Design-UML composition

UML consists of views, views (Diagram)、The model element (Model Element) and the general mechanism (General Mechanism) are composed of several parts.

a) View: A subset of UML modeling elements that express the characteristics of a certain aspect of the system. It is composed of multiple graphs and is an abstract representation of the system on a certain abstraction layer.

b) Diagram (Diagram): is a graphical representation of the model element set, usually composed of arcs (relationships) and vertices (other model elements) connected to each other.

c) Model Element: Represents the concepts of classes, objects, messages, and relationships in object-oriented, and is the most basic common concept that constitutes a graph.

d) General Mechanism: It is used to represent other information, such as annotations, semantics of model elements, etc. In addition, UML also provides an extension mechanism that enables the UML language to adapt to a particular method (or process), or expand to an organization or user.

 

2. Classification of UML views

UML is used to describe the model. The model is used to describe the system's mechanism or static characteristics, as well as behavior or dynamic characteristics. Model the system architecture from different perspectives to form different views of the system.

(1) Use Case View, which emphasizes the system functions seen or needed from the user's perspective, is a model diagram of system functions that can be observed by external users called participants.

(2) Logical View (Logical View), which shows the static or structural composition and characteristics of the system, also known as Structural Model View or Static View.

(3) Concurrent View, which reflects the dynamic or behavioral characteristics of the system, is also called Behavioral Model View or Dynamic View.

(4) The component view (Component View), which reflects the structure and behavior characteristics of the system implementation, is also called the implementation model view (Implementation Model View).

(5) Configuration view (Deployment View), which reflects the structure and behavior characteristics of the system implementation environment, also known as Environment Model View (Physical View) or Physical View.

 

Views are composed of graphs , and UML provides 9 different graphs:

(1) Use Case Diagram to describe system functions;

(2) Class diagram (Class Diagram), describing the static structure of the system;

(3) Object diagram, describing the static structure of the system at a certain moment;

(4) Component diagram (Component Diagram), which describes the organization of the elements that implement the system;

(5) Deployment Diagram, which describes the configuration of environment elements, and maps the elements of the implementation system to the configuration;

(6) State Diagram (State Diagram), which describes the state conditions and responses of system elements;

(7) Sequence Diagram (Sequence Diagram), describing the interaction between system elements in chronological order;

(8) Collaboration Diagram (Collaboration Diagram), describing the interaction between system elements and their relationship in time and space order;

(9) Activity diagram (Activity Diagram), describing the activities of system elements;

The modeling method is composed of modeling language and modeling process . The modeling language is used to express the design method, and the modeling process is a description of the steps that should be taken in the design. UML is a modeling language that is largely independent of the modeling process. In actual modeling, modelers are best to use UML in a case-driven, system-centric, iterative, and incremental development process.

Generally speaking, the architecture of a software system gives information about the organization of the software system, the choice of the structural elements and interfaces that make up the system, the behavior of the system, and the architectural style. In other words, it not only cares about the functional requirements such as the structure and behavior of the system, but also involves non-functional requirements such as system performance, easy to understand, and easy to reuse. As shown in the following figure, UML uses the user model view, structural model view, behavior model view, implementation model view, and environment model view to describe the architecture of the software system.

 

According to their application in different architecture views, 9 kinds of diagrams can be divided into:

(1) User model view: use case diagram;

(2) Structural model view: class diagram and objects;

(3) Behavior model view: state diagram, sequence diagram, collaboration diagram and activity diagram (dynamic diagram);

(4) Implementation model view: component diagram;

(5) Environment model view: configuration diagram.

The user model view consists of use cases that specifically describe the system behavior seen by end users, analysts, and testers . It actually describes the functions that the system should have from the user's perspective . The system functions described in the user model view rely on an external user or another system to activate and provide services for the user or another system, thereby realizing the interaction between the user or another system and the system. The ultimate goal of the system is to provide the functions described in the user model view. In UML, the user model view is composed of use case diagrams .

The structural model view describes the static structures such as the classes, objects, and relationships between them to support the functional requirements of the system, that is, how the internal functions of the system are designed. The structural model view is composed of class diagrams and object diagrams , and is mainly used by designers and developers .

Behavioral model view Figure mainly used to describe the formation of threads and processes Concurrency and synchronization mechanisms , the focus of its attention is the throughput performance of the system, easy scalability and systems such as non-functional requirements. The behavioral model view uses concurrency to describe the efficient use of resources, parallel execution, and processing of asynchronous events. In addition to dividing the system into control threads for concurrent execution, the behavioral model must also deal with communication and synchronization between these threads and processes. The behavior model view is mainly used by system developers and system integrators . It consists of sequence diagram, collaboration diagram, state diagram, and activity diagram .

