石振莲 软件学院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

Class Diagram 设计视图 Design View Analysts/Designers Structure A class diagram shows the existence of classes and their relationships in the logical design of a system. A class diagram may represent all or part of the class structure of a system. Class diagrams show the static structure of the model, in particular, the things that exist such as classes, their internal structure, and their relationships to other classes. Class diagrams do not show temporal information. The static view of a system primarily supports the functional requirements of a system. Design View Analysts/Designers Structure 设计视图

开发过程

类图的角色 类图描述系统中类的静态结构，它不仅定义系统中的类，表示类之间的联系（关联、依赖、聚合等），还包括类的内部结构（类的属性和操作）。类图描述的是一种静态关系，在系统的整个生命周期都是有效的。 一个系统通常要创建几个Class框图，有些要显示类及其关系的子集。有些显示类的子集，包括属性和操作，还有些显示类包及包之间的关系。默认情况下，有一个主Class框图，直接放在Logic视图下面，这个Class框图显示模型中的类包。 Class框图是项目小组的良好设计工具，有助于开发人员在编码之前显示和计划系统结构，保证系统一开始就设计合理。

类图解说 类图描述系统中类的静态结构，它不仅定义系统中的类，表示类之间的联系（关联、依赖、聚合等），还包括类的内部结构（类的属性和操作）。类图描述的是一种静态关系，在系统的整个生命周期都是有效的。 一个系统通常要创建几个Class框图，有些要显示类及其关系的子集。有些显示类的子集，包括属性和操作，还有些显示类包及包之间的关系。默认情况下，有一个主Class框图，直接放在Logic视图下面，这个Class框图显示模型中的类包。 Class框图是项目小组的良好设计工具，有助于开发人员在编码之前显示和计划系统结构，保证系统一开始就设计合理。

Objective Comprehend Class conception and description Identify Class and Attributes Identify the relationship of classes

Where are we？ Class conception and description Identify Class Relationship conception and classification Identify the relationship

Class (类) What is a class? A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. An object is an instance of a class. A class is an abstraction in that it Emphasizes relevant characteristics Suppresses other characteristics

Class (类)

Class (类) Class Compartments The class name The structure (attributes) The behavior (operations)

Class (类) Name 名称 Attribute 属性 Operation 操作 类是对一组具有相同属性、操作、关系和语义的对象的描述。是面向对象系统中最重要的构造块。在图形上，把一个类画成矩形。 Operation 操作

Class—Name 类的名称应该： 清楚、简单，使用问题域的词汇 类的名称是每个类所必有的构成，用于和其他类相区分。是一个文本串，可分为简单名称和路径名称。 类的名称应该： 清楚、简单，使用问题域的词汇

Class—Attributes 属性是已被命名的类的特性，它描述了该特性的实例的可以取值范围。可以有任意数目的属性，也可以没有属性。描述正被建模的事物的一些特性，这些特性为类的所有对象所共有。

Class—Attributes UML中类属性的语法为： [可见性] 属性名[：类型][=初值] + public - private # protected

Class— Derived Attribute An Attribute whose value may be calculated based on the other attribute(s) 派生属性是从一个或几个属性创建的属性。

Class— Derived Attribute When do you use it? When there is not enough time to re-calculate the value every time it is needed When you must trade-off runtime performance versus memory required

Class—Operation UML中类操作的语法为： [可见性]操作名[（参数列表）] [：返回类型] 举例： + display() : Area # create() - getLocation (Point : currentPoint) + public - private # protected 类的操作是对类的对象所能做的事物的抽象。它相当于对一个服务的实现，该服务可以由类的任何对象请求以影响其行为。一个类可以有任何数量的操作或者根本没有操作。类的操作必须有一个名字，可以有参数表，可以有返回值。 根据定义，类的操作所提供的服务可以可以分为两类： 一类是操作的结果引起对象状态的变化，状态的改变也包括相应动态行为的发生； 另一类是为服务的请求者提供返回值；

Class

类的版型 boundary control entity Interface

类的版型—边界类 位于系统与外界的交界处 User interface boundary class 窗体（form）、对话框（dialog box）、报表（report） External system boundary class 表示通讯协议（如TCP/IP）的类 直接与外部设备交互的类 直接与外部系统交互的类

The Role of a Boundary Class Concentrate on the responsibilities, not the details!

Finding Boundary Classes One boundary class per actor/use case pair One recommendation for the initial identification of boundary classes is one boundary class per actor/use-case pair. This class can be viewed as having responsibility for coordination the interaction with the actor. This may be refined as a more detailed analysis is performed. This is particularly true for window-based GUI applications where there is typically one boundary class for each window, or one for each dialogbox. In the above example: The RegisterForCoursesForm contains a Student’s”schedule-in-progress.” It displays a list of Course Offerings for the current semester from which the Student may select courses to be added to his or her Schedule. TheCourseCatalogSy interfaces with the legacy system that provide the unabridged catalog of all courses offered by the university. This class replaces the CourseCatalog abstraction originally identified in Architectural Analysis.

Boundary Class

类的版型—控制类 负责其它类工作 每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。 向其他的类发消息

Control Class

The Role of a Control Class

Finding Control Classes

类的版型—实体类 要放入持久存储体的信息 实体类用领域术语命名 每个实体类在数据库中有相应的表

What is an Entity Class? Key abstractions of the system

