1.

DESIGNPROCESS
Software design is an iterative process through which requirements are translated into a “blueprint”
for constructing the software. Software design consists of the set of principles, concepts, and
practices which is used fordeveloping the system or product

Characteristics of a good design

 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
forthose 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.

Quality Guidelines
 A design should exhibit an architecture that is created using recognizable
architectural styles or patterns and composed of components that exhibit
good design characteristics and can be implemented in an evolutionary
fashion.
 A design should be modular
 A design should contain distinct representations of data,
architecture, interfaces, andcomponents.
 A design should lead to data structures that are
appropriate for the classes to beimplemented 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
betweencomponents 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
itsmeaning.
Design Principles
 The design process should not suffer from ‘tunnel vision.’
 The design should be traceable to the analysis model.
 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, oroperating 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 semantic errors.
Quality Attributes.
 Functionality is assessed by evaluating the feature set and capabilities of the
program and the security of the overall system etc.
 Usability is assessed by considering human factors, consistency and documentation.
  Reliability is evaluated by measuring the frequency and severity of
failure, the mean-time-to-failure (MTTF), the ability to recover from
failure etc.
 Performance is measured by considering processing speed,
response time, resourceconsumption, throughput, and efficiency.
 Supportability combines the ability to extend the program
(extensibility), adaptability,serviceability
The Evolution of Software Design
 Early design work concentrated on criteria for the development of
modular programs and methods for refining software structures in a top
down manner.
 Procedural aspects of design definition evolved into structured programming
 Later work proposed methods for the translation of data flow into a design definition.
 Newer design approaches proposed an object-oriented approach to design derivation.
 The design patterns can be used to implement software architectures and
lower levels of design abstractions.
 Aspect-oriented methods, model-driven development, and test-driven
development emphasize techniques for achieving more effective
modularity and architectural structure in the designs.
Characteristics of design methods:
(1) A mechanism for the translation of the requirements
model into a designrepresentation,
(2) A notation for representing functional components and their interfaces,
(3) Heuristics for refinement and partitioning, and
(4) Guidelines for quality assessment.
2. DESIGN CONCEPTS

The software design concept provides a framework for implementing the right software.
Fundamental concept of software design includes,
a) Abstraction f) Structural Partitioning
b) Refinement g) Data Structure
c) Modularity h) Software Procedure
d) Software Architecture i) Information Hiding
e) Control Hierarchy
a) Abstraction:
 Abstraction is one of the fundamental ways that we as human cope with complexity.
 There are some levels of abstraction they are:
 Higher level abstraction
 Lower level abstraction
 At the highest level of abstraction, a solution is stated in broad terms using the
language of the problem environment.
 At lower levels of abstraction, a more detailed description of the solution is provided.
 There are 3 widely used abstraction mechanism. They are
 Procedural or Functional Abstraction
 Data Abstraction
 Control Abstraction
Procedural or Functional Abstraction:
 A procedural abstraction is a sequence of instructions that has a specific and limited
function.
 Eg : An example of a procedural abstraction would be the word open for a door.
Open implies a long sequence of procedural steps (e.g., walk to the door, reach out
and grasp knob, turn knob and pull door, step away from moving door, etc.).

Data Abstraction:
 A data abstraction is a named collection of data that describes a data object.

4
  Eg: In the context of the procedural abstraction open, we can define a data abstraction
called door.

Control Abstraction:
 Control abstraction is the third form of abstraction used in software design.
 Control abstraction implies a program control mechanism without specifying internal
details.
 Eg: synchronization semaphore used to coordinate activities in an operating system.

a) Refinement
 Stepwise refinement is a top-down design strategy, successively refining levels of
procedural detail.
 A hierarchy is developed by decomposing a macroscopic statement of function in a
stepwise fashion until programming language statements are reached.
 Refinement is actually a process of elaboration. Refinement causes the designer to
elaborate on the original statement, providing more and more detail as each
successive refinement occurs.
 Refinement helps the designer to reveal low-level details as design progresses.
 Both concepts aid the designer in creating a complete design model as the design
evolves.

b) Modularity
 Software is divided into separately named and addressable components, often
called modules, that are integrated to satisfy problem requirements.
 It has been stated that "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 reader.
 The number of control paths, span of reference, number of variables, and overall
complexity would make understanding close to impossible.
 To illustrate this point, consider the following argument based on observations of
human problem solving.

5
 C(x) - the perceived complexity of a problem x, and
E(x) - effort (in time) required to solve a problem x.

To define an effective modular system they should satisfy the following five criteria. They are:
1) Modular decomposability
2) Modular composability
3) Modular understandability
4) Modular continuity
5) Modular protection
1) Modular decomposability: If a design method provides a systematic mechanism for
decomposing the problem into sub problems, it will reduce the complexity of the overall
problem, thereby achieving an effective modular solution.
2) Modular composability: If a design method enables existing (reusable) design
components to be assembled into a new system, it will yield a modular solution.
3) Modular understandability: If a module can be understood as a standalone unit
(without reference to other modules), it will be easier to build and easier to change.
4) Modular continuity: If small changes to the system requirements result in changes to
individual modules.

