One, foreword

When it comes to the analysis and design of object-oriented technology, UML is indispensable. Many of my programmer friends are familiar with the concept of UML and use it in their work, but some of my programmer friends are actually not good at using UML or even have some ambiguity about it, including myself. Therefore, I hope to combine my own experience and practice, write a UML introduction article, to help object-oriented programmer friends can better use it, so as to successfully complete their own programming design work.

The following is an outline of the paper.

Start with an example

Let’s start with a real-world example. When we went to college, as students, each of us had a student ID card, we were assigned to a class, and we might use bicycles to go to school. Many students also take their driver’s licenses and practice driving, whether in a car or a pickup truck, during their holidays.

If you want to record the above information and behavior online, how to express it in the software world?

I believe that the operation of many friends is to find the subject and object in this paragraph, and also find the roles involved in this example, and then judge the relationship and ability between each role through the verb, and finally express it in the way of code to produce executable programs.

Identify the key entities and their relationships as shown in the figure below.

Using software engineering to solve problems in reality is the most obvious feature of the information age, which makes our life and work more convenient.

But the real world is complex and flexible, and everyone’s interpretation may be different, making mapping from the real world to the software world difficult and messy.

How to make the mapping from the real world to the software world simple and easy is the problem that UML is trying to solve.

What is UML?

UML stands for Unified Modeling Language (UML), which describes software concepts graphically.

3.1 Why is it called language

Let’s start with language. Why is it called language?

The foothold of a name is language. Since it is a language, it will have the characteristics of a language, such as structurally it is composed of vocabulary and grammar, and functionally it can solve communication problems.

Most of the languages you are familiar with are Chinese and English, and if you are in the software industry, C and Java languages are also familiar to you. English and Java are both obviously languages, but they are often not discussed together. Why? Because they are languages of different dimensions. English is a human language to solve the problem of communication between people in the real world, while Java is a computer language to solve the problem of communication between programmers and computers in the software world.

Human language is essentially a representation of facts and opinions; computer language is essentially a representation of zeros and ones. The expression form of the former is difficult to determine, and may produce ambiguity, so there will be the view of “being misunderstood is the fate of the expresser”, but the latter is the deterministic and unambiguous expression of 0 1.

In this way, THE goal of UML is to solve the problem of communication from the real world to the software world through a structural expression.

3.2 What is Modeling

Now modeling, what is a model, how do you build it?

Modeling simply means solving a domain problem in an abstract way. Together, these abstract perspectives form a problem domain.

For traditional models, it’s built to prove that something in the problem domain works. The premise, of course, is that the cost of building a model is much lower than the cost of building the actual thing. Like building airplanes or tall buildings.

For software models, it is built to communicate with others and to preserve the final product of software design in this problem domain. It also assumes, of course, that the model speaks louder than the code.

For example, when it comes to shopping, a can buy clothes on Taobao, B can buy books on Amazon and C can buy mobile phones on JINGdong.

Who does the shopping? Is a, B and C, they can abstract the human.

What do you want to buy? There are clothes, books and mobile phones, which can all be abstracted into goods.

Where can I buy it? On Taobao, Amazon and JD.com, they can all be abstracted into a marketplace.

The whole abstraction is that people go to the shop. Therefore, the shopping scene of the abstract out of the people’s goods yard, used to solve the problem of the retail field. Of course, there may be some rules, such as becoming a registered member in order to trade.

We will find that in a specific event (such as shopping), there will be specific behaviors of people (such as a, B and C going on the e-commerce website), specific things (such as goods) and specific rules (such as membership registration) to complete the shopping together.

A specific thing = a specific person's behavior + a specific thing + a specific ruleCopy the code

In the abstract perspective of people goods yard, many specific things will be involved, including member registration, member ordering, member payment, merchant shipping, express company mailing and so on.

In simple terms, it is people, things, things and rules.

People are the center of everything, people have to do things, things will use some things and produce other things, at the same time, things need to follow certain rules.

People drive systems, things embody processes, things record results, and rules are controls.

The key to establishing a model is to understand who there is, what people do what things, what things produce what rules, and then define the relationship between people, things and things, so that a model can be basically formed.

3.3 What is the significance of unification

