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 Our research goal: develop algorithms and tools that allow software models to be kept in sync with each other

Overview ??? Validate Requirements 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

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 B C s1 p/q s/t r/ s1 p q r s1 s t

State Machine Synthesis B C s1 p q r s t A B C a s1 s t b s1 p q s1 a/ b/ s/t p/q r/

State Machine Synthesis B C c p q r c/ s1 a/ b/ s/t p/q p/q r/ r/

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 RoseRT 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?

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

Scenario Relationships B C s1 p q r s t S1 S2 preempts S1 S2 A B C s1 a s/t p/q b a/ c r/ d b/c Hierarchical state machine d/

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 Generalize/ Refine Scenarios Develop 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