Use Cases and Aspects Working Seamlessly Together

1. Use Cases and Aspects Working Seamlessly Together Ivar Jacobson Rational Software Corporation ivar@rational.com

2. Alternative titles • Use case driven development with aspects • Aspect-oriented software development with use cases • Model-Driven Development with use cases and aspects

3. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

4. Components were not enough • Components were well established in 1978 • Components form the static structure of a system • Essential to understand, design, implement, distribute, test, and configure the system • The most important asset for reuse in practice • However • Requirements crosscut components – scattering • Components have parts of many different requirements -- tangling • We needed for the dynamic behavior • another kind of modularity • a refined implementation technique • We needed ”AOP”

5. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

6. Use cases are identified in Requirements FURPS Functionality Usability Reliability Performance Supportability Design Constraints Operating systems Environments Compatibility Application standards } Use cases address these requirements!

7. Use Cases Capture Requirements • Use cases reside inside the system • A use case describes the actions the system takes to deliver to the actor • Taken together, all use cases constitute all ways of using the system • A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor Bank customer Withdraw money Actor Use Case

8. Use Case Driven Development } Users’ Needs are Use Cases ! Use Case Driven Req’t Design & Impl. Test Capture the Use Cases Design to Implement the Use Cases Test that the Use Cases are Fulfilled Any product development should follow three steps: • Capture the users’ needs • Design to fit those needs • Testthat the needs are fulfilled

9. Requirements: Capture the use cases • A use case model ATM Withdraw Money Deposit Money Bank System Bank Customer Transfer Between Accounts

10. Use cases versus traditional feature spec’s? • A feature specification attempts to reply to the question: “What is the system supposed to do?” • The use case strategy forces us to add three words to the end of that question: “… for each user?”

11. Design & Implementation: use case design • Use cases are eventually realized as components • Components of the implementation ATM Withdraw Money Deposit Money Bank System Bank Customer Transfer Between Accounts Withdrawal Cash Components

12. Use cases – use case realizations -- components • Each use case is realized by a collaboration - a set of classes • A class plays different roles in different use case realizations • The total responsibility of a class is the composition of these roles Use case Specification Use case design Component design & implementation Cash Cash Interface Cash Withdrawal WithdrawCash Withdrawal Transfer Interface Cash Transfer Funds Interface Transfer Funds Funds Interface Deposit Cash Deposit Funds Funds Deposit Funds

13. Test: use case tests Use Case Modeling Done! Use Case Scenarios Cash Withdrawal of a pre-set amount ATM Withdraw Money Cash Withdrawal of custom amount Test Cases Etc. Many Test Cases for every Use Case Deposit Money Bank System Bank Customer Transfer Between Accounts  Plan Testing & DefineTest Cases • Design Done!  Generate Test Cases FromSequence diagramsand State-Chartdiagrams • Basis for the Test Specification

14. Identifying Use Case Scenarios Use Case: Withdraw Money Valid Card Invalid Card Valid PIN Code Invalid PIN Code . . . Amount Valid and in Range Amount Invalid Amount > Daily Limit Amount > Account Balance

15. Use-Case Driven Development Is thus an instance of • Model-Driven Development (MDD) Is also, as I hope to show, an instance of • Aspect-oriented Software Development (AOSD)

16. The Role of Use Cases Requirements Architecture Reuse … Use Cases Iteration Planning Analysis & Design Business Modeling Test User Experience Design

17. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

18. A case study A protocol subsystem in a telecom switching system • Realization of the base use case was 40% of the code • In total 23 other use cases were partly realized by the subsystem, for example code to • block a telephone line, • supervise the alarm level on a group of telephone lines, • measure the traffic over a group of lines, • restart the lines in case a software error occurred, and • support the distribution of the subsystem over several computational nodes.

19. Impact analysis The 23 parts of use cases had the following impact • 12 use case parts were noninvasive • 8 use case parts were extensions to but did not change the base use case • 3 use case parts had major impact on the base use case – they were peer use cases

20. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

21. The basic problems • Use cases couldn’t be kept separate all the way down to code. • Over all lifecycle models: requirements, analysis, design, implementation and test. • Adding new use cases to an existing system was painful • Infrastructure extensions, for instance concerned with distribution, persistence, debugging, performance monitoring, auditing. • Application extensions such as adding traffic recording to a base telecom system • Use cases were dissolved into the code, and distilling them from the code was far from easy. • A component had parts of many use cases, but these parts couldn’t be kept separate

