UML 类图

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-class-diagram/

 

Purpose of Class Diagrams 类图的作用

1. Shows static structure of classifiers in a system   展示系统中的静态类结构
2. Diagram provides basic notation for other structure diagrams prescribed by UML 为其他结构图的描述做好基础准备。
3. Helpful for developers and other team members too 对开发者和其他团队成员都很有用
4. Business Analysts can use class diagrams to model systems from business perspective 业务分析人员可用类图做业务到系统的建模

A UML class diagram is made up of: 类图由如下的信息组成

• A set of classes and 一系列的类 和
• A set of relationships between classes 类之间的关系

What is a Class 类的定义

A description of a group of objects all with similar roles in the system, which consists of:

描述系统中一组相似的角色，由以下部分组成

• Structural features (attributes) define what objects of the class "know"  结构特征（属性）定义类的对象特征
  • Represent the state of an object of the class    表示类的对象的状态
  • Are descriptions of the structural or static features of a class 类的静态特征或者类的组成
• Behavioral features (operations) define what objects of the class "can do" 行为特征（动作）定义类对象能做些什么
  • Define the way in which objects may interact  定义对象的相互作用方式
  • Operations are descriptions of behavioral or dynamic features of a class 描述行为或者动态特征的操作

Class Notation 类标记

A class notation consists of three parts:类标记图由三部分组成

    1.Class Name 类名

• The name of the class appears in the first partition.在第一部分出现

 

 

     2.Class Attributes 类属性

• Attributes are shown in the second partition. 第二部分显示的是属性
• The attribute type is shown after the colon.属性类型在冒号后面
• Attributes map onto member variables (data members) in code.属性列表在代码中做为类的成员变量

    3. Class Operations (Methods) 类操作（方法）

• Operations are shown in the third partition. They are services the class provides.操作在第三部分展示，是类提供的服务。
• The return type of a method is shown after the colon at the end of the method signature.方法参数的返回类型在参数名称后面的冒号之后显示
• The return type of method parameters are shown after the colon following the parameter name.返回类型的方法参数在
• Operations map onto class methods in code 操作列表在代码中做为类的方法

The graphical representation of the class - MyClass as shown above:上图（蓝色部分）显示了 MyClass类

• MyClass has 3 attributes and 3 operations MyClass类有3个属性，3个方法
• Parameter p3 of op2 is of type int    方法P3的op2参数的类型是int
• op2 returns a float      op2返回了个float类型
• op3 returns a pointer (denoted by a *) to Class6  op3返回了个指向Class6类型的指针

Class Relationships  类关系

A class may be involved in one or more relationships with other classes. A relationship can be one of the following types: (Refer to the figure on the right for the graphical representation of relationships).

一个类可能会和一个或者多个其他类有关系。类之间的关系可能有下面这些类型：（参考右边图示）

Relationship Type  关系类型	Graphical Representation
Inheritance (or Generalization):继承 Represents an "is-a" relationship. 表示 “是一个” 关系 An abstract class name is shown in italics. 抽象的类名显示为斜体 SubClass1 and SubClass2 are specializations of Super Class.SubClass1 和 SubClass2 是supserClass的特例  A solid line with a hollow arrowhead that point from the child to the parent class 一个有空箭头的实线从子类指向父类 例子：家禽（supserclasses）、鸭子（subclass1）、鸡（subclass2） 这种有归属关系的可以用这个关系表示
Simple Association:简单关系 A structural link between two peer classes.两个同级的类之间的关系 There is an association between Class1 and Class2 类1和类2之间有关联 A solid line connecting two classes 用一条实线连接的两个类
Aggregation: 组合 A special type of association. It represents a "part of" relationship.一个特殊的关系，描述了整体和“部件”的关系 Class2 is part of Class1. 类2是类1的一部分 Many instances (denoted by the *) of Class2 can be associated with Class1.很多个类2都可以和类1有关系 Objects of Class1 and Class2 have separate lifetimes.类1和类2有独立的生命周期。类2离开类1可以独立存在。 A solid line with a unfilled diamond at the association end connected to the class of composite 一个有空菱形的实线连接的两个类 例子：类1 ：汽车和类2 ：零件，多个零件可以组成汽车，但零件可以独立使用在别处。
Composition:组成 A special type of aggregation where parts are destroyed when the whole is destroyed.一种特殊的聚集，部分不能独立于整体存在，整体消失了部分也不存在了。 Objects of Class2 live and die with Class1.类2与类1同生死（类1消失了类2肯定不存在了） Class2 cannot stand by itself.类2不不能做为一个独立存在 A solid line with a filled diamond at the association connected to the class of composite一个有实心菱形的实现连接的两个类 例子：类2 ：嘴巴和 类1 ：头
Dependency:依赖 Exists between two classes if changes to the definition of one may cause changes to the other (but not the other way around). 依赖关系存在于如果一个类改变了，那么另外一个类也会被改变 Class1 depends on Class2 类1依赖与类2 A dashed line with an open arrow 一个虚线由依赖类指向被依赖的类 例子： 订购信息---〉产品 （产品定义变了，那么订购的信息也变了）

Relationship Names 关系名称

