RationalRose培训

1、rational rose & oo建模 臧立威 课程目标 n了解可视化建模的相关知识 n能够使用rational rose n能够看懂别人用uml表示的设计 n具备oo建模的基本技能 课程内容 n1. 可视化建模基础 n2. oo基础 n3. 需求建模 n4. 基于团队的建模 n5. 分析 n6. 设计 n7. 正向工程和逆向工程 1. 可视化建模基础 什么是可视化建模 业务流程 计算机系统 可视化建模 可视化建模就是用标准 的图形表示法来建模 “建模获取系统的关键 部分” um l 可视化建模的作用（1） n可视化建模获取业务流程 n用例（use case）分析是一种从用户的角度获取业务流

2、程 的技术 n使用相同的语言，不至于产生歧义 n用例分析能让分析师在构建系统之前理解要构建什么 可视化建模的作用（2） n可视化建模是一个交流工具 业务领域 计算机领域 业务对象和逻辑 业务对象和逻辑 可视化建模的作用（3） n管理复杂性 n把3000多个类放在一张图中不好 n可视化建模的“包”（package） n把元素模型化成有意义的组合 n为不同的人提供不同级别的抽象 n软件构架(architecture) logical view physical view user interface business logic database vb java c+ java c+&sql 可视

3、化建模的作用（4） n促进复用(reuse) n复用是软件的“圣杯” n不止是复用代码，而是复用建立原始工件时需要 的所有分析、设计、实现、测试、文档化 n可以有一个类复用、多个类（或一个组件）的复 用、应用模式等复用方式 n可视化建模让你从复用的角度看，如果想复用工 件，什么是可用的 什么是uml numl(unified modeling language)是可视化、说明、 构建和文档化软件系统工件的标准语言 numl可以做下面的建模 n数据建模 n业务建模 n对象建模 n组件建模 numl可以用于可视化建模 n系统与外界的交互 n系统的行为 n系统的结构 n系统的构架 n系统的组件 视图

4、（views） n模型由不同的view和diagram构建而成，描述了不同 的视点和系统的构建块 nview是一个对特定涉众有意义的模型的视点 nview是模型的“碎片” nrose中的“4+1view” logical view 分析师 设计师 structure process view 系统集成员 performance scalability throughput implementation view 编程人员 software management use-case view 最终用户 functionality deployment view 系统工程 system topolo

5、gy delivery installation communication 图（diagrams） n用例图（use case diagram）：模型化系统与外界的交互 n类图（class diagram）：模型化系统的结构 n时序图（sequence diagram）：模型化系统的行为 n协作图（collaboration diagram）：模型化系统的行为 n组件图（component diagram）：模型化组件的组织和依赖 n部署图（deployment diagram）：模型化系统的硬件分布 n活动图（activity diagram）：模型化系统内的事件流 n状态图（statec

6、hart diagram）：模型化状态相关的方面 模型结构 view作用作用模型模型图图 use case view是其他view的“心 脏”，说明系统做什什 么么 use case model use case diagram activity diagram（可选） statechart diagram（可选） logical view支持系统的功能性需 求 analysis model （可选） design model class diagram sequence diagram collaboration diagram activity diagram（可选） statechart

7、 diagram（可选） process view阐述系统的性能、伸 缩性和吞吐量 process modelclass diagram implementation view 以分包、分层和配置 管理的形式描述了静 态软件模型的组织 implementation model component diagram deployment view 如何把执行体和其他 运行时组件映射到下 层平台或计算节点 deployment model deployment diagram rational rose的界面 nbrowser让你可以文本化的查看和导航views和diagrams n不在browse

8、r中的元素就不是模型化系统的一部分 ndiagram window让你可以创建、修改和模型化当前模型的 图形化视图 ndiagram toolbar n包括构建diagram的元素 n每个diagram都有自己独特的toolbar n只有显示diagram时才是活动的 ndocumentation window用于创建、查看或修改解释diagram 中被选项目的文本 nlog window报告进度、结果和错误 ntitle组成 nrational rose-模型名-xx diagram:diagram所在的package名/diagram 名 rational rose 2. oo基础 对象

9、n对象是一个有定义良好的边界和标识，并封装了状态（state）和行为 （behavior）的实体。可以是物理的（如一个卡车）、概念的（如一个 化学过程）或软件的（如一个链表） n状态 n是对象可以处于的状况 n对象的状态随时间变化 n用属性（attribute）和关系（relation）表示 n行为 n行为决定对象如何动作和做反应 n对象的可见行为用一系列它响应的消息来模型化 n用操作（operation）、方法（method）和状态机（state machine）表示 n标识（identity） n每个对象有唯一的标识 n例如，一个名叫j clark的教授对象的信息如下（她的状态是tenur

