1.6. UML and Quality

UML facilitates communication. It provides a mechanism to create and share models in an industrially accepted standard of the Object Management Group (OMG). The OMG officially adopted the UML 1.1 specifications in November 1997. After a number of revisions and iterations, the current accepted standard is UML 1.4. The current work going on at the OMG is to create the UML 2.0 standard. The focus of the work in UML 2.0 is the UML infrastructure, the UML superstructure, the OCL, and the Diagram Interchange capabilities.^[11]

^[11] For more details, see www.omg.org/technology/UML.

The UML enhances communication by improving the dialogue between business and technology and among businesses and technologists. Thus, it plays a major role in reducing the chances of project failure due to bad communication (which, as you will recall from Section 1.3.5, contributes to 20 percent of project failures). Needless to say, this has a direct bearing in improving and enhancing the quality within the project.

But before we start dealing with UML, it is important to clarify two common yet crucial misunderstandings about UML:

• That UML is a language (as in a programming language)

• That UML is a methodology (as in a full process or methodological approach)

In order to arrive at a satisfactory clarification, let us deal briefly with the history of UML.

1.6.1. A Brief History of UML

Fowler [1996], in his tutorial at OOPSLA 96, lamented:

With a plethora of notational differences, many of which are entirely arbitrary, the simple modeler such as myself feels like banging the gurus' heads together until they pick a common cardinality symbol.

This plea was true of almost all practitioners utilizing methodologies. So overcrowded was the field that the OMG's special interest group on analysis and design described 27 different object-oriented methods, with some of the followers of these methodologies at war with each other—spurring Jacobson [1993] to write, “Cease the methodology war.” Hutt [1994] in his two books has surveyed between 16 and 21 methods.^[12]

^[12] These include Booch, Coad et al., Demeter, Fresco, Fusion, SOMA, Objectory, Rumbaugh, Shlaer/Mellor, SSADM, and Wirfs-Brock et al., to name but a few.

Apart from this large number of recognized methodologies, there were a number of second-generation methodologies [Henderson-Sellers and Edwards 1994], and probably many others that were never published or that were homemade concoctions derived from one or more of these recognized object-oriented methodologies. The effect of this is confusion in the software development community, followed by debates between programmers and designers [Dodani 1994] with most end users preferring to sit on the sidelines rather than betting on the wrong horse.

Who could be bothered about quality in this scenario? Luckily for the practicing modelers, and for the benefit of quality, the first results of such efforts could be seen as early as a year before Fowler's plea—with the announcement of the Unified Method (a version less than UML 1.0), at OOPSLA 95 in Austin, Texas. This was the UML in its inception phase,^[13] and it was brought about by the unification of three popular approaches to object-oriented design [Booch, Rumbaugh and Jacobson 1996]: Booch, Object Modeling Technique, and Object-Oriented Software Engineering (whose commercial version is Objectory).

^[13] For RUP users, a subtle pun intended.

After a few iterations and a lot of input from various individual and organizational members, this unified approach was announced as the Unified Modeling Language. Presumably, one of the reasons why it was not stamped as a “method” was that it was a unification of notation and other modeling elements; the actual approach to, or the process of, development derived from these three popular methodologies and a number of other popular methodologies, still remained separate—even as this book is published.^[14]

^[14] As I understand, the unification of process is under way at the OMG and can be called the “Unified Process.”

Thus, one of the things to note is that the UML is not a methodology, but a common and standard set of notations and diagrams that can be used by different processes, as shown in Figure 1.8.

Furthermore, the OMG has accepted the UML as a standard modeling language—to be used primarily for specifying, constructing, visualizing, and documenting the artifacts of an object-oriented software system. Thus, it is not a programming language, although together with a programming language for implementation, it provides an excellent mechanism to develop software systems.

1.6.2. Quality of UML versus Quality by UML

There is a difference between “Quality of UML” and “Quality by UML.”

