Unit II

Software Design
 More creative than analysis
 Problem solving activity
Unit II
 Bridge the gap bet specifications & coding
Software Design for large projects
WHAT IS DESIGN

‘HOW’

Software design document (SDD)

1 Software Engineering UNIT II . 2 Dr. Rabins Porwal

1 2

Software Design Software Design

Initial requirements

Gather data on user requirements design

Analyze requirements data

Validate the design Obtain answers to Satisfy

against the requirement
requirements questions

Conceive of a high level design

Customer Developers
Refine & document the design (Implementers)

Completed design
Fig. 1 : Design framework
Software Engineering UNIT II . 3 Dr. Rabins Porwal Software Engineering UNIT II . 4 Dr. Rabins Porwal

3 4

Software Design Software Design

Conceptual Design and Technical Design
Conceptual design answers :
D
e  Where will the data come from ?
s How
What  What will happen to data in the system?
i
Conceptual g Technical  How will the system look to users?
design n design
e  What choices will be offered to users?
r
s  What is the timings of events?
A two part design System  How will the reports & screens look like?
Customer
process Builders
Fig. 2 : A two part design process
Software Engineering UNIT II . 5 Dr. Rabins Porwal Software Engineering UNIT II . 6 Dr. Rabins Porwal

5 6

Compiled by: Prof. Rabins Porwal 1

Unit II

Software Design Software Design

Objectives of Design:
Technical design describes :
The design is quite likely to work down through a
 Hardware configuration number of levels. At each level, breaking the
 Software needs implementation problem into a combination of smaller
& simpler problems.
 Communication interfaces The design needs to be
 I/O of the system  Correct & complete
 Software architecture
 Understandable
 Network architecture
 At the right level
 Any other thing that translates the requirements in to a
solution to the customer’s problem.  Maintainable, and to facilitate maintenance of the
produced code
Software Engineering UNIT II . 7 Dr. Rabins Porwal Software Engineering UNIT II . 8 Dr. Rabins Porwal

7 8

Software Design Why Design is important

 A good design is the key to successful product.
 Almost 2000 years ago Roman Architect Vitruvious
recorded the following attributes of a good design:
Informal More  Durability
design Informal formal Finished
 Utility and
outline design design design  Charm
 A well designed system is easy to implement, understand
and reliable and allows for smooth evolution. Without
design, we risk building an unstable system:
 One that will fail when small changes are made
 One that will be difficult to maintain
Fig. 3 : The transformation of an informal design to a detailed  One whose quality can not be assessed until late in the software
design process.

Software Engineering UNIT II . 9 Dr. Rabins Porwal Software Engineering UNIT II . 10 Dr. Rabins Porwal

9 10

Why design is imp. (Contd.) Software Design

 There are three characteristics that serve as a guide for the MODULARITY
evolution of a good design. There are many definitions of the term module. Range is from :
 The design must implement all of the explicit requirements
i. Fortran subroutine
contained in the analysis model and it must accommodate all of
the implicit requirements desired by the customer. ii. Ada package
 The design must be readable, understandable guide for those
who generate code and for those who test and subsequently
iii. Procedures & functions of PASCAL & C
support the software. iv. C++ / Java classes
 The design should provide a complete picture of the software,
v. Java packages
addressing the data, functional and behavioral domain from an
implementation perspective. vi. Work assignment for an individual programmer

Software Engineering UNIT II . 11 Dr. Rabins Porwal Software Engineering UNIT II . 12 Dr. Rabins Porwal

11 12

Compiled by: Prof. Rabins Porwal 2

Unit II

Software Design Software Design

Properties of a modular system:
i. Each module is a well defined subsystem that is
All these definitions are correct. A modular potentially useful in other applns.
system consist of well defined manageable ii. Each module has a single, well defined purpose
units with well defined interfaces among iii. Modules can be separately compiled and stored
the units. in a library
iv. Modules can use other modules
v. Modules should be easier to use than to build
vi. Modules should be simpler from outside than
from the inside
Software Engineering UNIT II . 13 Dr. Rabins Porwal Software Engineering UNIT II . 14 Dr. Rabins Porwal

13 14

Software Design Software Design