The implementation model view is used to describe the dependencies and resource allocation of the system's implementation modules. This view is mainly used for system configuration management, it is composed of some independent components. The realization model view is composed of component diagrams . The components are code modules, and different types of code modules form different components. The implementation model view is mainly used by developers .

The environment model view is used to describe the hardware topology of the physical system . For example, the distribution of computers and devices in the system and the connection between them, where computers and devices are collectively called nodes. The environment model view in UML is represented by the deployment diagram. The system deployment diagram describes the distribution of system components on nodes, which is used to describe the mapping of software components to physical nodes. The deployment diagram is mainly used by developers, system integrators, and testers .

Each of the above views reflects a specific aspect of the system, and different people can use each of these views individually to focus on specific architectural issues. But under normal circumstances, because the ultimate goal of the system is to provide the functions described in the user model view and other non-functional requirements, the user model view is the core foundation of other views, and the construction of other views depends on the user model view The class described in.

Attentive readers have discovered that each UML diagram is composed of multiple diagrams, and each diagram is a representation of a certain side of the architecture. The various diagrams are actually consistent, and all the diagrams are composed together. A complete view of the system. As shown in the following figure, UML provides a total of 9 diagrams: use case diagram, class diagram, object diagram, sequence diagram, collaboration diagram, state diagram, activity diagram, construction diagram, and deployment diagram. According to whether they describe the static structure or dynamic behavior of the system, they can be divided into static graphs and dynamic graphs. When further introducing these 9 UML diagrams, first understand what are the model elements:

 

3. UML modeling mechanism

UML has two sets of modeling mechanisms: static modeling mechanism and dynamic modeling mechanism. Static modeling mechanisms include use case diagrams, class diagrams, object diagrams, packages, component diagrams, and configuration diagrams. Dynamic modeling mechanisms include state diagrams, timing diagrams, collaboration diagrams, and activity diagrams.

(1) Use case diagram: A use case visualization tool that provides a high-level user view of the computer system and represents how the system will be used from the perspective of external actors.

Use case diagrams (use case diagrams) are used to describe a set of use cases, participants, and the connection between them. A use case diagram describes a set of action sequences, and each sequence represents the interaction of the system's external facilities (system participants) with the system itself. From the perspective of a particular participant, a use case accomplishes a work that is valuable to it. As shown in Figure 2.5, the use case diagram only describes the information in the system from the perspective of participants using the system, that is, standing outside the system to see what function the system should have, but does not describe how this function is implemented inside the software . The use case can be applied to the entire system or a part of the system, including subsystems, individual classes, or interfaces. Often, use cases not only represent the expected behavior of these elements, but they can also be used as the basis for test cases during development.

The use case diagram includes the following three aspects:

(a) Use Case

(b) Actor

(c) Dependence, generalization and association

Example use case diagram:

(2) Class diagram: a diagram describing classes, interfaces, collaboration, and relationships between them.

Class diagrams are used to describe a set of classes, interfaces, collaborations, and static relationships between them. In the modeling of object-oriented systems, the class diagram is the most commonly used diagram, which is used to clarify the static structure of the system. In fact, a class is a description of a group of objects with the same attributes, operations, relationships, and semantics. One of the most important details when describing the attributes and operations of a class is its visibility.

Classes can be connected in various forms, such as association, generalization, dependency, and implementation. There are usually several class diagrams in a typical system. A class diagram does not necessarily contain all the classes in the system, a class can be added to several class diagrams.

Example class diagram:

(3) Object diagram: a diagram representing a group of objects and their relationships at a certain time. The object graph can be seen as an instance of the class graph at a certain moment in the system.

An object diagram is an instance of a class diagram, used to describe the relationship between a group of objects at a specific runtime. In other words, the object is used to describe the static part of the interaction, and it consists of related objects participating in the collaboration. It does not include any messages passed between objects.

When creating object graphs, modelers do not need to use a single object graph to describe every object in the system. In fact, most systems contain hundreds or thousands of objects. It is generally impractical to use objects to describe all the objects of the system and their relationships. Therefore, the modeler can choose the relationship between the object of interest and the description.