6
 5) Modular protection. If an aberrant condition occurs within a module and its effects are
constrained within that module.

4) Software Architecture
 The overall structure of the software and the ways in which that structure provides
conceptual integrity for a system.
 Architecture is the hierarchical structure of program components (modules), the
manner in which these components interact and the structure of data that are used by
the components.
 The architectural design can be represented using one or more of a number of
different models.

1) Structural models
2) Framework models
3) Dynamic models
4) Process models
5) Functional models

 Structural models
Represents architecture as an organized collection of program components.
 Framework models
Increase the level of design abstraction by attempting to identify repeatable architectural
design frameworks (patterns) 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
Used to represent the functional hierarchy of a system

7
 5) Control Hierarchy

 Control hierarchy, also called program structure, represents the organization of program components
(modules) and implies a hierarchy of control
 Different notations are used to represent control hierarchy and the most common is the treelike diagram (Figure
2) that represents hierarchical control for call and return architectures.
 Depth and width provide an indication of the number of levels of control.
 Fan-out is a measure of the number of modules that are directly controlled by another module.
 Fan-in indicates how many modules directly control a given module.

Fig 2: Structure Terminology for a Call and Return Architectural style

 The control relationship among modules is expressed in the following way:

 A module that controls another module is said to be super ordinate to it.
 A module controlled by another is said to be subordinate to the controller.

 Eg: Referring to Figure 2, module M is super ordinate to modules a, b, and c. Module h is subordinate to module
e and is ultimately subordinate to module M.

8
 6) Structural Partitioning
 The program structure can be partitioned both horizontally and
vertically. Referring to Figure 3,
 Horizontal partitioning defines separate branches of the modular hierarchy for each major
program function.
 Control modules, represented in a darker shade are used to coordinate communication between and
execution of the functions.
 The simplest approach to horizontal partitioning defines three partitions—input, data
transformation (often called processing) and output.

Fig 3: Structured Partitioning

Benefits/ Advantages:
 Software that is easier to test
 Software that is easier to maintain
 Propagation of fewer side effects
 Software that is easier to extend

9
 Disadvantage:
 It causes more data to be passed across module interfaces and can complicate the overall control of
program flow
Vertical partitioning (Figure 3b), often called factoring, suggests that control (decision making) and work
should be distributed top-down in the program structure.

Top-level modules should perform control functions and do little actual processing work.
Modules that reside low in the structure should be the workers, performing all input, computation, and output
tasks.The nature of change in program structures justifies the need for vertical partitioning.
 Referring to Figure 3b, it can be seen that a change in a control module (high in the structure) will have a
higher probability of propagating side effects to modules that are subordinate to it.
 A change to a worker module, given its low level in the structure, is less likely to cause the propagation of
side effects.
 In general, changes to computer programs revolve around changes to input, computation or transformation,
and output.
 The overall control structure of the program (i.e., its basic behavior is far less likely to change).
For this reason vertically partitioned structures are less likely to be susceptible to side effects when changes
are made and will therefore be more maintainable—a key quality factor.

7) Data Structure
Data structure is a representation of the logical relationship among individual elements of data.
Because the structure of information will invariably affect the final procedural design, data structure is as
important as program structure to the representation of software architecture.

8) Software Procedure
Program structure defines control hierarchy without regard to the sequence of processing and decisions.
Software procedure focuses on the processing details of each module individually.
Procedure must provide a precise specification of processing, including sequence of events, exact decision
points, repetitive operations, and even data organization and structure.
The processing indicated for each module must include a reference to all modules subordinate to the module
being described.

10
 9) Information Hiding
Information hiding is characterized by design decisions that hide from all others.
In other words, modules should be specified and designed so that information (procedure and data)
contained within a module is inaccessible to other modules.
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.

3. DESIGNMODEL
 The design model can be viewed in two different dimensions
– (Horizontally) The process dimension indicates the evolution of the parts of
the design model as each design task is executed
– (Vertically) The abstraction dimension represents the level of detail as each
element of the analysis model is transformed into the design model and then
iteratively refined
 Elements of the design model use many of the same UML diagrams used in the
analysis model
– The diagrams are refined and elaborated as part of the design
– More implementation-specific detail is provided
Fig: Dimensions of the Design Model

11
 Design:
Design is a process of transforming the requirements of a customer to a product or solution.
The description of a solution is also called design. The designer’s goal is to produce a model or
representation of an entity that will be built later.
Translating the Analysis Model into A Software Design
Four levels of design are required to transform the requirements to software design. Four
levels of design are:
1) Data design
2) Architecture design
3) Interface design
4) Component design
5) Deployment Design

