|
|
2.1 Software Architecture ApproachesAs a professional discipline, software architecture has at least a dozen schools of thought, including
Alternative approaches to architecture share concepts and principles, but their terminologies differ greatly. Each architecture school is relatively isolated from the others. In the literature of any given school, perhaps one or two other schools are acknowledged, however briefly. None of the schools appears to make any significant use of the results of the others. Since the terminology between these groups varies significantly, communication is difficult, especially between practitioners using different architectural approaches. Upon further study, the goals of each school are quite similar, and each school has some unique value to offer. In addition to these schools, many vendor-driven approaches are tied to specific product lines, such as Sun One, IBM Lotus Notes, and Microsoft .Net. In fact, every vendor appears to have a unique architectural vision for the future founded upon its own product lines. Here, the focus is on those architectural approaches that consider key application drivers, with appropriate product support for underlying capabilities. Architectural ApproachesHere is a brief tour of the major schools of software architecture thought. Zachman FrameworkDerived from IBM research and practice, the Zachman Framework is a traditional architectural approach (i.e., it is decidedly non-object oriented). The Zachman Framework is a reference model comprising thirty architectural viewpoints. The reference model is a matrix, which intersects two paradigms: journalism (who, what, when, why, where, and how) and construction (planner, owner, builder, designer, subcontractor). Architects choose from among these viewpoints to specify a system architecture. Open Distributed ProcessingA formal standard from the International Standards Organization (ISO) and International Telecommunications Union (ITU), Open Distributed Processing defines a five-viewpoint reference model (enterprise, information, computation, engineering, and technology). ODP defines a comprehensive set of terminology, a conformance approach, and viewpoint correspondence rules for traceability. The product of seven years of standards work, ODP is a recent adoption that fully supports object-oriented (OO) and component-based architecture. While ODP may not have the level of recognition that some of the other approaches have, there is significant concrete value in its framework and overall approach to software architecture description. It will be discussed in greater detail later in this chapter. Domain AnalysisA process for the systematic management of software reuse, domain analysis transforms project-specific requirements into more general domain requirements for families of systems. The requirements then enable the identification of common capabilities, which are used as the basis for horizontal frameworks and reusable software architectures. An important capability of this approach is the definition of robust software designs, which are relatively resistant to requirements and context changes. 4+1 View ModelIBM Rational uses a four-viewpoint approach in describing software architecture as part of the Unified Process. The viewpoints include logical, implementation (formerly "component"), process (i.e., runtime), and deployment. The "+1" denotes use case specifications supporting requirements capture. Academic Software ArchitectureAcademic software architecture comprises a community of computer science researchers and educators constituting an academic field. Their educational efforts are focused on basics and fundamentals. In their research contributions, this community avoids proven architectural standards and practices in order to achieve originality, theoretical formality, and other academic goals. Common PrinciplesIt is often said that the principles of software are simple (e.g., simplicity and consistency). Architects agree that managing complexity (i.e., achieving simplicity) is a key goal because it leads to many architectural benefits, such as system adaptability and reduced system cost. For example, a simpler system is easier to test, document, integrate, extend, and so forth.
Simplicity is most necessary in the specification of the architecture itself. Most architectural approaches utilize multiple viewpoints to specify architecture. Viewpoints separate concerns into a limited set of design forces, which can be resolved in a straightforward and locally optimal manner. Consistency enhances system understanding and transfer of design knowledge among parts of the system and among developers. An emphasis on consistency contributes to the discovery of commonality and opportunities for reuse. Architects agree that unnecessary diversity in design and implementation leads to decidedly negative consequences, such as brittle system structure. A more comprehensive treatment of the principles related to the challenges of being a software architect is the VRAPS model named for its principles of Vision, Rhythm Anticipation, Partnering, and Simplification. The model was pioneered in Software Architecture: Organizational Principles and Patterns [Dikel 2001]. The VRAPS principles can be used to make hidden risks and opportunities of software development apparent. Architectural ControversiesThe principal disagreements among architecture schools include (1) terminology, (2) completeness, and (3) a priori viewpoints. Architects disagree on terminology based on their backgrounds or schools of thought. For example, when discussing software interfaces, the consistency principle is variously called standard interfaces, common interfaces, horizontal interfaces, plug-and-play interfaces, and interface generalization. It can also be argued that variation-centered design (from design patterns) and component substitution are largely based upon consistent interface structure. Unnecessary diversity of terminology leads to confusion and sometimes to proprietary advantage. Some vendors and gurus change terminology so frequently that keeping up with their latest expressions becomes a time-consuming career. Differences in terminology lead to miscommunication. In contrast, some distinct areas of disagreement among architecture schools can't be resolved through improved communications alone. The notion of complete models is promoted by legacy OO approaches (e.g., Object Modeling Technique [OMT], the Zachman Framework, and various other models). These groups have promoted a vision that complete models (describing multiple phases of development) are a worthwhile goal of software development projects. Other schools would argue that multiple models are not maintainable, that unnecessarily detailed models are counterproductive, and that architectural significance should be considered when selecting system features for modeling. The selection of architectural viewpoints is a key point of contention among architecture schools. Some schools have preselected a priori viewpoints. Some schools leave that decision to individual projects. The Zachman Framework is an interesting case because it proposes thirty viewpoints, from among which most projects select groups of viewpoints to specify. Variable viewpoints have the advantage that they can be tailored to address the concerns of particular system stakeholders. Predefined viewpoints have the advantage that they can accompany a stable conceptual framework and a well-defined terminology, as well as predefined approaches for resolving viewpoint consistency and architectural conformance. These contrary notions can be summarized in terms of the principle of pragmatism. The pragmatists make a good case because of the preceding advantages as well as because most software systems are too complex to model completely (e.g., multithreaded distributed computing systems). Pragmatism is a key principle to apply in the transition from document-driven to architecture-centered software process. All the architectural approaches are being applied in practice. Software architects should have a working knowledge of the software architectural approaches described here. In addition, they should utilize one of the product-quality architectural frameworks in daily practice. Component architectural development is a challenging area, requiring the best of stable conceptual frameworks supporting sound architectural judgment. |
|
|