When is it worth modeling in UML?

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.

Model building:

  • 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.

More from my site

  • Kanban Tasks In the previous entry, I wrote about the task board in Kanban. Now I will add some words about tasks and task cards. Kanban tasks are specified by means of a card. Many people prefer […]
  • Levels of Business Architecture and Business Process Modeling In the previous article of Modeling Business processes in the software development process, I described the meaning of modeling business processes. In my opinion, business processes […]
  • User Stories vs. Use Cases We are currently in a “strange situation”. There are user stores and usage case scenarios, of which the latter can be divided into formal and informal use cases as well as summaries of […]
  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]
  • The TAO Principle in the Software Development Process In larger companies or on the occasion of large ventures called projects, analysts are not one or two people but a group of people who develops requirements, business processes, specifies […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top