Marama Project Presentation (part 2): --- Johnson & Robert

1. Marama Project Presentation (part 2): --- Johnson & Robert MaramaSUddEN example: simple plan of this presentation.

2. What We Did (1) • Spent a fair amount of time trying to get Marama installed correctly! • Played around with Marama – learned about what it’s used for and what it can accomplish. • Learned how to create modelling tools using Marama by designing the: • Meta-model (entities and associations) • View (shapes and connectors) • View Type (view to meta-model mapping) • And the tool’s behaviour (constraints &operations using event handlers, formulas, etc)). • Used Marama to try and develop a “function block” tool. Tool design End product

3. What We Did (2) • Improved two existing tools: “MaramaSUddEN” (a supply chain modelling tool) and “MaramaFB” (a function block designing tool). • Practise writing custom event handlers, • And using Marama API to expand diagram functionality / behaviour. • Moved to a new version of Marama that was currently being developed. • Tested our tools “MaramaSUddEN” and “MaramaFB” in the new version to check for differences in functionality (i.e. bugs). • New version of Marama was very buggy… but we managed to get our tools to a working state. • Compiled a list of bugs for the new version of Marama: • Some specific to the new version of Marama, some pre-existing. • Compiled a list of suggested improvements for Marama. • Mostly addressed “nuisances” in Marama. • E.g. not being able to move files around because absolute paths were stored in xml files… • Didn’t fix any of these issues (because they would have been complex tasks).

4. MaramaSUddEN in the new version of Marama (albeit with most of the bugs fixed).

5. Bugs & suggested improvements.

6. What We Did (3) • Part 2 of our objectives: basic GUI and interface improvements. • Made it possible for “associations” (in the tool model definer) and “mappings” (in the view type definer) to be created automatically by drawing a single connector. • Previously had to create a shape and set its properties manually… • Implemented a grey box floating above a shape in the Shape Definer displaying the shape’s name. • Makes it easier for the user to identify which shape is which. • Added new test cases to the MaramaTests package to test our new code. • Marama uses JUnit to perform unit tests. • Now confident with the workings of much of the core Marama code and gained useful experience with JUnit.

7. New features + JUnit.

8. What We Did (4) • Committed our changes to the Marama SVN Repository. • Other developers could view our changes and update their own workspace with what we had done. • Required some changes to Marama data files (xml files) that weren’t stored in the SVN Repository… had to upload these too. • Worked on improving the mapping creation process. • Previous process was multi-step and very time consuming… • Adopted a “Wizard” approach to automate much of the mapping process. • Speeds up development time significantly. • Gained experience using the Eclipse SWT (Standard Widget Toolkit) package for visual components.

9. SVN + Mapping Wizard example.

10. What We Did (5) • Part 3 of our objectives: advanced GUI improvements. • Added a “dynamic key” feature to Tool diagrams . • Creates a unique key value for new shapes on creation. • Added a new method to the API to duplicate shapes. • Takes in an instance of a MaramaShape and returns another MaramaShape that is a copy of the original. • Allowed shapes to have a default size when created. • Previously had to drag to size wanted. • Now has both – click for default, drag to specify size. • Continually updated the SVN Repository with our new code. • Constantly finding and fixing bugs as well. • Used test suite to identify and fix build breakages. • Some in Marama itself, most because of us.

11. New features.

12. New features.

13. What We Did (6) • Must Have objectives completed. • Could Haves: more GUI improvements. • Dynamic anchor points for connectors onto shapes (incomplete – too complex). • Ability to have buttons (+ event handlers for them) on shapes (complete). • Revised earlier bug-list. • Investigated and fixed several visual bugs: • Connectors not touching the sides of non-rectangular shapes. • Square brackets being continually added to some text fields (fixing this fixed many serious issues associated with the new version of Marama). • A few minor bug fixes too. • Fixed several failing test cases in the MaramaTests package. • Prepared for reports and presentations.

14. What We Learned (1) • Marama is an example of good object oriented programming,we learned the advantages of designing software this way: • Packages are good for code organisation, etc. • Commenting code properly helps A LOT. • Meaningful package, class, and method names help too. • Automated testing makes testing easy and repeatable (Marama uses JUnit). • The Model-View-Controller approach is great (and is the central theme of Marama itself). • Factories, controllers, constants classes, etc centralise certain common functionalities and makes things easier to change. • Singletons and reusing object instances prevent unnecessary object creation and increase performance. • Extensive use of interfaces and abstract classes has many advantages: • type safety, improved compile time checking, code reuse, modifying behaviour of super-classes, etc… • Use of events / notifications and event listeners to achieve organised communication between classes is of course beneficial…

15. What We Learned (2) • We gained an idea of the kind of scale that software solutions often have: • Marama has hundreds of source files and is the result of collaboration between many people over many years. • There are many more things to consider than there appears to be on the surface. • Even when using libraries like Eclipse’s SWT, GEF and EMF, which are supposed to simplify applications by reducing the amount of code that needs to be reinvented, the software solution is still large.

16. Marama package hierarchy.

17. What We Learned (3) • We learned the benefits of using advanced software development tools: • Jira: an issue management service. • SVN: an online source code repository. • The Eclipse platform (and the myriad of add-ons / plug-ins): • Reusing a well known and stable platform. • Saves having to re-write code for what has already been done and thoroughly tested. • Eclipse debug feature is especially useful.

18. Final Thoughts on Marama • Marama in its current condition has quite a few issues that can make it rather difficult to use • Bugs, somenon user friendly interfaces… • …But the tool in theory would be very useful in a large number of situations. • It’s very dynamic! • Can be used to create almost any sort of modelling tool. • Hence could be used to model nearly anything you put your mind to. • We think that once Marama has most of its critical issues fixed, it would become a very useful Eclipse tool to use. It would enable users to quickly develop Domain Specific modelling tools for their own (probably special purpose) modelling needs.

19. References • Marama wiki page: https://wiki.auckland.ac.nz/display/csidst/Welcome. Or just navigate to the UoA wiki dashboard, then click on the “Marama” link. • Has downloads (including Marama source code), • Tutorials (including a video tutorial), • Presentation slides, • Example tools made using Marama, • …and more. • Our project objectives and work log page: https://wiki.auckland.ac.nz/display/csidst/Marama+Project+Management+2008. Can be found through the Marama wiki page, but may not be easy to spot.

20. Thanks We thoroughly enjoyed our project and would like to thank the following people for all their help and for giving us this opportunity: • Jun Huh • John Hosking • John Grundy • Richard Li Also, thanks to The University of Auckland, and everyone involved in The CSI Academy. We learned a lot from Marama, our mentors, and the Academy seminars. We are grateful.

21. Questions?