SOFTWARE ARCHITECTURE
1. Historical Improvement:
Software architecture began as a field of study with early observations by Parnas, Dijkstra, and others that how software is structured matters as much as its ability to compute the correct result. Structured programming was the small-scale expression of this realization in the 1970s and 1980s, when object-oriented design emerged as a larger-scale manifestation. In the 1990s, interest in software architecture blossomed as Perry and Wolf, Shaw and Garlan, Kruchten, and others wrote about large-scale structures, reusable styles and patterns, and multiple coordinated views.
The software engineering community has adopted the term to denote the gross-level structure of software-intensive systems. The importance of structure was already acknowledged early in the history of software engineering. The first software programs were written for numerical calculations using programming languages that supported mathematical expressions and later algorithms and abstract data types. Programs written at that time served mainly one purpose and were relatively simple compared to the current large-scale diverse software systems. Over time due to the increasing complexity and the increasing size of the applications, the global structure of the software system became an important issue. Already in 1968, Dijkstra proposed the correct arrangement of the structure of software systems before simply programming. He introduced the notion of layered structure in operating systems, in which related programs were grouped into separate layers, communicating with groups of programs in adjacent layers. Later, Parnas maintained that the selected criteria for the decomposition of a system impact the structure of the programs and several design principles must be followed to provide a good structure. Within the software engineering community, there is now an increasing consensus that the structure of software systems is important and several design principles must be followed to provide a good structure.
Looking back at the historical developments of architecture design we can conclude that similar to the many concepts in software engineering the concept of software architecture has also evolved over the years. We observe that this evolution took place at two places. First, existing stable concepts are specialized with new concepts providing a broader interpretation of the concept of software architecture. Second, existing interpretations on software architectures are abstracted and synthesized into new and improved interpretations. Let us explain this considering the development of the definitions in the last decade. The set of existing definitions is large and many other definitions have been collected in various publications.
2. Definition of Software Architecture: What is It?
The term architecture is not new and has been used for centuries to denote the physical structure of an artifact. The definition in Websters' Dictionary:
Architecture: 1: the art or science of building; specifically: the art or practice of designing and building structures and especially habitable ones2 a>:formation or construction as or as if as the result of conscious actb: a unifying or coherent form or structure 3: architectural product or work4: a method or style of building5: the manner in which the components of a computer or computer system are organized and integrated.
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them (Bass, L., Clements, P., Kazman, R., 2003).
"Externally visible” properties refer to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Let us look at some of the implications of this definition in more detail.
First, architecture defines elements. The architecture embodies information about how the elements relate to each other. This means that architecture 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 that do not affect how they use, are used by, relate to, or interact with other elements. In nearly all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts. Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal implementation—are not architectural.
Second, the definition makes clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. For example, all non-trivial projects are partitioned into implementation units; these units are given specific responsibilities, and are the basis of work assignments for programming teams. This kind of element will comprise programs and data that software in other implementation units can call or access, and programs and data that are private. In large projects, the elements will almost certainly be subdivided for assignment to subteams. This is one kind of structure often used to describe a system. It is a very static structure, in that it focuses on the way the system’s functionality is divided up and assigned to implementation teams.
Other structures are much more focused on the way the elements interact with each other at runtime to carry out the system’s function. Suppose the system is to be built as a set of parallel processes. The set of processes that will exist at runtime, the programs in the various implementation units described previously that are strung together sequentially to form each process, and the synchronization relations among the processes form another kind of structure often used to describe a system.
Third, the definition implies that every software system has an architecture because every system can be shown to be composed of elements and relations among them. In the most trivial case, a system is itself a single element -- an uninteresting and probably non-useful architecture, but an architecture nevertheless. Even though every system has an architecture, it does not necessarily follow that the architecture is known to anyone. Unfortunately, an architecture can exist independently of its description or specification, which raises the importance of architecture documentation and architecture reconstruction.
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. This behavior is what allows elements to interact with each other, which is clearly part of the architecture. This does not mean that the exact behavior and performance of every element must be documented in all circumstances; but to the extent that an element’s behavior influences how another element must be written to interact with it or influences the acceptability of the system as a whole, this behavior is part of the software architecture.
Finally, the definition is indifferent as to whether the architecture for a system is a good one or a bad one, meaning that the architecture will allow or prevent the system from meeting its behavioral, performance, and life-cycle requirements. Assuming that we do not accept trial and error as the best way to choose an architecture for a system—that is, picking an architecture at random, building the system from it, and hoping for the best—this raises the importance of architecture evaluation.
The one of the other definition is "As the size and complexity of software systems increase, the design and specification of overall system structure become more significant issues than the choice of algorithms and data structures of computation. Structural issues include the organization of a system as a composition of components; global control structures; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; dimensions of evolution; and selection among design alternatives. This is the software architecture level of design. " (Shaw, M. & Garlan, D., 1996).
The understanding on the concept of software architecture is increasing though there are still several ambiguities. Architectures consist of components and relations, but the term components may refer to subsystems, processes, software modules, hardware components or something else. Relations may refer to data flows, control flows, call-relations, part-of relations etc.
Software architecture must be distinguished from low-level design (e.g., design of component internals and algorithms) and implementation, on the one hand, and other kinds of related architectures, on the other. For instance, software architecture is not the information (or data) model, though it uses the information model to get type information for method signatures on interfaces, for example. It is also not the architecture of the physical system, including processors, networks, and the like, on which the software will run. However, it uses this information in evaluating the impact of architectural choices on system qualities such as performance and reliability. More obviously, perhaps, it is also not the hardware architecture of a product to be manufactured. While each of these other architectures typically have their own specialists leading their design, these architectures impact and are impacted by the software architecture, and where possible, should not be designed in isolation from one another. This is the domain of system architecting.
3. Need to Software Architecture: Why It is Important?
There are several reasons for applying software architecture design: (Softrware Architecture, n.d.).
-Faciliate communication between stakeholdersWith the increasing complexity of current software systems the need for understanding has grown. Unlike lower-level design descriptions which are mainly used by the developers of the software systems, software architectures represent a common-high-level abstraction that needs to be understood not only by designers and maintainers but also by other stakeholders, such as project managers, customer, users etc. These stakeholders have different concerns that they would like to focus on. Modeling the system at a high-level using a common architecture language facilitates the communication with the different stakeholders and enables the analysis of the priorities. To the project managers the software architecture may be used to communicate the corresponding cost and schedule to build the software system. To the developers the software architecture may be used to provide a gross-level understanding of the software system so that they can grasp the responsibilities and interdependencies of the higher-level structures. To the users the software architecture may communicate the requirements that will be fulfilled by the software system. By abstracting away from much implementation detail, software architectures provide a common perspective of the whole system and as such support the communication between the different stakeholders.
-Support effective work allocation and parallel development A well-defined software architecture provides a structural decomposition of loosely coupled architectural components with clear responsibilities. The architecture design phase is generally followed by the analysis and system design phase. Since the architectural components are relatively independent from each other, the subsequent development work be partitioned rather easily and proceed in a parallel manner. Each partitioned component can be analyzed and developed by a team with specialized skills.
-Provide a means for directing the subsequent developmentThe software architecture prescribes the structure of the software system and as such directs the subsequent phases of the software development process. Software architectures embody the first design decisions of the software system and put constraints on the design alternatives. This eases the job of the developers of the software systems who can faster analyze and select different design alternatives using the prescribed structure as a basis for their design decisions.
Provide a means for evaluationA software architecture may be used for evaluation before the system is actually built. Each software system is developed to fulfill particular requirements. The software architecture gives a clear insight in the requirements it can fulfill and the possible variations and constraints. In this way, it may be used to evaluate and prioritize the kind of requirements that need to be fulfilled. Software architectures can also serve in the evaluation of the desired changes after the system has been built.
Support quality factorsSoftware architecture support the quality factors such as reuse, adaptability and maintenance. Software architectures provide an abstract structure of the system and inherently anticipate different kinds of changes that will occur in the system. This will minimize the cost for evolution and maintenance because the maintainers will be directed to allowable changes. Software architectures provide the basis for understanding, development and maintenance, and evaluation and maintenance of the system in cost-effective ways. Since it abstracts away from many details it serves as a framework for a families of systems remaining relatively constant over time. This provides the opportunity to reuse the architecture for producing many similar systems in a rather predictable way. Architecture development partitions the system among relatively independent components that are generally developed separately. Besides of reusing the complete software architecture, this allows for reusing separate components to develop new architectures.
According to Malan and Creary, architecture serves both technical and organizational purposes. On the organizational side, the architecture helps in:
-communicating the high-level design: A number of stakeholders need to understand the system at a fairly gross level. These include higher-level managers, many of the cross-functional team (e.g., marketing, quality assurance, and learning products or user documentation), and may include customers too. Modeling the system at a high level facilitates communication of the high-level system design or architecture. The reduction in detail makes it easier to grasp the assignment of significant system responsibilities to high-level structures. Moreover, it satisfies the constraint that, though seemingly trivial, has important implications for communication--with suitable leveling and nesting, even large and complex architectures can be conveyed using overhead transparencies and documented using traditional 8.5 x11'' paper!
-providing the system context: The developers (and future maintainers) also need to understand the system at a gross level. In large systems, developers cannot efficiently understand the details of the entire system. They need a detailed understanding of the more narrowly-scoped portions of the system that they work on. But without an understanding of the responsibilities and interdependencies of the higher-level structures, individual development and optimization of the substructures will tend to result in a sub-optimal system. This is both from the point of view of system characteristics like performance, as well as effort in integration and maintenance.
-work allocation: Where architectures decompose the system into substructures that are relatively independent, have clear responsibilities, and communicate with each other through a limited number of well-defined interfaces, the development work can be partitioned effectively. This allows parallel development work to proceed in relative independence between integration points. This is especially important in large projects, or projects where the teams are geographically dispersed or subcontractors are used. Moreover, since these units tend to be centers of specialization of function or service, they also afford opportunities for skill specialization among developers. This independence and focus makes development more efficient. The design of the system architecture can be viewed as the dual of designing the organization architecture. If this duality is ignored and the organization architecture is not compatible with the system architecture, then it can influence and degrade the system architecture.
On the technical side, architecture allows us to design better systems:
-meet system requirements and objectives: Both functional and non-functional requirements can be prioritized as ``must have'' vs. ``high want'' vs. ``want'', where ``must have'' identifies properties that the system must have in order to be acceptable. An architecture allows us to evaluate and make tradeoffs among requirements of differing priority. Though system qualities (also known as non-functional requirements) can be compromised later in the development process, many will not be met if not explicitly taken into account at the architectural level.
-enable flexible distribution/partitioning of the system: A good architecture enables flexible distribution of the system by allowing the system and its constituent applications to be partitioned among processors in many different ways without having to redesign the distributable component parts. This requires careful attention to the distribution potential of components early in the architectural design process.
reduce cost of maintenance and evolution: Architecture can help minimize the costs of maintaining and evolving a given system over its entire lifetime by anticipating the main kinds of changes that will occur in the system, ensuring that the system's overall design will facilitate such changes, and localizing as far as possible the effects of such changes on design documents, code, and other system work products. This can be achieved by the minimization and control of subsystem interdependencies.
-increase reuse and integrate with legacy and third party software: An architecture may be designed to enable and facilitate the (re)use of certain existing components, frameworks, class libraries, legacy or third-party applications, etc.
4. Creating Software Architecture: How? (This part is all quoted from http://www.bredemeyer.com/howto.htm)
How is Software Architecture Created?
We have worked with and studied dozens of architecting projects, and distilled what we believe to be the best practices and pitfalls that would help architects successfully create and deploy their architectures. Based on this experience, we have created our Visual Architecting Process™ (VAP). Though our architecting process lays out the activities and guidelines that we have derived from real-world experience, no project that we studied followed exactly this process. Also, every project that we have consulted with or coached, has adapted the process. This has been true of other software development methods, such as SA/SD, OMT and Fusion (Malan, Coleman and Letsinger, 1995). It would appear that a method is not fully embraced by a project team until they have adapted it to their particular project needs. In this regard, methods are somewhat like architectures!
The architecting process incorporates a technical process and an organizational process. The technical process includes steps and heuristics for creating a good architecture. However, a technically good architecture is not sufficient to ensure the successful use of the architecture, and the organizational process is oriented toward ensuring support for, and adoption of, the architecture.
The Technical Process
Overview
The focal deliverable of the architecting process is the architecture document (set), motivating and describing the structure of the system through various views. However, though system structuring is at the heart of the architecting process, it is just one of several activities critical to the creation of a good architecture (Figure P1). Architectural requirements are needed to focus the structuring activities. Different architectural approaches tend to yield differing degrees of fit to various system requirements, and evaluating alternatives or performing architectural tradeoff analyses are an important adjunct to the structuring phase. Lastly, a validation phase provides early indicators of, and hence an opportunity to resolve, problems with the architecture.
Architectural Requirements
Architectural requirements are a subset of the system requirements, determined by architectural relevance. The business objectives for the system, and the architecture in particular, are important to ensure that the architecture is aligned with the business agenda. The system context helps determine what is in scope and what is out of scope, what the system interface is, and what factors impinge on the architecture. The system value proposition helps establish how the system will fit the users’ agenda and top-level, high-priority goals. These goals are translated into a set of use cases, which are used to document functional requirements. The system structure fails if it does not support the services or functionality that users value, or if the qualities associated with this functionality inhibit user performance or are otherwise unsatisfactory. System qualities that have architectural significance (e.g., performance and security, but not usability at the user interface level) are therefore also important in directing architectural choices during structuring.
Of course, requirements may already have been collected by product teams. In that case, the architecture team needs to review those requirements for architectural relevance and completeness (especially with respect to non-functional requirements), and be concerned with requirements for future products that the architecture will need to support.
Lastly, for the architecture of a product line or family, architectural requirements that are unique to each product and those that are common across the product set need to be distinguished so that the structure can be designed to support both the commonality and the uniqueness in each product.
Architecture Specification
The architecture is created and documented in the system structuring phase. This is decomposed into sub-phases, along the lines of our model of software architecture:
Meta-Architecture
First, the architectural vision is formulated, to act as a beacon guiding decisions during the rest of system structuring. It is a good practice to explicitly allocate time for research—or scavenging for ideas—in documented architectural styles, patterns, dominant designs and reference architectures, other architectures your organization, competitors, partners, or suppliers have created or you find documented in the literature, etc. Based on this study, and your and the team’s past experience, the meta-architecture is formulated. This includes the architectural style, concepts, mechanisms and principles that will guide the architecture team during the next steps of structuring.
Conceptual Architecture
The system is decomposed into components and the responsibilities of each component, and interconnections between components are identified. The intent of the conceptual architecture is to direct attention at an appropriate decomposition of the system without delving into the details of interface specification and type information. Moreover, it provides a useful vehicle for communicating the architecture to non-technical audiences, such as management, marketing, and many users.
Logical Architecture
The conceptual architecture forms the starting point for the logical architecture, and is likely to be modified as well as refined during the course of the creation of the logical architecture. Modeling the dynamic behavior of the system (at the architectural—or component—level) is a useful way to think through and refine the responsibilities and interfaces of the components. Component specifications make the architecture concrete. These should include a summary description of services the component provides, the component owner’s name, IID and version names, message signatures (IDL), a description of the operations, constraints or pre-post conditions for each operation (these may be represented in a state diagram), the concurrency model, constraints on component composition, a lifecycle model, how the component is instantiated, how it is named, a typical use scenario, a programming example, exceptions, and a test or performance suite.
Execution Architecture
An execution architecture is created for distributed or concurrent systems. It is formed by mapping the components onto the processes of the physical system. Different possible configurations are evaluated against requirements such as performance and scaling.
Architecture Tradeoff Analysis
At each step in structuring, it is worthwhile challenging the team’s creativity to expand the solution set under consideration, and then evaluating the different architecture alternatives against the prioritized architectural requirements. This is known as architecture tradeoff analysis (Barbacci et. al., 1998), and it recognizes that different approaches yield differing degrees of fit to the requirements. Selection of the best solution generally involves some compromise, but it is best to make this explicit.
Architecture Validation
During structuring, the architects obviously make their best effort to meet the requirements on the architecture. The architecture validation phase involves additional people from outside the architecting team to help provide an objective assessment of the architecture. In addition to enhancing confidence that the architecture will meet the demands placed on it, including the right participants in this phase can help create buy-in to the architecture. Architecture assessment involves "thought experiments", modeling and walking-through scenarios that exemplify requirements, as well as assessment by experts who look for gaps and weaknesses in the architecture based on their experience. Another important part of validation is the development of prototypes or proofs-of-concept. Taking a skeletal version of the architecture all the way through to implementation, for example, is a really good way to prove out aspects of the architecture.
Iterations
Though described sequentially above, the architecting process is best conducted iteratively, with multiple cycles through requirements, structuring and validation. One approach is to have at least one cycle devoted to each of Meta, Conceptual, Logical, and Execution architecture phases and cycles for developing the architectural guidelines and any other materials to help in deploying the architecture (such as tutorials). At each cycle, just enough requirements are collected to proceed with the next structuring step, and validation concentrates on the architecture in its current phase of maturity and depth.
Moreover, a number of architecture teams that we have worked with have stopped at different points, leaving more detailed architecting to the product and component teams. At one end of the spectrum, a very small team of architects created the meta-architecture, and each of the product teams created their own architectures within the guidelines and constraints of the meta-architecture. Other architecture teams created the meta- and conceptual architectures, and a broader team of component owners developed the logical architecture. At the other end of the spectrum, the architecture team developed the entire architecture, all the way to its detailed logical architecture specification. This approach yields the most control over the architecture specification, but is typically fraught with organizational issues (e.g., the "NIH syndrome") that slow or even completely inhibit the use of the architecture.
The Organizational Process
Overview
Architecture projects are susceptible to three major organizational sources of failure—the project is under-resourced or cancelled prematurely by an uncommitted management; it is stalled with endless infighting or a lack of leadership; or the architecture is ignored or resisted by product developers. The organizational process helps address these pitfalls. Two phases—namely Init/Commit and Deployment—bookend the technical process. However, the principal activities in these phases, namely championing the architecture and leading/teaming in Init/Commit, and consulting in Deployment, also overlap with the technical process activities.
Init/Commit
The Init/Commit phase focuses on initiating the architecture project on a sound footing, and gaining strong commitment from upper management. The creation of the architecture vision is central both to aligning the architecture team and gaining management sponsorship. A communication plan is also helpful in sensitizing the team to the need for frequent communication with others in the organization. A heads-down, hidden skunkworks architecture project may make quick progress—as long as it is well-led and its members act as a team. However, not listening to the needs of the management, developers, marketing, manufacturing and user communities and not paying attention to gaining and sustaining sponsorship in the management and technical leadership of the organization, or buy-in from the developer community, will lead to failure. The communication plan places attention on balancing the need for communication and isolation, as well as planning what to communicate when, and to whom.
Deployment
The Deployment phase follows the technical process, and addresses the needs of the developers who are meant to use the architecture to design and implement products. These range from understanding the architecture and its rationale, to responding to the need for changes to the architecture. This entails consulting, and perhaps tutorials and demos, as well as the architects' involvement in design reviews.
Championing
It is important that at least the senior architect and the architecture project manager (if there is one) champion the architecture and gain the support of all levels of management affected by the architecture. Championing the architecture starts early, and continues throughout the life of the architecture, though attention to championing tapers off as the architecture comes to be embraced by the management and developer communities.
Leading/Teaming
For the architecture team to be successful, there must be a leader and the team members must collaborate to bring their creativity and experience to bear on creating an architecture that will best serve the organization. This would seem so obvious as to not warrant being said, but unfortunately this is easier said than done. Explicit attention to developing the designated lead architect’s leadership skills, in the same way one would attend to developing these skills in management, is a worthy investment. Likewise, investing in activities aimed at developing the team as a team also has great payoff in the team’s efficacy.
Communicating and Consulting
Consulting with and assisting the developer community in their use of the architecture is important in facilitating its successful adoption and appropriate use. These activities are most intense during deployment. However, earlier communication and consulting helps create buy-in the developer community through participation and understanding. This allows the architecture team to understand the developers’ needs and the developers to understand the architecture (and its rationale) as it evolves through the cycles of the technical process.
5. Duties of a Chief Software Architect
Crafting the right architecture to solve the problem at hand is only part of the duties of a project's chief software architect. He or she must also:
get it defined and documented and communicated;
make sure everyone is using it, and using it correctly;
make sure that it comes out in stages in a timely way so that the overall organization can make progress before it's complete;
make sure the software and system architectures are in synchronization;
act as the emissary of the architecture;
make sure management understands it (to the detail necessary);
make sure the right modeling is being done, to know that qualities like performance are going to be met;
give input as needed to issues like tool and environment selection;
identify and interact with stakeholders to make sure their needs are being met;
make sure that the architecture is not only the right one for operations, but also for deployment and sustainment;
resolve disputes and make tradeoffs;
resolve technical problems;
maintain morale, both within the architecture group, and externally as well. The latter is done by providing a sound design, when needed, and providing good presentations and materials to let everyone know the organization is on the right track.
understand and plan for evolutionary paths. plan for new technology insertion.
manage risk identification and risk mitigation strategies associated with the architecture.
David Weiss, Director of Software Technology Research at Avaya Laboratories and co-author of Software Product-Line Engineering, writes that a chief architect should have the following responsibilities (not in priority order).
a. Create and enforce architectural standards that enable the company's products to interoperate. b. Create and enforce architectural standards that make the same features appear and behave the same in all of the company's products. c. Create a company product line (responsibilities a and b preceding are part of this). d. Define the responsibilities of an architect in the company, including what architecture means in the company. e. Create a community of architects within the company. f. Create training and education for the company's architects. g. Identify and recruit potential architects. h. Explain the architecture of the company's products to customers.
6. Benefits of Architecture-Based Technologies
At the Institute for Software Research, they believe that architecture-based technologies can provide benefits in the following areas:
Separation of Concerns
Open Architectures
Scalability
Extensibility
Flexibility
Reliability
Cost Reduction
Understandability
Separation of Concerns
They believe that realizing that architectures can be distinct from implementation is an important concept. However, there is a place for automated tools to help the migration from architecture to implementation. Without the right tools, it is hard to support keeping architectures distinct from the implementation. By relying upon automated tools and selection of components, it is possible to derive multiple implementations from the same architecture.
By promoting architectures that have first-class components and connectors, it allows for a clear distinction in an architecture. Components become the loci of computation (state), while connectors are the loci of communication. This allows the architect to be able to isolate responsibility by classifying a part as a component or connector.
Open Architectures
An architectural style should be generally applicable and not reliant upon a single technology that works in only one environment. Openness is fundamental to achieving an architecture that can withstand changes gracefully and work in a heterogeneous environment. If an architecture were closed, it would not be possible for others to learn how the system operates. By producing tools and recommending techniques that are well documented and understood, effective communication between stakeholders can occur.
In practice, individual components within an architecture may be implemented independently or in different programming languages. By utilizing an open environment, it allows for interoperability between different implementations. In an open environment, each component may independently select operating constraints so long as the constraints of the overall architecture are met.
Scalability
An architecture should be able to support either coarsely-grained or finely-grained components. A component may be able to perform multiple tasks, or it may only perform one task. By creating architectures that support differing levels of granularity, the architect can determine the level of coarseness best suited to the system.
This coarseness is important because components may also have different constraints upon its operating environment. Some components may be resource-constrained, while others may not share that level of constraint. Therefore, a separation in the architecture which realizes the operational constraints is important to building high-quality architectures.
Extensibility
Extensibility can be a useful property to have because components can be repackaged to fit into architectures with differing component interface requirements. And, architectural style rules can limit component interdependencies so components can be easily substituted as long as they share the same interfaces.
Flexibility
System architectures may be modified before and during execution. Architects and end-users may modify functionality and upgrade applications by incorporating new components and configuring parameters of exiting components. Multiple languages, toolkits, and media types may be employed.
Reliability
Off-the-shelf components that have been carefully designed, implemented, and verified can be leveraged to increase system reliability.
Cost Reduction
Incorporation of custom and commerical-off-the-shelf components. This may help to reduce the development effort by reusing prior work.
Component reuse, design guidance, analysis, and system generation facilities reduce application development time.
Understandibility
High level models with multiple coordinated views and active rationale facilities make complex systems easier to understand.
7. Software Architecture Life-Cycle Integration
The Software Architecture Technology Initiative at the Carnegie Mellon Software Engineering Institute (SEI) has developed a number of architecture-centric methods currently in use, of which the SEI Architecture Tradeoff Analysis Method (ATAM) was the first. The SEI ATAM helps a system's stakeholder community understand the consequences of architectural decisions with respect to the system's quality attribute requirements and business goals. The ATAM is a method that helps stakeholders ask the right questions to discover potentially problematic architectural decisions. Discovered risks can then be made the focus of mitigation activities.
As we gained experience from conducting ATAM-based evaluations, we developed methods to extend earlier into the software development life cycle. The SEI Quality Attribute Workshop (QAW) provides a method for eliciting quality attribute requirements. The SEI Attribute-Driven Design (ADD) method provides an approach to defining a software architecture by basing the design process on the system's quality attribute requirements.
We also developed complementary evaluation methods. SEI Active Reviews for Intermediate Designs (ARID) are based on the ATAM and active design reviews. The review concentrates on whether the design being proposed is suitable from the point of view of other parts of the architecture that must use it. The SEI Cost Benefit Analysis Method (CBAM) is a method for architecture-based economic analysis of software-intensive systems. It can be used to help the system's stakeholders choose architectural alternatives for enhancing the system, during design or maintenance phases of the software development life cycle.
Although these methods share a common heritage, set of concepts, and activities, they have not been integrated explicitly with each other or integrated into an organization's architecture-based software development life cycle. Integration of this kind is essential if organizations are to reap the total possible benefits of adopting an architecture-centric approach to software development.
We have already begun moving toward these goals. The integration of different methods and techniques with each other or with other development life cycles is beginning to be applied in some organizations. We will be addressing the topic of integration in a series of future reports. Investigating such potential combinations is part of a larger effort to understand how to
-integrate the approaches
-understand the appropriate fit with other architectural processes and technologies
-connect with other business, management and/or acquisition processes that can help enforce software architecture practices throughout the life cycle.
7.1 The Architecture Tradeoff Analysis Method (ATAM)
For the past several years the SEI has been developing the Architecture Tradeoff Analysis MethodSM (ATAMSM). The ATAM is based upon a set of attribute-specific measures of the system - some analytic, based upon formal models (e.g., performance and availability) and some qualitative, based upon formal inspections (e.g., modifiability, safety, and security). The ATAM process typically takes three days and the involvement of 10-20 people - evaluators, architects, and other system stakeholders. We have piloted the ATAM in many state-of-the-art organizations and have seen many benefits including:
-clarified quality attribute requirements
-improved architecture documentation
-documented basis for architectural decisions
-identified risks early in the life-cycle
-increased communication among stakeholders
The following diagram displays a conceptual flow of the ATAM.
Business drivers and the software architecture are elicited from project decision-makers. These are refined into scenarios and the architectural decisions made in support of each one. Analysis of scenarios and decisions results in identification of risks, non-risks, sensitivity points, and tradeoff points in the architecture. Risks are synthesized into a set of risk themes, showing how each one threatens a business driver.
The most important results are improved architectures. The output of an ATAM is an out-brief presentation and/or a written report that includes the major findings of the evaluation. These are typically:
the architectural styles identified
a "utility tree" - a hierarchic model of the driving architectural requirements
the set of scenarios generated and the subset that were mapped onto the architecture
a set of quality-attribute specific questions that were applied to the architecture and the responses to these questions.
8. Architecture Evaluations
Why should an organization analyze a software or system architecture? Quite simply, because it is a cost-effective way of mitigating the substantial risks associated with this highly important artifact. Architectures are the blueprints for a system, and the carriers of the system's quality attributes.
Most complex software systems are required to be modifiable and have good performance. They may also need to be secure, interoperable, portable, and reliable. But for any particular system, what precisely do these quality attributes - modifiability, security, performance, reliability - mean? Can a system be analyzed to determine these desired qualities? How soon can such an analysis occur? How do you know if a software architecture for a system is suitable without having to build the system first?
Experience has shown that the quality attributes of large software systems live principally in the system's software architecture. In such systems the achievement of qualities attributes depends more on the overall software architecture than on code-level practices such as language choice, detailed design, algorithms, data structures, testing, and so forth. It is therefore a critical risk mitigation measure to try to determine, before a system is built, whether it will satisfy its desired qualities.
9. Architecture Documentation
Because architectures are intellectual constructs of enduring and long-lived importance, communicating an architecture to its stakeholders becomes as important a job as creating it in the first place. If the architecture cannot be understood so that others can build systems from it, analyze it, maintain it, and learn from it, then the effort put into crafting it will by and large have been wasted.
Beginning in 1999, researchers at the Software Engineering Institute and the Carnegie Mellon School of Computer Science set out to answer the question: "How should you document an architecture so that others can successfully use it, maintain it, and build a system from it?" The result of that work is an approach we loosely call "views and beyond."
A view is a representation of a set of system elements and relations associated with them. Views are representations of the many system structures that are present simultaneously in software systems.
Some authors prescribe a fixed set of views with which to engineer and communicate an architecture. Rational's Unified Process, for example, is based on Kruchten's 4+1 view approach to software. A recent trend, however, is to recognize that architects should produce whatever views are useful for the system at hand. ANSI/IEEE-1471-2000 ("IEEE 1471"), a recommended best practice for documenting the architectures of software intensive systems, exemplifies this philosophy; it holds that an architecture description consists of a set of views, each of which conforms to a viewpoint, which in turn is a realization of the concerns of one or more stakeholders.
In concert with that, the Views and Beyond approach holds that documenting an architecture is a matter of documenting the relevant views, and then adding documentation that applies to more than one view. It shows how to choose the relevant views, how to document each one, and how to document the information that applies across views. It also covers practical information such as how to judiciously combine views to avoid documentation overload, and how to document well-known architectural constructs in UML(Unified Modeling Language).
10. Architecture Reconstruction
Evaluation of an architecture's properties is critical to successful system development. However, reasoning about a system's intended architecture must be recognized as distinct from reasoning about its realized architecture. As design and eventually implementation of an architecture proceed, faithfulness to the principles of the intended architecture is not always easy to achieve. This is particularly true in cases where the intended architecture is not completely specified, documented or disseminated to all of the project members. In our experience, this is the rule and well specified, documented, disseminated and controlled architectures are the exception. This problem is exacerbated during maintenance and evolutionary development, as architectural drift and erosion occur. However, if we wish to transfer our reasoning about the properties of a system's intended architecture to the properties of the implemented system, we must reconstruct the architecture of the realized system.
The implemented architecture of a software system typically exists only in artifacts such as source code, makefiles and occasionally designs that are directly realized as code (through, for example, the use of an architecture description language). In addition, it is infrequent that an implementation language provides explicit mechanisms for the representation of architectural constructs. Therefore, facilities for the reconstruction of a software architecture from these artifacts are critical for identifying the as implemented architecture.
Software architecture reconstruction also provides important leverage for the effective reuse of software assets. The ability to identify the architecture of an existing system that has successfully met its quality goals fosters reuse of the architecture in systems with similar goals; hence architectural reuse is the cornerstone practice of product line development.
Architecture reconstruction is an iterative and interactive process, comprising four phases. The first phase is the extraction, from implementation artifacts (including source code and dynamic information such as event traces), of a set of extracted views that represent the system's fundamental structural and behavioral elements. The second phase is fusion of the extracted views to create fused views that augment or improve the extracted views. During the third phase, the analyst iteratively and interactively develops and applies patterns to the fused views to reconstruct architecture-level derived views. Patterns provide the medium for an analyst to express their understanding of a system’s architecture as structural and attribute-based relationships among its components. Finally, the derived views may be explored for the purposes of evaluating architectural conformance, identifying targets for reengineering or reuse and analyzing the architecture's qualities.
The reconstruction process can be most effectively supported by the integration of existing tools and techniques. There currently exist a large number of commercial and research tools that provide the basic mechanisms for view extraction. Similarly, there are several tools and techniques available for performing view fusion and reconstruction. The synthesis of these tools and techniques provides a support environment for software architects and analysts reconstructing architectures.
1. Historical Improvement:
Software architecture began as a field of study with early observations by Parnas, Dijkstra, and others that how software is structured matters as much as its ability to compute the correct result. Structured programming was the small-scale expression of this realization in the 1970s and 1980s, when object-oriented design emerged as a larger-scale manifestation. In the 1990s, interest in software architecture blossomed as Perry and Wolf, Shaw and Garlan, Kruchten, and others wrote about large-scale structures, reusable styles and patterns, and multiple coordinated views.
The software engineering community has adopted the term to denote the gross-level structure of software-intensive systems. The importance of structure was already acknowledged early in the history of software engineering. The first software programs were written for numerical calculations using programming languages that supported mathematical expressions and later algorithms and abstract data types. Programs written at that time served mainly one purpose and were relatively simple compared to the current large-scale diverse software systems. Over time due to the increasing complexity and the increasing size of the applications, the global structure of the software system became an important issue. Already in 1968, Dijkstra proposed the correct arrangement of the structure of software systems before simply programming. He introduced the notion of layered structure in operating systems, in which related programs were grouped into separate layers, communicating with groups of programs in adjacent layers. Later, Parnas maintained that the selected criteria for the decomposition of a system impact the structure of the programs and several design principles must be followed to provide a good structure. Within the software engineering community, there is now an increasing consensus that the structure of software systems is important and several design principles must be followed to provide a good structure.
Looking back at the historical developments of architecture design we can conclude that similar to the many concepts in software engineering the concept of software architecture has also evolved over the years. We observe that this evolution took place at two places. First, existing stable concepts are specialized with new concepts providing a broader interpretation of the concept of software architecture. Second, existing interpretations on software architectures are abstracted and synthesized into new and improved interpretations. Let us explain this considering the development of the definitions in the last decade. The set of existing definitions is large and many other definitions have been collected in various publications.
2. Definition of Software Architecture: What is It?
The term architecture is not new and has been used for centuries to denote the physical structure of an artifact. The definition in Websters' Dictionary:
Architecture: 1: the art or science of building; specifically: the art or practice of designing and building structures and especially habitable ones2 a>:formation or construction as or as if as the result of conscious act
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them (Bass, L., Clements, P., Kazman, R., 2003).
"Externally visible” properties refer to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Let us look at some of the implications of this definition in more detail.
First, architecture defines elements. The architecture embodies information about how the elements relate to each other. This means that architecture 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 that do not affect how they use, are used by, relate to, or interact with other elements. In nearly all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts. Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal implementation—are not architectural.
Second, the definition makes clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. For example, all non-trivial projects are partitioned into implementation units; these units are given specific responsibilities, and are the basis of work assignments for programming teams. This kind of element will comprise programs and data that software in other implementation units can call or access, and programs and data that are private. In large projects, the elements will almost certainly be subdivided for assignment to subteams. This is one kind of structure often used to describe a system. It is a very static structure, in that it focuses on the way the system’s functionality is divided up and assigned to implementation teams.
Other structures are much more focused on the way the elements interact with each other at runtime to carry out the system’s function. Suppose the system is to be built as a set of parallel processes. The set of processes that will exist at runtime, the programs in the various implementation units described previously that are strung together sequentially to form each process, and the synchronization relations among the processes form another kind of structure often used to describe a system.
Third, the definition implies that every software system has an architecture because every system can be shown to be composed of elements and relations among them. In the most trivial case, a system is itself a single element -- an uninteresting and probably non-useful architecture, but an architecture nevertheless. Even though every system has an architecture, it does not necessarily follow that the architecture is known to anyone. Unfortunately, an architecture can exist independently of its description or specification, which raises the importance of architecture documentation and architecture reconstruction.
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. This behavior is what allows elements to interact with each other, which is clearly part of the architecture. This does not mean that the exact behavior and performance of every element must be documented in all circumstances; but to the extent that an element’s behavior influences how another element must be written to interact with it or influences the acceptability of the system as a whole, this behavior is part of the software architecture.
Finally, the definition is indifferent as to whether the architecture for a system is a good one or a bad one, meaning that the architecture will allow or prevent the system from meeting its behavioral, performance, and life-cycle requirements. Assuming that we do not accept trial and error as the best way to choose an architecture for a system—that is, picking an architecture at random, building the system from it, and hoping for the best—this raises the importance of architecture evaluation.
The one of the other definition is "As the size and complexity of software systems increase, the design and specification of overall system structure become more significant issues than the choice of algorithms and data structures of computation. Structural issues include the organization of a system as a composition of components; global control structures; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; dimensions of evolution; and selection among design alternatives. This is the software architecture level of design. " (Shaw, M. & Garlan, D., 1996).
The understanding on the concept of software architecture is increasing though there are still several ambiguities. Architectures consist of components and relations, but the term components may refer to subsystems, processes, software modules, hardware components or something else. Relations may refer to data flows, control flows, call-relations, part-of relations etc.
Software architecture must be distinguished from low-level design (e.g., design of component internals and algorithms) and implementation, on the one hand, and other kinds of related architectures, on the other. For instance, software architecture is not the information (or data) model, though it uses the information model to get type information for method signatures on interfaces, for example. It is also not the architecture of the physical system, including processors, networks, and the like, on which the software will run. However, it uses this information in evaluating the impact of architectural choices on system qualities such as performance and reliability. More obviously, perhaps, it is also not the hardware architecture of a product to be manufactured. While each of these other architectures typically have their own specialists leading their design, these architectures impact and are impacted by the software architecture, and where possible, should not be designed in isolation from one another. This is the domain of system architecting.
3. Need to Software Architecture: Why It is Important?
There are several reasons for applying software architecture design: (Softrware Architecture, n.d.).
-Faciliate communication between stakeholdersWith the increasing complexity of current software systems the need for understanding has grown. Unlike lower-level design descriptions which are mainly used by the developers of the software systems, software architectures represent a common-high-level abstraction that needs to be understood not only by designers and maintainers but also by other stakeholders, such as project managers, customer, users etc. These stakeholders have different concerns that they would like to focus on. Modeling the system at a high-level using a common architecture language facilitates the communication with the different stakeholders and enables the analysis of the priorities. To the project managers the software architecture may be used to communicate the corresponding cost and schedule to build the software system. To the developers the software architecture may be used to provide a gross-level understanding of the software system so that they can grasp the responsibilities and interdependencies of the higher-level structures. To the users the software architecture may communicate the requirements that will be fulfilled by the software system. By abstracting away from much implementation detail, software architectures provide a common perspective of the whole system and as such support the communication between the different stakeholders.
-Support effective work allocation and parallel development A well-defined software architecture provides a structural decomposition of loosely coupled architectural components with clear responsibilities. The architecture design phase is generally followed by the analysis and system design phase. Since the architectural components are relatively independent from each other, the subsequent development work be partitioned rather easily and proceed in a parallel manner. Each partitioned component can be analyzed and developed by a team with specialized skills.
-Provide a means for directing the subsequent developmentThe software architecture prescribes the structure of the software system and as such directs the subsequent phases of the software development process. Software architectures embody the first design decisions of the software system and put constraints on the design alternatives. This eases the job of the developers of the software systems who can faster analyze and select different design alternatives using the prescribed structure as a basis for their design decisions.
Provide a means for evaluationA software architecture may be used for evaluation before the system is actually built. Each software system is developed to fulfill particular requirements. The software architecture gives a clear insight in the requirements it can fulfill and the possible variations and constraints. In this way, it may be used to evaluate and prioritize the kind of requirements that need to be fulfilled. Software architectures can also serve in the evaluation of the desired changes after the system has been built.
Support quality factorsSoftware architecture support the quality factors such as reuse, adaptability and maintenance. Software architectures provide an abstract structure of the system and inherently anticipate different kinds of changes that will occur in the system. This will minimize the cost for evolution and maintenance because the maintainers will be directed to allowable changes. Software architectures provide the basis for understanding, development and maintenance, and evaluation and maintenance of the system in cost-effective ways. Since it abstracts away from many details it serves as a framework for a families of systems remaining relatively constant over time. This provides the opportunity to reuse the architecture for producing many similar systems in a rather predictable way. Architecture development partitions the system among relatively independent components that are generally developed separately. Besides of reusing the complete software architecture, this allows for reusing separate components to develop new architectures.
According to Malan and Creary, architecture serves both technical and organizational purposes. On the organizational side, the architecture helps in:
-communicating the high-level design: A number of stakeholders need to understand the system at a fairly gross level. These include higher-level managers, many of the cross-functional team (e.g., marketing, quality assurance, and learning products or user documentation), and may include customers too. Modeling the system at a high level facilitates communication of the high-level system design or architecture. The reduction in detail makes it easier to grasp the assignment of significant system responsibilities to high-level structures. Moreover, it satisfies the constraint that, though seemingly trivial, has important implications for communication--with suitable leveling and nesting, even large and complex architectures can be conveyed using overhead transparencies and documented using traditional 8.5 x11'' paper!
-providing the system context: The developers (and future maintainers) also need to understand the system at a gross level. In large systems, developers cannot efficiently understand the details of the entire system. They need a detailed understanding of the more narrowly-scoped portions of the system that they work on. But without an understanding of the responsibilities and interdependencies of the higher-level structures, individual development and optimization of the substructures will tend to result in a sub-optimal system. This is both from the point of view of system characteristics like performance, as well as effort in integration and maintenance.
-work allocation: Where architectures decompose the system into substructures that are relatively independent, have clear responsibilities, and communicate with each other through a limited number of well-defined interfaces, the development work can be partitioned effectively. This allows parallel development work to proceed in relative independence between integration points. This is especially important in large projects, or projects where the teams are geographically dispersed or subcontractors are used. Moreover, since these units tend to be centers of specialization of function or service, they also afford opportunities for skill specialization among developers. This independence and focus makes development more efficient. The design of the system architecture can be viewed as the dual of designing the organization architecture. If this duality is ignored and the organization architecture is not compatible with the system architecture, then it can influence and degrade the system architecture.
On the technical side, architecture allows us to design better systems:
-meet system requirements and objectives: Both functional and non-functional requirements can be prioritized as ``must have'' vs. ``high want'' vs. ``want'', where ``must have'' identifies properties that the system must have in order to be acceptable. An architecture allows us to evaluate and make tradeoffs among requirements of differing priority. Though system qualities (also known as non-functional requirements) can be compromised later in the development process, many will not be met if not explicitly taken into account at the architectural level.
-enable flexible distribution/partitioning of the system: A good architecture enables flexible distribution of the system by allowing the system and its constituent applications to be partitioned among processors in many different ways without having to redesign the distributable component parts. This requires careful attention to the distribution potential of components early in the architectural design process.
reduce cost of maintenance and evolution: Architecture can help minimize the costs of maintaining and evolving a given system over its entire lifetime by anticipating the main kinds of changes that will occur in the system, ensuring that the system's overall design will facilitate such changes, and localizing as far as possible the effects of such changes on design documents, code, and other system work products. This can be achieved by the minimization and control of subsystem interdependencies.
-increase reuse and integrate with legacy and third party software: An architecture may be designed to enable and facilitate the (re)use of certain existing components, frameworks, class libraries, legacy or third-party applications, etc.
4. Creating Software Architecture: How? (This part is all quoted from http://www.bredemeyer.com/howto.htm)
How is Software Architecture Created?
We have worked with and studied dozens of architecting projects, and distilled what we believe to be the best practices and pitfalls that would help architects successfully create and deploy their architectures. Based on this experience, we have created our Visual Architecting Process™ (VAP). Though our architecting process lays out the activities and guidelines that we have derived from real-world experience, no project that we studied followed exactly this process. Also, every project that we have consulted with or coached, has adapted the process. This has been true of other software development methods, such as SA/SD, OMT and Fusion (Malan, Coleman and Letsinger, 1995). It would appear that a method is not fully embraced by a project team until they have adapted it to their particular project needs. In this regard, methods are somewhat like architectures!
The architecting process incorporates a technical process and an organizational process. The technical process includes steps and heuristics for creating a good architecture. However, a technically good architecture is not sufficient to ensure the successful use of the architecture, and the organizational process is oriented toward ensuring support for, and adoption of, the architecture.
The Technical Process
Overview
The focal deliverable of the architecting process is the architecture document (set), motivating and describing the structure of the system through various views. However, though system structuring is at the heart of the architecting process, it is just one of several activities critical to the creation of a good architecture (Figure P1). Architectural requirements are needed to focus the structuring activities. Different architectural approaches tend to yield differing degrees of fit to various system requirements, and evaluating alternatives or performing architectural tradeoff analyses are an important adjunct to the structuring phase. Lastly, a validation phase provides early indicators of, and hence an opportunity to resolve, problems with the architecture.
Architectural Requirements
Architectural requirements are a subset of the system requirements, determined by architectural relevance. The business objectives for the system, and the architecture in particular, are important to ensure that the architecture is aligned with the business agenda. The system context helps determine what is in scope and what is out of scope, what the system interface is, and what factors impinge on the architecture. The system value proposition helps establish how the system will fit the users’ agenda and top-level, high-priority goals. These goals are translated into a set of use cases, which are used to document functional requirements. The system structure fails if it does not support the services or functionality that users value, or if the qualities associated with this functionality inhibit user performance or are otherwise unsatisfactory. System qualities that have architectural significance (e.g., performance and security, but not usability at the user interface level) are therefore also important in directing architectural choices during structuring.
Of course, requirements may already have been collected by product teams. In that case, the architecture team needs to review those requirements for architectural relevance and completeness (especially with respect to non-functional requirements), and be concerned with requirements for future products that the architecture will need to support.
Lastly, for the architecture of a product line or family, architectural requirements that are unique to each product and those that are common across the product set need to be distinguished so that the structure can be designed to support both the commonality and the uniqueness in each product.
Architecture Specification
The architecture is created and documented in the system structuring phase. This is decomposed into sub-phases, along the lines of our model of software architecture:
Meta-Architecture
First, the architectural vision is formulated, to act as a beacon guiding decisions during the rest of system structuring. It is a good practice to explicitly allocate time for research—or scavenging for ideas—in documented architectural styles, patterns, dominant designs and reference architectures, other architectures your organization, competitors, partners, or suppliers have created or you find documented in the literature, etc. Based on this study, and your and the team’s past experience, the meta-architecture is formulated. This includes the architectural style, concepts, mechanisms and principles that will guide the architecture team during the next steps of structuring.
Conceptual Architecture
The system is decomposed into components and the responsibilities of each component, and interconnections between components are identified. The intent of the conceptual architecture is to direct attention at an appropriate decomposition of the system without delving into the details of interface specification and type information. Moreover, it provides a useful vehicle for communicating the architecture to non-technical audiences, such as management, marketing, and many users.
Logical Architecture
The conceptual architecture forms the starting point for the logical architecture, and is likely to be modified as well as refined during the course of the creation of the logical architecture. Modeling the dynamic behavior of the system (at the architectural—or component—level) is a useful way to think through and refine the responsibilities and interfaces of the components. Component specifications make the architecture concrete. These should include a summary description of services the component provides, the component owner’s name, IID and version names, message signatures (IDL), a description of the operations, constraints or pre-post conditions for each operation (these may be represented in a state diagram), the concurrency model, constraints on component composition, a lifecycle model, how the component is instantiated, how it is named, a typical use scenario, a programming example, exceptions, and a test or performance suite.
Execution Architecture
An execution architecture is created for distributed or concurrent systems. It is formed by mapping the components onto the processes of the physical system. Different possible configurations are evaluated against requirements such as performance and scaling.
Architecture Tradeoff Analysis
At each step in structuring, it is worthwhile challenging the team’s creativity to expand the solution set under consideration, and then evaluating the different architecture alternatives against the prioritized architectural requirements. This is known as architecture tradeoff analysis (Barbacci et. al., 1998), and it recognizes that different approaches yield differing degrees of fit to the requirements. Selection of the best solution generally involves some compromise, but it is best to make this explicit.
Architecture Validation
During structuring, the architects obviously make their best effort to meet the requirements on the architecture. The architecture validation phase involves additional people from outside the architecting team to help provide an objective assessment of the architecture. In addition to enhancing confidence that the architecture will meet the demands placed on it, including the right participants in this phase can help create buy-in to the architecture. Architecture assessment involves "thought experiments", modeling and walking-through scenarios that exemplify requirements, as well as assessment by experts who look for gaps and weaknesses in the architecture based on their experience. Another important part of validation is the development of prototypes or proofs-of-concept. Taking a skeletal version of the architecture all the way through to implementation, for example, is a really good way to prove out aspects of the architecture.
Iterations
Though described sequentially above, the architecting process is best conducted iteratively, with multiple cycles through requirements, structuring and validation. One approach is to have at least one cycle devoted to each of Meta, Conceptual, Logical, and Execution architecture phases and cycles for developing the architectural guidelines and any other materials to help in deploying the architecture (such as tutorials). At each cycle, just enough requirements are collected to proceed with the next structuring step, and validation concentrates on the architecture in its current phase of maturity and depth.
Moreover, a number of architecture teams that we have worked with have stopped at different points, leaving more detailed architecting to the product and component teams. At one end of the spectrum, a very small team of architects created the meta-architecture, and each of the product teams created their own architectures within the guidelines and constraints of the meta-architecture. Other architecture teams created the meta- and conceptual architectures, and a broader team of component owners developed the logical architecture. At the other end of the spectrum, the architecture team developed the entire architecture, all the way to its detailed logical architecture specification. This approach yields the most control over the architecture specification, but is typically fraught with organizational issues (e.g., the "NIH syndrome") that slow or even completely inhibit the use of the architecture.
The Organizational Process
Overview
Architecture projects are susceptible to three major organizational sources of failure—the project is under-resourced or cancelled prematurely by an uncommitted management; it is stalled with endless infighting or a lack of leadership; or the architecture is ignored or resisted by product developers. The organizational process helps address these pitfalls. Two phases—namely Init/Commit and Deployment—bookend the technical process. However, the principal activities in these phases, namely championing the architecture and leading/teaming in Init/Commit, and consulting in Deployment, also overlap with the technical process activities.
Init/Commit
The Init/Commit phase focuses on initiating the architecture project on a sound footing, and gaining strong commitment from upper management. The creation of the architecture vision is central both to aligning the architecture team and gaining management sponsorship. A communication plan is also helpful in sensitizing the team to the need for frequent communication with others in the organization. A heads-down, hidden skunkworks architecture project may make quick progress—as long as it is well-led and its members act as a team. However, not listening to the needs of the management, developers, marketing, manufacturing and user communities and not paying attention to gaining and sustaining sponsorship in the management and technical leadership of the organization, or buy-in from the developer community, will lead to failure. The communication plan places attention on balancing the need for communication and isolation, as well as planning what to communicate when, and to whom.
Deployment
The Deployment phase follows the technical process, and addresses the needs of the developers who are meant to use the architecture to design and implement products. These range from understanding the architecture and its rationale, to responding to the need for changes to the architecture. This entails consulting, and perhaps tutorials and demos, as well as the architects' involvement in design reviews.
Championing
It is important that at least the senior architect and the architecture project manager (if there is one) champion the architecture and gain the support of all levels of management affected by the architecture. Championing the architecture starts early, and continues throughout the life of the architecture, though attention to championing tapers off as the architecture comes to be embraced by the management and developer communities.
Leading/Teaming
For the architecture team to be successful, there must be a leader and the team members must collaborate to bring their creativity and experience to bear on creating an architecture that will best serve the organization. This would seem so obvious as to not warrant being said, but unfortunately this is easier said than done. Explicit attention to developing the designated lead architect’s leadership skills, in the same way one would attend to developing these skills in management, is a worthy investment. Likewise, investing in activities aimed at developing the team as a team also has great payoff in the team’s efficacy.
Communicating and Consulting
Consulting with and assisting the developer community in their use of the architecture is important in facilitating its successful adoption and appropriate use. These activities are most intense during deployment. However, earlier communication and consulting helps create buy-in the developer community through participation and understanding. This allows the architecture team to understand the developers’ needs and the developers to understand the architecture (and its rationale) as it evolves through the cycles of the technical process.
5. Duties of a Chief Software Architect
Crafting the right architecture to solve the problem at hand is only part of the duties of a project's chief software architect. He or she must also:
get it defined and documented and communicated;
make sure everyone is using it, and using it correctly;
make sure that it comes out in stages in a timely way so that the overall organization can make progress before it's complete;
make sure the software and system architectures are in synchronization;
act as the emissary of the architecture;
make sure management understands it (to the detail necessary);
make sure the right modeling is being done, to know that qualities like performance are going to be met;
give input as needed to issues like tool and environment selection;
identify and interact with stakeholders to make sure their needs are being met;
make sure that the architecture is not only the right one for operations, but also for deployment and sustainment;
resolve disputes and make tradeoffs;
resolve technical problems;
maintain morale, both within the architecture group, and externally as well. The latter is done by providing a sound design, when needed, and providing good presentations and materials to let everyone know the organization is on the right track.
understand and plan for evolutionary paths. plan for new technology insertion.
manage risk identification and risk mitigation strategies associated with the architecture.
David Weiss, Director of Software Technology Research at Avaya Laboratories and co-author of Software Product-Line Engineering, writes that a chief architect should have the following responsibilities (not in priority order).
a. Create and enforce architectural standards that enable the company's products to interoperate. b. Create and enforce architectural standards that make the same features appear and behave the same in all of the company's products. c. Create a company product line (responsibilities a and b preceding are part of this). d. Define the responsibilities of an architect in the company, including what architecture means in the company. e. Create a community of architects within the company. f. Create training and education for the company's architects. g. Identify and recruit potential architects. h. Explain the architecture of the company's products to customers.
6. Benefits of Architecture-Based Technologies
At the Institute for Software Research, they believe that architecture-based technologies can provide benefits in the following areas:
Separation of Concerns
Open Architectures
Scalability
Extensibility
Flexibility
Reliability
Cost Reduction
Understandability
Separation of Concerns
They believe that realizing that architectures can be distinct from implementation is an important concept. However, there is a place for automated tools to help the migration from architecture to implementation. Without the right tools, it is hard to support keeping architectures distinct from the implementation. By relying upon automated tools and selection of components, it is possible to derive multiple implementations from the same architecture.
By promoting architectures that have first-class components and connectors, it allows for a clear distinction in an architecture. Components become the loci of computation (state), while connectors are the loci of communication. This allows the architect to be able to isolate responsibility by classifying a part as a component or connector.
Open Architectures
An architectural style should be generally applicable and not reliant upon a single technology that works in only one environment. Openness is fundamental to achieving an architecture that can withstand changes gracefully and work in a heterogeneous environment. If an architecture were closed, it would not be possible for others to learn how the system operates. By producing tools and recommending techniques that are well documented and understood, effective communication between stakeholders can occur.
In practice, individual components within an architecture may be implemented independently or in different programming languages. By utilizing an open environment, it allows for interoperability between different implementations. In an open environment, each component may independently select operating constraints so long as the constraints of the overall architecture are met.
Scalability
An architecture should be able to support either coarsely-grained or finely-grained components. A component may be able to perform multiple tasks, or it may only perform one task. By creating architectures that support differing levels of granularity, the architect can determine the level of coarseness best suited to the system.
This coarseness is important because components may also have different constraints upon its operating environment. Some components may be resource-constrained, while others may not share that level of constraint. Therefore, a separation in the architecture which realizes the operational constraints is important to building high-quality architectures.
Extensibility
Extensibility can be a useful property to have because components can be repackaged to fit into architectures with differing component interface requirements. And, architectural style rules can limit component interdependencies so components can be easily substituted as long as they share the same interfaces.
Flexibility
System architectures may be modified before and during execution. Architects and end-users may modify functionality and upgrade applications by incorporating new components and configuring parameters of exiting components. Multiple languages, toolkits, and media types may be employed.
Reliability
Off-the-shelf components that have been carefully designed, implemented, and verified can be leveraged to increase system reliability.
Cost Reduction
Incorporation of custom and commerical-off-the-shelf components. This may help to reduce the development effort by reusing prior work.
Component reuse, design guidance, analysis, and system generation facilities reduce application development time.
Understandibility
High level models with multiple coordinated views and active rationale facilities make complex systems easier to understand.
7. Software Architecture Life-Cycle Integration
The Software Architecture Technology Initiative at the Carnegie Mellon Software Engineering Institute (SEI) has developed a number of architecture-centric methods currently in use, of which the SEI Architecture Tradeoff Analysis Method (ATAM) was the first. The SEI ATAM helps a system's stakeholder community understand the consequences of architectural decisions with respect to the system's quality attribute requirements and business goals. The ATAM is a method that helps stakeholders ask the right questions to discover potentially problematic architectural decisions. Discovered risks can then be made the focus of mitigation activities.
As we gained experience from conducting ATAM-based evaluations, we developed methods to extend earlier into the software development life cycle. The SEI Quality Attribute Workshop (QAW) provides a method for eliciting quality attribute requirements. The SEI Attribute-Driven Design (ADD) method provides an approach to defining a software architecture by basing the design process on the system's quality attribute requirements.
We also developed complementary evaluation methods. SEI Active Reviews for Intermediate Designs (ARID) are based on the ATAM and active design reviews. The review concentrates on whether the design being proposed is suitable from the point of view of other parts of the architecture that must use it. The SEI Cost Benefit Analysis Method (CBAM) is a method for architecture-based economic analysis of software-intensive systems. It can be used to help the system's stakeholders choose architectural alternatives for enhancing the system, during design or maintenance phases of the software development life cycle.
Although these methods share a common heritage, set of concepts, and activities, they have not been integrated explicitly with each other or integrated into an organization's architecture-based software development life cycle. Integration of this kind is essential if organizations are to reap the total possible benefits of adopting an architecture-centric approach to software development.
We have already begun moving toward these goals. The integration of different methods and techniques with each other or with other development life cycles is beginning to be applied in some organizations. We will be addressing the topic of integration in a series of future reports. Investigating such potential combinations is part of a larger effort to understand how to
-integrate the approaches
-understand the appropriate fit with other architectural processes and technologies
-connect with other business, management and/or acquisition processes that can help enforce software architecture practices throughout the life cycle.
7.1 The Architecture Tradeoff Analysis Method (ATAM)
For the past several years the SEI has been developing the Architecture Tradeoff Analysis MethodSM (ATAMSM). The ATAM is based upon a set of attribute-specific measures of the system - some analytic, based upon formal models (e.g., performance and availability) and some qualitative, based upon formal inspections (e.g., modifiability, safety, and security). The ATAM process typically takes three days and the involvement of 10-20 people - evaluators, architects, and other system stakeholders. We have piloted the ATAM in many state-of-the-art organizations and have seen many benefits including:
-clarified quality attribute requirements
-improved architecture documentation
-documented basis for architectural decisions
-identified risks early in the life-cycle
-increased communication among stakeholders
The following diagram displays a conceptual flow of the ATAM.
Business drivers and the software architecture are elicited from project decision-makers. These are refined into scenarios and the architectural decisions made in support of each one. Analysis of scenarios and decisions results in identification of risks, non-risks, sensitivity points, and tradeoff points in the architecture. Risks are synthesized into a set of risk themes, showing how each one threatens a business driver.
The most important results are improved architectures. The output of an ATAM is an out-brief presentation and/or a written report that includes the major findings of the evaluation. These are typically:
the architectural styles identified
a "utility tree" - a hierarchic model of the driving architectural requirements
the set of scenarios generated and the subset that were mapped onto the architecture
a set of quality-attribute specific questions that were applied to the architecture and the responses to these questions.
8. Architecture Evaluations
Why should an organization analyze a software or system architecture? Quite simply, because it is a cost-effective way of mitigating the substantial risks associated with this highly important artifact. Architectures are the blueprints for a system, and the carriers of the system's quality attributes.
Most complex software systems are required to be modifiable and have good performance. They may also need to be secure, interoperable, portable, and reliable. But for any particular system, what precisely do these quality attributes - modifiability, security, performance, reliability - mean? Can a system be analyzed to determine these desired qualities? How soon can such an analysis occur? How do you know if a software architecture for a system is suitable without having to build the system first?
Experience has shown that the quality attributes of large software systems live principally in the system's software architecture. In such systems the achievement of qualities attributes depends more on the overall software architecture than on code-level practices such as language choice, detailed design, algorithms, data structures, testing, and so forth. It is therefore a critical risk mitigation measure to try to determine, before a system is built, whether it will satisfy its desired qualities.
9. Architecture Documentation
Because architectures are intellectual constructs of enduring and long-lived importance, communicating an architecture to its stakeholders becomes as important a job as creating it in the first place. If the architecture cannot be understood so that others can build systems from it, analyze it, maintain it, and learn from it, then the effort put into crafting it will by and large have been wasted.
Beginning in 1999, researchers at the Software Engineering Institute and the Carnegie Mellon School of Computer Science set out to answer the question: "How should you document an architecture so that others can successfully use it, maintain it, and build a system from it?" The result of that work is an approach we loosely call "views and beyond."
A view is a representation of a set of system elements and relations associated with them. Views are representations of the many system structures that are present simultaneously in software systems.
Some authors prescribe a fixed set of views with which to engineer and communicate an architecture. Rational's Unified Process, for example, is based on Kruchten's 4+1 view approach to software. A recent trend, however, is to recognize that architects should produce whatever views are useful for the system at hand. ANSI/IEEE-1471-2000 ("IEEE 1471"), a recommended best practice for documenting the architectures of software intensive systems, exemplifies this philosophy; it holds that an architecture description consists of a set of views, each of which conforms to a viewpoint, which in turn is a realization of the concerns of one or more stakeholders.
In concert with that, the Views and Beyond approach holds that documenting an architecture is a matter of documenting the relevant views, and then adding documentation that applies to more than one view. It shows how to choose the relevant views, how to document each one, and how to document the information that applies across views. It also covers practical information such as how to judiciously combine views to avoid documentation overload, and how to document well-known architectural constructs in UML(Unified Modeling Language).
10. Architecture Reconstruction
Evaluation of an architecture's properties is critical to successful system development. However, reasoning about a system's intended architecture must be recognized as distinct from reasoning about its realized architecture. As design and eventually implementation of an architecture proceed, faithfulness to the principles of the intended architecture is not always easy to achieve. This is particularly true in cases where the intended architecture is not completely specified, documented or disseminated to all of the project members. In our experience, this is the rule and well specified, documented, disseminated and controlled architectures are the exception. This problem is exacerbated during maintenance and evolutionary development, as architectural drift and erosion occur. However, if we wish to transfer our reasoning about the properties of a system's intended architecture to the properties of the implemented system, we must reconstruct the architecture of the realized system.
The implemented architecture of a software system typically exists only in artifacts such as source code, makefiles and occasionally designs that are directly realized as code (through, for example, the use of an architecture description language). In addition, it is infrequent that an implementation language provides explicit mechanisms for the representation of architectural constructs. Therefore, facilities for the reconstruction of a software architecture from these artifacts are critical for identifying the as implemented architecture.
Software architecture reconstruction also provides important leverage for the effective reuse of software assets. The ability to identify the architecture of an existing system that has successfully met its quality goals fosters reuse of the architecture in systems with similar goals; hence architectural reuse is the cornerstone practice of product line development.
Architecture reconstruction is an iterative and interactive process, comprising four phases. The first phase is the extraction, from implementation artifacts (including source code and dynamic information such as event traces), of a set of extracted views that represent the system's fundamental structural and behavioral elements. The second phase is fusion of the extracted views to create fused views that augment or improve the extracted views. During the third phase, the analyst iteratively and interactively develops and applies patterns to the fused views to reconstruct architecture-level derived views. Patterns provide the medium for an analyst to express their understanding of a system’s architecture as structural and attribute-based relationships among its components. Finally, the derived views may be explored for the purposes of evaluating architectural conformance, identifying targets for reengineering or reuse and analyzing the architecture's qualities.
The reconstruction process can be most effectively supported by the integration of existing tools and techniques. There currently exist a large number of commercial and research tools that provide the basic mechanisms for view extraction. Similarly, there are several tools and techniques available for performing view fusion and reconstruction. The synthesis of these tools and techniques provides a support environment for software architects and analysts reconstructing architectures.
1 yorum:
Yorum Gönder