Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi Peter, > As I recall, you've "extended" UML to add relationship types not > normally included in the UML vocabulary? If not, don't you have the > problem that UML doesn't capture all the semantics you need? In some cases yes, the association types in UML are limited and in some cases I need to be able to define new association types. So, yes UML in its actual incarnation doesn't help capture all the semantics I need. I some ways it is still to close to object oriented languages and hence, closer to platform specific model than to platform independent models. > > I think what you call the interaction model might be our "abstract > object model". That's the end result of running XSLT across all the > various models to combine them into a single model. We then can > transform this abstract model using different presentation XSLT. We've > basically got ECMAScript/XHTML and Flash as our mix, sounds pretty much > equivalent? (Other presentation model targets are PDF, Word and Excel, > but so far no actual implementations.) Interesting, If I understand well, you create an intermediary model aggregating other models, do I get it? It seems that your abstract object model is what we have with PDML. A PDML instance is then transformed into a representation. In the case of a user interacting with the object, we transform the PDML instance into a rich client app like you do. So its seems that your abstract model is equivalent to our PDML encoding. Our value chain is: XMI -----> PDML ------->XHTML/ECMAScript/etc. For each step we use XSLT as a transformation tool. But like I said previously, when we use XMI we have to limit the association types to the ones provided by UML and we found it too restrictive to fully model any knowledge. UML would benefit if the association could be custom typed as the objects can be. > We're doing all the transformation on the server side, partially for > security reasons. For us, part of presentation production is traversal > of authorization models and data. If you're doing that on the client > side don't you run the risk of allowing the client to peal back the > transformation and get at things you don't want them to? This was the subject of a lot of discussion. We resolved that by providing a subject representation. Users see only the part of the model they are allowed to see. Off course, the code itself is open but for an intranet it is not a big issue. For software sold on the internet it could be. So even if the object has more properties and methods, users see only the subset they are allowed to see. We refine the notion of "subject oriented" to the concept of representation. A subject being a representation. > It's an after the fact rationalization, but; that's seems partly why we > have a metadata model that's not coded directly in XML: you want to be > free to produce multiple model representations as needed... > Good point, we found that too. You need to store the object metadata separately from the object especially if the object is created with object oriented languages. Peter it seems that you are moving toward more modern environments, we should exchange more. Cheers Didier PH Martin
|
