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

Loading...

PPT – Transitioning From Software Requirements Models to Design Models PowerPoint presentation | free to download - id: 98345-MWYwN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Transitioning From Software Requirements Models to Design Models

Description:

on software modeling, e.g., Mission Data System (JPL), Space Shuttle (United Space ... Currently, however, software models serve merely as documentation that becomes ... – PowerPoint PPT presentation

Number of Views:63
Avg rating:3.0/5.0
Slides: 19
Provided by: jonathan48
Learn more at: http://www.nasa.gov
Category:

less

Write a Comment
User Comments (0)
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 leading to
    possible flaws and missed reuse opportunities

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 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
  • RoseRealTime
  • Inserted tested in CTAS
  • Work reported at ICSE, May 2003
  • 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

9
Work Underway
  • More precise scenario language
  • Extend to UML2 sequence diagram notation
  • Alternatives, interleaving, coregions etc.
  • Add scenario relationships to UML scenarios
  • S1 OR S2, S1 AND S2, S1 preempts S2, S1 suspends
    S2, temporal relationships
  • 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
About PowerShow.com