When we discuss the quality assurance of UML-based projects, our main interest is in the latter—the value, in terms of quality, added by the UML to our project. As practitioners, and especially as users of UML, we are not too deeply involved in the quality of UML itself. However, as researchers or process consultants, we would like to have some idea about the emergence of the UML as a standard, and the reasons for its robustness.

The attempt to unify methodologies, as discussed earlier, was not just a concoction of various approaches put together. In fact, it was not even a unification of notations to start with—but the creation of a metamodel (model of a model) that would provide the ground rules for creation of models and, optionally, corresponding notations. Creation of the metamodel for UML has attracted far more attention and effort than the notations themselves.

1.6.3. Metamodels and Quality

OMG has provided for four levels of modeling, as shown in Figure 1.9. They are:

• Level 0: The Level 0 model is an instance-level model. It is a representation of a unique instance of an object. A diagram that only depicts instances, such as this account or that customer, falls within this level. Creating models at this level helps when we are dealing with a single instance of an entity. For example, if there is a need to differentiate a particular checking account in a bank from another checking account, the two need to be modeled as instances, and would be done so at this level of the metamodel.

• Level 1: The Level 1 model is a representation of a collection or group of instances resulting in a class-level representation. Numerous diagrams can be used to represent not only a collection of objects, but also a collection of behaviors, relationships, and so on. Models at this level provide the mold from which many items (objects) can be produced—making this Level 1 modeling work more abstractly than the Level 0 modeling.

• Level 2: The Level 2 model is not a simple model, but a model that relates all the representations of Level 1. This model shows how the classes, relationships, and behavior shown at Level 1 relate to each other. Thus, this metamodel provides the ground rules for enabling the creation and linking of diagrams drawn in Level 1 and plays a crucial role in enhancing the quality of UML. The metamodel at this level lays down the ground rules for UML usage—leaving the users free to create their own variations to satisfy their own particular modeling needs (provided they do not transgress the rules laid down by the metamodel).

• Level 3 (the MOF, or Meta Object Facility): This is the overall repository from various modeling domains such as process models (as would be required once unification of process takes place) and UML-based models—and provides the source for new modeling domains including the process modeling work.

For UML, in Level 2, there is a comprehensive metamodel. Those responsible for the UML have spent most of their time in this model. Metamodels play a vital role in enhancing the quality of UML, for they provide the basic rules that both the developers and extenders of UML and the CASE tool vendors have followed. Metamodels are more like barriers on a freeway—their impact is in preventing fundamental modeling errors rather than merely correcting them.

Also, most well-known CASE tools comply with the UML metamodel, enabling a certain standard across the industry. Needless to say, this has a major impact in improving communication and, thereby, quality. Finally, multiple levels of modeling can also be combined in complex modeling exercises, resulting in better comprehensibility of diagrams. This multilevel modeling is a part of UML 2.0 initiative.

1.6.4. Quality by UML

UML is a modeling language that is used to visualize, specify, construct, and document software artifacts [Booch, Rumbaugh, and Jacobson 1999]. Therefore, in considering quality for UML-based projects we have to consider the effect of using UML on:

• Quality of visual representation of the artifacts, diagrams, and models

• Quality of the specification that provides detailed attributes for the UML artifacts and diagrams

• Quality of the construction of relevant software resulting from the visual UML diagrams

• Quality of the documentation of the artifacts and diagrams to provide additional description that would suffice for the quality requirements in creating corresponding models

Each of these quality aspects of UML needs further discussion to ensure that we understand the impact of UML on them, and how their quality can be enhanced.

1.6.5. Quality of Visualization

While “a picture is worth a thousand words,” the challenge in software modeling is to represent pictorially that which is inherently nonvisual. However, that challenge in itself would not be insurmountable, but for the fact that we also need to model the nascent thought processes of a user. The UML's ability to show both processes and software elements visually, spanning the entire lifecycle of software development, is the key to improving the quality of overall visualization in software development.