Fig1 Translating the Analysis Model into A Software Design

Data Design
 The data design transforms the information domain model created during analysis into the data
structures that will be required to implement the software.
 The data objects and relationships defined in the entity relationship diagram and the detailed data
content depicted in the data dictionary provide the basis for the data design activity.
12
  Entity-relationship consists of information required for each entity or data objects as well as it
shows the relationship between these objects. It shows the structure of the data in terms of the
tables.
 It shows three type of relationship – One to one, one to many, and many to many. In one to one
relation, one entity is connected to another entity. In one many relation, one Entity is connected to
more than one entity. un many to many relations one entity is connected to more than one entity as
well as other entity also connected with first entity using more than one entity.

Architectural Design

 The architectural design defines the relationship between major structural elements of the software,
the “design patterns” that can be used to achieve the requirements that have been defined for the
system, and the constraints that affect the way in which architectural design patterns can be applied.
 It defines the relationship between major structural elements of the software. It is about decomposing
the system into interacting components. It is expressed as a block diagram defining an overview of
the system structure – features of the components and how these components communicate with each
other to share data. It defines the structure and properties of the component that are involved in the
system and also the inter-relationship among these components.

Interface Design
 The interface design describes how the software communicates within itself, with systems that
interoperate with it, and with humans who use it.
 An interface implies a flow of information (e.g., data and/or control) and a specific type of behavior.
 Therefore, data and control flow diagrams provide much of the information required for interface
design.
 It represents how the Software communicates with the user i.e. the behavior of the system. It refers to
the product where user interact with controls or displays of the product.
 For example, Military, vehicles, aircraft, audio equipment, computer peripherals are the areas where
user interface design is implemented. UI design becomes efficient only after performing usability
testing. This is done to test what works and what does not work as expected. Only after making the
repair, the product is said to have an optimized interface.

13
Component-Level Design
 The component-level design transforms structural elements of the software architecture into a
procedural description of software components.
 Information obtained from the PSPEC, CSPEC, and STD serve as the basis for component design.
 It transforms the structural elements of the software architecture into a procedural description of
software components. It is a perfect way to share a large amount of data. Components need not be
concerned with how data is managed at a centralized level i.e. components need not worry about
issues like backup and security of the data.

Fig: Component diagram

Principles of Design Model

 Design must be traceable to the analysis model:

Analysis model represents the information, functions, and behavior of the system. Design model
translates all these things into architecture – a set of subsystems that implement major functions and a
set of component kevel design that are the realization of Analysis classes. This implies that design
model must be traceable to the analysis model.

 Always consider architecture of the system to be built:

Software architecture is the skeleton of the system to be built. It affects interfaces, data structures,
behavior, program control flow, the manner in which testing is conducted, maintainability of the
resultant system, and much more.

 Focus on the design of the data:

Data design encompasses the manner in which the data objects are realized within the design. It helps
to simplify the program flow, makes the design and implementation of the software components
easier, and makes overall processing more efficient.

14
 User interfaces should consider the user first:

The user interface is the main thing of any software. No matter how good its internal functions are or
how well designed its architecture is but if the user interface is poor and end-users don’t feel ease to
handle the software then it leads to the opinion that the software is bad.

 Components should be loosely coupled:

Coupling of different components into one is done in many ways like via a component interface, by
messaging, or through global data. As the level of coupling increases, error propagation also increases,
and overall maintainability of the software decreases. Therefore, component coupling should be kept
as low as possible.

 Interfaces both user and internal must be designed:

The data flow between components decides the processing efficiency, error flow, and design
simplicity. A well-designed interface makes integration easier and tester can validate the component
functions more easily.

 Component level design should exhibit Functional independence:

It means that functions delivered by component should be cohesive i.e. it should focus on one and

only one function or sub-function.

4. EFFECTIVE MODULAR DESIGN

A modular design reduces complexity facilitates change and results in easier implementation by
encouraging parallel development of different parts of a system.
a) Functional Independence
 Functional independence is a direct outgrowth of modularity and the concepts of abstraction and
information hiding.
Functional Independence = Modularity + Abstraction + Information Hiding

 Functional independence is achieved by developing modules with "single-minded" function and an

"aversion" to excessive interaction with other modules.
 Functional independence is a key to good design, and design is the key to software quality.
 Independence is measured using two qualitative criteria: cohesion and coupling.
 Cohesion is a measure of the relative functional strength of a module.
15
  Coupling is a measure of the relative interdependence among modules.

b) Cohesion
 Cohesion is a natural extension of the information hiding concept. A cohesive module performs a
