Introduction to the various views of UML

There are no obvious conceptual differences between the various views in UML, the views are broadly divided into three categories: structural classification, dynamic behavior, and model Management.

The structure classification mainly describes the structure members and their interrelation in the system. A class element includes classes, use cases, artifacts, and nodes. The class element lays the foundation for studying the dynamic behavior of the system. A class meta view includes a static view, a use case view, and an implementation view.

Dynamic Behavior describes the behavior of the system over time. Behavior is described by changing the instantaneous value of a system extracted from a static view. Dynamic behavior views include state machine views, active views, and interactive views.

Model Management illustrates the hierarchical organizational structure of the model. A package is the basic organizational unit of a model. Special packages also include models and subsystems. The Model Management view spans other views and organizes these views according to the development and configuration of the system.

In addition, UML has a number of extensible components, which are limited but useful. These components include constraints, stereotypes, and tagged values that apply to all views.

Here is a table of instructions, as a guide:

One, static view

It models internal concepts related to concepts and system implementations in the field of application. It is called a static view because it does not describe the system behavior associated with time. Static views are composed primarily of classes and the relationships between classes, including associations, generalizations, and dependencies, and how to use and implement relationships. A class is a description of the concepts in the application domain or application solution. Class diagrams are organized in a class-centric, other element in a class diagram or belonging to a class or associated with a class. A static view is implemented with a class diagram, which is called a class diagram because he is centered on the class. Here is an example of a class diagram:

Privately think this picture is very complicated, especially do not know this picture is used for what time!

Two: Use Case view

The use Case view is referred to as a system functional model diagram that can be observed by external users of the actor. A use case is a functional unit in a system that can be described as an interaction between the participant and the system. The use case model is used to list the system's use cases and contributors, and shows which participant participates in which use case is executed. Here is an example of a use case view:

Personal point of view, this figure is silly, but it is still very interesting, at least to show the normal development of the activities of the various participants.

Three: Interactive view

The interactive view describes the sequential relationship between the various roles that perform system functions. The interactive view displays a system control process that spans multiple objects. Interactive views can be represented in two views: sequence diagrams and collaboration diagrams, each with a different focus.

1: Sequence diagram

A sequence diagram describes the process of a transaction, which is the same as the order structure in process-oriented programming, from top to bottom. Here is a legend:

This picture reminds me of a long time ago without Ajax when the network services, is always using synchronous way to operate, unbearable!

2: Collaboration diagram

A collaboration diagram is a model of the chain between objects and objects that make sense in a single interaction, with objects and relationships only meaningful in the context of the interaction. A collaboration diagram uses geometric permutations to represent the roles in the interaction. Arrows attached to a class meta role represent messages, and the order in which they occur is represented by a numbered number. Here is a collaboration diagram example:

This figure has a feature, unlike the sequence diagram, which shows the parameters, method names, not based on time series, are based on logical sequences.

Four: State machine view

A state machine view is a model diagram of all the processes that a class object may experience. A state machine consists of the individual states of an object and the transitions that connect those states. Each State models a period of time when an object satisfies a certain condition in its life cycle. A transition that triggers a state when an event occurs, from one state to another. Here is a legend:

This state machine I think it is best to refer to the state pattern inside the design pattern, the implementation of the state pattern is the code description of this state diagram.

V: active view

The active view is a variant of the state machine that describes the activities involved in the workflow that executes the algorithm. The activity status represents an activity: a workflow execution step or an action execution. An activity diagram describes a set of sequential or concurrent activities. Activity views are represented by activities. Here is a legend:

This and the state machine still has a big change, it is a linear execution step, state machine is a kind of ring trigger situation. State machines are complex in each case and have a certain trigger state in them. Activity diagrams may not have these, but realistic workflows.

VI: Physical View

The physical view is modeled on its own structure implementation, and the classes in the diagram map to nodes that are called physical structures. Physical views are divided into implementation views and deployment views. The implementation view models the components in the system, as well as the dependencies between the components, and the impact of the evaluation on the system by modifying the dependency relationship. Here is a legend for implementing the View:

This picture is very interesting, at first I thought it was a diagram like a circuit board. Next is a deployment diagram, looking closely at the difference:

VI: Model Management view

It is the modeling of the model's own organization. A model is a description of the integrity of a system from a point of view with a certain degree of precision. Here is a legend:

Such a system diagram looks very good, very easy to understand and accept.

VII: Extension components

A component exists as a model that provides specific functionality, including constraints, stereotypes, and tagged values. A constraint is a textual description of the semantic relationship expressed in a formal language or natural language. Stereotypes are new model elements designed by modelers, but they are based on existing UML models. The tag value is a named block of information that is attached to any model element. Here is an example diagram:

VIII: Relationships between various views

IX: Personal learning experience sharing

Some things are very simple, the key is that there is no motivation to learn, without the direction of their own progress. I have always felt that the easiest thing to recite is the simplest, and the hardest to understand and introduce. Each time the innovation is the embodiment of their own ability to progress, or progress is too ordinary, not worth to cheer themselves. Learning, even if only because of the sentiment of a sentence, but also progress.

Introduction to the various views of UML