Algebraic Specification

1
Algebraic Specification

• Marija Rakic
• Roshanak Roshandel

2
(No Transcript)
3
OBJ3

• Entities
• Objects encapsulates executable code
• Theories defines properties that may (or may
  not) be satisfied by another object or theory
• Views bindings of entities declared in some
  theory to entities in some other module, as well
  as an assertion that the other module satisfies
  the properties declared in the theory

OBJ program is conceptually a graph of modules
4
OBJ3

• Objects
• Strong sorting and subsorts
• Operation and Expression syntax
• Equations and Semantics
• Operational Semantics is Reduction
• Denotational Semantics
• Exceptions
• Attributes
• Order of evaluation
• Propositional calculus

5
Object

• Obj BITS is
• Endo.
• Sorting same as types
• Unsorted logic too permissive
• First-name(not(age(3false))) iff
  2(birthplace(temperature(329))
• Sorts in OBJ -gt OSA (Order Sorted Algebra)
• sorts (SortIdList). -gt sorts Nat Int Rat.
• subsort(SortId1)lt(SortId2)

6
Operation and Expression Syntax

• op (OpForm) (SortIdList) -gt (SortId) .
• op top_Stack -gtInt op if_then_else_fi Bool Int
  Int -gtInt
• obj BITS is sorts Bit Bits.
• subsorts Bit lt Bits.
• ops 0 1 -gtBit.
• op _._ Bit Bits -gt Bits.
• Endo.

7
Equations and Semantics

• Equations eq (Exp1)(Exp2).
• Cond. Eq. cq (Exp1)(Exp2) if (Bexp).
• Variables vars (VarIdList)SortId.

8
Reduction

• obj LIST_OF_INT is sort List.
• protecting INT.
• subsort IntltList.
• op _ _Int List -gt List.
• op length_List-gtInt.
• var IInt. var L List.
• eq length I1.
• eq length (I L)1 length(L).
• endo.

reduce length (17 4 329) length(17 4
329)gt 1length(4 329)gt 1(1
length(329))gt 1(11)gt 12gt 3
9
Exceptions

• (-4/-2)! does not parse since parser doesnt
  know to what will it evaluate (Rat or Nat)
• Parser can insert retract special operation
  symbol (r RatgtNat) removed at runtime if the
  subexpression evaluates to Nat but otherwise
  remains behind as informative error message.

10
Exceptions Example

• obj STACK_OF_NAT is sorts Stack NeStack.
• subsort NeStackltStack.
• protecting NAT.
• op empty -gt Stack.
• op pushNat Stack-gtNeStack.
• op top_ NeStack-gt Nat.
• op pop_ NeStack-gt Stack.
• var XNat. var S Stack.
• eq top push(X,S)X.
• eq pop push(X,S)S.
• endo

• Reduce top push(1, empty)
• Should be 1
• Reduce pop push(1, empty)
• Should be empty
• Reduce top empty
• Yields
• Result Nattop rStackgtNeStack(empty)

11
Attributes

• op _or_ Bool Bool -gt Bool assoc idfalse
• Or is an associative binary infix operation on
  truth values
• op __ Int Int-gtInt assoc comm id0 prec 33
• Precedence of an operation is a number (0-127)
  where lower value indicates tighter binding.

obj LIST_OF_INT is sort List. protecting
INT. subsort IntltNeListltList. op nil
-gtList op _ _List List -gt List assoc
idnil. op _ _NeList List -gt NeList
assoc. endo.
Reduce 0 nil 1 nil 3. 0 nil 1 nil 3 gt 0 1 nil
3gt 0 1 3
12
Hierarchical structure
Conceptual clarity breaking a program into
modules (1988) Many modules - hierarchical
structure of module dependency explicit (if the
module uses sorts or operations declared in
another , the other must be imported explicitly
in the first, and must be defined earlier in
program text) Importing modules Using Extending
(ModExp)-module expression such as
INT Protecting
13
Parameterized programming

• Maximize reuse of software trough systematic use
  of parameterized programming.
• Successful software reuse
• Finding old parts that are close enough to what
  you need
• Understanding those parts
• Getting them to do what you need now
• Putting them all together correctly.
• (nothing new in this section) like templates in
  C

14
Theories
Express properties of modules and module
interfaces OBJ3 theories have the same structure
as objects. Difference is that the objects are
executable, while theories only define
properties. Example partially ordered sets (lt
is anti-reflexive and transitive) th POSET is
sort Elt. op _lt_ Elt Elt -gtBool. vars E1 E2 E3
Elt. eq E1 lt E1 false. cq E1 lt E3true if
E1ltE2 and E2ltE3. endth.
th EQV is sort Elt. op _eq_ Elt Elt -gtBool
comm. vars E1 E2 E3 Elt. eq (E1 eq E1)
true. cq (E1 eq E3)true if (E1 eq E2) and (E2
eq E3). endth.
15
Views
A object can satisfy a theory in more than one
way, but that can be arbitrarily hard to find. A
view V from a theory T to a module M indicated
VTgtM consists of a mapping from the sorts of T
to the sorts of M preserving the subsort relation
and a mapping from the operations of T to the
operations of M preserving sort, and attributes
such that every equation in T is true of every
model of M view NATG from POSET to NAT is sort
Elt to Nat. op _lt_ to _gt_. endv. This view
interprets _lt_ in POSET as _gt_ in NAT.
16
Instantiation
Parametrized object LEXLXPOSET can be
instantiated with a make LEXL_NATG is
LEXLNATG endm. Also make STACK_OF_LIST_OF_RAT
is STACKLISTRAT endm.
17
Tools

• Kumo - UCSD - is a web-based proof assistant,
  having the following features
• Kumo assists with proofs in first order hidden
  logic, using OBJ3 as a reduction engine.
• Kumo generates proof documentation for the web
• Kumo supports distributed cooperative proving.
  Users can send proof parts to the other members
  in the same group, and receive proof parts from
  them.
• The BOBJ (for Behavioral OBJ) language extends
  OBJ3 by adding behavioral modules for behavioral
  specification of objects (i.e., state machines),
  and first order sentences for modules with loose
  semantics.

18
OBJ3 in SW Engineering

• TOOR A System for Tracing Object Oriented
  Requirements
• Based on OBJ3
• For formal specification of requirements and
  their tracing. The idea is to specify the objects
  that can take part in a software development
  process, use TOOR to input these objects as they
  are created, and then trace requirements, making
  use of the relations among the current collection
  of objects. In this approach requirements are
  also objects
• OOZE An Object Oriented Z Envirnoment
• OOZE is an object oriented environment for Z,
  built on top of the FOOPS system, which in turn
  is built in top of the OBJsystem

19
The Larch Family of Specification
LanguagesParameterized programming in
LILEANNARoshanak Roshandel
20
What is Larch?

• Family of Specification Languages
• Specification components
• Larch Interface Language particular to
  specific PL
• Larch Shared Language common to all languages
• LIL tailored to a programming language
• LSL an algebraic language

21
Some Aspects of Larch Languages

• Composability. Incremental construction of
  specifications from other specifications
• Emphasis on Presentation. Readable. Larch
  composition mechanisms are operations on
  specification, rather than on theories or models.
• Suitability for integrated interactive tools.
  Good for interactive construction and incremental
  checking of specs.
• Semantic Checking. Checking of specs when they
  are being constructed. (i.e. theorem prover for
  semantic checking)

22
And Some More

• Localized programming language dependencies. Each
  LIL encapsulates features needed to write
  specifications in a particular Programming
  Language and incorporates LSL in a uniform way.

23
Trait is the basic unit of specification in LSL.
It introduces operators and specifies their
properties. Sometimes collection of operators
correspond to an ADT. Theory is a set of
theorems that can be proved about the terms
defined in a trait. Theory contains equations and
inequation ((true false)) that can be proved
by substituting equal for equal. BUT, if 2 terms
can not be proven to be equal then they are not
necessarily unequal. Also if two terms are not
provably unequal, it does not mean they are equal.
24

Larch shared language
Two-tiered specification in Larch
25
Signature domains and range of the operators
used for sort-check (similar to type-check in
PL). Constraints limit the operators by means of
equations that relate the terms containing them.
26
TableSpec trait introduces new
Table add Table,Index,Val Table ? Index,
Table Bool eval Table,Index Val isEmpty
Table Bool size Table Card Constrains
new, add, ?, eval, isEmpty, size so that for
all ind, ind1 Index, val Val, tTable
eval (add(t, ind, val), ind1) if ind
ind1 then val else eval(t, ind1) ind ? new
false ind ? add(t,ind1,val) (ind indl)
(ind ? t) size (new) 0 size(add(t,ind,val))
if ind ? t then size(t) else
size(t)1 isEmpty(t) (size(t) 0)
27
Container trait introduces new
C insert C, E C Constrains C so that C
generated by new, insert IsEmpty trait
assumes Container introduces IsEmpty C
Bool constrains IsEmpty, new, insert so that
for all cC, eE IsEmpty(new) true
IsEmpty(insert(c,e)) false implies converts
IsEmpty Next trait assumes Container
introduces next C E constrains next insert
so that for all eE next(insert(new,e))
e exempts next(new)
28
Rest trait assumes Container introduces
rest C C constrains rest insert so that for
all eE rest(insert(new,e)) new
exempts rest(new) Size trait assumes
Container imports Cardinal introduces size
C Card constrains size so that size(new)
0 Enumerable trait includes Container,
Next, Rest, IsEmpty constrains C so that C
partitioned bynext,rest,IsEmplty Partitioned
by If Next(t1) Next (t2), Rest(t1)
Rest(t2), IsEmpty(t1) IsEmpty(t2) then t1t1
29
Larch Interface Languages

• Interface specification describe program units to
  be implemented.
• Role of LSL traits is to define the theories that
  give meaning to operators that appear in the
  Interface specification.
• Particular to the programming language, and
  influenced by them.

30
Type Specification in LIL

1. Header giving the type name and the names of
   externally visible routines.
2. Associated traits and a mapping from the types in
   the data abstraction to sorts in the traits.
3. The Interface specification for each routine
   (procedure or function) of a type.

31
Preliminary design of Larch/Java

• LIL for C, ADA, Modula-3
• C, Smalltalk
• Generic Interface Language for new languages
• preliminary proposal for Larch/CORBA-IDL
• Larch/JAVA from C
• Supports concurrency
• Synchronization (when)
• myID (client), lock, waiting set (thread and
  mutual exclusion)

32
Larch/Java for Software Architecture

• Software architecture
• Design of the structure of a software system,
  including its overall behavior and its
  decomposition in simpler computational elements.
• Software architecture
• Components, Connectors, Configurations

33
Ports Interface between each component and its
environment Roles Interaction point among
participating components
component trait includes Set(iport, Setiport),
Set (oport, Setoport) component tuple of
inportsSetiport, outportsSetoport connector
trait includes Set(irole, Setirole, Set
(orole, Setorole) connector tuple of
inrolesSetirole, outrolesSetorole
34
Client-Server architecture

• Clienttrait
• includes component,
• Queue(data, inputstream)
• Queue(data, outputstream)
• Client tuple of compcomponent,inputsinputstrea
  m,
• outputsoutputstream
• introduces
• Initclient -gt Client
• Isconnected Client -gt Bool
• IsValid Client -gt Bool
• asserts
• \forall c Client
• IsValid(c) size(c.comp.inports) 1 /\
• size(c.comp.outports) 1

35

• Servertrait
• includes component,
• Queue(data, inputstream)
• Queue(data, outputstream)
• Server tuple of compcomponent, inputs
  inputstream,
• outputsoutputstream
• introduces
• Initserver -gt Server
• Isconnected Server -gt Bool

36
Rpc trait includes connector, Queue(data,
inputstream) Queue(data, outputstream)
Rpc tuple of connconnector, inputs
inputstream, outputsoutputstream
introduces Initrpc -gt Rpc
Initinputstream -gt inputstream
Initoutputstream -gt outputstream IsValid
Rpc -gt Bool asserts \forall r Rpc
IsValid(r) size(r.conn.inroles) 1 /\
size(r.conn.outroles) 1
37



The LIL specification modules describe the
functional behavior of each component. Client
responsible for starting the communication and
the retrieval of result data. Server listens
for incoming requests services a client as soon
as possible. RPC connector sets up the
connection for the exchange of data between the
client and the server. Java socket interface is
used as protocol of communication between hosts
on the network. The LIL modules for the Server
component and the RPC connector are developed.
38
Notes

• LSL is used to specify a theory, rather than a
  model.
• LIL are built around predicate calculus rather
  than an operational notation.
• Larch specifications are less prone to
  implementation bias.
• LSL has mechanisms for building one
  specification from another (assumes, includes,
  imports) and to insert checkable redundancy
  (constraints, converts).
• LIL does not have corresponding mechanism.

39
More notes

• Larch semantics are simple
• Operators and sorts in the shared specifications
  are treated as auxiliary and are never
  implemented.
• Issues that are dealt with in LIL are not dealt
  with in LSL.
• Larch was fun!

40
LIL ANNA in a tiny Nutshell

• An implementation of LIL (Library Interconnect
  Language), a MCL (Module Composition Language)
• Parameterized programming paradigm
• Language for formally specifying and generating
  Ada packages.

41
What sets reusable software apart is how it is
put together!

• Design and development of parameterized
  components and software architecture
• Layered architectures
• Integrate (glue) the instantiated components
  together to form new capabilities.
• Module expressions

42
Introduction

• Supports
• Parameterized programming in Ada by introducing
• Vertical and horizontal structuring and
  composition of applications through multiple
  inheritance and module expressions.
• theories
• views
• And enhancing
• package specifications

43

• LILEANNA package template for actual Ada package
  specifications.
• Theory high level abstraction to describe a
  modules syntactical and semantic of interface or
  properties of parameters.
• View mapping between types, operations and
  exceptions.
• Vertical hierarchy levels of abstraction and /or
  stratification
• Horizontal hierarchy aggregation and
  inheritance (type and code)

44

• Module semantics Expressed as a set of
  individual assertions or as a whole
  axiomatically.
• Operations explained in terms of other operations
  (axioms)
• Functionality expressed in terms of pre- and post
  cond.
• make Integer_set is
• LIL_SetInteger_view
• End
• view Integer_View Triv gt Standard is
• types (Element gt Integer)
• End

45

• View can be given a name and reused in other
  instantiation
• Make Integer_set is
• LIL_Set view Triv gt Standard is
• types (Element gt Integer)
• End

46
Comparison of MILs

• LILEANNA, MIL75, Thomass MIL, Coopriders MIL,
  INTERCOL and PIC
• Units of Modularization, Version/Implementation
  Control, Implementation/Dependency relationship,
  Export/Interface definition.
• Only LIL provides inheritance as a structuring
  mechanism, supports both syntactic and semantic
  spec. of a module interface, and has a module
  parameterization and generation capability.
• Other MILs have toolsets providing more static
  analysis of dependency conflicts.

47

• THE END!