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

  • System Architecture On walls, boards and other surfaces, you do not see squares and rectangles connected with each other by lines. Next to them is the information of what these "squares are doing with each […]
  • Architect in Agile Team In the last post I described what I think about the role of an analyst in agile team. The second role that I would like to mention is the role of the architect. This role is defined in […]
  • Three Benefits of Use Cases I recommend each person to use the use cases particular in Agile projects. Below three are basic advantages that I think will convince you to use the use cases in Agile projects 1. […]
  • 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 […]
  • Reviews of Models in Enterprise Architect Software development is a process in which the reviews of the status of work are a daily or almost everyday situation. Verification of analytical and design works as well as architectural […]

Leave a Comment

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

Scroll to Top