software architecture and quality by

Software Architecture and QualityBY

Touseef TahirTouseeftahir@ciitlahore.edu.pk

Lecturer CSCOMSATS Institute of Information Technology, Lahore

IEEE 1471-2000◦ Software architecture is the fundamental organization of a

system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution

Architecture definedFormal Definition

IEEE 1471-2000

Software architecture encompasses the set of significant decisions about the organization of a software system◦Selection of the structural elements and their interfaces by

which a system is composed◦Behavior as specified in collaborations among those

elements◦Composition of these structural and behavioral elements

into larger subsystems◦Architectural style that guides this organization

Architecture definedAnother Go

Booch, Kruchten, Reitman, Bittner, and Shaw

Perry and Wolf, 1992◦ A set of architectural (or design) elements that have a particular form

Boehm et al., 1995◦ A software system architecture comprises A collection of software and system components, connections, and constraints A collection of system stakeholders' need statements A rationale which demonstrates that the components, connections, and constraints define a system that,

if implemented, would satisfy the collection of system stakeholders' need statements

Clements et al., 1997 ◦The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them

Architecture definedFew More

http://www.sei.edu/architecture/definitions.html

Architecture defines major components Architecture defines component relationships

(structures) and interactions Architecture omits content information about

components that does not pertain to their interactions Behavior of components is a part of architecture insofar

as it can be discerned from the point of view of another component

Common elements 1/2

Architecture defines major components Architecture defines component relationships

(structures) and interactions Architecture omits content information about

components that does not pertain to their interactions Behavior of components is a part of architecture insofar

as it can be detected from the point of view of another component

Common elements 1/2

Every system has an architecture (even a system composed of one component)

Architecture document defines the rationale behind the components and the structure

Common elements 2/2

Architecture represents the set of earliest design decisions◦ Hardest to change◦ Most critical to get right

Architecture is the first design artifact where a system’s quality attributes are addressed

Architecture is Early

Architecture serves as the blueprint for the system but also the project:◦ Team structure◦ Documentation organization◦ Work breakdown structure◦ Scheduling, planning, budgeting◦ Unit testing, integration

Architecture establishes the communication and coordination mechanisms among components

Architecture Drives

Architecture vs. Design

non-functional requirements

functional requirements

(domains)

Important : this is a general guideline – sometimes the borders are blurred

Architecture: where non-functional decisions are cast, and functional requirements are partitionedDesign: where functional requirements are accomplished

architecture

design

Performance Availability Usability Security

System Quality Attribute

MaintainabilityPortabilityReusabilityTestability

End User’s view

Developer’s view

Time To MarketCost and BenefitsProjected life timeTargeted MarketIntegration with Legacy System

BusinessCommunityview

A list of quality attributes exists inISO/IEC 9126-2001 Information Technology – Software Product Quality

Design patterns

Producer consumer problem

You have◦ legacy code◦ current client

Adapter changes interface of legacy code so client can use it

Adapter fills the gap b/w two interfaces e.g date formats

No changes needed for either◦ legacy code, or◦ Client

Adapter

In object-oriented programming, the command pattern is a design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

Three terms always associated with the command pattern are client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

Command

You have commands that need to be◦ executed,◦ undone, or◦ Queued

All commands derive from Command and implement do(), undo(), and redo()

You◦ have a set of related classes◦ want to shield the rest of the system from these details

Facade provides a simplified interface Encapsulates a subsystem e-g

◦ wrap a poorly-designed collection of APIs with a single well-designed API

Facade

You want uniformly to treat ◦ items (atomic elements), and◦ groups (containing items or other groups)

Composite interface specifies operations that are shared between items and groups

Examples: hierarchy of files and directories, groups of draw able elements

Composite

You want to◦ delay expensive computations,◦ use memory only when needed, or◦ check access before loading an object into memory

Proxy ◦ has same interface as Real object◦ stores subset of attributes

◦ Example : thread pools

Proxy

You want to◦ use different algorithms depending upon the context◦ avoid having to change the context or client

Strategy ◦ decouples interface from implementation◦ shields client from implementations◦ Context is not aware which strategy is being used; Client

configures the Context

Strategy

You◦ have several different implementations◦ need to choose one, possibly at run time

Bridge ◦ decouples interface from implementation◦ shields client from implementations◦ Abstraction creates and initializes the Concrete Implementations◦ Example:

optimized code execution time, memory usage, disk space, bandwidth, power

consumption

Bridge

Software Architectures

Copyright © 2001 DeLorme28 November 2001

Model view controller

Thin Client Fat Client

Client server architecture

Single tier Two Tier N Tier

Client Server Architectures

Server downloads files from shared location to Desktop environment

Job is run at the desktop environment Works if

◦ Shared usage is low◦ Data transferred is low

File Sharing Architecture

File-Server Architecture

Database server to replace File server Query based approach Reduced traffic, since required content is only

transferred Improves multi-user updating RPC or SQL typically used

Client/Server Architecture

Two Tier Architecture

N-Tier Architecture

Common Architecture for a set of products or systems developed by an organization

Product Line Architecture

Boxes and lines

Software Architecture

Software Architecture

Copenhagen city VIEWS

“4+1 Approach”

4+1 Approach

Process view

Development View

Scenario View

Conceptual viewModule view Execution viewCode view

Siemens Four view model

Develop software architecture for your project….!!!

Assignment

THANK YOU!!!!