[Uml-devel] 2.0 anybody?

[Andrew Sutton]

all,

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 
go here.
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 
implementations:
XMI - storage abstraction layer implementation for XMI.
DB - storage abstraction layer for postrges or mysql or oracle or (ha ha) 
SQLServer.

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 
capabilities.

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 
umbrello.
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

andy