The document discusses various concepts related to software architecture design. It describes that architecture design identifies subsystems and their interactions early in the design process. It involves decomposing a system, determining component responsibilities, and how components communicate and work together. The document outlines different architectural styles like shared repository, client-server, and layered models. It also discusses design decisions, modular decomposition approaches like function-oriented and object-oriented, and control styles like centralized and event-based control.

1. Architecture Design
Chapter 3

2. Software Design
• Design activity begins when SRS document for software is available
• Design is the first step towards solution domain from problem domain
• Design can accurately translate customer’s requirement into a finished
software product
• Software Design is the practice of taking a specification of externally
observable behavior and adding details needed for actual computer system
implementation, including human interaction, task management and data
management skills.

3. Importance of Design
• System model
• Help you understand requirement better
• Prevents redundancy and increases reusability
• Points out the risk of which you have no idea

4. Software Design Framework

5. Software Architecture
• The design process for identifying the sub-systems making up a system and
the framework for sub-system control and communication is architectural
design.
• The output of this design process is a description of the software
architecture.
• Software architecture is he process of defining software methods, functions,
objects and the overall structure and interaction of your code so that the
resulting functionality will satisfy the user’s requirements

6. Architecture Design
• An early stage of the system design process.
• Identifies the sub-system from large systems
• Concerned with understanding how a system should be organized
• It involves identifying major system components and their communications.
• Represents the link between specification and design processes.
• Often carried out in parallel with some specification activities.

7. Components of Architecture Design
1. Architectural design decisions
2. System organisation
3. Decomposition styles
4. Control styles

8. Architecture Design Decision
• Is there a generic application architecture that can be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?

9. System Organization
• Reflects the basic strategy that is used to structure a system.
• Three organizational styles are widely used:
• A shared data repository style;
• A shared services and servers style;
• An abstract machine or layered style.

10. The Repository Model
• Sub-systems making up a system must exchange information so that they work
together effectively.
• This may be done in two ways:
• Shared data is held in a central database or repository and may be accessed by all sub-
systems;
• Each sub-system maintains its own database and passes data explicitly to other sub-systems.
• When large amounts of data are to be shared, the repository model of sharing is
most commonly used.
• Suited for applications where data is generated by one sub-system and used by
another.

11. • The components do not interact on
their own, only through the central
reposition
• All the components in the system
compromise for the exchange of
data
• New components are difficult to
integrate
Project Management Software

12. Application
• When large volume of information is generated and has to be stored for
long time
• When data security is of higher importance
• When the control of the system needs to be central

13. Advantages
• Independent of component as they
need not know their existence
• Easy to accommodate change in a
component
• All information are centrally managed
and easily available
• Sub-systems need not be concerned
with how data is produced Centralised
management e.g. backup, security, etc.
Disadvantages
• Any problem in the central reposition
affect whole system
• Communication issues are likely to
arise since compromise in inevitable
• Process distribution is a challenge
• Data evolution is difficult and
expensive;

14. Client-Server Model
• A system model where the system is organized as a set of services and associated
servers and clients that access & use the services.
• i.e. Distributed system model which shows how data and processing is distributed
across a range of components.
• The major components of this model are:
1. A set of servers that offer services to other subsystems such as printing, data
management, etc.
2. A set of clients that call on services offered by the servers.
3. A network that allows clients to access these services.

15. • Mainly, client-server architecture considered as distributed system
• But the logical model can be implemented on single computer
• It emphasizes on separation and independence since change in server or
client do not affect each other
• Application:
• When same service has to be provide to different clients in different location

16. • Clients may have to know the names
of the available servers & the services
they provide
• However, servers need not know either
the identity of clients and their
number.
• Clients accesses the service from
remote procedural call using request
reply protocol such as http.
Youtube Architecture

17. Advantages
• Distribution of data is straightforward;
• Makes effective use of networked
systems. May require cheaper
hardware;
• Easy to add new servers or upgrade
existing servers.
Disadvantages
• No shared data model so sub-systems
use different data organisation. Data
interchange may be inefficient;
• Redundant management in each
server;
• No central register of names and
services - it may be hard to find out
what servers and services are available.

18. Abstract Machine (Layered) Model
• Used to model the interfacing of sub-systems.
• Organises the system into a set of layers (or abstract machines) each of which
provide a set of services.
• Each layer can be thought of as an abstract machine whose machine language is
defined by the services provided by the layer beneath it.
• This language used is to implement the next level of abstract machine.
• Supports the incremental development of sub-systems in different layers.

19. • i.e. it supports development of
layers separately and independently
• When a layer interface changes,
only the adjacent layer is affected.
• The components are changeable
and portable since developed in
independent approach

20. Application
• When tier needs to be created to service the model.
• When the key factor to consider is security.
• When information has to be passes over a network.

21. Advantages
• It allows the replacement of a entire
faulty layer.
• It provides robustness and stability
• Independent portable of components
is possible.
• The model is flexible, scalable and
maintainable
Disadvantages
• It is practically difficult to achieve
separation between layers.
• Performance can be of issue.
• Data overhead and processing delay
due to multiple layers
• Risk of data being lost in upper layers

22. Modular Decomposition
• Decomposition of sub-systems into modules or process modules is called
modular decomposition.
• There are two main strategies that one can use while decomposing subsystem
into modules.
1. Function oriented Pipelining
• A Function oriented pipelining (or data-flow model) where the system is decomposed into
functional modules which transform inputs to outputs.
2. Object Oriented Decomposition
• An Object oriented model where the system is decomposed into interacting object

