UML2 构架设计基础.ppt

-*- 封装技巧：边界类(2) 如果系统边界(用户界面、系统接口)不太可能进行大的更改 将边界类和在功能上与它们相关的类打包到一起 -*- 封装技巧：功能相关的类(1) 确定类在功能上是否相关的标准： 如果某个边界类的功能是显示一个特定的实体类，它就可能在功能上与该实体类相关 如果两个类与同一个参与者进行交互，或受到对同一个参与者更改的影响 一个类的行为和（或）结构的变化使得另一个类也必须相应地变化 一个类的删除影响其它类 两个对象进行大量的消息交互，或者以一种复杂的方式相互通信 两个类之间存在某些关系 一个类创建另一个类的实例 -*- 封装技巧：功能相关的类(2) 下列情况一般不应将两个类放在同一个包中 与不同参与者相关的两个类不应放在同一个包中 一个可选类和一个必选类不应放在同一个包中 -*- 实例：旅游申请系统分包考虑 考虑的几个要素 考虑用户界面的不确定性，将用户界面单独打包(User Interface) 系统核心业务为申请旅游团，与申请相关的业务打包为Application Services包，负责前端与申请相关的业务处理 与参与者相关业务可以考虑和其它系统的复用(如与CRM系统)，与路线管理相关的业务也存在一定的复用性，这些均可放在单独的包中，作为旅游业务相关的基础业务服务单元(Tour Artifaces) -*- 实例：旅游申请系统分包结果 -*- 3.3 子系统和接口 接口(Interface)是类、子系统或构件提供的操作的集合 接口允许用户以公开的方式定义多态，并且和实现没有直接联系 接口支持“即插即用”的结构 实现(Realization)关系 -*- 子系统(Subsystem)是一种介于包和类之间的一种设计机制，它实现一个或多个接口所定义的行为 具有包的语义：能够包含其它模型元素 具有类的语义：具有行为 -*- 子系统的作用 完全封装了行为 利用清晰的接口代表所拥有的能力(便于复用) 可以定义不同的实现 -*- 子系统 VS. 包 子系统： 提供行为 完全封装实现细节 容易替换 包： 不提供行为 不完全封装实现细节 难以替换 关键在于封装 -*- 子系统的主要用途 子系统可以将系统划分成独立的部分，将被实现为独立的构件，这些构件在保持结构不变的情况下，可以 独立地开发和部署， 适应变更，而不影响到其它系统 子系统也可用于 将系统划分成若干单元 表示设计中的既存产品或外部系统 -*- 候选子系统 可能发展为子系统的分析类 提供复杂服务和(或)通用功能的类 边界类(用户界面和外部系统接口) 设计中既存产品或外部系统 通信软件 数据库访问支持 类型和数据结构 通用程序 专业应用软件产品 -*- 确定子系统 如果分析类相当复杂，以致它所包含的行为无法由单个类(或几个类的简单组合)来独自负责执行，此时应该考虑将该分析类映射到设计子系统 使用设计子系统来封装协作 子系统客户在完全不知道内部设计的情况下可以很方便的使用它提供的服务 子系统内部的实现细节则延迟到子系统设计阶段 -*- 确定子系统示意图 Superman Class -*- 确定子系统的接口 目的 基于子系统的职责确定其接口 步骤 为每个子系统确定一个备选接口集 寻找接口之间的相似点 定义接口依赖关系 将接口映射到子系统 定义接口所指定的行为 将接口打包 -*- 指南：确定接口 接口名 反映在系统中的作用 接口描述 表达职责 操作定义 名称应反映出操作的结果 说明操作做什么，以及所有参数和结果 接口文档 交互图、状态图、测试计划… -*- 实例：确定子系统和接口 考虑作业“旅游业务申请系统”中的下列用例模型的分析和设计策略 添加接口和子系统后，软件构架也会相应的调整 引入接口和子系统后的架构 -*- 3.4 更新软件架构 构架设计基础 -*- 主要内容 8.1 过渡到设计 8.2 构架设计基础 8.3 确定设计元素 重点：确定设计元素 难点：确定设计元素 课时：2课时 -*- 学习路线图 OO UML OOP DP … Case-Study … 学 习 路 线 图 …………………… 1 2 3 4 5 6 7 8 9 10 -*- 软件设计的定义 IEEE 1990：设计是构架、接口、构件、以及系统其它特征定义的过程 -*- 更精确定义 软件设计（的结果）必须 描述系统的构架（architecture） 系统如何分解（decompose）和组织（organize）构件 描述构件间的接口（interface） 描述构件（component）：必须详细到可进一步构造的程度 -*- 软件设计知识域(SWEBOK) D-设计（Decomposition design） 将系统映射为构件片（component pieces） FP-设计