single task within a software procedure, requiring little interaction with procedures being performed in
other parts of a program.
Types of cohesion are:
Coincidental Cohesion:
A module that performs a set of tasks that relate to each other loosely, if at all.
Logical Cohesion:
A module that performs tasks that are related logically (e.g.,a module that produces all output
regardless of type)
Temporal Cohesion:
When a module contains tasks that all must be executed with the same span of time, the module exhibits.
Procedural Cohesion:
When processing elements of a module are related and must be executed in a specific order.
Communicational Cohesion:
When all processing elements concentrate on one area of a data structure.

c) Coupling
 Coupling is a measure of interconnection among modules in a software structure.
 Types of coupling are:
Content Coupling:
o Occurs when one component “secretly modifies data that is internal to another component”.

GLOBAL DATA AREA

L

A K

B C
M

D E F N O P

o In figure 4, Modules B and D are content coupled.

Fig 4: Content and common coupling

Common Coupling:
o Occurs when a number of components all make use of a global variable.
o In figure 4, Modules C and N are common coupled.
Control Coupling:
o Occurs when operation A () invokes operation B() and passes a control flag to B.

16
 o The control flag then “directs” logical flow within B.

Module 1

Flag
Module 2

Flag
Flag
C

B
Fig 5: Control Coupling
o In figure 5, when Module 1 passes the control flag to Module 2, Module 1 and Module 2
are said to be control coupled.

Stamp Coupling:
o Occurs when class B is declared as a type for an argument of an operation of class A.
Data Passed
Via Argument List
Module 2 (Data Coupling)

No Direct Coupling Module 3

Module 1

Data Structure Module 4

Passed via Argument List
(Stamp Coupling)
Fig 6: No Direct, Data and Stamp Coupling

17
 o In Figure 6, data structure is passed between Modules 1 and 4. Therefore, Module 1
and Module 4 is stamp coupled.

Data Coupling:
o Occurs when operation pass long strings of data arguments.
o The “bandwidth” of communication between classes and components grows and the
complexity of the interface increases.
o In figure 6, Module 1 and module 3 are data coupled.

No Direct Coupling:
o Two modules are said to be ‘no direct coupled’ if they are independent of each other.
o In figure 6, Module 1 and Module 2 are not directly coupled.
Routine Call Coupling:
o Occurs when one operation invokes another.
o It increases the connectedness of a system.
Type Use Coupling:
o Occurs when component A uses a data type defined in component B.
Inclusion or Import Coupling:
o Occurs when component A imports or includes a package or the content of
component B.
External Coupling:
o Occurs when a component communicates or collaborates with infrastructure
components.

5. DESIGN HEURISTICS
Heuristic
The Main goal of Heuristics evaluation is to identify any problems associated with the
design of user interfaces. Usability Consultant Jakob Nielson developed this method on
the basis of several years of experience in teaching and consulting about usability
engineering.
Heuristics evaluation are one of the most informal methods of usability inspection in the
field of Human Computer Interaction.
Once program structure has been developed, effective modularity can be achieved by
applying the design concepts. The program structure can be manipulated according to the
following set of heuristics:

1. Evaluate the "first iteration" of the program structure to reduce coupling and
improve cohesion..
2. Attempt to minimize structures with high fan-out; strive for fan-in as depth
18
increases.

19
 Fig 7: Program Structures

3. Keep the scope of effect of a module within the scope of control of that module.
The scope of effect of module e is defined as all other modules that are affected by a decision made in module
e. The scope of control of module e is all modules that are subordinate and ultimately subordinate to module e.
Referring to Figure 7, if module e makes a decision that affects module r, we have a violation of this heuristic,
because module r lies outside the scope of control of module e.

4. Evaluate module interfaces to reduce complexity and redundancy and improve consistency.
Module interface complexity is a prime cause of software errors. Interfaces should be designed to pass
information simply and should be consistent with the function of a module.

5. Define modules whose function is predictable, but avoid modules that are overly restrictive.
6. Strive for “controlled entry” modules by avoiding "pathological connections."
Software is easier to understand and therefore easier to maintain when module interfaces are constrained and
controlled. Pathological connection refers to branches or references into the middle of a module.

20
6. ARCHITECTURAL DESIGN

ARCHITECTURE DESIGN
Effective software architecture and its explicit representation and design have become dominant themes in
software engineering.

What Is Architecture?
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.

For deriving the architecture, horizontal and vertical partitioning are required

Horizontal Partitioning
 Horizontal Partitioning define separate branches of the module hierarchy for
each majorfunction
 This use control modules to coordinate communication betweenfunctions

Fig: Horizontal Partitioning

Vertical Partitioning
 Vertical partitioning suggests the control and work should be distributed
top- down in theprogram structure.
 The decision making modules should reside at the top of the architecture

21
 Fig: Vertical Partitioning
Architectural Design:

 Use an architectural context diagram (ACD) that shows

– The identification and flow of all information into and out of a system
– The specification of all interfaces
– Any relevant support processing from/by other systems
 An ACD models the manner in which software interacts with entities external to its boundaries
 An ACD identifies systems that interoperate with the target system
