Transitioning From Software

Requirements Models to Design

Models
PI: Jon Whittle
QSS Group Inc.

NASA POC: Michael Lowry

Ames Research Center
 Problem
How to cope with the problems of requirements engineering?
– Complexity
– Validation
– Evolution
– Requirements/Design gap
NASA CTAS example:

data uplink/downlink

customers

designer/architect programmer
 Approach
– Complexity
Simulation of use cases (scenarios)
– Validation
– Evolution
Semi-automatic design
– Requirements/Design gap
transformation

customers designer/architect
programmer

Goal:Cost-effective way of
simulating requirements
simulation • automatic transformation to
executable form
• executable form can be reused in
design
 Overview of Research
SCASP (Scenario Creation and Simulation Process)
Write use Prioritize Identify Refine/ Transform
Write Write nominal Generalize to state
requirements cases use cases scenarios relationships
scenarios machines

Itemized
List UML2.0
For risk,
Sequence importance &
Diagrams metric
calculation
Write down
what you preempts,
can parallel, systematic
crosscuts etc. synthesis
guidelines
algorithm
 Importance/Benefits
• Thorough simulation of use cases before design/implementation
– reduced cost
– fewer misunderstandings
– reuse of executable form of use cases
• SCASP gives systematic guidelines on how to:
– separate concerns in use case descriptions
– elicit non-nominal scenarios (alternatives, exceptions, concurrent
scenarios etc.)
– transform those scenarios automatically into a set of concurrent state
machines
– execute those state machines, i.e., scenario simulation
• NASA relevance (specific projects):
– CTAS air traffic control (Ames)
• weather update module
• trajectory synthesizer
• data link/uplink
– also: Motorola test methodology (ENTITE)
 Accomplishments
• SCASP:
– Defined SCASP and evaluated on multiple case studies
• CTAS weather update
• Motorola call setup sequence
• Univ. Paderborn shuttle system
• CTAS trajectory up/downlink
– Techniques for separation of concerns (aspects)
• forthcoming papers in Requirements Engineering ’04 and IEE Software
– Synthesis:
• outlined new algorithm for synthesizing state machines from scenarios
– Metrics
• defined metrics for evaluating completeness/complexity of process
• Tool support (IBM Rational Rose plug-in):
– Simple version of algorithm
– plug-in for reusable patterns (including use case aspects)
– Integrated state machine simulator from Teknowledge Corp. (Alexander Egyed)
• Customer interest:
– NASA CTAS
– Motorola
 Next Steps
• SCASP:
– Further evaluation on case studies
– Synthesis:
• develop, implement and test new algorithm
– Metrics:
• evaluation
– Simulation:
• feedback simulation results
• Tool support:
– Full version of algorithm
– Integration
• Customer transfer
 Transitioning From Software
Requirements Models to Design
Models
PI: Jon Whittle
QSS Group Inc.
 Use case simulation
– Complexity
Simulation of use cases (scenarios)
– Validation
– Evolution
Semi-automatic design
– Requirements/Design gap
transformation

customers designer/architect
programmer

Goal:Cost-effective way of
simulating requirements
simulation • automatic transformation to
executable form
• executable form can be reused in
design
 Main Idea
Scenarios State Machines Code

Test Cases
etc..
Requirements
Validation
Many good reasons for working with scenarios
• walkthrough software artifacts
• analysis/validation
• test case generation
• state machine generation

Missing link: how to develop an appropriate set of scenarios?

• synthesis requires completeness
• test case generation requires coverage
• requirements validation requires coverage
 Overview of Research
SCASP (Scenario Creation and Simulation Process)
Write use Prioritize Identify Refine/ Transform
Write Write nominal Generalize to state
requirements cases use cases scenarios relationships
scenarios machines

Itemized
List UML2.0
For risk,
Sequence importance &
Diagrams metric
calculation
Write down
what you preempts,
can parallel, systematic
crosscuts etc. synthesis
guidelines
algorithm
Based on UML, but (mostly) language-independent
Metrics measure completeness/complexity
 Illustrative Example
• Autonomous agents bid for orders from
clients
– May bid for any number of orders
simultaneously
– Broker assigns orders
– Clients pay controller who in turn pays agents

This talk:
agent=rail shuttle
client=passenger
Controller
Broker
 1. Write Requirements
