From requirements to specification

2. From requirements to specification • Specification is a refinement of requirements • Can be included together as Software Requirements Specifications (SRS) • Elaborate on the WHAT? the software system is supposed to do • As opposed to HOW it will do it • Should not be very constraining • Leave the details to the design

4. Software modeling • Modeling techniques – visual, executable, general, readable, ….. • Modeling • Behavior: Finite state machine (FSM), Petri net (PN), Sequence diagram, Activity diagram, and other UML diagrams • Data: Entity relationship diagram (ERD) • Process: Data flow diagram (DFD), Decision table, decision tree

5. The Finite State Machine Model (FSM) • Used to describe: • State-based behavior of a process within a software systems. • Whole system as one process. • FSM is used when the number of states the process can be in is small, and the next state of a process is determined by its current state and the inputs applied to the process. • Typically, the process behavior is be described by the next process state and the output the process delivers after accepting an input.

6. Algebraic definition of an FSM

10. Properties of an FSM model • Completeness • Determinism • Fully connected • Strongly connected • Minimal • Can be verified

11. Complete FSM • An FSM is said to be complete or completely specified, if and only if, at each state, there exists a transition for each input i SI. • In other words, the FSM should react to every input at every state, and this reaction should be captured and specified in the model.

12. Complete FSM • To produce a robust software system, it is desirable to specify what to do when both valid (good) and invalid (bad or unexpected) inputs are applied at each state of the system. • Specification completeness would allow the implementation of a robust process, a process capable of dealing with both correct and wrong inputs.

13. Deterministic FSM • An FSM is said to be deterministic, if and only if, at any state, the reaction to an input is unique and unambiguously determined. • Uniqueness means that for the same input at the same state, the FSM should move to the same next state and delivers the same output, any time it executes.

14. Deterministic FSM • It is extremely desirable that an FSM modeling a software process be deterministic. • A software implementation must be deterministic, since a user, at the same state, would like to obtain the same result any time the same request (input) is present. • This property is desirable also for any user-oriented systems (i.e., a vending machine, a telephone system, ...).

15. Strongly connected FSM • An FSM is said to be strongly connected, if from any state, we can reach any other state of the FSM either immediately by executing one or more transitions. • The strong connectedness feature is desirable for software processes. • A state that is not reachable from any other state means that the process is somehow disconnected or discontinued. Therefore, one part of the process may be useless since it is unreachable.

16. Fully connected FSM • An FSM is said to be fully connected, if from any state of the FSM, we can reach each of the other states by executing one transition. • This requirement is very restrictive and infeasible, and is normally not desirable in software processes. • Think about it for a user interface?

18. Minimal FSM • An FSM is said to be minimal, if there exists no other equivalent FSM with less number of states or transitions. • The minimality property is desirable for both software and hardware (digital) systems. • Implementing a non-minimal FSM implies wasting development efforts on a non-reduced and somehow redundant specification. This definition of minimality assumes that all transitions are of equal complexity.

19. Example • Describe the FSM in both the algebraic and tabular forms. • Can you describe in English what does this FSM specify? • Add the necessary transitions and states to the FSM diagram. Is the FSM complete and deterministic? why? if incomplete, can you suggest a modification to complete it.

20. Limitations of the FSM • Conditional behavior specification • Time specification • Data manipulation specification • Concurrency specification • The Extended FSM – EFSM

23. Timing and Timeout Specification • We want to specify that if at a state S no input is present within t time units, a transition should take place and an output should be delivered. • This situation would occur in many real-time processes, and in user-oriented interfaces and systems. • We would like to have certain delayed transitions, in which a time delay is specified instead of an input symbol. • Presence of an input symbol or time delay is mutually exclusive.

24. Conditional Transitions • To specify that, at a given state S, in addition to the availability of an input symbol, certain predicate(s) should evaluate to True • Predicated or conditional transitions. • Transition takes place only if the predicate evaluates to true. • Modified definition: EFSM is said to be deterministic, if at the same state, for the same input and the same predicate, the same transition (next state and output) must occur.

26. Is this deterministic?