– Super-ordinate systems
 Use target system as part of some higher level processing scheme
– Sub-ordinate systems
 Used by target system and provide necessary data or processing
– Peer-level systems
 Interact on a peer-to-peer basis with target system to produce or consume data
– Actors
 People or devices that interact with target system to produce or consume data
.Architectural Design Process For Safe Home System
Architectural Design Steps
1) Represent the system in context
2) Define archetypes
3) Refine the architecture into components

22
 4) Describe instantiations of the system
1. Represent the System in Context
 To represent the system in context an architectural context diagram
(ACD) is used thatshows
– The identification and flow of all information into and out of a system
– Any relevant support processing from other systems
 An ACD models in such a way that the software interacts with
entities external to itsboundaries
 An ACD identifies systems that interoperate with the target system
– Super-ordinate systems are systems that use the target system as part
of some higherlevel processing scheme
– Sub-ordinate systems are systems that are used by target system
and providenecessary data or processing

– Peer-level systems are those systems that interact on a peer-to-

peer basis with targetsystem to produce or consume data
– Actors are the people or devices that interact with target system
to produce orconsume data
-The specification of all interfaces

23
 Fig: Architectural context diagra

2. Define Archetypes
 Archetypes indicate the abstractions within the problem domain.
 An archetype is a class or pattern that represents a core abstraction that is critical
to thedesign of an architecture for the target system
 It includes a common structure and class-specific design strategies and a collection
ofexample program designs and implementations

 Only a relatively small set of archetypes is required in order to design

even relatively complex systems
 The target system architecture is composed of the searche types
o
They represent stable elements of the architecture
o
They may be instantiated in different ways based on the behavior of thesystem
o
They can be derived from the analysis class model
 The archetypes and their relationships can be illustrated in the fig below

24
 Fig: UML Class diagram

3. Refine the Architecture into Components

 The architectural designer refines the software architecture into components to describe
theoverall structure and architectural style of the system
 These components are derived from various sources
o
The application domain provides components, which are the domain classes
in theanalysis model that represent entities in the real world
o
The infrastructure domain provides design components that
enable applicationcomponents but have no business connection
 Examples: memory management, communication, database,
and taskmanagement
o
The interfaces in the ACD imply one or more specialized components
that processthe data that flow across the interface

A UML class diagram can represent the classes of the refined architecture and their
relationships

25
4. Describe Instantiations of the System
 An actual instantiation of the architecture is developed by applying it to a specific problem
 This demonstrates that the architectural structure, style and components are appropriate
 A UML component diagram can be used to represent the instantiation of the system.

Fig: Refined Component diagra

26
 7. ARCHITECTURAL STYLES

The software that is built for computer-based systems also exhibits one of many 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’s and
cooperation” among components;
(3) Constraints that define how components can be integrated to form the system;
(4) Semantic models that enable a designer to understand the overall properties of
a system by analyzing the known properties of its constituent parts.

 Architectural styles can be categorized into:

1) Data-centered architectures
2) Data-flow architectures
3) Call and return architectures
4) Object-oriented architectures
5) Layered architectures

1) Data-centered architectures:
 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.
 Data-centered architectures promote integrability. That is, existing components can be changed and new client
components can be added to the architecture without concern about other clients.

27
 Fig 8: Data-Centered Architecture

2) Data-flow architectures

Fig 9: Data Flow Architectures

 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.
 Filter works independently of those components upstream and downstream, is designed to expect data input of
a certain form, and produces data output of a specified form.
 If the data flow degenerates into a single line of transforms, it is termed batch sequential.
28
3) Call and return architectures:
 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:
1) Main program/subprogram architectures.
2) Remote procedure call architectures
• Main program/subprogram architectures
This 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.
• Remote procedure call architectures
The components of a main program/ subprogram architecture are distributed across multiple computers on a
network.

4) 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 is accomplished via message passing.

5) Layered architectures:

29
 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.

8. Architectural Mapping Using Data Flow

Structured design provides a convenient transition from a data flow diagram to software
Architecture
Types of information flow

The 2 different types of information flows:

1. transaction flow - a single data item triggers information flow along one of many paths
2. transform flow
o
overall data flow is sequential and flows along a small number of straight line paths
o
Incoming Flow: The paths that transform the external data into an internal form
o
Transform Center: The incoming data are passed through a transform
center andbegin to move along paths that lead it out of the software
o
Outgoing Flow: The paths that move the data out of the software

Fig: Types of Information flow

30
TRANSFORM MAPPING:

Transform mapping is a set of design steps that allows a DFD with transform flow
characteristics to be mapped into a specific architectural style.
Consider an example of secure home system. To represent in transform mapping the
following steps should be considered.

Step 1: Review the fundamental system model

