INF465 Information system modeling pour master.pdf

Cours de modélisation de SI pour master

1. INF465
Course Lecturer: Dr. KIMBI
Xaveria
INFORMATION
SYSTEM MODELING

2. Course Content
Module 1: Introduction to Information System Modeling
The rudiments of Modeling

Design Concepts: Cohesion and Coupling

Modeling tool Work bench: Draw.IO

Configuration of Twillio
Module 2: UML Modeling

Behavioral Modeling

A real life case study
Module 3: UML Modeling
●
Structural Modeling
●
A real life case study
Module 4: Process Modeling

Modeling with Data Flow Diagrams.

A real life case study

3. GENERAL INTRODUCTION TO
INFORMATION SYSTEM MODELING
•System Analysis Versus System Design
•What is Information System Modeling?
•Design Concepts: Cohesion and Coupling
•Information modeling approaches

4. Software design is an art, - We can discover principles and
techniques useful to be applied throughout the process of
software creation, but we probably won’t ever be able to
provide an exact path to follow from the real world need to
the code module meant to serve that need.

5. ●
Is there any difference between System Analysis and
System Design?

6. What is System Analysis?
What is System Design?
- ,
System Analysis Versus System Design

7. System Analysis Vs System Design
Analysis
●What is the problem?
●what happens in the current system?
●Have you understood domain analysis
●what is required in the new system?
●Results (Outcome of Analysis phase):SRSD
- Detail understanding of requirements and domain properties

8. System Analysis Vs System Design
Software Design
●Software design is a creative activity in which you identify software components and their relationships,
based on customer’s requirements
Investigates “how to build a solution”
●How will the new system work?
●How can we solve the problem that the analysis phase identified?
●Results in a solution to the problem. I.E The purpose of Design phase in the Software Development Life
Cycle is to produce a solution to a problem given in the SRS(Software Requirement Specification)
document. The output of the design phase is Software Design Document (SDD)
-An architectural design to provide solution to the identified problem
- A working system that satisfies the requirements: Hardware + Software + ‘Peopleware’
- Focuses on building technical solutions
●Separate activities but not necessary sequential

9. Steps in System Analysis
●This phase has three steps:
(1) An analysis strategy is developed to guide the project team’s
efforts. Such a strategy usually includes a study of the current
system (called the as-is system) and its problems, and envisioning
ways to design a new system (called the to-be system).
(2) The next step is requirements gathering (e.g., through
interviews, group workshops, written documents or questionnaires).
(3) The production of specification document called Software
Requirement Specification (SRS) document.

10. Design Concepts: Cohesion and Coupling
●Coupling and cohesion are methods to measure the relationship
between and within modules. A software system is divided into
multiple modules, where each and every module are capable of
performing a function independently. This technique is known as
Modularization
●Coupling is the degree of inter-dependencies between software
modules.
●Cohesion is the degree of intra-dependencies within the
functionalities in a software component.

11. Cohesion and Coupling

12. Why Information System Modeling?
•Since software applications are critical in modern life, it is very important
to provide adequate means of communication between the development
team and stakeholder by modeling business requirement.
•The main advantage of information system modeling is the architectural
separation of concerns, thereby reducing system complexity.

13. What type of modeling approaches exist and how can these
approaches contribute to the modeling of complex
infrastructure in an appropriate way?

14. Information modeling approaches
Some information system modeling approaches are:
●Data Modeling Approach e.g. Entity Relationship Modeling
●Process Modeling Approach e.g Data Flow Diagram
●Object Modeling Approach e.g UML

15. Object Modeling Using UMLObject Modeling Using UML

16. OutlineOutline
●What is UML and why we use UML?
●What UML Modeling tools do we use today?
●How to use UML diagrams to design software system

17. What is UML and why we use UML?What is UML and why we use UML?
●UML → “Unified Modeling Language” - UML is a standardized
specification language for object modeling.
●UML is a standardized general-purpose modeling language for object modeling.

●Unified: UML has become a world standard Object Management Group (OMG): www.omg.org
●Modeling: Describing a software system at a high level of abstraction
●Language: Expresses idea, not a methodology

18. What is UML and why we use UML?What is UML and why we use UML?
●It is a industry-standard graphical language for specifying, visualizing,
constructing, and documenting the artifacts of software systems.
●The UML uses mostly graphical notations to express the OO analysis and
design of software projects. 
●Simplifies the complex process of software design
●There are a variety of different object-oriented design processes that depend
on the organization using the processes

