1 / 142

Specification

Specification. 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 L ogic-based notations Algebraic notations

issac
Télécharger la présentation

Specification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Specification Ch. 5

  2. 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 Ch. 5

  3. Specification • A broad term that means definition • Used at different stages of software development for different purposes • Generally, a statement of agreement (contract) between • producer and consumer of a service • implementer and user • All desirable qualities must be specified Ch. 5

  4. Uses of specification • Statement of user requirements • major failures occur because of misunderstandings between the producer and the user • "The hardest single part of building a softwarem system is deciding precisely what to build" (F. Brooks) Ch. 5

  5. 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 Ch. 5

  6. Uses of specification (cont.) • Statement of requirements for implementation • design process is a chain of specification (i.e., definition)–implementation–verification steps • requirements specificationrefers 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 Ch. 5

  7. 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 Ch. 5

  8. Specification qualities • Precise, clear, unambiguous • Consistent • Complete • internal completeness • external completeness • Incremental Ch. 5

  9. Clear, unambiguous, understandable • Example: specification fragment for a word-processor 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? Ch. 5

  10. 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 3rd? Ch. 5

  11. 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? Ch. 5

  12. Complete • Internal completeness • the specification must define any new concept or terminology that it uses • glossary helpful for this purpose • the specification must document all the needed requirements • difficulty: when should one stop? Ch. 5

  13. 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 in increments Ch. 5

  14. Classification of specification styles • Informal, semi-formal, formal • Operational • Behavior specification in terms of some abstract machine • Descriptive • Behavior described in terms of properties Ch. 5

  15. Example 1 • Specification of a geometric figure E: E 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 Ch. 5

  16. Ch. 5

  17. A descriptive specification • Geometric figure E is describe by the following equation ax2 + by2 + c = 0 where a, b, and c are suitable constants Ch. 5

  18. Another example “Let a be an array of n elements. Theresult 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.” OP “The result of sorting array a is an array b which is a permutation of a and is sorted.” DES Ch. 5

  19. How to verify a specification? • “Observe” dynamic behavior of specified system (simulation, prototyping, “testing” specs) • Analyze properties of the specified system • Analogy with traditional engineering • physical model of a bridge • mathematical model of a bridge Ch. 5

  20. 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 Ch. 5

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

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

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

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

  25. A library example Ch. 5

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

  27. 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. Ch. 5

  28. A refinement Ch. 5

  29. More refinement Ch. 5

  30. 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? Ch. 5

  31. 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 Ch. 5

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

  33. borrow book return book librarian customer library update UML use-case diagrams • Define functions on basis of actors and actions Ch. 5

  34. UML sequence diagrams • Describe how objects interact by exchanging messages • Provide a dynamic view Ch. 5

  35. UML collaboration diagrams • Give object interactions and their order • Equivalent to sequence diagrams Ch. 5

  36. 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) Ch. 5

  37. Example: a lamp Ch. 5

  38. Another example:a plant control system Ch. 5

  39. A refinement Ch. 5

  40. Classes of FSMs • Deterministic/nondeterministic • FSMs as recognizers • introduce final states • FSMs as transducers • introduce set of outputs • . . . Ch. 5

  41. FSMs as recognizers qf is a final state Ch. 5

  42. FSMs as recognizers Ch. 5

  43. Limitations • Finite memory • State explosion • Given a number of FSMs with k1, k2, … kn states, their composition is a FSM with k1 * k2 *… * kn. This growth is exponential with the number of FSMs, not linear (we would like it to be k1 + k2 +… + kn ) Ch. 5

  44. State explosion: an example Ch. 5

  45. The resulting FSM Ch. 5

  46. Petri nets A quadruple (P,T,F,W) P: places T: transitions (P, T are finite) F: flow relation (F  {PT}  {TP}) W: weight function (W: F  N – {0})Properties: (1) P  T = Ø (2) P  T  Ø (3)F  (P  T)  (T  P) (4) W: F  N-{0} Default value of W is 1 State defined by marking: M: P  N Ch. 5

  47. P P 1 2 t 1 t P 2 3 P P 4 5 t 4 t 3 P P 6 7 t 5 t 6 Graphical representation Ch. 5

  48. Semantics: dynamic evolution • Transition t is enabled iff • pt's input places, M(p)  W(<p,t>) • t fires: produces a new marking M’ in places that are either t's input or output places or both • if p is an input place: M'(p) = M(p) - W(<p,t>) • if p is an output place: M'(p) = M(p) + W(<t,p>) • if p is both an input and an output place: M'(p) = M(p) - W(<p,t>) + W(<t,p>) Ch. 5

  49. Nondeterminism • Any of the enabled transitions may fire • Model does not specify which fires, nor when it fires Ch. 5

  50. Modeling with Petri nets • Places represent distributed states • Transitions represent actions or events that may occur when system is in a certain state • They can occur as certain conditions hold on the states Ch. 5

More Related