DEV Community: Gene Zeiniss

UML Diagrams: Sequence Diagram Overview

Gene Zeiniss — Sat, 20 Feb 2021 09:56:24 +0000

This article was originally published on Medium.

Unveiling UML Sequence Diagrams Through “The Little Prince” | by Gene Zeiniss | The Startup

Gene Zeiniss ・ Aug 8, 2024 ・
Medium

The most used by me (and my favorite) UML diagram is Sequence Diagram. Implementation designs of each new feature I’m working on are loaded with Sequence diagrams. I mean it, totally chock-full.

In general, a Sequence diagram describes how and in what order objects in our system interact with each other, arranged in time sequence. In this article, I’m about to show you the notations of these interactions through “The Little Prince” narrator’s interactions with the world around him. Have you read Antoine de Saint-Exupéry’s novel?

I will summarise only the part that is relevant to the current article. It will be connected, I promise.

...

Okay, briefly, when he was a child, the Narrator read a book on jungles and was fascinated by the fact that a boa constructor swallows his prey whole and then sleeps for few months while digesting the meal. He drew a picture of the boa in this state.

Here is a boa roentgen, if you have any doubts.

When he showed it to adults, they all thought it was a lumpy hat and suggested he stop messing about and study the “important subjects” in school instead. The adults’ criticism killed the artist. The child grew up, became a pilot, and flew worldwide (not the worst). As an adult, he used the boa drawing to decide what topics to talk about with other adults. If an adult saw a lumpy hat, the Narrator spoke about golf and bridge and politics; he never mentioned jungles or boa constrictors or stars.

...

Now, back to the Sequence Diagram.

Sequence Diagram

In my opinion, a sequence diagram is best to represent cross-services end-to-end scenarios or specific flow (or part of it) within a particular service. I’m creating this diagram before I start to design implementation, just to understand the requirements. It’s a contract between me and other involved guys, such as product manager, software architect, team members, etc. These diagrams are the VIP guests of each feature-related meeting.

The sequence diagram depicts the objects involved in the scenario and the sequence of messages exchanged between them required to execute the functionality. It’s pretty cool and handy.

...

Let’s start with an overview of basic symbols:

Basic Symbols

The sequence diagram has only two basic symbols: object and focus of control.

Object

The Sequence diagram object is notated by a box with the name and dashed line extended down below. While the object can represent a specific class (depending on what kind of logic you describe), I mostly use it to define a microservice.

However, today, it will represent a Narrator.

The dashed line is also known as the timeline, shows the sequential events that occur to an object during the charted process. Note that time in a Sequence diagram is all about ordering. The timeline is not relevant for the duration of the interaction.

Focus of Control

The focus of control is the block that overlays the object’s timeline. This is the time in which the object is actually being utilized.

...

Now we are jumping to the exciting part — the interaction between objects!

Interactions

The objects in software systems can interact synchronously or asynchronously.

Synchronous Message

Synchronous messaging is when the caller makes a call, expecting that object that’s being called to do some processing and return control back to the caller at some point in time.

Back to our Narrator. Remember the bao drawing? He showed the drawing of bao to adults and actually waited to hear what they see:

The synchronous message is notated by a solid line with a filled-in and enclosed arrow, pointing from the caller (Narrator) to the callee (Adult). And you can see that it starts a new focus of control on the callee.

Once the call that was made completes, control is returned back to the caller. This is represented by the return line, which is a dashed line with an open arrow pointing to the caller.

If you describe the flow between classes, I mean, the Narrator is calling to the Adult’s method, you can place the method name on the line. It’s also possible to put the passed parameters (depend on the level of details you are looking for).

The return line can be identified with return values that are coming back to the caller. Again, according to the level of the details you decided on. It’s often common to not label the return line at all.

“Less is more” — Ludwig Mies van der Rohe

In case, Narrator and Adult are services, the message can receive the endpoint name.

Here, you can see my return is pretty detailed. In my diagrams, I often return values that are relevant to the flow or to the contract.

“God is in the details” — Ludwig Mies van der Rohe

...

Another special kind of message is self-massage.

Self-Message

The self-messaging, obviously, is a call that an object makes to itself. When an Adult is asked by a Narrator, the first calls his cognitive abilities to answer the question.

In the case of self-message, you don’t need a return on it.

Asynchronous Message

The pretty of the asynchronous message is that the caller is not expecting the return message, so it’s not blocked.

Imagine, that Narrator just said to Adult that he drew bao.

