System

Modelling &
Design
Software Engineering

1 Presented By Dr. Huda Amin

Information Systems
[email protected]
Software Engineering - H.A.
 Event-Driven Model
2

 Event-driven modelling shows how a system responds to external and

internal events. It is based on the assumption that a system has a
finite number of states and that events (stimuli) may cause a
transition from one state to another.

 This view of a system is particularly appropriate for real-time systems.

 The UML supports event-based modelling using state diagrams.

Software Engineering - H.A.

 Event-Driven Model
3

 Event-driven modelling shows how a system responds to external and

internal events. It is based on the assumption that a system has a
finite number of states and that events (stimuli) may cause a
transition from one state to another.

 This view of a system is particularly appropriate for real-time systems.

 The UML supports event-based modelling using state diagrams.

Software Engineering - H.A.

4

 State diagrams show system states and events that cause transitions
from one state to another. They do not show the flow of data within
the system but may include additional information on the
computations carried out in each state.

Software Engineering - H.A.

5

 In UML state diagrams, rounded rectangles represent system states.

They may include a brief description (following ‘do’) of the actions
taken in that state.

 The labeled arrows represent stimuli that force a transition from one
state to another.

 The diagram uses start and end states using filled circles, as in activity
diagrams.
Software Engineering - H.A.
6

Software Engineering - H.A.

7

Software Engineering - H.A.

8

Software Engineering - H.A.

9

Software Engineering - H.A.

 State Chart Diagram
10

 These diagrams are a good way to model the dynamic behavior of a class

 State chart diagrams aren't created for every class. Only if an object of the
class can exist in several states, and behaves very differently in each of the states

 State chart diagrams are created for documentation only, no source code is
generated from it
Software Engineering - H.A.
 State Chart Diagram
11

 It includes information about

 The various states in which an object can exist
 How the object transitions from one state to another
 How the object behaves differently in each of the states

 For example, a bank account can exist in several different states. It can be open, closed, or
overdrawn

 A State chart diagram shows the life cycle of a single object, from the time that it is
created until it is destroyed
Software Engineering - H.A.
 Elements of State Chart Diagram
12

Element Notation Representation

Start State It indicates what state the object is in
when it is first created. there is one
and only one start state (Mandatory)

End State It shows what state the object is in just

before it is destroyed. you can have no
stop state, or there can be as many
stop states as you need

State It one of the possible states in which an

NewState
object may exist

Transition It is a movement from one state to

another (can be reflexive)

Software Engineering - H.A.

13

Software Engineering - H.A.

 Transitions
14

 Event: An event is something that causes a transition from one state to another to occur

 The transition arrow is labeled with the event name, along with any arguments in parenthesis

 An automatic transition, which has no event, an object automatically moves from one state to another
as soon as all the entry actions, activities, and exit actions have occurred

Software Engineering - H.A.

 Transitions
15

 Guard condition: controls when a transition can or cannot occur

 If a guard condition is present, it must be true in order for the transition to occur

 The guard condition is listed along the transition arrow, following any event, and is
enclosed in square brackets

Software Engineering - H.A.

16 Data-Driven Model

Software Engineering - H.A.

17

 Data-driven models show the sequence of actions involved in processing input data and
generating an associated output.

 Data-flow diagrams (DFDs) are system models that show a functional perspective where
each transformation represents a single function or process.
 DFDs are used to show how data flows through a sequence of processing steps. For
example, a processing step could be the filtering of duplicate records in a customer
database. The data is transformed at each step before moving on to the next stage. These
processing steps or transformations represent software processes or functions where data-
flow diagrams are used to document a software design.
Software Engineering - H.A.
Data Models
 Data flow diagrams (DFDs) may be used to model the system’s data
processing
 These show the processing steps as data flows through a system.
 DFDs are an intrinsic part of many analysis methods
 Simple and intuitive notation that customers can understand.
 Show end-to-end processing of data
Data Flow Diagrams

 DFDs model the system from a functional perspective.

 Tracking and documenting how the data associated with a process is

helpful to develop an overall understanding of the system.

 Data flow diagrams may also be used in showing the data exchange
between a system and other systems in its environment.
 Data Flow Notations
20

Element Notation Representation

Process Work or actions performed on data (inside
the system)
Labels should be verb phrases
Receives input data and produces output

Data Flow Arrows depicting movement of Data

Labels should be noun phrases
Data Store It is used in a DFD to represent data that the
system stores (inside the system)
Labels should be noun phrases
Must have at least one incoming and one
outgoing data flow
Source/Sink External entity that is origin
(External or destination of data (outside the system)
Entity) Labels should be noun phrases
Software Engineering - H.A.
 DFD Diagramming Rules
21

 Data flow from a process to a data store means update (insert, delete
or change)

 Data flow from a data store to a process means retrieve or use

Software Engineering - H.A.

 DFD Diagramming Rules
22

No process can have only

outputs or only
inputs…processes must
have both outputs and
inputs

Software Engineering - H.A.

 DFD Diagramming Rules
23

All flows to or from a data store must

move through a process.

Software Engineering - H.A.

 DFD Diagramming Rules
24

No data moves directly between external entities

without going through a process.

Interactions between external entities without intervening

processes are outside the system and therefore not
represented in the DFD.

Software Engineering - H.A.

 DFD Diagramming Rules
25

Bidirectional flow
between process and
data store is
represented by two
separate arrows.

Forked data flow

must refer to exact
same data item (not
different data items)
from a common
location to multiple
destinations.

Software Engineering - H.A.

 DFD Diagramming Rules
26

Joined data flow must

refer to exact same
data item (not
different data items)
from multiple sources
to a common location.

Data flow cannot go

directly from a
process to itself, must
go through
intervening
processes.

Software Engineering - H.A.

 Functional Decomposition
27

 An iterative process of breaking a system description down into finer

and finer detail

 High-level processes described in terms of lower-level sub-processes

 DFD charts created for each level of detail

Software Engineering - H.A.

 DFD Levels
28

 Context DFD
 Overview of the organizational system

 Level 0 DFD
 Representation of system’s major processes at high level of abstraction

 Level 1 DFD
 Results from decomposition of Level 0 diagram

 Level n DFD
 Results from decomposition of Level n-1 diagram
Software Engineering - H.A.
 Context Diagram
29

 Context diagram shows the system boundaries, external entities that interact with the
system, and major information flows between entities and the system

 Only one process

symbol, and

no data stores shown

Software Engineering - H.A.

 Level-0 DFD
30

Software Engineering - H.A.

 Level-1 DFD
31

Software Engineering - H.A.

 Level-n DFD
32

Software Engineering - H.A.

 DFD Balancing
33

 The conservation of inputs and outputs to a data flow process when that
process is decomposed to a lower level
 Balanced means:
 Number of inputs to lower level DFD equals number of inputs to associated
process of higher-level DFD
 Number of outputs to lower level DFD equals number of outputs to associated
process of higher-level DFD

Software Engineering - H.A.

 Unbalanced DFD
34

1 input
1 output

2 inputs
1 output

Software Engineering - H.A.

 Balanced DFD
35

1 input
3 outputs

Software Engineering - H.A.

 Data Flow Splitting
36

A composite data
flow at a higher level
may be split if
different parts go to
different processes in
the lower level DFD.

Software Engineering - H.A.

 Source
37

 Sommerville, I., “Software Engineering”, 9th Edition, Adison-Wesley.

 Modern Systems Analysis and Design, Fourth Edition

Software Engineering - H.A.

38 Thanks for Listening
Any Questions!

Software Engineering - H.A.