tags: UML
What is UML?
The full name of UML is: Unified Modeling Language, also known as Unified Modeling Language or standard Modeling Language.
Is a graphical language that supports modeling and software system development, providing modeling and visualization support for all phases of software development, from requirements analysis to specification to construction and configuration. It’s a language, and language is used to describe things.
Why do we use UML?
A look at the history of software development helps us understand why we use UML.
Software history is divided into three phases:
- Program design stage [1946 ~ 1955 hardware development, small scale, program design to save space and programming skills]
- Software design stage [From 1956 to 1970, hardware grew at a fast speed and cost performance became higher and higher, software development technology did not have a major breakthrough **, software products were of low quality and production efficiency, leading to the “software crisis” **]
- Software Engineering stage [from 1970 to present, a large number of requirements were put forward and the idea of engineering was adopted to manage software]
The goal of software engineering: use engineering methods. Under the premise of given cost and schedule, software with maintainability, correctness and portability is developed. Improve software product quality and development efficiency, reduce maintenance difficulties
As software engineering progressed, the IT community wanted to use a single language to describe the requirements and designs they accomplished, but different companies developed their own products.
As a result, the OMG, the ObjectManagementGroup, unified the language for describing requirements and design, known as UML.
That is, UML is used for design, requirements analysis.
Using IBM Rational
We use the IBM Rational tool to explain UML.
Generally, we use this tool to do three things:
- Use case diagram
- The class diagram
- Sequence diagram
Use case diagram
Use case diagrams show who will be users of the system, what services they want the system to provide, and what services the system can provide to users. Describe system functions from the user’s point of view. Use case diagrams are most commonly used to describe systems and subsystems
Two elements and four relationships in the use case diagram
- Actors (Actor)
- Use Cases
- Association
- Include relationships
- Extended relationships (Extend)
- Generalization relation
We use it to simulate a use case diagram for a mall
The message we want to describe looks like this:
- Visitors have browsing commodities, login and registration functions
- Members have all the functions of tourists, as well as the functions of shopping and managing personal information
- In the shopping, including the purchase of goods, add to the shopping cart, pay so several functions
- And payment has payment on delivery, online payment, other payment so several payment functions
- An order is generated regardless of the payment
- Orders are managed by customer service, which also has the function of commodity management
- Customer service has the function, the administrator has, the administrator also has the function of managing members.
The class diagram
Class diagrams are used to describe the relationships between classes in a system
The class diagram has the following relationships:
- Inheritance: Parent-child relationship
- Implementation: Class and interface relationships
- Associations (global variables, combinations/aggregates): values, references
- The combination is strong
- Aggregation is not so strong.
- Associations are navigational: that is, bidirectional or unidirectional relationships
- Dependencies: Local variables (not Spring dependency injection)
- Local variables in a method
Sequence diagram
When a use case is needed, we can drag it over to the sequence diagram.
If you find this article helpful, give the author a little encouragement