The fundamental system model encompasses the level 0 DFD and supporting information.
The design step begins with an evaluation of both the System Specification and the Software
Requirements Specification.
Both documents describe information flow and structure at the software interface.
Figures 11 and 12 depict level 0 and level 1 data flow for the SafeHome software.

Fig 11: Context Level DFD for Safehome

31
 Fig 12: Level 1 DFD For Safehome

Step 2: Review and refine data flow diagrams for the software

The data flow diagrams are analyzed and refined into next higher levels. Each
transform in the data flow diagram exhibits relatively high cohesion.That means after
applying the certain transformation the process in the DFD performs a single distinct
function.
For example, the level 2 DFD for monitor sensors fig 13 is examined, and a level 3 data
flow diagram is derived as shown in Fig 14.

Step 3: Determine whether the DFD has transform or transaction flow characteristics

The information flow within a system can always be represented as transform. However,
there can be dominance of transaction characteristics in the DFD.
Based on the characteristics of the DFD the transformation or transaction flow is
decided. Evaluating the DFD (Figure 14), we see data entering the software along one
incoming path and exiting along three outgoing paths.
No distinct transaction center is implied. Therefore, an overall transform characteristic
will be assumed for information flow.

32
 Fig 13: Level 2 DFD After Refinement

Fig 14: Level 3 DFD For Monitor Sensors With Flow Boundaries

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

In this design step, the reasonable boundaries are selected and it is avoided to apply lengthy
iterations on placement of divisions.
Incoming and Outgoing flow boundaries are open to interpretation.

Step 5: Perform "first-level factoring."

After performing the first level factoring the program structure results in top down architecture
where
o Top-level modules perform decision making
o Low-level modules perform most input, computation, and output work
o Middle-level modules perform some control and do some amount of work.

When transform flow is identified, a DFD is mapped to a specific structure (a call and
return architecture) that provides control for incoming, transform, and outgoing
information processing.

Fig 15: First-Level Factoring For Monitor Sensors

34
 Fig 16: Second-Level Factoring For Monitor Sensors
Step 6: Perform "second-level factoring."
Second-level factoring is accomplished by mapping individual transforms (bubbles) of a DFD
into appropriate modules within the architecture.
There could be one- to-one mapping of bubble of DFD into the software module or two or three
bubbles can be combined together to form a single software module.
After performing the second level factoring the architecture serves as the first iteration design.

Step 7: Refine the first-iteration architecture using design heuristics for improved software
quality
First-iteration architecture can always be refined by applying concepts of module independence.
The modules can be exploded or imploded with good cohesion, minimal coupling.
The refinement should be such that the structure can be implemented without confusion and can
be easily maintained.

35
TRANSACTION MAPPING
A single data item triggers one or a number of information flows that effect a function
implied by the triggering data item.

Design Steps for Transaction Mapping:

Step 1: Review the fundamental system model
The fundamental system model encompasses the level 0 DFD and supporting
information.
The design step begins with an evaluation of both the System Specification and the
Software Requirements Specification.

Step 2: Review and refine data flow diagrams for the software
The data flow diagrams are analyzed and refined into next higher levels. Each transform
in the data flow diagram exhibits relatively high cohesion.
That means after applying the certain transformation the process in the DFD performs a
single distinct function.

Step 3: Determine whether the DFD has transform or transaction flow characteristics
The information flow within a system can always be represented as transform. However,
there can be dominance of transaction characteristics in the DFD.
Based on the characteristics of the DFD the transformation or transaction flow is decided.

Step 4: Identify the transaction center and the flow characteristics along each of the action
paths
In transaction mapping we have to identify the location of transaction centre.
From the transaction centre many action paths flow radially from it.

Step 5: Map the DFD into transaction processing structure

The identified transaction flow is mapped into an architecture that contains an incoming
branch and a dispatcher branch.
Starting from the transaction centre the corresponding bubbles on incoming path are
mapped into the appropriate modules.

36
 Fig 17: Transaction Mapping

The bubbles along the action path are mapped into the action modules.
Step 6: Factor and refine the transaction structure and the structure of
each action path. Each action path of the data flow diagram has its own
information flow characteristics. The action path-related "substructure"
is developed.
Substructure serves as first iteration architecture.

Step 7: Refine the first-iteration architecture using design heuristics for

improved software quality
The first iteration architecture can be refined by applying the module
independency. The modules can be exploded or imploded with high
cohesion and minimum coupling.
The refinement should be such that the structure can be implemented
without difficulty, tested without confusion and can be easily
maintained.
User Interface Design – Software Engineering


The user interface is the front-end application view to which the user interacts to use the
software. The software becomes more popular if its user interface is:
1. Attractive
2. Simple to use
3. Responsive in a short time
4. Clear to understand

37
 5. Consistent on all interface screens
