Class diagram is used to describe the classes contained in the system and the relationship between them, to help people simplify the understanding of the system, it is an important product of the system analysis and design phase, but also the system coding and testing important model basis. Let's talk about the composition of the class diagram, and we'll discuss the relationship between class diagrams in the next article.
First, the composition of the class diagram
1. General class
is a UML ordinary class diagram, from our view, a UML is usually composed of three parts.
The first part is the class name: Each class must have a name, and the class name is a string.
The second part is the property of the Class (Attributes): The property refers to the nature of the class, which is the member variable of the class. A class can have any number of attributes, or it can have no properties.
The format of the property:
可见性 名称:类型 [ = 缺省值 ]
Visibility Indicates whether the property is visible to elements outside of the class, including public, private, and protected (protected) three, denoted by symbol +,-, and # in the class diagram.
The name represents the property name, represented by a string.
A type represents the data type of a property, either a base data type or a user-defined type.
The default value is an optional option, the initial value of the property.
The third part is the operation of the Class (Operations): The action is the behavior that any instance object of the class can use, and is the member method of the class.
Format of the operation:
可见性 名称(参数列表) [ : 返回类型]
The definition of visibility is the same as the visibility definition of a property.
The name is the method name, represented by a string.
The parameter list represents the parameter of the method, its syntax is similar to the definition of the property, the number of arguments is arbitrary, and multiple parameters are separated by a comma ",".
The return type is an option that represents the return value type of the method, depends on the specific programming language, can be a basic data type, can be a user-defined type, can be an empty type (void), and no return type if it is a construction method.
The underscore indicates that this method is a static method.
2. Abstract class
As shown, the difference between abstract classes and ordinary classes is that the names of abstract classes are written in italics, and abstract methods in abstract classes are italicized.
The interface has the upper two methods, the first method is to add <> to the front of the class, so that the class becomes the interface class, the second method is to declare an interface, next to the circle is the name of the interface, and then to implement its class, the second method of expression I personally still do not understand, There is no way to write this interface in the circle, to implement its class to the time of the interface method, but how can distinguish what is the interface which is itself? Please also know the great God to explain.
Relationship in the class diagram
1. Related relationships
An association (association) relationship is the most common relationship between a class and a class, and it is a structured relationship that is used to indicate that a class of objects is associated with another type of object, such as cars and tires, Master and apprentice, class and student, and so on. In UML Class diagrams, the classes that connect objects associated with a solid line are used to implement association relationships using programming languages such as Java, C #, and C + +, and the object of one class is typically used as a member variable of another class . When you use a class diagram to represent an association relationship, you can label the role name on the association line, typically using a verb or noun that represents the relationship between the two, representing the role name (sometimes the noun is the instance object name), and the relationship ends up representing two different roles, so you can include two role names in an association relationship, which is not required. Can be increased as needed, with the aim of making the relationships between classes more explicit.
In UML, association relationships often contain several forms:
(1) Bidirectional correlation
By default, associations are bidirectional. For example, a customer (customer) buys a product and owns a product, and conversely, a customer sells a product that is associated with it. Therefore, there is a two-way association between the customer class and the Product class:
(2) One-way correlation
The Association of a class can also be unidirectional, and a one-way association is represented by a solid line with arrows. For example: The customer has an address, and the customer class has a one-way association with the address class:
There may be some classes in the system where the Property object type is the class itself, and this special association relationship is called self-correlation. For example, the member of a node class is another node-type object:
(4) Multiple sexual associations
The multiplicity Association is also called the Multiplicity (multiplicity) Association, which represents the correspondence relation between the number of two related objects. In UML, the multiplicity of objects can be represented directly on the associated line by a number or a range of numbers.
There can be multiple multiple association relationships between objects, and the common multiplicity representation is as shown in the table:
||Description of Multiplicity
||Indicates that an object of another class is related only to an object of that class
||Represents an object of another class that has a relationship to 0 or more objects of that class
||Represents an object of another class that has a relationship to one or more objects of the class
||Indicates that an object of another class does not have or is related only to an object of that class
||Represents an object of another class with a minimum of M, a maximum of N objects (m≤n)
For example, an interface (Form) can have 0 or more buttons (button), but a button can belong to only one interface, so an object of a form class may be associated with an object of 0 or more button classes. However, an object of a button class can be associated with only one object of the form class.
2. Aggregation relationship
aggregation is a special case of association relationship, he embodies the whole and part, the relationship between the has-a, the relationship between the whole and the part is separable, they can have their own life cycle, some can belong to multiple whole objects, can also be shared in UML for multiple whole objects, The aggregation relationship is represented by a straight line with a hollow diamond. For example, a car engine is an integral part of a car, but a car engine can exist independently, so the car and the engine are the aggregation relationships:
When the code implements an aggregation relationship, the member object is usually injected into the overall object as a constructor, setter, or business method parameter.
3. Combinatorial relationships
The combination is also a special case of the relationship, he embodies a contains-a relationship , which is stronger than aggregation, also known as strong aggregation, he also embodies the relationship between the whole and part, but at this time the whole and part is not divided, The end of the whole life cycle also means that part of the life cycle is over. In UML, a composite relationship is represented by a straight line with a solid diamond. For example: The head (head) and Mouth (Mouth), the mouth is one of the components of the head, and if the head is gone, the mouth is not, so the head and mouth is a combination of relations,
4. Dependency relationship
It can be simply understood that a class A uses another Class B, which is accidental, temporary, and very weak, but changes in class B affect A; For example, if someone wants to cross the river and borrow a boat, the relationship between the man and the ship is dependent; At the code level, For Class B as a parameter is used by Class A in a methods method;
In UML, a dependency relationship is indicated by a dashed line with arrows, and the relying party points to the relying party. For example: The driver drives, the car type Object car is passed as a parameter in the drive () method of the driver class, so that the car's move () method can be called in the drive () method, and the driver () method relies on the car's Move () method, So class driver depends on the class car,:
5. Generalization relationship
a generalization (generalization) relationship is also an inheritance relationship that describes the relationship between a parent class and a subclass , which is also known as a base class or superclass, and a subclass is also known as a derived class. In UML, the generalization relation is represented by a straight line with a hollow triangle. When the code is implemented, we use an object-oriented inheritance mechanism to implement generalization relationships, such as using the extends keyword in the Java language, and using the colon ":" in c++/c#. For example: The student class and the teacher class are subclasses of the person class, and the student class and the teacher class inherit the properties and methods of the person class, the property of the person class contains the name (name), and the Age, Each of the student and teacher also has these two attributes, and the student class adds the attribute number (STUDENTNO), the teacher class adds the attribute teacher number (Teacherno), and the person class method includes the walk Move () and speak Say (), student class and teacher class inherit both methods, and student class is also new method study (), teacher class is also new method teach (). ：
6. Implementing the Relationship
Interfaces can also have inheritance relationships and dependencies similar to those between classes, but there is also an implementation (realization) relationship between the interface and the class, in which the class implements the interface, and the operations in the class implement the actions declared in the interface. In UML, the implementation relationship between a class and an interface is represented by a dashed line with a hollow triangle. For example: Defines a transport interface vehicle, which contains an abstract operation Move (), which implements the move () operation in class ship and class car, but the specifics of the implementation will be different:
Iii. the difference between relationships
1. Aggregation and Combination
(1) Aggregation and combination are a kind of binding relationship, but the extra has a whole-part meaning.
(2) different life cycle of parts
In an aggregation relationship, the entire piece does not have a life cycle of the part, so the part is not deleted when the whole piece is deleted. Furthermore, multiple pieces can share the same part.
In a composite relationship, the entire piece has a life cycle of the part, so the part must be deleted when the whole piece is deleted. Also, multiple pieces cannot share the same part at the same time.
(3) The aggregation relationship is a "has-a" relationship, and the combined relationship is a "contains-a" relationship.
2. Associations and Aggregations
(1) Performance at the code level, and the association is consistent, can only be differentiated from the semantic level.
(2) The difference between association and aggregation is mainly semantically, and the associated two objects are generally equal, for example, if you are my friend, aggregation is generally not equal.
(3) Association is a structured relationship in which an object is associated with another object.
(4) Association and aggregation are depending on the problem domain, for example, in the field of concern about the car, the tyre must be combined in the car class, because it has no meaning to leave the car. But in the business of selling tires, even if the tires leave the car, it makes sense, and it can be aggregated.
3. Associations and Dependencies
(1) in association, it is a kind of strong dependency between the two classes, or the semantic level between the class and the interface, such as me and my friends; this relationship is more than relying on the contingency, the relationship is not temporary, generally long-term, and the relationship between the two is generally equal.
(2) In the dependency relationship, it is simple to understand that a class A uses another Class B, which is contingent, temporary, and very weak, but changes in class B affect a.
4. Comprehensive comparison
These relationships are semantically level, so it is not possible to completely differentiate the relationships from the code level, but in general, the latter relationships are shown in the following ways:
Combination > Aggregation > Correlation > dependencies;
UML (i) class diagrams and inter-class relationships (generalization, implementation, dependency, association, aggregation, composition) of design patterns