10.1 Why Make System Models?

As is the case with so many terms in software development, a certain ambiguity has shaded the connections between modeling, design, and building in the practice of developing systems.

In many methodologies, there is a design phase that is distinct from the analysis and implementation phases (for example). Partly as a result of the rigidities of mainframe development, for many the practice of design has become synonymous with the activities that are part of the design phase even after the demise of mainframe culture. The Gang of Four design patterns book (Gamma et al. 1995) is a reflection of this labeling; the book focuses on patterns that fit neatly into that middle world between identifying requirements and implementing the results in code.

The old notion (frequently preached, seldom practiced) of getting the requirements 100 percent complete and verifiably correct before design has, of course, been replaced by more practical approaches that emphasize iterative analysis, design, and development, and the gradual evolution of requirements. In particular, increasingly sophisticated approaches to modeling have made it possible for developers to treat requirements and analysis activities as elements of the design process and to use a broader palette of design techniques in their work.

Meanwhile, at the other end of the development process, building code is a separate activity, although one that is driven in a sensible organization by models. It should also be noted that the resurrection of modeling has brought with it renewed respectability for prototyping. In some ways, the building of prototypes is now an element of the design process that needs to be performed differently from coding as well. But coding in the traditional sense remains a personal skill with, frequently, an idiosyncratic quality. It is constrained by standards but, it is usually executed in solitude.

In contrast, modeling is a critical design skill with communal qualities, constrained more by the need to communicate and describe effectively than by prescriptive standards. Design itself has become an ongoing and collaborative process that permeates virtually all of the activities in modern software development. Even planning and management are shaped by the iterative, incremental, architected approach to development that both reflects and encourages the re-emergence of modeling. As a result, modeling is becoming a community effort that helps ensure that what is developed is what was intended and agreed upon, not just a compromise between the designer's vision and the technical constraints.

So, one answer to the question of "Why make systems models?" is that they are the keys to a collaborative design process that is becoming the core of software development today. One implication of all of this is that the practice of design must now be considered separately from the process of development the usual context for looking at systems design and software modeling. In fact, the practice of design needs to be understood by anyone engaged in systems development.

10.1.1 What Use Is a Model?

Another answer to the question of "Why make system models?" comes from the end result: the models themselves. Models are useful ways to manage the complexity of software development by means of a technique called abstraction. In short, a model represents edited details of a system reality from an aggregation of specific perspectives.

Because business modeling is one of the valid uses of the UML, and a business is a system from a systems perspective, models are abstractions of a system that can include a business in the UML.

Models are the products of the (small d) design process: interpretations, representations, and specifications of two simplified and connected realities (one descriptive and one prescriptive). There are two realities involved. The real world, including the context of the system and the things that it interacts with in the outside world, need to be modeled just as much as the end result. Models are containers for knowledge about both the why and how of the system.

In effect, the system reality being modeled connects the problem space being described (requirements, analysis, and functional specification) with the solution space being prescribed (design, construction, testing, and deployment). Unlike any other technology in the history of humanity, software development goes to great pains to connect an interpretive conceptualization of the problem space being addressed to a prescriptive solution. Models mediate this connection.

This is the obvious role of models: the end products of system design, the realization of the idea of the system. Even here, though, there's a nuance to consider. The style and shape of a model is a reflection of cultural, social, and political forces at work in the development process and in the development and client organizations. A model is not only a standardized representation, even in the most prim development shop. And UML models, in particular, are situated culturally and socially in the organizations and processes that they both reflect and shape.

More narrowly, even within the confines of the technical aspects of a system, the architectural style of a system is not just a product of the architectural constraints and choices that are made, but also a reflection of the modeling constructs consciously selected by the architect. As Ivar Jacobson, Martin Griss, and Patrick Jonsson explain in Software Reuse: Architecture, Process and Organization for Business Success, "[W]e can think of the architectural style as the set of all (good) models that can be built" using these constructs (1997, 51).

The UML specifically caters to the idea of modeling as an active medium for design, shaping both the process and the results. Stereotypes and other extension capabilities provide for graphical customization. The acceptance of incompleteness and inconsistency as givens for some models and diagrams sometimes encourages the use of models as gestures in an ongoing dance with users and stakeholders. The notion of models being view-driven reinforces the shaping force of interpretation. The inclusion of flexible packaging constructs provides for variations in the structure of models for purposes that aren't just technical and implementation-bound.