19. What is UML and why we use UML?What is UML and why we use UML?
●Why we use UML?
●Use graphical notation: more clearly than natural language (imprecise) and code (too
detailed).
●Help acquire an overall view of a system.
●UML is not dependent on any one language or technology.

20. 1997: UML 1.0, 1.1
1996: UML 0.9 & 0.91
1995: Unified Method 0.8
Other methods
Booch ‘91
Booch ‘93
OMT - 2
OMT - 1
Year Version
2003: UML 2.0
2001: UML 1.4
1999: UML 1.3

21. What UML Modeling tools do we use today? What UML Modeling tools do we use today?
There are several UML modeling tools available. Some of them
are:
●Draw.IO
●Star UML
●ArgoUML: http://argouml.tigris.org/
●Rational Rose (www.rational.com) by IBM
●
●

22. How to use UML diagrams to design software system How to use UML diagrams to design software system
This will take us to different views (categories) of UML Diagrams:This will take us to different views (categories) of UML Diagrams:

23. Categories of UML DiagramsCategories of UML Diagrams
●Structural (static) UML Diagrams
●Behavioural (dynamic) UML Diagrams
●Exercise:
Explain two categories of UML diagrams and hence give
five (5) examples in each category.

24. Static (Structural) vs Dynamic (Behavioral) View
●Static Modeling is used to specify the structure of the objects, classes or components that exists in the
problem domain.
●Structural or static view emphasis on the static structure of the system using objects, attributes,
operations and relationships.
●These are express using Class, Object or Component.
●It includes Class diagrams and Composite structure diagrams.
●Behavioral or dynamic view shows how the system behaves and interacts with itself and other
entities (users and other systsm). They show how data move through the system, how objects
communicate with each other, how the passage of time affects the system, or what event cause the
system to chage internal states.
●Since behavioral diagrams illustrate the behavior of the system, they are used extensively to
describe the functionality of software systems.
● It is represented by Sequence, Activity, Use Case diagrams, Collaboration and State diagrams.

25. Structural UML DiagramsStructural UML Diagrams
●UML Class diagram
●UML Composite Structure Diagram
●UML Component Diagram
●UML Deployment Diagram
●UML Object Diagram
●UML package Diagram.

26. Behavioural UML DiagramsBehavioural UML Diagrams
●UML Use Case diagram
●Activity diagram
●State Machine diagram
●Sequence diagram
●Collaboration diagram

27. Modeling using Use Case Diagram Modeling using Use Case Diagram
●Understanding the relationships between the software that is being
designed and its external environment is essential for deciding how to
provide the required system functionality and how to structure the system
to communicate with its environment.
●Understanding of the context also lets you establish the boundaries of
the system. Setting the system boundaries helps you decide what
features are implemented in the system being designed and what
features are in other associated systems.
●Use case diagram models the interaction between Actors and
Software

28. Use Case Diagram ElementsUse Case Diagram Elements
●
Actors: A role that a user plays with respect to the system, including human users and other systems. e.g., it can
be real or abstract/inanimate objects.
- Real objects e.g students, doctors, patients, supervisors,
- Inanimate physical objects - an external system that needs some information from the current system e.g. robot,
Control System for determining electricity consumption or Control System for weather investigation
.
●
Use case: A set of scenarios that describing an interaction between a user and a system, including alternatives.
●
System boundary: Rectangle diagram representing the boundary between the actors and the system.

29. Use Case Diagram Use Case Diagram ElementsElements
●
Association:
communication between an actor and a use case; Represented by a solid line.
●
Generalization: relationship between one general use case and a special use case (used for defining
special alternatives) Represented by a line with a triangular arrow head toward the parent use case.

30. Use Case Diagram Use Case Diagram ElementsElements
<<include>>
Extend: a dotted line labeled <<extend>> with an arrow toward the base case. The extending use
case may add behavior to the base use case. The base class declares “extension points”.

<<extend>>

Include: a dotted line labeled <<include>> beginning at base use case and ending with an arrows
pointing to the include use case. The include relationship occurs when a chunk of behavior is
similar across more than one use case. Use “include” in stead of copying the description of that
behavior.

31. Use Case DiagramsUse Case Diagrams
Library Management System
Borrow
Order Title
Fine Remittance/Penalty
Student
Employee
Supervisor
Boundary
Actor
Use Case

