Hey Professor,
In this email I’m going to give you some background information on xtUML, the link to what we call an “analysis note” (the first stage of our engineering process), and my proposal for a delivery schedule.
The analysis note you will read does not make much sense unless you are familiar with xtUML and BridgePoint and some of the ins and outs of how it all works.
xtUML is a language based on the computer science concept of object oriented analysis (OOA) and the Shlaer-Mellor method of software development. This method was created by Sally Shlaer and Steve Mellor in the late 80s. It focuses on first modeling data in classes and associations between classes, then modeling behavior in states, events, and transitions, and finally modeling actions in a textual language.
BridgePoint is an open source tool based on eclipse that allows users to edit xtUML models. It also includes Verifier, which allows users to interpretively execute models and a set of model compilers that generate code from a model to a chosen architecture/language.
xtUML itself is modeled using xtUML (this is referred to commonly as the meta-model or the OOAofOOA). The editor creates instances of the classes in this model to build application models. Model compilers can query this model to generate code. For example, a model compiler can ask for all the instances of class Attribute, and generate a line of Java code for a member in a Java class.
Historically, model compilers have been written in a template language called RSL. RSL queries the meta-model instances and generates code based on the attributes and relationships of those instances. This is an effective way to generate code, but it is slow for large models because it is interpreted.
The main compiler we use (MC3020) generates C code. A handful of years ago, a new partial compiler called mcmc was introduced based on MC320. This compiler is actually compiled with BridgePoint (more levels of meta!) and it is very fast, but it only compiles the action language portion of the xtUML model (textual language). Overall it decreases the build time for a large model significantly (order of 10 in some cases).
We have another compiler called MC-Java which is used to compile BridgePoint to Java plugins for eclipse. It is quite old and messy and cannot be used for generic Java. There are a lot of problems with MC-Java, but one we can solve now is to extend mcmc to also translate action language to Java. We can integrate this with MC-Java and it should cut our build time down significantly for BridgePoint. This is very desirable right now because a full build of our tool can take almost an hour. This project will greatly help our developers.
If you have any more questions about how this works, let me know. You can also look at onefact.net and xtuml.orgfor more information.
Here is the link to the analysis note:
There are 8 weeks in the semester. Below is my proposed delivery schedule:
Week 1:
– Analysis note draft delivered
– Deliverable schedule
Week 2:
– Analysis note complete/reviewed
Week 3:
– Design note complete/reviewed
Week 4:
– Test plan delivered
– Presentation of One Fact engineering process delivered
Week 5:
– Implementation status update
Week 6:
– Implementation complete
– Implementation note delivered
Week 7:
– Testing completed
Week 8:
– Work promoted
– Presentation
Some of these terms are specific to our engineering process. I am planning on making some sort of presentation (maybe slides with voiceover or video demo, not sure yet) describing the engineering and review process we employ at One Fact. Let me know if you have any questions before then. I’d be happy to explain anything.