arch:modelingpracticalusage

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
arch:modelingpracticalusage [2021/10/13 18:06] – [Current usage of modeling in practice] nmsuvorovarch:modelingpracticalusage [2026/08/29 07:59] (current) – external edit 127.0.0.1
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.1634148397.txt.gz
  • Last modified: 2026/08/29 07:59
  • (external edit)