Architectural Design

1
• The software architecture of a program or computing
system is the structure or structures of the system, which
comprise software components, the externally visible
properties of those components, and the relationships
among them.

• IEEE defines architectural design as “the process of

defining a collection of hardware and software
components and their interfaces to establish the
framework for the development of a computer system.”

2
 Why Architecture?
The architecture is not the operational software.
Rather, it is a representation that enables a software
engineer to:
(1) analyze the effectiveness of the design in
meeting its stated requirements,
(2) consider architectural alternatives at a stage
when making design changes is still relatively easy,
and
(3) reduce the risks associated with the
construction of the software.

3
 Why is Architecture Important?
• Representations of software architecture are an
enabler for communication between all parties
(stakeholders) interested in the development of a
computer-based system.
• The architecture highlights early design decisions that
will have a profound impact on all software engineering
work that follows and, as important, on the ultimate
success of the system as an operational entity.

• Architecture “constitutes a relatively small,

intellectually graspable mode of how the system is
structured and how its components work together”.
4
 Architectural Styles
Each style describes a system category that
encompasses:
(1) a set of components (e.g., a database,
computational modules) that perform a function
required by a system,
(2) a set of connectors that enable “communication,
coordination and cooperation” among components,
(3) constraints that define how components can be
integrated to form the system, and
(4) semantic models that enable a designer to
understand the overall properties of a system by
analyzing the known properties of its constituent
parts. 5
 Types of Architecture
• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Object-oriented architectures
• Layered architectures

6
 Data-Centered Architecture

• Use of Blackboard mechanism

• Promotes integrability
7
 Data-Centered Architecture
• A data store (e.g., a file or database) resides at the
center of this architecture and is accessed frequently
by other components that update, add, delete, or
otherwise modify data within the store.
• In some cases, the data repository is passive. i.e , client
software accesses the data independent of any changes
to the data or the actions of other client software.
• another approach transforms the repository into a
“blackboard” that sends notifications to client software
when data of interest to the client changes.
 Data-Centered Architecture
• Data-centered architectures promote
integrability – existing components can be
changed and new client components added to
the architecture without concern about other
clients
• data can be passed among clients using the
blackboard mechanism
• Client components independently execute
processes.
Data Flow Architecture

10
 Data Flow Architecture
• This architecture is applied when input data are to
be transformed through a series of computational
or manipulative components into output data.

• A pipe-and-filter pattern has a set of components,

called filters, connected by pipes that transmit
data from one component to the next.
 Data Flow Architecture
• 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.
• the filter does not require knowledge of the
workings of its neighboring filters.
Call and Return Architecture

13
Structure of Call and Return
Architecture

14
 Call and Return Architecture
• enables to achieve a program structure that is
relatively easy to modify and scale.
• Two substyles that exist within this category:
1. Main program/subprogram architectures.- classic
program structure decomposes function into a
control hierarchy where a “main” program invokes
several program components, which in turn may
invoke still other components.
2. Remote procedure call architectures- components of
a main program/subprogram architecture are
distributed across multiple computers on a network.
Main program/
subprogram
architecture

16
Object-oriented architectures

• The components of a system encapsulate data

and the operations that must be applied to
manipulate the data.
• Communication and coordination between
components are accomplished via message
passing.
• UML communication diagram that shows the
message passing for the login portion of a
system implemented using an object-oriented
architecture.

17
UML communication diagram
Layered Architecture

19
 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.
 Model-View-Controller (MVC)
architecture
• one of a number of suggested infrastructure
models often used in Web development.
• The model contains all application-specific content
and processing logic.
• The view contains all interface-specific functions
and enables the presentation of content and
processing logic required by the end user.
• The controller manages access to the model and
the view and coordinates the flow of data between
them.
The MVC architecture
 MVC architecture
• user requests are handled by the controller.
• The controller also selects the view object that is applicable
based on the user request.
• Once the type of request is determined, a behavior request is
transmitted to the model, which implements the functionality
or retrieves the content required to accommodate the request.
• The model object can access data stored in a corporate
database, as part of a local data store, or as a collection of
independent files.
• The data developed by the model must be formatted and
organized by the appropriate view object and then transmitted
from the application server back to the client-based browser for
display on the customer’s machine.
 Architectural Design
• The software must be placed into context
– the design should define the external entities (other
systems, devices, people) that the software interacts
with and the nature of the interaction
• A set of architectural archetypes should be
identified
– An archetype is an abstraction (similar to a class)
that represents one element of system behavior
• The designer specifies the structure of the
system by defining and refining software
components that implement each archetype 24
 Tasks of Architectural Design
