1 / 14

Aspects and Modularity: The Hope and the Challenge

Aspects and Modularity: The Hope and the Challenge. Jonathan Aldrich Institute for Software Research International School of Computer Science Carnegie Mellon University. Why Modularity?. Protect client code from changes to design decisions encapsulated within a module [Parnas, others]

jaunie
Télécharger la présentation

Aspects and Modularity: The Hope and the Challenge

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. Aspects and Modularity:The Hope and the Challenge Jonathan Aldrich Institute for Software Research International School of Computer Science Carnegie Mellon University

  2. Why Modularity? • Protect client code from changes to design decisions encapsulated within a module • [Parnas, others] • Protect invariants of module code from ill-behaved clients • [Milner, others]

  3. Aspects: A New Hope Key benefit: capture concerns more locally and consistently • Better protects clients from change by localizing crosscutting concerns • Can be used to consistently enforce invariants of a module

  4. Aspects: A Double-Edged Light-Saber? • This works when you use AOP to modularize a concern • What happens when the client of a module uses AOP?

  5. Aspects: The Phantom Menace • Aspect-oriented clients can become dependent on details of a module’s implementation • Aspect-oriented clients can break a module’s invariants

  6. Non-Solution: Read-Only Aspects • AOP clients may still depend on information that might change • Even non-mutator AOP clients can break invariants • Untrusted code can view sensitive data • Aspects can create new objects with broken invariants • Many concerns require mutator aspects

  7. Non-Solution: Semantic Pointcuts • Control flow, data flow pointcuts are more robust • Still can be broken if control/data flow does not exactly match problem • Only one kind of semantic pointcut is a solution: Do what I mean! We say this already with interfaces!

  8. Non-Solution: Semantic Pointcuts • Control flow, data flow pointcuts are more robust • Still can be broken if control/data flow does not exactly match problem • Only one kind of semantic pointcut is a solution: Do what I mean! We say this already with interfaces!

  9. Non-Solution: Semantic Pointcuts • Control flow, data flow pointcuts are more robust • Still can be broken if control/data flow does not exactly match problem • Only one kind of semantic pointcut is a solution: Do what I mean! We say this already with interfaces!

  10. Solution: Interfaces • Use Interfaces to Mediate Interaction • Aspects may advise entry/exit join points of a module • Aspects may advise pointcuts explicitly exported by a module • “do what I mean” by this pointcut • Other advice is prohibited • Module changes which preserve interface pointcuts also preserve client behavior • Can be formalized and proved for simple pointcuts • Aldrich, FOAL ‘04, ECOOP ’05 • Work needed to extend to practical system • Interfaces also enforce internal invariants This story is old…but controversial in AOP!

  11. Solution: Interfaces • Use Interfaces to Mediate Interaction • Aspects may advise entry/exit join points of a module • Aspects may advise pointcuts explicitly exported by a module • “do what I mean” by this pointcut • Other advice is prohibited • Module changes which preserve interface pointcuts also preserve client behavior • Can be formalized and proved for simple pointcuts • Aldrich, FOAL ‘04, ECOOP ’05 • Work needed to extend to practical system • Interfaces also enforce internal invariants This story is old…but controversial in AOP!

  12. Obliviousness is Bunk! • Well-known AOP “requirement” • Code does not have to be specifically prepared to receive AOP enhancements • Bunk because aspects depend on details of code • As soon as you advise it, code is no longer oblivious! • Can’t change code or rely on invariants obliviously (without knowing about aspects)

  13. Obliviousness is Bunk! • A proxy for what you really want: agility • Ease of change of crosscutting concerns • Modify a pointcut declaratively and locally within a module • After-the-factenhancement Tools could give it to you transparently View or modify a pointcut in an interface Even if it’s a reflection of a more global pointcut Add or modify a pointcut that cuts across interfaces This may require negotiation with another stakeholder (other developers, the user, the application architect)

  14. Obliviousness is Bunk! • A proxy for what you really want: agility • Ease of change of crosscutting concerns • Modify a pointcut declaratively and locally within a module • After-the-factenhancement • Maybe tools could give this to you transparently • View or modify a pointcut in an interface • Even if it’s a reflection of a more global pointcut • Add or modify a pointcut that cuts across interfaces • This may require negotiation with another stakeholder (other developers, the user, the application architect) • Insufficient to calculate one from the other • Both must be editable if you want both modularity and agility • Changes to pointcuts in interfaces of module require negotiation

More Related