ITKarma picture
Image from www.uml.org

This article is about UML and its current uses. A bit of historical information, very little, only the main points:
  • UML was born in the 90s as a result of work on creating an object-oriented modeling language.
  • Specification 1.0 was released in 1997.
  • Specification 2.0 was released in 2005.
  • To date, UML 2.5, several profiles have evolved, such as SysML and SoaML .

If you look at how UML was used then and now, and think it over, you can draw the following conclusion: Let the version of UML be 2.5 now, but the principles of using the language have not changed since the first version.

And as a result: Analysts use the concept of a description of software systems, which was laid down more than 20 years ago. The concept itself is good, but you need to relate it to the place and context of application.

If we continue this analysis of the use of UML, as well as correlate it with the requirements of the current time, the conclusions are as follows:

  • All methods of using UML "go around" Use Case Driven Development.
  • UML models lack integrity. The approach chosen to separately describe aspects of structure and behavior, business levels, and applications complicates the perception of models as a whole.
  • UML is an object-oriented language, which makes it difficult to express other concepts with it.

I won’t say anything about the Use Case Driven Development approach; one of its incarnations is the Rational Unified Process. Next, I’ll talk about the last two points.

Aspects of presentation


UML consists of many diagrams. Each of which obeys its own rules, uses elements and arrows in its own understanding. And from the outside it does not look like a unified language, but as a set of different representations, which is often presented as an opportunity to look at a subject area from different points of view. With the same success, you can call the Swiss knife a unified tool, which is essentially a set consisting of blades, screwdrivers, openers, spoons, forks and all on one handle.

ITKarma picture

What does an analyst do when he tries to fit all the diagrams into one model? He begins to build hybrid charts and link tables. The result is not a single model, but a lot of diagrams, to which more diagrams and tables have been added.

ITKarma picture

Presentation Levels


Suppose a business analyst described a subject area using UML diagrams. And now a system analyst or the same analyst is required to formulate a model of a software system. If the analyst is focused on UML, then he will begin to create representations corresponding to those made earlier, but already within the system. It will look again in the form of similar diagrams.

ITKarma picture

And what will the analyst do when he wants to compare the description of the subject area and the model of the system?

He again begins to build hybrid diagrams, link tables, and traces.

The result is again many charts and tables.

ITKarma picture

There is still to be noted that UML is an old language and there are a huge number of books and old examples for it. Which mainly describes cases of transition from a non-automated business to an automated one. And analysts learn from these examples. But today, information technology has penetrated everywhere. The “Business separately, IT separately” approach is not acceptable .

Service Oriented Approach


UML is an object-oriented language, which makes it difficult to express other concepts with it. For example, service oriented. There is no “Service” concept in the standard UML profile, but there is a SoaML profile, which is presented as a modeling language Service Oriented Architecture.

I’ll briefly talk about a service-oriented approach, so that it is further understood why SoaML is not suitable for its modeling. Based on the interpretation of definitions from TOGAF .

For a simple formalization of a service-oriented approach, we need 2 abstractions:
  • Process - control flow between/over services. It must also be said that the process is a sequence of actions that together achieve a certain result.
  • Service - an element of behavior that provides certain functionality in response to requests from subjects or other services. The service provides or supports features , has an explicit interface and is managed explicitly.

Let's see how this is modeled on SoaML. At the same time, we will compare how object-oriented modeling in UML and service-oriented modeling in SoaML will differ.

Man and Shop


Task: Describe a model for purchasing a product in a store.

The object-oriented approach, I think, is clear and simple to everyone. In order not to waste time, we will not consider the business level. I think everyone can imagine in their head the advising Use Case and its detail in the form of activity diagrams or sequence diagrams.

ITKarma picture

A person acts not as a user, but as one of the sides of interaction.
Now we will solve this problem using SoaML, strictly in accordance with the specification .

ITKarma picture

In this diagram, we define the community of interacting, this is the Store and the Person.
We determine the business process “Selling Goods” between them, in which the Store acts as a “seller” and the Person as a “buyer."
ITKarma picture

Based on the business process, we can now identify the following business service, in SoaML, the ServiceContract classifier is used for this.

ITKarma picture

Within the framework of this service: The seller acts as a provider, and the Buyer acts as a consumer.
The seller, as a supplier, provides one “sell” operation. The business analysis is complete, go to the system level.

We need to simulate at the system level an updated version of our business process for selling goods. To do this, I chose a sequence diagram, you can use any other behavioral diagram.

ITKarma picture

From the updated business process, we can single out one “sell” operation, arrange it in the basic “Able to Sell” interface.

Next, we need to describe the service interfaces that will be used to implement the service.

