Janis Osis

Model-Driven Domain Analysis and Software Development: Architectures and Functions

Software developers use different techniques for identification and specification of a domains characteristics and requirements for a planned application. The importance of this step cannot be understated as it is impossible to be highly efficient with a weak beginning, even with a strong end of the software development life cycle. Model-Driven Domain Analysis and Software Development: Architectures and Functions displays how to effectively map and respond to the real-world challenges and purposes which software must solve. The implications can be far-reaching and apply to domains such as mechatronic, embedded and high risk systems, where failure could cost human lives. It is also important for complex business systems, wherein failures could lead to huge financial losses. This book forms an essential reference for developers and researchers by providing both cases and theories to ensure a strong and suitable domain analysis to support all other efforts when creating and applying software solutions.

Derivation of Use Cases from the Topological Computation Independent Business Model

Model-Driven Architecture (MDA) developed by the Object Management Group (OMG) proposes three (or at least two) transformable models for system specification. The first one is a Computation Independent Model or CIM. The CIM is a model that should eliminate the gap between business people and software developers. Two other models are a Platform Independent Model (PIM) and a Platform Specific Model (PSM). The last two models specify the system structure and behavior according to the object-oriented paradigm and definitely are transformable. This chapter discusses the CIM. This model specifies domain information: business vocabulary, business rules, business knowledge, system requirements (in a broad sense), etc. This means ABstrAct

Formal Problem Domain Modeling within MDA

The proposed approach called Topological Functioning Modeling for Model Driven Architecture (TFM4MDA) uses formal mathematical foundations of Topological Functioning Model (TFM). It introduces the main feature of MDA – Separation of Concerns by formal analysis of a business system, enables mapping to functional requirements and verifying whether those requirements are in conformity with the TFM of the problem domain. By using a goal-based method, a holistic behavior of the planned application can be decomposed in accordance with the goals. Graph transformation from the TFM to a conceptual model (or a domain object model) enables establishing the definition of domain concepts and their relations. The paper also suggests a concept of a tool for TFM4MDA, which is realized as an Eclipse plug-in.

Topological Modeling for Model-Driven Domain Analysis and Software Development: Functions and Architectures

There are many ways how to describe semantics. In software development during the so called problem domain analysis mostly informal approaches and languages are used. There are several causes, and one of more important is that the problem domain itself is not well determined. Thus, developers explore the problem domain by parts, at the beginning trying to understand each fragment of the problem domain and only after that trying to join those fragments together in the holistic and more formal representation. Indeed, the question about possibility of formal description of semantics still exists. The important property of diagrams used in software development is that they must provide very precise or even formal sense. In (Diskin, Kadish, Piessens, & ABstrAct

Topological Functioning Model as a CIM-Business Model

The Object Management Group (OMG) proposed Model Driven Architecture (MDA) that architecturally separates viewpoints on specifications. MDA suggests three different models for each of the proposed viewpoints. According to MDA principles stated in (The Object Management Group, 2003), they are a Computation Independent Model (CIM), a Platform Independent Model (PIM), and a Platform Specific Model (PSM). The CIM describes system requirements and a way a system works within its environment, while details of the application structure and realization are hidden or as yet undetermined. This model is sometimes called a domain model (a business model) and a vocabulary. The PIM describes operation of a system. It suppresses all the details necessary for a particular platform a system works within and shows only those parts of the complete specification that do not change going from one platform to another. The PSM ABstrAct

Formalization of the UML Class Diagrams

In this paper a system static structure modeling formalization and formalization of static models based on topological functioning model (TFM) is proposed. TFM uses mathematical foundations that holistically represent complete functionality of the problem and application domains. By using TFM within software development process it is possible to do formal analysis of a business system and in a formal way to model the static structure of the system. After construction of the TFM of a system’s functioning a problem domain object model is defined by performing transformation of defined TFM. By making further transformations of TFM and by using TFM within software development it is possible to introduce more formalism in the Unified Modeling Language (UML) diagrams and in their construction. In this paper we have introduced topology into the UML class diagrams.

Determination of Natural Language Processing Tasks and Tools for Topological Functioning Modelling.

Topological Functioning Modelling (TFM) is based on analysis of exhaustive verbal descriptions of the domain functionality. Manual acquisition of knowledge about the domain from text in natural language requires a lot of resources. Natural Language Processing (NLP) tools provide automatic analysis of text in natural language and may fasten and make cheaper this process. First, the knowledge, its expressing elements of the English language, and processing tasks that are required for construction of the topological functioning model are identified. The overview of the support of these tasks by the main NLP pipelines is based on the available documentation without performing practical experiments. The results showed that among the selected six NLP pipelines the largest support comes from the Stanford CoreNLP toolkit, FreeLing, and NLTK toolkit. They allow analysing not only the words and sentences, but also dependencies in word groups and between sentences. The obtained results can be used for academics and practitioners that perform research on NLP for composition of domain (business, system, software) models.

Retrieving the Topology from the Knowledge Frame System for Composition of the Topological Functioning Model.

Model-driven software development considers models as a core artefact for generation of software source code. This requires models to be formal and complete enough for further transformations and code generation. It requires clear understanding of such knowledge as functionality, objects and dependencies in the problem domain. In our approach, this knowledge is kept in the frame-based system. The completeness and consistency of the knowledge can be verified by generating and validating the topological functioning model (TFM). The TFM is a model, which elements are linked by the topology, i.e. by cause and effect relations among the functional characteristics of the domain. Automated composition of the TFM requires retrieving appropriate conditions on cause and effect functional characteristics of the system from the knowledge base. The proposed algorithm reads data of functional characteristics kept in the knowledge base, relates those of them, where a cause condition corresponds to an effect condition, and generates data for the corresponding cause-and-effect relation. The difficulty is that conditions can be combined using logical operators AND, OR, XOR, as well as can use negation NOT. The benefit is that any inconsistency in the retrieved topology could be discovered and marked for further analysis. This should force careful analysis of the problem domain before generation of the design model. That could lead to decreasing a number of errors made due to uncertainty in the analysis.

Lessons learned by using the Integrated Domain Modeling toolset

To contribute with the analysis of tools that attempt to acquire Computation Independent Model (CIM) from the domain system, authors explore the Integrated Domain Modeling toolset, and explain how it automatically acquires a formal CIM from description of a business system in a form of textual business use cases. This paper recognizes the computation independent nature of a Topological Functioning Model and suggests it to be used as a CIM within Model Driven Architecture. Authors of this paper share their experiences of using the toolset and mention several lessons learned during the usage process, as well as, their suggestions for improvements.

The algorithm for getting a UML class diagram from Topological Functioning Model

The approach called Topological Functioning Modeling for Model Driven Architecture (TFM4MDA) uses Topological Functioning Model (TFM) as a formal problem domain model. TFM is used as a computation independent model (CIM) within Model Driven Architecture (MDA). Following the recommendations of MDA a CIM must be transformed to a platform independent model (PIM). The object of this research is the construction of a UML class diagram on PIM level in conformity with the TFM. Nowadays this transformation is executed manually. Manual creation of models is time-consuming; also a probability exists, that a user (e.g., system architect) will make a mistake during the execution. Time investment and risk of making mistakes increase costs and reduce efficiency of TFM4MDA approach. That is why automation of this process is useful. The paper presents an algorithm for the transformation. The algorithm is written in pseudocode and can be implemented as a tool, thus improving the TFM4MDA approach.