32. Use Case DiagramsUse Case Diagrams
Figure 16.12

33. Use Case DiagramsUse Case Diagrams
●
Both Make Appointment and
Request Medication include
Check Patient Record as a
subtask (include)
●
The extension point is written
inside the base case Pay bill; the
extending class Defer payment
adds the behavior of this extension
point. (extend)
●
Pay Bill is a parent use case and
Bill Insurance is the child use
case. (generalization)

36. Exercise
(a) To give an exam, an Instructor first notifies the Students of Computer Science department of the
exam date and the material to be covered. She then prepares the exam paper (with sample solutions
to each question) with referenced to syllabus, gives it to the Examination Officer for multiplication,
that is, gets it copied to produce enough copies for the class. The Instructor hands the exam papers
to students on the designated time and location. The Students write their answers to exam
questions and hand in their papers to the Instructor. The Instructor then gives the exam booklets to
the Examination Unit for verification after which the booklets are returned to the Instructor. Along with
sample solutions to each question, the Instructor distributed the booklets to concern Lecturers and
gets them to mark it. She (Instructor) then records all marks and returns the papers to the students.
Draw a Use case diagram that represents this process. Make sure to show when is each actor
participating in the process.
This Exercise was done last week (22/10/22)

37. UML CLASS DIAGRAMUML CLASS DIAGRAM

38. UM.L Class DiagramsUM.L Class Diagrams
●What is a Class and What is an Object?
●What is Class Diagram?
●Class Diagram in Software Development Life cycle
●Benefits of Class Diagram
●Essential elements of A UML class diagram ( Class Name, Attributes, Methods/Function)
●Class Name
●Attributes:
●Relationships
●Aggregation vs. Composition
●Abstract Classes
●Example of UML Class Diagram:
●Best practices of Designing of the Class Diagram

39. QuestionQuestion
●What is the difference between a Class and an Object?

40. Class and ObjectClass and Object
Difference between Class and Object
●Class –
- A description of a set of objects that have something in common.
- Class is also a programming concept used to define objects that have the same attributes,
operations, relationships and semantics.
●Object –
-An object is an instance of a Class.
- Objects are created from a Class at run-time. Since Classes have state, an object retains
information about its attributes for some indefinite time. This is different than functions or
subprograms

41. What is Class?
●A Class is a blueprint that is used to create Object. The Class
defines what object can do

42. What is Class Diagram?
●
UML CLASS DIAGRAMUML CLASS DIAGRAM gives an overview of a software system by displaying classes,
attributes, operations, and their relationships. This Diagram includes the class name,
attributes, and operation in separate designated compartments. I.e UML class defines the
types of objects in a system, the attributes, operations and the different types of relationships
that exist among them.
●Class Diagram defines the types of objects in the system and the different types of
relationships that exist among them. It gives a high-level view of an application. This
modeling method can run with almost all Object-Oriented Methods.
●A class can refer to another class. A class can have its objects or may inherit from other
classes

43. Class Diagram in Software Development Life cycleClass Diagram in Software Development Life cycle
●Class diagrams can be used in various software development phases.
●
It helps in modeling class diagrams in two different perspectives:It helps in modeling class diagrams in two different perspectives:
- Conceptual Perspective- Conceptual Perspective
- Implementation Perspective- Implementation Perspective
(1). Conceptual perspective: Conceptual diagrams are describing things in the real world. You
should draw a diagram that represents the concepts in the domain under study. These These
concepts related to class and it is always language-independent. concepts related to class and it is always language-independent.
(2) Implementation perspective: This type of class diagrams is used for implementations in a
specific language or application. Implementation perspective, use for software
implementation - language-dependent. language-dependent.

44. Benefits of Class DiagramBenefits of Class Diagram
●Class Diagram Illustrates data models for even very complex information
systems
●It provides an overview of how the application is structured before studying
the actual code. This can easily reduce the maintenance time
●It helps for better understanding of general schematics of an application. - -
provides the basic structure for other UML diagramsprovides the basic structure for other UML diagrams
●Allows drawing detailed charts which highlights code required to be
programmed
●Helpful for developers and other stakeholders. - Breaks down system Breaks down system
complexity for the development team and other stakeholderscomplexity for the development team and other stakeholders

45. Essential elements of A UML class diagramEssential elements of A UML class diagram
●Essential elements of UML class diagram are:
- Class Name (Class Identity)
- Attributes (Behavior)
- Operations (Methods/Functions)
attributesattributes
Class NameClass Name
operationsoperations