10、ed）： nname: j clark nemployee id：567138(标识) nstatus: tenured ndiscipline: finance 类 n类是对一系列具有相同属性、操作、关系和 语义的对象的描述 n对象是类的实例 n类定义了它的所有对象的结构和行为的模板 面向对象的基本规则 n抽象（abstraction） n对象区别于其他对象的本质特征 n定义与使用者视点相关的边界 n不是具体的表现，而是理想化的本质 n封装（encapsulation） n对用户隐藏了实现，用户只能通过接口与对象通信 n封装通常叫“信息隐藏” n封装使对象的状态不受用户的影响，使用户不受对象

11、实 现变化的影响 n模块化（modularity） n把复杂的东西分成可管理的小块 n帮助人们理解复杂的系统 3. 需求建模 需求流程 用例模型 n为什么要创建用例模型 n用例模型允许顾客和系统开发者之间用一种用户可以理 解的语言交流系统要做什么 n你可以认为用例模型是顾客和开发者之间的可视化契约 n什么是用例模型 n在use-case view中创建 n用例模型代表了从最终用户角度看的系统的功能和环境 n是顾客和开发者之间的契约 n对于分析、设计和测试活动都是至关重要的 n包括用例图、用例规约和补充规约，也可以包括活动图 用例图（use case diagram) n用例图表示了用例和主角以

12、及用例和用例之间的关 系 n可视化的表示出了客户希望系统做什么 n代表一些大的完整的功能 n表示系统完成的有明确结果的对主角有价值的一系列动 作 n可以模型化 n所有的主角和用例（global view） n某个选定主角的所有用例 n一个用例以及它所有的关系 n一个迭代的所有的用例 用例图的元素 n主角 n用例 n关系 registration student 主角（actor） n定义：系统外的与系统进行交互的人或事物 n种类 n人 n外部系统 n外部设备或timer n识别actor要依据actor的定义，可以这样查 找： n有哪些用户使用系统？ n系统会用到哪些外部的系统或设备？ n有什

13、么外部系统或设备会用到要开发的系统？ n有没有定时触发的行为？ 主角（actor） n如何判断一个事物是不是actor n首先它必须与系统有交互，如果与系统没有交互 则不是主角 n其次它必须是系统外的，如果它是我们将要开发 的系统或是系统的一部分则不是主角 n其它 n用户如果通过标准的输入和输出设备与系统交互 则用户是actor n用户如果通过特殊的设备与系统交互，则设备是 actor 用例（use case） n定义：是actor与系统的一系列交互 n特点： n完成actor的某个目的（不是功能），一般会给actor一个 有价值的结果 n起始于actor的输入 n其中，系统是一个黑盒 n用于

14、描述系统行为，但不描述如何实现 n识别用例的依据就是用例的定义和特点 n识别用例时需要注意 n用例的粒度不要太大也不要太小 n用例描述的是系统做什么，初始识别用例的时候不要过 多考虑系统的实现，即把系统作为黑盒 n外部系统或设备的行为不是要开发的系统行为，不要识 别出来用例 用例（ use case） n有些用例不代表系统的主要功能，因而通常 会被大家忽视，这些用例可能属于以下类型： n系统启动和停止 n系统的维护。例如，添加新用户和建立用户简档 n维护在系统中存储的数据。例如，所构建的系统 和遗留系统平行工作，所以数据需要在两个系统 之间达到同步 n修改系统行为所需的功能。例如创建新报告的功

15、 能，它不仅可以创建硬代码，还可以对系统中存 储的数据创建一组特定报告 actor和use case的关系 nactor与use case之间的关系是association关系， 含义是“触发”，千万不要理解成数据流 systemstartup (from system) driver (from actors) rose操作加入模型元素 n从browser窗口中加入 n选择要加入模型元素所在的package，单击鼠标 右键，从弹出菜单中选择new-模型元素种类 （如class，package，use case diagram等），此时 相应的包下面就会加入一个新的元素，你可以为 它命名 n从

16、diagram的toolbar中直接加入 n从toolbar中选择要加入的元素类型，单击diagram 窗口的某个位置，新的元素就会显示到diagram 窗口中，此时你可以为新元素命名。同时 browser中也出现新的元素（新的模型元素会加 入到相应的diagram所在的包中）。 rational rose rose操作更改模型元素 n双击browser或diagram中的元素（或者单击鼠 标右键，从弹出菜单中选择open specification） 就会打开新建元素的specification，在 specification对话框中，你可以更改名字以及 做其他的设置 n注意：diagram

