CHAPTER 2 ELEMENTS OF UML

Presentation on theme: "CHAPTER 2 ELEMENTS OF UML"— Presentation transcript:

1 CHAPTER 2 ELEMENTS OF UML

2 Roadmap

3 Agenda Elements of UML Things Relationships Rules Common mechanisms Extension Architecture and diagrams Summary

4 Elements of UML UML building blocks Rules to connect the building blocks Common mechanisms of UML

5 Agenda Elements of UML Things Relationships Rules Common mechanisms Extension Architecture and diagrams Summary

6 Things Things are the most important building blocks of UML. Things can be Structural things: define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things. Behavioral things: consist of the dynamic parts of UML models Grouping: can be defined as a mechanism to group elements of a UML model together Annotational things: can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements

7 Object-oriented world
First, construct the building blocks that reflect the things of the real-world. Then, determine the relationships between the building blocks. After that, decide the attributes and the operations of each building block. Finally, simulate the real-world via interactions and collaborations between the building blocks.

8 Structural Things Class and object Interface Active class Use case Collaboration Component Node

9 Class and objects Class represents set of objects having similar responsibilities. Represented as rectangles, including class name, attributes, and operations Object diagrams represent an instance of a class diagram

10 Interface Interface defines a set of operations which specify the responsibility of a class.

11 Active class An Active Class indicates that, when instantiated, the Class controls its own execution. Rather than being invoked or activated by other objects, it can operate standalone and define its own thread of behavior.

12 Use case Proposed by Ivar Jacobson. Use case represents a set of actions performed by a system for a specific goal. The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition is too generic to describe the purpose.

13 Component Entities larger than class, such as COM components, DLL files, JavaBeans, executables, etc. The usage of component diagrams can be described as: Model the components of a system. Model database schema. Model executables of an application. Model system's source code.

14 Node A node can be defined as a physical element that exists at run time. Nodes are used to model the physical structure of the software system, such as workstation, printer, server, etc.

15 Behavioral things A behavioral thing consists of the dynamic parts of UML models. Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task State machine: State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.

16 Grouping things Grouping things can be defined as a mechanism to group elements of a UML model together.

17 Annotational things Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note is the only one Annotational thing available.

18 Agenda Elements of UML Things Relationships Rules Common mechanisms Extension Architecture and diagrams Summary

19 UML模型关系的种类 种类 变种 表示法 关键字或符号 抽象 派生 依赖关系 《derive》 导入 私有 《access》 显现
《manifest》 公有 《import》 实现 实现关系 虚线加空心三角 信息流 《flow》 精化 《refine》 包含并 《merge》 跟踪 《trace》 许可 《permit》 关联 关联关系 实线 协议符合 未指定 绑定 《bind》(参数表) 替换 《substitute》 部署 《deploy》 使用 调用 《call》 扩展 Extend 《extend》(扩展点) 创建 《create》 extension 扩展关系 实线加实心三角 实例化 《instantiate》 泛化 泛化关系 实线加空间三角 职责 《responsibility》 包含 《include》 发送 《send》

20 Association Association is basically a set of links that connects elements of an UML model. It also describes how many objects are taking part in that relationship In UML, use solid line to represent associations Two special cases: Aggregation Composition

21 Generalization, realization, and dependency
Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the world of objects.

22 Generalization, realization, and dependency
Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility which is not implemented and the other one implements them. This relationship exists in case of interfaces.

23 Generalization, realization, and dependency
Dependency is a relationship between two things in which change in one element also affects the other one.

24 Agenda Elements of UML Things Relationships Rules Common mechanisms Extension Architecture and diagrams Summary

25 Rules UML has a number of rules so that the models are semantically self-consistent and related to other models in the system harmoniously. UML has semantic rules for the following Names Scope Visibility Integrity Execution

26 Agenda Elements of UML Things Relationships Rules Common mechanisms Extension Architecture and diagrams Summary

27 Specifications In UML, behind each graphical notation, there is a textual statement denoting the syntax and semantics. These are the specifications. The specifications provide a semantic backplane that contains all the parts of a system and the relationship among the different paths

28 Adornments and Common Divisions
Each element in UML has a unique graphical notation. Besides, there are notations to represent the important aspects of an element like name, scope, visibility, etc. Common Divisions: Object-oriented systems can be divided in many ways. Division of classes and objects : A class is an abstraction of a group of similar objects. An object is the concrete instance that has actual existence in the system. Division of Interface and Implementation : An interface defines the rules for interaction. Implementation is the concrete realization of the rules defined in the interface.

