STRUCTURED SYSTEM DESIGN By Ankit Kharwar

STRUCTURED SYSTEM DESIGN

3.1 Introduction
Design is a meaningful activity needed to develop a quality product. Design is
the only way by which we can accurately translate the customer’s requirements
into a finished software product or system. Thus design serves as the basis for
all the software engineering steps. In this chapter we will get introduced with
the systematic approach to design process. We will discuss architectural
design, user interface design and real time software design.
What is Design?
A meaningful representation of something to be built
It's a process by which requirements are translated into blueprint for constructing a software
Blueprint gives us the holistic view (entire view) of a software

Design Software
SRS Process Design

Problem Solution
Domain Domain

3
CONTI…
3.1.1 Importance of software Design
Design allows a software engineer to create a model of the system or product
that is to be built. This model is useful to access quality improvements. The
assessment of quality can be done before code generation. A large number of
users can be involved in development process if design model is prepared. In
short, design where software quality can be assured.
Software Design Process? Software design is the most creative part of the development process

Requirement Analysis Design Design

Engineering Model Engineering Model

Blue Print for Process involves

Constructing Diversification &
Convergence
Software

5
Design Models It is creative activity. It is most critical activity during system development

Analysis Models Has great impact on testing and maintenance

Scenario-based elements Design document forms reference for later phases
• Use cases - text
• Use-case diagrams
• Activity diagrams
• Swimlane diagrams

Flow-oriented elements
• Data flow diagrams
• Control-flow diagrams Procedural
• Processing narratives Design Procedural description of Software components
Behavioral elements
• State diagrams Interface Design Human computer interaction
• Sequence diagrams
Architectural Design Relationship among structural elements
Class-based elements
• Class diagrams Data/Class Design Data Structure
• Analysis packages
• CRC models
• Collabortion diagrams
6
Design Models Cont.
Data Design Architectural Design Interface Design Procedural Design

It transforms
structural
It transforms class It defines the It defines how elements of
models into design relationship software software into
class realization between major communicates with procedural
and prepares data structural systems & with description of
structure (data elements of the humans. An interface software
design) required to software implies flow of components
implement the information &
software. behavior.
7
Gentle overview of – F U R P S
“Quality is not an act, it is a habit.”— Aristotle

8
Quality attributes of software design The FURPS quality attributes

F Functionality U Usability
assessed by feature set and capabilities of the assessed by considering human factors,
program, generality of the functions & security overall aesthetics, consistency &
of overall system documentations

R Reliability P Performance
assessed by measuring frequency & severity of measured by processing speed, response
failures, accuracy of outputs, mean-time-of- time, resource consumption, throughput
failure (MTTF), ability to recover from errors and efficiency

S Supportability
Ability to extend program, adaptability, serviceability, testability, compatibility

9
CONTI…
3.2 Design Concepts
The software design concept provides a framework for implementing the right software.
Following are certain issues that considered while designing the software
1. Abstraction
2. Modularity
3. Architecture
4. Refinement
5. Pattern
6. Information hiding
7. Functional independence
8. Refactoring
9. Design Issue
Design Concepts
The beginning of wisdom for a software engineer is to recognize the difference between
getting program to work and getting it right

Fundamental Each design concept helps to answer the following questions

software design
concepts provide 1. What criteria can be used to partition software into individual
the necessary components?
framework 2. How is function or data structure detail separated from a
for conceptual representation of the software?
“getting it right.” 3. What uniform criteria define the technical quality of a software
design?

11
 3.2.1 ABSTRACTION