The symbols used in the object diagram are almost identical to the symbols used in the class diagram, the only difference is that the object name of the object diagram is underlined, and all instances of the relationship between the classes are drawn.

(4) Component diagram : Describes the relationship between software components and components. The component itself is a physical module of the code, and the component diagram shows the structure of the code.

Component diagram (component diagram) is used to describe the organization and dependencies between a set of components, and is used to model the static implementation view of the system. A component can be an executable assembly, library, table, file, document, etc. It contains logic class or logic class implementation information, so there is a mapping relationship between the structural model view and the implementation model view.

The construction diagram can also include packages or subsystems, which are used to form model elements into larger blocks.

Component legend:

(5) Configuration diagram : Describes the physical topology of the system hardware and the software executed on this structure. The configuration diagram can display the topology and communication paths of the computing nodes, the software components running on the nodes, and the logical units (objects, classes) contained in the software components. Configuration diagrams are often used to help understand distributed systems.

The configuration diagram (deployment diagram) is used to describe the configuration of the nodes that process the system operation and the components active on the nodes. The deployment diagram is used to model the environment model view of the system. In most cases, deployment diagrams are used to describe the generalized structure of system hardware.

In UML, modelers can use class diagrams to describe the static structure of the system, sequence diagrams, collaboration diagrams, state diagrams, and activity diagrams to describe the dynamic behavior of the system, and deployment diagrams to describe what the software needs to execute. The topology of processors and devices.

(6) State diagram: establish a model through the life cycle of class objects to describe the dynamic behavior of objects over time.

A state diagram is actually a state machine composed of states, transitions, events, and activities. The state diagram describes the control flow from state to state, and is often used to model the dynamic characteristics of the system. In most cases, it is used to model the behavior of reactive objects.

In UML, state diagrams can be used to model the behavior of an object sorted by events. A state diagram is a simple representation of a state machine that emphasizes the control flow from state to state. Generally speaking, the state diagram is a supplementary description of the facilities described by the class. It describes the state that all objects of the class may have and the events that cause the state to change.

(7) Sequence diagram: The interaction diagram describes an interaction, which is composed of a group of objects and their relationships, and also includes the information passed between the objects. Interaction diagrams express the interaction between objects, and are modelling tools that describe how a group of objects cooperate to complete a certain behavior.

Sequence diagrams and collaboration diagrams are collectively called interaction diagrams. Among them, the sequence diagram is used to describe the order in which messages are sent between objects, to clarify the interaction process between objects and what events will occur at a specific moment during the execution of the system. A sequence diagram is an interactive diagram that emphasizes chronological order, in which objects are arranged along the horizontal axis and messages are arranged along the vertical axis.

The lifeline of an object in a sequence diagram is a vertical dashed line, which indicates that an object exists within a period of time. Since most objects in the sequence diagram exist during the entire interaction process, these objects are all arranged at the top of the diagram, and their lifelines are drawn from the top of the diagram to the bottom of the diagram. There is a rectangular bar below each object, which overlaps the lifeline of the object, and it represents the control focus of the object. Messages in sequence diagrams can have sequence numbers, but since messages on such diagrams have been sorted chronologically from the vertical axis, the message sequence numbers are usually omitted.

(8) Collaboration diagram: contains class meta roles and associated roles, not just class meta roles and associations. The collaboration diagram emphasizes the organization of the objects participating in the interaction. Collaboration diagrams only model objects that interact with each other and the relationships between these objects, while ignoring other objects and associations. The collaboration diagram is also an interaction diagram, which emphasizes the organizational structure of the objects that send and receive messages.

Collaboration diagrams and sequence diagrams are collaborative, they can be converted to each other. In most cases, collaboration diagrams mainly model monotonous, sequential control flows, but it can also be used to model complex control flows including iterations and branches.

In general, modelers can create multiple collaboration diagrams, some of which are primary and others are alternative paths or abnormal conditions. Modelers can use packages to organize these collaborative diagrams and give each diagram a proper name to distinguish it from other diagrams.

(9) Activity diagram: It is used to show the activities or actions of the participating behaviors.

Activity diagrams are a special case of state diagrams, where almost all or most of the states are active, and almost all or most of the changes are triggered by the completion of activities in the source state. An activity diagram is essentially a flow chart that describes the flow of control from activity to activity.

You can think of the activity diagram as a new kind of interaction diagram, but the interaction diagram observes the objects passing the message, while the activity diagram observes the messages transmitted between the objects. Although the semantic difference between the two is subtle, they use different ways to look at the system.