[Study Notes] UML summary and preliminary System Design Based on Domain Model

Document directory

• In the class diagram, draw the relationship between classes.

UML

 

UML is neither OOA/D nor a method. It is just a graphical representation. The purpose is to make people understand what you know.

Each graph is equivalent to an angle. Different graphs are used to observe the system from different angles.

For example, the traffic map and Administrative Area Chart observe China from different angles.

 

The Necessity is the principle of drawing. Although there is such a relationship, you do not have to draw it out. If you have to draw it out, consider not to affect the appearance of the image.

 

Activity diagram

An activity diagram represents a process.

Example:

Sequence Chart

The purpose of a sequence chart is to assign responsibilities to objects, rather than listing steps.

In, actionservlet is not necessary to draw out, it is a very stable, not provided by ourselves, there is no need to describe its object responsibility. It is obviously unnecessary to insert it here.

In this case, you can:

Use Case and use case diagram

Use case definition: text description.

 

Use Cases are used to discover and record requirements, which will affect subsequent OOA/D work.

 

Use Cases are not examples. The use case diagram is not important, and the use case description is important.

 

Use cases should not be named by nouns, but should start with a verb, for example, managing commodities.

Use Cases are generally used for functional requirements rather than for performance requirements.

When writing a case, only the primary success event is written in the basic path (that is, the primary success path), and other possible situations (such as the user cannot be found) should be written in the extension point.

 

Use Case granularity: for example, whether to use a management user as a use case or add or delete a user as two use cases respectively.

When determining the granularity of a case, several steps are required to describe the basic path of the case. Within 10 steps, 7 or 8 steps are more appropriate.

A typical case description

A typical use case chart

The relationship between the sales manager and the cashier is a general relationship, that is, the manager has all the use cases owned by the cashier. There are also exclusive use cases.

Class Diagram

Class Diagrams allow us to mark the relationship between static content and classes. They are the most important figures in UML and can be used at any time.

Do not use a class chart to describe all the details and keep it simple.

UML has three main types: boundary class, control class, and entity class.

The boundary class is at the junction of the system and the outside world, such as forms, reports, communication protocols, directly interacting with external devices, and directly interacting with external systems. The use case diagram can be used to determine the required boundary class. Each actor/Use Case pair requires at least one boundary class, but not each actor/Use Case pair must have a unique boundary class.

Entity classes can be discovered through event streams and interaction graphs. Generally, each object class has a corresponding table in the database, and the attributes in the object class correspond to fields in the database table.

The control class controls other jobs. The control class can be shared by multiple use cases. Other classes do not send many messages to the control class. Instead, the control class sends many messages.

 

In the class diagram, draw the relationship between classes.

The connection and difference between inheritance, implementation, dependency, association, aggregation, and combination in UML

Inheritance (Also called generalization)

A class (called a subclass or sub-interface) inherits the functions of another class (called parent class or parent interface) and can add its own new functions, inheritance is the most common relationship between classes or interfaces. in Java, such relationships are identified by the keyword extends, which is generally not controversial during design;

Implementation

It refers to the function of a class to implement interface interfaces (which can be multiple). Implementation is the most common relationship between classes and interfaces. in Java, such a relationship is identified by the keyword implements, it is generally not controversial during design;

Dependency

It can be simply understood that a class A uses another class B, and this use relationship is contingent, temporary, and very weak, but changes in Class B will affect; for example, if a person wants to cross the river, he needs to borrow a ship. In this case, the relationship between the person and the ship is dependent. The class B is represented in the Code and used as a parameter by Class A in a method;

Association

It represents a strong dependency between two classes or between classes and interfaces, such as my friends and I; this relationship is more dependent than the dependency relationship, with no dependency relationship. The relationship is not temporary and is generally long-term. In addition, the relationship between the two parties is generally equal, and the relationship can be one-way and two-way; it is manifested in the Code layer. For associated Class B, it appears in the form of class attributes in associated Class, it may also be that associated Class A references a global variable of the associated Class B;

Aggregation

Aggregation is a special case of association. It reflects the relationship between the whole and the part, that is, the relationship between has-a. At this time, the whole and the part can be separated, they can have their own lifecycles, some of which can belong to multiple objects, or share multiple objects, such as the relationship between computers and CPUs, and between companies and employees; it is manifested at the code level and is consistent with the Association, which can only be distinguished at the semantic level;

Combination

A combination is also a special case of association. It represents a contains-a relationship, which is stronger than aggregation, also known as strong aggregation; it also shows the relationship between the whole and the part, but the whole and the part are inseparable at this time, and the end of the overall life cycle means that part of the life cycle ends; for example, you and your brain; it is manifested at the code level, consistent with the association, and can only be distinguished at the semantic level;

Summary:

