1.5. Modeling and Quality

1.5.1. Purpose of Modeling

Modeling enhances quality. To understand this better, let us consider why we model. As shown in Figure 1.6, modeling serves two clear purposes [Unhelkar 1999]:

• To understand the complex reality

• To be a creative cause for a new reality

A model is necessarily incomplete as it cannot, need not, and perhaps should not incorporate every possible detail of the real-life situation. By creating an abstraction of the otherwise complex reality, modeling assists in understanding that reality. This is important to note because it emphasizes modeling in all types of projects—including a modeling effort in a legacy environment where, say, a COBOL application has been running for the past 20 years. Creating a model, however brief, is imperative in understanding that “old” legacy application. In a new development, modeling provides great help in understanding of the complex and fluid requirements.

In addition to this important aim, modeling also instigates the creation of new reality. We don't simply model what we know we want. Our modeling effort educates us so that we come to know what else we want. Many times a user who sees the prototype (a type of model) of a system changes her requirements and adds new requirements. As we will see later, this should be done as early in the lifecycle as possible.

Modeling provides the end user with a means of giving input long before the final product is ready. A model is a means of involving the end user or the sponsor of the product in its creation at an early stage of its lifecycle. It provides for a new paradigm, a paradigm that Kent Beck in his keynote address at TOOLS 2000 called “conversations.”^[9] Modeling facilitates conversation between the one who owns the problem (in defining it) and the one who has to provide the solution for it (in casting the solution iteratively).

^[9] Although along with many fellow practitioners, I share my doubts on the scalability of XP, the programming-based approach that Kent Beck has initially put forward. In XP you don't just base your “conversations” with users on a model, but actually show them the final output—a piece of executable code—albeit in minuscule parts at a time.

1.5.2. Modeling Caveats

Despite its advantages, use of a model in both understanding the reality and creating new reality has its own limitations. It is essential to be aware of these limitations to enable us to make quality use of modeling as a technique. Some of the specific limitations of modeling are:

• A model is an abstraction of the reality. Therefore, it does not provide the complete picture of the real situation. A model, therefore, is subject to the interpretation of the observer.

• Unless a model is dynamic, it does not provide the feel for timing. Since the reality itself is changing with time, if the model does not change accordingly, it will not be able to convey the right meaning to the user.

• 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. Nonstandardized notations and processes can render a model useless.

• 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 may no longer be relevant.

1.5.3. Understanding Modeling Spaces in Software

Appreciation of the value and the limitations of modeling provide us with the necessary background to start applying the modeling approach to practical software development. But before we can do that, we need to take a step back and consider the areas in software that we need to model. More importantly, though, we also need to consider the areas in which we need to model. These areas are what I call “modeling spaces,” as shown in Figure 1.7.

Out there, the reality is a cohesive whole. Whether it is a real software system, or a real baby, it has to be treated holistically. However, when we create a model for the same, we have the opportunity of slicing and dicing it so that it becomes more comprehensible. At the very least, this provides us with various “views” of the model, depending on our interest. A more robust approach to quality models is not only creation of various views of the same model, but separate models themselves, which are sufficiently cohesive to provide a complete and holistic view, whenever needed.

However, this creation of separate models provides the advantage of modeling (understanding and creation of reality) in an area of interest and in an area where the objectives of the project are directly served by the modeling effort. For example, a project that deals with implementing a third-party Customer Relationship Management System (CRMS) package has greater use of a modeling technique to specify the problem only. There is no point, in such a project, to model the solution as well—for the solution will be provided by the CRMS package.

In order to create an understanding of the spaces in which we should model, consider briefly the background of software development itself. Little more than 50 years ago we, the computing community, started off with an interesting approach—we simply provided solutions. Twenty years ago, when I took up my first job writing COBOL, the IT community was still eagerly and enthusiastically providing a wide array of solutions. Programming was “cool,” and I programmed many complex algorithms for the “fun” of it. Sometimes, I gave such programs to my users, and let them figure out a problem to which they could fit my solution.

Medicine is considered a far more mature industry^[10] not only because of the number of years it has been around, but also because it never provides a solution without first asking and understanding the problem. Even today, when I walk in to my family doctor's office, she is in no hurry to write a prescription without asking me first whether it is my head that hurts or my tummy. Until the relatively recent advent of well-researched methodologies, which are also supported by industrial-strength CASE tools, software developers had no qualms in “prescribing” solutions for a problem that had not been properly understood and documented.

^[10] It is only fair to acknowledge that the medical profession has more experience than the IT community. Doctors have been handling viruses for millenniums whereas computer viruses are much newer.

The IT community is maturing as it learns from its mistakes. First and foremost, we recognize the need to understand the problem that exists. What is the purpose of the system that is being created? This is followed by a model for the solution that is provided. This is the technical or design part of the model. And no modern-day software, especially Web application software, is built from scratch. There is always a background architecture that influences both the capabilities of the solution provided and the understanding of the problem.

