Object-Oriented Modelling in LePUS3 and Class-Z

1. 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 Modellingin LePUS3 and Class-Z Modelling small programs Modelling large programs Modelling application frameworks Modelling design patterns

2. LePUS3 and Class-Z: desiderata • Abstraction • Abstract ontology • Offer an answer: What are the conceptual building blocks of software design? • 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 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

3. 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

4. What can be modelled in LePUS3/Class-Z? Programs Design patterns Application frameworks (Collections in java.util) (The Iterator pattern) (Java Servlets)

5. What cannot be modelled in LePUS3/Class-Z? • Temporal relations • ‘Method x should be called before method y’ • No collaboration/interaction diagrams, flow charts, statecharts, … • Statements about specific objects • Strategic design • Architectural styles • Components • Programs in procedural/functional/other programming paradigms • LePUS3 and Class-Z model object-oriented programs

6. Tool support in LePUS3and Class-Z Design Formal specificationSoftware modelling Software visualization Forward engineering (Verification) Reverse engineering (Design Recovery) interface Collection ... { public Iterator iterator() { ... } } Applications App. frameworksClass libraries public class LinkedList ... { public Iterator iterator() { ... } } Implementation

7. 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 LePUS3 Example java.lang.system, printStream :CLASS Class-Z Member(java.lang.system,printStream)

8. 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. CSM-474, 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]

9. Modellingsmall programsin LePUS3 and Class-Z Class and signature constants Unary relation symbols Binary relation symbols

10. Modelling individual classes • class constant: represents any specific static type such as a class, Java interface, and primitive types class LinkedList interfaceCollection primitive typeint Example linkedList, collection, int:CLASS

11. Modelling individual methods • signature constant: represents a specific ‘signature’ of (one or more) methods A method with signature newItr is defined in class Collection A method with signature newItr is defined in class LinkedList public class LinkedList ... { public IteratornewItr() { ... } } public class Collection ... { public IteratornewItr() { ... } } Example linkedList, collection :CLASSnewItr :SIGNATURE Method(newItrlinkedList)Method(newItrcollection)

12. Modelling properties • Unary relation: represents a property Class AbstractSet is abstract Collection is an Interface Collection.newItr is an abstract method Example abstractSet,collection :CLASSnewItr :SIGNATURE Abstract(abstractSet)Abstract(collection)Abstract(newItrcollection)

13. Modelling relations between individuals • Binary relation: represents a relation between two individuals LinkedList ‘extends’ AbstractSet ListIter ‘implements’ ListIterator Example linkedList, abstractSet, ListItr, ListIterator :CLASS Inherit(linkedList,abstractSet)Inherit(ListItr,ListIterator)

14. Binary relations: Member public class System { ... public static PrintStream out; ... } Example java.lang.system, printStream :CLASS Member(java.lang.system,printStream)

15. Binary relations: Aggregate Example linkedList, object :CLASS Aggregate(linkedList,object)