The universal meaning of unity is to form standards. A standard is a statement that everyone understands and a format that everyone follows. Standards allow information to flow freely among people, even if it comes from different regions, cultures, societies or organizations.

For example, the United States dollar, as an internationally unified currency, facilitates global economic and trade, and the popularization of Mandarin in China facilitates communication between different regions.

In the software world, there is a standard behind any componentized development pattern, such as the JSR standard for Java. With standards, programming is easier to componentize and collaboration is much more efficient. For UML, this is what unity means.

Why is UML needed

A software project should go through business research, project approval, demand collection, architecture design, coding development and testing and verification.

Each link may have different roles, and the more backward the same document and the same words are passed, the more likely they are to be distorted. It’s easy to end up with a product that isn’t really what the customer wants.

How to avoid the distortion of information transfer between roles and ensure that information can be accurately conveyed and understood? A good way is for people to use standardized language.

The Unified Modeling Language (UML) tries to cover the entire software process with a standardized language so that different teams and different roles can communicate in the same language.

In the dissemination of information, graphics relative to text, the ability to accept the human brain is obviously stronger. Therefore, UML uses a “visual” graphical approach to defining languages.

Fifth, the application scenario of UML

UML can describe either a problem domain, a software design in mind, or a completed software implementation.

It applies to the whole process of object-oriented analysis and design. This process can be divided into three stages, as shown below.

The first stage is to turn the real world into a business model through modeling. Business models truly map the real-world behavior of actors (the drivers of business activities).

As you can see from the figure, the real world is mapped to the business model using actors and use cases, two core elements of UML. An actor is the driver of a particular event, and a use case describes the business goals of that driver. These two elements will also be mentioned later in this article.

The second stage is to conceptualize the business model and build a model suitable for computer understanding and implementation, which is the conceptual model, or analysis model. The analysis model is a transitional model that maps the original requirements upwards and provides a high level of abstraction for computer implementation downwards.

Real-world businesses are described in terms of boundaries, controls, and entities, and packaged in terms of packages and components that have nothing to do with the real world.

The third stage is to instantiate the conceptual model to obtain a relatively detailed design model.

In the design model, the boundary class in the conceptual model can be transformed into operation interface or system interface. Control classes can be transformed into computing programs or control programs, such as workflow, algorithm body, etc. Entity classes can be transformed into database tables, XML documents, or other classes with persistence characteristics.

The same conceptual model can lead to different design models due to different choices. For example, using different programming languages in technology selection, different middleware will get different designs.

Why is this conversion necessary?

Because objectification concepts like “boundaries”, “controls”, and “entities”, while understood by computers, are not real object instances, that is, they are not executable code, and conceptual models are just words on paper. The real object world behavior is made up of executable code such as Java classes, C++ classes, JSP, and so on.

In other words, a design model is an instantiation of a conceptual model under specific circumstances and conditions, and the behavior of the instantiated object implements the information described by the conceptual model.

The following is the complete process of object-oriented analysis and design, which shows how the real world is mapped to the object world through UML.

Sixth, the composition structure of UML

The orientation and application scenarios of UML are analyzed in a large part in order to help readers establish a systematic understanding of UML, rather than falling into the details of UML usage. When we apply a technology or tool, we should not use it simply because it is cool or it is widely used in the industry. Instead, we should confirm whether this technology or tool is what we need based on our own application scenarios and characteristics of the technology or tool.

After the reader understands the great features of UML in the area of object-oriented analysis and design, let’s look at some of the details of UML.

In every language, there is a basic vocabulary and grammar.

In UML, the basic vocabulary is the core element, and the syntax is the core view.

The composition structure of UML is as follows:

6.1 Core Elements

Let’s start with the core elements. Here’s an outline.

6.1.1 version

Plate type: also called “type” or “stereotype”. Is an extension of the UML element base definition, giving specific meaning to the element to make it suitable for specific situations.

For example, the “boundary class”, “entity class”, and “control class” we mentioned earlier are all versions of classes.

6.1.2 the participants’

Actor positioning: The first driver of events and the server of the system. If you’re shopping on an e-commerce site, you’re a participant.

Also 6.1.3 cases

Use case localization: A series of actions performed by the system that generate values that actors can observe. For example, if you are trading on an e-commerce site and an online order is generated, a user order is a use case.

Use case version:

