Verification and Validation for Quality of UML 2. 0 Models / Edition 1

Hardcover (Print)
Buy New
Buy New from
Used and New from Other Sellers
Used and New from Other Sellers
from $54.07
Usually ships in 1-2 business days
(Save 56%)
Other sellers (Hardcover)
  • All (8) from $54.07   
  • New (4) from $94.29   
  • Used (4) from $54.06   


A practical approach to enhancing quality in software models using UML Version 2.0

"Despite its increasing usage, many companies are not taking the best advantage of UML and, occasionally, individuals have experienced frustration in applying its standards. Perhaps this is because they have not yet read this book!"
-From the Foreword by Prof. Brian Henderson-Sellers

This book presents a practical checklist approach to enhancing the quality of software models created with the Unified Modeling Language (UML) Version 2.0. The foundation for quality is set by the discussion on the nature and creation of UML models. This is followed by a demonstration of how to apply verification and validation checks to these models with three foci: syntactical correctness, semantic meaningfulness, and aesthetic symmetry. The quality work is carried out within three distinct yet related modeling spaces:
* Model of problem space (MOPS)
* Model of solution space (MOSS)
* Model of background space (MOBS)

Readers can then choose a specific quality approach according to their roles in their projects.

Verification and validation checks are also organized according to these three modeling spaces, making it easier for the reader to focus on the appropriate diagrams and quality checks corresponding to their modeling space. In addition, a major element of this publication is the Strengths, Weaknesses, Objectives, and Traps (SWOT) analysis. This analysis is performed on each UML diagram, enabling readers to fully comprehend these diagrams, their advantages and limitations, and the way in which they can be used in practical projects for modeling.

A consistent case study of the Lucky Insurance System is provided throughout the chapters to illustrate the creation of good quality UML diagrams, followed by application of quality checks to them. With its emphasis on quality in UML-based projects, this book is an essential resource for all quality professionals, including quality analysts, process consultants, quality managers, test designers, and testers.

Read More Show Less

Editorial Reviews

From the Publisher
" 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, November 3, 2005)

Read More Show Less

Product Details

Meet the Author

BHUVAN UNHELKAR, PhD, is founding Principal of MethodScience and a highly acclaimed trainer and presenter in the field of software engineering. Author of seven books, Dr. Unhelkar is also a professor at the School of Computing and Information Technology, University of Western Sydney.
Read More Show Less

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?


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


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.


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.


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.


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.

Read More Show Less

Table of Contents

Figures xix

Foreword 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

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)