17、没有specification n注意：双击diagram中的package，不会打开 它的specification，而是进入package下的某个 类图 rational rose rose操作删除模型元素 ndelete from model：模型元素从模型中删除 （也从它参与的所有图中删除） n从browser中选择要删除模型元素，单击鼠标右 键，从弹出菜单中选择delete，或者 n从diagram中选择要删除模型元素，从菜单中选 择edit-delete from model（快捷键ctrl+d） ndelete from diagram n从diagram中中选择要删除模型元素，

18、从菜单中 选择edit-delete （快捷键del） rational rose 实践 ndemo n识别atm系统的主角和用例，并在rose中画出用 例图 详细用例模型 nactor之间的关系泛化（generalization） nuse case之间的关系 n泛化（generalization）：不常用 n扩展（extend） n包含（include） super actorsub actor 用例之间的扩展关系 n扩展关系的双方分别叫做基本用例（base use case）和扩展用例（extension use case） n扩展用例用来模型化基本用例中 n有条件的部分，只在某些环境下

19、执行 n复杂的或可选的路径。 n扩展关系用stereotype是“extend” 的 association关系来表示 extensivebasic 用例之间的扩展关系 n扩展用例和基本用例的关系 n基本用例自身应是完整的，即基本用例在不必引用任何 扩展用例的情况下，应该是可理解且有意义的 n基本用例可以不依赖于扩展用例而单独的运行 n扩展用例只有在基本用例中的某种条件满足时才能执行， 如果没有基本用例，扩展用例不能运行 n扩展用例可以扩展多个基本用例 n扩展点 n定义在基本用例的哪些位置插入扩展用例 n包括一个名称和对用例事件流中一个或多个位置的引用 n一个扩展点可以引用基本用例内的两个行为

20、步骤之间的 单个位置，也可以引用一组不连续的位置 扩展关系的实例 n在电话系统中，为用户提供的主要服务通过用例“打电话” 来表示。可选服务的示例包括 n能让第三方加入通话（召开电话会议） n允许接收方看到呼叫方的身份（显示呼叫方身份） n我们可以将这些可选服务所需的行为表示为基本用例“打电 话”的扩展用例，由于“打电话”本身就具有意义，您无需 阅读扩展用例的说明就可理解基本用例的主要目的 callercallee plae conference call show caller identify place call 用例之间的包含关系 n包含关系的双方分别叫做基本用例（basic use c

21、ase） （或具体用例, concrete use case）和包含用例 (included use case)（或抽象用例, abstract use case） n包含用例用来模型化基本用例中 n多个用例都包含的路径 n复杂的路径 n包含用例要能生成一个有意义的结果 n扩展关系用stereotype是“include” 的association关系 来表示 basic use caseincluded use case 用例之间的包含关系 n抽象用例和具体用例 n抽象用例不能单独执行，必须与包括（也就是执 行）它的具体用例一起执行 n抽象用例没有特定的actor，它的actor实际上包 括

22、它的具体用例的actor n抽象用例可以被几个其他的用例复用 n具体用例的基本流执行时，抽象用例一定执行 扩展关系和包含关系 n共同点 n扩展用例和包含用例都是基本用例的一部分 n基本用例不执行，扩展用例和包含用例都不会执 行 n扩展用例可以扩展多个基本用例；包含用例可以 被多个基本用例包含 n区别 n扩展关系中基本用例的基本流执行时，扩展用例 不一定执行，即扩展用例只有在基本用例满足某 种条件的时候才会执行 n包含关系中基本用例的基本流执行时，包含用例 一定会执行 包含关系的实例 n在 atm 系统中，用例 withdraw cash、deposit cash和 transfer funds

23、都需要包含系统识别客户的过程。可以将此 行为抽取到一个名为 identify customer的新包含用例中 n从基本用例的角度来看，识别客户方法是读取银行磁卡还是 执行视网膜扫描并不重要。它们仅依赖于 identify customer 的结果，即客户的身份。 n从 identify customer 用例的角度来看，基本用例如何使用客 户身份或者在执行包含用例之前基本用例中发生了什么并不 重要：识别方法都会完全相同 withdraw cash transfer fundsdoposit cash identify customer stereotype的作用 n扩展模型元素 n例如rose

24、中没有extend和include关系，于是用 stereotype是“extend”和“include”的association关 系来表示 n给模型元素分类 n例如将来把分析类分成“boundary”、”entity”和 “control”三种 rational rose 用例规约（use case specification） n用例名字（name） n简要说明（brief description） n事件流（flows of events） n特殊需求（special requirements） n前置条件（pre-conditions） n开始用例前所必需的系统及其环境的状态 n后置

