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

  • Prolaborate and Enterprise Architect A few weeks ago, in an article about Enterprise Architect Pro Cloud Server, I described one of the tools offered by Sparx Systems, which allows access to the model repository via a web […]
  • Kanban Workflow In the preceding Kanban post, I wrote about partially done work. I wrote that it is worth limiting partily done work. The WIP (Work In Progress) which is too high results in the fact that […]
  • 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 […]
  • Registration of Problems Identified During the Analysis I received an interesting question by e-mail: According to your knowledge, is there an object in EA that would be best suited for registering problems identified during business or […]
  • Requirements Documentation Based on Use Cases Use cases are used to document the functionality of the system and are based on two commonly used concepts: Use case diagramsSpecifications of use cases Objects Use case: The use […]

Leave a Comment

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

Scroll to Top