46. Class Name
●The name of the class is only needed in the graphical representation of the class. It
appears in the topmost compartment. A class is the blueprint of an object which can
share the same relationships, attributes, operations, & semantics. The class is
rendered as a rectangle, including its name, attributes, and operations in separate
compartments.
Following rules must be taken care of while representing a classFollowing rules must be taken care of while representing a class:
●A class name should always start with a capital letter.
●A class name should always be in the center of the first compartment.
●A class name should always be written in bold format.
●An abstract class name should be written in italics format

47. Exercise/TDExercise/TD
Identify the actors and the objects in the following scenario to register a patient in a Identify the actors and the objects in the following scenario to register a patient in a
hospital management system:hospital management system:
●The administrator enters the patient’s name, address, date of birth and emergency contact
details into the system. If the patient has only public health insurance, the administrator
enters the patient’s medicare number, and the system verifies this with government health
database. If the patient also has private health insurance, then the administrator enters also
the patient’s private health insurance details, and the system verifies these details with the
private health insurance system. When these details are verified as correct, the system saves
the patient's details and confirms the registration, thereafter, the patient can see the doctor.

48. ●Actors:
- Administrator, Patient, Doctor, Government Health Database, Private
Health Insurance System
(The last two are external systems)
●Objects:
-Administrator, Patient, Doctor, PublicHealthInsurance,
PrivateHealthInsurance, Registration

49. Attributes
●An attribute is named property of a class which describes the object being modeled. In the
class diagram, this component is placed just below the name-compartment.
●A derived attribute is computed from other attributes. For example, an age of the student can
be easily computed from his/her birth date
Attributes characteristicsAttributes characteristics
●Attributes must have a meaningful name that describes the use of it in a class
●The attributes are generally written along with the visibility factor.
●Public, private, protected and package are the four visibilities which are denoted by +, -, #, or
~ signs respectively.
●Visibility describes the accessibility of an attribute of a class.

50. Some Relationship between classesSome Relationship between classes
Question:Question:
(1) List three (3) types of relationships that are frequently used
in a UML Class Diagram and hence with respect to any E-
commerce System of your choice, explain graphically the
relationships using UML Class Diagram.
(2) Draw a UML Class Diagram for ATM machine.
N/B: All multiplicities must be shown.

51. Some Relationship between classesSome Relationship between classes
Aggregation
●Aggregation displays a relationship whereby the child class can exist separately from the
parent class.
●Aggregation is a special type of association that models a “whole- part” relationship between
aggregate and its parts.
●The symbol for aggregation is an open diamond shape pointing towards the parent class.
●For example, the class college is made up of one or more student. In aggregation, the
contained classes are never totally dependent on the life cycle of the container. Here, the
college class will remain even if the student is not available.
●Another Example: Automobile (Parent) and Car (Child). So, If you delete the Automobile, the
child Car still exist.

52. COMPOSITIONCOMPOSITION
●Composition display relationship whereby the child will never
exist independent of the parent.

53. UML Sequence Diagrams

54. ●What is a Sequence Diagram?
●Purpose of a Sequence Diagram
●Sequence Diagram Notations
●Drawing of Sequence Diagrams
●Sequence Diagram Best Practices

55. What is a Sequence Diagram? What is a Sequence Diagram?
●
●Sequence Diagrams show elements as they interact over time and how they
are organized according to object (horizontally) and time (vertically).
●A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place. We can
also use the terms event diagrams or event scenarios to refer to a sequence
diagram. Sequence diagrams describe how and in what order the objects in a
system function

56. Purpose of Sequence DiagramPurpose of Sequence Diagram
●Model high-level interaction between active objects in a system
●Model the interaction between object instances within a collaboration that
realizes a use case
●Model the interaction between objects within a collaboration that realizes an
operation
●Either model generic interactions (showing all possible paths through the
interaction) or specific instances of a interaction (showing just one path
through the interaction)

57. Sequence Diagram NotationsSequence Diagram Notations
●Actors
●Lifelines
●Activation Bar
●Messages

58. ActorsActors
●a type of role played by an entity that interacts
with the subject (e.g., by exchanging signals and data)
●external to the subject (i.e., in the sense that an instance of an actor is not a
part of the instance of its corresponding subject).
●represent roles played by human users, external hardware, or other subjects
(external resources).
Note that:
●An actor does not necessarily represent a specific physical entity but merely a
particular role of some entity.
●A person may play the role of several different actors and, conversely, a given
actor may be played by multiple different person.
ActorActor

