[
Lists Home |
Date Index |
Thread Index
]
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
|