29 Agenda Elements of UML Things Relationships Rules Common mechanisms Extension Architecture and diagrams Summary

30 Extensibility Mechanisms
Stereotypes : It extends the vocabulary of the UML, through which new building blocks can be created out of existing ones. Tagged Values : It extends the properties of UML building blocks. Constraints : It extends the semantics of UML building blocks.

31 Agenda UML的组成 事物构造块 关系构造块 UML规则 UML公共机制 UML扩展机制 UML体系结构与图 本章小结

32 Agenda Elements of UML Things Relationships Rules Common mechanisms Extension Architecture and diagrams Summary

33 Composite Structure复合结构图
Diagrams in UML 图名 功能 备注 Class 类图 描述类、类的特性以及类之间的关系 UML 1原有 Object 对象图 描述一个时间点上系统中各个对象的一个快照 UML 1非正式图 Composite Structure复合结构图 描述类的运行时刻的分解 UML 2.0新增 Component 构件图 描述构件的结构与连接 Deployment 部署图 描述在各个节点上的部署 Package 包图 描述编译时的层次结构 UML中非正式图 Use Case 用例图 描述用户与系统如何交互 Activity 活动图 描述过程行为与并行行为 State machine 状态机图 描述事件如何改变对象生命周期 Sequence 顺序图 描述对象之间的交互，重点在强调顺序 Communication 通信图 描述对象之间的交互，重点在于连接 UML 1中的协作图 Timing 定时图 描述对象之间的交互，重点在于定时 UML 2.0 新增 Interaction Overview 交互概观图 是一种顺序图与活动图的混合

34 UML视图和图 Domain View Diagram 结构 静态视图 类图 设计视图 复合结构图、协作图、构件图 用例视图 用例图 动态 状态视图 状态机图 活动视图 活动图 交互视图 顺序图、通信图 物理 部署视图 部署图 模型管理 模型管理视图 包图 特性描述

35 UML图形分类

36 4+1视图

37 开发过程

38 Agenda Elements of UML Things Relationships Rules Common mechanisms Extension Architecture and diagrams Summary

39 本章小结 首先阐述了事物构造块、关系构造块，它们是UML建模元素的主体。事务构造块包括结构、行为、分组和注释四种类型；关系构造块主要包括关联、泛化、依赖、实现 接着简要阐述了UML中公共的规则 然后，系统地介绍了规格说明、修饰和通用划分三种公共机制；并对扩展机制进行了更深入的讲解 在本章的最后又将读者的目光转回到“图”这个最重要的构造块中，简要地阐述了UML 2.0中定义的13种图，以及不同图的划分和类别

40 CHAPTER 3 CLASS DIAGRAMS: THE ESSENTIALS

41 Roadmap

42 Terms and Concepts A class is ...
The most important building block of any object-oriented system. A description of a set of objects that share the same attributes and behaviors. A blueprint for creating an object. An abstraction (simplification) of reality. A representation of a software thing, a hardware thing, or even a conceptual thing. Graphically represented as a rectangle.

43 Terms and Concepts All classes have … Class names are …
Names - Used to distinguish one class from another. A class must have a name. Attributes - Member data Operations (behaviors) - Member functions (C++) or methods (Java) Responsibilities Class names are … extracted from the problem domain (statement) nouns or noun phrases concise and descriptive

44 Terms and Concepts Class attributes are …
usually nouns or noun phrases. extracted or inferred from the problem statement. used to represent properties of the enclosing class. determine the state of an object usually notated using the format visibility name: type multiplicity = default {property string} example: - firstName: String = ‘Bob’ {read only} optionally notated as associations

45 Terms and Concepts Class operations (behaviors) are …
named using a verb or verb phrases. inferred from the problem statement. Provide a requested service. usually notated using the format visibility name (parameter-list) : return-type {property-string} example: +printFirstName( ) : void Class responsibility… Is a contract or obligation of a class to the users of the class. Maps directly to the Responsibility field of a CRC card. CRC - Class Responsibility Collaboration

46 Class Artifact

47 Simple Class Diagram

