Role of UML Class Diagram in Object-Oriented Software Development

Role of UML Class Diagram in Object-Oriented Software Development UML is an industrial standard for object-oriented software specification which offers a notation for class modeling during object oriented software development. Since the UML class diagram is a so-called "bridge" between software specification at the user side and software realization at the developer side, it requires strong guidelines for identification of class objects from the problem domain and notational conventions for modeling of the class diagram for its further usage in system coding. This paper presents a discussion on problematic stages and possible element transformations into software components. Several conclusions are drawn on potential usage of the class diagram in industry. UML klašu diagrammas loma objektorientētā programmatūras izstrādē UML ir industriālais standarts objektorientētā programmatūras izstrādē, kas piedāvā dažādu sistēmas aspektu modelēšanas notāciju. Viens no sistēmas modelēšanas uzdevumiem UML notācijā ir kalpot par "tiltu" starp programmatūras sistēmas specificēšanu lietotāja pusē un programmatūras realizāciju programmētāja pusē. Šī uzdevuma risināšanai UML valodā ir jābūt definētām stingrām prasībām diagrammu elementu identificēšanai un sistēmas modeļa izstrādei, kur galveno lomu "spēlē" UML klašu diagrammas izstrāde. Klašu diagramma tiek veidota, apkopojot informāciju par izstrādājamo programmatūras sistēmu no lietotāja puses, un kalpo par pamatu programmatūras komponentu izstrādei. Pašlaik pastiprināta uzmanība ir pievērsta klašu diagrammas elementu automatizētai transformācijai koda fragmentos. Šis raksts fokusējas uz klašu diagrammas lietošanu programmatūras izstrādē no diviem aspektiem, gan aprakstot dažādus paņēmienus klašu diagrammas izstrādes metodēs no sākotnējas informācijas par sistēmu, gan arī aprakstot dažas perspektīvas koda generēšanas uzdevumā. Rakstā ir secināts par to, ka eksistē pietiekami daudz pieeju, lai izstrādātu UML klašu diagrammu pilnīgu un nepretrunīgu, un ar formālām transformācijām no dažādiem problēmvides apraksta veidiem. Taču koda generēšanas jomā joprojām pastāv problēmas, kā iegūt strādājošas programmatūras komponentes. Tas ir iemesls, kādēļ klašu diagrammas joprojām tiek lietotas tikai dokumentācijai. Pat, ja klašu diagramma tiks izstrādāta formālā ceļa, tik un tā, mūsdienās to vēl nav iespējams lietot koda generēšanai. Patreizējā klašu diagrammas versija nesatur pietiekamu informāciju, kuru varētu "tiešā" veidā transformēt programmatūras komponentos. Koda generēšanas rīki nepilda visas modeļvadāmās programmatūras izstrādes prasības, līdz ar to, pieaug rīku standartizācijas nepieciešamība. Nobeigumā tiek diskutēts par esošajām problēmām klašu diagrammas lietošanā un perspektīvām plašākai klašu diagrammas lietošanai programmatūras izstrādes projektos. Роль диаграммы классов языка UML в разработке объектно-ориентированного программного обеспечения UML является индустриальным стандартом для разработки систем программного обеспечения, использующим объектно-ориентированную технологию. Одной из задач моделирования системы, используя нотацию UML, является обеспечение «моста» между спецификацией системы на стороне заказчика и реализацией системы на стороне разработчика. Для решения этой задачи в языке UML должны быть определены строгие требования к идентификации элементов диаграмм и разработке модели системы, где главную роль играет диаграмма классов. Диаграмма классов строится, обобщая информацию, полученную от заказчика, и должна служить основанием для реализации системы. В последнее время большое внимание уделяется решению проблемы автоматической генерации кода из диаграммы классов. В статье рассматриваются два аспекта использования диаграммы классов в разработке программного обеспечения: с одной стороны - приемы конструирования диаграммы на базе начальной информации о системе, а с другой - перспективы генерации кода из диаграммы классов. В статье дается подтверждение того, что за 20 лет существования диаграммы классов, разработано достаточно методов, приемов и техник для того, чтобы считать, что проблема формального построения диаграммы классов решена. А вот по части генерации кода существуют проблемы, связанные с автоматическим получением работающих компонентов системы программного обеспечения. И это является одной из причин, почему диаграмма классов используется только для документации, а в полном объеме своих возможностей в процессе разработки программного обеспечения не используется, даже если разработана формальным образом. На данный момент диаграмма классов не содержит достаточный синтаксис для того, чтобы описать все возможные и необходимые элементы, которые дадут возможность генерировать полноценный программный код. И CASE средства, которые существуют в поддержку генерации кода на данном этапе, не соответствуют всем требованиям для разработки управляемой моделями системы, таким образом, возрастает необходимость стандартизировать такие CASE средства. В заключение авторы ведут дискуссию о существующих проблемах в использовании диаграммы классов языка UML и перспективах расширения области использования диаграммы классов в проектах по разработке программного обеспечения.

