Software archiecture lecture03
- 1. What is Software Architecture?
- 2. Typical, uninformative software architecture ● What can we tell from it?
- 3. Typical, uninformative software architecture ● What can we tell ● The system consists from it? of four elements ● Three of the elements might have common with each other ● All of the elements apparently have some sort of relationship with each other
- 4. Typical, uninformative software architecture ● What can we not tell ● What is the nature of from it? the elements? ● What are the responsibilities of the elements? ● What is the significance of the connections? ● What is the significance of the layout?
- 5. What is Software Architecture ● 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, – and the relationships among them ● One key aspect of architecture is – its organization of element structure, interfaces, and operating concepts
- 6. Implications of definition ● Architecture defines software elements ● Systems can and do comprise more than one structure , and no one structure can claim to be the architecture ● Every computing system with software has a software architecture ● The behavior of each element is part of the architecture ● Architecture will allow or prevent the system from meeting its – behavioral, – performance, – and life-cycle requirements
- 7. Other Points of View ● Software architecture is a growing but still young discipline – it has no single, accepted definition ● Software Engineering community has attempt to abstract the commonalities inherent in system design, and it must account for a wide range of activities, concepts, methods, approaches and results.
- 8. Other Points of View ● Architecture is high-level design. – Other tasks associated with design are not architectural, such as deciding on important data structures that will be encapsulated. ● Architecture is the overall structure of the system. – This definition imply that systems have one structure.
- 9. Other Points of View ● Architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evolution over time – This definition is process-centered, guideline, policy are not Architecture ● Architecture is components and connectors. – This definition concentrates on runtime architectural structures , So the static structure will be disappear.
- 10. Architectural Patterns , Architectural style ● An architectural pattern is – a description of element & relation – with a set of constraints on how they may be used ● An architectural pattern is not an architecture – Examples ● Client-Server ● 3 Tiers ● N- Tiers ● The most useful aspects of patterns is that they exhibit known quality attributes ● Choosing an architectural pattern is often the architect's first major design choice.
- 11. Reference Model ● A reference model is a division of functionality together with data flow between the pieces ● A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem ● Reference models are a characteristic of mature domains. ● Can you name the standard parts of a compiler or a database management system? – If so, it is because you have been taught a reference model of these applications.
- 12. Reference Architecture ● A reference architecture is a reference model mapped onto software elements and the data flows between them – Whereas a reference model divides the functionality, – a reference architecture is the mapping of that functionality onto a system decomposition ●
- 13. Relationships of RM, AP, RA ● They are not architectures ● They are useful concepts that capture elements of an architecture
- 14. Analogous ● People often make analogies to other uses of the word architecture ● A building architect must design a building that provides accessibility, aesthetics, light, maintainability, and so on. ● A software architect must design a system that provides concurrency, portability, modifiability, usability, security, and the like, and that reflects consideration of the tradeoffs among these needs.
- 15. Why is Software Architecture Important? ● From technical perspective – Communication among stakeholders – Early design decisions – Transferable abstraction of a system (re-use)
- 16. Communication among stakeholder ● ARCHITECTURE IS THE VEHICLE FOR STAKEHOLDER COMMUNICATION – Software architecture represents a common abstraction of a system that most stakeholders can use as a basis for mutual understanding, negotiation, consensus, and communication. – Each stakeholder of a software is concerned with different system characteristics ● Customer ● User ● project manager ● Coder ● Tester ● and so on
- 17. Early design decisions ● ARCHITECTURE MANIFESTS THE EARLIEST SET OF DESIGN DECISIONS – The Architecture Defines Constraints on Implementation ● Architecture define elements and interaction between each elements, these are constraints for developer
- 18. Early design decisions ● The Architecture Dictates Organizational Structure – The normal method for dividing up the labor in a large system is called the work breakdown structure (WBS) – Architecture used as the basis for WBS, which in turn dictates ● units of planning, scheduling, and budget; ● interteam communication channels; ● configuration control and file system organization; ● integration and test plans and procedures;
- 19. Early design decisions ● The Architecture Enables a System's Quality Attributes , Keep these in mind – If your system requires high performance, you need to manage the time-based behavior of elements and the frequency and volume of inter- element communication. – If modifiability is important, you need to assign responsibilities to elements such that changes to the system do not have far-reaching consequences.
- 20. Early design decisions – If you believe scalability will be needed in your system, you have to carefully localize the use of resources to facilitate the introduction of higher- capacity replacements. – If your project needs to deliver incremental subsets of the system, you must carefully manage inter-component usage. – If you want the elements of your system to be re- usable in other systems, you need to restrict inter-element coupling so that when you extract an element it does not come out with too many attachments to its current environment to be useful.
- 21. Early design decisions ● Predicting System Qualities by Studying the Architecture ● The Architecture makes it Easier to Reason about and manage change – 80 percent of a typical software system's cost occurs after initial deployment. – Software systems change over their lifetimes – Every architecture partitions possible changes into three categories: local, nonlocal, and architectural
- 22. Early design decisions ● The Architecture Helps in Evolutionary Prototyping – Once an architecture has been defined, it can be analyzed and prototyped as a skeletal system ● The system is executable early in the product's life cycle ● Potential performance problems can be identified early in the product's life cycle. ●
- 23. Early design decisions ● The Architecture Enables more accurate cost and schedule estimates – the organizational structure of a project is based on its architecture. – Each team will be able to make more accurate estimates for its piece. – the initial definition of an architecture has been reviewed by each team
- 24. Transferable abstraction of a system ● ARCHITECTURE AS A TRANSFERABLE, RE- USABLE MODEL ● While code re-use is beneficial, re-use at the architectural level provides tremendous leverage for systems with similar requirements. ● When architectural decisions can be re-used across multiple systems, all of the early decision consequences we just described are also transferred.
- 25. Transferable abstraction of a system ● Software Product Lines Share a Common Architecture ● Product line architects choose an architecture that will serve all envisioned members of the product line. ● by making design decisions that apply across the family early and by making other decisions that apply only to individual members late.
- 26. Transferable abstraction of a system ● Systems Can Be Built Using Externally Developed Elements – Architecture-based development focuses on composing or assembling elements that are likely to have been developed separately, even independently, from each other. – This composition is possible because the architecture defines the elements that can be incorporated into the system
- 27. Transferable abstraction of a system ● Less Is More: It Pays to Restrict the Vocabulary of Design Alternatives – we wish to minimize the design complexity of the system we are building. – Advantages to this approach include enhanced re-use, more regular and simpler designs that are more easily understood and communicated, more capable analysis, shorter selection time, and greater interoperability. ● An Architecture Can Be the Basis for Training – The architecture can serve as the introduction to the system for new project members
- 28. System Arch VS Software Arch ● In fact, there is little difference, ● In creating a software architecture, system considerations are seldom absent ● Most of the architect's freedom is in the software choices, not in the hardware choices. –
- 29. System Arch VS Software Arch ● Hardware choices may be out of the architect's control (for example, when creating a system that needs to work on arbitrary client machines on the Internet) or specified by others (for reasons of economics, legal issues, or compliance with standards); or they will likely change over time.
- 30. Architectural Structures and Views ● A structure is the set of elements ● Architectural structures can be divided into 3 groups ● These 3 structure groups correspond to the types of decision 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 nonsoftware structures in its environment (i.e., CPUs, file systems, networks, development teams, etc.)?
- 31. Architectural Structures and Views
- 32. Structure & View :Module
- 33. Structure & View : Component and Connector
- 34. Structure & View : Allocation
- 35. Relating structures to each other ● Each of these structures provides a different perspective ● They are not independent. ● Elements of one will be related to elements of others – a module in a decomposition structure may be manifested as one, as part of one, or as several components in one of the component-and- connector structures, reflecting its runtime
- 36. Summary ● Software architecture definitions ● Concepts of reference model, reference architecture, and architectural pattern. ● Systems comprise many structures. ● We showed several of the most commonly used structures and explained how each serves as an engineering leverage point into the design process.