system models

36
System Models Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn Lecture 6 & 7

Upload: lida

Post on 11-Feb-2016

45 views

Category:

Documents


0 download

DESCRIPTION

Lecture 6 & 7. System Models. Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn. System models are abstract descriptions of systems whose requirements are being analysed. Objectives To explain why the context of a system should be modelled as part of the RE process To describe - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: System Models

System Models

Hoang Huu Hanh, Hue Universityhanh-at-hueuni.edu.vn

Lecture 6 & 7

Page 2: System Models

System Models2

System models are abstract descriptions of systems whose requirements are being analysed

Objectives To explain why the context of a system should

be modelled as part of the RE process To describe

Behavioural modelling (FSM, Petri-nets), Data modelling and Object modelling (Unified Modeling Language,

UML)

Page 3: System Models

System Models3

System modelling System modelling helps the analyst to

understand the functionality of the system and models are used to communicate with customers

Different models present the system from different perspectives External perspective showing the system’s

context or environment Behavioural perspective showing the behaviour

of the system Structural perspective showing the system or

data architecture

Page 4: System Models

System models weaknesses They do not model non-functional system

requirements They do not usually include information

about whether a method is appropriate for a given problem

They may produce too much documentation

The system models are sometimes too detailed and difficult for users to understand

4 System Models

Page 5: System Models

System Models5

Model types Data processing model showing how the data

is processed at different stages Composition model showing how entities are

composed of other entities Architectural model showing principal sub-

systems Classification model showing how entities

have common characteristics Stimulus/response model showing the

system’s reaction to events

Page 6: System Models

1. Context models Context models are used to illustrate the

boundaries of a system Social and organisational concerns may

affect the decision on where to position system boundaries

Architectural models show the a system and its relationship with other systems

6 System Models

Page 7: System Models

The context of an ATM system

Auto-tellersystem

Securitysystem

Maintenancesystem

Accountdatabase

Usagedatabase

Branchaccounting

system

Branchcountersystem

7 System Models

Page 8: System Models

Process models Process models show the overall process

and the processes that are supported by the system

Data flow models may be used to show the processes and the flow of information from one process to another

8 System Models

Page 9: System Models

Equipment procurement process

System Models9

Get costestimates

Acceptdelivery ofequipment

Checkdelivered

items

Validatespecification

Specifyequipmentrequired

Choosesupplier

Placeequipment

order

Installequipment

Findsuppliers

Supplierdatabase

Acceptdelivered

equipment

Equipmentdatabase

Equipmentspec.

Checkedspec.

Deliverynote

Deliverynote

Ordernotification

Installationinstructions

Installationacceptance

Equipmentdetails

Checked andsigned order form

Orderdetails +

Blank orderform

Spec. +supplier +estima te

Supplier listEquipment

spec.

Page 10: System Models

2 Behavioural models Behavioural models are used to describe the

overall behaviour of a system Two types of behavioural model

Data processing models that show how data is processed as it moves through the system

State machine models that show the systems response to events

Both of these models are required for a description of the system’s behaviour

10 System Models

Page 11: System Models

2.1 Data-processing models Data flow diagrams are used to model the

system’s data processing These show the processing steps as data flows

through a system IMPORTANT part of many analysis methods Simple and intuitive notation that

customers can understand Show end-to-end processing of data

11 System Models

Page 12: System Models

Order processing DFD

Completeorder form

Orderdetails +

blankorder form

Valida teorder

Recordorder

Send tosupplier

Adjustavailablebudget

Budgetfile

Ordersfile

Completedorder form

Signedorder form

Signedorder form

Checked andsigned order

+ ordernotification

Orderamount

+ accountdetails

Signedorder form

Orderdetails

12 System Models

Page 13: System Models

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

13 System Models

Page 14: System Models

2.2 State machine models

State Machine models the behaviour of the system in response to external and internal events

They show the system’s responses to stimuli so are often used for modelling real-time systems

State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another

Statecharts are an integral part of the UML

14 System Models

Page 15: System Models

Microwave oven modelFull power

Enabled

do: operateoven

Fullpower

Halfpower

Halfpower

Fullpower

Number

TimerDooropen

Doorclosed

Doorclosed

Dooropen

Start

do: set power = 600

Half powerdo: set power = 300

Set timedo: get numberexit: set time

Disabled

Operation

Timer

Cancel

Waitingdo: display time

Waitingdo: display time

do: display 'Ready'

do: display 'Waiting'

State machine model does not show flow of data within the system

15 System Models

Page 16: System Models

Microwave oven stimuli

Stimulus DescriptionHalf power The user has pressed the half power buttonFull power The user has pressed the full power buttonTimer The user has pressed one of the timer buttonsNumber The user has pressed a numeric keyDoor open The oven door switch is not closedDoor closed The oven door switch is closedStart The user has pressed the start buttonCancel The user has pressed the cancel button

16 System Models

Page 17: System Models

Finite state machines

Finite State Machines (FSM), also known as Finite State Automata (FSA)

are models of the behaviours of a system or a complex object, with a limited number of defined conditions or modes, where mode transitions change with circumstance.

17 System Models

Page 18: System Models

System Models18

Finite state machines - Definition A model of computation consisting of

a set of states, a start state, an input alphabet, and a transition function that maps input symbols and current

states to a next state Computation begins in the start state with an

input string. It changes to new states depending on the transition function. states define behaviour and may produce actions state transitions are movement from one state to another rules or conditions must be met to allow a state transition input events are either externally or internally generated, which may

possibly trigger rules and lead to state transitions

Page 19: System Models

Variants of FSMs There are many variants, for instance,

machines having actions (outputs) associated with transitions (Mealy machine) or states (Moore machine),

