1 / 14

Objects and Aspects: Language Support for Evolvability

Study OOP/AOP concepts, systems strengths/weaknesses, engineering benefits, formal reasoning, and modular reasoning in OOP/AOP systems. Research questions and paper discussions included.

franklin
Download Presentation

Objects and Aspects: Language Support for Evolvability

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. 15-819 Objects and Aspects:Language Support for Extensibility and Evolvability Jonathan Aldrich Fall, 2004

  2. Objects and Aspects • Goals • Capture problem domain more closely in code • Provide mechanisms for extensibility • Techniques • Inheritance, Subtyping, Dispatch, Pointcuts, Advice

  3. Course Goals • Understand most important OOP/AOP ideas • Analyze strengths and weaknesses of OOP/AOP systems • Develop insight into the engineering benefits of OOP/AOP • Develop open research questions

  4. Course Topics • Object-oriented programming • Language mechanisms • Type systems • Aspect-oriented programming • Emerging models • Engineering benefits and drawbacks • Formal reasoning • Formal models of objects and aspects • Modular reasoning in OOP and AOP systems • Questions • What topics would you like to emphasize? • What papers do you want to read?

  5. Topic Sign-Up • Sep 15. Prototypes – Jonathan Aldrich • Self: the Power of Simplicity • Sep 20. Multi-methods • Object-Oriented Multi-Methods in Cecil • Sep 22. Objects and Functions • Modular Typechecking for Hierarchically Extensible Datatypes and Functions • Sep 25. Traits and Mix-ins • Traits: Composable Units of Behavior • Sep 29. Scala • Web site and documentation

  6. Course Structure • This is a graduate-level research seminar • Not a lecture course: must actively participate • Expectations • Read the paper(s) before class • Present one or two lectures • Prepare slides • Discuss them with me before class

  7. Leading the Discussion • Assume people have read the paper • Summarize main idea • Go through examples • Compare to other work • Expressiveness: use code examples • Checking: what errors does it catch and/or miss? • Engineering: how does it aid or hinder software evolution? • Ask open-ended questions • You’re not giving a lecture!

  8. Why Objects? • Simula 67 – the first OO language • Goal: Executable models of complex systems • Technical properties • Inheritance • Facilitates code reuse • Subtyping between ADTs • Models classification hierarchies in real-world systems • Data type extensibility • Define new classes and their functionality • No need to change existing code

  9. Object Mechanisms • Prototypes • Object cloning instead of class instantiation • Multiple dispatch, value dispatch • Dispatch on argument types and values • Traits, Mixins • A clean way to compose object behavior

  10. OO Type Systems • Correlated families of types • F-bounded polymorphism • Family polymorphism • Typestate • Track interface changes to an object • Ownership • Enforcing “containment” of internal objects

  11. Reasoning about Inheritance • Effects • Want to specify effects in superclass, even though subclasses can add new mutable data • Invariants • Must be extended when new fields are added • Must be preserved with overriding

  12. Why Aspects? • Separation of concerns • Modularize “crosscutting concerns” • Those that are spread throughout program • E.g., display update, synchronization, security checks • Makes these concerns easier to evolve • Non-invasive extension • Want to extend existing objects with new behavior • Subclassing doesn’t help if “new” statements in existing code are fixed

  13. What is AOP? • Quantification • Can locally specify a set of events in the dynamic execution of a program • E.g., calls to all methods in the interface of a module • Pointcut: a named set of events, described with a logical predicate • Obliviousness • Can extend a program even if that program was not specifically prepared for the extension • E.g., add synchronization to unsynchronized data structures • Advice:a piece of code that is executed whenever the events in a pointcut are triggered

  14. AOP Research Questions • What can different AOP models express? • Is AOP useful in practice? • How does one formally model AOP? • How can one reason modularly in the presence of aspects?

More Related