• Business Use cases: For requirements phase business domain modeling. It has nothing to do with computer system modeling. For example, orders can be signed offline without relying on online services. The goal of business modeling is to get the demander and the customer on the same page.
• Business Use Case realization: An implementation of a business use case. A business use case can have multiple implementations. For example, payment after placing an order can be made by cash, bank card transfer or third-party payment.

• Conceptual use cases: Used to capture key concepts in the business model and analyze the core business structure. Business architecture is generated during the conceptual modeling phase and provides important guidance for the system modeling phase. The use case of placing an order, for example, takes some core business from the implementation and presents it.

• System use cases: Used to define system scope and capture functional requirements. That’s the use case we talk about all the time. Offline contracting, as mentioned in the business use case, is not included in the system use case, but electronic contracting can be included in the system use case.
• System use case realization: an implementation of a system use case. A system use case can have multiple implementations. For example, payment after placing an order can be connected to wechat payment interface or Alipay payment interface.

As you can see, the difference between a business use case and a system use case is that the business case is the customer business perspective and the system case is the system perspective.

6.1.4 boundary

Boundary location: Used for analysis in the business modeling and system modeling phases to ensure that the granularity of analysis is within a certain range and does not diffuse.

For example, an e-commerce website will have shop domain, commodity domain, membership domain, exchange domain, payment domain and marketing domain according to the domain responsibilities as the boundary. Each domain is only responsible for its own affairs, thus reducing the chaos of tightly coupled situations.

A good analysis and design is like a basket of eggs in the shell. A bad design is like a sticky pile of eggs with broken shells. Shell, is the key to good or bad.

6.1.5 Business Entities

Business entity positioning: It represents what participants deal with or use when executing business use cases, specifically for establishing domain models during the business modeling phase. A business entity is a version of a class.

Structure of business entities: contains properties and methods. Properties are used to hold business entity characteristics, and methods are used to access business entities. For example, if you look at a TV as a business entity, its properties are operating state and volume, and its method is the remote control. We can turn the sound on, off, and adjust it, but we can’t try to make it fly — it doesn’t have such a method.

6.1.6 package

Package localization: Holds and categorizes other UML elements. For example, the Java back end often provides JAR packages for access parties to use.

6.1.7 analysis classes

Analysis class orientation: Used to represent the major responsibility clusters in the system, resulting in the design classes and subsystems of the system.

• Boundary classes: Used to model the interaction between the external environment and the internal workings of the system. Windows in the real world, web pages in the computer world.
• Control classes: Used to model control behavior specific to use cases. Such as an MVC architecture where display logic and business logic are separated through the control layer.
• Entity classes: Used to model the information and related behavior that needs to be stored. Derived from business entities in the business model.

Analysis classes have a higher level of abstraction and are much more stable than design and implementation, so they are easier to maintain and have a stable architecture to guide overall software development.

6.1.8 design class

Design class localization: Is an abstraction of one or more objects in the implementation of the system, from which it maps to the implementation code, depending on the implementation language.

Design class structure:

• Type: A generalization or abstraction of a particular aspect of an object. Map to class in the code.
• Properties: Object characteristics. Map to the field in the code.
• Method: The only way to access an object’s properties. Map to method in the code.

6.1.9 relationship

Relational localization: Abstracting the relationships between objects so that they form a particular structure.

Relationships are classified as follows:

• Association
  • Relationship: is an ownership relationship, that is, one class knows the properties and methods of another class; For example, teachers and students can be two-way or one-way. A two-way association can have two arrows or no arrows, and a one-way association has one arrow.
  • Arrows and cords: Solid lines with regular arrows pointing to the possessor.
  • Application scenario: Class diagram.
• Dependency
  • Relationship: a relationship of use, that is, the implementation of one class needs the assistance of another class, is a weak relationship, which varies with the running scenario. For example, when peeling an apple, people rely on the knife. Without this scene, the dependency relationship does not exist.
  • Arrows and lines: Dotted lines with arrows pointing to the user.
  • Application scenario: Class diagram.
• Generalization.
  • Relationship: an inherited relationship. For example, a cat is a kind of animal.
  • Arrows and lines: Solid lines with trigonometry and arrows pointing to the parent class.
  • Application scenario: Class diagram.