25、条件（post-conditions） n用例结束后系统可能具备的状态 n扩展点（extension points） 事件流 n事件流用文本形式描述了用户和系统之间如何进行 交互 n用例的执行有很多种情况，每一种情况就是一个场场 景景 （scenario），用例的事件流应该描述出所有的 场景 n事件流分成基本流（基本流（basic flowbasic flow）和备选流备选流 （alternative flowalternative flow）两种 n基本事件流应包括在执行用例时“通常”会发生的事件， 也叫happy flow n备选事件流包括与正常行为相关的可选或异常特征的行 为，同时也包括

26、正常行为的各种变形 n可以将备选事件流看作是基本事件流的“绕行道”，有 些备选事件流将返回到基本事件流，而有些将结束此用 例的执行 前置条件和后置条件 n前置条件或后置条件所说明的状态应该是用户可以 观察到的状态 n前置条件是对用例何时开始的约束，它并不是使用 例开始的事件 n虽然可以在分支流级别定义前置条件和后置条件， 但是一个用例的前置条件并不只是一个分支流的前 置条件 n无论执行了哪些备选流，用例的后置条件都应为 “真”；它不能只对主事件流为“真”。如果可能 出现故障，则应在后置条件内包括“该动作已经完 成，或者，如果可能出现故障，则不执行该动作”， 而不只是“该动作已经完成” 实践 n

27、demo n描述withdraw用例的用例描述 4. 基于团队的建模 基于团队的建模 n受控的演化 nrose通过使用uml包和子系统支持基于构架的 建模 nrose帮助用户在不影响其他人工作的情况下进行 详细设计 nrose帮助用户避免创建构架单元之间不恰当的联 系 n把模型划分成在构架上有重大意义的单元 n可以分成叫做受控单元的单独的文件 n构架上有重大意义的模型元素的复用 rational rose 受控单元 n受控单元 n是rational rose保存模型全部或一部分的文件 n是能进行版本控制的模型元素 n定义了单个开发人员可以操作模型的一部分 n在团队中共享 n让团队可以平行开发

28、n一定是包 n下面元素可以作为受控单元 n模型文件本身(.mdl) n逻辑视图和用例视图包(.cat) n组件视图包(.sub) n部署视图的图(.prc) n模型属性(.prp) rational rose 受控单元 n受控单元可以被loaded或unloaded n可以load模型的一部分，这样就减少了启动延迟、资源 消耗和维护对unloaded的单元的索引 n可以被write enable或write protect（手动的或自动的） n子受控单元具有独立于父受控单元的写保护 n即使有版本控制系统，也可以对受控单元进行写保护控 制 nreload模型后，写保护失效 n手动写保护不影响文件

29、系统的访问权限 nmodel workspace是当前装载的受控单元和打开的 diagram的快照 nmodel包括组成完成模型的图、元素和受控单元 nmodel workspace包括某个model在某一点上的打开的图和 受控单元的实际状态 rational rose 虚路径 n虚路径使模型可以在不同的目录结构中移动， 可以从不同的workspace上修改。 rational rose 虚路径使model脱离物理位置 虚路径 物理路径 5. 分析 分析和设计流程 分析和设计 分析设计 侧重于理解问题侧重于解决问题 功能需求非功能性需求 系统结构 行为(behavior) 操作和属性 对象的生

30、命周期 小模型大模型 用例实现 n用例实现 n对用例模型中的每个用例，在设计模型中都有相应的实现 n提供从分析和设计到需求的可跟踪性 n用例实现结构 n用例实现包 n是组织用例的类和交互图的方式 n每个用例都对应一个用例实现包 n可跟踪性图 n交互图 n时序图（sequence diagrams）（动态） n协作图（collaboration diagrams） （动态） n类图（class diagrams） （静态） registration (from use case view) registration 分析类 n分析类代表“系统中具备职责和行为的事物” 的初期概念模型。这些概念模型

31、最终将演进 为设计模型中的类和子系统 n分类 n边界类（boundary class） n接口与系统外部某些事物的媒介 n控制类（control class） n负责协调用例的行为 n实体类（entity class） n封装了数据以及数据相关的操作 边界类 n边界类帮助系统接口与系统外部进行交互。边界对 象将系统与其外部环境的变更（与其他系统的接口 的变更、用户需求的变更等）分隔开，使这些变更 不会对系统的其他部分造成影响 n分类 n用户接口类 n帮助与用户进行通信的类，通过标准的i/o设备提供人机界面 n系统接口类 n帮助与其他系统进行通信的类，系统接口对象隐藏如何与外部接 口通信的细节

