Unit III

DESIGN ENGINEERING AND ANALYSIS: DESIGN PRINCIPLES, DESIGN CONCEPTS,

EFFECTIVE MODULAR DESIGN-COHESION AND COUPLING.
TRANSLATING THE REQUIREMENT MODELS INTO THE DESIGN MODEL.
DESIGNS: ARCHITECTURAL DESIGN, COMPONENT LEVEL DESIGN, USER INTERFACE
DESIGN.
6TH EDITION
Chapter 9: Design Engineering
Chapter 10: Creating an Architectural Design
Chapter 11: 11.3 and Coupling-Cohesion ppt
Chapter 12: Performing User Interface Design – 12.1

7TH EDITION
Chapter 8: Design Concepts
Chapter 9: Architectural Design
Chapter 10: 10.3 and Coupling-Cohesion ppt
Chapter 11: Performing User Interface Design – 11.1

Kiran Bhowmick
 2

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

Kiran Bhowmick
 Design Engineering 3

What is design?
- its where you stand with a foot in two worlds – the world of technology and the world
of people & human purpose – and you try to bring the two together
Goal of design engineering is to produce a model or representation that exhibits
firmness, commodity and delight.

Kiran Bhowmick
 Analysis Model 4

• Use-cases • Data flow

• Use-case diagrams
diagrams • Control-flow
• Activity diagrams
diagrams • Processing
• Swim lane narratives
diagram Scenario- Flow-
based oriented
elements elements

Class-
Behavioral
based
elements
elements
• Class diagrams • State
• Analysis diagrams
packages • Sequence
• CRC models diagrams
• Collaboration
diagrams

Kiran Bhowmick
 Analysis Model  Design Model 5

Kiran Bhowmick
 Why design is Important? 6

 Quality is fostered – provides representations where quality is assessed

 Accurately translate customer’s requirements into a finished software product

 Serves as foundation for all the Software engineering tasks

 Without design there is a risk of building unstable system – will fail with small
changes, difficult to test, whose quality cannot be assessed until late in software
process i.e. when time is short and cost is high

Kiran Bhowmick
 Quality Guidelines 7
 A design should exhibit an architecture that
(1) has been created using recognizable architectural styles or patterns,
(2) is composed of components that exhibit good design characteristics and
(3) can be implemented in an evolutionary fashion
 For smaller systems, design can sometimes be developed linearly.
 A design should be modular; that is, the software should be logically partitioned into elements or subsystems

 A design should contain distinct representations of data, architecture, interfaces, and components.

 A design should lead to data structures that are appropriate for the classes to be implemented and are
drawn from recognizable data patterns.

 A design should lead to components that exhibit independent functional characteristics.

 A design should lead to interfaces that reduce the complexity of connections between components and
with the external environment.
 A design should be derived using a repeatable method that is driven by information obtained during
software requirements analysis.

 A design should be represented using a notation that effectively communicates its meaning.

Kiran Bhowmick
 Design Quality Attributes 8

A set of software quality attributes – FURPS which is a target for all software design.
 Functionality – evaluating feature set and capabilities, generality of functions delivered,
security of overall system
 Usability – human factors, consistency, overall aesthetics, documentation
 Reliability – frequency and severity of failure, accuracy of output results, MTTF, ability to
recover from failure and predictability
 Performance – processing speed, efficiency, throughput, response time and resource
consumption
 Supportability(maintainability) – ability to extend the program (adaptability, extensibility
and serviceability) and testability, compatibility, configurability – ease of installation
and configuration, organize and control elements of the software configuration.

Kiran Bhowmick
 Evaluation of good design 9

 the design must implement all of the explicit requirements contained in the analysis
model, and it must accommodate all of the implicit requirements desired by the
customer.

 the design must be a readable, understandable guide for those who generate code
and for those who test and subsequently support the software.

 the design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.

Kiran Bhowmick
 Design Principles
