10.6 Perspectives: A Generic Modeling Framework

Models need organizing. But if your toolset doesn't provide a usable organizing approach, and if the architecture-focused ways of organizing seem inappropriate, you'll need to improvise a basic framework of model types. The core set of UML diagrams can be used in a variety of models at various stages of a development process, so, by themselves, they don't provide enough organizing structure. Development methods often don't go beyond identifying the existence of analysis and design models, and suggesting that the code itself is the implementation model. However, Syntropy, a pre-UML object-oriented process, discusses categories of models (perspectives) that provide an informal idea of how to organize your models. The following are the Syntropy perspectives:

Essential perspective:
This perspective models the ideas and relationships that appear in the domain. The result is a conceptual model that is free of implementation language details. Types and collaborations in the model reflect domain concepts directly, although there often is no direct mapping. The purpose of the conceptual model is to accurately represent the domain in its own terms: to capture its essential structure, relationships, and processes.
Specification perspective:
The focus in this perspective is on software, but particularly on the interfaces of the software rather than the implementation. A specification model has an emphasis on who provides what services to whom without explaining the mechanics of how it is done. Classes in this perspective represent types (abstracted interfaces) rather than programmed classes.
Implementation perspective:
All the implementation details are exposed here and the specifics of system behavior are described in detail.

Martin Fowler, Kendall Scott, and Ivar Jacobson mention this approach approvingly in UML Distilled: Applying the Standard Object Modeling Language because it facilitates some critical distinctions about the way object, class, and type should be used (1997). Significantly, it helps avoid getting trapped in discussions about whether an object is an implementation abstraction, and so is out of place in analysis and possibly specification. Fowler's book has a good detailed description of the impact of these perspectives, which is outside the scope of this discussion, but worth consulting for anyone concerned with producing models that are clear and practical.