We get the following service interfaces:
  • "The desire to sell", which is inherited from the interface "able to sell";
  • "Need to buy", which depends on the interface "able to sell."

ITKarma picture

Now you can imagine the target service model in the form of a composite structure diagram.

ITKarma picture

Compare the results of object-oriented modeling in UML and service-oriented modeling in SoaML.

ITKarma picture

Visually, the whole difference is in these small squares on the border of the components. I marked them in red. Is that all the difference?

The difference between object-oriented and service-oriented modeling is actually there, just SoaML has reduced everything to objects. But more about that later.

And now let's finish the consideration of SoaML in a more complex case, then we will get about the following schemes.

ITKarma picture

What is wrong, in my opinion, with SoaML.

First : Again, problems with the integrity of the language and the connection between the business level and the application level, you yourself have seen how difficult everything is related to each other.

Secondly : The service is described as an object of the structure, this is not good. In Russian speech, the phrase "The provider represents the service" is common, this is a component-oriented approach that is implemented in SoaML. But in the case of a service-oriented paradigm, it’s more correct to say “The supplier provides the service.” And if you translate the “Service” into Russian in another way, then everything immediately falls into place: “The supplier provides the service ”. From this point of view, “Service” is not “Object”, it is “Behavior”.

Third : On the slide about service-oriented architecture, I talked about two abstractions: Process and Service. To consider and describe them through the prism of an object-oriented approach is, to put it mildly, an intense task.

Paradigms


Back to UML. UML, through its paradigm, is trying to describe other paradigms.

ITKarma picture

And if everything turns out with a component-oriented paradigm, it can be represented as a logical continuation of an object-oriented one. That with the service-oriented turned out badly.
In this case, expressing one paradigm through another is a bad idea.
I demonstrated the use of such a concept with SoaML using the example of the “Man and Shop” task.

It relates to paradigms better as indicated below.

ITKarma picture

Demonstrate how service-oriented modeling is different from object-oriented.

Man and Dog


Task: Describe a model of interaction - A person walks with a Dog.

Without a second thought, this task will probably be solved by any student of the technical faculty. In schools and universities in the relevant specialties, object-oriented programming is mandatory. The object-oriented approach is presented below.

ITKarma picture

And what will a model with a service-oriented approach look like? I don’t know if the student will answer such a question.

This is what I would like to get. (Think for a minute yourself, then watch)
ITKarma picture

You need to understand that this is a simple task and this is a simple model. But it reflects the essence of a service-oriented approach. A person provides (provides) for the Dog a service (service) "Walk".

You can recall the history of object-oriented programming. How even very authoritative people such as Edsger Dijkstra and Niklaus Wirth were skeptical at the beginning of his appearance. And still, some people consider OOP to be undeserving of attention.

Well, this model can also cause smiles. The fact is that a service-oriented paradigm does not have sufficient support at the initial level of programming and design. For programmers, support is provided only by frameworks such as Java Enterprise Edition or Spring. I think that programmers get to them with a head already formatted for an object-oriented approach.
Analysts are building their ideas about service-oriented architecture and designing for articles on the Internet that have a different understanding of what it is, and some articles without a deep immersion in the specifics and technical details are generally incomprehensible. As a result, analysts return to the generally accepted Use Case between the system and users. It is also common that the architecture of the system and its component composition are already fixed by the architect or due to the chosen platform. And then analysts again simply describe the Use Case between the system and users.

Compare the object-oriented approach and this seemingly ridiculous one, where the Man renders the Walk service to the Dog. When it ceases to be funny for you, but the object-oriented approach seems to be funny, where the Person implements the “walk” method, the Dog is fed to the entrance !!! That's when the understanding of the service-oriented paradigm came to you.

It should be noted that these paradigms are quite compatible. A man can still perform his usual actions: to sleep and dance, and the Dog to bark.
Another point: In this example, I introduced a new concept of "Service". However, I have not yet clearly defined the rules for its use, but it differs from that in SoaML. Here you need to be careful, do not get too carried away with this, since this kind of extension refers to metamodeling. It may happen that the created models turn out to be contradictory and obscure.

Instead of a conclusion


  • UML limits the analyst’s ability to choose a modeling approach. If you drive everything into one paradigm or express a subject area with an approach that is unusual for it, then your idea may turn out to be a distortion. Therefore, choose the appropriate modeling languages.
  • Do not get far from developers in knowledge of modern technologies and their development directions. It is better to have knowledge deeper than just in general terms. Otherwise, you will not be able to build models that correspond to new approaches in information technology.
  • Problems like those found in UML can be found in any modeling language. Any paradigm, any model is flawed relative to the real world. Learn to think with different approaches, unlike UML, a person is able to do this.
.

Source