10
 The design process should not suffer from ‘tunnel vision.’
 The design should be traceable to the analysis model.
 The design should not reinvent the wheel.
 The design should “minimize the intellectual distance” [DAV95] between the software and the
problem as it exists in the real world.
 The design should exhibit uniformity and integration.
 The design should be structured to accommodate change.
 The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered.
 Design is not coding, coding is not design.
 The design should be assessed for quality as it is being created, not after the fact.
 The design should be reviewed to minimize conceptual (semantic) errors.

Kiran Bhowmick
 Fundamental Design Concepts 11

 abstraction—levels of abstraction
 architecture—the overall structure of the software
 patterns—”conveys the essence” of a proven design solution
 modularity—compartmentalization of data and function
 hiding—controlled interfaces
 Functional independence—single-minded function and low
coupling
 refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design

Kiran Bhowmick
 Procedural Abstraction 12

open
Sequence of instructions that
have limited and specific
details of enter functions.
algorithm Name implies the function but
details are suppressed

implemented with a "knowledge" of the

object that is associated with enter

Kiran Bhowmick
 Data Abstraction 13

door
manufacturer Named collection of data that
model number describes data object
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

Calculate volume
Sphere/cylinder
Kiran Bhowmick
 Procedural abstraction Data abstraction

focuses on eliminating duplicate code within a hides the implementation details of data from 14
single program, the user of an API.

focuses on the steps that need to be taken in focuses on the data that is needed in order to
order to complete a task complete a task.
For example, when creating a new bank For example, data abstraction would focus on
account, a programmer would use procedural the data that needs to be collected in order to
abstraction to determine the steps that need to create the account, such as the customer’s
be taken in order to create the account, such name, address, and Social Security number.
as inputting the customer’s information and
generating a new account number.
hides the details of how a task is completed hides the details of what data is being used
from the user from the user.

For example, when a user clicks on a “submit” when a user inputs their information into a
button, they are not concerned with the details form, they are not concerned with how that
of how their information is being sent to the information is being stored; they just know that
server; they just know that clicking the button their information will be stored somewhere.
will submit their information.

Kiran Bhowmick
 Fundamental Design Concepts 15

 abstraction—levels of abstraction
 architecture—the overall structure of the software
 patterns—”conveys the essence” of a proven design solution
 modularity—compartmentalization of data and function
 hiding—controlled interfaces
 Functional independence—single-minded function and low coupling
 refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design

Kiran Bhowmick
 Architecture
16
“The overall structure of the software and the ways in which that structure provides
conceptual integrity for a system.”
The structure or organization of s/w components, the manner in which these components interact and the data
used by these components

Structural models. Represents architecture as an organized collection of program components.

Framework models. Increases the level of design abstraction by attempting to identify repeatable architectural
design frameworks that are encountered in similar types of applications.
Dynamic models. Address the behavioral aspects of the program architecture, indicating how the structure or
system configuration may change as a function of external events.
Process models. Focus on the design of the business or technical process that the system must accommodate.
Functional models. Can be used to represent the functional hierarchy of a system.

Kiran Bhowmick
 Patterns 17
A named nugget of insight which conveys the essence of proven solution to a recurring problem
within a certain context

A design pattern describes a design structure that solves a particular problem within a specific
context and amid forces that may have an impact on the manner in which the pattern is applied and
used
e.g., problem of consistency, problem of persistence, distribution

Design pattern is to provide a description that enables a designer to determine

1. Whether the pattern is applicable to the current work
2. Whether the pattern can be reused
3. Whether the pattern can serve as a guide for developing a similar, but functionally or structurally
different

Types of design patterns:

1. Architectural patterns
2. Design patterns
3. Idioms or coding patterns
Kiran Bhowmick
 Fundamental Design Concepts 18

 abstraction—levels of abstraction
 architecture—the overall structure of the software
 patterns—”conveys the essence” of a proven design solution
 modularity—compartmentalization of data and function
 hiding—controlled interfaces
 Functional independence—single-minded function and low