• Names of relationships are written in the middle of the association line.关系名称一般写在两个类的连线中间
• Good relation names make sense when you read them out loud:好的关系名称让你读出其含义
  • "Every spreadsheet contains some number of cells",每个扩展的单元页包含一系列的单元格。
  • "an expression evaluates to a value" 一个表达式能算出一个值
• They often have a small arrowhead to show the direction in which direction to read the relationship, e.g., expressions evaluate to values, but values do not evaluate to expressions.它们通常有一个小箭头，以显示读取关系的方向，例如，表达式对值求值，但是值对表达式不求值。

Relationship - Roles 关系角色

• A role is a directional purpose of an association.
• Roles are written at the ends of an association line and describe the purpose played by that class in the relationship.
  • E.g., A cell is related to an expression. The nature of the relationship is that the expression is the formula of the cell.

Navigability

The arrows indicate whether, given one instance participating in a relationship, it is possible to determine the instances of the other class that are related to it.

The diagram above suggests that,

• Given a spreadsheet, we can locate all of the cells that it contains, but that
  • we cannot determine from a cell in what spreadsheet it is contained.
• Given a cell, we can obtain the related expression and value, but
  • given a value (or expression) we cannot find the cell of which those are attributes.

Visibility of Class attributes and Operations

In object-oriented design, there is a notation of visibility for attributes and operations. UML identifies four types of visibility: public, protected, private, and package.

The +, -, # and ~ symbols before an attribute and operation name in a class denote the visibility of the attribute and operation.

• + denotes public attributes or operations
• - denotes private attributes or operations
• # denotes protected attributes or operations
• ~ denotes package attributes or operations

Class Visibility Example

In the example above:

• attribute1 and op1 of MyClassName are public
• attribute3 and op3 are protected.
• attribute2 and op2 are private.

Access for each of these visibility types is shown below for members of different classes.

Access Right	public (+)	private (-)	protected (#)	Package (~)
Members of the same class	yes	yes	yes	yes
Members of derived classes	yes	no	yes	yes
Members of any other class	yes	no	no	in same package

Multiplicity

How many objects of each class take part in the relationships and multiplicity can be expressed as:

• Exactly one - 1
• Zero or one - 0..1
• Many - 0..* or *
• One or more - 1..*
• Exact Number - e.g. 3..4 or 6
• Or a complex relationship - e.g. 0..1, 3..4, 6.* would mean any number of objects other than 2 or 5

Multiplicity Example

• Requirement: A Student can take many Courses and many Students can be enrolled in one Course.
• In the example below, the class diagram (on the left), describes the statement of the requirement above for the static model while the object diagram (on the right) shows the snapshot (an instance of the class diagram) of the course enrollment for the courses Software Engineering and Database Management respectively)

Aggregation Example - Computer and parts

• An aggregation is a special case of association denoting a "consists-of" hierarchy
• The aggregate is the parent class, the components are the children classes

Inheritance Example - Cell Taxonomy

• Inheritance is another special case of an association denoting a "kind-of" hierarchy
• Inheritance simplifies the analysis model by introducing a taxonomy
• The children classes inherit the attributes and operations of the parent class.

Class Diagram - Diagram Tool Example

A class diagram may also have notes attached to classes or relationships. Notes are shown in grey.

In the example above:

We can interpret the meaning of the above class diagram by reading through the points as following.

1. Shape is an abstract class. It is shown in Italics.
2. Shape is a superclass. Circle, Rectangle and Polygon are derived from Shape. In other words, a Circle is-a Shape. This is a generalization / inheritance relationship.
3. There is an association between DialogBox and DataController.
4. Shape is part-of Window. This is an aggregation relationship. Shape can exist without Window.
5. Point is part-of Circle. This is a composition relationship. Point cannot exist without a Circle.
6. Window is dependent on Event. However, Event is not dependent on Window.
7. The attributes of Circle are radius and center. This is an entity class.
8. The method names of Circle are area(), circum(), setCenter() and setRadius().
9. The parameter radius in Circle is an in parameter of type float.
10. The method area() of class Circle returns a value of type double.
11. The attributes and method names of Rectangle are hidden. Some other classes in the diagram also have their attributes and method names hidden.

Dealing with Complex System - Multiple or Single Class Diagram?

Inevitably, if you are modeling a large system or a large business area, there will be numerous entities you must consider. Should we use multiple or a single class diagram for modeling the problem? The answer is:

• Instead of modeling every entity and its relationships on a single class diagram, it is better to use multiple class diagrams.
• Dividing a system into multiple class diagrams makes the system easier to understand, especially if each diagram is a graphical representation of a specific part of the system.

Perspectives of Class Diagram in Software Development Lifecycle

We can use class diagrams in different development phases of a software development lifecycle and typically by modeling class diagrams in three different perspectives (levels of detail) progressively as we move forward:

Conceptual perspective: The diagrams are interpreted as describing things in the real world. Thus, if you take the conceptual perspective you draw a diagram that represents the concepts in the domain under study. These concepts will naturally relate to the classes that implement them. The conceptual perspective is considered language-independent.

Specification perspective: The diagrams are interpreted as describing software abstractions or components with specifications and interfaces but with no commitment to a particular implementation. Thus, if you take the specification perspective we are looking at the interfaces of the software not the implementation.

Implementation perspective: The diagrams are interpreted as describing software implementations in a particular technology and language. Thus, if you take the implementation perspective we are looking at the software implementation.