59. Lifeline Notation Lifeline Notation
●A sequence diagram is made up of several of these lifeline notations
●Lifelines identify the existence of an object over time
●They should be arranged horizontally across the top of the diagram
●So basically each instance in a sequence diagram is represented by a lifeline.
Lifeline elements are located at the top in a sequence diagram.
●No two lifeline notations should overlap each other (All lifelines should be distinct)
●They represent the different objects that interact with each other in the system
Object 1Object 1Object 2Object 2Object 3Object 3Object 4Object 4

60. ●The standard in UML for naming a lifeline follows the following format –
Instance Name : Class NameInstance Name : Class Name
●A lifeline notation with an actor element symbol
is used when the particular sequence diagram
is owned by a use case
●A lifeline with a boundary element indicates a
system boundary/ software element in a system;
for example, user interface screens, database
gateways or menus that users interact with, are boundaries.
ActorActor
BoundaryBoundary

61. Activation BarsActivation Bars
●Activation bar is the box placed on the lifeline. It is used to indicate that an
object is active (or instantiated) during an interaction between two objects.
The length of the rectangle indicates the duration of the objects staying active.
●In a sequence diagram, an interaction between two objects occurs when one
object sends a message to another. The use of the activation bar on the
lifelines of the Message Caller (the object that sends the message) and the
Message Receiver (the object that receives the message) indicates that both
are active/is instantiated during the exchange of the message.

62. Modeling using State Transition DiagramModeling using State Transition Diagram

63. An Example of Activation BarsAn Example of Activation Bars

64. MessagesMessages
Object 2Object 2 Object 3Object 3

65. MessagesMessages
●Communication between objects is depicted using messages. The messages
appear in a sequential order on the lifeline. We represent messages using
arrows. Lifelines and messages form the core of a sequence diagram.
●A message defines a particular communication between Lifelines of an
Interaction.
●An arrow from the Message Caller to the Message Receiver specifies a
message in a sequence diagram. A message can flow in any direction; from
left to right, right to left or back to the Message Caller itself. While you can
describe the message being sent from one object to the other on the arrow,
with different arrowheads you can indicate the type of message being sent or
received
●Messages can be broadly classified into the following categories:

66. (1) (1) Synchronous MessageSynchronous Message
●As shown in the activation bars example, a synchronous message is used
when the sender sends a message, waits for the receiver to process the
message and return before carrying on with another message. The
arrowhead used to indicate this type of message is a solid one, like the one
below.

67. (2) (2) Asynchronous MessageAsynchronous Message
●An asynchronous message is used when the message caller send a
message, does not wait for the receiver to process the message and return
before sending other messages to other objects within the system. The
arrowhead used to show this type of message is a line arrow like shown in the
example below

68. (3) (3) Return Message/Reply MessageReturn Message/Reply Message
●A return message is used to indicate that the message receiver is done processing
the message and is returning control over to the message caller. Return messages
are optional notation pieces, for an activation bar that is triggered by a synchronous
message always implies a return message.
●Tip: You can avoid cluttering up
your diagrams by minimizing the
use of return messages since the
return value can be specified in the
initial message arrow itself.

69. (3) (3) PParticipant Creation articipant Creation MessageMessage
●Objects do not necessarily live for the entire duration of the sequence of
events. Objects or participants can be created according to the message that
is being sent.
●The dropped participant box notation can be used when you need to show
that the particular participant did not exist until the create call was sent. If the
created participant does something immediately after its creation, you should
add an activation box right below the participant box.

70. An Example of participant creation messageAn Example of participant creation message

71. (4) (4) PParticipant Destruction articipant Destruction MessageMessage
●Likewise, participants when no longer needed can also be deleted from a
sequence diagram. This is done by adding an ‘X’ at the end of the lifeline of
the said participant.
●Destroy message/ Delete Message is a kind of message that represents the
request of destroying the life cycle of target lifeline
●It destroys the occurrence of the object in the system. It is represented by an
arrow terminating with an xx

72. An Example of participant destruction messageAn Example of participant destruction message