Types of User Interface
1. Command Line Interface: The Command Line Interface provides a command
prompt, where the user types the command and feeds it to the system. The user
needs to remember the syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides a simple interactive
interface to interact with the system. GUI can be a combination of both hardware
and software. Using GUI, the user interprets the software.
User Interface Design Process

User Interface Design Process

The analysis and design process of a user interface is iterative and can be represented by a
spiral model. The analysis and design process of user interface consists of four framework
activities.
1. User, Task, Environmental Analysis, and Modeling
Initially, the focus is based on the profile of users who will interact with the system, i.e.,
understanding, skill and knowledge, type of user, etc., based on the user’s profile users are
made into categories. From each category requirements are gathered. Based on the
requirement’s developer understand how to develop the interface. Once all the requirements
are gathered a detailed analysis is conducted. In the analysis part, the tasks that the user
performs to establish the goals of the system are identified, described and elaborated. The
analysis of the user environment focuses on the physical work environment. Among the
questions to be asked are:
1. Where will the interface be located physically?
2. Will the user be sitting, standing, or performing other tasks unrelated to the
interface?
3. Does the interface hardware accommodate space, light, or noise constraints?
4. Are there special human factors considerations driven by environmental factors?
2. Interface Design
The goal of this phase is to define the set of interface objects and actions i.e., control
mechanisms that enable the user to perform desired tasks. Indicate how these control
mechanisms affect the system. Specify the action sequence of tasks and subtasks, also called

38
a user scenario. Indicate the state of the system when the user performs a particular task.
Always follow the three golden rules stated by Theo Mandel. Design issues such as response
time, command and action structure, error handling, and help facilities are considered as the
design model is refined. This phase serves as the foundation for the implementation phase.
3. Interface Construction and Implementation
The implementation activity begins with the creation of a prototype (model) that enables
usage scenarios to be evaluated. As iterative design process continues a User Interface toolkit
that allows the creation of windows, menus, device interaction, error messages, commands,
and many other elements of an interactive environment can be used for completing the
construction of an interface.
4. Interface Validation
This phase focuses on testing the interface. The interface should be in such a way that it
should be able to perform tasks correctly, and it should be able to handle a variety of tasks. It
should achieve all the user’s requirements. It should be easy to use and easy to learn. Users
should accept the interface as a useful one in their work.
User Interface Design Golden Rules
The following are the golden rules stated by Theo Mandel that must be followed during the
design of the interface. Place the user in control:
1. Define the interaction modes in such a way that does not force the user into
unnecessary or undesired actions: The user should be able to easily enter and
exit the mode with little or no effort.
2. Provide for flexible interaction: Different people will use different interaction
mechanisms, some might use keyboard commands, some might use mouse, some
might use touch screen, etc., Hence all interaction mechanisms should be
provided.
3. Allow user interaction to be interruptible and undoable: When a user is doing
a sequence of actions the user must be able to interrupt the sequence to do some
other work without losing the work that had been done. The user should also be
able to do undo operation.
4. Streamline interaction as skill level advances and allow the interaction to be
customized: Advanced or highly skilled user should be provided a chance to
customize the interface as user wants which allows different interaction
mechanisms so that user doesn’t feel bored while using the same interaction
mechanism.
5. Hide technical internals from casual users: The user should not be aware of the
internal technical details of the system. He should interact with the interface just
to do his work.
6. Design for direct interaction with objects that appear on-screen: The user
should be able to use the objects and manipulate the objects that are present on the
screen to perform a necessary task. By this, the user feels easy to control over the
screen.
Key Principles for Designing User Interfaces
1. User-centered design: User interface design should be focused on the needs and
preferences of the user. This involves understanding the user’s goals, tasks, and
context of use, and designing interfaces that meet their needs and expectations.

39
 2. Consistency: Consistency is important in user interface design, as it helps users to
understand and learn how to use an application. Consistent design elements such
as icons, color schemes, and navigation menus should be used throughout the
application.
3. Simplicity: User interfaces should be designed to be simple and easy to use, with
clear and concise language and intuitive navigation. Users should be able to
accomplish their tasks without being overwhelmed by unnecessary complexity.
4. Feedback: Feedback is significant in user interface design, as it helps users to
understand the results of their actions and confirms that they are making progress
towards their goals. Feedback can take the form of visual cues, messages, or
sounds.
5. Accessibility: User interfaces should be designed to be accessible to all users,
regardless of their abilities. This involves considering factors such as color
contrast, font size, and assistive technologies such as screen readers.
6. Flexibility: User interfaces should be designed to be flexible and customizable,
allowing users to tailor the interface to their own preferences and needs

Component Based

A component is a modular, portable, replaceable, and reusable set of well-defined

functionality that encapsulates its implementation and exporting it as a higher-level interface.

A component is a software object, intended to interact with other components, encapsulating

