Practice 18. Model Key Perspectives

Bruce MacIsaac

Modeling raises the level of abstraction and allows the system to be more easily understood from different perspectives.

Problem

As software systems become more and more complex, and as distributed teams strive to communicate more effectively, there is an increasing need to use abstraction to deal with complexity, to simplify understanding, and to become more productive.

Models raise the level of abstraction, and their powerful ability to provide information in a simple, intuitive form improves the understanding of everyone involved. Models can focus on a particular perspective that addresses particular concerns of particular stakeholders, which aids communication. This in turn helps teams to do the following:

• Detect errors and omissions.

• Explore and compare alternatives at a low cost.

• Understand the impact of changes.

Figure 6.10. Levels of Abstraction.

Models raise the level of abstraction, allowing you to focus on important aspects such as relationships and patterns rather than getting bogged down in details. (From RUP v7.0.)

These general benefits apply to all forms of modeling, including requirements modeling, business process modeling, software design, and even your house's wiring diagrams. This practice focuses on modeling key perspectives for software development.

Background

Imagine you wanted to meet someone through a dating service, and your date was described solely in terms of his or her chemical makeup and relative positions of molecules in space. While completely accurate, such a description would be useless; you really want a higher abstraction, such as height, intelligence, and personality. Models are simplifications of systems that filter out unwanted details so that you can focus on particular aspects.

Figure 6.11. Models Are Simplifications of Systems.

Models filter out unwanted details so that you can focus.

As software systems get larger, models that capture the "big picture," the major structural elements and patterns of behavior, become especially important. Visual representations are particularly useful, as human beings are very efficient at processing visual information. Graphics that show relationships and interactions of software elements can be read at a glance. Many errors have patterns that are easily spotted in a visual representation (see Figure 6.12).

Figure 6.12. Structure Diagrams.

Structure diagrams are one way to visualize a system. In this example the first diagram shows a cyclic dependency between packages. The second diagram shows this corrected through refactoring.

For example, Figure 6.12 shows dependencies between packages A, B, and C. You can easily see the circular dependency relationship between A and C. Structure diagrams like these enable developers to reason about a system, exploring alternatives such as splitting A to remove the cyclic dependency, as shown in the right half of the figure.

Behavior can also be represented visually, for example using a UML activity diagram, as shown in Figure 6.13.

Figure 6.13. Example of a UML Activity Diagram.

UML diagrams visually model behaviors. (From RUP v7.0.)

The arrows show how the processing flows, while decision nodes such as "baggage/no baggage" show alternative flows. Because it doesn't take long to learn the meaning of the various symbols, subject matter experts can evaluate the system behavior for missing steps or incorrect sequences even if they cannot read code.

Visual modeling is just one way to model. This practice describes some useful modeling practices and explains when they are best applied.

Applying the Practice

This section describes how to focus your modeling efforts on key perspectives, starting with basic design sketches. It also provides an overview of model-driven development approaches in which a visual model becomes the implementation.

Identify the Key Perspectives

The most important perspectives are not the same for every system. For systems with a large and complex database, the data perspective is important to model. For others, concurrency may be important. When deciding what to model, you should start with the most complex aspects of the system, which is where modeling can help the most.

Focus on the most complex aspects of the system first.

Before modeling anything, you should understand the purpose of the model. What information should be conveyed? What information should be hidden? Who will benefit from the model? Is the model worth the effort to maintain?

Usually, it is best to start with informal modelssuch as rough sketches, tables in a spreadsheet, or notes in an e-mailthat focus on a single purpose.

Sketch the Design

Design sketches are an effective way to capture ideas, so that you can see the "big picture." Sketches are particularly useful for design brainstorming sessions, because you can use them to focus on aspects that your group is interested in.

For example, sketches of a large system should include major subsystems, their interfaces, and their interactions. Such sketches are key to understanding how a large system is composed. Sketches of structure and behavior within subsystems in turn help to provide an understanding of the internals of subsystems.

Initial sketches should be created quickly and revised dynamically as new ideas and trade-offs are considered. Because whiteboards are quick and easy to use, they are good for design sketches. However, results are hard to capture and share with geographically dispersed colleagues. Software modeling tools can be great as a "virtual whiteboard" for design sketching, as they allow standard shapes to be selected and connected quickly and easily. However, once a sketch conveys the right information, it is more important to validate the design than make the sketch pretty. The best software designers refactor their designs, so don't waste time cleaning up a graphic in the early stages of design.

Sketches should be considered as a way to capture or communicate ideas, not as a step that has to precede implementation. It is often useful to write some code to try out a design idea or to learn how to use an unfamiliar component, while a sketch may work better as a way to understand relationships and communicate with others. Each activity benefits and complements the other.