The abstraction means an ability to cope with the complexity. At each stage of software
design process levels of abstractions should be applied to refine the software solution.
At the higher level of abstraction, the solution should be stated in broad terms and in
the lower level more detailed description of the solution is given.
While moving through different levels of abstraction the procedural abstraction and
data abstraction are created.
The procedural abstraction gives the named sequence of instructions in the specific
function. That means the functionality of procedure is mentioned by its implementation
details are hidden. For example: Search the Record is a procedural abstraction in which
implementation details are hidden(i.e. Enter the name, compare each name of the
record against the entered one, if a match is found then declare success!! Otherwise
declare 'name not found')
In data abstraction the collection of data objects is represented. For example for the
procedure search the data abstraction will be Record. The record consists of various
attributes such as Record ID, name, address and designation.
CONTI…
Data Abstraction Procedural Abstraction
3.2.2 MODULARITY
•The software is divided into separately named and addressable components that
called as modules
•Monolithic software is hard to grasp for the software engineer, hence it has now
become a trend to divide the software into number of products. But there is co-
relation between the number of modules and overall cost of software products.
Following argument support the idea:
Suppose there are two problems A and B with varying complexity. If the complexity of
problem A is greater than complexity of B then efforts required to solve problem A is
greater than problem B. That also means, the time required by problem A to get
solved is more than that of problem B.
CONTI…
The overall complexity of two problems when they are combined is greater than sum
of complexity of the problems when considered individually. This leads to divide and
conquer strategy.
Thus dividing the software problem into manageable number of pieces leads to
concept modularity.
It is possible to conclude that if we subdivide that software indefinitely then effort
required to develop each software component will become very small. But this
conclusion is invalid because the total number of modules get increased the efforts
required for developing each module also get increased. That means cost associated
with each effort get increased.
CONTI…
The total cost required to develop such software product is shown:
CONTI…
Modularization should be such that the development can be planned easily, software increments can be
defined and delivered, changes can be more easily accommodated and long term maintenance can be
carried out effectively.
Meyer defines five criteria that enable us to evaluate a design method with respect to its ability to define
an effective modular system:
Modular decomposability : A design method provides a systematic mechanism for decomposing the
problem into sub-problems. This reduces the complexity of the problem and the modularity can be
achieved.
Modular composability : A design method enables existing design components to be assembled into a
new system.
Modular understandability : A module can be understood as a standalone unit. Then it will be easier to
build and easier to change.
Modular continuity : Small changes to the system requirements result in changes to individual modules,
rather than system-wide changes.
Modular protection : An aberrant condition occurs within a module and its effects are constrained within
the module.
CONTI…
easier to build, easier to change, easier to fix ...
3.2.3.ARCHITECTURE
Architecture means representation of overall structure of an integrated system. In
architecture various components interact and the data of the structure is used by
various components. These components are called system elements. Architecture
provides the basic framework for the software system so that important framework
activities can be conducted in systematic manner.
In architectural design various system models can be used and these are
Model Functioning
Structural model Overall architecture of the system can be represented using
this mode!
Framework model This model shows the architectural framework and
corresponding applicability.
Dynamic model This model shows the reflection of changes on the system due
to external events.
Process model The sequence of processes and their functioning is represented
in this model
Functional model
The functional hierarchy occurring in the system is represented
by this model.
CONTI…
• Structural properties. This aspect of the architectural design representation
defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one another.
For example, objects are packaged to encapsulate both data and the processing
that manipulates the data and interact via the invocation of methods
• Extra-functional properties. The architectural design description should address
how the design architecture achieves requirements for performance, capacity,
reliability, security, adaptability, and other system characteristics.
• Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of families of
similar systems. In essence, the design should have the ability to reuse
architectural building blocks.
3.2.4 REFINEMENT
•Refinement is actually a process of elaboration.
•Stepwise refinement is a top-down design strategy proposed by Nikiaus WIRTH.
•The architecture of a program is developed by successively refining levels of
procedural detail.
•The process of program refinement is analogous to the process of refinement and
partitioning that is used during requirements analysis.
•Abstraction and refinement are complementary concepts. The major difference is that
- in the abstraction low-level details are suppressed. Refinement helps the designer to
elaborate low-level details.
STEPWISE REFINEMENT
3.2.5 PATTERN
According to Brad Appleton the design pattern can be defined as - It is a named
nugget(something valuable) of insight which conveys the essence of proven solution to
a recurring problem within a certain context.
In other words, design pattern acts as a design solution for a particular problem
occurring in specific domain. Using design pattern designer can determine whether-
❑Pattern can be reusable
❑Pattern can be used for current work
❑Pattern can be used to solve similar kind of problem with different functionality.
CONTI…
Pattern name—describes the essence of the pattern in a short but expressive
name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is applicable
Structure—describes the classes that are required to implement the pattern
Participants—describes the responsibilities of the classes that are required to
implement the pattern
Collaborations—describes how the participants collaborate to carry out their
responsibilities
Consequences—describes the “design forces” that affect the pattern and the
potential trade-offs that must be considered when the pattern is implemented
Related patterns—cross-references related design patterns
3.2.6 INFORMATION HIDING
It is the characteristics of module in which major design decisions can be hidden from
all others. Such hiding is necessary because information of one module cannot be
accessed by another module. The advantage of information hiding is that
modifications during testing and maintenance can be made independently without
affecting the functionality of other modules.
CONTI…
CONTI…
Why Information Hiding?
• Reduces the likelihood of “side effects”
• Limits the global impact of local design decisions
• Emphasizes communication through controlled interfaces
• Discourages the use of global data
• Leads to encapsulation—an attribute of high quality design
• Results in higher quality software
3.3 MODULAR DESIGN
Modular design reduces complexity and helps in easier implementation. The parallel
development of different parts of the system is possible due to modular design.
What is the benefit of modular design?
Changes made during testing and maintenance becomes manageable and they do
not affect other modules.
Various quality parameters for effective modular design are
1) Functional independence
2) Cohesion
3) Coupling
Cohesion & Coupling
A good software design implies clean The primary characteristics of
decomposition of the problem into neat module decomposition are
modules, and the neat arrangement of high cohesion and low
these modules in a hierarchy. coupling.

