1 / 9

Theme: An Approach for Aspect-Oriented Analysis and Design

Theme: An Approach for Aspect-Oriented Analysis and Design. Authors: Elisa Baniassa Siobh ́an Clarke Conference: International Conference on Software Engineering Year: 2004 pp: 158 - 167 Poster By: Pratik Mehta. Summary of Paper.

luann
Download Presentation

Theme: An Approach for Aspect-Oriented Analysis and 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. Theme: An Approach for Aspect-Oriented Analysis and Design Authors: Elisa Baniassa Siobh ́an Clarke Conference: International Conference on Software Engineering Year: 2004 pp: 158 - 167 Poster By: Pratik Mehta

  2. Summary of Paper • Crosscutting behaviors can be easily identified as Aspects in the system • Some of the subtle behaviors may not be identified as aspects because they are hard to identify during the analysis of requirements • Thus, developer needs support for aspect identification and analysis in requirements documentation • THEME: is a model and a tool to - • Support and identify aspects in requirement specification • Help design level modeling of aspects and their composition • Check design decisions in the context of requirements

  3. Basic Background Information • Aspect orientation is encapsulating behavior that impacts the whole system. I.e Crosscutting behavior • Before encapsulating crosscutting behavior it must first be identified in the requirements • Identification of aspects in requirements is difficult because aspects are entangled with other behaviors and are described in multiple parts of requirements document • For example: “there was significant effort put in to identify and characterize that pre-fetching could be modeled as an aspect in the FreeBSD operating system”

  4. Basic Background Information • Three approaches to identifying aspects in early lifecycle: • Look for objects in the system first and then try to spot the tangled behavior as it becomes evident • Criticism of this approach: Developer will need to re-design as aspects are discovered later in the design process • Before the design process, scan requirements for typical aspect-style behavior such as logging, tracing • Criticism of this approach: Covers a narrow range of potential aspects and does not help in identifying crosscutting behavior • Apply AORE (Aspect Oriented Requirements Engineering) and target non-functional requirements as initial set of aspects. • Criticism of this approach: There are functional requirements which break down into complex interrelated behavior

  5. Why THEME ? • In order to Identify and model aspects: • Need to analyze relationships between all behaviors described in the requirements documentation • Need to support translation of results from this analyzed data into design models which can be implemented in code • Theme provides support for Aspect-Oriented development at: • Requirements Level (Theme/Doc), has four views • Action View • Clipped action view, which clusters requirements with particular behavior and shows which actions were chosen to crosscut others • Theme View: Depicts entities and actions of a cluster from clipped view • Augmented Theme View: Places Design decision into context of requirements • Design Level (Theme/UML)

  6. Example: Course Management System (CMS) • R1. Students can register for courses • R2. Students can un-register for courses • R3. When a studentregistersthen It must beloggedin their record • R4. When a student un-registers It must also be logged • R5. Professors can un-register students. • R6. When a professor un-registers a student it must be logged • R7. When a professor un-registers a student it must be flagged as special • R8. Professors can give marks for courses. • R9. When a professor gives a mark this must be logged in the record • KEY: BLUE: ACTIONS

  7. Two Inputs to create Action View: List of key actions identified by the developer Theme/Doc performs lexical analysis on the requirements text and generates action view Figure 1 show the valid action verbs: give, logged,register, un-register and flagged Register action as a theme designed separately.

  8. Critique of Paper • Need to compare in-depth Aspect Oriented Requirements Engineering to the Theme tool provided in this paper\ • Clear explanation of Theme/Doc with proper examples, but not augmented Theme/UML with examples • Traceability and scalability provided by the tool need to be described further and more complex examples of the design process should be given

  9. Questions ? • What are the three ways to approach aspect oriented analysis and design ? • How do we come up with register, un-register, give, flagged and logged as actions in Figure 1 from the requirements? • Do you think that this approach is traceable?

More Related