Chapter 2
Basic Principles
Winter 2007, rev. 2008
SEG2101 - Chapter 2
1
Basic Principles
•
•
•
•
•
•
•
Introduction to the system example
Systems
Techniques to manage complexity
Approaches to behavior description
Some description approaches
The methodology presented here
The SOON notation
Winter 2007, rev. 2008
SEG2101 - Chapter 2
2
2.1: Introduction to the System Example
• Access Control System (AC-System)
• Access point: controlled by local station, physically distributed to where
the services are needed
• Local station: control unit, a door lock mechanism, one or two panels,
each contains a card reader, a display unit, and a keypad
• Central station: keeps information about the users, their access rights,
their cards, and their secret PINs, performs authentication and authorization.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
3
Panel and Card
Winter 2007, rev. 2008
SEG2101 - Chapter 2
4
System Structure
Winter 2007, rev. 2008
SEG2101 - Chapter 2
5
2.2: Systems
•
•
•
•
What is a system?
Behavior
Structure
Real time systems
Winter 2007, rev. 2008
SEG2101 - Chapter 2
6
What is a System?
• A system is part of real world that a person or
group of persons during some time interval and for
some purpose choose to regard as a whole,
consisting of interrelated components, each
component characterized by properties that are
selected as being relevant to the purpose.
• A system is a purposeful collection of interrelated
components that work together to achieve some
objective.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
7
What is a System (2)
• A system is part of the real world.
• What constitutes a system is a matter of
definition.
• Each component of a system may also be
regarded as a system.
• A system is not just any unordered
collection of components.
• A system has purpose.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
8
System Hierarchy
Town
Street
Building
Winter 2007, rev. 2008
Heating
system
Power
system
Water
system
Security
system
Lighting
system
Waste
system
SEG2101 - Chapter 2
9
A Simple Intruder Alarm System
Door
sensors
Movement
sensors
Alarm
contr oller
Siren
Winter 2007, rev. 2008
Voice
synthesizer
SEG2101 - Chapter 2
Telephone
caller
External
control centre
10
System Description
• Two purposes
– To describe the functional behavior so that it
can be fully understood
– To describe the realization so that the system
may be produced
• System vs system description
Winter 2007, rev. 2008
SEG2101 - Chapter 2
11
System and System Description
Winter 2007, rev. 2008
SEG2101 - Chapter 2
12
Behavior
• The behavior of a system is the development of
states and state transitions generated by actions of
the system during the time interval in which it is
studied.
• Behavior is a dynamic development over time.
• Actually occurring in real world.
• Approximation: behavior consists of actions that
change state (value) of variables.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
13
A Segment of Behavior
Winter 2007, rev. 2008
SEG2101 - Chapter 2
14
Structure
• The structure of a system is the aspects of
the system which stay invariant during the
time interval in which it is studied.
• Structure is the way things hold together for
some time.
•
pp 30-31
Winter 2007, rev. 2008
SEG2101 - Chapter 2
15
Real Time Systems
• A system is a real time system if it has a
role with time constraints.
• A real-time system is a system that is
required to react to stimuli from the
environment within time intervals dictated
by the environment.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
16
A Simple Fluid Control System
(real-time)
Interface
Pipe
Input flow
reading
Flow meter
Processing
Valve
Output valve
angle
Time
Computer
Winter 2007, rev. 2008
SEG2101 - Chapter 2
17
A Grain-Roasting Plant
(real-time)
Bin
Furnace
Fuel Tank
grain
Pipe
fuel
Winter 2007, rev. 2008
SEG2101 - Chapter 2
18
A Process Control System
(real-time)
Process
Control
Computer
Valve
Chemicals
and
Materials
Temperature
Transducer
Stirrer
Finished
Products
PLANT
Winter 2007, rev. 2008
SEG2101 - Chapter 2
19
2.3: Techniques to Manage Complexity
•
•
•
•
Abstraction
Projection
Aggregation and partition
Generalization and specialization
Winter 2007, rev. 2008
SEG2101 - Chapter 2
20
Abstraction
• To ignore some aspects of a phenomenon in
order to describe (and understand) others
more clearly.
• Opposite of concrete or physical
• The abstractions should be clear and
precise, lead to efficient implementation,
and support the continuing development and
reuse.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
21
Projection
• In projections we look at the system from
different angles.
• A projection is a description of a system as
it is observed at subset of its interfaces.
• Only the observable interfaces are visible,
while the others are hidden.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
22
Aggregation and Partitioning (I)
• All non-trivial systems are composed from
components.
• The process of lumping components
together to form a whole is called
aggregation.
• The opposite process of decomposing a
whole into parts is called partitioning.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
23
Aggregation and Partitioning (II)
Winter 2007, rev. 2008
SEG2101 - Chapter 2
24
Generalization and Specialization
• In the real world there are huge amounts of similar
subjects.
• Rather than describing and understanding all
individuals in full detail, we may describe and
understand them in terms of similarity.
• Type are conceptual entities that we use to
structure our descriptions and thoughts.
• Individual or subtype is an instance of a type.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
25
A Generalization Hierarchy
Employee
Ma nager
Programmer
budgetsControlled
dateAppointed
project
progLanguage
Project
Ma nag er
projects
Winter 2007, rev. 2008
De pt.
Ma nager
dept
SEG2101 - Chapter 2
Strategic
Ma nag er
responsibilities
26
Type and Subtype
Winter 2007, rev. 2008
SEG2101 - Chapter 2
27
Inheritance and Specialization
Winter 2007, rev. 2008
SEG2101 - Chapter 2
28
2.4: Behavior Description: the Problem
• The quality of a real-time system is determined to
a very large extent by its behavior.
• Behavior is the most difficult system aspect to
describe, due to its dynamic and transient nature.
• How can we represent a dynamic and possibly
infinite behavior in a static and finite way?
Winter 2007, rev. 2008
SEG2101 - Chapter 2
29
Behavior Description: Example
Winter 2007, rev. 2008
SEG2101 - Chapter 2
30
Behavior Description: Focus
• State-oriented
– focus on states and action instances
– each state is represented by a node
– each action instance is represented by a branch
• Action-oriented
– focus on action types and variables
– states need not be described at all
– the states may be found by analyzing the
actions
Winter 2007, rev. 2008
SEG2101 - Chapter 2
31
2.5: Some Description Approaches
•
•
•
•
•
Abstract description
Entity relationship description
SOON notation
Data flow diagrams
Finite state machine
Winter 2007, rev. 2008
SEG2101 - Chapter 2
32
Abstract Description
• Many different approaches to abstract
system description
• Conflict between the need to formalize and
the need to understand
• The abstract description methods that have
had the strongest penetration so for have
been those that emphasize the needs of
human audience.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
33
Entity Relationship Description
Winter 2007, rev. 2008
SEG2101 - Chapter 2
34
Entity Relationship Diagram Legend
Winter 2007, rev. 2008
SEG2101 - Chapter 2
35
Another Entity Relationship Diagram
Winter 2007, rev. 2008
SEG2101 - Chapter 2
36
SOON Notation (used in book by Braek)
Winter 2007, rev. 2008
SEG2101 - Chapter 2
37
Type Definition
The SOON notation has a clear separation between types and
instances it allows us to represent individuals and types explicitly
and not implicitly as in ER diagrams.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
38
UML Class Diagram
Winter 2007, rev. 2008
SEG2101 - Chapter 2
39
Data Flow Diagrams
Winter 2007, rev. 2008
SEG2101 - Chapter 2
40
UML Activity Diagram (related to
Dataflow Diagrams)
Winter 2007, rev. 2008
SEG2101 - Chapter 2
41
Use Case Maps
A notation (with roots in Ottawa) which is semantically similar to Activity Diagrams.
Here is the same example:
Warehouse
Ship
Order
Office
[ Order
rejected ]
Receive
Order
[ Order
accepted ]
Close
Order
Fill
Order
Send
Invoice
Acccept
Payment
Client
Make
Payment
Winter 2007, rev. 2008
SEG2101 - Chapter 2
42
Concepts describing requirements
• Each Use Case is a scenario
– Actions done by actors in some given order
• Action: Activity / Responsibility
• Actor: Swimlane / Component
• Order: sequence, alternatives, concurrency, arbitrary control flows
(similar to Petri nets)
• Abstraction: refinement of activity / Plug-in
• Data-Flow: Object flow / not in UCMs. Question: what type of
data is exchanged (an extension of control flow)
– Input assertions for input data flow
– Output assertions for output data flow
– Conditions for alternatives (also in UCMs)
Winter 2007, rev. 2008
SEG2101 - Chapter 2
43
Finite State Machine
Winter 2007, rev. 2008
SEG2101 - Chapter 2
44
FSM
•
•
•
•
A finite set of inputs, I:
A finite set of outputs, O;
A finite set of state, S;
A next state function, FS:
SIS ;
• An output function, FO:
SIO* ;
• A designated initial state,
Initial.
Winter 2007, rev. 2008
SEG2101 - Chapter 2
45
2.6: The Methodology Presented Here
Winter 2007, rev. 2008
SEG2101 - Chapter 2
46
Summaries of Notations
Winter 2007, rev. 2008
SEG2101 - Chapter 2
47
2.7: The SOON Notation
• SISU Object-Oriented Notation
• Used to describe structures where SDL is
not appropriate
• Less formal and does not enforce SDL
semantics
Winter 2007, rev. 2008
SEG2101 - Chapter 2
48
SOON Symbols
Winter 2007, rev. 2008
SEG2101 - Chapter 2
49
SOON Syntax
Winter 2007, rev. 2008
SEG2101 - Chapter 2
50