石振莲 软件学院308 67396121 zshi@bjut.edu.cn 可视化建模与UML 石振莲 软件学院308 67396121 zshi@bjut.edu.cn

Architecture Views 设计视图 实现视图 进程视图 实施视图 Design View Implementation View The 4+1 model is introduced here and because it is important for the students to see how the views fit together up front, in order to set context. Discuss the 4+1 views at a high level. These are covered in detail in RUP. Emphasize that the architectural views are the architecturally-significant subsets of system models. Not all systems require all views (e.g., single processor: drop deployment view; single process: drop process view; small program: drop implementation view, etc.). A project may document all of these views or additional views. The number of views is dependent on the system you’re building. These views and their representation in UML are discussed in the Artifacts module. Note: More information than the views is required to capture the software architecture. This information is captured in the Software Architecture Document (SAD). Design View Analysts/Designers Structure 设计视图 Implementation View Programmers Software management 实现视图 Use-Case View End-user Functionality 用例视图 Many different parties are interested in the architecture (such as the system analyst, the designers, the end users, and so on). To allow these parties or stakeholders to communicate, discuss, and reason about architecture, you need to have an architectural representation they understand. Because different stakeholders have different concerns and because architecture is quite complex, multiple views are required to represent architecture adequately. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective. While many views of architecture can be useful, RUP identifies 4+1 views as a standard set: * The Design view addresses the conceptual structure of the system. It is an abstraction of the design model, identifying major design packages, subsystems, and classes. 包含了类、接口和协作，它们形成了问题及其对问题解决方案的术语词汇。这种视图主要支持系统的功能需求，即系统提供给 用户的服务。静态视图：类图、对象图； * The implementation view describes the organization of static software modules in the development environment, in terms of packaging, layering, and configuration management. 包含了用于装配与发布物理系统的构件和文件。这种视图主要针对系统发布的配置管理，由一些独立的构件和文件组成。 静态视图：构件图 * The deployment view shows how the various executables and other run-time components are mapped onto the underlying platforms or computing nodes. 包含了形成系统硬件拓扑结构的节点。主要描述组成物理系统的部件的分布、交付和安装。 静态图：实施图； 动态图：交互图、状态图、活动图 * The process view addresses the concurrent aspects of the system at run-time: tasks, threads or processes, and their interactions. 包含了形成系统并发与同步机制的线城和进程。主要针对性能、可伸缩性、系统的吞吐量。注重于描述进程和线程的主动 类。 静态图：类图，对象图 动态图：交互图、状态图、活动图。 * The use-case view contains a few key scenarios or use cases that are used to drive and validate the architecture. It is the “heart” of the other views because it specifies WHAT the system should do. 由专门描述可被最终用户、分析人员和测试人员看到的系统行为的用例组成，用例视图实际上没有描述软件系统的组织，而是描述了形成系统体系结构的动力。 静态图：用例图 动态图：交互图、状态图和活动图。 UML中，可以将软件密集型系统的所有抽象组织成一些模型，每个模型代表正在开发的系统的相对独立而又重要的方面。然后用图来可视化这些抽象的有趣集合。 最好用5个互连的视图来描述软件密集型系统的体系结构。每一个视图是在一个特定的方面对系统的组织和结构进行的投影。这五种视图中的每一种视图头可单独使用，使不同的人员能专注于他们最关心的体系结构的问题。这五种视图也可以相互作用。(See Page 22) Process View Performance Scalability Throughput System integrators 进程视图 Deployment View System topology Delivery, installation communication System engineering 实施视图 Logic Model Physic Model

UML——图 Static Diagrams Dynamic Diagrams 结构 行为 Use-Case Diagrams Class The UML emphasizes a graphical language for representing models, but provides little or no guidance on when and how to use these diagrams. This is an area where the RUP helps. It describes the kinds of project artifacts needed, including diagrams, and puts them in the context of an overall project plan. Static Diagrams 结构 Use-Case Diagrams Class Diagrams Sequence Diagrams Object Diagrams In building a visual model of a system, many different diagrams are needed to represent different views of the system. The UML provides a rich notation for visualizing our models. This includes the following key diagrams: Use-Case diagrams to illustrate user interactions with the system Class diagrams to illustrate logical structure Object diagrams to illustrate objects and links Component diagrams to illustrate physical structure of the software Deployment diagrams to show the mapping of software to hardware configurations Activity diagrams to illustrate flows of events Statechart diagrams to illustrate behavior Collaboration diagrams to illustrate behavior Sequence diagrams to illustrate behavior Notice that there is a single model (viewed through multiple diagrams) in which semantic consistency is maintained following the UML specifications. Collaboration Diagrams Component Diagrams Models 行为 Statechart Diagrams Deployment Diagrams Activity Diagrams Dynamic Diagrams