32、n设备接口类或timer n提供对硬件设备的软件接口 控制类 n作用 n用于对一个或几个用例所特有的控制行为进行建模，控制类封装了 用例的特有行为 n控制对象（控制类的实例）通常控制其他对象，因此它们的行为具 有协调性质 n控制类有效地将边界对象与实体对象分开，让系统更能适应其边界 内发生的变更 n控制类还将用例所特有的行为与实体对象分开，使实体对象在用例 和系统中具有更高的复用性 n控制类并不能处理用例需要执行的一切事务。相反，它协调其他用 来实施此功能的对象的活动。控制类将工作委派给已被指定负责此 项功能的对象。控制类通常被看成一个乐队的指挥，它指挥（控制） 参与use case的其它对象

33、的行为，通知对象什么时候执行以及执行 什么。 n有的用例没有控制类，复杂的用例可以有多个控制类 n控制对象的生命周期通常和用例实例的生命周期相同 实体类 n作用实体类是用于对必须存储的信息和相关行为建 模的类。实体对象用于保存和更新一些现象的有关 信息，例如事件、人员或者一些现实生活中的对象 n实体类的特点 n实体类通常都是永久性的，它们所具有的属性和关系是 长期需要的，有时甚至在系统的整个生存期都需要 n一个实体对象通常不是某个用例实现所特有的；有时， 一个实体对象甚至不专用于系统本身 n属性和关系的值通常由主角指定，执行系统内部任务时 也可能要使用实体对象 n实体对象的行为可以和其他类的对

34、象的行为一样复杂。 但是，与其他对象不同的是，这种行为与实体对象所代 表的现象具有很强的相关性 n实体对象是独立于环境（主角）的 n实体对象代表了开发中的系统的核心概念 查找分析类 n每个用例主角对都至少有一个边界类 n可以首先为每个用例实现确定一个控制类，接着， 在确定了更多的用例实现并发现更多的共性后，再 对其进行改进 nactor的信息可以作为一个实体类 n用过滤名词方法寻找实体类 n在use case flow of events中画出名词 n去掉重复的候选 n去掉含糊的候选 n去掉actor n去掉实现结构 n去掉属性 n去掉操作 n此时剩下的名词一般就是实体 记录分析类 n在“de

35、sign model”包中加入识别出来的分 析类 n分析类的类型用类的stereotype表示 n如果能说明某个分析类的责任，就给该分析 类加上说明 实践 ndemo n识别课程注册系统中register for course用例的分 析类 将行为分配给分析类 n用时序图和协作图来描述用例行为 n是动态建模的一部分 n每个用例的每个事件流（基本流和备选流） 建一个或多个时序图和协作图 n具有多个复杂时间点或者判定点的分支流通 常需要用不同的图来说明，而复杂流因为太 长而无法用一个图来把握时也需要用不同的 图来说明 n一般都是从时序图入手，生成了时序图之后， 在 rose的browser中选择时

36、序图，然后按 “f5”键，就会生成该时序图对应的协作图 时序图 n时序图表示如何一步步的完成系统的一个功能 n时序图是用于决定类责任和接口的主要信息来源 n时序图描述了对象间的交互模式 n通过对象的“生命线”和他们相互发送的消息来显示对 象 n时序图与协作图在语义上是相同的，只是时序图中的消 息是按时间顺序分布的 n时序图表示的是一个场景(scenario) n组成 n主角(actor) n对象(object) n消息(message)：消息可以有sequence number n生命线(lifeline)：表示对象在特定时间的存在 nfocus of control：表示对象直接或通过子过程

37、执行动作的 一段时间 时序图的元素 协作图 n协作图显示对象之间的交互 n协作图强调参与交互的对象的组织 n适合分析活动，适合表示少数对象的简单交互 n协作图很难显示补充的说明性信息，例如时间、 判定点或其他非结构化的信息，而在序列图中这 些信息可以方便地添加到注释中 n组成 n主角(actor) n对象(object) nlinks：link是对象通信的途径 n消息(message) 协作图的元素 实例 ndemo n课程注册系统中register for course用例的用例分 析 类的职责 n在开发初期，类的属性和操作不一定被定义， 但是我们知道了类的职责 n类的责任就是类可以提供的事

38、物的状态或契约 n类的责任用/表示 类图 n类图 n表示一系列类、接口和它们的关系 n表示系统的静态视图，在logical view中 n用例实现的类图又叫vopc（view of participated classes） nvopc类图表示用例实现的参与类以及这些类之间的关系 n确保跨越子系统的用例实现的一致性 n类图的元素 n类 n关系 类之间的关系 ndependency（依赖） n体现“暂时使用”的含义，或者b的变更会导致a的变更 n是一种暂时的关系 n可以有以下几种实现方式 n对象具有“全局”范围，系统中的任何对象都可以向它发送消息 n一个对象可以作为一个参数传递给第二个对象 n对

