1

1
Universitt Stuttgart
Institute of Industrial Automation and Software Engineering
Prof. Dr.-Ing. Dr. h. c. P. Ghner
2004 IAS, Universitt Stuttgart
Exercises Software Engineering
for Real-Time Systems
Exercise 4: Basic Techniques
Introduction
Basic Techniques Summary
2
2004 IAS, University of Stuttgart
Function Tree
Consists-of hierarchy (definition phase): A consists of B and C
Calling hierarchy (design phase): A calls B and C.
A
B C
Composition Rules:
Functions being pooled by a common parent function should be in a
close context to each other
Functions being at the same hierarchy level should have the same
abstraction level
Car
Body Motor ...
2
3
2004 IAS, University of Stuttgart
ER Diagram (Entity Relationship Diagram)
Aim: Specification of objects (persistent data) and the relationships between
them.
Example: Customer"
Salutation: Herr
Title: Dipl.-Ing.
Name: Schulz
Street: Poststr. 12
City: 44112 Dortmund
Customer
Customer ID
Salutation
Title
. . .
Entity Type: Collection of entities
having identical properties
Attribute: Property of an entity type
or the existing objects of that entity
type respectively
Descriptive attributes
Identifying attributes (keys)
[P. Chen, 1976]
Entity (object): An individual and
identifiable sample of the reality being
described by a set of properties
4
2004 IAS, University of Stuttgart
ER Diagram - Associations (1)
Association (Relationship):
Relation between entity types or the existing objects of these entity types
respectively
Cardinalities (Degree of Complexity):
Number of entities a certain entity has to be or can be involved with
A1
A2
A3
B1
B2
B3
A
is
associated
with
B
1 1
1:1 - Association
Mr Meyer
Mr Mller
Mr Schulz
Ms Meyer
Ms Mller
Ms Schulz
Husband
is
married
with
Wife
1 1
3
5
2004 IAS, University of Stuttgart
ER Diagram - Associations (2)
1:n - Association
A1
A2
B1
B2
..
A
is
associated
with
B
1 M
Schulz
Meyer
Alfred
Jan
Uwe
...
Married-
couple
has Child
1 m
m:n - Association
A
is
associated
with
B
m n
A B
Mller
Meyer
Schulz
...
Java
course
C++
course
Course
is
attended
by
Paticipant
m n
6
2004 IAS, University of Stuttgart
Data Flow Diagram (DFD) (1)
Notation
Function
Memory
Data Flow
Interface
Syntactic Rules
A DFD contains at least one interface
In general each interface exists only once
There are no data flows between interfaces
Each data flow has a name (exception: data flow from
and to memory dont need a name)
There cannot be any direct data flows between
memories
There cannot be any direct data flows between
interfaces and memories
Aim: Specification of the data or information exchange between functions,
memories and interfaces.
Aim: Specification of the data or information exchange between functions,
memories and interfaces.
[De Marco, 1979]
4
7
2004 IAS, University of Stuttgart
Data Flow Diagram (DFD) (2)
Semantic Rules
DFDs describe the data flow, but not the control flow (i.e. no decisions or loops, no
initialization or termination statements)
Interfaces specify the original source or sink of an information
(e.g. Registration data of an event originate from the visitor rather than from the
official in charge to process the registrations)
Important: interfaces are detached from involved I/O media or peripherals (i.e. the
interface is not the keyboard or printer by which the information is passed in or out)
Data flow names are composed of a noun only (e.g. Street Name) or a noun plus an
adjective (e.g. New Street Name)
Function names are composed of a verb specifying some action followed by an
object (e.g. Create Address Label)
8
2004 IAS, University of Stuttgart
Finite State Machines
In many systems the reaction does not depend a single input only but on a
upstream history of inputs the system has passed through. Finite State
Machines can be used to describe such a behavior.
The Finite State Machine consists of a finite number of internal
configurations named states.
States contain the information, which
results from all previous inputs and
is needed in addition to the current input in order to determine the
actual reaction of the system
Initial State
End Sate
Notation Example: Clock
Date
Mode
Time
Mode
Button pressed
Button pressed
Event
Transition
State Name
State
5
9
2004 IAS, University of Stuttgart
Decision Table
Aim: Definition of actions to be performed depending on whether several
conditions are true or false.
Conditions
Actions
Condition indicator
Action indicator
Name Rule
if
then
C1 The sun is shining
C2 There is some snow
A1 Cross-country skiing
A2 Hiking
A3 Having a walk
A4 Staying at home
R1 R2 R3 R4
Y
Y
X
Y
N
X
N
Y
X
N
N
X
Example
Decision Tables can be validated for
Completeness
Consistence
Unambiguousness