Unified Modeling Language

Unified Modeling Language

DDD Theory Learning Series--cases and catalogues

1. Introduction

The previous section explained the domain model, where the domain model was primarily to abstract the concepts involved in the business into object-oriented ideas, abstract entity objects, determine the corresponding methods and properties of entities, and the relationships between entities. The relationships between these entities and entities are then presented in some form (such as UML, graphics, code, text descriptions, and so on). And the domain model is the result of domain modeling, how to model it? We can take advantage of UML.

We know that UML (Unified Modeling Language) is a graphical symbol for drawing software concept diagrams. Diagrams are most effective in communicating with others and helping to solve design problem methods. In DDD we are accustomed to using UML for domain modeling, so for subsequent chapters we need and must be familiar with the use of common UML. Before also wrote an article, want to learn design patterns, you have to look at class diagram, a diagram read UML, introduced some basic usage, may wish to see.

Let's start with a brief introduction to the basic usage of several common UML.

2. Levels and categories of UML

In UML essence, UML is divided into three levels:

• Conceptual Level : A shorthand method for describing concepts and abstractions in problem areas, with no more restrictive semantic rules. And the source code is not very strong correlation.
• specification Level : A solution to depict the problem in order to be able to convert it into source code. Adhere to strict semantic rules.
• implementation level : Used to depict existing source code, such as class diagram. Adhere to strict semantic rules.

There are three main types of UML diagrams:

• static Diagram: Describes classes, objects, data structures, and their relationships, showing the immutable logical structure between software elements. Class diagrams, object graphs are static diagrams.
• dynamic diagram (DYNAMCI diagram): Shows how a software entity is transformed during operation, describing how the running process or entity changed state. Sequence diagrams, collaboration diagrams, and state diagrams are all state diagrams.
• physical diagram (physical diagram): Shows the physical structure of a software entity, describing physical entities such as source files, libraries, binaries, data files, and the relationships between them.

3. Case studies

In order to really have a visual understanding of UML, we also combine specific business scenarios (shopping cart) example analysis, the UML diagram design.

3.1. Class diagram

The class diagram mainly shows the main classes and relationships in the program.
Shopping cart mainly involves four objects: shopping cart, shopping car items, goods, categories.

In this diagram, all relationships are aggregation relationships.

3.2. Object graph

The object graph shows a set of objects and relationships at a particular point in time that the system executes, and can be seen as a memory snapshot.

This illustration shows that there are two items in the current shopping cart.

3.3. Sequence diagram

A sequence diagram is a dynamic model for clearly expressing the order of messages.

There are several illustrations to note:

• Dashed line: Lifeline.
• Narrow Bar Small Rectangle: Active, indicating the time the function was executed.
• Boolean expression in square brackets: guardianship condition.
• Small Circle Arrow: data marker

3.4. Collaboration diagram

Collaboration diagrams are designed to express the relationships between objects.

3.5. State diagram

The state diagram is to understand the transformation of the system's behavior and state.

The diagram briefly describes the state transitions between orders from normal, shipped, and closed.

4. Summary

This paper introduces several common UML usages through simple cases. Because of their own UML is not very understanding, to show that inevitably some flaws.

UML itself is a complex thing, it takes a lot of time and effort to fully master it. But we need to use it with less and better ideas when we are modeling. Do not pursue the details of the diagram too much, and the UML diagram is not the source code, there is no need to declare all methods, variables and relationships.
When learning UML, do not suggest to find some UML drawing tools, directly on the paper to write and draw on the good, all the illustrations of this article is directly in the draft design.

Finally, the most important thing is, please do the painting!

Unified Modeling Language