|
Author |
Thread:
Comments on Crash Records UML Models |
|
Scott Came
|
Comments on Crash Records UML Models
Posted:
Thursday, March 10, 2005 12:09 AM (EST)
|
|
Hello everyone, I'm new to this group (though I've been watching for awhile), so if my comments are out in left field, forgive me.
I've been quite involved over on the Justice XML side of things, mostly using the vocabulary as a basis for building schemas for individual information exchanges. I've also been working on how an XML vocabulary fits into an overall service-oriented architecture. On both of these fronts, I've been making good use of UML to communicate about data structures with non-technical stakeholders...then we map the UML entities into GJXDM structures (sometimes cleanly, sometimes not.) So in my view, FWIW, you're going down the right path modeling this first in UML, then deriving schemas from the models.
One comment on your model... I would recommend that you use inheritance very sparingly. In fact, I've come to believe that it's better not to use it unless there is really no other way to represent the semantics in a situation.
Despite its promise of increasing reuse, in my experience inheritance hierarchies actually hinder reuse. This is because the amount of reuse inherent in a model is directly proportional to how flexible and interchangeable the parts are...that is, how resilient the components are to change. When you establish deep or wide inheritance hierarchies, changing the classes at the top of those hierarchies becomes very painful. The problem is compounded by the fact that (rightfully) most programming languages, as well as XML Schema, do not allow multiple inheritance.
Here is an example. In the VehicleDetail model, we currently have CommercialVehicle extending CrashVehicle extending Vehicle. At some point, someone is going to want to use the transxml vocabulary, but will want to extend it with their own additional vehicle information. So, their first inclination will be to extend the Vehicle class (or the schema representation of it). But that extension will have no impact on the CrashVehicle or CommercialVehicle classes, because they already extend the transxml Vehicle class, not the new derived Vehicle class. If this hypothetical user also has some extensions to CrashVehicle, then he/she will have to decide whether to extend the derived Vehicle class, or the transxml CrashVehicle class...it will not be possible to extend both.
There is also a semantic argument to consider. We are often drawn to represent associations as inheritance, when really we should just represent them as associations. In one sense, a CrashVehicle is a kind of Vehicle...that is, the kind of vehicle that has been in a crash. But that's not the most direct way to describe the semantics. In actuality, what we're after here is an association between a crash that has happened, and one or more vehicles.
A similar argument applies to person-role relationships. This might be a bit far-fetched, but...what if a firefighter is involved in a crash? (I'm looking here at the properties of a NonMotorist in the model.) The same human being may have some of the characteristics of an occupant (i.e., play the role of occupant), but may also have some of the characteristics of a non-motorist, such as taking actions during the crash (i.e., may play the role of a non-motorist.) Because of single inheritance, it's very difficult to allow something to be more than one kind of thing. That's why we should consider modeling these as people-playing-roles.
Finally, associations map much more cleanly to the hierarchical nature of XML and XML Schema. So life becomes easier downstream as well.
One other general comment...I think the transxml vocabulary's potential to foster reuse would be enhanced by breaking up some of the larger entities (e.g., Driver, CrashVehicle) into smaller components that can be independently composed and extended if necessary. In the ideal world, the name of a class should be an abstract encapsulation of what the properties and associations of that class represent. I've often found that to be a good litmus test for when my entities are getting too heavy.
I hope these comments are useful, or at least food for thought. Looks like really exciting, useful work is happening here.
Thanks.
--Scott
Scott Came
Principal Consultant
Justice Integration Solutions, Inc.
|
|
|
|