A cohesive module A Coupling is an

performs a single indication of the
task, requiring little relative
interaction with other interdependence
components. among modules.

29
3.3.1 FUNCTIONAL INDEPENDENCE
The functional independence can be achieved by developing the functional modules
with single-minded approach.
By using functional independence functions may be compartmentalized and interfaces
are simplified.
Independent modules are easier to maintain with reduced error propagation.
Functional independence is a key to good design and design is the key to software
quality.
The major benefit of functional independence is in achieving effective modularity.
Cohesion
 Cohesion is an indication of the relative functional Classification of Cohesion
strength of a module.
 A cohesive module performs a single task, requiring
little interaction with other components. Coincidental Low

Classification of Cohesion
 Stated simply, a cohesive module should (ideally) do Logical
just one thing.
Temporal
 A module having high cohesion and low coupling is
said to be functionally independent of other modules. Procedural
 By the term functional independence, we mean that a Communicational
cohesive module performs a single task or function.
Sequential
Functional High

31
Classification of Cohesion cont.
Coincidental cohesion Logical cohesion
 A module is said to have coincidental cohesion,  A module is said to be logically
if it performs a set of tasks that relate to each cohesive, if all elements of the
other very loosely. module perform similar operations.
 In this case, the module contains a random  For Ex., error handling, data input,
collection of functions. data output, etc.
 It is likely that the functions have been put in the  An example of logical cohesion is the
module out of pure coincidence without any case where a set of print functions
thought or design. generating different output reports
 For Ex., in a transaction processing system are arranged into a single module In
(TPS), the get-input, print-error, and summarize- this case, the module contains a
members functions are grouped into one module random collection of functions.
 At the outer layer, components service user
interface operations.
32
Classification of Cohesion cont.
Temporal cohesion Procedural cohesion
 When a module contains functions that are  If the set of functions of the module
related by the fact that all the functions must be are all part of a procedure (algorithm)
executed in the same time span. in which certain sequence of steps
 For Ex., the set of functions responsible for have to be carried out for achieving an
initialization, start-up, shutdown of some objective
process, etc.  For Ex., the algorithm for decoding a
message.
Communicational cohesion
 If all functions of the module refer to the same data structure
 For Ex., the set of functions defined on an array or a stack.

33
Classification of Cohesion cont.
Sequential cohesion
 If the elements of a module form the parts of sequence, where the output from one element
of the sequence is input to the next.
 For Ex., In a Transaction Processing System, the get-input, validate-input, sort-input functions
are grouped into one module.

Functional cohesion
 If different elements of a module cooperate to achieve a single function.
 For Ex., A module containing all the functions required to manage employees’ pay-roll
exhibits functional cohesion.

34
Coupling
 Coupling between two modules is a measure of the Classification of Coupling
degree of interdependence or interaction between the
two modules.
 A module having high cohesion and low coupling is Data Low

Classification of Coupling
said to be functionally independent of other modules.
 If two modules interchange large amounts of data, Stamp
then they are highly interdependent.
 The degree of coupling between two modules depends Control
on their interface complexity.
 The interface complexity is basically determined by Common
