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:11] – [Current usage of modeling in practice] nmsuvorovarch:modelingpracticalusage [2026/08/29 07:59] (current) – external edit 127.0.0.1
Line 22: Line 22:
  
 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.1634148719.txt.gz
  • Last modified: 2026/08/29 07:59
  • (external edit)