• Realization
  • Relationship: Is an implementation relationship, such as the relationship between use cases and use case implementations, interfaces and implementation classes.
  • Arrows and wires: Dotted lines with triangles pointing to use case realizations or interface classes.
  • Application scenario: Use case diagram, class diagram.
• Aggregation
  • Relation: the relation between the whole and the parts, and the parts can exist independently of the whole. The life cycles are independent. If the car and the tire are polymeric, the tire can still exist without the car.
  • Arrows and lines: Solid lines with hollow diamonds pointing towards the whole.
  • Application scenario: Class diagram.
• Composition
  • Relation: it is the relation between the whole and the parts, but the parts cannot exist without the whole. Same birth and same death. If the company and the department are a combination, there is no company, there is no department.
  • Arrows and wires: Solid line with solid (black solid: die together, conscience is black) diamond, diamond points to the whole.
  • Application scenario: Class diagram.

The difference between association and dependency:

• Association relation is static natural relation, dependence relation is dynamic temporary relation.

There are also relationships that are only used in use cases:

• Extends (extends)
  • Relationships: Used in the use case model to describe the insertion of an extension use case to an extension point in the base use case.
  • Arrows and lines: Dotted lines with arrows<<extends>>.
  • Features: Optional use cases.
• Include
  • Relationships: Used in the use-case model to describe the behavior segments that are inserted during the use-case instance execution of the base use case.
  • Arrows and lines: Dotted lines with arrows<<include>>.
  • Characteristics: Use cases are required.

6.1.10 components

Component location: A logical code module that implements a specific function. For example, in distributed application architecture, service objectives are divided into multiple functions, and each function is deployed independently as a component. These components can then be reused by other scenarios as well.

6.1.11 node

Node location: Represents the deployment unit of the application. For example, in a distributed application environment, there are many servers or devices, so nodes are required to reflect the physical deployment.

6.2 Core View

Earlier we introduced the core elements of UML, which are applied to each phase of object-oriented analysis and design, and it is their combination that forms the views in UML that ultimately guide software design.

Let’s talk about the structure view and behavior view in the core view. The following is an outline.

6.2.1 Structure View

Structural views are also called static views. Static views represent static things. It describes the static structure of things, not their dynamic behavior. The static views outlined here include use case diagrams, object diagrams, class diagrams, component diagrams, package diagrams, and deployment diagrams.

6.2.1.1 use case diagram

Use case diagrams contain three core elements: actors, use cases, and relationships. Different perspectives can lead to different use case views, which show the functional requirements of the system.

The so-called different perspectives can correspond to the three stages of object-oriented analysis and design.

• The business model building phase produces the business use case view.
• The conceptual model building stage produces the conceptual use case view.
• Build design model stage, produce system use case view.

In terms of the use case for borrowing books, the business use case view is as follows, which is entirely business from a computer system standpoint.

In the process of business use case analysis, we can decompose some key conceptual use cases and establish the relationship between them, as shown in the following figure (BU represents business use cases, cu represents conceptual use cases).

Once we have analyzed the business use cases, we can draw the system use case view. However, not all business use cases have corresponding system use cases, such as checking checking cards, which may be manual work, does not need to be included in the scope of system construction.

The following is a system use case view of borrowing books.

6.2.1.2 class diagram

Class diagrams are used to show classes in a system and their relationships to each other.

Class diagram modeling is commonly used in a process of progressively lowering and refining the level of abstraction from the concept level, to the description level, and finally to the implementation level.

The conceptual layer class diagram is located in the business modeling phase, which is represented by the core element of the business entity.

Below is the business entity diagram of online shopping.

Online shopping is mainly composed of commodities, orders and payment accounts. The interaction of these several categories can accomplish the business goal of online shopping.

The illustration class diagram is located in the conceptual modeling phase, which is represented by the core element of the analysis class.

The diagram below shows the illustration class diagram of online shopping. This class diagram expresses which classes accomplish the business goal of online shopping from the perspective of computers. The interfaces of these classes ensure the achievement of the business goal.

The implementation layer class diagram is located in the design modeling phase, which is represented by the core element of the design class.

At this level, the class diagram is visible as pseudocode, so at this level, the class must specify which implementation language, design patterns, communication standards, specifications to follow, and so on.

The following figure shows the class diagram for querying product functionality. As you can see, by the implementation layer class diagram, class descriptions and class relationships are at the pseudo-code level.