Therefore, for the sake of creating an understanding of the modeling work, we divide all the software related work into three spaces:

1.5.4. Problem Space

The problem space obviously deals with the understanding of the problem. Primarily this is the problem that the user or the potential user of the system faces. Less often, it can also be a technical problem. In any case the problem space deals with all the work that goes on in understanding the software or system problem that is yet to be developed. In the case of projects dealing with existing legacy applications, this problem space handles the creation of a formal model of what exists, followed by a model of what is needed.

Major activities that take place in the problem space are documenting and understanding the requirements, analyzing the requirements, investigating the problem in detail, optionally creating a conceptual prototype, and understanding the flow of the process within the business. Thus, the problem space is entirely focused on what is happening with the business or the user.

Advanced readers will appreciate that as a nontechnical description of what is happening with the user or the business, the problem space needs those UML diagrams that explain the problem without going into the specifics of the technology used to provide the solution. These UML diagrams are primarily the use case diagram and the activity diagrams, followed by high-level class and sequence diagrams, and optionally state chart diagrams.

1.5.5. Solution Space

The solution space is primarily involved in the description of the solution. Models in this space take the information made available in the problem space in order to create and provide a solution that satisfies the needs of the user understood in the problem space. Therefore, this is a technical space and deals primarily with the technology used to provide the solution to whatever the problem might be.

Activities in this space need detailed understanding of the programming languages, programming environments, databases, middleware, Web application solutions, and a number of other related technical details. Good understanding of technology is therefore imperative to work well in the solution space coupled with a good understanding of how models in this space relate to the underlying technologies.

For advanced UML readers, the primary diagram used in the solution space is the class diagram. These design-level class diagrams contain the lowermost details including attributes, types of attributes, their initial values, operations, their signatures, and so on. This is followed by sequence diagrams, together with their messages and protocols. State chart diagrams and object diagrams can be used sparingly here. Finally, in order to complete the solution we will also need component diagrams, which may be initiated in the background space (discussed next). The component diagrams represent the executable chunks of code or libraries (in a Windows environment, these will be the.exe and the.dll files), which are finally incorporated in the software solution.

1.5.6. Background Space

The background space deals with two major aspects of software development that are not covered by either the problem space or solution space: architecture and management.

Management deals primarily with the planning of the entire project and does not necessarily form part of the problem or the solution space. To rephrase, management includes both the problem and the solution space. There are a number of activities within management that are handled in the background by the person playing the role of the project manager. They include planning the project; resourcing the project hardware, software, and people; budgeting and performing cost-benefit analysis; tracking the project as it progresses so that the various iterations are performed per the requirements of the process; and providing the checkpoints that yield quality results for the roles in the problem and solution space.

Planning activities fall under the general category of management, or to be precise, project management. While authors like Cantor [1998] have written about project management with UML, I personally don't think UML provides any direct assistance in project management. Yes, we have the job of managing such projects, but whether or not the UML within the projects is helping in the activities of project management is a moot point.

Architectural work, on the other hand, deals with a large amount of technical background work that must consider major issues of architecture of the solution, existing architecture of the environment in the organization, and the operational requirements of the system (requirements of the system in operation—for example, the stress and the volume and the bandwidth that the system needs).

Further background issues include the important strategic aspects of reusability of programs, designs, and even architecture. These activities will most certainly require the local knowledge of the way in which the environment works, and the industrial knowledge of the availability of reusable architectures and designs. In all modern-day software systems, making software in-house is almost sacrilegious, unless the avenues of buying it, or at least some sizeable component of it, have been exhausted. This all-important “make versus buy” decision is heavily influenced by the fact that work in this space is abstract yet precise. Explicit models of software or components greatly influence the decision to buy (or not to buy) them.

The background space will need help and support from UML in modeling the deployment environment as well as in reusing both architecture and design. Advanced readers will notice that the diagrams that the background space uses as provided by the UML are primarily deployment diagrams and component diagrams. More importantly, though, the background space will end up using material in the UML domain that deals with analysis patterns, such as the work by Martin Fowler [1997], Design Patterns by the Gang of Four [Gamma et al. 1995], Cognitive Patterns [Gardner et al. 1998], Anti Patterns [Brown et al. 1998], and so on.

We have thus divided our work in modeling software in three domains or spaces. It is important to remember that these three spaces are not watertight compartments; these spaces—especially the background space—are in three dimensions, as shown in Figure 1.7, and are dependent on each other. Ideally, it should be possible to pick a point anywhere within the three dimensions of the three spaces and apply the criteria of quality to that point. Each such point that is subjected to quality assurance will have a component in it that belongs to the problem space, another component that belongs to the solution space, and another element that belongs to the background space.