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

MaramaSUddEN example: simple plan of this presentation.

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:o Meta-model (entities and associations)o View (shapes and connectors)o View Type (view to meta-model mapping)o And the tool’s behaviour (constraints &operations using event handlers,

formulas, etc)).• Used Marama to try and develop a “function block” tool. End

productTool design

What We Did (2)• Improved two existing tools: “MaramaSUddEN” (a supply

chain modelling tool) and “MaramaFB” (a function block designing tool). o Practise writing custom event handlers,o And using Marama API to expand diagram functionality /

behaviour.• Moved to a new version of Marama that was currently

being developed.o Tested our tools “MaramaSUddEN” and “MaramaFB” in the new

version to check for differences in functionality (i.e. bugs). o 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:

o Some specific to the new version of Marama, some pre-existing.• Compiled a list of suggested improvements for Marama.

o Mostly addressed “nuisances” in Marama.• E.g. not being able to move files around because absolute paths

were stored in xml files…o Didn’t fix any of these issues (because they would have been

complex tasks).

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

Bugs & suggested improvements.

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.o 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.o 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.o 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.

New features + JUnit.

What We Did (4)• Committed our changes to the Marama SVN

Repository.o Other developers could view our changes and update

their own workspace with what we had done.o 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. o Previous process was multi-step and very time

consuming…o Adopted a “Wizard” approach to automate much of the

mapping process.o Speeds up development time significantly.

• Gained experience using the Eclipse SWT (Standard Widget Toolkit) package for visual components.

SVN + Mapping Wizard example.

What We Did (5)• Part 3 of our objectives: advanced GUI improvements. • Added a “dynamic key” feature to Tool diagrams .

o Creates a unique key value for new shapes on creation.• Added a new method to the API to duplicate shapes.

o 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.o Previously had to drag to size wanted.o Now has both – click for default, drag to specify size.

• Continually updated the SVN Repository with our new code.o Constantly finding and fixing bugs as well.

• Used test suite to identify and fix build breakages.o Some in Marama itself, most because of us.

New features.

New features.

What We Did (6)• Must Have objectives completed.• Could Haves: more GUI improvements.

o Dynamic anchor points for connectors onto shapes (incomplete – too complex).

o Ability to have buttons (+ event handlers for them) on shapes (complete).

• Revised earlier bug-list.• Investigated and fixed several visual bugs:

o Connectors not touching the sides of non-rectangular shapes.o Square brackets being continually added to some text fields (fixing

this fixed many serious issues associated with the new version of Marama).

o A few minor bug fixes too.• Fixed several failing test cases in the MaramaTests package. • Prepared for reports and presentations.

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…

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.

Marama package hierarchy.

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.

Final Thoughts on Marama Marama in its current condition has quite a few issues

that can make it rather difficult to use ◦ Bugs, some non 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.

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.

ThanksWe 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.

Questions?