F. USING AN IMPERATIVE DEFINITION, SPECIFY THE ABSTRACT DATA TYPE FOR A SOFTWARE STACK
1. Explanation of how to specify an abstract data type using the example of the software stack
1.1. Introduction to the formal specification, types of formal specification languages a) Introduction to the formal specification:
In software engineering, highly comprehensive descriptions are referred to as 'formal specifications' (Nissanke, 2012). Formal specifications are also a method of communication, therefore they must be clear and short their vocabulary, syntax, and semantics are formally defined.
In other words, formal specification is the translation of a non-mathematical clarification (diagrams, tables, English text) into a formal specification language with a brief explanation of the high-level behaviour and properties of a system. They must utilize an agreed-upon language
that everyone uses and understands. It’s used to describe external behaviour without describing or constraining the implementation of software.
b) Types of formal specification languages
Axiomatic Specifications
Use a number of stateless functions, each with its own set of pre- and post-conditions. Pre- and post-conditions are predicates over the inputs and outputs of a function. A predicate is a true or false Boolean statement with variables that are the parameters of the function being stated.
Stages of axiomatic specification of a function:
Determine the range of input parameters across which the function is expected to perform successfully. As a condition, provide the constraints on the input parameters.
Define a predicate that defines a condition that must hold on the function's output if it operates appropriately.
Determine what modifications (if any) are made to the function's input/output parameters. (Note: no parameters would be updated in a strictly mathematical function. However, some programming languages alter parameters through a call by name or call by reference.)
Combine these into pre- and post-conditions for the function.
VDM
VDM is an abbreviation for "The Vienna Development Method," which is a set of methodologies for the formal specification and development of computing systems (Fuchs, 1992). It consists of a specification language called VDM-SL; rules for data and operation refinement that allow one to establish links between abstract requirements specifications and detailed design specifications down to the level of code; and a proof theory in which rigorous arguments about the properties of specified systems and the correctness of design decisions can be conducted.
1.2. Describe what are Pre-condition, Post-condition and error-condition
a) Pre-condition: A precondition could be understood as a condition that determines what has to be true and after that, the operation could be executed. In other words, the operation could not be executed in case the precondition is false. The precondition commonly represents the expectation of the operation’s argument or the state of objects that the operation may use.
b) Post-condition: Like a precondition, a postcondition also is a condition but this one determines what would be true when the operation completes this task. Simply put, when the precondition is true and the operation completes the task, the postcondition is ensured to be true.
c) Error-condition: error condition is also a condition that indicates the case that the program comes wrong or brings the program to an error state. For example, simulating an error condition by trying to open an unavailable file.
1.3. Specify Stack’s operations using this formal specification language Stack’s Operations:
Note:
Limited_capacity: max capacity of stack – integer
Stack Q
a) Creator operation – Stack(Limited_capacity int) constructor:
Argument/entry: Limited_capacity -> integer;
Result/return: Q (a new stack) Pre-condition: Limited_capacity > 0 Post-condition: Q -> declared and empty
Size = 0
Capacity = Limited_capacity Error-condition: no
b) Push operation – Push(T Value p): Insert Value into stack Q Note
T datatype
p (inserted element) Argument/entry: Value -> T;
Result/return: S -> new size, new element Pre-condition: p’s type == Q type
p != null
size < Limited_capacity Post-condition: size -> size +1,
top -> p
Error-condition: size >= Limited_capacity
c) Pop operation – T pop(): delete and return top element in Q Note
T datatype
D output/deleted element
Argument/entry: no Result/return: D
Pre-condition: isEmpty() -> false, top -> D
Post-condition: size -> size -1 top != D
Error-condition: isEmpty()-> true top != D || top -> null
d) PeekTop operation – T peekTop(): return the top element of Q Note:
T datatype
O output/return element Argument/entry: no
Result/return: O
Pre-condition: isEmpty() -> false, top -> O
Post-condition: top -> O, size -> size
Error-condition: isEmpty()-> true top != D || top -> null
e) Size Operation – int Size(): return the size of Q Note
s return number Argument/entry: no Result/return: s Pre-condition: s -> size Post-condition: size -> size
Error-condition: s != size
f) isEmpty() – boolean isEmpty(): return true or false based on size of Q Note
b return boolean Argument/entry: no Result/return: b Pre-condition: no
Post-condition: true if size =0, false if size > 0
Error-condition: no
g) deleteStack() – deleteStack(): delete the stack Q – other operation Argument/entry: no
Result/return: no
Pre-condition: Q -> defined
Post-condition: Q -> not existed or undefined
Error-condition: Q -> undefined before deleteStack() called.