CS445 CS645 ECE451 Software Requirements Specification and Analysis - PowerPoint PPT Presentation

1 / 75
About This Presentation

CS445 CS645 ECE451 Software Requirements Specification and Analysis


... shown that raw prose is ... This is hard stuff, eh! Pre true. Post. 13 ? Algebraic specification ... e.g., create an array of integers from an array ... – PowerPoint PPT presentation

Number of Views:98
Avg rating:3.0/5.0
Slides: 76
Provided by: michaelw1


Transcript and Presenter's Notes

Title: CS445 CS645 ECE451 Software Requirements Specification and Analysis

CS445 / CS645 / ECE451Software Requirements
Specification and Analysis
  • Lecture 13
  • Algebraic specification and SDL ADTs

  • Required (all in course pack)
  • Belina and Hogrefe, Section 6 (SDL ADTs)
  • Gannon, Purtilo, Zelkowitz (review of logic)
  • Sommerville
    (algebraic spec.)
  • Optional
  • SDL book, Chap. 8

Getting back to SDL
  • Recall that we declared simple variables at the
    process level
  • What if you need to use more interesting
    entities at this level,
  • e.g.,
  • character strings,
  • arrays and sets,
  • structs/records, and
  • objects with operations ?
  • Good news
  • SDL provides mechanisms for this, as do many
    other specification languages

dcl i Integer dcl done Boolean
SDL advanced data entities
  • SDL provides these data types for you
  • Boolean
  • Character, Charstring
  • Integer, Natural, Real
  • PId, Duration, Time
  • SDL also provides a way of building bigger data
    types from these using
  • A struct-like construct
  • for pure structure, i.e., no operations
  • Algebraic specification
  • for ADTs with operations has inheritance,
    generics, etc.
  • Building on predefined generators
  • e.g., for arrays, sets of XXX

Now wait just a minute here!
  • Didnt we agree that the golden rule of
    requirements specification is
  • What, not how
  • Wont you be arrested by the
  • requirements police if you include
  • code in a requirements specification?

Well ...
  • The real answer is that the boundary between
    requirements and design is always fuzzy.
  • The idea of a struct is pretty generic.
  • Most programming languages support them in
    roughly the same way so defining an SDL struct
    doesnt really overconstrain the specification
    too much.
  • We can appeal to formal mathematical intuition on
    ideas such as sets and sequences.
  • We can avoid writing code per se if we try
    using algebraic specification.