23. Differences-Sub-system and Modules
• A sub-system is a system in its own right whose operation is independent of
the services provided by other sub-systems.
• A module is a system component that provides services to other
components but would not normally be considered as a separate system.
• To produce its output it requires other’s input

24. Function Oriented Pipelining
• System is decomposed into set of interacting units which has clearly defined
function.
• Functional transformations process their inputs to produce outputs.
• May be referred to as a pipe and filter model (as in UNIX shell).
• When transformations are sequential, this is a batch sequential model which is
extensively used in data processing systems.
• It only views system as black-box that performs high level function.
• It follows top down approach mainly used for computation sensitive application
• Not really suitable for interactive systems.

25. Invoice Processing System
• An Invoice processing system has issued
invoices to customers
• Once a week, payments that have been made
reconciled with the invoices
• For invoices that have been paid, a receipt is
issued.
• For invoices that have not been paid within the
allowed payment time, reminder is issued.
• This model is only the part of invoice
processing system

26. Advantages
• Supports transformation reuse.
• Intuitive organization for stakeholder communication.
• Easy to add new transformations.
• Relatively simple to implement as either a concurrent or sequential system.
• However, requires a common format for data transfer along the pipeline and
difficult to support event-based interaction.

27. Object Oriented Decomposition
• Structure the system into a set of loosely coupled objects with well-defined
interfaces.
• Object-oriented decomposition is concerned with identifying object classes,
their attributes and operations.
• Objects are defined which collaborate to fulfill the requirements.
• When implemented, objects are created from these classes and some control
model used to coordinate object operations.

28. Invoice Processing System
• This system can issue invoices to customers
• receive payments & issue receipts for these
payments, reminders for unpaid invoices
• Object classes have names and a set of
associated attributes
• Operations, if any are defined in the lower part
of the rectangle representing the object.
• Dashed arrows indicate that an object uses the
attributes or services provided by another
object.

29. Advantages
• Objects are loosely coupled so their implementation can be modified without
affecting other objects.
• The objects may reflect real-world entities because of which objects can be
reused.
• OO implementation languages are widely used.
• However, object interface changes may cause problems and complex
entities(abstract) may be hard to represent as objects.

30. Control Styles
• Control styles offer a mechanism to regulate the components or routine in the software
• It allows one function to access other sub-function to carry out the task
• Is concerned with the control flow between sub-systems. Distinct from the system
decomposition model.
1. Centralised control
One sub-system has overall responsibility for control and starts and stops other sub-
systems.
2. Event-based control
Each sub-system can respond to externally generated events from other sub-systems or
the system’s environment.

31. Centralized Control
• Here, one subsystem is designated as the system controller & has
responsibility for managing the execution of other sub systems.
• Centralized control models fall into two classes, depending on weather the
controlled sub-system execute sequentially or in parallel
1. Call return model:
Here the control is passed down the hierarchy and the result is passed to the calling
function or object
2. Manager model:
Here one component controls the execution of other components.

32. Call Return Model
• Top-down subroutine model where control
starts at the top of a subroutine hierarchy and
moves downwards. Applicable to sequential
systems.
• This model may be used at the module level to
control functions and objects.
• Strength-It is relatively simple to analyze
control flows & work out how the system will
respond to particular inputs.
• Weakness- exceptions to normal operation are
awkward to handle.

33. • In fig. the main program call routines 1,2 &3; Routine 1 can call Routine 1.1 &
1.2;Routine 3 can call Routines 3.1 & 3.2; & so on.
• Here, control passes from a higher-level routine in the hierarchy to the lower level
• Then it returns to a point where the routine was called
• The currently executing subroutine has responsibility to control & can either call
other routines or return control to its parents.
• It is poor programming style to return to some other point in the program.

34. Manager Model
• One system component controls the
stopping, starting and coordination of
other system processes.
• Can be implemented in sequential systems
as a case statement.
• Applicable to concurrent systems.

35. • In fig., shows the centralized management model of control for a concurrent
system.
• This model is often used in “soft” real-time systems which do not have very tight
time constraints.
• The central controller manages the execution of set of processes associated with
sensors and actuators
• The system controller decides when processes should be started or stop depending
on system state variables.
• It checks whether other processes have produced information to be processed or
pass the information to them for processing.

36. Event Driven Control
• Event driven control models are driven by externally generated events where
the timing of the event is outside the control of the process that handles
that event.
• Other event driven models include spreadsheets and production systems.
• Two principal event-driven models
1. Broadcast models. An event is broadcast to all sub-systems. Any sub-system which
can handle the event may do so;
2. Interrupt-driven models. Used in real-time systems where interrupts are detected by
an interrupt handler and passed to some other component for processing.

37. Broadcast Model
• Here an event is broadcasted to all sub-
system
• Any sub-system that has been programmed
to handle can respond to it.
• Here, a sub-system has to register an interest
in specific events.
• When these events occur, control is
transferred to that sub-system which can
handle it.
• Sub-system decide which event they require,
& the event of interest to them.

38. Interrupt Driven Model
• Used in real-time systems where fast response to an event is essential.
• There are known interrupt types with a handler defined for each type.
• Each type is associated with a memory location and a hardware switch causes
transfer to its handler.
• Allows fast response but complex to program and difficult to validate.

39. Interrupt Driven Model
• In fig., there are known number of interrupt
types with the handler defined for each type.
• Each interrupt is associated with a memory
location where its handler’s address is stored.
• When an interrupt of a particular type is
received, h/w switch causes control to be
transferred immediately to its handler.
• This interrupt handler may then start or stop
other processes in response to the event
signaled by the interrupt.

40. Reference Architecture
• Distributed Object Architecture
• Multi-processor Architecture
• Inter-organizational Distributed Computing