Guidelines: Logical View
Topics
Introduction 
The Logical View is a subset of the Artifact: Design Model which presents architecturally significant design elements. It is presented in the Artifact: Software Architecture Document.
What to include in the Logical View
- A model element that encapsulates a major abstraction of the problem domain, such as:
- A flight plan in an air-traffic control system.
- An employee in a payroll system.
- A subscriber in a telephone system.
Sub-types of these should not necessarily be included, e.g. Distinguishing an ICAO Standard Flight Plan from a US Domestic Flight Plan is not important; they are all flight plans and share a substantial amount of attributes and operations.
Distinguishing a subscriber with a data line, or with a voice line, does not matter as long as the call handling proceeds in roughly the same way.
- A model element that is used by many other model elements.
- A model element that encapsulates a major mechanism (service) of the system
- Design Mechanisms
- Persistency mechanism (repository, database, memory management).
- Communication mechanism (RPC, broadcast, broker service).
- Error handling or recovery mechanism.
- Display mechanism, and other common interfaces (windowing, data capture, signal conditioning, and so on).
- Parameterization mechanisms.
In general, any mechanism likely to be used in many different packages (as opposed to completely internal to a package), and for which it is wise to have one single common implementation throughout the system, or at least a single interface that hides several alternative implementations.
- A model element that participates in a major interface in the system with, for example:
- An operating system.
- An off-the-shelf product (windowing system, RDBMS, geographic information system).
- A class that implements or supports an architectural pattern (such as patterns for de-coupling model elements, including the model-view-controller pattern, or the broker pattern).
- A model element that is of localized visibility, but may have some huge impact on the
overall performance of the system, for example:
- A polling mechanism to scan sensors at a very high rate.
- A tracing mechanism for troubleshooting.
- A check-pointing mechanism for high-availability system (check-point and restart).
- A start-up sequence.
- An online update of code.
- A class that encapsulates a novel and technically risky algorithm, or some algorithm that is safety-critical or security-critical, for example: computation of irradiation level; airplane collision-avoidance criteria for congested airspace; Password encryption.
The criteria as to what is architecturally significant will evolve in the early iterations of the project, as you discover technical difficulties and begin to better understand the system. As a rule however, you should label at most 10% of the model elements as "architecturally significant." Otherwise you risk diluting the concept of architecture, and "everything is architecture."
When you define and include the architecturally significant model elements in the logical view, you should also take the following aspects into consideration
- Identify potential for commonality and reuse. Which classes could be subclasses of a common class, or instances of the same parameterized class?
- Identify potential for parameterization. What part of the design can be made more reusable or flexible by using static and run-time parameters (such as table-driven behavior, or resource data loaded at start-up time)?
- Identify potential for using off-the-shelf products.