coupling
 refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design

Kiran Bhowmick
 Modular Design 19
easier to build, easier to change, easier to fix ...

Kiran Bhowmick
 Modularity 20
Modularity is the single attribute of software that allows a program to be intellectually
manageable

Monolithic software (i.e., a large program composed of a single module) cannot be easily
grasped by a software engineer.
The number of control paths, span of reference, number of variables, and overall
complexity would make understanding close to impossible.

In almost all instances, you should break the design into many modules, hoping to make
understanding easier and, as a consequence, reduce the cost required to build the
software

if you subdivide software indefinitely the effort required to develop it will become negligibly
small?????

Kiran Bhowmick
 Modularity: Trade-offs 21
What is the "right" number of modules for a specific software design?

Modularize in the vicinity of

M.

Over and Under

modularization to be
avoided

Kiran Bhowmick
 Fundamental Design Concepts 22

 abstraction—levels of abstraction
 architecture—the overall structure of the software
 patterns—”conveys the essence” of a proven design solution
 modularity—compartmentalization of data and function
 hiding—controlled interfaces
 Functional independence—single-minded function and low
coupling
 refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design

Kiran Bhowmick
 Information Hiding 23

module • algorithm
controlled
interface • data structure
• details of external interface
• resource allocation policy

clients "secret"

a specific design decision

Kiran Bhowmick
 Why Information Hiding? 24
 The concept of modularity leads you to a fundamental question: “How do I decompose
a software solution to obtain the best set of modules?”
 The principle of information hiding suggests that modules be “characterized by design
decisions that (each) hides from all others.”
 In other words, modules should be specified and designed so that information
(algorithms and data) contained within a module is inaccessible to other modules that
have no need for such information
 Hiding implies that effective modularity can be achieved by defining a set of
independent modules that communicate with one another only that information
necessary to achieve software function.
 Abstraction helps to define the procedural (or informational) entities that make up the
software.
 Hiding defines and enforces access constraints to both procedural detail within a
module and any local data structure used by the module

Kiran Bhowmick
 Why Information Hiding? 25

 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

Kiran Bhowmick
 Fundamental Design Concepts 26

 abstraction—levels of abstraction
 architecture—the overall structure of the software
 patterns—”conveys the essence” of a proven design solution
 modularity—compartmentalization of data and function
 hiding—controlled interfaces
 Functional independence—single-minded function and low
coupling
 refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design

Kiran Bhowmick
 Functional Independence 27
Outgrowth of modularity, abstraction and information hiding

Achieved by developing modules with single minded function and an aversion to excessive
interaction with other modules

COHESION - the degree to which a

module performs one and only one
function.

COUPLING - the degree to which a

module is "connected" to other
modules in the system.

Refer couplingcohesion.pptx for details

Kiran Bhowmick
 Fundamental Design Concepts 28

 abstraction—levels of abstraction
 architecture—the overall structure of the software
 patterns—”conveys the essence” of a proven design solution
 modularity—compartmentalization of data and function
 hiding—controlled interfaces
 Functional independence—single-minded function and low
coupling
 refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design

Kiran Bhowmick
 Stepwise Refinement 29
Stepwise refinement is a top-down design strategy. open
A program is developed by successively refining
levels of procedural detail.
walk to door;
A hierarchy is developed by decomposing a reach for knob;
macroscopic statement of function (a procedural
abstraction) in a stepwise fashion until open door; repeat until door opens
programming language statements are reached turn knob clockwise;
walk through; if knob doesn't turn, then
Refinement is actually a process of Elaboration. close door. take key out;
You begin with a statement of function (or find correct key;
description of information) that is defined at a high insert in lock;
level of abstraction. endif
pull/push door
The statement describes function or information move out of way;
conceptually but provides no information about end repeat
the internal workings of the function or the internal
structure of the information.

