Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Software Architecture Session2

1 055 vues

Publié le

Software Architecture

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

×