R1 Shuttles traveling on sections of tracks that are disrupted are not affected.
R2 Shuttles not traveling on a section of tracks that become disrupted will not be able to use it.
R3 All shuttles will be informed of a disruption and its duration.
R4a Orders are made known to all shuttles by a broker.
R4b Any shuttle can make an offer within a certain period of time
R4c The shuttle making the lowest offer will receive the assignment
R4d In the event of two equal offers, the assignment goes to the shuttle that made the first offer
R5 Orders will be paid for by passengers either by credit card or invoice
R6a Every shuttle has a maximum capacity determined at the start of the simulation
R6b A shuttle can transport more than one order at a time as long as the orders do not exceed the maximum capacity
R6c The number of orders assigned (not necessarily loaded) to a shuttle at any given time is not limited
R7a To complete an order, a shuttle has to travel to the start station, load the order and proceed to the destination station to
unload
R7b R7a has to be completed within a deadline or a penalty will be levied.
R7c Loading/unloading at intermediate stations (for the same order) is not permitted
R8 A shuttle traveling on a section of tracks can neither change direction nor choose another destination. A travel decision is
only possible at a station before the journey has begun.
R9a In the beginning, every shuttle will receive a fixed capital
R9b Payment to a shuttle occurs after an order is delivered and an invoice is sent to the banking agent
R9c If the order specified credit card payment, money is transferred to the shuttle immediately. If the payment was invoicing
then the transfer will be delayed for a certain amount of time
R10 Shuttles pay their toll when a station is reached
R11 If a shuttle exceeds a certain distance, maintenance will be carried out at the next station automatically and the shuttle will
not be able to leave the station until maintenance is finished.
R12 Repairs can be scheduled before the distance limit is reached and carried out at any station.
R13 Payment for maintenance and repairs is immediate.
 2. Write Use Cases <<extend>>

Affected Shuttle
Initialization Connection Disruption

<<extend>>

Shuttle Make a Bid

Retirement <<extend>> Unaffected Shuttle

<<extend>>
Successful Completion

Maintenance
Carry Out Order ReceivePayment

<<extend>>
Passengers MakePayment
<<extend>>

<<extend>>

Unsuccessful Completion
Pay Toll PayPenalty
3. Prioritize Use Cases
Use case Priority
Affected Shuttle 5
Carry out order 9
Connection disruption 5
Initialization 5
Maintenance 5
Make a bid 10
Make payment 1
Pay toll 3
Pay penalty 4
Receive payment 4
Retirement 5
Successful completion 8
Unaffected shuttle 1
Unsuccessful Completion 8
 4. Write nominal scenarios

Non-nominal
Non-nominal
Nominal scenario Non-nominal
Non-nominal
scenario
scenario scenario scenario

• Nominal scenario: typical or important

functionality
• Non-nominal scenario: unusual or
unexpected behavior

“write down what you can!”

 Nominal Scenario: bidding

: Controller : Broker
: Shuttle : Shuttle

1: newOrder

2: newOrder

3: newOrder
4: makeBid
5: makeBid

6: makeBid

7: makeBid

8: OfferTimeEnds

9: chooseLowestBid
10: grantOffer

11: acceptOffer
12: endOrder
 5. Identify Relationships
5.1 Within use cases:
S is a continuation of T
S is an alternative to T
S may execute in parallel with T
S may preempt T
S may suspend T
S may never happen during R
S is an exception handler for T
Multiple instances of S may execute at once Move to
<<neg>>
S crosscuts R. intermediate
station
*
Successful
completion
 5. Identify Relationships
5.2 Between use cases:

Initialization

*
Maintenance Retirement Connection Make A
Disruption Bid

{....}

*
{....}
Carry Out
* Order

Make
Payment
 6. Generalize/Refine
Nominal Scenarios

• Series of issues based on common

generalization/refinement strategies.
– May be language dependent or independent

Issue Context Question Action Alternatives

A generalization Component, What to look What action to Alternative

/refinement message or for? take? actions
strategy to look scenario
for
 Issues (so far)
