11.1 The Work of Design

11.1 The Work of Design

I avoided grounding the UML in any one specific process for two reasons:

  • This provided me with an opportunity to take the UML's process- independence (and mutt-like quality) seriously. I was able to focus on the ideas that are the UML itself, rather than the way they are used. And, I've been able to use examples from both Rational's Unified Process and Desmond D'Souza and Alan Wills' Objects, Components and Frameworks with the UML: The Catalysis Approach (1998) to process polar opposites in many ways in which process-specific differences are significant.

  • I felt that focusing on one process, however good, would continue the unstated, perhaps unconscious, focus on development-as-programming that has permeated the UML literature (but not the UML itself, interestingly).

The latter reason was the more important reason of the two for me personally.

I went through my own personal paradigm shift some time ago, but as a modeler, not as a programmer. As part of a previous generation of developers, I'd seen the emergence of modeling as a distinctive skill within the framework of structured methods the old paradigm.

As a modeler, objects became interesting to me because of intransigent problems I continually ran into when doing traditional modeling. The abstractions produced as artifacts were unrelated to the world of the user, and they were difficult to use in establishing their needs and validating the results. Once defined, the process of translation into programmer-readable format was frequently a tortured one with many magic moments of smoke and mirrors mediating the translation. The models we produced, although useful to management, were less useful to their real supposed beneficiaries.

Objects presented a way out of this dilemma, and object-oriented analysis and design became the achievement that, in Kuhn's terms, redefined the work I did.

The UML and patterns, taken together, are for me the final linchpins in this personal paradigm shift. They are not silver bullets. They do provide the tools to do design differently, in a way that is fully congruent with all of the other significant achievements over the last ten years. Combined, they add up to a paradigm shift for system development in general, and for system design in particular.

11.1.1 What Is Design?

The forces that need to be balanced in looking at the work of system design will be familiar from earlier parts of this book:

  • The initial situation is one of uncertainty and complexity, in which the problem(s) to be addressed may be expressed poorly or incompletely, may not even be right, or may not be the right one(s).

  • Context and situation are important parts of the problem to be solved, not just information to be archived.

  • Vision, and not just current problems, is a motivator and shaper of the end result.

  • Although problem solutions in software are typically technical, the problems are typically business problems.

  • Feedback is as important as feedforward (that is, conceptualization) in the "artistic performance" of design, but the levels and types of abstractions required for each may be significantly different.

  • Prototyping and modeling are both activities in design; they are taught as techniques but need to be applied as skills. Models can be seen as documentation and specification; prototypes can be seen as simulations and experiments. But a designer can experiment with models and specify with prototypes.

  • Representation is not presentation. The way the world and the system are represented in a model and the way that model is presented reflect different needs. "The map is not the territory," as Sessue Hayakawa used to preach.

