Softwarearchitecture in practice unit1 2

Creating an Architecture

Unit 1-2

1. Understanding quality attributes2.Achieving qualities3. Architectural patterns and styles4.Designing the Architecture5.Documenting software Architecture6.Reconstructing software Architecture

contents

1.1 Functionality and Architecture1.2 Architecture and Quality Attributes1.3 System quality Attributes1.4 Quality Attribute Scenarios in practice1.5 Business Qualities1.6 Architecture Qualities

1.Quality Attributes

Quality“a characteristic or attribute of

something”Attribute of an item , quality refers to

measurable characteristics

Contd..

Functionality and quality are orthogonal Functionality-it is the ability of the system to

do the work for which it was intended. It can be achieved through the use of any of

a number of possible structures. Software architecture constraints its

allocation to structure when other quality attributes are important.

1.1 Functionality and Architecture

The message of this section is twofold:1.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.

2.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.

1.2 Architecture and Quality Attributes

Quality attributes are examined in three classes:1.Qualities of the system. we will focus on

availability, modifiability, performance, security, testability and usability.

2.Business qualities(such as time to market) that are affected by the architecture.

3.Qualities such as conceptual integrity, that are about the architecture itself although they indirectly affect other qualities, such as modifiability.

Contd..

A solution to the problems of the system quality attributes is to use Quality attribute scenarios

- as a means of characterizing quality attributes.

-a quality attribute is a quality-attribute-specific requirement.

-it consists of six parts.

1.3 System Quality Attributes

1)Source of stimulus: this is some entity(a human, a computer system, or any other actuator) that generated the stimulus.

2)Stimulus: the Stimulus is a condition that needs to be considered when it arrives at a system.

3)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.

Contd..

4) Artifact: some artifact is stimulated. This may be the whole system or some pieces of it.

5)Response: the response is the activity undertaken after the arrival of the stimulus.

6)Response measure: when the response occurs, it should be measurable in some fashion so that the requirement can be tested.

Contd..

Contd..

Contd..

Availability scenario An example availability scenario is derived

from the general scenario of fig 4.2 by instantiating each of the parts, is “an unanticipated external message is received by a process during normal operation. The process informs the operator of the receipt of the message and continues to operate with no downtime.” fig 4.3 shows the pieces of the derived scenario

Contd..

Contd..

Modifiability Scenario a sample modifiability scenario is “ A

developer wishes to change the user interface to make a screen’s background color blue. This change will be made to the code at design time. It will take less than 3 hrs to make and test the change and no side effects changes will occur in the behavior.” fig 4.4 illustrates this sample scenario(omitting a few minor details for brevity)

Contd..

Contd..

Quality Attribute Scenario Generation-To help the architect generate meaningful

quality attribute requirements for a system.-in theory this is done in a project’s

requirement elicitation, but in practice this is is seldom rigorously enforced.

Contd..

To make the general scenarios useful for a particular system, you must make them system specific.

The six most common and important system quality attributes, with the twin goals of identifying the concepts used by the attribute community and providing a way to generate general scenarios for that attribute.

1.4 Quality attribute scenarios in practice

Availability- is concerned with system failure and its associated consequences.

The availability of a system is the probability that it will be operational when it is needed. This is typically defined as

Contd..

Contd..

Modifiability- is about the cost of change. It brings up two concerns.

1. what can change(the artifact)?2.when is the change made and who makes it

(the environment)?

Contd..

Contd..

Performance- is about timing. Events (interrupts, messages, requests from users, or the passage of to time) occur, and the system must respond to them.

A performance scenario begins with a request for some service arriving at the system. Satisfying the request requires resources to be consumed. While this is happening the system may be simultaneously servicing other requests.

Contd..

Contd..

Contd..

Security- is a measure of the system’s ability to resist unauthorized usage while still providing its services to legitimate users.

Security can be characterized as a system providing nonrepudiation, confidentiality, integrity, assurance and auditing.

Each of these security categories gives rise to a collection of general scenarios.

Contd..

Contd..

Contd..

Testability – software testability refers to the ease with which software can be made to demonstrate its faults through(typically execution-based) testing.

In particular testability refers to the probability, assuming that the software has at least one fault, that it will fail on its next test execution.

Contd..

Contd..

Contd..

Usability – is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. it can be broken into following areas:

Learning system features- if the user is unfamiliar with a particular system or a particular aspect of it, what can the system do to make the task of learning easier?

Using a system efficiently- what can the system do to make the user more efficient in its operation.

Contd..

Minimizing the impact of errors- what can the system do so that a user error has minimal impact?

Adapting the system to user needs- how can the user(or the system itself) adapt to make the user’s task easier?

Increasing confidence and satisfaction-what does the system do to give the user confidence that the correct action is being taken?

