Software architecture 4
- 1. Software Architecture & Design Syed Salman Qadri Asisstant Professor (CS) The Islamia University of Bahawalpur
- 2. Why Architecture is Important Three Main Reason of Importance • Mutual communication • Early design decisions. • Reusability of a system.
- 3. Why Software Architecture important Software Architecture Reusability of Mutual Design Decision system communication
- 5. Mutual communication • Software architecture represents a common high-level abstraction of the system that most, if not all, of the system's stakeholders can use as a basis for creating mutual understanding, forming consensus, and communicating with each other
- 6. Mutual Communication • Each stakeholder of a software system (customer, user, project manager, coder,tester, and so on) is concerned with different characteristics of the system that are affected by its architecture. Architecture provides a common language in which different concerns can be expressed, negotiated, and resolved at a level that is
- 7. Continued… • intellectually manageable, even for large, complex systems.Without such language, it is difficult to understand large systems sufficiently to make the early decisions that influence both quality and usefulness
- 8. Early design decisions. • Software architecture embodies a relatively small, intellectually graspable model for how the system is structured and how its • components work together; this model is transferable across systems; • particular, it can be applied to other systems exhibiting similar requirements, and can promote large scale reuse..
- 9. Early design decisions. • The architecture is in fact the sum of the early design decisions. System architects choose an architecture • Capture the emergent behavior of the system, that is they relate to system as a whole or a family of closely related architectures.
- 10. Continued… • The architecture defines what is fixed for all members of the family and what is variable
- 11. Limitations • Resource allocation decisions also constraint on implementation level • The architects need not be experts in all aspects of designing but he knows the all architectural trade-offs. • the work breakdown structure of a system
- 12. Limitations. • The work breakdown structure, in turn, dictates units of planning, scheduling, and budget, as well as inter-team communications channels, configuration control and file system organization • Integrations of all subsystems is not so easy task
- 13. Reusability of a system • Software architecture embodies a relatively small, intellectually graspable model for how the system is structured and how its components work together; this model is transferable across systems; in particular, it can be applied to other systems exhibiting similar requirements, and can promote large scale reuse.
- 14. Reusability of a system • reusing a family-wide design reduces the risk that a derived system might have an inappropriate architecture. Using a standard design reduces both risk and development costs, at the risk of non- optimality
- 15. Architectural Attributes • Performance can be enhanced by localising operations to minimize sub-system communication. That is, try to have self- contained modules as much as possible so that inter-module communication is minimized. • Security can be improved by using a layered architecture with critical assets put in inner layers. • Safety Safety-critical components should be isolated
- 16. Architectural Attributes • Availability can be ensured by building redundancy in the system and having redundant components in the architecture. • Maintainability is directly related with simplicity.Therefore,maintainability can be increased by using fine-grain, self- contained components
- 17. Architectural Design Process • System structuring is concerned with decomposing the system into interacting sub-systems. The system is decomposed into several principal sub-systems and communications between these sub- systems are identified.
- 18. Architectural Design Process • Control modelling establishes a model of the control relationships between the different parts of the system.
- 19. Architectural Design Process • Modular decomposition During this activity, the identified sub-systems are decomposed into modules.
- 20. References • ‘Requirements Engineering: Processes and Techniques’ by G. Kotonya and I. Sommerville, John Wiley & Sons, 1998 • Software Requirements: Objects, Functions, and States by A. Davis, PH, 1993 • Software Engineering 6th Edition, by I. Sommerville, 2000 • Software Engineering 5th Edition, by R. Pressman
- 21. Any Question?? Thanks