22. The basic idea -- Use-case modularity A new kind of modules – use-case modules -- to live alongside the component modules. • Use-case modules would cross-cut components. • Use-case modules would be similar to component modules, since • Component modules are composed to build the system, and • Use-case modules would be composed to provide the functional behavior of the system. • Different kinds of “interfaces” though • Composition of use cases would occur on all levels, both inside a component and over all components as a whole.

23. The component structure is the base • Components of different type: subsystems, frameworks, application components, infrastructure components.

24. Add a use case module to the base A use-case module = • a slice (design model + implementation model) • The slice (design model) = a use case realization + the realization of the set of use case parts in participating components • The slice (implementation model) = the code implementing the use case parts in participating components A use case The realization of a use case part

25. Add another use case module

26. Add a third use case module • A use-case module in the design model cross-cuts several components

27. Two mechanisms needed • Use case separation technique • Separating peer use cases was easy (normally how use cases are realized) • Separating extension use cases required new langauge constructs • Use case composition technique • Composing normal extensions would be ”easy” • Composing peer use cases is harder – ovelapping behavior, conflicts... In 1978, extensions got in focus – most ”bucks” for the money

28. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

29. Extension use cases ________________________________________________________________________________ ext p. 1 ________________________________ ext p. 3 ________________________________ Existion ext p. 2 ________________________________ Extensions How to support extensions: • “The extension requires control access from an existion [base], without changing the existion. • …while an existion is executed atomically, the extension may 'intervene' at specified points. • The idea is to provide an extension … with a list of extension points” From: Language Support for Changeable Large Real Time Systems, Ivar Jacobson, 1986

30. Example: A base program • A telecom switching system Call Handling … idle off-hook connect digit receiver dial tone busy

31. Example: Adding traffic recording -- intrusive to base Traffic Recording … Call Handling … idle off-hook time-out yes fetch call counter traffic recording? no step call counter store value connect digit receiver dial tone busy

32. Example: Adding Traffic Recording -- oblivious to base Traffic Recording … Call Handling … • extension point X in Call Handling • after input: off-hook • before task: connect digit receiver • ! • ! • ! • insert at X idle off-hook connect digit receiver dial tone yes traffic recording? busy no step call counter • continue at X time-out fetch call counter store value From: Use Case Modularity, Ivar Jacobson, Ericsson internal document X/Tg 2618, 1979.

33. Language support for extensions Traffic Recording <<extend>> Callee Caller Call Handling Extension points • UML supports extensions in use case modeling Extension use case • However, UML doesn’t support extensions in design and implementation • Extensions on classes, components, subsystems, ...

34. How does general-purpose AOP help? AOP is ”the missing link”, since in AOP • aspects ≈ extensions • join points ≈ extension points • Join Point Model is an important contribution • Allows us to specify sets of join points (incl using regular expr.s) AOP allows us to • Separate use case extensions all the way down to code • Compose back extensions before execution Thus AOPsupports extensions

35. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

36. Peer use cases Use case Specification Use case design Component design & implementation Cash Cash Interface Cash Withdrawal WithdrawCash Withdrawal Transfer Interface Cash Transfer Funds Interface Transfer Funds Funds Interface Deposit Cash Deposit Funds Funds Deposit Funds

37. Peer use cases realized as use case modules Interface Interface Interface Cash CashWithdrawal CashTransfer CashDeposit availableCash withdrawAmount() transferAmount() depositAmount() checkAmount() debitAmount() Cash availableCash enterPin() enterTransactionAccounts() enterTransferAmount() transferCash() enterPin() depositCash() enterDepositAmount() collectCash() debitAmount() creditAmount() checkAmount() Cash availableCash debitAmount() creditAmount() checkAmount() Use Cases enterPin() dispenseCash() enterWithdrawalAmount() withdrawCash() Withdraw Cash Transfer Funds Deposit Cash Classes

38. The system composed from use-case modules MergeByName «system» ATM Interface Cash CashWithdrawal Use Cases «use case module» Withdraw Cash Withdraw Cash «use case module» Transfer Funds Interface CashTransfer Cash Transfer Funds «use case module» Deposit Cash Interface CashDeposit Cash Deposit Cash Classes

