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