UML Use Case
1
C lass Transform ations <<actor>> C lass Analyzer C heck Equivalence _________________ O bjectEquivalence Find PartC lusters __________________ checkPartC lusters <<includes>> W eakExtension and Extension ___________________________ extends w eakExtends O ptional Parts <<extends>> <<extends>> <<extends>> <<extends>> UML Use Case Implementation +get_partC lusters(in C d_graph) PartC lusters +objectE qu ivalence(in pc1,in pc2):bool O bjectE quivalence 1 1 Extension <<Aspect>> pointcut checkE xtensions(M ap pc1,M ap pc2): call (* M ain.objectE qu ivalent(M ap,M ap)) && args (pc1,pc2); boolean w eakE xtension(M ap pc1,M ap pc2){...} boolean extensionR elation(M ap pc1,M ap pc2){...} OptionalParts <<Aspect>> pointcut checkO bjectE quivalent(M ap pc1,M ap pc2): execution (* M ain.objectE quivalent(M ap,M ap)) && args (pc1,pc2); pointcut checkW eakE xtension(M ap pc1,M ap pc2): execution (* w eakE xtension(M ap,M ap)) && args (pc1,pc2); pointcut checkE xtensionR elation(M ap pc1,M ap pc2): execution (* extensionR elation(M ap,M ap)) && args (pc1,pc2); pointcut opPartC lu sters(C d_graph cdg): execution (*PartC lu sters.get_partC lu sters(C d_graph) && args (cdg); M ap around (C d_graph cdg):checkParts(cdg){… } //A dvice after (M ap pc1,M ap pc2) returning (boolean flag):checkE xtensions(pc1,pc2){ } //A dvice boolean around (M ap pc1,M ap pc2): checkO bjectE qu ivalent(pc1,pc2){… } boolean around (M ap pc1,M ap pc2): checkW eakE xtension(pc1,pc2){… } boolean around (M ap pc1,M ap pc2): checkE xtensionR elation(pc1,pc2){… } Base Extension, Weak Extension Optional Parts References: [1] Ivar Jacobson, “Use cases and Aspects -- Working together ”. Invited Talk at AOSD 2003, Boston, USA. [2] Karl J. Lieberherr, “Adaptive Object Oriented Software The Demeter Method with propagation patterns”. PWS Publishing Company, Boston, 1996. [3] Bashar Nuseibeh and Steve Easterbrook . “Requirements Engineering: A roadmap”. ICSE 2000. Analysis and Design phase: well-defined structure involving Actors and Use Cases. Implementation phase: use cases get dissolved into multiple, overlapping software modules. Loss of Use Case Modularity Problem: Design Space Implementation Space (AOP) Base Use Case Base Program Extension Points Join Points Extended Use Case Aspect Advice Mapping «extends» from Use Cases to AOP * Part of this work has been funded by ABB Switzerland . Tangling & Scattering of use cases in software modules. Use Cases Software Modules Implementati on phase Manali Bhole and Therapon Skotiniotis* Northeastern University, Boston, USA. {manali, skotthe}@ccs.neu.edu Use Cases to Code mapping allows for: • Iterative approach to development and future evolution. Results: • Easier traceability of stakeholders requirements. • Easier validation of implementation against requirements. • Increase understandability of design through inspection of implementation. • Easier to show that implementation covers all use cases (scenarios). Future Work: • Pointcut expressiveness vs. use case extensions needed. • Attempt more complicated scenario flows and re- assess results. • Add non-functional requirements. to from
description
Use Case Modularity using Aspects. Manali Bhole and Therapon Skotiniotis * Northeastern University, Boston, USA . {manali, skotthe}@ccs.neu.edu. Results :. Use Cases to Code mapping allows for:. Easier traceability of stakeholders requirements. - PowerPoint PPT Presentation
Transcript of UML Use Case
Class Transformations<<actor>>
Class Analyzer
Check Equivalence_________________
ObjectEquivalence
Find Part Clusters__________________
checkPartClusters
<<includes>>
WeakExtension andExtension
___________________________extends
weakExtends
Optional Parts
<<extends>>
<<extends>><<extends>>
<<extends>>
UML Use Case
Implementation
+get_partClusters(in Cd_graph)
PartClusters
+objectEquivalence(in pc1, in pc2) : bool
ObjectEquivalence
11
Extension<<Aspect>>
pointcut checkExtensions(Map pc1, Map pc2): call(* Main.objectEquivalent(Map, Map))
&& args(pc1,pc2);
boolean weakExtension(Map pc1,Map pc2){... }boolean extensionRelation(Map pc1, Mappc2){...}
OptionalParts<<Aspect>>
pointcut checkObjectEquivalent(Map pc1, Map pc2):execution(* Main.objectEquivalent(Map, Map))&& args(pc1, pc2);
pointcut checkWeakExtension(Map pc1, Map pc2): execution(* weakExtension(Map, Map))&& args(pc1, pc2);
pointcut checkExtensionRelation(Map pc1, Map pc2):execution(* extensionRelation(Map,Map))&& args(pc1,pc2);
pointcut opPartClusters(Cd_graph cdg):execution(*PartClusters.get_partClusters(Cd_graph) && args(cdg);
Map around(Cd_graph cdg):checkParts(cdg) { … }
/ / Adviceafter(Map pc1, Map pc2) returning(boolean
flag): checkExtensions(pc1,pc2){ }
/ / Advice boolean around(Map pc1, Map pc2):
checkObjectEquivalent(pc1, pc2){ … } boolean around(Map pc1, Map pc2):
checkWeakExtension(pc1, pc2){ … } boolean around(Map pc1, Map pc2):
checkExtensionRelation(pc1, pc2){ … }
BaseExtension, Weak Extension Optional Parts
References:[1] Ivar Jacobson, “Use cases and Aspects -- Working together”. Invited Talk at AOSD 2003, Boston, USA.
[2] Karl J. Lieberherr, “Adaptive Object Oriented Software The Demeter Method with propagation patterns”. PWS Publishing Company, Boston, 1996.
[3] Bashar Nuseibeh and Steve Easterbrook . “Requirements Engineering: A roadmap”. ICSE 2000.
Analysis and Design phase: well-defined structure
involving Actors and Use Cases. Implementation phase: use cases get dissolved into multiple, overlapping software modules.
Loss of Use Case Modularity
Problem:
Design SpaceImplementation Space
(AOP)Base Use Case Base Program
Extension Points Join Points
Extended Use Case Aspect Advice
Mapping «extends» from Use Cases to AOP
* Part of this work has been funded by ABB Switzerland.
Tangling & Scattering of use cases in software modules.
Use Cases Software Modules
Implementation phase
Manali Bhole and Therapon Skotiniotis*
Northeastern University, Boston, USA.
{manali, skotthe}@ccs.neu.edu
Use Cases to Code mapping
allows for:
• Iterative approach to development and future evolution.
Results:
• Easier traceability of stakeholders requirements.
• Easier validation of implementation against requirements.
• Increase understandability of design through inspection of implementation.
• Easier to show that implementation covers all use cases (scenarios).
Future Work:• Pointcut expressiveness vs. use case extensions needed.
• Attempt more complicated scenario flows and re-assess results.
• Add non-functional requirements.
to
from