73. (5) Reflexive message(5) Reflexive message
●Certain scenarios might arise where the object needs to send a message to
itself.
●When an object sends a message to itself, it is called a reflexive message
(Self Message). It is indicated with a message arrow that starts and ends at
the same lifeline as shown in the example below.
● Such messages are called Self Messages and are represented with an
inverted U U shaped arrow

74. An Example of a Reflective Message An Example of a Reflective Message
●For example – Consider a scenario where the device wants to access its
webcam. Such a scenario is represented using a self message.

75. (6) Duration message(6) Duration message
●Duration message shows the distance between two time
instants for a message invocation.

76. An Example of Duration and other MessagesAn Example of Duration and other Messages

77. Sequence Diagram Best PracticesSequence Diagram Best Practices
(A) Manage complex interactions with sequence fragments(A) Manage complex interactions with sequence fragments
●A sequence fragment is represented as a box that frames a section of
interactions between objects (as shown in the examples below) in a sequence
diagram.
●It is used to show complex interactions such as alternative flows and loops in
a more structured way. On the top left corner of the fragment sits an operator.
This – the fragment operator – specifies what sort of a fragment it is:
●Alternatives (Alt)
●Option (Opt)
●Loop
Let us take a look at guard conditions

78. Guards (Guard Conditions)Guards (Guard Conditions)
●To model conditions we use guards in UML. They are used when we need to
restrict the flow of messages on the pretext of a condition being met. Guards
play an important role in letting software developers know the constraints
attached to a system or a particular process.
●For example: In order to be able to withdraw cash, having a balance greater
than zero is a condition that must be met as shown below.

79. An Example of Guard Condition An Example of Guard Condition

80. (1) Alternatives (1) Alternatives Combination FragmentCombination Fragment
●The alternative combination fragment is used when a choice needs to be
made between two or more message sequences. It models the “if then else” “if then else”
statement.statement.
●The alternative fragment is represented by a large rectangle or a frame; it is
specified by mentioning ‘alt’ inside the frame’s name box (a.k.a. fragment
operator).
●To show two or more alternatives, the larger rectangle is then divided into
what is called Interaction OperandsInteraction Operands using a dashed line (to represent
multiple conditions), as shown in the sequence diagram example above. Each
operand has a guard to test against and it is placed at the top left corner of
the operand

81. An Example of AlternativesAn Example of Alternatives

82. (2) Option Combination Fragment(2) Option Combination Fragment
●The option combination fragment is used to indicate a sequence that will only
occur under a certain condition, otherwise, the sequence won’t occur. It
models the “if then” statement. “if then” statement.
●Similar to the alternative fragment, the option fragment is also represented
with a rectangular frame where ‘opt’ is placed inside the name box.
●Unlike the alternative fragment, an option fragment is not divided into two or
more operands. Option’s guard is placed at the top left corner.

83. Reference Fragment Reference Fragment
●You can use the ref fragment to manage the size of large sequence diagrams.
It allows you to reuse part of one sequence diagram in another, or in other
words, you can reference part of a diagram in another diagram using the ref
fragment.
●To specify the reference fragment, you have to mention ‘ref’ in the name box
of the frame and the name of the sequence diagram that is being referred to
inside the frame.

84. (b) Draw smaller sequence diagrams that capture the essence of the use (b) Draw smaller sequence diagrams that capture the essence of the use
casecase
●Instead of cluttering your sequence diagram with several objects and groups
of messages that will confuse the reader, draw a few smaller sequence
diagrams that aptly explain what your system does. Make sure that the
diagram fits on a single page and leaves space for explanatory notes too.
●
●Also instead of drawing dozens of sequence diagrams, find out what is
common among the scenarios and focus on that. And if the code is expressive
and can stand on its own, there’s no need to draw a sequence diagram in the
first place.

86. Process Modeling Using Data Flow Diagram Process Modeling Using Data Flow Diagram
(DFD) (DFD)
●A graphical tool, useful for communicating with users,
managers, and other personnel.
●Used to perform structured analysis to determine logical
requirements.
●Useful for analyzing existing as well as proposed systems.
●Focus on the movement of data between external entities
and processes, and between processes and data store

87. Why DFD?
DFD Provides an overview of:
● What data a system processes
●What transformations are performed
●What data are stored
●What results are produced and where they flow
●Graphical nature makes it a good communication tool between- User and System Analyst, System Analyst and
System designer,
System Designer and Developer.
●An Example:

89. DFD Elements
●Source/Sinks (External entity)
●Processes
●Data Stores
●Data flows

