Winter 2007, rev. 2008 SEG2101 - Chapter 2 1

Chapter 2

Basic Principles

Winter 2007, rev. 2008 SEG2101 - Chapter 2 2

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 3

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 4

Panel and Card

Winter 2007, rev. 2008 SEG2101 - Chapter 2 5

System Structure

Winter 2007, rev. 2008 SEG2101 - Chapter 2 6

2.2: Systems

• What is a system?

• Behavior

• Structure

• Real time systems

Winter 2007, rev. 2008 SEG2101 - Chapter 2 7

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 8

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 9

System Hierarchy

Securitysystem

Heatingsystem

Lightingsystem

Powersystem

Wastesystem

Watersystem

Town

Street

Building

Winter 2007, rev. 2008 SEG2101 - Chapter 2 10

A Simple Intruder Alarm System

Alarmcontroller

Voicesynthesizer

Movementsensors

Siren

Doorsensors

Telephonecaller

Externalcontrol centre

Winter 2007, rev. 2008 SEG2101 - Chapter 2 11

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 12

System and System Description

Winter 2007, rev. 2008 SEG2101 - Chapter 2 13

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 14

A Segment of Behavior

Winter 2007, rev. 2008 SEG2101 - Chapter 2 15

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 16

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 17

A Simple Fluid Control System (real-time)

Pipe

Flow meter

Valve

Interface

ComputerTime

Input flowreading

Processing

Output valveangle

Winter 2007, rev. 2008 SEG2101 - Chapter 2 18

A Grain-Roasting Plant(real-time)

Fuel Tank

Furnace

Bin

Pipe

fuel

grain

Winter 2007, rev. 2008 SEG2101 - Chapter 2 19

A Process Control System(real-time)

ProcessControl

Computer

ChemicalsandMaterials

ValveTemperatureTransducer

StirrerFinishedProducts

PLANT

Winter 2007, rev. 2008 SEG2101 - Chapter 2 20

2.3: Techniques to Manage Complexity

• Abstraction

• Projection

• Aggregation and partition

• Generalization and specialization

Winter 2007, rev. 2008 SEG2101 - Chapter 2 21

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 22

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 23

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 24

Aggregation and Partitioning (II)

Winter 2007, rev. 2008 SEG2101 - Chapter 2 25

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 26

A Generalization HierarchyEmployee

Programmer

projectprogLanguage

Manager

ProjectManager

budgetsControlled

dateAppointed

projects

Dept.Manager

StrategicManager

dept responsibilities

Winter 2007, rev. 2008 SEG2101 - Chapter 2 27

Type and Subtype

Winter 2007, rev. 2008 SEG2101 - Chapter 2 28

Inheritance and Specialization

Winter 2007, rev. 2008 SEG2101 - Chapter 2 29

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 30

Behavior Description: Example

Winter 2007, rev. 2008 SEG2101 - Chapter 2 31

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 32

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 33

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 34

Entity Relationship Description

Winter 2007, rev. 2008 SEG2101 - Chapter 2 35

Entity Relationship Diagram Legend

                                                                                                                                                                                                                      

Winter 2007, rev. 2008 SEG2101 - Chapter 2 36

Another Entity Relationship Diagram

                                                                                                                                                                                                                                                   

Winter 2007, rev. 2008 SEG2101 - Chapter 2 37

SOON Notation (used in book by Braek)

Winter 2007, rev. 2008 SEG2101 - Chapter 2 38

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.

Type Definition

Winter 2007, rev. 2008 SEG2101 - Chapter 2 39

UML Class Diagram

Winter 2007, rev. 2008 SEG2101 - Chapter 2 40

Data Flow Diagrams

Winter 2007, rev. 2008 SEG2101 - Chapter 2 41

UML Activity Diagram (related to Dataflow Diagrams)

Winter 2007, rev. 2008 SEG2101 - Chapter 2 42

Use Case Maps A notation (with roots in Ottawa) which is semantically similar to Activity Diagrams.

Here is the same example:

Receive Order Fill

Order SendInvoice

Ship Order

Make Payment

AccceptPayment

CloseOrder

Warehouse

Office

Client

[ Order rejected ]

[ Order accepted ]

Winter 2007, rev. 2008 SEG2101 - Chapter 2 43

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 44

Finite State Machine

Winter 2007, rev. 2008 SEG2101 - Chapter 2 45

FSM

• A finite set of inputs, I:

• A finite set of outputs, O;

• A finite set of state, S;

• A next state function, FS: SIS ;

• An output function, FO: SIO* ;

• A designated initial state, Initial.

Winter 2007, rev. 2008 SEG2101 - Chapter 2 46

2.6: The Methodology Presented Here

Winter 2007, rev. 2008 SEG2101 - Chapter 2 47

Summaries of Notations

Winter 2007, rev. 2008 SEG2101 - Chapter 2 48

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 49

SOON Symbols

Winter 2007, rev. 2008 SEG2101 - Chapter 2 50

SOON Syntax