certain functionality or a set of functionalities. It has an obviously defined interface and
conforms to a recommended behavior common to all components within an architecture.

A software component can be defined as a unit of composition with a contractually specified

interface and explicit context dependencies only. That is, a software component can be
deployed independently and is subject to composition by third parties.

Views of a Component

A component can have three different views − object-oriented view, conventional view, and
process-related view.

Object-oriented view

A component is viewed as a set of one or more cooperating classes. Each problem domain
class (analysis) and infrastructure class (design) are explained to identify all attributes and
operations that apply to its implementation. It also involves defining the interfaces that enable
classes to communicate and cooperate.

Conventional view

40
 It is viewed as a functional element or a module of a program that integrates the 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.

Process-related view

In this view, instead of creating each component from scratch, the system is building from
existing components maintained in a library. As the software architecture is formulated,
components are selected from the library and used to populate the architecture.

 A user interface (UI) component includes grids, buttons referred as controls, and
utility components expose a specific subset of functions used in other components.
 Other common types of components are those that are resource intensive, not
frequently accessed, and must be activated using the just-in-time (JIT) approach.
 Many components are invisible which are distributed in enterprise business
applications and internet web applications such as Enterprise JavaBean (EJB), .NET
components, and CORBA components.

Characteristics of Components

 Reusability − Components are usually designed to be reused in different situations in

different applications. However, some components may be designed for a specific
task.
 Replaceable − Components may be freely substituted with other similar components.
 Not context specific − Components are designed to operate in different environments
and contexts.
 Extensible − A component can be extended from existing components to provide new
behavior.
 Encapsulated − A A component depicts the interfaces, which allow the caller to use
its functionality, and do not expose details of the internal processes or any internal
variables or state.
 Independent − Components are designed to have minimal dependencies on other
components.

Principles of Component−Based Design

A component-level design can be represented by using some intermediary representation (e.g.

graphical, tabular, or text-based) that can be translated into source code. The design of data
structures, interfaces, and algorithms should conform to well-established guidelines to help us
avoid the introduction of errors.

 The software system is decomposed into reusable, cohesive, and encapsulated

component units.

41
  Each component has its own interface that specifies required ports and provided ports;
each component hides its detailed implementation.
 A component should be extended without the need to make internal code or design
modifications to the existing parts of the component.
 Depend on abstractions component do not depend on other concrete components,
which increase difficulty in expendability.
 Connectors connected components, specifying and ruling the interaction among
components. The interaction type is specified by the interfaces of the components.
 Components interaction can take the form of method invocations, asynchronous
invocations, broadcasting, message driven interactions, data stream communications,
and other protocol specific interactions.
 For a server class, specialized interfaces should be created to serve major categories
of clients. Only those operations that are relevant to a particular category of clients
should be specified in the interface.
 A component can extend to other components and still offer its own extension points.
It is the concept of plug-in based architecture. This allows a plugin to offer another
plugin API.

Designing Traditional Components

Designing Traditional Components
 Introduction : Traditional components are designed based on different constructs like
 Sequence,
 Condition,
 Repetition.
Sequence implements processing steps that are essential in the specification of any
algorithm.
Condition provides the facility for selected processing based on some logical
occurrence.

42
 Repetition allows for looping.
These three constructs are fundamental to structured programming— an
important component-level design technique.
The use of the structured constructs reduces program complexity and thereby
enhances readability, testability, and maintainability.
The use of a limited number of logical constructs also contributes to a human
understanding process that psychologists call chunking.
Graphical Design Notation
 A picture is worth a thousand words,” but it’s rather important to know which
picture and which 1000 words.
 There is no question that graphical tools, such as the UML activity diagram or
the flowchart, provide useful pictorial patterns that readily depict procedural detail.
 The activity diagram allows you to represent sequence, condition, and
repetition— all elements of structured programming.
 It is a descendent of an earlier pictorial design representation (still used
widely) called a flowchart.
 A flowchart, like an activity diagram, is quite simple pictorially. A box is used
to indicate a processing step. A diamond represents a logical condition, and arrows show the
flow of control

Tabular Design Notation

 In many software applications, a module may be required to evaluate a
complex combination of conditions and select appropriate actions based on these conditions.
 Decision tables provide a notation that translates actions and conditions into a
tabular form.
 The table is difficult to misinterpret and may even be used as a machine-
readable input to a table-driven algorithm.

43
 Program Design Language
 Program design language (PDL), also called structured English or
pseudocode,
 It incorporates the logical structure of a programming language with the free-
form expressive ability of a natural language (e.g., English).
 Narrative text (e.g., English) is embedded within a programming language-like
syntax.
 Automated tools can be used to enhance the application of PDL.
 A basic PDL syntax should include constructs for
 Component definition,
 Interface description,
 Data declaration,
 Block structuring,
 Condition constructs,
 Repetition constructs,
 Input-output (I/O) constructs.

44