1. Chapter 5: Specification Yuanfang Cai CS751 Jan 29, 2003

2. Overview Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.6 Descriptive Specifications 5.7 Building and Using Specifications in Practice

3. Overview Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.6 Descriptive Specifications 5.7 Building and Using Specifications in Practice

4. Overview Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.5.1 Data Flow Diagram (DFD): Function 5.5.2 Unified Modeling Language (UML): Behavior 5.5.3 Finite State Machine (FSM): Control Flow 5.5.4 Petri Nets: Asynchronous Systems 5.6 Descriptive Specifications 5.7 Building and Using Specifications in Practice

5. Overview Definition 5.1 The Uses of Specification 5.2 Specification Qualities 5.3 Classification of Specification Styles 5.4 Verification of Specification 5.5 Operational Specifications 5.6 Descriptive Specifications 5.6.1 Entity Relationship Diagrams 5.6.2 Logic Specification 5.6.3 Algebraic Specifications 5.7 Building and Using Specifications in Practice

6. Definition  The statement of an agreement between a producer of a service and the consumer of the service or between an implementer and a user Requirement specification Design specification Module specification  Requirements, Specification and Design

7. Definition  The statement of an agreement between a producer of a service and the consumer of the service or between an implementer and a user Requirement specification Between end user and the system architect/developer Design specification Module specification  Requirements, Specification and Design

8. Definition  The statement of an agreement between a producer of a service and the consumer of the service or between an implementer and a user Requirement specification Between end user and the system architect/developer Design specification Between the architect and the implementers Module specification  Requirements, Specification and Design

9. Definition  The statement of an agreement between a producer of a service and the consumer of the service or between an implementer and a user Requirement specification Between end user and the system architect/developer Design specification Between the architect and the implementers Module specification Between the implementer and the user of a module  Requirements, Specification and Design

10. 5.1 The use of Specifications  A statement of user requirement  A statement of interface between the machine and the controlled environment  A statement of requirements for the implementation  A reference point during product maintenance.

11. 5.2 Specification Quality  Clear, unambiguous and understandable  Consistency  Complete Internally complete Externally complete

12. 5.3 Classification of Specification Styles  Formal, informal and Semiformal Specifications  Operational and descriptive specifications Operational specifications: desired behavior Descriptive specifications: desired properties

13. 5.4 Verification of Specifications  Dynamic analysis  Static analysis  Formalism and verification Simulation Prototype  Verify all three aspects: Functional Consistency completeness

14. 5.5 Operational Specifications 5.5.1 Data Flow diagrams Features Example limitations 5.5.2 UML Diagram for Specifying Behaviors 5.5.3 Finite State Machine: Describing Control Flow 5.5.4 Pretri Nets: Specifying Asynchronous Systems

15. 5.5.1 Data Flow Diagram: Specifying Functions of Information Systems  Features Describe systems as collections of functions that manipulate data Can be expressed by means of graphical notation Elements: Input device symbol Function symbol Data flowOutput device symbol Data store symbol

16. a + * + * b d c 5.5.1 DFD Example (a + b) * ( c + a * d)

17. 5.5.1 DFD limitations  The semantics of the symbol is specified only by the identifiers chosen by the user.  Control aspects are not defined by the model B D E C F A

18. 5.5.1 DFD Limitations  The semantics of the symbol is specified only by the identifiers chosen by the user.  Control aspects are not defined by the model B D E C F A

19. 5.5.1 DFD Limitations  The semantics of the symbol is specified only by the identifiers chosen by the user.  Control aspects are not defined by the model B D E C F A

20. 5.5 Operational Specifications 5.5.1 Data Flow diagrams 5.5.2 UML Diagram for Specifying Behaviors Features Example Limitations 5.5.3 Finite State Machine: Describing Control Flow 5.5.4 Pretri Nets: Specifying Asynchronous Systems

21. 5.5 Operational Specifications 5.5.1 Data Flow diagrams 5.5.2 UML Diagram for Specifying Behaviors 5.5.3 Finite State Machine: Describing Control Flow Definiation Features Example Limitations 5.5.4 Pretri Nets: Specifying Asynchronous Systems

22. 5.5.3 Finite State Machines: Describing Control Flow  Definition A finite automata is a 5-tuple (Q, , , q 0, F), where 1. Q is a finite set called the states, 2.  is a finite set called the alphabet (inputs), 3.  : Q    Q is the transition function, 4. q 0  Q is the start state, and 5. F  Q is the set of accept states (final states).

23. 5.5.3 Finite State Machines: Describing Control Flow  Features Formal notation Suitable for describing systems that can be in a finite set of states and that can go from one state into another as a consequence of some event, modeled by an input symbol. Widely used: specification of control systems, compilation, pattern matching, etc.

24. 5.5.3 Finite State Machines: Describing Control Flow  Example On Off Push switch

25. 5.5.3 Finite State Machines: Describing Control Flow  Example: Chemical plant On Off High-pressure alarm Restart High-temperature alarm

26. Normal Off Pressure Recovery Temperature Recovery Pressure signal Temperature signal Pressure signal Successful recovery Unsuccessful recovery Successful recovery Unsuccessful recovery 5.5.3 Finite State Machines: Describing Control Flow  Example: Chemical plant

27. 5.5.3 Finite State Machines: Describing Control Flow  Limitations Finite states: need assistance such as natural language or accompanied by action descriptions, like: Cooling_effort := k * (present_temperature – standard temperature) Can’t describe concurrent, asynchronous systems. P1 P2C1 C2 0 12 write produce read consume write read empty full

28. consume Produce consume Produce consume Produce write read write read 5.5.3 FSM: Describing Control Flow  Example continued: the Cartesian Product of the component state sets:

29. 5.5.3 Finite State Machines: Describing Control Flow  Limitations: The cardinality of the state space grows dramatically: if we have n subsystems, each with k i states, the resulting system has a cardinality of k 1 *k 2 *…K n FSM are essentially a synchronous model: at any time, a global state of the system must be defined and a single transition must occur.

30. 5.5 Operational Specifications 5.5.1 Data Flow diagrams 5.5.2 UML Diagram for Specifying Behaviors 5.5.3 Finite State Machine: Describing Control Flow 5.5.4 Pretri Nets: Specifying Asynchronous Systems Definition Example Features Limitations

31. 5.5.4 Petri Nets: Specifying Asynchronous System  Definition A Petri Net is a quadruple (P, T, F, W), where 1. P is the finite set of places; 2. T is a finite set of transitions; 3. P  T   ; 4. F  { P  T}  { T  P} is the flow relation; and 5. W: F  N – {0} is the weight function, which associates a nonzero natural value to each element of F. If no weight value is explicitly associated with a flow element, the default value 1 is assumed for the function

32. 5.5.4 Petri Nets: Specifying Asynchronous System  Example: write produce p1 p2 Place Token Transition p2 is the input place of transition write p1 is the output place of transition write Produce is the enabled, so transition produce may fire

33. 5.5.4 Petri Nets: Specifying Asynchronous System  Example: write produce p1 p2 Place Token Transition p2 is the input place of transition write p1 is the output place of transition write Produce is the enabled, so transition produce may fire 2

34. 5.5.4 Petri Nets: Specifying Asynchronous System  Example: After produce fired write produce p1 p2 Place Token Transition p2 is the input place of transition write p1 is the output place of transition write Now, write is the enabled, so transition write may fire 2

35. write produce p1 p2 consume read c1 c2 read write 0 1 read write 2 5.5.4 PN: Specifying Asynchronous System  Example: producer and consumer

36. consume c1 c2 produce p1 p2 read write 0 1 read write 2 5.5.4 PN: Specifying Asynchronous System  Example continued: producer and consumer: Now the system is at the state

37. consume c1 c2 produce p1 p2 read write 0 1 read write 2 5.5.4 PN: Specifying Asynchronous System  Example continued: producer and consumer: Now the system is at the state

38. consume c1 c2 produce p1 p2 read write 0 1 read write 2 5.5.4 PN: Specifying Asynchronous System  Example continued: producer and consumer: Now the system is at the state

39. 5.5.4 Petri Nets: Specifying Asynchronous System  Features Good at describing concurrent and asynchronous system  Limitations Tokens are anonymous Can’t specify a selection policy Can’t resolve deadlock or starving…

40. 5.6 Descriptive Specifications 5.6.1 Entity Relationship (ER) Diagrams A semiformal notation 5.6.2 Logic Specification 5.6.3 Algebraic Specifications

41. 5.6.1 Entity Relationship Diagrams STUDENT CLASS AGE SEX NAME ENROLLED_IN SUBJECT COURSE_ID MAX_ENROLLMENT Entities: a collection of items that share common properties Relations: A set of pairs, where a is an element of STUDENT and b is an element of CLASS Attribute:

42. 5.6.1 Entity Relationship Diagrams Relation Attributes: A B R A B R A B R A B R A R B is one to one A R B is one to many A R B is many to one A R B is many to many

43. Unified Modeling Language  A general-purpose visual modeling language that is used to specify, visualize, construct and document the artifacts of a software system.  Static Structure (Descriptive)  Dynamic behavior (Operational)

44. Unified Modeling Language  Static Structure (Descriptive) Static view: class diagram User Case View Physical Views Implementation view Deployment view  Dynamic behavior (Operational) Interaction view Sequence diagram Collaboration diagram State machine view Activity view

45. Unified Modeling Language  Static Structure (Operational) Static View: class diagram User Case View Physical Views Implementation view Deployment view  Dynamic behavior (Descriptive) Interaction view Sequence diagram Collaboration diagram State machine view Activity view

46. Customer Name: String Phone: String Add(name,phone) Reservation Date: Date Subscription Series Series: integer Individual Reservation Ticket Available: Boolean Sell (c. Customer) Exchange() Show Name: String Performance Date: Date Time: TimeOfDay Seat: Sting 1 * 1* 1 1..* Class attributes class-scope operation association generalization multiplicities Class Diagram: qualifier 0..1 3..6 0..1 1

47. Kiosk buy tickets buy subscription make charges survey sales relationship Use case > Clerk Credit card service Supervisor system actor Use Case Diagram:

48. Unified Modeling Language  Static Structure (Operational) Static View: class diagram User Case View Physical Views Implementation view Deployment view  Dynamic behavior (Descriptive) Interaction view Sequence diagram Collaboration diagram State machine view Activity view

49. Kiosk box office credit card service message Request (count, performance) Show availability (seat-list) Select(seats) Demand payment(cost) Insert card(card number) Print tickets (performance, seats) Eject card charge(card number,cost)) authorized lifeline (active) Active object Sequence Diagram

50. Kiosk ticketseller message active object performanceGuide Db: performanceDB link multi object Db: performanceDB 2: db := findDB(performance) >db transient link passive object 1:request (count, performance)4: offer(seat-list)5:buy(seats)8:confirm (seats, cost) 3: seat-list := lock(count)  6: claim (seats)  7: unlock(seat-list)  Collaboration Diagram:

51. Initial state Available Locked Sold state transition Trigger event Assign to subscription Time out lock unlock exchange buy State chart Diagram

52. activity Pick show schedule show publicize show Buy scripts and music Hire artists Build sets Design lighting Make costumes Sell tickets rehearse Dress rehearsal perform Completion transition join fork Activity Diagram

53. Questions?