A system is considered modular if it consists of
discrete components so that each component
Modularity is the single attribute of software that can be implemented separately and a change to
allows a program to be intellectually manageable. one component has minimal impact on other
components.
It enhances design clarity, which in turn eases
implementation, debugging, testing, One important question:
documenting, and maintenance of software to what extent we should modularize
product. As the number of modules grows, the effort
associated with integrating the modules also
grows.
Software Engineering UNIT II . 15 Dr. Rabins Porwal Software Engineering UNIT II . 16 Dr. Rabins Porwal

15 16

Software Design Software Design

Observation:
A s/w system can not be made modular by
simply chopping it into a set of modules. Each
module needs to support a well defined
abstraction and should have a clear interface
through which it can interact with other
modules.
Thus over-modularity and under-modularity in a
software should be avoided.
Fig. 4 : Modularity and software cost

Software Engineering UNIT II . 17 Dr. Rabins Porwal Software Engineering UNIT II . 18 Dr. Rabins Porwal

17 18

Compiled by: Prof. Rabins Porwal 3

Unit II

Software Design Software Design

Module Coupling
Coupling is the measure of the degree of
interdependence between modules.

Loosely coupled: Highly coupled:

some dependencies many dependencies
(b) (c)
Fig. 5 : Module coupling
(Uncoupled : no dependencies)
(a)
Software Engineering UNIT II . 19 Dr. Rabins Porwal Software Engineering UNIT II . 20 Dr. Rabins Porwal

19 20

Software Design Software Design

A good design will have low coupling. Coupling is
measured by the number of interconnections bet Consider the example of editing a student record in a
modules. ‘student information system’.
The hypothesis is that design with high coupling will Edit student Edit student
record record
have more errors. Loose coupling minimizes the
Student name,
interdependence amongst modules. This can be student ID,
Student Student Student
achieved as: record ID record
address,
EOF EOF
 Controlling the number of parameters passed amongst course
modules. Retrieve Retrieve
 Avoid passing undesired data to calling module. student record student record
 Maintain parent / child relationship between calling & called Poor design: Tight Coupling Good design: Loose Coupling
modules.
 Pass data, not the control information. Fig. 6 : Example of coupling
Software Engineering UNIT II . 21 Dr. Rabins Porwal Software Engineering UNIT II . 22 Dr. Rabins Porwal

21 22

Software Design Software Design

Data coupling Best Data coupling
Stamp coupling The dependency between module A and B is said to be data
Control coupling coupled if their dependency is based on the fact they
communicate by only passing of data. Other than
External coupling
communicating through data, the two modules are
Common coupling independent.
Content coupling Worst Stamp coupling
Fig. 7 : The types of module coupling Stamp coupling occurs between module A and B when
Given two procedures A & B, we can identify number of complete data structure is passed from one module to another.
ways in which they can be coupled.
Software Engineering UNIT II . 23 Dr. Rabins Porwal Software Engineering UNIT II . 24 Dr. Rabins Porwal

23 24

Compiled by: Prof. Rabins Porwal 4

Unit II

Software Design Software Design

Control coupling
Module A and B are said to be control coupled if they
communicate by passing of control information. This is usually
accomplished by means of flags that are set by one module and
reacted upon by the dependent module.

Common coupling
With common coupling, module A and module B have shared
data. Global data areas are commonly found in programming
languages. Making a change to the common data means tracing
back to all the modules which access that data to evaluate the
effect of changes. Fig. 8 : Example of common coupling
Software Engineering UNIT II . 25 Dr. Rabins Porwal Software Engineering UNIT II . 26 Dr. Rabins Porwal

25 26

Software Design Software Design

External coupling
A form of coupling in which a module has a dependency to
other module, external to the software being developed or to a
particular type of hardware. This is basically related to the
communication to external tools and devices.

Content coupling
Content coupling occurs when module A changes data of
module B or when control is passed from one module to the
middle of another. In Fig. 9, module B branches into D, even
though D is supposed to be under the control of C.
Fig. 9 : Example of content coupling
Software Engineering UNIT II . 27 Dr. Rabins Porwal Software Engineering UNIT II . 28 Dr. Rabins Porwal

27 28