Contd..

Contd..

Contd..

Contd..

Communicating concepts using general scenarios

One of the uses of general scenarios is to enable stakeholders to communicate.

Table 4.7 gives the stimuli possible for each of the attributes and shows a no.of different concepts.

For example, it may occur with an exchange of several messages b/w a client and server each of which is an atomic event from a performance perspective.

Contd..

Contd..

A no.of other attributes can be found in the attribute taxonomies in the research literature.

For example, scalability is often an important attribute, it is captured by modifying system capacity- the no.of users supported.

Portability is captured as a platform modification.

Interoperability- is important to your organization, it is reasonable to create your own general scenario for it.

1.5 Other system quality attributes

In addition to the qualities that apply directly to a system, a number of business quality goals frequently shape a system’s architecture. These goals center on cost, schedule, market, and marketing considerations.

Time to market: if there is competitive pressure or a short window opportunity for a system or product, development time becomes important.

1.6 Business qualities

Cost and benefit: the development effort will naturally have a budget that must not be exceeded.

Projected lifetime of the system: if the system is intended to have a long lifetime, modifiability, scalability and portability become important.

Targeted market: for general-purpose(mass-market) software, the platforms on which a system runs as well as its features set will determine the size of the potential market. Thus portability and functionality are key to market share.

Contd..

Rollout schedule: if a product is to be introduced as base functionality with many features released later, the flexibility and customizability of the architecture are important.

Integration with legacy systems: if the new system has to integrate with existing systems, care must be taken to define appropriate integration mechanisms.

Contd..

In addition to qualities of the system and qualities related to the business environment in which the system is being developed, there are also qualities directly related to the architecture itself that are important to achieve.

Conceptual integrity is the underlying theme or vision that unifies the design of the system at all levels.

1.7 Architecture Qualities

Correctness and completeness are essential for the architecture to allow for all the system’s requirements and runtime resource constraints to ne met.

Buildability allows the system to be completed by the available team in a timely manner and to be open to certain changes as development progress.

Contd..

2.1 Introducing Tactics2.2 Availability Tactics2.3 Modifiability Tactics2.4 Performance Tactics2.5 Security Tactics2.6 Testability Tactics2.7 Usability Tactics2.8 Relationship of Tactics to Architectural

Patterns

2.Achieving Qualities

A Tactic is a design decision that influences the control of a quality attribute response.

We call a collection of tactics an architectural strategy

Each tactic is a design option for the architect

Usually achieving a high availability through redundancy implies a concomitant need for synchronization.

We see two immediate ramifications of this example.

2.1Introducing Tactics

1. Tactics can refine other tactics2. pattern package tacticsFig5.1 the tactics are those that architects

have been using for years, and we isolate and describe them. we are not inventing tactics here, just capturing what architects do in practice.

Contd..

Contd..

Recovery or repair is an important aspect of availability.

In some cases the monitoring or recovery is automatic and in others it is manual.

We first consider fault detection. We then consider fault recovery and finally fault prevention.

The tactics we discuss in this section will keep faults from becoming failures or at least bound the effects of the fault and make repair possible. This will shown in the foll fig.

2.2 Availability Tactics

Contd..

Contd..

Three widely used tactics for recognizing faults are ping/echo, heartbeat and exceptions.

Ping/echo-one component issues a ping and expects to receive back an echo within a predefined time, from the component under scrutiny.

Heartbeat(dead man timer)- in this case one component emits a heartbeat message periodically and another component listens for it.

Exceptions- one method for recognizing faults is to encounter an exception which is raised when one of the fault classes recognized.

Fault Detection

Fault recovery consists of preparing for recovery and making the system repair. Some preparation and repair tactics follow.

Voting Active redundancy(hot restrat) Passive redundancy(warm restrat/dual

redundancy/triple redundancy) Spare Shadow operation State resynchronization Checkpoint/rollback

Fault Recovery

The following are some fault prevention tactics Removal from service- this tactic removes a

component of the system from operation undergo some activities to prevent anticipated failures.

Transactions- a transaction is the bundling of several sequential steps such that the entire bundle can be undone at once.

Process monitor- once a fault in a process has been detected, a monitoring process can delete the nonperforming process and create a new instance of it, initialized to some appropriate state as in the spare tactic.

Fault prevention

Tactics to control modifiability have as their goal controlling the time and cost to implement, test and deploy changes.fig 5.4 shows this relationship.

2.3 Modifiability tactics

Contd.. We organize the tactics for modifiability in sets

according to their goals. One set has as its goal reducing the no.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.”

A third set of tactics has its goal controlling deployment time and cost. We call this set “defer binding time.”

Contd..

2.4 Performance tactics Performance tactics control the time within

the which a response is generated. This is shown in fig 5.6

