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