ABSTRACT
“ Software architecture” is an important field of study that is becoming more important and more talked about with every passing day. Nevertheless, to our knowledge, there exists little practical guidance on managing software architecture in a real software development organization, from both technical and managerial perspectives .
Systems are built to satisfy an organization's requirements. These requirements dictate the system's performance, availability, security, compatibility with other systems, and the ability to accommodate change over its lifetime. The desire to satisfy these goals with software that has the requisite properties influences the design choices made by a software architect.
We believe that software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. Because its architecture appears early in a product's lifetime, getting it right sets the stage for everything to come—the system's development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel.
Also, compared to other development activities, analyzing architectures is inexpensive. Thus, architectures give a high return on investment because decisions made for the architecture have substantial downstream consequences and because checking and fixing architecture is relatively inexpensive .
We also believe that re-use is achieved best within an architectural context. Re-use of an architecture leads to the creation of families of systems, which in turn leads to new organizational structures and new business opportunities.
We choose the cases presented here to illuminate the types of choices that architects must make to achieve their quality goals and to illuminate how organizational goals affect the final systems. We look at architecture representation and reconstruction techniques as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating architecture's fitness for its purpose. Each of these techniques is derived from our experience, and the experience of our colleagues at the Software Engineering Institute, with a variety of software systems.
The case studies illuminate these technical foundations, and show how they are realized in practice. To benefit from the lessons illuminated by the case studies, you will need a reasonable background in computer science, software engineering, or a related discipline.
PART ONE: VISUALIZING AN ARCHITECTURE
Architecture is the result of a set of business and technical decisions, in general a structural design. There are many influences at work in its design, and the realization of these influences will change depending on the environment in which the architecture is required to perform.
Architecture in turn influences the system being developed, and it may be a core asset that influences the developing organization. The system also has an effect on the developing organization; the architecture; and, potentially, the technical environment. This effect affects the future goals for the system and its organization. The influences and feedback loops that surround architecture form the ABC (Architecture Business Cycle).
1.1 Architecture Business Cycle :
We begin building the ABC by identifying the influences to and from architectures. A business manages this cycle to handle growth, to expand its enterprise area, and to take advantage of previous investments in architecture and system building. Figure 1.1 shows the feedback loops. Some of the feedback comes from the architecture itself, and some comes from the system built from it.
Figure 1.1. The Architecture Business Cycle
ARCHITECTURES ARE INFLUENCED BY
1. SYSTEM STAKEHOLDERS
2. THE DEVELOPING ORGANIZATION
3. THE TECHNICAL ENVIRONMENT
4. THE BACKGROUND AND EXPERIENCE OF THE ARCHITECTS
5. THE TECHNICAL ENVIRONMENT
1.2 Software Process:
Software process is the term given to the organization, reutilization, and management of software development activities. As indicated in the structure of the ABC, architecture activities have comprehensive feedback relationships with each other. These activities include the following:
• Creating the business case for the system
• Understanding the requirements
• Creating or selecting the architecture
• Documenting and communicating the architecture
• Analyzing or evaluating the architecture
• Implementing the system based on the architecture
Ensuring that the implementation conforms to the architecture
1.3 What Makes a "Good" Architecture?
There is no such thing as an inherently good or bad architecture. Architectures are either more or less fit for some stated purpose. An architecture carefully crafted to achieve high modifiability does not make sense for a throw-away prototype. Architectures can in fact be evaluated—one of the great benefits of paying attention to them—but only in the context of specific goals. Nevertheless, there are rules of thumb that should be followed when designing architecture. Some recommended observations are as followed:
• The architecture should feature well-defined modules whose functional responsibilities are allocated on the principles of information hiding and separation of concerns, thus insulating the bulk of the software from change should the infrastructure change.
• Each module should have a well-defined interface that encapsulates or "hides" changeable aspects (such as implementation strategies and data structure choices) from other software that uses its facilities. These interfaces should allow their respective development teams to work largely independently of each other.
• The architecture should never depend on a particular version of a commercial product or tool. If it depends upon a particular commercial product, it should be structured such that changing to a different product is straightforward and inexpensive.
• Every task or process should be written so that its assignment to a specific processor can be easily changed, perhaps even at runtime .
PART TWO: SOFTWARE ARCHITECTURE
2.1 Software Architecture:
Here we will focus on architecture strictly from a software engineering point of view. That is, we will explore the value that software architecture brings to a development project in addition to the value returned to the enterprise. The study of software architecture has evolved by observation of the design principles that designer's follow and the actions that they take when working on real systems. It is an attempt to abstract the commonalities inherent in system design, and as such it must account for a wide range of activities, concepts, methods, approaches, and results.
“ The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements (building blocks), the externally visible properties of those elements, and the relationships among them.”
Let's look at some of the implications of this definition in more detail.
First, architecture defines software elements . The architecture embodies information about how the elements relate to each other. This means that it specifically omits certain information about elements that does not pertain to their interaction. Thus, an architecture is foremost an abstraction of a system that suppresses details of elements.
Second, the definition makes clear that systems can and do comprise more than one structure and that no one structure can irrefutably claim to be the architecture. For example, all nontrivial projects are partitioned into implementation units; these units are given specific responsibilities and are frequently the basis of work assignments for programming teams.
Third, the definition implies that every computing system with software has software architecture because every system can be shown to comprise elements and the relations among them.
Fourth, the behavior of each element is part of the architecture insofar as that behavior can be observed or discerned from the point of view of another element. Such behavior is what allows elements to interact with each other, which is clearly part of the architecture.
Finally, the definition is indifferent as to whether the architecture for a system is a good one or a bad one , meaning that it will allow or prevent the system from meeting its behavioral, performance, and life-cycle requirements.
2.2 Importance Of Software Architecture:
There are fundamentally three reasons for software architecture's importantance.
1. Communication among stakeholders. Software architecture represents a common abstraction of a system that most if not all of the system's stakeholders can use as a basis for mutual understanding, negotiation, consensus, and communication.
2. Early design decisions. Software architecture manifests the earliest design decisions about a system, and these early bindings carry weight far out of proportion to their individual gravity with respect to the system's remaining development, its deployment, and its maintenance life. It is also the earliest point at which design decisions governing the system to be built can be analyzed.
3. Transferable abstraction of a system. Software architecture constitutes a relatively small, intellectually graspable model for how a system is structured and how its elements work together, and this model is transferable across systems. In particular, it can be applied to other systems exhibiting similar quality attribute and functional requirements and can promote large-scale re-use.
2.3 Architectural Patterns, Reference Models, and Reference Architectures
Reference models, architectural patterns, and reference architectures are not architectures; they are useful concepts that capture elements of an architure. Each is the outcome of early design decisions. The relationship among these design elements is shown in Figure2.1.
2.5 Designing the Architecture
We describe a method for designing an architecture to satisfy both quality requirements and functional requirements. We call this method Attribute-Driven Design (ADD). ADD takes as input a set of quality attribute scenarios and employs knowledge about the relation between quality attribute achievement and architecture in order to design the architecture. The ADD method can be viewed as an extension to most other development methods, such as the Rational Unified Process.
ATTRIBUTE-DRIVEN DESIGN (ADD)
ADD is an approach to defining a software architecture that bases the decomposition process on the quality attributes the software has to fulfill. It is a recursive decomposition process where, at each stage, tactics and architectural patterns are chosen to satisfy a set of quality scenarios and then functionality is allocated to instantiate the module types provided by the pattern. We begin by briefly presenting the steps performed when designing an architecture using the ADD method. We will then discuss the steps in more detail.
1. Choose the module to decompose. The module to start with is usually the whole system.
2. Refine the module according to these steps:
• Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. This step determines what is important for this decomposition.
• Choose an architectural pattern that satisfies the architectural drivers. Create (or select) the pattern based on the tactics that can be used to achieve the drivers. Identify child modules required to implement the tactics.
• Instantiate modules and allocate functionality from the use cases and represent using multiple views.
• Define interfaces of the child modules. The decomposition provides modules and constraints on the types of module interactions. Document this information in the interface document for each module.
• Verify and refine use cases and quality scenarios and make them constraints for the child modules. This step verifies that nothing important was forgotten and prepares the child modules for further decomposition or implementation.
3. Repeat the steps above for every module that needs further decomposition .
PART THREE: Documenting Software Architectures
Documenting an architecture is a matter of recording the relevant views and then recording the information that applies across the views. The architecture serves as the blueprint for both the system and the project developing it. It defines the work assignments that must be carried out by design and implementation teams. Documenting the architecture is the crowning step to crafting it. Even a perfect architecture is useless if no one understands it or (perhaps worse) if key stakeholders misunderstand it. If you go to the trouble of creating a strong architecture, you must describe it in sufficient detail, without ambiguity, and organized in such a way that others can quickly find needed information. Otherwise, your effort will have been wasted because the architecture will be unusable. Here is a simple three-step procedure for choosing the views for your project.
- Produce a candidate view list. Begin by building a stakeholder/view table for your project
- Combine views
- Prioritize . At this point you need to decide what to do first.
There is no industry-standard template for documenting a view, but the seven-part standard organization that we suggest in this section has worked well in practice.
1. Primary presentation shows the elements and the relationships among them that populate the view. The primary presentation should contain the information you wish to convey about the system (in the vocabulary of that view) first.
2. Element catalog details at least those elements and relations depicted in the primary presentation.
3. Context diagram shows how the system depicted in the view relates to its environment in the vocabulary of the view.
4. Variability guide shows how to exercise any variation points that are a part of the architecture shown in this view.
5. Architecture background explains why the design reflected in the view came to be.
An architecture background includes
Rationales, explaining why the decisions reflected in the view were made and why alternatives were rejected.
Analysis results, which justify the design or explain what, would have to change in the face of a modification.
Assumptions reflected in the design.
6. Glossary of terms used in the views, with a brief description of each.
7. Other information .
PART FOUR: Reconstructing Software Architectures
Suppose we have a system but we don't know its architecture. Perhaps the architecture was never recorded, or was lost, or the system diverged from the architecture through evolution. How do we maintain such a system? How do we manage its evolution to maintain the quality attributes that its architecture has provided for us? Architecture reconstruction is the process where the "as-built" architecture of an implemented system is obtained from an existing system
Architecture reconstruction is an interpretive, interactive, and iterative process involving many activities; it is not automatic. It requires the skills and attention of both the reverse engineering expert and the architect (or someone who has substantial knowledge of the architecture), largely because architectural constructs are not represented explicitly in the source code.
Architecture reconstruction has been used in a variety of projects ranging from MRI scanners to public telephone switches and from helicopter guidance systems to classified NASA systems. It has been used
• to redocument architectures for physics simulation systems.
• to understand architectural dependencies in embedded control software for mining machinery.
• to evaluate the conformance of a satellite ground system's implementation to its reference architecture.
• to understand different systems in the automotive industry.
Familiarity with compiler construction techniques and utilities such as GREP, sed, awk, Perl, python, and lex/yacc is also important.
Software architecture reconstruction comprises the following activities, carried out iteratively:
1. Information extraction. The purpose of this activity is to extract information from various sources.
Figure 4.1. Architecture reconstruction activities.
2. Database construction. Database construction involves converting this information into a standard form such as the Rigi Standard Form (a tuple-based data format in the form of relationship
3. View fusion. View fusion combines information in the database to produce a coherent view of the architecture.
4. Reconstruction. The reconstruction activity is where the main work of building abstractions and various representations of the data to generate an architecture representation takes place.
As you might expect, the activities are highly iterative. Figure 10.1 depicts the architecture reconstruction activities and how information flows among them. The reconstruction process needs to have several people involved. These include the person doing the reconstruction (reconstructor) and one or more individuals who are familiar with the system being reconstructed (architects and software engineers).The reconstructor extracts the information from the system and either manually or with the use of tools abstracts the architecture from it. The architecture is obtained by the reconstructor through a set of hypotheses about the system. These hypotheses reflect the inverse mappings from the source artifacts to the design (ideally the opposite of the design mappings). They are tested by generating the inverse mappings and applying them to the extracted information and validating the result. To most effectively generate these hypotheses and validate them, people familiar with the system must be involved, including the system architect or engineers who have worked on it (who initially developed it or who currently maintain it).
The results of architectural reconstruction can be used in several ways. If no documentation exists or if it is out of date, the recovered architectural representation can be used as a basis for redocumenting the architecture. This approach can also be used to recover the as-built architecture, to check conformance against an "as-designed" architecture. This assures us that our maintainers (or our developers, for that matter) have followed the architectural edicts set forth for them and are not eroding the architecture, breaking down abstractions, bridging layers, compromising information hiding, and so forth. The reconstruction can also be used as the basis for analyzing the architecture or as a starting point for re-engineering the system to a new desired architecture. Finally, the representation can be used to identify elements for re-use or to establish an architecture-based software product line.
PART FIVE: Software Architecture in the Future
The history of programming can be viewed as a succession of ever-increasing facilities for expressing complex functionality. In the beginning, assembly language offered the most elementary of abstractions: exactly where in physical memory things resided (relative to the address in some base register) and the machine code necessary to perform primitive arithmetic and move operations.
The 1970s saw a concern with the structuring of programs to achieve qualities beyond correct function.
Figure 5.1. Growth in the types of abstraction available over time
In the 1980s, module-based programming languages, information hiding, and associated methodologies crystallized into the concept of objects.
In the 1990s, standard object-based architectures, in the form of frameworks, started appearing.
In the current decade, we see the rise of middleware and IT architecture as a standard platform. Purchased elements have security, reliability, and performance support services that a decade ago had to be added by individual project developers. We summarize this discussion in Figure 1.1. We look at the Architecture Business Cycle again and identify some of the yet to be solved problems associated with software architecture and discuss why more research is needed. We will examine the
areas of software architecture where things are not as we would wish and point out areas where the research community has some work to do.
CONCLUSION _
Software architecture plays a pivotal role in allowing an organization to meet its business goals. It is an attempt to abstract the commonalities inherent in system design, and as such it must account for a wide range of activities, concepts, methods, approaches, and results. The study of software architecture has evolved by observation of the design principles that designers follow and the actions that they take when working on real systems. For that reason, other definitions of architecture are present in the software engineering community.
Software architecture is brought to bear when the people issues are exposed: making the system perform well, building the system within cost constraints, achieving desired benefits, letting teams work cooperatively to build the system, helping the maintainers succeed, letting all the stakeholders understand the system. With this in mind, we can offer our safest prediction. Architecture will continue to be important as long as people are involved in the design and development of software.
REFERENCES _
1. Software Architecture in Practice, Second Edition, Len Bass, Paul Clements, Rick Kazman, 2003.
2. Recommended Best Industrial Practice for Software Architecture Evaluation, Clements, Kazman, Northrop, and Zaremski.
3. Illuminating the Fundamental Contributors to Software Architecture Quality, Bachmann F, Bass L, Klein M.
4. Achieving Usability through Software Architecture, Bass L, John B, Kates J.
5. Jones, T. Capers, Estimating Software Costs . McGraw-Hill, 2000 .
No comments:
Post a Comment