Rational_Rose培训.ppt

rational rose & oo建模,臧立威,课程目标,了解可视化建模的相关知识 能够使用rational rose 能够看懂别人用uml表示的设计 具备oo建模的基本技能,课程内容,1. 可视化建模基础 2. oo基础 3. 需求建模 4. 基于团队的建模 5. 分析 6. 设计 7. 正向工程和逆向工程,1. 可视化建模基础,什么是可视化建模,业务流程,计算机系统,可视化建模,可视化建模就是用标准的图形表示法来建模,“建模获取系统的关键部分”,uml,可视化建模的作用（1）,可视化建模获取业务流程 用例（use case）分析是一种从用户的角度获取业务流程的技术 使用相同的语言，不至于产生歧义 用例分析能让分析师在构建系统之前理解要构建什么,可视化建模的作用（2）,可视化建模是一个交流工具,业务领域,计算机领域,业务对象和逻辑,业务对象和逻辑,可视化建模的作用（3）,管理复杂性 把3000多个类放在一张图中不好 可视化建模的“包”（package） 把元素模型化成有意义的组合 为不同的人提供不同级别的抽象 软件构架(architecture),logical view,physical view,user interface,business logic,database,vb java,c+ java,c+&sql,可视化建模的作用（4）,促进复用(reuse) 复用是软件的“圣杯” 不止是复用代码，而是复用建立原始工件时需要的所有分析、设计、实现、测试、文档化 可以有一个类复用、多个类（或一个组件）的复用、应用模式等复用方式 可视化建模让你从复用的角度看，如果想复用工件，什么是可用的,什么是uml,uml(unified modeling language)是可视化、说明、构建和文档化软件系统工件的标准语言 uml可以做下面的建模 数据建模 业务建模 对象建模 组件建模 uml可以用于可视化建模 系统与外界的交互 系统的行为 系统的结构 系统的构架 系统的组件,视图（views）,模型由不同的view和diagram构建而成，描述了不同的视点和系统的构建块 view是一个对特定涉众有意义的模型的视点 view是模型的“碎片” rose中的“4+1view”,logical view,分析师 设计师 structure,process view,系统集成员 performance scalability throughput,implementation view,编程人员 software management,use-case view,最终用户 functionality,deployment view,系统工程 system topology delivery installation communication,图（diagrams）,用例图（use case diagram）：模型化系统与外界的交互 类图（class diagram）：模型化系统的结构 时序图（sequence diagram）：模型化系统的行为 协作图（collaboration diagram）：模型化系统的行为 组件图（component diagram）：模型化组件的组织和依赖 部署图（deployment diagram）：模型化系统的硬件分布 活动图（activity diagram）：模型化系统内的事件流 状态图（statechart diagram）：模型化状态相关的方面,模型结构,rational rose的界面,browser让你可以文本化的查看和导航views和diagrams 不在browser中的元素就不是模型化系统的一部分 diagram window让你可以创建、修改和模型化当前模型的图形化视图 diagram toolbar 包括构建diagram的元素 每个diagram都有自己独特的toolbar 只有显示diagram时才是活动的 documentation window用于创建、查看或修改解释diagram中被选项目的文本 log window报告进度、结果和错误 title组成 rational rose-模型名-xx diagram:diagram所在的package名/diagram名,rational rose,2. oo基础,对象,对象是一个有定义良好的边界和标识，并封装了状态（state）和行为（behavior）的实体。可以是物理的（如一个卡车）、概念的（如一个化学过程）或软件的（如一个链表） 状态 是对象可以处于的状况 对象的状态随时间变化 用属性（attribute）和关系（relation）表示 行为 行为决定对象如何动作和做反应 对象的可见行为用一系列它响应的消息来模型化 用操作（operation）、方法（method）和状态机（state machine）表示 标识（identity） 每个对象有唯一的标识 例如，一个名叫j clark的教授对象的信息如下（她的状态是tenured）： name: j clark employee id：567138(标识) status: tenured discipline: finance,类,类是对一系列具有相同属性、操作、关系和语义的对象的描述 对象是类的实例 类定义了它的所有对象的结构和行为的模板,面向对象的基本规则,抽象（abstraction） 对象区别于其他对象的本质特征 定义与使用者视点相关的边界 不是具体的表现，而是理想化的本质 封装（encapsulation） 对用户隐藏了实现，用户只能通过接口与对象通信 封装通常叫“信息隐藏” 封装使对象的状态不受用户的影响，使用户不受对象实现变化的影响 模块化（modularity） 把复杂的东西分成可管理的小块 帮助人们理解复杂的系统,3. 需求建模,需求流程,用例模型,为什么要创建用例模型 用例模型允许顾客和系统开发者之间用一种用户可以理解的语言交流系统要做什么 你可以认为用例模型是顾客和开发者之间的可视化契约 什么是用例模型 在use-case view中创建 用例模型代表了从最终用户角度看的系统的功能和环境 是顾客和开发者之间的契约 对于分析、设计和测试活动都是至关重要的 包括用例图、用例规约和补充规约，也可以包括活动图,用例图（use case diagram),用例图表示了用例和主角以及用例和用例之间的关系 可视化的表示出了客户希望系统做什么 代表一些大的完整的功能 表示系统完成的有明确结果的对主角有价值的一系列动作 可以模型化 所有的主角和用例（global view） 某个选定主角的所有用例 一个用例以及它所有的关系 一个迭代的所有的用例,用例图的元素,主角 用例 关系,主角（actor）,定义：系统外的与系统进行交互的人或事物 种类 人 外部系统 外部设备或timer 识别actor要依据actor的定义，可以这样查找： 有哪些用户使用系统？ 系统会用到哪些外部的系统或设备？ 有什么外部系统或设备会用到要开发的系统？ 有没有定时触发的行为？,主角（actor）,如何判断一个事物是不是actor 首先它必须与系统有交互，如果与系统没有交互则不是主角 其次它必须是系统外的，如果它是我们将要开发的系统或是系统的一部分则不是主角 其它 用户如果通过标准的输入和输出设备与系统交互则用户是actor 用户如果通过特殊的设备与系统交互，则设备是actor,用例（use case）,定义：是actor与系统的一系列交互 特点： 完成actor的某个目的（不是功能），一般会给actor一个有价值的结果 起始于actor的输入 其中，系统是一个黑盒 用于描述系统行为，但不描述如何实现 识别用例的依据就是用例的定义和特点 识别用例时需要注意 用例的粒度不要太大也不要太小 用例描述的是系统做什么，初始识别用例的时候不要过多考虑系统的实现，即把系统作为黑盒 外部系统或设备的行为不是要开发的系统行为，不要识别出来用例,用例（ use case）,有些用例不代表系统的主要功能，因而通常会被大家忽视，这些用例可能属于以下类型： 系统启动和停止 系统的维护。例如，添加新用户和建立用户简档 维护在系统中存储的数据。例如，所构建的系统和遗留系统平行工作，所以数据需要在两个系统之间达到同步 修改系统行为所需的功能。例如创建新报告的功能，它不仅可以创建硬代码，还可以对系统中存储的数据创建一组特定报告,actor和use case的关系,actor与use case之间的关系是association关系，含义是“触发”，千万不要理解成数据流,rose操作加入模型元素,从browser窗口中加入 选择要加入模型元素所在的package，单击鼠标右键，从弹出菜单中选择new模型元素种类（如class，package，use case diagram等），此时相应的包下面就会加入一个新的元素，你可以为它命名 从diagram的toolbar中直接加入 从toolbar中选择要加入的元素类型，单击diagram窗口的某个位置，新的元素就会显示到diagram窗口中，此时你可以为新元素命名。同时browser中也出现新的元素（新的模型元素会加入到相应的diagram所在的包中）。,rational rose,rose操作更改模型元素,双击browser或diagram中的元素（或者单击鼠标右键，从弹出菜单中选择open specification）就会打开新建元素的specification，在specification对话框中，你可以更改名字以及做其他的设置 注意：diagram没有specification 注意：双击diagram中的package，不会打开它的specification，而是进入package下的某个类图,rational rose,rose操作删除模型元素,delete from model：模型元素从模型中删除（也从它参与的所有图中删除） 从browser中选择要删除模型元素，单击鼠标右键，从弹出菜单中选择delete，或者 从diagram中选择要删除模型元素，从菜单中选择editdelete from model（快捷键ctrl+d） delete from diagram 从diagram中中选择要删除模型元素，从菜单中选择editdelete （快捷键del）,rational rose,实践,demo 识别atm系统的主角和用例，并在rose中画出用例图,详细用例模型,actor之间的关系泛化（generalization） use case之间的关系 泛化（generalization）：不常用 扩展（extend） 包含（include）,用例之间的扩展关系,扩展关系的双方分别叫做基本用例（base use case）和扩展用例（extension use case） 扩展用例用来模型化基本用例中 有条件的部分，只在某些环境下执行 复杂的或可选的路径。 扩展关系用stereotype是“extend” 的association关系来表示,用例之间的扩展关系,扩展用例和基本用例的关系 基本用例自身应是完整的，即基本用例在不必引用任何扩展用例的情况下，应该是可理解且有意义的 基本用例可以不依赖于扩展用例而单独的运行 扩展用例只有在基本用例中的某种条件满足时才能执行，如果没有基本用例，扩展用例不能运行 扩展用例可以扩展多个基本用例 扩展点 定义在基本用例的哪些位置插入扩展用例 包括一个名称和对用例事件流中一个或多个位置的引用 一个扩展点可以引用基本用例内的两个行为步骤之间的单个位置，也可以引用一组不连续的位置,扩展关系的实例,在电话系统中，为用户提供的主要服务通过用例“打电话”来表示。可选服务的示例包括 能让第三方加入通话（召开电话会议） 允许接收方看到呼叫方的身份（显示呼叫方身份） 我们可以将这些可选服务所需的行为表示为基本用例“打电话”的扩展用例，由于“打电话”本身就具有意义，您无需阅读扩展用例的说明就可理解基本用例的主要目的,用例之间的包含关系,包含关系的双方分别叫做基本用例（basic use case）（或具体用例, concrete use case）和包含用例(included use case)（或抽象用例, abstract use case） 包含用例用来模型化基本用例中 多个用例都包含的路径 复杂的路径 包含用例要能生成一个有意义的结果 扩展关系用stereotype是“include” 的association关系来表示,用例之间的包含关系,抽象用例和具体用例 抽象用例不能单独执行，必须与包括（也就是执行）它的具体用例一起执行 抽象用例没有特定的actor，它的actor实际上包括它的具体用例的actor 抽象用例可以被几个其他的用例复用 具体用例的基本流执行时，抽象用例一定执行,扩展关系和包含关系,共同点 扩展用例和包含用例都是基本用例的一部分 基本用例不执行，扩展用例和包含用例都不会执行 扩展用例可以扩展多个基本用例；包含用例可以被多个基本用例包含 区别 扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行 包含关系中基本用例的基本流执行时，包含用例一定会执行,包含关系的实例,在 atm 系统中，用例 withdraw cash、deposit cash和 transfer funds都需要包含系统识别客户的过程。可以将此行为抽取到一个名为 identify customer的新包含用例中 从基本用例的角度来看，识别客户方法是读取银行磁卡还是执行视网膜扫描并不重要。它们仅依赖于 identify customer 的结果，即客户的身份。 从 identify customer 用例的角度来看，基本用例如何使用客户身份或者在执行包含用例之前基本用例中发生了什么并不重要：识别方法都会完全相同,stereotype的作用,扩展模型元素 例如rose中没有extend和include关系，于是用stereotype是“extend”和“include”的association关系来表示 给模型元素分类 例如将来把分析类分成“boundary”、”entity”和“control”三种,rational rose,用例规约（use case specification）,用例名字（name） 简要说明（brief description） 事件流（flows of events） 特殊需求（special requirements） 前置条件（pre-conditions） 开始用例前所必需的系统及其环境的状态 后置条件（post-conditions） 用例结束后系统可能具备的状态 扩展点（extension points）,事件流,事件流用文本形式描述了用户和系统之间如何进行交互 用例的执行有很多种情况，每一种情况就是一个场景 （scenario），用例的事件流应该描述出所有的场景 事件流分成基本流（basic flow）和备选流（alternative flow）两种 基本事件流应包括在执行用例时“通常”会发生的事件，也叫happy flow 备选事件流包括与正常行为相关的可选或异常特征的行为，同时也包括正常行为的各种变形 可以将备选事件流看作是基本事件流的“绕行道”，有些备选事件流将返回到基本事件流，而有些将结束此用例的执行,前置条件和后置条件,前置条件或后置条件所说明的状态应该是用户可以观察到的状态 前置条件是对用例何时开始的约束，它并不是使用例开始的事件 虽然可以在分支流级别定义前置条件和后置条件，但是一个用例的前置条件并不只是一个分支流的前置条件 无论执行了哪些备选流，用例的后置条件都应为“真”；它不能只对主事件流为“真”。如果可能出现故障，则应在后置条件内包括“该动作已经完成，或者，如果可能出现故障，则不执行该动作”，而不只是“该动作已经完成”,实践,demo 描述withdraw用例的用例描述,4. 基于团队的建模,基于团队的建模,受控的演化 rose通过使用uml包和子系统支持基于构架的建模 rose帮助用户在不影响其他人工作的情况下进行详细设计 rose帮助用户避免创建构架单元之间不恰当的联系 把模型划分成在构架上有重大意义的单元 可以分成叫做受控单元的单独的文件 构架上有重大意义的模型元素的复用,rational rose,受控单元,受控单元 是rational rose保存模型全部或一部分的文件 是能进行版本控制的模型元素 定义了单个开发人员可以操作模型的一部分 在团队中共享 让团队可以平行开发 一定是包 下面元素可以作为受控单元 模型文件本身(.mdl) 逻辑视图和用例视图包(.cat) 组件视图包(.sub) 部署视图的图(.prc) 模型属性(.prp),rational rose,受控单元,受控单元可以被loaded或unloaded 可以load模型的一部分，这样就减少了启动延迟、资源消耗和维护对unloaded的单元的索引 可以被write enable或write protect（手动的或自动的） 子受控单元具有独立于父受控单元的写保护 即使有版本控制系统，也可以对受控单元进行写保护控制 reload模型后，写保护失效 手动写保护不影响文件系统的访问权限 model workspace是当前装载的受控单元和打开的diagram的快照 model包括组成完成模型的图、元素和受控单元 model workspace包括某个model在某一点上的打开的图和受控单元的实际状态,rational rose,虚路径,虚路径使模型可以在不同的目录结构中移动，可以从不同的workspace上修改。,rational rose,虚路径使model脱离物理位置,虚路径,物理路径,5. 分析,分析和设计流程,分析和设计,用例实现,用例实现 对用例模型中的每个用例，在设计模型中都有相应的实现 提供从分析和设计到需求的可跟踪性 用例实现结构 用例实现包 是组织用例的类和交互图的方式 每个用例都对应一个用例实现包 可跟踪性图 交互图 时序图（sequence diagrams）（动态） 协作图（collaboration diagrams） （动态） 类图（class diagrams） （静态）,分析类,分析类代表“系统中具备职责和行为的事物”的初期概念模型。这些概念模型最终将演进为设计模型中的类和子系统 分类 边界类（boundary class） 接口与系统外部某些事物的媒介 控制类（control class） 负责协调用例的行为 实体类（entity class） 封装了数据以及数据相关的操作,边界类,边界类帮助系统接口与系统外部进行交互。边界对象将系统与其外部环境的变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响 分类 用户接口类 帮助与用户进行通信的类，通过标准的i/o设备提供人机界面 系统接口类 帮助与其他系统进行通信的类，系统接口对象隐藏如何与外部接口通信的细节 设备接口类或timer 提供对硬件设备的软件接口,控制类,作用 用于对一个或几个用例所特有的控制行为进行建模，控制类封装了用例的特有行为 控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质 控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内发生的变更 控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性 控制类并不能处理用例需要执行的一切事务。相反，它协调其他用来实施此功能的对象的活动。控制类将工作委派给已被指定负责此项功能的对象。控制类通常被看成一个乐队的指挥，它指挥（控制）参与use case的其它对象的行为，通知对象什么时候执行以及执行什么。 有的用例没有控制类，复杂的用例可以有多个控制类 控制对象的生命周期通常和用例实例的生命周期相同,实体类,作用实体类是用于对必须存储的信息和相关行为建模的类。实体对象用于保存和更新一些现象的有关信息，例如事件、人员或者一些现实生活中的对象 实体类的特点 实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要 一个实体对象通常不是某个用例实现所特有的；有时，一个实体对象甚至不专用于系统本身 属性和关系的值通常由主角指定，执行系统内部任务时也可能要使用实体对象 实体对象的行为可以和其他类的对象的行为一样复杂。但是，与其他对象不同的是，这种行为与实体对象所代表的现象具有很强的相关性 实体对象是独立于环境（主角）的 实体对象代表了开发中的系统的核心概念,查找分析类,每个用例主角对都至少有一个边界类 可以首先为每个用例实现确定一个控制类，接着，在确定了更多的用例实现并发现更多的共性后，再对其进行改进 actor的信息可以作为一个实体类 用过滤名词方法寻找实体类 在use case flow of events中画出名词 去掉重复的候选 去掉含糊的候选 去掉actor 去掉实现结构 去掉属性 去掉操作 此时剩下的名词一般就是实体,记录分析类,在“design model”包中加入识别出来的分析类 分析类的类型用类的stereotype表示 如果能说明某个分析类的责任，就给该分析类加上说明,实践,demo 识别课程注册系统中register for course用例的分析类,将行为分配给分析类,用时序图和协作图来描述用例行为 是动态建模的一部分 每个用例的每个事件流（基本流和备选流）建一个或多个时序图和协作图 具有多个复杂时间点或者判定点的分支流通常需要用不同的图来说明，而复杂流因为太长而无法用一个图来把握时也需要用不同的图来说明 一般都是从时序图入手，生成了时序图之后，在 rose的browser中选择时序图，然后按“f5”键，就会生成该时序图对应的协作图,时序图,时序图表示如何一步步的完成系统的一个功能 时序图是用于决定类责任和接口的主要信息来源 时序图描述了对象间的交互模式 通过对象的“生命线”和他们相互发送的消息来显示对象 时序图与协作图在语义上是相同的，只是时序图中的消息是按时间顺序分布的 时序图表示的是一个场景(scenario) 组成 主角(actor) 对象(object) 消息(message)：消息可以有sequence number 生命线(lifeline)：表示对象在特定时间的存在 focus of control：表示对象直接或通过子过程执行动作的一段时间,时序图的元素,协作图,协作图显示对象之间的交互 协作图强调参与交互的对象的组织 适合分析活动，适合表示少数对象的简单交互 协作图很难显示补充的说明性信息，例如时间、判定点或其他非结构化的信息，而在序列图中这些信息可以方便地添加到注释中 组成 主角(actor) 对象(object) links：link是对象通信的途径 消息(message),协作图的元素,实例,demo 课程注册系统中register for course用例的用例分析,类的职责,在开发初期，类的属性和操作不一定被定义，但是我们知道了类的职责 类的责任就是类可以提供的事物的状态或契约 类的责任用/表示,类图,类图 表示一系列类、接口和它们的关系 表示系统的静态视图，在logical view中 用例实现的类图又叫vopc（view of participated classes） vopc类图表示用例实现的参与类以及这些类之间的关系 确保跨越子系统的用例实现的一致性 类图的元素 类 关系,类之间的关系,dependency（依赖） 体现“暂时使用”的含义，或者b的变更会导致a的变更 是一种暂时的关系 可以有以下几种实现方式 对象具有“全局”范围，系统中的任何对象都可以向它发送消息 一个对象可以作为一个参数传递给第二个对象 对象可以在操作内创建和破坏（即“临时”对象） association（关联） 体现“use ”的含义 实现：类a的定义中有类b的指针变量,类之间的关系,aggregation（聚合） 体现“is a part-of”(包含、拥有)的含义 composition（组合） 体现“is a part-of”(包含、拥有)的含义 组合与聚合的区别是组合的整体和部分的object具有相同的生命周期，而聚合则不同 generalization（泛化） 或 inheritance（继承） 体现“is a kind of”的含义 子类不仅继承了超类的attribute和operation，同时还继承了超类的relationship 类之间关系的强弱顺序 依赖 关联 聚合 组合 继承,类之间关系相关的其它概念,role（角色）表示参与关联关系的对象在关联关系中承担的角色 multiplicity（多重性）表示类a的一个object对应类b的几个object，代表的是business rule navigability（导向性 ）表示对象访问的方向,右图中 01表示一个类b的对象可以对应0个或1个类a的对象 0n表示一个类a的对象可以对应类b的0个或多个对象 关系上的箭头就是navigability，表示类a的对象可以访问类b的对象，但是类b的对象不能访问类a的对象，如果关系上没有箭头，表示navigability是双向的,识别分析类之间的关系,识别分析类之间的关联关系有两个来源 协作图：协作图中对象之间有联系，就意味着相应的类之间存在关联关系 领域知识：从中得到实体类之间的聚合关系 注意： 不要添加您认为“或许”存在的关联关系，除非协作图要求添加这些关联关系 在分析时不用识别出类之间的关系是关联还是依赖，是聚合还是组合，因为我们还没有作出明智决策所需要的足够信息，我们将在类设计活动中改进 对于继承关系，在分析时可以识别出来，但是不要求 是关联还是聚合 选择聚合只是为了阐明一种整体/部分的关系 如果拿不准是什么关系，通常关联关系更合适。聚合关系通常是很明显的，聚合的语义应该很容易的从上下文中理解出来 是聚合关系还是关联关系与开发的具体应用有关,记录类之间的关系,用类图来表示类之间的关系 用例实现的类图又叫vopc（view of participated classes）,实践,方法 在用例实现包中建一个类图，取名叫vopc 在类图中表示参与用例的所有类及其关系 demo atm系统的类图,6. 设计,process model,demo 用类图描述课程注册系统的运行时结构,deployment model,deployment model的模型元素 node physical run-time computational resource processor node 运行系统软件 device node support device typically controlled by a processor connection 通信机制 物理媒介 软件协议 demo：课程注册系统,设计元素接口和包,接口 接口是定义行为集（即操作集）的模型元素 该行为集由classifier模型元素（即类、子系统或component）提供 classifier可以实现一个或多个接口；一个接口可由一个或多个classifier实现 实现相同接口的那些classifier在系统中可以互换 每个接口应该是唯一且明确定义的操作集 设计包 一个包中可以包含公有类，也可以包含私有类 公有类可以与任何其他类相关联 私有类只能与其所在包中包含的类相关联 包接口由包的公有类组成，包接口隔离并实施对其他包的依赖关系 包耦合的原则 不应对包进行交叉耦合（即互相依赖），例如两个包不应互相依赖。 较低层中的包不应依赖于较高层中的包，包只应依赖于同一层及下一层中的包 通常，依赖关系不应跳层，除非依赖行为在所有层之间都是共同的,设计元素设计子系统,设计子系统 设计子系统是一种模型元素，它具有包（其中可包含其他模型元素）和类（其具有行为）的语义 子系统的行为由它实现的一个或多个接口来定义 子系统的行为由它所包含的类或其他子系统提供 子系统内部的元素对外不可见 子系统的特点 可以独立预定、配置或交付 可以独立开发（只要接口保持不变） 可以在一组分布式计算节点上独立部署 可以在不破坏系统其他部分的情况下独立地进行更改 可以将系统分为若干单元，以提供对关键资源的有限安全保护 可以在设计中代表现有产品或外部系统,设计元素,子系统和包的区别 子系统比包封装性好 子系统有接口，外部只能通过子系统接口访问子系统内部 包没有接口，外部可以直接访问包中公共的类 子系统具有行为，而包没有 子系统是一种通过一个或多个它所实现的接口来提供行为的包 而包并不提供行为它们只是用来容纳对象的容器 子系统依赖关系 子系统不应暴露自己的任何内容；子系统外部的元素都不应依赖于子系统内部特定元素的存在 子系统只应依赖于其他模型元素的接口，因此它不直接依赖于子系统外部的任何特定模型元素 。 例外情况 许多子系统共享一组类定义，因此这些子系统将“导入”包含公共类的包中的内容。这只能用于位于构架低层的包，并且原因只能是为了确保在子系统之间传递的公共类定义保持一致,创建初始的设计类,做设计类的设计时，将没有分析类的类型，但是可以根据将要设计的分析类类型，采用不同的特定策略来创建初始设计类 需要多少类 大量的简单的类意味着每个类： 封装了整个系统逻辑的很小的一部分 更容易复用 容易实现 少量的复杂的类意味着每个类： 封装了整个系统逻辑的很大一部分 不容易复用 实现困难 注意 a class should have a single well focused purpose.a class should do one thing and do it well,边界类的设计策略,ui边界类 分析时识别出来了高层次的边界类，设计时需要创建更多的类来支持实际的guii和外部系统交互 用户接口边界类的设计依赖与用什么ui开发工具，你只需要设计开发环境不能自己你创建的部分。 用户界面的原型开发会使设计有一个良好的起点 系统边界类 外部系统的接口通常有复杂的行为，所以通常模型化成子系统 如果接口不复杂，你可以用一个或多个设计类来表示，以后对于每个协议、接口或api使用一个单独的设计类,实体类的设计策略,实体对象经常是被动的和持久化的 性能要求可能会导致返工 例如，如果我们有一个包括5个属性的类，一个属性实际上不是持久化的，只是运行时的记录，另外两个属性不常用，设计时，我们决定应该能立即查询常用的属性，而对于不常用的属性只有当有人请求时才去查询。我们不想为用户做一个复杂的设计，因此，从数据的角度看，我们把fatclass作为两个持久化数据类的代理，它被查询时它就会从数据库中查询fatclassdatahelper，而只有用户请求时才从数据库中查询fatclasslazydatahelper,实体类的设计策略确定永久类,必需在永久媒介上保存状态的类被称为“永久类” 在分析的设计后，已经为永久类标记了“永久性”的分析机制 设计之前构架设计师应该已经选择了设计机制和实现机制 提醒了数据库设计员要特别注意类的物理存储特征 告诉负责永久性机制的设计员，类的实例必需是永久性的 设计永久类是要应用构架设计师选择的实现机制,控制类的设计策略,如果控制类只是边界类和实体类的通路，就可以去掉 以下的控制类是必要的： 封装了复杂的控制行为 封装的行为可能会变化 性能必须分布在多个进程或处理器中 需要事务管理,定义类的可见性,“公有”类可由它所在的包之外的类引用 “私有”类（或类的可见性是“实施”）只能由同一包内的类引用。,定义操作,操作来源 交互图中的message 为与设计类相对应的分析类的每个责任定义一个操作 研究设计类参与的用例实现，看操作是如何被使用的细化操作、描述、返回值和参数 研究use-case特定的需求，确保没有遗漏操作的隐含需求 其它 是否存在一种生成类实例的方式 是否有判断两个类实例是否相等的需求 是否有创建类实例拷贝的需求 为了应用机制是否需要新的操作,定义操作,命名和说明操作 在命名操作、返回类型和参数及其类型时，应该使用实现语言的命名约定 操作名应该简短，并可说明进行操作所得到的结果 从操作用户的角度为操作编写说明 定义操作可见性 （属性和操作都有） public: + protected: # private: - scope（属性和操作都有） instance:一个类实例对应一个属性或操作实例 classifier：所有的类实例对应一个属性或操作实例,定义方法,方法说明了操作的实现 大多数情况下，方法是直接由编程语言实施的。如果实现操作需要采用特定算法，或需要操作说明之外的更多信息，则要采用单独的方法说明 需要考虑 特殊的算法 使用的其他对象和操作 属性和参数如何被实现和使用 关系（relations)如何被实现和使用,定义状态,对于状态相关的设计类，可以画状态图来增加对类的理解 状态图中每一状态转移事件都与一个操作关联关系 对象的操作根据状态可以具有不同的行为，所以定义方法的时候应该参照状态图 在处理一些异常事件时，状态图尤其有用 状态通常采用属性表示,状态图（statechart diagram)的组成,状态图状态（state）,状态是对象生命中的一个情形，对象的状态决定它能响应的事件 状态具有以下特征 初始状态（start state） 状态机或子状态的默认起始位置 有且只能有一个初始状态 最终状态（end state） 表示对象生命的结束 可以有一个以上的最终状态，也可以没有最终状态 初始状态和终止状态实际上是伪状态 除了名称外，它们都没有常规状态通常所具有的部分,状态图转移（transition）,转移：当发生指定事件并且满足指定条件时，第一个状态中的对象将执行某些操作并进入第二个状态 转移具有以下几项特征 一个转移可能有多个源状态，一个转移也可能有多个目标状态,状态图历史状态,当转移进入复合状态时，嵌套状态机的操作将从初始状态开始重新执行（除非转移直接以子状态为目标）。历史状态使状态机可以重新进入在它退出复合状态之前的最后一个活动子状态,状态图实例atm control,状态图练习,活动图,活动图可以表示系统内的事件流 demo：atm的控制过程,确定属性,属性来源 检查方法描述 检查状态 类本身需要保存的任何信息 分析时可以只定义出属性名就可以，设计时，对于每个属性需要定义： 名字:要同时符合项目和编程语言的命名风格 类型 缺省或初始值 可见性 注意：类是持久化的，但不一定所有的属性都是持久化的,定义依赖关系,associations和aggregation是结构的关系 dependencies是非结构的关系 分析时，我们假设所有的关系都是结构关系；设计时，我们必须决定需要哪种通信渠道 区分是关联还是依赖 如果你总是需要一个关系，如果一个事物跨一个或多个操作的与另一个事物由关系，那么这个关系就是association；否则就是暂时的，就是local,parameter或全局的 如果许多运行时对象总是共享一个实例，也许这个实例应该作为参数来传递，如果这个实例自始至终只有一个，那么就可以作为全局变量 如果不需要共享一个实例，就作为local变量就可以了 如果每次需要时都要创建和销毁对象，就可以定义成field，参数或全局,定义关联关系,需要 区分组合（composition） vs. 聚合（aggregation） 区分attribute vs. association 确定navigability association class design multiplicity design,区分组合和聚合,聚合 shared aggregation：一个part可以属于多个whole non-shared aggregation：一个part只能属于一个whole 是组合还是聚合？ 组合的whole和part具有相同的生命周期 所以只要看对象如