Software Design Software Design

Module Cohesion
Cohesion is a measure of the degree to which the Types of cohesion
elements of a module are functionally related. It can be  Functional cohesion
viewed as a glue that keeps the module together.
 Sequential cohesion
 Communicational cohesion
 Procedural cohesion
Module  Temporal cohesion
strength
 Logical cohesion

 Coincidental cohesion

Fig. 10 : Cohesion=Strength of relations within modules

Software Engineering UNIT II . 29 Dr. Rabins Porwal Software Engineering UNIT II . 30 Dr. Rabins Porwal

29 30

Compiled by: Prof. Rabins Porwal 5

Unit II

Software Design Software Design

Given a procedure that carries out operations X and Y,
Functional Cohesion Best (high) various forms of cohesion between X and Y can be described as:

Sequential Cohesion Functional Cohesion

 X and Y are part of a single functional task. This is very good
Communicational Cohesion reason for them to be contained in the same procedure. Such a
module often transformed a single input datum into a single
Procedural Cohesion
output datum.
Temporal Cohesion Ex: calculate current GPA, cumulative GPA
Logical Cohesion Sequential Cohesion
 Operation X outputs some data which forms the input to Y. This is
Coincidental Cohesion Worst (low)
the reason for them to be contained in the same procedure.
Ex: addition of marks of individual subjects into a specific format
Fig. 11 : Types of module cohesion is used to calculate the GPA as input for preparing the result of
the students.
Software Engineering UNIT II . 31 Dr. Rabins Porwal Software Engineering UNIT II . 32 Dr. Rabins Porwal

31 32

Software Design Software Design

Communicational Cohesion
 X and Y both operate on the same input data or contribute
towards the same output data. Temporal Cohesion
X and Y must perform around the same time. So, module exhibits
Procedural Cohesion temporal cohesion when it contains tasks that are related by the
X and Y, both are structured in the same way. This is a poor fact that all tasks must be executed in the same time-span.
reason for putting them in the same procedure. Thus, procedural
cohesion occurs in modules whose instructions although Ex: the set of functions responsible for initialization, start up
accomplish different tasks yet have been combined because activities such as setting program counters or control flags
there is a specific order in which the tasks are to be completed. associated with programs.

Ex: if a report module of an examination system includes the

following – “calculate student GPA, print student record, calculate
cumulative GPA, print cumulative GPA”

Software Engineering UNIT II . 33 Dr. Rabins Porwal Software Engineering UNIT II . 34 Dr. Rabins Porwal

33 34

Software Design Software Design

Logical Cohesion
Coincidental Cohesion
 X and Y perform logically similar operations. Therefore, logical  X and Y have no conceptual relationship other than shared
cohesion occurs in modules that contain instructions that code. Hence, coincidental cohesion exists in modules that
appear to be related because they fall into the same logical contain instructions that have little or no relationship to one
class of functions. another. That is, instead of creating two components, each of
Ex: more than one data item in an input transaction may be a one part, only one component is made with two unrelated parts.
date. Separate code would be written to check that each such Ex: check validity and print in a single component with two
date is a valid date. A better way is to construct a separate parts.
module and call this module whenever a date check is
necessary.
Note: Coincidental cohesion is to be avoided as far as possible.

Software Engineering UNIT II . 35 Dr. Rabins Porwal Software Engineering UNIT II . 36 Dr. Rabins Porwal

35 36

Compiled by: Prof. Rabins Porwal 6

Unit II

Software Design Software Design

Relationship between Cohesion & Coupling
If the software is not properly modularized, a host of seemingly
trivial enhancement or changes will result into death of the project.
Therefore, a good software design professes clean decomposition of
a problem into modules and the arrangement of these modules in a
neat hierarchy. Therefore, a software engineer must design the
modules with goal of high cohesion and low coupling.
Ex: a good example of a system that has high cohesion and low
coupling is the ‘plug and play’ feature of the computer system.
Various slots in the mother board of the system simply facilitate to
add or remove the various services/ functionalities without affecting Fig. 12 : View of cohesion and coupling
the entire system. This is because the add-on components provide the
services in highly cohesive manner.
Software Engineering UNIT II . 37 Dr. Rabins Porwal Software Engineering UNIT II . 38 Dr. Rabins Porwal

