1. Ch. 51 Specification

2. Ch. 52 Outline Discussion of the term "specification" Types of specifications –operational Data Flow Diagrams (Some) UML diagrams Finite State Machines Petri Nets –descriptive Entity Relationship Diagrams Logic-based notations Algebraic notations Languages for modular specifications –Statecharts –Z

3. Ch. 53 Specification A broad term that means definition that emphasizes on What to do versus How to do it –In traditional engineering it has precise meaning (i.e., the specific parameters of the product). In SE this is not the case. Used at different stages of software development for different purposes Generally, specification is a statement of agreement (contract) between producer and consumer of a service: –implementer and user: requirement spec, non-technical, e.g., plain English –Architect and developer: design spec, technical, e.g., UML diagrams All desirable qualities must be specified

4. Ch. 54 Uses of specification Statement of user requirements –major failures occur because of misunderstandings between the producer and the user Lack of knowledge of computer –In most cases the owner does not exactly know what he/she wants to be developed –"The hardest single part of building a software system is deciding precisely what to build" (Frederick Brooks)

5. Ch. 55 Uses of specification (cont.) Statement of the interface between the machine and the controlled environment –serious undesirable effects can result due to misunderstandings between software engineers and domain experts about the phenomena affecting the control function to be implemented by software: Receiving input signals from sensors and generating output signals to control the embedded system.

6. Ch. 56 Uses of specification (cont.) Statement of requirements for implementation –Software Development process is a chain of: Specification–Implementation–Verification steps Requirements specification refers to definition of external behavior –design specification must be verified against it Design specification refers to definition of the software architecture –code must be verified against it

7. Ch. 57 Uses of specification (cont.) A reference point during maintenance –Corrective maintenance only changes implementation –Adaptive and Perfective maintenance occur because of requirements changes requirements specification must change accordingly

8. Ch. 58 Specification qualities Precise, clear, unambiguous Consistent Complete –internal completeness –external completeness Incremental

9. Ch. 59 Clear, unambiguous, understandable Example: specification fragment of a word- processor for “selection” operation. Selecting is the process of designating areas of the document that you want to work on. Most editing and formatting actions require two steps: first you select what you want to work on, such as text or graphics; then you initiate the appropriate action. can an area be scattered?

10. Ch. 510 Precise, unambiguous, clear Another example (from a real safety- critical system) The message must be triplicated. The three copies must be forwarded through three different physical channels. The receiver accepts the message on the basis of a two-out-of-three voting policy. can a message be accepted as soon as we receive 2 out of 3 identical copies of message or do we need to wait for receipt of the 3 rd ?

11. Ch. 511 Consistent Example: specification fragment for a word-processor The whole text should be kept in lines of equal length. The length is specified by the user. Unless the user gives an explicit hyphenation command, a carriage return should occur only at the end of a word. What if the length of a word exceeds the length of the line?

12. Ch. 512 Complete Internal completeness –The specification must define any new concept or terminology that it uses glossary of terms is helpful for this purpose External completeness –The specification must document all the needed requirements difficulty: when should one stop?

13. Ch. 513 Incremental Referring to the specification process –start from a sketchy document and progressively add details Referring to the specification document –document is structured and can be understood and extended in increments

14. Ch. 514 Classification of specification styles Informal (plain English), semi-formal (DFD, UML diagrams), formal (languages: Z, Larch, B-method, Petri-nets, SDL, VHDL, LOTOS) Operational –Behavior specification in terms of some abstract machine Descriptive –Behavior described in terms of properties and input/output relation.

15. Ch. 515 Example 1 Specification of a geometric figure E: Ellipse can be drawn as follows: 1.Select two points P1 and P2 on a plane 2.Get a string of a certain length and fix its ends to P1 and P2 3.Position a pencil as shown in next figure 4.Move the pen clockwise, keeping the string tightly stretched, until you reach the point where you started drawing this is an operational specification

16. Ch. 516

17. Ch. 517 A descriptive specification Ellipse E is described by the following equation: ax 2 + by 2 + c = 0 where a, b, and c are suitable constants. Given x as input, the resulting pairs in the form of (x, y 1 ) and (x,y 2 ) would be two points of the Ellipse in the x-y plane. this is a descriptive specification

18. Ch. 518 Another example: Sorting an array of elements “Let a be an array of n elements. The result of its sorting is an array b of n elements such that the first element of b is the minimum of a (if several elements of a have the same value, any one of them is acceptable); the second element of b is the minimum of the array of n-1 elements obtained from a by removing its minimum element; and so on until all n elements of a have been removed.” “The result of sorting array a is an array b which is a permutation of a and is sorted.” OP DES

19. Ch. 519 How to verify a specification? Testing specification against the ideal system: “Observe” dynamic behavior of the specified system (simulation, prototyping). “Analyze” properties of the specified system similar to the traditional engineering: –physical model of a bridge –mathematical model of a bridge

20. Ch. 520 Data Flow Diagrams (DFDs) A semi-formal operational specification System viewed as collection of “data” manipulated by “functions” Data can be persistent –they are stored in data repositories Data can flow –they are represented by data flows DFDs have a graphical notation

21. Ch. 521 Graphical notation –bubbles represent functions –arcs represent data flows –open boxes represent persistent store –closed boxes represent I/O interaction

