1. Software Architecture and Quality BY
Touseef Tahir
Lecturer CS
COMSATS Institute of Information Technology, Lahore

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

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

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

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

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

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

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

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

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

11. 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 Information Technology – Software Product Quality .

12. Design patterns

13. Producer consumer problem

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

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

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

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

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

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

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

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

22. Software Architectures

23. Model view controller
Copyright © 2001 DeLorme
28 November 2001

24. Client server architecture
Thin Client
Fat Client

25. Client Server Architectures
Single tier
Two Tier
N Tier

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

27. File-Server Architecture

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

29. Two Tier Architecture

30. N-Tier Architecture

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

33. Boxes and lines

40. Software Architecture

41. Software Architecture

43. Copenhagen city VIEWS

44. “4+1 Approach”

45. 4+1 Approach

46. Process view

47. Development View

48. Scenario View

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

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

67. THANK YOU!!!!