What is UML?
If you look at the pictures in search engines, it becomes clear that UML- this is something about schemes, arrows and squares. What is important is that UML translates as Unified Modeling Language. The word Unified is important here. That is, our pictures will be understood not only by us, but also by others who know UML. It turns out this is such an international language for drawing diagrams.
As Wikipedia says
UML is a graphical description language for object modeling in the fields of software development, business process modeling, systems engineering, and mapping organizational structures.The most interesting thing that not everyone thinks about or guesses about is that UML has specifications. Moreover, there is even a UML2 specification. More information about the specification can be found on the Object Management Group website. Actually, this group is engaged in the development of UML specifications. It is also interesting that UML is not limited to describing the structure of classes. There are many types of UML diagrams. A brief description of the types of UML diagrams can be seen in the same Wikipedia: UML diagrams or in Timur Batyrshinov's video Overview of UML Diagrams. UML is also widely used in describing various processes, for example here: Single sign-on using JWT. Returning to the use of UML class diagrams, it is worth noting the book Head First: Design Patterns, in which the patterns are illustrated by those same UML diagrams. It turns out that the UML is indeed being used. And it turns out that knowing and understanding its application is quite a useful skill.
Application
Let's see how you can work with this very UML from the IDE. As an IDE, take IntelliJ Idea. If use IntelliJ Idea Ultimate, then we will have the plugin installed "out of the box" UML Support". It allows you to automatically generate beautiful class diagrams. For example, through Ctrl + N or the menu item "Navigate" -> "Class" go to the class ArrayList. Now, through the context menu by the class name, select "Diagram" -> "Show diagram popup". As a result, we get a beautiful chart:
But what if you want to draw yourself, and even there is no Ultimate version of Idea? If we are using IntelliJ Idea Community Edition, then we have no other choice. To do this, you need to understand how such a UML scheme works. First we need to install Graphviz . It is a set of graph visualization utilities. It is used by the plugin that we will use. After installation, you need to add a directory bin from the installed directory graphviz to an environment variable PATH. After that, in IntelliJ Idea, select File -> Settings from the menu. In the "Settings" window, select the "Plugins" category, click the "Browse repositories" button and install the PlantUML integration plugin. Why is this one so good PlantUML? It uses a graph description language called " dot" and this allows it to be more universal, because this language is used not only by PlantUML. Moreover, everything that we will do below can be done not only in the IDE, but also in the planttext.com online service. After installing the PlantUML plugin, we will be able to create UML diagrams through "File" -> "New". Let's create a diagram of the "UML class" type. During this, a template with an example is automatically generated. Let's delete its contents and create our own, armed with an article from Habr: Class Relations - from UML to code... And to understand how to depict this in the text, let's take the PlantUML manual: plantuml class-diagram... In it, at the very beginning, there is a sign with how to describe relationships:
About the connections themselves, we can still peep here: "Relationships between classes in UML. Examples". Based on these materials, let's start creating our UML diagram. Add the following content describing the two classes: @startuml class ArrayList ( ) class LinkedList ( ) @enduml To see the result in Idea, select "View" -> "Tool Windows" -> "PlantUML". We will get just two squares denoting classes. As we know, both of these classes implement the List interface. This relation of classes is called - implementation (realization). An arrow with a dotted line is used to depict such a relationship. Let's draw it: interface List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о package private element array: ~ Object elementData Now we want to show that the ArrayList contains some objects. In this case, the connection type will be - aggregation(aggregation). The aggregate in this case is ArrayList , because it contains other objects. We choose aggregation because the objects in the list can live without the list: they are not integral parts of it. Their lifetime is not tied to the lifetime of the list. The unit from Latin is translated as "collected", that is, something made up of something. For example, in life, there is a pumping unit, which consists of a pump and an engine. The unit itself can be disassembled, leaving some of its components. For example, to sell or put in another unit. So it is on the list. And this is expressed in the form of an empty rhombus at the unit and a continuous line. Let's put it this way: class Object ( ) ArrayList o- Object Now we want to show that, unlike ArrayList , the LinkedList class contains Node containers that refer to stored data. In this case, Nodes are part of the LinkedList itself and cannot live separately. Node is not directly stored content, but only contains a reference to it. For example, when we add a row to the LinkedList, we add a new Node , which contains a link to this row, as well as a link to the previous and next Node . This type of connection is called composition(composition). To display a composite (one that consists of parts), a filled robic is drawn, a continuous line leads to it. Now let's write this as a text display of the link: class Node ( ) LinkedList * -- Node And now we need to learn how to display another important type of link - addiction(dependency relationship). It is used when one class uses another, while the class does not contain the used class and is not its successor. For example, LinkedList and ArrayList can create a ListIterator . Let's display this as dotted arrows: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
You can detail as much as you need. All designations are listed here: "PlantUML - Class Diagram". In addition, there is nothing supernatural in drawing such a scheme, and when working on your tasks, you can quickly draw it by hand. This will develop your application architecture thinking skills and help you spot class structure flaws early on, not after you've already spent a day implementing the wrong model. I think that's a good reason to give it a try?)
Automation
There are various ways to automatically generate PlantUML diagrams. For example, in ideas There is a SketchIT plugin, but it doesn't draw them correctly. For example, the implementation of interfaces is drawn incorrectly (displayed as inheritance). There are also examples online of how to build this into your project's build life cycle. Let's say for Maven there is an example using uml-java-docklet . To show how this is done, let's use the Maven Archetype to quickly create a Maven project. Let's execute the command: mvn archetype:generate On the question of choosing a filter ( Choose a number or apply filter) leave default by simply pressing Enter. It will always be" maven-archetype-quickstart". We select the latest version. Next, answer the questions and complete the creation of the project:
Since Maven is not the focus of this article, answers to your questions about Maven can be found in the Maven Users Center . In the generated project, open the project description file for editing, pom.xml. We will copy the contents from the description of uml-java-docklet installing into it. The artifact used in the description could not be found in the Maven Central repository. But it worked for me with this: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . That is, in that description you just need to replace groupId from " info.leadinglight" on the " com.chfourie" and put version " 1.0.0 ". After that, we can execute in the directory where the file is located pom.xml these commands are: mvn clean install and mvn javadoc:javadoc . Now, if we open the generated documentation (explorer target\site\apidocs\index.html), we will see UML diagrams. By the way, the implementation is already displayed correctly here)
Conclusion
As you can see, UML allows you to visualize the structure of your application. Also, UML is not limited to just that. With the help of UML, you can describe various processes within your company or describe the business process within which the function that you write works. It is up to you to decide how much UML is useful for you personally, but it will be useful to find the time and get to know it in more detail anyway. #Viacheslav Russian version of this post: UML diagram Java on CodeGymAnnotation: The subject of this course is The UML - Unified Modeling Language. In the previous lecture, we talked about what UML is, about its history, purpose, ways of using the language, the structure of its definition, terminology and notation. It has been noted that a UML model is a set of diagrams. In this lecture, we will consider such questions: why we need several types of diagrams; types of diagrams; OOP and sequence diagramming
Before moving on to the discussion of the main material of this lecture, let's talk about why build any diagrams at all. The development of a model of any system (not only software) always precedes its creation or updating. This is necessary at least in order to more clearly imagine the problem being solved. Thoughtful models are very important both for interaction within the development team and for mutual understanding with the customer. After all, it allows you to make sure that the project is "architecturally consistent" before it is implemented in code.
We build models of complex systems because we cannot describe them completely, "take a look at them at a glance". Therefore, we single out only the properties of the system that are essential for a particular task and build its model that reflects these properties. The method of object-oriented analysis makes it possible to describe real complex systems in the most adequate way. But as systems become more complex, there is a need for good simulation technology. As we said in the previous lecture, a unified system is used as such a "standard" technology. modeling language(Unified Modeling Language, UML), which is a graphical language for the specification, visualization, design, and documentation of systems. Using UML, you can develop a detailed model of the system being created, reflecting not only its concept, but also specific implementation features. Within the framework of the UML model, all representations about the system are fixed in the form of special graphic constructions called diagrams.
Note. We will not consider all, but only some of the types of charts. For example, the component diagram is not covered in this lecture, which is only a brief overview of diagram types. The number of chart types for a particular application model is not limited in any way. For simple applications, there is no need to build diagrams of all types without exception. Some of them may simply be missing, and this fact will not be considered an error. It is important to understand that the availability of diagrams of a certain type depends on the specifics of a particular project. Information about other (not discussed here) types of diagrams can be found in the UML standard.
Why You Need Multiple Types of Charts
First, let's define terminology. In the preface to this lecture, we repeatedly used the concepts of system, model, and diagram. The author is sure that each of us intuitively understands the meaning of these concepts, but to make it completely clear, let's look again at the glossary and read the following:
System- a set of interconnected controlled subsystems united by a common goal of functioning.
Yes, not very informative. What is a subsystem then? To clarify the situation, let's turn to the classics:
system call a set of subsystems organized to achieve a specific goal and described using a set of models, possibly from different points of view.
Well, there's nothing you can do, you have to look for the definition of a subsystem. It also says there that subsystem is a set of elements, some of which specify the behavior of other elements. Ian Sommerville explains the concept this way:
Subsystem is a system whose functioning does not depend on the services of other subsystems. The software system is structured as a set of relatively independent subsystems. Interactions between subsystems are also defined.
Also not very clear, but better. Speaking in "human" language, the system is represented as a set of simpler entities that are relatively self-sufficient. This can be compared to how, in the process of developing a program, we build a graphical interface from standard "cubes" - visual components, or how the program text itself is also divided into modules that contain subroutines that are combined according to a functional feature, and they can be reused, in the following programs.
Understand the concept of a system. During the design process, the system is considered from different points of view with the help of models, the various representations of which appear in the form of diagrams. Again, the reader may have questions about the meaning of the concepts models And diagrams. We think a beautiful, but not very clear definition models as a semantically closed system abstraction is unlikely to clarify the situation, so let's try to explain "in our own words."
Model- this is a certain (material or not) object that displays only the most significant characteristics of the system for this task. Models are different - tangible and intangible, artificial and natural, decorative and mathematical...
Let's give some examples. The plastic toy cars familiar to all of us, which we played with such excitement in childhood, are nothing more than material artificial decorative real car model. Of course, in such a "car" there is no engine, we do not fill its tank with gasoline, the gearbox does not work in it (moreover, it is absent at all), but as a model, this toy fully fulfills its functions: it gives the child an idea about the car, because it displays its characteristic features are the presence of four wheels, a body, doors, windows, the ability to drive, etc.
In medical research, animal testing often precedes clinical trials of drugs in humans. In this case, the animal acts as material natural human models.
The equation shown above is also a model, but this is a mathematical model, and it describes the movement of a material point under the action of gravity.
It remains only to say what a diagram is. Diagram is a graphical representation of a set of elements. Usually depicted as a graph with vertices (entities) and edges (relations). There are many examples of diagrams. This is a block diagram familiar to all of us from school years, and installation diagrams for various equipment that we can see in user manuals, and a tree of files and directories on a disk, which we can see by running the tree command in the Windows console, and much, much more other. In everyday life, diagrams surround us from all sides, because a picture is easier for us to perceive than a text...
But back to software design (and not only). In this industry since using diagrams, you can visualize the system from different points of view. One of the diagrams, for example, can describe the interaction of the user with the system, the other - the change in the states of the system during its operation, the third - the interaction between the elements of the system, etc. A complex system can and should be represented as a set of small and almost independent models - diagrams, and none of them is sufficient to describe the system and get a complete picture of it, since each of them focuses on some particular aspect of the functioning of the system and expresses a different abstraction level. In other words, each model corresponds to some specific, particular point of view on the system being designed.
Despite the fact that in the previous paragraph we were very loose with the concept of a model, it should be understood that in the context of the above definitions no single diagram is a model. Diagrams are only a means of visualizing the model, and the two should be distinguished. Only a set of diagrams constitutes a system model and describes it most fully, but not one diagram taken out of context.
Types of charts
UML 1.5 defined twelve types of charts divided into three groups:
- four types of diagrams represent the static structure of the application;
- five represent the behavioral aspects of the system;
- three represent the physical aspects of system operation (implementation diagrams).
The current version of UML 2.1 hasn't made too many changes. Diagrams have slightly changed in appearance (frames and other visual improvements have appeared), notation has improved slightly, some diagrams have received new names.
However, the exact number canonical diagrams it is absolutely unimportant for us, since we will not consider all of them, but only some - for the reason that the number of diagram types for a particular model of a particular application is not strictly fixed. For simple applications, there is no need to build all diagrams without exception. For example, for a local application, it is not necessary to build a deployment diagram. It is important to understand that the list of diagrams depends on the specifics of the project being developed and is determined by the developer himself. If the curious reader still wants to know about all UML diagrams, we will refer him to the UML standard (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Recall that the purpose of this course is not to describe absolutely all the possibilities of UML, but only to introduce this language, to give an initial idea of this technology.
So, we will briefly look at such types of charts as:
- use case diagram;
- class diagram;
- object diagram;
- sequence diagram;
- interaction diagram;
- state diagram;
- activity diagram;
- deployment diagram.
We will talk about some of these diagrams in more detail in the next lectures. For now, we will not focus on the details, but set ourselves the goal of teaching the reader to at least visually distinguish between the types of diagrams, to give an initial idea of the purpose of the main types of diagrams. So, let's begin.
Use Case Diagram
Any (including software) systems are designed taking into account the fact that in the course of their work they will be used by people and / or interact with other systems. The entities with which the system interacts in the course of its work are called actors, and each actor expects the system to behave in a strictly defined, predictable way. Let's try to give a more rigorous definition of an ector. To do this, we use a wonderful visual vocabulary for UML Zicom Mentor:
Hector (actor)- this is a set of logically related roles performed when interacting with precedents or entities (system, subsystem or class). An actor can be a person or another system, subsystem or class that represents something outside of the entity.
Graphically, the vector is depicted either " little man", similar to those that we drew in childhood, depicting members of our family, or class symbol with corresponding stereotype, as it shown on the picture. Both forms of presentation have the same meaning and can be used in diagrams. The "stereotyped" form is more often used to represent system actors or in cases where the actor has properties that need to be displayed (Fig. 2.1).
The attentive reader may immediately ask the question: Why is hector and not an actor?? We agree, the word "ektor" cuts the ear of a Russian person a little. The reason why we say this is simple - the ector is formed from the word action, which means in translation action. The literal translation of the word "ektor" - actor- too long and uncomfortable to use. Therefore, we will continue to say so.
Rice. 2.1.
The same attentive reader could notice the word "precedent" flashed in the definition of the ector. What is it? This question will interest us even more if we remember that we are now talking about use case diagram. So,
Precedent (use-case)- description of a particular aspect of the system behavior from the user's point of view (Butch).
The definition is quite understandable and exhaustive, but it can be further refined using the same Zicom Mentor"om:
use case- description of the set of successive events (including variants) performed by the system that lead to the result observed by the actor. A use case represents the behavior of an entity by describing the interaction between the actors and the system. A precedent does not show "how" a certain result is achieved, but only "what" it is.
Precedents are indicated in a very simple way - in the form of an ellipse, inside which its name is indicated. Use cases and actors are connected with lines. Often at one end of the line depict rice. 2.3
UML is now the standard notation for visual modeling of software systems, adopted by the Object Managing Group (OMG) in the fall of 1997 and supported by many object-oriented CASE products.
The UML standard offers the following set of diagrams for modeling:
Use case diagram (use case diagram) - for modeling the business processes of an organization or enterprise and determining the requirements for the information system being created;
class diagram (class diagram) - for modeling the static structure of the system classes and the relationships between them;
system behavior diagram (behavior diagrams);
interaction diagrams;
Sequence diagrams - for modeling the process of messaging between objects within one use case;
collaboration diagram (collaboration diagram) - for modeling the process of messaging between objects within the same use case;
statechart diagram - for modeling the behavior of system objects during the transition from one state to another;
activity diagram - for modeling the behavior of the system within the framework of various use cases, or modeling activities;
implementation diagram (implementation diagrams):
Component diagrams (component diagrams) - for modeling the hierarchy of components (subsystems) of an information system;
deployment diagram (deployment diagram) - for modeling the physical architecture of the designed information system.
On fig. 1.1 presents an integrated model of the information system, including the main diagrams to be developed in this course project.
Rice. 1. An integrated model of an information system in the notation of the UML language
4.2. Use case diagram
A use case is a sequence of actions performed by the system in response to an event triggered by some external object (actor). A use case describes a typical interaction between a user and a system. In the simplest case, the use case is determined in the process of discussing with the user the functions that he would like to implement in this information system. In UML, a use case is depicted as follows:
Fig.2. Use case
An actor is a role that a user plays in relation to the system. Actors represent roles, not specific people or job titles. Although they are depicted as stylized human figures in use case diagrams, an actor can also be an external information system that needs some information from the system. You should only show actors in a diagram when they really need some use cases. In UML, actors are represented as shapes:
Fig.3. Character (actor)
Actors are divided into three main types:
Users
systems;
Other systems interacting with this one;
Time becomes an actor if the triggering of any events in the system depends on it.
4.2.1. Relationships Between Use Cases and Actors
In UML, use case diagrams support several types of relationships between diagram elements:
Communication (communication),
Inclusion (include),
extension (extend),
generalization.
communication communication is the relationship between the use case and the actor. In UML, communication links are shown using a one-way association (solid line).
Fig.4. Communication link example
Inclusion connection used in situations where there is some piece of system behavior that is repeated in more than one use case. With the help of such links, a reusable function is usually modeled.
Extension connection used to describe changes in the normal behavior of a system. It allows one use case to use the functionality of another use case when needed.
Fig.5. An example of an inclusion and extension relationship
Communication generalization indicates that several actors or classes have common properties.
Fig.6. An example of a generalization relationship
4.3.
Interaction diagrams describe the behavior of interacting groups of objects. Typically, an interaction diagram only covers the behavior of objects within a single use case. Such a diagram displays a number of objects and the messages that they exchange with each other.
message is the means by which the sender object requests the receiver object to perform one of its operations.
Information (informative) message is a message that provides the receiving object with some information to update its state.
Request message (interrogative) is a message requesting the output of some information about the recipient object.
Imperative message is a message that asks the receiver to perform some action.
There are two types of interaction diagrams: sequence diagrams and collaboration diagrams.
4.3.1. Sequence diagrams
sequence diagram reflects the flow of events occurring within a single use case.
All actors (actors, classes, or objects) involved in a given scenario (use case) are shown at the top of the diagram. Arrows correspond to messages passed between an actor and an object, or between objects to perform the required functions.
In a sequence diagram, an object is depicted as a rectangle, from which a dotted vertical line is drawn downward. This line is called lifeline of an object . It is a fragment of the life cycle of an object in the process of interaction.
Each message is represented as an arrow between the lifelines of two objects. Messages appear in the order they appear on the page from top to bottom. Each message is tagged with at least the message name. Optionally, you can also add arguments and some control information. You can show self-delegation, a message that an object sends to itself, with the message arrow pointing to the same lifeline.
Rice. 7. Sequence Diagram Example
4.3.2. Collaboration diagram
Cooperation Diagrams display the flow of events within a specific scenario (use case). Messages are ordered by time, although collaboration diagrams focus more on relationships between objects. A collaboration diagram shows all the information that a sequence diagram has, but a collaboration diagram describes the flow of events in a different way. From it it is easier to understand the connections that exist between objects.
In a collaboration diagram, as in a sequence diagram, the arrows represent the messages that are exchanged within a given use case. Their time sequence is indicated by numbering the messages.
Rice. 8. An example of a cooperation diagram
4.4. class diagram
4.4.1. General information
class diagram defines the types of system classes and various kinds of static links that exist between them. Class diagrams also show class attributes, class operations, and constraints that are placed on relationships between classes.
A class diagram in UML is a graph whose nodes are the elements of the static structure of the project (classes, interfaces), and the arcs are the relationships between the nodes (associations, inheritance, dependencies).
The class diagram shows the following elements:
· Package (package) - a set of elements of the model, logically related to each other;
· Class (class) - description of common properties of a group of similar objects;
· Interface (interface) - an abstract class that specifies a set of operations that an object of an arbitrary class associated with a given interface provides to other objects.
4.4.2. Class
Class is a group of entities (objects) that have similar properties, namely data and behavior. An individual member of a class is called an object of the class, or simply an object.
The behavior of an object in UML refers to any rules for the interaction of an object with the outside world and with the data of the object itself.
In diagrams, a class is depicted as a rectangle with a solid border, divided by horizontal lines into 3 sections:
The top section (the name section) contains the name of the class and other general properties (in particular, the stereotype).
The middle section contains a list of attributes
At the bottom is a list of class operations that reflect its behavior (actions performed by the class).
Any of the attribute and operation sections may not be shown (or both). For the missing section, you do not need to draw a dividing line and somehow indicate the presence or absence of elements in it.
Additional sections, such as Exceptions, may be introduced at the discretion of a particular implementation.
Rice. 9. Class Diagram Example
4.4.2.1.Class stereotypes
Class stereotyping is a mechanism for classifying classes into categories.
The UML defines three main class stereotypes:
Boundary (border);
Entity (entity);
Control (management).
4.4.2.2.Boundary classes
Boundary classes are those classes that are located on the boundary of the system and the entire environment. These are displays, reports, interfaces with hardware (such as printers or scanners), and interfaces with other systems.
To find boundary classes, you need to explore use case diagrams. Every interaction between an actor and a use case must have at least one boundary class. It is this class that allows the actor to interact with the system.
4.4.2.3.Entity classes
Entity classes contain stored information. They have the greatest meaning for the user, and therefore their names often use terms from the subject area. Usually, for each entity class, a table is created in the database.
4.4.2.4.Control classes
Control classes are responsible for coordinating the actions of other classes. Typically, each use case has one control class that controls the sequence of events for that use case. The control class is responsible for coordination, but does not carry any functionality in itself, since the other classes do not send it a large number of messages. Instead, he himself sends a lot of messages. The manager class simply delegates responsibility to other classes, which is why it is often referred to as the manager class.
There may be other control classes in the system that are common to several use cases. For example, there might be a SecurityManager class responsible for monitoring security-related events. The TransactionManager class handles the coordination of messages related to database transactions. There may be other managers to deal with other elements of the system's operation, such as resource sharing, distributed data processing, or error handling.
In addition to the stereotypes mentioned above, you can create your own.
4.4.2.5.Attributes
An attribute is a piece of information associated with a class. Attributes store encapsulated class data.
Because the attributes are contained within the class, they are hidden from other classes. Because of this, it may be necessary to specify which classes have the right to read and modify attributes. This property is called attribute visibility.
The attribute can have four possible values for this parameter:
Public (general, open). This visibility value assumes that the attribute will be visible to all other classes. Any class can view or change the value of an attribute. In accordance with UML notation, a common attribute is preceded by a "+" sign.
Private (closed, secret). The corresponding attribute is not visible to any other class. A private attribute is denoted by a "-" sign in accordance with UML notation.
Protected (protected). Such an attribute is available only to the class itself and its descendants. The UML notation for a protected attribute is the "#" sign.
Package or Implementation (batch). Assume that the given attribute is shared, but only within its package. This type of visibility is not indicated by any special icon.
With the help of closedness or security, it is possible to avoid the situation when the attribute value is changed by all classes of the system. Instead, the attribute modification logic will be wrapped in the same class as the attribute itself. The visibility options you set will affect the generated code.
4.4.2.6.Operations
Operations implement class-related behavior. An operation has three parts - a name, parameters, and a return type.
Parameters are the arguments that the operation receives as input. The return type refers to the result of the action of the operation.
A class diagram can show both the names of operations and the names of operations along with their parameters and return type. To reduce the load on the diagram, it is useful to show only the names of operations on some of them, and their full signature on others.
In UML, operations have the following notation:
Operation Name (argument: argument data type, argument2: argument2 data type,...): return type
There are four different types of operations to consider:
Implementation operations;
Management operations;
Access operations;
Auxiliary operations.
Implementation operations
Implementor operations implement some business functions. Such operations can be found by examining interaction diagrams. Diagrams of this type focus on business functions, and each message in the diagram can most likely be associated with an implementation operation.
Each implementation operation must be easily traceable to the corresponding requirement. This is achieved at various stages of the simulation. The operation is derived from the message in the interaction diagram, the messages are derived from the detailed description of the flow of events, which is generated based on the use case, and the latter based on the requirements. Being able to trace this entire chain helps ensure that each requirement is implemented in the code, and each piece of code implements some requirement.
Management operations
Manager operations manage the creation and destruction of objects. Class constructors and destructors fall into this category.
Access operations
Attributes are usually private or protected. However, other classes sometimes need to view or change their values. There are access operations for this. This approach makes it possible to safely encapsulate attributes within a class, protecting them from other classes, but still allowing controlled access to them. Creating Get and Set operations (getting and changing a value) for each attribute of a class is a standard.
Auxiliary operations
Auxiliary (helper operations) are those operations of a class that are necessary for it to fulfill its responsibilities, but about which other classes should not know anything. These are private and protected class operations.
To identify transactions, do the following:
1. Study sequence diagrams and cooperative diagrams. Most of the messages in these diagrams are implementation operations. Reflective messages will be auxiliary operations.
2. Consider control operations. You may need to add constructors and destructors.
3. Consider access operations. For each class attribute that other classes will need to work with, you need to create Get and Set operations.
4.4.2.7.Connections
A relationship is a semantic relationship between classes. It gives a class the ability to learn about the attributes, operations, and relationships of another class. In other words, in order for one class to send a message to another in a sequence or cooperative diagram, there must be a connection between them.
There are four types of relationships that can be established between classes: associations, dependencies, aggregations, and generalizations.
Communication association
An association is a semantic relationship between classes. They are drawn on the class diagram as an ordinary line.
Rice. 10. Communication association
Associations can be bidirectional, as in the example, or unidirectional. In the UML, bidirectional associations are drawn as a simple line with no arrows, or with arrows on both sides of the line. A unidirectional association has only one arrow showing its direction.
The direction of an association can be determined by examining sequence diagrams and cooperative diagrams. If all messages on them are sent by only one class and received only by another class, but not vice versa, there is a unidirectional communication between these classes. If at least one message is sent in the opposite direction, the association must be bidirectional.
Associations can be reflexive. Reflexive association means that one instance of a class interacts with other instances of the same class.
Communication addiction
Dependency relationships also reflect the relationship between classes, but they are always unidirectional and show that one class depends on definitions made in another. For example, class A uses methods of class B. Then, when class B changes, it is necessary to make corresponding changes in class A.
A dependency is represented by a dashed line drawn between two diagram elements, and the element anchored at the end of an arrow is said to be dependent on the element anchored at the beginning of that arrow.
Rice. 11. Communication addiction
When generating code for these classes, no new attributes will be added to them. However, the language-specific operators needed to support communication will be created.
Communication aggregation
Aggregations are a tighter form of association. Aggregation is the connection between the whole and its part. For example, you might have a Car class, as well as Engine, Tire classes, and classes for other car parts. As a result, an object of class Car will consist of an object of class Engine, four objects of Tires, etc. Aggregations are visualized as a line with a rhombus for a class that is an integer:
Rice. 11. Communication aggregation
In addition to simple aggregation, the UML introduces a stronger form of aggregation called composition. According to composition, an object-part can only belong to a single whole, and, moreover, as a rule, the life cycle of parts coincides with the cycle of the whole: they live and die with it. Any removal of the whole extends to its parts.
This cascading deletion is often considered part of the definition of aggregation, but it is always implied when the role multiplicity is 1..1; for example, if a Customer needs to be deleted, then that deletion must be propagated to Orders (and, in turn, Order Lines).
UML is a unified graphical modeling language for describing, visualizing, designing and documenting OO systems. UML is designed to support the process of PS modeling based on the OO approach, to organize the relationship between conceptual and program concepts, and to reflect the problems of scaling complex systems. UML models are used at all stages of the software life cycle, from business analysis to system maintenance. Different organizations can use the UML in their own way, depending on their problem areas and the technologies used.
A Brief History of UML
By the mid-1990s, several dozens of OO modeling methods were proposed by various authors, each of which used its own graphical notation. At the same time, any of these methods had its strengths, but did not allow to build a sufficiently complete PS model, to show it “from all sides”, that is, all the necessary projections (See article 1). In addition, the absence of an OO modeling standard made it difficult for developers to choose the most appropriate method, which prevented the widespread use of an OO approach to software development.
At the request of the Object Management Group (OMG) - an organization responsible for adopting standards in the field of object technologies and databases, the urgent problem of unification and standardization was solved by the authors of the three most popular OO methods - G. Booch, D. Rambo and A. Jacobson, who combined Efforts created UML version 1.1, approved by OMG in 1997 as a standard.
UML is a language
Any language consists of a dictionary and rules for combining words to make meaningful constructions. So, in particular, programming languages are arranged, such is the UML. Its distinctive feature is that the vocabulary of the language is formed by graphic elements. Each graphic symbol has specific semantics, so a model created by one developer can be unambiguously understood by another, as well as by a tool that interprets the UML. From this, in particular, it follows that a PS model presented in UML can be automatically translated into an OO programming language (such as Java, C ++, VisualBasic), that is, with a good visual modeling tool that supports UML, by building a model , we will also get a blank of the program code corresponding to this model.
It should be emphasized that UML is a language, not a method. It explains what elements to create models from and how to read them, but says nothing about which models and in what cases should be developed. To create a method based on UML, it is necessary to supplement it with a description of the PS development process. An example of such a process is the Rational Unified Process, which will be discussed in later articles.
UML vocabulary
The model is represented in the form of entities and relationships between them, which are shown on diagrams.
Essences are abstractions that are the main elements of models. There are four types of entities - structural (class, interface, component, use case, cooperation, node), behavioral (interaction, state), grouping (packages) and annotative (comments). Each entity type has its own graphical representation. Entities will be discussed in detail when studying diagrams.
Relations show different relationships between entities. The following types of relationships are defined in the UML:
- Addiction shows such a relationship between two entities, when a change in one of them - independent - can affect the semantics of the other - dependent. A dependency is represented by a dotted arrow pointing from the dependent entity to the independent entity.
- Association is a structural relationship showing that objects of one entity are related to objects of another. Graphically, an association is shown as a line connecting the related entities. Associations are used to navigate between objects. For example, the association between the classes "Order" and "Product" can be used to find all the products specified in a particular order - on the one hand, or to find all orders that contain this product - on the other. It is clear that the corresponding programs must implement a mechanism that provides such navigation. If navigation is required in only one direction, it is indicated by an arrow at the end of the association. A special case of association is aggregation - a relationship of the form "whole" - "part". Graphically, it is highlighted with a rhombus at the end near the entity-whole.
- Generalization is a relationship between a parent entity and a child entity. Essentially, this relationship reflects the property of inheritance for classes and objects. The generalization is shown as a line ending with a triangle pointing towards the parent entity. The child inherits the structure (attributes) and behavior (methods) of the parent, but at the same time it can have new structure elements and new methods. The UML allows multiple inheritance when an entity is related to more than one parent entity.
- Implementation- the relationship between the entity that defines the specification of behavior (interface) with the entity that defines the implementation of this behavior (class, component). This relationship is commonly used in component modeling and will be described in more detail in subsequent articles.
Diagrams. The UML provides the following diagrams:
- Diagrams describing the behavior of the system:
- State diagrams (State diagrams),
- Activity diagrams,
- Object diagrams,
- Sequence diagrams,
- Collaboration diagrams;
- Diagrams describing the physical implementation of the system:
- Component diagrams;
- Deployment diagrams.
Model control view. Packages.
We have already said that in order for a model to be well understood by a person, it is necessary to organize it hierarchically, leaving a small number of entities at each level of the hierarchy. UML includes a means of organizing a hierarchical representation of a model - packages. Any model consists of a set of packages that can contain classes, use cases, and other entities and diagrams. A package can include other packages, which allows you to create hierarchies. The UML does not provide separate package diagrams, but they may appear in other diagrams. The package is displayed as a rectangle with a tab.
What UML provides.
- hierarchical description of a complex system by highlighting packages;
- formalization of functional requirements for the system using the apparatus of use cases;
- detailing the requirements for the system by constructing diagrams of activities and scenarios;
- selection of data classes and construction of a conceptual data model in the form of class diagrams;
- selection of classes that describe the user interface, and the creation of a screen navigation scheme;
- description of the processes of interaction of objects in the performance of system functions;
- description of the behavior of objects in the form of diagrams of activities and states;
- description of software components and their interaction through interfaces;
- description of the physical architecture of the system.
And the last…
Despite all the attractiveness of UML, it would be difficult to use it in real PS modeling without visual modeling tools. Such tools allow you to quickly present diagrams on the display screen, document them, generate blanks of program codes in various OO programming languages, and create database schemas. Most of them include the possibility of reengineering program codes - restoring certain projections of the PS model by automatically analyzing the source codes of programs, which is very important for ensuring that the model and codes match and when designing systems that inherit the functionality of predecessor systems.
UML (Unified Modeling Language - unified modeling language) - a graphical description language for object modeling in the field of software development. UML is a general language, it is an open standard that uses graphical notation to create an abstract model of a system, called a UML model. UML was created to define, visualize, design and document mostly software systems. UML is not a programming language, but code generation is possible in the runtime tools for UML models as interpreted code. Wikipedia
Commercial Products
Microsoft Visio
Type: commercial software
A popular software product from Microsoft that allows you to draw rich diagrams, including UML:
Starting from the 2010 version, it became possible to publish diagrams on the web (SharePoint + Visio Services):
Visio Viewer- a free program that allows you to view previously created Visio diagrams. You can download at %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.
%0A
Microsoft%20Visual%20Studio%202010
%0A%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).
%0A
%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modelling,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.
%0A
%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sequence%20Diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.
%0A%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Use%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:
%0A%0A%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualization%20and%20Modeling%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:
%0A- %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0 %0A
- %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrams%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagrams %0A
%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualization%20and%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20
IBM Rational Rose
Opportunities:
- Use case diagram (diagrams of precedents);
- Deployment diagram (topology diagrams);
- Statechart diagram (state diagrams);
- Activity diagram (activity diagrams);
- Interaction diagram (interaction diagrams);
- Sequence diagram (diagrams of sequences of actions);
- Collaboration diagram (collaboration diagrams);
- Class diagram (class diagrams);
- Component diagram (component diagrams).
Screenshots:
open source programs
StarUML
Opportunities:
- UML 2.0 support
- MDA (Model Driven Architecture)
- Plug-in Architecture (you can write in COM compatible languages: C++, Delphi, C#, VB, ...)
StarUML is written mainly in Delphi, but components can also be added in other languages, such as C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Below are some screenshots.
Class Diagram:
Use case diagram:
ArgoUML
Supported charts:
- class
- State
- use cases
- Activity
- Collaboration
- Deployment
- Sequence
Opportunities:
- Support for nine UML 1.4 diagrams
- Platform independent (Java 5+)
- UML 1.4 Standard Metamodel
- XMI support
- Export to GIF, PNG, PS, EPS, PGML and SVG
- Languages: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
- OCL support
- Forward, Reverse Engineering
Screenshot:
