1 / 8

Testbed for Aspect-Oriented Software Development: TAO

Testbed for Aspect-Oriented Software Development: TAO. Phil Greenwood and numerous other contributors. Various Barriers. Available systems lack complete documentation. Difficult to find AO and non-AO implementations for the same system.

delano
Download Presentation

Testbed for Aspect-Oriented Software Development: TAO

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. Testbed for Aspect-Oriented Software Development: TAO Phil Greenwood and numerous other contributors

  2. Various Barriers • Available systems lack complete documentation. • Difficult to find AO and non-AO implementations for the same system. • Need to guarantee that the non-AO and AO decompositions are good ones. • Difficult to find or develop from scratch a plausible “benchmark”. • many risks: time-consuming task, inherent bias, etc… • collaboration is the only alternative left. • Quantitative or qualitative indicators are often NOT ready for use. • Replication of studies becomes a pain.

  3. A Testbed for AOSD • Towards more scientific and cohesive research. • Serve as a communication and collaboration vehicle • Achieve widely-accepted exemplars, indicators, and data that can be reused and refined. • Facilitate the identification of “unknown” problems and benefits inherent to AOSD. • Effects throughout the lifecycle. • Bottlenecks specific to certain SE phases and their transitions. • Accelerate the progress in the area by offering context to pinpoint technique-specific problems.

  4. Testbed Elements Design Stability Study

  5. Completed Studies • “On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study” ECOOP 2007. • “A Comparative Study of Aspect-Oriented Requirements Engineering Approaches” ESEM 2007 • “On the Impact of Evolving Requirements-Architecture Dependencies: An Exploratory Study” CAiSE 2008 • “Pointcut Rejuvenation: Recovering Pointcut Expressions in Evolving Aspect-Oriented Software” ICSE 2009 (under review) • “Investigating Pointcut Fragility: An Exploratory Study” AOSD 2009 (under review) • “Semantic vs. Syntactic Compositions in Aspect-Oriented Requirements Engineering: an Empirical Study” AOSD 2009 (under review)

  6. On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study • Multi-dimensional analysis of AO and OO implementations which included: • Modularity Sustenance. • Observing ripple effects. • Aspect types which are susceptible to instability. • Satisfaction of basic design principles through the releases. • Outcome Highlights • AO solutions required less intrusive modifications. • Aspectual decompositions satisfy the open-closed principle. • AO modifications tended to propagate to seeming unrelated modules.

  7. A Comparative Study of Aspect-Oriented Requirements Engineering Approaches • Comparison of four eminent AORE approaches which involved analysing: • Time effectiveness (person-minutes). • Accuracy of their produced outcome. • Precision and recall of the models produced . • Identifying the activities that are the main bottlenecks in AORE approaches. • Main outcomes. • Composition specification and conflict analysis activities are the most time consuming. • Common framework for comparing AORE approaches in order to facilitate future AORE evaluation exercises.

  8. On the Impact of Evolving Requirements-Architecture Dependencies: An Exploratory Study • The goal of the analysis was to characterize: • How the nature of requirements’ dependencies can lead to tight or loose interconnections with architectural elements. • The most architecturally-significant requirements’ dependencies. • How the requirements’ dependencies evolve during maintenance changes. • Significant findings: • Conditional and service dependencies are architecturally significant. • Infrastructure dependency has high impact for adaptive change. • Rare to have isolated dependencies pull the architecture in various directions.

More Related