UML practice-use case diagram, sequence diagram, state diagram, class diagram, package diagram, and collaboration Diagram

Http://www.uml.org.cn/oobject/200901203.asp

UML practice-use case diagram, sequence diagram, state diagram, class diagram, package diagram, and collaboration Diagram

Author: Randy Miller Source: Network

The key to dealing with object-oriented problems is modeling. Modeling can abstract many important details in the complex world. Many modeling tools encapsulate UML (that is, the Unified Modeling Language). This course aims to show the highlights of UML.

There are nine types of modeling icons in UML:

• Use case diagram
• Class Diagram
• Object Graph
• Sequence Chart
• Collaboration Diagram
• Status chart
• Activity diagram
• Component Diagram
• Configuration chart

Some parts of this course contain links to the details of these graphs. In addition, each part has a small problem. Test your understanding of this part.

Why is UML important?

To answer this question, let's look at the construction industry. The designer designs the house. The construction engineer uses this design to build the house. The more complex the building is, the more important the communication between the designer and the construction personnel is. The blueprint has become a required course for designers and construction personnel in this industry.

Writing software is like building a building. The more complex the system is, the more important the communication between the personnel involved in writing and configuring the software is. In the past decade, UML has become an analyst, designer, andProgramBuilding blueprint between members ". Now it has become part of the software industry. UML provides a common language for analysts, designers, and programmers in software design.

UML is applied to solving object-oriented problems. To learn UML, you must be familiar with the basic principles of object-oriented Problem Solving-all starting from the creation of models. A model is the abstraction of fundamental issues. Domain is the real world where the problem is located.

The model consists of object objects, which send messages to each other to interact with each other. Remember to think of an object as "alive ". Objects have things they know (attributes) and things they can do (behavior or operation behaviors or operations ). The attribute value of an object determines its State.

Class classes is the "blueprint" of the object ". A class encapsulates attributes (data) and behaviors (methods or functions) in a separate entity ). The object is the instance instances of the class.

Use case diagram

Use case diagram Use Case Diagrams to describe the impression of the system as an external observer. Emphasize what the system is, not how it works.

The use case diagram is closely related to the plot. Scenario refers to a situation in which an individual interacts with the system. The following is the story of a hospital outpatient department.

"A patient calls the clinic to schedule a one-year health check. The receptionist finds out the latest no-reservation time in the booking record and records the appointment records at that time ."

Use case is the sum of a series of plots to complete a job or achieve a goal. The role actor is the person or thing that initiates an event related to this job. A role simply acts as a person or object. The following figure shows a make appointment case in the outpatient department. The role is patient. Communication between roles and use cases refers to communication with communication Association (or communication)

A role is a person-like icon, a use case is an elliptic, and communication is the line connecting a role and a use case.

A use case diagram is a set of relationships between roles, use cases, and them. We have used make appointment as part of a graph containing four roles and four use cases. Note that a single use case can have multiple roles.

Use Case charts are useful in three fields.

• Determines features (requirements ). New use cases generate new requirements when the system has been analyzed and designed
• Customer communication. The use case diagram easily shows the relationship between developers and customers.
• Generate Test Cases. The plot of a single use case may generate a batch of test cases for these scenarios.

Class Diagram

Class diagram Class digoal indicates the system by displaying the system classes and the relationships between these classes. Class diagrams are static-they show what can have an impact, but do not tell you when it will have an impact.

The following is a class diagram of a customer's model for commodity booking from a retailer. The center class is order. It connects the customer and payment of the purchased goods. There are three payment methods: cash, check, or credit. The order includes orderdetails (line item), each of which is connected to item.

The UML Class symbol is a box divided into three parts: Class Name, attribute, and operation. The name of the abstract class. For example, payment is italic. The relationship between classes is a connection line.

Class Diagrams have three relationships.

• Association-indicates the relationship between two types of instances. If an instance of a class must use an instance of another class to complete its work, it must be associated. In the figure, the Association is represented by a line between two classes.
• Aggregate aggregation-when a class belongs to a container, it is a special relationship. Aggregation uses a line with a diamond, and the diamond points to the class with the overall nature. In our detail, order is the orderdetails container.
• Generalized generalization-an inheritance line pointing to a super class using other classes. A generalized relationship points to a superclass with a triangle. Payment is the superclass of cash, check, and credit.

One association has two tails. Each tail end can have a role name to describe the role of association. For example, an orderdetail instance is a project of an order instance.

The direction navigability arrow on the Association indicates the direction in which the association is passed or queried. The orderdetail class can query its items, but cannot query them in turn. The arrow direction can also tell you which class has the implementation of this association; that is, orderdetail has the item. Association with arrows without direction is bidirectional.

