Presentation Guide Lines

Each group will be expected to give a 25-minute "professional" presentation on their work.  (Which is equivalent, by the way, to a standard 25-minute conference presentation).  The presentation can be given by one person or several; the choice is up to you.  But you must finish in 25 minutes and this requires you to: rehearse, rehearse, rehearse.  It will be obvious to me and to everyone else in class if you have dropped the ball on this point.  So be forewarned and don't embarrass yourself!

Next, remember that you can't cover everything.  25 minutes is NOT a lot of time.  It is barely enough time for you to answer the basics, such as the following questions (which are fundamental questions you should answer in any research endeavor):

  1. What is the general problem?

  2. Why is it important?

  3. What specifically did you (or your group) do?

  4. Why is it important?

Questions 1,2,4 can be dispensed with easily.  Question 3 is where you will spend the bulk of your time.  Here are some suggestions:

Your Submission on Wednesday, May 2

For Project 2 and 3 groups, you are to submit a manual that, step-by-step, walks your readers through a series of standard examples and shows them how to use your tool.  The notion of standard example is this: talk to your counterpart group and choose 2 examples that you both will present/elaborate.  You can present other examples in your write-ups or have them in appendices (that would be good).  But do share the same examples so that their explanation can be brief.  This will allow you to concentrate on the real details that you need to present.  For example, look at this link which explains how to produce an Eclipse-based editor (complete with OCL constraints on a metamodel).  I used this page last year in my undergrad class, but this use of Eclipse didn't work well.  The most important thing is for you to tell others on how they can use your tools.

For the Project 1 group: you are to submit an overview of your work, explaining where others can find your prolog transformations and constraints.  It should be abundantly clear the input format you expect as input (or that one could subsequently massage a set of tables into) and the output format that you produce.  This information will be used by Project 2 and 3 groups to understand what you have done, and to make sure that they can use your results. Should you given an example, assume your audience knows prolog.  What you can do is concentrate on what you have learned.  This years "project" is an experiment -- can we bring MDE concepts to the masses by using a fundamental language in computer science (as opposed to an "engineers" language)?  Is prolog really suitable, considering the alternatives?  But the most important thing is to tell others how they can access your work & results for them to use.

Incidentally, THE alternative is OCL.  Follow this link to a how-to-do page on using and testing OCL on an example you created.  I used this in my undergrad class last year and, while the page was decent w.r.t. instructions, far too many people couldn't get things to work.

Back to Your Presentation

I would gear my presentation (if I were you) on your written submission.  Choose one example (agreed upon by your counterpart group) that you both will present.  Again, in this way, you have to spend little time on explaining it.  And then show people how your tool works, how it can be used, the limitations, what should be avoided, etc.  Any insights that you may in the process of building your tool, please let us know.

Remember that there will be 35 minutes total for each group: 25 minute presentation (which I will terminate at the 25 minute 1 second mark).  So a presentation that finishes in 23 minutes would be perfect; handling questions should be very easy.

I will add to this note, periodically, as I get more input and ideas from you.