10.5 Abstraction and Architecture Made Simple

10.5 Abstraction and Architecture Made Simple

Abstraction and architecture are the two key concepts that the UML enshrines, in a way that previous generations of modeling tools and methodologies didn't. So far, I used the terms without detailed explanation, relying on a general sense of what they mean to carry the day. However, despite the often self-proclaimed desire of a large part of the systems community to embrace formality and rigor, these terms in particular suffer from "definitional diarrhea" in common use. So, because they are both so important within the UML, it's worth taking some time to ground them.

10.5.1 Abstraction

For the UML, abstraction is the key conceptual connection with object-oriented programming. Modeling is about making, manipulating, and managing abstractions. Objects are abstractions ones that cross the threshold between modeling and programming.

Abstractions are to modeling and object-orientation what algorithms are to structured programming: the meat of the matter. As Booch puts it: "[D]eciding on the right set of abstractions for a given domain is the central problem in object-orientation" (1994, 42). His comment applies to modeling using the UML just as easily.

Models manage complexity by means of abstraction. A modeling language provides a variety of means for abstracting, often in ways that parallel abstraction in object-oriented programming languages.

For the most part, the UML documentation invokes only a basic explanation of abstraction: abstraction as a filtering of reality, an elimination of unnecessary details, and the creation of simplified views.

This could be seen as the fundamental abstraction for programming, which is probably why it has became a touchstone definition for abstraction itself within the UML. The UML as a modeling language has a different scope from programming languages, as part of a broader set of purposes. Therefore, many of the abstractions used in modeling are not programmatic. In the UML, abstractions frequently reflect the abstractions of object-oriented programming, but often they don't. For example, association (basically, a loose link between classes) and aggregation (a loose collection of classes) can be approximated with varying precision by a programmer, depending on whether the target language is Smalltalk, Java, or C++. Other abstractions, such as role or use case, don't have any directly corresponding programming abstractions.

The UML implicitly supports a broad understanding of the process of abstracting:

  • Models themselves abstract by packaging.

    Packaging is typically a management abstraction, whether the management in question is for communication or conceptualization (or both), or simply to organize models. Management is easier with packages, as long as the packaging is understood to be driven by exogenous considerations, and may not have any essential connection to what is being modeled.

    The UML provides packages (details in Chapter 3) as a construct for a model organization that resembles programmatic modularization in intent. That is, it facilitates the grouping of logically connected elements while minimizing connections between individual elements of different groups, following the principles of coupling and cohesion. Desmond D'Souza and Alan Wills wisely suggest that documentation should be structured around package structure (1998, 709).

    Models and diagrams are also packaging abstractions, and in some ways, the UML's approach to patterns can also be seen as a way of performing conceptual packaging.

  • Model and presentation elements abstract by filtering.

    Unnecessary details about things and their connections are hidden from sight, and what is left as necessary depends on the diagram's perspective or view. This is the meaning that the UML documentation relies on for abstraction in general, and is what is intended when elision is mentioned. The UML actively supports the idea of leaving out unnecessary information from a diagram and having multiple expressions of the same model elements that show different pieces of the puzzle.

  • Model and presentation elements (such as symbols and forms) also provide operational abstractions.

    This is the term Desmond D'Souza uses for black-box abstraction, derived from Booch. It is used, for instance, when testing against a specification. In modeling, operational abstractions are placeholders that have implied effects (modeling features, services, and behaviors) that can be associated with the instance that is being represented. For example, because a box symbolizes class or type, a box called Customer in a class diagram can be assumed to exhibit the syntactic and semantic behavior of a class in the model that contains the diagram.

Note

D'Souza and Booch sprinkle their main books with good material on abstraction D'Souza with more of a design flavor (1998) and Booch with more of a programming flavor (1994).


The UML Specification also enshrines abstraction idiomatically as a model element in the metamodel, by means of constructs that are not so clearly programmatic. In other words, it supports abstraction explicitly as well as implicitly.

The explicit version of abstraction in the UML is focused on modeling needs inevitably because it is part of a specification. In particular, it gives the modeler the means to organize the model components in ways that are more sophisticated than the simple hierarchical structures of Chinese boxes that preceded the UML.

An abstraction is a dependency relationship between two model elements or sets of model elements. According to the UML Specification, the abstracting takes place between a supplier element and a client element, but this implies a hierarchy, which is not necessarily the case. There does have to be an overt relationship between the two they have to "represent the same concept at different levels of abstraction or from different viewpoints" (Rational Software Corporation 1999, 2 19). Being good object-oriented citizens, the supplier-client relationship can be one to many in either direction, or even many-to-many. It can be unidirectional or bi directional.

Abstraction is presented graphically as stereotyped versions of the dependency relationship. I've already mentioned the abstraction stereotypes (as of UML 1.3): derivation, realization, refinement, and trace (see Chapter 3).

10.5.2 Architecture

The UML Specification clearly focuses on architecture. It identifies architectural models as first-class citizens in the modeling world, along with the familiar static models, behavioral models, and usage models (Rational Software Corporation 1999, xi). It is architecture-centric.

Although static models and behavioral models can be interpreted easily from software history, and usage models are obviously a nod in the direction of use cases, the idea of architectural models never gets defined; it is neither historical nor intuitive as an idea.

Nor is it possible to rely on the field of architecture itself for a conceptual leg-up because the field of architecture doesn't really have an equivalent to what systems call architecture. To some extent, the systems notion of architecture as talked about here has echoes in plans at various levels (regional, urban, community). As used, it also suggests high-level blueprints, although these are working drawings and not conceptual ones, which is quite a mix.

