Image from www.uml.org This
article is about UML and its current uses. Few 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 came out in 1997.
- Specification 2.0 was released in 2005.
- To date, UML 2.5, several profiles such as SysML and SoaML have been developed .
If you look at how the UML was applied then and now, and think about it, you can draw the following conclusion: Let the UML version is now 2.5, but the principles of using the language have not changed since the first version.
And as a consequence: Analysts use the concept of describing 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 UML application, and also correlate it with the requirements of the current time, then the conclusions are as follows:
- All techniques for using UML "go around" Use Case Driven Development.
- UML models lack integrity. The chosen approach of a separate description of aspects of structure and behavior, levels of business 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.
Presentation aspects
The UML is composed 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 the subject area from different points of view. With the same success, you can call the Swiss knife a unified tool, which in fact is a set consisting of blades, screwdrivers, openers, spoons, forks and all on one handle.
What does an analyst do when trying to link all charts into one model? He starts building hybrid charts and link tables. The result is not a single model, but a set of diagrams, to which more diagrams and tables have been added.
Presentation levels
Let's say a business analyst has described a subject area using UML diagrams. And now a systems analyst or the same analyst needs to form a model of a software system. If the analyst is focused on the UML, then he will begin to create views corresponding to those made earlier, but already within the framework of the system. It will look like similar diagrams again.
What will the analyst do when he wants to compare the description of the subject area and the model of the system?
He starts building hybrid diagrams, link tables and traces again.
The result again is a lot of charts and tables.
It should also be noted here that UML is an old language and there are a lot of books and old examples for it.In which mainly cases of transition from a manual business to an automated one are described. And analysts learn from these examples. But today information technologies have penetrated everywhere. The approach "Business separately, IT separately" is unacceptable .
Service-oriented approach
UML is an object-oriented language, which makes it difficult to express other concepts with it. For example, service oriented. In the standard UML profile there is no concept of “Service”, but there is a SoaML profile , which is presented as a modeling language for service-oriented architecture.
I will briefly talk about the service-oriented approach, so that later it will be clear why SoaML is not suitable for modeling it. Based on the interpretation of the definitions from TOGAF .
For a simple formalization of a service-oriented approach, we need 2 abstractions:
- A process is a control flow between / over services. It must also be said that a process is a sequence of actions that together achieve a certain result.
- Service - an element of behavior that provides a certain functionality in response to requests from subjects or other services. A service provides or supports capabilities , has an explicitly defined interface, and is explicitly controlled.
Let's see how this is modeled in 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 the model of buying goods in the 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 layer. I think everyone can imagine in their head the advising Use Case and its detailing in the form of an activity diagram or a sequence diagram.
A person acts not as a user, but as one of the parties to the interaction.
Now we will solve this problem using SoaML, strictly in accordance with the specification .
In this diagram, we define the community of interacting people, 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”.
Based on the business process, we can now identify the next business service, in SoaML, the ServiceContract classifier is used for this.
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. Business analysis is over, we go to the system level.
We need to model at the system level an updated version of our business process for selling a product. For this, I chose a sequence diagram, you can use any other behavioral diagram.
From the updated business process, we can single out one operation “sell”, we will arrange it into the basic interface “Who knows how to sell”.
Next, we need to describe the service interfaces that will be used to implement the service.
We get the following service interfaces:
- "Desire to sell", which is inherited from the "Selling" interface;
- "Need to Buy", which depends on the "Selling" interface.
You can now represent the target service model as a composite structure diagram.
Let's compare the results of object-oriented modeling in UML and service-oriented modeling in SoaML.
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?
There really is a difference between object-oriented and service-oriented modeling, it's just that SoaML has reduced everything to objects. But more on that later.
And now let's finish the consideration of SoaML in a more complex case, then we will get about the following schemes.
What is wrong, in my opinion, with SoaML.
Firstly: Again, problems with the integrity of the language and the connection between the level of business and the level of applications, you yourself saw how difficult everything is related to each other.
Second : Service is described as a structure object, this is not good. In Russian speech, the phrase "The provider represents a service" is common, this is a component-oriented approach that is implemented in SoaML. But in the case of the service-oriented paradigm, it is more correct to say "The supplier provides a service." And if you translate "Service" into Russian differently, then everything immediately falls into place: "The supplier provides a service ." From this point of view, "Service" is not an "Object", it is a "Behavior".
Thirdly: On the slide about service-oriented architecture, I talked about two abstractions: Process and Service. Viewing and describing them through the lens of an object-oriented approach is, to put it mildly, a stressful task.
Paradigms
Back to UML. The UML tries to describe other paradigms through its paradigm.
And if everything works out with the component-oriented paradigm, it can be presented as a logical continuation of the object-oriented one. That with a 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 "Person and Store" problem.
Applies to paradigms better as indicated below.
I will demonstrate how service-oriented modeling differs from object-oriented.
Man and Dog
Task: Describe a model of interaction - A person walks with a Dog.
Any student of the technical faculty will probably solve this problem without hesitation. Object-oriented programming is a must in schools and universities in the relevant specialties. The object oriented approach is presented below.
And what will a model with a service-oriented approach look like? I don't know if a student will answer such a question.
This is what I would like to receive. (Think for a minute for yourself, then see)
, . - . () () «».
, . - . () () «».
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 to this day, some people consider OOP to be unworthy of attention.
Well, this model can also cause smiles. The point is that the 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 base their understanding of service-oriented architecture and design on articles on the Internet that have different understanding of what it is, and some articles without deep diving into the specifics and technical details are generally obscure. As a result, analysts return to the generally accepted Use Cases 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 are determined by the chosen platform. And then analysts again simply describe the Use Case between the system and the users.
Compare the object-oriented approach and this seemingly ridiculous one, where the Man renders the Dog a "Walk" service. When it ceases to be ridiculous for you, and the object-oriented approach seems to be ridiculous, where the Person implements the “walk” method,the entrance to which the Dog is served !!! That's when you came to understand the service-oriented paradigm.
It should be noted that these paradigms are quite compatible. A person can still perform his usual actions: sleep and dance, and the Dog can bark.
One more point: In this example, I introduced a new concept "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 . , . .
- . , . .
- UML . , . , UML, .