Software architecture 4


Published on

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software architecture 4

  1. 1. Software Architecture & Design Syed Salman Qadri Asisstant Professor (CS) The Islamia University of Bahawalpur
  2. 2. Why Architecture is Important Three Main Reason of Importance• Mutual communication• Early design decisions.• Reusability of a system.
  3. 3. Why Software Architectureimportant Software Architecture Reusability of Mutual Design Decision system communication
  4. 4. Mutual communication
  5. 5. Mutual communication• Software architecture represents a common high-level abstraction of the system that most, if not all, of the systems stakeholders can use as a basis for creating mutual understanding, forming consensus, and communicating with each other
  6. 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. 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. 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. 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. 10. Continued…• The architecture defines what is fixed for all members of the family and what is variable
  11. 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. 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. 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. 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. 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. 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. 17. Architectural DesignProcess• 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. 18. Architectural DesignProcess• Control modelling establishes a model of the control relationships between the different parts of the system.
  19. 19. Architectural DesignProcess• Modular decomposition During this activity, the identified sub-systems are decomposed into modules.
  20. 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. 21. Any Question?? Thanks