1 / 76

CS 586 – Aspect-Oriented Software Development Aspect-Oriented Design - Method

CS 586 – Aspect-Oriented Software Development Aspect-Oriented Design - Method. Bedir Tekinerdogan Billkent University, Dep artment of Computer Engineering Bilkent, Turkey, Ankara e:mail - bedir@cs.bilkent.edu.tr http://www.cs.bilkent.edu.tr/~bedir/. Table of Contents. Problem Statement

sybill-flowers
Download Presentation

CS 586 – Aspect-Oriented Software Development Aspect-Oriented Design - Method

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. CS 586 – Aspect-Oriented Software DevelopmentAspect-Oriented Design - Method Bedir TekinerdoganBillkent University, Department of Computer Engineering Bilkent, Turkey, Ankarae:mail - bedir@cs.bilkent.edu.tr http://www.cs.bilkent.edu.tr/~bedir/

  2. Table of Contents • Problem Statement • Scenario-based Analysis of Software Architecture • ASpectual SAAM (ASAAM) • Modeling Aspects using Domain Analysis

  3. Aspect-Oriented Programming • Crosscutting and tangling at code level • Modeling aspects at code level Aspect-Oriented Design • Modeling aspects at design level (Model) • Identifying aspects (Method)

  4. class Point { void setX(int x) { _x = x; } } DisplayTracker.updatePoint(this); Tracer.traceEntry(“Point.set”); Tracer.traceExit(“Point.set”); Current aspect identification approaches • In general ad-hoc • “aspects are for the picking...” • Usually based on code-analysis: “Assume the given example.... Concerns crosscuts code and is tangled in classes...”

  5. Systemic, tends to affect multiple components Affects performance/quality Cross-cuts, spread over different components Characteristics of an aspect...

  6. Problem Aspects?! Where? Requirements Analysis Domain Analysis Analysis Design Implementation Testing Solution Aspect identification...

  7. Systemic, cross-cuts and relates to quality… Hmmm… There is an aspect, and there, and there too, ooh and over there... Requirements Analysis Domain Analysis Analysis Design Implementation Testing Where are the aspects? software development

  8. Requirements Analysis Domain Analysis Too late! Analysis Design Missing early aspects. Difficult to model aspects. Implementation Testing Late Aspect Identification

  9. class Point { void setX(int x) { _x = x; } } DisplayTracker.updatePoint(this); Tracer.traceEntry(“Point.set”); Tracer.traceExit(“Point.set”); Modeling Aspects Alright, tracing is an aspect But what is tracing/ how to model this?

  10. Requirements Analysis Domain Analysis Analysis Design All relevant aspects can be identified. Modeling aspects from domain knowledge. Implementation Testing Early Aspect Identification

  11. What is a method? Webster's dictionary: • Method: 1: a procedure or process for attaining an object: as a (1): a systematic procedure, technique, or mode of inquiry employed by or proper to a particular discipline or art (2): a systematic plan followed in presenting material for instruction b (1): a way, technique, or process of or for doing something (2): a body of skills or techniques. • Methodology: A branch of philosophy dealing with the science of method; a system of methods and rules applied in a science.

  12. Rationale for method • Guidelines for production • Guidelines for verification • Provides logical consistency among the different processes and phases in design. • Helps to reduce possible errors • Helps to identify important progress milestones.

  13. Aspect-Oriented Method • Identifying • Specifying • Evaluating aspects • in a systematic way

  14. Rationale for aspect-oriented method • Guidelines for identification/production of aspects • Guidelines for verification of aspects • Provides logical consistency among the different processes and phases in design; consistency for/with aspects. • Helps to reduce possible errors in aspect-oriented programs/designs • Helps to identify important progress milestones.

  15. Method Software engineering Driver Monitoring system application layer support layer applicationn tools1 method layer methodm objects, classes inheritance CASE, OO compiler model layer modelo

  16. What is a method? • Artifacts • Rules (heuristics) If then .. If then .. • Process If then .. If then .. entities attributes inheritance If then .. If then .. If then .. Use cases associations classes STD

  17. Use case Monitor Driver Actions Track Steering Movement Track Brake Maneuvers Track Transmission Maneuvers Actor Monitor Example: Requirements Analysis • Models • use case • actor • Rules • Identify Actors • Identify Use Case • Draw the use case diagram • Process • Application

  18. Ok, but is there a method to identify aspects? Architecture Design Methods

  19. ASAAM: Aspectual Software Architecture Analysis Method Bedir TekinerdoganBillkent University, Department of Computer Engineering Bilkent, Turkey, Ankarae:mail - bedir@cs.bilkent.edu.tr http://www.cs.bilkent.edu.tr/~bedir/

  20. Contents • Software Architecture • Evaluating Architectures using Scenarios • SAAM • Example: Window Management System • Architectural Aspects • ASAAM • Conclusion & Discussions

  21. Describes (is) Structure Consisting of components which forms the foundation of the whole.... Architecture

  22. Intuitive notion of software architecture • Software Architecture represents the gross level structure of a software system. • Design : Implementation = • Software Architecture : Design

  23. aStudent theRegistrar aSection theTranscript getSectionsFor: return sections enrollInSection: takenCourse: prerequisite state of prereq takenCourse: prerequisite have prereq addStudent: enrolled enrolled Design, Realize and Test Architecture Requirements Analysis ....... ....... ....... ....... Software Architecture Design Analysis & Design Implementation public class Student {private String name; private int id; public String getName () return name} public void setName (String str){ name = str;} public int getId() {return id; } public void setId(int i) {id = i; } }

  24. Rationale for Software Architecture • Improved understanding because of a higher level abstract specification • Guides construction since it embodies earliest design decisions • Supports stakeholder communication • Support for large-grained reuse • Enables to evaluate system before it is implemented • Controls impact of change • Management of software development activities

  25. Implementing Architecture • Architecture is the earliest artifact • with the largest impact • where trade-offs are visible. • Implementing it requires lots of resources • time • money • manpower

  26. Therefore evaluate architecture early … • Analyzing for system qualities early in the life cycle allows for a comparison of architectural options. • Predict quality of system before it has been built • Evaluation/Analysis provides a mechanism for understanding how the system will evolve. • Identify potential risks • Evaluation later in the project: damage control

  27. Architecture (Re)definition Review Guidelines Quality Criteria no Architecture Ok? yes Go! Implement Architecture Software Architecture Evaluation

  28. Evaluation Techniques • Simulations • Mathematical Modeling • Question-based • Questionnaire-based • List of general open questions that apply to all software architectures (see project review guidelines). • Checklist-based • detailed set of questions • after experience of analyzing common set of systems • usually domain specific • Scenario-based analysis

  29. Scenarios • Scenario is a brief description of an interaction of a stakeholder with a system What if… What if… System What if… What if… What if…

  30. Stakeholders • Stakeholders: • end users • managers • developers • maintainers • analysts • designer • testers • customers • ....

  31. Quality • Correctness does software do what its supposed to? • Flexibility how easy is it to change it? • Security how secure is it? • Interoperability does it interface easily? • Maintainability how easy is it to repair? • Portability how easy is it to transport? • Usability how easy is it to use? • Reliability how often will it fail? • Reusability is it reusable in other systems? • Safety does it prevent hazards? • Verifiability can it be tested?

  32. Qualities are vague… • Is the system modifiable? Sure! We have just to change that parameter in this component Hmmm, no this is not that easy, we have to change too many components… What if we change the color of the user interface, is that possible…? What about changing the data format?

  33. Quality depends on context • We cannot completely define the context • but we can focus on important parts of the context • and describe desired or anticipated use of the system • so that quality considerations become more clear. • Scenarios help to provide a view of the context

  34. Stakeholders-Quality • Different stakeholders see quality in different terms : • End user • Usability • Understandability • Functionality • Customer • Efficiency • Developer • Reusability • Interoperability • Portability • Maintainer • maintainability • Tester • Testability Every stakeholder will define specific set of scenarios

  35. Example Scenarios • Use Scenario • User downloads document from the file server • Change scenario • The relational database is mapped to an object-oriented database • Exploratory scenarios • Half of the servers go down during operation

  36. Scenarios should be specific • S1. System fails • what is system? which component fails? • why does it fail? • when? • S1’. Database is destroyed and the data is recovered from the backup files.

  37. How to extract scenarios • Brainstorming Session with different stakeholders • Collect Scenarios of different stakeholders • Workshop • Look at domain • Possible uses of system • Risks • Look at other systems • Compare systems • Experiences • Reuse Scenarios • Evaluate scenarios • Select scenarios

  38. Scenario-based evaluation techniques • SAAM • Scenario-Based Architecture Analysis Method • SAAMCS • SAAM Founded on Complex Scenario • ESAAMI • Extending SAAM by Integration In The Domain • SAAMER • Software Architecture Analysis Method Evolution and Reusability • ATAM • Architecture Trade-off Analysis Method • SBAR • Scenario-Based Architecture Re-engineering • ALPSM • Architecture Level Prediction of Software Maintenance • SAEM • A Software Architecture Evaluation Model L.Dobrica & E.Niemela, A Survey on Software Architecture Analysis Methods,IEEE Transactions on Software Engineering, Vol 28, No. 7, pp. 638-654, July 2002.

  39. Example: SAAM • Describe candidate architectures • Develop scenarios • Perform scenario evaluation • Reveal scenario interactions • Generate overall evaluations

  40. A window management system includes different important components such as EventManager for I/O controlling, e.g. keyboard and mouse events; Process-Manager for scheduling and managing application processes; ScreenManager for maintaining the integrity of the screen; WindowManager for managing the windows that are related to the application processes. Example: Window Management System

  41. <<arch>> EventManager communicates <<arch>> ScreenManager <<arch>> WindowManager update screen notifies <<arch>> ProcessManager 1. Describe Candidate Architectures • Identify alternative architectures • domain model • patterns • Structures should be selected based on functional and quality requirements

  42. 2. Develop and Prioritize Scenarios • Develop task scenarios that the system must support • Develop change scenarios which describe anticipated changes of system • Capture all important scenarios

  43. Develop Scenarios - Example • S1. Start multiple processes at the same time. • S2. Change color of widgets in the window. • S3. Close all open windows • S4. Change screen resolution • S5. Enter a command to start application process • S6. Move the main window • S7. Screen saver is activated • S8. Resize a window • S9. Terminate a process • S10. Interrupt a process • S11. Change look-and-feel style on run-time. • S12. Add voice control • S13. A failure occurs and the system shuts down. • S14. Provide dual display screen. • S15. Use multiple desktops. • S16. Monitor activities of the user • S17. Provide touch screen and light pen as input • S18. A memory overflow due to many opened windows • S19. Port system to command-based operation system • S20. Minimize windows after idle time

  44. Identify Stakeholders • Who are the important stakeholders? • What is their interest? • Interview stakeholders • iterate until sufficient coverage (never sure)

  45. Classify Scenarios • Direct Scenarios • can be executed by the system without modification • Indirect scenarios • require modifications to the system • addition/removal/update of architectural components or relations • Whether a scenario is direct or indirect depends on both architecture and the scenario itself

  46. S1. Start multiple processes at the same time. S2. Change color of widgets in the window. S3. Close all open windows S4. Change screen resolution S5. Enter a command to start application process S6. Move the main window S7. Screen saver is activated S8. Resize a window S9. Terminate a process S10. Interrupt a process <<arch>> EventManager communicates <<arch>> ScreenManager <<arch>> WindowManager update screen notifies <<arch>> ProcessManager Classify Scenarios - Example Direct Scenarios Indirect Scenarios • S11. Change look-and-feel style on run-time. • S12. Add voice control • S13. A failure occurs and the system shuts down. • S14. Provide dual display screen. • S15. Use multiple desktops. • S16. Monitor activities of the user • S17. Provide touch screen and light pen as input • S18. A memory overflow due to many opened windows • S19. Port system to command-based operation system • S20. Minimize windows after idle time

  47. 3. Perform Scenario Evaluation • For each indirect scenario • identify the components and relations that must be modified (added, removed or updated) • provide an estimation of the difficulty of the modification • Difficulty of modification is based on the architectural components that need to be modified.

  48. Perform Scenario Evaluation - Example Indirect Scenario Impacts • S11. Change look-and-feel style on run-time. • S12. Add voice control • S13. A failure occurs and the system shuts down. • S14. Provide dual display screen. • S15. Use multiple desktops. • S16. Monitor activities of the user • S17. Provide touch screen and light pen as input • S18. A memory overflow due to many opened windows • S19. Port system to command-based operation system • S20. Minimize windows after idle time • WindowManager • EventManager • EventManager, ProcessManager • WindowManager • WindowManager • all components • EventManager • EventManager, ScreenManager • all components • ScreenManager

  49. 4. Reveal Scenario Interactions • Scenario interaction: • Multiple indirect scenarios affect the same components • Good scenario interactions • Semantically related scenarios affect the same architectural components. • Bad scenario interactions • Semantically unrelated scenarios affect the same components  shows which components are implementing semantically unrelated functions • Poor separation of concerns

  50. Cohesion • Cohesive component performs only one concern/task • Maximize cohesion within an architectural component • required changes can be easily localized and will not propagate Synchronization Recovery Synchronization Recovery Authentication Authentication Many concerns in one module Low Cohesion Each module addresses one concernHigh Cohesion

More Related