48 Common Modeling Techniques
Identify the classes that are to be included in the design. Formulate a problem statement. The problem statement may be scenarios associated with use cases. Identify the nouns in the problem statement. Use CRC (Class, Responsibility, Collaboration) cards or use-cases to isolate each class. Determine the responsibilities of each class. Even out the work load between classes. A class with too much responsibility should be broken up into multiple classes. A class with too little responsibility should be absorbed into another class.

49 Common Modeling Techniques
Classes should exhibit high cohesion and low coupling. A class should have a single well-defined purpose. This promotes software reusability A class should interact with a limited number of other classes. This simplifies modifications to the program. Feel free to model abstract (non-software) things (such as people) that are outside of the system boundaries.

50 Associations An association is …
a type of relationship that can exist between one or more classes. used to show a ‘knows-a’ relationship. either unidirectional or bidirectional. graphically represented by a solid line which may optionally be labeled and have a name direction indicator or navigability arrows. an alternative notation for a class attribute Association names are verbs or verb phrases. The same class can be on both ends of an association.

51 Associations Associations may optionally have role names and multiplicity symbols on either end of the association line (next to the class icon). Role The face that a class on one end of an association presents to the class on the other end of the association. A class can participate in many associations and thus have multiple (different) roles. Role names are nouns. Role names are usually used in place of association names.

52 Attributes Modeled as Associations

53 Multiplicity Multiplicity
Indicates how many object may be connected across an instance of an association. Commonly used multiplicities 1 0..1 * The default multiplicity of an attribute is ‘1’

54 Terms and Concepts

55 Generalization Generalization is …
a type of relationship that can exist between two classes. One of the classes is the base (or parent) class; the other class is the derived (or child) class. used to show a ‘kind-of’ relationship. another name for inheritance. graphically represented by a solid line with an open triangular arrowhead on the base class end. The parent class has no knowledge of the child class. All OO programming languages support single inheritance; some (C++) also support multiple inheritance.

56 Common Modeling Techniques
Modeling inheritance (generalization) Make it a priority to look for possible inheritance relationships. This will reduce code redundancy. Use the “ClassA ‘is-a-kind-of’ ClassB” test. Do not model relationships using multiple inheritance unless the implementation language supports multiple inheritance. This will save programmers having to develop messy work-arounds. Look for classes that have similar attributes and behaviors and then factor those attributes and behaviors into a common base class.

57 Notes and Comments Use notes to embed comments into UML diagrams.
The comment may contain links to other documents. A note may stand alone or be attached to a graphical element. A dashed line is customarily used as the connector Use notes when a picture is not enough.

58 Dependency A dependency is ...
A type of relationship that can exist between two classes. An indication that one class ‘uses’ another class. If the ‘used’ class changes it can have an impact on the ‘using’ class. Graphically represented as a dashed line with an open arrowhead on one end. Rarely labeled. The ‘used’ class is frequently an argument to one of the member functions of the ‘using’ class. The “used” class has no knowledge of the “using” class.

59 Dependency Relationships

60 Common Class Relationships

61 Terms and Concepts

62 Agenda What is a class How to read class diagrams Advanced topics How to draw class diagrams Class diagram specification Composite structure Summary

63 Demonstration How many classes? How many associations? What about multiplicities?

64 How to read class diagrams
Find out classes: 7 classes, Order, OrderItem, Customer, Consignee、DeliverOrder、Peddlery、Prodcut Find out associations: From the most dense part: Order 1）Composition between OrderItem and Order. The direction of the arrow matters 2）Associations between Order and Customer, Consignee, and DeliverOrder. 一个订单和客户、收货人、送货单是相关的。

65 How to read class diagrams
Multiplicity：用来说明关联的两个类之间的数量关系 源类及多重性 目标类及多重性 分析 Customer(1) Order(0…n) 订单是属于某个客户的，网站的客户可以有0个或多个订单 Order(1) Consignee(1) 每个订单只能够有一个收货人 OrderItem(1…n) 订单是由订单项组成的，至少要有一个订单项，最多可以有n个 DeliverOrder(1…n) 一个订单有一个或多个送货单 说明：系统根据订单项的产品所属的商户，将其分发给商户，拆成了多个送货单！ DeliverOrder(1) 一张送货单对应订单中的一到多个订单项 每张送货单都对应着一个收货人 Peddlery(1) DeliverOrder(0…n) 每个商户可以有相关的0个或多个送货单 OrderItem(1) Product(1) 每个订单项中都包含着唯一的一个产品 Prodcut(0…n) 产品是属于某个商户的，可以注册0到多个产品