39、象可以在操作内创建和破坏（即“临时”对象） nassociation（关联） n体现“use ”的含义 n实现：类a的定义中有类b的指针变量 ab ab 类之间的关系 naggregation（聚合） n体现“is a part-of”(包含、拥有)的 含义 ncomposition（组合） n体现“is a part-of”(包含、拥有)的 含义 n组合与聚合的区别是组合的整体和 部分的object具有相同的生命周期， 而聚合则不同 ngeneralization（泛化） 或 inheritance（继承） n体现“is a kind of”的含义 n子类不仅继承了超类的attribute和

40、 operation，同时还继承了超类的 relationship n类之间关系的强弱顺序 n依赖 关联 聚合 组合 继承 ab ab superclass subclass 类之间关系相关的其它概念 nrole（角色）表示参与关联关系的对象在关联关系中承担的 角色 nmultiplicity（多重性）表示类a的一个object对应类b的几个 object，代表的是business rule nnavigability（导向性 ）表示对象访问的方向 n右图中 n0.1表示一个类b的对象可以对应0 个或1个类a的对象 n0.n表示一个类a的对象可以对应类 b的0个或多个对象 n关系上的箭头就是n

41、avigability，表 示类a的对象可以访问类b的对象， 但是类b的对象不能访问类a的对象， 如果关系上没有箭头，表示 navigability是双向的 识别分析类之间的关系 n识别分析类之间的关联关系有两个来源 n协作图：协作图中对象之间有联系，就意味着相应的类之间存在关 联关系 n领域知识：从中得到实体类之间的聚合关系 n注意： n不要添加您认为“或许”存在的关联关系，除非协作图要求添加这 些关联关系 n在分析时不用识别出类之间的关系是关联还是依赖，是聚合还是组 合，因为我们还没有作出明智决策所需要的足够信息，我们将在类 设计活动中改进 n对于继承关系，在分析时可以识别出来，但是不要求

42、 n是关联还是聚合 n选择聚合只是为了阐明一种整体/部分的关系 n如果拿不准是什么关系，通常关联关系更合适。聚合关系通常是很 明显的，聚合的语义应该很容易的从上下文中理解出来 n是聚合关系还是关联关系与开发的具体应用有关 记录类之间的关系 n用类图来表示类之间的关系 n用例实现的类图又叫vopc（view of participated classes） 实践 n方法 n在用例实现包中建一个类图，取名叫vopc n在类图中表示参与用例的所有类及其关系 ndemo natm系统的类图 6. 设计 process model ndemo n用类图描述课程注册系统的运行时结构 deployment

43、model ndeployment model的模型元素 nnode nphysical run-time computational resource nprocessor node n运行系统软件 ndevice node nsupport device ntypically controlled by a processor nconnection n通信机制 n物理媒介 n软件协议 ndemo：课程注册系统 设计元素接口和包 n接口 n接口是定义行为集（即操作集）的模型元素 n该行为集由classifier模型元素（即类、子系统或component）提供 nclassifier可以实现

44、实现一个或多个接口；一个接口可由一个或多个 classifier实现 n实现相同接口的那些classifier在系统中可以互换 n每个接口应该是唯一且明确定义的操作集 n设计包 n一个包中可以包含公有类，也可以包含私有类 n公有类可以与任何其他类相关联 n私有类只能与其所在包中包含的类相关联 n包接口由包的公有类组成，包接口隔离并实施对其他包的依赖关系 n包耦合的原则 n不应对包进行交叉耦合（即互相依赖），例如两个包不应互相依赖。 n较低层中的包不应依赖于较高层中的包，包只应依赖于同一层及下 一层中的包 n通常，依赖关系不应跳层，除非依赖行为在所有层之间都是共同的 设计元素设计子系统 n设计子

45、系统 n设计子系统是一种模型元素，它具有包（其中可包含其 他模型元素）和类（其具有行为）的语义 n子系统的行为由它实现的一个或多个接口来定义 n子系统的行为由它所包含的类或其他子系统提供 n子系统内部的元素对外不可见 n子系统的特点 n可以独立预定、配置或交付 n可以独立开发（只要接口保持不变） n可以在一组分布式计算节点上独立部署 n可以在不破坏系统其他部分的情况下独立地进行更改 n可以将系统分为若干单元，以提供对关键资源的有限安 全保护 n可以在设计中代表现有产品或外部系统 设计元素 n子系统和包的区别 n子系统比包封装性好 n子系统有接口，外部只能通过子系统接口访问子系统内部 n包没有接

