Transitioning From Software Requirements Models to Design Models - PowerPoint PPT Presentation

1 / 18
About This Presentation
Title:

Transitioning From Software Requirements Models to Design Models

Description:

... From Software Requirements Models to Design Models. PI: ... d. S1. S2. S2 preempts S1. s1. p/q. s/t. r/ a/ b/c. d/ Hierarchical state. machine. Methodology I ... – PowerPoint PPT presentation

Number of Views:168
Avg rating:3.0/5.0
Slides: 19
Provided by: jonathan48
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com