Agile Software Development: principles, patterns and practices--the 19th class diagram

19th Chapter Class diagram

19.1 Basic Knowledge
19.1.1 class

Classes are generally expressed as follows:

The class icon for the lattice and the corresponding code

Note that the variables and function names in the class icon are preceded by a match. (-) denotes private, (#) represents protected; (+) represents public.

19.1.2 Association

The association between classes represents the instance variables that hold references to other objects. such as the association between Phone and button:

A phonebook object is connected to multiple PhoneNumber objects (asterisks represent many):

19.1.3 inheritance

All arrows in UML point to the direction in which the source code is dependent. Inheritance between classes and classes is with a solid line, and the inheritance between classes and interfaces is dashed. I suggest drawing on the Whiteboard, do not draw the arrows into a dashed line, drawing a dashed line is a waste of time.

Examples of inheritance relationships:

Examples of implementation relationships:

Equivalent to the following lollipop-like interface:

19.2 Class diagram example

The following is an example of ATM:

When you see this picture, you should be able to visualize the code. The code for the UI implementation is as follows:

 Public Abstract classUi:withdrawalui, Depositui, transferui{PrivateScreen Itsscreen; PrivateMessageLog Itsmessagelog;  Public Abstract voidPromptfordepositamount ();  Public Abstract voidPromptforwithdrawalamount ();  Public Abstract voidinforminsufficientfunds ();  Public Abstract voidPromptforenvelope ();  Public Abstract voidPromptfortransferamount ();  Public Abstract voidPromptforfromaccount ();  Public Abstract voidPromptfortoaccount ();  Public voidDisplayMessage (stringmessage)        {itsmessagelog.logmessage (message);    Itsscreen.displaymessage (message); }}

19.3 Details

In most cases, the details and decorations should not be added, but sometimes they are useful.

19.3.1 type

The class shape appears between a pair of grammar numbers (<<>>). C # programmers can use two standard diffraction:<<interface>> and <<utility>>.

19.3.2 Abstract class

Write the name in italics, or use the (abstract) attribute to represent the abstract class:

When drawing on a whiteboard, you can use an informal representation:

19.3.3 Property

property is written as a comma-delimited list of name/value pairs. The attribute is written in the lower right of the class name:

In addition to the {abstract} property, I don't know what the properties are useful for. Personally, I've been drawing UML diagrams for so many years that I haven't found anything useful in using class properties.

19.3.4 Aggregation
Aggregation (aggregation) is a special form of association that implies a whole/part relationship.

19.3.5 Combination

A combination (composition) is a special form of aggregation. Owner/property relationship.

19.3.6 Multi-Sex

An object can contain arrays or collections of other objects, and can hold many other homogeneous objects than different instance variables. A multiplicity expression can be a simple number, a range, or a combination of both.

Multi-character allowed:

Number-the exact number of elements;

* or 0. *--0 to more than one.

0..1--0 or 1, in C #, are often implemented with a nullable reference.

1..*--1 to more than one.

3..5--3~5 A

0,2..5,9..*--is ridiculous, but it is legal.

19.3.7 Correlation diffraction Type

The <<create>> pattern means that the source creates the purpose and passes it to other parts of the system.

The <<local>> pattern means that the lifetime of the created instance is within the scope of the member function that created it.

The <<parameter>> shape indicates that the source class obtains access to the target instance through the parameters of a member function. The virtual dependency arrow line is a common and convenient parameter representation method.

<<delegate>> the source class transfers a member function call to the target.

19.3.8 Inline class

　　
19.3.9 Association Classes

Although multiple associations tell us that the source and many target instances are connected, we cannot see what kind of container class is used. This can be described by an association class.

19.4 Conclusion
To avoid most of the mysterious and complex features in UML, just know the parts that you use frequently. Too little use of UML is almost always better than too much use.

Excerpt from: "Agile Software Development: principles, patterns and Practices (C # Edition)" Robert C.martin Micah Martin

Reprint please specify the source:

Jesselzj
Source: http://jesselzj.cnblogs.com

Agile Software Development: principles, patterns and practices--19th class diagram