• 1. Representing the System in Context
• 2. Defining Archetypes
• 3. Refining the Architecture into
Components
• 4. Describing Instantiations of the System

25
 1. Representing the System in Context

• At the architectural design level, a software architect uses an

architectural context diagram (ACD) to model the manner in
which software interacts with entities external to its boundaries.

• The generic structure of the architectural context diagram

consists
– Superordinate systems
– Subordinate systems
– Peer-level systems
– Actors

26
Architectural Context (Generic framework)

27
 Architectural Context –
Safe home security system

28
 2. Defining Archetypes

An archetype is a class or
pattern that represents a
core abstraction that is
critical to the design of an
architecture for the target
system.

Fig. UML relationships for SafeHome security

function archetypes

29
• Node. Represents a cohesive collection of input and output
elements of the home security function. For example, a
node might be composed of (1) various sensors and (2) a
variety of alarm (output) indicators.

• Detector. An abstraction that encompasses all sensing

equipment that feeds information into the target system.

• Indicator. An abstraction that represents all mechanisms

(e.g., alarm siren, flashing lights, bell) for indicating that an
alarm condition is occurring.

• Controller. An abstraction that depicts the mechanism that

allows the arming or disarming of a node. If controllers
reside on a network, they have the ability to communicate
with one another
30
3. Refining the Architecture into Components

Fig. Overall architectural structure for SafeHome with top-level components

31
• represent entities within the application (business)
domain that must be addressed within the
software architecture.
• Hence, the application domain is one source for
the derivation and refinement of components.
• Another source is the infrastructure domain.
• Continuing the SafeHome home security function example, you
might define the set of top-level components that address the
following functionality:
• External communication management —coordinates
communication of the security function with external entities such
as other Internet-based systems and external alarm notification.

• Control panel processing —manages all control panel

functionality.

• Detector management —coordinates access to all detectors

attached to the system.

• Alarm processing —verifies and acts on all alarm conditions

33
4. Describing Instantiations of the System

Fig. An instantiation of the security function with component elaboration 34

 Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment
description.
3. Describe the architectural styles/patterns that have been
chosen to address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considering each attribute in
isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using
the sensitivity analysis conducted in step 5.
35
Architectural Mapping using Dataflow
customer requirements
"four bedrooms, three baths,
lots of glass ..."

architectural design

36
Deriving Program Architecture

Program
Architecture

37
 Partitioning the Architecture
• “horizontal” and “vertical” partitioning are
required

38
 Horizontal Partitioning
• define separate branches of the module
hierarchy for each major function
• use control modules to coordinate
communication between functions
function 1 function 3

function 2
39
 Vertical Partitioning: Factoring
• design so that decision making and work are
stratified
• decision making modules should reside at the
top of the architecture
decision-makers

workers
40
 Why Partitioned Architecture?
• results in software that is easier to test
• leads to software that is easier to maintain
• results in propagation of fewer side effects
• results in software that is easier to extend

41
 STRUCTURED DESIGN
• aim of structured design is to transform the
results of the structured analysis (that is, the
DFD model) into a structure chart.
• A structure chart represents
– the software architecture
– various modules making up the system,
– the module dependency (i.e. which module calls
which other modules), and
– the parameters that are passed among the different
modules.
 STRUCTURE CHART
• basic building blocks used in structure charts are
• Rectangular boxes: represents a module. Usually,
every rectangular box is annotated with the name
of the module it represents.
• Module invocation arrows: An arrow connecting
two modules implies that during program
execution control is passed from one module to
the other in the direction of the connecting arrow.
( no. of times a module is called and the order of
calling can’t be identified from the structure chart)
 CONTD.,
• Data flow arrows: These are small arrows appearing
alongside the module invocation arrows. The data flow
arrows are annotated with the corresponding data name.

• Library modules: A library module is usually represented

by a rectangle with double edges. Libraries comprise the
frequently called modules. Usually, when a module is
invoked by many other modules, it is made into a library
module.
 CONTD
• Selection: The diamond symbol represents the
fact that one module of several modules
connected with the diamond symbol is invoked
depending on the outcome of the condition
attached with the diamond symbol.

• Repetition: A loop around the control flow

arrows denotes that the respective modules
are invoked repeatedly.
 Guidelines for Structure Chart
