Software Architecture and Quality BY

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

2. Architecture definedFormal Definition • IEEE 1471-2000 • Software architecture is the fundamentalorganization 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

3. Architecture definedAnother Go • 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 definedFew More • 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

5. 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 discerned from the point of view of another component

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

7. Common elements 2/2 • 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 9126-2001 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 • 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 • 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 • 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 • 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

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