Practical Software Architecture - Moving From System Context To Deployment

Introduction to Software Architecture
Unit 1

Agenda
◮ What is Design?
◮ Software Architecture vs Software Design
◮ Why we need Software Architecture
◮ Role of Stake holders
◮ Role of Software Architect
◮ Activities involved in making a software Architecture
◮ Conclusion

What is D esign
◮ Requirements specification was about the WHAT the system will do

◮ Design is about the HOW the system will perform its functions
◮ Abstract
◮ Detailed

Software Architecture vs Software D esign
Software Architecture Software Design
Abstract View Detailed View

Bigger Picture Smaller Picture
Design of entire system Design of module
Analysis of system can be done Analysis of system not possible
Hard to change Modifications possible
Ex: relationship among classes Ex: Sequence Dig., UML

Why we need Software Architecture
◮ Orchestration of various technologies.

◮ To analyze properties like reliability, usability of the system (not possilbe at
code level).
◮ Used as a communication medium.
◮ Used for planning, scheduling and budget.
◮ Expose the structure; Hide its implementation details.

Figure: Role Of various stake holders

Figure: Role of software Architect

Activities involved in making a software Architecture
◮ creating business case for the system

◮ understanding the Requirements
◮ creating or selecting the Architecture
◮ documenting and communicating the architecture
◮ Analysing or evaluating the architecture
◮ Implementing the system as per the architecture
◮ ensuring the Implementation conforms to architecture

B usiness case
◮ Product cost?
◮ Targeted market?
◮ Targeted time to reach?
◮ Need of interface?

Requirements Understanding
◮ Use Case scenarios

◮ Finite State Machines
◮ Formalspecification language
◮ Prototype

communicating architecture
◮ No ambiguity.
◮ Each team should get their responsibility

Analysing or evaluating architecture
◮ Scenario based.
◮ Architecture Tradeoff Analysis Method (ATAM)
◮ Cost Benifit Analysis Method (CBAM)

What is S o f tw a r e A r chi te ctur e ?
A software architecture defines:
• The components of the software system
• How the components use each other’s functionality and data
• How control is managed between the components.
Software Architecture ={ Elements ,Form ,Rationale}
Elements : Data Elements, Processing Elements, Connecting Elements

Architectural Form : Relationship (Interactions), Properties (constraints),
weights(importance)
Rationale : Capture motivation for the choice of style , elements
Software Architecture ={ Components and Connectors}
Components : Unit of software that performs specific task. Ex object , class,

process, client, server, database
Connectors : Interaction among objects(components). Ex Shared variable,
procedure call, RPC, protocols, streams.

What is So f t w are A rch it e ct u re ?
• In partitioning an application, the architect assigns responsibilities to each constituent

component.
• Responsibilities deﬁne the tasks a component can be relied upon to perform within the
application.
• Each component plays a speciﬁc role in the application, and the overall component ensemble
that comprises the architecture collaborates to provide the required functionality
• A key structural issue for nearly all applications is minimizing dependencies between
components, creating a loosely coupled architecture from a set of highly cohesive
components

Why So f t w are Archit e ct u re ?
• Handling complexity
• Communication among stakeholders
• Early Design Decisions –(Predict behavior , quality, analysis)
• Representation of transferable knowledge of a system

Importance of Software Architecture
Software architecture:
– provides a communication among stakeholders
– captures early design decisions
– acts as a transferable abstraction of a system
– defines constraints on implementation
– dictates organizational structure
– inhibits or enables a system’s quality attributes
– is analyzable and a vehicle for predicting system qualities
– makes it easier to reason about and manage change
– helps in evolutionary prototyping
– enables more accurate cost and schedule estimates

4 + 1 View Model

4 + 1 View Model
Logical
– Focus: Functional requirements of the system.
– Contents: Class diagrams, Sequence diagrams, Layer diagrams.
Development (implementation)
– Focus: Static organization of the software in its development environment
– Contents: Component diagram, Package diagrams.
Process
– Focus: Runtime behavior of the system, such as the system processes and communication, concurrency,
performance and scalability.
– Contents: Activity diagrams.
Physical (Deployment)
– Focus: System Engineer’s perspective, looking at the system topology, deployment and communication.
– Contents: Deployment diagrams.
Scenarios
– Focus: Use cases for illustrating and validating the architecture.
– Contents: Use case diagrams.
Logical View

Development View

Process View

Scenario View

Physical View

Software Design
• Software design is the process of defining software methods, functions,

objects, and the overall structure and interaction of your code so that the
resulting functionality will satisfy your users requirements.

Software Architecture vs Design

7 Design - Bad Smell:
1. Rigidity - Rigidity is the tendency of software to be difficult to change. A single change causes a
cascade of subsequent changes in dependent modules
2. Fragility - Fragility is the tendency of software to break in many places when a single change is
made. As the fragility of a module increases the likelihood a change will introduce unexpected
problems approaches certainty
3. Immobility - A design is immobile when it contains parts that could be useful in other systems,
but the effort and risk of separating them from the original system are too great.
4. Viscosity - When faced with a change, developers often have several ways to implement the
desired change. Some ways preserve the design, others do not (they are called hacks). A system
has a high viscosity if the design-preserving changes are more difficult to use than the hacks.