the number of types of parameters that are
interchanged while invoking the functions of the Content High
module.

35
Classification of Coupling Cont.
Data coupling Stamp coupling
 Two modules are data coupled, if they  This is a special case (or extension)
communicate through a parameter. of data coupling
 An example is an elementary (primal) data item  Two modules (``A'' and ``B'') exhibit
passed as a parameter between two modules, stamp coupling if one passes directly
e.g. an integer, a float, a character, etc. to the other a composite data item -
such as a record (or structure), array,
or (pointer to) a list or tree.
Control coupling  This occurs when ClassB is declared
 If data from one module is used to direct the as a type for an argument of an
order of instructions execution in another. operation of ClassA
 An example of control coupling is a flag set in
one module and tested in another module

36
Classification of Coupling Cont.
Common coupling
 If data from one module is used to direct the order of instructions execution in another.
 An example of control coupling is a flag set in one module and tested in another module.

Content coupling
 Content coupling occurs when one component secretly modifies data that is internal to
another component.
 This violets information hiding – a basic design concept
 Content coupling exists between two modules, if they share code.

37
 CONTI…

What's How big

COHESION - the degree to which a inside?? is it??
module performs one and only one
function.

COUPLING - the degree to which a

module is "connected" to other MODULE
modules in the system.
3.3.4 FAN-OUT
Fan-out is measure of the number of immediate subordinates to a module. The fan-
out should be within some limit in design. If fan-out is very high then it indicates that a
single module is controlling many other modules. Preferably limit fan-out to no more
than seven.
3.3.5 FAN-IN
Fan-in indicates how many modules directly control a given module. Modules with fan-
in must have good cohesion. Each interface to module must have same number and
types of parameters.
3.3.6 REFACTORING
Refactoring is necessary for simplifying the design without changing the function or behaviour.
Fowler has defined refactoring as the process of changing a software system in such a way that
the external behavior of the design do not get changed, however the internal structure gets
improved.
Benefits of refactoring are -
❑The redundancy can be achieved.
❑Inefficient algorithms can be eliminated or can be replaced by efficient one.
❑Poorly constructed or inaccurate data structures can be removed or replaced.
❑Other design failures can be rectified.
❑The decision of refactoring particular component is taken by the designer of the software
system.
CONTI…
◼ Fowler [FOW99] defines refactoring in the following manner:
◼ "Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code [design] yet improves its
internal structure.”
◼ When software is re-factored, the existing design is examined for
◼ redundancy
◼ unused design elements
◼ inefficient or unnecessary algorithms
◼ poorly constructed or inappropriate data structures,
◼ or any other design failure that can be corrected to yield a better design.
3.4 DESIGN MODELS
CONTI…
The design model is represented as pyramid. The pyramid is a stable object
Representing design model in this way means that the software design should be
stable.
The design model has broad foundation of data design, stable mid-region with
architectural and interface design and the sharp point to for component level design.
The design model represents that the software which we create should be stable such
that any changes should not make it collapsed. And from such a stable design a high
quality software should be generated.
CONTI…
hig h

a n a ly sis m o d e l

class diagr ams

analysis packages
use- cases - t ext class diagr ams
Requirement s:
CRC models use- case diagr ams const raint s
analysis packages
collabor at ion diagr ams
act ivit y diagr ams CRC models int eroperabilit y
dat a f low diagr ams sw im lane diagr ams collabor at ion diagr ams t arget s and
cont r ol- f low diagr ams collabor at ion diagr ams dat a f low diagr ams
pr ocessing nar r at ives st at e diagr ams cont r ol- f low diagr ams
conf igurat ion
sequence diagr ams pr ocessing nar r at ives
st at e diagr ams
sequence diagr ams

design class r ealizat ions

subsyst ems
collabor at ion diagr ams t echnical int er f ace component diagr ams
design class r ealizat ions
design design classes
subsyst ems
Navigat ion design act ivit y diagr ams
collabor at ion diagr ams
GUI design sequence diagr ams
component diagr ams
d e sig n m o d e l design classes
r ef inement s t o: act ivit y diagr ams
r ef inement s t o: sequence diagr ams
component diagr ams
design class r ealizat ions design classes
subsyst ems act ivit y diagr ams
lo w collabor at ion diagr ams sequence diagr ams deployment diagr ams

