SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I: Envisioning Architecture
Creating and Architecture Quality Attributes
Software Architecture
software architecture is an attempt to abstract the commonalities inherent in system design, and as such it must account for a wide range of activities, concepts, methods, approaches, and results.
Architecture is high-level design. Other tasks associated with design are not architectural, such as deciding on important data structures that will be encapsulated.
Architecture is the overall structure of the system. The different structures provide the critical engineering leverage points to imbue a system with the quality attributes that will render it a success or failure. The multiplicity of structures in an architecture lies at the heart of the concept.
Architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evolution over time. Any system has an architecture that can be discovered and analyzed independently of any knowledge of the process by which the architecture was designed or evolved.
Architecture is components and connectors. Connectors imply a runtime mechanism for transferring control and data around a system. When we speak of "relationships" among elements, we intend to capture both runtime and non-runtime relationships.
Further, it involves a set of significant decisions about the organization related to software development and each of these decisions can have a considerable impact on quality, maintainability, performance, and the overall success of the final product.
These decisions comprise of
SOFTWARE ARCHITECTURE IMPORTANCE
There are fundamentally three reasons for software architecture’s importance from a technical perspective.
Communication among stakeholders: software architecture represents a common abstraction of a system that most if not all of the system’s stakeholders can use as a basis for mutual understanding, negotiation, consensus and communication.
Early design decisions: Software architecture manifests the earliest design decisions about a system with respect to the system's remaining development, its deployment, and its maintenance life. It is the earliest point at which design decisions governing the system to be built can be analyzed.
Transferable abstraction of a system: software architecture model is transferable across systems. It can be applied to other systems exhibiting similar quality attribute and functional attribute and functional requirements and can promote large-scale re-use.
AN ARCHITECTURE PERMITS TEMPLATE-BASED DEVELOPMENT
AN ARCHITECTURE CAN BE THE BASIS FOR TRAINING
THE ARCHITECTURE HELPS IN EVOLUTIONARY PROTOTYPING
THE ARCHITECTURE ENABLES MORE ACCURATE COST AND SCHEDULE ESTIMATES
ARCHITECTURE AS A TRANSFERABLE, RE-USABLE MODEL
� Software Design�
The objectives of having a design plan are as follows
It comes before the detailed design, coding, integration, and testing and after the
domain analysis, requirements analysis, and risk analysis.
ARCHITECTURAL PATTERNS, REFERENCE MODELS &
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.
For ex: 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.
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.
A 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, A reference architecture is the mapping of that functionality onto a system decomposition
THE ARCHITECTURE BUSINESS CYCLE
THE ARCHITECTURE BUSINESS CYCLE
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.
Software architecture is a result of technical, business and social influences.
Its existence in turn affects the technical, business and social environments that subsequently influence future
architectures.
We call this cycle of influences, from environment to the architecture and back to the environment, the Architecture Business Cycle (ABC).
ABC in detail and examine the following:
How organizational goals influence requirements and development strategy.
How requirements lead to architecture.
How architectures are analyzed.
How architectures yield systems that suggest new organizational capabilities and requirements.
WHERE DO ARCHITECTURES COME FROM?
An 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.
1. ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS
Many people and organizations interested in the construction of a software system are referred to as stakeholders.
E.g. customers, end users, developers, project manager etc. Figure below shows the architect receiving helpful stakeholder “suggestions”.
2. ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATIONS.
Architecture is influenced by the structure or nature of the development organization.
There are three classes of influence that come from the developing organizations: immediate business, long-term business and organizational structure.
An organization may have an immediate business investment in certain assets, such as existing architectures and the products based on them.
3. THE BACKGROUND AND EXPERIENCE OF THE ARCHITECTS
4. THE TECHNICAL ENVIRONMENT
Ramifications of the Various Influences on an Architecture
The properties required by the business and organizational goals are seldom completely understood.
Customer requirements are often not complete or well documented.
Architects must identify and actively engage stakeholders to solicit their needs and expectations.
In addition to technical skills, architects need to be skilled in diplomacy, negotiation, and communication.
Architectures Affect the Factors that Influence
Software Architecture Activities
What Makes a Good Architectural Process?
The architecture should be the product of a single architect or small group of architects.
The architect should gather both the functional requirements and a well specified, prioritized list of quality attributes.
The architecture should be well documented, with at least one static view and one dynamic view.
The architecture should be reviewed by the system’s stakeholders.
What Makes a Good Architectural Structure?
The architecture should feature well-defined modules based on the principles of information hiding and separation of concerns.
Each module should have a well-defined interface that hides changeable aspects.
Quality attributes should be achieved using well-know architectural tactics.
The architecture should be independent of particular versions of commercial products or tools.
ARCHITECTURAL STRUCTURES AND VIEWS
Architectural structures can by and large be divided into three groups, depending on the broad nature of the elements they show.
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. Module structures allow us to answer questions such as What is the primary functional responsibility assigned to each module? What other software elements is a module allowed to use? What other software does it actually use? What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships?
A descriptive process model describes what has happened in a software development. It is often developed as the result of a postmortem analysis.
A prescriptive model describes what should be done during software development, including responses to error situations."
Allocation structures
Allocation structures show the relationship between the software elements and the elements
in one or more external environments in which the software is created and executed.
They answer questions such as What processor does each software element execute on? In what
files is each element stored during development, testing, and system building? What is the
assignment of software elements to development teams?
A view is a representation of a whole system from the perspective of a related set of concerns.
Usually a view is a work product that presents specific architecture data for a given system
Architectural styles and patterns
An Architectural Style is the application design at the highest level of abstraction; An Architectural Pattern is a way to implement an Architectural Style;
A Design Pattern is a way to solve a localized problem.
An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.
Architectural patterns are often documented as software design patterns.
ARCHITECTURAL STYLES
Data centered architectures
A data store will reside at the center of this architecture and is accessed frequently by the other components that update, add, delete or modify the data present within the store.
The figure illustrates a typical data centered style. The client software access a central repository. Variation of this approach are used to transform the repository into a blackboard when data related to client or data of interest for the client change the notifications to client software.
This data-centered architecture will promote integrability. This means that the existing components can be changed and new client components can be added to the architecture without the permission or concern of other clients.
Data can be passed among clients using blackboard mechanism.
Data flow architectures
This kind of architecture is used when input data to be transformed into output data through a series of computational manipulative components.
The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has a set of components called filters connected by pipes.
Pipes are used to transmit data from one component to the next.
Each filter will work independently and is designed to take data input of a certain form and produces data output to the next filter of a specified form.
Call and Return architectures
It is used to create a program that is easy to scale and modify. Many sub-styles exist within this category. Two of them are explained below.
2. Main program or Subprogram architectures: The main program structure decomposes into number of subprograms or function into a control hierarchy. Main program contains number of subprograms that can invoke other components.
Object Oriented architecture
The components of a system encapsulate data and the operations that must be applied to manipulate the data. The coordination and communication between the components are established via the message passing.
Layered architecture
A number of different layers are defined with each layer performing a well-defined set of operations. Each layer will do some operations that becomes closer to machine instruction set progressively.
At the outer layer, components will receive the user interface operations and at the inner layers, components will perform the operating system interfacing(communication and coordination with OS) Intermediate layers to utility services and application software functions.
Software Quality Attributes
Developers of critical systems are responsible for identifying the requirements of the application, developing software that implements the requirements, and for allocating appropriate resources (processors and communication networks).
It is not enough to merely satisfy functional requirements.
Critical systems in general must satisfy security, safety, dependability, performance, and other, similar requirements as well.
Software quality is the degree to which software possesses a desired combination of attributes (e.g., reliability, interoperability) .
How Various Communities Have Addressed Quality Attributes:
There are different schools/opinions/traditions concerning the properties of critical systems and the best methods to develop them:
Performance — from the tradition of hard real-time systems and capacity planning
Dependability — from the tradition of ultra-reliable, fault-tolerant systems
Security — from the traditions of the government, banking and academic communities
Safety — from the tradition of hazard analysis and system safety engineering
Software Architecture Design Requirements
Functional Requirements
Non-functional requirements
Non-functional requirements are different from functional requirements in many ways.
Functional Requirements:
Non-Functional Requirements:
Quality Attributes
Usually, business considerations determine the qualities that must be accommodated in a system architecture.
functionality overrides maintainability, portability, scalability, and other factors determining the long-term success of a project.
Functionality and quality attributes are orthogonal, since a given functionality can be achieved by many different architectures.
Quality requirements depend on the system architecture more than on the functional requirements.
There are three main categories of quality attributes:
System Qualities: availability, modifiability, performance, security, testability, usability, others.
Business Qualities: time to market, cost and benefit, product lifetime, target market, roll-out schedule, integration, others.
Architectural Qualities: conceptual integrity, correctness and completeness.
A quality attribute scenario has six parts, shown in the schematic:
System Quality Attributes
Availability: The availability attribute is concerned with system failures. Faults are problems that are corrected or masked by the system. Failures are uncorrected errors that are user-visible.
availability = [mean time to failure] / ([mean time to failure] + [mean time to repair])
Modifiability: The modifiability quality is concerned with what can change, when are changes made, and who makes the changes.
Performance: The performance quality is concerned with response times and similar measures for various events.
Security: Non-repudiation, Confidentiality, Integrity, Assurance or authenticity, Availability (no denial of service), Auditing
Testability: The testability attribute is concerned with detecting failure modes. Typically, 40% of the cost of a large project is spent on testing. This means architectural support for testing that reduces test cost is time well spent. We need to control the internal state of and inputs to each unit, then observe the corresponding output of that unit.
Usability:
How easy it is to learn the features of the system
How efficiently the user can use the system
How well the system handles user errors
How well the system adapts to user needs
To what degree the system gives the user confidence in the correctness of its actions.
Business Quality Attributes
Time to Market: architectural reuse affects development time.
Cost and Benefit: in-house architectural expertise is cheaper than outside expertise.
Projected Lifetime of the System: long-lived systems require architectures that are modifiable and scalable.
Targeted Market: architecture affects what platforms will be compatible and incompatible with the system.
Roll-out Schedule: if functionality is planned to increase over time, the architecture needs to be customizable and flexible.
Integration with Legacy Systems: the architecture of the legacy system being integrated will influence the overall system’s architecture.
Architectural Quality Attributes
Conceptual Integrity is the underlying vision or theme unifying the components and their interactions. The architecture should do similar things in similar ways.
Correctness and Completeness is concerned with checking the architecture for errors and omissions.
Buildability is concerned with the organization’s capabilities to actually construct the architecture in question.
Documenting Software Architectures
Uses of Architectural Documentation
2.Views
Documenting an architecture is a matter of documenting the relevant views and then adding documentation that applies to more than one view.
3.Choosing the Relevant Views
Stakeholders and the Architecture Documentation They Might Find Most Useful
Three-step procedure for choosing the views for a project
(a) Produce a candidate view list
(b) Combine views
(c) Prioritize
4. Documenting a View
The seven parts of a documented view
5. Documentation across Views
Summary of cross-view documentation
RECONSTRUCTING SOFTWARE ARCHITECTURE
Architecture reconstruction is an interpretive, interactive, and iterative process involving many activities; it is not automatic.
It requires the skills and attention of both the reverse engineering expert and the architect (or someone who has substantial knowledge of the architecture), largely because architectural constructs are not represented explicitly in the source code.
There is no programming language construct for "layer" or "connector" or other architectural elements that we can easily pick out of a source code file.
Architectural patterns, if used, are seldom labeled. Instead, architectural constructs are realized by many diverse mechanisms in an implementation, usually a collection of functions, classes, files, objects, and so forth.
When a system is initially developed, its high-level design/architectural elements are mapped to implementation elements.
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
RECONSTRUCTION ACTIVITIES
Software architecture reconstruction comprises the following activities,
carried out iteratively:
2. Database construction. Database construction involves converting this information into a standard form such as the Rigi Standard Form (a tuple-based data format in the form of relationship <entity1> <entity2>) and an SQL based database format from which the database is created.
3. View fusion. View fusion combines information in the database to produce a coherent view of the architecture.
4. Reconstruction. The reconstruction activity is where the main work of building abstractions and various representations of the data to generate an architecture representation takes place.
Information extraction involves analyzing a system's existing design and implementation artifacts to construct a model of it.
The result is a set of information placed in a database, which is used in the view fusion activity to construct a view of the system.
Information extraction is a blend of the ideal.
The extracted information is converted into a standard format for storage in a database during database construction. It is necessary to choose a database model.
It should support remote access of the database from one or more geographically distributed user interfaces.
It supports view fusion by combining information from various tables.
It supports query languages that can express architectural patterns.
View fusion involves defining and manipulating extracted information (now stored in a database) to reconcile, augment, and establish connections between the elements.
consists of two primary activities:
visualization and interaction-provides a mechanism by which the user may interactively visualize, explore, and manipulate views.