7 Design - Bad Smell:
5. Opacity - Opacity is the tendency of a module to be difficult to understand. Code can be written
in a clear and expressive manner, or it can be written in an opaque and convoluted way
6. Needless repetition - Usually this happens when necessary abstractions have not been made,
either because of a lack of time or a lack of experience.
7. Needless Complexity – Good software design is lightweight, flexible, easy to read and
understand and above all easy to change so you don’t have to keep into account all potential
changes in the future

Characteristics of Good Design
• A design should exhibit a hierarchical organization about software

• A design should be modular based on logical partition.
• A design contains both data and procedural abstractions.
• A design should leads to modules with independent functional features.
• A design should leads to simplified interfaces between modules.
• A design should be derived using a repeatable method
• Software design process encourages good design through the application of
fundamental design principles, systematic methodology, and through reviews.

Characteristics of Good Design
• The design process should not suffer from “tunnel vision”.

• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The design should “minimize the intellectual distance” between the software and the
problem in the real world.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be structured to degrade gently.
• Design is not coding.
• The design should be assessed for quality.
• The design should reviewed to minimize conceptual errors.

Software Design Principles
Software design principles represent a set of guidelines that helps us to avoid having a bad design.
The software designs helps to make a software well designed, well read and best maintainable.
S.O.L.I.D. is a collection of best-practice, object-oriented design principles which can be applied to
your design, allowing you to accomplish various desirable goals such as loose-coupling, higher
maintainability, intuitive location of interesting code, etc.
 Single Responsibility
 Open - Closed
 Liskov Substitution
 Interface Segregation
 Dependency Inversion
 Modularization, Abstraction, Encapsulation, Coupling, Cohesion, Separation of interface and
implementation, Sufficiency and, completeness

Software Design Principles – Single Responsibility
The Single Responsibility Principle (SRP) states that there should never be more than
one reason for a class to change. This means that every class, or similar structure, in
your code should have only one job to do.

Software Design Principles – Open-Closed Principle
The Open-Closed Principle (OCP) states that classes should be open for extension but closed
for modification. “Open to extension” means that you should design your classes so that
new functionality can be added as new requirements are generated. “Closed for
modification” means that once you have developed a class you should never modify it,
except to correct bugs.

Software Design Principles: Liskov Substitution Principle
"Derived types must be completely substitutable for their base types"

Software Design Principles: Interface Segregation Principle
The Interface Segregation Principle (ISP) states that clients should not be forced to depend
upon interface members they do not use. When we have non-cohesive interfaces, the ISP
guides us to create multiple, smaller, cohesive interfaces.

Software Design Principles – Interface Segregation Principle

Software Design Principles – Dependency Inversion Principle
The Dependency Inversion Principle (DIP) states that high-level modules should not depend
upon low-level modules; they should depend on abstractions. Secondly, abstractions should
not depend upon details; details should depend upon abstractions.

Software Design Principles – Modularization
• Modular ization is the process of continuous decomposition of the

software system until fine-grained c o m p o n e n t s ar e created.
• W h e n you modularize a design , you are also modularizing the

requirements, p r ogr amming and test cases.

Software Design Principles – Abstraction
• Abstraction: View of an object that focuses on the information relevant to a

particular purpose and ignores the remaining information.
Procedures
Data
o r behavior
• PROCEDURAL ABSTRACTION : Simplifies reasoning about behavioral operations

containing a sequence of steps.
• DATA ABSTRACTION : Simplifies reasoning about structural composition of data

objects.

Software Design Principles – Abstraction
SEND(client, server, message)
Procedural
1. Client retrieves the serverʼs information, abstraction
2. opens a TCP/IP connection,
3. sends the message, waits for response, and
4. closes the connection
Data
abstraction
SEND(client, server, message)
MESSAGE - is an example of the data abstraction; the details of a message

can be deferred to later stages of the design phase.

Software Design Principles – ENCAPSULATION
• Encapsulation deal with providing access to abstracted entities by Exposing only
the information that services of essential to carry out such services while hiding
details of how the services are carried out.
• Information hiding: Internal details (state, structure, behavior) become the object's
secret
• Information hiding is the principle and encapsulation is the technique.
• Encapsulation is the public interface that defines how an object can be used, and
how its data is derived. Information Hiding prevents an external object from using
the derived data altogether.

Software Design Principles – Coupling
• Refers to the manner and degree of interdependence between software modules.
Measurement of dependency between units.
Higher Coupling Higher

Dependency
No dependencies Loosely coupled - some Highly coupled - many

dependencies dependencies
High coupling makes modifying parts of the system difficult, e.g., modifying a
component affects all the components to which the component is connected

Design principles - Coupling
Content
Common
Control
Stamp
Data
TIGHT COUPLING LOOSE COUPLING

More interdependency. Less interdependency.
More coordination. Less coordination.
More information flow. Less information flow

