an overview of the main types of diagrams, class diagram. Part 1

[*]

Telegram channel, today I want to talk about such a mandatory skill for analysts as process design. I think that everyone who will work in the position of a systems / business analyst will sooner or later face such a task.

There are many different process modeling languages, but today we will focus on UML. After reading the first article in a series of articles on process modeling, you will learn:

  • What is UML and why should you use it

  • What types of diagrams exist in UML

  • Learn in detail how to model processes using a class diagram

What is UML?

UML (Unified Modeling Language – unified modeling language) – a graphical description language for object modeling in software development, it is also used for business process modeling, system modeling and displaying organizational structures.

Why do we need UML? Can we come up with our own modeling language?

Imagine the following situation: the analyst Vasya is engaged in the development of technical documentation for a new project, he uses his own invented diagrams to describe the processes.

After compiling the documentation, Vasya presents the results to the developer Kolya, but Kolya does not understand anything in what is written. Vasya has to explain what he drew in his documentation and spend a lot of time on it.

But what if we have not one developer, but 10? Or 100?

In this case, we need a universal modeling language that will be understood by all participants in the software development process. UML is such a universal language, that is, UML is a kind of standard for describing various processes. It is used by developers, analysts, an architect, with its help you can clearly convey thoughts and communicate with each other. Such an approach using a universal language will significantly reduce the time of communication between employees and reduce the time to deliver the final product to the user.

Pros of UML:

  • Simplifies the complexities of software development

  • Automates the production of software and processes

  • Helps solve persistent architecture problems

  • Improves the quality of work

  • Reduces costs and time to market

Cons of UML:

Types of diagrams in UML

So, let’s start studying and reviewing UML diagrams. All UML diagrams are essentially divided into two types:

  1. Structural diagrams – describe the structure of complex objects and systems, show the static structure of the system and its parts at different levels of abstraction and implementation, as well as their relationship

  2. Behavior diagrams – illustrate the interaction with the system and the process of its operation, the focus here is on the dynamic aspects of the software system or process

Structure diagrams include the following 7 types of diagrams:

  • Composite Structure Diagram

  • Deployment Diagram

  • Package diagram

  • Profile diagram

  • class diagram

  • Object Diagram

  • Component Diagram

Behavior diagrams include the following types of diagrams:

  • activity diagram

  • Use Case Diagram

  • State diagram

  • sequence diagram

  • Communication diagram

  • Interaction Overview Diagram

  • timing diagram

The figure below shows an illustration of the structure of the UML language:

Figure 1. The structure of the UML language

Figure 1. The structure of the UML language

Today I propose to dwell on the class diagram and consider this type of diagram in detail. Other types of diagrams will be discussed in subsequent series of articles.

class diagram

class diagram describes the types of system objects and various kinds of static relationships that exist between them. Class diagrams show class properties, class operations, and constraints that are placed on relationships between objects.

The figure below shows the model of the customer order processing class. The boxes in the diagram represent classes and are divided into three parts: the name of the class (in bold), its attributes, and its operations. The figure also shows two kinds of relationships between classes: associations and generalizations.

Figure 2. An example of using a class diagram

Figure 2. An example of using a class diagram

Properties

Properties represent the structural functionality of a class. You can think of properties as fields of a class. Properties represent a single concept, embodied in two completely different entities: attributes and associations. Although they look completely different on the diagram, they are actually the same thing.

Attributes

Attribute describes the property as a line of text inside the class rectangle.
Full attribute form:
видимость имя: тип кратность = значение по умолчанию {строка свойств}

For example:
имя: String [1] = "Без имени" {readOnly}

Be sure to include only the name.

Consider the main attribute entities:

  • The visibility label indicates whether the attribute is public (+) (public) or private ( ) (private).

  • The attribute name – the way the class refers to the attribute – roughly corresponds to the name of a field in a programming language.

  • The attribute type imposes a restriction on the kind of object that can be placed in the attribute. You can think of it as an analogue of a field type in a programming language.

  • Multiplicity – this concept will be discussed below.

  • The default value is the value for newly created objects if the attribute is not defined during creation.

  • The {property string} element allows you to specify additional attribute properties. In the example, it is equal to {readOnly}, which means that clients cannot change the attribute. If it is omitted, then, as a rule, the attribute can be modified.

