1 / 102

specification

Ch. 5. 2. Outline. Discussion of the term "specification"Types of specificationsoperational Data Flow Diagrams(Some) UML diagramsFinite State MachinesPetri Nets descriptiveEntity Relationship DiagramsLogic-based notationsAlgebraic notationsLanguages for modular specifications StatechartsZ.

Mia_John
Download Presentation

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

    2. Ch. 5 2

    3. 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

    4. 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)

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

    6. 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 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. 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

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

    9. Ch. 5 9 Clear, unambiguous, understandable Example: specification fragment for a word-processor

    10. Ch. 5 10 Precise, unambiguous, clear Another example (from a real safety-critical system)

    11. Ch. 5 11 Consistent Example: specification fragment for a word-processor

    12. 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?

    13. 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

    14. 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

    15. Ch. 5 15 Example 1 Specification of a geometric figure E:

    16. Ch. 5 16

    17. 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

    18. Ch. 5 18 Another example “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.”

    19. 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

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

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

    22. Ch. 5 22 Example

    23. Ch. 5 23 A construction “method” (1)

    24. Ch. 5 24 A construction “method” (2)

    25. Ch. 5 25 A library example

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

    27. Ch. 5 27 Patient monitoring systems

    28. Ch. 5 28 A refinement

    29. Ch. 5 29 More refinement

    30. Ch. 5 30 An evaluation of DFDs (1) Easy to read, but … Informal semantics How to define leaf functions? Inherent ambiguities

    31. Ch. 5 31 An evaluation of DFDs (2) Control information is absent

    32. 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)

    33. Ch. 5 33 UML use-case diagrams Define functions on basis of actors and actions

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

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

    36. Ch. 5 36 Finite state machines (FSMs) Can specify control flow aspects Defined as

    37. Ch. 5 37 Example: a lamp

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

    39. Ch. 5 39 A refinement

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

    41. Ch. 5 41 FSMs as recognizers

    42. Ch. 5 42 FSMs as recognizers

    43. 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 )

    44. Ch. 5 44 State explosion: an example

    45. Ch. 5 45 The resulting FSM

    46. 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

    47. Ch. 5 47

    48. 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>)

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

    50. 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

    51. Ch. 5 51

    52. Ch. 5 52 Common cases Concurrency two transitions are enabled to fire in a given state, and the firing of one does nor prevent the other from firing see t1 and t2 in case (a) Conflict two transitions are enabled to fire in a given state, but the firing of one prevents the other from firing see t3 and t4 in case (d) place P3 models a shared resource between two processes no policy exists to resolve conflicts (known as unfair scheduling) a process may never get a resource (starvation)

    53. Ch. 5 53 How to avoid starvation

    54. Ch. 5 54 A conflict-free net

    55. Ch. 5 55 A deadlock-free net

    56. Ch. 5 56 A case of partial starvation

    57. Ch. 5 57 Producer-consumer example (1)

    58. Ch. 5 58 Producer-consumer example (2)

    59. Ch. 5 59 Limitations and extensions

    60. Ch. 5 60 Extension 1assigning values to tokens Transitions have associated predicates and functions Predicate refers to values of tokens in input places selected for firing Functions define values of tokens produced in output places

    61. Ch. 5 61 Example

    62. Ch. 5 62 Extension 2specifying priorities A priority function pri from transitions to natural numbers: pri: T ? N When several transitions are enabled, only the ones with maximum priority are allowed to fire Among them, the one to fire is chosen nondeterministically

    63. Ch. 5 63 Extension 3Timed Petri nets A pair of constants <tmin, tmax> is associated with each transition Once a transition is enabled, it must wait for at least tmin to elapse before it can fire If enabled, it must fire before tmax has elapsed, unless it is disabled by the firing of another transition before tmax

    64. Ch. 5 64 Examplecombining priorities and time

    65. Ch. 5 65

    66. Ch. 5 66

    67. Ch. 5 67 Case study An n elevator system to be installed in a building with m floors Natural language specs contain several ambiguities Formal specification using PNs removes ambiguities Specification will be provided in a stepwise fashion Will use modules, each encapsulating fragments of PNs which describe certain system components

    68. Ch. 5 68 From informal specs… “The illumination is cancelled when the elevator visits the floor and is either moving in the desired direction, or ...” 2 different interpretations (case of up call) switch off as the elevator arrives at the floor from below (obvious restrictions for 1st and last floor) switch off after the elevators starts moving up in practice you may observe the two cases!

    69. Ch. 5 69 …more analysis of informal specs “The algorithm to decide which to service first should minimize the waiting time for both requests.” what does this mean? in no other way can you satisfy either request in a shorter time but minimizing for one may require longer for the other the sum of both is minimal why the sum?

    70. Ch. 5 70 Initial sketch of movement

    71. Ch. 5 71 Button module

    72. Ch. 5 72 Elevator position (sketch)

    73. Ch. 5 73

    74. Ch. 5 74 Switch internal button off

    75. Ch. 5 75 Switch external button off

    76. Ch. 5 76 Specifying policy

    77. Ch. 5 77 A general scheduler

    78. Ch. 5 78 Declarative specifications ER diagrams: semiformal specs Logic specifications Algebraic specifications

    79. Ch. 5 79 ER diagrams Often used as a complement to DFD to describe conceptual data models Based on entities, relationships, attributes They are the ancestors of class diagrams in UML

    80. Ch. 5 80 Example

    81. Ch. 5 81 Relations Relations can be partial They can be annotated to define one to one one to many many to one many to many

    82. Ch. 5 82 Non binary relations

    83. Ch. 5 83 Logic specifications Examples of first-order theory (FOT) formulas: x > y and y > z implies x > z x = y ? y = x for all x, y, z (x > y and y > z implies x > z) x + 1 < x – 1 for all x (exists y (y = x + z)) x > 3 or x < -6

    84. Ch. 5 84 Specifying complete programs A property, or requirement, for P is specified as a formula of the type

    85. Ch. 5 85 Example Program to compute greatest common divisor

    86. Ch. 5 86 Specifying procedures

    87. Ch. 5 87 Specifying classes Invariant predicates and pre/post conditions for each method Example of invariant specifying an array implementing ADT set

    88. Ch. 5 88 Specifying non-terminating behaviors Example: producer+consumer+buffer Invariant specifies that whatever has been produced is the concatenation of what has been taken from the buffer and what is kept in the buffer

    89. Ch. 5 89 A case-study using logic specifications We outline the elevator example Elementary predicates at (E, F, T) E is at floor F at time T start (E, F, T, up) E left floor F at time T moving up Rules (at (E, F, T) and on (EB, F1, T) and F1 > F) implies start (E, F, T, up)

    90. Ch. 5 90 States and events Elementary predicates are partitioned into states, having non-null duration standing(E, F, T1, T2) assumption: closed at left, open at right events instantaneous (caused state change occurs at same time) represented by predicates that hold only at a particular time instant arrived (E, F, T) For simplicity, we assume zero decision time no simultaneous events

    91. Ch. 5 91 Events (1) arrival (E, F, T) E in [1..n], F in [1..m], T ? t0, (t0 initial time) does not say if it will stop or will proceed, nor where it comes from departure(E, F, D, T) E in [1..n], F in [1..m], D in {up, down}, T ? t0 stop (E, F, T) E in [1..n], F in [1.. m], T ? t0 specifies stop to serve an internal or external request

    92. Ch. 5 92 Events (2) new_list (E, L, T) E in [1..n], L in [1.. m]*, T ? t0 L is the list of floors to visit associated with elevator (scheduling is performed by the control component of the system) call(F, D, T) external call (with restriction for 1, N) request(E, F, T) internal reservation

    93. Ch. 5 93 States moving (E, F, D, T1, T2) standing (E, F, T1, T2) list (E, L, T1, T2) We implicitly assume that state predicates hold for any sub- interval (i.e., the rules that describe this are assumed to be automatically added) Nothing prevents that it holds for larger interval

    94. Ch. 5 94 Rules relating events and states

    95. Ch. 5 95

    96. Ch. 5 96

    97. Ch. 5 97

    98. Ch. 5 98

    99. Ch. 5 99 Control rules

    100. Ch. 5 100

    101. Ch. 5 101

    102. Ch. 5 102 Verifying specifications The system can be simulated by providing a state (set of facts) and using rules to make deductions standing (2, 3, 5, 7) elevator 2 at floor 3 at least from instant 5 to 7 list(2, empty, 5, 7) request(2, 8, 7) new_list(2, {8}, 7) ? (excluding other events) departure (2, up, 7 + Dts) arrival (2, 8, 7 + Dts + Dta *(8-3))

    103. Ch. 5 103 Verifying specifications Properties can be stated and proved via deductions new_list (E, L, T) and F ? L impliesnew_list (E, L1, T1) and F ? L1 and T1 > T2 (all requests are served eventually)

    104. Ch. 5 104 Descriptive specs The system and its properties are described in the same language Proving properties, however, cannot be fully mechanized for most languages

    105. Ch. 5 105 Algebraic specifications Define a heterogeneous algebra Heterogeneous = more than 1 set Especially useful to specify ADTs

    106. Ch. 5 106 Example A system for strings, with operations for creating new, empty strings (operation new) concatenating strings (operation append) adding a new character at the end of a string (operation add) checking the length of a given string (operation length) checking whether a string is empty (operation isEmpty) checking whether two strings are equal (operation equal)

    107. Ch. 5 107 Specification: syntax

    108. Ch. 5 108 Specification: properties

    109. Ch. 5 109 Example: editor newF creates a new, empty file isEmptyF states whether a file is empty addF adds a string of characters to the end of a file insertF inserts a string at a given position of a file (the rest of the file will be rewritten just after the inserted string) appendF concatenates two files

    110. Ch. 5 110

    111. Ch. 5 111

    112. Ch. 5 112 Requirements for a notation Ability to support separation of concerns e.g., separate functional specs from performance specs user-interface specs … Support different views

    113. Ch. 5 113 Example of viewsdocument production

    114. Ch. 5 114 Control flow view (2)

    115. Ch. 5 115 UML notations Class diagrams describe static architecture in terms of classes and associations dynamic evolution can be described via Statecharts (see later) Activity diagrams describe sequential and parallel composition of method executions, and synchronization

    116. Ch. 5 116 An activity diagram

    117. Ch. 5 117 Building modular specifications The case of algebraic specifications How to combine algebras taken from a library How to organize them in a hierarchy

    118. Ch. 5 118 Algebras used by StringSpec

    119. Ch. 5 119 Algebras used by StringSpec (cont.)

    120. Ch. 5 120 StringSpec revisited

    121. Ch. 5 121 Incremental specification of an ADT We want to target stacks, queues, sets We start from "container" and then progressively specialize it We introduce another structuring clause assumes defines inheritance relation among algebras

    122. Ch. 5 122 Container algebra

    123. Ch. 5 123 Table specializes Container

    124. Ch. 5 124 Queue specializes Container

    125. Ch. 5 125 A graphical view

    126. Ch. 5 126 A richer hierarchy

    127. Ch. 5 127 From specs to an implementation Algebraic spec language described so far is based on the "Larch shared language" Several "interface languages" are available to help transitioning to an implementation Larch/C++, Larch/Pascal

    128. Ch. 5 128 Using Larch/Pascal for StringSpec

    129. Ch. 5 129 Modularizing finite state machines Statecharts do that They have been incorporated in UML They provide the notions of superstate state decomposition

    130. Ch. 5 130 Sequential decomposition--chemical plant control example--

    131. Ch. 5 131 Parallel decomposition

    132. Ch. 5 132 Object state diagram using Statecharts

    133. Ch. 5 133 Modularizing logic specifications: Z System specified by describing state space, using Z schemas Properties of state space described by invariant predicates predicates written in first-order logic Operations define state transformations

    134. Ch. 5 134 The elevator example in Z

    135. Ch. 5 135 Complete state spaceattempt #1

    136. Ch. 5 136 Complete state spaceattempt #2

    137. Ch. 5 137 Complete state spacefinal

    138. Ch. 5 138

    139. Ch. 5 139

    140. Ch. 5 140 Specifications for the end-user Specs should be used as common reference for producer and user They help removing ambiguity, incompleteness, … Can they be understood by end-user? They can be the starting point for a prototype They can support some form of animation (e.g., see Petri nets)

    141. Ch. 5 141 Conclusions (1) Specifications describe what the users need from a system (requirements specification) the design of a software system (design and architecture specification) the features offered by a system (functional specification) the performance characteristics of a system (performance specification) the external behavior of a module (module interface specification) the internal structure of a module (internal structural specification)

    142. Ch. 5 142 Conclusions (2) Descriptions are given via suitable notations There is no “ideal” notation They must be modular They support communication and interaction between designers and users

More Related