Design principles – Coupling - Types
• Content coupling - modules rely on each others’ internal data or internal

organization.
• Common coupling - modules share the same global data.
• Control coupling - one module controls the flow of another, such as by passing it a
flag or other information.
• Stamp coupling - modules share a composite data structure but use different parts
of it.
• Data coupling - modules share data through parameters, such as in a subroutine
call.
• Message coupling - modules communicate by passing messages.
• External coupling - modules share an externally imposed data format,
communication protocol or device interface.
Design principles - Cohesion
 The manner and degree to which the tasks performed by a single software
module are related to one another.
 Measures how well design units are put together for achieving a
particular tasks.
Loosely coupled and high in

cohesion
• High cohesion means keeping parts of a code base that are related to each of
them in a single place.
• Low coupling, at the same time, is about separating unrelated parts of the
code base as much as possible.

Design principles – Separation of Concern
• This principle involves defining a component by specifying a public

interface known to the client of the component) that is separate from the
details of how the component is realized.
Interface
Implementation

Design principles – COMPLETENESS AND SUFFICIENCY
• Sufficiency measures how well the designed units are at providing only
the services that are sufficient for achieving the intent (no more).
• Completeness measures how well designed units provide the required

services to achieve the intent (no less).

Fundamental Design Issues
• Design issues are the quality concerns that all software must address—for
example, performance, security, reliability, usability, etc. Another important
issue is how to decompose, organize, and package software components. Key
issues are:
 Concurrency
 Control and Handling of Events
 Data Persistence
 Distribution of Components
 Error, Exception Handling and Fault tolerance
 Interaction and Presentation
 Security

Figure: Alternatives
Fundamental Design Issues - Concurrency
 Concurrency is concerned with decomposing software into processes, tasks, and threads and
dealing with related issues of efficiency, atomicity, synchronization, and scheduling.
 In a distributed system, several processes may operate at the same time on separate
computers on the network. These processes may (but need not) communicate with each other
during their normal operation.
 complexity arises because it is practically impossible to have a top-down model of control of

these systems. The nodes in the system that deliver functionality are often independent
systems with no single authority.
 Security: How can usable security policies be defined and implemented that apply across a
set of independently managed systems?
 Example, The gateways of the sensors should be designed in such way that all are
concurrently sending the datas to the server.
by Ramraj S Design Issues View Points

Fundamental Design Issues - Control and Handling of Events
 This design issue is concerned with how to organize data and control flow as
well as how to handle reactive and temporal events through various
mechanisms such as implicit invocation and call-backs.
 Example, In the fire rescue design various events such as sensing data from
sensors transferring the data to the gateways and transferring the data from
the gateways to the server.

Fundamental Design Issues - Data Persistence
 This design issue is concerned with how to handle long-lived data.

 Example, In the fire rescue design how long the data’s will be stored in each node how
many backups will be provided.

Fundamental Design Issues - Distribution of Components
This design issue is concerned with how to distribute the software across the
hardware (including computer hardware and network hardware), how the
components communicate, and how middleware can be used to deal with
heterogeneous software.

Fundamental Design Issues –
Error and Exception Handling and Fault Tolerance
 This design issue is concerned with how to prevent, tolerate, and process errors and
deal with exceptional conditions.
 Example, In the fire rescue design if any one of the network fails how the network
will continue to receive and send the data. If any of the sensor is failed how it has to
be handled

Fundamental Design Issues - Interaction and Presentation
 This design issue is concerned with how to structure and organize interactions
with users as well as the presentation of information (for example, separation of
presentation and business logic using the Model-View-Controller approach). Note
that this topic does not specify user interface details, which is the task of user
interface design.
 Example, In the fire rescue design once the data are stored in the server, what
are the ways the users can operate those data for any kind of analysis.

Fundamental Design Issues - Security
 Design for security is concerned with how to prevent unauthorized disclosure,

creation, change, deletion, or denial of access to information and other
resources. It is also concerned with how to tolerate security-related attacks
or violations by limiting damage, continuing service, speeding repair and
recovery, and failing and recovering securely. Access control is a
fundamental concept of security, and one should also ensure the proper use
of cryptology.
 Example, In the fire rescue design if we are choosing the wireless network
connectivity for the sensor connections then what kind of security process to
deploy

Quality Attributes
.
..
Quality Attributes
 Software quality is the degree to which software possesses a desired
combination of attributes(e.g., reliability, interoperability).
 Architecture, by itself, is unable to achieve qualities
 Architecture should include the factors of interest for each attribute.
 It categorizes the attributes in various specific areas
 Design qualities
 Runtime qualities
 System qualities
 User qualities
 Non-runtime qualities
 Architecture qualities
 Business qualities
Design Quality Attributes
Conceptual Integrity:
 Defines the consistency and coherence of the overall design
 Includes the way that components or modules are designed
Maintainability:
 Ability of the system to undergo changes with a degree of ease
Reusability:
 Defines the capability for components and subsystems to be suitable for
use in other applications

Runtime Quality Attributes
Interoperability:
 Ability of a system or different systems to operate successfully by
