Practical uses of modeling in enterprises

By Suvorov Nikolai (nmsuvorov@edu.hse.ru)

Visual modeling can be applied in various domains besides the software engineering but in this sphere, modeling can be used for a huge variety of purposes including graphical formalization of requirements, system design, generation of program code based on created models, etc. In addition, modeling can be used as a common language for people with different backgrounds – for instance, it can be used in communication between analysts and developers, or it can even be used in communication between people who know different languages. Nevertheless, visual modeling is still not widely spread in enterprises and there are several reasons for it. This essay discusses how and where modeling is most often used in enterprise and what are the limitations of its practical usage which led to relatively low prevalence of modeling nowadays.

To start with, it is necessary to define what visual modeling languages are currently used in software engineering and what is their purpose. Such languages may include UML [1] for designing software systems, BPMN [2] and DFD [3] for modeling business processes and ERD [3] for designing databases. Despite of the existence of various visual modeling languages, UML has been heralded by many as the “de-facto standard” [4] and “the lingua franca” [5,6] of software engineering. One of the reasons is that this notation can be used for all the aforementioned purposes: UML activity diagrams can be used to model business processes, UML class diagrams can be used for designing databases and simultaneously various UML diagrams can be used for designing the architecture. However, other notations are still in use: for instance, data flow and entity relation diagrams are still broadly used by people who follow Structured Systems Analysis and Design Method (SSADM) [7] while the BPMN is currently the leading standard for process mining [8]. Nevertheless, currently there is almost no formal notation which can struggle with UML in object oriented modeling, which is mainly used in enterprise software design, that is why the essay covers the practical usage of this notation in detail.

There are several surveys which examine the usage of UML in real software projects, and most of them show that this notation is rarely consistently used: both in sense of the full use in all projects and in sense of using the UML on all the stages of development. According to [9], more than 60% of respondents, who somehow use UML at work, used UML only in large projects or used it sporadically and only 27% used UML consistently on all projects. In contrast, [10] implies that in 50 observed companies only in 11 companies UML is used at least in “a personal, selective and informal way”, whereas in other companies it is not used at all. It is also worth mentioning that the latter survey is done after 9 years of the former one, so a certain decrease in consistent UML usage can be detected.

According to [10], most of respondents who use UML selectively use it for as long as it is considered useful, after which it is set aside or even discarded. Thus, the UML is mostly used at the early design stage and at the process of elicitation of requirements. However, some customers require including UML diagrams into technical documentation, therefore, in some cases the UML is still used throughout the whole process of development, but it is rather the desire of the customer than the desire of the development team. The respondents mention that one of the key intentions to use UML for them is its help in collaboration with other colleagues (even with international ones): it can be used to propose the system architecture to team and also to demonstrate main use cases and show lifecycles of data to newcomers.

As for diagram types, there are 3 main UML diagrams which are currently used in industry: class diagrams, sequence diagrams and activity diagrams [10]. Class diagrams are primarily used to represent architecture, conceptual models and to perform concept analysis of the domain. Sequence diagrams are used for requirements and behavior elicitation, and activity diagrams are mainly used for ordering processes, eliciting behavior, and modeling concurrency. All these diagrams are used by more than 54% of companies who use UML selectively. As for other diagrams, [10] mentions only state machines diagrams and use case diagrams but their usage is much less frequent. As for modeling tools, various modeling systems are currently used in enterprise, including IBM Rational Software Architect, MagicDraw, Eclipse Papyrus, MS Visio, etc. Nevertheless, many people still prefer to use pencil and paper to generate their diagrams.

It is worth mentioning that UML can also be used in code generation. In this situation developers usually deal only with models which helps to ensure high quality of programs and prevent errors. CASE-tools are mainly used for these purposes: they automate the process of system development due to possibilities of visual modeling, interpretation of models and/or code generation based on the created models. IBM Rational Software Architect, MagicDraw and Papyrus are mainly used for these purposes [11]. As for Russian developments, there are CaseBerry [12] and FlexBerry [13] platforms, which allow users to generate software based on UML diagrams. However, all the autogenerated systems tend to be used mainly in companies where the software is a subsystem rather than the main product of the company [10], which leads to the fact that the actual usage of such systems remains at a low level.

To understand why the usage of modeling in enterprise is not so widely spread nowadays, it is needed to look at limitations of tools used for modeling. Despite of the modeling notation used, there are some user requirements which are common for all the tools which implement modeling notations. There are certain papers, such as [14, 15], which define such requirements for modeling tools. Among the main requirements the following can be highlighted:

• the ability to use different languages,
• the ability to perform simulation modeling,
• consistency control between different diagrams,
• monitoring of the syntactical correctness of models,
• the ability to generate artifacts (reports or program code),
• possibility of group work on models,
• ease of using the product.