The async message is represented by a solid line with an open arrow.

...

So, what we saw so far works great for basic simple flows. Although, we all know that the software we build includes many more operations and much more complexity.

Let’s take a look, how we can model structural controls using Sequence Diagrams.

Structural Controls

The first structural control I want to show you is Conditional control.

Alternative (Conditional) Control

The alternative is a choice (that is usually mutually exclusive) between message sequences. This is modeled by switch or if/else logic in our code:

The Narrator showed bao a drawing and asked, “what is it?”. If an adult saw a hat, the Narrator talked about golf; If an adult saw bao, he felt free to speak about boa constrictors.

Alternative control is represented by a labeled rectangle shape with a dashed line inside.

...

Okay, to show you the controls, I will refresh the novel slightly more for you.

The Narrator, who was a pilot (remember?), crashes in the Sahara desert. While he tries to repair his engine, a little boy (a Little Prince) appears out of nowhere and simply asks him to draw a sheep.

Now, let’s talk about Parallel Control.

Parallel Control

So, our Narrator is an extraordinary person (to put it mildly). However, to his credit, he is multitasking. He can (though with mixed success) repair the engine and communicate with a Little Prince in parallel. I must say, he is a genius!

As you can see, Parallel control notation is pretty similar to the Alternative one. It is represented by a labeled rectangle with a dividing dashed line. However, here each section must be processed, and processes should run in parallel.

...

Last but not least structural control is Looping.

Looping Control

When Little Prince appeared in the story, he asked the Narrator to draw a sheep.

Think about it for a moment. A little boy in a desert, alone… He’s not thirst or hunger. He wants a sheep. Fata-morgana? Genius Narrator stops the world and draws a sheep. So far, so good?

As it turned out, the boy was very fussy. He asked to draw a sheep repeatedly (once it was too big, once too old). Until the Narrator pulled a box and told that the sheep is inside.

The looping control shows that message interaction is going to happen multiple times. There is a guard text underneath the inverted tab that explains the loop.

That’s all! 🐑

...

To look at some of the other UML diagrams I wrote about, head on over to my profile.

UML Diagrams: Component Diagram Overview

Gene Zeiniss — Wed, 06 Jan 2021 14:19:58 +0000

This article was originally published on Medium.

Unveiling UML Component Diagrams: A Pizza-Lover’s Guide | by Gene Zeiniss | The Startup

Gene Zeiniss ・ Aug 8, 2024 ・
Medium

Think of pizza. The imagined smell of saucy, cheesy, spicy pizza baking in the oven is smashing me. Sometimes you want new toppings, other times, you want a different base. Many different ingredients create it. Each of these ingredients is separate components, but they interact and complement one another. They all exist within the greater system, in this case, the pizza.

You got that straight. In this article, we will deal with UML’s Component Diagram.

Component Diagram

Component diagrams are used to visualize how a system’s components interact (gee!) and what relationships they have among them. For the purpose of UML, the term “component” refers to a module of classes that represent independent systems with the ability to interface with the rest of the system. As we’re able to identify these interfaces, we’re able to find parts of the system that can be replaceable. In other words, we able to find plugin components.

Finding plugin components allow us to reuse these components in other projects. It also helps us structure our work by dividing that work off to a few developers or independently running sub-teams.

Back to the pizza, but now more specifically. Think about Hawaiian pizza on a restaurant menu. Probably, you will not find the pizza’s preparation and cooking methods. The menu just states the pizza ingredients, such as ham, pineapple, and bacon pieces over a red sauce (to be perfectly specific). By listing all of the ingredients, the customer can get a better idea of whether or not they’d enjoy the pizza. It is the same for the Component diagram. Unlike the other diagrams, the component ones are focused on high-level structure and not their methods and specific implementations. It’s a kind of a bird’s-eye view of your software system.

...

When you are building a Component diagram, the first step is to identify the basic components used in the system.

Basic Component

A component is a logical unit block of the system, a slightly higher abstraction than classes. It’s a subsystem if you wish. When subsystems are connected, it creates a single system.

Let’s assume we want to create a small family Pizzeria system. Our basic components will be:

Pizzaiolo — a professional pizza maker, as climbed by Oxford.
Customer — the actual pizza’s consumer (pizza eater, the same one that possibly will enjoy Hawaiian pizza).
Waiter — is “The One Who Waits”. Never mind, I’m just playing associations.

In UML, a component is represented as another box with this puzzle symbol in the top right-hand corner.

