Search

Introduction: Large-scale genome-wide association studies have identified >200 single-nucleotide variants (SNVs) significantly associated with coronary artery disease (CAD), collectively explaining Hypothesis: Mitochondrial (MT) genetic variants presents an underexplored one potential source of the “missing heritability”. Methods: We analyzed 265 MT-SNVs in ∼500,000 UK Biobank individuals, exploring two different CAD definitions: including (SOFT=34,782) vs. excluding (HARD=20,405) angina, using the array, sex, birth year and first five principal components as covariates. Results: In SOFT cases, four MT-SNVs survived multiple testing correction (at FDRT (rs28358278, OR=1.28, MAF=0.02, T114T in MT-ND3), m.15301G>A (rs527236045, OR=1.03, MAF=0.04, L185L in MT-CYB), m.11251A>G (rs869096886, OR=1.03, MAF=0.2, L164L in MT-ND4) and m.15452C>A (rs193302994, OR=1.03, MAF=0.2, L236I in MT-CYB), the latter two previously associated with height in the UK Biobank. In HARD cases, no MT-SNVs survived multiple testing correction, the most significant nominal (P T (rs41528348, OR=1.05, MAF=0.1, in the D-LOOP) and m.12612A>G (rs28359172, OR=1.05, MAF=0.04, V92V in MT-ND5) could potentially increase CAD risk, whereas m.12372G>A (rs2853499, OR=0.97, MAF=0.22, L12L in MT-ND5), m.11467A>G (rs2853493, OR=0.97, MAF=0.22, L236L in MT-ND4) and m.15301G>A (rs193302991, OR=0.97, MAF=0.04, L185L in MT-CYB) may confer protective effects. Previously, several of these variants have been associated with a number of blood cell traits in the UK Biobank, including the mean corpuscular hemoglobin levels (m.295C>T, m.12612A>G, m.12372G>A) and volume (m.295C>T and m.12612A>G). In addition, m.12372G>A was significantly association with five other blood cell traits, including the mean platelet volume and white/red blood cell count, as well as with several renal biomarkers, and m.12612A>G was associated with height. Conclusions: Our results indicated only spurious associations of the MT-SNV with the occurrence of CAD. More data in larger study cohorts may be needed to conclusively determine the role of MT-DNA in CAD.

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.

Object state change and transition analysis is an activity within Topological UML modeling process following structure analysis and design activity. It is based on the state diagram development. Event-driven software systems continuously wait for occurrence of some external or internal events. When such event is received and recognized, the system reacts by performing corresponding computations which may include generation of events that trigger computation in other components. The response to the received event depends on the current state of the system and underlying objects and can include a change of state leading to a state transition. The state changes and transitions within a system are formally analyzed by using Topological Functioning Model (TFM). It captures system functioning specification in the form of topological space consisting of functional features and cause-and-effect relationships among them and is represented in a form of directed graph. The functional features together with topological relationships contain the necessary information to create state diagram which reflects the state changes within system.

Components and deployment design is an activity within Topological UML modeling, it follows the structuring logical layout of software design activity and concludes the Topological UML modeling process. Components are designed in accordance with packages and nonfunctional requirements while deployment is planned for the designed components in accordance with nonfunctional requirements. The components design is depicted by using component diagram showing the internal parts, connectors, and ports that implement a component. Component represents a modular part of a system that encapsulates its contents. It defines its behavior in terms of provided and required interfaces. The planned deployment is reflected by using deployment diagram which commonly is used to specify how the components of a system are distributed across the infrastructure and how they are related together. To model such a view deployment diagrams use just two kinds of elements—nodes (i.e., components of a system or the infrastructure artifacts) and relationships that link nodes together.

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.

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.

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.

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.

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.