• In any structure chart, there should be one and only one
module at the top, called the root.
• There should be at most one control relationship
between any two modules in the structure chart.
– if module A invokes module B, module B cannot invoke module
A. The main reason behind this is different modules are to be
arranged in layers or levels.
• The principle of abstraction does not allow lower-level
modules to be aware of the existence of the high-level
modules.
• it is possible for two higher-level modules to invoke the
same lower-level module.
Structure Chart
 Flow chart versus structure chart
• difficult to identify the different modules of a
program from its flow chart representation.
• Data interchange among different modules is
not represented in a flow chart.
• Sequential ordering of tasks that is inherent
to a flow chart is suppressed in a structure
chart.
 Transformation of a DFD into Structure Chart
• Structured design provides two strategies to guide
transformation of a DFD into a structure chart:
• Transform analysis - identifies the primary
functional components (modules) and the input
and output data for these components.
• Transaction analysis - an alternative to transform
analysis and is useful while designing transaction
processing programs. A transaction allows the user
to perform some specific type of work by using the
software. For example, ‘issue book’, ‘return book’,
‘query book’, etc., are transactions.
 Whether to apply transform or
transaction processing?
• we have to examine the data input to the diagram.
• If all the data flow into the diagram are processed
in similar ways (i.e. if all the input data flow
arrows are incident on the same bubble in the
DFD) then transform analysis is applicable.
• Otherwise, transaction analysis is applicable.
• Normally, transform analysis is applicable only to
very simple processing.
 Transform analysis
• first step in transform analysis is to divide the
DFD into three types of parts:
– Input.
– Processing.
– Output.
 Transform analysis
• The input portion in the DFD includes processes
that transform input data from physical (e.g,
character from terminal) to logical form (e.g.
internal tables, lists, etc.). Each input portion is
called an afferent branch.
• The output portion of a DFD transforms output
data from logical form to physical form. Each
output portion is called an efferent branch.
• The remaining portion of a DFD is called central
transform.
 Transform analysis contd.,
• In the next step of transform analysis, the structure chart is
derived by drawing one functional component each for
the central transform, the afferent and efferent branches.
• These are drawn below a root module, which would
invoke these modules.
• Processes which validate input are not central transforms.
• Processes which sort input or filter data from it are
central transforms.
• The first level of structure chart is produced by
representing each input and output unit as a box and each
central transform as a single box.
 Transform analysis contd.,
• In the third step of transform analysis, the structure chart is
refined by adding subfunctions required by each of the high-
level functional components.
• Many levels of functional components may be added.
• This process of breaking functional components into
subcomponents is called factoring.
• Factoring includes adding
– read and write modules,
– error-handling modules,
– initialization and termination process,
– identifying consumer modules etc.
• The factoring process is continued until all bubbles in the DFD
are represented in the structure chart.
• Example -6.1 (RMS Calculating Software) A
software system called RMS calculating
software would read three integral numbers
from the user in the range of –1000 and +1000
and would determine the root mean square
(RMS) of the three input numbers and display
it.
 0
• To Draw the structure chart for the RMS software
of Example 6.1.
• By observing the level 1 DFD of Figure 6.8, we can
identify validate-input as the afferent branch and
write-output as the efferent branch.
• The remaining (i.e., compute-rms) as the central
transform.
• By applying the step 2 and step 3 of transform
analysis, we get the structure chart shown in
Figure 6.19.
Figure 6.19: Structure chart for Example 6.6.
 Transaction analysis
• Each different way in which input data is
processed is a transaction.
• A simple way to identify a transaction is the
following.
• Check the input data. The number of bubbles on
which the input data to the DFD are incident
defines the number of transactions.
 Transaction analysis -steps
• For each identified transaction, trace the input data to
the output.
• All the traversed bubbles belong to the transaction.
• These bubbles should be mapped to the same module
on the structure chart.
• In the structure chart, draw a root module and below
this module draw each identified transaction as a
module.
• Every transaction carries a tag identifying its type.
• Transaction analysis uses this tag to divide the system
into transaction modules and a transaction-center
module.
 Example
• Draw the structure chart for the Supermarket
Prize Scheme software of Example 6.3.
• Example 6.3 (Supermarket Prize Scheme) A super market needs to develop a
software that would help it to automate a scheme that it plans to introduce to
encourage regular customers. In this scheme, a customer would have first
register by supplying his/her residence address, telephone number, and the
driving license number. Each customer who registers for this scheme is assigned
a unique customer number (CN) by the computer. A customer can present his
CN to the check out staff when he makes any purchase. In this case, the value of
his purchase is credited against his CN. At the end of each year, the supermarket
intends to award surprise gifts to 10 customers who make the highest total
purchase over the year. Also, it intends to award a 22 caret gold coin to every
customer whose purchase exceeded Rs. 10,000. The entries against the CN are
reset on the last day of every year after the prize winners’ lists are generated.
Figure 6.10: Context diagram for Example 6.3.
Figure 6.11: Level 1 diagram for Example 6.3.
 .

