Topological Modeling for Model-Driven Domain Analysis and Software Development

Abstract

Model-driven software development has all chances to turn software development into software engineering. But this requires not only mature methodologies but also engineering models. An engineering model should satisfy five key characteristics, namely, abstraction, understandability, accuracy, predictiveness and inexpensiveness. This chapter discusses capabilities of a Topological Functioning Model (TFM) as such an engineering model for the purposes of domain analysis and software development in common. The TFM has functional and topological properties. The functional properties are cause-effect relations, cycle structure, inputs, and outputs. The topological properties are connectedness, closure, neighborhood, and continuous mapping. Thanks to its formal mathematical foundations, the TFM completely satisfies the mentioned characteristics of engineering models that is illustrated in the chapter.

Comparing Transformation Possibilities of Topological Functioning Model and BPMN in the Context of Model Driven Architecture

“…To do this, a formal mechanism provided by topological modelling -continuous mappingcan be used. As it is stated in [7] and [39], "If some more detailed functioning system is formed by substitution of a subset of specialized functional features for some functional feature, then continuous mapping exists between a detailed model and a simplified parent topological model. In the topological digraph G* (X*, U*), the direction of arcs, which join the specialized point subset nodes with other nodes, is determined by the direction of the arcs, which join the replaced point with the corresponding nodes of the digraph G (X, U)".…”

The Knowledge Frame System based on Principles of Topological Functioning Model

“…A TFM is valid when it satisfies topological and functioning properties [33]. The topological properties are: connectedness, neighbourhood, closure and continuous mapping.…”

“…The TFM can be specified as a topological space ( , Θ), where is a finite set of functional features of the system under consideration, and Θ is a topology on . A functional feature is "a characteristic of the system (in its general sense) that is designed [for] and necessary to achieve some system goal" [33]. It can be specified by a unique 7-ple (1), where:…”

“… is an action linked with an object;  is a result (results) of the action ;  is an object (objects) that gets the result of the action or an object (objects) that is used in this action;  is a set of preconditions or atomic business rules;  is a set of postconditions or atomic business rules;  is a set of responsible entities (systems and/or subsystems) that provide or suggest an action with a set of certain objects;  is a set of responsible entities (systems or subsystems) that enact a concrete action [33], [34]. A TFM is valid when it satisfies topological and functioning properties [33].…”

Dependencies among Architectural Views Got from Software Requirements Based on a Formal Model

“…TFM development consists of three activities: 1) Development of the topological space with the purpose to classify functional characteristics of the problem domain and causal dependencies among them [8], [40], [34]; 2) Development of the initial TFM ("AS-IS") [40], in which determination of boundaries of the problem domain is conducted by separation of the TFM from the topological space. Along with the causal dependencies, logical relations among them should be analyzed as well (they show the behavior of the control flow within the system, e.g., decision making, parallel activities, branching, and joining) [41]; 3) Development of the refined TFM ("TO-BE") with the aim to conform functional requirements with the initial TFM in order to bridge solution and problem domains.…”