System Modeling in UML with Two-Hemisphere Model Driven Approach
System modeling in an object-oriented manner at the initial stage of software development can be considered as a comprehensive knowledge presentation, which enables the developer practice problem domain (instead of code) to reuse and to share responsibilities between system objects at the high enough level of system abstraction. Unified Modeling Language (UML) is an industrial standard for software specification, modeling and software development in object-oriented manner. UML is not a methodology for how to model a system and to develop a software, but just a notational conventions for "drawing" of model elements. And developers have to identify model elements from problem domain based on some guidelines or their own intuition. It can arouse and frequently arise situations, where system model is not adequate to problem domain and has information loss, duplication and discrepancy. The paper offers to use two-hemisphere model driven approach for system modeling at the problem domain level to avoid problems of manual or intuitive system modeling, and illustrates how two-hemisphere model can be translated into software model expressed in UML by using rules for graph transformations. The problem domain of assigning the pupils of the driving school has been adopted for the illustration case study.
Several outlines on model-driven approach for testing of embedded systems
This paper is devoted to model-driven testing approaches in the context of embedded systems. The article discusses specifics of the embedded systems as well as specific testing approaches for them. As the testing objects of embedded systems next non-functional requirements were previously selected: task scheduling, time restrictions, synchronization, asynchronisms and reliability. Timing restrictions are selected for detailed analysis in model specification. For this purpose Time domain from UML profile for Schedulability, Performance and Time is presented and discussed. Testing model as destination model is specified using standardized UML Testing profile, which provides general purpose metamodel for such model definition. The main idea of the paper is to show general principles of the model-driven testing and to represent simplified example of testing of the one specific feature of the embedded system. Discussed model-driven testing approach is based on the model transformation, where the source model describes the feature of the system and the destination model is the test case model. Transformation rules in future works will provide test case generation using model of the system.
Nowadays there is a wide variety of tools, supporting the idea of software development process to be enriched by the principles of modelling—the source code is being generated from the model. Many of these purporting to be "MDA complaint" as well. Model driven architecture offers an approach to software development process that provides a separation of concerns, keeping the appropriate level of abstraction on each stage of development. Furthermore, the source code can be generated in a formal way, requiring no interference from the developer. There are two types of software development tools: the former type represents the semiautomatic approach, where the software is supposed to be created using system's model and code transformations, also considering different types of routines, which are done manually, while the latter type is an automatic solution, where no manual steps or routines are required. The original article defines various perspectives on positioning of MDA tools among CASE tools for software development, as well as proposes a methodological approach on classification of MDA tools. One of the perspectives that can be used in the MDA tool classification approach corresponds with the Model Driven Development life cycle, while the other one defines the role of modelling and model application levels in a whole development process. In addition, various sets of features have been defined, in order to clarify the accordance level of these tools from the MDA perspective.
Obtaining of elements of UML class diagram from initial information about problem domain
The Model Driven Architecture (MDA) is frequently used approach to software development. Basic conception of MDA is splitting of software development by levels of abstraction, where every level is presented with separate model - Computation Independent, Platform Independent, Platform Specific Models and code. The construction of central component of Platform Independent Model - system static structure in form of Unified Modeling Language (UML) class diagram is discussed in the paper. A set of approaches proposes the way for construction of UML class diagram. Different researchers try to find the possibility to obtain elements of class diagram in the formal way. This paper describes the method of obtaining of elements of class diagram from initial knowledge about the problem domain, which is described with interrelated business process and concept model. The proposed method defines main elements of class diagram, such as class name, class attribute, class operation, relationships among classes. Formal definition of these elements allows to avoid mistakes in the software analysis and design stage. It is very important to obtain correct model on this stage, as the design model is a base of future software.
On Foundation for Certification of Model Driven Architecture (MDA) Tools: Defining a Specification
A modern approach to software development includes a wide variety of processes, which are used to regulate and manage the entire development life cycle. One of the main aspects to be considered during the preparation stage of software development is the selection of the right tools. Nowadays when software systems become more and more complex, an inappropriate selection of the tools may cause project not to succeed at all. That is why the main challenge of the industry is still aimed on the simplification, optimization, and automation of software development process. One of the ways to deal with an increasing complexity, as well as not to dig into the details of the source code, is to use modeling. A model-driven approach, mainly represented by OMG's Model Driven Architecture as the most advanced and popular one, purports to be the next evolutional milestone for the whole software industry. In fact, most of the tools currently available on the market are claimed as "MDA complaint," though have never been checked or analyzed for that compliance. Therefore, there should be a certification program defined to figure out the main features of each tool in accordance with OMG standards. The original article proposes a foundation for certification of MDA tools. In particular, this includes the specification of the most common features and options defined to clarify the accordance level of each tool from various perspectives.
Tool Integration to Support SPEM Model Transformations in Eclipse
This paper propose the approach for integrating SPEM modeling tools with the Query/View/Transformation (QVT) tools using Eclipse Modeling Framework (EMF). The aim of tool integration is to support the adoption of Model Driven Architecture within the organizations, which currently use "traditional" software development approaches. The software development process lifecycle of organization is supposed to be expressed with the help of OMG SPEM language. The approach presented in the paper is based on the model-level integration using EMF based interfaces, which will help to link the MOF based Ecore models with the QVT transformation tools. The outcomes of the work are: (i) the design of EMF based tool integration, (ii) solution prototype for Eclipse environment (iii) QVT Relations transformation rules. Model transformations are performed using mediniQVT tool, which is able to operate with the models expressed as Ecore metamodels and provides debugging features and transformation rules tracing. The QVT Relations transformations are applied to the source model, which corresponds to the "traditional" software development lifecycle. The outcome of such unidirectional transformation is the new software development process, which corresponds to the model-driven software development process. The generated target model is SPEM compliant, and can be imported into the external tool supporting SPEM models in Ecore.
The usual aim of the modern computer-aided system modelling is to improve a connection between software model and code components. Therefore, the task of a diagram import/export becomes very important during software development. Layouting of diagrams after importation from another tool and application plays the main role. Authors of this paper describe some concepts, which are currently being considered in the area of diagram layouting and indicate several problems and their potential solutions for use in the development of CASE tools.
Problems and Perspectives of Code Generation from UML Class Diagram
As a result of increasing technological diversity, more attention is being focused on model driven architecture (MDA), and its standard - Unified Modeling Language (UML). UML class diagrams require correct diagram notation mapping to target programming language syntax under the framework of MDA. Currently there are plenty of CASE tools which claim that they are able to generate the source code from UML models. Therefore by combining the knowledge of a programming language, syntax rules and UML class diagram notation semantic, an experimental model for stressing the code generator can be produced, thus allowing comparison of quality of the transformation result. This paper describes a creation of such experimental models.
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.