The first application of the term architecture came in the '50s. IBM's Gerritt Blaauw, one of the early giants who worked with Howard Aiken on the Harvard Mark III system and later was part of the System/360 effort, used the term to describe the logical structure of a modular mainframe computer system, including both the hardware and software. Then, as now, it was a way to manage complexity when a simple hierarchy was insufficient.

By the late '80s, the idea was being applied more generally, as the need to do real planning when developing potentially distributed IT resources became evident. Over time, the same needs that drove the original invention of system architecture for describing expensive and complicated mainframes (and then the enterprises that used them) began to be applied to applications themselves. The seminal paper in this transition was "A Framework for Information Systems Architecture" by John A. Zachman (1999). (I introduced him in Section 10.2, "Every Picture Tells a Story: The UML as a Modeling Language." ) He attempted to use the way architects work and the models they create as the basis for structuring the various views of a system.

Zachman's idea of the working practices of an architect were simplistically biased toward the software engineer's ideal development process of the time, and so provide a basis-in-analogy that is misleading if seen as an explanation of the practice of design (1999). His version of the way an architect works is eerily reminiscent of the infamous waterfall methodology that is now merely a remnant of mainframe wishful thinking. And he compounded the error by validating his understanding against a typical manufacturing product development cycle of the time, also (now) outdated.

But the framework he proposed is solid, and still forms the basis for most of the thinking on the subject of architecture within IT. It is the most comprehensive approach that has been proposed.

The UML Specification echoes Zachman in many ways, however indirectly. Two ideas that Zachman introduced are critical to using the UML, and critical to its development:

  • Building a complex engineering product requires a set of architectural representations that reflect the perspectives of the participants.

  • A product can be described in a variety of ways, reflecting the purposes of the description as well as the perspectives of the participants.

Zachman's original version of an architecture proposed a matrix of models, with one dimension being role (Owner, Designer, Builder) or goal (Ballpark, Product). The other dimension originally consisted of the answers to three questions: what, how, and where? The first two are familiar to any analyst or designer; the last is usually asked by Operations if not brought up as part of the scope.

Each cell in the matrix was home for a unique model type. The "what" models focused on requirements, the "how" models on implementation, and the "where" on deployment. Any set of models that was complete could explain the strategic decisions in these areas that comprised a solution. The product that resulted was in the details, of course just like the devil.

Although Zachman's framework continues to be a considerable influence (for example, in the OMG's attempts to define a Business Objects Framework), it is scarcely mentioned in any of the literature on the UML. There are (probably) good reasons for this:

  • Zachman's framework (1999) is pre-object, and so his model types reflect a structured view of development and deliverables; they have not been updated.

  • Zachman went on to add columns to his matrix to cover "who," "when," and "why" elements that complicate what is supposed to be a way of managing complexity. The resulting thirty-six-cell matrix adds to the complexity rather than resolving it.

  • Zachman and his supporters felt that his framework could also be applied at the enterprise level, and most of the follow-up efforts have been directed at enterprise modeling. This has turned out to be a blind alley. An enterprise model typically requires years to create (after which it is out-of-date) and an attention span from senior management that simply is not available. It also adds complexity.

However, at the system level, Zachman's original framework is still the best way to conceptualize all the elements of a system strategically, including how they interact (1999).

Of course, there is a role for enterprise architecture. But, like any enterprise at the turn of the millennium, it has to be agile and flexible. At the enterprise level, architecture should simply model an organization's technology portfolio and the configuration of its components. As an alternative to a complicated matrix, an enterprise architecture organizes the enterprise's strategic chunks into layers and levels, providing an easy set of packaged abstractions and their relationships.

There are object-oriented frameworks contending to be successors to Zachman's.

The International Standards Organization (ISO) has a "Reference-Model for Open Distributed Processing," which has been noted approvingly by working groups of the Object Management Group at various times (one example is the Business Object Component Architecture Proposal). A UML working paper says that, although the UML "stems from an earlier generation of object analysis and design methods (Booch, OMT, OOSE) it is possible to achieve a large measure of compatibility with the ODP modeling language by using the UML extension mechanisms where there are no direct correspondences" (MCI Systemhouse Corporation 1997, 37). The ODP architecture framework covers the range of possible viewpoints from the enterprise domain down to deployment, using object concepts that reflect the work of Desmond D'Souza and Fusion more than the Three Amigos. The viewpoints are abstract, however; they do not reflect the concerns of specific stakeholders as Zachman's does.

Another contender is the Four+one framework from Phillippe Kruchten (1998), which is so named because it consists of four technical viewpoints plus a user viewpoint. This has become the official framework for Rational Software and, by extension, the Three Amigos. In effect, it provides a way of structuring both the work and the strategic information about an application. Unfortunately, in doing so, it doesn't separate the "what" and "how" concerns within a viewpoint, and it only really addresses the engineering aspects of a system. In The Unified Modeling Language User Guide, Jacobson, Booch, and Rumbaugh (1998a) make it clear that an architecture would combine portions of the models from each view, rather than simply being the set of all the views. It is basically a framework fitted to a method useful as a way of organizing deliverables in the context of a development workflow, rather than a real architecture.

Pattern Oriented Software Architecture:

A System of Patterns, the so-called POSA book (Buschmann et al. 1996), provides the best discussion of software architecture from an object-oriented viewpoint, including lucid pattern-based descriptions of major architectural frameworks such as Model-View-Controller.



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