Inheritance and implementation reflect the vertical relationship between classes and classes, or between classes and interfaces, which is not easy to be confused; the other four relationships reflect the reference and horizontal relationships between classes and classes, or between classes and interfaces. These relations are semantic-level, therefore, the Code layer cannot be fully differentiated;

For example, in the field of car care, tires must be combined in the automobile category, because it has no meaning when it leaves the automobile. However, in the shops where tires are sold, even if the tires leave the car, it makes sense, and this can be aggregated.

In general, the strengths and weaknesses of the subsequent links are: Combination> aggregation> association> dependency.

Example 1

A special example of association, indicating a tree structure class chart,

You can use the following code to implement

Public class node {

Public ID;

Private node parent;

Private set <node> children;

}

Example 2:

The Association indicates that the document has a user-type field creator, so you do not have to write the creator in the document.

Example 3:

Because user is another complex concept, we need to establish associations instead of using user as a simple attribute (such as name)

Do not model complex domain concepts as attributes.

 

 Example 4:

Student and class are two-way associations. Of course, it can also be said that student depends on class, because student cannot be compiled without class. However, not all existing things need to be drawn, which indicates that the Association is more appropriate.

In addition, Association refers to the structure of the other Party. If object a only uses a method of object B, such as collections. Sort (), this is obviously dependent rather than associated.

Preliminary System Design Based on Domain Model

Important principles during design:

Low coupling and high cohesion.

Minimize the dependency on unstable objects. For very stable things, such as the core class library of JDK, you can rely on it at will.

Do not rely on forward engineering and reverse engineering. If you want to generate code from a graph, you have to pay attention to various details in the graph. It is better to write your own code.

Graphics are used to abstract the logic trunk for easy understanding. They cannot replace detailed and complete text descriptions.

Core Value of the system

The value of a domain model lies not in its beautiful design (it is only some objects, but also the relationship between objects), but in its embodiment of the core value of the system. What is the core value of the system? I think the essential difference between our library system and a commercial system on Wall Street is not what language, database, or process the system uses, the difference lies in what services and quality the system can provide to users. These are reflected by the system running mode, system running process, and system business logic.

Value of Use Cases

After taking over a system, the system analyst must first obtain the system services and service scenarios. That is, the use case we often talk about)

Many people do not know the value of clear use cases. They just draw a picture by themselves because they have beautiful images. In fact, they don't even look at it. Such case analysis can only confuse the boss and show the demo to others, without any substantial impact on system development.

The use case represents a scenario in which the system is used. In essence, it describes the system user (actor) in detail) how to interact with the system and what are the consequences of the Interaction. A detailed and complete Use Case will guide you throughout the system development process.

 

Low Coupling Design

In addition to dealing with Domain Models and users, the system object interacts with other modules of the system. For example, persistence systems, log systems, and information notification systems (you cannot change the domain model from email notification to SMS notification because the user requires it). Of course, there is also the UI, these are not the core of the system (domain model.

These modules should not be included in the business logic. Contact these modules at the boundary.

 

Example:

Public void borrow ()

{

Borrower handler = new borrower (current book, current login name );

Bool successful = handler. Borrow () // This method is mainly used for the above two generations

If (successful ){

Persistence system. Add (current book );

Log System. Add log (current nationality, "borrow ")

Email system. Send email (current book. Name of the borrower)

}

}

// The Key to this example is that you can implement the borrow logic in the "borrow ()" method first, and then perform persistence, log, and mail operations. However, here we get an additional "handler" object for special lending operations. The purpose is to separate the "borrowing" logic and make it loose to other modules.

 

 

Example 2:

Void persistence system. Add (current book)

{

Borrowing relationship BBB = new borrowing relationship

Bbb. ID = generate ID ()

Bbb. book id = current book. ID;

Bbb. borrower = current book. Borrow record. borrower name

Bbb. Borrow time = current book. Borrow record. Borrow time

Bbb. Save ();

}

In the real system, I have) some pure software designs have been made here. For example, C # has the event feature, and an event is published after the borrowing method. In this way, when I want to add any peripheral sound, I only need to respond to the event. yes. You don't need to change this method again.

 

 

The processing process of other modules is similar.

Business process is the core of the system, and other modules depend on it.

To change the business logic of a system, we only need to change the domain model and no longer need to complain about the changes.

 

 

References:

Shang UML series video

<Http://www.blogjava.net/lsshap/archive/2009/11/18/302755.html>

<Http://www.diybl.com/course/3_program/gcs/2008324/106156.html>

Http://blogger.org.cn/blog/more.asp? Name = nrzj & id = 17433>

<Http://blog.csdn.net/sfdev/archive/2009/02/18/3906243.aspx>

<Http://www.kuqin.com/system-analysis/20080613/9441.html>