Kiran Bhowmick
 Refinement Vs Abstraction 30

 Abstraction and refinement are complementary concepts.

 Abstraction enables you to specify procedure and data internally but suppress
the need for “outsiders” to have knowledge of low-level details.
 Refinement helps you to reveal low-level details as design progresses.

 Both concepts allow you to create a complete design model as the design
evolves

Kiran Bhowmick
 Sizing Modules: Two Views 31

What's How big

inside?? is it??

MODULE

Kiran Bhowmick
 Fundamental Design Concepts 32

 abstraction—levels of abstraction
 architecture—the overall structure of the software
 patterns—”conveys the essence” of a proven design solution
 modularity—compartmentalization of data and function
 hiding—controlled interfaces
 Functional independence—single-minded function and low
coupling
 refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design

Kiran Bhowmick
 Refactoring 33
 Fowler 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 refactored, 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.

Kiran Bhowmick
 Design Classes 34
 Analysis classes are refined during design to become entity classes
 Five different types of design classes

 User interface classes – define all abstractions that are necessary for human computer interaction

 Business domain classes – define all classes that are required to implement some element of the
business domain

 Process classes – implement lower-level business abstractions required to fully manage the business
domain classes

 Persistent classes – represent data stores that will persist beyond the execution of the software

 System classes – implement software management and control functions that enable the system to
operate and communicate within its computing environment and with the outside world

Kiran Bhowmick
 Design Classes 35
 Boundary classes are developed during design to create the interface (e.g., interactive
screen or printed reports) that the user sees and interacts with as the software is used.
 Boundary classes are designed with the responsibility of managing the way entity objects are represented to
users.

 Controller classes are designed to manage

 the creation or update of entity objects;
 the instantiation of boundary objects as they obtain information from entity objects;
 complex communication between sets of objects;
 validation of data communicated between objects or between the user and the application.

Kiran Bhowmick
 OO Design Concepts 36

 Design classes
 Entity classes
 Boundary classes
 Controller classes
 Inheritance—all responsibilities of a superclass is immediately inherited
by all subclasses
 Messages—stimulate some behavior to occur in the receiving object
 Polymorphism—a characteristic that greatly reduces the effort
required to extend the design

Kiran Bhowmick
 Inheritance 37

 Design options:
 The class can be designed and built from scratch. That is, inheritance is not used.

 The class hierarchy can be searched to determine if a class higher in the hierarchy (a
superclass)contains most of the required attributes and operations. The new class
inherits from the superclass and additions may then be added, as required.

 The class hierarchy can be restructured so that the required attributes and operations
can be inherited by the new class.
 Characteristics of an existing class can be overridden and different versions of attributes
or operations are implemented for the new class.

Kiran Bhowmick
 Messages 38

:SenderObject

message (<parameters>)
:ReceiverObject

Kiran Bhowmick
 Polymorphism 39
Conventional approach …
case of graphtype:
if graphtype = linegraph then DrawLineGraph (data);
if graphtype = piechart then DrawPieChart (data);
if graphtype = histogram then DrawHisto (data);
if graphtype = kiviat then DrawKiviat (data);
end case;

All of the graphs become subclasses of a general class called graph. Using a concept called
overloading [TAY90], each subclass defines an operation called draw. An object can send a
draw message to any one of the objects instantiated from any one of the subclasses. The
object receiving the message will invoke its own draw operation to create the appropriate
graph.

graphtype draw

Kiran Bhowmick
 The Design Model
40

Kiran Bhowmick
 Design Model Elements
41
 Data design elements
 Creates a model of data that is refined into implementation specific representations
 Architecture of Data influences the architecture of software that process it.
 Program Component level --> design of data structures and algorithm to manipulate them is essential to
achieve high quality application
 Application level --> translation of data model into database is essential to achieve business objectives
 Business level -> collection of info stored in disparate databases into data warehouse enables data mining or