The UML, through its “class” representations, can bring the reality (real passengers, flights, and seats in a typical airline reservation system) close to the people working in solution space by modeling Class::Passenger, Class::Flight, and Class::Seat as shown in Figure 1.10. The small semantic gap between models and reality, as provided by the use of object-oriented technology, improves the quality of visualization. However, in this quality exercise, we also attempt to improve the quality of visualization by improving the quality of the artifacts produced by the UML itself.

As a visual modeling language, the UML has a direct bearing on the creation of, and the quality of, visual artifacts produced in a project. Decades ago one of the common and popular visual artifacts was the humble flowchart. A flowchart used to be constructed by using a commonly understood set of notations and some associated conventions. In my early attempts—almost twenty years ago—at visual modeling with a flowchart, the only tools I could use were paper and pencil, and at the most a stencil.

The flowchart technique was followed by the advent of Software Engineering [Somerville 1989], which used Data Flow Diagrams (DFDs) and Entity Relationship Diagrams (ERDs). While DFDs and ERDs were popular, they still were derived from technology; data was the main theme of these diagrams, and ERDs primarily helped model relational structures. Thus, in the absence of something like the UML, there was very little in terms of visual modeling that could be used to describe comprehensively the behavior or the business process for which the software was to be written.

The UML provides an excellent means to produce visual models—and in the three different modeling spaces. While the UML is not entirely diagrams (and there are associated specifications and documentations), still a substantial amount of UML (at least half) is made up of a number of notational elements and their corresponding diagrams. This provides an extensive amount of diagramming techniques (far more than flowcharts, DFDs, and ERDs did) to satisfy modeling needs in all three work spaces.

Furthermore, the quality of visualization is not only enhanced by the use of the UML as a standard, but also because of the large number of CASE tools that support these visual diagramming techniques. In verifying and validating these diagrams, we will consider a “quality approach” to producing them. We will then subject the diagrams to detailed checks for their syntactical and semantic correctness and completeness. Finally, we consider the detailed quality control and testing exercise on the resultant software. A quality software process encompasses all these aspects of quality development, crosschecking, and testing.

1.6.6. Quality of Specification

While the core contribution of UML is to provide detailed visual artifacts, they still need to be supported by specifications. Specifications go along with UML artifacts and the diagrams. For example, a use case, visually represented by a UML standard notation, would still have a lot of accompanying specification that may not be visual. Specifications start with simple things like the name of the use case, its stereotype, or the various relationships that a use case has with other use cases and actors. Everything that is outside of the visual diagram falls under the specification. And certainly the UML goes a long way in improving the quality of specification by:

• Attaching the specifications to the visual models

• Enabling the projects to decide, in addition to the standard recommendations, which areas of a particular element, or diagram, they want to specify

• Allowing (through CASE tools) these specifications to be available in various formats such as a company intranet, Web page, or a set of documentation

One of the ways these specifications and their quality can be further improved is by not producing all specifications at one time. Providing steps and guidelines to produce specifications in an iterative and incremental fashion, together with the visual artifacts, is the responsibility of the process. This is discussed in greater detail in Part III—which deals with quality processes.

1.6.7. Quality of Construction

If UML were to remain at an abstract level, it would not serve the valuable purpose of controlling what the programmer does. In a way, the purpose of the UML is to visualize and specify in the problem space that which will be actually developed, implemented, or constructed in the solution space. Certainly UML through its “visual and specification” characteristics directly contributes to improved quality of construction. A code that is constructed based on proper UML-based modeling would fare much better in both its validation and its verification. Classes and class diagrams, together with their specifications (for example, accessibility options, relationships, multiplicities), ensure that the code produced is inherently superior to code produced without the benefit of UML-based modeling.

Some tools (for example, TogetherSoft) provide what they call “live source.” This facility shows the programmer a piece of code while at the same time showing the designer the corresponding class. Such a direct relationship between a model and its construction vastly enhances the quality of construction.

