90 likes | 262 Views
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.
E N D
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 • 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
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”
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
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)
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
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.
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
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?