27. Variable Manipulation • If at given state of the FSM, the reaction to the next input symbol must change a certain variable value needed in future transitions (i.e., in a predicate evaluation). • For example, in a user interface driven process, at the logon state, the reaction to a bad login input may depend on the number of times a bad login input was performed earlier. • A variable holding a counter of the number of bad logins is needed.

28. Concurrency Specification • Due to its inherently sequential nature, a basic finite state machine cannot model concurrent behaviors that may be needed to describe complex concurrent applications. • Extensions to the FSM were added in the UML statechart diagram to model concurrent execution by specifying concurrent substates.

32. States: idle state (s1), the wait-for-pin state (s2), the start-selection state (s3), and the card-confiscated state (s4). Inputs: the client’s card (i1), and the PIN code (i2). Outputs: the screen to get the PIN (sc1), the waiting for PIN timeout message (o1), the invalid PIN error message (e1), the card confiscated message (e2), and the start transaction selection screen (sc2). Predicate P1 evaluates to true if the number of trials did not exceed the specified limit, and predicate P2 evaluates to true if the entered PIN code is valid. Only one variable to count the number of trials is needed (v1).

33. Example • Suppose that at any state (except the initial idle state) if we do not receive an input within 10 time units, we want the system to be blocked for 5 time units and then move to the locked state again. Add the necessary transitions and states to the FSM diagram.

34. Example • Partial behavior of ATM: • “First the user inserts the bank card in the ATM’s card reader. • Then, the ATM expects the user to enter the PIN within 20 seconds, otherwise the ATM will beep and eject the card. • If the PIN is valid, the user is allowed to proceed with a choice of banking transactions. • Otherwise if the PIN is invalid, the user can retry for a maximum of two more trials. • After 3 wrong trials, the card is confiscated by the ATM, and the user has to contact the main branch.”

35. Example • Given the following English specification involving a distributed system of 3 CFSMs corresponding to 3 interacting processes. “The user process (UP) requests a data item from the server process (SP). The server process directs any request to the database process (DP) which returns either with a data item or an error message indicating that the requested item is not available. Once the SP receives the data item (data), it increments a counter (c) of serviced request by 1 and passes the data item to the UP. However, if the SP receives an ‘item not available’ (nav) message from the DP, it tries again one more time after the elapse of 2 seconds. If for the second time, it receives the ‘item not available’ (nav) message, it returns back to the UP with the message ‘item not available’ (nav).”

37. The Petri Net model • Introduced by Carl Petri in 1963. • Powerful modeling technique with strong mathematical foundation. • Verification of the model properties is facilitated. •  Algebraic and graphical representation •  Executable and verifiable using available tools

38. Algebraic definition of a PN

39. Graphical representation of a PN

40. PN Example • Places: p1, p2, p3 • Transitions: t1, t2 • Backward and Forward Arcs • Tokens: 2 tokens (initially) • Initial marking: (1, 0, 1)

41. t1, t4 are forking transitions t3 is a joining (synchronizing transition)

42. Analysis of a PN model • Structural properties: invariant analysis • Place invariants • Transition invariants • Dynamic properties: enumerative analysis • Reachability graph

43. PN invariants • Transition invariants: • A sequence of transition that leads back to the same token distribution (the initial state) • Desirable properties for cyclic systems • C (the incidence matrix) = B – F • M’ = M + C s and M’ = M => C s = 0 • Solve for C (s1s2s3 … st), = 0 • Can have more than one transition invariant

44. PN invariants • Place invariants: • A subset of places in which the number of tokens remains constant • Conservative PN: the number of tokens in the whole net remains constant • Can have more than one place invariant • Solve f C = 0, where the f = (f1f2 … fp)

46. Enumerative analysis

47. Extensions to the PN model • Inhibitor Arc PN • Predicate PN • Timed PN • Colored PN • Numeric PN • Probabilistic PN • Fuzzy time PN • …

48. Example – Modeling requirements • In a request handling system, the handler must immediately process an incoming request once it is received. The processing takes between 5 and 10 seconds to complete. Once a request is handled, the system must be able to handle new requests immediately. The system should keep track of the number of handled requests.

50. p2 p3 is a place invariant • No transition invariants