UML Class Diagrams: Capturing the Structural Essence of Systems

UML is undisputedly the most efficient and effective tool of information systems analysis and design. Abstraction as paradigm, represent the basis of an object-oriented approach to development of information system and software solutions. No matter what background team members have (i.e. information technology or problem domain experts), the capability of abstraction is of crucial importance, especially at the early phase of the system's structure identification. Since class and object diagrams specify system's structure, indicating how to identify and relate them, they are an issue for system analysts and designers. This paper examines the following issue: to what extent abstraction level influences the need for creating object diagrams in shaping class diagrams and vice versa to what extent concretization at the level of an object diagrams influences structural decomposition of class diagrams.

2007

UML is now widely accepted as the standard modeling language for software construction. The Class Diagram model is its core view, providing the backbone for any modeling effort and having well formed semantics. Class diagrams are widely used for purposes such as software and language specification, database and ontology engineering, and model transformation. The central role played by class diagrams emphasizes the need for strengthening Computer Aided Software Engineering (CASE) tools with features at the level of modern integrated development environments. Such tools need to detect errors in models, identify the source of errors, reveal redundancies, and possibly suggest design improvements. These tasks require reasoning capabilities since they depend on the meaning of the constraints that occur in a diagram. This paper characterizes four essential reasoning problems in class diagram design, and surveys methods for their solution. The contribution of this paper lies in classifying ...

Defining semantics for UML is a difficult task. Disagreement in the meaning of UML constructs as well as the size of UML are major obstacles. In this report, we describe our approach to define the semantics for UML. Semantics is defined denotationally as a mapping into our semantics domain called the system model [4, 5, 6]. We demonstrate our approach by defining the semantics for a comprehensive version of class diagrams. The semantics definition is detailed for UML/P class diagrams, a variant of class diagrams which restricts the use of a few methodologically and semantically involved concepts. Class diagrams are well-known and rather easy to understand and thus perfect to examine the usability of the system model for precise semantic mappings.

2008

2007

This paper continues description of UML class diagram wich represents the structure of an object-oriented application. The present paper describes the class relations of association, aggregation, compounding, dependency and generalisation/specialisation. Also, presents the concepts of navigability, multiplicity, association and qualified association. Class Relations Classes are basic elements of the class diagram. An application obviously demands for the modelling of more classes. Isolated classes will never allow for the modelling of a system and of the different interactions between its components. UML proposes more solutions for the connection between classes. Class relations express the semantic or structural relations. The most frequently used relations are: association, aggregation, compounding, dependency and inheritance. Remark. Even if the relations are described within the class diagrams, they express in the majority of the cases, the connections between objects. Due to th...

2012

Object-oriented system modeling enables the sharing of responsibilities between system objects at a high level of system abstraction. The UML class diagram is the central part of the object-oriented system model and serves as a "bridge" between the information about the problem domain at the customer's side and the software components at the developer's side. However, UML is not a methodology for how to model the system, but just a notation for "drawing" of model elements. This paper demonstrates the functionality of the BrainTool, which enables the generation of the UML class diagram from the so called two-hemisphere model, where the problem domain is presented as a concatenation of the problem domain processes, incoming and outgoing information flows and their types. BrainTool is developed using Visual Studio .NET for modeling of the two-hemisphere model, the Python programming language for definition of transformation rules and XMI for model interchang...

… , 1998. Proceedings. 2nd IEEE Workshop on, 1998

The Unified Modeling Language (UML) is likely to become an important industry standard language for modelling object-oriented systems. However, its use as a precise analysis tool is limited due to a lack of precise semantics and practical analysis techniques. This paper proposes a rigorous analysis technique for UML based on the use of diagrammatical transformations. A precise description of a subset of UML class diagrams is presented. This is then used to identify a number of deductive transformations on class diagrams. Conditions for checking the soundness of the rules are also given. Because the reasoning system is based on the manipulation of diagrams, it is proposed that they can be successfully used by practitioners without recourse to complex linguistic proof techniques.

2020

Model-based software engineering contemplates several software developments approaches in which models play an important role. One such approach is round-trip engineering. The objective of this paper is to benchmark the comparative analysis of the round-trip engineering capability of three modelling tools: Papyrus, Modelio and Visual Paradigm. The conclusions drawn throughout the paper will answer the question: How effective are current code generation tools for documenting application evolution? Throughout the discussion, we have pointed out several improvements that these UML modelling tools have recently brought to the discussion. We have also proposed some improvements that we consider desirable to improve Roundtrip Engineering approaches pointing out possible directions and solutions.