specification techniques. system models are abstract descriptions of systems whose requirements are...
TRANSCRIPT
Specification Techniques
System models are abstract descriptions of systems whose requirements are being analyzed
Objectives To explain why specification modeling techniques
help discover problems in system requirements To describe
– Behavioural modeling (Finite State Machines, Petri-nets),
– Data modeling and – Object modeling (Unified Modeling Language,
UML)
Formal Specification - Techniques for the unambiguous specification of software
Objectives: To explain why formal specification techniques
help discover problems in system requirements To describe the use of
– algebraic techniques (for interface specification) and
– model-based techniques (for behavioural specification)
System Modeling
System modeling 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
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
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
Context Models
Context models are used to illustrate the boundaries of a system
Social and organizational concerns may affect the decision on where to position system boundaries
Architectural models show a system and its relationship with other systems
The Context of an ATM System
Auto-tellersystem
Securitysystem
Maintenancesystem
Accountdatabase
Usagedatabase
Branchaccounting
system
Branchcountersystem
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
Equipment Procurement Process
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 +estimate
Supplier listEquipment
spec.
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
Software Design Semantic ModelDesign
namedescriptionC-dateM-date
Link
nametype
Node
nametype
links
has-links
12
1 n
Label
nametexticon
has-labelshas-labels
1
n
1
n
has-linkshas-nodes is-a
1
n
1
n1
1
Data Dictionary Entries
Data dictionaries are lists of all of the names used in the system modelsDescriptions of the entities, relationships and attributes are also included
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
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 recognized as a difficult process requiring a deep understanding of the application domain
Object classes reflecting domain entities are reusable across systems
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
modeling 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 generalization and is shown ‘upwards’ rather than ‘downwards’ in a hierarchy
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
Data Flow Diagrams
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
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
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
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 modeling 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
State charts are an integral part of the UML
Microwave Oven Model
Full power
Enabled
do: operateoven
Fullpower
Halfpower
Halfpower
Fullpower
Number
TimerDooropen
Doorclosed
Doorclosed
Dooropen
Start
do: set power = 600
Half powerdo: set power = 300
Set time
do: get numberexit: set time
Disabled
Operation
Timer
Cancel
Waiting
do: display time
Waiting
do: display time
do: display 'Ready'
do: display 'Waiting'
State machine model does not show flow of data within the system
Microwave Oven Stimuli
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
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
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.
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.
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.
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.
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 recognizer, 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.
State Charts 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
stimuli
Cookdo: run generator
Done
do: buzzer on for 5 secs.
Waiting
Alarm
do: display event
do: checkstatus
Checking
Turntablefault
Emitterfault
Disabled
OK
Timeout
TimeOperation
Dooropen
Cancel
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.
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
TransitionPlace
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.
The Classical Petri Net Model A Petri net is a network composed of places ( ) and transitions ( ).
t2
p1
p2
p3
p4t3
t1
Connections are directed and between a place and a transition.
Tokens ( ) are the dynamic objects.
The state of a Petri net is determined by the distribution of
tokens over the places.
Transition t1 has three input places (p1, p2 and p3)and two output places (p3 and p4).Place p3 is both an input and an output place of t1.
p1
p2
p3
p4t1
Enabling ConditionTransitions are the active components and places and
tokens are passive.A transition is enabled if each of the input placescontains tokens.
t1 t2
Transition t1 is not enabled, transition t2 is enabled.
FiringAn enabled transition may fire.
Firing corresponds to consuming tokens from the inputplaces and producing tokens for the output places.
t2t2
Firing is atomic.
Example
Non-Determinism
Two transitions fight for the same token: conflict.Even if there are two tokens, there is still aconflict.
t1
t2
A Collection of Primitive Structures that occur in Real Systems
High-Level Petri Nets The classical Petri net was invented by Carl Adam
Petri in 1962. Since then a lot of research has been conducted (>10,000 publications).
Since the 80-ties the practical use is increasing because of the introduction of high-level Petri nets and the availability of many tools.
High-level Petri nets are Petri nets extended with– color (for the modeling of attributes)– time (for performance analysis)– hierarchy (for the structuring of models, DFD's)
Modeling
States of a process are modeled by tokens in places andstate transitions leading from one state to another aremodeled by transitions.
Tokens represent objects (humans, goods, machines), information, conditions or states of objects.
Places represent buffers, channels, geographical locations, conditions or states.
Transitions represent events, transformations or transportations.
Example: Traffic Light
rg
red
yellow
green
yr
gy
Current StateThe configuration of tokens over the places.
Reachable StateA state reachable form the current state by firing a sequence of enabled transitions.
Dead StateA state where no transition is enabled.
Some Definitions
blackred
bbrr
br
High-Level Petri Nets
In practice the classical Petri net is not very useful: The Petri net becomes too large and too complex. It takes too much time to model a given situation. It is not possible to handle time and data.
Therefore, we use high-level Petri nets, i.e. Petri netsextended with: color time hierarchy
To explain the three extensions we use thefollowing example of a hairdresser's saloon.
start
waiting
finish
busy
free
ready
client waiting
hairdresser ready to begin
Note how easy it is to model the situation with multiple hairdressers.
The Extension with Color
A token often represents an object having allkinds of attributes.Therefore, each token has a value (color) whichrefers to specific features of the object modeled bythe token.
start
waiting
finish
busy
free
ready
name: Harryage: 28experience: 2
name: Sallyage: 28hairtype: BL
Each transition has an (in)formalspecification which specifies: the number of tokens to be produced, the values of these tokens, and (optionally) a precondition.
The complexity is divided over the network andthe values of tokens.
This results in a compact, manageable and naturalprocess description.
Examples
c := a+ba
b c
+
b := -a
b-a
if a> 0then b:= aelse c:=afi
a b
c
select
a >=0 | b := a
bsqrta
Extra Credit Exercise:calculate |a+b| using these building blocks
The Extension with Time
For performance analysis we need to modeldurations, delays, etc.Therefore, each token has a timestamp andtransitions determine the delay of a producedtoken.
start
waiting
finish
busy
free
ready
0
1
3 9
=3
=0=0
The Extension with Hierarchy A mechanism to structure complex Petri nets comparable to DFD's.
A subnet is a net composed out of places, transitions and subnets.
waiting ready
h1
h2
h3
start finishbusy
free
Key Points Modeling specification complements informal
requirements elicitation techniques. Model specifications can be precise and
unambiguous, but generally depend on interpretation of inputs/output. They reduce areas of doubt in a specification.
More formal models, such as FSM or Petri nets forces an analysis of the system requirements at an early stage. Correcting errors at this stage is cheaper than modifying a system during design.