The biggest problem that arises during application development is communication between business and programmers. On the one hand, we have a person who, when hearing about a new project, already has before their eyes all the latest frameworks that every programming blog is buzzing about. On the other hand, there is a client who imagines how beautiful and perfect their new application will be. Interestingly, the same situation occurs in the minds of novice programmers planning their own application, on the one hand they rush to code as quickly as possible, on the other they think about their project very superficially, focusing mainly on the user interface (interface
). And this is where UML comes in - a language created for modeling systems . It provides tools (diagrams) thanks to which the programmer can write the application project in a way that is unambiguous and understandable to the client. Thanks to this, we are able to detect logical errors in our application at an early stage. In our company, we adopt the principle that it is better to spend 2 weeks on talks and modeling than to find out after months of coding that part of the application was not fully thought out and requires expensive changes to the entire system.Web, mobile or computer application - for a designer it is not a problem It is worth remembering that at the application design stage we should define the problem we intend to solve, then create a solution project, and only then select the appropriate technology. Thanks to this, we are able to repeat the same process when designing any application.
Use Cases - First Sketch of Our App
During the first conversations with the client, we create a use case diagram that shows us who will use our application (actors) and what actions they will be able to perform (use cases). At this point, we talk to the client about what actions a given actor can perform in the first version of the system or in the future. It is always better to model a larger system than it is initially supposed to be created, to enable its easy expansion in the future. So let's get to work. Let's imagine that we have an online system for booking a dentist appointment to design. The first step is to list the actors who will appear in our system. In our case, it will be:
client - a person who intends to make a reservation,
dentist - who will be able to view his/her schedule,
administrator - who will be able to manage schedules and dentists.
In the actor diagram we represent them with a human symbol:
Actors in UML diagram
We then move on to writing out basic use cases and connecting them to our actors.
Use Case Diagram
The question is, have we listed all the use cases? Of course not. After all, in order for a customer to view the visits they have booked, they must first log in. That is, they must have an account. If they have an account, they may namibia telemarketing data forget the password, so they should be able to recall it. And so on, the longer we analyze a given project, the more cases we will find. Since I don't want this post to turn into a multi-page documentation of a system that will never be created, I will focus only on booking a visit.
There may be some dependencies between use cases, because during the execution of a given use case, another use case may sometimes be executed. We will connect such use cases with a relation that says that a given use case extends another ( extend ). When a use case must always be executed, we use the include relation . Importantly, at this point we do not specify in what order they should be executed.
Use Cases
We can already see that our diagram has grown significantly, even though we have only listed one of the cases that we declared at the beginning. We can also see that the actor can be not only a human, but also an external service that we will use. The question is whether we can assume that we have listed all the cases. After all, our client may expect that, for example, when displaying a list of terms, there will be a possibility to filter terms by date and time. Such cases should also be included in the diagram.
Use Case Diagram
We can already see that we can expand this diagram a lot, and during its creation many questions arise. And that's the point!
Having all the use cases listed, we know what size system we will be dealing with. This is the first moment when we can also make a preliminary time estimate.
Activity diagrams - how our user should behave
Okay, we already know more or less what our system will look like. We know who will use our system and what they will be able to do in it. It's time to answer the question of how they will do it. This is what activity diagrams are for. We create them for each use case separately. If a use case is extended or contains other cases, we can combine such diagrams into one.
Below you can see the activity diagram for the “filter by date” use case.
UML Activity Diagram
We can see that our UML activity diagram shows a certain process of how to decide which activity should be performed next. When creating online stores Wrocław , activity diagrams can help to precisely define the interactions of users with the system.
Class Diagrams - Between the World of Business and Programming
It's time to enter the world of programming in small steps. This is the most difficult part of application modeling itself, but also the most important. At this stage, in UML, we define classes that will be present in our system and the relationships between them. But what is a class?
In simple terms, a class is a description of some real object, in which we provide the parameters of the object and the actions it will be able to perform. For example, in our system there will be a customer who has a name, surname and email, and can also display their reservations, so we should create a Client class that will have the appropriate fields and methods. At this stage, it is worth switching to English, because these diagrams will be used by programmers to create applications. Creating web portals requires precise definition of classes and relationships between them, which is crucial for later implementation.