It can be seen that in different stages of software life cycle, class diagram also has three different expressions, they are concept layer class diagram, illustration layer class diagram and implementation layer class diagram.

Many people only use the implementation layer class diagram when modeling, not because they know enough about the problem domain, but because they don’t know that the class diagram has three layers.

6.2.1.3 object graph

An object diagram is an instance of a class diagram, and the identity is essentially the same as the class diagram. Because objects have a life cycle, an object graph can only exist at a certain time in the system, so it can be thought of as a snapshot of a running system at a certain point in time.

For example, if you describe a moving train using an object graph, you will find the following static image at some point in time:

• Current operating status (running or stopping)
• Current number of passengers. (This value will change if captured at different times)

6.2.1.4 package diagram

In a real project, the modeling process might have a very large number of elements, and if the relationships of these elements were plotted out, it would look very messy, complicated, and difficult to identify.

To better understand and manage these modeling elements, we need to organize them on a regular basis. The package diagram serves as a container through which modeling elements can be organized from large to small and from coarse to fine for analysis, communication, and refinement.

Below is the Domain package diagram for online shopping, which represents the key business areas and their dependencies.

The following figure shows the class hierarchy of query commodity functionality, which expresses a view of the software architecture that implements the class at which level.

6.2.1.5 component diagram

When a package can be reused in multiple scenarios, it can be considered to have a specific function and accomplish a specific goal.

In this case, a package can be defined as a component, which is a special package that both organizes and accommodates ordinary packages and performs specific functions.

Such as modules (login modules), class libraries (Java Guava package).

The following diagram illustrates the process of component implementation, which can be defined by third-party software or various packages generated during the object-oriented analysis and design process.

Components can be functionally categorized into modules, subsystems, libraries, executables, packages, and so on.

6.2.1.6 deployment diagram

Deployment diagrams describe the physical structure of the system runtime, including the distribution of hardware in the system and the specific way software is deployed to the hardware.

The deployment diagram is used in the design modeling phase and is drawn using two core elements, nodes and relationships. It is used in distributed application environments and multi-device application environments.

The figure above is a simple deployment diagram that shows how a client, such as a browser node, requests data to a Web server node and returns data through a database server node. If a distributed environment is involved, multiple Web servers, multiple Database servers, and even multiple computer rooms, remote and other physical layer deployment modes should be considered.

6.2.2 Behavior View

With the structural view, let’s talk about the behavioral view.

Behavioral views are also called dynamic views. Dynamic views describe the dynamic behavior of things. Dynamic views cannot stand on their own; they must be based on a static view or UML element that explains their dynamic behavior within the structure of things specified by the static view.

Dynamic views briefly described here include state diagrams, activity diagrams, sequence diagrams, and collaboration diagrams.

6.2.2.1 state diagram

A state diagram, also known as a state machine, describes the life cycle of an object. You can think of it as a running machine that is responsible for the flow of the object between fixed states.

This object can be a business entity object, an analysis object, or a design object. In other words, the three phases of object-oriented analysis and design (business modeling, conceptual modeling, and design modeling) can all be represented by state diagrams.

The following diagram shows the life cycle state of a product. The green parts are the elements associated with the state diagram, and the red parts are the explanations of the elements.

From the figure, we can see that the state diagram has the following key elements:

1. Initial state: It is the starting position of the state machine and does not require an event to be triggered. It’s a solid circle.
2. State: A state is a condition in which an object performs an activity or waits for an event. For example, in order to perform an action for a product to be in storage, the product has to be in storage if you want to sell a product.
3. Transition: A transition is a relationship between two states that indicates that when a specified event occurs and a specified condition is met, an object in the first state will perform some action and enter the second state. For example, the action of storing a product changes the state of the product from unstored to stored.
4. Event: An event is a specific action or behavior, sometimes including timers such as the system clock. If the condition is met, the occurrence of the event triggers a transition. For example, when a product is sold, the product is moved from the in-store state to the sold state.
5. Condition: A condition is a Boolean expression whose value is checked when an event occurs. The result of the conditional evaluation may determine the branch of the transfer or reject the transfer. Conditions may refer to the current state. For example, whether a product is acceptable or not is a Boolean judgment that determines whether a product can be sold or not.
6. Final state: The final state indicates the end of the state machine execution or the end of the object life cycle. Represented by a solid circle with a ring.