Figure 6.12: Level 2 diagram for Example 6.3.

Figure 6.21: Structure chart for Example 6.8.
 User Interface Design
• creates an effective communication medium
between a human and a computer.
• Following a set of interface design principles,
design identifies interface objects and actions
and then creates a screen layout that forms
the basis for a user interface prototype
UI Design Evaluation

user interface evaluation cycle

 A Spiral Process
• User interface development follows a spiral process
• – Interface analysis (user, task, and environment analysis)
– Focuses on the profile of the users who will interact with the system
Concentrates on users, tasks, content and work environment
• – Interface design
– Defines a set of interface objects and actions (and their screen
representations) that enable a user to perform all defined tasks in a manner
that meets every usability goal defined for the system
• – Interface construction
– Begins with a prototype that enables usage scenarios to be evaluated
Continues with development tools to complete the construction
• – Interface validation,
– focuses on the ability of the interface to implement every user task correctly,
to accommodate all task variations, and to achieve all general user
requirements
 The Golden Rules of User Interface Design
Place the User in Control
• Define interaction modes in a way that does not force a
user into unnecessary or undesired actions
– The user shall be able to enter and exit a mode with little or
no effort (e.g., spell check  edit text  spell check)
• Provide for flexible interaction
– The user shall be able to perform the same
action via keyboard commands, mouse movement, or
voice recognition
• Allow user interaction to be interruptible and
"undo"able
 Place the User in Control contd.,
• Streamline interaction as skill levels advance
and allow the interaction to be customized
• Hide technical internals from the casual user
• Design for direct interaction with objects that
appear on the screen (e.g., stretch a rectangle,
press a button, move a slider)
 Make the Interface Consistent
• The interface should present and acquire
information in a consistent fashion
• Allow the user to put the current task into a
meaningful context
• Maintain consistency across a family of
applications
• If past interactive models have created user
expectations, do not make changes unless there
is a compelling reason to do so
• Four different models come into play when a
user interface is analyzed and designed
1. User profile model – Established by a human
engineer or software engineer
2. Design model – Created by a software engineer
3. Implementation model – Created by the software
implementers
4. User's mental model – Developed by the user
when interacting with the application
• The role of the interface designer is to merge
these differences and derive a consistent
representation of the interface
 User Profile Model
• Establishes the profile of the end-users of the system
– Based on age, gender, physical abilities, education, cultural or ethnic background, motivation,
goals, and personality
• Considers syntactic knowledge of the user
– The mechanics of interaction that are required to use the interface effectively
• Considers semantic knowledge of the user
– – The underlying sense of the application; an understanding of the functions that are performed,
the meaning of input and output, and the objectives of the system
• Categorizes users as
– Novices - No syntactic knowledge of the system, little semantic
knowledge of the application, only general computer usage
– Knowledgeable, intermittent users with Reasonable semantic
knowledge of the system, low recall of syntactic information to use the
interface
– Knowledgeable, frequent users , Good semantic and syntactic
knowledge (i.e., power user), look for shortcuts and abbreviated modes of
operation
 Design Model
• Derived from the analysis model of the
requirements
• Incorporates data, architectural, interface, and
procedural representations of the software
• Constrained by information in the requirements
specification that helps define the user of the
system
 Implementation Model
• Consists of the look and feel of the interface
combined with all supporting information (books,
videos, help files) that describe system syntax and
semantics
• Strives to agree with the user's mental model;
users then feel comfortable with the software and
use it effectively
• Serves as a translation of the design model by
providing a realization of the information
contained in the user profile model and the user’s
mental model
 User's Mental Model
• Often called the user's system perception
• Consists of the image of the system that users
carry in their heads
• Accuracy of the description depends upon the
user’s profile and overall familiarity with the
software in the application domain
 User Interface Analysis
• To perform user interface analysis, the practitioner
needs to study and understand four elements
1. The users who will interact with the system
through the interface
2. The tasks that end users must perform to do
their work
3. The content that is presented as part of the
interface
4. The work environment in which these tasks
will be conducted