Software Architecture and Quality BY Touseef Tahir Touseeftahir@ciitlahore.edu.pk Lecturer CS COMSATS Institute of Information Technology, Lahore

Architecture defined Formal Definition Emphasize that the rationale for the architectural decisions is very important. 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 IEEE 1471-2000 .

Architecture defined Another Go Emphasize that the rationale for the architectural decisions is very important. 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 Booch, Kruchten, Reitman, Bittner, and Shaw .

Architecture defined Few More Key words in the definitions are underlined. 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 http://www.sei.edu/architecture/definitions.html .

Common elements 1/2 Architecture defines major components Every system has an architecture, even if it is not formally “spec’ed out”. 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 Every system has an architecture, even if it is not formally “spec’ed out”. 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 2/2 Every system has an architecture, even if it is not formally “spec’ed out”. Every system has an architecture (even a system composed of one component) Architecture document defines the rationale behind the components and the structure .

Architecture is Early 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 Drives 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 vs. Design Architecture: where non-functional decisions are cast, and functional requirements are partitioned Design: where functional requirements are accomplished architecture non-functional requirements design functional requirements (domains) Important : this is a general guideline – sometimes the borders are blurred .

System Quality Attribute Performance Availability Usability Security Time To Market Cost and Benefits Projected life time Targeted Market Integration with Legacy System Business Community view End User’s view Maintainability Portability Reusability Testability Developer’s view A list of quality attributes exists in ISO/IEC 9126-2001 Information Technology – Software Product Quality .

Design patterns

Producer consumer problem

Adapter 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

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

You have commands that need to be executed, undone, or Queued All commands derive from Command and implement do(), undo(), and redo()

Facade You Facade provides a simplified interface 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

Composite 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

Proxy You want to Proxy 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

Strategy You want to Strategy 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

Bridge You Bridge 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

Software Architectures

Model view controller Copyright © 2001 DeLorme 28 November 2001

Client server architecture Thin Client Fat Client

Client Server Architectures Single tier Two Tier N Tier

File Sharing Architecture 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-Server Architecture

Client/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

Two Tier Architecture

N-Tier Architecture

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

Boxes and lines

Software Architecture

Software Architecture

Copenhagen city VIEWS

“4+1 Approach”

4+1 Approach

Process view

Development View

Scenario View

Siemens Four view model Conceptual view Module view Execution view Code view

Assignment Develop software architecture for your project….!!!

THANK YOU!!!!