Context:
component:
type If no: consider a refactoring of the
Does the scenario apply to all type model to introduce sub-
1.1
Issue components
Question of type type? components
Action for those to which the
numberShould a message sent to If all: replace component with a
scenario applies.
multiobject representing all
1.1 component be sent
Does the scenario applyto allcomponents
to all If no: consider a refactoring of the type model to
1.2 of type type? components of type typeforand
introduce sub-components thosemake
to which
components of type type or just
the
If all:message
the a universal message
scenario applies.
replace component with a
one?
Should a message received by
1.2 Should a message sent to component be sent sent If all:to
multiobject all components.
replace representing
component all
with a multiobject
component be received
to all components of typeby
typeall
or just representing all components of type type and
1.3 components of type type and make
components
one? of type type or just make the message a universal message sent
the message a universal message
to all components.
one?
1.3
received bycomponent
all components.
Analog of 1.2 for messages sent to at least one of a setwith
Should a message received by component be If all: replace ofacomponents
multiobject of
1.4 received by all components of type type representing all components of type type and
a certain type.
or just one? make the message a universal message
received by all components.
Analog
Analog of
of 1.21.3 for messages
sent to at leastreceived bycomponents
at leastof a one
certain of
type.a set of
1.51.4 for messages one of a set of
components of a certain type.
1.5 Analog of 1.3 for messages received by at least one of a set of components of a certain type.
 Context:
message

2.1 Could message be replaced with another message without If yes: replace message with a combined fragment with interaction
changing the behavior of the scenario? operator alt and the two alternative messages as operands.
2.2 Can the
Could ordering
message be sent from of
or bemessage be
received by a different
component without changing the behavior of the scenario?
If yes: replace message with a combined fragment with interaction
operator alt and message with its alternative sending or receiving
changed? In particular, could the components as operands.
2.3 ordering
Is message aof message
choice and
point? – i.e., could its
an alternative If yes: encapsulate the existing and new behaviors in operands of a
message have appeared at this point that would change the Ifcombined
yes: introduce
fragment coregions
with an alt operator, toguards
and introduce relax
for
2.4 immediate neighbors be altered?
following behavior? the operands if necessary.
the scenario ordering constraints.
2.4 Could
Can thethe ordering
ordering of
of message be changed? message
In particular, could
the ordering of message and its immediate neighbors be
If yes: introduce coregions to relax the scenario ordering constraints.

andaltered?
its Could
distant neighbors
the ordering of message and beits distant
neighbors be altered?
2.5
altered?
Is message optional (or part of an optional sequence)? If yes: encapsulate the optional elements in a combined fragment
with operator opt.
2.6 Does message have a guard? If yes: introduce alternatives when the guard is not satisfied (using
alt).
2.7 Can message fail? If yes: capture the failure handler as a separate interaction diagram
referred to (using ref) in the main diagram and use an alt operator to
capture the alternative when the message fails.
2.8 Could message overlap its neighbors? If yes: redraw the message. If necessary, add timing mark
Are there undesired implied constraints.
2.9 scenarios? – e.g.,
Are there alternatives caused
for the message that are by
invalid? IfIf yes:
yes: introduce
introduce an with
combined fragments explicit
a neg interaction
operator.
2.10
messages on different lifelines
Are there opportunities for introducing concurrency?
“handshake” message between the
If yes: introduce combined fragments with the par operator.
3.12.11 thatDoes
appear todepend
message really be onordered based
all its predecessors? two lifelines
If no: extract that
the dependent forces
messages the scenario.
into a separate sequence
Context: scenarioon their graphical depiction but diagram semantics to constrain the
are not ordered according to the ordering of the messages.
3.1 sequence diagram
Are there undesired semantics.
implied scenarios? – e.g., caused by If yes: introduce an explicit “handshake” message between the two
messages on different lifelines that appear to be ordered lifelines that forces the sequence diagram semantics to constrain the
based on their graphical depiction but are not ordered ordering of the messages.
according to the sequence diagram semantics.
 Example
2.11 Does message really depend on all its If no: extract the dependent messages
predecessors? into a separate scenario.

Scenario shows just one example, therefore factor out

any “incidental” dependencies

Crew Ground
Crew Ground
detectConflict Ground
detectConflict

notify
notify
detectConflict

detectConflict
Split into two scenarios to allow other orderings
 Bidding Example: Before
Issue Description

1.2 Scenario shows only 2 shuttle instances. Generalize using a

multiobject and merge messages 2 and 3 into a universal
: Controller : Broker
message. Note: there needs to be a single identified
: Shuttle : Shuttle
Scenario shows only 2 shuttle instances. Generalize using a multiobject
1: newOrder
instance of Shuttle to receive message 10.

1.2 and merge messages 2 and 3 into a1.5universal

2: newOrder message.
Merge messages Note:
4 and 6 into an existential there
message

needs to be a single identified instance

2.3 ofAlternative
Shuttle to11receive
to message message
is rejectOffer. Alternatives
noBids and BidsAreEqual.
to 9 are 10.
3: newOrder

4: makeBid 2.4 Messages 2,3 can be in any order. As can 4,6 and 5,7

