Modeling UML Basic Level

Hello everyone! This post I wrote who is a newbie, so the content may be very basic and focus on the main subject “Modeling UML Basic Level”

The content includes these sections:

1. Overview of Software modeling with UML
2. UML diagrams (Use case diagram, Activity diagram, Class diagram, Sequence diagram)

What is UML?

UML, short for Unified Modeling Language, is a standardized modeling language consisting of an integrated set of diagrams, developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.

Modeling sharpens it and helps you think about what you are going to build, how to seek feedback, and where to make improvements. It prepares you to build the real thing, to reduce any potential risk of failure. Because it helps you see the big picture.
Modeling in software has been around for many decades, and through this experience, unified modeling language, or UML has emerged as the most widely used standard.

You can read more at refer link: UML languages

UML Diagram Types

By looking at types of UML models, you’ll be able to develop static and dynamic models of software systems

Common Users of UML Diagrams

1. Product owner
2. Business Analyst
3. Architect
4. Operations
5. Quality Assurance
6. Developer

1. Use Case Diagrams

Use case diagrams are a precursor to use case specifications that capture the overall functionality of a system at a very high level using notations for actors, use cases, and relationships among them. They are often used as a summary of all use cases in a system showing which use cases have been identified and documented elsewhere in the detailed use case specifications.

There are four elements in a use case diagram, use cases, the system for which the use cases have been identified, the actors, and associations among all these elements

The notation for a use case is a bubble with a use case title. A use case title is a combination of a verb and a noun that captures what the user wants to do with the system. A use case may have associations with other actors, as well as use cases. So what is an actor? Represents a user’s role with respect to the system. An actor may also be another system that interfaces with your system. And what is an association? It is between actor and use case.

1. Use cases:

• Is a bubble that carries use case title
• Associated with actors and possibly other user cases

2. Systems: A subject of Use cases could be a system or any other element that may have behavior, such as a Component or Class

3. Actors:

• A user with respect to the system
• Maybe a human or another system

4. Associations

• Between actor and use case
• Between use cases
• Between actors

2. Activity Diagrams

An activity diagram is a behavioral diagram that captures the workflow or the process model of the system. If you have learned any kind of flowcharting before, you will find activity diagrams to be very intuitive and easy to draw and understand. To add to its simplicity, an activity diagram is quite powerful in its ability to capture parallel tracks in a process, as well as multiple actors involved in a process.​​​​​​​

About key elements, I will cover the most basic six key elements shown in this sample diagram to help you get started. Among these, the first three are quite self-explanatory. The start and end nodes mark the scope of the activity diagrams. The rectangles are for actions that are taken with the activity that is being modeled, And flows are the arrows showing the sequence in which actions are conducted.​​​​​​​​​

1. Start and End — Key Elements

• Start and End nodes
• Actions
• Flows

2. Fork and Join

Fork and join help model a parallel flow within an activity. The first horizontal bar, which is called a fork, models the process of splitting into two parallel tracks.
A fork always has one incoming flow and more than one outgoing flow, indicating parallel tracks.
Once the request has been approved, the two parallel flows join back into a single flow. This is indicated again by the second horizontal bar which is a joining bar, with more than one incoming flow and a single outgoing flow. It is important to note that for the outgoing flow to start all incoming flows coming into the joining bar must have their actions completed. If not, the flow waits at the joining bar.

Key Elements

• Model parallel flows
• Fork (One incoming flow forks into multiple outgoing flows)
• Join

— Multiple incoming flows join one outgoing flow

— Outgoing flow starts only when all incoming flows have come in

3. Decision and Merge

It is a condition denoted by the diamond notation with the question is as text and possible response as the outflows. This node has one inflow and multiple guarded or conditional outflows that are mutually exclusive, which is unlike a fork where all outflows are executed in parallel. Here, only one outflow will be executed depending on which condition is true. After the outflow actions are over, the flow meets a merge node that has multiple inflows and one outflow. Again, anyone outflow with its actions completed will take the flow past the merge node. Then, when the event organizer is confirming the event.

Key Elements

• Model conditional flows
• Decision

— With one inflow and multiple guarded mutually exclusive outflows

— Each outflow has a (condition) as its guard

4. Swimlanes

Finally, when you want to model who is doing all many actions, then swimlanes can be very handy.

3. Class Diagrams

Class diagrams model the type of object in the system, along with the relationships among them. They also represent the most granular or lowest level, of abstraction, for example, classes and interfaces. They are the most widely-used structural models, showing a static view of the system, and they are often created by developers as part of design activity.

