Unit 1 Chapter 3

Software Engineering
UNIT-1
Chapter-3 (Function and Object oriented design)
Structured analysis, Data flow diagrams, Basic object orientation concepts, Unified
modeling language, Use case model, Class diagrams, Interaction diagrams,
Activity diagrams, State chart diagrams.
Prepared By: Er. Inderjeet Singh(e8822) Page 1

Chapter-3
(Function Oriented Software Design)
Function Oriented Design
Function Oriented Design is an approach to software design where the design

is decomposed into a set of interacting units where each unit has a clearly
defined function.
Or
• In function-oriented design, the system is comprised of many smaller sub-

systems known as functions.
• These functions are capable of performing significant task in the system.
• The system is considered as top view of all functions.
• This design mechanism divides the whole system into smaller functions,
which provides means of abstraction by concealing the information and their
operation.
These techniques, to start with, view a system as a black-box that provides a set of
services to the users of the software. These services provided by a software (e.g.,
issue book, search book, etc., for a Library Automation Software to its users are
also known as the high-level functions supported by the software. During the design
process, these high-level functions are successively decomposed into more detailed
functions.

Generic Procedure
Start with a high-level description of what the software/program does. Refine each
part of the description by specifying in greater detail the functionality of each part.
These points lead to a Top-Down Structure.
Function Oriented Design Strategies
Function Oriented Design Strategies are as follows:
1. Data Flow Diagram (DFD): A data flow diagram (DFD) maps out the flow
of information for any process or system. It uses defined symbols like
rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination.
2. Data Dictionaries: Data dictionaries are simply repositories to store

information about all data items defined in DFDs. At the requirement
stage, data dictionaries contains data items. Data dictionaries include Name

of the item, Aliases (Other names for items), Description / purpose,

Related data items, Range of values, Data structure definition / form.
3. Structure Charts: Structure chart is the hierarchical representation of

system which partitions the system into black boxes (functionality is
known to users, but inner details are unknown). Components are read from
top to bottom and left to right. When a module calls another, it views the
called module as a black box, passing required parameters and receiving
results.
4. Pseudo Code: Pseudo Code is system description in short English like

phrases describing the function. Pseudocodes are used as replacement for
flow charts. It decreases the amount of documentation required.
OVERVIEW OF SA/SD METHODOLOGY
As the name itself implies, SA/SD methodology involves carrying out two distinct
activities:
 Structured analysis (SA)

 Structured design (SD)
The roles of structured analysis (SA) and structured design (SD) have been shown
schematically in Figure. Observe the following from the figure:
 During structured analysis, the SRS document is transformed into a data

flow diagram (DFD) model.

 During structured design, the DFD model is transformed into a structure

chart.
As shown in Figure 6.1, the structured analysis activity transforms the SRS
document into a graphic model called the DFD model. During structured analysis,
functional decomposition of the system is achieved. That is, each function that
the system needs to perform is analysed and hierarchically decomposed into
more detailed functions. On the other hand, during structured design, all
functions identified during structured analysis are mapped to a module
structure. This module structure is also called the high-level design or the
software architecture for the given problem. This is represented using a structure
chart.
Note: It is important to understand that the purpose of structured analysis is

to capture the detailed structure of the system as perceived by the user,
whereas the purpose of structured design is to define the structure of the
solution that is suitable for implementation in some programming language.

STRUCTURED ANALYSIS
The structured analysis technique is based on the following underlying principles:
 Top-down decomposition approach.

 Application of divide and conquer principle. Through this each high-level
function is independently decomposed into detailed functions.
 Graphical representation of the analysis results using data flow
diagrams(DFDs).
Data Flow Diagrams (DFDs)
he DFD (also known as the bubble chart) is a simple graphical formalism

that can be used to represent a system in terms of the input data to the system,
various processing carried out on those data, and the output data generated by
the system.
The main reason why the DFD technique is so popular is probably because of the
fact that DFD is a very simple formalism— it is simple to understand and use. A
DFD model uses a very limited number of primitive symbols (shown in Figure) to
represent the functions performed by a system and the data flow among these
functions.

Function/Process symbol: A function is represented using a circle. This symbol is

called a process or a bubble. Bubbles are annotated with the names of the
corresponding functions (see Figure 6.3)
External entity symbol: An external entity such as a librarian, a library

member, etc. is represented by a rectangle. The external entities are
essentially those physical entities external to the software system which
interact with the system by inputting data to the system or by consuming the
data produced by the system. In addition to the human users, the external entity
symbols can be used to represent external hardware and software such as another
application software that would interact with the software being modelled.
Data flow symbol: A directed arc (or an arrow) is used as a data flow symbol.
A data flow symbol represents the data flow occurring between two processes
or between an external entity and a process in the direction of the data flow
arrow. Data flow symbols are usually annotated with the corresponding data
names. For example the DFD in Figure 6.3(a) shows three data flows—the data

item number flowing from the process read-number to validate-number, data-item

flowing into read-number, and valid-number flowing out of validate-number.
Data store symbol: A data store is represented using two parallel lines. It
represents a logical file. That is, a data store symbol can represent either a data
structure or a physical file on disk. Each data store is connected to a process by
means of a data flow symbol. The direction of the data flow arrow shows
whether data is being read from or written into a data store. An arrow flowing
in or out of a data store implicitly represents the entire data of the data store and
hence arrows connecting to a data store need not be annotated with the name
of the corresponding data items. As an example of a data store, number is a data
store in Figure 6.3(b).
Output symbol: The output symbol is used when a hard copy is produced.
Note: A DFD is a hierarchical graphical model of a system that shows

the different processing activities or functions that the system performs and
the data interchange among those functions.

DFD model only represents the data flow aspects and does not show the
sequence of execution of the different functions and the conditions based on
which a function may or may not be executed. It completely ignores aspects such
as control flow, the specific algorithms used by the functions, etc. In the DFD
terminology, each function is called a process or a bubble. It is useful to consider
each function as a processing station (or process) that consumes some input data
and produces some output data.
DEVELOPING THE DFD MODEL OF A SYSTEM
A DFD model of a system graphically represents how each input data is

transformed to its corresponding output data through a hierarchy of DFDs.
The DFD model of a system is constructed by using a hierarchy of DFDs (see

Figure 6.4). The top level DFD is called the level 0 DFD or the context diagram.
This is the most abstract (simplest) representation of the system (highest level). It is
the easiest to draw and understand. At each successive lower level DFDs, more
and more details are gradually introduced. To develop a higher-level DFD
model, processes are decomposed into their subprocesses and the data flow
among these subprocesses are identified.
To develop the data flow model of a system, first the most abstract representation
(highest level) of the problem is to be worked out. Subsequently, the lower
level DFDs are developed. Level 0 and Level 1 consist of only one DFD each.
Level 2 may contain up to 7 separate DFDs, and level 3 up to 49 DFDs, and so
on. However, there is only a single data dictionary for the entire DFD model.

Commonly made errors while constructing a DFD model
 Many beginners commit the mistake of drawing more than one bubble in the
context diagram. Context diagram should depict the system as a single
bubble.
 Many beginners create DFD models in which external entities
appearing at all levels of DFDs. All external entities interacting with the

system should be represented only in the context diagram. The external

entities should not appear in the DFDs at any other level.
 It is a common oversight to have either too few or too many bubbles in a
DFD. Only three to seven bubbles per diagram should be allowed. This also
means that each bubble in a DFD should be decomposed three to seven
bubbles in the next level.
 A common mistake committed by many beginners while developing a DFD
model is attempting to represent control information in a DFD.
Or
 Data can not flow between two entities. –

Data flow must be from entity to a process or a process to an entity. There can be
multiple data flows between one entity and a process.
 Data can not flow between two data stores
Data flow must be from data store to a process or a process to an data store. Data
flow can occur from one data store to many process.
 Data can not flow directly from an entity to data store –
Data Flow from entity must be processed by a process before going to data store
and vice versa.
 A process must have atleast one input data flow and one output data flow –
Every process must have input data flow to process the data and an output data flow
for the processed data.
 A data store must have atleast one input data flow and one output data flow
–

Every data store must have input data flow to store the data and an output data flow
for the retrieved data.
 Two data flows can not cross each other.
Context Diagram
The context diagram is the most abstract (highest level) data flow
representation of a system. It represents the entire system as a single bubble. The
bubble in the context diagram is annotated with the name of the software
system being developed.
To develop the context diagram of the system, we have to analyse the SRS
document to identify the different types of users who would be using the
system and the kinds of data they would be inputting to the system and the data
they would be receiving from the system.
Example: (RMS Calculating Software) A software system called RMS

calculating software would read three integral numbers from the user in the range of
–1000 and +1000 and would determine the root mean square (RMS) of the three
input numbers and display it.

Level 1 DFD
The level 1 DFD usually contains three to seven bubbles. That is, the system is
represented as performing three to seven important functions. To develop the
level 1 DFD, examine the high-level functional requirements in the SRS
document. If there are three to seven high-level functional requirements, then
each of these can be directly represented as a bubble in the level 1 DFD. Next,
examine the input data to these functions and the data output by these

functions as documented in the SRS document and represent them appropriately

in the diagram.
To draw the level 1 DFD, from a cursory analysis of the problem description, we
can see that there are four basic functions that the system needs to perform—accept
the input numbers from the user, validate the numbers, calculate the root mean
square of the input numbers and, then display the result.
Level 2 DFD: This level provides an even more detailed view of the system by
breaking down the sub-processes identified in the level 1 DFD into further sub-
processes. Each sub-process is depicted as a separate process on the level 2 DFD.
The data flows and data stores associated with each sub-process are also shown.

More Examples of DFD:

University Management System DFD Level 0
The context diagram is an alternative name for the Level 0 DFD Diagram for
University Management System. Users, the main process, and data flow make up
its parts. Also, the project concept is demonstrated using the single process
visualization.
DFD Level 0 shows the entities that interact with a system and defines the border
between the system and its environment. This diagram also depicts the university
management system at a high level.


The "detonated view" of the context diagram is University Management System
DFD Level 1. Its function is to deepen the concept derive from the context diagram.
Specifically, level 1 shows the broader details of University Management System
DFD Level 0. This is to clarify the paths (flow) of data and its transformation from
input to output.

Level 2 DFD for University Management System is also the highest abstraction of
the data flow diagram. This level also broadens the idea from the DFD level 1. It
includes the subprocesses from level 1 as well as the data that flows.

Example 2: Railway Reservation System

Shortcomings of the DFD model
DFD models suffer from several shortcomings. The important shortcomings of

DFD models are the following:
 Imprecise DFDs leave ample scope to be imprecise. In the DFD model, we

judge the function performed by a bubble from its label. However, a short
label may not capture the entire functionality of a bubble. For example, a
bubble named find-book-position has only intuitive meaning and does not
specify several things, e.g. what happens when some input information i s
missing or is incorrect.
 Not-well defined control aspects are not defined by a DFD. For
instance, the order in which inputs are consumed and outputs are produced by
a bubble is not specified. A DFD model does not specify the order in which
the different bubbles are executed.
 Decomposition: The method of carrying out decomposition to arrive at
the successive levels and the ultimate level to which decomposition is
carried out are highly subjective and depend on the choice and
judgment of the analyst. Due to this reason, even for the same problem,
several alternative DFD representations are possible.
 Improper data flow diagram: The data flow diagramming technique does
not provide any specific guidance as to how exactly to decompose a given
function into its subfunctions and we have to use subjective judgment to
carry out decomposition.

Data dictionary
Every DFD model of a system must be accompanied by a data dictionary. A data

dictionary lists all data items that appear in a DFD model. The data items
listed include all data flows and the contents of all data stores appearing
on all the DFDs in a DFD model. Please remember that the DFD model of a
system typically consists of several DFDs, viz., level 0 DFD, level 1 DFD, level 2
DFDs, etc.,
Note: A data dictionary lists the purpose of all data items and the definition of
all composite data items in terms of their component data items.
The dictionary plays a very important role in any software development process,
especially for the following reasons:
 A data dictionary provides a standard terminology for all relevant data

for use by the developers working in a project. A consistent vocabulary
for data items is very important, since in large projects different
developers of the project have a tendency to use different terms to refer to the
same data, which unnecessarily causes confusion.
 The data dictionary helps the developers to determine the definition of
different data structures in terms of their component elements while
implementing the design.
 The data dictionary helps to perform impact analysis. That is, it is possible
to determine the effect of some data on various processing activities and vice

versa. Such impact analysis is especially useful when one wants to check the
impact of changing an input value type, or a bug in some functionality, etc.
For large systems, the data dictionary can become extremely complex and
voluminous. Even moderate-sized projects can have thousands of entries in the data
dictionary. It becomes extremely difficult to maintain a voluminous dictionary
manually. Computer-aided software engineering (CASE) tools come handy to
overcome this problem. Most CASE tools usually capture the data items appearing
in a DFD as the DFD is drawn, and automatically generate the data dictionary. As a
result, the designers do not have to spend almost any effort in creating the data
dictionary. These CASE tools also support some query language facility to query
about the definition and usage of data items.
STRUCTURED DESIGN
The aim of structured design is to transform the results of the structured

analysis (that is, the DFD model) into a structure chart. A structure chart
represents the software architecture. The various modules making up the system,
the module dependency (i.e. which module calls which other modules), and the
parameters that are passed among the different modules. The structure chart
representation can be easily implemented using some programming language.
Since the main focus in a structure chart representation is on module structure
of a software and the interaction among the different modules, the
procedural aspects (e.g. how a particular functionality is achieved) are not
represented.

The basic building blocks using which structure charts are designed are as
following:
 Rectangular boxes: A rectangular box represents a module. Usually, every

rectangular box is annotated with the name of the module it represents.
 Module invocation arrows: An arrow connecting two modules implies
that during program execution control is passed from one module to the
other in the direction of the connecting arrow. However, just by
looking at the structure chart, we cannot say whether a modules calls another
module just once or many times.
 Data flow arrows: These are small arrows appearing alongside the module
invocation arrows. The data flow arrows are annotated with the
corresponding data name. Data flow arrows represent the fact that the
named data passes from one module to the other in the direction of the arrow.
 Library modules: A library module is usually represented by a rectangle with
double edges. Libraries comprise the frequently called modules. Usually,
when a module is invoked by many other modules, it is made into a library
module.
 Selection: The diamond symbol represents the fact that one module of several
modules connected with the diamond symbol i s invoked depending on the
outcome of the condition attached with the diamond symbol.
 Repetition: A loop around the control flow arrows denotes that the respective
modules are invoked repeatedly.

Example: Draw the structure chart for the RMS software
Example: Structure chart for the Supermarket Prize Scheme

OBJECT MODELLING USING UML
• In the object-oriented design method, the system is viewed as a collection of

objects (i.e., entities).
• The tasks defined for one purpose cannot refer or change data of other
objects.
• Objects have their internal data which represent their state. Similar objects
create a class.
• In other words, each object is a member of some class. Classes may inherit
features from the super class.
Or
It is well known that mastering an object-oriented programming language such as

Java or C++ rarely equips one with the skills necessary to develop good quality
object-oriented software—it is important to learn the object-oriented design skills
well. Once a good design has been arrived at, it is easy to code it using an object-
oriented language. It has now even become possible to automatically generate
much of the code from the design by using a CASE tool.
Note: A model is constructed by focusing only on a few aspects of the

problem and ignoring the rest. The model of a problem is called an analysis
model. On the other hand, the model of the solution (code) is called the design

model. The design model is usually obtained by carrying out iterative refinements
to the analysis model using a design methodology.
A model can be documented using a modelling language such as unified

modelling language (UML). Over the last decade, UML has become
immensely popular. UML has also been accepted by ISO as a standard for
modelling object-oriented systems.
BASIC OBJECT-ORIENTATION CONCEPTS
Objects
In the object-oriented approach, it is convenient to imagine the working of a

software in terms of a set of interacting objects.
For example, consider a manually operated library system. For issuing a book, an
issue register needs to be filled up and then the return date needs to be stamped

on the book. In an object-oriented library automation software, analogous

activities involving the book object and the issue register object take place.
Each object in an object-oriented program usually represents a tangible real-

world entity such as a library member, a book, an issue register, etc.
A key advantage of considering a system as a set of objects is the following:
When the system is analysed, developed, and implemented in terms of objects,

it becomes easy to understand the design and the implementation of the system,
since objects provide an excellent decomposition of a large problem into small
parts.
Each object essentially consists of some data that is private to the object and a
set of functions (termed as operations or methods ) that operate on those data.

Observe that the data of the object can only be accessed by the methods of the
object.
In other words, no object can directly access the data of any other object.
Therefore, each object can be thought of as hiding its internal data from other
objects. However, an object can access the private data of another object by
invoking the methods supported by that object. This mechanism of hiding data
from other objects is popularly known as the principle of data hiding or data
abstraction.
Class
Similar objects constitute a class. That is, all the objects constituting a class
possess similar attributes and methods. For example, the set of all library
members would constitute the class LibraryMember in a library automation
application. In this case, each library member object has attributes such as
member name, membership number, member address, etc. and also has methods
such as issue-book, return-book, etc.
Abstract data: The data of an object can be accessed only through its methods.
In other words, the exact way data is stored internally (stack, array, queue, etc.) in
the object is abstracted out (not known to the other objects).
Data type: In programming language terminology, a data type defines a collection

of data values and a set of predefined operations on those values. Thus, a data

type can be instantiated to create a variable of that type. We can instantiate a

class into objects. Therefore, a class is a data type.
Methods: The operations (such as create, issue, return, etc.) supported by an

object are implemented in the form of methods. Notice that we are distinguishing
between the terms operation and method. An operation is a specific
responsibility of a class, and the responsibility is implemented using a method.
Assume that the class provides three definitions for the create operation—int
create(), int create(int radius) and int create(float x, float y, int radius);. In this
case, we say that create is an overloaded method.
Note: The implementation of a responsibility of a class through multiple methods

with the same method name is called method overloading.
Class Relationships
Classes in a programming solution can be related to each other in the following

four ways:
• Inheritance
• Association and link
• Aggregation and composition
• Dependency

Inheritance
The inheritance feature allows one to define a new class by incrementally

extending the features of an existing class. The original class is called the base
class (also called superclass or parent class ) and the new class obtained
through inheritance is called the derived class (also called a subclass or a child
class ). The derived class is said to inherit the features of the base class. An
example of inheritance has been shown in Figure 7.3. In Figure 7.3, observe that
the classes Faculty, Students, and Staff have been derived from the base class
LibraryMember through an inheritance relationship (note the special type of
arrow that has been used to draw it).
A base class is said to be a generalisation of its derived classes. This means that
the base class should contain only those properties (i.e., data and methods) that
are common to all its derived classes. For example, in Figure 7.3 each of the

derived classes supports the issue-book method, and this method is supported by
the base class as well.
Two important advantages of using the inheritance mechanism in

programming include code reuse and simplicity of program design.
Association and link
Association is a common type of relation among classes. When two classes are
associated, they can take each others help (i.e. invoke each others methods) to
serve user requests. More technically, we can say that if one class is associated
with another bidirectionally, then the corresponding objects of the two classes
know each others ids (identities). As a result, it becomes possible for the object
of one class to invoke the methods of the corresponding object of the other class.
However, there can be situations where three or more different classes can be
involved in an association. As an example of a ternary association, consider

the following—A person books a ticket for a certain show. Here, an association
exists among the classes Person, Ticket, and Show.
A class can have an association relationship with itself. This is called recursive
association or unary association. As an example, consider the following—two
students may be friends. Here, an association named friendship exists among
pairs of objects of the Student class.
Link: When two classes are associated, the relationship between two objects of
the corresponding classes is called a link.
Example 7.1 Consider the following extract from a problem description. Identify
the association relation among classes and the corresponding association links
among objects from an analysis of the description. "A person works for a
company. Ram works for Infosys. Hari works for TCS."
Answer: In this example, an association relationship named works for exists

between the classes Person and Company. Ram works for Infosys, this implies
that a link exists between the object Ram and the object Infosys. Similarly, a works
for link exists between the objects Hari and TCS.
Important Note: An association describes a group of similar links. Alternatively,

we can say that a link can be considered as an instance of an association relation.

Composition and aggregation
Composition and aggregation represent part/whole relationships among

objects. Objects which contain other objects are called composite objects. As an
example, consider the following—A Book object can have upto ten Chapters. In
this case, a Book object is said to be composed of upto ten Chapter objects. The
composition/aggregation relationship can also be read as follows—A Book has
upto ten Chapter objects
Dependency
A class is said to be dependent on another class, if any changes to the latter class
necessitates a change to be made to the dependent class.
Dependencies among classes may arise due to various causes. Two important
reasons for dependency to exist between two classes are the following:
 A method of a class takes an object of another class as an argument.

 A class implements an interface class. In this case, dependency arises due to
the following reason. If some properties of the interface class are changed,
then a change becomes necessary to the class implementing the interface
class as well.

Other Key Concepts
Abstraction
Abstraction is the selective examination of certain aspects of a problem while

ignoring all the remaining aspects of a problem. In other words, the main
purpose of using the abstraction mechanism is to consider only those aspects of
the problem that are relevant to a given purpose and to suppress all aspects of
the problem that are not relevant.
Encapsulation
The data of an object is encapsulated within its methods. To access the data
internal to an object, other objects have to invoke its methods, and cannot
directly access the data. This concept is schematically shown in Figure 7.8.
Observe from Figure 7.8 that there is no way for an object to access the data
private to another object, other than by invoking its methods.
Encapsulation offers the following three important advantages:
• Protection from unauthorised data access: The encapsulation feature

protects an object’s variables from being accidentally corrupted by other
objects. This protection includes protection from unauthorised access and also
protection from the problems that arise from concurrent access to data such as
deadlock and inconsistent values.
• Data hiding: Encapsulation implies that the internal structure data of an
object are hidden, so that all interactions with the object are simple and
standardised. This facilitates reuse of a class across different projects.

Furthermore, if the internal data or the method body of a class are modified,
other classes are not affected. This leads to easier maintenance and bug
correction.
• Weak coupling: Since objects do not directly change each others internal
data, they are weakly coupled. Weak coupling among objects enhances
understandability of the design since each object can be studied and
understood in isolation from other objects.
Polymorphism
Polymorphism literally means poly (many) morphism (forms). Remember that

in Chemistry, diamond, graphite, and coal are called polymorphic forms of
carbon. That is, though diamond, coal, and graphite are essentially carbon, they

behave very differently. In an analogous manner in the object-oriented

paradigm, polymorphism denotes that an object may respond (behave) very
differently even when the same operation is invoked on it depending on the exact
polymorphic object to which the call gets bound. There are two main types of
polymorphisms in object-orientation:
Static polymorphism: Static polymorphism occurs when multiple methods

implement the same operation. In this type of polymorphism, when a method is
called (same method name but different parameter types), different
behaviour (actions) would be observed. This type of polymorphism is also
referred to as static binding, because the exact method to be bound on a method
call is determined at compiled-time (statically). Let us try to understand static
binding through the following example. Suppose a class named Circle has three
definitions for the create operation—int create(), int create(int radius), and int
create(float x, float y, int radius). Recollect that when multiple methods
implement the same operation, then the mechanism used is called method
overloading.
Dynamic polymorphism: Dynamic polymorphism is also called dynamic

binding. In dynamic binding,the exact method that would be invoked (bound) on
a method call can only be known at the run time (dynamically) and cannot be
determined at compile time. That is, the exact behaviour that would be produced
on a method call cannot be predicted at compile time and can only be observed at
run time.
Advantages of OOD
The main reason for the popularity of OOD is that it holds out the following
promises:
 Code and design reuse

 Increased productivity
 Ease of testing and maintenance
 Better code and design understandability enabling development of large
programs
Out of all the above mentioned advantages, it is usually agreed that the chief
advantage of OOD is improved productivity—which comes about due to a variety
of factors, such as the following:
 Code reuse by the use of predeveloped class libraries

 Code reuse due to inheritance
 Simpler and more intuitive abstraction, i.e., better management of inherent
problem and code complexity
 Better problem decomposition
Disadvantages of OOD
The following are some of the prominent disadvantages inherent to the object
paradigm:

 The principles of abstraction, data hiding, inheritance, etc. do incur run

time overhead due to the additional code that gets generated on account of
these features. This causes an project-oriented program to run a little slower
than an equivalent procedural program.
 An important consequence of object-orientation is that the data that is
centralised in a procedural implementation, gets scattered across
various objects in an object-oriented implementation. Therefore, the
spatial locality of data becomes weak and this leads to higher cache miss
ratios and consequently to larger memory access times. This finally shows
up as increased program run time.
UNIFIED MODELLING LANGUAGE (UML)
As the name itself implies, UML is a language for documenting models. As is the
case with any other language, UML has its syntax (a set of basic symbols and
sentence formation rules) and semantics (meanings of basic symbols and
sentences). It provides a set of basic graphical notations (e.g. rectangles, lines,
ellipses, etc.) that can be combined in certain ways to document the design and
analysis results.
It is important to remember that UML is neither a system design or

development methodology by itself, nor is tied to any specific methodology.
UML is merely a language for documenting models.
Or
• Unified Modeling Language (UML) is a general purpose modeling language.
• The main aim of UML is to define a standard way to visualize the way a
system has been designed.
• It is quite similar to blueprints used in other fields of engineering.
• UML is not a programming language, it is rather a visual language.
• We use UML diagrams to portray the behavior and structure of a system.
• UML helps software engineers, businessmen and system architects with

modeling, design and analysis
Note: UML can be used to document object-oriented analysis and design results
that have been obtained using any methodology.
Need of UML
• Complex applications need collaboration and planning from multiple teams

and hence require a clear and concise way to communicate amongst them.
• Businessmen do not understand code. So UML becomes essential to

communicate with non-programmers essential requirements, functionalities
and processes of the system.
• A lot of time is saved down the line when teams are able to visualize
processes, user interactions and static structure of the system.

UML 2.0
UML 2.0 defines thirteen types of diagrams, divided into three categories as
follows:
Structure diagrams: These include the class diagram, object diagram, component
diagram, composite structure diagram, package diagram, and deployment
diagram.
Behaviour diagrams: These diagrams include the use case diagram, activity
diagram, and state machine diagram.
Interaction diagrams: These diagrams include the sequence diagram,

communication diagram, timing diagram, and interaction overview diagram.

USE CASE MODEL
The use case model for any system consists of a set of use cases.
Roughly speaking, the use cases correspond to the high-level functional

Requirements.
Example: The use case model for the Tic-tac-toe game software is shown in Figure
7.15. This software has only one use case, namely, “play move”. Note that we did
not name the use case “get-user-move”, as “get-user move” would be
inappropriate because this would represent the developer’s perspective of the
use case. The use cases should be named from the users’ perspective.
Text description
Each ellipse in a use case diagram, by itself conveys very little information,
other than giving a hazy idea about the use case. Therefore, every use case
diagram should be accompanied by a text description. The text description

should define the details of the interaction between the user and the
computer as well as other relevant aspects of the use case. It should include all
the behaviour associated with the use case in terms of the mainline sequence,
various alternate sequences, the system responses associated with the use case,
the exceptional conditions that may occur in the behaviour, etc.
Notations of Use Cases:
Actors
Actors are external entities that interact with the system. These can include users,
other systems, or hardware devices. In the context of a Use Case Diagram, actors
initiate use cases and receive the outcomes. Proper identification and
understanding of actors are crucial for accurately modeling system behavior.

Use Cases
Use cases are like scenes in the play. They represent specific things your system
can do. In the online shopping system, examples of use cases could be “Place
Order,” “Track Delivery,” or “Update Product Information”. Use cases are
represented by ovals.
System Boundary
The system boundary is a visual representation of the scope or limits of the system
you are modeling. It defines what is inside the system and what is outside. The
boundary helps to establish a clear distinction between the elements that are part
of the system and those that are external to it. The system boundary is typically
represented by a rectangular box that surrounds all the use cases of the system.
Example 7.3 The use case diagram of the Super market prize scheme

Text description
U1: register-customer: Using this use case, the customer can register himself by
providing the necessary details.
Scenario 1: Mainline sequence
1. Customer: select register customer option
2. System: display prompt to enter name, address, and telephone number.
3. Customer: enter the necessary values
4: System: display the generated id and the message that the customer has
successfully been registered.
Scenario 2: At step 4 of mainline sequence
4: System: displays the message that the customer has already registered.
Scenario 3: At step 4 of mainline sequence
4: System: displays message that some input information have not been entered.
The system displays a prompt to enter the missing values.
U2: register-sales: Using this use case, the clerk can register the details of the
purchase made by a customer.
1. Clerk: selects the register sales option.

2. System: displays prompt to enter the purchase details and the id of the
customer.
3. Clerk: enters the required details.
4: System: displays a message of having successfully registered the sale.
U3: select-winners. Using this use case, the manager can generate the winner
list.
1. Manager: selects the select-winner option.
2. System: displays the gold coin and the surprise gift winner list.
Use Case Diagram Relationships
Include relationship: The includes relationship implies one use case includes the
behaviour of another use case in its sequence of events and actions. The includes
relationship is appropriate when you have a chunk of behaviour that is similar
across a number of use cases.
Example: The use cases issue-book and renew-book both include check-
reservation use case.

Generalisation
Use case generalisation can be used when you have one use case that is similar to
another, but does something slightly differently or something more.
Generalisation works the same way with use cases as it does with classes. The
child use case inherits the behaviour and meaning of the present use case.

Extends
The main idea behind the extends relationship among use cases is that it allows
you show optional system behaviour. An optional system behaviour is executed
only if certain conditions hold, otherwise the optional behaviour is not executed.
This relationship among use cases is also predefined as a stereotype as shown.
Association
Association between two classes is represented by drawing a straight line

between the concerned classes. The name of the association is written along
side the association line. An arrowhead may be placed on the association line to
indicate the reading direction of the association.
Example: “Many books may be borrowed by a LibraryMember”.

Aggregation
Aggregation is a special type of association relation where the involved classes

are not only associated to each other, but a whole-part relationship exists
between them. That is, the aggregate object not only knows the addresses of its
parts and therefore invoke the methods of its parts, but also takes the
responsibility of creating and destroying its parts.
Aggregation is represented by an empty diamond symbol at the aggregate end of a

relationship. An example of the aggregation relationship has been shown in Fig
7.25.
Observe that the number 1 is annotated at the diamond end, and a * is annotated
at the other end. This means that one document can have many paragraphs.
Composition
Composition is a stricter form of aggregation, in which the parts are existence-

dependent on the whole. This means that the life of the parts cannot exist
outside the whole. In other words, the lifeline of the whole and the part are
identical. When the whole is created, the parts are created and when the whole is
destroyed, the parts are destroyed.

A typical example of composition is an order object where after placing the order,
no item in the order cannot be changed. If any changes to any of the order items
are required after the order has been placed, then the entire order has to be
cancelled and a new order has to be placed with the changed items. In this case,
as soon as an order object is created, all the order items in it are created and as
soon as the order object is destroyed, all order items in it are also destroyed.
Aggregation versus Composition: Both aggregation and composition represent

part/whole relationships. When the components can dynamically be added and
removed from the aggregate, then the relationship is aggregation. If the
components cannot be dynamically added/delete then the components are have
the same life time as the composite. In this case, the relationship is represented by
composition.
CLASS DIAGRAMS
A class diagram describes the static structure of a system. It shows how a system is
structured rather than how it behaves. The static structure of a system comprises
a number of class diagrams and their dependencies. The main constituents of a
class diagram are classes and their relationships—generalisation, aggregation,
association, and various kinds of dependencies.

Example:
Composite Structure Diagram
• We use composite structure diagrams to represent the internal structure of a

class and its interaction points with other parts of the system.
• A composite structure diagram represents relationship between parts and

their configuration which determine how the classifier (class, a component,
or a deployment node) behaves.
• They represent internal structure of a structured classifier making the use of

parts, ports, and connectors.
Or
The composite structure diagram lets you define how a class is defined by a
further structure of classes and the communication paths between these parts.
Some new core constructs such as parts, ports and connectors are introduced.
Part: The concept of parts makes possible the description of the internal structure
of a class.
Port: The concept of a port makes it possible to describe connection points

formally. These are addressable, which means that signals can be sent to them.
Connector: Connectors can be used to specify the communication links between

two or more parts.
Composite Structure Diagrams show the internal parts of a class.
Parts are named: partName:partType[multiplicity]
Aggregated classes are parts of a class but parts are not necessarily classes, a
part is any element that is used to make up the containing class.

Example: The example in the figure shows how the composite structure diagram
identifies the containing classifier, Car. The diagram frame shows four internal
composite parts of the containing classifier, which represent the four wheels of
the car and are of the type Wheel. A communication link connects the front
wheels and the rear wheels with connectors named frontaxle and rearaxle.
Whenever you create a composite structure diagram from the Car classifier, four
instances of the Wheel class are created. These parts are held by composition
within the Car instance and the front wheels and the rear wheels are linked by
connectors.

Object diagrams
Object diagrams shows the snapshot of the objects in a system at a point in time.
Since it shows instances of classes, rather than the classes themselves, it is often
called as an instance diagram.
Package diagram
A package is a grouping of several classes. In fact, a package diagram can be used

to group any UML artifacts. Packages are popular way of organising source code
files. Java packages are a good example which can be modelled using a package
diagram. Such package diagrams show the different class groups (packages) and
their inter dependencies. These are very useful to document organisation of
source files for large projects that have a large number of program files.

Package Diagram Example - Order Processing System
Order Processing System - The Problem Description
We are going to design package diagram for "Track Order" scenario for an online
shopping store. Track Order module is responsible for providing tracking
information for the products ordered by customers. Customer types in the tracking
serial number, Track Order modules refers the system and updates the current
shipping status to the customer.
Task 1: Identify the packages of the system
 There is a track order module, it has to talk with other module to know about
the order details, let us call it "Order Details".
 Next after fetching Order Details it has to know about shipping details, let us
call that as "Shipping".
Identify the dependencies in the System
 Track order should get order details from "Order Details" and "Order Details"
has to know the tracking info given by the customer. Two modules are
accessing each other which suffices <<access>> dual dependency

• To know shipping information, "Shipping" can import "Track Order" to make

the navigation easier.
• Finally, Track Order dependency to UI Framework is also mapped which
completes our Package Diagram for Order Processing subsystem.

Deployment Diagram
The deployment diagram shows the environmental view of a system.That is, it

captures the environment in which the software solution is implemented.
In other words, a deployment diagram shows how a software system will be

physically deployed in the hardware environment. That is, which component will
execute on which hardware component and how they will they communicate with
each other. Since the diagram models the run time architecture of an application,
this diagram can be very useful to the system’s operation staff.
he environmental view provided by the deployment diagram is important for

complex and large software solutions that run on hardware systems comprising
multiple components.

Component Diagram
A component represents a piece of software that can be independently purchased,

upgraded, and integrated into an existing software. A component diagram can
be used to represent the physical structure of an implementation in terms of the
various components of the system. A component diagram is typically used to
achieve the following purposes:
• Organise source code to be able to construct executable releases.

• Specify dependencies among different components.
Or
A component diagram is used to break down a large object-oriented system into

the smaller components, so as to make them more manageable. It models the
physical view of a system such as executables, files, libraries, etc. that resides
within the node.
It visualizes the relationships as well as the organization between the components

present in the system. It helps in forming an executable system. A component is a
single unit of the system, which is replaceable and executable.
The example above shows the internal components of a larger component:
• The data (account and inspection ID) flows into the component via the port on
the right-hand side and is converted into a format the internal components can

use. The interfaces on the right are known as required interfaces, which
represents the services the component needed in order to carry out its duty.
• The data then passes to and through several other components via various
connections before it is output at the ports on the left. Those interfaces on the
left are known as provided interface, which represents the services to deliver
by the exhibiting component.
• It is important to note that the internal components are surrounded by a large
'box' which can be the overall system itself (in which case there would not be
a component symbol in the top right corner) or a subsystem or component of
the overall system (in this case the 'box' is a component itself).
Required Interface symbols with only a half circle at their end (a.k.a. sockets)
represent an interface that the component requires (in both cases, the
interface's name is placed near the interface symbol itself).
Provided interface symbols with a complete circle at their end represent an

interface that the component provides - this "lollipop" symbol is shorthand for a
realization relationship of an interface classifier.
INTERACTION DIAGRAMS
When a user invokes one of the functions supported by a system, the

required behaviour is realised through the interaction of several objects in the

system. Interaction diagrams, as their name itself implies, are models that describe
how groups of objects interact among themselves through message passing to
realise some behaviour.
Note: Typically, each interaction diagram realises the behaviour of a single use
case.
Interaction diagrams: These diagrams include the sequence diagram,

communication diagram, timing diagram, and interaction overview diagram.
Sequence Diagram
A sequence diagram shows interaction among objects as a two dimensional

chart. The chart is read from top to bottom. The objects participating in the
interaction are shown at the top of the chart as boxes attached to a vertical
dashed line. Inside the box the name of the object is written with a colon
separating it from the name of the class and both the name of the object and the
class are underlined. This signifies that we are referring any arbitrary instance of
the class.
Or
Sequence Diagram is an interaction diagram that details how operations are

carried out -- what messages are sent and when. Sequence diagrams are organized
according to time. The time progresses as you go down the page. The objects

involved in the operation are listed from left to right according to when they take
part in the message sequence.
Example:
Below is a sequence diagram for making a hotel reservation. The object initiating
the sequence of messages is a Reservation window.

Note That: Class and object diagrams are static model views. Interaction diagrams
are dynamic. They describe how objects collaborate.
Notation Description
Actor
• a type of role played by an entity that interacts with the subject (e.g., by
exchanging signals and data)
• represent roles played by human users, external hardware, or other subjects.

Lifeline
A lifeline represents an individual participant in the Interaction.
Activations
• A thin rectangle on a lifeline) represents the period during which an element is

performing an operation.
• The top and the bottom of the of the rectangle are aligned with the initiation
and the completion time respectively.

Call Message
 A message defines a particular communication between Lifelines of an

Interaction.
 Call message is a kind of message that represents an invocation of operation
of target lifeline.
Return Message

Interaction.
 Return message is a kind of message that represents the pass of information
back to the caller of a corresponded former message.

Self Message

Interaction.
 Self message is a kind of message that represents the invocation of message of
the same lifeline.
Recursive Message

Interaction.
 Recursive message is a kind of message that represents the invocation of
message of the same lifeline. It's target points to an activation on top of the
activation where the message was invoked from.
Communication Diagram
UML communication diagrams, like the sequence diagrams - a kind of interaction

diagram, shows how objects interact. A communication diagram is an extension of
object diagram that shows the objects along with the messages that travel from one
to another. In addition to the associations among objects, communication diagram
shows the messages the objects send each other.

In the example of the notation for a communication diagram, objects (actors in use
cases) are represented by rectangles. In the example (generic communication
diagram):
 The objects are Object1, Object2, Object..., ObjectN-1 ..., and ObjectN.
 Messages passed between objects are represented by labeled arrows that start
with the sending object (actor) and end with the receiving object.
 The sample messages passed between objects are labeled 1: message1, 2:
message2, 3: message3, etc., where the numerical prefix to the message name
indicates its order in the sequence.
 Object1 first sends Object2 the message message1, Object2 in turn sends
ObjectN-1 the message message2, and so on.
 Messages that objects send to themselves are indicated as loops (e.g., message
message5).

Example: The communication diagram explains the process to add an event to a

calendar.
Timing Diagram:
Timing diagrams focus on conditions changing within and among lifelines along a
linear time axis. Timing Diagrams describe behavior of both individual classifiers
and interactions of classifiers, focusing attention on time of occurrence of events
causing changes in the modeled conditions of the Lifelines.

Value Lifeline representation

Multiple Compartments
Activity Diagram
he activity diagram focuses on representing various activities or chunks of

processing and their sequence of activation. The activities in general may not
correspond to the methods of classes. An activity is a state with an internal action
and one or more outgoing transitions which automatically follow the termination
of the internal activity. If an activity has more than one outgoing transitions, then
exact situation under which each is executed must be identified through
appropriate conditions.

Activity diagrams are similar to the procedural flow charts. The main
difference is that activity diagrams support description of parallel activities and
synchronisation aspects involved in different activities.
For example, in Figure 7.32 the swim lane corresponding to the academic section,
the activities that are carried out by the academic section and the specific situation
in which these are carried out are shown.
STATE CHART DIAGRAM
A state chart diagram is normally used to model how the state of an object
changes in its life time. State chart diagrams are good at describing how the

behaviour of an object changes across several use case executions. However, if

we are interested in modelling some behaviour that involves several objects
collaborating with each other, state chart diagram is not appropriate.
State chart diagrams are based on the finite state machine (FSM) formalism.
An FSM consists of a finite number of states corresponding to those of the object
being modelled. The object undergoes state changes when specific events
occur.
Basic elements of a state chart
The basic elements of the state chart diagram are as follows:
Initial state: This represented as a filled circle.
Final state: This is represented by a filled circle inside a larger circle.
State: These are represented by rectangles with rounded corners.
Transition: A transition is shown as an arrow between two states. Normally, the

name of the event which causes the transition is places along side the arrow. You
can also assign a guard to the transition. A guard is a Boolean logic condition. The
transition can take place only if the guard evaluates to true. The syntax for the
label of the transition is shown in 3 parts— [guard]event/action.


Unit 1 Chapter 3

Uploaded by

Copyright:

Available Formats

Unit 1 Chapter 3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 1 Chapter 3

Uploaded by

Copyright:

Available Formats

Software Engineering

Prepared By: Er. Inderjeet Singh(e8822) Page 1

Function Oriented Design

Function Oriented Design is an approach to software design where the design

• In function-oriented design, the system is comprised of many smaller sub-

Prepared By: Er. Inderjeet Singh(e8822) Page 2

Function Oriented Design Strategies

Function Oriented Design Strategies are as follows:

2. Data Dictionaries: Data dictionaries are simply repositories to store

Prepared By: Er. Inderjeet Singh(e8822) Page 3

of the item, Aliases (Other names for items), Description / purpose,

3. Structure Charts: Structure chart is the hierarchical representation of

4. Pseudo Code: Pseudo Code is system description in short English like

OVERVIEW OF SA/SD METHODOLOGY

 Structured analysis (SA)

 During structured analysis, the SRS document is transformed into a data

Prepared By: Er. Inderjeet Singh(e8822) Page 4

 During structured design, the DFD model is transformed into a structure

Note: It is important to understand that the purpose of structured analysis is

Prepared By: Er. Inderjeet Singh(e8822) Page 5

 Top-down decomposition approach.

Data Flow Diagrams (DFDs)

he DFD (also known as the bubble chart) is a simple graphical formalism

Prepared By: Er. Inderjeet Singh(e8822) Page 6

Function/Process symbol: A function is represented using a circle. This symbol is

External entity symbol: An external entity such as a librarian, a library

Prepared By: Er. Inderjeet Singh(e8822) Page 7

item number flowing from the process read-number to validate-number, data-item

Note: A DFD is a hierarchical graphical model of a system that shows

Prepared By: Er. Inderjeet Singh(e8822) Page 8

DEVELOPING THE DFD MODEL OF A SYSTEM

A DFD model of a system graphically represents how each input data is

The DFD model of a system is constructed by using a hierarchy of DFDs (see

Prepared By: Er. Inderjeet Singh(e8822) Page 9

Commonly made errors while constructing a DFD model

Prepared By: Er. Inderjeet Singh(e8822) Page 10

system should be represented only in the context diagram. The external

 Data can not flow between two entities. –

Prepared By: Er. Inderjeet Singh(e8822) Page 11

Example: (RMS Calculating Software) A software system called RMS

Prepared By: Er. Inderjeet Singh(e8822) Page 12

Prepared By: Er. Inderjeet Singh(e8822) Page 13

functions as documented in the SRS document and represent them appropriately

Prepared By: Er. Inderjeet Singh(e8822) Page 14

More Examples of DFD:

Prepared By: Er. Inderjeet Singh(e8822) Page 15

University Management System DFD Level 1

Prepared By: Er. Inderjeet Singh(e8822) Page 16

University Management System DFD Level 2

Prepared By: Er. Inderjeet Singh(e8822) Page 17

Example 2: Railway Reservation System

Prepared By: Er. Inderjeet Singh(e8822) Page 18

Shortcomings of the DFD model

DFD models suffer from several shortcomings. The important shortcomings of

 Imprecise DFDs leave ample scope to be imprecise. In the DFD model, we

Prepared By: Er. Inderjeet Singh(e8822) Page 19

Every DFD model of a system must be accompanied by a data dictionary. A data

 A data dictionary provides a standard terminology for all relevant data

Prepared By: Er. Inderjeet Singh(e8822) Page 20

The aim of structured design is to transform the results of the structured