Upload
elizabeth-nicholson
View
257
Download
0
Tags:
Embed Size (px)
Citation preview
Checking and validation
• All parts match and everything is included
• Validate that stakeholders are happy
• Where are the major risks?
• Quality product = meet the spec?
A good requirement
• Correct; reflects a need• Complete; all necessary
requirements included• Unambiguous; all parties agree on
meaning• Consistent; all parts match (E/R and
event list)• Ranked for importance
A good requirement
• Modifiable; easy to change
• Verifiable; possible to see whether requirement is met
• Traceable; to goals/purposes, to design/code
• Understandable; by customer and developer
Checking the spec in isolation
• When a check reveals a problem;– Simple – fix it– Important info missing – more
elicitation work required– Important info missing but not
important – ignore or comment that intentionally left out
– Two parts of the spec mismatch – look into simple mistake or more important
Contents check
• Introduction• System goals• Data requirements• Functional requirements• Handling of special cases• Quality requirements• Other deliverables• Glossary
Structure check
• ID for each requirement• Verifiable requirements• Purpose• Examples of ways to meet requirement• Explanation of diagrams• Importance and stability • Cross references• Index• Electronic version
Consistency checks and CRUD
• CRUD; can each entity class in the data model be created and deleted by an event or function or user task?
• Can each field in the data model be Read and Updated by an event or function or user task?
• Event check; are all events handled by a function or user task?
Consistency checks and CRUD
• Information needs; are the necessary data for each task or message flow available in the data model?
• Virtual windows checks; – are all data in the virtual windows
available in the data model an vice versa?
– Are all tasks conveniently supported through a few virtual windows?
Checks against surroundings
• Review of the specification–Many issues are usually found– Not all lead to problems in development– Difficult to know which ones cause
problems – Resolving earlier saves a lot of time
later on
Checks against surroundings
• Goal-requirements tracing– Are all goals and critical issues covered
by requirements?– Are all requirements justified by
meaningful purposes?
Risk assessment
• A requirement that is risky to the customer is often low risk for the developer and vice versa
• Customer risk; doesn’t get what is needed even if this is what is specified
• Developer risk; cannot fulfill requirement within reasonable cost
Unacceptable risk
• Choose another requirement style with lower risk
• Elicit more precise requirements
• Isolate the risk
• Keep the risk under observation
Zed
• Based on set theory, functions and discrete mathematics
• Standard symbols Special symbols• Four sections– Given sets, data types, and constants– State definition– Initial state– Operations
Zed• Set theory provides foundation to
construct an abstract structure of software product
• First-order predicate logic used to express behavior of the product
• Strongly typed; every object must be associated with a unique type– easier to develop tools to type check
– interpreted as maximal sets (subset relations)
Schema
• Encapsulated structure
• Associated with some properties
• Can specify parts of a system separately and compose larger systems– types– state spaces– operations
Abstraction
• Representational abstraction– type definitions– global constants– state space declaration
• Operational abstraction– operation definitions– function definitions
Representational Abstraction
• Schema– unique name– structure described by a set of declarations– property described by a set of predicates
• express invariant relationships among the structure components
• Allows specification to be split into manageable pieces for modular specifications
Types• Interpreted as sets
• Carrier set; set of values associated with a type– describes the collection of values an object of
that type can assume
• Every variable, constant, and expression must be associated with a type– easier to spot errors in the spec– enforces discipline in writing good specs
Simple types
• Primitive types; already defined in Z– integer type is only primitive type in Z
• Basic types; user defined– used in current spec and not further
elaborated– users of an automated teller machine can
be modeled as a basic type• [USERS]• [USERS, STAFF, CLIENTS]
Abbreviation
• New names can be used for complex expressions
• Title X Author X CallNumber X Year• Book == Title X Author X CallNumber
X Year• Room numbers between 100 and 199• r: RoomNumber 100 <= r <= 199
Elevator Problem
• Given sets– do not need to be defined in detail– [Button] ; the set of all buttons
• floor buttons
• elevator buttons
• buttons (set of all buttons in the elevator problem)
• pushed (all buttons that have been pushed)
– PP; power set (set of all subsets of a given set)
Initial State
• Abstract initial state; state when the system is first tuned on
• Vertical schema vs horizontal schema• When elevator is first turned on the set
pushed is initially empty (all buttons off)
Button_Init = [Button_State’ | pushed’ = ]^
Operations
operation changes the state of a variableinput variableoutput variable
` new value of a variable/ set difference such that
Analysis of Z• Z successfully applied on many projects– easy to find faults in the specification– specifier must be very precise which leads
to less ambiguity– developers can prove specification correct– requires no formal mathematical
background– decreases the cost of software development– can be rewritten in natural language
Summary
• Summarize your present understanding of the problem and all your findings in a concise, complete, well-organized and polished statement (processing narrative )
• Important that this step is well done, since this first informal document will serve as anchor for your further work
Concurrent Systems
• FSM not good at coping with timing– synchronization problems– race conditions– deadlock
• Poor specifications can cause timing related problems
• Petri Nets good at specifying systems with potential timing problems
Petri Nets
• Carl Adam Petri (automata theory)
• Now used in other areas– performance evaluation– operating systems– software engineering
• Use to specify concurrent interrelated activities
Components of a Petri Net
• Four parts– set of places, P– set of transitions, T– input function, I– output function, O
• Formally; C = (P, T, I, O)– P = {p1,p2,…,pn}, n >= 0– T = {t1,t2,…,tm}, m >= 0 (P and T disjoint)– I: T --> P is the input function– O: T --> P is the output function
Petri net example
• Petri net on next page– P = {p1, p2, p3, p4}– T = {t1, t2}– I(t1) = {p2, p4}– I(t2) = {p2}– O(t1) = {p1}– O(t2) = {p3, p3}
Marking
• Marking is an assignment of tokens to the Petri net
• Represented by a vector (1,2,0,1)• Transition is ready to fire (enabled) if each of
its input places has as many tokens in it as there are arcs from the place to that transition– number of tokens not conserved–marking before t1 fires is (1,2,0,1)–marking after t1 fires is (2,1,0,0) –marking after t2 fires is (2,0,2,0)
More on Marking
• Petri nets are nondeterministic– if more than one transition is ready to
fire, any one of them may be fired
• Formally; C = (P,T,I,O) is a function from the set of places P to the set of nonnegative integers M: P --> {0,1,2,…}
• A marked Petri net is a 5 tuple (P,T,I,O,M)
Inhibitor Arc
• Small circle instead of an arrow head
• A transition is enabled if there is at least one token on each of its normal input arcs and no tokens on any of its inhibitor input arcs– Transition t1 is enabled because there
is a token in p3 but no token in p2
Petri Net Summary
• Abstract virtual machine (like FSM)
• Very well defined behavior
• Circles are “places”
• Lines are “transitions”
• Arrows (directed arcs) interconnect places and transitions
Petri Net Summary• Transition is enabled when all transition
arcs entering that transition emanate from places containing tokens (dots within places)
• “Enabled” is when the external stimulus associated with that transition occurs– tokens that enabled the transition are
consumed– new tokens created at the ends of the arcs
exiting from the transition node
Petri Net example
• Starting configuration• Only one transition is enabled (T1)• If stimulus T1 occurs– token at P2 moves to P1– only one transition enabled (T4)
• If stimulus T4 occurs– tokens at P1 and P5 are consumed– two tokens created at the ends of the arcs
exiting T4
Petri Net Example
• (e) is identical to (a)• Petri Net with a cycle of length 4• So how does this help us write a SRS?– assume that T1 - T4 are all associated with the
same 1 second clock– P2 and P3 are lights– Petri Net could be used to unambiguously
define the requirements for this 2 light system
Petri Net for a 2 light system
• 1. There are two light bulbs
• 2. Every other second, there shall be no lights on
• 3. Every other second, there shall be exactly one light on
• 4. Each time a light comes on, the lights alternate
Petri Net for a 2 light system
• Places P2 and P3 in the preceding Petri Net do just that
• Petri Net contains no ambiguity
• The English sentences may be misunderstood
• Same behavior shown on next page - but its simpler!
Another set of specifications
• 1. There are two light bulbs• 2. For the first two seconds one light
is on• 3. For the next two seconds, that
light goes off and the other light goes on
• 4. From then on every 2 seconds the lights alternate
How to analyze this Petri Net
• Initially a token at P0• User is asked to do x• Once the user arrives a timer token
proceeds to P1 and arrives at P2 in exactly 15 seconds
• A token also sits at P3 waiting for either the 15 seconds to elapse (P3 token consumed by firing transition T1) or for the user to complete x (P3 token consumed by firing transition T2)
How to analyze this Petri Net
• If 15 seconds elapses P4 is fired activating the alternative system response (warning message perhaps)
• If the user completes x before 15 seconds, P5 is fired for the normal system response
• If the user completes x in precisely15 seconds the normal system response happens (benefit of the doubt)
How to analyze this Petri Net
• lo and hi priorities places on arcs from P3 to remove any doubt associated with nondeterminism
• Normal response spawns a timer token at P2–may force an alternative system response to
the next user that comes along– Place P6 added to remove these– Mission at T3 is to remove all “renegade”
timer tokens that reach P2
How to analyze this Petri Net
–arc connecting P2 and T3 is higher priority than arc connecting P2 and T1• ensures that the timer token is
removed if there is a token at P6 and never has a chance to give a subsequent user at P3 an alternative system response through T1 accidentally
Petri Net Extension
• Stimulus-response and response-response constraints required a Petri Net extension– required execution time recorded above
each Place– specified the maximum allowable time
for the system to perform the operations