46、口，外部可以直接访问包中公共的类 n子系统具有行为，而包没有 n子系统是一种通过一个或多个它所实现的接口来提供行为的包 n而包并不提供行为它们只是用来容纳对象的容器 n子系统依赖关系 n子系统不应暴露自己的任何内容；子系统外部的元素都 不应依赖于子系统内部特定元素的存在 n子系统只应依赖于其他模型元素的接口，因此它不直接 依赖于子系统外部的任何特定模型元素 。 n例外情况 n许多子系统共享一组类定义，因此这些子系统将“导入”包含公 共类的包中的内容。这只能用于位于构架低层的包，并且原因只 能是为了确保在子系统之间传递的公共类定义保持一致 创建初始的设计类 n做设计类的设计时，将没有分析类的类型

47、，但是可 以根据将要设计的分析类类型，采用不同的特定策 略来创建初始设计类 n需要多少类 n大量的简单的类意味着每个类： n封装了整个系统逻辑的很小的一部分 n更容易复用 n容易实现 n少量的复杂的类意味着每个类： n封装了整个系统逻辑的很大一部分 n不容易复用 n实现困难 n注意 na class should have a single well focused purpose.a class should do one thing and do it well 边界类的设计策略 nui边界类 n分析时识别出来了高层次的边界类，设计时需要创建更 多的类来支持实际的guii和外部系统交互 n

48、用户接口边界类的设计依赖与用什么ui开发工具，你只 需要设计开发环境不能自己你创建的部分。 n用户界面的原型开发会使设计有一个良好的起点 n系统边界类 n外部系统的接口通常有复杂的行为，所以通常模型化成 子系统 n如果接口不复杂，你可以用一个或多个设计类来表示， 以后对于每个协议、接口或api使用一个单独的设计类 实体类的设计策略 n实体对象经常是被动的和持久化的 n性能要求可能会导致返工 n例如，如果我们有一个包括5个属性的类，一个属性实际上不是持久 化的，只是运行时的记录，另外两个属性不常用，设计时，我们决 定应该能立即查询常用的属性，而对于不常用的属性只有当有人请 求时才去查询。我们不想

49、为用户做一个复杂的设计，因此，从数据 的角度看，我们把fatclass作为两个持久化数据类的代理，它被查询 时它就会从数据库中查询fatclassdatahelper，而只有用户请求时才 从数据库中查询fatclasslazydatahelper 实体类的设计策略确定永久类 n必需在永久媒介上保存状态的类被称为“永久类” n在分析的设计后，已经为永久类标记了“永久性” 的分析机制 n设计之前构架设计师应该已经选择了设计机制和实现机 制 n提醒了数据库设计员要特别注意类的物理存储特征 n告诉负责永久性机制的设计员，类的实例必需是永久性 的 n设计永久类是要应用构架设计师选择的实现机制 控制类的设

50、计策略 n如果控制类只是边界类和实体类的通路，就可以去 掉 n以下的控制类是必要的： n封装了复杂的控制行为 n封装的行为可能会变化 n性能必须分布在多个进程或处理器中 n需要事务管理 定义类的可见性 n“公有”类可由它所在的包之外的类引用 n“私有”类（或类的可见性是“实施”）只 能由同一包内的类引用。 定义操作 n操作来源 n交互图中的message n为与设计类相对应的分析类的每个责任定义一个操作 n研究设计类参与的用例实现，看操作是如何被使用的细化操作、 描述、返回值和参数 n研究use-case特定的需求，确保没有遗漏操作的隐含需求 n其它 n是否存在一种生成类实例的方式 n是否有判

51、断两个类实例是否相等的需求 n是否有创建类实例拷贝的需求 n为了应用机制是否需要新的操作 定义操作 n命名和说明操作 n在命名操作、返回类型和参数及其类型时，应该使用实 现语言的命名约定 n操作名应该简短，并可说明进行操作所得到的结果 n从操作用户用户的角度为操作编写说明 n定义操作可见性 （属性和操作都有） npublic: + nprotected: # nprivate: - nscope（属性和操作都有） ninstance:一个类实例对应一个属性或操作实例 nclassifier：所有的类实例对应一个属性或操作实例 定义方法 n方法说明了操作的实现 n大多数情况下，方法是直接由编程语

