use cases and aspects working seamlessly together
DESCRIPTION
Use Cases and Aspects Working Seamlessly Together. Ivar Jacobson Rational Software Corporation [email protected]. Alternative titles. Use case driven development with aspects Aspect -oriented software development with use cases Model-Driven Development with use cases and aspects. - PowerPoint PPT PresentationTRANSCRIPT
Use Cases and Aspects Working Seamlessly Together
Use Cases and Aspects Working Seamlessly Together
Ivar JacobsonRational Software Corporation
Ivar JacobsonRational Software Corporation
Alternative titlesAlternative titles Use case driven development with aspects Aspect-oriented software development with use cases Model-Driven Development with use cases and aspects
Use case driven development with aspects Aspect-oriented software development with use cases Model-Driven Development with use cases and aspects
AgendaAgenda
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
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
Components were not enoughComponents 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”
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”
AgendaAgenda
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
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
Use cases are identified in RequirementsUse cases are identified in Requirements
FURPS Functionality Usability Reliability Performance Supportability
FURPS Functionality Usability Reliability Performance Supportability
Design Constraints Operating systems Environments Compatibility Application standards
Design Constraints Operating systems Environments Compatibility Application standards
Use cases address these requirements!
Use cases address these requirements!
}
Use Cases Capture RequirementsUse 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
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
Withdraw money Bank customer
Actor Use Case
Use Case DrivenReq’t Design & Impl. Test
Capture the Use Cases
Design to Implement
the Use Cases
Test that the Use Cases are Fulfilled
}Users’ Needs areUse Cases !
Use Case Driven DevelopmentUse Case Driven Development
Any product development should follow three steps: Capture the users’ needs Design to fit those needs Test that the needs are fulfilled
Any product development should follow three steps: Capture the users’ needs Design to fit those needs Test that the needs are fulfilled
Requirements: Capture the use casesRequirements: Capture the use cases A use case model A use case model
BankSystem
BankCustomer
Deposit Money
Withdraw Money
Transfer Between Accounts
ATMATMATMATM
Use cases versus traditional feature spec’s?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?”
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?”
Design & Implementation: use case designDesign & Implementation: use case design Use cases are eventually realized as components Components of the implementation
Use cases are eventually realized as components Components of the implementation
Cash Withdrawal
ComponentsComponentsComponentsComponents
BankSystem
BankCustomer
Deposit Money
Withdraw Money
Transfer Between Accounts
ATMATMATMATM
Use cases – use case realizations -- componentsUse 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
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
Withdraw Cash
Deposit Funds
Transfer Funds
Cash Withdrawal
Cash Interface
Cash Interface Deposit Funds
Transfer Funds
Interface Interface
Funds Deposit
Cash Transfer Funds
CashWithdrawal
Use case Specification
Use case design
Component design &implementation
Test: use case testsTest: use case tests
Test Cases
Cash Withdrawal of a pre-set amount
Cash Withdrawal of custom amount
Etc. Many Test Cases for every Use Case
Use Case Modeling Done!
Plan Testing & DefineTest Cases
Generate Test Cases From Sequence diagramsand State-Chart diagrams
Design Done!
Basis for the Test Specification
BankSystem
BankCustomer
Deposit Money
Withdraw Money
Transfer Between Accounts
ATMATMATMATM
Use Case Scenarios
Invalid PIN CodeValid PIN Code
AmountInvalid
Use Case: Withdraw Money
Valid Card Invalid Card
Amount> Account Balance
Amount > Daily Limit
. . .
Identifying Use Case ScenariosIdentifying Use Case Scenarios
AmountValid and in Range
Use-Case Driven DevelopmentUse-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)
Is thus an instance of Model-Driven Development (MDD)Is also, as I hope to show, an instance of Aspect-oriented Software Development (AOSD)
The Role of Use Cases The Role of Use Cases
UseCases
Requirements
Architecture
Analysis &Design
Test
User ExperienceDesign
BusinessModeling
IterationPlanning
…Reuse
AgendaAgenda
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
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
A case studyA 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.
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.
Impact analysisImpact 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
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
AgendaAgenda
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
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
The basic problemsThe 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
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
The basic idea -- Use-case modularityThe basic idea -- Use-case modularityA 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.
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.
The component structure is the baseThe component structure is the base Components of different type: subsystems, frameworks,
application components, infrastructure components. Components of different type: subsystems, frameworks,
application components, infrastructure components.
Add a use case module to the baseAdd 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 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 componentsA use case
The realization of a use case part
Add another use case moduleAdd another use case module
Add a third use case moduleAdd a third use case module
A use-case module in the design model cross-cuts several components
A use-case module in the design model cross-cuts several components
Two mechanisms neededTwo 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
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
AgendaAgenda
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
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
Extension use casesExtension use cases
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”
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”
ext p. 1ext p. 3
ext p. 2
________________________________________________________________________________
________________________________ _______
_________________________
________________________________
ExistionExistion
ExtensionsExtensions
From: Language Support for Changeable Large Real Time Systems, Ivar Jacobson, 1986
From: Language Support for Changeable Large Real Time Systems, Ivar Jacobson, 1986
Example: A base programExample: A base program A telecom switching system A telecom switching system
idle
off-hook
connect digit receiver
dial tone
busy
Call Handling …
Example: Adding traffic recording -- intrusive to baseExample: Adding traffic recording -- intrusive to base
traffic recording?
time-out
idle
off-hook
yes
no step callcounter
connect digit receiver
dial tone
busy
fetch call counter
store value
Call Handling … Traffic Recording …
idle
off-hook
connect digit receiver
dial tone
busy
extension point X in Call Handlingafter input: off-
hookbefore task:
connect digit receiver!!!
insert at X
step callcounter
traffic recording?
yes
no
continue at X
store value
fetch call counter
time-out
Call Handling … Traffic Recording …
Example: Adding Traffic Recording -- oblivious to baseExample: Adding Traffic Recording -- oblivious to base
From: Use Case Modularity, Ivar Jacobson, Ericsson internal document X/Tg 2618, 1979. From: Use Case Modularity, Ivar Jacobson, Ericsson internal document X/Tg 2618, 1979.
Language support for extensionsLanguage support for extensions
UML supports extensions in use case modeling UML supports extensions in use case modeling
Caller Callee
<<extend>><<extend>>
Call Handling
Traffic Recording
Extension points Extension points
Extension use caseExtension use case
However, UML doesn’t support extensions in design and implementation Extensions on classes, components, subsystems, ...
However, UML doesn’t support extensions in design and implementation Extensions on classes, components, subsystems, ...
How does general-purpose AOP help?How does general-purpose AOP help?
AOP is ”the missing link”, since in AOPaspects ≈ extensions join points ≈ extension pointsJoin 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 AOP supports extensions
AOP is ”the missing link”, since in AOPaspects ≈ extensions join points ≈ extension pointsJoin 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 AOP supports extensions
AgendaAgenda
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
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
Withdraw Cash
Deposit Funds
Transfer Funds
Cash Withdrawal
Cash Interface
Cash Interface Deposit Funds
Transfer Funds
Interface Interface
Funds Deposit
Cash Transfer Funds
CashWithdrawal
Use case Specification
Use case design
Component design &implementation
Peer use casesPeer use cases
Peer use cases realized as use case modulesPeer use cases realized as use case modules
Interface
enterPin()dispenseCash()enterWithdrawalAmount()withdrawCash()
CashWithdrawal
withdrawAmount()
CashavailableCash
checkAmount()debitAmount()
CashavailableCash
debitAmount()creditAmount()checkAmount()
CashavailableCash
debitAmount()creditAmount()checkAmount()
enterPin()enterTransactionAccounts()enterTransferAmount()transferCash()
Interface
enterPin()depositCash()enterDepositAmount()collectCash()
Interface
CashTransfer
transferAmount()
CashDeposit
depositAmount()Deposit Cash
Transfer Funds
Withdraw Cash
Use Cases
Classes
The system composed from use-case modulesThe system composed from use-case modules
Deposit Cash
Transfer Funds
«use case module» Deposit Cash
Cash
«use case module» Transfer Funds
CashDepositInterface
CashCashTransferInterface
Withdraw Cash
«use case module» Withdraw Cash
CashWithdrawal CashInterface
Use Cases
Classes
«system» ATM
MergeByName
Composition with HyperJComposition with HyperJ
-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;
-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;
Each Use Case is a cross cutting concern, realized as a use-case module
A system is composed from several use-case modules.
AgendaAgenda
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
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
Today – working with use casesToday – working with use cases
1. specify each use case, 2. design each use case, 3. design and implement each component, and finally 4. test each use case Component design and implementation means a disruption of the flow
1. specify each use case, 2. design each use case, 3. design and implement each component, and finally 4. test each use case Component design and implementation means a disruption of the flow
Tomorrow – working with use cases and aspectsTomorrow – working with use cases and aspects
First1. specify each use case2. design and code each use case3. compose the use case slices of each component4. test each use caseStill, a disruption but supported by tools – thus lessIn the long-term1. specify each use case2. design, code, and test each use caseAnd, no disruption
First1. specify each use case2. design and code each use case3. compose the use case slices of each component4. test each use caseStill, a disruption but supported by tools – thus lessIn the long-term1. specify each use case2. design, code, and test each use caseAnd, no disruption
AgendaAgenda
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
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
The Future – Extensibility from the BeginningThe 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 asnew use cases or changes in use cases due to new business requirements or new features desired by usersplatform or infrastructure changesarchitectural, refactoring, or other improvements
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 asnew use cases or changes in use cases due to new business requirements or new features desired by usersplatform or infrastructure changesarchitectural, refactoring, or other improvements
System development will be organized as extensionsSystem 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
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
And MoreAnd 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.
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.
AgendaAgenda
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
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
Concluding RemarksConcluding 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.
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!It is time to harvest – now!
ReferencesReferences 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.
Other Readings by Ivar JacobsonOther 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
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