Download Software Architecture and Design Pattern it is a most awaited Material and more Lecture notes Design Patterns in PDF only on Docsity!
UNIT-I
UNIT-I:
Envisioning Architecture: The Architecture Business Cycle, What is Software Architecture, Architectural patterns, reference models, reference architectures, architectural structures and views
Envisioning Architecture:
1. The Architecture Business Cycle 1.1 Where Do Architectures Come From? Architecture is the result of a set of business and technical decisions. There are many influences at work in its design, and the realization of these influences will change depending on the environment in which the architecture is required to perform. An architect designing a system for which the real-time deadlines are believed to be tight will make one set of design choices; the same architect, designing a similar system in which the deadlines can be easily satisfied, will make different choices.
ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS Many people and organizations are interested in the construction of a software system. We call these stakeholders: The customer, the end users, the developers, the project manager, the maintainers, and even those who market the system are a few examples. Stakeholders have different concerns that they wish the system to guarantee or optimize, including things as diverse as providing a certain behavior at runtime, performing well on a particular piece of hardware, being easy to customize, achieving short time to market or low cost of development, gainfully employing programmers who have a particular specialty, or providing a broad range of functions. Figure.1 shows the architect receiving helpful stakeholder "suggestions."
Figure 1.Influence of stakeholders on the architect
UNIT-I
ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATION
In addition to the organizational goals expressed through requirements, architecture is influenced by the structure or nature of the development organization. For example, if the organization has an abundance of idle programmers skilled in client-server communications, then client-server architecture might be the approach supported by management. If not, it may well be rejected. Staff skills are one additional influence, but so are the development schedule and budget.
There are three classes of influence that come from the developing organization: immediate business, long-term business, and organizational structure.
ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND EXPERIENCE OF THE ARCHITECTS If the architects for a system have had good results using a particular architectural approach, such as distributed objects or implicit invocation, chances are that they will try that same approach on a new development effort. Conversely, if their prior experience with this approach was disastrous, the architects may be reluctant to try it again. Architectural choices may also come from an architect's education and training, exposure to successful architectural patterns, or exposure to systems that have worked particularly poorly or particularly well. The architects may also wish to experiment with an architectural pattern or technique learned from a book (such as this one) or a course.
ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT A special case of the architect's background and experience is reflected by the technical environment. The environment that is current when architecture is designed will influence that architecture. It might include standard industry practices or software engineering techniques prevalent in the architect's professional community. It is a brave architect who, in today's environment, does not at least consider a Web-based, object-oriented, middleware-supported design for an information system.
RAMIFICATIONS OF INFLUENCES ON ARCHITECTURE Influences on architecture come from a wide variety of sources. Some are only implied, while others are explicitly in conflict. Almost never are the properties required by the business and organizational goals consciously understood, let alone fully articulated. Indeed, even customer requirements are seldom documented completely, which means that the inevitable conflict among different stakeholders' goals has not been resolved.
A business manages this cycle to handle growth, to expand its enterprise area, and to take advantage of previous investments in architecture and system building. Figure 2 shows the feedback loops. Some of the feedback comes from the architecture itself, and some comes from the system built from it. The architecture affects the structure of the developing organization. An architecture prescribes a structure for a system; as we will see, it particularly prescribes the units of software that must be implemented (or otherwise obtained) and integrated to form the system. These units are the basis for the development project's structure. Teams are formed for individual software units; and the development, test, and integration activities all revolve around the units. Likewise, schedules and budgets allocate resources in chunks corresponding to the units. If a company becomes adept at building families of similar systems, it will tend to invest in each team by nurturing each area of expertise. Teams become embedded in the organization's structure. This is feedback from the architecture to the developing organization.
UNIT-I
Communicating the Architecture For the architecture to be effective as the backbone of the project's design, it must be communicated clearly and unambiguously to all of the stakeholders. Developers must understand the work assignments it requires of them, testers must understand the task structure it imposes on them, management must understand the scheduling implications it suggests, and so forth. Toward this end, the architecture's documentation should be informative, unambiguous, and readable by many people with varied backgrounds. Analyzing or Evaluating the Architecture In any design process there will be multiple candidate designs considered. Some will be rejected immediately. Others will contend for primacy. Choosing among these competing designs in a rational way is one of the architect's greatest challenges.
1.3 What Makes a 'Good' Architecture? If it is true that, given the same technical requirements for a system, two different architects in different organizations will produce different architectures, how can we determine if either one of them is the right one? We divide our observations into two clusters: process recommendations and product (or structural) recommendations. Our process recommendations are as follows:
The architecture should be the product of a single architect or a small group of architects with an identified leader. The architect (or architecture team) should have the functional requirements for the system and an articulated, prioritized list of quality attributes (such as security or modifiability) that the architecture is expected to satisfy. The architecture should be well documented, with at least one static view and one dynamic view, using an agreed-on notation that all stakeholders can understand with a minimum of effort. The architecture should be circulated to the system's stakeholders, who should be actively involved in its review. The architecture should be analyzed for applicable quantitative measures (such as maximum throughput) and formally evaluated for quality attributes before it is too late to make changes to it. The architecture should lend itself to incremental implementation via the creation of a "skeletal" system in which the communication paths are exercised but which at first has minimal functionality.
2. What is Software Architecture? The system consists of four elements, Prop Loss Model (MODP), Reverb Model (MODR), and Noise Model (MODN)?might have more in common with each other than with the fourth model, Control Process (CP). All of the elements apparently have some sort of relationship with each other, since the diagram is fully connected. The models are described in figure 3.
Figure 3: Typical, but uninformative, presentation of software architecture
UNIT-I
3. Architectural patterns, Reference models and Reference architectures An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used. A pattern can be thought of as a set of constraints on architecture? On the element types and their patterns of interaction? And these constraints define a set or family of architectures that satisfy them. For example, client-server is a common architectural pattern. Client and server are two element types, and their coordination is described in terms of the protocol that the server uses to communicate with each of its clients. Use of the term client-server implies only that multiple clients exist; the clients themselves are not identified, and there is no discussion of what functionality, other than implementation of the protocols, has been assigned to any of the clients or to the server.
A reference model is a division of functionality together with data flow between the pieces. A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem.
Reference architecture is a reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them. Whereas a reference model divides the functionality, reference architecture is the mapping of that functionality onto system decomposition. The relationship among these design elements is shown in Figure 4.
Figure 4: The relationships of design elements
Architectural structures and views A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders. It consists of a representation of a set of elements and the relations among them. A structure is the set of elements itself, as they exist in software or hardware.
For example, a module structure is the set of the system's modules and their organization. A module view is the representation of that structure, as documented by and used by some system stakeholders. These terms are often used interchangeably, but we will adhere to these definitions.
Architectural structures can by and large be divided into three groups, depending on the broad nature of the elements they show.
Module structures: Here the elements are modules, which are units of implementation. Modules represent a code-based way of considering the system. They are assigned areas of functional responsibility. There is less emphasis on how the resulting software manifests itself at runtime.
Component-and-connector structures: Here the elements are runtime components (which are the principal units of computation) and connectors (which are the communication vehicles among components). Component-and-connector structures help answer questions such as what are the major executing components and how do they interact? What are the major shared data stores?
UNIT-I
running system. Shared data This structure comprises components and connectors that create, store, and access persistent data.
Allocation
Work assignment
This structure assigns responsibility for implementing and integrating the modules to the appropriate development teams.
Deployment
The deployment structure shows how software is assigned to hardware-processing and communication elements.
Implementation
This structure shows how software elements (usually modules) are mapped to the file structure(s) in the system's development, integration, or configuration control environments.
UNIT-I
Creating Architecture: Quality Attributes, Achieving qualities, Architectural styles and patterns, designing the Architecture, Documenting software architectures, Reconstructing Software Architecture
4. Quality Attributes
Architecture and Quality Attributes Achieving quality attributes must be considered throughout design, implementation, and deployment. No quality attribute is entirely dependent on design, nor is it entirely dependent on implementation or deployment. Satisfactory results are a matter of getting the big picture (architecture) as well as the details (implementation) correct.
Architecture is critical to the realization of many qualities of interest in a system, and these qualities should be designed in and can be evaluated at the architectural level. Architecture, by itself, is unable to achieve qualities. It provides the foundation for achieving quality, but this foundation will be to no avail if attention is not paid to the details. We will examine the following three classes:
Qualities of the system. We will focus on availability, modifiability, performance, security, testability, and usability. Business qualities (such as time to market) that are affected by the architecture. Qualities, such as conceptual integrity, that is about the architecture itself although they indirectly affect other qualities, such as modifiability.
Quality Attributes Scenarios A quality attribute scenario is a quality-attribute-specific requirement. It consists of six parts. Source of stimulus: This is some entity (a human, a computer system, or any other actuator) that generated the stimulus. Stimulus: The stimulus is a condition that needs to be considered when it arrives at a system. Environment: The stimulus occurs within certain conditions. The system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true. Artifact: Some artifact is stimulated. This may be the whole system or some pieces of it. Response: The response is the activity undertaken after the arrival of the stimulus. Response measure: When the response occurs, it should be measurable in some fashion so that the requirement can be tested.
Figure 6: shows the parts of a quality attribute scenario.
UNIT-I
5. Achieving qualities The achievement of these qualities relies on fundamental design decisions. We will examine these design decisions, which we call tactics. A tactic is a design decision that influences the control of a quality attribute response. A system design consists of a collection of decisions. Some of these decisions help control the quality attribute responses; others ensure achievement of system functionality.
Figure 9: Tactics are intended to control responses to stimuli
We organize the tactics for each system quality attribute as a hierarchy, but it is important to understand that each hierarchy is intended only to demonstrate some of the tactics, and that any list of tactics is necessarily incomplete.
5.1 Availability Tactics: A failure occurs when the system no longer delivers a service that is consistent
with its specification; this failure is observable by the system's users. A fault (or combination of faults) has the potential to cause a failure. Recall also that recovery or repair is an important aspect of
availability. We first consider fault detection. We then consider fault recovery and finally, briefly, fault prevention.
Figure 10: Goal of availability tactics
Figure 11: Summary of availability tactics
UNIT-I
5.2 Modifiability Tactics: We organize the tactics for modifiability in sets according to their goals. One set has as its goal reducing the number of modules that are directly affected by a change. We call this set "localize modifications." A second set has as its goal limiting modifications to the localized modules. We use this set of tactics to "prevent the ripple effect." Implicit in this distinction is that there are modules directly affected (those whose responsibilities are adjusted to accomplish the change) and modules indirectly affected by a change (those whose responsibilities remain unchanged but whose implementation must be changed to accommodate the directly affected modules). A third set of tactics has as its goal controlling deployment time and cost. We call this set "defer binding time."
Figure 12: Goal of modifiability tactics
Figure 13: Summary of modifiability tactics
UNIT-I
5.4 Security Tactics: Tactics for achieving security can be divided into those concerned with resisting attacks, those concerned with detecting attacks, and those concerned with recovering from attacks. All three categories are important. Using a familiar analogy, putting a lock on your door is a form of resisting an attack, having a motion sensor inside of your house is a form of detecting an attack, and having insurance is a form of recovering from an attack.
Figure 16: Goal of security tactics
Figure 17: Summary of tactics for security
UNIT-I
5.5 Testability Tactics: The goal of tactics for testability is to allow for easier testing when an increment of software development is completed.
Figure 18: Goal of testability tactics
Figure 19: Summary of testability tactics
UNIT-I
6. Architectural styles and patterns, An architectural pattern in software, also known as an architectural style, is analogous to an architectural style in buildings, such as Gothic or Greek revival or Queen Anne. It consists of a few key features and
rules for combining them so that architectural integrity is preserved. An architectural pattern is determined by:
A set of element types (such as a data repository or a component that computes a mathematical function). A topological layout of the elements indicating their interrelation-ships. A set of semantic constraints A set of interaction mechanisms
In response, a number of recurring architectural patterns, their properties, and their benefits have been cataloged. One such catalog is illustrated in Figure 5.
Figure 22: A small catalog of architectural patterns, organized by is-a relations
UNIT-I
7. Designing the Architecture, 7.1 Architecture in the Life Cycle: Any organization that embraces architecture as a foundation for its software development processes needs to understand its place in the life cycle. Several life-cycle models exist in the literature, but one that puts architecture squarely in the middle of things is the Evolutionary Delivery Life Cycle model shown in Figure 23. The intent of this model is to get user and customer feedback and iterate through several releases before the final release. The model also allows the adding of functionality with each iteration and the delivery of a limited version once a sufficient set of features has been developed.
Figure 23: Evolutionary Delivery Life Cycle .
7.2 Designing the Architecture: In this section we describe a method for designing architecture to satisfy
both quality requirements and functional requirements. We call this method Attribute-Driven Design (ADD). ADD takes as input a set of quality attribute scenarios and employs knowledge about the relation
between qualities attribute achievement and architecture in order to design the architecture. The ADD method can be viewed as an extension to most other development methods, such as the Rational Unified
Process. The Rational Unified Process has several steps that result in the high-level design of an
architecture but then proceeds to detailed design and implementation. Incorporating ADD into it involves modifying the steps dealing with the high-level design of the architecture and then following the process
as described by Rational.
ADD is an approach to defining a software architecture that bases the decomposition process on the
quality attributes the software has to fulfill. It is a recursive decomposition process where, at each stage, tactics and architectural patterns are chosen to satisfy a set of quality scenarios and then functionality is
UNIT-I
Figure 24: The seven parts of a documented view
UNIT-I
9. Reconstructing Software Architecture: Architecture reconstruction has been used in a variety of
projects ranging from MRI scanners to public telephone switches and from helicopter guidance systems to classified NASA systems. It has been used
To redocument architectures for physics simulation systems. To understand architectural dependencies in embedded control software for mining machinery. To evaluate the conformance of a satellite ground system's implementation to its reference architecture. To understand different systems in the automotive industry.
Reconstruction Activities Software architecture reconstruction comprises the following activities, carried out iteratively:
Information extraction. The purpose of this activity is to extract information from various sources. Database construction. Database construction involves converting this information into a standard form such as the Rigi Standard Form (a tuple-based data format in the form of relationship ) and an SQL-based database format from which the database is created. View fusion. View fusion combines information in the database to produce a coherent view of the architecture. Reconstruction. The reconstruction activity is where the main work of building abstractions and various representations of the data to generate an architecture representation takes place.
Figure 25: Architecture reconstruction activities.