Here you can see the basic components of our Pizzeria. Cool? Not really. This information is not enough to tell us what we really need to know. Each component has a particular relationship to the other component through the interface it provides. The existence of these interfaces is the most interesting part.

Let’s expand our diagram a little bit. We’ll add some adornments to our Customer component.

Take a look at a diagram. I’ll start by talking about the Order and Payment. When a customer comes to the pizzeria, first, he should select and order the pizza. Right? The pizza party is usually finished by paying the bill. In Component language, Order and Payment are interfaces that our Customer provides (realizes or implements). The purpose of a provided interface is to show that a component offers an interface for others to interact with. This kind of interface is represented by a solid line with a lollipop at the end and a name over it.

Now, to provide the specific payment, the customer needs to know how much he needs to pay. The half-circle (also called “socket”) at the end of the connecting line represents the required interface. The meaning of it is that our honest customer expects to receive a check, provided by some other component (Waiter!) to be able to achieve its responsibilities.

To summarize, the interface describes a group of operations used (required) or created (provided) by components.

...

Our basic components are defined. Next, identify all of the relevant libraries needed for your system.

Libraries and Third-Party Dependencies

Component diagrams do not purely focus on what you implement. All third-party implementation dependencies must also be identified and integrated into the diagram where relevant. I will expand on third-parties later.

...

Finally, come up with the connections found between all these components. See how components can plug together. This is exactly the rationale behind this design.

Connections Between Components

The components can be connected loosely or tightly, like a belt on trousers before (and after) eating pizza.

Let’s start by talking about how we can loosely connect different components together.

Loosely Connection

It’s the main connection type of Content diagram. This is where we can define our pluggable parts of the system. When one component provided interface matches another component’s required interface, it’s called an assembly relationship.

Here you can see Customer and Waiter are connected like a puzzle. The components are plugging together. But you can also unplug them easily. The connection between them is loose. You can popup the Waiter service and replace it with something else, such as Shift Supervisor, or maybe the Pizzaiolo in the flesh will take the order. This is a replaceable piece of our system.

Tightly Connection

The tight connection between components is represented by a solid line between two components. It indicates that it’s not going to be so easy to replace one of these components. They are tightly coupled together. Let’s think of our example, assume that the customer can select pizza only from the pizza menu. His order is tightly dependent on the Menu component.

A Customer can not provide the order without a Menu. Getting rid of one of them will probably, require some rework for implementing this replacement.

...

Basic Component Diagram

Now, let’s take a look at a kind of a completed though rather small, Component diagram.

You can see, the diagram has some new elements that we are not yet looked at. First of all, we have an outer component diagram here, called Pizzeria. It’s our whole system. The other components sitting inside of this box are parts that make up the Pizzeria. It consists of Pizzaiolo, Waiter, and Customer. The Customer is tightly connected to the pizzeria’s menu.

A couple of other things to look at is the interaction with the outside world from the Pizzeria. Notice small squares sitting on the bounds of the Pizzeria component. These squares are called ports, and they specify a separate interaction point between the component and the environment.

In the Pizzeria example, ports represent the third-parties, such as a Cashier Service, used by Waiter; a Grocery Store, that provides the groceries required by Pizzaiolo; Pizzerias Ranking Service, which depend on review, provided by satisfied (or not) Customer.

Since we don’t implement these services, it’s enough to show only the interaction point and the dependency direction (incoming or outgoing). Dependencies are represented by dashed lines linking one component (or element) to another.

...

That’s all. Ciao ciao!

To look at some of the other UML diagrams I wrote about, head on over to my profile.

UML Diagrams: Class Diagram Overview

Gene Zeiniss — Wed, 06 Jan 2021 14:01:47 +0000

This article was originally published on Medium.

Decoding UML Diagrams: The Common Tongue of Software Modeling | by Gene Zeiniss | The Startup

Gene Zeiniss ・ Aug 8, 2024 ・
Medium

In my line of work, I’m often using UML diagrams. Daily, I daresay. Regardless, I never understood the subtlety of the diagram’s components. When to use a full arrow and when hollow, the line should be solid or dashed and which direction it should point. I’m done living in ignorance. So, here I am, about to start the UML diagrams series of articles.
...

Briefly about UML

UML (Unified Modeling Language) is a common software engineering modeling language that is used to solve a wide variety of problems. It’s a “the Common Tongue” of Westeros, for Game of Thrones fans. It helps you specify, visualize, and document models of software systems, including their structure and design, before coding (with an emphasis on “before”). As the old proverb says: “The carpenter measures twice and cuts once”.

