[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (FC-Devel) Update
Sorry for such long pause.
>>>>> "JW" == Jeff Wolfe writes:
JW> I added a link to this site from the freecase details page. If you
JW> could add a link back to the project, I think it would be helpful.
JW> With a persistent link, maybe more people will see them and comment.
>> >From the architectual viewpoint, the repository breaks nicely in tree
>> a. the UML package, that provides the client functionality b. the
>> persistence package, that stores the UML data in a storage c. the CM
>> package, that deals with checkouts, updates, commits, etc.
JW> I just want to clarify my understanding. For (a), are you referring to
JW> the interface provided to the client to access the information?
JW> Several people have suggested that we use an architecture that will
JW> support other modeling languages in the future. Would it be better to
JW> provide a more general meta-model interface, and force the client
JW> software to turn this into UML?
Won't this take too much responsibility to the client?
JW> Perhaps we could have a meta-model interface and then allow server-side
JW> plug ins for UML and future models. These plug ins could act mostly
JW> like a translator.
Yes, that looks better. So (a) should be just one of possible plugins.
JW> As in all client server systems, we need to strike the proper balance
JW> between work done by the client and work done by the server.
JW> Then, (b) could focus strictly on storing the meta-model and would be
JW> isolated from all other details. Now for another question, if the
JW> repository stores model information, where and how do we store document
JW> info? I'm talking about things like page layout, how to display class
JW> detail (folded, unfolded), etc. It is my opinion that the model should
JW> be separated from the presentation documents, but also that the model
JW> should reflect the current contents of the documents. Does this make
Yes. UML metamodel doesn't specify the visual modeling part, so we've
figure it ourselves.
JW> Finally, for (c), we have discussed using cvs. This is certainly a
JW> good move. Why should we also try to create a revisioning tool?
We shouldn't. The (c) should be the interface to the cvs.
JW> However, we need to make sure that we don't create a document format
JW> that gets corrupted easily. Interesting things can happen when dealing
JW> with versioning. Can someone shed some light on whether or not this is
JW> likely to be a problem?
I'm using cvs for year and never ever got a corrupted file. All merge
tasks are easily solved by emacs's ediff and emerge.
JW> The only major problem I see is that the actual specifications are not
JW> free. Is this really a problem? I don't think so. There is a lot of
JW> free information on their site.
Glancing though cdif documents makes me think it's quite easy to implement
UML metamodel storage on top of cdif format.
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
There is no problem a good miracle can't solve.