37 38

Software Design Software Design

STRATEGY OF DESIGN In early days, if any design was done, it was just “writing down
A good system design strategy is to organize the program modules the flowchart in words”. Hence there is a sudden jump from
in such a way that are easy to develop and later to, change. specifications to flow chart that leads to the cause of many errors.
Structured design techniques help developers to deal with the size Flowcharts are at a low level. As a result, errors in flow-charts
and complexity of programs. Analysts create instructions for the could only be found by coding them, seeing that the code ran
developers about how code should be written and how pieces of wrongly, diagnosing that the error is in the flow chart, then
code should fit together to form a program. It is important for two diagnosing where in the flowchart, then fixing it, modifying code
reasons: and recoding.

 First, even pre-existing code, if any, needs to be understood, Now flowcharts are seldom used for design of large and complex
organized and pieced together. software. The result is that other notations were designed for
expressing design, and these are at “higher level” than flow charts.
 Second, it is still common for the project team to have to write
This helped to minimize the length of jumps from specification to
some code and produce original programs that support the design and design to code.
application logic of the system.
Software Engineering UNIT II . 39 Dr. Rabins Porwal Software Engineering UNIT II . 40 Dr. Rabins Porwal

39 40

Software Design Software Design

The set of modules form a hierarchy as shown in the following
Bottom-Up Design figure. This is a cross-linked tree structure in which each module is
A common approach is to identify modules that are required by many subordinate to those in which it is used.
programs. These modules are collected together in the form of a
“library”. These modules may be for match functions, for input-
output functions, for graphical functions etc.
This approach lead to a style of design where it is decided how to
combine these modules to provide larger ones; to combine those to
provide even larger ones, and so on, till we arrive at one big module
which is the whole of the desired program.
Since the design progressed from bottom layer upwards, the method
is called bottom-up design.
Fig. 13 : Bottom-up tree structure
Software Engineering UNIT II . 41 Dr. Rabins Porwal Software Engineering UNIT II . 42 Dr. Rabins Porwal

41 42

Compiled by: Prof. Rabins Porwal 7

Unit II

Software Design Software Design

Argument: Top-Down Design
If we start coding a module soon after its design, the chances of A top down design approach starts by identifying the major modules
recoding is high; but the coded module can be tested and design can of the system, decomposing them into their lower level modules and
be validated soon than a module whose sub modules have not yet iterating until the desired level of detail is achieved. This is stepwise
been designed. refinement; starting from an abstract design, in each step the design
Weakness: is refined to a more concrete level, until we reach a level where no
A lot of intuition is required to decide exactly what functionality a more refinement is needed and the design can be implemented
module should provide. If we get it wrong, then at a higher level, we directly.
will find that it is not as per requirements; then we have to redesign
at a lower level. Most design methodologies are based on this approach and this is
suitable, if the specifications are clear and development is from the
Suitability: scratch. Weakness: If coding of a part starts soon after it’s design,
If a system is to be built from an existing system, this approach is nothing can be tested until all its subordinate modules are coded.
more suitable, as it starts from some existing modules.
Software Engineering UNIT II . 43 Dr. Rabins Porwal Software Engineering UNIT II . 44 Dr. Rabins Porwal

43 44

Software Design
Hybrid Design
Software Design
Pure top-down or bottom-up approaches are often not practical. FUNCTION ORIENTED DESIGN
For a bottom-up approach to be successful, we must have a good Function oriented design is an approach to software design where
notion of the top to which the design should be heading. the design is decomposed into a set of interacting units where each
For top-down approach to be effective, some bottom-up approach is unit has a clearly defined function. Thus, system is designed from
essential for the following reasons: a functional viewpoint.
Its special variety is stepwise refinement, and it is a top down
 To permit common sub modules. design method. We start with a high level description of what the
 Near the bottom of the hierarchy, where the intuition is simpler, program does. Then, in each step, we take one part of our high
and the need for bottom-up testing is greater, because there are level description and refine it, i.e. specify in somewhat greater
more number of modules at low levels than high levels. detail what that particular part does.
 In the use of pre-written library modules, in particular, reuse of This method works fine for small programs.
