The proposed approach called Topological Functioning Modeling for Model Driven Architecture (TFMfMDA) uses formal mathematical foundations of Topological Functioning Model. It introduces more formal analysis of a business system (“as is”), enables defining of what the client needs, textual functional requirements validation, and missing requirements checking in conformance with the problem domain “as is” model. By using a goal-based method, a use case model of the planned application is defined. Graph transformation from the TFM to a conceptual class diagram enables the definition between domain concepts and their relations to be established. The paper also suggests a concept of a tool for the TFMfMDA, which is realized as an Eclipse plug-in, and uses Natural Language Processing techniques.
The main idea of the given work is to introduce more formalism into the problem
domain modeling within OMG Model Driven Architecture (MDA) [
This paper is organized as follows. Section 2 describes key principles and suggested solutions for a computation independent modeling as well as their weaknesses in the object oriented analysis (OOA) within the MDA. Section 3 discusses a developed approach, i.e. Topological Functioning Modeling for Model Driven Architecture (TFMfMDA). This is illustrated in an example of modeling of library functioning. Section 4 describes the concept of a tool that partially automates it. Conclusions establish further directions into the research of Computation Independent Model (CIM).
The MDA states that the CIM usually includes several distinct models that describe
system requirements, business processes and objects, environment the system will
work within, etc. OOA is a semiformal specification technique that contains use case
modeling, class modeling, and dynamic modeling. Use cases are a notation not an
approach. Their usage is not systematic in comparison with systematic approaches
that enable identification of all system requirements. Creation of use case models and
establishment of concepts and relations among them are usually rather informal than
semiformal. Fig. 1 shows several existing ways of creating these models. One way is
to apply assisting questions [
Use case modeling starts with some initial estimate (a tentative idea) about where
the system boundary lies. As an example we can mention the Unified Process [
The TFMfMDA is based on the formalism of Topological Functioning Model and
uses some capabilities of universal category logic [
The main steps of the TFMfMDA are illustrated by bold lines in Fig. 2. There are two parallel branches at the beginning of the problem analysis: analysis at the (business or enterprise) system level, and analysis at the application level. Having knowledge about a complex system that operates in the real world, a TFM of this system can be composed. The main idea is that the functionality determines the structure of the planned system. This means that the TFM of the system validates and can be partially changed by functional requirements. Then TFM’s functional features are associated to business goals of the system; this provides business use cases as well as system use cases identification according to the problem domain realities. Moreover, after those activities functional requirements are not only in conformance with the business system functionality but also can be traceable to the system use case model. Problem domain concepts are selected and described in UML Class Diagram.
Step 1: Topological Functioning Model Construction. The TFM has a solid
mathematical base. It is represented in a form of a topological space (X, Θ), where X
is a finite set of functional features of the system under consideration, and Θ is
topology that satisfies Hausdorff's axioms and is represented in a form of a directed
graph. The necessary condition for construction of a topological space is a meaningful
and exhaustive verbal, graphical, or mathematical system description. The adequacy
of a model describing the functioning of some concrete system can be achieved by
analyzing mathematical properties of such abstract object [
Steps of the TFM construction for problem domain modeling in a business system context are as follows: a) Definition of physical or business functional characteristics (inner and external objects, functional features) by means of noun and verb analysis in the informal problem description; b) Introduction of topology, i.e. establishing causeeffect relations between functional features. These relations are represented as arcs of a digraph that are oriented from a cause vertex to an effect vertex; and c) Separation of the topological functioning model.
Cause-effect relations form causal chains that sometimes are functioning cycles. All the cycles and subcycles should be carefully analyzed in order to completely identify existing functionality of the system. The main cycle (cycles) of system functioning (i.e. functionality that is vitally necessary for system’s life) must be found and analyzed before starting further analysis. In case of studying a complex system, a TFM can be separated into a series of subsystems according to identified cycles.
The result of this activity can be represented like the one in Fig.3a that illustrates a TFM for a fragment of library (business) system functioning. The identified inner objects are a librarian, a book copy, a reader account, a reader card, a request for a book, a fine, a loan term, a statement of utilization, book fund. The identified functional features should be represented in the form of <functional feature, [{precondition},] the responsible entity, subordination (“in” is inner, “ex” is external)>, e.g. “1: Arriving of a person, person, ex” or “2: Creating of a reader account, {unregistered person}, librarian, in”. All system functionality– the set X got by the closuring operation is X= {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21}. The main functional cycle is defined by an expert, and includes functional features “17-8-9-10-11-5-12-13-14-15-17” (bold lines in Fig. 3a). 21 22 1 20 16 19 18 2 15 14 a) 8 13 3 17 7 9 12 4 6 10 5 11 20 21 25 1 16 26 15 24
2
requirement (hereafter requirements) validation in conformity with the constructed
TFM. Functional features specify functionality that exists in the problem domain.
Requirements specify functionality that must exist in the application. Thus,
requirements can be mapped onto functional features of a TFM. Mappings are
described with arrow predicates ⎯ constructs borrowed from the universal
categorical logic for computer science that is explored in details in [
Within the TFMfMDA, five types of mappings and corresponding arrow predicates are defined: one-to-one for a complete specification of a functional feature, many-toone for an overlapping or non-overlapping specification of a functional feature, oneto-many for an incomplete or complete specification of a functional feature set, oneto-zero for a new or undefined functionality specification (possible changes in functioning must be defined), and zero-to-one indicates missed requirements. Thus, it is mandatory to make a decision about implementation of the discovered functionality together with the client. Results of this activity are both validated functional requirements and TFM, which describes needed system functionality and the environment it operates within.
Let us assume that five functional requirements are drafted: FR1, FR2, FR3, FR4, and FR5. The new functionality introduced by FR5 can be described by new identified objects (the system, a wait list and SMS), and the following functional features – 23, 24, 25, 26. As a result existing cause-effect relations are rechecked and the set X = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 23, 24, 25, 26}. The resulting model is represented in Fig. 3b. The final mappings of requirements onto the functional features are illustrated in Fig. 3c.
Step 3: Use Case Model Construction. Transition from an initial problem domain
model to a CIM “output” model, i.e. a use case model, goes as follows: 1)
Identification of business users (actors and workers) and their goals. Actors are
external entities that establish business goals. In the TFM, they are represented as
external objects responsible for functional feature execution. Workers are system’s
inner entities (humans, roles, etc.), who either establish system goals or implement
them and business goals [
In our example, actors are a person, a reader, and a utilizer. Workers are a librarian and the system itself. The resulting use-case model, where workers are transformed into actors, goal names into use case names, functional features into steps of the corresponding use case is shown in Fig. 4a.
conceptual class model. After Step 3, the TFM shows functionality that must be implemented, and includes all concepts that are necessary for proper functioning.
In order to obtain a conceptual class model each TFM functional feature is detailed to the level where it only uses one type objects. After that, this model must be transformed one-to-one into a problem domain object graph, and then vertices with the same type of objects must be merged keeping all relations with other graph vertices. As a result, a conceptual class graph with indirect associations is defined. Concepts used in the main functionality are necessary in all cases. Such transformation also indicates possible inheritance relations, and use case interfaces.
In our example, the step of the TFM refinement is skipped. Fig. 4b reflects the
TFM after the gluing of all graph vertices with the same object types. This reflects the
idea proposed in [
The tool supports client-server architecture. The server keeps information about
models; the client part enables the connection with the server and the use of the kept
information. It is implemented as an Eclipse plug-in [
The tool allows working with textual information (an informal description, a functional requirements description), and graph-based constructs (a topological functioning model, a conceptual class model, a use case model). All changes are automatically propagated to the related models. The scheme of the tool activities is illustrated in Fig. 5. It describes the considered TFMfMDA steps. The first three steps reflect TFM construction, the step IV reflects functional requirement validation and TFM enhancing, the step V illustrates use case model creation, and the step VI shows the process of getting the conceptual class diagram. By now realized parts of the tools include the first three steps. The steps IV, V and VI are still under research.
The interesting part is the realization of the work with an informal description. The informal text is handled on the server side for several reasons. They are knowledge base using, the multi-user environment, and “learning” possibilities of the tool. The server program supports detection of nouns, noun phrases, and verbs. The detected information is sent to the client side in XML file form, where it is highlighted to the user in different ways (different colors, fonts, etc.). The tool provides convenient interface for handling this information and creation of functional features. The topology introduced between functional features is realized as a mix of their graphical and textual representation. The tool offers the user to join, split up and define causeeffect relations between functional features using a tabular representation, but the result is also represented in the form of graphs.
The TFMfMDA tool provides a separate editor for each step. Each editor has relevant views that represent actual information. All automated steps that need user participation are realized as wizards that open corresponding editors. By now, there are three wizards constructed in the tool. The first wizard creates a system description file with the detected nouns, noun phrases and verbs by the Natural Language Processing Server (NLPS). The second one creates a topological space. And the third one creates a TFM.
The TFMfMDA application has the following advantages. First, careful cycle analysis can help to identify all (possible at that moment) functional and causal relations between objects in complex business systems. Use case implementation priorities can be ordered not only in accordance with the client's wishes, but in accordance with the functioning cycles. It makes it possible to take a decision about functional change acceptability before their realization in the application, and helps to validate functional requirement completeness. Second, it solves some use case limitations in information capturing, thinking limitation and completeness checking, provides use case completeness, avoids conflicts among use cases, and shows their effect on each other. Besides that it does not limit the use of any requirement gathering techniques.
The tool partially automates TFMfMDA steps described above. But this approach still requires human participation. Therefore, the further research is related to the TFMfMDA enhancing with the capabilities of natural language handling in order to make it possible to automate more steps of this approach and to decrease human participation in decision making.