Transcript Specification
Specification
Ch. 5 1
Outline
• Discussion of the term "specification" • Types of specifications – operational – Z • 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 Ch. 5 2
Specification
• A broad term that means What to do versus definition How to do it that emphasizes on – 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 Ch. 5 3
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) Ch. 5 4
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.
Ch. 5 5
Uses of specification (cont.)
• Statement of requirements for implementation – Software Development process is a chain of: Specification–Implementation–Verification steps • Requirements specification behavior refers to definition of external • – design specification must be verified against it Design specification architecture refers to definition of the software – code must be verified against it Ch. 5 6
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 7
Specification qualities • Precise
,
clear
,
unambiguous
• Consistent • Complete – internal – external completeness completeness • Incremental Ch. 5 8
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?
Ch. 5 9
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 ?
Ch. 5 10
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 11
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?
Ch. 5 12
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 Ch. 5 13
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.
Ch. 5 14
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 Ch. 5 15
P 1 P Ch. 5 16
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 Ch. 5 17
Another example:
Sorting an array of elements OP “Let a be an array of n elements. The result of its sorting is an array b b of n elements such that the first element of 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 removed.
” a element; and so on until all by removing its minimum n elements of a have been DES “The result of sorting array a permutation of a is an array b and is sorted.” which is a Ch. 5 18
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 Ch. 5 19
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 20
Graphical notation
– – – – bubbles represent functions arcs represent data flows open boxes represent persistent store closed boxes represent I/O interaction The function symbol The data flow symbol The data store symbol The input device symbol The output device symbol Ch. 5 21
Example
b a d * c + specifies evaluation of (a + b) * (c + a * d) * Ch. 5 22
A construction “method” (1)
1. Start from the “context” diagram Input 1 Input 2 Input n
...
information system
...
Output 1 Output 2 Output m Ch. 5 23
A construction “method” (2)
2. Proceed by refinements until you reach “elementary” functions (preserve balancing) A I O I A1 H K A3 A2 J A4 M N P A5 R Q A6 S A7 O K K2 B1 Ag T K1 B2 K3 B3 K4 Ch. 5 B4 M N 24
A library example
Boo k Sh elv es Boo k request by the us er Title and auth or of requ es ted book; name of the user Author Boo k List o f Au thors Boo k reception Get a book Title Boo k title; us er name List o f titles List o f topics Title List o f boo ks borro wed Search b y top ics Top ic Top ic requ es t by the us er Top ic List o f titles referrin g to the topic Dis play of the list o f titles Ch. 5 25
Book
Refinement of “Get a book”
Shelves Author Get the book List of Authors Title Find book position List of titles Title and author of requested book; name of the us er Book request by the us er
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.
Nurse Patient Report Reques t Cli nical Data Report Patient Monit oring Nurse Alarm Recen t data Data for report Persistent data Ch. 5 27
Recent Data Upda te archive
A refinement
Patient archive Report Reques t Da ta for Report Gene rate Report Report Forma tted data Central Monit oring Alarm Nurse Nurse Limits Limits f or patient Patient data Local Monit oring Cli nical Data Patient Ch. 5 28
More refinement
Limits Pressure , puls e… Check limi t violations Pressure Patient data Temperature decode Pulse Result Forma t data Date Time Forma tted data clock produce message alarm Ch. 5 29
A B C
An evaluation of DFDs (1)
• Easy to read, but … • Informal semantics – How to define leaf functions?
– Inherent ambiguities D E F • Outputs from A, B, C are all needed?
• Outputs for E and F are produced at the same time?
Ch. 5 30
An evaluation of DFDs (2)
• Control information is absent A B 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 31
Formalization/extensions
• There have been attempts to DFDs
formalize
• There have been attempts to
extend
DFDs (e.g., for real-time systems) d1 d2 . . .
dn Trigger Ch. 5 32
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.
Ch. 5 33
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 Ch. 5 34
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. Ch. 5 35
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 librarian customer library update Ch. 5 36
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.
Actor Association Base use case Place order <
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 Customer Librarian Catalogue member card + book request book borrowed Ch. 5 membership OK book request book available
time
38
Ch. 5 39
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.
Customer 2: membership OK 1: member card + book request 5: book borrowed Librarian 3: book request 4: book available Catalogue Ch. 5 40
Ch. 5 41
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 ( d can be a partial function) a Q q 1 a b q 0 c b q 3 Ch. 5 q 2 42
On
Example: a lamp
Push switch Off Push switch Ch. 5 43
Another example: a plant control system
High-pressure alarm High-temperature alarm On Off Restart Ch. 5 44
Press ure signal
A refinement
Temperature signal Pressure action Succ essful rec overy Unsucces sful rec overy Normal Normal Succ essful rec overy Unsucces sful rec overy Temperature signal Temperature ac tion Press ure signal Off Off Ch. 5 45
Classes of FSMs
• Deterministic/nondeterministic • FSMs as recognizers – introduce final states • FSMs as transducers – introduce set of outputs • . . .
Ch. 5 46
FSMs as recognizers
q 0 b e q 1 e q 2 g q 3 i q 4 n d q 5 n q f is a final state q 6 Ch. 5 q f 47
FSMs as recognizers
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 k 2 1 * *… * 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 ) Ch. 5 49
State explosion: an example
produce Producer p 1 p 2 deposit get Consumer c 1 c 2 consume deposit deposit Storage 0 1 2 get 50
consume
The resulting FSM
w rite 1 w rite 1 1 consume consume produce <0, p ,c > 2 1 <0, p ,c > 1 2 read produce read consume <0, p , c > 2 2 w rite produce 2 1 read 1 2 produce consume read w rite 2 2 Ch. 5 produce 2 1 1 1 2 produce consume 2 2 51
FSM simulator
Ch. 5 52
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_machine • For more in-depth study refer to the text books for finite automata theory.
Ch. 5 53