Topological UML Modeling

An Improved Approach for Domain Modeling and Software Development

Janis Osis, Uldis Donins

• Publisher: Elsevier
• Year: 2017
• Print ISBN: 9780128054765
• eBook ISBN: 9780128093535
• Topic: Computer Science
• Subtopic: Programming
• Index: Computer Science

Topological UML Modeling: An Improved Approach for Domain Modeling and Software Development presents a specification for Topological UML® that combines the formalism of the Topological Functioning Model (TFM) mathematical topology with a specified software analysis and design method. The analysis of problem domain and design of desired solutions within software development processes has a major impact on the achieved result – developed software.While there are many tools and different techniques to create detailed specifications of the solution, the proper analysis of problem domain functioning is ignored or covered insufficiently.The design of object-oriented software has been led for many years by the Unified Modeling Language (UML®), an approved industry standard modeling notation for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system, and this comprehensive book shines new light on the many advances in the field.- Presents an approach to formally define, analyze, and verify functionality of existing processes and desired processes to track incomplete or incorrect functional requirements- Describes the path from functional and nonfunctional requirements specification to software design with step-by-step creation and transformation of diagrams and models with very early capturing of security requirements for software systems.- Defines all modeling constructs as extensions to UML®, thus creating a new UML® profile which can be implemented in existing UML® modeling tools and toolsets

Part I

Introduction

Outline

Chapter 1 Unified Modeling Language: A Standard for Designing a Software

Chapter 2 Software Designing With Unified Modeling Language Driven Approaches

Chapter 3 Adjusting Unified Modeling Language

Chapter 1

Unified Modeling Language

A Standard for Designing a Software

Abstract

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

Keywords

Software system specification; UML; behavior analysis; structure analysis; TFM; modeling formalization

Information in This Chapter:

• UML diagrams

• Formalism of UML

• Benefits and disadvantages of applying UML

• UML improvement options

1.1 Introduction

Unified Modeling Language—abbreviated as UML—is a graphical language officially defined by Object Management Group (OMG) for visualizing, specifying, constructing, and documenting the artifacts of a software system [106]. An artifact in software development is an item created or collected during the development process (example of artifacts includes use cases, requirements, design, code, executable files, etc.). UML offers a standard way to write system’s blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components [37]. Despite that UML is designed for specifying, visualizing, constructing, and documenting software systems, it is not restricted only for software modeling. UML has been used for modeling hardware, and is used for business process modeling, systems engineering modeling and representing organizational structure, among many other domains [125].

The first UML specification (version 1.1) was published by OMG at 1997. Since then there has been continuously ongoing work to improve both the language and its corresponding specification. Additionally, we should admit that UML versions 1.4.2 and 2.4.1 have been published under International Organization for Standardization (ISO) [44] and International Electronical Commission (IEC) [43] as a standard. In year 2005, the version 1.4.2 was published as ISO/IEC 19501:2005 [46]. Following in year 2012, the version 2.4.1 was published as ISO/IEC 19505-1 [47] and ISO/IEC 19505-2 [48]. You should ask—why there are two separate ISO/IEC standards for single UML version? The answer hides in fact that beginning with UML version 2.0 its specification was divided in two parts (i.e., two separate documents)—so-called Infrastructure and Superstructure. Accordingly, the ISO/IEC standard is based on this separation. But what a surprise—UML version 2.5 specification [79] again is a single document.

During the two major and a number of revision versions of UML, the definition of UML is evolving. UML version 2.4.1 specification [77,78] defines the language as follows: “UML is a visual language for specifying, constructing, and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component methods, and that can be applied to all application domains (e.g., health, finance, telecom, aerospace) and implementation platforms (e.g., J2EE, .NET).”

The UML originally was developed in middle of 1990s as a combination of previously competing object-oriented analysis and design approaches:

• Booch method by Booch [13],

• Object-Modeling Technique (OMT) by Rumbaugh, Blaha, Premerlani, Eddy, and Lorensen [105],

• Object-Oriented Software Engineering (OOSE) by Jacobson, Christerson, Jonsson, and Overgaard [49], and

• Other contributions to modeling complex systems, e.g., statecharts by Harel [41].

The first version of UML (version 1.1) was approved by OMG in year 1997 [71]; afterwards UML has been revised with several releases (UML 1.3, 1.5, 2.0, 2.1.1, 2.1.2, 2.2, 2.3, 2.4.1, and 2.5 [81]) by fixing some problems and adding new notational capabilities. The latest standard released by OMG is UML version 2.5 (UML version 2.0 is a major rewrite of UML 1.x (“x” denotes the main version and any subversion of specification) and was released in 2015).

The UML became widely accepted as the standard for object-oriented analysis and design soon after it was first introduced [54] and still remains so today [22,103]. Since the release of first UML version a large number of practitioner and research articles and dozens of textbooks have been devoted to articulate various aspects of the UML, including guidelines for using it. In fact, since the UML specification is a specification and thus it is written in a manner to specify every aspect of the language’s constructs, it does not contain guidelines on how to apply the language elements in real-life situation. So just reading the language’s specification does not give an insight of its application. We advise to read UML specification together with guidelines describing approach or methodology of applying UML diagrams throughout software development lifecycle. Since the UML as a language includes 14 kinds of diagrams and many elements building them up, the scope of UML-related research areas is wide:

• Formalization of UML semantics (e.g., [31,42] (both after UML 1.1 was released), and [122] (after UML 2.0 was released)),

• Extending the UML (e.g., [64,99], and review of a number of UML profiles developed by different researchers and groups [103]),

• Formalizing the way, the UML diagrams are developed (e.g., [88,96]),

• Ontological analysis of UML modeling constructs (e.g., [125]),

• Empirical assessments (e.g., [22,32]),

• Analysis of the UML’s complexity (e.g., [30,111,112]),

• Difficulties of learning UML (e.g., [113]) and how to avoid them (e.g., [11]),

• Transformations between UML diagrams (e.g., [61,57,66]),

• Software code generation and related issues with generated code quality (e.g., [59,108,118]), and

• Experiments that evaluate aspects of UML models effectiven...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• Foreword
• Preface
• Acknowledgments
• Part I: Introduction
• Part II: Improving Domain Modeling
• Part III: Topological UML Modeling Explained
• Bibliography