Search

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).

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.

In this chapter, a software modeling language—Unified Modeling Language (UML)—is reviewed as a part of software intensive system development process. The review includes the evolution of UML by paying most attention on the diagrams included in versions 1.x and 2.x as well as on the formalism development used to specify the language. The review of UML shows the benefits and limitations of applying it within software development lifecycle, and identifies UML extension mechanisms and scenarios. As a result, UML improvement options are outlined. One of the improvement options is to strengthen UML specification by using mathematical topology which is based on formalism of Topological Functioning Model (TFM).

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.

Behavior analysis and design is the next activity within Topological UML modeling process. This activity is based on the results obtained within previous Topological UML modeling activity—problem domain functioning analysis. By basing behavior analysis on Topological Functioning Model (TFM), we are identifying and designing subsystems, use cases, actors, and relationships between them (topological use case diagram), messages and their sequence (sequence diagram), and workflows (activity and interaction overview diagram). As a source of these artifacts we use refined functional requirements, refined TFM, and mappings between functional requirements and functional features. Application of TFM logical relations allows formally developing activity diagrams representing workflows in problem domain including decisions, forking, and joining. In the context of use cases, these logical relations define «include» and «extend» relationships between use cases while cause-and-effect relationships show precise communication between the system and actors involved in those use cases.

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 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.

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.

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.

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.