arch:modelingpracticalusage

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		 Previous revision
arch:modelingpracticalusage [2021/10/13 17:51] – created nmsuvorovarch:modelingpracticalusage [2026/08/29 07:59] (current) – external edit 127.0.0.1
Line 9: Line 9:
 ===== Current usage of modeling in practice ===== ===== Current usage of modeling in practice =====
  
-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 software design, that is why the essay covers the practical usage of this notation in detail.+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.+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. 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.
Line 17: Line 17:
 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. 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].+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.
  
 ===== Limitations which users face ===== ===== Limitations which users face =====
  
 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: 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 use different languages,
   * the ability to perform simulation modeling,   * the ability to perform simulation modeling,
Line 29: Line 30:
   * possibility of group work on models,   * possibility of group work on models,
   * ease of using the product.   * 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. 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: 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 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 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].   * 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. 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.
  
 ===== Conclusion ===== ===== Conclusion =====
  
-Unfortunately, consistent modeling is becoming less and less popular in industry and the reasons for this trend are presented above. In my view, the omnipresent application of Agile methodology and Scrum and Kanban techniques 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 limitations 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.+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.
  
 ===== References ===== ===== References =====
 +
   - OMG Unified Modeling Language (OMG UML) Specification, OMG Document Number: formal/2017-12-05, Version 2.5.1, Dec. 2017.   - OMG Unified Modeling Language (OMG UML) Specification, OMG Document Number: formal/2017-12-05, Version 2.5.1, Dec. 2017.
   - OMG Business Process Model and Notation (BPMN) Specification, OMG Document Number: formal/2011-01-03, Version 2.0, Jan. 2011.   - OMG Business Process Model and Notation (BPMN) Specification, OMG Document Number: formal/2011-01-03, Version 2.0, Jan. 2011.
Line 53: Line 58:
   - Marian P., “UML in practice,” 35th International Conference on Software Engineering, 18-26 May 2013, San Francisco, CA, USA, pp. 722–731.   - Marian P., “UML in practice,” 35th International Conference on Software Engineering, 18-26 May 2013, San Francisco, CA, USA, pp. 722–731.
   - 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.   - 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.
-  - CASEBERRY. О продукте CASEBERRY. URL: https://caseberry.net/index.html. +  - CASEBERRY. О продукте CASEBERRY. URL: [[https://caseberry.net/index.html|https://caseberry.net/index.html]]. 
-  - Flexberry platform. Архитектура. URL: https://flexberry.net/ru/platform-architecture.html?1.+  - Flexberry platform. Архитектура. URL: [[https://flexberry.net/ru/platform-architecture.html?1|https://flexberry.net/ru/platform-architecture.html?1]].
   - Sannikova A.Yu., “Modeling of business processes of customer relationship management,” Scientific journal NovaUm.Ru, vol. 10, pp. 109-113. 2017.   - Sannikova A.Yu., “Modeling of business processes of customer relationship management,” Scientific journal NovaUm.Ru, vol. 10, pp. 109-113. 2017.
   - Berdonosov V. and Redkolis E., “TRIZ-fractality of computer-aided software engineering systems,” Procedia Engineering, vol. 9, pp. 199-213, 2011.   - Berdonosov V. and Redkolis E., “TRIZ-fractality of computer-aided software engineering systems,” Procedia Engineering, vol. 9, pp. 199-213, 2011.
   - 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.   - 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.
   - Rumpe B., “Agile Modeling with UML,” Cham: Springer International Publishing, 388 p., 2017.   - Rumpe B., “Agile Modeling with UML,” Cham: Springer International Publishing, 388 p., 2017.
  • arch/modelingpracticalusage.1634147484.txt.gz
  • Last modified: 2026/08/29 07:59
  • (external edit)