Transcript ppt - LePUS3 and/or Class-Z

Lecture notes in graduate module, CE839: Software Design and Architecture, Autumn term 2008/9
Dr Amnon H Eden, School of Computer Science and Electronic Engineering, University of Essex
Object-Oriented Modelling
in LePUS3 and Class-Z
Modelling small programs
Modelling large programs
Modelling application frameworks
Modelling design patterns
1
LePUS3 and Class-Z: desiderata

Abstraction

Abstract ontology





Scaling: capture the building blocks of very large programs

Detailed notation—cluttered diagrams

What NOT to model? What a specification should NOT represent?
Rigour

Formal specification

Verification
Decidability: Tool support in “round-trip engineering”

automated verification is possible in principle

Tool support automates the verification process

Allows us to “close the loop” of round-trip engineering
Visualization (Optional



Offer an answer: What are the conceptual building blocks of software design?
Offer a “picture” of a specification:

Existing program: a ‘roadmap’ to the millions of lines of code

A design motif: design pattern, architectural style
Makes software easier to understand and change
Theory & practice

Be relevant to practical applications

Provide a sound foundation in a solid mathematical theory
2
Specification language: desiderata
(cont.)

Combine theory & practice
It has long been my personal view that the separation of practical
and theoretical work is artificial and injurious. Much of the
practical work done in computing, both in software and in
hardware design, is unsound and clumsy because the people who
do it have not any clear understanding of the fundamental design
principles of their work. Most of the abstract mathematical and
theoretical work is sterile because it has no point of contact with
real computing.
-- Christopher Strachey
3
What can be modelled in LePUS3/Class-Z?
Programs
newItr
Design patterns
create
I terator
Produce
Produce
I terators
IteratorsHrc
CollectionsHrc
Aggregates
next
Aggregate
Aggregate
Return
http
Servlet
Elements
A
(The Iterator pattern)
servlet
Ops
user
Servlet
Return
Forward
(Collections in java.util)
Application frameworks
Inherit
object
next
servlet
Ops
4
(Java Servlets)
What cannot be modelled in LePUS3/Class-Z?

Temporal relations




Strategic design



‘Method x should be called before method y’
No collaboration/interaction diagrams, flow charts,
statecharts, …
Statements about specific objects
Architectural styles
Components
Programs in procedural/functional/other
programming paradigms

LePUS3 and Class-Z model object-oriented programs
5
Tool support
in LePUS3
and Class-Z
Design
create
Iterator
Produce
Iterators
Aggregates
next
Aggregate
Formal specification
Software modelling
Software visualization
Return
Elements
Forward engineering
(Verification)
Reverse engineering
(Design Recovery)
interface Collection ... {
public Iterator iterator() {
...
}
public class LinkedList ... {
}
public Iterator iterator() {
...
}
}
Implementation
Applications
App. frameworks
Class libraries
LePUS3 vs. Class-Z


Specifications can be expressed in one of two ways:

LePUS3: Visual, similar to UML Class Diagrams

Class-Z: symbolic, similar to Z
Students are only required to learn one of the notations
java.lang.
System
Member
printStream
LePUS3
Example
java.lang.system, printStream : CLASS
Member(java.lang.system,printStream)
Class-Z
7
The genealogy of LePUS3 and Class-Z


Definition: As a subset of first-order predicate
calculus (classical logic)
Official reference manual:


A.H. Eden, E. Gasparis, J. Nicholson. "LePUS3 and Class-Z
Reference Manual". University of Essex, Tech. Rep. CSM474, ISSN 1744-8050 (2007).
http://lepus.org.uk/ref/refman/refman.xml
Historical roots:


LePUS3: LePUS [Eden 2001]—LanguagE for Pattern
Uniform Specification
Class-Z: Z [Spivey]
8
Modelling small programs
in LePUS3 and Class-Z
Class and signature constants
Unary relation symbols
Binary relation symbols
9
Modelling individual classes

class constant: represents any specific static type such
as a class, Java interface, and primitive types
linkedList
collection
int
class
LinkedList
interface
Collection
primitive type
int
Example
linkedList, collection, int : CLASS
10
Modelling individual methods

signature constant: represents a specific ‘signature’ of
(one or more) methods A method with signature newItr is
defined in class Collection
linkedList
collection
newItr
A method with signature newItr is
defined in class LinkedList
Example
linkedList, collection : CLASS
newItr : SIGNATURE
Method(newItrlinkedList)
Method(newItrcollection)
newItr
public class LinkedList ... {
public Iterator newItr() {
...
}
}
public class Collection ... {
public Iterator newItr() {
...
}
11
}
Modelling properties

Unary relation: represents a property
Class
AbstractSet
is abstract
Abstract
Abstract
collection
abstractSet
Example
Collection
Abstract
collection
is an
Interface
Abstract
newItr
Collection.newItr is
an abstract method
abstractSet, collection : CLASS
newItr : SIGNATURE
Abstract(abstractSet)
Abstract(collection)
Abstract(newItrcollection)
12
Modelling relations between individuals

Binary relation: represents a relation between two
individuals
linkedList
Inherit
ListIter
abstractSet
LinkedList ‘extends’
AbstractSet
Inherit
ListIterator
ListIter ‘implements’
ListIterator
Example
linkedList, abstractSet, ListItr, ListIterator : CLASS
Inherit(linkedList,abstractSet)
Inherit(ListItr,ListIterator)
13
Binary relations: Member
public class System {
...
public static PrintStream out;
...
}
java.lang.
System
Member
printStream
Example
java.lang.system, printStream : CLASS
Member(java.lang.system,printStream)
14
Binary relations: Aggregate
linkedList
Aggregate
object
Example
linkedList, object : CLASS
Aggregate(linkedList,object)
15
Binary relations: Call

Note that the Call relation
abstracts away all
information about the
control-flow
test
public class Test {
public static void main(String[] args) {
if (args.length == 0)
System.out.print("Insufficient arguments");
...
printStream
main
Call
print
Example
test, printStream : CLASS
main, print : SIGNATURE
Call(maintest, printprintStream)
16
Binary relations: Forward
public class MyServlet extends HttpServlet {
public void doGet(HttpServletRequest rq, HttpServletResponse rs) {
super.doGet(rq,rs);
}
Forward:
A special kind of a Call
relation in which the
formal arguments are
passed on to a method with
same signature
myServlet
doGet
httpServlet
Forward
doGet
Method MyServlet.doGet forwards the
call to HttpServlet.doGet
Example
myServlet, httpServlet : CLASS
doGet : SIGNATURE
Forward(doGetmyServlet, doGethttpServlet)
17
Binary relations: Create
public class MyClass {
public void method() {
... if ... else ...
... for (int index = 0; ...) ...
}...
}
myClass
int
method
Create
Method MyClass.method may create an integer
Example
linkedList, listItr : CLASS
listIterator : SIGNATURE
Produce(listIteratorlinkedList, listItr)
18
Binary relations: Produce
public class LinkedList { ...
public ListIterator listIterator(int index) {
if (1 < 0)
return new ListItr(index);
} ...
}
linkedList
Produce:
A special kind of a Create
relation in which the
new object is returned
(typical to ‘factory methods’)
listItr
listIterator
Produce
Method LinkedList.listIterator may
create and return a new ListItr
Example
linkedList, listItr : CLASS
listIterator : SIGNATURE
Produce(listIteratorlinkedList, listItr)
19
Modelling indirect relations

Transitive relation: represents possibly indirect relation
(the ‘transitive closure’ of a binary relation)
interface Collection { ...
class AbstractList implements Collection {...
class AbstractSet extends AbstractList ...
class LinkedList extends AbstractSet ...
linkedList
Inherit +
collection
Example
linkedList, collection : CLASS
Inherit+(linkedList, collection)
20
Transitive relations II
public class FileInputStream ... {
public int read(byte[] b)
throws IOException, NullPointerException {
...
ioException
fileInput
Stream
ioException
+
read
C all
C all+
nullPointer
Exception
nullPointer
Exception
Example
fileInputStream, ioException, nullPointerException : CLASS
read,nullPointerException,ioException : SIGNATURE
Call+(readfileInputStream, ioExceptionioException)
Call+(readfileInputStream, nullPointerExceptionnullPointerException)
21
Case Study I:
LinkedList and ListItr
LePUS3
Abstract
UML Class diagram
Abstract
collection
iterator
Collection
Iterator
newItr()
next()
LinkedList
ListItr
newItr()
next()
Abstract
Abstract
newItr
next
I nherit +
I nherit +
linkedList
newItr
linkedList.
listItr
Produce
Aggregate
next
Return
object
return new ListItr();
Object
22
Case Study II: java.io.XXReader classes
public class LineNumberReader
extends BufferedReader { …
public void read() { …
super.read(); …
} …
public void mark(int readAheadLimit) { …
super.mark(readAheadLimit); …
} …
public void reset() { …
super.reset(); …
} …
bufferedReader
read
mark
reset
Forward
Forward
Forward
read
mark
reset
lineNumberReader
ReaderExample
bufferedReader, lineNumberReader : CLASS
read, mark, reset : SIGNATURE
Forward(readlineNumberReader, readbufferedReader)
Forward(marklineNumberReader, markbufferedReader)
Forward(resetlineNumberReader, resetbufferedReader)
23
Exercise


“Translate” the LePUS3 chart in the case study into a
Class-Z specification
Use either Class-Z or LePUS to model three DIFFERENT
specifications of the classes Collection, Iterator,
LinkedList, and ListItr in the package java.util.

Each specification should include one or more of the methods
defined in these classes. Which ones did you choose to model
and why?

Note that each specification may contain a different set of
relations

Note that each specification must be SATISFIED by the classes
in java.util!
24
Exercise (Cont.)

Which one is the most correct description of the purpose
of a LePUS/Class-Z specification?
1. Each specification is model of a particular implementation
2. Each specification models an one or more possible
implementations
3. Each specification models an aspect of one implementation
abstracted for a particular purpose
4. Each specification models an aspect of one or more possible
implementations abstracted for a particular purpose
25
Exercise (Cont.)

How many ways can you model a Java program
in which class MyClass has a method therein
with the signature method(String arg) which
throws an exception of class MyException in
LePUS3 or Class-Z?
26
Modelling large programs
in LePUS3 and Class-Z
Hierarchy constant
1-dim class and signature constants
Total and Isomorphic predicates
27
Modelling sets of classes
treeSet
Concrete
Collections

1-dimensional class
constant: Stands for a
(non-empty) set of
specific static types
hashSet
linkedList
Example
ConcreteCollections : PCLASS
array
List
28
Modelling sets of methods (one signature)

Concrete
collections
treeSet
newItr
Clan: A set of methods
with same signature
newItr
hashSet
newItr
linkedList
newItr
Example
array
List
newItr
ConcreteCollections : PCLASS
newItr : SIGNATURE
All(Method, newItrConcreteCollections)
29
Modelling sets of methods (many signatures)

1-dimensional signature constant: Stands for a (nonempty) set of specific method signatures
1-Dim
Signature
Constant
sig1

sign
Example
1-DimSignatureConstant : PSIGNATURE
30
Modelling sets of methods (many signatures)

Tribe: A set of methods in same class
http
Servlet
http
Servlet
doPost
doGet
doTrace
doPut
Servlet
Ops
Example
httpServlet : CLASS
ServletOps : PSIGNATURE
All(Method, ServletOpshttpServlet)
31
Modelling sets of methods (many signatures):
example
bufferedReader
bufferedReader
read
mark
reset
BufferOps
Example
BufferOps : PSIGNATURE
bufferedReader : CLASS
All(Method, BufferOps bufferedReader)
32
Modelling relations between sets: Total
d1
Domain
Binar y
Relation
Binar y
Relation
r1
Range
Every element in Domain is in relation
Relation with some element in Range
d2
d3
d4
Bi n
Rel ar y
at i o
n
Binar y
Relation
ar y
B i n t i on
a
Rel
r2
r3
Total(BinaryRelation,Domain,Range)
33
Total predicate: example
collection
Inherit +
Inherit +
Inherit +
Inherit +
Inherit +
collection
treeSet
Concrete
Collections
hashSet
linkedList
array
List
Example
ConcreteCollections : PCLASS
collection : CLASS
Total(Inherit+,ConcreteCollections,collection)
34
Total predicate: example II
treeSet
Concrete
Collections
hashSet
Aggregate
linkedList
object
array
List
Aggregate
Aggregate
Aggregate
Aggregate
object
Example
ConcreteCollections : PCLASS
object : CLASS
Total(Aggregate,ConcreteCollections,object)
35
Modelling relations between sets:
Isomorphic
d1
Abstract
r1
BinaryRelation
d2
Domain
Binary
Relation
r2
BinaryRelation
Range
d3
r3
BinaryRelation
d4
r4
Abstract
Every element in Domain is in relation
BinaryRelation with a unique element in
Range
Isomorphic(BinaryRelation,Domain,Range)
36
Isomorphic predicate: example I
bufferedReader
bufferedReader
read
mark
reset
BufferOps
Forward
Forward
Forward
Forward
read
mark
reset
BufferOps
lineNumberReader
lineNumberReader
Example
bufferedReader, lineNumberReader : CLASS
BufferOps : PSIGNATURE
Inherit(lineNumberReader,bufferedReader)
Isomorphic(Forward, ServletOpslineNumberReader,ServletOpsbufferedReader)
37
java.awt.
container
java.awt.
component
print
invalidate
setFont
paramString
Forward
Forward
Forward
Forward
print
invalidate
setFont
paramString
Forward
minimumSize
list
minimumSize
Forward
list
Forward
addNotify
addNotify
get
AlignmentY
Forward
get
AlignmentY
num
Listening
Forward
num
Listening
lightweight
Paint
Forward
lightweight
Paint
lightweight
Print
Forward
lightweight
Print
event
Enabled
Forward
event
Enabled
process
Event
Forward
process
Event
dispatch
EventImpl
Forward
dispatch
EventImpl
get
AlignmentX
Forward
get
AlignmentX
remove
Notify
Forward
remove
Notify
preferred
Size
Forward
preferred
Size
getMaximum
Size
Forward
getMaximum
Size
isFocus
CycleRoot
Forward
isFocus
CycleRoot
nextFocus
Helper
transfer
Focus
Backward
apply
Component
Orientation
addProperty
Change
Listener
Forward
nextFocus
Helper
transfer
Focus
Backward
apply
Component
Orientation
addProperty
Change
Listener
Forward
Forward
Forward
Isomorphic predicate:
example II
java.awt.
container
Container
Ops
java.awt.
component
Forward
Container
Ops
38
Case study: collections & iterators in java.util
treeSet
newItr
Produce
hashSet
newItr
Produce
linkedList
newItr
array
List
Produce
treeMap.
KeyIterator
Concrete
Collections
newItr
Produce
Concrete
Iterators
hashMap.
KeyIterator
linkedList.
ListItr
abstractList.Itr
newItr
Produce
Example
ConcreteCollections, ConcreteIterators : PCLASS
Isomorphic(Produce, newItrConcreteCollections, ConcreteIterators)
39
Abstract
Abstract
collection
Collections & iterators
in java.util (cont.)
iterator
Abstract
Abstract
newItr
next
I nherit +
I nherit +
I nherit +
I nherit +
treeSet
newItr
I nherit +
I nherit +
treeMap.
KeyIterator
I nherit +
Produce
I nherit +
next
Abstract
hashMap.
KeyIterator
hashSet
newItr
Produce
array
List
next
newItr
next
abstractList.Itr
newItr
Aggregate
Abstract
linkedList.
ListItr
newItr
Produce
next
Aggregate
next
I nherit +
I nherit +
Concrete
Collections
Concrete
Iterators
newItr
Produce
Aggregate
Return
Return
Aggregate
next
Return
Return
Return
Aggregate
iterator
Abstract
Produce
linkedList
Abstract
collection
object
object
40
Exercise

Translate the specification of collections and
iterators to UML
41
Modelling class hierarchies

1-dimensional hierarchy
constant: a set of classes s.t.
all inherit from one
root
Cls
1-Dim
Hierarchy
Constant
I nherit +
Other
Classes
Example
Hierarchy : HIERARCHY
42
Hierarchy: example
collection
I nherit +
I nherit +
I nherit +
treeSet
I nherit +
CollectionsHrc
hashSet
Example
linkedList
CollectionsHrc : HIERARCHY
array
List
43
Modelling sets of methods revisited
root
Cls
sig
sig
I nherit +
Hrc
Other
Classes
sig
Example
Hrc : HIERARCHY
sig : SIGNATURE
All(Method,sigHrc)
44
Example: the Lists hierarchy
list
Abstract
add
add
I nherit
linkedList
I nherit
ListsHrc
abstract
List
add
Abstract
I nherit
add
Example
I nherit
array
List
vector
add
add
Lists : HIERARCHY
add : SIGNATURE
All(Method,addLists)
45
Case study: collections & iterators in java.util
Abstract
Abstract
collection
iterator
Abstract
Abstract
newItr
newItr
next
I nherit +
I nherit +
Concrete
Collections
Concrete
Iterators
newItr
Produce
Produce
IteratorsHrc
CollectionsHrc
next
next
Aggregate
Return
object
Aggregate
Return
object
Example
CollectionsHrc, IteratorsHrc : HIERARCHY
next, newItr : SIGNATURE
object : CLASS
Isomorphic(Produce, newItrCollectionsHrc, IteratorsHrc)
Total(Return, nextIteratorsHrc, object)
46
Total(Aggregate, CollectionsHrc, IteratorsHrc)
Example: lists, sets, and sorted sets
Example
Lists, Sets, SortedSets : HIERARCHY
newItr : SIGNATURE
collection : CLASS
Total(Inherit+, Lists, collection)
Total(Inherit+, Sets, collection)
Total(Inherit+, SortedSets, collection)
Method(newItrcollection)
All(Method, newItrLists)
All(Method, newItrSets)
All(Method, newItrSortedSets)
newItr
+
I
newItr
rit
e
nh
I nherit +
collection
newItr
Lists
In
he
rit +
newItr
Sets
SortedSets
47
Modelling application
frameworks
Variables
48
Variables vs. constants
aClass
A class variable
Object
A class constant
Example
aClass, Object : CLASS
49
Variables vs. constants II
x
Inherit
y
Class x extends/
implements class y
linkedList
Inherit
abstractSet
LinkedList extends/
implements AbstractSet
Example
linkedList, abstractSet, x, y : CLASS
Inherit(linkedList,abstractSet)
Inherit(x,y)
50
Assignments


A specification with variables is only
meaningful wrt a specific
assignment
Example: Assignment-1





x
Inherit
y
Example: Assignment-2


x is assigned to LinkedList
y is assigned to AbstractSet
y is assigned to LinkedList
x is assigned to AbstractSet
Assignment-1 is satisfied by java.util
Assignment-2 is satisfied by java.uti
Example
x, y : CLASS
Inherit(x,y)
51
Example: Java Servlets
http
Servlet
A
Servlet class
can be any
class
that satisfies the
relations
Inherit
Servlet class must
extend class
HTTPServlet
Forward
Servlet
Ops
user
Servlet
Servlet
Ops
Each method in your Servlet
must forward call to respective
method in superclass
Servlet class must
override a particular
set of methods
JavaServlet
httpServlet, userServlet : CLASS
ServletOps : P(SIGNATURE)
Isomorphic(Forward, ServletOpsuserServlet, ServletOpshttpServlet)
Inherit(userServlet, httpServlet)
52
Variables vs. constants: example I
A specific implementation
A
http
Servlet
doGet
Inherit
Inherit
Forward
doGet
doGet
Hello
Text
A
Forward
http
Servlet
Any Java Servlet
doGet
user
Servlet
public class HelloText extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) {
super.doGet(request,response);
response.setContentType("text/plain");
PrintWriter out = response.getWriter();
out.println("Hello World");
}
}
53
Variables vs. constants: example II
Collections in java.util
newItr
Iterator pattern
create
I terator
Produce
Produce
I terators
IteratorsHrc
CollectionsHrc
next
Aggregate
Return
Aggregates
Aggregate
object
CollectionsInJavaUtil
next
Return
Elements
Iterator
Collections, Iterators : HIERARCHY
next, newItr : SIGNATURE
object : CLASS
Aggregates, Iterators : HIERARCHY
createIterator, next : SIGNATURE
object : CLASS
Isomorphic(Produce, newItrCollections, Iterators)
Return(nextIterators, object)
Isomorphic(Produce, createIteratorAggregates,Iterators)
Return(nextIterators, object)
54
Variables vs. constants: example III
Composite in java.awt
Composite pattern
Component
Ops
Abstract
Abstract
component
component
Forward
I nherit
Component
Leaves
Forward
I nherit
Aggregate
I nherit
Component
Ops
Component
Ops
container
Composite
Ops
Component
Ops
I nherit
Aggregate
Component
Ops
Leaves
Component
Ops
composite
Composite
Ops
55
Case study: Enterprise JavaBeans
From [Monson-Haefel 2001]:
1.
“Every bean [class] obtains an EJBContext object, which is a reference to
the container
2.
“The home interface extends the ...javax.ejb.EJBHome interface
3.
“A home [interface] may have many create() methods, … , each of which
must have corresponding ejbCreate() and ejbPostCreate() methods in the
bean class. The number and datatype of the arguments of each create() are
left up to the bean developer”
4.
“When a create() method is invoked on the home interface, the container
delegates the invocation to the corresponding ejbCreate() and
ejbPostCreate() methods on the bean class.
5.
[An implementation for the bean’s home interface is generated by the
container.]”
56
Modelling Enterprise JavaBeans I
A
I nherit
javax.ejb.
EJBHome
“The home interface extends
the ...javax.ejb.EJBHome
interface”
Member
A
“Every bean [class] obtains
an EJBContext object,
which is a reference to the
container”
EJBContext
Bean
BeanHome
A I nterface
create
57
Modelling Enterprise JavaBeans II
“A home [interface] may have many create() methods, … , each of which must have
corresponding ejbCreate() and ejbPostCreate() methods in the bean class. The number
and datatype of the arguments of each create() are left up to the bean developer
Bean
HomeI mp
Cal l
ejbPost
Create
Bean
ejbCreate
create
Call
“When a create() method is invoked on the home interface, the container delegates the
invocation to the corresponding ejbCreate() and ejbPostCreate() methods on the bean
class”
58
Summary: Enterprise JavaBeans
A
A
javax.ejb.
EJBHome
I nherit
Member
EJBContext
BeanHome
A I nterface
create
Generated
From
Bean
HomeI mp
Cal l
ejbPost
Create
Bean
ejbCreate
create
Call
59
Modelling design patterns
The ‘gang of four’ patterns:
Iterator, Proxy, Composite, Observer,
Factory Method, Adapter (Object), Adapter
(Class), Strategy
60
Iterator pattern
create
I terator
Produce
I terators
Aggregates
next
Aggregate
Return
Elements
Iterator
Aggregates, Iterators : HIERARCHY
createIterator, next : SIGNATURE
Elements : PCLASS
Isomorphic(Produce, createIteratorAggregates, Iterators)
Total(Return, nextIterators, Elements)
Total(Aggregate, Aggregates, Elements)
61
client
Ops-1
Call
R emote
R equests
Proxy pattern
A
subject
In
In
he
rit
Ops-2
Call
Local
R equests
Local
R equests
proxy
R emote
R equests
Member
Call
he
rit
realSubject
R emote
R equests
Proxy
client, subject, proxy, realSubject : CLASS
Ops-1, Ops-2, LocalRequests, RemoteRequests : PSIGNATURE
Abstract(subject)
Total(Call, Ops-1client, LocalRequestssubject)
Total(Call, Ops-2Client, RemoteRequestssubject)
Total(Call, RemoteRequestsproxy, RemoteRequestsrealSubject)
Method(LocalRequestsproxy)
Member(proxy,realSubject)
Inherit(proxy,subject)
Inherit(realSubject,subject)
62
Composite pattern
Abstract
Component
Ops
component
Forward
I nherit
Composite
component, composite : CLASS
Leaves : PCLASS
CompositeOps, ComponentOps : PSIGNATURE
I nherit
Aggregate
Component
Ops
Leaves
Component
Ops
composite
Composite
Ops
Abstract(component)
All(Method,ComponentOpsLeaves)
All(Method,CompositeOpscomposite)
Inherit(composite,component)
Total(Inherit, Leaves, component)
Aggregate(composite,component)
Isomorphic(Forward,ComponentOpscomposite,ComponentOpscomponent)
63
subject
detach
(Observers)
attach
(Observers)
Call
Call
SetState
concrete
Subject
getState
update
(subject)
Observer
pattern
Observers
Call
I nherit
notify
constructor
destructor
Ca
ll
A
Members
Call
Observer
subject, concreteSubject : CLASS
notify, getState, update, attach, detach, constructor,
destructor : SIGNATURE
SetState : PSIGNATURE
Observers : HIERARCHY
Abstract(subject)
Inherit(concreteSubject,subject)
Total(Call, SetStateconcreteSubject, notifysubject)
Total(Call, notifysubject, updateObservers)
Total(Call, updateObservers, getStateconcreteSubject)
Total(Call, constructorObservers, attachsubject)
Total(Call, destructorObservers, detachsubject)
Members(subject,Observers)
64
Factory Method pattern
factory
Method
Factories
Produce
Products
FactoryMethod
Factories, Products : HIERARCHY
factoryMethod : SIGNATURE
Isomorphic(Produce, factoryMethodFactories, Products)
65
Adapter (Class) pattern
target
client
Abstract
adaptee
Operations
Call
Requests
Specific
Requests
I nherit
I nherit
Call
adapter
Requests
ClassAdapter
client, target, adapter, adaptee : CLASS
Operations, Requests, SpecificRequests : PSIGNATURE
Abstract(target)
Total(Call, Operationsclient, Requeststarget)
Total(Call, Requestsadapter, SpecificRequestsadaptee)
Inherit(adapter,target)
Inherit(adapter,adaptee)
66
Adapter (Object) pattern
target
client
Abstract
adaptee
Operations
Call
Requests
Specific
Requests
I nherit
Member
Call
adapter
Requests
ObjectAdapter
client, target, adapter, adaptee : CLASS
Operations, Requests, SpecificRequests : P(SIGNATURE)
Abstract(target)
Total(Call, Operationsclient, Requeststarget)
Total(Call, Requestsadapter, SpecificRequestsadaptee)
Inherit(adapter,target)
Member(adapter,adaptee)
67
Strategy pattern
context
Member
client
request
Call
request
Call
I nterface
Call
algorithm
(context)
Strategies
Strategy
client, context : CLASS
request, algorithm : SIGNATURE
Interface : P(SIGNATURE)
Strategies : HIERARCHY
Member(context, Strategies)
Call(requestclient, requestcontext)
Call(requestcontext, algorithmStrategies)
Total(Call, algorithmStrategies, Interfacecontext)
68
Tool support in
LePUS3 and Class-Z
69
Two-Tier
Programming
Design
create
Iterator
Produce
Iterators
Aggregates
next
Aggregate
Formal specification
Software modelling
Software visualization
Return
Elements
Forward engineering
(Verification)
Reverse engineering
(Design Recovery)
interface Collection ... {
public Iterator iterator() {
...
}
public class LinkedList ... {
}
public Iterator iterator() {
...
}
}
Implementation
Applications
App. frameworks
Class libraries
The Two-Tier Programming Toolkit

Round-trip engineering

Supports:


Specification & verification (forward engineering)

Visualization (reverse engineering)
http://ttp.essex.ac.uk
71
The TTP Toolkit (cont.):
Specification in LePUS3
72
The TTP Toolkit (cont.):
Specification in Class-Z
73
The TTP Toolkit (cont.): Verification
74
The TTP Toolkit (cont.): Visualization
75
Exercises
1. Summarize the differences between LePUS3/Class-Z and
UML:
1.1 Compare the LePUS3 chart with the UML Class diagram of
LinkedList and the ListItr classes
1.2 Use UML to model the Collection and the Iterator hierarchies in
Java.util. How is this diagram different from the LePUS3/Class-Z
specification?
1.3 Use UML to model Java Servlets. How is this diagram different
from the LePUS3/Class-Z specification?
1.4 Use UML to model one of the design patterns. How is this
diagram different from the LePUS3/Class-Z specification?
2. List four abstraction mechanisms in LePUS3/Class-Z
76
Exercises (cont.)
3. Compare the LePUS3/Class-Z Specification of
each one of the design patterns to the
description in Gamma et al. 1995
3.1 What is the book saying that the chart/schema does
not say?
3.2 What is the chart/schema saying that the book does
not say?
3.3 What are the advantages of the book over the
chart?
3.4 What are the advantages of the chart over the
book?
77
Exercises (cont.)
4. Specify in LePUS3/Class-Z the following statements:
4.1 “There exists a method in class MyClass which creates
instances of class String”
Answer:
x
myClass
Create
string
78
LePUS3 quick reference

constants and variables
s-dim
signature
constant
1-Dim
Signature
Constant
0-dim
class
constant
1-Dim
Class
Constant
0-dim
signature
variable
1-Dim
Signature
Variable
0-dim
class
variable
1-Dim
Class
Variable
1-Dim
Hierarchy
Constant
2-DIM
HIERARCHY
CONSTANT
1-Dim
Hierarchy
Variable
2-DI M
HI ERARCHY
VARI ABLE
79
LePUS3 quick reference (cont.)
Methods
Relations and predicates
cls
sig
sig
Classes
sig
Hrc
cls
Signatures
An individual
method
Unary
Relation
Domain
Binary
Relation
Range
Domain
Binary
Relation
Range
A set of methods
of same
signature
A set of
methods
of different
signature
BinaryRelation
Total
predicate
Isomorphic
predicate
80
References





Legend: Key to LePUS3 and Class-Z Symbols [.pdf]
<http://www.lepus.org.uk/ref/legend/legend.xml>
A.H. Eden, J. Nicholson. Object-oriented modelling: Theory and Practice.
Unpublished manuscript (ask me for a copy)
A.H. Eden, E. Gasparis, J. Nicholson. "LePUS3 and Class-Z Reference
Manual". University of Essex, Tech. Rep. CSM-474, ISSN 1744-8050
(2007). <http://lepus.org.uk/ref/refman/refman.xml>
A.H. Eden, E. Gasparis, J. Nicholson. "The 'Gang of Four' Companion:
Formal specification of design patterns in LePUS3 and Class-Z.“ University of
Essex, Tech. Rep. CSM-472, ISSN 1744-8050 (2007).
<http://lepus.org.uk/ref/companion/index.xml>
A.H. Eden. “Formal Specification of Object-Oriented Design.” Proc. Int'l
Conf. Multidisciplinary Design in Engineering CSME-MDE 2001 (21–22
Nov. 2001), Montreal, Canada.
81