66 Understand operations
Order类，有两个方法：dispatch()和close()，从名字中可以猜出它们分别实现“分拆订单生成送货单”和“完成订单”。而在DeliveOrder()类中则有一个Close()方法，同理它应该表示“完成送货”。而在OrderItem中有一个stateChange()方法和deliverState，不难猜出它就是用来改变其“是否交给收货人”标志位的 先调用Order的dispatch()方法，它将根据其包含的OrderItem中产品信息，来按供应商户分拆成若干个DeliverOrder。商户登录系统后就可以获取其DeliverOrder，并在执行完后调用close()方法。这时，就将调用OrderItem的stateChange()方法来改为其状态。同时再调用Order的close()方法，判断该Order的所有的OrderItem是否都已经送到了，如果是就将其真正close()掉

67 Auxiliaries

68 Auxiliaries Navigation arrow (导航箭号)：类的实例之间只能沿着导航箭头的方向传递 ，在Order中可以获取其相应的Consignee，而从Consignee中是无法了解与其相关的Order的 Role name (角色名称)：Customer端有一个“+Owner”字符串 ，这表示Customer扮演的角色是Owner，也能对关联进行命名

69 Auxiliaries Export attribute (导出属性)：是指可以根据其他值计算出来的特性，这种属性应在其名称前加上一个“/”符号。 Qualifier (限定符)：在Order和OrderItem之间的组合关系中，OrderItem这端多了一个方框，里面写着“ProductId”。它在UML中称为限定符，存在限定符的关联称为受限关联。它用来表示某种限定关系。在本例中，它的用途是说明：对于一张订单，每一种产品只能用一个订单项 Constraint (约束)：用来说明规则，{xor}… Responsibility (职责)：在类的属性栏中添加注释行表示，或增加了一个新的分栏

70 Agenda What is a class How to read class diagrams Advanced topics How to draw class diagrams Class diagram specification Composite structure Summary

71 Interface and abstract class
Abstract class cannot be instantiated Interface: classes with no concrete realization

72 Association class Association classes allow you to add attributes, operations, and other features to associations

73 Template class This concept is most obviously useful for working with collections in a strongly typed language. This way, you can define behavior for sets in general by defining a template class Set

74 Active class and nested class
Classes have members, and it is entirely possible for the member of a class to be another user-defined type. 在诸如Java的语言中，允许你将一个类的定义放在另一个类定义的内部，这就是嵌套类，在Java中也称为inner class内层类。嵌套类是声明在它的外层类中的，因此只能够通过外层类或外层类的对象对它进行访问

