UML的核心视图解读.pptVIP

基本元素 ——\为异步消息 源消息对象发出消息后不等待响应，而继续执行其他操作，异步消息异步需要消息中间件支持，如JMS、MS等 Rose中还定义了一些其他消息，上面介绍的已经够用了，太多反而使图太复杂 会话 会话表示一次交互，在会话过程所有对象共享一个上下文环境，例如事务上下文，安全上下文 销毁 绘制在生命线上，表示对象生命周期的终止，一般不需要强调 注意 时序图以达成业务目标为准则 这个阶段处于业务阶段，适用的描述语言应当采用业务术语 时序图表达的内容对将来的分析设计带来帮助 不能作为编码实现依据 概念阶段的时序图采用分析类来绘制，目标同样是实现业务用例，此时的时序图带有计算机理解 概念用例时序图通常是依据业务模型场景图绘制，将业务模型场景用分析类重新绘制一遍，这样，既保留了实际业务需求，又得到计算机实现的基本理念 设计模型时序图使用设计类作为对象绘制，目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别 实际工作中我们很难为所有的交互都绘制时序图，统一方法讲究架构驱动，且近年来不使用现成软件结构的软件项目已经很少，因此在设计模型阶段，用框架中的关键类描述典型的交互场景，不需要为每一个交互绘制时序图 例子 展示在J2EE架构下实现查询商品过程的片段，可看作伪代码 描述了对象间交互的一种模式，通过对象间的连接和他们相互发送的消息来显示参与交互的对象 协作图中可以有对象和主角实例，以及描述它们之间关系和交互的连接和消息 消息对象间如何通过互相发送消息来实现通信，协作图描述了参与对象中发生的情况 协作图用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为，结果用于获取对象的责职和接口 与时序图不同，协作图展示了对象间的关系，使得它更适用于获得对象结构的理解，而时序图更适用于获得对象动用过程的理解 但在本质上，它们可以互换 使用协作图来描述用例实现，通过贡献于该用例实现的对象之间的交互来说明用例是如何被对象实现的 同样针对概念层、说明层和实现层分别对业务实体对象、分析类对象和设计类对象绘制协作图 如果更在意对象间的结构关系，请选择使用协作图；如果更在意对象交互的执行顺序，请选择时序图 业务模型协作图 采用业务实体绘制，目标是实现用例场景，不过有时候协作图不要求实现完整的场景，只需要将影响对象的关键消息绘制出来即可，因为协作图在意的是对象的结构及其相互的影响 协作图与时序图相比，对象间的结构一目了然，很容易知道哪些消息影响了对象 或者说对象需要提供哪些接口 协作图很难表示执行顺序 关键元素 对象 表示参与写作的对象，对象可以指定它的类，也可以直接用空对象表示 对象关联 连接两个对象，表示两者的关联，与对象关系不同，这种是临时关联，即只在本次交互中存在；类关系是永久关联 消息 与时序图中消息的定义完全一样 消息序号 消息的一部分，表明消息传递的先后顺序，在Rose中这个序号Rose自动维护，不能手工调整 概念模型协作图 与时序图相同，概念阶段的协作图采用分析类绘制，目标是实现业务用例 设计模型协作图 与时序图相同，设计模型协作图使用设计类未对象来绘制，目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别 静态视图表达事物的结构性观点 动态视图表达事物的行为性观点 一个好的建模，结构性和行为性缺一不可，而且要相得益彰，既要说明该事物长得什么样子，还要说明事物应该怎么用 包图一般用来展示高层次的观点 建模过程中获得的元素非常多，如果将这些元素的关系都绘制出来将如同蜘蛛网一样难以辨别 通过包这个容器来从大到小、从粗到细建立关系是一种很好的办法 例子 展示了网上购物的领域包图 表达了关键业务领域及其依赖关系 例子 展示了查询商品功能的类层次 表达了实现类位于哪个层次的软件架构的观点 动态视图描述事物动态行为 动态视图不能独立存在 必须特指一个静态视图或UML元素，说明在静态视图规定的事物结构下它们的动态行为 描述为了完成某一个目标需要做的活动以及这些活动的执行顺序 UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互 争议 活动图被引入UML是由争议的，因为活动图实际上描述的是业务流程，是一种过程化的分析方法，很多人担心面向过程的活动图引入会导致OO的类职责的混乱，这种担心是有道理的 在OO的眼中，是没有业务流程这种东西的，所谓流程，只不过是在外力推动下对象之间相互交流的一个过程，只是瞬间的 如果从活动图的观点来描述业务，实际上是不能直接看到对象是如何发挥作用的 这样在观念上很容易导致对象独立性被破坏，例如有的设计者可能会试图得到一个从头到尾参与整个业务流程的“对象” 在OO设计中，我们面临着这样一个矛盾，既要保持OO中对象的独立性，又要保持显示世界