archit ect ure int erf ace co m po nent -level deplo ym ent -level
elem ent s elem ent s elem ent s elem ent s

p ro cess d imensio n
CONTI…
◼ Data elements
◼ Data model --> data structures
◼ Data model --> database architecture
◼ Architectural elements “similar to the floor plan of a house”
◼ “You can use an eraser on the drafting table or a sledge hammer on the
construction site.”
◼ Application domain
◼ Analysis classes, their relationships, collaborations and behaviors are
transformed into design realizations
◼ Patterns and “styles”
 MobilePhone

WirelessPDA

CONTI…
Cont rolPanel
◼ Interface elements “The way in which
LCDdisplay
utilities connections come into the LEDindicat or s
keyPadChar act er ist ics K ey Pad
house and are distributed among the speaker

rooms” wir elessInt er f ace

r eadKeySt r oke( )
◼ the user interface (UI) decodeKey ( )
displaySt at us( )

◼ external interfaces to other light LEDs( )

sendCont r olMsg( )

systems, devices, networks or < < int erf ac e> >

K ey Pad
other producers or consumers of
information r eadKeyst r oke( )
decodeKey( )

internal interfaces between various

design components
Figure 9 . 6 UML int erf ac e represent at ion f or Co n t r o l P a n e l
CONTI…
◼ Component elements
It is equivalent to a set of detailed drawings and specs for each room in a house.
The component-level design for software fully describes the internal detail of each
software component.

◼ Deployment elements
Indicates how software functionally and subsystem terms will be allocated within
the physical computing environment that will support the software.
 3.4.1 Design Principles
Design process should not suffer from “tunnel vision” Design should be structured to degrade
gently, even when abnormal data, events, or
Design should be traceable to the analysis model operating conditions are encountered
Design should not reinvent the wheel Design is not coding, coding is not design
Design should “minimize the intellectual distance” between
Design should be assessed for quality as it
the software and the real world problem
is being created, not after the fact
Design should exhibit (present) uniformity and integration
Design should be reviewed to minimize
Design should be structured to accommodate change conceptual (semantic) errors
Tunnel Vision

Reinvent the Wheel

Coding Design
50
Design Process Rough View
Informal Design Outline Informal Design More formal Design Finished Design

Design Process
Requirements Specification
Design Activities
Architectural Abstract Interface Component Data Structure Algorithm
Design Specification Design Design Design Design

System Software Interface Component Data Structure Algorithm

Architecture Specification Specification Specification Specification Specification

Design Product
51
Software design work products Characteristics of good Design
For a design to be easily implemented in a conventional  The design must implement all explicit
programming language, the following items must be requirements available in requirement
designed during the design phase. model
Different modules required to implement the design  The design must accommodate all implicit
solution. requirements given by stakeholders
Control relationship among the identified modules.
 The design must be readable &
The relationship is also known as the call relationship
understandable
or invocation relationship among modules.  The good design should provide complete
picture of the software, addressing the
Interface among different modules. The interface
data, functional and behavioral domains.
among different modules identifies the exact data
items exchanged among the modules.
Algorithms required to implement each individual
module.
Data structures of the individual modules.
52
Architectural Design
Software Architecture & Design
 Large systems are decomposed into subsystems
 Sub-systems provide related services
 Initial design process includes
 Identifying sub-systems
 Establishing a framework for sub-system control and communication

Why to document the Architecture?

 Stakeholder Communication: High-level presentation of system
 System Analysis: Big effect on performance, reliability,
maintainability and other –ilities (Usability, Maintainability,
Scalability, Reliability, Extensibility, Security, Portability)
 Large-scale Reuse: Similar requirements similar architecture

55
Software Architecture & Design
Architectural design represents the structure of data and
program components

It considers
Architectural style that the system will take
Structure and properties of the components that constitute the system

Interrelationships that occur among all architectural components of a system Marry in haste
repent at leisure
 Representations of software architecture are an enabler
for communication between all parties (stakeholders).
True for Software
 Architecture “constitutes a relatively small, intellectually Architecture Design
graspable model of how the system is structured and how
its components work together”