knowledge discovery

 Architectural design elements

 Equivalent to floor plan – overall layout of rooms, size, shape
 Architectural design elements provide Overall view of the software
 Derived from
 Information about Application domain for the software to be built
 Specific analysis model elements like Analysis classes, their relationships, collaborations and behaviors are transformed into
design realizations
 Availability of architectural patterns and styles
Kiran Bhowmick
 Design Model Elements
42

 Interface design elements

 Equivalent to set of detailed drawings of doors, windows and external utilities
 Interface design tell
 how information flows in and out of the system
 How information is communicated among the components defined as part of the architecture
 3 important elements of interface design
 the user interface (UI)
 external interfaces to other systems, devices, networks or other producers or consumers of information
 internal interfaces between various design components.
 Interfaces all communication externally, enable internal communication and collaboration
among the components

Kiran Bhowmick
 Interface Elements
43
MobilePhone

WirelessPDA

Cont rolPanel

LCDdisplay
LEDindicat ors
keyPadCharact erist ics Key Pad
speaker
wirelessInt erf ace

readKeySt roke()
decodeKey ()
displaySt at us()
light LEDs()
sendCont rolMsg()

< < int erfac e> >

Key Pad

readKeyst roke()
decodeKey()

Figure 9 .6 UML int erfac e represent at ion for Co n t r o lPa n e l

Kiran Bhowmick
 Design Model Elements
44
 Component-level design elements
 Equivalent to set of detailed drawings for each room like wiring, plumbing, electrical
receptacles and switches, sinks, cabinets closets etc.

 Component level design describes full internal detail of each s/w component

 Component level design defines

 data structures for all local data objects
 Algorithmic detail for all processing that occurs within a component
 Interface that allows communication with the component

SensorManagement
Sensor

Kiran Bhowmick
 Design Model Elements
45
 Deployment-level Cont rol Panel CPI serv er
design elements
Security homeownerAccess

Indicate how software

functionality and
subsystems will be
allocated within the
physical computing
environment that will
support the software

Per sonal comput er

externalAccess

Security Surveillance

homeManagement communication

Figure 9 . 8 UML deploy m ent diagram f or Saf eHom e

Kiran Bhowmick
 Design Patterns 46

 The best designers in any field have an uncanny ability to see patterns that
characterize a problem and corresponding patterns that can be combined to
create a solution

 A description of a design pattern may also consider a set of design forces.

 Design forces describe non-functional requirements (e.g., ease of maintainability, portability)
associated the software for which the pattern is to be applied.

 The pattern characteristics (classes, responsibilities, and collaborations) indicate

the attributes of the design that may be adjusted to enable the pattern to
accommodate a variety of problems.

Kiran Bhowmick
 Patterns 47
Design Pattern Template
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

Kiran Bhowmick
 Frameworks 48

 A framework is not an architectural pattern, but rather a skeleton

with a collection of “plug points” (also called hooks and slots) that
enable it to be adapted to a specific problem domain.
 Gamma et al note that:
 Design patterns are more abstract than frameworks.
 Design patterns are smaller architectural elements than frameworks
 Design patterns are less specialized than frameworks

Kiran Bhowmick
 ARCHITECTURAL DESIGN 49

Kiran Bhowmick
 Software Architecture? 50

Define: 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

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.

Kiran Bhowmick
 Data Design 51
 At the architectural level …
 Design of one or more databases to support the application architecture
 Design of methods for ‘mining’ the content of multiple databases
 navigate through existing databases in an attempt to extract appropriate business-level
information
 Design of a data warehouse—a large, independent database that has access to the data that
are stored in databases that serve the set of applications required by a business
 At the component level …
 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

Kiran Bhowmick
 Data Design—Component Level 52

1. The systematic analysis principles applied to function and behavior should also be applied to data.
2. All data structures and the operations to be performed on each should be identified.
3. A data dictionary should be established and used to define both data and program design.
4. Low level data design decisions should be deferred until late in the design process.
5. The representation of data structure should be known only to those modules that must make direct use of
the data contained within the structure.
6. A library of useful data structures and the operations that may be applied to them should be developed.
7. A software design and programming language should support the specification and realization of abstract
data types.

