Analysis & Answer
Unified Modeling Language (UML) is also called standard Modeling Language.
UML defines 10 kinds of diagrams such as use case diagram, class diagram, object diagram, package diagram, state diagram, activity diagram, sequence diagram, communication diagram, component diagram, deployment diagram, etc. The red characters in the following figure are newly added to UML2.0.
Object-oriented dynamic modeling is used to establish four kinds of diagrams of behavior interaction between entities: Stage Diagram, Sequence Diagram, Communication Diagram and Activity Diagram. Sequence diagrams and collaboration diagrams represent similar messages, and activity diagrams are one type of state diagrams.
- Static Structure Diagram
Use case diagramUse Case Diagram
The class diagramClass Diagram
Package diagramPackage Diagram
Object graphObject Diagram - The Interaction Diagram
Sequence diagramSequence Diagram
Communication diagramsCommunication Diagram(UML1.0 is a collaboration diagram)
State diagramState chart Diagrams
Activity diagramsActivity Diagrams - Implementation Diagrams
Component diagramComponent Diagram
Deployment diagramDeployment Diagram
Use case diagram
Use Case Diagrams describe the impression of a system from the perspective of an external observer. Emphasize what the system is rather than how the system works.
Use case diagrams are closely related to the story. A scenario refers to the situation that occurs when an individual interacts with the system. The following is the scene of a hospital outpatient department.
“A patient calls the outpatient department to make an appointment for a yearly physical examination. The receptionist looks in the appointment book for the last unreserved time and makes a note of the appointment for that time.
A Use case is the sum of a series of plots to accomplish a job or a purpose. A role actor is the person or thing that initiates the event related to the work. A role simply acts as a person or object. The figure below is an outpatient Make Appointment use case. The character is the patient. The link between roles and use cases is communication communication Association (or simply communication communication)
A role is a human-like icon, a use case is an oval, and a communication is the line that connects the role to the use case.
A use-case diagram is a collection of roles, use cases, and the relationships between them. We’ve made Make Appointment as part of a diagram with four roles and four use cases. Note that a single use case can have multiple roles.
Use case diagrams are useful in three areas.
Determine characteristics (requirements). When the system has been analyzed and designed, new use cases create new requirements
Customer newsletter. Use case diagrams make it easy to represent the relationship between developer and customer.
Generate test cases. A plot of a use case may produce a batch of test cases for those plots.
The class diagram
The Class diagram represents a system by showing its classes and the relationships between these classes. Class diagrams are static – they show you what can have an impact but don’t tell you when.
Below is a class diagram of a model in which a customer orders an item from a retailer. The central class is Order. It is connected by the Customer and Payment that purchase the goods. Payment comes in three forms: Cash, Check, or Credit. The order includes OrderDetails (Line Item), each of which is attached to an item.
The notation for a UML class is a box divided into three blocks: class name, attribute, and operation. The names of abstract classes like Payment are italic. The relationships between classes are connections.
Class diagrams have three kinds of relationships.
Association – Represents the relationship between two types of instances. Use associations if an instance of a class must use an instance of another class to get its work done. In the figure, the association is represented by a line between two classes.
Aggregation – A special relationship when a class belongs to a container. Aggregation uses a line with a diamond that points to the class of wholeness. In our figure, Order is the container for OrderDetails.
Generalization – a generalization that refers to an inheritance line that refers to another class as a superclass. The generalization relation points to the superclass with a triangle. Payment is the superclass of Cash, Check, and Credit.
An association has two tails. Each tail can have a role name role name to indicate the role of the association. For example, an OrderDetail instance is an item of an Order instance.
The directional Navigability arrow on the association indicates the direction of the association delivery or query. The OrderDetail class can query its items, but not the other way around. The same arrow direction tells you which class has the implementation of the association; So OrderDetail has an Item. The association of non-directional arrows is bidirectional.
Multiplicity is expressed by the number at the end of the association representing the number of cells that an instance on the other side of the association can correspond to. A variety of numbers can be a single number or a range of numbers. In the example, each Order has only one Customer, but a Customer can have any number of orders.
The table below shows the most common examples of diversity.
Each class diagram includes class, association, and diversity representations. Directionality and roles are optional items to make the illustration clearer.
Package and object diagrams
To easily represent complex class diagrams, classes can be grouped into packages. A package is a collection of logically related components in UML. The figure below is a business model that combines classes into packages.
Dependencies. Package A depends on package B if A change in package B of another might cause A change in package A.
Packages are represented by a rectangle with a small label at the top. The package name is written on the label or inside the rectangle. Dotted line arrows indicate dependencies
Object Diagrams are used to represent instances of classes. They are useful in explaining the nuances of complex relationships, especially recursive ones.
This class illustrates how a university Department can include many other Departments.
This object represents an instance of the class diagram above. I used a lot of concrete examples.
Instance names are underlined in UML. Class or instance names can be omitted from the object diagram as long as the meaning is clear.
Each class diagram rectangle corresponds to a separate instance. The UML diagram highlighted in the instance name. The name of a class or instance may be omitted from the object diagram as long as the meaning of the diagram remains unambiguous.
Sequence diagram
Class diagrams and object diagrams are views of static models. Interaction diagrams are dynamic. They describe the interactions between objects.
A sequence diagram represents an interaction as a two-dimensional diagram. Vertically is the time axis, and time extends down a vertical line. The horizontal axis represents the class primitive roles of individual objects in the collaboration. Class meta-roles are represented by lifelines. When the object exists, the role is represented by a dotted line, and when the object’s process is active, the lifeline is a two-trace line.
Messages are represented by arrows from one object’s lifeline to another. Arrows are arranged chronologically from top to bottom in the figure.
Collaboration diagrams
Collaboration diagrams are also interactive diagrams. They convey the same information as sequence diagrams, but they do not care when the message is delivered, only the role of the object. In a sequence diagram, the role of the object is placed on top and the message is the connection line.
The object role rectangle is labeled with the class or object name (or both). The class name is preceded by a colon (:).
Each message in a collaboration diagram has a sequence number. The number of the top-level message is 1. Messages of the same rank (that is, messages in the same call) have the same numeric prefix, plus a suffix, 1,2, and so on, depending on the order in which they appear.
State diagram
Objects have behavior and state. The state of an object is determined by its current actions and conditions. The Statechart diagram shows the possible states of the object and the transitions caused by state changes.
Our model example diagram establishes an online login system for a bank. The login process includes entering a valid password and personal account and submitting the information to the system for verification.
Logging in to the system can be categorized as four non-overlapping states: Getting SSN, Getting PIN, Validating, and reality. Each state has a complete set of transitions to determine the order of states.
States are represented by rounded rectangles. Transitions are represented by lines with arrows. The event or condition that triggers the transition is written next to the arrow. We have two self-transfers on our diagram. One is Getting SSN and the other is Getting PIN.
The initial state (black circle) is the virtual beginning of the beginning action. The end state is also the virtual end of the action.
An event or condition that triggers an action is represented by a/action. When in the Validating state, objects do not wait for external events to trigger transitions. Instead, it produces an action. The result of the action determines the state of the next step.
Activity diagrams
The Activity diagram is a very special flow diagram. There is a relationship between activity diagrams and state diagrams. The state diagram focuses on the objects in the process, while the activity diagram focuses on a single process action flow. The activity diagram tells us about the dependencies between activities.
For our example, we use the following procedure.
“To withdraw money through an ATM.”
This activity has three classes Customer, ATM, and Bank. The process starts with black circles and ends with concentric circles in black and white. Activities are represented by rounded rectangles.
Activity maps can be broken down into many objects swimlanes, which can determine which objects are responsible for those activities. Each activity has a separate transition that connects the other activities.
A branch may branch into two or more mutually exclusive branches. The guard expression (in []) indicates that the transfer is derived from a branch. The branches and the merge at the end of the branches are represented in a diamond.
A fork can also be split into more than two parallel activities. Decomposition and the thread joining at the end of decomposition are represented by bold black lines
Components and configuration diagrams
Component components are code modules. A component diagram is a physical implementation of a class diagram.
Deployment Diagrams show software and hardware configuration.
The following configuration diagram illustrates the relationship between the software and hardware components related to real estate transactions.
Physical hardware is represented by nodes. Each component belongs to a node. Components are represented by a rectangle with two small rectangles in the upper left corner.
Reflection & Expansion
Brush interview: one-stop solution to interview problems, if you have good interview knowledge or skills to share!