[TransWarp] UML and XMI support now available in TransWarp CVS
Phillip J. Eby
pje at telecommunity.com
Fri Jun 29 17:05:28 EDT 2001
Recently, there has been much interest (on Zope-Dev and elsewhere) in
creating Zope and Python applications from UML diagrams. Since to my
knowledge there are no other Python libraries currently available for
UML/XMI processing, I decided to get busy and "release" a version of
TransWarp with support for querying/manipulating UML models and reading XMI
files. That version is now available at cvs.eby-sarna.com, for brave UML
hackers to experiment with.
I say "release", but if you've ever heard the jokes about Klingon
programmers, you'll know that "Klingon programmers do not *release* code.
Their code escapes, leaving the bloody corpses of testers, users, and
documentation writers in its wake." This is pretty much the case for this
rough draft of UML/XMI support. It is functional, but the interfaces are
subject to future upheaval as I continue refactoring. This "release" is
ONLY for people who have a good understanding of UML, and aren't afraid to
UTSL (Use The Source, Luke).
* Load an XMI file into a UML Model object
* Query UML model using full StructuralModel features and querying interface
* Create your own custom classes for UML elements - e.g. you could redefine
"ModelElement" to include a method to print out a nice report on the
element's features. You could also implement "executable UML" with this
* **ALL** model attributes are strings, rather than their correct type, so
booleans for example are represented as the strings "true" and "false".
Note that this doesn't mean you can't manipulate a UML model which
*defines* non-string attributes. It's the attributes of the model *itself*
(like the 'isRoot' attribute of a 'GeneralizableElement') which are
currently all strings. (This will be fixed when I finish refactoring to
the full Service-Element-Feature pattern, and every element class has a
corresponding Service object responsible for marshalling to/from strings.)
* Only the "InMemory" StructuralModel implementation can currently be used,
mainly because there aren't any other implementations of the StructuralModel.
Example of use (note, this is *all* subject to interface upheaval in future):
#------------ begin example code
from TW.UML import UMLRecipe
from TW.StructuralModel.Queries import Type, ANY
# if you have your own specs for classes, add them to UMLRecipe first
UMLModel = UMLRecipe(name='UMLModel')
myModel = UMLModel()
# print the names of all classes
# Shortcut to get a type name if you only know the short form... But
# it's better to just do this manually once to find out the name for
# future use; I'm not guaranteeing that _XMINames will always exist in
# its present form!
Package = UMLModel.Package._XMINames
isPackage = Type(Package)
# print the names of all packages which contain other packages
print myModel.Where( isPackage & ANY('ownedElements',isPackage) ).Get('name')
#------------ end example code
I'm willing to answer questions about the TW parts of this (how-to's,
problems, etc.), but can't provide handholding for anything else. For
example, me explaining XMI or the UML metamodel in general is out of scope.
So if for example, the code barfs in the 'xml' package because it can't
parse your XMI file, it's probably a problem with the program that
generated the XMI. If it barfs in the 'TW' package, it's probably
something to do with my code, unless you just have a very nastily malformed
XMI file (in which case I'll want to see the smallest version you can send
me that still produces the error).
Feedback from UML/XMI hackers is welcomed and encouraged. Please direct
all responses to the TransWarp list, transwarp at eby-sarna.com. To subscribe
to the TransWarp list, visit:
More information about the PEAK