1. 1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University

2. Outline 1. What Software Architecture is and What isn’t 2. Other Points of View 3. Architectural Patterns, Reference Models, and Reference Architecture 4. Why is Software Architecture Important? 5. Architectural Structures and Views 6. Summary 2

3. What is Software Architecture? Lecture: 2 3

4. 1. What is Software Architecture? Quite often shown as box-and-arrow diagrams 4 Control Process (CP) Prop Loss Model (MODP) Reverb Model (MODR) Noise Model (MODN)

5. What is Missing? What is the nature of the elements? What are the responsibilities of the elements? What is the significance of the connections? What is the significance of the layout? Unless we know precisely what the elements are & how they cooperate to accomplish the purpose of the system, this diagram is unhelpful! 5

6. Definition Again Definition; The software architecture of a program is the structure or structures of the system, which comprise software elements, the externally visible properties of these elements, and the relationships among them We see the elements (CP, MODP, MODR, MODN), but what properties do they or their relationships have? 6

7. Externally Visible Properties The assumptions that other elements can make of an element, such as:  its provided services,  performance characteristics,  fault handling,  shared resource usage,  etc. 7

8. Definition Implications 1. Architecture defines software elements 2. Systems can and do comprise more than one structure, all are part of the architecture 3. Every computing system with software has an architecture 4. The behavior of each element is part of the architecture as far as its behavior can be observed or discerned from the point of view of another element 5. The definition doesn’t judge goodness or badness 8

9. 2. Other Points of View Architecture is high-level design Architecture is the overall structure of the system Architecture is the structure of the components of a program or a system, their relationships, and the principles and guidelines governing their design and evolution over time Architecture is components and connectors 9

10. 3. Useful Concepts Three stages that capture characteristics of an architecture, on the way from box-and-arrow to full software architectures:  Architectural Patterns  Reference Models  Reference Architectures 10

11. Architectural Patterns A description of element & relation types together with a set of constraints on how they may be used These constraints on an architecture define a set or family of architectures  For example, the client-server pattern has 2 element types (?); their relationship is a protocol that the server uses to communicate with each of its clients, the clients don’t communicate directly and functionality is excluded 11

12. Value of Patterns They exhibit known quality attributes, and are a reuse of experience Some patterns solve performance problems, others apply to high-security systems, or high-availability goals Often the architect’s first major design decision Also referred to as architectural styles 12

13. Reference Models A division of functionality together with data flow between the pieces A standard decomposition of a known problem into parts that cooperatively solve the problem They arise from experience, and are thus a characteristic of mature domains  For example, the standard parts of a compiler or database management system & how they work together 13

14. Reference Architecture A reference model mapped onto software elements and the data flows between them. The elements must cooperatively implement the functionality defined in the reference model The mapping may be 1-1, but an element may implement a part of a function or several functions 14

15. Relationship among Architectural Patterns, Reference Models & Reference Architecture 15 Reference Model Architectural Pattern Reference Architecture Software Architecture

16. 4. Why is Software Architecture Important? Three fundamental reasons from a technical perspective:  Communication among stakeholders a basis for mutual understanding, negotiation, & consensus  Early design decisions earliest point at which decisions can be analyzed  Transferable abstraction of a system can promote large-scale reuse 16

17. 5. Structures and Views A view is a representation of a coherent set of architectural elements, consisting of:  a set of elements  the relationships among them A structure is the set of elements itself, as they exist in software or hardware Often used interchangeably, text will distinguish 17

18. Group of Architectural Structures Module structures  units of implementation with assigned areas of functionality - usually static Component-and-connector structures  runtime components (principal units of computation) and connectors (communication vehicles) Allocation structures  show relationships between software elements & external environments (creation or execution) 18

19. Three Types of Structures Correspond to the three broad types of decisions that architectural design involves:  How is the system to be structured as a set of code units (modules)?  How is the system to be structured as a set of elements that have runtime behavior (components) and interactions (connectors)?  How is the system to relate to non-software structures in its environment (i.e., CPUs, file systems, networks, development teams, etc. - allocation)? 19

20. Three Types of Structures 20

21. Non-functional Properties Each structure provides a method for reasoning about some of the relevant quality attributes, for example:  the uses structure, must be engineered to build a system that can be easily extended or contracted  the process structure is engineered to eliminate deadlock and reduce bottlenecks  the module decomposition structure is engineered to produce modifiable systems, etc. 21

22. Relating Structures to Each Other Although the structures give different system perspectives, they are not independent Elements of one structure are related to elements in another, and we need to reason about these relationships  For example, a module in a decomposition structure may map to one, part of one, or several, components in a component-and-connector structure at runtime In general, mappings are many-many 22

23. Choosing Structures Kruchten’s Four + One Views:  Logical - elements are “key abstractions” that are objects or classes in OO. This is a module view  Process - addresses concurrency & distribution of functionality. This is a C&C view  Development - shows organization of software modules, libraries, subsystems, and units of development. This is an allocation view  Physical - maps other elements onto processing & communication nodes, also an allocation view, but usually referred to specifically as the deployment view 23

24. Assignment# 1 Due Date: 26 th September, 2012 24

25. 25 Summary Any Questions?