multiple start states, transitions conditioned on no input symbol (a

null) or more than one transition for a given symbol and state (nondeterministic finite state machine),

one or more states designated as accepting states (recognizer), etc.

19 System Models

Page 20: System Models

Finite State Machines with Output (Mealy and Moore Machines) Finite automata are like computers in that

they receive input and process the input by changing states. The only output that we have seen finite automata produce so far is a yes/no at the end of processing.

We will now look at two models of finite automata that produce more output than a yes/no.

20 System Models

Page 21: System Models

Moore machine Basically a Moore machine is just

a FA with two extras. 1. It has TWO alphabets, an input and output

alphabet. 2. It has an output letter associated with each state.

The machine writes the appropriate output letter as it enters each state.

The output produced by the machine contains a 1 for each occurrence of the substring aab found in the input string.

This machine might be considered as a

"counting" machine.

21 System Models

Page 22: System Models

Mealy machine Mealy Machines are exactly as powerful as Moore

machines (we can implement any Mealy machine using a Moore

machine, and vice versa). However, Mealy machines move the output function

from the state to the transition. This turns out to be easier to deal with in practice, making Mealy machines more practical.

22 System Models

Page 23: System Models

A Mealy machine produces output on a transition instead of on entry into a state. Transitions are labelled i/o where

i is a character in the input alphabet and o is a character in the output alphabet.

Mealy machine are complete in the sense that there is a transition for each character in the input alphabet leaving every state.

There are no accept states in a Mealy machine because it is not a language recogniser, it is an output producer. Its output will be the same length as its input.

The following Mealy machine takes the one's complement of its binary input. In other words, it flips each digit from a 0 to a 1 or from a 1 to a 0.

23 System Models

Page 24: System Models

System Models24

Statecharts Allow the decomposition of a model into sub-models

(see a figure) A brief description of the actions is included following

the ‘do’ in each state Can be complemented by tables describing the states

and the stimuliCook

do: run generator

Donedo: buzzer on for 5 secs.

Waiting

Alarmdo: display event

do: checkstatus

Checking

Turntablefault

Emitterfault

Disabled

OK

Timeout

TimeOperation

Dooropen Cancel

Page 25: System Models

Petri Nets Model Petri Nets were developed originally by Carl

Adam Petri, and were the subject of his dissertation in 1962.

Since then, Petri Nets and their concepts have been extended, developed, and applied in a variety of areas.

While the mathematical properties of Petri Nets are interesting and useful, the beginner will find that a good approach is to learn to model systems by constructing them graphically.

25 System Models

Page 26: System Models

The Basics A Petri Net is a collection of

directed arcs connecting places and transitions.

Places may hold tokens. The state or marking of a net is

its assignment of tokens to places.

Place with token

P1

P2

T1

Arc with capacity 1

Transition

Place

26 System Models

Page 27: System Models

Capacity Arcs have capacity 1 by default; if other

than 1, the capacity is marked on the arc. Places have infinite capacity by default. Transitions have no capacity, and cannot

store tokens at all.

Arcs can only connect places to transitions and vice versa.

A few other features and considerations will be added as we need them.

27 System Models

Page 28: System Models

Enabled transitions and firing A transition is enabled when the number of

tokens in each of its input places is at least equal to the arc weight going from the place to the transition.

An enabled transition may fire at any time.

28 System Models

Page 29: System Models

When arcs have different weights… When fired, the tokens in the input places are

moved to output places, according to arc weights and place capacities.

This results in a new marking of the net, a state description of all places.

29 System Models

Page 30: System Models

A collection of primitive structures that occur in real systems

30 System Models

Page 31: System Models

3. Semantic data models Used to describe the logical structure of

data processed by the system Entity-relation-attribute model sets out

the entities in the system, the relationships between these entities and the entity attributes

Widely used in database design. Can readily be implemented using relational databases

No specific notation provided in the UML but objects and associations can be used

31 System Models

Page 32: System Models

Software design semantic model

System Models32

DesignnamedescriptionC-dateM-date

Linknametype

Nodenametype

links

has-links

12

1 n

Labelnametexticon

has-labelshas-labels

1

n

1

n

has-linkshas-nodes is-a

1

n

1

n1

1

Page 33: System Models

Data dictionary entries

Name Description Type Date has-labels

1:N relation between entities of type Node or Link and entities of type Label.

Relation

5.10.1998

Label

Holds structured or unstructured information about nodes or links. Labels are represented by an icon (which can be a transparent box) and associated text.

Entity

8.12.1998

Link

A 1:1 relation between design entities represented as nodes. Links are typed and may be named.

Relation

8.12.1998

name (label)

Each label has a name which identifies the type of label. The name must be unique within the set of label types used in a design.

Attribute

8.12.1998

name (node)

Each node has a name which must be unique within a design. The name may be up to 64 characters long.

Attribute

15.11.1998

Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included

33 System Models

Page 34: System Models

4. Object models Object models describe the system in

terms of object classes An object class is an abstraction over a set of

objects with common attributes and the services (operations) provided by each object

Various object models may be produced Inheritance models Aggregation models Interaction models

34 System Models

Page 35: System Models

System Models35

Object models Natural ways of reflecting the real-world

entities manipulated by the system More abstract entities are more difficult to

model using this approach Object class identification is recognised as a

difficult process requiring a deep understanding of the application domain

Object classes reflecting domain entities are reusable across systems

Page 36: System Models

System Models36

The Unified Modeling Language Devised by the developers of widely used

object-oriented analysis and design methods Has become an effective standard for object-

oriented modelling Notation

Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section

Relationships between object classes (known as associations) are shown as lines linking objects

Inheritance is referred to as generalisation and is shown ‘upwards’ rather than ‘downwards’ in a hierarchy