Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Architecture Session2

1,058 views

Published on

Software Architecture

Published in: Software
  • Be the first to comment

  • Be the first to like this

Software Architecture Session2

  1. 1. SOFTWARE ARCHITECTURE Session - 2
  2. 2. What is Software Architecture? • Quite often shown as box-and-arrow diagrams. Control Process (CP) Prop Loss Model (MODP) Reverb Model (MODR) Noise Model (MODN) Figure 2.1 9:32 AM SEPS ZG651 Software Architectures 2
  3. 3. What’s 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! 9:32 AM SEPS ZG651 Software Architectures 3
  4. 4. Definition Again • The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, an the relationships between them. • We see the elements (CP, MODP, MODR, MODN), but what properties do they or their relationships have? 9:32 AM SEPS ZG651 Software Architectures 4
  5. 5. 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. 9:32 AM SEPS ZG651 Software Architectures 5
  6. 6. 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. 9:32 AM SEPS ZG651 Software Architectures 6
  7. 7. 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 Reference Model Architectural Pattern Reference Architecture Software Architecture Figure 2.2 Source : Bass, Clements, and Kazman. Software Architecture in Practice, 9:32 AM SEPS ZG651 Software Architectures 7
  8. 8. 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. Functionality is excluded. 9:32 AM SEPS ZG651 Software Architectures 8
  9. 9. 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. 9:32 AM SEPS ZG651 Software Architectures 9
  10. 10. 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. 9:32 AM SEPS ZG651 Software Architectures 10
  11. 11. Reference Architectures • 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. 9:32 AM SEPS ZG651 Software Architectures 11
  12. 12. Why is 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 9:32 AM SEPS ZG651 Software Architectures 12
  13. 13. Early design decisions • The architecture: – defines constraints on implementation – dictates organizational structure – inhibits or enables a system’s quality attributes • some details on next slide, more on p. 30 – studying it can predict system qualities – easier to reason about and manage change – helps in evolutionary prototyping – enables more accurate cost & schedule estimates 9:32 AM SEPS ZG651 Software Architectures 13
  14. 14. Quality Attributes High performance Manage the time-based behavior of elements; the frequency & volume of inter-element communication Scalability Carefully localize the use of resources to facilitate the introduction of high-capacity replacements Deliver incremental subsets Carefully manage inter-component usage Re-usable elements Restrict inter-element couplings so an extraction doesn’t have too many environment attachments to be useful 9:32 AM SEPS ZG651 Software Architectures 14
  15. 15. Architecture: a Transferable, Reusable Model • The earlier in the lifecycle re-use is applied, the greater the benefit. – Software Product Lines share a common architecture. – Composing with large, externally developed elements. – Restrict the vocabulary of design alternatives: patterns. – Architecture permits template-based development. – Used as the basis for training. 9:32 AM SEPS ZG651 Software Architectures 15
  16. 16. 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. 9:32 AM SEPS ZG651 Software Architectures 16
  17. 17. Groups 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) 9:32 AM SEPS ZG651 Software Architectures 17
  18. 18. 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)? 9:32 AM SEPS ZG651 Software Architectures 18
  19. 19. Figure 2-3 Source : Bass, Clements, and Kazman. Software Architecture in Practice, 9:32 AM SEPS ZG651 Software Architectures 19
  20. 20. 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. 9:32 AM SEPS ZG651 Software Architectures 20
  21. 21. Value of Structures • Each structure provides the architect with a different view into the system & a different leverage point for design. • Table 2.1 on page 39-40 should be useful in your class project... Source : Bass, Clements, and Kazman. Software Architecture in Practice, 9:32 AM SEPS ZG651 Software Architectures 21
  22. 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. 9:32 AM SEPS ZG651 Software Architectures 22
  23. 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. 9:32 AM SEPS ZG651 Software Architectures 23
  24. 24. Quick Exercise • Read “Architecture Deja Vu” on pages 43-45. • What do you think? Do you agree or disagree? Why? 9:32 AM SEPS ZG651 Software Architectures 24
  25. 25. Summary 9:32 AM SEPS ZG651 Software Architectures 25
  26. 26. 9:32 AM SEPS ZG651 Software Architectures 26

×