39. Composition with HyperJ Each Use Case is a cross cutting concern, realized as a use-case module A system is composed from several use-case modules. • -hyperspace • hyperspace ATMHyperspace • composable class atm.withdrawal.*, atm.transfer.* atm.deposit.*; • -concerns • package atm.withdrawal : UseCase.WithdrawCash • package atm.transfer : UseCase.TransferCash • package atm.deposit : UseCase.DepositCash • -hypermodules • hypermodule ATM • hyperslices: • UseCase.WithdrawCash, • UseCase.TransferCash, • UseCase.DepositCash ; • relationships: • mergeByName; • end hypermodule;

40. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

41. Today – working with use cases • specify each use case, • design each use case, • design and implement each component, and finally • test each use case Component design and implementation means a disruption of the flow

42. Tomorrow – working with use cases and aspects First • specify each use case • design and code each use case • compose the use case slices of each component • test each use case Still, a disruption but supported by tools – thus less In the long-term • specify each use case • design, code, and test each use case And, no disruption

43. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

44. The Future – Extensibility from the Beginning The software development process is a change process: changing from ‘something’ to ‘something else,’ and the first development step is just a special case of changing from ‘nothing’ to ‘something.’ • Software is built in extensions • even the base is an extension—an extension of the null existion. • mathematically: • S1 = S0 + E1 = E1; • S2 = S1 + E2 = E1 + E2; • S3 = S2 + E3 = E1 + E2 + E3. • Extensions will be of several kinds, such as • new use cases or changes in use cases due to new business requirements or new features desired by users • platform or infrastructure changes • architectural, refactoring, or other improvements

45. System development will be organized as extensions • Organized as successive extensions on top of or beneath an existion. • “On the top of” means extensions that add higher-layer features (application use cases). “Beneath” means extensions that add lower-layer features (infrastructure use cases). • The existion is itself a set of extensions on top of or beneath a previous existion. • This will make the system easier to understand, grow, shrink, and maintain

46. And More • Extensions will be composed at some point in time, • maybe as late as runtime, to provide an integrated behavior by the system. • Extensions will occur during the entire system lifecycle: • over all releases, iterations, and builds. • Extensions must be implemented without disrupting the operations of a deployed system. • The operational semantics of extensions should be built into the programming language • Instead of being vendor specific.

47. Agenda • Components were not enough • Use case basics • A case study • Approaching a solution • Extension use cases • Peer use cases • Working with use cases and aspects • The future • Concluding remarks

48. Concluding Remarks • Neither use cases nor aspects are silver bullets; they only represent two best practices. • Integrating them will dramatically improve the way software will be developed; keeping the use cases separate all the way down to the code. • We will get software that is easier to work with in basically all dimensions. • Easier to understand, design, implement, reuse, distribute, test, and configure • We will get better software (higher quality) and we will—of course —get it cheaper and faster. It is time to harvest – now!

49. References • AOSD • Ivar Jacobson, Use Cases and Aspects – Working Together, soon to be published • Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G. Griswold. “An overview of AspectJ.” Proceedings of the European Conference on Object-Oriented Programming, Budapest, Hungary, 18-22 June 2001. • http://www.eclipse.org/aspectj/ • http://www.alphaworks.ibm.com/tech/hyperj • H. Ossher and P. Tarr. "Multi-Dimensional Separation of Concerns and The Hyperspace Approach.” Proceedings of the Symposium on Software Architectures and Component Technology: The State of the Art in Software Development. Kluwer, 2000. • Ivar Jacobson. “Use Case Modularity.” Ericsson internal document X/Tg 2618, 1979-12-13. • Ivar Jacobson (inventor) & Ericsson (applicant), Patent application, Address Sequence Variator, 1981-09-21. • Ivar Jacobson. “Language Support for Changeable Large Real Time Systems.” Proceedings of OOPSLA’86. pp 377-384, Sept 1986. • Ivar Jacobson. “Concepts for Modeling Large Real Time Systems.” Department of Computer Systems, The Royal Institute of Technology, Stockholm, Sept. 1985.

50. Other Readings by Ivar Jacobson • Object-Oriented Software Development--A Use Case Driven Approach (Addison Wesley)Jacobson et al, Addison Wesley Longman (1992) • The Object Advantage: Business Process Reengineering with Objects (Addison Wesley)Jacobson et al, Addison Wesley Longman (1994) • Software Reuse: Architecture, Process and Organization for Business Success (Addison Wesley) Ivar Jacobson, Martin Griss & Patrik Jonsson, Addison Wesley Longman (1997) • Unified Software Development ProcessJacobson, Booch, Rumbaugh, Addison Wesley Longman (1999) • The Road to the Unified Software Development Process Ivar Jacobson, Stefan Bylund, Cambridge University Press, 2000