Kiran Bhowmick
 Architectural Styles
53
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.

It is a transformation that is imposed on the design of an entire system.

The intent is to establish a structure for all components of the system.
If an existing architecture is to be reengineered the imposition of an architectural style will
result in fundamental changes to the structure of the software including reassignment of
functionality of components

Kiran Bhowmick
 Architectural Styles
54
A taxonomy of Architectural Styles:

 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures

Kiran Bhowmick
 Data-Centered Architecture
55
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.

Client software accesses a central repository.

Data repository can be active or passive.

Passive – the client software accesses the data independent

of any changes to the data or the actions of other client
software.

Active - the repository is like a “blackboard” that sends

notifications to client software when data of interest to the
client changes

Advantages:
Integrability – client components can be added or modified/changed

Data can be passed among clients using the blackboard mechanism (i.e., the blackboard component serves to
coordinate the transfer of information between clients).

Client components independently execute processes

Kiran Bhowmick
 Data Flow Architecture 56

This architecture is applied when input data are to be

transformed through a series of computational or
manipulative components into output data.

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. However, the filter
does not require knowledge of the workings of its
neighboring filters

If the data flow degenerates into a single line of

transforms, it is termed batch sequential. This structure
accepts a batch of data and then applies a series of
sequential components (filters) to transform

Kiran Bhowmick
 Call and Return Architecture 57

This architectural style enables to achieve a program structure that is relatively

easy to modify and scale

A number of substyles exist in this category. Viz.,

1. Main program / Sub program architecture
2. Remote procedure call architecture – distributed components across
networks

Kiran Bhowmick
 Layered Architecture 58

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.

Kiran Bhowmick
 Architectural Patterns
59

It also imposes transformation on the design of an architecture like styles.

However, it differs in different ways:
1. The scope of pattern is less broad; focuses on only one aspect
2. Imposes a rule on architecture describing how software will handle a particular
aspect of functionality at infrastructure level
3. Address specific behavioral issue within a context.
e.g: how a real time application handles the issues of synchronization or
interrupts.

Kiran Bhowmick
 Architectural Patterns
60
Architectural patterns for a software define a specific approach for handling some behavioral aspects
 Concurrency—applications must handle multiple tasks in a manner that simulates parallelism
 operating system process management pattern
 This pattern incorporates OS functionality that manages communication between processes, scheduling and other
capabilities to achieve concurrency.
 task scheduler pattern – tick() or start() or initiate()
 Persistence—Data persists if it survives past the execution of the process that created it. 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(e.g. word processing
software)
 Distribution— the manner in which systems or components within systems communicate with one
another in a distributed environment.
Two problems: a. the way in which entities connect to one another
b. the nature of communication
 A broker acts as a ‘middle-man’ between the client component and a server component. E.g. CORBA
 CORBA - The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that
enables software components written in multiple computer languages and running on multiple computers to work together.

Kiran Bhowmick
 Architectural Context 61

 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

Kiran Bhowmick
 Architectural Context
62

• Superordinate systems—those systems that use the target