16. Binary relations: Call • Note that the Call relation abstracts away all information about the control-flow public class Test { public static void main(String[] args) { if (args.length == 0) System.out.print("Insufficient arguments"); ... Example test, printStream :CLASSmain, print:SIGNATURE Call(maintest, printprintStream)

17. 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 Callrelation in which the formal arguments are passed on to a method withsame signature Method MyServlet.doGet forwards the call to HttpServlet.doGet Example myServlet,httpServlet:CLASSdoGet:SIGNATURE Forward(doGetmyServlet, doGethttpServlet)

18. Binary relations: Create public classMyClass { publicvoid method() { ... if ... else ... ... for (int index = 0; ...) ... }...} Method MyClass.method may create an integer Example linkedList,listItr :CLASSlistIterator :SIGNATURE Produce(listIteratorlinkedList, listItr)

19. Binary relations: Produce public classLinkedList { ... publicListIteratorlistIterator(int index) { if (1 < 0) return new ListItr(index); } ... } Produce: A special kind of a Createrelation in which the new object is returned(typical to ‘factory methods’) Method LinkedList.listIterator may create and return a new ListItr Example linkedList,listItr :CLASSlistIterator :SIGNATURE Produce(listIteratorlinkedList, listItr)

20. 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 ... Example linkedList, collection:CLASS Inherit+(linkedList,collection)

21. Transitive relations II public class FileInputStream ... { public int read(byte[] b) throws IOException, NullPointerException { ... Example fileInputStream,ioException, nullPointerException :CLASSread,nullPointerException,ioException:SIGNATURE Call+(readfileInputStream, ioExceptionioException)Call+(readfileInputStream, nullPointerExceptionnullPointerException)

22. Case Study I: LinkedList and ListItr UML Class diagram LePUS3

23. Case Study II: java.io.XXReaderclasses public classLineNumberReaderextendsBufferedReader { …public void read() { …super.read(); … } … public void mark(intreadAheadLimit) { …super.mark(readAheadLimit); … } … public void reset() { …super.reset(); … } … ReaderExample bufferedReader,lineNumberReader :CLASSread, mark, reset:SIGNATURE Forward(readlineNumberReader, readbufferedReader)Forward(marklineNumberReader, markbufferedReader)Forward(resetlineNumberReader, resetbufferedReader) 23

24. 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!

25. Exercise (Cont.) • Which one is the most correct description of the purpose of a LePUS/Class-Z specification? • Each specification is model of a particular implementation • Each specification models an one or more possible implementations • Each specification models an aspect of one implementation abstracted for a particular purpose • Each specification models an aspect of one or more possible implementations abstracted for a particular purpose

26. 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?

27. Modelling large programsin LePUS3 and Class-Z Hierarchy constant 1-dim class and signature constants Total and Isomorphic predicates

28. Modelling sets of classes • 1-dimensional class constant: Stands for a (non-empty) set of specific static types Example ConcreteCollections:PCLASS

29. Modelling sets of methods (one signature) Clan: A set of methods with same signature Example ConcreteCollections :PCLASSnewItr :SIGNATURE All(Method, newItrConcreteCollections)

30. Modelling sets of methods (many signatures) • 1-dimensional signature constant: Stands for a (non-empty) set of specific method signatures Example 1-DimSignatureConstant:PSIGNATURE

31. Modelling sets of methods (many signatures) • Tribe: A set of methods in same class Example httpServlet:CLASSServletOps:PSIGNATURE All(Method, ServletOpshttpServlet)

32. Modelling sets of methods (many signatures): example Example BufferOps :PSIGNATUREbufferedReader : CLASS All(Method, BufferOps bufferedReader)

33. Modelling relations between sets: Total Every element in Domain is in relation Relation with some element in Range Total(BinaryRelation,Domain,Range)

34. Total predicate: example Example ConcreteCollections :PCLASScollection:CLASS Total(Inherit+,ConcreteCollections,collection)

35. Total predicate: example II Example ConcreteCollections :PCLASSobject:CLASS Total(Aggregate,ConcreteCollections,object)

36. Modelling relations between sets: Isomorphic Every element in Domain is in relation BinaryRelationwith a unique element in Range Isomorphic(BinaryRelation,Domain,Range)

37. Isomorphic predicate: example I Example bufferedReader, lineNumberReader:CLASSBufferOps:PSIGNATURE Inherit(lineNumberReader,bufferedReader)Isomorphic(Forward, ServletOpslineNumberReader,ServletOpsbufferedReader)

38. Isomorphic predicate: example II

39. Case study: collections & iterators in java.util Example ConcreteCollections, ConcreteIterators:PCLASS Isomorphic(Produce, newItrConcreteCollections,ConcreteIterators)

40. Collections & iterators in java.util (cont.)

41. Exercise • Translate the specification of collections and iterators to UML

42. Modelling class hierarchies • 1-dimensional hierarchy constant: a set of classes s.t. all inherit from one Example Hierarchy:HIERARCHY

43. Hierarchy: example Example CollectionsHrc:HIERARCHY

44. Modelling sets of methods revisited Example Hrc:HIERARCHYsig :SIGNATURE All(Method,sigHrc)

45. Example: the Lists hierarchy Example Lists:HIERARCHYadd:SIGNATURE All(Method,addLists)

46. Case study: collections & iterators in java.util Example CollectionsHrc, IteratorsHrc:HIERARCHYnext, newItr:SIGNATUREobject:CLASS Isomorphic(Produce, newItrCollectionsHrc, IteratorsHrc)Total(Return, nextIteratorsHrc, object)Total(Aggregate, CollectionsHrc, IteratorsHrc)

47. Example: lists, sets, and sorted sets Example Lists, Sets, SortedSets :HIERARCHYnewItr:SIGNATUREcollection :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)

48. Modelling application frameworks Variables

49. Variables vs. constants A class variable A class constant Example aClass, Object:CLASS

50. Variables vs. constants II Class x extends/implements class y LinkedList extends/ implements AbstractSet Example linkedList, abstractSet,x,y:CLASS Inherit(linkedList,abstractSet)Inherit(x,y)