22. Ch. 522 Example specifies evaluation of (a + b) * (c + a * d)

23. Ch. 523 A construction “method” (1) 1. Start from the “context” diagram

24. Ch. 524 A construction “method” (2) 2. Proceed by refinements until you reach “elementary” functions (preserve balancing)

25. Ch. 525 A library example

26. Ch. 526 Refinement of “Get a book”

27. Ch. 527 Patient monitoring systems The purpose is to monitor the patients’ vital factors--blood, pressure, temperature, …--reading them at specified frequencies from analog devices and storing readings in a DB. If readings fall outside the range specified for patient or device fails, an alarm must be sent to a nurse. The system also provides reports.

28. Ch. 528 A refinement

29. Ch. 529 More refinement

30. Ch. 530 An evaluation of DFDs (1) Easy to read, but … Informal semantics –How to define leaf functions? –Inherent ambiguities Outputs from A, B, C are all needed? Outputs for E and F are produced at the same time?

31. Ch. 531 An evaluation of DFDs (2) Control information is absent Possible interpretations: (a)A produces datum, waits until B consumes it (b)B can read the datum many times without consuming it (c)a pipe is inserted between A and B

32. Ch. 532 Formalization/extensions There have been attempts to formalize DFDs There have been attempts to extend DFDs (e.g., for real-time systems)

33. Ch. 533 UML diagrams UML (Unified Modeling Language) is a general purpose visual modeling language that provides different types of diagrammatic techniques and notations to specify, visualize, analyze, construct, and document the artifacts of a software system. Software artifacts include: SRS, SDS, test cases, source code, technical/user manual, software architecture, etc. UML diagrams are used to understand, design, browse, configure, maintain, and control information about software system. UML is intended for use with all development methods, lifecycle stages, application domains, and media. In this chapter, we cover use-case diagram, sequence diagram, and collaborative diagram from UML.

34. Ch. 534 UML History UML was developed in an effort to unify and simplify the large number of OO development methods that use popular OO languages. Simula 67 was the first OO language Smalltalk was introduced in early 1980s followed by Objective C, C++, Eiffle, CLOS, Java. First OO development method was Shlaer-88, then Yourdon 91, and Booch 91 Unification effort: –UML 1995 by Booch, Rumbaugh, Jacobson –OMG 1996 proposed a standard for OO modeling CORBA

35. Ch. 535 Modeing Software System What is model? –A model captures the important aspects of the artifact being modeled from a certain point of view, and simplifies or omits the rest. Data, Function, Behavior, Process, Implementation… What are models for? –To capture and precisely state requirements and domain knowledge so that all stakeholders may understand and argue on them. –To think about the design of a system –To capture design decisions –To organize, find, filter, retrieve, examine, and edit information about large systems.

36. Ch. 536 UML use-case diagrams Defines a global view of the actors involved in a system and the actions that the system performs, which in turn provides an observable result that is of value to the actors. Partitions the overall functionality of the system into transactions with respect to the actor and illustrates how actors interact with them. Actors define different roles such as: people, computer systems, environment borrow book return book library update librarian customer

37. Ch. 537 Use case diagram notations Association: the communication path between an actor and a use case that the actor participates in Extend: the insertion of additional behavior into a base use case that extends its operation. Generalization: relation between a general use case and a more specific use case that inherits from it. Include: the insertion of additional behavior into a base use case that describes the details of the base use case. Place order Order produce Supply Customer data Request catalog Arrange payment Pay cash Pay by credit > Parent use case Child use case Inclusion use case Base use case Extension use case Association > Actor Generalization

38. Ch. 538 UML sequence diagram Describes how different objects in the system interact by exchanging messages Provides a dynamic and temporal view Emphasizes on time sequence of message exchange

39. Ch. 539 UML sequence diagram example: Ticket selling box office

40. Ch. 540 UML collaboration diagrams Represents object interactions and their order Equivalent to sequence diagrams Sequence diagram is intended for time ordering considerations, whereas collaboration is emphasizes on the structural aspect of the system.

41. Ch. 541 UML collaborative diagram example: Ticket selling box office

42. Ch. 542 Finite state machines (FSMs) Can specify control flow aspects Defined as a finite set of states, Q; a finite set of inputs, I; a transition function d : Q x I  Q (d can be a partial function)

43. Ch. 543 Example: a lamp

44. Ch. 544 Another example: a plant control system

45. Ch. 545 A refinement

46. Ch. 546 Classes of FSMs Deterministic/nondeterministic FSMs as recognizers –introduce final states FSMs as transducers –introduce set of outputs...

47. Ch. 547 FSMs as recognizers q f is a final state

48. Ch. 548 FSMs as recognizers

49. Ch. 549 Limitations Finite memory State explosion –Given a number of FSMs with k 1, k 2, … k n states, their composition is a FSM with k 1 * k 2 *… * k n. This growth is exponential with the number of FSMs, not linear (we would like it to be k 1 + k 2 +… + k n )

50. Ch. 550 State explosion: an example

51. Ch. 551 The resulting FSM

52. Ch. 552 FSM simulator

53. Ch. 553 More Resources on FSM Course web page has several examples of finite state machines in reading questions Wikipedia –http://en.wikipedia.org/wiki/Finite_state_machinehttp://en.wikipedia.org/wiki/Finite_state_machine For more in-depth study refer to the text books for finite automata theory.