Associations

Another property entity is association. Much of the information that can be specified in an attribute appears in an association. Figures 3 and 4 below show the same properties in different notations.

Figure 3. Representation of order properties as attributes

Figure 3. Representation of order properties as attributes

Figure 4. Representation of order properties as associations

Figure 4. Representation of order properties as associations

Association is a continuous line between two classes, from the source class to the target class. The name of the property (together with the multiplicity) is located at the target end of the association. The target end of the association points to the class that is the type of the property.

Naturally, the question arises: “When should one or another representation be chosen?”. As a rule, attributes are used to denote small elements, such as dates or booleans, and associations for more significant classes, such as customers or orders.

Bidirectional Associations

Bidirectional Association is a pair of properties related in opposite directions. The Car class has an owner:Person property[1]and the Person class has the cars:Car property[*].

Figure 5. Bidirectional association

Figure 5. Bidirectional association

The feedback between the two implies that if you follow both properties, you should return back to the set containing your starting point. For example, if we start with a specific Ford model, find its owner, and then look at the set of cars that the owner owns, then it should include the Ford model we started with.

multiplicity

multiplicity properties indicates the number of objects that can populate this property. The most common multiplicity is:

  • 1 (Only one customer can submit an order)

  • 0..1 (A corporate customer may or may not have a single sales representative.)

  • * (Customer is under no obligation to place an order, and the number of orders is unlimited. He can place zero or more orders.)

Operations

Operations are actions implemented by some class. There is an obvious correspondence between operations and class methods. Usually the terms operation and method are used interchangeably, but sometimes it is useful to distinguish between them.

The complete syntax for operations in the UML is as follows:

видимость имя (список параметров) : возвращаемый тип {строка свойств}

Consider the main essence of the operation:

  • The visibility label, as in attributes, indicates whether the operation is public (+) (public) or private ( ) (private)

  • Name is the name of the operation.

  • Parameter list – list of operation parameters.

  • The return type is the type of the return value, if any.

  • Property line – property values ​​that apply to this operation.

For example, in an invoice, a transaction might look like this:

+ balanceOn (date: Date) : Money

Generalization

Generalization combines multiple subclasses into one class. So, in our example, the generalization combines individual and corporate clients of some business system. Despite certain differences, they have a lot in common. The same properties can be placed in the base class Customer (Client), while the class Personal Customer (Individual client) and the class Corporate Customer (Corporate client) will act as subtypes.

From a software perspective, the obvious interpretation of inheritance is as follows: Enterprise Client is a subclass of the Client class. In major object-oriented languages, the subclass inherits all the functionality of the superclass and can override any methods of the superclass.

Notes and comments

Notes are the comments on the diagrams. Notes can exist on their own or be linked by a dotted line to the elements they comment on. They can be present on diagrams of any type.

Figure 6. An example of using notes

Figure 6. An example of using notes

Class Diagram Tips

So, we have covered the basic UML diagrams and the class diagram in detail. I want to finish my first article with quotes from Martin Fowler’s book “UML Fundamentals”. In the chapter on process modeling with class diagrams, Martin gives the following tips:

1. Do not try to use all available concepts at once. Start with the simple ones covered in this chapter: classes, associations, attributes, generics, and constraints.

2. I have found that conceptual class diagrams are very useful in learning business language. In order for this to work, it is necessary to avoid discussing software in every possible way and use very simple notation.

3. Don’t build models for everything, instead focus on key aspects. It is better to create few diagrams that are constantly used in work and reflect all the changes made, than to deal with a large number of forgotten and outdated models.

The biggest danger with class diagrams is that you can focus solely on structure and forget about behavior. Therefore, when drawing class diagrams to understand software, use some form of behavioral analysis. If you apply these methods alternately, then you are moving in the right direction.

Thanks to everyone who read this article to the end. Share your opinion in the comments. In the next article, I will continue the topic of process modeling in UML and talk about new types of UML diagrams.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *