UNIT- III

DESIGN PHASE
 Basic Design sub-Phases

There are basically 4 sub-phases in the design

phase of software engineering, they are as follows

 Data design.
 Architectural design.
 Interface design.
 Procedural design.
Procedural
design

Interface
design

Architectural
design

Data
design

Fig. 4.5 Design Model

 Design Concepts
• Problem Partitioning
• Information Hiding
• Abstraction
• Modularity
• Refinement
Problem Partitioning

 Horizontal Partitioning : Defines separate branches of

the modular hierarchy for each major program
function.

 Partitioning the architecture horizontally

provides a number of distinct benefits:
• software that is easier to test
• software that is easier to maintain
• propagation of fewer side effects
• software that is easier to extend
Horizontal Partitioning
Vertical Partitioning
 Vertical Partitioning: Called factoring that control and
work should be distributed top-down in the program
structure.

 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.
Vertical Partitioning
Information Hiding
 How to achieve modularity: Apply information hiding
principle and approach
 What is the information hiding
 In modularisation context: Components hides the
internal details and processing from one another
 In more general context: grouping and packaging the
elements and internal details of an abstraction (a
component, an abstract data type, a class or a object
etc ) and making those details inaccessible
 Also called data hiding or encapsulation
 Information Hiding

Example: Abstract data type - Stack

 Abstract methods
• create :: Void  Stack a
• destroy :: Stack a  Void
• is_empty :: Stack a  boolean
• top :: Stack  Element
• push :: (Stack,Element)  Stack
• pop :: Stack  Stack
 Access to the stack only via the above methods. The users
(such as a class or a component) only care about the
interface (i.e., the above methods) of the data
 And neither know , nor care, how the stack is implemented
(information hiding). Any change of the implementation has
no effect on the users
 Information Hiding
Why information hiding in design: each component hides a design
decision from the others to achieve
 Changeability
 If a design decision is changed, such as a data structure,
changes are confined to as few components as possible whereas
the design as a whole can remain intact
 Independent development
 Enable independent development as far as the interfaces
between components are simple and well defined. Also access
methods are often simpler than access data
 Comprehensibility
 For design, debug, testing and maintenance, it is vital to
understand each component independently of others. Information
hiding improves our understanding by eliminating confusing from
unrelated functions and data.
Information Hiding
How to achieve information hiding
 Apply the information hiding principle in design
 Aiming at the end of the design process, any data structure or
file is accessed only via certain well-defined specific methods
(interfaces)
 Separation of interface and implementation
 Separating interface and implementation involves defining a
component by specifying a public interface, separate from (or
hid) the details of how the component is realized.
 Choose programming languages support Information hiding
 Such as Java, C++, C#, Visual Basic, .Net
Abstraction
 An abstraction of a component describes the
external behavior of that component without
bothering with the internal details that
produces the behavior.

 "A view of a problem that extracts the

essential information relevant to a particular
purpose and ignores the remainder of the
information." -- [IEEE, 1983]
 During software design , abstraction allows the s/w designer
to organize and channel his thoughts and ideas of solution
without going in to the details of implementation like detailed
algorithmic considerations.
 Three widely used abstraction mechanisms are: -

I) Functional abstraction: - A module is specified by the function it

performs.

For example, a module to compute the log of a value can be abstractly

represented by the function log.
II) Data abstraction :- A data abstraction is a named collection of data
that describes a data object.

Here the abstract data objects are presented with a set of legal
operations but the actual representation and implementation details are
hidden.
The externally visible functions are provided with the abstract data
objects so that the values of the data object can be modified.

III) Control abstraction :- It’s the process of controlling the execution

method of the program under consideration by providing some
statements for controlling the path of execution. Here the actual
implementation of the change in execution path is hidden.
For example : Exception handlers
 While decomposing, we consider the top level to be the most
abstract, and as we move to lower levels, we give more details about
each component.

 The basic goal of system design is to specify the modules in a

system and their abstractions. Once the different modules are
specified, during the detailed design the designer can concentrate on
one module at a time.
 Abstraction is used for existing components as well as components
that are being designed. Abstraction of existing components plays
an important role in the maintenance phase.

 To modify a system, the first step is understanding

what the system does and how. The process of comprehending an
existing system involves identifying the abstractions of subsystems
and components from the details of their implementations.

Using these abstractions, the behavior of the entire system can be

understood.
Modularity
 Modularity
 A system is considered modular if it consists of
discreet components so that each component can be
implemented separately, and a change to one
component has minimal impact on other components.

 Modularity helps in
- system debugging—isolating the system problem
to a component is easier if the system is modular

- system repair—changing a part of the system is

easy as it affects few other parts.

- system building—a modular system can be easily

built by "putting its modules together."
 A software system cannot be made modular
by simply chopping it into a set of modules.
For modularity, each module needs to support
a well defined abstraction and have a clear
interface through which it can interact with
other modules.
Functional Independence
 Functional independence is achieved by
developing modules with “single minded”
function and “aversion to excessive
interaction with other modules.

 Functional independence is the key to good

design and design is the key to software
quality.
Independence is measured using two qualitative criteria :

 Coupling

 Cohesion
Coupling

What are Coupling

 Coupling is a term to describe the interactions between
components. The lower coupling, the less interaction (i.e., the
more independence ) between components
Design Principle: Minimise Coupling
 Coupling connections cause dependencies between components,
which, in turn, have an impact on system qualities such as
maintainability (a modification of a components may require
modifications to its connected components) or testability (a fault in
one components may cause a failure in a completely different,
connected components). Thus, a common design principle is to
minimize coupling.
Definition of Coupling
 Coupling is the measure of interconnection
among modules in a s/w structure.

 The more we must know about module A in

order to understand module B the more
closely connected A is to B.
Levels of coupling
 Data coupling
 Stamp coupling Low Level coupling
 Control coupling
 External coupling
 Common coupling
 Content coupling High Level coupling
Levels of coupling
 Data coupling : it occurs when simple or elementary data
are passed between modules.
 Stamp coupling : Stamp coupling is when modules share
a composite data structure and use only a part of it, possibly a
different part (e.g. passing a whole record to a function which
only needs one field of it).
 Control coupling : it occurs when a “control flag” (a
variable that controls decisions in a subordinate or
superordinate module) is passed between modules.
 External coupling : Relatively high levels of coupling occur when
modules are tied to an environment external to software. For example,
I/O couples a module to specific devices, formats, and communication
protocols.
 Common coupling : it occurs when a number of modules reference a
global data area.
(e.g., a disk file or a globally accessible memory area)
 Content coupling : The highest degree of coupling, occurs when one
module makes use of data or control information maintained within the
boundary of another module.
Secondarily, content coupling occurs when branches are made into the
middle of a module. This mode of coupling can and should be avoided.
 Design Principle – Coupling and Cohesion

What are Cohesion

 Cohesion is a term to describe the interactions within components.
The more cohesive a component, the more related the internal parts
of the component to each other and to its whole purpose
Design Principle: Maximise Cohesion
 A low cohesive design element has been assigned many unrelated
responsibilities. Consequently, the design element is more difficult to
understand and therefore also harder to maintain and reuse. Design
elements with low cohesion should be considered for refactoring, for
instance, by extracting parts of the functionality to separate classes
with clearly defined responsibilities.
 Cohesion
 It’s the measure of the strength of binding between
the elements in a module.

There are following types of cohesion: -

 Coincidental cohesion. Lowest
 Logical cohesion.
 Temporal cohesion.
 Communication cohesion.
 Sequential cohesion.
 Functional cohesion.
 Informational cohesion. Highest
 Coincidental cohesion (worst)
Coincidental cohesion is when parts of a module are
grouped arbitrarily (at random); the parts have no
significant relationship
(e.g. a module of frequently used mathematical functions).

 Logical cohesion
Logical cohesion is when parts of a module are grouped
because they logically are categorised to do the same
thing, even if they are different by nature.
(e.g. grouping all I/O handling routines).
 Communicational cohesion
Communicational cohesion is when parts of a module are
grouped because they operate on the same data
(e.g. a module which operates on the same record of
information).

 Sequential cohesion
Sequential cohesion is when parts of a module are grouped
because the output from one part is the input to another part.
(e.g. a function which reads data from a file and processes the
data).
 Temporal cohesion
Temporal cohesion is when parts of a module are grouped by when they are
processed - the parts are processed at a particular time in program
execution
(e.g. a function which is called after catching an exception which closes
open files, creates an error log, and notifies the user).
 Procedural cohesion
Procedural cohesion is when parts of a module are grouped because they
always follow a certain sequence of execution (e.g. a function which
checks file permissions and then opens the file).
 Functional cohesion (best)
Functional cohesion is when parts of a module are
grouped because they all contribute to a single well-
defined task of the module
(e.g. calculating the sine of an angle).

 Informational cohesion
It occurs when a module contains a complex data
structure and functions to manipulate it. All the
functions in this module will show functional binding.
Information cohesion is the concrete realization of
abstraction.
Cohesion
The different degree of cohesion in order

High Cohesion

Functional
Sequential
Communication
Procedural
Temporal
Logical
Low Cohesion Coincidental
 Functional cohesion is the strongest cohesion.

 In a functionally bound module, all the elements of

the module are related to performing a single
function.

 Functions like "compute square root" and "sort the

array" are clear examples of functionally cohesive
modules.
 Design Principle – Coupling and Cohesion

Last Note about Cohesion

 The goal
 In design, to put objects and actions together only when
have one common and sensible purpose
 The limitation
 It is not always to achieve the best cohesion such as
Functional Cohesion but try to achieve as cohesive as
realistic
 In fact, it is not always possible even to classify the
cohesive level for a component.
How does one determine the cohesion level of a
module?
 A useful technique for determining if a module has functional cohesion is
to write a sentence that describes, fully and accurately, the function or
purpose of the module.

The following tests can then be made

1. If the sentence must be a compound sentence, if it contains a comma, or

it has has more than one verb, the module is probably performing more
than one function, and it probably has sequential or communicational
cohesion.

2. If the sentence contains words relating to time, like "first," "next,“ "when,"
and "after" the module probably has sequential or temporal cohesion.

3. If the predicate of the sentence does not contain a single specific object
following the verb (such as "edit all data") the module probably has
logical cohesion.

4. Words like "initialize" and "cleanup" imply temporal cohesion.

 Modules with functional cohesion can always be
described by a simple sentence.

 However, if a description is a compound sentence, it

does not mean that the module does not have functional
cohesion.

 Functionally cohesive modules can also be described by

compound sentences. If we cannot describe it using a
simple sentence, the module is not likely to have
functional cohesion.
 The goal of modularizing a software system
using the coupling and cohesion criteria is to
produce systems that have stamp and data
coupling between the modules and functional
and informational cohesion of elements within
each module.
main ()
{
int array[100], size, i,j,tmp;
scanf("%d",&size);
for (i=0; i<size; i++)
scanf("%d",&array[i]);
for (i=0; i<size-1; i++)
for (j=size-1; j>i; j--)
{
if (array[j] < array[j-1])
{ tmp = array[j];
array[j] = array[j-1];
array[j-1] = tmp;
}
}
for (i=0; i<size; i++)
printf("%d ",array[i]);
printf ("\n");
}
 /* Main "first" reads the data,"then" sorts the
data, and "after" writes the data =>
SEQUENTIAL COHESION
 But main "does everything" => LOW
COHESION In general, the body could get
long => make procedures Array is STATIC
and always INTEGER. No other procedures
=> no coupling or interaction*/
DESIGN HEURISTICS FOR EFFECTIVE
MODULARITY
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 increases.

3. Keep the scope of effect of a module within the

scope of control of that module.
DESIGN HEURISTICS FOR EFFECTIVE
MODULARITY
4. Evaluate module interfaces to reduce complexity
and redundancy and improve consistency.

5. Define modules whose function is predictable,

but avoid modules that are overly restrictive.

6. Strive for “controlled entry” modules by avoiding

"pathological connections."
Design Notations
Introduction to Data Flow Diagrams

 Basic Constructs:

 Processes

 Data flows

 Files

 External Entities: sources or sinks

The Interrelation Between Specification
Components
Example of a Data Flow Diagram(2)
Introduction to Data Flow Diagrams (cont.)
 Constructing Data Flow Diagrams

 Identify the Static Components

 Identify the Main Processes

 Expand and Refine the Diagram

 Review the Diagram

Introduction to Data Flow Diagrams (cont.)
 Levelling Data Flow Diagrams
 The Concept of Levelling
 Levelling Conventions
 Process Referencing
 Functional Primitives
 Balancing

 Hints on Data Flow Diagramming

 Annotation of Diagrams
 Extent of Decomposition
 Extent of Partitioning
 Check for Usefuleness
Example of a Data Flow Diagram(1)
The Structure of a Set of
Levelled DFDs
Context Diagram
Decomposition Level: 0
Diagram 0
Decomposition Level: 1
Diagram 1
Decomposition Level: 2
Diagram 2
Decomposition Level: 2
Data Dictionaries (DD)
 Purpose:
 to keep data about:
 Data Flow and Data Item Specifications
 File Specifications
 Process Specifications
 Data Specification Language:
 Notational Conventions: = , + , [ ] , { } , ( )
 e.g. amount due = [dollar amount, sterling
amount]
 Process Specifications
Process Specifications
 Processing and control information omitted from a DFD
belongs in a process specification

 Each functional primitive has one process specification

 Process Specifications can be represented in a variety of

languages, the most popular are:

 Structured English
 Decision Tables and Decision Trees
Structured English
 A rigid subset of the English language
omitting adjectives, adverbs, compound and
complex sentences, all verb modes except
imperative and most punctuation
 Result: A language containing a limited set of
conditional and logic statements with nouns and
strong verbs
 Standards vary between organisations -
objectives of: conciseness, preciseness and
lack of ambiguity apply to all variants
 Structured English (cont.)
Posesses the three standard control constructs of:
 sequence

 selection

 iteration

and
 primitive actions

These constructs permit the specification of any

system
 Structured English (cont.)
Primitive Actions
 inform the reader of sth which must be done as
opposed when it is to be done
 expressed as imperative statements, e.g.
 READ-FILE STOCK-DETAILS
 should be concise
 avoiding vague words (e.g. process / handle)
 containing a strong verb identifying the
function
 stating explicitly the object of the statement,
which is selected from the data dictionary
Structured English (cont.)
Control Constructs
 Sequences: represent actions taking place in sequence
without interruption. They are defined by the successive
appearance of a set of primitive actions
 Selections: describe a series of alternative policies from
which only one is selected
IF <condition> CASE
<statement> WHEN <condition>
<statements>
ELSE WHEN <condition>
<statements>
<statement> … ……….. …...
 Iterations: A policy or series of actions is repeated within
some bounds. Represented by DO…WHILE construct or
a REPEAT … UNTIL construct
 Structured English (cont.)
Total_charge = 0
REPEAT
get_next_room
IF room_type = ‘EXECUTIVE’
total_charge=total_charge+60$
ELSE
total_charge=total_charge + 35$
UNTIL all_booked_rooms_processed
OR total_charge > credit_limit
Structured English (cont.)
Advantages:
 consice and precise, allow easy reading
without ambiguity & misunderstanding
 language notation may be tailored to suit
user
 must exist a cross-referencing with any dfd &
dd entries thus perimitting thourough
verification
Disadvantages:
 formality may be alien when first read or
write
Avoid assuming that anything written in SE is
Decision Tables
 A tabular of conditions and actions and an
indication under which conditions, which actions
must be performed
 Consists of four quadrants

Condition Stub Rules

a list of all possible conditions contains selectors which identify
that can arise within the process different combinations of the possible
conditions

Action Stub Action Entries

a list of all possible actions that indicators which select the actions to be
performed
occur within the process
 Decision Tables: 3 variants
 Limited Entry Decision Table

 Mixed Entry Decision Table

 Extended Entry Decision Table

Limited Entry Decision Table
 Contains only the binary selectors Y & N and the catch all
selector - in the rules quadrant. In the action entries, it
contains only the action selector symbol X.
1 2 3 4

Credit Satisfactory Y N N N
Prompt Payer - Y N N
Special Clearance - - Y N

Accept Order X X X
Return Order X
 Mixed Entry Decision Table
 Contains only the binary selectors Y & N and the catch all selector -
in the rules quadrant. In the action entries quadrant, indicators other
than X appear.
1 2 3

Salaried Employee N N Y
Hours Worked > 40 Y N -

Pay Overtime Regular Regular

rate rate rate
 Extended Entry Decision Table
 Selectors in the rules quadrant are no longer simply binary (y or N)
bt may take on specific values or ranges of values.

1 2 3 4

Approved Credit N Y Y Y
Quantity Ordered - 0-24 25-55 56-99

Discount (%) 0 5 10
Release Order X X X
Reject Order
 Validating Decision Tables
 Limited and Mixed Decision Entry
Tables can be checked for
completeness, according to the
following algorithm:
i=j

2 number of conditions = Σ 2i c i
i=1
 Advantages of Decision Tables

 Easily understood

 Alternatives are shown side by side

 Cause & effect relationship is shown, thus

permitting easier user validation

 Possible to check that all combinations of

conditions have been considered
Object-Oriented Design
 Topics
 During the balance of this
semester, we will pursue and
follow two learning threads
 Object-relational databases
 The Geo-Web
 These two threads are
interwoven
To understand Object-Relational
Databases…
 We need to understand both relational
concepts (next week) and
 Object-oriented concepts (this week)
Why…Object-Oriented
 A brief history of computer programming…

The concept of encapsulation!

 Today’s Goals

 We will dissect “Object-Oriented” to learn what it really

is
 What is a class?
 What is an object?
 Enable you to identify inheritance, aggregation, and
dependency relationships between classes
 Understand class attributes and object properties
 Become familiar with new terminology
 What is a CLASS?
 A class is a computer construct representing a
concept bound in a cohesive package
 Some are concrete (i.e. real world)
 Bank account
 Rental item
 Database item
 Pile
 Others are abstract
 Scanner
 Stream
 Math
Discovering CLASSES
 Simple Rule:
 Look for nouns in descriptions
 Obviously not all nouns are classes
 But at least this method can allow one to
create a list of candidate classes
What is an OBJECT
 An instance of a CLASS
 Contains meaningful data
 Concepts that occupy memory space at
runtime are, according to the definition,
objects
 If not, they are CLASSES
 For example: data type vs. double
A little Quiz…
 #1 Class or Object?

Dog

Dog is a generalization of Scooby-Doo

Scooby-Doo
A little Quiz (cont’d)…
 #2 Class or Object?

Dog

Dog is a subclass of the Animal class

Animal Animal is a generalization of Dog

Scooby-Doo

The concept of subclass!

 A little Quiz (cont’d)…
 #3 Class or Object?

Animal

Bird Dog

The concept of polymorphism!

Questions…
Key Points

 Many classes already exist and are at our

disposal when we design a database
 We use inheritance to add capabilities to our
projects
 A subclass inherits from its superclass
 i.e., a child inherits from its parent
 Defining our CLASS
 After a class has been identified we can define:
 The behavior of each class
 Verbs = methods
 The attributes of each class
Behavior
 Relationships Between CLASSES

 We have learned about inheritance as a

relationship between classes
 There are 3 important relationships
 Inheritance
 Aggregation
 Dependency
 Inheritance
 Is-a relationship
 Relationship between a more general class
(superclass) and a more specialized class
(subclass)
 Every
 savings account is a bank account
 DVD rental is a rental
 Aggregation
 Has-a relationship
 Each Dog has a Paw (dog is not a generalization
of paw!)
 Objects of one class contain references to
objects of another class
Inheritance vs. Aggregation
 Often confused
 Questions?
 Example

 Car is a Vehicle –
Inheritance
 Car has a set of Tires –
Aggregation
Dependency
 Dependency occurs when a class uses
another class’ methods
 This is a Uses relationship
 Example: an application may depend on the
Scanner class to read input
Attributes
Class Diagram

What type of Method behaviors are these?

Dog example
 Name of the class =
 Methods? Dog
 Attributes?
Instantiate into object
 Three features characterize objects:
 Identity: specific property settings have been
made for the attributes of the class. This
distinguishes it from other objects.
 State: Describes the data stored in the object
WHERE DID THIS COME FROM?
 Behavior: describes the methods in the
object's interface through which the object can
be used.
Instantiating the Dog CLASS
 CLASS (DOG)
 Attributes (Properties)
 NAME = Scooby-Doo
 HEIGHT = 36
 WEIGHT = 145 Scooby-Doo
 Methods
 [Uses] bark- “Rooby roo”
 etc.
Key Concepts

 Understand the difference between a CLASS and

an OBJECT
 Understand new terms:
 Encapsulation, polymorphism, superclass, subclass,
behavior, attributes, instantiation
 Understand --and be able to differentiate-- the three
types of behaviors
Questions…
 Objects

An object is an entity which has a state and a defined set of

operations which operate on that state. The state is represented as a
set of object attributes. The operations associated with the object
provide services to other objects (clients) which request these
services when some computation is required.

Objects are created according to some object class definition. An

object class definition serves as a template for objects. It includes
declarations of all the attributes and services which should be
associated with an object of that class.
Advantages of inheritance
Object-oriented Design

Designing systems using self-

contained objects and object
classes
Objectives
 To explain how a software design may be
represented as a set of interacting objects
that manage their own state and operations
 To describe the activities in the object-
oriented design process
 To introduce various models that describe an
object-oriented design
 To show how the UML may be used to
represent these models
Topics covered
 Objects and object classes
 An object-oriented design process
 Design evolution
Characteristics of OOD
 Objects are abstractions of real-world or
system entities and manage themselves
 Objects are independent and encapsulate
state and representation information.
 System functionality is expressed in terms of
object services
 Shared data areas are eliminated. Objects
communicate by message passing
 Objects may be distributed and may execute
sequentially or in parallel
Interacting objects

o1: C1 o3:C3 o4: C4

s tate o1 s tate o3 s tate o4
ops 1() ops 3 () ops 4 ()

o2: C3 o6: C1 o5:C5

s tate o2 s tate o6 s tate o5
ops 3 () ops 1 () ops 5 ()
Advantages of OOD
 Easier maintenance. Objects may be
understood as stand-alone entities
 Objects are appropriate reusable components
 For some systems, there may be an obvious
mapping from real world entities to system
objects
Object-oriented development
 Object-oriented analysis, design and
programming are related but distinct
 OOA is concerned with developing an object
model of the application domain
 OOD is concerned with developing an object-
oriented system model to implement
requirements
 OOP is concerned with realising an OOD
using an OO programming language such as
Java or C++
Objects and object classes
 Objects are entities in a software system
which represent instances of real-world and
system entities
 Object classes are templates for objects.
They may be used to create objects
 Object classes may inherit attributes and
services from other object classes
UML
The Unified Modeling Language
 Several different notations for describing
object-oriented designs were proposed in the
1980s and 1990s
 The Unified Modeling Language is an
integration of these notations
 It describes notations for a number of
different models that may be produced during
OO analysis and design
 It is now a de facto standard for OO modelling
 UML is not a methodology
 Class diagrams
 Use-case diagrams
 Stereotypes
 Interaction diagrams
 Sequence Diagrams
 Collaboration Diagrams
 Statecharts
 Review of UML diagrams
 UML and iteration
The Current Version of UML
 Like all modern computer languages, UML is
constantly changing
 When this book was written, the latest version
of UML was Version 2.0
 These versions mean aspects of UML are
changing.

 UML is now under the control of the Object

Management Group (OMG)
 Check for updates at the OMG Web site,
www.omg.org
16.1 UML Is Not a Methodology
 UML is an acronym for Unified Modeling Language
 UML is therefore a language

 A language is simply a tool for expressing ideas

 UML is a notation, not a methodology

 It can be used in conjunction with any methodology

 UML is not merely a notation, it is the notation

 UML has become a world standard
 Every information technology professional today needs
to know UML
 UML Is Not a Methodology
(contd)
 The manual for Version 1.5 of UML is 736 pages long
 Complete coverage here is not possible

 But surely every information technology professional must know every

aspect of UML?

 The English language has over 100,000 words

 We can manage fine with just a subset

 The small subset of UML presented in Chapters 7, 10, 12, and 13 is

adequate for the purposes of this book. Here we review those pieces.
 Class Diagrams
 A class diagram depicts classes and their interrelationships
 Here is the simplest possible class diagram

Bank Account Class

 Class diagram showing more details of Bank Account Class

Bank Account Class

accountBalance

deposit( )
withdraw( )

 Add as many (or as few) details as appropriate for the current iteration
and incrementation
 Class Diagrams: Notation
 Freedom of notation extends to objects
 Example:
 bank account : Bank Account Class
 bank account is an object, an instance of a class Bank Account Class
 The underlining denotes an object
 The colon denotes “an instance of”
 The bold face and initial upper case letters in Bank Account Class
denote that this is a class
 UML allows a shorter notation when there is no ambiguity
 bank account
 The UML notation for modeling the concept of an arbitrary bank
account is
 : Bank Account Class
 The colon means “an instance of,” so
: Bank Account Class
means “an instance of class Bank Account Class”
 Class Diagrams: Visibility Prefixes
(contd)
 UML visibility prefixes (used for information hiding)
 Prefix + indicates that an attribute or operation is public
 Visible everywhere

 Prefix – denotes that the attribute or operation is private

 Visible only in the class in which it is defined

 Prefix # denotes that the attribute or operation is protected

 Visible either within the class in which it is defined
Bank or within
Account Class
subclasses of that class - accountBalance
 Example:
 Class diagram with visibility prefixes added
+ deposit( )
 Attribute accountBalance is visible only within + withdraw( )
the Bank Account Class

 Operations deposit and withdraw are accessible

from anywhere within the software product
 Aggregation
 Example: “A car consists of a chassis, an engine, wheels,
and seats”

 The open diamonds denote aggregation

 Aggregation is the UML term for the part–whole relationship

 The diamond is placed at the “whole” (car) end, not the

“part” (chassis, engine, wheels, or seats) end of the line
connecting a part to the whole
 Multiplicity
 Example: “A car consists of one chassis, one engine, 4 or 5
wheels, an optional sun roof, zero or more fuzzy dice
hanging from the rear-view mirror, and 2 or more seats”
 The numbers next to the ends of the lines denote
multiplicity
 The number of times that the one class is associated
with the other class
 The line connecting Chassis Class to Car Class
 The 1 at the “part” end of the line denotes that there is
one chassis involved
 The 1 at the “whole” end denotes that there is one car
involved
 Each car has one chassis, as required
 Multiplicity

 The line connecting Wheels Class to Car Class

 The 4..5 at the “part” end together with the 1 at the “whole” end
denotes that each car has from 4 to 5 wheels (the fifth wheel is the
spare)
 A car has 4 or 5 wheels, as required
 Instances of classes come in whole numbers only
 The line connecting Sun Roof Class to Car Class
 Two dots .. denote a range, so the 0..1 means zero or one, the UML
way of saying “optional”
 A car has an optional sun roof, as required
 The line connecting Fuzzy Dice Class to Car Class
 Multiplicity

 The line connecting Seats Class to Car Class

 An asterisk in a range denotes “or more,” so the 2..* means 2 or more
 A car has two or more seats, as required
 If the exact multiplicity is known, use it
 Example: The 1 that appears in 8 places
 If the range is known, use the range notation
 Examples: 0..1 or 4..5
 If the number is unspecified, use the asterisk
 Example: *
 If the range has upper limit unspecified, combine the range with asterisk
 Example: 2..*
 16.2.3 Composition
 Aggregation example: Every chess board consists of 64 squares

 This relationship goes further

It is an instance of composition, a stronger form of aggregation
 Association
 Models the part–whole relationship
 Composition
 Also models the part–whole relationship but, in addition,
 Every part may belong to only one whole, and
 If the whole is deleted, so are the parts
 Example: A number of different chess boards
 Each square belongs to only one board
 16.2.4 Generalization
 Inheritance is a required feature of object orientation
 Inheritance is a special case of generalization
 The UML notation for generalization is an open triangle
 Sometimes the open triangle is labeled with a discriminator
 Every instance of Investment Class or its subclasses has an attribute
investmentType (the discriminator)
 This attribute can be used to distinguish between instances of the
subclasses
 16.2.5 Association
 An example of association:

 A radiologist consults a lawyer

 The optional navigation triangle shows the direction of the
association
•The association between the two classes may be modeled as
a class

Example: Suppose the radiologist consults the lawyer on a

number of occasions, each one for a different length of time
 16.4 Use-Case Diagrams
 A use case is a model of the interaction
between
 External users of a software product (actors)
and
 The software product itself
 More precisely, an actor is a user playing a
specific role

 A use-case diagram is a set of use cases

 Generalization of actors is supported
 The open triangle points toward the more
general case
 16.5 Stereotypes
 A stereotype in UML is a way of extending UML
 Stereotypes already encountered include
Boundary, control, and entity classes, and
 The «include» stereotype
 The names of stereotypes appear between guillemets
 Example: «This is my own construct»
 Example:
 All three primary U.S. tax forms need to be printed
 The other three use cases incorporate Print Tax Form
Stereotypes (contd)
 In the «extend» relationship, one use case is
a variation of the standard use case
 Example: A separate use case to model the
situation of a diner ordering a burger but
turning down the fries.
 The open-headed arrow goes in the other
direction

Figure 16.13
16.6 Interaction Diagrams
 Interaction diagrams show how objects interact with one
another

 UML supports two types of interaction diagrams

 Sequence diagrams
 Collaboration diagrams
 Sequence Diagrams
 Example:
 Dynamic creation followed by destruction of an object
 lifelines in the sequence diagram
 An active object is denoted by a thin rectangle (activation box) in
place of the dashed line

 Creation of the : Order Class object is denoted by the lifeline starting at

the point of dynamic creation
 Destruction of that object after it receives message 9: Destroy order
is denoted by the heavy X

Figure 16.14
 Sequence Diagrams
 A message is optionally followed by a message sent back to the object
that sent the original message
 Even if there is a reply, it is not necessary that a specific new message
be sent back
 Instead, a dashed line ending in an open arrow indicates a return
from the original message, as opposed to a new message

 There is a guard on the message

 9: [offer rejected] Destroy object
 Only if Osbert’s offer is rejected is message 9 sent
 A guard (condition) is something that is true or false
 The message sent only if the guard is true
 The purpose of a guard
 To ensure that the message is sent only if the relevant condition is true

Figure 16.14
 Sequence Diagrams
 Iteration an indeterminate number of times is modeled by an asterisk
(Kleene star)
 Example: Elevator *move up one floor
 The message means: “move up zero or more floors”

 An object can send message to self

 A self-call
 Example:
 The elevator has arrived at a floor
 The elevator doors open and a timer starts
 At the end of the timer period the doors close again
 The elevator controller sends a message to itself to start its timer —
this self-call is shown in the UML diagram
Sequence Diagrams
Collaboration Diagrams
 Collaboration diagrams are equivalent
to sequence diagrams
 All the features of sequence diagrams
are equally applicable to collaboration
diagrams
 Use a sequence diagram when the
transfer of information is the focus of
attention
 Use a collaboration diagram when
concentrating on the classes
16.7 Statecharts
 Statechart with guards

Figure 16.16
 Statechart
 Ansevent also causes transitions
between states
 Example: The receipt of a message

 The elevator is in state Elevator Moving

 It performs operation
 Move up one floor
while guard [no message received yet] is true, until it receives message
 Elevator has arrived at floor
 Receipt of this message [event] causes the guard to be false
 It also enables a transition to state Stopped at Floor
 In this state, activity
 Open the elevator doors
is performed
 Statecharts
 The most general form of a transition
label is
 event [guard] / action
 If
 event
has taken place and
 [guard]
is true, the transition occurs, and,
while it is occurring,
 action
 The transition label is
is performed
 Elevator arrived at floor [a message is received] / Open the elevator doors
 The guard
 [a message has been received]
is true when the event
 Elevator has arrived at floor
has occurred and the message has been sent
 The action to be taken is
 Open the elevator doors
 Statecharts
 There are two places where an action can be performed in
a statechart
 When a state is entered
 Activity

 As part of a transition
 Action

 Technical difference:
 An activity can take several seconds
 An action takes places essentially instantaneously

 An event can be specified in terms of words like “when” or

“after”
 Example:
 when (cost > 1000) or after (2.5 seconds)
 Statecharts
 Superstates combine related states

 States A, B, C, and D all have transitions to Next State

 Combine them into superstate ABCD Combined
 Now there is only one transition
 The number of arrows is reduced from four to only one
 States A, B, C, and D all still exist in their own right
 Statecharts (contd)

 Example: Four states are unified into MSG Combined

 16.12 Review of UML Diagrams
 Some diagrams that could be confused include:
 A use case models the interaction between actors and the
information system
 A use-case diagram is a single diagram that incorporates a number
of use cases
 A class diagram is a model of the classes showing the static
relationships between them
 Including association and generalization

 A statechart shows
 States (specific values of attributes of objects),
 Events that cause transitions between states (subject to guards),
and
 Actions taken by objects
 An interaction diagram (sequence diagram or collaboration diagram)
shows how objects interact as messages are passed between them
 16.13 UML and Iteration
 Every UML diagram consists of a small required part plus
any number of options
 Not every feature of UML is applicable to every information
system

 To perform iteration and incrementation, features have to be

added stepwise to diagrams

 This is one of the many reasons why UML is so well suited

to the Unified Process
Design By Products
 Test Plan
What do you mean by Test Plan ?
 Test planning should be done throughout the
development cycle, especially early in the development
cycle.
 In general testing commences with a test plan and
terminates with acceptance testing.
 Test Plan is a document describing the scope, approach,
resources and schedule of intended testing actvities.
 Identifies test items, the feature to be tested, testing
tasks, who will do each task, and any risks requiring
contingency planning.
A test plan should contain the
following :
 - Test unit specification
- Features to be tested
- Approach for testing
- Test deliverables
- Schedule and task allocation
 What’s a test case?

IEEE Standard 610 (1990) defines test case as follows:

“(1) A set of test inputs, execution conditions, and expected

results developed for a particular objective, such as to
exercise a particular program path or to verify compliance
with a specific requirement.

“(2) (IEEE Std 829-1983) Documentation specifying inputs,

predicted results, and a set of execution conditions for a
test item.”
 What’s a test case?
According to Ron Patton (2001, p. 65),

“Test cases are the specific inputs that you’ll try

and the procedures that you’ll follow when you
test the software.”
 Test Case Design
"Bugs lurk in corners
and congregate at
boundaries ..."
Boris Beizer

OBJECTIVE to uncover errors

CRITERIA in a complete manner

CONSTRAINT with a minimum of effort and time

 Test Cases
 The Test Case Specification is a document
wherein you derive/explain various scenarios to
test the component/system.
 It would consists of Component name, Case
Description, Expected Results, Pass/Fail status.
Test Case
 Test case template is the a document which
describes you haw and what all the items must
appear in the test case .The following are the item
which appear in the test case template
 Test Case ID
 Test Case Description
 Input
 Expected Result
 Actual Result
 Pass / Fail Condition
We can prepare Test Cases for

1) individual components,
2)for integrating the components
3) for full business scenarios...
 Milestone
 Inspection
 Walkthrough
Milestones

 These are a set of occasions in project design where

the proper progress of the project can be assessed in
such a way that corrective measures could be taken if
necessary.
The two major milestones are -
a) Preliminary Design Review (PDR): - Its normally held
near the end of architectural design and prior to detailed
design. and
b) Critical design Review (CDR) :- Its normally held at the
end of detailed design and prior to implementation.
 The major goal of PDR is to demonstrate the
externally observable characteristics and
architectural structure of the product, which would
satisfy the customer’s requirements. Functional
characteristics, performance attributes, external
interface, user dialogs, report formats, exception
conditions and exception handling and future
enhancements are reviewed during PDR.

 The CDR provides a final management decision point

, to build or cancel the system.
 Walkthrough
 Inspection
Aims and Learning Outcomes

Aims and Learning Outcomes

 Understand what are structured walkthroughs for software
verification
 Understand what are inspections for software verification
 Understand the similarities and differences between
walkthroughs and inspections
 Understand the differences between testing and
walkthroughs/inspections
 Verification and Validation

 Verification:
"Are we building the product right”.
 The software should conform to its specification (i.e., fault-
free. In reality, as fault-free as possible).
 Examples of verifications: Unit testing, integrating testing,
and formal verification
 Validation (or Valuation):
"Are we building the right product”.
 The software should do what the user really requires (i.e.,
user satisfactory).
 Examples of validation: Prototyping, acceptance testing
 Verification and Testing

 Verification Techniques: There are several different

techniques for software verification
 Dynamic verification
 Testing
 Static verification
 Structure Walkthroughs
 Inspections
 Formal verification
 Applying mathematical logic method (called formal
method) to verify (prove) the correctness of a program,
often for safety-critical applications
 Structured Walkthroughs and Inspections

Background:
 The initial idea was proposed by Gerry Weinberg in 1970s
(in his book “The Psychology of Computer Programming”)
 We often cannot see errors and deficiencies in our own
work, since do so would be to find a fault in ourselves, and
this, apparently, is unacceptable to us
 To overcome this weakness as human being, all work
should be checked by someone else.
 Structured walkthroughs and inspections are two
techniques to do such a check.
 Structured Walkthroughs - Introduction

 What are structured walkthroughs

 A structured walkthrough is an organized procedure for
a group of peers to review and discuss the technical
products (such as a requirement , design, or source
code document etc) to detect faults, violations of
development standards, and other problems
 The word “structured” simply means “well organised”
 The term “walkthrough” means that the activity of the
product author (requirement manager, designer or
program developer etc) explaining step by step the
working of his/her product
 Structured Walkthroughs- Objectives

 Objectives of structured walkthrough

 For early detecting errors and improving the quality of
the product
 Structured walkthroughs should not be used to discuss
solutions for the errors that are found. The basic
purpose of a walkthrough is error detection, not error
correction
 Why structured walkthroughs
 By letting other people looks at the product you
produced, errors will be found much more quickly
 The earlier an error is found, the cheaper it is to fix
 Structured Walkthroughs-Scheduling

Scheduling Walkthroughs:
 Structured walkthroughs should be conducted during all stages
of the system lifecycle
 Walkthroughs should be conducted frequently
 Focuses on a specific and small piece of work
 Increases the likelihood of uncovering errors
 Before author has too great an ego investment
 Scheduled only when the creator or author is ready
 About 4 or 5 people
 Advanced preparation (e.g., no more than 2 hours) should be
required of and performed by each reviewer
Structured Walkthroughs - Procedure

Organisation and Procedure: Outlines

 the preparatory work required

 participants and their roles
 procedures to follow
 time limits for the review
 essential paperwork for recording the outcome of the review
Structured Walkthroughs - Procedure

Organisation and Procedure:

 the preparatory work required
 The required documents are ready
 The author is ready
 The reviewers are ready
 participants and their roles
 Coordinator (Review Leader): develops the agenda and
chair the review meeting
 Author (Producer): presents the step by step walkthrough
 Reviewers: evaluate the work product to determine if it is
technically accurate and correct
 Recorder: records the errors identified and any other
technical comments, suggestions, and unresolved
questions.
 Structured Walkthroughs - Procedure

 Coordinator chairs the meeting

 Author's overview? No
 Reviewers should be able to understand the product
without assistance
 Author's overview may "brainwash" reviewers into making
the same logical errors as did the author
 Author's detailed walkthrough
 Based on logical arguments of what the design or code
will do at various stages
 Reviewers review
 Provide feedbacks (positive and negative comments and
suggestions including error found)
 Coordinator resolves disagreements when the team can not reach
a consensus
Structured Walkthroughs - Procedure

 Recorder’s recordkeeping
 Review issues list:
 Identify problem areas within the product
 Action Item checklist for corrections to be made
 Review summary report
 What was reviewed?
 Who reviewed it?
 What were the findings and conclusions?
Structured Walkthroughs - Procedure

Organisation and Procedure:

 essential paperwork for recording the outcome of the review
 recording outcome of a structured walkthrough:
 Accept the product without further modification
 Accept the product provisionally
 a list of errors
 the name of who will check the corrected product
 Reject the product due to severe errors
 a list of errors
 the date and time of the meeting to check the
corrected product
 All attendees complete a sign-off, indicating...
 Their participation in the review
 Concurrence with the review team's findings
Structured Walkthroughs - Procedure
Organisation and Procedure:
 time limits for the review
 Keep walkthroughs short (less than 90 minutes)

 Finally it should be emphasized in organisation and

procedure
 Error detection, not error correction
 Everyone is responsible for any bugs remaining after the
walkthrough
 The product, not the person, is being reviewed
 Management should not involved and not use inspections
for staff appraisal, i.e. finding out who makes mistakes.
Structured Walkthroughs-Types
Types of Walkthroughs
 Requirements walkthroughs
 Project planning
 Requirements analysis
 Design walkthroughs
 Architecture design
 Design
 Implementation walkthroughs
 Test walkthroughs
 Test plan
 Test procedure
 Structured Walkthroughs-Checklist
 Checklists
 For more formal walkthroughs and for inspections (will be
talked later), checklists are used
 Sample checklist for Implementation walkthroughs
 Documents to be checked
 The specification
 The text of the source codes on paper
 Elements to be checks
 Structure
 Documentation
 Variables
 Arithmetic Operations
 Loops and Branches
 Structured Walkthroughs-Checklist
 Sample checklist for Implementation walkthroughs
 Structure check
 Does the code properly implement all elements of