[1]  Stephen R. Schach,et al.  Object-oriented and classical software engineering , 1995 .

[2]  Terry Quatrani.  Visual modeling with Rational Rose 2000 and UML (2nd ed.) , 2000 .

[3]  Stephen J. Mellor,et al.  Executable UML - A Foundation for Model-Driven Architecture , 2002, Addison Wesley object technology series.

[4]  Oksana Nikiforova,et al.  Problems and Perspectives of Code Generation from UML Class Diagram , 2011, Sci. J. Riga Tech. Univ. Ser. Comput. Sci..

[5]  Ivar Jacobson,et al.  The Unified Software Development Process , 1999 .

[6]  Peter P. Chen.  The Entity-Relationship Model: Towards a unified view of Data , 1976 .

[7]  Bhuvan Unhelkar.  Verification and Validation for Quality of UML 2.0 Models , 2005 .

[8]  Dragan Gasevic,et al.  Model Driven Engineering and Ontology Development , 2009 .

[9]  Peter P. Chen.  The entity-relationship model: toward a unified view of data , 1975, VLDB '75.

[10]  Jon Siegel.  Developing in OMG’s New Model-Driven Architecture , 2001 .

[11]  John Jeston,et al.  Business Process Management , 2013 .

[12]  Oksana Nikiforova,et al.  Object Interaction as a Central Component of Object-oriented System Analysis , 2017, MDA/MTDD.

[13]  Michael Havey,et al.  Essential business process modeling , 2005 .

[14]  Jon Siegel.  Developing in OMG''s Model-Driven Architecture , 2001 .

[15]  Jeffrey Parsons,et al.  Dimensions of UML Diagram Use: A Survey of Practitioners , 2008, J. Database Manag..

[16]  Oscar Pastor,et al.  Model-driven architecture in practice - a software production environment based on conceptual modeling , 2007 .

[17]  Frank Budinsky,et al.  Eclipse Modeling Framework , 2003 .

[18]  Oksana Nikiforova,et al.  Discussing the Difference between Model Driven Architecture and Model Driven Development in the Context of Supporting Tools , 2009, 2009 Fourth International Conference on Software Engineering Advances.

[19]  Marite Kirikova,et al.  Two-Hemisphere Model Driven Approach: Engineering Based Software Development , 2004, CAiSE.

[20]  H. V. Jagadish,et al.  Database Modeling and Design , 1998 .

[21]  정인기,et al.  [서평]「Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design」 , 1998 .

[22]  Anneke Kleppe,et al.  MDA explained - the Model Driven Architecture: practice and promise , 2003, Addison Wesley object technology series.

[23]  James E. Rumbaugh,et al.  Object-Oriented Modelling and Design , 1991 .

[24]  Ivar Jacobson,et al.  Object-oriented software engineering - a use case driven approach , 1993, TOOLS.

[25]  Silvia Mara Abrahão,et al.  A systematic review of the use of requirements engineering techniques in model-driven development , 2010, MODELS'10.

[26]  Craig Larman,et al.  Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process , 2001 .

[27]  Oksana Nikiforova,et al.  Two Hemisphere Model Driven Approach for Generation of UML Class Diagram in the Context of MDA , 2009, e Informatica Softw. Eng. J..

[28]  Grady Booch,et al.  Object-Oriented Design with Applications , 1990 .

[29]  H. V. Jagadish,et al.  Database Modeling and Design: Logical Design , 2011 .

[30]  Peter Meso,et al.  Conceptualizing Systems for Understanding: An Empirical Test of Decomposition Principles in Object-Oriented Analysis , 2006, Inf. Syst. Res..

[31]  Adam Brooks Webber.  Formal Language: A Practical Introduction , 2011 .