Dynamic Diagram Sequence Diagram Collaboration Diagram StateChart Diagram Activity Diagram

动态图 识别参与对象 在对象间分配责任 对对象间消息的建模 描述消息的处理结果 对类的关系建模

Sequence Diagram 设计视图 Design View Analysts/Designers Structure 在建好系统静态模型的基础上，接下来需要分析和设计系统的动态结构，并且建立相应的动态模型。 动态模型描述了系统随时间变化的行为，这些行为是用从静态试图中抽取的系统瞬间值的变化来描述的。 交互图：协作图+顺序图；用于定义系统如何实现功能；一步一步显示用例的流程；包括：流中需要什么对象，对象相互发送什么消息，什么角色启动流；消息按什么时序发送。描述了一个交互，由一组对象和他们之间的关系组成。包括在对象间传递的信息。 时序图：强调消息时间顺序的交互图，描述类系统中类和类之间的交互，将交互建模成消息交换

两种分析方法

业务建模：第0步，辅助步骤，不是软件开发的步骤。 并不是所有的项目都需要

Use-Case Realization

UML动态模型

现在已有的工件 类图 用例文档 通过画顺序图完成责任分配

交互模式

用例—类—交互

例： Lifeline Class Role Activation Message

对象通过消息交互

创建顺序图步骤 寻找类/对象 寻找角色 将消息加进框图 实体类/对象 边界类/对象 控制类/对象 对事件流启动工作流的外部刺激 一个对象/类请求另一个类/对象完成特定功能

用例的责任分配到这些类上

检索零件 基本路径 1. 检索零件者提交查询条件 2. 系统按查询条件检索零件 3. 系统显示搜索到零件的列表 4. 检索零件者选中某个零件 5. 系统显示该零件的详细信息 扩展 2a. 系统没有检索到所需零件： 2a1. 系统显示“没有找到适合条件的零件” 2a2. 用例结束

检索零件类图

顺序图解说 ：会员

另一种序号表示法

绘制要点

绘制要点

绘制要点

绘制要点

绘制要点

绘制要点

责任分配 V.S 功能分解

？？？

顺序图和类图的映射

顺序图和类图的映射

顺序图和类图的映射

思考：

思考：

思考：

责任分配原则 专家（Expert）原则 老板（Boss）原则 可视（Visibility）原则

责任分配原则

责任分配原则

责任分配原则

练习：

结帐：

责任分配给谁？ 会员？ 账户？

应用：专家+老板 原则

代码：

责任分配给谁？

应用 “专家原则”

责任分配给谁？

应用“专家原则+可视”

应用“专家原则”

增加“计费类”

UML——图 Static Diagrams Dynamic Diagrams 结构 行为 Use-Case Diagrams Class The UML emphasizes a graphical language for representing models, but provides little or no guidance on when and how to use these diagrams. This is an area where the RUP helps. It describes the kinds of project artifacts needed, including diagrams, and puts them in the context of an overall project plan. Static Diagrams 结构 Use-Case Diagrams Class Diagrams Sequence Diagrams Object Diagrams In building a visual model of a system, many different diagrams are needed to represent different views of the system. The UML provides a rich notation for visualizing our models. This includes the following key diagrams: Use-Case diagrams to illustrate user interactions with the system Class diagrams to illustrate logical structure Object diagrams to illustrate objects and links Component diagrams to illustrate physical structure of the software Deployment diagrams to show the mapping of software to hardware configurations Activity diagrams to illustrate flows of events Statechart diagrams to illustrate behavior Collaboration diagrams to illustrate behavior Sequence diagrams to illustrate behavior Notice that there is a single model (viewed through multiple diagrams) in which semantic consistency is maintained following the UML specifications. Collaboration Diagrams Component Diagrams Models 行为 Statechart Diagrams Deployment Diagrams Activity Diagrams Dynamic Diagrams

业务建模：第0步，辅助步骤，不是软件开发的步骤。 并不是所有的项目都需要

Collaboration Diagram 和Sequence框图一样，Collaboration框图也显示用例中特定情形的流程。Sequence框图按时间排序，而Collaboration框图则着重于对象之间的关系。 可以看出，Collaboration框图与Sequence框图中的信息相同，但Collaboration框图显示了不同的流视图，在这个框图中，更容易看出对象之间的关系，但对象顺序信息则不够明显。 为此，可以对一个情景同时创建Sequence框图和Collaboration框图。尽管他们的作用相同，包含相同的信息，但视图有所不同。

另一种序号表示法

Collaboration Vs. Sequence Collaboration Diagram Show relationships in addition to interactions Better for visualizing all of the effects on a given object Sequence Diagrams Show the explicit sequence of messages Better for visualizing overall flow Better for real-time specifications and for complex scenarios

???????.......