modules.
Software Engineering UNIT II . 45 Dr. Rabins Porwal Software Engineering UNIT II . 46 Dr. Rabins Porwal

45 46

Software Design Software Design

We continue the refinement of each module until we reach the statement
level of our programming language. At that point, we can describe the
structure of our program as a tree of refinement as in design top-down
structure as shown in fig. 14.

Fig. 14 : Top-down structure

Software Engineering UNIT II . 47 Dr. Rabins Porwal Software Engineering UNIT II . 48 Dr. Rabins Porwal

47 48

Compiled by: Prof. Rabins Porwal 8

Unit II

Software Design Software Design

Design Notations
If a program is created top-down, the modules become very specialized.
During the design phase there are two things of interest: (1) the
As one can easily see in top down design structure, each module is used design of the system and (2) the process of designing itself. For the
by at most one other module, its parent. For a module to be reusable, second one, principles and methods are needed.
however, we must require several other modules in design reusable
structure as shown in fig. 15. Design notations are largely meant to be used during the process
of design and are used to represent design or design decisions.
For a function oriented design, the design can be represented
graphically or mathematically by the following:
 Data flow diagrams

 Data Dictionaries
 Structure Charts
 Pseudocode
Fig. 15 : Design reusable structure
Software Engineering UNIT II . 49 Dr. Rabins Porwal Software Engineering UNIT II . 50 Dr. Rabins Porwal

49 50

Software Design Software Design

Structure Chart
The most commonly used method for system design. It partitions a
system into black boxes. A black box means that functionality is
known to the user without the knowledge of internal design.

Fig. 17 : Structure chart notations

Fig. 16 : Hierarchical format of a structure chart
Software Engineering UNIT II . 51 Dr. Rabins Porwal Software Engineering UNIT II . 52 Dr. Rabins Porwal

51 52

Software Design
Software Design A structure chart for “update file” is given in fig. 18.

 Types of Structure Chart:

 Transform-centered Structure Chart:
 Transform-centered structure clout receive an
input which is transformed by a sequence of
operations, with each operation being carried out
by one module.
 Transaction-centered Structure Chart:
 It describes a system that processes a number of
Fig. 18 : Update file
different types of transactions.
Note: The components are generally read from top to bottom, left to
right. This being the example of transform-centered structure chart.
Software Engineering UNIT II . 53 Dr. Rabins Porwal Software Engineering UNIT II . 54 Dr. Rabins Porwal

53 54

Compiled by: Prof. Rabins Porwal 9

Unit II

Software Design Software Design

Pseudocode
Pseudocode notation can be used in both the preliminary and detailed
design phases.
Pseudocode can be used at any desired level of abstraction. Using
Fig. 19 : Transaction-centered structure pseudocode, the designer describes system characteristics using
In the above figure, the MAIN module controls the system short, concise, English language phrases that are structured by key
operation. Its function is to: words such as If-Then-Else, While-Do, and End. Keywords and
 invoke the INPUT module to read a transaction; indentation describe the flow of control, while English phrases
describe processing actions.
 determine the kind of transaction and select one of a number
of transaction modules to process that transaction, and Pseudocode can replace flowcharts and reduce the amount of external
 output the results of the processing by calling OUTPUT documentation required to describe a system.
module.
Software Engineering UNIT II . 55 Dr. Rabins Porwal Software Engineering UNIT II . 56 Dr. Rabins Porwal

55 56

Software Design Software Design

Functional Procedure Layers  Level 1

 Functions are built in layers, Additional notation is used to  Function Parameters (problem variables, types, purpose,
specify details. etc.)

 Level 0  Global variables (problem variables, type, purpose,

sharing information)
 Function or procedure name
 Routines called by the function
 Relationship to other system components (e.g., part of
which system, called by which routines, etc.)  Side effects

 Brief description of the function purpose.  Input/Output Assertions

 Author, date

Software Engineering UNIT II . 57 Dr. Rabins Porwal Software Engineering UNIT II . 58 Dr. Rabins Porwal

57 58

Software Design Software Design

 Level 2 Object Oriented Design
 Local data structures (variable etc.) Object oriented design is the result of focusing attention not on the
