UML Learning Summary

the 4+1 model in UML

UML's 4+1 model was invented by someone named Kruchten, but there are other versions of the 4+1 model on the Web: use case view, Logic view, Process view, Impementation View and Deployment view.

Logic View: Abstract Description of the various components of the system, focusing on how the system is composed and how the various parts of the system interact. Our commonly used Class View (class Digram), object graph (diagram), sequence diagram ( sequence diagram)/ communication diagram (communication diagram) all belong to Logic View.
Process View: describes the various activities in the system, the typical view being the activity diagram. The activity diagram and flowchart are considered very similar and are intended to describe the activities in the system clearly.
Development view: Describe the composition of a system from a developer's perspective, a typical view of a component view (component diagram)
Physical Views: This view focuses on the top structure of software artifacts on hardware and the communication between components. A typical view is a deployment view (deployment diagram)
use Case view: A description of the system use cases, a typical view is a view of the usage cases diagram

UML models, views, graphs

the concepts and models of UML can be divided into the following conceptual domains: Static structure, dynamic behavior, implementation structure, model organization, extension mechanism
UML views and diagrams

Static view

1. class element

A class element is a discrete concept in a model that possesses identities, states, behaviors, and relationships. There are several kinds of elements including classes, interfaces, and data types. The other kinds of elements are the embodiment of the concept of behavior, environment and execution structure. These primitives include use cases, contributors, artifacts, nodes, and subsystems. The diagram lists several kinds of elements and their functions. All of these concepts are included in the meta-model term class element.

2, the relationship between the class element

The relationships between the classes are related, generalized, and various forms of dependency, including implementation relationships and usage relationships.

Associations: objects are typically associated with other objects, and associations can have multi-layered forms. Multiplicity problems (pair of one or one-to-many). The Association in UML is represented by a straight line.

Generalization: A class inherits the properties and operations of other classes. generalization in UML is represented by "drawing a line with a hollow triangular arrow from something like" to the parent class.

Dependency: One class uses another class. In UML, it is represented by a "dashed line from a dependent class to a dependent arrow".

Aggregation is one of the associations in which a clustered object consists of a subset of objects. That is, the whole is associated with the part. In UML, it is represented by a "wired connection between the whole and the part with a hollow diamond Arrow".

A combination is a special aggregation in which a part of an object can exist only as part of a combined object and a combined object. represented in UML with "wired connection between whole and part with a solid diamond arrow".

Implementation: The relationship between a class and an interface is called an implementation. The implementation of the relationship in UML is represented by a dashed arrow with a hollow triangle and an arrow pointing to the interface.

Types of relationships

Figure Example:

1. Association

2. Reliance

3. Qualifying the Association

4. Aggregation and composition

5. Generalization

6. Implementing the Relationship

Use Case view

When a use Case view appears before an external user, it captures the behavior of the system, subsystem, or class. It divides system functionality into useful requirements for participants ( that is, the ideal user of the system ) . The interactive feature section is called a use case. A use case uses a series of messages between the system and one or more actors to describe the interaction in the system. Participants can be people or external computer systems and external processes.

Relationship between use cases: association, extension, generalization, inclusion.

Figure Example:

1. use case diagram

2. Use case diagrams

Interactive view

The interactive view describes the sequential relationship between the various roles that perform system functions passing messages to each other. A class element is a description of an object that plays a particular role in the interaction within the system, which distinguishes it from other objects of the same kind. The interactive view shows a system control process that spans multiple objects. The interactive view can be represented by two diagrams: Sequence diagrams and collaboration diagrams, each with different emphases. The collaboration diagram also shows the interaction between objects, emphasizing the context of the interaction and the overall organization of the objects involved in the interaction. The collaboration diagram is organized by space (parallel), while the sequence diagram is in chronological order (serial).

1. sequence Diagram

2. Collaboration Diagram

State view

A state view is a model diagram of all the processes that a class object may experience. A state diagram consists of the individual states of an object and the transitions that connect those states. A state diagram is an "amplification" of a single object that describes the state changes that an object undergoes. Emphasizes the change of state within a single object.

Active view

An activity diagram is a variant of the state diagram that describes the activities involved in the workflow that executes the algorithm. An activity state represents an activity: the execution of a workflow step or an action. An activity diagram describes a set of sequential or concurrent activities. The activity view is represented by an activity diagram. The activity diagram is like a flowchart, which shows the work steps, points and branches. Can be used to express an object's operations and a business process.

Physical view

The physical view models the implementation structure of the application itself, such as the component organization of the system and the configuration established on the running node. Such views provide a mechanism for mapping classes in a system into physical artifacts and nodes. There are two kinds of physical views: A component diagram and a deployment view.

1. Component Diagram

2. Deployment Diagram

Model Management view

Model Management view models the model's own organization. A series of packages consisting of model elements such as classes, state machines, and use cases make up the model. A package may contain other packages, so the entire model can actually be seen as a root package that indirectly contains everything in the model. A package is a basic unit for manipulating model content, access control, and configuration control. Each model element is contained in a package or contained within another model element.

Extension mechanism

UML provides several extensibility mechanisms that allow modelers to do common extensions without changing the basic modeling language. These extensibility mechanisms have been designed so that they can be stored and used without the need to understand the full semantics. For this reason, the extension can be stored and used as a string. For tools that do not support the extension mechanism, the extension is just a string that can be imported, stored as part of the model, and can be passed to other tools. We expect backend tools to be designed to handle various extensions that define specific syntax and semantics for the extensions they need to understand. Extension mechanisms include constraints, tagged values, and stereotypes.

Constraints are semantic constraints expressed in literal expressions.

The tag value is a pair of strings-a token string and a value string-that stores some information about the element. Tag values can be related to any independent element, including model elements and expression elements. A tag is the name of some attribute that the modeler wants to record, and the value is the value of the attribute of the given element. For example, the tag can be author, and the value is the name of the person responsible for the element, such as Charles Babbage.

Tagged value

Stereotypes are a new model element that is constructed on the basis of a defined model element. The information content and form of stereotypes are the same as existing basic model elements, but they are different in meaning and usage. For example, modelers in the Business modeling field want to differentiate between business objects and business processes as special modeling elements that are used differently during a particular development process. They can be considered special classes-they have properties and operations, but they have special constraints on their relationship to other elements and their use.

Various chart summaries

UML Learning Summary