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 • Focus on scenario-based requirements • Translate automatically to state machine designs and on to code • UML context • Application CTAS (Center Tracon Automation System) Use cases (scenarios) Requirements Reduce “transformational errors” ??? 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/validation

5. s1 s/t p/q r/ State Machine Synthesis A B C s1 p q r s1 s t

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

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