system as part of some higher-level processing scheme.
• Subordinate systems—those systems that are used by the
target system and provide data or processing that are
necessary to complete target system functionality.
• Peer-level systems—those systems that interact on a peer-
to-peer basis (i.e., information is either produced or
consumed by the peers and the target system.
• Actors—entities (people, devices) that interact with the
target system by producing or consuming information that is
necessary for requisite processing

Kiran Bhowmick
 Architectural Context
63
Safehome Internet-based Superordinate
Product system systems
Used by

control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses

Actors
uses Depends on

Sub-ordinate
sensors sensors
systems

Kiran Bhowmick
 Archetypes
Cont roller
64
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
communicat es wit h

• Node. Represents a cohesive collection of input and output elements of the

home security function. For example a node might be comprised of (1)
Node
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
Det ect or Indicat or
arming or disarming of a node. If controllers reside on a network, they have
the ability to communicate with one another

Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
(adapt ed f rom [ BOS00] )

Kiran Bhowmick
 Refining Architecture into Components 65

SafeHome
Execut ive

Funct ion
select ion

Ext ernal
Communicat ion
Management

Securit y Surveillance Home

management

GUI Int ernet

Int erface

Cont rol det ect or alarm

panel management processing
processing

Kiran Bhowmick
 Refined Component Structure 66
SafeHome
Executive

Ext ernal
Communicat ion
Management

Security

GUI Internet
Interface

Co n t ro l d e t e ct o r alarm
p an e l m an ag e m e n t p ro ce ssin g
p ro ce ssin g

Ke y p ad
p ro ce ssin g phone
sch e d u le r
co m m u n icat io n

CP d isp lay
fu n ct io n s
alarm

sennso
se so r
se
se nsoso rr
se
se nnso
sorrr
se nnso r
se n so
se n so r r

Kiran Bhowmick
 Analyzing Architectural Design
67
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. – identify the trade-off points
Kiran Bhowmick
 Deriving Program Architecture 68
Architectural mapping using data flow

Program
Architecture

Kiran Bhowmick
 Structure design 69

 Data flow oriented design

 Transition from DFD to software architecture
 Type of information flow:
 Transform flow:
 Flow of information into the system - incoming flow
 Processing of information / transition within the system – transform center
 Flow of data out of the system – outgoing flow
 Transaction flow:
 Transaction – incoming flow is triggered into data that flows
through different paths

Kiran Bhowmick
 Transaction Example 70

fixture setting fixture

servos

commands
operator process
report display
operator
commands screen

robot control

robot
control
software
assembly
record
in reality, other
commands
would also be shown

Kiran Bhowmick
 Transform mapping: is a set of design steps that allows a DFD with transform flow
characteristics to be mapped into a specific architectural style 71
 To map these data flow diagrams into a software architecture, you would initiate the
following design steps:
 Step 1. Review the fundamental system model
 Step 2. Review and refine data flow diagrams for the software
 Step 3. Determine whether the DFD has transform or transaction flow characteristics
 Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries
 Step 5. Perform “first-level factoring”
 Step 6. Perform “second-level factoring.”
 Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality
 Refining the Architectural Design

Kiran Bhowmick
 Level 2 – refines monitor sensors transform
Level 0
72

Step 1. Review the fundamental

system model
Step 2. Review and refine data
Level 1 flow diagrams for the software

Level 3 – monitor sensors with flow boundaries

Kiran Bhowmick
 Step 3. Determine whether the DFD has transform or transaction flow characteristics

73

Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries

Kiran Bhowmick
 Step 5. Perform “first-level factoring”

Factoring leads to a program structure in which top-level 74

components perform decision making and low-level
components perform most input, computation, and output
work.
Middle-level components perform some control and do
moderate amounts of work

When transform flow is encountered, a DFD is mapped to a specific structure (a

call and return architecture) that provides control for incoming, transform, and
outgoing information processing – first level factoring

A main controller (called monitor sensors executive) resides at the top of the
program structure and coordinates the following subordinate control functions:
• An incoming information processing controller, called sensor input controller,
coordinates receipt of all incoming data
• A transform flow controller, called alarm conditions controller, supervises all
operations on data in internalized form (e.g., a module that invokes various
data transformation procedures).
• An outgoing information processing controller, called alarm output controller,
coordinates production of output information.

Kiran Bhowmick
 Transaction Mapping 75
e f
a d
b
t i
g
h k
l j
data flow model
m
x1 n
Mapping
b t

a x2 x3 x4

d e f g h x3.1 l m n

i j
k

Kiran Bhowmick
 Step 6. Perform “second-level factoring”

76
Second-level factoring is accomplished by mapping
individual transforms (bubbles) of a DFD into appropriate
modules within the architecture.

Step 7. Refine the first-iteration architecture using design heuristics for improved software quality.

Kiran Bhowmick
Step 7. Refine the first-iteration architecture using design heuristics for improved software quality.

77

9.6.2 Refining the Architectural Design

Kiran Bhowmick
 COMPONENT LEVEL DESIGN 78

Kiran Bhowmick
 Component Level Design-I 79
 Step 1. Identify all design classes that correspond to the problem domain.
 Step 2. Identify all design classes that correspond to the infrastructure domain.
 Step 3. Elaborate all design classes that are not acquired as reusable components.
 Step 3a. Specify message details when classes or component collaborate.
 Step 3b. Identify appropriate interfaces for each component.
 Step 3c. Elaborate attributes and define data types and data structures required to implement them.
 Step 3d. Describe processing flow within each operation in detail.
 Step 4. Describe persistent data sources (databases and files) and identify the classes required to
manage them.
 Step 5. Develop and elaborate behavioral representations for a class or component.
 Step 6. Elaborate deployment diagrams to provide additional implementation detail.
 Step 7. Factor every component-level design representation and always consider alternatives.

Kiran Bhowmick
 Collaboration Diagram
80

:ProductionJob

1: buildJob (WOnumber )
2: submitJob (WOnumber )

:WorkOrder

:JobQueue

Kiran Bhowmick
 Refactoring 81

computeJob

PrintJob
initiateJob

WorkOrder

ap p ro p riat e at t rib u t e s <<interface>>

getJobDescriiption buildJob initiateJob
buildWorkOrder ()
p assJo b To Pro d u ct io n ( )
ProductionJob

submitJob
JobQueue
ap p ro p riat e at t rib u t e s

checkPriority ()

Kiran Bhowmick
 Activity Diagram
82
validat e at t ribut es
input

acc ess PaperDB (weight )

ret urns bas eCost perPage

paperCos t perPage =
bas eCost perPage

size = B paperCos t perPage =

paperCos t perPage * 1 . 2

size = C paperCost perPage =

paperCost perPage * 1 . 4

s ize = D paperCost perPage =

paperCost perPage * 1 . 6

c olor is cust om
paperCost perPage =
paperCost perPage * 1 . 1 4

color is st andard

ret urns
( paperCos t perPage )

Kiran Bhowmick
 Statechart
b eh avio r w it h in t h e
83
st at e b u ild in g Jo b Dat a

d at aIn p u t In co mp let e
buildingJobDat a

ent ry/ readJobDat a ()

exit / displayJobDat a ()
do/ checkConsist ency()
include/ dat aInput

d at aIn p u t Co mp let ed [ all d at a

it ems co n sist en t ] / d isp layUserOp t io n s

comput ingJobCost

ent ry/ comput eJob

exit / save t ot alJobCost

j o b Co st Accep t ed [ cu st o mer is au t h o rized ] /

g et Elect ro n icSig n at u re

f ormingJob

ent ry/ buildJob

exit / save WOnumber
do/

submit t ingJob

ent ry/ submit Job

exit / init iat eJob
do/ place on JobQueue

j o b Su b mit t ed[ all au t h o rizat io n s acq u ired ] /

p rin t Wo rkOrd er

Kiran Bhowmick
 USER INTERFACE DESIGN 84

Kiran Bhowmick
 Golden Rules

 Place the user in control

 Reduce the user’s memory load
 Make the interface consistent

Kiran Bhowmick
 Place the User in Control
Define interaction modes in a way that does not force a user
into unnecessary or undesired actions.
Provide for flexible interaction.
Allow user interaction to be interruptible and undoable.
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.

Kiran Bhowmick
 Reduce the User’s Memory Load
Reduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a real
world metaphor.
Disclose information in a progressive fashion.

Kiran Bhowmick
 Make the Interface
Consistent
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.

Kiran Bhowmick