Transitioning From Software Requirements Models to Design Models

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 Validate Requirements Use cases (scenarios) Requirements ? ? ? State machines C++/Java/… Design Code Reduce “transformational errors” • Focus on scenario-based requirements • Translate automatically to state machine designs and on to code Code generators • UML context (Rational Rose) • Application CTAS (Center Tracon Automation System)

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 s 1 p s 1 s/t p/q q r s 1 s t r/

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

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

State of Play 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 Rose. Real. Time • Inserted & tested in CTAS • Work reported at ICSE, May 2003 July 03 • 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 UML 2 sequence diagram notation • Alternatives, interleaving, coregions etc. – Add scenario relationships to UML scenarios • S 1 OR S 2, S 1 AND S 2, S 1 preempts S 2, S 1 suspends S 2, temporal relationships • A methodology for generalizing/refining scenarios • A catalogue of patterns for implementing scenarios as state machines

Scenario Relationships A B C s 1 p r S 1 q s 1 s t A B C S 2 preempts S 1 S 2 s 1 a b a/ c s/t p/q r/ d 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 1. 2. Write down nominal scenarios Generalize/Refine nominal scenarios • • • 3. 4. 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 Mc. Clean) • Research challenges: – Need a precise way to represent patterns – Need to integrate patterns with synthesis

Interaction Pattern Specification (Dae-Kyoo Kim) context j. Update inv: self. message. Sort = 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