2015年软考系统架构设计师学习笔记第六章（3）
发布时间：2010/12/4 22:18:30 来源：城市学习网 编辑：ziteng
6.3.2 基于 UML 的需求分析
1、生成用例
如果多个用户扮演同一角色，这些用户将由单一执行者表示。如果一个用户扮演多种角色，则需要多个执行者来表示同一用户。
用例主要来源于分析人员对 场景的 分类和抽象，即将相似的场景进行归类，使一个用例可以通过实例化和参数调节而涵盖多个场景。
2、用活动图表示用例
3、生成用例图
执行者与用例之间的关系有两种：触发执行、信息交换。
执行者指向用例 表示 触发执行 和/或 信息交换，用例指向执行者 表示用例将生成的信息传递给执行者。
4、建立顶层架构
顶层架构便于开发人员 聚焦于系统的不同部分。
模型——视图——控制器(Model、View、Controller，MVC)模式。
模型 维护并保存数据，视图 呈现数据，控制器将动作映射为处理功能并实际调用。
MVC 模式特别适合于分布式应用软件，尤其是web应用系统。
分层模式 降低软件系统的 耦合度。
确立顶层架构的过程中需综合考虑以下因素：
包的数量，架构过早地陷入细节，返工的可能性很大，也不合理地限制了后续分析和设计活动的自由空间。
包之间的耦合度。
将不稳引起的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。
可选功能 和 必须实现的功能 置于 不同的包。
根据开发人员 专长 划分，使每个包都能分配给最合适的开发人员，有利于并行开发。
6.3.3 面向对象的设计方法
1、设计用例实现方案
1.提取边界类，实现类和控制类。
边界类用于描述 系统与外部环境之间的交互。
a.界面控制。
b.外部接口。
c.环境隔离。使目标软件系统的 其余部分 尽可能地 独立于环境软件。
边界类，《boundary》。
实体类“内向收敛”特征，仅提供 读/写 信息的必要操作 作接口，并不涉及业务逻辑处理，《entity》。
控制类，《control》。
边界类的作用范围可以超越单个用例。 [NextPage] 2.构造交互图
交互图作为用力的精确实现方案。
事件流中的事件 直接对应交互图中的消息，事件间的先后关系体现为 交互图中的时序，对消息的响应 则构成消息接收者的职责，这种职责被确立为 类的方法。
不应该出现 穿越控制类 生命线 的消息。
为 易于理解，应该用分离的 UML 交互图 分别表示 事件流和每个备选事件流。
原则上，每个类都应该有一个操作来响应交互图中指向其对象的那条消息。
2、设计技术支撑方案
当用户需求发生变化时，技术支撑方案应具有良好的稳定性。
技术支撑方案应该位于层次结构中的较低层次。
一方面取决于 需求，另一方面取决于 对软件技术手段把我和选取。
3、设计用户界面
1.熟悉用户 并对 用户分类，以便尽量照顾到所有用户的合理要求，并优先满足某些特权用户。
2.按用户类别 分析用户的 工作流与习惯，从每类中选取一个用户代表，建立调查表，判断用户对操作界面的需求和喜好。
3.首先应考虑命令的顺序，一般常用命令居先，与用户工作习惯保持一致;其次，根据外部服务之间的聚合关系组织相应的命令;然后充分考虑人类记忆的局限性，最好组织为一颗两层多叉树;提供操作的快捷方式。
5.利用快速原型演示，改进界面设计。并评判系统是否 齐全、方便、好用。
4、精化设计模型
对模型进行改进的活动可以分为 精化 和 合并 两种。一般先从精化开始。设计优秀的粗粒度组件应该只是完成一项功能，这一点是它与子系统的主要区分。
粗粒度组件的范围过于广泛，难以发挥重用价值，粗粒度组件拥有持久化的行为，拥有业务逻辑，需要表示层的支持。
将需求分成几个功能组，基本上就可以得到相应的粗粒度组件了。
过小的范围，将会造成粗粒度组件不容易使用，用户需要理解不同的粗粒度组件之间的复杂关系。
如果可能，在粗粒度组件之间定义单项关联可以有效的减少组件之间的耦合。
尽可能简化组件之间的关系。
我们需要从软件的目标领域中 识别出关键性的实体，或者说领域中的名词。然后决定它们应该归属于那些粗粒度组件。
两个组件之间存在重复的要素，可以从中抽取共性的部分，形成新的组件。
6.4 系统架构文档化