75 Dependencies in Java 依赖构造型 含义 例子程序 《create》
表明目标对象是由源对象创建的，目标对象创建后将传递给系统其他部分。 public class ClassA{ public ClassB createB() { return new ClassB(); } 《local》或 《call》 源类对象创建目标类对象实例，并将该实例包含在一个局部变量中。例如右边的例子中，将赋给一个名为test的变量 public void testMethod() { ClassB test=new ClassB(); 《parameter》 源类对象通过它的某个成员函数的参数得以访问目标类对象实例。它的意思是指：类ClassA的操作需要类ClassB的实例作为参数，或返回类ClassB的实例。 public void testMethod(ClassB test) { // use b; 《delegate》 源类对象把一个对于成员函数的调用传递给目标类对象。这是现代编程语言和设计模式中很常用的一种机制，但这不属于UML的标准关系。 private ClassB objectB; objectB.testMethod();

76 Reference and value Reference object (引用对象)，例如客户、产品、订单等对象都是典型的引用对象，对于这些对象而言，标识（identity）是很重要的，因为对于现实世界中的一个实体只需要一个软件对象来表示 Value object (值对象)：例如日期、重量、高度等对象都是典型的值对象，表示现实世界中的同一个对象往往有多个值对象

77 Object Constraint Language
Environment and constraints (环境与约束)：每个OCL表达式都必须是针对某个元素的，因此在OCL表达式前必须说明它针对元素（这就称为环境） 1）“context Object inv：”，其中Object是OCL表达式针对的建模元素名称； 2）“ Object ”，其中Object是OCL表达式针对的建模元素名称。 当声明了环境之后，就可以用self来引用它的变量

78 OCL 子集约束： Consistency (一致性)：一个客户拥有零个或多个合同，发票是基于某个合同的，而一个客户将收到零张或多张发票 Invoice：self.contract.customer=self.customer

79 OCL XOR (异或关系)： Range (规定的取值范围)：Rectangle：length>0 and width>0

80 Agenda What is a class How to read class diagrams Advanced topics How to draw class diagrams Class diagram specification Composite structure Summary

81 Requirements specification
小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计

82 Find out classes 小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计

83 筛选备选类 “小王”、“人”、“家里”很明显是系统外的概念，无须对其建模；
而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模； 很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。 “基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模； “功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；

84 Find out candidates “计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义； “外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”； “购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体。

85 书籍 计算机类书籍 非计算机类书籍 借阅记录 借阅记录列表 书籍列表 Find out candidates
在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字 书籍 计算机类书籍 非计算机类书籍 借阅记录 借阅记录列表 书籍列表

86 Association analysis

87 Responsibility analysis
书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。 书籍列表类：书籍列表就是全部 的藏书列表，其主要的成员方法 是新增、修改、查询（按关键字 查询）、统计（按特定时限统计 册数与金额）。 借阅记录类：借阅人（朋友）、 借阅时间。 借阅记录列表类：主要职责就是 添加记录（借出）、删除记录 （归还）以及打印借阅记录

88 Qualifier and constraints
导航性分析：Book与BookList之间、BorrowRecord和BorrowList之间是组合关系均无需添加方向描述，而Book与BorrowRecord之间则是双方关联，也无需添加 约束：Book对象创建后就不能够 被删除只能被修改，因此在Book 类边上加上用自由文本写的约束 ； 一本书要么属于计算机类，要么 属于非计算机类，因此在ItBook 和OtherBook间加了 “{Xor}”约束 限定符：一本书只有一册，因此只 能够被借一次，因此对于一本Book 而言只能有一个RecordId与其对应

89 Agenda What is a class How to read class diagrams Advanced topics How to draw class diagrams Class diagram specification Composite structure Summary

90 System modeling Domain model (领域模型) 是从面向对象的视角看待现实世界的结果，也就是通过类图来描述现实世界中各种事物的关系。 Analysis model (分析模型) 和领域模型是很相近的，分析模型主要是针对软件系统的分析，领域模型则更多是偏重对业务领域的分析 Design model (设计模型)则是在分析模型的基础上添加设计元素的结果。与分析模型相比，设计模型中的类的属性集更趋完善；

91 数据库逻辑模型 “Super set” of E-R diagram: 从某种意义上说UML中的类图是E-R图的超集，E-R图只针对存储的数据，而类图则在些基础上，增加了行为建模的能力。在使用类图来表示E-R模型时，要注意遵循以下策略 将表示E-R模型的类，用UML的标准构造型“{persistent}”来表示； 展开类的结构性细节，并且加强关联和多重性分析； 尽量消除循环关联、n-元关联

92 Agenda What is a class How to read class diagrams Advanced topics How to draw class diagrams Class diagram specification Composite structure Summary

93 Agenda 什么是类 如何阅读类图 其他高级概念 如何绘制类图 类图应用说明 复合结构图 本章小结

94 Composite structure 通过 “部件（Part）”和“连接器（Connector）”来表示类的内部结构 部件也称为结构化部分，它是一个代表上下文关系中的一个对象或一组对象的元素，也可以是类中的一部分。部件具有名称、类型和多重性 连接器：是一种上下文中的关联，它用来连接两个部件

95 Example of composite structure
该类由“命令解析”、“485通信”和“数据组装”三个部分组成，命令解析提供了getState（获取状态）和setState（设置状态）两个接口； 根据传入数据的不同， 由“485”通信来完成数据 的获取或设置的任务； 并且根据最终的执行结 果，进行“数据封装”， 调用外部的storeData接 口来实现数据的存储

96 Agenda What is a class How to read class diagrams Advanced topics How to draw class diagrams Class diagram specification Composite structure Summary

97 Summary 首先，从一个现实生活中的例子开始引入面向对象思想的本质，并且详细地说明了UML中类的表示法 接着讲述了阅读类图的方法、技巧和相关的知识：关系、多重性、导航箭头、角色名称、导出属性、限定符、约束；接口/抽象类、关联类、模板类、主动类、嵌套类；OCL 类图的绘制方法，类图的功能与作用 复合结构图的基础知识 重点复习内容：面向对象基础，