Intersperse sketching, implementation, and refactoring.

In particular, you should avoid creating volumes of detailed design before creating an implementation. Implementing should be done early, to ensure that design ideas actually work in practicenot just on paper.

Agree on a Standard Notation

For a small group of people, informal notations can work reasonably well; you can draw some shapes and invent a notation as you go along. However, for larger audiences, a formal notation helps avoid confusion.

Many notations have been proposed for various languages and environments. For object-oriented software design, the UML is dominant. UML has also been extended to other domains, such as business modeling and data modeling, but competes with other notations in these domains.

The common notation of UML makes cross-domain communication easier.

All other things being equal (tool support, richness of notation, and so on), we recommend UML-based notations. Once you know the basics of UML, it's easier to learn additional UML-based notations. If business modelers, data modelers, and object modelers are using similar notations, it will be easier to evolve business objects into classes in object models and transform classes in object models to tables in data models. The common notation of UML makes cross-domain communication easier.

Visualize the Code

The latest software development platforms are providing more and more ways to view code. For example, you can capture the results of running tests as sequence diagrams. As another example, you can automatically generate diagrams to show dependencies between code elements. These visualizations help developers to understand their code better and relate it to the intended design.

Code visualization helps developers to relate code to design.

Document Key Architectural Perspectives

There are many arguments for and against documenting design. Up-to-date design documentation can help testers, developers, and maintainers understand the system, enabling them to work more effectively. However, design documentation can easily become obsolete and cause harm by communicating wrong information.

Managers responsible for large legacy systems often suffer from the following problem: the original developers have left and nobody understands the implementation, so it is very difficult to make changes. How could this problem have been avoided? One way would have been to maintain the design documentation. Another would have been to ensure that the code remained well structured and self-documenting as it evolved.

Well-written, understandable code is better than poor code that is well documented. But documentation still has value if you can maintain it efficiently.

One approach to ensure efficiency is to focus on the highest-value documentation. It is this part of the design that many people need to understand and that will be referenced frequently as the system evolves.

An architectural description enables understanding of key parts and patterns.

You'll want to start by documenting the architecture. Architecture encompasses the key design decisions, including the most important components, patterns, and interactions. A concise description of the architecture is usually worth maintaining, as it helps your team understand how the parts fit into the whole and reminds them of the patterns to be followed. Diagrams can be particularly useful to hide unnecessary detail and focus on a particular architectural concern.

Architecture is best described from multiple perspectives or "views." RUP suggests the following views:^[25]

^[25] First proposed in Kruchten 1995 as the "4+1 Views."

• Logical view describes the structure and interactions of design classes and components.

• Implementation view describes how the code is organized into elements for version control and deployment.

• Process view describes concurrency.

• Deployment view describes how software is distributed across processing nodes.

• Requirements (or use case) view describes the requirements that drive the other views.

Most projects start with the logical and requirements views and then add other views as needed.

Use a Model-Driven Development Approach

Software development started with binary language, moved to assembly languages, shifted to higher-level languages such as FORTRAN and C, and later moved to languages such as Java and C#. Each step on the way enabled great gains in expressiveness; developers could solve problems with less effort.

Model-driven development (MDD) is the next step in that evolution. In an MDD approach, the model is essentially a high-level language. Developers create and evolve models that can be transformed into code or executed directly. By modeling instead of coding, developers can express solutions in terms closer to the problem being solved, and by using a visual notation, developers can better understand and communicate how a system works.

Model-driven development is the next step in the evolution of software implementation.

The Object Management Group (OMG) is defining a standard approach to MDD, called model-driven architecture (MDA). MDA describes development in terms of successive model transformations. For example, a model is created that describes the structure and behavior of the system in conceptual terms, without specifying a particular platform. This is called a platform-independent model (PIM). Transformations can then be applied to create a model that targets a specific platform, such as J2EE or Microsoft .NET. The result is a platform-specific model (PSM). The PSM can, in turn, be transformed into executable code.

This approach promises a number of benefits:

• More efficient development. Descriptions of the problem to be solved are more quickly converted into implementations.

• Higher quality. Each model can be evaluated from a quality perspective.

• Greater reuse. More abstract models have more general applicability.

• Long-term maintainability. A platform-independent design is less affected by technology churn as platforms evolve.

MDA is still in an early stage of evolution. However, early adopters are reporting some successes,^[26] and there are many tools^[27] that support MDA in terms of generating code from models, and transforming models to models.

^[26] See http://www.omg.org/mda/products_success.htm.