Contd..

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.

Fig 5.8 shows the goals of a security tactics

2.5 Security tactics

Contd..

Contd..

2.6 Testability tactics

The goal of tactics for testability is to allow for easier testing when an increment of s/w development is completed.

Fig 5.10 displays the use of tactics for testability.

Contd..

Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of support the system provides to the users.

Two types of tactics support usability, each intended for two categories of “users”.

The first category, “runtime” , includes those that support the user during system execution.

The second category is based on the iterative nature of user interface developer at design time.

2.7 Usability tactics

Contd..

Contd..

usability

Separate user interface

Support user initiative

Support system initiative

CancelUndoaggregate

User modelSystem modelTask model

User request

UserGiven appropriate feedback and assistance

Fig 5.13 summary of runtime usability tactics

2.8 Relationships of Tactics to Architectural Patterns An architect usually chooses a pattern or a

collection of patterns designed to realize one or more tactics.

The pattern consists of six elements. A proxy which provides an interface that

allows clients to invoke publicly accessible methods on an active object

A method request which defines an interface for executing the methods of an active object.

An activation list which maintains a buffer of pending method requests

A scheduler which decides what method requests to execute next

A servant which defines the behavior and state modeled as an active object

A future which allows the client to obtain the result of the method invocation

Contd..

The other tactics this pattern involves Information hiding(modifiability)- each element

chooses the responsibilities it will achieve and hides their achievement behind an interface

Intermediary(modifiability)- the proxy acts as an intermediary that will buffer changes to the method invocation

Binding time(modifiability)- the active object pattern assumes the requests for the object arrive at the object at runtime.

Scheduling policy(performance)- the scheduler implements some scheduling policy

Contd..

An architectural pattern in s/w, 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.

3 Architectural patterns and styles

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 interrelationships.

A set of semantic constraints. A set of interaction mechanisms.

Contd..

Mary Shaw and David Garlan’s influential work attempted to catalog a set of architectural patterns that they called architectural Styles or idioms.

This has been evolved by the SEC into what is now more commonly known as architectural patterns, analogous to design patterns and code patterns.

Contd..

Contd..

4.1 Architecture in the life cycle4.2 Designing the architecture4.3 Forming the team structure4.4 Creating a skeletal system

4.Designing the architecture

Any organization that embraces architecture as a foundation for its software development processes needs to understand its place in the life cycle.

The intent of this model is to get user and customer feedback and iterate through several releases before the final release.

4.1Architecture in the life cycle

Contd..

Where can I begin designing? the life-cycle model shows the design of

the architecture as iterating with preliminary requirement analysis.

An architecture is “shaped” by some collection of functionality, quality and business requirements. We call these shaping req’s architectural drivers.

Once architectural drivers are known, the architectural design can begin.

Contd..

A method for designing an architecture to satisfy both quality req’s and functional req’s. we call this method Attribute Driven Design(ADD)

ADD is an approach to defining a s/w architecture that bases the decomposition process on the quality attributes the s/w has to fulfill.

Sample Input: the input to ADD is a set of req’s.

4.2 Designing the Architecture

Beginning ADD- the process can begin when the driver req’s are known with some assurance

ADD steps1.Choose the module to decompose2.A) choose the architectural drivers B)choose an architectural pattern c)Instantiate modules and allocate

functionality using multiple views

Contd..

Contd..

Contd..

2. D)define interfaces of the child modules E)verify and refine use cases and quality

scenarios as constraints for the child modules

3. Repeat the steps above for every module that needs further decomposition.

Contd..

Once an architecture for the system under construction has been agreed on , teams are allocated to work on the major modules and a work breakdown structure is created that reflects those teams.

Each team then creates its own internal work practices.

The teams within an organization work on modules.

4.3 Forming the Team Structure

Once an architecture is sufficiently designed and teams are in place to begin building to it, a skeletal system can be constructed.

The idea at this stage is to provide an underlying capability to implement a system’s functionality in an order advantageous to the project.

Classical S.E practice recommends “stubbing out” sections of code so that portions of the systems can be added separately and tested immediately

4.4 creating a skeletal system

5.1 Uses of Architectural Documentation5.2 Views5.3 Choosing the relevant views5.4 Documenting a View5.5 Documentation across Views5.6 Unified Modeling Language

5.Documenting Software Architecture

The architecture for a system depends on the req’s levied on it, so too does the documentation for an architecture depend on the it- i.e., how we expect it will be used.

Architecture documentation is both perspective and descriptive.

All of this tells us that different stakeholders for the documentation have different needs.

5.1 Uses of Architectural Documentation

Contd..

The concept a view, which you can think of as capturing a structure, provides us with the basic principle of documenting software architecture.