communicating and exchanging information with other external systems
written and run by external parties
Manageability:
 Defines how easy it is for system administrators to manage the application
Reliability:
 Ability of a system to remain operational over time

Scalability:
 Ability of a system to either handle increases in load without impact on the
performance of the system, or the ability to be readily enlarged
Performance:
 Indication of the responsiveness of a system to execute any action. (Choice of
algorithms, Database design, Communication, Resource management)
Security:
 Capability of a system to prevent malicious or accidental actions outside of the
designed usage
Availability:
 Proportion of time that the system is functional and working. Measured as a
percentage of the total system downtime over a predefined period
Supportability:
 Ability of the system to provide information helpful for identifying and resolving
issues when it fails to work correctly
Testability:
 Measure of how easy it is to create test criteria for the system and its
components

User Quality Attributes
Usability:
 Defines how well the application meets the requirements of the user and
consumer by being intuitive (undo, redo, cancel)

Non Runtime Quality Attributes
Portability:
 Ability of a system to run under different computing environments
Reusability:
 Degree to which existing applications can be reused in new applications
Integrability:
 Ability to make the separately developed components of the system work
correctly together.
Modifiability:
 Ease with which a software system can accommodate changes to its software

Architecture Quality Attributes
Correctness:
 Accountability for satisfying all requirements of the system
Conceptual Integrity
 Integrity of the overall structure that is composed from a number of small
architectural structures

Business Quality Attributes
Cost and schedule:
 Cost of the system with respect to time to market, expected project lifetime,
and utilization of legacy and COTS systems
Marketability:
 Use of the system with respect to market competition

Quality Attribute General Scenario

Quality Attribute Scenario
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.

Quality Attribute Scenario - Availability

Tactics
http://www.ece.ubc.ca/~matei/EECE417/BASS/ch05lev1sec1.html
Quality attribute – Modifiability
The modifiability of a software system is the ease with which it can

be modified to changes in the environment, requirements or functional
specification.

Modifiability
Modifiability is about change and our interest in it is the cost and risk of making
changes. To plan for modifiability, an architect has to consider four questions:
• What can change?
o functions, platform, environment, system qualities, capacity…
• What is the likelihood of the change?
• When is the change made and who makes it?
o implementation, compile, build, configuration setup, execution
• What is the cost of the change?
o The cost of introducing the mechanism(s) and the cost of using it

Why Modification?
It involves evolving, changing and updating. Modifiability plays a major role in

creating a software that involves likely changes.

Modifiability Aspect
 What can change ?
 Functions, Platform, Environment.
 Qualities (performance, reliability,…)
 Capacity (number of users,..)
 When is the change required ?
 Development time, build time, configuration, runtime
 Who will implement the change ?
 Software engineers ,users , administrators ?
 What is the cost of change?
 Cost of introducing the mechanism in the architecture
 Cost of making the modification using that mechanism
 Extensibility
 Adding and enhancing functionality
 Simplification
 Complex components are difficult to change
 Simplifying functionality for maintainability
 Restructuring
 Modularizing - Creating reusable components
 Smaller components are easier to modify

 Time to deploy
 Time for introducing a new feature
 Functional scalability
 Ability to scale up or down in terms of users,
transactions …
 Functional flexibility
 Make existing functionality available to new users, new locations
& unforeseen situations.

Modifiability General Scenario
 Source
The developer, system administrator or end user, can request or introduce a
change to the system.
 Stimulus
A directive to
Add/delete/modify functionality;
Modify quality attributes
Modify platform, technology
Operate in a new environment, new users
Scale up and scale out
Artifact
Code, data, interfaces, components, resources, configurations,
…

Modifiability General Scenario
 Environment
 Response
Make, test and deploy the modification
 Response measures
• Number of affected artifacts.
• Size of the change.
• Effort & time
• Cost (direct or opportunity cost)
• Number of other functions or quality attributes affected by the change
• New defects introduces

Modifiability General QAS

Modifiability General QAS

Example Modifiability QAS
A developer wants to change the UI code (e.g. change an input field to a
pick list) at design time; the modification is made without side effects in 3
hours.

Understanding Modifiability
The modifiability of a system is determined by:
Coupling: Modules in systems have different responsibilities. If the

responsibilities of modules overlap, a single change request may impact
multiple modules. The probability that a modification to one module will
propagate to another is called coupling. Coupling is an “inter module”
characteristic and is the enemy of modifiability: low coupling is good.
Cohesion: Cohesion measures how much the responsibilities of a module

are related. The cohesion of a module is the probability that a change
request to one responsibility will impact another one.
Cohesion is an intramodule characteristic and high cohesion is
good.

Modifiability Tactics

Increase Cohesion (1/2)
Maintain Semantic Coherence The responsibilities in a module should serve the same
purpose.
Example: Responsibilities that deal with hardware should be allocated to the hardware
module and not to the application level. A hardware responsibility typically does not have
any semantic coherence with the application responsibilities.
Abstract Common Services: In case of similar services they should be implemented

only once in a slightly more general form.
Refactoring is an example of this tactic. Refactoring rule involves examining existing

