Running Bear (M2T) Transformations
In P1, you harvested data from Java
byte codes to
produce an instance of a prog1
database, consisting of tables bcClass
In this assignment, you will use RunningBear (RB) to
translate a prog1
into a YUML specification, x.yuml.yuml,
where x is
specified on the command line.
You may work alone or in groups of two.
Assignment Big Picture
You are to write a program that
implements a model-to-text transformation with the following
> java prog1ToYuml.Main X.prog1.pl [outputFile]
database that you produced in assignment P1. The default
output file is X.yuml.yuml,
otherwise whatever name is given as the
output file is used. The output of prog1toYuml is a
specification, which you simply copy
into the YUML web
page to produce a drawing.
Bear and YUML Specs
is written on RB,
simply because it is a trivial Java class of 8 methods. You
will find RB
source file in the MDELite7/src/MDELite/
directory (a reasonably
up-to-date copy is here). Have a look. I
will provide you with a shell
program that will get you started. As for YUML
read the first part of the YUML manual in MDELite7/Docs (a reasonably up-to-date copy is here).
It will tell you what you need to know.
an even bigger hint, the Yuml.ClassUnparser,
is an RB
program that translates a VPL to Yuml Spec (a reasonably up-to-date copy is
here). So you have a lot to go on to complete this assignment.
Tables and Associations
is a repeat of the schema of prog1
Yuml specs for classes is not difficult. The tuples in bcClass
are given to you. What is a challenge is to determine
associations, which Java doesn't do a particularly good job to
- Database schema prog1 contains
2 table definitions: bcClass
- Table bcClass
has 3 columns or fields or attributes (they all mean the same
-- class identifier
-- qualified class name
-- qualified name of superclass
- Table bcMember
has 5 columns or fields or attributes (they all mean the same thing)
-- member identifier
-- identifier of class that mid is a member
-- true or false -- is the member static?
-- return type of the member (or simply for fields, type of the member)
-- signature of the member, for a constructor of class File it is
Hint: if you are
looking at the members of
class C, and you find a variable of class D (where both C and D are
represented by tuples in bcClass),
you can infer an association from
C→D. Symmetrically, if you are in class D and find a variable
of class C, you can infer an association from D→C.
problem is that without deep program analysis (which is debatable
whether it is worth doing), you don't know if C→D and D→C are
TWO distinct associations or ONE. So, what you do is to play
safe and assume C→D is a
different association than D→C.
Sad, but such is life.
As P1 specifically restricted its output to only public fields (static
or non-static), you will find few opportunities to draw
associations. I've added a new prog1 database to the mix, Tree.prog1.pl, which if you
draw it you'll get the following diagram:
Netbeans shell to get you started.
that there is an Node array in tree.Nonterminal named children.
converted this into "* children", meaning it is a * association.
If it were just a variable children of type Node, I would
produced "0..1 children".
Take a look at pong.prog1.pl too -- Yuml
doesn't draw it particularly well:
to Submit to Canvas
A zip file with all source code
your Netbeans or Eclipse Project). The zip file
must unzip into <yourLastName>/<YourFilesAndDirectories>
if you work alone or <LastName1-LastName2>/<YourFilesAndDirectories>
if you work in a group.
program needs to run correctly on Linux machines, even though you may
have developed them on Macs and Windoze. The TA will grade
program running on Linux.
The Grader should be able to invoke
your program just like "java
exactly like the above
from a command line in the unzipped
directory. The Grader will reject any submission where this is not the
your PDF document, show the contents of each X.yuml.yuml file you
produced, along with its YUML representation. The 8 Java
packages that you are to draw Yuml diagrams are in this zip file.
- A PDF file
(in the required
format) that the
Grader should read to provide any information that is not obvious.
The contents of the PDF file can be minimal.
You should expect that other packages,
known only to the grader, will be used to evaluate your program.
A critical part of any
design is clarity and understandability. Hence, you
will be graded on the clarity of your project and its ability to work
correctly. Sloppy code, documentation, or anything that makes
grading or understanding your program difficult will cost you
points! Beware, some of these "beauty" points are
late assignments/submissions will be accepted.