[Uml-devel] 2.0 anybody?
ansutton at kent.edu
Fri Dec 13 09:40:10 UTC 2002
sebastian and i have been having some extensive off-list discussions about the
future versions of umbrello and come up with some interesting ideas. alot of
our discussions have revolved around usage scenarios; these have helped
motivate the development of a general architecture for 2.0 (and up, we hope).
we understand that 1.1 is still the topic of the day, but we thought we throw
this out to get some ideas kicked around before any new development starts.
so... without further ado:
the primary driving factor of this architecture has thus far centered around
collaborative development. it was sebastian's concern that multiple
developers be able to work on a single model concurrently. it was my concern
that umbrello supported a diff/merge type feature to support collaborative
development - basically, instead of patching sources, you patch models.
fortunately, this isn't really hard - its explicitly called out by XMI.
finally, we have the lonely single user who doesn't care about anybody else -
which, is most model development in my experience.
we think we've done a good job defining an architecture that satisfies all
these requirements. as with concurrent development, there was some concern
that we might have to write our own server (and we really don't want to do
that), but it turns out a better solution was found. now, you have to keep in
mind, this is very, very superficial - we haven't really done any design
work. we're just calling out components for a rewrite. oh. and its going to
look nothing like the current version :)
basically, we realized were dealing with a data center application here (an
architectural style). actually, we're probably dealing with some variant of a
blackboard architecture, but that's beside point. so, we decided to go with
the standard 3 tier layering architecture that seems so prevalent these days.
now, before you say "ugh... middleware", we don't need any. the way we
propose the architecture, all the middleware is actually implemented with the
application and not as some CORBA-like set of services. good for us, i say.
anyway, the tiers:
data - responsible for storing information about models, metadata, etc.
logic - provides abstractions of the data storage and abstractions to the
application(s) that use it. this is not networked middleware.
presentation - user interfaces - what we think of as Umbrello is here. we've
also been able to identify a host of other tools that we can build in
conjuction with Umbrello.
anyways, the data tier is replacable. for example, one data storage solution
is XMI. we've known this for some time. another that has been identified is
an online database - and this is important... by using an online database, we
can deliver concurrent development capabilities to the masses. and, even
better, we don't have to do shit to get those capabilities because we can
"borrow" the argouml schema (interoperability ;)
the logic layer, or middleware, basically provides a bunch of abstractions.
the idea is that Umbrello has a core library that implements a bunch of
common services. they are:
Storage Abstraction Layer (SAL) - this is how we make provide storage
transparency to the application... well, to a certain degree anyway. it hides
whatever storage system underlies the model being developed.
Reflection Inteffaces - we've talked about reflective interfaces before. these
Primitive Types Library - because we're using C++, we don't get really good
generic handling for primitive types (int, float, matrix - just kidding) so
we implement that here. These also have reflective interfaces.
Meta Object Facility - because MOF is the highest level of "metaness" we need
to implement that here. its too tightly coupled to other components within.
Visual Metaphor Extensibility Layer (VMEL) - this is a placeholder for
whatever component we decide handles drawing extensibility. we haven't talked
a lot about this.
in addition to these common services, we introduce the following SAL
XMI - storage abstraction layer implementation for XMI.
DB - storage abstraction layer for postrges or mysql or oracle or (ha ha)
finally, as umbrello IS a UML tool, i suppose we need to allocate space for
that somewhere too. since UML is a metamodel implementation, it is
implemented separately from the rest of the middleware - even though it is
middleware. the UML library (libUML) uses this to provide all the drawing
now... finally applications:
Umbrello - the big one. we all know what this is going to be
metamodel compilers - command line tools that take a metamodel specification
(like UML) and generate a metamodel implementation (like libUML) for
design compilers - command line tools that take model specifications in UML
and create source code.
command line parsers - should work with build systems (like make, gmake) to
create UML models from source code. like doxygen or kdoc.
now, just because some of that functionality is called out as command line
tools, that's not actually how they will be built. the functionality should
be built into a shared library so that it can be used by both umbrello and
the command line app.
so, there 'tis. its a fairly complete picture of the general architecture of
the system. rember, the architecture isn't the design. the design for all of
these components is still forthcoming and is going to be considerably
difficult as there's lots and lots of stuff here.
so if you've read this far and have some comments or would like to make
suggestions or tear these ideas apart, please do. this is the work of 2
people and we're probably wrong in a couple of our assumptions - although we
think we've done a fairly good job with this.
that is all
More information about the umbrello-devel