Скачать презентацию Lecture notes in graduate module CE 839 Software Скачать презентацию Lecture notes in graduate module CE 839 Software

1228cfa98ad35ffa9ba3fccf079d2835.ppt

  • Количество слайдов: 81

Lecture notes in graduate module, CE 839: Software Design and Architecture, Autumn term 2008/9 Lecture notes in graduate module, CE 839: 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 Le. PUS 3 and Class-Z Modelling small programs Modelling large programs Modelling application frameworks Modelling design patterns 1

Le. PUS 3 and Class-Z: desiderata n Abstraction q Abstract ontology n q Offer Le. PUS 3 and Class-Z: desiderata n Abstraction q Abstract ontology n q Offer an answer: What are the conceptual building blocks of software design? Scaling: capture the building blocks of very large programs n n n Detailed notation—cluttered diagrams What NOT to model? What a specification should NOT represent? Rigour q q n Formal specification Verification Decidability: Tool support in “round-trip engineering” q q Tool support automates the verification process q n automated verification is possible in principle Allows us to “close the loop” of round-trip engineering Visualization (Optional q Offer a “picture” of a specification: n n q n Existing program: a ‘roadmap’ to the millions of lines of code A design motif: design pattern, architectural style Makes software easier to understand change Theory & practice q Be relevant to practical applications q Provide a sound foundation in a solid mathematical theory 2

Specification language: desiderata (cont. ) n Combine theory & practice It has long been Specification language: desiderata (cont. ) n 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 Le. PUS 3/Class-Z? Programs Design patterns Application frameworks (Collections What can be modelled in Le. PUS 3/Class-Z? Programs Design patterns Application frameworks (Collections in java. util) (The Iterator pattern) (Java Servlets) 4

What cannot be modelled in Le. PUS 3/Class. Z? n Temporal relations q q What cannot be modelled in Le. PUS 3/Class. Z? n Temporal relations q q q n Strategic design q q n ‘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 q Le. PUS 3 and Class-Z model object-oriented programs 5

Tool support in Le. PUS 3 and Class-Z Design Formal specification Software modelling Software Tool support in Le. PUS 3 and Class-Z Design Formal specification Software modelling Software visualization Forward engineering (Verification) Reverse engineering (Design Recovery) interface Collection. . . { public Iterator iterator() {. . . } } public class Linked. List. . . { public Iterator iterator() {. . . } } Implementation Applications App. frameworks Class libraries

Le. PUS 3 vs. Class-Z n Specifications can be expressed in one of two Le. PUS 3 vs. Class-Z n Specifications can be expressed in one of two ways: q q n Le. PUS 3: Visual, similar to UML Class Diagrams Class-Z: symbolic, similar to Z Students are only required to learn one of the notations Le. PUS 3 Example java. lang. system, print. Stream : CLASS Member(java. lang. system, print. Stream) Class-Z 7

The genealogy of Le. PUS 3 and Class-Z n n Definition: As a subset The genealogy of Le. PUS 3 and Class-Z n n Definition: As a subset of first-order predicate calculus (classical logic) Official reference manual: q n A. H. Eden, E. Gasparis, J. Nicholson. "Le. PUS 3 and Class-Z Reference Manual". University of Essex, Tech. Rep. CSM 474, ISSN 1744 -8050 (2007). http: //lepus. org. uk/refman/refman. xml Historical roots: q q Le. PUS 3: Le. PUS [Eden 2001]—Languag. E for Pattern Uniform Specification Class-Z: Z [Spivey] 8

Modelling small programs in Le. PUS 3 and Class-Z Class and signature constants Unary Modelling small programs in Le. PUS 3 and Class-Z Class and signature constants Unary relation symbols Binary relation symbols 9

Modelling individual classes n class constant: represents any specific static type such as a Modelling individual classes n class constant: represents any specific static type such as a class, Java interface, and primitive types class Linked. List interface Collection primitive type int Example linked. List, collection, int : CLASS 10

Modelling individual methods n signature constant: represents a specific ‘signature’ of (one or more) Modelling individual methods n signature constant: represents a specific ‘signature’ of (one or more) methods A method with signature new. Itr is defined in class Collection A method with signature new. Itr is defined in class Linked. List Example linked. List, collection : CLASS new. Itr : SIGNATURE Method (new. Itr linked. List) Method (new. Itr collection) public class Linked. List. . . { public Iterator new. Itr() {. . . } } public class Collection. . . { public Iterator new. Itr() {. . . } 11 }

Modelling properties n Unary relation: represents a property Class Abstract. Set is abstract Example Modelling properties n Unary relation: represents a property Class Abstract. Set is abstract Example Collection is an Interface Collection. new. Itr is an abstract method abstract. Set, collection : CLASS new. Itr : SIGNATURE Abstract (abstract. Set) Abstract (collection) Abstract (new. Itr collection) 12

Modelling relations between individuals n Binary relation: represents a relation between two individuals Linked. Modelling relations between individuals n Binary relation: represents a relation between two individuals Linked. List ‘extends’ Abstract. Set List. Iter ‘implements’ List. Iterator Example linked. List, abstract. Set, List. Itr, List. Iterator : CLASS Inherit(linked. List, abstract. Set) Inherit(List. Itr, List. Iterator) 13

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

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

Binary relations: Call n Note that the Call relation abstracts away all information about Binary relations: Call n 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, print. Stream : CLASS main, print : SIGNATURE Call(main test, print. Stream) 16

Binary relations: Forward public class My. Servlet extends Http. Servlet { public void do. Binary relations: Forward public class My. Servlet extends Http. Servlet { public void do. Get(Http. Servlet. Request rq, Http. Servlet. Response rs) { super. do. Get(rq, rs); } Forward: A special kind of a Call relation in which the formal arguments are passed on to a method with same signature Method My. Servlet. do. Get forwards the call to Http. Servlet. do. Get Example my. Servlet, http. Servlet : CLASS do. Get : SIGNATURE Forward(do. Get my. Servlet, do. Get http. Servlet) 17

Binary relations: Create public class My. Class { public void method() {. . . Binary relations: Create public class My. Class { public void method() {. . . if. . . else. . . for (int index = 0; . . . ). . . } Method My. Class. method may create an integer Example linked. List, list. Itr : CLASS list. Iterator : SIGNATURE Produce(list. Iterator linked. List, list. Itr) 18

Binary relations: Produce public class Linked. List {. . . public List. Iterator list. Binary relations: Produce public class Linked. List {. . . public List. Iterator list. Iterator(int index) { if (1 < 0) return new List. Itr(index); }. . . } Produce: A special kind of a Create relation in which the new object is returned (typical to ‘factory methods’) Method Linked. List. list. Iterator may create and return a new List. Itr Example linked. List, list. Itr : CLASS list. Iterator : SIGNATURE Produce(list. Iterator linked. List, list. Itr) 19

Modelling indirect relations n Transitive relation: represents possibly indirect relation (the ‘transitive closure’ of Modelling indirect relations n Transitive relation: represents possibly indirect relation (the ‘transitive closure’ of a binary relation) interface Collection {. . . class Abstract. List implements Collection {. . . class Abstract. Set extends Abstract. List . . . class Linked. List extends Abstract. Set. . . Example linked. List, collection : CLASS Inherit+(linked. List, collection) 20

Transitive relations II public class File. Input. Stream. . . { public int read(byte[] Transitive relations II public class File. Input. Stream. . . { public int read(byte[] b) throws IOException, Null. Pointer. Exception {. . . Example file. Input. Stream, io. Exception, null. Pointer. Exception : CLASS read, null. Pointer. Exception, io. Exception : SIGNATURE Call +(read file. Input. Stream, io. Exception) Call +(read file. Input. Stream, null. Pointer. Exception) 21

Case Study I: Linked. List and List. Itr Le. PUS 3 UML Class diagram Case Study I: Linked. List and List. Itr Le. PUS 3 UML Class diagram 22

Case Study II: java. io. XXReader classes public class Line. Number. Reader extends Buffered. Case Study II: java. io. XXReader classes public class Line. Number. Reader extends Buffered. Reader { … public void read() { … super. read(); … } … public void mark(int read. Ahead. Limit) { … super. mark(read. Ahead. Limit); … } … public void reset() { … super. reset(); … } … Reader. Example buffered. Reader, line. Number. Reader : CLASS read, mark, reset : SIGNATURE Forward(read line. Number. Reader, read buffered. Reader) Forward(mark line. Number. Reader, mark buffered. Reader) Forward(reset line. Number. Reader, reset buffered. Reader) 23

Exercise n n “Translate” the Le. PUS 3 chart in the case study into Exercise n n “Translate” the Le. PUS 3 chart in the case study into a Class -Z specification Use either Class-Z or Le. PUS to model three DIFFERENT specifications of the classes Collection, Iterator, Linked. List, and List. Itr in the package java. util. q q q 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. ) n Which one is the most correct description of the purpose Exercise (Cont. ) n Which one is the most correct description of the purpose of a Le. PUS/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. ) n How many ways can you model a Java program in Exercise (Cont. ) n How many ways can you model a Java program in which class My. Class has a method therein with the signature method(String arg) which throws an exception of class My. Exception in Le. PUS 3 or Class-Z? 26

Modelling large programs in Le. PUS 3 and Class-Z Hierarchy constant 1 -dim class Modelling large programs in Le. PUS 3 and Class-Z Hierarchy constant 1 -dim class and signature constants Total and Isomorphic predicates 27

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

Modelling sets of methods (one signature) n Clan: A set of methods with same Modelling sets of methods (one signature) n Clan: A set of methods with same signature Example Concrete. Collections : PCLASS new. Itr : SIGNATURE All(Method , new. Itr Concrete. Collections) 29

Modelling sets of methods (many signatures) n 1 -dimensional signature constant: Stands for a Modelling sets of methods (many signatures) n 1 -dimensional signature constant: Stands for a (nonempty) set of specific method signatures Example 1 -Dim. Signature. Constant : PSIGNATURE 30

Modelling sets of methods (many signatures) n Tribe: A set of methods in same Modelling sets of methods (many signatures) n Tribe: A set of methods in same class Example http. Servlet : CLASS Servlet. Ops : PSIGNATURE All(Method , Servlet. Ops http. Servlet) 31

Modelling sets of methods (many signatures): example Example Buffer. Ops : PSIGNATURE buffered. Reader Modelling sets of methods (many signatures): example Example Buffer. Ops : PSIGNATURE buffered. Reader : CLASS All(Method , Buffer. Ops buffered. Reader) 32

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

Total predicate: example Example Concrete. Collections : PCLASS collection : CLASS Total(Inherit+, Concrete. Collections, Total predicate: example Example Concrete. Collections : PCLASS collection : CLASS Total(Inherit+, Concrete. Collections, collection) 34

Total predicate: example II Example Concrete. Collections : PCLASS object : CLASS Total(Aggregate , Total predicate: example II Example Concrete. Collections : PCLASS object : CLASS Total(Aggregate , Concrete. Collections, object) 35

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

Isomorphic predicate: example I Example buffered. Reader, line. Number. Reader : CLASS Buffer. Ops Isomorphic predicate: example I Example buffered. Reader, line. Number. Reader : CLASS Buffer. Ops : PSIGNATURE Inherit(line. Number. Reader, buffered. Reader) Isomorphic(Forward, Servlet. Ops line. Number. Reader, Servlet. Ops buffered. Reader) 37

Isomorphic predicate: example II 38 Isomorphic predicate: example II 38

Case study: collections & iterators in java. util Example Concrete. Collections, Concrete. Iterators : Case study: collections & iterators in java. util Example Concrete. Collections, Concrete. Iterators : PCLASS Isomorphic(Produce, new. Itr Concrete. Collections, Concrete. Iterators) 39

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

Exercise n Translate the specification of collections and iterators to UML 41 Exercise n Translate the specification of collections and iterators to UML 41

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

Hierarchy: example Example Collections. Hrc : HIERARCHY 43 Hierarchy: example Example Collections. Hrc : HIERARCHY 43

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

Example: the Lists hierarchy Example Lists : HIERARCHY add : SIGNATURE All(Method , add Example: the Lists hierarchy Example Lists : HIERARCHY add : SIGNATURE All(Method , add Lists) 45

Case study: collections & iterators in java. util Example Collections. Hrc, Iterators. Hrc : Case study: collections & iterators in java. util Example Collections. Hrc, Iterators. Hrc : HIERARCHY next, new. Itr : SIGNATURE object : CLASS Isomorphic(Produce, new. Itr Collections. Hrc, Iterators. Hrc) Total(Return, next Iterators. Hrc, object) 46 Total(Aggregate , Collections. Hrc, Iterators. Hrc)

Example: lists, sets, and sorted sets Example Lists, Sets, Sorted. Sets : HIERARCHY new. Example: lists, sets, and sorted sets Example Lists, Sets, Sorted. Sets : HIERARCHY new. Itr : SIGNATURE collection : CLASS Total(Inherit+, Lists, collection) Total(Inherit+, Sets, collection) Total(Inherit+, Sorted. Sets, collection) Method (new. Itr collection) All(Method , new. Itr Lists) All(Method , new. Itr Sets) All(Method , new. Itr Sorted. Sets) 47

Modelling application frameworks Variables 48 Modelling application frameworks Variables 48

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

Variables vs. constants II Class x extends/ implements class y Linked. List extends/ implements Variables vs. constants II Class x extends/ implements class y Linked. List extends/ implements Abstract. Set Example linked. List, abstract. Set, x, y : CLASS Inherit(linked. List, abstract. Set) Inherit(x, y) 50

Assignments n n A specification with variables is only meaningful wrt a specific assignment Assignments n n A specification with variables is only meaningful wrt a specific assignment Example: Assignment-1 q q n Example: Assignment-2 q q n n x is assigned to Linked. List y is assigned to Abstract. Set y is assigned to Linked. List x is assigned to Abstract. Set 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 Servlet class must extend class HTTPServlet class can be any class Example: Java Servlets Servlet class must extend class HTTPServlet class can be any class that satisfies the relations Each method in your Servlet must forward call to respective method in superclass Servlet class must override a particular set of methods Java. Servlet http. Servlet, user. Servlet : CLASS Servlet. Ops : P(SIGNATURE) Isomorphic(Forward, Servlet. Ops user. Servlet, Servlet. Ops http. Servlet) Inherit(user. Servlet, http. Servlet) 52

Variables vs. constants: example I A specific implementation Any Java Servlet public class Hello. Variables vs. constants: example I A specific implementation Any Java Servlet public class Hello. Text extends Http. Servlet { public void do. Get(Http. Servlet. Request request, Http. Servlet. Response response) { super. do. Get(request, response); response. set. Content. Type("text/plain"); Print. Writer out = response. get. Writer(); out. println("Hello World"); } } 53

Variables vs. constants: example II Collections in java. util Collections. In. Java. Util Collections, Variables vs. constants: example II Collections in java. util Collections. In. Java. Util Collections, Iterators : HIERARCHY next, new. Itr : SIGNATURE object : CLASS Isomorphic(Produce, new. Itr Collections, Iterators) Return(next Iterators, object) Iterator pattern Iterator Aggregates, Iterators : HIERARCHY create. Iterator, next : SIGNATURE object : CLASS Isomorphic(Produce, create. Iterator Aggregates, Iterators) Return(next Iterators, object ) 54

Variables vs. constants: example III Composite in java. awt Composite pattern 55 Variables vs. constants: example III Composite in java. awt Composite pattern 55

Case study: Enterprise Java. Beans From [Monson-Haefel 2001]: 1. “Every bean [class] obtains an Case study: Enterprise Java. Beans 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 ejb. Create() and ejb. Post. Create() 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 ejb. Create() and ejb. Post. Create() methods on the bean class. 5. [An implementation for the bean’s home interface is generated by the container. ]” 56

Modelling Enterprise Java. Beans I “Every bean [class] obtains an EJBContext object, which is Modelling Enterprise Java. Beans I “Every bean [class] obtains an EJBContext object, which is a reference to the container” “The home interface extends the. . . javax. ejb. EJBHome interface” 57

Modelling Enterprise Java. Beans II “A home [interface] may have many create() methods, … Modelling Enterprise Java. Beans II “A home [interface] may have many create() methods, … , each of which must have corresponding ejb. Create() and ejb. Post. Create() methods in the bean class. The number and datatype of the arguments of each create() are left up to the bean developer “When a create() method is invoked on the home interface, the container delegates the invocation to the corresponding ejb. Create() and ejb. Post. Create() methods on the bean class” 58

Summary: Enterprise Java. Beans 59 Summary: Enterprise Java. Beans 59

Modelling design patterns The ‘gang of four’ patterns: Iterator, Proxy, Composite, Observer, Factory Method, Modelling design patterns The ‘gang of four’ patterns: Iterator, Proxy, Composite, Observer, Factory Method, Adapter (Object), Adapter (Class), Strategy 60

Iterator pattern Iterator Aggregates, Iterators : HIERARCHY create. Iterator, next : SIGNATURE Elements : Iterator pattern Iterator Aggregates, Iterators : HIERARCHY create. Iterator, next : SIGNATURE Elements : PCLASS Isomorphic(Produce, create. Iterator Aggregates, Iterators) Total(Return, next Iterators, Elements) Total(Aggregate , Aggregates, Elements) 61

Proxy pattern Proxy client, subject , proxy , real. Subject : CLASS Ops-1, Ops-2, Proxy pattern Proxy client, subject , proxy , real. Subject : CLASS Ops-1, Ops-2, Local. Requests, Remote. Requests : PSIGNATURE Abstract (subject ) Total(Call, Ops-1 client, Local. Requests subject ) Total(Call, Ops-2 Client, Remote. Requests subject ) Total(Call, Remote. Requests proxy , Remote. Requests real. Subject) Method (Local. Requests proxy ) Member(proxy , real. Subject) Inherit(proxy , subject ) Inherit(real. Subject, subject ) 62

Composite pattern Composite component, composite : CLASS Leaves : PCLASS Composite. Ops, Component. Ops Composite pattern Composite component, composite : CLASS Leaves : PCLASS Composite. Ops, Component. Ops : PSIGNATURE Abstract (component) All(Method , Component. Ops Leaves) All(Method , Composite. Ops composite) Inherit(composite, component) Total(Inherit, Leaves, component) Aggregate (composite, component) Isomorphic(Forward, Component. Ops composite, Component. Ops component) 63

Observer pattern Observer subject , concrete. Subject : CLASS notify, get. State , update Observer pattern Observer subject , concrete. Subject : CLASS notify, get. State , update , attach , detach , constructor, destructor : SIGNATURE Set. State : PSIGNATURE Observers : HIERARCHY Abstract (subject ) Inherit(concrete. Subject, subject ) Total(Call, Set. State concrete. Subject, notify subject ) Total(Call, notify subject , update Observers) Total(Call, update Observers, get. State concrete. Subject) Total(Call, constructor Observers, attach subject ) Total(Call, destructor Observers, detach subject ) 64 Members(subject , Observers)

Factory Method pattern Factory. Method Factories, Products : HIERARCHY factory. Method : SIGNATURE Isomorphic(Produce, Factory Method pattern Factory. Method Factories, Products : HIERARCHY factory. Method : SIGNATURE Isomorphic(Produce, factory. Method Factories, Products) 65

Adapter (Class) pattern Class. Adapter client, target, adapter, adaptee : CLASS Operations, Requests, Specific. Adapter (Class) pattern Class. Adapter client, target, adapter, adaptee : CLASS Operations, Requests, Specific. Requests : PSIGNATURE Abstract (target) Total(Call, Operations client, Requests target) Total(Call, Requests adapte r, Specific. Requests adapte e) Inherit(adapter, target) Inherit(adapter, adaptee) 66

Adapter (Object) pattern Object. Adapter client, target, adapter, adaptee : CLASS Operations, Requests, Specific. Adapter (Object) pattern Object. Adapter client, target, adapter, adaptee : CLASS Operations, Requests, Specific. Requests : P(SIGNATURE) Abstract (target) Total(Call, Operations client, Requests target) Total(Call, Requests adapte r, Specific. Requests adapte e) Inherit(adapter, target) Member(adapter, adaptee) 67

Strategy pattern Strateg y client, context : CLASS request, algorithm : SIGNATURE Interface : Strategy pattern Strateg y 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 Le. PUS 3 and Class-Z 69 Tool support in Le. PUS 3 and Class-Z 69

Two-Tier Programming Design Formal specification Software modelling Software visualization Forward engineering (Verification) Reverse engineering Two-Tier Programming Design Formal specification Software modelling Software visualization Forward engineering (Verification) Reverse engineering (Design Recovery) interface Collection. . . { public Iterator iterator() {. . . } } public class Linked. List. . . { public Iterator iterator() {. . . } } Implementation Applications App. frameworks Class libraries

The Two-Tier Programming Toolkit n Round-trip engineering n Supports: q q n Specification & The Two-Tier Programming Toolkit n Round-trip engineering n Supports: q q n Specification & verification (forward engineering) Visualization (reverse engineering) http: //ttp. essex. ac. uk 71

The TTP Toolkit (cont. ): Specification in Le. PUS 3 72 The TTP Toolkit (cont. ): Specification in Le. PUS 3 72

The TTP Toolkit (cont. ): Specification in Class-Z 73 The TTP Toolkit (cont. ): Specification in Class-Z 73

The TTP Toolkit (cont. ): Verification 74 The TTP Toolkit (cont. ): Verification 74

The TTP Toolkit (cont. ): Visualization 75 The TTP Toolkit (cont. ): Visualization 75

Exercises 1. Summarize the differences between Le. PUS 3/Class-Z and UML: 1. 1 Compare Exercises 1. Summarize the differences between Le. PUS 3/Class-Z and UML: 1. 1 Compare the Le. PUS 3 chart with the UML Class diagram of Linked. List and the List. Itr classes 1. 2 Use UML to model the Collection and the Iterator hierarchies in Java. util. How is this diagram different from the Le. PUS 3/Class-Z specification? 1. 3 Use UML to model Java Servlets. How is this diagram different from the Le. PUS 3/Class-Z specification? 1. 4 Use UML to model one of the design patterns. How is this diagram different from the Le. PUS 3/Class-Z specification? 2. List four abstraction mechanisms in Le. PUS 3/Class-Z 76

Exercises (cont. ) 3. Compare the Le. PUS 3/Class-Z Specification of each one of Exercises (cont. ) 3. Compare the Le. PUS 3/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 Le. PUS 3/Class-Z the following statements: 4. 1 Exercises (cont. ) 4. Specify in Le. PUS 3/Class-Z the following statements: 4. 1 “There exists a method in class My. Class which creates instances of class String” Answer: 78

Le. PUS 3 quick reference n constants and variables 79 Le. PUS 3 quick reference n constants and variables 79

Le. PUS 3 quick reference (cont. ) Methods Relations and predicates An individual method Le. PUS 3 quick reference (cont. ) Methods Relations and predicates An individual method A set of methods of same signature A set of methods of different signature Total predicate Isomorphic predicate 80

References n Legend: Key to Le. PUS 3 and Class-Z Symbols [. pdf] <http: References n Legend: Key to Le. PUS 3 and Class-Z Symbols [. pdf] n A. H. Eden, J. Nicholson. Object-oriented modelling: Theory and Practice. Unpublished manuscript (ask me for a copy) n A. H. Eden, E. Gasparis, J. Nicholson. "Le. PUS 3 and Class-Z Reference Manual". University of Essex, Tech. Rep. CSM-474, ISSN 1744 -8050 (2007). n A. H. Eden, E. Gasparis, J. Nicholson. "The 'Gang of Four' Companion: Formal specification of design patterns in Le. PUS 3 and Class-Z. “ University of Essex, Tech. Rep. CSM-472, ISSN 1744 -8050 (2007). n 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