5: makeBid 2.5 Messages 4,5 can be marked as optional as only one shuttle may
decide to bid
Message 9 is optional (there may be only one bid)
6: makeBid
Message 11 is optional as the winning shuttle may not respond to
the offer

1.5 Merge messages 4 and 6 into an existential

7: makeBid
2.7
message
There may be communication failures

2.9 The broker should not accept the highest bid

8: OfferTimeEnds
2.10 The order/bid for each shuttle can be split into parallel fragments

9: chooseLowestBid
2.11 Message 4 does not depend on 3 (this one is ok because of the
10: grantOffer partial order semantics). Message 6 does not depend on
message 2. Messages 6,7 do not depend on message 5.

11: acceptOffer
Message 4 does not depend on 3 (this one is ok because of the partial Message 8 does not depend on messages 4-7. Message 11
does not depend on messages 4 and 5.
order semantics). Message 6 does not depend on message 2. Messages
12: endOrder

2.11
6,7 do not depend on message 5. Message 8 does not depend on
messages 4-7. Message 11 does not depend on messages 4 and 5.
 Bidding Example: Before
Issue Description

1.2 Scenario shows only 2 shuttle instances. Generalize using a

multiobject and merge messages 2 and 3 into a universal
: Controller : Broker
message. Note: there needs to be a single identified
: Shuttle : Shuttle instance of Shuttle to receive message 10.
1: newOrder

2: newOrder 1.5 Merge messages 4 and 6 into an existential message

2.3 Alternative to message 11 is rejectOffer. Alternatives to 9 are

noBids and BidsAreEqual.
3: newOrder

4: makeBid 2.4 Messages 2,3 can be in any order. As can 4,6 and 5,7

5: makeBid 2.5 Messages 4,5 can be marked as optional as only one shuttle may
decide to bid
Message 9 is optional (there may be only one bid)
6: makeBid
Message 11 is optional as the winning shuttle may not respond to
the offer

7: makeBid
2.7 There may be communication failures

2.9 The broker should not accept the highest bid

8: OfferTimeEnds
2.10 The order/bid for each shuttle can be split into parallel fragments

9: chooseLowestBid
2.11 Message 4 does not depend on 3 (this one is ok because of the
10: grantOffer partial order semantics). Message 6 does not depend on
message 2. Messages 6,7 do not depend on message 5.
Message 8 does not depend on messages 4-7. Message 11
11: acceptOffer does not depend on messages 4 and 5.
12: endOrder
 Bidding Example: After
: Controller : Broker
: Shuttle
: Controller : Broker
: Shuttle
<<multiobject>> 1: offerTimeEnds
1: newOrder
X
all 2: chooseLowestBid
2: newOrder

3: grantOffer
exist

3: makeBid alt 4: acceptOffer

5: endOrder
4: makeBid

6: rechoose
5: refuseOffer

S1 X

S2 preempts S1 S2
 7. Transform to State
machines
?pickUpPassengers timeout
?moveToStation(end)
?moveToStation(start) ?requestPayment

?requestRoute pleaseWait
?dropOffPassengers

sendRoute
makePayment makePayment
timeout

?requestRoute

?pickUpPassengers
?moveToStation(start) sendRoute

?moveToStation(end)

ERROR
?requestPayment
?dropOffPassengers
 “State of Play”
SCASP (Scenario Creation and Simulation Process)
Write use Prioritize Identify Refine/ Transform
Write Write nominal Generalize to state
requirements cases use cases scenarios relationships
scenarios machines

Metrics
TRL 5
 Metrics
actual complexity
NTu
ECPu
UCCP =# w ×
NTu
nonzero priority & ∑
u′
ECPu
nonzero complexity
nonzero priority

ECPu = Pu × ECu
priority
expected complexity
 Accomplishments
• SCASP:
– Defined SCASP and evaluated on multiple case studies
• CTAS weather update
• Motorola call setup sequence
• Univ. Paderborn shuttle system
• CTAS trajectory up/downlink)
– Techniques for separation of concerns (aspects)
• forthcoming papers in Requirements Engineering ’04 and IEE Software
– Synthesis:
• outlined new algorithm for synthesizing state machines from scenarios
– Metrics
• defined metrics for evaluating completeness/complexity of process
• Tool support (IBM Rational Rose plug-in):
– Simple version of algorithm
– plug-in for reusable patterns (including use case aspects)
– Integrated state machine simulator from Teknowledge Corp. (Alexander Egyed)
• Customer interest:
– NASA CTAS
– Motorola