1 / 18

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

rune
Download Presentation

Transitioning From Software Requirements Models to Design Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related