function performed by the program, but instead on the data that are
 Timing constraints
to be manipulated by the program. Thus, it is orthogonal to function
 Exception handling (conditions, responses, events) oriented design.

 Any other limitations Object Oriented Design begins with an examination of the real
world “things” that are part of the problem to be solved. These
things (which we will call objects) are characterized individually in
 Level 3 terms of their attributes and behavior.
 Body (structured chart, English pseudo code, decision
tables, flow charts, etc.)

Software Engineering UNIT II . 59 Dr. Rabins Porwal Software Engineering UNIT II . 60 Dr. Rabins Porwal

59 60

Compiled by: Prof. Rabins Porwal 10

Unit II

Software Design Software Design

 Basic Concepts The various terms related to object design are:
Object Oriented Design is not dependent on any specific
implementation language. Problems are modeled using objects. i. Objects
Objects have:
The word “Object” is used very frequently and conveys different
 Behavior (they do things) meaning in different circumstances. Here, meaning is an entity able to
save a state (information) and which offers a number of operations
 State (which changes when they do things) (behavior) to either examine or affect this state. An object is
characterized by number of operations and a state which remembers
the effect of these operations.

Software Engineering UNIT II . 61 Dr. Rabins Porwal Software Engineering UNIT II . 62 Dr. Rabins Porwal

61 62

Software Design Software Design

ii. Messages iv. Class
Objects communicate by message passing. Messages consist of the In any system, there shall be number of objects. Some of the objects
identity of the target object, the name of the requested operation and may have common characteristics and we can group the objects
any other operation needed to perform the function. Message are often according to these characteristics. This type of grouping is known as a
implemented as procedure or function calls. class. Hence, a class is a set of objects that share a common structure
and a common behavior.
iii. Abstraction
We may define a class “car” and each object that represent a car
In object oriented design, complexity is managed using abstraction. becomes an instance of this class. In this class “car”, Indica, Santro,
Abstraction is the elimination of the irrelevant and the amplification of Maruti, Indigo are instances of this class as shown in fig. 20.
the essentials.
Classes are useful because they act as a blueprint for objects. If we
want a new square we may use the square class and simply fill in the
particular details (i.e. colour and position) fig. 21 shows how can we
represent the square class.
Software Engineering UNIT II . 63 Dr. Rabins Porwal Software Engineering UNIT II . 64 Dr. Rabins Porwal

63 64

Software Design Software Design

Fig. 21: The square class

Fig.20: Indica, Santro, Maruti, Indigo are all instances of the class “car”

Software Engineering UNIT II . 65 Dr. Rabins Porwal Software Engineering UNIT II . 66 Dr. Rabins Porwal

65 66

Compiled by: Prof. Rabins Porwal 11

Unit II

Software Design Software Design

v. Attributes vii. Inheritance
An attributes is a data value held by the objects in a class. The square Imagine that, as well as squares, we have triangle class. Fig. 22 shows
class has two attributes: a colour and array of points. Each attributes the class for a triangle.
has a value for each object instance. The attributes are shown as
second part of the class as shown in fig. 21.

vi. Operations
An operation is a function or transformation that may be applied to or
by objects in a class. In the square class, we have two operations: set
colour() and draw(). All objects in a class share the same operations.
An object “knows” its class, and hence the right implementation of the
operation. Operation are shown in the third part of the class as
indicated in fig. 21. Fig. 22: The triangle class

Software Engineering UNIT II . 67 Dr. Rabins Porwal Software Engineering UNIT II . 68 Dr. Rabins Porwal

67 68

Software Design Software Design

Now, comparing fig. 21 and 22, we can see that there is some
difference between triangle and squares classes.
For example, at a high level of abstraction, we might want to think of a
picture as made up of shapes and to draw the picture, we draw each
shape in turn. We want to eliminate the irrelevant details: we do not
care that one shape is a square and the other is a triangle as long as
both can draw themselves.
To do this, we consider the important parts out of these classes in to a
new class called Shape. Fig. 23 shows the results.

Fig. 23: Abstracting common features in a new class

