[udm-dev] Udm meeting memo
Endre Magyari
endre at isis.vanderbilt.edu
Sat Jul 16 23:32:10 CDT 2005
Ok, let me suggest the following:
1. I'll check in the changes for what you called "smart namespace
generation" Monday.
2. If we are happy with the udm_ns as it is for short-term use (when can
we know this ?), then I'll modify UmlInUml and the core files accordingly,
as you have suggested.
Answers that I know for your questions:
1. MetaGME and UML are quite different. Unfortunattly the MGA backend part
of UDM is already full of hacks like "Uml Association with one role called
"ref" means GME reference" and so on with sets, connections, instances and
subtypes. So this namespace thing wouldn't be the only discrepancy between
the two.
2. Namespace support in backends: XML supports it, MEM was modified to
support it, in GME we added a registry key for each object.
3. Nested Namespaces: Probably the UmlInUml can be modified and again the
core libraries can be updated. But I don't see how it will be supported by
the XML backend for instance.
4. Namespace TAGS in XML file: Only XML files with namespace tags or
default namespace can be parsed in. The compatibility of the XML format
was not a requirement two weeks ago, you said:
"
In my opinion it is perfectly legal to change the format of the Udm Xml
files, because these files are generated artifacts for the Udm code
generator, and they are not directly manipulated by end users. So
backward compatibility is not an important issue here."
Old UDM used XML without namespace tags, udm_ns uses XML with namespace
tags.
But this can be changed w/o problems if there is only one Namespace.
Endre.
On Sat, 16 Jul 2005 11:20:28 -0500, Attila Vizhanyo
<viza at isis.vanderbilt.edu> wrote:
>
>>> In summary, we have agreed on the following:
>>> 1, The current namespace support in udm_ns is not viable in the
>>> long-term, because it does not have clean and straightforward support
>>> for non-namespace usage scenarios (which is still in active use).
>>> 2, We need to redesign the namespace feature, and reimplement the
>>> corresponding code with the following rule in mind:
>>> If a user does not use namespaces, then Udm must generate the
>>> same set of artifacts (e.g. udm xml file, DS-API, xsd, etc.) as before.
>>> 3, This change requires putting back the
>>> Diagram-{Class,Association,Composition} containment relationships into
>>> UmlinUml, and modifying the udm core libraries to reflect these
>>> changes.
>>> 4, We must restore the non-namespace functionality completely.
>>
>>
>>
>> Ok, should I understand that for namespace scenarios the current design
>> is OK ?
>
> No, not really. I think the paragraph above explains clearly why.
> It is not OK up to the point that Gabor wants to ditch udm_ns and start
> from scratch.
>
>>
>>> We realize that it will take several months to complete these changes.
>>
>>
>> I never said several months. A month is enough.
>
> OK, my mistake. But you promised one-two months in December 2004, and
> now it is July 2005.
> I'm just taking precautions.
>
>>
>>> In the meantime, we would like to start testing the existing udm_ns
>>> version, point out its weaknesses, so that we can learn from the
>>> faults,
>>> and take the accumulated learnings into the new design. Currently, we
>>> are aware of two limitations that prevent us from starting the tests.
>>> 1, smart namespace generation feature
>>> 2, Discrepancy of the Udm Xml file with GME model files: since every
>>> udm
>>> xml file contains a namespace, how can they used to validate/manipulate
>>> GME model files, obviously with GME not having namespace support.
>>>
>>> Please give your thoughts on these issues. If you could fix these two
>>> problems, then we could start the extensive testing of udm_ns on the
>>> next week.
>>
>>
>> 1.) - I can fix this by Monday
>> 2.) - I'm not sure I understand the connection with UDM XML files and
>> GME models.
>> Are you reffering to UML Udm XML files or DS Udm XML files ( a result
>> of UDM DOM Backend ) ?
>>
>> In case of UML UDM XML files, I don't see how they are related to GME
>> models.
>> In case of DS UDM XML files, each object clearly belongs to a XML
>> namespace defined by an .xsd file for that namespace.
>> in the MGA backend, this is implemented with a registry key/value
>> pair. (key = __udm_namespace)
>>
> 1 is fine. In the case of 2, we are admittedly reasoning only on
> theoretical basis.
> Here is an example to illustrate what we worry about.
> Suppose the user defines a GME paradigm, in which models ModelA are
> contained in RootFolder.
> The generated UML class diagram, output of MetaGME2UML, will have class
> RootFolder containing class ModelA.
> But the generated DS UDM XML file, output of UML2XML, will have an extra
> namespace generated between class diagram and the classes.
> This xml file can be used to either generate DS API files, or to load
> GME model files (instances of the paradigm) dynamically.
> Question: (1) How can this xml file be used to manipulate/validate GME
> model files, which surely does not have namespace defined in it at all?!
> (2) I understand that the two files do not need to have semantical
> equivalent parts, but what is the artificial namespace element good for
> in the case of GME models? And in the case of CORBA backend? And in the
> case of XML,MEM backend, when no namespace is used?
>
>
>>
>>
>>
>>> We believe that udm_ns is now fairly close to the stage where it can be
>>> used with reasonable confidence.
>>
>>
>> As I said, all tests are green now.
>
> OK, we'll give it a try on Monday.
>
>>
>>> Specifically, our hope/plan is that we can prove that udm_ns is (1)
>>> fully backward compatible, and (2) fullfills the namespace requirements
>>> completely, in 3-4 weeks.
>>
>>
>> Isn't (2) proved at this moment?
>
> Well, the requirement arised from the Biocomp project, let's them
> evaluate the fullfilment.
>
>>
>>
>>> If we cannot show this, than we have to discard the changes, and start
>>> adding the namespace feature from scratch (e.g. from old udm).
>>>
>>> Meanwhile, we can start redesigning the namespace feature with the
>>> above
>>> goals in mind. We'd also like to have you share your design ideas with
>>> us prior to implementing them.
>>> We can help not only in the desing, but in the implementation, as well.
>>
>>
>> I'd further investigate the possibility to have a clear and simple
>> (the simpler, the better) design:
>>
>> 1. All classes shoud belong (semantically) to a namespace, even if
>> there is one special namespace (root namespace), with special API
>> mapping (the old C++ API syntax).
>> Let me continue with Gabor's parallel, if you look at the C++
>> namespaces/classes , all classes belong to a namespace.
>> And of course, there is a root namespace, but still, internally it
>> is a (special) namespace.
>> In case of C++, you don't have some classes in namespaces, and some
>> classes in "no namespace". You have them in the "root namespace" which
>> is still a namespace.
>
> True, but I'm not sure how global namespaces are implemented in C++.
> They had to use some hacks for sure, since namespaces were not around
> since the beginning, so they could not have a clean architecture (such
> as packages in Java) because they had to think about making old code
> work. Moreover, Udm's case is even more difficult because of the
> multiple backends, e.g. the notion of namespaces is completely missing
> from GME, and it is not even planned to introduce them later..
>
>>
>> 2. reintroducing the containment relationships Diagram - {Class,
>> Association and Composition} will lead to a lot of ambigous and
>> complicated code resulting from an ambigous parent() call, which does
>> not return Uml::Namespace, but Udm::Object and the user will always
>> have to check runtime for it's type.
>> It's also not clear what is the difference between the contaiment
>> relationships Namespace - {Association, Composition} and Diagram -
>> {Association, Composition}. I believe nothing, so why should we have
>> this ambiguity in the modelling environment and in UmlInUml.
>
> Exactly for the sake of straight backward compatibility. The UmlinUml
> class diagram in udm_ns should contain all classes and relations of the
> old udm. To resolve the ambiguity, what about using different parent
> names, e.g. "parent_ns"?
>
>>
>>
>> As a conclusion, I'd investigate the idea of a special namespace, let
>> us call it "root namespace", and for non-namespace scenarios I'd
>> consider all defined classes in that "root namespace". Internally, I'd
>> keep all classes strongly tied to a namespace, I believe this makes
>> UDM and UDM applications simpler, as opposed to a hierarchy when
>> Classes are either in Namespaces or in Diagrams.
>>
>> I believe this does not interfere with backward compatibility, as
>> defined by Gabor: "old code works." Btw, this is achieved as of now.
>
> I'd be more careful with that verdict. Let's see how GReAT copes with
> udm_ns.
> But in general, I beleive you when you say udm_ns is backward
> compatible. However, backward compatibility is not the only issue we
> need to think about. Think of future changes, e.g. how extensible is the
> current design of udm_ns. We fear that adding new features will be
> more difficult as udm_ns gets more interwoven with the namespace feature
> throghout everywhere in the core libraries. E.g how about nested
> namespaces, an original requirement, seem to be missing currently? Can
> you support it easily with the current design?
>
>>
>> Your proposed changes would make UmlinUml (the core of Udm) more
>> complicated and ambigous.
>> We should keep it simple and straightforward, as it is now or as it is
>> in old UDM.
>
> Clearly, our opinion is different on what is simple and what is
> straightforward.
> I admit that you know better the inner workings of Udm, but from an
> outside point of view, generating namespace elements into the DS UDM XML
> file, even when no namespace is used, seems a workaround for me.
> Here is a new question: if no namespace is used in the UML class
> diagram, then are you sure that model XML files (instances) do not
> contain namespace qualifiers in the XML tags?
>
>>
>> Do you think that the idea of a "special namespace" could work?
>>
>>
>> If so, I already have an idea, we could use unnamed namespaces
>> (namespace with no name) as a "special namespace".
>> This also solves the following generation issue:
>>
>> Currently if there is a single namespace in the Uml diagram, we don't
>> generate the extra C++ namespace, to provide backward compatibility:
>>
>> So, instead of
>>
>> namespace LampDiagram
>> {
>> namespace LampDiagram
>> {
>> Uml::Namespace meta;
>> class Lamp;
>> }
>> }
>>
>> we generate
>>
>> namespace LampDiagram
>> {
>> Uml::Namespace meta;
>> class Lamp;
>> }
>>
>> in case of a single Namespace in Diagram. This does not break existing
>> code.
>>
>>
>> Instead, we could generate an unnamed C++ namespace :
>>
>> namespace LampDiagram
>> {
>> namespace
>> { Uml::Namespace meta;
>> class Lamp;
>> }
>> }
>>
>>
>> The great thing is that :
>> 1. C++ supports supports such unnamed namespaces
>> 2. LampDiagram::Lamp syntax would still work
>>
>>
>> Taking advantage of C++'s unnamed namespaces, we could solve this
>> issue like this:
>>
>> 1. uml2xml: classes without a namespace will be placed in an unnamed
>> namespace. <Uml:Namespace> <class name ....> </Uml:Namespace>
>> 2. udm.exe would be extremly straigtforward in API generation: for
>> each Uml Namespace a C++ namespace would be generated with it's name.
>> (thus, a UML namespace with no name would be mapped to a C++ unnamed
>> namespace)
>>
> The implementation of udm might be more starightforward, but the
> generated files will contain superfluous details, still.
>
> Thanks,
> Attila
>
More information about the udm-dev
mailing list