6.2.2.2 activity diagram

An activity diagram describes the activities that need to be done in order to accomplish a goal and the order in which those activities are performed.

There are two layers of activity diagrams in UML: use case activity diagrams, which describe use case scenarios and are often used in the business modeling phase, and object activity diagrams, which describe object interactions and are often used in the design modeling phase.

The following is an activity diagram of a use case for check-in. The green parts are the elements associated with the activity diagram, and the red parts are the explanations of the elements.

From the figure, we can see that the activity diagram has the following key elements:

• Start point: The start point marks the beginning of a business process. There is only one activity diagram. It’s a solid circle.
• Activity: An activity is an execution unit in a business process. Such as showing your ticket and ID card to check in.
• Judgement: Judgement makes decisions based on a condition and executes different branches of the process. For example, identity checks determine whether you can continue to check in.
• Base flow: A base flow represents the primary, most frequently used, and default branch of a business process. Like the normal branch of identity checking.
• Tributaries: A tributary is a branch of a business process that you walk into after making a judgment. For example, there is no baggage branch.
• Exception flows: Exception flows represent branches of business processes that are abnormal, not expected by business goals, fault tolerant, and handle unexpected situations. For example, id check errors.
• Synchronization: Synchronization is divided intoSynchronous initiation and synchronous convergence.
  • Synchronous start indicates that multiple tributaries are executed in parallel from its start. The processing of checked baggage and the printing of boarding passes, for example, can be done in parallel.
  • Synchronous confluence means that multiple tributaries arrive at the same time before carrying out follow-up activities.
• End point: The end point represents the termination of a business process. One or more.

Use-case activity diagrams often analyze from a business perspective what activities need to be performed to achieve a certain goal. If from the perspective of system design, to express the activities needed to achieve the goal, we need to use object activity diagram.

For example, based on the object interaction process of querying goods, the following object activity diagram can be drawn.

Although UML allows activity diagrams to plot object interactions, I’ve never used them in my actual work. Because UML has other, better tools for drawing object interaction diagrams, such as sequence diagrams, which we’ll cover next.

6.2.2.3 sequence diagram

Sequence diagrams are used to describe the interaction patterns between objects arranged in chronological order.

As mentioned in the previous class diagram section, classes have three levels of perspective: Concept layer, description layer and implementation layer, respectively corresponding to the object-oriented analysis and design of business modeling stage, stage of concept modeling and design modeling phase, accordingly, also can respectively on the three levels of the business entity object class object, analysis and design class object sequence diagram drawing business model, the conceptual model, sequence diagram and sequence diagram design model.

Here are three types of sequence diagrams.

Business model sequence diagrams are used to model business entity interactions in the domain model with the goal of realizing business use cases.

The activity diagram mentioned in the previous section can help us discover business entities, and it can also be easily converted into a sequence diagram. The following is a sequence diagram of the business model for online purchase of goods.

Several UML elements are involved in sequence diagrams. Here are some common ones:

• Object: Represents the object that participates in the interaction. Each object has a lifecycle line, and when an object is activated, a long bar (session) appears on the lifecycle line to indicate the existence of the object.
• Lifecycle line: Indicates the existence of an object. When an object is activated, a session appears on the lifecycle line, indicating that the object participates in the session.
• Message: indicatesThe actions that occur in the interaction between objects. The lifecycle line of one object points to the lifecycle line of another. There are several common message types:
  • Simple message: solid right arrow, most commonly used.
  • Return message: The return body of the source message, not the new message. Represented by a one-way dotted arrow to the left. It is not generally necessary to draw a return message for every source message, on the one hand, the source message has a return message by default, on the other hand, too many return messages can complicate the diagram.
  • Synchronous message: Indicates that the object that sent the message will stop all subsequent actions until the receiver responds. Indicated by a one-way solid line arrow with an x to the right. Synchronizing messages blocks all behavior of the source message. Usually method calls between programs are synchronous messages.
  • Asynchronous message: Indicates that the source message sends a message without waiting for a response and can continue to perform other operations. Indicated by a one-way upward arrow to the right. Asynchronous messages generally require the support of messaging middleware, such as MQ.