the design as specified?

 Are there any uncalled or unneeded procedures?
 Can any code be replaced by calls to external
reusable components or library functions?
 Do processes occur in the correct sequence?
 Is the code well-structured, consistent in style, and
clearly and consistently indented?
 Are there any blocks of repeated code that could
be condensed into a single procedure?
 Structured Walkthroughs-Checklist

 Sample checklist for Implementation walkthroughs

 Documentation check
 Is the code clearly and adequately documented

(both file prologues and module headers)?

 Are there any inconsistencies between code and
comments?
 Is the commenting style easy to maintain?

 Variable check
 Are all variables properly defined and given

meaningful, consistent, and clear names?

 Are all variables are initialised?
 Do all assigned variables have proper type
consistency ?
 Structured Walkthroughs-Checklist

 Sample checklist for Implementation walkthroughs

 Arithmetic Operations
 Does the code avoid comparing floating-point

numbers for equality?

 Does the code systematically prevent rounding
errors?
 Does the code avoid additions and subtractions
on numbers with greatly different magnitudes?
 Will all mixed-mode arithmetic operations give the
correct results? Should type conversions be done
in such cases?
 Structured Walkthroughs-Checklist
 Sample checklist for Implementation walkthroughs
 Loops and Branches
 Are all loops, branches, and logic constructs complete,
correct and properly nested?
 Are the most common cases tested first in IF-THEN-ELSEIF
chains?
 Are all cases covered in an IF-THEN-ELSEIF or CASE
block, including ELSE or DEFAULT clauses?
 Does the normal case follow the IF, not the ELSE?
 Are loop termination conditions obvious and invariably
achievable?
 Are indexes or subscripts properly initialized, just prior to the
loop?
 Does the code in the loop avoid manipulating the index
 Structured Walkthroughs - Benefits
 Software quality is improved because
 More bugs are eliminated
 The software is easier to maintain, because it is clearer
 Developer effort is reduced because
 Specifications are clarified before implementation
 Errors are detected early, and so costly rework is
avoided
 The time spend at the meeting (and in preparation for it)
is more than repaid in time saved

“The number of errors in software decreases by as much as 80% in

organizations that use walkthroughs diligently.”
 Structured Walkthroughs - Benefits
 Meeting deadlines is improved because
 Visibility of the project is better
 Major errors are avoided early
 Developer expertise is enhanced because
 Everyone learns from everyone else
 Developer morale is improved because
 People gain satisfaction from better work
 People get to find out what is going on
 People enjoy the discussions with colleagues

"For a junior developer, working for one year as part of a team

that practices walkthroughs is equivalent to two years of
working alone."
 Structured Walkthroughs - Benefits
 Promotes backup and continuity because
 It reduces risk of discontinuity & "useless code" since
several people become familiar with parts of software
that they may not have otherwise seen
Summary of Walkthroughs
 Objective: FIND ERRORS
 Focus: the product, not the author
 Improves software quality
 Provides training for junior personnel
 Time-effective and cost-effective
 Reduces risks of discontinuity
 Structured Walkthroughs - Difficulties
Difficulties in implementing structured walkthroughs
 People feel pressure or do not like to present their
products to others to review or criticise
 Sometimes it is difficult to keep only to provide
constructive criticism (in a friendly manner) and it is
possible to lead the conflict between team members
 It is less widely used as claimed in books

“So it is more difficult to implement the structured

walkthroughs than it is sounded”
 Inspections - Introduction
 What are inspections

 A formal evaluation technique in which software

products (such as requirement, design, or code
documents) are examined in detail by a group of peers
to detect faults, violations of development standards,
and other problems
 Software inspections were introduced in the 1970s by
Michael Fagan at IBM, which pioneered their early
adoption and later evolution. It is sometimes termed as
"Fagan inspection."
 Software inspections provide value in improving
software reliability, availability, and maintainability
 Similar to structured walkthroughs
 Inspections – Introduction
Inspection pre-conditions

 A precise specification must be available.

 Team members must be familiar with the organisation standards.
 Syntactically correct code or other system representations must
be available.
 An error checklist should be prepared.
 Management must accept that inspection will increase costs
early in the software process
 Inspections - Procedure

1. Planning
2. Overview
3. Individual preparation
4. Inspection meeting
5. Rework
6. Follow-up
 Inspections - Procedure

 System overview presented to inspection team

 Code and associated documents are distributed to inspection
team in advance
 Inspection (meeting) takes place and discovered errors are
noted
 Modifications are made to repair discovered errors
 Re-inspection may or may not be required
 Inspections -Team and Roles
 Author or owner
 The developer or designer responsible for producing the
program or document. Responsible for fixing defects
discovered during the inspection process
 Inspector(s)
 Finds errors, omissions and inconsistencies in programs
and documents
 Reader
 Presents the code or document at an inspection meeting.
 Scribe (recorder)
 Records the results of the inspection meeting.
 Chairman or moderator
 Manages the process and facilitates the inspection.
Reports process results to the Chief moderator.
 Chief moderator
 Responsible for inspection process improvements,
checklist updating, standards development etc.
 Comparison of Walkthroughs and Inspections

Software Software
Walkthroughs Inspections
Participants Peer(s) led by Peers in designated roles
author
Rigor Informal to formal Formal

Training None, informal, or Structured, preferably by teams

structured
Checklist None, partial or Structured and complete
complete checklist
Purpose Judge quality, find Measure/improve quality of
defects, training product and process

Effectiveness Low to medium Low to very high, depending on

training and commitment
 Summary of Walkthroughs/Inspections

 Peers can find faults in our product much easier as we are

unwilling (psychologically) to find faults in our own products –
This is the basically reason behind walkthroughs and
inspections
 Both are activities that software products (such as
requirement, design, or code documents) are examined by a
group of peers to detect faults, violations of development
standards, and other problems
 Key factors to success are to find errors rather than solution,
focus on product rather than author, and organise carefully
 Both lead to improve software quality, reliability and
maintainability as well as Time-effective and cost-effective