The many web pages and books on software architecture have provided dozens, if not hundreds, of definitions of software architecture and related terms. Given this plethora of definitions, we must settle on a set of key definitions for the purposes of communicating software architecture concepts. What follows are some key definitions required for a discussion of software architecture. Additional definitions can be found in the recommended readings located at the end of this chapter.
The Institute of Electrical and Electronic Engineers (IEEE) recently issued a recommended practice regarding Software Architecture: IEEE 1471. The definitions we provide in this book are closely aligned with IEEE 1471. These include definitions of system, stakeholder, architect, architecture, architectural views, and architectural viewpoints. IEEE 1471 defines the following key terms:
- System is a set of components that accomplishes a specific function or set
of functions.
- ‘Architecture is the fundamental organization of a system embodied in its
components, their relationships to each other, and to the environment,
and the principles guiding its design and evolution’.
- Architectural Description is a set of products that document the architecture.
- Architectural View is a representation of a particular system or part of a
system from a particular perspective.
- Architectural Viewpoint is a template that describes how to create and
use an architectural view. A viewpoint includes a name, stakeholders,
concerns addressed by the viewpoint, and the modeling and analytic
conventions.
The IEEE definitions are intentionally general, to cover many types of software architecture, and are not specific enough to provide detailed guidance to architects and developers of large-scale systems. As such, a large portion of the book is devoted to the description of specific architectural viewpoints, defined in the UML, which can be applied to many different largescale development projects. In addition, most of these viewpoints can also be applied to smaller development efforts. In this book, these viewpoints are illustrated as architectural views for an example system. The System Architecture is the set of entities, the properties of those entities, and relationships among them that define structure of the system. The Software
Architecture is the set of software components, subsystems, relationships, interactions, the properties of each of these elements, and the set of guiding principles that together constitute the fundamental properties and constraints of a software system or set of systems.
Software Architecting refers to the analysis, design, documentation, review, approval, and other related activities concerned with the definition and management of the software architecture. Architectural Views provide representations of the architecture that can be used to guide construction, manage, explore, train personnel, test, and perform other engineering tasks related to creation and maintenance of the software system. Some uses for views include:
- Capturing the design decisions both early on, and as enhancements are
made
- Capturing information about the runtime environment for the software
- Providing constraints on the lower-level design and implementation
- Architectural Description is a set of products that document the architecture.
- Architectural View is a representation of a particular system or part of a
system from a particular perspective.
- Architectural Viewpoint is a template that describes how to create and
use an architectural view. A viewpoint includes a name, stakeholders,
concerns addressed by the viewpoint, and the modeling and analytic
conventions.
For each of these views there is a group of associated Stakeholders. The stakeholders may include project and program managers, development team managers and technical leads, system engineers, the test organization, and individual developers. This group of stakeholders may be building the early versions of the software, or may be making maintenance modifications to software that has existed for some time. The architectural views are used to communicate with the stakeholders and, as such, must be carefully crafted
to communicate the appropriate information at the appropriate level of detail to the set of associated stakeholders for that view. While the definition of software architecture terminology provided above is
useful, the definitions are still somewhat fuzzy since some of the terms used in the definitions are not themselves clearly defined. The following sections of this chapter will help refine and clarify these definitions. Architecting software is primarily about software design – design in the large. Thus, the focus of architecture is on the arrangement of the larger aspects of software systems such as subsystems and components rather than classes and objects. To model software systems in the large requires examining
both the static or build-time view and the dynamic or runtime behaviors of the software. Another way of thinking about software architecture is to think about some of the typical questions that can be answered by views of the architecture:
• What are the subsystems or components of the software?
• What are the responsibilities of the components?
• What are the interfaces provided/consumed by these subsystems or components?
• What subsystems or components are impacted by a change to the software?
• How much retesting is required if we change this component?
• What components are involved in installing this change?
• How are parts of the system to be physically distributed?
• How will a change impact the performance of the system?
• What development teams are impacted by a change to this interface?
• How much effort is involved in the development of this functionality?
Since the software architecture being defined is often part of an even larger system, it is often useful to concentrate on the subset of the system for which a particular architecture is being defined. Examples of this type of system subset include a set of components being developed by a particular development team
or a set of components that will be developed rather than purchased. This subset of the system can be referred to as the system under design. This means that even though only part of a larger system is being designed, any external entities can be considered external to the system under design. This approach
allows architectural definition to focus on the parts of the system that are critical and delay concerns about parts of the system which are not yet defined.
What software architecture is not
The software architecture does not include the hardware, network, or physical plant architecture. As such, the software architecture description is not intended to convey the complete description of the system, only the software within that system and any context needed to create the software. As an example, information such as hardware model number, hardware configuration information, routers, or LAN cards is not the focus in software architecture views. Other views, tables, or documents may be used to specify this type of information. However, this type of information should be included or referenced if it influences the software design. In general, the software architecture description should not duplicate information found in other sources, such as requirements documents or marketing information. Duplication causes extra rework when these other documents change. The software architecture description must be kept at the appropriate level
of detail. The team that defines the architecture must keep each view at the right level of detail and avoid showing more than one level of detail in a particular view, unless the reasons for doing so are clear and agreed upon in advance. Low-level implementation details should not be included in the software architecture description. For example, a context or subsystem view should not include details about the implementation mechanism for a particular interface. In addition, descriptions of specific implementation mechanisms such as compiler optimizations, shared versus static libraries, COTS class or method names, or file format should not be included in the software architecture views.
Attributes of software architecture
Many different attributes or qualities are of interest in software architecture. These qualities are important because they impact the design and development of many different parts of the software. Some of these qualities include:
• Cultural adaptability – support for multiple languages and cultural differences
• Security – prevent unauthorized access
• Data integrity – does not corrupt or provide bad data
• Maintainability characteristics
Portability – can software be ported to other platformss, Changeability – ability to add new functions and change existing functions, Fragility – changes to fragile software tend to break existing functions, Rigidity – software is difficult to change even in simple ways, Duplication – software with duplication strewn throughout ismore difficult to maintain because it is larger and because change is not localized, Understandability – can the software be understood so that changes can be mades Debugging support – support for multiple levels of online debugging.
• Testability – software can be tested effectively (impacts changeability)
• Usability – a measure of the effectiveness of the human interface
• Operational system aspects:
Availability – percentage of the time system is functioning, Manageability – ability to inspect and manage executing components, Upgradeability – can system be upgraded while running, how difficult are upgrade procedures, Reliability – ability to perform required functions over specified period of time and Recoverability – time required to recover from a failure.
• Performance
Response – is the response fast enough for normal and extreme usage scenarios, Scalability – system capacity/throughput can be increased or decreased as necessary, Capacity/Throughput – handle heavy loads and still maintain response
• Safety – system does not create hazards in the real world
All of these attributes of the architecture are typical concerns for the architecture team. Members of the architecture team need to constantly evaluate the software architecture to determine if it meets the desired goals with respect to these characteristics. At first blush, this evaluation seems straightforward, but it is not. Increasing one attribute often results in a non-linear decrease in a different attribute. For example, an increase in modifiability might reduce performance. An increase in changeability might negatively impact testability. In addition, the requirements with respect to these properties are not easy to specify. Many of these attributes can only be assessed qualitatively given current tools and practice. Architects must constantly prioritize and manage the trade-offs between these attributes for a given project. Some of these properties also imply that architects are concerned with implementation mechanisms. For example, mechanisms involving data persistence, transactions, and component error handling often need consistent
approaches in order to meet the architectural goals. This often means coping with how to integrate legacy components alongside new components. To a large extent, the practice of software architecture is the attempt to balance a series of fuzzy trade-offs for the system stakeholders over what are often immensely complex systems. Looking at the whole system at once is simply not possible. Architects need tools to break down problems and reason about the parts, the interaction of the parts, and how the entire system fits together.
Definitions of other key architecture-related terms
The following are a few other definitions that are required for understanding the discussions in the remainder of the book. We recommend the reader rely on the recommended readings for a complete set of architecture-related definitions. Terms that are associated with a particular aspect of software architecture, for example terms associated with the analysis and design process, are defined in the appropriate sections later in this book. The following terms will provide a clearer understanding of concepts key to large-scale software architecture:
Architectural Patterns – define a general set of element types and their interactions. Examples of Architectural Patterns include Pipes and Filters, Model–View–Controller, and Reflection. Architectural Style – As the term coined by Garlan and Shaw, it is an idiomatic pattern of system organization. For example, a client–server system is an architectural style. Many of the original architectural styles have been
reformulated as patterns. Build Systems – Development teams typically employ a set of tools that facilitate the translation of a large source code base into a set of libraries and executables in an orderly manner. This usually involves interacting with configuration management tools as well as tools such as the ‘Make’ utility that utilizes software dependencies to perform incremental builds. Commercial Off-the-Shelf (COTS) Products – These include software components that are purchased from software vendors or obtained from open source. Some authors use the term ‘common’ in place of the term commercial to prevent confusion with using the term ‘commercial’ for open source software.
Component – A construct that groups implementation constructs and provides/consumes a set of interfaces. A component is a modular and easily replaceable implementation construct. The UML definition includes executable processes, applets, EJB, and code libraries as part of the componentdefinition. Some authors further categorize components to include conceptual or logical components. However, we define views only in terms of the runtime aspects of components.
Domain – A domain is an area of concern. For example, the ‘problem domain’ defines the ‘what’ aspect of the system under design. The ‘solution domain’ is the ‘how’ aspect. A large complex problem is often broken into sub-domains that address only one aspect of the larger problem.
Model – A representation used to understand or document one or more aspects of a problem or solution. With the UML, the model is often kept in a tool that will support the creation of multiple views. In this case, the tool can provide the ability to keep a series of partial views of a complex model consistent.
Top-Level Software Architecture Description – The set of views of the system that encompass the highest-level perspective of the software. This perspective tends to focus on subsystems and components as documented in the top-levelsoftware design document.
Subsystem – A collection of classes and components that are grouped to form a development package. These subsystems need to be defined in such a way as to facilitate having them assigned to different, possibly geographically diverse, development teams.
Other types of architectures
Architecture is used in conjunction with many adjunct terms such as technical architecture, business architecture, enterprise architecture, reference architecture, product line architecture, and information architecture. To some extent, all these ‘architectures’ have confused and obscured the definition of software
architecture. The following list will briefly describe some of these in order to clarify how they relate to software architecture:
Enterprise Architecture is generally defined in terms of its constituent architectures. These include the business architecture, application architecture, technology architecture, software infrastructure architecture, and information architecture. The enterprise architecture provides the vision and consistent principles that cross all the constituent architecture types and addresses objectives such as security, flexibility, make versus buy decisions, and reuse.
The Business Architecture defines the key business strategies, organization, goals, and related business processes. The software architecture should be complementary with the business architecture. We must remember that the final goal of most software is to make the business successful, not simply to produce an elegant software design.
At the enterprise level, the Application Architecture may be more of a set of guidelines on how the various software architectures should be constructed consistently across the enterprise. For a specific product, the application architecture is the software architecture for that product.
The Technology/Infrastructure Architecture refers to the network connectivity, hardware upon which the software runs, network routers, operating systems, and other technologies that facilitate the communication among the distributed software components and support the execution environment of
the software.
The Data Architecture, sometimes referred to as the Information Architecture, refers to how the data is structured, stored, and handled either in the enterprise or for a particular project. The definition of the data architecture involves the specification of the number and type of databases, the logical and physical database design, the allocation of data to servers, the strategy for data replication and archival, as well as the strategy and design of a data warehouse.
The U.S. Army’s Joint Technical Architecture – Army (JTA-Army) provides the following definition:
A Technical Architecture is the minimal set of rules governing the arrangement, interaction, and interdependence of the parts or elements that together may be used to form an information system. Its purpose is to ensure that a conformant system satisfies a specified set of requirements. It is the build code for the Systems Architecture being constructed to satisfy Operational Architecture requirements.
A Product-line Architecture is used to define a set of products that are developed by a company or organization within the company. The similarities within that set of products allow for sharing of design and implementation information among the various teams developing the products. In this way, the products can be more consistent in the way they are designed, developed, tested, supported, and in their appearance to the end user. In addition, these products can be developed in a more cost-effective manner, due to the design and implementation reuse potential.
The term Reference Architecture refers to the definition of an architecture for a particular application domain. An example domain might be satellite ground control systems or telecommunications switch network management. The reference architecture describes the high-level set of elements involved in applications from a particular domain along with their interactions. These elements must intentionally be left at a high level to apply to a large number of systems for that particular domain. Reference architectures are often used to focus on subsystem definition rather than application process level definition. Reference
architecture definitions also provide an excellent framework for development of a specific system in that application domain and can save the software architects a significant amount of time rediscovering these elements. In addition, the naming conventions used in the reference architecture provide a common
language for architects and application developers to communicate. The functional and interface definitions provided in the reference architecture also provide an opportunity for third-party COTS products to be developed that can be used by software architects for significant portions of the final system. The techniques and many of the architectural views described in this book can also be used for developing product-line, data, and reference architectures.
Posted by creasoft