• Session: Represents an interaction in which all objects share a context. For example, operation context.
• Destruction: Indicates the end of the life cycle. Drawn at the end of the lifecycle line, it is generally not necessary to emphasize.

The business model sequence diagram is the product of the business modeling phase and represents the actual requirements of the business, so the description language used should be in business terms.

In the conceptual modeling stage, analysis class can be used to draw the sequence diagram of the conceptual model. Compared with the sequence diagram of the business model, the sequence diagram also shows the business requirements. The difference is that the analysis class represents the prototype of the system, so the sequence diagram at this stage already has the understanding of the computer level.

Thus, the conceptual model sequence diagram not only preserves the actual business requirements, but also obtains the basic idea of computer implementation. As shown in the figure below.

As you can see, in the conceptual model sequence diagram, we have added security certification and merchandise catalog to our expression relative to the business model sequence diagram. This is because when we actually do the login function, our software system needs to care about identity verification. When we acquire goods, we need to classify them in order to avoid clutter.

In addition, our business entities are turned into analysis classes for presentation, and the website is used as a boundary class to separate user operations from system behavior. As a control class, security authentication is used to determine whether a website can be successfully logged in. As entity classes, catalogs and commodities are used to express the entity information that users actually want to see or operate.

The analysis class has shown the prototype of the system implementation, into the design modeling stage, we do work is to choose the appropriate implementation way to achieve the prototype.

In the design modeling stage, we use the sequence diagram of the design model to realize the interaction in the conceptual model.

Design model sequence diagram, which uses design classes as objects, is also the most commonly used dynamic view in our daily development and design. The following is a sequence diagram of the design model for the product query.

As you can see, messages are detailed down to the method level in the design model sequence diagram. At this stage, the relevant technology selection, such as programming language, interaction protocol, middleware, etc., has been relatively clear.

In addition to being used in the three phases of modeling, sequence diagrams can be used when you need to express the interaction of objects, or when you want to analyze the responsibilities and interfaces of objects.

6.2.2.4 collaboration diagrams

Like sequence diagrams, collaboration diagrams also describe the interaction patterns between objects. The difference is that sequence diagrams focus on the execution sequence of object interactions, while collaboration diagrams focus on the structural relations between objects.

Thus, sequence diagrams are useful for gaining an understanding of the invocation process, while collaboration diagrams are useful for gaining an understanding of the object structure.

Collaboration diagrams can be converted to sequence diagrams, corresponding to three expressions of sequence diagrams. Collaboration diagrams can also be divided into business model collaboration diagrams, conceptual model collaboration diagrams and design model sequence diagrams. This article covers only business model collaboration diagrams; the other two collaboration diagrams, which can be derived from the corresponding sequence diagrams, are not covered here.

Business model collaboration diagrams are also drawn using business entities and are also aimed at realizing use case scenarios. Below is a business model collaboration diagram for purchasing goods online.

As you can see, the structure between objects in collaboration diagrams is straightforward compared to sequence diagrams, making it easy to know which messages affect which objects or which objects need to provide which interfaces. But the execution order is weak and must rely on numbers in the message text.

The following are common UML elements for collaboration diagrams:

• Object: Represents the object participating in the collaboration.
• Object association: Used to connect two objects and represent their association. This association is temporary and only valid for this interaction.
• Message: As defined in the sequence diagram.
  • Message sequence number: Indicates the order in which the message is delivered.

6.2.3 summary

This section introduces the core view of UML, so let’s take a look at the outline of the core view.

The core view is divided into static view and dynamic view. The static view expresses the structural view of things, and the dynamic view expresses the behavioral view of things.

A good model is both structural and behavioral, explaining both what something looks like and how it should be used.

Seven,

This article starts with an example, introduces UML concepts, explains what IT is, why it is used, and when it is used. When we know something, we need to know why we know it.

Then it introduces the composition structure of UML, and explains the method of drawing graphics and related concepts from the point of view of elements and views. There are also a lot of sample views that I drew by hand, and I’m looking forward to your criticism if there are any mistakes.

The paper come zhongjue shallow, and must know this to practice. There is always a distance between knowing and doing, but practice is the key.

Hope this article is engaged in object oriented programming reader friends can be inspired, welcome to communicate with me, also welcome to forward to have the need of friends.

(after)