Transitioning From Software Requirements Models to Design Models

1
Transitioning From Software Requirements Models
to Design Models

• PI Jon Whittle
• Qss Group Inc.

NASA POC Michael Lowry Ames Research Center
2
Software Modeling
UNIFIED MODELING LANGUAGE

• A software model is a blueprint for software
  essential for project team
• communication and to ensure architectural
  soundness
• NASA missions generally follow rigorous software
  processes that increasingly rely
• on software modeling, e.g., Mission Data System
  (JPL), Space Shuttle (United Space
• Alliance)
• Currently, however, software models serve merely
  as documentation that becomes
• obsolete when crunch time hits

Our research goal develop algorithms and tools
that allow software models to be kept in sync
with each other
3
Overview
Validate Requirements
Use cases (scenarios)
Requirements
Reduce transformational errors
???

• Focus on scenario-based requirements
• Translate automatically to state machine designs
  and on to code
• UML context
• Application CTAS (Center Tracon Automation System)

State machines
Design
Code generators (Rational Rose)
C/Java/
Code
4
What is a Scenario?
Scenario trace of an individual execution of a
(software) artifact
UML Sequence Diagram

• shows the global interactions between
  classes/components
• describe concrete interactions ? good for early
  development and communication
• part of popular software development
  methodologies (e.g., use-case based)

But local view needed for design/implementation/va
lidation
5
State Machine Synthesis
A
B
C
s1
p
q
r
s1
s
t
6
State Machine Synthesis
A
B
C
a
s1
s
t
b
s1
p
q
s1
a/
b/
s/t
p/q
r/
7
State Machine Synthesis
c/
a/
b/
p/q
p/q
r/
r/
8
State of Play
July 03
Dec 02

• Synthesis algorithm re-implemented as COM C
  object/ plug-in to Rational Rose
• CTAS case study positives
• It worked!
• CTAS team to use tool on trajectory subsystem
• CTAS case study negatives
• Precise and complete requirements
• Question can we use tool to flesh out/validate
  requirements?
• Methodology
• Interaction patterns
• Question can we better support design process?
• Interaction patterns

• Synthesis algorithm prototype in Java
• Proof-of-concept case study CTAS weather
  forecast update system
• 10 pages of natural language requirements
• Modeled as UML scenarios
• Synthesized state machines
• Generated C code using RoseRT
• Inserted tested in CTAS
• Work reported at ICSE, May 2003

9
Work Underway

• More precise scenario language
• Add scenario relationships to UML scenarios
• S1 OR S2, S1 AND S2, S1 preempts S2, S1 suspends
  S2, temporal relationships
• Extend to UML2 sequence diagram notation
• Alternatives, interleaving, coregions etc.
• A methodology for generalizing/refining scenarios
• A catalogue of patterns for implementing
  scenarios as state machines

10
Scenario Relationships
S1
S2 preempts S1
S2
A
B
C
a
b
a/
c
r/
d
b/c
Hierarchical state machine
d/
11
Methodology I

• For requirements validation, it is easy to write
  down nominal scenarios, but eliciting less
  obvious scenarios is more difficult
• We developed a methodology for refining/generalizi
  ng scenarios

Generalize/ Refine Scenarios
Develop Scenarios
Apply Synthesis Algorithm
Refine State Machines
Use state machines as desired, e.g., validation,
code generation
12
Methodology II

• Write down nominal scenarios
• Generalize/Refine nominal scenarios
• Should a message sent to an instance of class be
  sent to all instances of that class?
• Does a message really depend on all messages that
  have gone before or just some of them?
• Is the message order crucial?
• Can a message fail what is the handler?
• Is additional synchronization information needed?
• Apply synthesis.
• Validate and iterate

13
Methodology III

• Applied to trajectory uplink/downlink scenarios
  from CTAS
• Customer independently developed conflict
  detection scenarios.
• We specified relationships between conflict
  detection scenarios and generalized/refined
  scenarios using our methodology
• We derived state machines by hand. Synthesis
  algorithm needs to be enhanced to enable
  automatic synthesis.

14
Interaction Patterns

• User may want more control over the synthesis
  algorithm
• to introduce design choices
• to integrate with existing code
• to capture information more abstractly
• Interaction patterns are a good way to do this
• Developing a catalogue of interaction patterns
  with collaborators from Carleton University
  (Francis Bordeleau, Toby McClean)
• Research challenges
• Need a precise way to represent patterns
• Need to integrate patterns with synthesis

15
Interaction Pattern Specification(Dae-Kyoo Kim)
context jUpdate inv self.messageSort asynchcall
16
Pattern Realization
17
Patterns So far

• Developed a precise specification for an object
  synchronization pattern
• Will implement a way of representing patterns in
  Rational Rose and of instantiating those patterns
• Integrate patterns with synthesis to generate
  architectures structured state machines from
  patterns scenarios

18
Summary

• Proof-of-concept of state machine synthesis from
  scenarios CTAS case study
• CTAS team wants to use the synthesis algorithm to
  validate trajectory generation
• Extending synthesis algorithm towards
  requirements validation
• Scenario relationships
• Methodology for generalizing/refining scenarios
• Interaction patterns to control synthesis
• Initial ideas tested on conflict detection
  scenarios