Software Architecture & Design Syed Salman Qadri Asisstant Professor (CS) The Islamia University of Bahawalpur
Why Architecture is Important Three Main Reason of Importance• Mutual communication• Early design decisions.• Reusability of a system.
Why Software Architectureimportant Software Architecture Reusability of Mutual Design Decision system communication
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
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
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
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..
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.
Continued…• The architecture defines what is fixed for all members of the family and what is variable
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
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
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.
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
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
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
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.
Architectural DesignProcess• Control modelling establishes a model of the control relationships between the different parts of the system.
Architectural DesignProcess• Modular decomposition During this activity, the identified sub-systems are decomposed into modules.
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