Documenting an architecture is a matter of documenting the relevant views and then adding documentation that applies to more than one view.

This principle is useful because it breaks the problem of architecture documentation into more tractable parts.

5.2 Views

Different views support different goals and uses. Different views will highlight different system

elements and/or relationships. Table shows a representative population of

stakeholders and the kind if views they tend to find useful.

Table divided views into these three groups: module, component-and-connector(C&C), and allocation. This 3-way categorization reflects the fact that architects need to think about their s/w in at least 3 ways at once:

5.3 Choosing the relevant views

1. how it is structured as a set of implementation units

2. how it is structured as a set of elements that have runtime behavior and interactions

3.How it relates to non-software structures in its environment

Contd..

Contd..

Other views are available Here is a simple three-step procedure for

choosing the views for your project1.Produce a candidate view2.Combine views3.proritize

Contd..

There is no industry-standard template for documenting a view, but the seven-part standard organization that we suggest in this section has worked well in practice.

1.Primary presentation2.Element catalog3.Context diagram4.Variability guide5.Architecture background6.Glossary of terms7.Other information

5.4 Documenting a View

Contd..

Documenting interfaces: documenting an interface consists of naming

and identifying it and documenting its syntactic and semantic information

A template for documenting interfaces1.Interface identity2.Resources provided3.Datatype definitions4.Exception definitions

Contd..

5.Variability provided by the interface6.Quality attribute characteristics of the

interface 7.Element requirement8.Rationale and design issues9.Usage guide

Contd..

Contd..

cross-view documentation consists of just three major aspects, which can summarize as how-what-why:

1.How the documentation is2.What the architecture is3.Why the architecture is the way it is

5.5 Documentation across views

Contd..

Uml has emerged as the de-facto standard notation for documenting a software architecture.

Module views- is an enumeration of modules together with their interfaces and their relations.

-interfaces-modules-aggregation-generalization-dependency

5.6 Unified Modeling Language

Component-and-connector viewsThere is no single preferred to document

component-and-connector(C&C) views in uml, but a no.of alternatives.

-components-interfaces-connectors-systems

Contd..

Allocation viewsin uml, a deployment diagram is a graph of

nodes connected by communication associations

The nesting of symbols within the node symbol signifies a composition association b/w a node class and constituent classes or a composition link b/w a node object and constituent objects.

Contd..

6.1 introduction 6.2 information extraction6.3 database construction6.4 view fusion6.5 reconstruction

6.Reconstructing Software Architectures

Reconstruction in which the “as-built” architecture of an implemented system is obtained from an existing system.

Reconstruction activitiess/w architecture reconstruction comprises the

following activities, carried out iteratively:1.Information extraction2.Database construction3.View fusion4.Reconstruction

6.1 introduction

Contd..

Information extraction involves analyzing a system’s existing design and implementation artifacts to construct a model of it.

Info obtained can be categorized as either static or dynamic.

To extract info a variety of tools are used, including these:-parsers-abstract syntax trees-lexical analyzers-profilers-code instrumentation tools-ad hoc

6.2 information extraction

Guidelinesthe following are some practical

considerations in applying this step of the method.

-use the “least effort” extraction-validate the info you have extracted-extract dynamic info where required

Contd..

The extracted info is converted into a standard format for storage in a database during database construction. It is necessary to choose a database model. When doing so, consider the following:

• It should be a well-known model• It should allow for efficient queries• It should support remote access of the database• It supports view fusion• It supports query language• Check pointing should be supported by

implementations

6.3 Database Construction

Contd..

Guidelines-build database tables from the extracted

relations-as with any database construction, carefully

consider the database design before you get started

-use simple lexical tools like perl and awk

Contd..

View fusion involves defining and manipulating extracted info to reconcile, augment, and establish connections b/w the elements.

improving a view Disambiguating function calls

6.4 View Fusion

GuidelinesThe following are some practical considerations

in applying this step of the method:-fuse tables when no single extracted table

provides the needed info-fuse tables when there is ambiguity within one

of them, and it is not possible to disambiguate using a single table

-consider different extraction techniques to extract different info.

Contd..

The view info has been extracted, stored, and refined or augmented to improve its quality. The reconstruction operates on view to reveal broad, coarse-grained insights into the architecture

Reconstruction consists of two primary activities:

-visualization and interaction-pattern definition and recognization

6.5 Reconstruction

GuidelinesThe following are some practical

considerations in applying this step of the method:

-be prepared to work with the architect closely and to iterate several times on the architectural abstraction that you create

-when developing code segments try to build ones that are succinct and that do not list every source element

Contd..

-code segments can be based on naming conventions

-code segments can be based on the directory structure

-architecture reconstruction is the effort of redetermining architectural decisions, given only the result of these decisions in the actual artifacts

Contd..

Thank U