^[27] See http://www.omg.org/mda/committed-products.htm.

One notable example is the Eclipse modeling framework (EMF), an open source MDA implementation with broad applicability. With EMF you can specify a model using UML, XML, or annotated Java and use that model to generate a nearly complete Java application with a default user interface and data persistency. The generated Java classes provide basic create, update, and delete code, as well as notification, persistency to XMI, and lots of other code that can be used as is or extended as needed. Models or code can be updated and synchronized with each other.^[28]

^[28] EMF was used to develop both EPF (see Appendix A), and RMC (see Appendix B).

Other Methods

Traditional waterfall development is based on an up-front design approach, usually using some kind of model. However, waterfall development does not validate the model with running code until late in the project, which is a risky time to discover design flaws. Traditional development methods also tend to create a lot of design documentation that is difficult to maintain, rather than focusing on key architectural perspectives.

XP takes an incremental design approach, focusing on constantly improving the code through refactoring. XP is compatible with an MDD approach; you just recognize that the model represents a higher-level programming language^[29] and develop incrementally using that language. XP doesn'tencourage or discourage sketching the design using UML diagrams. You can diagram if you want, but diagram only what you need, create tests and code, and then discard the diagrams.

^[29] Beck 2000 discusses this in "role of pictures in design."

Like XP, the Unified Process encourages an evolving design, but unlike XP, the Unified Process encourages diagramming as a means of evolving the design and documenting the architecture from key perspectives. The most important diagrams are maintained. Others are maintained only if there is tool support that makes it easy.

The Unified Process encourages diagramming to evolve designs and to document key architectural perspectives.

In terms of visual modeling, the Unified Process and XP differ on the topic of architecture. The Unified Process encourages defining an architecture, whereas XP does not. RUP then goes beyond the needs of most small projects by including optional specialized techniques, such as business modeling, simulation, round-trip engineering, and code-and-test visualization.

Agile modeling is a development approach that recognizes the value of using models (both visual and nonvisual) and includes guidance on how to model efficiently and effectively. Most of the core principles and practices, such as "software is your primary goal" and "model in small increments," are consistent with the Unified Process. Agile modeling focuses on design sketching, because it offers high value and is relatively easy for developers to adopt. The Unified Process recognizes the value of design sketching but also encourages MDD.

Levels of Adoption

This practice can be adopted at different levels:

• Basic. Use informal models to understand and communicate ideas.

  Creating informal models, such as design sketches, can speed development by enhancing understanding and communication. This moves you down and to the left on the process map.

• Intermediate. Document the architecture using UML.

  Maintaining the architecture is a moderate investment that pays off in many ways: the entire team understands the system better; software is stabilized early; and developers can work more independently, thus increasing the team's ability to deliver iteratively. This moves you down on the process map.

• Advanced. Use an MDD approach.

  MDD requires investment and training. However, both small and large teams may benefit significantly from the increased productivity. This moves you down and to the right on the process map.

Related Practices

• Practice 15: Leverage Patterns describes how to use patterns as tried and true solutions and how they can be applied in modeling environments.

• Practice 16: Architect with Components and Services describes how components and services lead to better architectures. Visual modeling is an effective way to document components and services.

More generally, visual modeling helps you to define a clear architecture, which supports practices related to managing change, organizing teams, and so on.

Additional Information

Information in the Unified Process

Visual modeling plays a role throughout RUP and OpenUP/Basic. However, OpenUP/Basic takes a very light approachmodels are informal and optional and are used to communicate and understand. RUP expands on informal modeling to cover additional model-driven approaches, including round-trip engineering and MDA approaches. RUP also provides technology-specific guidance, such as J2EE and .NET, as well as tool-specific guidance, such as guidance for a variety of visual modeling environments.

Additional Reading

To learn more about UML, see the following:

Michael Chonoles. UML 2 for Dummies. John Wiley & Sons, 2003.

James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language Reference Manual, Second Edition. Addison-Wesley, 2004.

For guidance on how to practice modeling in an agile fashion, see the following:

Scott Ambler. The Object Primer, Third Edition, Agile Model-Driven Development with UML 2.0. Cambridge University Press, 2004.

Martin Fowler. Is Design Dead? (Keynote XP 2000 conference). Found online at http://www.martinfowler.com/.

For the latest on the evolution of MDA and MDD, see the following:

http://www.omg.org/mda and http://www.ibm.com/software/rational/mda/

To learn more about EMF, see the following:

Bill Moore et al. Eclipse Development Using the Graphical Editing Framework and the Eclipse Modeling Framework, IBM 2004, available at http://ibm.com/redbook.