Paper Summary
“Architectural Blueprints – The ‘4+1’ View Model of Software Architecture”
By Philippe Kruchten
Part II
Jeff Schott
CS590L Distributed Component Architecture
Prof. Yugi Lee
January 28, 2004
Kruchten lays out a software architecture model for what he describes as “software intensive systems.” It is apparent that this means distributed systems, although this is never explicitly stated. The architecture is based on multiple, concurrent views that together address the concerns of the various stakeholders of the system – end users, developers, systems engineers, and project managers. Five views are defined along with notations, and these five will handle both functional and non-functional requirements. The views are designed using an architecture-centered, scenario driven, iterative development process. This summary will cover the architecture in two parts. The first part presented an overview of the architecture and looked at three of the views – the logical architecture, the process architecture, and the development architecture in more detail. This second part of the summary will look at the physical architecture and scenarios and then show the correspondence among the views and how to tailor the architecture to specific projects and document the architectural design.
The physical architecture focuses on non-functional requirements such as availability, reliability, performance, and scalability. The software will execute on a network of computers, or nodes, and each of the key elements – networks, processes, tasks, and objects – must be mapped to these nodes. Several physical configurations may be defined for different activities such as development and testing, or different deployment sites and customers. The mapping must be flexible and have minimal impact on the code. The notation uses many of the same tools as the process architecture.
Scenarios show how the other four views work together by means of use cases and scripts. They represent an abstraction of the most important requirements and are expressed using object scenario diagrams and object interaction diagrams. The scenarios view is redundant with the other views but serves two purposes – discover the architectural elements of the system, and provide validation and illustration, which are the starting point for tests. The notation is similar to the logical view, but uses the connectors of the process view. The logical blueprint is captured using scenario diagrams.
The five views are connected to one another in various ways, following certain rules. The logical view is connected to the process view because of the concurrency of objects. Objects in the logical view are considered active and potentially concurrent, needing their own threads of control. To define the necessary processes and concurrency to support these objects, both inside-out and outside-in strategies are applied. The inside-out strategy defines clusters of tasks that can operate on a single thread of control. The clustering continues until there are a reasonably small number of threads that still allows distribution and use of the physical resources. The outside-in strategy identifies outside stimuli to the system and defines processes to handle the stimuli. The processes are then distributed to servers accordingly. These strategies operate iteratively and in parallel until a mapping of classes onto a set of tasks and processes in the process architecture is achieved.
The logical and development view are closely related, as classes are typically implemented as software modules, but due to additional constraints such as subsystem definition, team organization, expected magnitude of code, degree of expected reuse and commonality, layering principles, and release policy and configuration management there may not always be a one-to-one correspondence between the views. The process and physical views are related by the mappings of processes onto the physical hardware.
Depending on the complexity of the project, not all of the views may be used. For example, if there is only one processor, the physical view may be omitted, or if there is only one process or program the process view may be omitted. For some systems the logical view and development view may be so similar they can be combined. The development process should be iterative, and should focus on the most critical scenarios identified for the system. Eventually, the initial prototype will evolve to become the real system, and after 2 or 3 iterations the architecture should be stable enough that no new major elements need be identified or added. The architectural design is captured in two documents – the Software Architecture Document and the Software Design Guidelines.