Uldis Donins

Software development with the emphasis on topology

In this paper a problem domain and system static modeling formalization approach and formalization of static models based on topology borrowed from topological functioning model (TFM) is proposed. TFM uses mathematical foundations that holistically represent complete functionality of the problem and application domains. With the application of TFM within software development process it is possible to do formal analysis of a business system and in a formal way model static structure of the system. Software development starts with construction of TFM of a system functioning, after what the constructed TFM is transformed into problem domain object model. By doing further transformations of TFM it is possible to introduce more formalism in the Unified Modeling Language (UML) diagrams, their construction and in software development process. In this paper topology is introduced into the UML class diagrams and is defined approach for developing topological class diagrams.

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.

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

Abstract A system architect has software requirements and some unspecified knowledge about a problem domain (e.g., an enterprise) as source information for assessment and evaluation of possible solutions and getting the target point, a preliminary software design. The solving factor is architect’s experience and expertise in the problem domain (“AS-IS”). A proposed approach is dedicated to assist a system architect in making an appropriate decision on the solution (“TO-BE”). It is based on a formal mathematical model, Topological Functioning Model (TFM). Compliant TFMs can be transformed into software architectural views. The paper demonstrates and discusses tracing dependency links from the requirements to and between the architectural views.

Topological Unified Modeling Language

Topological Unified Modeling Language (Topological UML) is a combination of Unified Modeling Language (UML) and formalism of Topological Functioning Model (TFM). The main aim of improving UML is by transferring topology and mathematical formalism of TFM to UML, thus strengthening the very beginning of the software development lifecycle, while using the TFM as a tool to carefully analyze the problem domain and design the solution domain we are going from more abstract models to more specialized models, thus adding more and more development specific artifacts to design to get us to the executable software. Topological UML is developed as a profile of UML and its specification takes advantage of the package merge feature of UML to merge extensions into UML. The created profile provides a UML specific version of the metamodel that can be incorporated into standard UML modeling tools. Topological UML development is based on following two aspects: (1) at first extending UML by using profile mechanism, thus creating Topological UML profile, and (2) afterwards defining guidelines for using Topological UML in practice (thus formalizing the way the Topological UML is used). This chapter covers extending UML while next chapter—defining guidelines for applying Topological UML profile in practice. Despite that together with Topological UML is defined method on how to apply it in practice, the Topological UML language is intended to support multiple approaches and methods (e.g., structured, object-oriented, and conceptual). It is assumed that each methodology may impose additional constraints on how a Topological UML construct or diagram may be used and applied.

Topological UML Modeling

Topological UML modeling for problem domain modeling and software systems designing is a model-driven modeling method. In the context of Model Driven Architecture (MDA), the Topological Functioning Model (TFM) considers problem domain information separate from the solution domain information and holistically represents a complete functionality of the system from the computation independent viewpoint while Topological UML has elements for representing system design at the platform independent viewpoint and platform-specific viewpoint. The Topological UML modeling method covers modeling and specification of systems in computation independent and platform independent viewpoints. Problem domain analysis and software system design with Topological UML modeling method consist of six activities—the first one is problem domain functioning analysis followed by behavior analysis and design, structure analysis and design, state change and transition analysis, structuring logical layout of design, and concluding with components and deployment design.

Adjusting Unified Modeling Language

This chapter discusses the metamodeling base of Unified Modeling Language (UML) and how it can be used to improve it. The metamodeling base defines that there exist a metamodel that describes and includes all the elements needed for UML to exist as we know it. In other words, a metamodel is used to specify the model that builds UML. One of the UML metamodel principles is its extensibility. In fact, the most common and suitable way for improving UML is to use its extensibility mechanisms—the profiles. By improving UML with the profile mechanism, it is possible to adapt and use ordinary UML compliant modeling tools. Thus, by creating a profile of UML the costs of adaption in industry for such new language is lowered and it can be adapted faster (in comparison with creating a Meta-Object Facility (MOF)-based solution which forces to implement new modeling tools along with the very new language).

Chapter 2 – Software Designing With Unified Modeling Language Driven Approaches

The Unified Modeling Language (UML) is a notation and as such its specification does not contain any guidelines for software development process. Despite that UML is independent of particular methods and approaches, most of the UML modeling driven methods uses use case driven approach thus raising incomplete analysis of the problem domain functioning. Since UML modeling driven approaches are elaborated by different authors, their prescriptions differ. There is also difference in the use of use case narratives across various methods due to the lack of guidance on narrative format in the UML specification. The UML specification only states that “ use cases are typically specified in various idiosyncratic formats such as natural language, tables, trees, etc. Therefore, it is not easy to capture its structure accurately or generally by a formal model. ” This chapter discusses the current state of the art of UML-based software development approaches. Most attention is paid on the artifacts created by using the UML.

Structuring Logical Layout of Software Design

Structuring logical layout of software design is an activity within Topological UML modeling, it consumes artifacts produced within other Topological UML modeling activities. Logical layout of software design is structured in accordance with the defined subsystems in the behavior analysis and design activity and classes with their relationships as developed within structure analysis and design activity. The logical layout is depicted by using package diagram where each package initially represents one subsystem. The contents of packages are added from the topological class diagram accordingly to the use cases in each system and the mappings between functional features and use cases. Thus, each package gets a set of classes that are responsible for particular subsystem. If needed the initial packages can be split up by grouping classes by their responsibilities. The output of this activity is package diagram structured according to subsystems and responsibilities of classes.

Structure Analysis and Design

Structure analysis and design is an activity within Topological UML modeling process. The main goal of structure analysis and design is to develop a topological class diagram which contains classes together with their attributes and responsibilities. To identify classes and assign the right responsibility to each one of them a Topological Functioning Model (TFM) is used. This chapter shows the transformation of TFM into communication diagram and communication diagram into topological class diagram (together with refinement of it). Structure analysis and design activity is based on the results obtained within the very first Topological UML modeling activity—problem domain functioning analysis in which TFM is developed for the system under consideration. The TFM holistically represents the functioning of the problem and solution domains. As a holistic model, TFM includes necessary information to develop diagrams reflecting structure of the solution domain. Topological UML modeling models structure by means of the topological class diagram. To design a structure reflecting diagrams, the following activities are performed: initially TFM is transformed into communication diagram showing objects and messages they send each other, afterward the communication diagram is further transformed into topological class diagram. For better understanding of the system’s structure and to analyze relationships between classes, object diagram is developed.

Problem Domain Functioning Analysis

Problem domain functioning analysis is the first activity within Topological UML modeling and it states that the analysis of the problem domain should be performed. To do so, functioning description and functional requirements are used as prerequisites. Functioning description can be in any form; it needs to cover full description of problem domain functioning. Output of this activity is Topological Functioning Model (TFM) (both the one representing functioning of problem domain, i.e., the situation as-is , and the one representing functionality of desired software system, i.e., the solution to-be ) which shows the system from computation independent viewpoint, mappings between functional features and functional requirements, and refined functional requirements. This activity ensures that proper attention is paid at the very beginning of the software development lifecycle by capturing various aspects of the desired system.