1.6.8. Quality of Documentation

While quality of construction is important, organizations have realized that code is not the only asset they have in IT. Accompanying documentation during all stages of a software lifecycle is an equally important asset, if not more so. This became evident during one of the largest time-bound projects that the IT community undertook—the Y2K project.

One of the first steps in approaching the Y2K cleanup, in any organization, was taking stock of the IT assets [Unhelkar, 1999]. This inventory exercise usually only revealed code or databases. People realized that to make sense of these pure programming-based assets was taking a lot of time and effort. Documentation has thus become paramount—not only the one that accompanies the code, but also the documentation that goes with models, prototypes, and other such artifacts. The UML suggests documentation accompanying all of its diagrams. Each diagram has a corresponding documentation, which may or may not reside with its specifications.

Furthermore, creation and quality of documentation is expedited when they are based on document templates (I occasionally call them documentation patterns). It is worth noting that we are not merely talking about the quality of documentation that accompanies the UML diagrams. Overall quality of any documentation produced in a UML-based project improves because relevant UML diagrams can be embedded in those documents (external to UML), thereby improving their readability and the overall communication in the project.

Documents in a quality-driven project are usually based on predetermined templates, as opposed to creating them from scratch. Such templates are provided as part of commercial processes, and are well worth the money spent to buy them. Decisions on documentation templates that accompany the UML diagrams can be made by project team members before the start of the project. Thus, overall, we see how the quality of documentation in a project is enhanced by the UML.

1.6.9. Summary of UML Diagrams and Their Importance in Modeling Spaces

As mentioned earlier, the UML follows the rigors of a metamodel. This results in a set of diagrams that have a set of underlying rules specifying how to create them. The metamodel also helps to provide rules for cross-diagram dependencies. The following table summarizes the UML diagrams and the modeling aspect of a software solution represented by them. CASE tools dealing with these modeling techniques are summarized in UML CASE Tools.

Table 1.1. UML diagrams in practice

UML diagrams	Model representing the . . .
Use case diagrams	functionality from user's viewpoint
Activity diagrams	the flow within a use case or the system
Class diagrams	classes, entities, business domain, database
Sequence diagrams	the interactions between objects
Collaboration diagrams	the interactions between objects
Object diagrams	objects and their links
State chart diagrams	the lifecycle of an object in real time
Component diagrams	the executables, linkable libraries, etc.
Deployment diagrams	the hardware nodes, processors, and optionally, corresponding components
Package diagrams[*]	subsystems, organizational units
Robustness diagrams[*]	architecture by ensuring separation of interface from business models

^[*] indicates two additional diagrams to the original list appearing in Booch et al.'s The UML User Guide

Further to this description of the focus of the UML diagrams, Table 1.2 summarizes the relative importance of each of the UML diagrams in each of the modeling spaces and to each of the major modeling roles within the project. While project team members can work in any of these modeling spaces using any of the UML diagrams, good quality models will result by understanding the importance of the diagrams with respect to each of the modeling spaces. This is shown in Table 1.2.

As is obvious from this table, modelers are not precluded from using any of the UML diagrams, but Table 1.2 provides the focus—in terms of which UML diagrams to use—for a particular role within a project. This information can be invaluable in organizing the quality team, as well as in following the quality process that will create and check these diagrams.

Table 1.2. Importance of UML diagrams to respective models

UML diagrams	MOPS (Business Analyst)	MOSS (Designer)	MOBS (Architect)
Use case diagrams	*****	**	*
Activity diagrams	*****	**	*
Class diagrams	***	*****	**
Sequence diagrams	***	*****	*
Collaboration diagrams	**	*
Object diagrams	*	*****	***
State chart diagrams	***	****	**
Component diagrams	*	***	*****
Deployment diagrams	**	**	*****
Package diagrams	***	**	****
Robustness diagrams	*	***	*****
* = least important, ***** = most important