The number at the end of the Association indicates the number of numbers corresponding to an instance on the other side. A diverse number can be a separate number or a range of numbers. In this example, each order has only one customer, but one customer can have any number of orders.

The following table provides the most common examples of diversity.

Diversity
Meaning

0 .. 1
0 or 1 instance. n .. m represents n to M instances

0 ..*Or*
There is no limit on the number of instances (including none ).

1
Only one instance

1 ..*
At least one instance

Each class diagram includes class, association, and diversity representation. Direction and role are optional items to make the illustration clearer.

Package and object graph

To easily represent complex class diagrams, you can combine classes into packages. A package is a set of elements with logical relationships on UML. The following figure shows a business model that combines classes into packages.

Dependencies relationship. If another package B changes, one package a may change, then Package A depends on Package B.

The package is represented by a rectangle with a small label on the top. The package name is written on the label or in the rectangle. The dotted line arrow indicates dependency.

Object diagrams is used to represent an instance of a class. They are useful when interpreting small issues of complex relationships (especially when recursive relationships.

This class shows that a department of a university can include many other departments.

The instance of the class chart on this object graph. Many specific examples are used.

The instance name in UML is underlined. The class or Instance name can be omitted in the object graph.

The rectangle of each class graph corresponds to a separate instance. The UML chart highlighted in the instance name. The class or Instance name may be omitted from the object chart, as long as the meaning of the chart is still clear.

Sequence Chart

Class charts and object graphs are static model views. The interaction diagram is dynamic. They describe the interaction between objects.

The sequence graph shows the interaction as a two-dimensional graph. The vertical line is the timeline, and the time goes down along the vertical line. The horizontal axis represents the class meta-roles of independent objects in the collaboration. The class meta-role is represented by a lifeline. When an object exists, the role uses a dotted line. When the object is activated, the lifeline is a dual line.

Messages are represented by arrows from the lifeline of an object to the lifeline of another object. Arrows are arranged from top to bottom in chronological order.

Collaboration Diagram

A collaboration chart is also an interactive chart. They transmit the same information like a sequence chart, but they do not care when the message is transmitted, but only care about the role of the object. In the sequence diagram, the role of the object is placed above, and the message is a connection line.

The class or object name (or both) is attached to the rectangle of the object role ). The class name is preceded by a colon (:).

Each message in the Collaboration diagram has a serial number. The number of top-level messages is 1. Messages of the same level (that is, messages in the same call) have the same number prefix, and then add a suffix 1 and 2 according to the order in which they appear.

Status chart

The object has behaviors and States. The object State is determined by the current action and condition of the object. Status chart statechart diagram shows the possible state of the object and the transfer caused by the state change.
The model example shows how to create an online logon system for a bank. The logon process includes entering a valid password and personal account, and then submitting it to the system for verification.

The logon system can be divided into four non-overlapping states: Getting SSN, getting pin, validating, and rejecting. Each status has a complete set of transfer transitions to determine the sequence of States.

The status is represented by a rounded rectangle. The transfer is represented by a line with arrows. The event or condition that triggers the transfer is written next to the arrow. There are two self-transfer methods in our graph. One is in getting SSN, and the other is in getting pin.

The initial state (black circle) is the virtual start of the starting action. The end status is also the virtual end of the action.

The event or condition trigger action is represented by (/action. When the instance enters the validating status, the object does not trigger a transfer when an external event is triggered. Instead, it generates an action. The result of the action determines the status of the next step.

Activity diagram

Activity diagram activity digoal is a special flowchart. There is a relationship between the activity chart and the status chart. The status chart focuses on the objects in the process, while the activity chart focuses on a separate process action flow. The activity diagram shows the dependency between activities.

For our example, we use the following process.

"Using ATM to get money ."

This activity has three types of customers, ATM and bank. The whole process starts from a black circle to a concentric circle in black and white. The activity is represented by a rounded rectangle.

Activity graphs can be broken down into many object swimming channels, which can decide which objects are responsible for those activities. Each activity has a separate transfer transition connection to this other activity.

A transfer may be a branch of branch into two or more mutually exclusive transfers. The protection expression (in []) indicates that the transfer is derived from a branch. Merge merge at branch end and diamond in the figure.

Transfer can also be decomposed into more than two parallel activities. The threads at the end of the decomposition and the end of the decomposition are combined with the join statement, which is expressed by a thick black line in the figure.

Components and configuration Diagram

Component component isCodeModule. A component chart is a physical implementation of a class chart.

The configuration map deployment diagrams displays the configuration of software and hardware.

The following configuration diagram illustrates the relationship between software and hardware components related to real estate transactions.

Physical hardware is represented by node nodes. Each component belongs to one node. The component is represented by a rectangle with two small rectangles in the upper left corner.

Link: http://dn.codegear.com/article/31863