56
3.6 DATA DESIGN
Data design is basically the model of data that is represented at the high level of
abstraction.
The data design is then progressively refined to create implementation specific
representations.
Various elements of data design are
o Data object - The data objects are identified and relationship among various data
objects can be represented using entity relationship diagrams or data dictionaries.
o Databases - Using software design model, the data models are translated into
data structures and databases at the application level.
o Data warehouses - At the business level useful information is identified from
various databases and the data warehouses are created. For extracting or
navigating the useful business information stored in the huge data warehouse then
data mining techniques are applied.
3.6.1 DATA DESIGN AT THE ARCHITECTURAL
LEVEL
▪The challenge is extract useful information from the data environment, particularly when the
information desired is cross-functional.
▪To solve this challenge, the business IT community has developed data mining techniques, also
called knowledge discovery in databases (KDD), that navigate through existing databases in an
attempt to extract appropriate business-level information.
▪However, the existence of multiple databases, their different structures, the degree of detail
contained with the databases, and many other factors make data mining difficult within an
existing database environment.
▪An alternative solution, called a data warehouse, adds on additional layer to the data
architecture.
▪A data warehouse is a separate data environment that is not directly integrated with day-to-
day applications that encompasses all data used by a business.
▪In a sense, a data warehouse is a large, independent database that has access to the data that
are stored in databases that serve as the set of applications required by a business.
3.6.2 DATA DESIGN AT THE COMPONENT LEVEL
At the component level, data design focuses on specific data structures required to
realize the data objects to be manipulated by a component.

◼ refine data objects and develop a set of data abstractions

◼ implement data object attributes as one or more data structures
◼ review data structures to ensure that appropriate relationships have been
established
◼ simplify data structures as required
SET OF PRINCIPLES FOR DATA SPECIFICATION:
1. Apply systematic analysis on data
Represent data objects, relationships among them and data flow along with the contents.
2. Identify data structures and related operations
For the design of efficient data structures all the operations that will be performed on it should
be considered.
3. Establish data dictionary
The data dictionary explicitly represents various data objects, relationships among them and
the constraints on the elements of data structures.
4. Defer the low-level design decisions until late in the design process
Major structural attributes are designed first to establish an architecture of data. And then
low-level design attributes are established.
CONTI…
5. Use information hiding in the design of data structures
The use of information hiding helps in improving quality of software design. It also
helps in separating the logical and physical views.
6. Apply a library of useful data structures and operations
The data structures can be designed for reusability. A use of library of data structure
templates (called as abstract data types) reduces the specification and design efforts
for data.
7. Use a software design and programming language to support data specification and
abstraction
The implementation of data structures can be done by effective software design
and by choosing suitable programming language.
3.7 ARCHITECTURAL STYLES AND PATTERNS
The architectural model or style is a pattern for creating the system architecture for given
problem. However, most of the large systems are heterogeneous and do not follow single
architectural style.
System categories define the architectural style.
1. Components : They perform a function.
For example: Database, simple computational modules, clients, servers and filters.
2. Connectors : Enable communications. They define how the components communicate, co-
ordinate and co-operate.
For example, Call, event broadcasting, pipes.
3. Constraints : Define how the system can be integrated.
4. Semantic models : Specify how to determine a system's overall properties from the
properties of its parts.
CONTI…
The commonly used architectural styles are
1. Data centered architectures
2. Data flow architectures
3. Call and return architectures
4. Object oriented architectures
5. Layered architectures.
Data-centered architecture style
 A data store (Ex., a file or database)
resides at the center of this
architecture and is accessed frequently
by other components.
 Client software accesses a central
repository.
 In some cases the data repository is
passive
That is, client software accesses the data
independent of any changes to the data or the
actions of other client software.

64
Data-flow architectures
 This architecture is applied when input data are
to be transformed.
 A set of components (called filters) connected
by pipes that transmit data from one component
to the next.
 Each filter works independently of those
components upstream and downstream, is
designed to
 expect data input of a certain form, and
 produces data output (to the next filter) of a specified
form.

65
Call and return architecture
 This architectural style enables a software designer
(system architect) to achieve a program structure
that is relatively easy to modify and scale.
 A number of sub styles exist within this category as
below.
1. Main program/subprogram architectures
▪ This classic program structure decomposes function into a
control hierarchy where a “main” program invokes a
number of program components, which in turn may invoke
still other components.
2. Remote procedure call architectures
▪ The components of a main program/subprogram
architecture are distributed across multiple computers on a
network.

