1. May08-21 Model-Based Software Development Kevin Korslund Daniel De Graaf Cory Kleinheksel Benjamin Miller Client – Rockwell Collins Faculty Advisor – Dr. Suraj Kothari

2. May08-21 Model-Based Software Development Requirements Specification Project Plan Design Method Engineering Specification Detailed Design

3. Requirements Specification Model Based Development  Visual model of software Blocks represent functions Blocks linked together to implement solutions  Tool generates source code from model  Reduce number of bugs in software  Map closely to requirements specification

4. Requirements Specification Problem / Need  Generated code must be manually verified  Code may exceed 750,000 lines of code  Costly in time and labor  Human error may be introduced Purpose  Develop automated tool to verify correctness of code No extra functionality added by compiler No functionality removed by compiler

5. Requirements Specification Concept Sketch / Mockup  Integration into the Eclipse platform as a menu option  Command line output may look like this: Reading c files... done Detecting Simulink blocks... done Inferring Block Relationships... done Verifying Block Correctness... done Generating Simulink File... done Done processing, all files correct.

6. Requirements Specification

7. System Description 1. Convert C code into a syntax tree 2. Use heuristics to identify Simulink blocks 3. Infer relationships and common variables 4. Verify block correctness 5. Generate new Simulink mdl file.

8. Requirements Specification Operating Environment  This application will run as an Eclipse plug-in.  It will require a Java Runtime Environment of 5.0 or later.  Operating systems supported include Microsoft Windows, Linux, and Mac OS X.

9. Requirements Specification User Interface  The intended user interface for this application will be an Eclipse plug-in.  A menu option will be added to the right-click menu of folders containing compiled code.  The plug-in will invoke the model generator on the selected folder.  The model generator will be a backgroundable job in Eclipse, displayed using the standard job progress dialog.

10. Requirements Specification User Interface Mockup

11. Requirements Specification Functional Requirements  Input FR1. The application shall read the C files produced by Real-Time Workshop FR2. The application shall not read the original model files used to generate the code FR3. The application shall provide feedback to the user if it cannot parse the C files FR4. The application shall provide feedback to the user if the C files contain unknown elements FR5. The application shall provide line numbers from the C code for all generated errors.

12. Requirements Specification Functional Requirements (Cont.)‏  Output FR6. The application shall produce one or more valid simulink files FR7. The simulink files shall accurately reflect the execution flow of the source C code FR8. The simulink files shall be easy to read by humans FR9. The simulink files shall be similar in format to the source files RT-workshop used FR10. The simulink files may contain comments indicating the source location in the C code for a particular element

13. Requirements Specification Functional Requirements (Cont.)‏  Extensibility FR11. The application shall provide a programming interface for addition of additional block types FR12. The application shall use Eclipse's extension point mechanism to integrate with the Eclipse platform and provide extensibility

14. Requirements Specification Non-Functional Requirements NFR1. The application shall be usable on any system capable of running Eclipse and Eclipse plug-ins. NFR2. The end user shall be able to learn how to operate the software within one hour. NFR3. The reproduced model shall contain at least 95% of all original blocks and lines.

15. Requirements Specification Market/Literature survey  Honeywell International - patent 20050114841 for an \Automatic computer code review tool" in 2004. Never issued Also designed to aid engineers in meeting DO-178B guidelines; however, the method differs from ours. They generate \expected source" and compare it with generated source We reproduce the model file from the source code and compare it to the original model file.

16. Requirements Specification Deliverables 1. Requirements specification 2. Project plan 3. Engineering specification 4. Design Documents 5. Application executable (source code?) 6. User's manual 7. Project Poster 8. Website

17. Project Plan Work breakdown structure  Create Simulink models and C code 1.1: Learn how to use Simulink 1.2: Create models from basic Simulink blocks 1.3: Learn how to use RealTime Workshop 1.4: Generate C code from Simulink models

18. Project Plan Work breakdown structure (Cont.)‏  Identify logical Simulink blocks from C code 2.1: Analyze C code for understanding 2.2: Using Simulink model find corresponding components in C 2.3: Research methods to identify models from C code 2.4: Develop Algorithms to detect models from C code

19. Project Plan Work breakdown structure (Cont.)‏  Develop syntax tree 3.1: Create tokens 3.2: Analyze tokens and convert to graph  Process blocks 4.1: Extract parameters 4.2: Extract links 4.3: Extract metadata

20. Project Plan Work breakdown structure (Cont.)‏  Output to Simulink Model 5.1: Learn Simulink model file structure 5.2: Generate model from processed blocks  Verify generated model is functionally equivlent 6.1: Use model generator to convert generated C code back to a Simulink model 6.2: Use SimDiff to compare original models to generated models

21. Project Plan Work breakdown structure (Cont.)‏  User Interface 7.1: Generate a graphical interface as an Eclipse plug-in  Testing and Debugging 8.1: Develop Test Cases 8.2: Develop Test Plan 8.3: Execute Test Plan