These forces have appeared in various guises already as forces in the patterns. They are also obvious elements in the thinking behind the UML, and in the thinking behind processes such as RUP and Catalysis (D'Souza and Wills 1998). However, most discussions of software design bury them or treat them as being tacitly understood shared knowledge, and so not in need of explicit attention.

Generally, what constitutes design in the context of systems development is as fuzzy as most of the other ideas we development professionals seem to profess. For example, Ivar Jacobson, Grady Booch, and James Rumbaugh can maintain that design isn't just architecture (1998a), while Jim Coplien can take the position that design is making architecture (1998a). I already mentioned the widely held tacit notion that design is only a stage in the standard development lifecycle between analysis and construction. Even the Rational Unified Process only avoids this view by reinventing it: for RUP, design is that part of an iteration that falls between requirements analysis and implementation.

There's also the view of design as tied to a specific role. Designers design, architects architect, analysts analyze, and programmers develop. Each role applies known techniques specific to that role and recurring problems that are well-formulated for that role.

Much of this approach came from IBM's early attempts to bureaucratize the development process via programming teams and IBM's view of architecture. Of course, the real picture has always been somewhat smudged, and it was when IBM helped formulate it. Analysts encroach on the design turf at the beginning of development, and programmers are known to indulge in design fixes at the end.

There is a need to distinguish design from engineering. Design is emphatically not engineering, although it complements engineering, and many engineers do design as well as engineering.

Narrowly viewed, engineering is like the normal science that Kuhn describes problem-solving in a well-defined conceptual framework. Design is broader and messier than that.

David Kelly, CEO of IDEO and a design consultant at Stanford, puts it this way: "(t)he designer has a dream that goes beyond what exists, rather than fixing what exists design defines what it ought to be engineering does it" (Winograd et al. 1996, 152 157). Although admitting that clear distinctions between engineering and design only caricature either, Kelly adds that engineering "is not supposed to be messy you try to assume away the messiness that only works when you are solving a well-formulated problem . Designers try to understand the mess (instead)" (1996, 153).

Engineers may rightfully protest that this narrow view of engineering represents only a limited portion of the things engineers do. Engineering as a practice embodies many ways of knowing and doing that we find in design. Even Kelley admits that, in his experience, "[G]ood engineers are really designer-engineers designers in every sense of the word" (Winograd et al. 1996, 153). But design is still not engineering, however much the two complement each other and are practiced together.

In systems, design permeates any development process, and constitutes a practice a repertoire of ways of knowing and doing engaged in by systems professionals, rather than being a technical role or set of activities. As Jim Coplien puts it, in this reality "we can't separate design from architecture and implementation" (1998a, 40). And, as modeling becomes a key element of managing and operating the software products that development produces, in some ways design also becomes part of management and operations, and things get smudged even more.

11.1.2 Beyond Patterns and Paradigms

What do designers do, then, that's different from engineering? And how do they do it?

An alternative to the engineering view of things is provided by Donald Schon in his books on the reflective practitioner. Schon emphasizes the ongoing role of professional reflection and the importance of practical knowledge in ensuring the effectiveness of professional practice.

He uses the term professional practitioner as a general description of a professional engaged in providing a service for a client (who may be called something else, such as patient or student). He leverages both meanings that are usually associated with the word practice. His notion of practice combines the performance of a range of services and the preparation for performing them. Ultimately, for Schon, a professional practitioner is "a specialist who encounters certain types of situations over and over again" (1983, 60).

In Schon's view, rather than simply applying technical expertise to well-formed problems, a professional is continually being confronted with surprises that require "reflection-in-action" about both the knowledge that is being brought to bear and the actions being taken. He balances theoretical knowledge with a repertoire of practical knowledge, some of which may be tacit and not easily articulated. Improvisation that is acquired from practice is at least as important a component of performing well as any lessons learned in graduate school.

Design is a special case of reflective practice, but it is more than that.

In a way that parallels Coplien's understanding of the role of design in systems development, Schon sees design as permeating all aspects of professional practice. When Schon discusses the role of reflective practice in engineering and the sciences, for example, he implicitly echoes Kelley's comments that "(g)ood engineers are really designer-engineers" (1983). However, it's clear that although design can be an element in the practice of those professions, it isn't essential to them. (But reflective practice might be seen to be essential in engineering and the sciences in a different way in the creation of new paradigms when surprise anomalies need to be accounted for.)

Schon's model for the design process is what he calls a "reflective conversation with the situation" (1983, 40). In a nutshell, it could be described as an iterative, incremental, architecture-centric, user-driven, but informal process.

The best summary of Schon's idea about design is by Schon himself:

A designer makes things. Sometimes he makes the final product; more often, he makes a representation, plan, program, or image of an artifact to be constructed by others. He works in particular situations, uses particular materials, and employs a distinctive medium and language. Typically, his making process is complex. There are more variables kinds of possible moves, norms, and interrelationships of these than can be represented in a finite model. Because of this complexity, the designer's moves tend, happily or unhappily, to produce consequences other than those intended. When this happens, the designer may take account of the unintended changes be has made in the situation by forming new appreciations and understandings and by making new moves. He shapes the situation, in accordance with his initial appreciation of it, the situation "talks back," and he responds to the situation's back-talk.

In a good process of design, this conversation with the situation is reflective. In answer to the situation's back-talk, the designer reflects-in-action on the construction of the problem, the strategies of action, or the model of the phenomena, which have been implicit in his moves. (1983, 79)



A UML Pattern Language
A UML Pattern Language (Software Engineering)
ISBN: 157870118X
EAN: 2147483647
Year: 2005
Pages: 100
Authors: Paul Evitts

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net