1 / 42

Formal Specification of Object-Oriented Design

Formal Specification of Object-Oriented Design. Amnon H. Eden Department of Computer Science, University of Essex Research seminar given at the Department of Computer Science, University of Essex 25 October, 2003. Context. Abstractions Design Vs. Architecture. Levels of Abstraction.

helene
Download Presentation

Formal Specification of Object-Oriented Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formal Specification of Object-Oriented Design Amnon H. Eden Department of Computer Science, University of Essex Research seminar given at the Department of Computer Science, University of Essex 25 October, 2003

  2. Context Abstractions Design Vs. Architecture

  3. Levels of Abstraction Architecture Design while (true) do c := c - 1; d := d + 1; if c < 0 goto continue; continue: ... Implementation

  4. Software Architecture An emerging discipline • Origins: Perry & Wolf [92] • “Architectural Styles”: Shaw & Garlan [96] • Underlying formalisms • Z • Statecharts • finite automata • CSP • Architecture Description Languages (ADLs) • ACME • Rapide • UniCon • Wright, …

  5. Implementations • Programming languages • Denotational/operational semantics • Computational models • Turing machine, RAM machine, Abstract State Machines • Formal Languages • Lambda calculus, sigma calculus, …

  6. (Object-Oriented) Design • Design Methodologies • Notations • Heuristics • Design patterns • In particular: Gamma, Helm, Johnson & Vlissides [94] • Formalization?

  7. Objectives • Conceptual: • A formal ontology for OOD • A formal specification language • Patterns • Libraries & frameworks • Elegance • Reasoning capabilities • Pragmatic • Full integration with existing programming practice • Tool support • Visual specifications

  8. Design Models A Computational Model

  9. Program & Design Model class PMCreator: extends Creator {PMButton_FactoryMethod() { // ... new PMButton;} } interface Creator {} class WinCreator: extendsCreator {WinButton_FactoryMethod() { // Creation: new WinButton; // Invocation: exit();} } class PMButton {} class WinButton {} void exit() {}

  10. Denotation Function Given LÎ OOPL, A Denotation: Modelling function D: L®áUniverseD ,RelationsD ñ Abstract, Inherit, Create, Call, … Classes, methods Invoke Methods Create Inherit Classes

  11. Axiomatic Semantics Building Blocks of O-O Design

  12. º FactoriesÎH Hierarchy AbstractFactoryÎC ConcreteFactoriesÎ P(C) Abstract(AbstractFactory) Inherit(ConcreteFactories,AbstractFactory)

  13. Clans, Selection Operator PrimitiveOperations1Î S ClassesÎ P(C) PrimitiveOperation1ÄClasses

  14. Isomorphic Relations Factories, ProductAÎH CreateProductAÎS Create«(CreateProductAÄProducts, ProductA)

  15. LePUS Terms Predicates Operator

  16. Terms • Constants: Belong to a given domain EJBContextÎC • Variables: Range over a given domain bean:C

  17. Auxiliary Domains • P(X) Power set of X P(X)º{x | x Ì X} • H Domain of all hierarchies • H º{h Î P(C) | Hierarchy(h)} • S Domain of function signatures

  18. Predicates R®(S,T) ºTotal(R,S,T) º • "sÎS$tÎT ·R(s,t) R«(S,T) ºIsomorphic(R,S,T) º • "sÎS$tÎT ·R(s,t) • "tÎT$sÎS ·R(s,t) Hierarchy(h) º • Abstract(r) • "cÎh, c¹r· Inherit+®(c,r) Clan(F,C) º • DefinedIn«(F,C) • " f1,f2ÎF·SameSignature® (f1,f2) Tribe(F,C) º • " fÎF·Tribe(f,C)

  19. Selection Operator • Given a signature s, set of signatures S: • sÄC Selects methods in cÎCwith signature s • Result is a clan • SÄC Selects clans in cÎCwith signature s • Result is a tribe

  20. Specifications in LePUS Design Patterns Object-Oriented Design

  21. Products, Creators: H FactoryMethods :S Produce«(FactoryMethodsÄCreators,Products)Return«(FactoryMethodsÄCreators,Products) Factory-Method Pattern

  22. subject, concrete-subject :C observers:H attach, detach, notify, update, get-state:S SetState:P(S) ObserverPattern ReferenceToMany®(subject,Observers) Inherit(subject, concrete-subject) FirstArg®(attach,observers) FirstArg®(detach,observers) FirstArg®updateÄobservers,subject) Invoke®(SetStateÄconcrete-observer, notifyÄsubject) Invoke®(notifyÄsubject,updateÄObervers) Invoke®(updateÄObervers,attachÄsubject) Invoke®(updateÄObervers,detachÄsubject) Assign(attachÄsubject,sybject,observers)

  23. Elements, Visitors:H Accept:S Visit:P(S) FirstArg«(AcceptÄElements,Visitors) FirstArg«(VisitÄVisitors,Elements) Invocation«(AcceptÄElements,VisitÄVisitors) Invocation«(VisitÄVisitors,Elements) VisitorPattern Concision: Three isomorphic relations, one total relation, and many pages of documentation in one diagram

  24. Documentation Taken from the description of the Enterprise JavaBeans™: “Every bean obtains anEJBContext object, which is a reference directly to the container” “A bean's home interface may declare zero or more create() methods, each of which must have corresponding ejbCreate() andejbPostCreate() methods in the bean class. ”

  25. Enterprise JavaBeans™

  26. Reasoning

  27. Conformance (also Refinement) “Model-View-Controller” in Java Swing ... Conforms to the Observer pattern

  28. Projection creator, product:C factory-method:S Create(factory-methodÄfactory, product) Return(factory-methodÄfactory, product) creator, product:P(C) factory-method :S Create«(factory-methodÄ factory, product) Return«(factory-methodÄ factory, product)

  29. Factory Method Vs. Abstract Factory The difference is merely in the order of sets • Isomorphisms are preserved

  30. Two-Tier Programming Integrating Intentional With Extensional programming

  31. public class Observable { publicsynchronized void addObserver(Observer o) { ... } public void notifyObservers(Object arg) { ... } } class MyObservable extends Observable { public void access() { ... } public void mutate() { ... notifyObservers(); } } intrface Observer { void update(Observable); } class ScrollView extends Scrollbar implements Observer { … } class TextView extends TextField implements Observer { public TextView(Counter c) { ... } public void update(Observable o, Object counter) { ... } } Multiple Representations Source Code Intentional tier Pattern Extensional tier Design Model Instance of a pattern

  32. public class Observable { publicsynchronized void addObserver(Observer o) { ... } public void notifyObservers(Object arg) { ... } } class MyObservable extends Observable { public void access() { ... } public void mutate() { ... notifyObservers(); } } intrface Observer { void update(Observable); } class ScrollView extends Scrollbar implements Observer { … } class TextView extends TextField implements Observer { public TextView(Counter c) { ... } public void update(Observable o, Object counter) { ... } } Coordination Source Code Pattern Coordination Design Model Instance of a pattern

  33. public class Observable { publicsynchronized void addObserver(Observer o) { ... } public void notifyObservers(Object arg) { ... } } class MyObservable extends Observable { public void access() { ... } public void mutate() { ... notifyObservers(); } } intrface Observer { void update(Observable); } class ScrollView extends Scrollbar implements Observer { … } class TextView extends TextField implements Observer { public TextView(Counter c) { ... } public void update(Observable o, Object counter) { ... } } Coordination: Part I Source Code Parsing/ Reverse engineering Design Model

  34. Coordination: Part II <observers, observer, TextView, ScrollView> <observers.update,observer.update, TextView.update, ScrollView.update> … Design Model Instance of a pattern

  35. Coordination: Part III <Observers, Observers> <subject, observable> <concrete-subject, model> <Set-state, Mutators> <Observers.update, Observers.update> … Pattern Instance of a pattern

  36. Tool Support • The Software Architecture Lab, Concordia U. • Architectural Reflection projects: • Visualization tool • Specifications with a graphic editor • Parser for symbolic specifications • Reverse engineering from Java • In collaboration with IBM Research Centre, Haifa pattern AbstractFactory is FactoryMethods in P2(F), Creators in H, Products in P(H) where tribe (FactoryMethods, Creators), production <-> (FactoryMethods, Products), return_type <-> (FactoryMethods, Products).

  37. Implementation in Prolog • LePUS is readily implemented in PROLOG: • Supported activities: • Validation • Application • Recognition • Discovery FactoryMethod(hierarchy_structure (Creators_root, Creators_Leaves), hierarchy_structure (Products_root, Products_Leaves), FactoryMethods) :- clan(FactoryMethods,[Creators_root|Creators_Leaves]), isomorphic(production, FactoryMethods, [Products_root|Products_Leaves]).

  38. origin Limitations • “Design Models”: Static properties • Cannot give behavioural specifications • Relations are abstract • Cannot represent more thanone relationships between (Journey, Location) destination Journey Location

  39. Future Directions • Sample specifications • Common libraries & Frameworks • Behavioural specifications • Use Gurevich’s Abstract State Machines (“evolving algebras”) • Tool support • Forward and reverse engineering • Formalization of the visual language • Design visual primitives & operators • Visual semantics & syntax

  40. References D. E. Perry, A. L. Wolf (1992). "Foundation for the Study of Software Architecture." ACM SIGSOFT Software Engineering Notes Vol. 17, No. 4. M. Shaw, D. Garlan (1996). Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall. E. Gamma, R. Helm, R. Johnson, J. Vlissides (1994). Design Patterns: Elements of Reusable Object Oriented Software. Addison-Wesley

  41. Bibliography Full text: http://www.eden-study.org/ Ontology : A. H. Eden Y. Hirshfeld, "Principles in Formal Specification of Object Oriented Architectures.“CASCON 2001, November 5-8, 2001, Toronto, Canada. LePUS: A. H. Eden (2001). "Formal Specification of Object-Oriented Design." International Conference on Multidisciplinary Design in Engineering CSME-MDE 2001, November 21-22, 2001, Montreal, Canada. Visual Notation: A. H. Eden (2002). “Design Schemata.”Submitted: Annals of Software Engineering, Special Volume on Software Visualization.

  42. Bibliography (Cont.) The Patterns’ Wizard. A. H. Eden, J. Gil, A. Yehudai (1997). "Precise Specification and Automatic Application of Design Patterns." Proceedings of the Twelve IEEE International Automated Software Engineering Conference (ASE 1997), Lake Tahoe, Nevada Los Alamos, IEEE Computer Society Press, Nov. 3-5, 1997. Two-Tier Programming. A. H. Eden, J. Jahnke (2002) "Coordinating Software Evolution Via Two-Tier Programming," Coordination 2002, Lecture Notes in Computer Science 2315, pp. 149-159. Berlin: Springer-Verlag. Intention/Locality. A. H. Eden (2002). “Architecture, Design, Implementation.” Submitted: Journal of Software and System Modeling (SoSyM). Berlin: Springer.

More Related