Dynamic modeling

For static structure and dynamic behavior, uml provides diagrams to describe the structure and behavior of the system. UML provides diagrams to describe the structure and behavior of the system. Class diagrams are most suitable for describing the static structure of the system, classes, objects and their relationships, while state, sequence, collaboration and activity diagrams are suitable for describing the dynamic behavior of the system. That is to describe how the objects in the system interact dynamically at different points of time during execution.

Objects in the system need to communicate with each other: they send messages to each other. Under normal circumstances, a message is an object that activates an operation call in another object. How the object communicates and the result of the communication is the dynamic behavior of the system, that is, the way the objects cooperate through communication and the system The way an object changes state during the lifetime of the system is the dynamic behavior of the system. A group of objects that communicate in order to achieve some functions are called interactions, and interactions can be described by three types of diagrams: sequence diagrams, collaboration diagrams, and activity diagrams.

 

State diagram: describes which state the object is in during its life cycle, the behavior of each state, and what events cause the state of the object to change.

Sequence diagram: describes how objects interact and communicate with each other. The most important thing in a sequence diagram is time. Through the sequence diagram, you can see how a group of objects send and receive a sequence of messages in order to complete certain functions.

Collaboration diagram: Describes the interaction of objects, focuses on spatial collaboration, and clearly shows the relationships (links) between objects.

Activity diagram: describes the interaction of objects, focusing on the description of work. When the objects interact, some work or activities need to be performed. These activities and their order of appearance are what the activity diagram wants to describe.

 

Sequence diagrams, collaboration diagrams, and activity diagrams are all used to describe object interactions. When describing an interaction in detail, you need to make a choice for this. The specific choice depends on which aspect of the description: time? space? Or activity?

 

In addition to static structure and dynamic behavior, it can also be described from the perspective of function. The perspective of function is mainly to describe the function of the system. Use case is to describe the system from the perspective of function. It describes how roles use the system, classes and interactions to implement the system. Use cases. Interactions are described by sequence diagrams, collaboration diagrams or activity diagrams, so there is also a connection between functional views and dynamic views. The classes used in the realization of use cases are described in class diagrams and state diagrams.

 

I, whereabouts

A message is an arrow line connecting the sender and receiver, and the type of arrow indicates the type of message.

Simple message: It represents a normal control flow. It only represents how control is passed from one object to another, without describing any details of the communication.

Synchronous message: A nested control flow, which typically represents an operation call. The operation of processing the message is completed before the caller resumes execution. The return can be represented by a simple message, or implicitly when the message has been processed.

Asynchronous message: asynchronous control flow, not directly returned to the caller, the sender needs to wait for the completion of the message processing after sending the message and continue to execute.

Second, the state diagram
The state diagram is mainly used to describe the life cycle of objects, subsystems, and systems. Through the state diagram, you can understand all the states that an object can reach and the impact of events received by the object on the state of the object. All classes, as long as it has labelable states and complex behaviors, should have a state diagram.
The state diagram specifies the behavior of the object and the difference between the behavior according to different current states. At the same time, it can also explain how events change the state of an object of a class.
The result of the previous activity of the object operation in the state is usually determined by the attribute value of the state object and the chain pointing to other objects. The state of the class is explained by the specified attribute in the class or the state of the object is determined by the value of the general attribute in the object.
The state diagram can have a start point and multiple end points. The start point is represented by a black dot, and the end point is represented by a black dot plus a circle. The state in the state diagram is represented by a rounded quadrilateral, and the state transitions between states are represented by a line with an arrow. The event that caused the state transition can be represented by a label next to the state transition line.
A state generally contains three parts, the first part is the name of the state, the second part is the variable name and value of the optional state variable, the attribute refers to the attribute of the class in the state diagram, and the third part is the optional activity table , List related events and activities. In the activity table, the following three standard events are often used: enter, exit, and do.
The syntax of the active part is as follows:
 

Guess you like

Origin blog.csdn.net/jinzhengquanqq/article/details/5871596