Verification and Validation for Quality of UML 2.0 Models / Edition 1 available in Hardcover
Verification and Validation for Quality of UML 2.0 Models / Edition 1
- ISBN-10:
- 0471727830
- ISBN-13:
- 9780471727835
- Pub. Date:
- 07/20/2005
- Publisher:
- Wiley
Verification and Validation for Quality of UML 2.0 Models / Edition 1
Hardcover
Buy New
$143.95Buy Used
$92.28-
-
SHIP THIS ITEM
Temporarily Out of Stock Online
Please check back later for updated availability.
-
Overview
Product Details
| ISBN-13: | 9780471727835 |
|---|---|
| Publisher: | Wiley |
| Publication date: | 07/20/2005 |
| Series: | Wiley Series in Systems Engineering and Management , #42 |
| Pages: | 312 |
| Product dimensions: | 6.42(w) x 9.53(h) x 1.02(d) |
About the Author
Read an Excerpt
Verification and Validation for Quality of UML 2.0 Models
By Bhuvan Unhelkar
John Wiley & Sons
Copyright © 2005 John Wiley & Sons, Inc.All right reserved.
ISBN: 0-471-72783-0
Chapter One
The Quality Strategy for UML
Quality-you know what it is, yet you don't know what it is. But that is self contradictory. ... But some things are better than others, that is, they have more quality.... But if you can't say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn't exist at all. But for all practical purposes it really does exist.... So round and round you go, spinning mental wheels and nowhere finding any place to get traction. What the hell is Quality? What is it?
CHAPTER SUMMARY
This chapter discusses the underlying concepts of modeling and the effect of verification and validation (V&V) techniques on its quality. After creating an understanding of modeling and its relevance to quality, this chapter describes the toolbox of Unified Modeling Language (UML) diagrams and divides them over the three distinct yet related modeling spaces: problem, solution and background. Following this is a discussion on defining the syntax, semantics and aesthetics checks for V&V of UML models and how their levels and skill sets affect the quality of the project.
1.1 MODELING AND QUALITY
1.1.1 The Modeling Advantage
Modeling enhances quality because it enhances communication. Through modeling, communication becomes efficient and effective. This is so because modeling raises abstraction to a level where only the core essentials matter. The resultant advantage is twofold: easier understanding of the reality that exists and efficient creation of a new reality (Unhelkar, 1999).
The advantage of modeling in understanding complexity is derived from the fact that models distill reality. Elements that are not significant in understanding the reality are dropped. Modeling also fosters creativity by focusing on the essentials and ignoring the gory details. This holds true for modeling in many industries such as construction, medicine and transportation. However, the role of modeling is even more important in software development, where it provides the means of understanding existing software systems whose legacy nature renders them extremely complex, as well as in developing and customizing new software systems expected to serve highly demanding customers in constant flux.
Consider, for example, an abstraction of a COBOL application. Modeling assists in understanding that application and the complex environment in which it operates. Creating a model, however brief, is imperative in understanding the traditional legacy application.
Modeling also facilitates smoother creation of the new reality. For example, creating a model of a software system is much easier, cheaper and faster than creating the actual system. Once the concepts are bedded down, they can be adorned with all the additional paraphernalia that makes up the final application. In this process, modeling not only represents what we want, but also educates us in understanding what we should want. It is not uncommon to have a user change her requirements based on a prototype (type of model) of a system that she has seen. Alterations and additions to the functionality required of the system during early modeling stages are welcome signs, providing significant impetus to the modeling and quality activities within a project. This is because changes during the early modeling stages of a software life cycle are cheaper and faster to incorporate or fix than those introduced later during implementation.
1.1.2 Modeling Caveats
Despite the stated and obvious advantages of modeling, there is one singularly important factor that influences the value of a model: the quality of the model itself. If the abstraction is incorrect, then obviously the reality eventually created out of that abstraction is likely to be incorrect. An incorrect abstraction will also not reflect or represent the reality truthfully. Therefore, model quality is of immense importance in eventually deriving quality benefits.
Modeling is limited by the following caveats:
Amodel, by its very nature, is an abstraction of the reality. The modeler, depending on her needs, keeps parts of the reality that are important to her in a particular situation and leaves out others which may be considered less important. Therefore, the model is not a complete representation of the reality. This leads to the possibility of the model's being subjected to different interpretations. Unless a model is dynamic, it does not provide the correct sense of timing. Since the reality is changing, it is imperative that the model change accordingly. Otherwise, it will not be able to convey the right meaning to the user. A model may be created for a specific situation or to handle a particular problem. Needless to say, once the situation has changed, the model will no longer be relevant. A model is a singular representation of possible multiple elements in reality. For example, a class in software modeling parlance is a single representation of multiple objects. In such cases, a model may not provide a feel for the operational aspects of the system, such as volume and performance. The user of the model should be aware of the notations and language used to express the model. For example, when the design of a house is expressed using a paper model, it is necessary for the user to know what each of the symbols means. Nonstandard notations and processes can render a model useless. Modeling casually, or at random, without due care and consideration for the nature of the models themselves, usually results in confusion in projects and can reduce productivity. Therefore, formality in modeling is necessary for its success. Models must change with the changing reality. As applications and systems change, so should the models if they are to be relevant. Models that are not kept up-to-date can be misleading. Processes play a significant role in steering modeling activities. Modeling without considering processes is a potential practical hazard and should be avoided.
Goals, methods and performance are considered the three major aspects of quality by Perry (1991).
1.1.3 Context of Model Quality
Where and how should the model quality effort be focused? Firstly, we must understand that model quality is not the only aspect of quality in a project. Model quality exists within the context of other quality dimensions or levels, and these influence each other as well as model quality. In practical UML-based projects, the following levels of quality are listed by Unhelkar (2003):
Data quality-the accuracy and reliability of the data, resulting in quality work ensuring integrity of the data.
Code quality-the correctness of the programs and their underlying algorithms. Model quality-the correctness and completeness of the software models and their meanings. Architecture quality-the quality of the system in terms of its ability to be deployed in operation. Process quality-the activities, tasks, roles and deliverables employed in developing software. Management quality-planning, budgeting and monitoring, as well as the "soft" or human aspects of a project. Quality environment-all aspects of creating and maintaining the quality of a project, including all of the above aspects of quality.
1.1.4 Model Quality
The aforementioned quality levels play a significant role in enhancing the overall quality of the output of a software project. Most literature on quality, however, focuses on code and data quality. Even when modeling appears in the discussion of quality, it is with the aim of creating good-quality software (data and algorithms). In this book, however, model quality refers to the quality of the software models themselves. Model quality depends on detailed V&V of those models.
In software projects without substantial modeling, code remains the primary output of the developers. In such projects, code emerges from the developer's brain-directly. This, as the history of software development indicates (Glass, 2003), has had disastrous effect on software projects.
Quality-conscious software projects use modeling throughout the entire life cycle. Subsequently, modeling is used not only to create the software solution but also to understand the problem. As a result, modeling occurs in the problem, solution and background (architectural) spaces. The modeling output in such software projects transcends both data and code and results in a suite of visual models or diagrams. While these models go on to improve the quality of the code produced, it is not just their influence on the implemented code that interests us but also their own quality-that is, the quality of the models themselves. There is an acute need to subject the software models themselves to quality assurance and quality control processes. It is important that these models adhere to known standards and are also subjected to stringent quality control. Model quality is all about V&V of the models themselves. The result is not only improved model quality, but also improved communication among project team members and among projects.
1.2 POSITIONING UML FOR MODELING
How do we build software models? The ubiquitous flowcharts, followed by the entity relationship (E-R) and data flow diagrams (DFDs), are no longer sufficient to model modern software systems. With the advent of objects and components, Web services and grid computing, and pervasive mobile computing, we need a sophisticated as well as an exhaustive suite of modeling techniques. UMLversion 2.0 (Object Management Group [OMG]) is specifically advocated as a software modeling language for visualization, specification, construction and documentation (Booch et al., 1999). Thus, it is not a programming language, although with the recent initiatives involving model-driven architecture (MDA), we are close to using UML as an executable UML language. Thus, overall, UML, together with a programming language for implementation, provides an excellent mechanism to develop software systems.
Furthermore, it is worth noting that UML is not a methodology, but rather a common and standard set of notations and diagrams. These are used by processes in varying ways to create the required models in the problem, solution and background modeling spaces. Therefore, the checklists developed later in this book for V&V purposes are likely to vary, depending on the process; in other words, the V&V checklists will change, depending on the role and the modeling space in which they are applied.
It is also worth mentioning that UML has been (and is being) used effectively in a large range of projects, including:
New development projects, where systems are designed from scratch and the new business applications are modeled using, for example, UML's use cases and activity diagrams. Integration projects, where newer systems-typically Web-enabled systems-are integrated with existing (typically legacy) systems. Package implementation, where UML's behavioral diagrams can be used to understand the requirements of the implementation of the customer relationship management system (CRMS) or the enterprise resource planning (ERP) system. Outsourcing projects, where UML provides the basis for scoping, delivery and testing. Data warehousing and conversion projects, where not only are the data and related information modeled using UML, but the conversion and testing processes also use UML to document the flow. Educational projects, where UML can be used for testing concepts, for example for teaching and learning object orientation.
In addition to the above types of projects, UML is being used in small, mediumsized and large projects (Unhelkar, 2003). Due to such wide-ranging applicability of UML, the model quality of UML-based projects assumes great importance. Let us, therefore, consider UML from a model quality perspective.
1.3 QUALITY ASPECTS OF UML
UML has four main purposes: visualization, specification, construction and documentation (Booch et al., 1999). Therefore, in investigating the quality of UML models, it is worthwhile to consider how these factors affect, and are affected by, quality.
Visualizing-UML notations and diagrams provide an excellent industry standard mechanism to represent pictorially the requirements, solution and architecture. UML's ability to show business processes and software elements visually, spanning the entire life cycle of software development, provides the basis for extensive modeling in software development. UML, through its class representations, can bring the reality (real customers, accounts and transactions in a typical banking system) close to the people working in the solution space by modeling the corresponding Class Customer, Class Account and Class Transaction. The small gap between models and reality, especially in object-oriented (OO) development, improves the quality of visualization. This quality of visualization is enhanced not only by the use of UML as a standard, but also because of the large number of Computer Aided Software Engineering (CASE) tools supporting these visual diagramming techniques. CASE tools in modeling facilitate the work of teams of modelers and prevent syntax errors at the visual modeling level. Specifying-Together with visual representations, UML facilitates the specification of some of its artifacts. For example, specifications can be associated with the actors, use cases, classes, attributes, operations and so on. These UML specifications help enhance the quality of modeling, as they enable additional descriptions of the visual models, enable members of a project team to decide which areas of a particular diagram or element they want to specify, and allow them (through CASE tools) to make the specifications available to all stakeholders. The specifications can be made available in various formats, such as a company's intranet Web page, a set of Word documents or a report. Constructing-UML can also be used for software construction, as it is possible to generate code from UML visual representations. This is becoming increasingly important with the rapidly advancing concepts of executable UML (Mellor and Balcer, 2002) and the MDA initiative (Mellor et al., 2004). A piece of software that is constructed based on formal UML-based modeling is likely to fare much better during its own V&V. Classes and class diagrams, together with their specifications (e.g., accessibility options, relationships, multiplicities), ensure that the code generated through these models is correctly produced and is inherently superior to hand-crafted code (i.e., code without models). Documenting-With the help of UML, additional and detailed documentation can be provided to enhance the aforementioned specifications and visual representations. Documentation has become paramount-not only the type that accompanies the code, but also the type that goes with models, prototypes and other such artifacts. In UML, diagrams have corresponding documentation, which may be separate from the formal specifications and which goes a long way toward explaining the intricacies of visual models.
1.4 UNDERSTANDING MODELING SPACES IN SOFTWARE
With the aforementioned four dimensions in which UML promises quality enhancement, it is still vital to remember that UML-based modeling does not happen within a single modeling space. Successful modeling needs to consider the areas in which modeling needs to take place. These modeling spaces have been formally considered and discussed by Unhelkar and Henderson-Sellers (2004). This role-based division is shown in Figure 1.1.
This figure depicts the three distinct yet related modeling spaces: problem, solution and background. These role-based divisions form the basis of further quality V&V work with respect to UML models. These divisions provide a much more robust approach to quality modeling, as they segregate the models based on their purpose, primarily whether the model is created to understand the problem, to provide a solution to the problem, or to influence both of these purposes from the background, based on organizational constraints (e.g., stress, volume and bandwidth), and need to reuse components and services.
(Continues...)
Excerpted from Verification and Validation for Quality of UML 2.0 Models by Bhuvan Unhelkar Copyright © 2005 by John Wiley & Sons, Inc.. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Figures xixForeword xxiii
Preface xxv
Acknowledgments xxxi
Glossary of Acronyms and Terms xxxiii
Author Profile xxxv
1 The Quality Strategy for UML 1
Chapter Summary 1
1.1 Modeling and Quality 2
1.2 Positioning UML for Modeling 4
1.3 Quality Aspects of UML 5
1.4 Understanding Modeling Spaces in Software 7
1.5 Modeling Spaces and UML 7
1.6 Verification and Validation 14
1.7 Quality Checks and Skills Levels 19
1.8 Levels of Quality Checks to UML Diagrams 20
1.9 Model-Driven Architecture (MDA) and Quality 23
1.10 Prototyping and Modeling Spaces 23
Discussion Topics 24
References 25
2 Nature and Basics of UML Diagrams 27
Chapter Summary 27
2.1 The Nature of UML Diagrams 27
2.2 Use Case Diagrams 30
2.3 Activity Diagrams 33
2.4 Class Diagrams 35
2.5 Sequence Diagrams 37
2.6 Communication Diagrams 39
2.7 Interaction Overview Diagrams 41
2.8 Object Diagrams 41
2.9 State Machine Diagrams 43
2.10 Composite Structure Diagrams 44
2.11 Component Diagrams 45
2.12 Deployment Diagrams 46
2.13 Package Diagrams 47
2.14 Timing Diagrams 49
2.15 UML’s Extensibility Mechanisms 50
2.16 UML Meta-Models and Quality 53
Discussion Topics 55
References 56
3 Strengths, Weaknesses, Objectives and Traps (SWOT) of UML Diagrams 57
Chapter Summary 57
3.1 SWOT Analysis of the UML Diagrams 58
3.2 SWOT of Use Case Diagrams 59
3.3 SWOT of Activity Diagrams 65
3.4 SWOT of Classes and Class Diagrams 67
3.5 SWOT of Sequence Diagrams 70
3.6 SWOT of Communication Diagrams 73
3.7 SWOT of Interaction Overview Diagrams 74
3.8 SWOT of Object Diagrams 75
3.9 SWOT of State Machine Diagrams 76
3.10 SWOT of Composite Structure Diagrams 77
3.11 SWOT of Component Diagrams 78
3.12 SWOT of Deployment Diagrams 79
3.13 SWOT of Package Diagrams 80
3.14 SWOT of Timing Diagrams 82
Discussion Topics 82
Note 83
References 84
4 V&V of the Quality of MOPS 85
Chapter Summary 85
4.1 UML Diagrams in MOPS 86
4.2 V&V of Use Cases and Use Case Diagrams in MOPS 88
4.3 Quality of Activity Diagrams in MOPS 122
4.4 Quality of Package Diagrams in MOPS 129
4.5 Quality of Classes and Class Diagrams in MOPS 132
4.6 Quality of Sequence Diagrams in MOPS 145
4.7 Quality of State Machine Diagrams in MOPS 150
4.8 Quality of Interaction Overview Diagrams in MOPS 154
4.9 Validating the Entire MOPS 156
4.10 Summary of Quality Checks for MOPS 158
Discussion Topics 158
References 160
5 V&V of the Quality of MOSS 161
Chapter Summary 161
5.1 UML Diagrams in the Solution Space (MOSS) 161
5.2 Analyzing MOPS for MOSS for a Solution 163
5.3 Quality of Classes and Class Diagrams in MOSS 166
5.4 Quality of Sequence Diagrams in MOSS 178
5.5 Quality of Communication Diagrams in MOSS 182
5.6 Quality of Object Diagrams in MOSS 184
5.7 Quality of State Machine Diagrams in MOSS 186
5.8 Quality of Timing Diagrams in MOSS 188
5.9 Converting Models into Systems 189
5.10 Cross-Diagram Dependencies 189
Discussion Topics 190
References 192
6 V&V of the Quality of MOBS 193
Chapter Summary 193
6.1 Working in the Background Space 194
6.2 UML Diagrams in the Background Space (MOBS) 194
6.3 V&V of Package Diagrams in MOBS 199
6.4 Classes and Class Diagrams in the Background Space 204
6.5 V&V of Class Diagrams in the Background Space 208
6.6 V&V of Robustness through Class Diagrams in MOBS 210
6.7 V&V of Component Diagrams in MOBS 213
6.8 V&V of Composite Structure Diagrams in MOBS 218
6.9 V&V of Deployment Diagrams in MOBS 219
6.10 Cross-diagram dependencies in MOBS 222
Discussion Topics 223
References 224
7 Managing the V&V Process 225
Chapter Summary 225
7.1 Processes and UML 225
7.2 Understanding the Process and Process Components 226
7.3 Iterations and Increments in a Process 228
Discussion Topics 230
Note 230
References 230
Appendix A LUCKY Insurance Case Study 231
Appendix B UML CASE Tools 237
Appendix C Summary of Checks for V&V of the Quality of MOPS 241
Appendix D Summary of Checks for V&V of the Quality of MOSS 251
Appendix E Summary of Checks for V&V of the Quality of MOBS 257
Appendix F Templates for Actors, Use Cases and Classes in MOPS 263
Index 267
What People are Saying About This
"...is just the book to help one use the UML effectively...I highly recommend this book." (Software Quality Professional, December 2006)
"I recommend this book to all those…using UML in small or medium-sized projects…it will serve as a useful guide for their next UML modeling task." (Computing Reviews.com, November 3, 2005)