# Presentation: 168384

## Transitioning From Software Requirements Models to Design Models

- PI: Jon Whittle
*Qss Group Inc. *

- NASA POC: Michael Lowry
*Ames Research Center*

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

## Overview

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

- Requirements

- Design

- Code

- Code generators
- (Rational Rose)

- Use cases
- (scenarios)

- State machines

- C++/Java/...

**???**

- Reduce “transformational errors”

- Validate Requirements

## 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/validation

## State Machine Synthesis

- A

- B

- C

- s1

- s1

- p

- q

- r

- s

- t

## State Machine Synthesis

- s1

- p/q

- s/t

- r/

- A

- B

- C

- s1

- a

- s

- t

- a/

- s1

- b

- p

- q

- b/

## State Machine Synthesis

- p/q

- r/

- a/

- b/

- p/q

- r/

- c/

## State of Play

- Dec 02

- July 03

-  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

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

## Scenario Relationships

- A

- B

- C

- a

- b

- c

- d

- S1

- S2

- S2 preempts S1

- r/

- a/

- b/c

- d/

- Hierarchical state
- machine

## 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/generalizing scenarios

- Develop
- Scenarios

- Generalize/
- Refine
- Scenarios

- Apply
- Synthesis
- Algorithm

- Refine
- State
- Machines

- Use state machines as
- desired, e.g., validation, code generation

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

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

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

## Interaction Pattern Specification(Dae-Kyoo Kim)

- context jUpdate inv: self.messageSort = asynchcall

## Pattern Realization

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

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