responsibilities and factoring out the similar elements.

Increase Cohesion (2/2)
How to test for semantic cohesion?

Anticipate the set of envisioned changes:
Does one specific change impacts a lot of modules ?
Do fundamentally different changes affect the same module ?

If some responsibilities are not affected by a change they should be moved to another
module.
If a change impacts multiple modules, responsibilities need to be moved or allocated

to new modules.

Reduce Coupling
Hide information – Encapsulation

Encapsulation introduces an explicit interface to a module.
Encapsulation acts by enforcing information hiding behind an interface.
Maintain existing interfaces – Wrappers
A wrapper is a form of encapsulation. It is an interface for a module that
transforms the data or control information for the module.
The wrapper transformations reduce the total cost of a change by reducing
the costs associated with propagation
Reduce Communication Paths
Use Intermediaries - Break dependencies. (Data (DB repository) – services (Proxy)

Defer Binding Time
 Implementation/Design time:
 Aspect-Oriented Programming, Polymorphism, Parameterize Modules.
 Build time
 Component Replacement.(build scripts, makefiles)
 Deployment & Initialization time
 Configuration-Time Binding, Resource Files.
 Runtime
 Use Runtime Registration, Dynamic Lookup (for services)
 Interpret Parameters, Start-Up Time Binding, Runtime Binding.
 Name Servers, Plug-Ins, Publisher-Subscriber

Modifiability Tactics - Summary

Quality attribute – Availability
Availability is concerned with system failure and duration of system failures.

System failure is when the system is not able to provide the service for which it
was intended to.
Availability
Availability refers to a property of software that it is there and ready to

carry out its task when you need it to be (availability builds upon the concept
of reliability by adding the notion of recovery).
"Availability refers to the ability of a system to mask or repair faults such

that the cumulative service outage period does not exceed a required value
over a specified time interval.“
- Availability related Security
- Availability expressed in the product Service Level agreement.
Categorization of hazards
• Catastrophic. Loss of Critical Function

• Hazardous. Large negative impact on safety or performance,
• Major. This kind of failure is significant, but has a lesser impact
(discomfort)
• Minor. This kind of failure is noticeable
• No effect. This kind of failure has no impact
Availability General QAS
E x ampl e Av ailability Q AS
"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.
Availability General Scenario
Source of stimulus. We differentiate between internal and external indications of faults or

failure since the desired system response may be different.
Stimulus. A fault of one of the following classes occurs.

• omission. A component fails to respond to an input.
• crash. The component repeatedly suffers omission faults.
• timing. A component responds but the response is early or late.
• response. A component responds with an incorrect value.
Artifact. This specifies the resource that is required to be highly available, such as a
processor, communication channel, process, or storage.
Availability General Scenario
Environment. The state of the system when the fault or failure occurs may also affect the
desired system response
Response. There are a number of possible reactions to a system failure. logging the failure,
notifying selected users or other systems, switching to a degraded mode with either less
capacity or less function, shutting down external systems, or becoming unavailable during
repair.
Response measure. The response measure can specify an availability percentage, or it can
specify a time to repair, times during which the system must be available, or the duration for
which the system must be available.
Goal of Availability
Availability tactics, therefore, are designed to enable a system to endure system
faults so that a service being delivered by the system remains compliant with its
specification
Availability Tactics
Availability tactics – Fault Detection
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. If the heartbeat fails, the originating component is assumed to have
failed and a fault correction component is notified
Exceptions. One method for recognizing faults is to encounter an exception, which is raised when one of
the fault classes is recognized.
Time Stamp. Used to detect incorrect sequence of events.
Sanity Checking. Checks validity and reasonableness of specific operation
Self-Test. Components can self test.

Availability tactics – Fault Recovery – Preparation & Repair
Voting. Processes running on redundant processors each take equivalent input and compute a simple
output value that is sent to a voter. If the voter detects deviant behavior from a single processor, it
fails it.
Active redundancy (hot restart). All redundant components respond to events in parallel. Consequently,
they are all in the same state. The response from only one component is used, and the rest are
discarded.
Passive redundancy (warm restart/dual redundancy/triple redundancy). One component responds to
events and informs the other components of state updates they must make.
Spare. A standby spare computing platform is configured to replace many different failed components.
It must be rebooted to the appropriate software configuration and have its state initialized when a
failure occurs.
Availability tactics – Fault Recovery – Reintroduction
Shadow operation. A previously failed component may be run in "shadow mode" for a short time to
make sure that it mimics the behavior of the working components before restoring it to service.
State resynchronization. The passive and active redundancy tactics require the component being
restored to have its state upgraded before its return to service. The updating approach will depend on
the downtime that can be sustained, the size of the update, and the number of messages required for
the update.
Checkpoint/rollback. A checkpoint is a recording of a consistent state created either periodically or in

response to specific events. If System fails, In this case, the system should be restored using a previous
checkpoint of a consistent state and a log of the transactions that occurred since the snapshot was
taken.
Availability tactics – Fault Prevention
Removal from service. This tactic removes a component of the system from operation to undergo some
activities to prevent anticipated failures. One example is rebooting a component to prevent memory
leaks from causing a failure. If this removal from service is automatic, an architectural strategy can be
designed to support it. If it is manual, the system must be designed to support it.
Transactions. A transaction is the bundling of several sequential steps such that the entire bundle can
be undone at once. Transactions are used to prevent any data from being affected if one step in a
process fails and also to prevent collisions among several simultaneous threads accessing the same
data.
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.
Quality attribute – Performance
Performance is about Timing.

Performance
Performance is about timing. Events occur, and the system must respond to them. There are a
variety of characterizations of event arrival and the response but basically performance is
concerned with how long it takes the system to respond when an event occurs.
Request:
A Web-based financial services system gets events from its users . For the Web-based
financial system, the response might be the number of transactions that can be processed in a
minute.
Arrival Pattern may be periodic stochastic and, sporadic.
Response:
The response of the system to a stimulus can be characterized by latency, deadlines in
processing ,the throughput of the system, the jitter of the response, the number of events not
processed because the system was too busy to respond, and the data that was lost because
the system was too busy
Performance General QAS
General Scenario for Performance
Source of stimulus. The stimuli arrive either from external (possibly multiple) or internal
sources.
Stimulus. The stimuli are the event arrivals.
Artifact. The artifact is always the system's services,
Environment. The system can be in various operational modes, such as normal, emergency,
or overload.
Response. The system must process the arriving events
Response measure. The response measures are the time it takes to process the arriving
events. In our example, the transactions should be processed with an average latency of
two seconds.
E x ampl e P e rf o rmance Q AS
"Users initiate 1,000 transactions per minute stochastically under normal operations, and
these transactions are processed with an average latency of two seconds."
Goal of Performance
the goal of performance tactics is to generate a response to an event arriving at the
system within some time constraint.
Performance Tactics
Performance Tactics
After an event arrives, either the system is processing on that event or the processing is blocked
for some reason. This leads to the two basic contributors to the response time: resource
consumption and blocked time.
Resource consumption. Resources include CPU, data stores, network communication bandwidth,
and memory, but it can also include entities defined by the particular system under design
Blocked time. A computation can be blocked from using a resource because of contention for it,
because the resource is unavailable, or because the computation depends on the result of other
computations that are not yet available.
Contention for Resources, Availability of resources, Dependency on other computation.
Performance Tactics– Resource Demand
• Increase computational efficiency. One step in the processing of an event or a

message is applying some algorithm. Improving the algorithms used in critical
areas will decrease latency..
• Reduce computational overhead. If there is no request for a resource, processing
needs are reduced.
• Manage event rate. If there is no control over the arrival of externally generated
events, queued requests can be sampled at a lower frequency, possibly resulting in
the loss of requests.
• Control frequency of sampling. If it is possible to reduce the sampling frequency at
which environmental variables are monitored, demand can be reduced.
Performance Tactics– Resource Demand
Bound execution times. Place a limit on how much execution time is used to respond to
an event. Sometimes this makes sense and sometimes it does not. For iterative, data-
dependent algorithms, limiting the number of iterations is a method for bounding
execution times.
Bound queue sizes. This controls the maximum number of queued arrivals and
consequently the resources used to process the arrivals.
Performance Tactics– Resource management
Introduce concurrency. If requests can be processed in parallel, the blocked time can be
reduced. Concurrency can be introduced by processing different streams of events on
different threads or by creating additional threads to process different sets of activities.
Maintain multiple copies of either data or computations. Clients in a client-server

pattern are replicas of the computation. The purpose of replicas is to reduce the
contention that would occur if all computations took place on a central server.
Increase available resources. Faster processors, additional processors, additional

memory, and faster networks all have the potential for reducing latency.
Performance Tactics– Resource Arbitration
Whenever there is contention for a resource, the resource must be scheduled. Processors
are scheduled, buffers are scheduled, and networks are scheduled.
Scheduling Policy: Priority Assignment and dispatching.
• First-in/First-Out
• Fixed-Priority Scheduling – semantic importance, deadline monotonic, rate monotonic
• Dynamic Priority – round robin, earliest deadline first.
• Static Scheduling
http://etutorials.org/Programming/Software+architecture+in+practice,+second+edition/Part
+Two+Creating+an+Architecture/Chapter+5.+Achieving+Qualities/5.4+Performance+Tactics/
Quality attribute – Security
Security is a measure of the system's ability to resist unauthorized

usage while still providing its services to legitimate users.
Security
Security is a measure of the system's ability to resist unauthorized usage while still providing
its services to legitimate users.
An attempt to breach security is called an attack and can take a number of forms such as theft
of credit card numbers, destruction of files on computer systems, or to denial-of-service
attacks carried out by worms or viruses.
Security can be characterized as a system providing nonrepudiation, confidentiality, integrity,
assurance, availability, and auditing.
Security
• Non-repudiation is the property that a transaction (access to or modification of
data or services) cannot be denied by any of the parties to it.
• Confidentiality is the property that data or services are protected from
unauthorized access.
• Integrity is the property that data or services are being delivered as intended.
• Assurance is the property that the parties to a transaction are who they purport to
be.
• Availability is the property that the system will be available for legitimate use.
• Auditing is the property that the system tracks activities within it at levels
sufficient to reconstruct them.
Security General QAS
General Scenario for Security
• Source: Individual or system that is correctly identified, identified incorrectly, unknown identity
who is internal/external, authorized/not with access to limited resources, vast resources.
• Stimulus: Tries to display data, change/delete data, access system services, reduce availability to
system services.
• Artifact: System services; data within system.
• Environment: Either online or offline, connected or disconnected, firewalled or open.
• Response: Authenticates user; hides identity of the user; blocks access to data and/or services;
allows access to data and/or services; grants or withdraws permission to access data.
• Response Measure: Time/effort/resources required to circumvent security measures with

probability of success; probability of detecting attack; probability of identifying individual
responsible for attack or access/modification of data and/or services; percentage of services still
available under denial-of-services attack; restore data/services; extent to which data/services
damaged and/or legitimate access denied.
E x ampl e Se cu rity Q AS
Unidentified user trying to modify the pay rate the system detect that and track record of
it and restore the original data.
Goal of Security
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.
Security Tactics
Security Tactics– Detecting Attacks
The detection of an attack is usually through an intrusion detection system. Such systems
work by comparing network traffic patterns to a database.
In the case of misuse detection, the traffic pattern is compared to historic patterns of known
attacks. In the case of anomaly detection, the traffic pattern is compared to a historical
baseline of itself.
Frequently, the packets must be filtered in order to make comparisons. Filtering can be on
the basis of protocol, TCP flags, payload sizes, source or destination address, or port
number.
Security Tactics– Resisting Attacks
Authenticate users. Authentication is ensuring that a user or remote computer is actually

who it purports to be. Passwords, one-time passwords, digital certificates, and biometric
identifications provide authentication.
Authorize users. Authorization is ensuring that an authenticated user has the rights to
access and modify either data or services. This is usually managed by providing some
access control patterns within a system.
Maintain data confidentiality. Data should be protected from unauthorized access.
Confidentiality is usually achieved by applying some form of encryption to data and to
communication links
Security Tactics– Resisting Attacks
Maintain integrity. Data should be delivered as intended. It can have redundant information
encoded in it, such as checksums or hash results, which can be encrypted either along with or
independently from the original data.
Limit exposure. Attacks typically depend on exploiting a single weakness to attack all data
and services on a host. The architect can design the allocation of services to hosts so that
limited services are available on each host.
Limit access. Firewalls restrict access based on message source or destination port. Messages
from unknown sources may be a form of an attack. It is not always possible to limit access to
known sources.
Security Tactics– Recovering from Attacks
Tactics involved in recovering from an attack can be divided into restoring state and attacker
identification.
The tactics used in restoring the system or data to a correct state overlap with those used for
availability since they are both concerned with recovering a consistent state from an
inconsistent state. One difference is that special attention is paid to maintaining redundant
copies of system administrative data such as passwords, access control lists, domain name
services, etc.
The tactic for identifying an attacker is to maintain an audit trail. Audit information can be
used to trace the actions of an attacker, support nonrepudiation and support system
recovery.
Quality attribute – Testability
Software testability refers to the ease with which software can be

made to demonstrate its faults through testing
Testability
• At least 40% of the cost of developing well-engineered systems is taken up by testing. If the
software architect can reduce this cost, the payoff is large.
• 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.
• For a system to be properly testable, it must be possible to control each component's internal
state and inputs and then to observe its outputs. Frequently this is done through use of a test
harness, specialized software designed to exercise the software under test. This may be as simple
as a playback capability for data recorded across various interfaces or as complicated as a testing
chamber for an engine.
• Testing is done by various developers, testers, verifiers, or users and is the last step of various
parts of the software life cycle. Portions of the code, the design, or the complete system may be
tested.
• The response measures for testability deal with how effective the tests are in discovering faults
and how long it takes to perform the tests to some desired level of coverage.
Testability General QAS
General Scenario for Testability
Source of stimulus. The testing is performed by unit testers, integration testers, system
testers, or the client.
Stimulus. The testing is triggered by the completion of a unit of code.
Artifact. A design, a piece of code, or the whole system is the artifact being tested. In
our example, a unit of code is to be tested.
Environment. The test can happen at design time, at development time, at compile
time, or at deployment time.
Response. Since testability is related to observability and controllability, the desired
response is that the system can be controlled to perform the desired tests and that the
response to each test can be observed. In our example, the unit can be controlled and
its responses captured.
Response measure. Response measures are the percentage of statements that have
been executed in some test, the length of the longest test chain
Goal of Testability
The goal of tactics for testability is to allow for easier testing when an increment of
software development is completed.
Testability Tactics
Testability Tactics -INPUT/OUTPUT
• Record/playback. Record/playback refers to both capturing information crossing an

interface and using it as input into the test harness. The information crossing an
interface during normal operation is saved in some repository and represents output
from one component and input to another.
• Separate interface from implementation. Separating the interface from the
implementation allows substitution of implementations for various testing purposes.
Stubbing implementations allows the remainder of the system to be tested in the
absence of the component being stubbed
• Specialize access routes/interfaces. Having specialized testing interfaces allows the
capturing or specification of variable values for a component through a test harness as
well as independently from its normal execution.
Testability Tactics – Built-in Monitors
Built-in monitors. The component can maintain state, performance load, capacity,
security, or other information accessible through an interface. This interface can be a
permanent interface of the component or it can be introduced temporarily via an
instrumentation technique such as aspect-oriented programming or preprocessor
macros.
A common technique is to record events when monitoring states have been activated.
Monitoring states can actually increase the testing effort since tests may have to be
repeated with the monitoring turned off. Increased visibility into the activities of the
component usually more than outweigh the cost of the additional testing.
Quality attribute – Interoperability
Interoperability is about the degree to which two or more systems can usefully
exchange meaningful information
Interoperability
For two or more systems to usefully exchange information they must

– Know about each other. That is the purpose behind the locate tactics.
– Exchange information in a semantically meaningful fashion. That is the purpose
behind the manage interfaces tactics.
Two aspects of the exchange are
• Provide services in the correct sequence
• Modify information produced by one actor to a form acceptable to the second
actor.
Goal of Interoperability
.
Interoperability Tactics
Interoperability Tactics
• Discover service: Locate a service through searching a known directory service.

There may be multiple levels of indirection in this location process – i.e. a known
location points to another location that in turn can be searched for the service.
• Orchestrate: uses a control mechanism to coordinate, manage and sequence the

invocation of services. Orchestration is used when systems must interact in a
complex fashion to accomplish a complex task.
• Tailor Interface: add or remove capabilities to an interface such as translation,

buffering, or data-smoothing.
Quality Attributes Trade-off
 Performance  Security, Availability, Testability,
 Availability  Security
 Security  Performance, Accessibility, Usability,

Cost
 Scalability  Security
Case Study Discussion

Design a System
 Mail Server
 All problems have to be recorded with time in a log
 If there is a operational fault, with the help of log file it should be
cleared.

v1:Classical
v1: ClassicalApproach
Approach
) No centralized appraoch
) make all the log in a file
) grep function needed to search
Figure:
by Ramraj S
Architecture
v2: With RDMS
) centralized appraoch
) make all the log file in RDMS
) Indexing is needed
Figure:
by Ramraj S
Architecture
v2:
v2:With
WithMapReduce
Mapreduce
) centralized appraoch
) make all the log file in a distributed file system.
) Indexing is faster using Mapreduce.
Figure:
by Ramraj S
Architecture
Architecture - Tradeoff
Tradeoff: Data Freshness

) In version 1 Queries run on current data.
) In Version 2 Queries run on 10 minutes old data
) In Version 3 Queries run on 10-20 minutes old data
Tradeoff: Scalability
) In Version 1 Slow down (for Dozens of Servers)
) In VErsion 2 Speed and Stability problem (for Hunderends of
Servers)
) In version 3 No Problem yet
Tradeoff: Adhoc Query ease
) In version 1 Regular Expression.
) In Version 2 SQL Expression.
) In Version 3 Mapreduce program.