NEWTYPE PidPair STRUCT Caller, Callee
HockeyPlayer STRUCT goals, assists Integer
name Charstring ENDNEWTYPE HockeyPlayer /
Elsewhere ... / DCL mats HockeyPlayer /
assigning values to records / mats (. 5, 10,
Mats Sundin" .) / Use ! to select field / /
i.e. mats!goals /
Specifying types with operations
  • So what about those pesky operations?
  • How should we specify them?
  • Suppose we needed a stack of integers inside our
    SDL process, how would you specify it?
  • Lets pretend we havent heard of a stack before.
    That is, that we are ignoramuses about stacks.
  • I chose this example because stacks are common
    examples you will be familiar with, but in
    general we will be specifying ADTs with more
    interesting and specialized behaviour.

Strategy 1
  • How about just writing a prose specification?
  • A stack of ints supports three operations push,
    pop, and size.
  • Pushing adds an int to the stack.
  • Popping returns the most recently added element.
  • Size returns the number of elements.

Hidden slide
  • Problems
  • element vs int elegant variation
  • adds an int possible confusion
  • What are the precise signatures of the
  • What happens when you pop an empty stack?
  • Does return imply remove as well or just peek?
  • added element -gt how added?
  • Oh, push means add
  • size current ? total ? max size ?
  • most recently added but not yet deleted.
  • Are the stacks unbounded? Explicitly bounded?
    What happens on resource exhaustion?

More on prose specification
  • Formal studies have shown that raw prose is often
  • vague, verbose, poorly stated and poorly
  • good for motivation but often hard to analyze.
  • e.g., fast, good, easy to use, like
  • ambiguous
  • self-contradictory
  • impractical or impossible to implement
  • just plain wrong
  • Recall the previous joke about designing a house
    for inspiration.

Strategy 2
  • Careful and structured prose.
  • This is what most specifications look like at the
    macro level.
  • See next slide for overview of IEEE standard.
  • Your course project will be structured prose plus
    (semi) formally-defined diagrams.
  • How well does it work at the detailed level?
  • Lets redo our stack as a class exercise.

Hidden slide
  • Hard to get right, eh!
  • Had to put in lots of detail. Might as well go
    whole hog and encode formally in some way.

The requirements document
  • I. Introduction
  • A. System reference
  • B. Overall description
  • C. Software project constraints
  • II. Informal description
  • A. Information content representation
  • B. Information flow representation
  • 1. Data flow
  • 2. Control flow
  • III. Functional description
  • A. Functional partitioning
  • B. Functional description
  • 1. Processing narrative
  • 2. Restrictions/limitations
  • 3. Performance requirements
  • 4. Design constraints
  • 5. Supporting diagrams

The requirements document
  • C. Control description
  • 1. Control specification
  • 2. Design constraints
  • IV. Behavioural description
  • A. System states
  • B. Events and actions
  • V. Validation and criteria
  • A. Performance bounds
  • B. Classes of tests
  • C. Expected software response
  • D. Special considerations
  • VI. Bibliography
  • VII. Appendix
  • Adapted from IEEE specification and Pressman

Another example
  • Real sign on an escalator in the UK
  • Example due to Michael Jackson
  • Completely correct! Says all we need to know!
  • Any reasonable native speaker of English would
    immediately understand the intended meaning ...
    BUT what if we were not domain experts
  • Naively, you would expect these two statements to
    have analogous meanings.

Another example
  • Shut off the pump in the nuclear reactor if the
    water level reaches 100 metres for more than four
  • Possible interpretations
  • Reaches from above or below?
  • Replace reaches with remains above.
  • Stays exactly at 100m? mean above 100? median
  • 100m? minimum above 100?

  • Even careful prose is open to misinterpretation
  • but thats not to say we want all specification
    to be formal
  • Want a rigorous delineation of the requirements
  • unambiguous
  • concise
  • consistent
  • as complete as appropriate (all incompleteness is
    explicit and intended e.g., the kitchen must be
    big enough for my 1952 Gibson fridge, but we may
    decide to buy another smaller fridge)

Whither prose specification?
  • Q Does this mean the end of non-mathematical
  • A No!
  • Many requirements simply cant be expressed
  • Formal specification is difficult, very time
    consuming, tools only help you so much, many of
    the interesting questions are undecidable in the
    general case.
  • SDL and OMT qualify as formal in this context as
    their diagrams have a precise semantics

Strategy 3
  • Give an operational specification.
  • i.e., write some code as the specification.
  • Its formal (squint a bit)!
  • You know how to do it ?
  • Lots of supporting tools ?
  • compilers, etc.

public class IntStack int s int
top final int BIG 100 public
IntStack () s new intBIG
top -1 public void push (int i)
if (top lt s.length-1) top
stop i
// more to come
public int pop () int ans -1
if (top gt 0) ans stop
top-- return ans
public int size () return
top1 // end class IntStack
Hidden slide
  • Problems?
  • Overconstraining, implementation bias
  • Reader / implementor likely to be confused as to
    what is part of problem (what is required vs.
    what specifier happened to state)
  • Remember, this is a trivial example!
  • Must commit to representation and algorithmic
    strategies, which are not really problem space
  • Java ints are 4 bytes ... same with problem?
  • How to handle resource exhaustion? BIG array (and
    what BIG is) vs. linked list vs. java.util.Vector
    vs. java.util.Stack
  • Need to know Java API if we use java.util. is
    this a good thing to require of a specification?
  • Too much inessential detail if lots of
    algorithmic complexity its confusing.
  • Remember the mantra What, not how.

Another example
  • Specify an operation that searches an array of
    structs. Return index of struct whose key value
    matches sought key or -1 if no match found.
  • i.e., simple array search
  • Q How would you specify this operationally?

Hidden slide
  • Binary search Efficient, but hard to follow.
    Which algorithm? recursive vs. non-recursive? how
    bracket end points? easy to get wrong (Bentleys
  • Linear search simple but developer may believe
    this is the expected strategy or just may not
    bother to re-implement efficiently

Another example
  • Moral
  • Any implementation of this problem will require a
    detailed strategy that is unrelated to the
    essence of the problem.
  • This is true of most software systems, as we
    build em big and require that they run fast.
  • However, for some problems, an algorithmic-ish
    specification may be unavoidable, e.g.,
    calculating your income tax.
  • The logical specification of this problem is much
  • Return an appropriate index if one exists
    return -1 otherwise.

Strategy 4
  • Use some kind of formal logic!
  • Well look at several kinds, and spend a fair bit
    of time on this
  • Set theory, and predicate calculus / first-order
  • e.g., Z using pre / posts
  • Algebraic specification (general purpose)
  • Temporal logic (if system includes idea of time)
  • Exercise Given array A0..N, specify pre- and
    post-conditions for a procedure called Sort that
    will ensure that A will be sorted after Sort is

Hidden slide
Pre true Post
  • Should the inequality be lt or lt?
  • Except that this doesnt work is that the right
    formula for a permutation?
  • It is satisfied by picking one element from A and
    using that to fill A!
  • So add a mirror image reversing i and j does
    that work?
  • No! What if there are duplicates? The arities
    could be different and satisfy this formula
  • It does work if all values are unique!
  • This is hard stuff, eh!

Specifying more complex types
  • Using logic to describe data types
  • to describe packaging of data into a new data
    type, use mathematical structures such as pairs,
    tuples, sets, arrays, sequences
  • for a new data type
  • describe what an operation should do using
    pre/post conditions
  • relate the behaviour of the operations on the
    data to each other (algebraic specification)
  • In requirements specification, we describe
    properties of the operations, rather than
    implementations of the operations.
  • e.g., ordered collection of data rather than
    linked list

  • ADT Abstract Data Type Guttag 75
  • ADT sort (set of values) operators
  • An ADT provide an abstract view of data of that
    sort (think type). The operations are not
  • The values of a sort may be packaged values
    (e.g., records), but no particular representation
    is described.

Algebraic specification
  • Algebraic specification ADT axioms
  • But to be honest, I usually say ADT when
    referring to the whole package myself
  • An algebraic specification describes
  • name of the sort
  • signatures of operators (names, and domains and
    ranges of operators)
  • properties (axioms) of the operators usually as
    relationships between operators.
  • Its good practice to also have an informal
    description of the ADT in a comment.

SDL Specifying more complex types
  • What you can do in SDL
  • Describe packaging of data into a new data type
    as a record using STRUCT
  • Create a new data type using algebraic
  • can use inheritance
  • can create parameterized data types called
  • Build on the SDL predefined generators
  • e.g., create an array of integers from an array
  • SDL notes
  • Declarations of data types go in a text box with
    other declarations on an SDL diagram.
  • A data type is visible (i.e., can be used) in all
    descendent diagrams of the one where the data
    type is declared.

  • SDL uses an algebraic approach to specifying
  • The particular notation is from a language called
    ACT-ONE, but many specification languages use an
    almost identical approach
  • e.g., Larch, OBJ, LOTOS.
  • Algebraic specs are hard to learn how to write
    (and read)
  • But there is a zen to it having an
    understanding of logical and functional
    programming helps (Prolog, Scheme, Lisp)
  • Parts of an algebraic spec of a data type in SDL
  • Name of the ADT
  • Literals (operators with no arguments)
  • Signature (introduce operators and their types)
  • Axioms (equations of the form x y that specify
    the semantics of the operators)

push Integer, IntStack -gt IntStack
pop IntStack -gt IntStack top
IntStack -gt Integer isEmpty
IntStack -gt Boolean AXIOMS FOR ALL
s in IntStack ( FOR ALL i in Integer (
pop (EmptyStack) EmptyStack
pop (push (i,s)) s top
(EmptyStack) Error! top
(push(i,s)) i isEmpty
(EmptyStack) true isEmpty (push
(i,s)) false )) ENDNEWTYPE IntStack
Hidden slide
  • All stacks start out empty, and then have various
    operations performed on them.
  • new push 5 push 8 top
  • What is returned?
  • Lets encode this stack as a sequence of function
    calls on the IntStack ADT
  • top (push (8, push (5, ES)))
  • by axiom 4, the answer is 8!
  • new push 3 push 7 push 9 pop pop
  • What is the current state?
  • pop (pop (push (9, push (7, push (3, ES)))))
  • Applying axiom 2 to simplify
  • pop (pop (push (9, push (7, push (3, ES)))))
  • pop (push (7, push (3, ES)))
  • push (3, ES)

Avoiding implementation bias
  • Values of an ADT are expressed as sequences of
    operations on base constants or literals.
  • That is, a value, i.e., a representation, of an
    expression is the expression itself.
  • This is as free of a representation
    (implementation bias) as you can get, and since
    you have to write these expressions anyway in the
    code that uses the ADT, this representation does
    not constrain any implementation.
  • The axioms define values of expressions in terms
    of other expressions.

Some observations
  • We consider only the abstract behaviour of the
  • That is, we consider two stacks to be equivalent
    if any set of (well formed) operations applied to
    both will always yield the same result.
  • Any stacks history can be rewritten to remove
    all pushes and pops of elements no longer in the
  • Another way of saying this
  • Any stacks history can be written as an
    equivalent history with no pops.
  • Another way of saying this
  • Any stack can be generated by the EmptyStack
    literal plus calls to push.

Some observations
  • That is, we do not need any operator other than
    the literal EmptyStack and the function push to
    make stack values.
  • Any set of operators, e.g., the literal
    EmptyStack and the function push for the stack
    ADT, that can be used to build all values of the
    ADT is called a generator set.
  • The literal EmptyStack and the function push make
    a generator set for the stack ADT.
  • Yes, this does imply that we are only interested
    in the final state, and that is not always a
    reasonable assumption for all situations.
  • e.g., We might care about the real total number
    of pushes to track avg response time in a more
    real world scenario.

Canonical form
  • In general, there is no unique expression for an
    ADT value
  • push (9, push (7, push (3, ES)))
  • push (9, push (7, pop(push(5, push (3, ES) )) ))
  • push (9, push (7, pop(push(6,pop(push(5, push (3,
    ES) )))) ))
  • pop(push(5, push (9, push (7, push (3, ES))) ))
  • pop(push(6,pop(push(5, push (9, push (7, push (3,
    ES))) ))))
  • However, there may be a minimal length expression
    for a value, called the canonical term or trace
    or form of the expression.

Some observations
  • Note that our definition of IntStack mentions
    only a single special constant (EmptyStack) plus
  • NO data structure!
  • NO array/linked list/vector!
  • The semantics of the operations are given
    entirely by specifying how combinations of
    function calls return particular values.
  • Thus
  • we avoid overly constraining the specification of
    the operations by specifying their semantics
    implicitly, and
  • we avoid overly constraining the specification of
    the data representation similarly!

  • There is a significant cost
  • Algebraic specs are devilishly hard to write and
    read and maintain.
  • Tools can help somewhat, but the job is hard even
    with the best tools.
  • Its hard to tell if what youve written is
  • correct
  • what you intended to say
  • consistent (some tools help)
  • complete (i.e., says all its supposed to)
  • You often end up in a combinatorial explosion of
    cases and serious parenthesis blindness.

  • Can express specs of complicated ADTs up to
    beyond module level.
  • The literature on algebraic specs claims that it
    scales up well. This means that it is possible,
    not easy, to scale up to specs of large systems.
  • Has lots of use in specifying and formally
    verifying desired semantic properties of systems
    (e.g., security, functionality).
  • But its not useful for real-time systems without
    additional logical constructs.
  • Usually only done when system is safety-critical,
    or client is DoD, or just worth the effort
    because of heavy use (e.g., network protocols).
  • Usual approach
  • Formally specify (part of) system.
  • Prove program implements specification.
  • Prove properties using spec (not program).

Values, not variables
  • There is no modification of values in ADTs
    instead, operations make new values.
  • Just like 11 does not modify 1 it creates a new
    value, 2.
  • Each ADT operation returns a new ADT, it doesnt
    modify the old one.
  • Variables exist in SDL processes.
  • Values of these variables can be these values,
    these terms
  • s push (1, s)
  • The old value of the variable s is lost to the
    computation, to the process that contains s,
    although not to the ADT!
  • While the value of the variable s is changed, no
    value is modified.

Using types
  • Variables can have a type that is a type created
    through algebraic specification.
  • s IntStack
  • The possible values of the variable are the
  • A variable must be initialized to a literal
    before invoking operations on it.
  • s EmptyStack
  • . . .
  • s push (1, s)

  • A sort is a set of values
  • Think of them like types in programming languages
  • An ADT defines one or more sorts and operators on
    and to these sorts.
  • Values of a sort are
  • literals
  • terms (expressions using operators and

Axioms and generators
  • Observe the structure of the set of axioms.
  • Consider an axiom written as f (x) y as a
    definition of f .
  • We see that there are definitions of only the
    non-generator operators, pop, top, and isEmpty.
  • Moreover, to define each such non-generator
    operator, there is one definition applying the
    operator to an application of each generator.
  • A literal is considered an operator with no
  • Thus, there is one definition of pop applying
    it to EmptyStack and another applying it to an
    application of push.
  • Why are there no definitions of the generators?

Axioms and generators
  • If there were, they would be written as
  • FOR ALL s in IntStack (
  • FOR ALL i in Integer (
  • EmptyStack EmptyStack
  • push(i,s) push(i,s) ))
  • This comes out of the fact that we are using a
    canonical trace of a sequence of applications of
    operators as the representation of the value of
    the sequence of operators.
  • Thus, a sequence of applications of only
    generators is represented by itself.

Axioms and generators
  • A well-defined sequence of applications s
    containing non-generators is simplified by the
    axioms into a sequence of applications of only
    generators, that is taken as the representation
    of the value of s.
  • Thus, in a sense, in the axioms above, the left
    side is the trace and the right side is the
    value, and they are the same since the operators
    being defined are the generators.
  • But, note that these axioms are useless, because
    they do not help work our way to a canonical

A few words on generators / inductive proof /
specifying semantics
  • If you have a set S, and you want to prove that a
    property P holds for all members of S,
  • If S is finite and not too big, just prove P
    holds for each element
  • If S is large or infinite, find a way to
    characterize all members of S.
  • For ADTs, we know how to do this generators!
  • For example, any stack is either EmptyStack, or
    can be generated by a finite number of
    applications of the push operation.

Generators and structural induction
  • Recall mathematical induction
  • To prove a property P hold for all natural
    numbers, prove
  • P(0) holds
  • If P(N) holds, then P(N1)
  • This works because of the way in which the
    integers are defined formally
  • 0 is a natural number
  • If N is a natural number, then so is N1

Generators and structural induction
  • Similar rules of induction hold for the integers
    and rational numbers
  • 0 is an integer / rational
  • If N is an integer / rational, then so are N1
    and N-1
  • If N and K are rationals and K? 0, then N/K is a
  • This is because the naturals, integers, and
    rationals are all discrete structures
  • We wont discuss the reals, irrationals, complex
    numbers etc.

Generators and structural induction
  • The ADTs we are forming are also discrete
    structures. They consists of special constants
    (literals) and functions.
  • More formally, suppose we have a set S where
  • c1, c2, ck are constants in the set S
  • f1, f2, fn are functions whose range is S
  • Each fi may take a different / set of args,
    including other elts of S
  • And suppose that all members of S can be
    generated repeated applications of (1) and (2)
  • Then, if you want to prove a property hold for
    all elements of set S, you

Generators and structural induction
  • Prove P(ci) holds for i1..K, and
  • For each generator f, suppose that its arguments
    in S are
  • e1, e2, , eM
  • We need to show that if P(e1), P(e2), , P(eM)
    all hold,
  • then it must be the case that
  • P(f(e1, e2, eM))
  • also holds.
  • That is, each generator f preserves the property
  • Note that each f may also have arguments that
    are not of type S, but lets ignore them for

Generators and structural induction
  • Now lets turn our attention from proving
    properties to defining the semantics of
    non-generator operations.
  • Because generators can characterize all possible
    elements of the sort, we can define the semantics
    of the other operations by simple showing how
    they behave on the generators
  • How does each op act on the literals?
  • How does each op act on the generator functions?
  • and thats enough to show the complete
    semantics (meaning) of each operator!
  • Got it? Thats why the ADT operator definitions
    you have seen have this structure!

A generic process for defining ADTs
  • Step 1
  • Determine what operations and literals (special
    values) you need.
  • Specify signatures of operations.
  • Step 2
  • Categorize operations and literals into three
  • Generators A small set of operations that taken
    together can generate any value of the ADT.
  • e.g., Any stack can be generated by calls to only
    push plus EmptyStack.
  • Often these are adding / creative operations,
    but not always.

A generic process for defining ADTs
  • Extenders Any other operations that returns
    values of the ADT.
  • e.g., pop changes stacks
  • Observers Operations that DONT produce values
    of the ADT.
  • i.e., They take snapshots but dont change the
  • e.g., top, isEmpty
  • Step 3
  • Define result of applying non-generator
    operations after each generator operation.

push Integer, IntStack -gt IntStack
pop IntStack -gt IntStack top
IntStack -gt Integer isEmpty
IntStack -gt Boolean AXIOMS FOR ALL
s in IntStack ( FOR ALL i in Integer (
pop (EmptyStack) EmptyStack
pop (push (i,s)) s top
(EmptyStack) Error! top
(push(i,s)) i isEmpty
(EmptyStack) true isEmpty (push
(i,s)) false )) ENDNEWTYPE IntStack
Another example
EmptyStack CONSTANT MaxSizeInteger / Im not
sure this is legal, but you get the idea,
right? / OPERATORS push Integer,
BoundedIntStack -gt BoundedIntStack
pop BoundedIntStack -gt BoundedIntStack top
BoundedIntStack -gt Integer isEmpty
BoundedIntStack -gt Boolean isFull
BoundedIntStack -gt Boolean height
BoundedIntStack -gt Integer
AXIOMS MaxSize gt 0 AND FOR ALL s in
BoundedIntStack ( FOR ALL i in
Integer ( pop (EmptyStack)
EmptyStack pop (push (i,s))
IF isFull(s) THEN
pop(s) ELSE
s FI
top (EmptyStack) error!
top (push(i,s)) IF
isFull(s) THEN top(s)
isEmpty (EmptyStack) true
isEmpty (push (i,s))
IF isFull(s) THEN
isEmpty(s) ELSE
false FI
height (EmptyStack) 0
height (push (i,s)) IF
isFull(s) THEN height(s)
/ could say MaxSize /
height(s)1 FI
isFull (s) height(s)
BoundedIntStack example
  • Note that there are no definitions of the
    generators, including push, which has a boundary
    condition due to the upper bound on the size of a
  • This means that the dealing with the boundary
    condition must be written into each application
    of push as the operand of the second definition
    for each non-generator operator.
  • Hence, each such definition has a conditional
    on the right hand side separating it into two
    cases, one for pushing into a full stack, and one
    for pushing into a non-full stack.

BoundedIntStack example
  • If we were to have a definition for push it
    would look like
  • FOR ALL s in IntStack (
  • FOR ALL i in Integer (
  • push(i,s)
  • IF isFull(s) THEN
  • s
  • ELSE
  • / knowing that the
  • stack isnt full /
  • push(i,s)
  • FI
  • Again, note that this axiom is useless, because
    it does not help work our way to a canonical
    expression, unless all stacks are full.

Another example
NEWTYPE IntQueue LITERALS EmptyQ / generator
/ OPERATORS enQ IntQueue, Integer -gt
IntQueue / generator / deQ IntQueue
-gt IntQueue front IntQueue -gt Integer
isEmpty IntQueue -gt Boolean / more to
come /
AXIOMS FOR ALL q in IntQueue ( FOR
ALL i in Integer ( deQ (EmptyQ)
EmptyQ deQ (enQ (q,i))
IF q EmptyQ THEN
enQ (deQ (q), i) FI
front (EmptyQ) error! front
(enQ(q,i)) IF qEmptyQ THEN
front (q) FI
isEmpty (EmptyQ) true isEmpty
(enQ (q,i)) false )) ENDNEWTYPE
Hidden slide
  • deQ(enQ(enQ(enQ(EmptyQ,5),3),2)) / deQ(5,3,2) /
  • should yield
  • enQ(enQ(EmptyQ,3),2) / 3,2 /
  • OK. Lets see!
  • deQ(enQ(enQ(enQ(EmptyQ,5),3), 2))
  • enQ(deQ(enQ(enQ(EmptyQ,5),3) ),2)
  • enQ( deQ(enQ(enQ(EmptyQ,5), 3)) ,2)
  • enQ( enQ(deQ(enQ(EmptyQ,5) ),3) ,2)
  • enQ( enQ( deQ(enQ(EmptyQ, 5)) ,3) ,2)
  • enQ( enQ( EmptyQ ,3) ,2)
  • enQ(enQ(EmptyQ,3),2)
  • This is what we wanted.

An exercise
insert Integer, IntSet -gt IntSet delete
IntSet, Integer -gt IntSet isMember IntSet,
Integer -gt Boolean isEmpty IntSet -gt
Boolean AXIOMS / Lets define the axioms
together / ENDNEWTYPE
Hidden slide
i, j in Integer ( delete (EmptySet,
j) EmptySet delete (insert (i,s),
j) IF ij THEN delete (s, j)
ELSE insert(i,delete(s,j))
FI isMember (EmptySet, j)
false isMember (insert(i,s), j)
IF ij THEN true
ELSE isMember (s, j) FI isEmpty
(EmptySet) true isEmpty (insert
(i,s)) false )) ENDNEWTYPE
Inheritance of ADTs
  • We can extend existing ADTs using inheritance
    (SDL-style) to add new features
  • Can also change names of operations
  • Bonus question Is this a good use of
    inheritance? ?
  • Lets add operations for set union and
    intersection to our Set ADT

(insert, inismember) / or OPERATORS all
/ ADDING / could add literals too /
OPERATORS union IntSet, IntSet -gt
IntSet intersect IntSet, IntSet -gt
IntSet AXIOMS /GeneratorsEmptySet,insert/
FOR ALL s, t in IntSet ( FOR ALL
i, j in Integer ( union (EmptySet, t)
t union (insert (i, s), t)
insert (i, union (s,t))
intersect (EmptySet, t) EmptySet
intersect (insert (i, s), t)
IF isMember (t, i) THEN
insert (i, intersect (s, t)) ELSE
intersect (s, t) FI )) ENDNEWTYPE
SDL ADT inheritance
  • With inheritance, the child sort inherits all
    values (i.e., all literals), some or all
    operators, and all axioms.
  • The ADDING clause can introduce new literals, new
    operators, and new axioms.
  • There was a small cheat here, using the fact that
    union and intersection are commutative, and only
    one of the operands was expanded into its
    constructive forms.
  • Some algebraic notations allow you to state
    explicitly that an operation is commutative, thus
    allowing you to get away with expanding only one
    of the operands.
  • Otherwise, you would have to expand both
    operands, to demonstrate commutativity.
  • If the operation were not commutative, you would
    have to expand both operands in all combinations.

Generator ADTs
  • What if we want sets of Ints, Reals, Pids, etc.?
  • Could just clone n hack repeatedly.
  • OO solution use generics.
  • Java 1.5 has generics
  • C implements generics using templates
  • SDL supports parameterized ADTs called
  • Unfortunate overloading of term, alas.
  • A generator type needs to be filled in to be

EmptySet OPERATORS insert Set, Element -gt
Set delete Set, Element -gt Set
isEmpty Set -gt Boolean isMember Set,
Element -gt Boolean AXIOMS FOR ALL s, t in
Set ( FOR ALL e, f in Element (
.... / as before, but
using e/f for i/j / )) ENDGENERATOR
Generic (type-parameterized) ADTs
Range) LITERALS Empty OPERATORS update
Function, Domain, Range -gt Function remove
Function, Domain -gt Function defined
Function, Domain -gt Boolean apply Function,
Domain -gt Range / more to come /
AXIOMS / Empty and update are constructors /
FOR ALL f IN Function ( FOR ALL d, d1, d2 IN
Domain ( FOR ALL r IN Range ( remove
(Empty,d) Empty remove
(update(f,d1,r), d2) IF d1d2 THEN
remove(f,d2) ELSE update (remove
(f,d2),d1,r) FI defined (Empty,d)
false defined (update (f,d1,r),d2)
IF d1d2 THEN true ELSE
defined (f,d2) FI apply (Empty,d)
error! apply (update (f,d1,r),d2)
IF d1d2 THEN r ELSE apply
(f,d2) FI ))) ENDGENERATOR Function
NEWTYPE MapTable Function(Integer,Integer) ADDING
OPERATORS invapply MapTable, Integer
-gt Integer AXIOMS FOR ALL m IN
MapTable ( FOR ALL d, r, r1, r2 IN
Integer ( invapply(Empty, r)
error! invapply(update(m,d,r1), r2)
IF r1r2 THEN d
ELSE invapply(m, r2) FI
)) ENDNEWTYPE MapTable / elsewhere ... / DCL
Calls MapTable, Callee MapTable
  • Exercise Make invapply return a set.
  • Left to student as exam practice ?

(No Transcript)
(No Transcript)
Predefined SDL generators
GENERATOR Array / unbounded array of Element /
Make! Element -gt Array / make an
(unbounded) array of elements / Modify!
Array, Index, Element -gt Array / update one
item in array / Extract! Array, Index -gt
Element / read one value of an item
/ AXIOMS / Study question / ENDGENERATOR
Predefined SDL generators
GENERATOR Powerset / sets of any type /
(TYPE Element) / poor choice of name! / LITERAL
Empty OPERATORS IN Element, Powerset -gt
Boolean / is element in the set? /
Incl Element, Powerset -gt Powerset /
include element in the set / Del Element,
Powerset -gt Powerset / delete element in
the set / lt Powerset, Powerset -gt
Boolean / is first a proper subset of
second? / gt Powerset, Powerset -gt
Boolean / is second a proper subset of
first? / / more to come /
Predefined SDL generators
/ see, I told you / lt
Powerset, Powerset -gt Boolean / is first a
subset of second? / gt Powerset,
Powerset -gt Boolean / is second a subset of
first? / AND Powerset, Powerset -gt
Powerset / intersection of sets /
OR Powerset, Powerset -gt Powerset /
union of sets / AXIOMS / Study question
Predefined SDL generators
GENERATOR String / unbounded seq of Element /
MkString Element -gt String / make a
string from an element / Length String -gt
Integer / number of elements in string /
First String -gt Element / first element
in string / Last String -gt Element /
last element in string / // String,
String -gt String / concatenation /
/ more to come /
Predefined SDL generators
Extract! String, Integer -gt Element /
get indexed item from string / Modify!
String, Integer, Element -gt String / modify
one item in string / Substring String,
Integer, Integer -gt String / make substring
// AXIOMS / Study question / ENDGENERATOR
An example of use
NEWTYPE PidPair STRUCT Caller, Callee
(Integer, PidPair) ENDNEWTYPE
Are ADTs executable?
  • Strictly speaking, no they are not.
  • In general, legal ADT definitions do not have an
    executable semantics
  • But if you write your specifications in a
    particular (constrained) way, it is possible to
    animate the ADTs, i.e., to execute them.
  • Some tools do this, but our SDL tool does not.
  • So if you include an ADT in your model, it will
    not be executable.

SDL ADTs and the SRS
  • Its likely that you can get away without
    defining your own ADTs from scratch in the
  • But it is excellent exam material ?
  • You will need some ADTs for the SRS, but you can
    probably get what you need from
  • the generic ADTs
  • String, Array, Powerset
  • the predefined SDL types
  • Boolean, Character, Charstring, Integer, Natural,
    Real, PId, Duration, Time

CS445 / CS645 / ECE451Software Requirements
Specification and Analysis
  • Lecture 13
  • Algebraic specification and SDL ADTs
Write a Comment
User Comments (0)
About PowerShow.com