Use Cases and Aspects Working Seamlessly Together Ivar Jacobson Rational Software Corporation...

Use Cases and Aspects Working Seamlessly Together

Use Cases and Aspects Working Seamlessly Together

Ivar JacobsonRational Software Corporation

[email protected]

Ivar JacobsonRational Software Corporation

[email protected]

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 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



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


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


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



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



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



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


dial tone

busy

fetch call counter

store value

Call Handling … Traffic Recording …

idle

off-hook


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



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



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



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



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.

Ivar Jacobson

Which other ref's

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

Use Cases and Aspects Working Seamlessly Together Ivar Jacobson Rational Software Corporation...

Documents

Transcript of Use Cases and Aspects Working Seamlessly Together Ivar Jacobson Rational Software Corporation...