There are several types of UML diagrams and each one of them serves a different purpose. The two most broad categories that encompass all other types are Structural and Behavioral diagrams.

Structural (or Static) diagram visualizes the system’s static structure through objects, attributes, operations, and relationships. I have a cat, Lola. She has some stuff, such as a food bowl, claw sharpener, and the poop-house. So, the static aspects of Lola encompass the existence of her stuff. By the way, Lola herself will be described as an object (from an object-oriented view, right?).

The Structural diagrams are: Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, Deployment Diagram, and Profile Diagram.

Behavioral (or Dynamic) diagrams are used to visualize the dynamic aspects of a system. The Behavioral category includes a few general types of behavior, specifically the Use Case Diagram, Activity Diagram, and State Machine Diagram; and types that represent the different aspects of interaction (aka “Interaction Diagrams”) — Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
In other words, it shows how the system interacts with external entities and users, how it responds to input or events, and what constraints it operates under. Just an example of an interaction between me and my cat. Lola hysterically meows. It triggers me to put food in her bowl. She eats while keeping the “thank hers”.

Not all of the 14 different types of UML diagrams are used regularly when documenting systems and/or architectures. I’m about to write about the most useful diagrams, in my humble opinion, and will start the series with Class Diagrams.
...

Class Diagram

Since most software being created nowadays is still based on the object-oriented programming paradigm, using Class diagrams to document the software turns out to be a common-sense solution. A Class Diagram describes the structure of a system by showing it’s classes, their attributes, methods, and the relations between them. It’s a vocabulary of the system, a common language between all members of the team.

Structural features (attributes) define what objects of the class “know”. Cat knows her eye color, coat, weight range and is acutely aware of her superiority.

Behavioral features (operations, aka methods) define what objects of the class “can do”. A cat can meow, eat, and poop (a very superficial idea of what a cat can do).

Classes are described as boxes in a Class Diagram. Each box has a title that represents the name of the class. Under the title, there are two sections:

The middle part of the box includes attributes. An attribute notation is attribute:type = defaultValue (optional)

The bottom part includes operations. An operation notation is operation(params):returnType

Following notations allow to specify the visibility of a class member (i.e. any attribute or operation):

We are cool? This is a Cat Class example. Let’s take a look at what we have here:

“Cat” is a class name (title).
The Cat has some public attributes, such as “eyes color” of type enum with default value “Yellow” (let’s say), and value object “coat” of type Coat.
Cats can meow and eat treats in public, however, they prefer to defecate in privacy (operations).

When you create a class diagram, omit not required details. I mean, try to keep the diagram clean, by showing only relevant details. Class diagrams get cluttered really fast. Take a look at the middle part of the box, the displayed attributes are marked as public. It means that other classes have access to these parameters. As a notation, it saves me the need to indicate the obvious getters and setters we’d expect here. Verstehen?
...

Relationships Between Classes

A relationship is a general term covering the types of logical connections found on class and object diagrams. A class may be involved in one or more relationships with other classes or instances.
...

The class-level relationships cover the object-oriented paradigm key-factors: interface implementation (realization) and inheritance (generalization).

Realization (Interface implementation)

In UML modeling, the realization is a relationship between two model elements, in which one model element (the client) implements the behavior that the other model element (the supplier) specifies.

Now, the same stuff in human language. The Cat is a domestic species of the Felidae family. I could say, Cat is a realization of Felidae. Or, in an object-oriented language, Cat is a specific implementation of the Felidae interface.

Note that the interface box has only one part under the title, which includes the operations, which have various implementations.

Class “Cat” implements the “Felidae” interface. We can recognize it by the connecting line between their boxes. The dashed line with a hollow arrow pointing back to the interface that’s being implemented.

Notice that in the Cat box, we are not showing any operations that are part of “Felidae”. Cat implements these operations, no need to duplicate them (keep diagrams as clean as possible, remember?).

Generalization (Inheritance)

Generalization represents a “IS A’’ relationship between a general class (Cat) and a more specific implementation of this class (Cat Breed). Russian Blue is a cat breed, while each specific cat breed acquires all the attributes and operations of a Cat, but also can have it’s own. For, example, cats of the Scottish Fold breed can stand up on their hind legs.

The generalization relationship notated in UML by a solid line with an enclosed hollow arrow, pointing back to the general (base) class.

Another couple of items to keep in mind here is the concept of Abstract and Concrete Classes.