52、言实施 的。如果实现操作需要采用特定算法，或需 要操作说明之外的更多信息，则要采用单独 的方法说明 n需要考虑 n特殊的算法 n使用的其他对象和操作 n属性和参数如何被实现和使用 n关系（relations)如何被实现和使用 定义状态 n对于状态相关的设计类，可以画状态图来增 加对类的理解 n状态图中每一状态转移事件都与一个操作关联关 系 n对象的操作根据状态可以具有不同的行为， 所以定义方法的时候应该参照状态图 n在处理一些异常事件时，状态图尤其有用 n状态通常采用属性表示 状态图（statechart diagram)的组成 状态图状态（state） n状态是对象生命中的一个情形，对象的状

53、态决定它能响应的事件 n状态具有以下特征 n初始状态（start state） n状态机或子状态的默认起始位置 n有且只能有一个初始状态 n最终状态（end state） n表示对象生命的结束 n可以有一个以上的最终状态，也可以没有最终状态 n初始状态和终止状态实际上是伪状态 n除了名称外，它们都没有常规状态通常所具有的部分 名称名称状态的名字 活动活动(activity)(activity)在进入或退出状态时，或状态持续过程中所执行的操作。非原 子的，可中断的执行体 内部迁移内部迁移状态不发生变更的情况下对事件的响应 子状态子状态状态的嵌套结构，superstate时包括了嵌套的状态（sub

54、state）的 状态，substate的公共的迁移可以在superstate级表示，对嵌套的 层数没有限制 延迟的事件延迟的事件 未在该状态中处理但被延迟处理（即列队等待由另一个状态中 的对象来处理）的一系列事件。 状态图转移（transition） n转移：当发生指定事件并且满足指定条件时，第一 个状态中的对象将执行某些操作并进入第二个状态 n转移具有以下几项特征 n一个转移可能有多个源状态，一个转移也可能有多 个目标状态 源状态源状态转移前的状态 事件触发器事件触发器(event)使转移满足触发条件的事件 可能包括信号、调用、时间推移或状态变更 警 戒 条 件警 戒 条 件 ( g u a

55、 r d condition) 一种布尔表达式。在接收到事件触发器只有 表达式求值结果为 true才发生转移 动作（动作（action）可执行的、不可分割的计算过程 目标状态目标状态在完成转移后被激活的状态。 状态图历史状态 n当转移进入复合状态时，嵌套状态机的操作将从初 始状态开始重新执行（除非转移直接以子状态为目 标）。历史状态使状态机可以重新进入在它退出复 合状态之前的最后一个活动子状态 状态图实例atm control idle entry/ display welcome ejecting confiscating waiting for password validating pa

56、ssword waiting for choice waiting for password card inserted validating password waiting for choice cancel first invalid password,second third invalid password, stolen or expired card valid password password inputed start up 状态图练习 open assigned unassigned assigned unassigned closed cancelle d full c

57、ommited do/ generate class roster cancelle d full commited do/ generate class roster cancel colseregistration has profesosr assigned close / numstudents = 0 removeprofessor close closeregistration cancle numstudents = 10 addprofessor close numstudent = 3 close numstudents = 3 活动图 n活动图可以表 示系统内的事 件流 n

58、demo：atm 的控制过程 create curriculum select courses to teach create catalog place catalog in bookstore mail catalog to students open registration close registration registratin time period expired 确定属性 n属性来源 n检查方法描述 n检查状态 n类本身需要保存的任何信息 n分析时可以只定义出属性名就可以，设计时，对于每个属性 需要定义： n名字:要同时符合项目和编程语言的命名风格 n类型 n缺省或初始值

59、n可见性 n注意：类是持久化的，但不一定所有的属性都是持久化的 定义依赖关系 nassociations和aggregation是结构的关系 ndependencies是非结构的关系 n分析时，我们假设所有的关系都是结构关系；设计时，我们 必须决定需要哪种通信渠道 n区分是关联还是依赖 n如果你总是需要一个关系，如果一个事物跨一个或多个操作的与另 一个事物由关系，那么这个关系就是association；否则就是暂时的， 就是local,parameter或全局的 n如果许多运行时对象总是共享一个实例，也许这个实例应该作为参 数来传递，如果这个实例自始至终只有一个，那么就可以作为全局 变量 n如

60、果不需要共享一个实例，就作为local变量就可以了 n如果每次需要时都要创建和销毁对象，就可以定义成field，参数或 全局 定义关联关系 n需要 n区分组合（composition） vs. 聚合（aggregation） n区分attribute vs. association n确定navigability nassociation class design nmultiplicity design 区分组合和聚合 n聚合 nshared aggregation：一个part可以属于多个whole nnon-shared aggregation：一个part只能属于一个 whole n是