90. DFD Naming Guidelines
●
External Entity  Noun
●
Data Flow  Names of data
●
Process  verb phrase
–a system name
–a subsystem name
●
Data Store  Noun

91. Descriptions Of DFD Elements
● External Entity (Source/Sink) - people or organisations that send data into the system or receive data from the system.
They either supply or receive data
- Source: Any Entity that supplies data to the system.
- Sink: – Any Entity that receives data from the system.
They do not process data

●Process – Activities in system - models what happens to the data i.e. transforms incoming data into outgoing data.
- Process model work or actions performed on data (inside the system)
- Straight line with incoming arrows are input data flows
- Straight lines with outgoing arrows are output data flows
- Labels are assigned to Data flow
- Processes can have more than one outgoing data flow or more than one incoming data flow
- Processes can connect to any other symbol (including another process symbol)
●Data Store - A Data Store is a repository of data.
- Data can be written into the data store. This is depicted by an incoming arrow
- Data can be read from a data store. This is depicted by an outgoing arrow Data
●Data Flow - Data in motion: models the actual flow of the data between the other elements.
- Marks movement of data through the system
- Connects the processes, external entities and data stores
- Data Flows are generally unidirectional, but If same data flows in both directions, double-headed arrow can be used

92. Decomposition Of DFD (Leveling DFDs)
●Recall the essence of modeling: - To reduce system complexity
●Any “real” system is too large to be represented as a single DFD.
●The solution is to decompose the system into a hierarchy of levels of processing.
●The process model of the system then consist of a set of leveled DFDs.
●Importance: The leveling of DFDs improves readability and communication between development team and
stakeholders.
●DFD can be decomposed into Levels:
●Context Diagram: Context diagram Contains only one process – the highest level of DFD
●Level 0 DFD: System overview showing Self Entities (Main Processes) Does not utilize all four elements
●Level 1 DFD: The breakdown of Main Processes (level 0) into sub processes - Utilizes all four elements
●Level 2 DFD: Detailed diagram - A breakdown of a level 1 process - Utilizes all four elements
●There is no rule as to how many levels of DFD that can be drawn for any specific software
●You continue until the system cannot be broken down further. This is called Primitive DFD.

93. Creating Data Flow Diagrams
Steps:
1.Create a list of activities
2.Construct Context Diagram Level 0 DFD
(identifies external entities and processes)
3.Construct Level 1 DFD
(identifies manageable sub process )
4.Construct Level 2- n DFD
(identifies actual data flows and data stores )
5.Check against rules of DFD

94. Good Style in Drawing DFD
● Use meaningful names for data flows, processes and
data stores.
●Use top down development starting from context
diagram and successively leveling DFD
●Only previously stored data can be read
● A process can only transfer input to output. It cannot
create new data
●Data stores cannot create new data

97. Context Diagrams
●
The highest of DFD is the context diagram.
●
The context diagram shows the interaction of the system with External Entities in terms
of data flow.
●
The context diagram defines the boundary of the system
●
Understanding the relationships between the software that is being designed and
its external environment is essential for deciding how to provide the required
system functionality and how to structure the system to communicate with its
environment.
●
Understanding of the context also lets you establish the boundaries of the system.
Setting the system boundaries helps you decide what features are implemented in
the system being designed and what features are in other associated systems.
●
Only the data flows which leaves the system and the data flows which come from the
system are shown. No processes are shown.

98. Creating Data Flow Diagrams
Lemonade Stand Example

99. Creating Data Flow Diagrams
Steps:
1.Create a list of activities
•Old way: no Use-Case Diagram
•New way: use Use-Case Diagram
2.Construct Context Level DFD
(identifies sources and sink)
3.Construct Level 0 DFD
(identifies manageable sub processes )
4.Construct Level 1- n DFD
(identifies actual data flows and data stores )
Example
The operations of a simple lemonade
stand will be used to demonstrate the
creation of dataflow diagrams.

100. Creating Data Flow Diagrams
1.Create a list of activitiesExample
Think through the activities that take
place at a lemonade stand.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product

101. Creating Data Flow Diagrams
Example
Also think of the additional activities
needed to support the basic activities.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
1.Create a list of activities

102. Creating Data Flow Diagrams
Example
Group these activities in some logical
fashion, possibly functional areas.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
1.Create a list of activities

