第五讲 面向对象分析与设计（Object-oriented Analysis and Design）.ppt

创建Tier和Layer的包图 对每一层 确定(determine)存在什么应用组件 确定(determine)组件需求什么技术的API、通信协议或规范 确定(determine)应用哪种容器产品 确定(determine)应用哪种操作系统 确定(determine)应用什么硬件 Tier和layer的图（HotelApp） Tier和Layer的图（WebPresenceApp） 5.4.2 创建设计模型 设计模型是根据需求模型（用例和域模型）来创建的。 设计模型与架构模型结合产生出解决方案模型。 项目干系人 Mental Modle 需求模型 设计模型 解决方案模型 编码 NFRs FRs 架构模型 分析与设计的差异 分析能够帮助你对系统必须支持的业务过程（业务流程）进行建模： 用例 域模型 设计能够帮助你对系统是怎样支持业务过程进行建模。设计模型包括： 边界（用户界面）组件 服务组件 实体组件 从分析到设计的转换——鲁棒性分析 鲁棒性分析是这样一个过程，它采用鲁棒图引导我们从用例转换为支持用例实现的职责模型： 需求模型 设计模型 SRS 用例模型 域模型 鲁棒性分析 鲁棒性分析的输入： 一个用例 这个用例的用例场景 这个用例的活动图（如果可以用到） 域模型（domain model） 鲁棒性分析的输出： 通过一个UML序列图和一些设计组件：边界、服务、实体组件，得出用鲁棒图表示的设计模型。 边界组件 抽取用户界面、传感器(sensors) 、通信接口等。 高层（High-level）用户接口组件。 每一个边界组件必须至少与一个参与者关联起来。 “一个边界类（或者边界组件）用于针对系统和参与者（用户或者外部系统）之间交互建模。”（Jacobson，Booch，和Rumbaugh 第183页）。 BookingAgent ResvUI 服务组件 调整控制流 在工作流中隔离所有从边界组件到实体组件的更改。 （“控制（服务）类（组件）扮演协调、序列化、事务以及控制另外的对象的角色，而且他们经常被用来封装与某个特定用例的控制。”Jacobson，Booch，和Rumbaugh 第185页）。 BookingAgent ResvUI ResvService 实体组件 实体通常与域对象通信 大多数实体是具有持久性的。 实体可以有非常复杂的行为。 “一个实体类（组件）通常用来模拟那些长期存在并且具用持久性的信息。”（Jacobson，Booch，和Rumbaugh 第184页）。 鲁棒性分析过程 1.选择一个适当的用例。 2.把一个参与者放到协作图里面。 3.分析这个用例（活动图）。 对于用例的每一个动作： a.确定并增加边界组件 b.确定并增加服务组件 c.确定并增加实体组件 d.画出这些组件间的关联 e.把每个组件都贴上用来满足用例交互的动作标签 4. 把协作图转换成序列图（可选） 第1步——选择一个用例 选择一个用例：创建预约 1.顾客联系预约代理 2.预约代理选择“新建预约”图标 3.预约代理输入查询标准 3.1预约代理输入入住和退宿日期 3.2预约代理输入房间类型 4.预约代理点击“查询”按钮 ………… 11预约代理输入顾客姓名 12.预约代理点击“查询”按钮 13.如果没有找到匹配的顾客： 13.1预约代理输入地址信息 13.2预约代理输入电话信息 13.3预约代理点击“增加新顾客” 14.否则 14.1系统显示匹配信息列表 14.2预约代理选择所要查找的顾客 14.3系统跳转到顾客信息界面 ………… 21.系统保存预约并显示预约编号 22.预约代理点击“确定” 第2步——在图中放置参与者 把参与者放到协作图中： 第3a步——确定边界组件 活动：2.预约代理选择“新建预约” 第3a步——确定边界组件 活动：2.预约代理选择“新建预约” 第3b步——确定服务组件 活动：2.预约代理选择“新建预约” 第3c步——确定实体组件 活动：2.预约代理选择“新建预约” 在活动图里分析所有动作 活动：3.预约代理输入查询标准 在活动图里分析所有动作 活动：4.预约代理点击“查询”按钮 把协作图转换成序列图 为了给鲁棒性分析提供另外一个视角，可以把协作图转换成序列图。这个图对开发者而言将更为有用。 下一个部分将描述UML序列图。 利用序列图弄清设计模型 1.按照对第一次动作反映的时间顺序将合作者安排在序列图的顶部。 2.在第一次活动中为每一个消息添加信息链（message link）和活动条（activation bars）. 3.对于每一个活动都重复第2步操作，直至转换完成为止。 第