66
3.7.1.4 OBJECT ORIENTED ARCHITECTURE
In this architecture the system is decomposed into number of
interacting objects.
These objects encapsulate data and the corresponding
operations that must be applied to manipulate the data.
The object oriented decomposition is concerned with
identifying objects classes, their attributes and the
corresponding operations. There is some control models
used to co-ordinate the object operations.
Layered architecture
 A number of different layers are defined, each
accomplishing operations that progressively become
closer to the machine instruction set.
 At the outer layer, components service user interface
operations.
 At the inner layer, components perform operating
system interfacing.
 Intermediate layers provide utility services and
application software functions.

68
3.7.2 ARCHITECTURAL PATTERNS
A S/W architecture may have a number of architectural patterns that address issues such as
concurrency, persistence, and distribution.
◼ Concurrency—applications must handle multiple tasks in a manner that simulates
parallelism
◼ operating system process management pattern
◼ task scheduler pattern

◼ Persistence—Data persists if it survives past the execution of the process that created it.
Persistent data are stored in a database or file and may be read and modified by other
processes at a later time.
Two patterns are common:
◼ a database management system pattern that applies the storage and retrieval capability of
a DBMS to the application architecture
◼ an application level persistence pattern that builds persistence features into the application
architecture
CONTI…
◼ Distribution— the manner in which systems or components within systems communicates
with one another in a distributed environment, and the nature of the communication that
occurs.
◼ A broker acts as a ‘middle-man’ between the client component and a server component.
3.8 ALTERNATIVE ARCHITECTURAL DESIGNS
There are one alternative approaches used for architectural design –
1. To apply iterative method to access design trade-offs
3.8.1 ARCHITECTURE TRADE-OFF ANALYSIS
METHOD
Various design analysis activities:
1. Collect Scenarios –
Use cases are developed for representing system for user’s point of view. Hence a set
of use cases help in collecting scenarios.

2. Elicit requirements, constraints, and environment description –

This information is obtained during requirement analysis. Customer, user and stake-
holders must specify the requirement correctly.
3. Describe architectural style chosen for representing scenarios and requirements
The architecture style should describe various views about system. Those views are -
i) Model View – working of components and information hiding can be described
ii) Process View – helps to analyse the system performance
Iii) Data flow view – functional requirement analysis can be made using this analysis

4. Evaluate quality attributes individually –

Various quality attributes that can be evaluated are
Reliability, performance, security, flexibility, maintainability, testability, portability,
inter-operatability, reusability
5. Identify sensitivity of quality attribute –
For checking sensitivity of these attribute, small changes are made in architecture and
observe the effect of these changes on quality attributes. If any attribute got
affected by these changes then that attribute is considered as sensitive point.

6. Criticize quality attribute –

By making small changes in architecture, sensitive points are obtained. Now,
architecture trade-off points can be obtained by criticizing these quality factors.

The above 6 iteration represent one complete iteration. Based on result of 5 and 6,
some architecture alternatives are eliminated and some modifications are made in
architecture. Then these steps are again reapplied.
3.9 WHAT IS A COMPONENT?
This section defines the term component and discusses the differences between
object-oriented, traditional, and process related views of component-level design.
Object Management Group OMG UML defines a component as “… a modular,
deployable, and replaceable part of a system that encapsulates implementation and
exposes a set of interfaces.”
3.9.1 AN OBJECT ORIENTED VIEW
OO view: a component contains a set of collaborating classes.

Each class within a component has been fully elaborated to include all attributes and
operations that are relevant to its implementation. As part of the design elaboration,
all interfaces (messages) that enable the classes to communicate and collaborate with
other design classes must also be defined. To accomplish this, the designer begins
with the analysis model and elaborates analysis classes (for components that relate
to the problem domain) and infrastructure classes (or components that provide
support services for the problem domain).
3.9.2 THE CONVENTIONAL VIEW
Conventional view: a component is a functional element of a program that
incorporates processing logic, the internal data structures that are required to
implement the processing logic, and an interface that enables the component to be
invoked and data to be passed to it.
A conventional component, also called a module, resides within the s/w architecture
and serves one of three important roles as:
1. A control component that coordinates the invocation of all other problem domain
components,
2. A problem domain component that implements a complete or partial function that is
required by the customer,
3. An infrastructure component that is responsible for functions that support the
processing required in the problem domain.