An abstract class is a class that we will never instantiate. In UML, this class’s name should be italicized.

A concrete class is a class that we actually instantiate. It’s a default class, without any special decorations of its title.

...
The next thing we want to look at in our Class Diagram is modeling relationships.

Basic Relationship (Association)

This association relationship is usually described as a “HAS A” relationship. It indicates that at least one of two related classes refers to each other. This relationship is represented simply by a solid line (without an arrow) that connects two classes.

Now, often, it’s important to understand how many items on each side of a relationship can exist, which we call “cardinality”. The cardinality is expressed in terms of: “one to one”, “one to many” and “many to many”. In UML it’s notated as follows:

Take a look at this diagram:

In the current example, a cat has a human (the chosen one, right). The human has few cats (of both Russian Blue (wannabe) and Scottish Fold breeds. True story). It’s a “many to one” relationship.

Aggregation Relationship

Aggregation is a variant of the “HAS A” relationship, however, it’s more specific than an association. Aggregation represents a one-way association, called a “PART-WHOLE” relationship. I mean, one entity works as an owner (a whole) of another (a part of the whole), but the owned classes do not have a strong lifecycle dependency on the owner.

Back to our Cat. Each cat must have a poop-house. So, the implied relationship between “Cat” and “Poop-House” will be a “HAS A” type relationship. But the reverse may not be true. Each poop-house doesn’t need to be contained by any cat. Now it easy to recognize that Cat is an owner entity and this is an aggregation relationship.

In UML, the connecting line has a hollow diamond, pointing to the owner class. Poop-House is strongly related to the Cat.

Composition Relationship

The composition is a “PART OF” relationship, a special type of aggregation, where parts don’t stand on their own so much. The owner class here is a kind of container, and related entities are its contents. All entities are interdependent of each other for example “litter box and clumping litter is part of poop-house”. The house can not exist without the box or the litter, doesn’t it?

Here we have a solid line with a filled diamond, pointing to the owner class.

Uses Relationship (Dependency)

Uses relationship is a little bit softer tied between the classes. This relationship indicates that one class depends on another because it uses it at some point in time.

For example, other family members can communicate with the Cat and the Human (that is not welcomed much by the Cat).

Uses relationship notation is a dashed line with an open arrow, pointing to the used classes. It helps us to understand that changes in Cat or Human can affect Other Family Members, and so we should be careful. We’re good?
...
We are done. Now, let’s check the completed overall view of the basic Class Diagram.

That’s all.

DEV Community: Gene Zeiniss

UML Diagrams: Sequence Diagram Overview

This article was originally published on Medium.

Unveiling UML Sequence Diagrams Through “The Little Prince” | by Gene Zeiniss | The Startup

Gene Zeiniss ・ Aug 8, 2024 ・ Medium

Sequence Diagram

Basic Symbols

Object

Focus of Control

Interactions

Synchronous Message

“Less is more” — Ludwig Mies van der Rohe

“God is in the details” — Ludwig Mies van der Rohe

Self-Message

Asynchronous Message

Structural Controls

Alternative (Conditional) Control

Parallel Control

Looping Control

To look at some of the other UML diagrams I wrote about, head on over to my profile.

UML Diagrams: Component Diagram Overview

This article was originally published on Medium.

Unveiling UML Component Diagrams: A Pizza-Lover’s Guide | by Gene Zeiniss | The Startup

Gene Zeiniss ・ Aug 8, 2024 ・ Medium

Component Diagram

Basic Component

Libraries and Third-Party Dependencies

Connections Between Components

Loosely Connection

Tightly Connection

Basic Component Diagram

To look at some of the other UML diagrams I wrote about, head on over to my profile.

UML Diagrams: Class Diagram Overview

This article was originally published on Medium.

Decoding UML Diagrams: The Common Tongue of Software Modeling | by Gene Zeiniss | The Startup

Gene Zeiniss ・ Aug 8, 2024 ・ Medium

Briefly about UML

Class Diagram

Relationships Between Classes

Realization (Interface implementation)

Generalization (Inheritance)

Basic Relationship (Association)

Aggregation Relationship

Composition Relationship

Uses Relationship (Dependency)

To look at some of the other UML diagrams I wrote about, head on over to my profile.

Gene Zeiniss ・ Aug 8, 2024 ・
Medium

Gene Zeiniss ・ Aug 8, 2024 ・
Medium

Gene Zeiniss ・ Aug 8, 2024 ・
Medium