In addition, the paper [15] notes the importance of the integration capabilities of the modeling system as well as the importance of monitoring model changes and controlling model versions.

Generally, no tool satisfies all these requirements, which probably leads to relatively low usage of modeling tools, but it is also important to look at modeling tool limitations which users themselves denote as key factors which have led to rejection of using visual modeling by them and by their companies. Such limitations include:

• lack of checks for redundancy and quality of models, which provides users with possibility to construct difficult-to-understand models, which can often contain errors [16],
• lack of support for connections between models and model elements, which means that when changing one model, it is necessary to manually update all the models associated with the source one [10],
• lack of possibilities for developing own languages or using several languages at the same time, whereas software development rarely handles without the simultaneous use of various notations [10].

Although some people prefer to use a paper and a pencil to generate diagrams, some of these limitations influence them, too. The most obvious restriction in this case is the necessity to draw a model from scratch if something needs to be changed. Currently this limitation significantly restricts the usage of modeling notations without regard what is used for model generation, as most of the projects are currently done in Agile methodology where requirements fluctuate during the whole development process which requires to update all the models regularly and check that all of them are still consistent. That is why, according to [9] consistent modeling is primarily used only in projects with relatively high development cost, where most of the possible risks must be avoided.

Unfortunately, consistent modeling is becoming less and less popular in industry and the reasons for this trend are presented above. Despite all the aforementioned limitations, in my view, the thing which actually has the highest influence upon the decrease in usage of modeling is the omnipresent application of Agile methodology and Scrum and Kanban techniques. Generally, it makes consistent modeling too expensive, that is why modeling is currently mainly used for as long as it is considered useful. Nevertheless, there are certain works, including [17], which investigate this problem and provide new approaches of using modeling which are applicable to Agile methodologies. Despite of all the restrictions mentioned in the essay, I guess that modeling will still be used at least sporadically in most projects as it significantly helps in collaborating with colleagues, eliciting requirements and designing high-level architecture.

1. OMG Unified Modeling Language (OMG UML) Specification, OMG Document Number: formal/2017-12-05, Version 2.5.1, Dec. 2017.
2. OMG Business Process Model and Notation (BPMN) Specification, OMG Document Number: formal/2011-01-03, Version 2.0, Jan. 2011.
3. Shavrin S.M., Lyadova L.N., and Chuprina S.I., “Modeling and design of information systems: educational and methodical manual”, Perm State University, Perm, 2007, 154 p.
4. Tichy W., “Empirical software research: an interview with Dag Sjøberg”, Ubiquity, vol. 2011, pp. 1-14.
5. Selic B., Kent S., and Evans A., “UML 2000 – Advancing the Standard,” LNCS, vol. 1939, 575 p.
6. Störrle H., “Describing Process Patterns with UML,” Software Process Technology. LNCS, vol. 2077, pp. 173-181.
7. Ashworth C.M., “Structured systems analysis and design method (SSADM),” Information and Software Technology, vol. 30, pp. 153-163.
8. Leopold H., Mendling J., and Günther O., “Learning from Quality Issues of BPMN Models from Industry,” IEEE Software, vol. 33, no. 4, pp. 26-33.
9. Grossman M., Aronson J., McCarthy R.V., “Does UML make the grade? Insights from the software development community,” Information and Software Technology, vol. 47, pp. 383-397, 2005.
10. Marian P., “UML in practice,” 35th International Conference on Software Engineering, 18-26 May 2013, San Francisco, CA, USA, pp. 722–731.
11. Planas E., Cabot J., “How are UML Class Diagrams built in practice? A usability study of two UML tools: MagicDraw and Papyrus,” Computer Standards & Interfaces, vol. 67, pp. 1-13, 2020.
12. CASEBERRY. О продукте CASEBERRY. URL: https://caseberry.net/index.html.
13. Flexberry platform. Архитектура. URL: https://flexberry.net/ru/platform-architecture.html?1.
14. Sannikova A.Yu., “Modeling of business processes of customer relationship management,” Scientific journal NovaUm.Ru, vol. 10, pp. 109-113. 2017.
15. Berdonosov V. and Redkolis E., “TRIZ-fractality of computer-aided software engineering systems,” Procedia Engineering, vol. 9, pp. 199-213, 2011.
16. Gruhn V. and Laue R., “Reducing the Cognitive Complexity of Business Process Models,” Proceedings of the 8th IEEE International Conference on Cognitive Informatics, ICCI 2009, pp. 339-345, 2009.
17. Rumpe B., “Agile Modeling with UML,” Cham: Springer International Publishing, 388 p., 2017.