This sort of abstraction is called inheritance. The low level classes
(known as subclasses or derived classes) inherit state and behavior
from this high level class (known as a super class or base class).
Software Engineering UNIT II . 69 Dr. Rabins Porwal Software Engineering UNIT II . 70 Dr. Rabins Porwal

69 70

Software Design Software Design

viii. Polymorphism
When we abstract just the interface of an operation and leave the
implementation to subclasses it is called a polymorphic operation and
process is called polymorphism.

ix. Encapsulation (Information Hiding)

Encapsulation is also commonly referred to as “Information Hiding”. It
consists of the separation of the external aspects of an object from the
internal implementation details of the object.
x. Hierarchy
Hierarchy involves organizing something according to some particular
order or rank. It is another mechanism for reducing the complexity of Fig. 24: Hierarchy
software by being able to treat and express sub-types in a generic way.
Software Engineering UNIT II . 71 Dr. Rabins Porwal Software Engineering UNIT II . 72 Dr. Rabins Porwal

71 72

Compiled by: Prof. Rabins Porwal 12

Unit II

Software Design Software Design

 Steps to Analyze and Design Object Oriented System

There are various steps in the analysis and design of an object

oriented system and are given in fig. 25

Fig. 25: Steps for analysis & design of object

oriented system
Software Engineering UNIT II . 73 Dr. Rabins Porwal Software Engineering UNIT II . 74 Dr. Rabins Porwal

73 74

Software Design Software Design

i. Create use case model
First step is to identify the actors interacting with the system. We
should then write the use case and draw the use case diagram.

ii. Draw activity diagram (If required)

Activity Diagram illustrate the dynamic nature of a system by modeling

the flow of control form activity to activity. An activity represents an
operation on some class in the system that results in a change in the
state of the system. Fig. 26 shows the activity diagram processing an
order to deliver some goods.

Fig. 26: Activity diagram

Software Engineering UNIT II . 75 Dr. Rabins Porwal Software Engineering UNIT II . 76 Dr. Rabins Porwal

75 76

Software Design Software Design

iii. Draw the interaction diagram
An interaction diagram shows an interaction, consisting of a set of The object types used in this analysis model are entity objects,
objects and their relationship, including the messages that may be interface objects and control objects as given in fig. 27.
dispatched among them. Interaction diagrams address the dynamic
view of a system.
Steps to draw interaction diagrams are as under:
a) Firstly, we should identify the objects with respects to every use
case.
b) We draw the sequence diagrams for every use case.
Fig. 27: Object types
d) We draw the collaboration diagrams for every use case.

Software Engineering UNIT II . 77 Dr. Rabins Porwal Software Engineering UNIT II . 78 Dr. Rabins Porwal

77 78

Compiled by: Prof. Rabins Porwal 13

Unit II

Software Design Software Design

iv. Draw the class diagram b) Dependencies connect two classes. Dependencies are
always unidirectional and show that one class, depends on the
The class diagram shows the relationship amongst classes. There are definitions in another class.
four types of relationships in class diagrams.

a) Association are semantic connection between classes. When c) Aggregations are stronger form of association. An
an association connects two classes, each class can send aggregation is a relationship between a whole and its parts.
messages to the other in a sequence or a collaboration
diagram. Associations can be bi-directional or unidirectional.

d) Generalizations are used to show an inheritance relationship

between two classes.

Software Engineering UNIT II . 79 Dr. Rabins Porwal Software Engineering UNIT II . 80 Dr. Rabins Porwal

79 80

Software Design Software Design

v. Design of state chart diagrams vi. Draw component and deployment diagram
A state chart diagram is used to show the state space of a given class,
Component diagrams address the static implementation view of a
the event that cause a transition from one state to another, and the
system they are related to class diagrams in that a component typically
action that result from a state change. A state transition diagram for a
maps to one or more classes, interfaces or collaboration.
“book” in the library system is given in fig. 28.
Deployment Diagram Captures relationship between physical
components and the hardware.

Fig. 28: Transition chart for “book” in a library system.

Software Engineering UNIT II . 81 Dr. Rabins Porwal Software Engineering UNIT II . 82 Dr. Rabins Porwal

81 82

Compiled by: Prof. Rabins Porwal 14