I will gladly answer this question. However, you need to know that there is no single correct method for achieving this goal. There is a set of techniques that are supposed to help us with this. Today I will present you the methods that we use in our company to implement projects from small configurators to complex systems. Regardless of whether you are a programmer who plans to develop your own startup after hours, or a businessman planning to invest in a new Facebook, you will find here a handful of information that will help you operate between the worlds of business and programming .
Contents
Different points of view - one goal
Use Cases - First Sketch of Our App
Activity diagrams - how our user should behave
Class Diagrams - Between the World of Business and Programming
Different points of view - one goal
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 hungary telemarketing data 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 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.