22. Project Plan 81 20 21 27 13 6 Task 1 - Create Simulink models and C code Task 2 - Identify logical Simulink blocks from C code Task 3 - Process blocks Task 4 - Develop syntax tree Task 5 - Output to Simulink model Task 6 - Verify generated model is functional equivalent Task 7 - UI Task 8 - Testing and Debugging 514116297628529438Total 1213010162112210Kevin Korslund 12928818493110Daniel DeGraaf 126308172141810Cory Kleinheksel 138283252018238Ben Miller Total8754321Personnel Name Resource Requirements  Estimated man hours for each task

23. Project Plan *- Site-licensed to Iowa State University $50.0010Totals $0.00 $1900.00* $3000.00* $7500.00* 00000000 Eclipse MATLAB- 7.5 Simulink- 7.0 Real-Time Workshop- 7.0 Software $50.0010Print Project Poster Parts and Materials CostMan HoursItem Resource Requirements (Cont.)‏  Estimated project costs

24. Project Plan $5290.00$50.00Total $1380.00 $1260.00 $1290.00 $1210.00 -------- Ben Miller Cory Kleinheksel Daniel DeGraaf Kevin Korslund Labor at $10.00 per hour $150.00$50.00Required Resources With LaborW/O LaborItem Resource Requirements (Cont.)‏  Estimated cost for each task

25. Project Plan Project Schedule

26. Project Plan Risks  Project has the potential to be an unsolvable problem Model data is lost during compilation Possibility of an NP-Complete problem  Rigid design structures will require numerous updates to project design documentation to keep up with this research based project (shorten)  Team members Little combined design experience No experience in Simulink No experience in reverse compiling  Time may become an issue Research based project whose solution is not known to be possible

27. Design Methods Brainstorming  Proactive approach to identifying problems  Team can creatively solve complex problems  Increase team unity through open collaboration of ideas and thoughts Agile Development  Respond to constantly changing project needs  Allows project to grow to maturity through iterative design steps  Frequent, thorough testing (Test early -> Test often)‏

28. Engineering specification Inputs / Processing / Outputs

29. Engineering specification No Additional Interfaces  Hardware  Software  Communication

30. Engineering specification Software Specification  Parse C Code Using Eclipse C Development Tools, generated code is tokenized and parsed into an abstract syntax tree  Detect Simulink Blocks Look for known patterns in syntax tree and detect Simulink blocks  Infer Block Relationships Link blocks together by identifying common variables between them

31. Engineering specification Software Specification (Cont.)‏  Verify Block Correctness Look for leftover code not matched Verify no functionality has been added Verify no functionality has been removed  Output to Simulink File Write a Simulink model with the same functionality as the original

32. Engineering specification Software Specification (Cont.)‏  Performance Requirements (put in requirements section) O(n^2) or better on the number of blocks in the source file Parse Models with 100 blocks or less in under a minute

33. Engineering specification Software Specification (Cont.)‏  SW System Attributes Reliability 95% or greater coverage on model of less than 100 blocks and less than 3 levels of model structure Availability No requirements – User initiated from eclipse application Security Will run on trusted machines by trusted users No additional security considerations Portability Runs on all platforms supporting Eclipse C Development Toolkit

34. Engineering specification User Interface  User interface shall be an Eclipse plug-in.  A menu option shall be added to the right-click menu of folders containing compiled code.  The plug-in shall invoke the model generator on the selected folder.  The model generator shall be a backgroundable job in Eclipse, displayed using the standard job progress dialog.

35. Engineering specification User Interface Mockup

36. Engineering specification Unit Level Testing  Parse C Code Input Generated C Code Verify Comments tied correctly to AST tree Verify All artifacts extracted and no extras  Detect Simulink blocks Input C code with both recognized and unrecognized blocks Verify resulting block detection  Infer Block Relationships Input C code Verify the identified block links

37. Engineering specification Unit Level Testing (Cont.)‏  Verify Block Correctness Input modified C Code to have errors and additional functionality Verify c2mdl identifies errors and the additional functionality  Output Simulink file Verify internal representation of models are translated into textual models as expected

38. Engineering specification System Level Testing  Labor intensive  Collection of Large model files  Procedure 1. Compile Model files 2. Run c2mdl 3. Compile Generated Model file 4. Run c2mdl 5. Compare Generated Model files  Layout information is lost during step 1  Layouts of two generated models with same functionality should be similar/identical

39. Detailed Design No Design Drawings Applicable  Mechanical CAD  Electronic CAD  PCB

40. Detailed Design Software Design  Overall class diagram

41. Detailed Design Software Design (Cont.)‏  Parser class diagram

42. Detailed Design Software Design (Cont.)‏  BlockMatcher class diagram

43. Detailed Design Software Design (Cont.)‏  Simulink class diagram

44. May08-21 Model-Based Software Development Requirements Specification Project Plan Design Method Engineering Specification Detailed Design

45. Questions / Answers

46. Summary