Project

On this page you can find a clearinghouse of information related to your project's design, implementation, requirements, etc.

Project Companion

This page serves as your project companion for this course.

Project schedule at a glance

You can see the project schedule on the Schedule of Weeks page.

Project Proposal

You must turn in a project proposal, which consists of:

  • A description of your project, which should be readable by any person taking this course
  • A verbose discussion of the domain you are planning to abstract, including:
    • Types (anticipated)
    • Constraints
    • Semantics
  • A discussion detailing the technology space for the semantic output you expect, e.g., code, configuration files, MATLAB scripts, other models, etc.
  • A timeline (adhering to the one on the Schedule of Weeks) where you discuss your planned deliverables, and project workload
  • Supplemental materials, including any existing modeling languages related to your planned one, or existing visual terminology for your domain.

Your proposal will be graded on its merits. Proposals that are unclear, or do not address the above points, will receive reductions in their grades. Treat this proposal as just that: a proposal. If I (the "funding agency") may be unclear about your objectives, or your approach, I might not "fund" your proposal (just as I may not give it a good grade). It may be useful for you to have someone else vet your proposal. However, do not have someone else help you with the writing portion---that is your responsibility. You can accept comments from others, but the work must be your own.

Turning in Project Documents

The design documents, project metamodel, and interpreter design are all submitted to their respective assignment names on d2l. You do not need to submit a paper version of your project documents!! Please submit in a .tgz file format if you expect more than one file. Otherwise, the .xme is okay for the metamodel.

Your interpreter design is not necessarily the entire interpreter. The best submission for this is a document describing your preliminary design. You should, however, know the following things by the time you finish your interpreter design document:

  • Language that will be used
  • Output artifact. You should know everything about your output artifacts, including formatting if it is a particular artifact used by another file. Providing an example artifact (hand-made, or from the tool's example if you are producing tool-specific artifacts) will help you understand how metamodel types and structure map to the output artifact.
  • Visitor or OO traversal strategy, including preliminary algorithm

Class diagrams, etc., may be beneficial to you, but the above portions will help me understand your interpreter design, and give you any feedback necessary.

Final Project Submission

Your project will contain the following traits:

  • A domain-specific modeling environment, implemented in GME
  • A visual language, generated using the MetaGME modeling language
  • At least one semantic interpreter, which generates a useful artifact
  • Documentation, in the form of an academic style paper, which details
    • The project overview
    • Design principles
    • Details on the domain expert
    • Artifact description
    • Interesting implementation details
    • Lessons learned

Use IEEE conference style to create your final document.

You can submit your project only via d2l. Please have your submission as:

  • One single .tgz or .zip file
  • Containing:
    • all of your source code
    • your updated design document in the root directory
    • your documentation (final report) in the root directory
    • a README file in the root directory, which explains how to compile and how to run your project.

Project Demonstrations

Project demonstrations should reflect the current state of your code at the time of the demonstration. It is understood that you will be making refinements to the final product at this time. The purpose of the demonstration is (a) to make sure you have something running before the deadline, and (b) to allow you to demonstrate the "final" code so that during grading, the instructor will be able to run your program.

Here are a few basic requirements:

  • Remind the instructor of your requirements
  • Show your overall project running
  • Show several examples, or demonstrate how you tested that it works

Here are a few pitfalls:

  • Do NOT:
    • Show up and say "well, it worked this morning, but doesn't now"
    • Plan to build the code at the beginning of your demonstration, only to realize that you're missing some files on this machine

Suggestions:

  • Make sure to bring a power supply if you are using your computer
  • Do a dry run one hour before your demo to the instructor
  • Be prepared for 'demo demons', by having a backup version, or another machine