<<需求分析与系统设计>>读书笔记之三

　　终于把《需求分析与系统设计》读完了，感受很多，虽然理解还不是透彻，但还是学到了不少知识。在软件需求规格说明中，需要用图形和其他形式化模型来说明需求，为了完整地说明一个系统，有必要采取多种模型。UML提供了许多集成化的建模技术来辅助系统分析师来完成这项工作。规格说明的过程是迭代增量式的。对成功的建模来说，使用case工具是必须的。需求规格说明产生三种模型：状态模型，行为模型，状态变化模型。需求规格说明涉及需求确定期定义的客户需求进行严格的建模，重点放在那些系统将要提供的所期望的服务上。在规格说明阶段通常不对系统约束做进一步的考虑，但系统约束可以指导和验证建模工具。这种指导和验证采用体系结构优先权的方式。软件体系结构定义了系统中相互作用的软件构件及子系统的结构和组织方式。软件体系结构捕捉并保存设计人员关于系统结构和行为的设计意图，因此它提供了一种对设计的保护措施，以防止作为系统阶段的设计出现失败。在详细的系统规格说明工作开始之前，软件开发团队必须选定全体开发人员都要遵循的体系结构模式和原则，这是至关重要的。如果系统没有清晰的体系结构视图，那么分析阶段就是在为一个不可支持的系统交付规格说明。所有软件建模的最重要目标都是将构件依赖最小化。为了做到这一点，开发人员不能随意的对象通信那会造成混乱的不可理解的构件通信网络。随着模型的增长和每个对象的加入，这样的系统复杂性会指数上升，这是无法容忍的，必须在它造成破坏之前停止。在生命周期早期，就必须采用一种具有分层的构件和子系统，并严格控制对象通信的，清晰的体系结构模型。

　　在迭代和增量软件开发中，使用技术细节不断地对模型进行细化，一旦技术细节考虑软件/硬件，分析模型就变成了设计模型。系统设计包括两个方面的主要问题:系统的体系结构设计和系统中程序的详细设计。体系结构设计是从系统的模块方面对系统进行描述，包括确定系统的客户机构件和服务器构件的解决方案策略。体系结构定义类与包的分层组织，将进程分配给计算设施，复用和构件管理。体系结构设计解决多层物理体系结构及多层逻辑体系结构的有关问题。体系结构设计具有物理和逻辑两个方面。物理体系结构设计关注部署方案的选择及系统的工作负荷在多处理器上的分布。物理体系结构解决客户机和服务器问题，以及粘接客户机和服务器所需要的任何中间件问题。它将处理构件分配给计算机节点。大多数企业信息系统采用分层体系结构，相对于对等体系结构，分层体系结构定义计算层次。软件开发者知道创建小系统的困难是不能与大型解决方案的困难相比的。小系统易于理解，实现和部署。大型企业系统由相应随机事件的大量对象组成，这些随机事件会引发相互关联的操作混乱。没有清晰的体系结构设计和严格的过程，大型软件项目注定要失败。

　　系统的行为，就是它展现给外部用户的，通过用例来描述，用例模型可以在不同的抽象层次上生成。它们可以将系统看做一个整体，说明开发中的应用所具有的主要功能单元。在分析期，用例通过关注系统做什么或者应该做什么来捕捉系统需求。在设计阶段，用例视图可以用来说明系统将要实现的行为。由用例制定的行为，要求通过计算以及对象间的交互来执行一个用例。计算可以用活动图建模，对象的交互可以用顺序图或者通信图来说明。行为规格说明提供系统的操作视图，主要任务是定义应用领域中的用例，并确定在这些用例的执行中将涉及哪些类，标示类操作和对象操作之间的信息传递。虽然对象交互也会引起对象状态的变化，但在行为规格说明中，我们只定义关于系统的冻结状态的操作视图，对象状态的变化将在状态变化规格说明中明确地描述。