106. Creating Data Flow Diagrams
Level 1 DFD
Example
Create a level 1 decomposing the
processes in level 0 and identifying
data stores.
4.Construct Level 1- DFD
(identifies actual data flows and data stores )
1.3
Produce Sales
Forecast
Sales ForecastPayment
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
1.1
Record Order
Customer Order
ORDER
1.2
Receive
Payment
PAYMENT
Severed Order
Request for Forecast
CUSTOMER

107. Creating Data Flow Diagrams
Level 1 DFD
Example
Create a level 1 decomposing the
processes in level 0 and identifying
data stores.
4.Construct Level 1 (continued)
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
2.1
Serve
Product
Product Order
ORDER
2.2
Produce
Product
INVENTORY
Quantity Severed
Production
Schedule
RAW MATERIALS
2.3
Store
Product
Quantity Produced & Location
Stored
Quantity Used
Production Data

108. Creating Data Flow Diagrams
Level 1 DFD
Example
Create a level 1 decomposing the
processes in level 0 and identifying
data stores.
4.Construct Level 1 (continued)
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
3.1
Produce
Purchase
Order
Order Decision
PURCHASE ORDER
3.2
Receive
Items
Received Goods
RAW MATERIALS
3.3
Pay Vendor
Quantity
Received
Quantity On-Hand
RECEIVED ITEMS
VENDOR
Payment Approval
Payment

109. Creating Data Flow Diagrams
Level 1 DFD
Example
Create a level 1 decomposing the
processes in level 0 and identifying
data stores.
4.Construct Level 1 (continued)
Time Worked
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
4.1
Record Time
Worked
TIME CARDS
4.2
Calculate
Payroll
Payroll Request
EMPLOYEE
4.3
Pay
Employee
Employee ID
PAYROLL
PAYMENTS
Payment Approval
Payment
Unpaid time cards

110. Process Decomposition
4.1
Record Time
Worked
4.2
Calculate
Payroll
4.3
Pay
Employee
3.1
Produce
Purchase
Order
3.2
Receive
Items
3.3
Pay Vendor
2.1
Serve
Product
2.2
Produce
Product
2.3
Store
Product
1.1
Record Order
1.2
Receive
Payment
2.0
Production
1.0
Sale
3.0
Procurement
4.0
Payroll
0.0
Lemonade
System
Level 0 Level 1Context Level

111. DFD Example: Bus Garage Repairs
●
Buses come to a garage for repairs.
●
A mechanic and helper perform the repair, record the reason for
the repair and record the total cost of all parts used on a Shop
Repair Order.
●
Information on labor, parts and repair outcome is used for billing
by the Accounting Department, parts monitoring by the inventory
management computer system and a performance review by the
supervisor.

112. DFD Example: Bus Garage Repairs (cont’d)
●
External Entities: Bus, Mechanic, Helper, Supervisor, Inventory
Management System, Accounting Department, etc.
●
Key process (“the system”): performing repairs and storing
information related to repairs
●
Processes:
–Record Bus ID and reason for repair
–Determine parts needed
–Perform repair
–Calculate parts extended and total cost
–Record labor hours, cost

113. DFD Example: Bus Garage Repairs (cont’d)
●
Data stores:
–Personnel file
–Repairs file
–Bus master list
–Parts list
●
Data flows:
–Repair order
–Bus record
–Parts record
–Employee timecard
–Invoices

114. Bus
Mechanic
Helper
Bus Repair
Process
System
Supervisor
Accounting
Bus Garage Context Diagram
Mechanical problem
to be repaired
Labor
Labor
Fixed mechanical
problems
Inventory Management
System
Repair
summary
List of parts
used
Labor, parts
cost details

115. Exercise/TD: Student Result Management System
●You have been hired by University of Yaounde I to
design and implement a software for managing student
results. As a System Analyst, you have to carry out
domain analysis in order to identify user requirements.
Draw the context diagram and Level 0 DFD for the
system

116. Exercise/TD: Student Result Management System
●
Draw the context diagram
–System
●
Result Management system
–External entities
●
Departments
●
Examination Officer
●
Students
●
Lecturers
–Processes (Use Cases)
●
Course Registration
●
Results Compilation
●
Management report
●
Transcript Management
●
Certification Management

117. What is the difference between a System Context
Model and a System Interaction Model?

118. ●A system context model is a structural model that
demonstrates the other systems in the environment of
the system being developed.
●An interaction model is a dynamic model that shows
how the system interacts with its environment as it is
used.