For some time, there has been a discussion about the value of modeling. Advocates of agile approach are not very happy to see models. Conservatives preferring the classic approach to the software development process are more likely to model.
Modeling costs. The tools are usually not much, but people (analysts, designers, architects) have a lot. There is no denying that the use of UML extends the process of building software. Is this time wasted? With the redundant modeling, it probably will. With a reasonable selection of techniques and appropriate methodology of the work of the production team, we gain profit during the development of the system, its expansion and current changes.
I am a supporter of careful modeling. In my opinion, their excess causes a considerable load on the team. Nevertheless, building models is of great value. Project documentation is a bit like a house project. A building bigger than a garage is not built without a design. (I ignore the fact that building a house requires design documentation and it is optional to build an information system that is many times more expensive than many homes.)
Documentation describing system operation, architecture and data is in my opinion the minimum. Documentation in UML allows for a conscious and less risky system expansion.
- allows you to discover new requirements
- increases the efficiency of the system description
- helps to give the right priorities to the requirements
In other words, regardless of whether we are building a new system or expanding the old one, having a model we are able to better manage the requirements and thus the whole undertaking, because we avoid more random activities that could lead to failure.
On the other hand, with a small change in the system, drawing large diagrams makes little sense. Note that changes to existing UML models are a good way to go.
So when is it worth modeling in UML?
In my opinion, models in UML should be:
- for large systems (for smaller ones too, but sometimes agile enough)
- for systems that process personal data, sensitive or support saving lives (regardless of size)
- when we want to control the complexity of the system
- when we want to describe how IT systems support individual steps of business processes
- when we plan to integrate systems (especially emphasis should be placed on models describing architecture and processed data in integrated systems)
- when we want to precisely describe the problem (requirements), solution (design) and context (architecture) of the system operation.
And finally, when we plan to build a house, we complete documents including its project. When building a house, we rely on its design. Of course, there are some changes (we change the walls, change the height of the window ,etc.), but nobody destroys everything and starts again. When implementing an application without documentation, it is often the case that we either render a wrongly written component (if it works as it is), or write it again (to make it work as it should). Building models in UML increases the probability that we will minimize the time losses associated with correcting (or rewriting) badly functioning components.