​​​​​​​The key elements in class diagrams can be divided into three groups: classifiers, features, and relationships. Classifiers represent the types of entities in your system. Features represent the structural and behavioral characteristics of these entities. And Relationships depict how these entities are related to each other​​​​​​​

Key Elements

• Classifiers — An abstract metaclass whose concrete subclasses classify different types of values
• Features

— Structural and behavioral characteristics of a classifier

— Structural (Properties or attributes)

— Behavioral (Operations or methods)

• Relationships — There are 3 relationships among classifiers (Association, Generalization, Dependency)

3.1 Classifiers and Relationships: A common abstraction for different types such as classes and interfaces. Initial analysis generates mostly concrete classes. Other classifiers may emerge as the design proceeds​​​​​​​

3.2 Association link: The instance of a source class is related to an instance of a target class

Multiplicity:

• *: zero or more
• 1..*: one or more
• 1: exactly one
• m..n: between m and n

Bidirectional association: Associated classes are navigable from each other

Aggregation and Composition source contains the target

• Aggregation: shared ownership
• Composition: ownership not shared

Generalization: Inheritance relationship between two classifiers

Dependency: A supplier/client relationship between two classifiers

4. Sequence Diagrams

Sequence diagrams are not only one of the most widely-used interaction diagrams but also one of the most popular UML diagrams as well. They capture the dynamic view of the system in terms of the sequence of interaction among its entities. They help capture the communication among classes, and through that, help us identify the behavior that we need to implement in the code.

A sequence diagram is read in two directions: from top to bottom, and horizontally from left to right or right to left, depending on the direction of the arrows.

• Most common interaction diagram
• Capture the behavior of interaction among two or more entities within a scenario

There are several elements in a sequence diagram. The most important and frequently used ones are participants, their lifelines, interaction messages among participants, activation bars on the lifelines, and fragments, which I will show you a little later in this lesson.

A participant is indicated as a box with its name in it. Since interaction is a dynamic behavior, which occurs when the system is in execution mode, the participants are essentially live objects. So, the name is that of an object with an optional class name separated by a colon.
The lifelines go from top to bottom, showing the flow of the time when the object is alive. All messages going to a lifeline mean a message to the participant attached to that lifeline.
Messages that ask the participant to do something are shown with a solid arrow, whereas a participant’s response to a message is shown as a dotted arrow

Key Elements

1. Participants
2. Lifeline
3. Interaction messages​​​​​​​
4. Activation or execution specification
5. Fragments

Message to a participant models

While class diagrams give us classes, attributes, and associations, sequence diagrams help identify methods.
Starting with the sequence diagram shown here as an example, the start message translates to a method in class A because it indicates that it is object A is responsible to start the interaction.
Similarly, the do something message received by object B translates to a method in class B, which returns a value of type int. It also tells us that class A and class B are associated through this message exchange.
So, a message in a sequence diagram translates to a method in a class, a message response translates to the method’s return value, and the whole interaction translates to an association between two classes.

• Its method, or a return value
• An association with the participant sending the message

Conditions/Loop

When you want to model some conditional exchange or repetition of a message, UML offers various kinds of fragment notations. We focus on three kinds: opt, alt, and loop.

Opt represents an option, or an if condition, that doesn’t have an else. Its notation is a box with opt keyword at the top right, along with the condition, which needs to be true for the participants to enter into that box.

The conditional exchange of messages is shown within the box. So, this means, A sends a message to B, then if some condition is true, B sends a response back to A.
Alt represents one or more alternate conditions if the first condition is not true. So, it is like an if condition with one or more else statements with their own conditions. In this case, if condition 1 is true, B will send response A to A, if condition 2 is true, it will send response B to A, and so on.

Loop represents a block of messages that continue to get passed as long as the condition is true. A will ask B to increase the count, and B will send a count to A as long as the count is less than 100 in this example.

Now that you have understood sequence diagrams, you can apply this understanding two draw communication diagrams, as they’re quite similar to each other.
The key difference is that participants in communication diagrams do not have a lifeline, and the focus is on how objects are like to each other through messages.
For example, in the sequence diagram, object A sends a message to object B, which asks object C to get X, object C responds with X, and object B responses to object A.
The same interaction is modeled in a communication diagram, as shown here, where the sequence of messages is shown by numbering the messages. In my experience and understanding, sequence diagrams are easier to read, have a better tool a better tool support, but are somewhat tedious to draw or change, especially on whiteboards. On the other hand, communication diagrams are easier to draw or change but are relatively less well-supported by tools, and sometimes, hard to read.

• A variant of sequence diagram without a lifeline
• Focus on links between objects

Thank you guys, I hope this article can be useful to you!