case study
Figure: Architecture Business Cycle realtes to A-7E avionics systems

Practical Software Architecture - Moving From System Context To Deployment

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Practical Software Architecture - Moving From System Context To Deployment

Transféré par

Droits d'auteur :

Formats disponibles

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

◮ Requirements specification was about the WHAT the system will do

Introduction to Software Architecture

Software Architecture Software Design

Abstract View Detailed View

Introduction to Software Architecture

◮ Orchestration of various technologies.

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

◮ creating business case for the system

Introduction to Software Architecture

Introduction to Software Architecture

◮ Use Case scenarios

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Software Architecture ={ Elements ,Form ,Rationale}

Elements : Data Elements, Processing Elements, Connecting Elements

Software Architecture ={ Components and Connectors}

Components : Unit of software that performs specific task. Ex object , class,

Introduction to Software Architecture

• In partitioning an application, the architect assigns responsibilities to each constituent

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

• Software design is the process of defining software methods, functions,

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

• A design should exhibit a hierarchical organization about software

Introduction to Software Architecture

• The design process should not suffer from “tunnel vision”.

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

Introduction to Software Architecture

• Modular ization is the process of continuous decomposition of the

• W h e n you modularize a design , you are also modularizing the

Introduction to Software Architecture

• Abstraction: View of an object that focuses on the information relevant to a

• PROCEDURAL ABSTRACTION : Simplifies reasoning about behavioral operations

• DATA ABSTRACTION : Simplifies reasoning about structural composition of data

Introduction to Software Architecture

SEND(client, server, message)

MESSAGE - is an example of the data abstraction; the details of a message

Introduction to Software Architecture

• Encapsulation deal with providing access to abstracted entities by Exposing only

details of how the services are carried out.

• Information hiding is the principle and encapsulation is the technique.