The Role of Entity Class

Finding Entity Classes

Summary

Where are we？ Class conception and description Identify Class Relationship conception and classification Identify the relationship

识别类（方法之一） From Use-Case Behavior Analysis classes represent an early conceptual model for “things in the system that have responsibilities and behavior.” Analysis class are used to capture a “first-draft” rough-cut of the Object Model of the system.

识别类（方法之二） 回顾需求文档，抽取对应于业务实体或事件的名词 出现遗漏时，返回需求文档进行修改 将名词进行分类、抽取出合适的类

识别类 — 从需求文档抽取名词

识别类 — 分析结果

类图初步

审查类及属性 是否在系统责任之内 是否描述类对象的特征 是否存在冗余 是否有复杂结构的属性 根据对需求的理解进行细化

审查类及属性 是否在系统责任之内

审查类及属性 属性是否描述类对象的特征

审查类及属性 属性是否存在冗余

审查类及属性 是否有复杂结构的属性

审查类及属性 是否有复杂结构的属性 1:1 可以在源类内展开 1:N 独立出去形成关联

审查类及属性 是否有复杂结构的属性

审查类及属性 是否有复杂结构的属性

根据需求对类图细化

Where are we？ Class conception and description Identify Class Relationship conception and classification Identify the relationship

关系 relationship Relationship is a semantic connection among elements 事务之间的联系 当对软件密集型系统建模时，依赖、泛化、何关联时遇到的最常用的关系。然而，为了避免随后设计中的实际缺陷，需要捕获系统中的一些细节，就需要这些关系的一些高级特征。

关系 Relationship 关联 Association 依赖 Dependency 泛化 Generalization 连接 Link 聚合 Aggregation 组合 Composition 依赖 Dependency 泛化 Generalization

关系—关联 关联是一种结构关系，它详述了一个事物的对象与另一个事物的对象相联系。 修饰：关联名、关联每一端的角色、 关联每一端的多重性、聚合

关系—关联 类之间关联的几种形式

关系—关联 连接/链 最弱的关联，只表示两个类对象之间有导航关系 导航性：就是说给定源类的一个对象，可以达到目标类的所有对象。

关系—关联 聚合 指明一个聚集（整体）和组成部分之间的 整体与部分的关系 具有“has a”语义

关系—关联 聚合 整体 部分 聚合

关系—关联 组合 带有很强的所有关系的聚合 整体消失，则部分消失

关系—关联 聚合 Vs. 组合

关系—关联 连接 Vs. 聚合 聚合是连接的精化，两端角色被默认为“拥有者”和“被拥有者” 连接与聚合的区别只在于个人喜好，而不是语义上的区别

关系—关联 比较关联的几种形式

关系—关联 聚合—代码

关系—关联 组合—代码

关系—关联 双向连接—代码

关系—关联 单向连接—代码

关系—依赖 表示类之间的使用关系 当客户类的操作需要提供者类的参数 客户类的操作返回提供者类的值 客户类的操作在实现中使用提供者类的对象

关系—泛化 是一般和特殊的关系 Is a kind of 子类继承父类属性和操作 子类可以应用在父类对象可能出现的地方

关系—泛化

Where are we？ Class conception and description Identify Class Relationship conception and classification Identify the relationship

关系识别—泛化 是否在系统责任范围之内 是否同处一个领域 是否符合常识 是否在结构上真正构成泛化关系 子类之间的差别能否由父类的属性值改变来实现 是否一父一子

关系识别—泛化 是否在系统责任范围之内

关系识别—泛化 是否同处一个领域

关系识别—泛化 是否符合常识

关系识别—泛化 是否在结构上真正构成泛化关系

关系识别—泛化 子类之间的差别能否由父类的属性值改变来实现

关系识别—泛化 一父一子

关系识别—聚合(组合) 物理上的整体事物和它的组成部分 组织机构和它的下级组织 团队（组织）和成员 空间上的包容 抽象事物的整体和部分

关系识别—聚合(组合) 物理上的整体事物和它的组成部分

关系识别—聚合(组合) 组织机构和它的下级组织

关系识别—聚合(组合) 团队（组织）和成员

关系识别—聚合(组合) 空间上的包容

关系识别—聚合(组合) 抽象事物的整体和部分

类图修订

类图修订

类图修订

类图位置（Rose）

一个系统通常要创建几个Class框图，有些要显示类及其关系的子集。有些显示类的子集，包括属性和操作，还有些显示类包及包之间的关系。默认情况下，有一个主Class框图，直接放在Logic视图下面，这个Class框图显示模型中的类包。 Class框图是项目小组的良好设计工具，有助于开发人员在编码之前显示和计划系统结构，保证系统一开始就设计合理。

Student：A person enrolled in classes at the university. Schedule：The courses a student has selected for a semester. Classification: Specifies what type of student the student is Course Offering：A specific offering for a course, including days of the week and times. CourseOfferings are part of the semantics of what defines a Schedule (a Schedule is the courses a that a Student has selected for a semester). Thus, Field visibility is chosen from Schedule to CourseOffering and the relationships remain associations. In this design, we will only Implement the Schedule-to-CourseOffering direction. If navigation is required in the other direction (e.g., if a list of Schedules on which the CourseOffering appears is needed), it is implemented by searching all of the Schedule instances and checking the CourseOfferings that appear on them.