[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [COAS-List] Some Ideas from the UML Spec
Tim,
> While I think having operations and private state for OBV is valuable
> (for vendor specific work) it may not be as applicable in standard
> specifications.
I would argue that it isn't applicable at all. Of what use is private state to an interface specification? How would one demonstrate compliance?
> Do we really want to put the burden on clients
> to implement operations too (whether they need them or not)? Although
> it may be OK to put operations in the conceptual model (UML) - I haven't
> thought through the ramifications of that.
Hopefully you are specifying the classes, associations and methods (i.e. attributes and operations) that represent a model of real world behavior. It would seem a bit odd to me to state that there isn't way to deposit money into a bank account because we are going to represent the account in OBV and don't want to put the burden on the clients. OBV or no OBV - one of the things that you do with a bank account is deposit money. Once you get the model correct, you can then *map* the deposit operation into different implementations. An OBV implementation might have a different mapping than a distributed object implementation. They would both certainly have a different implementation than a manual implementation (hire a teller, train him, put him in a bank and give him a deposit).
This issue is fairly critical. A specification needs to consist of at least two parts: Part 1: what we would like to do (the real world model) and Part 2: how we go about doing it in the OMG environment as it exists today. If you get Part 1 and Part 2 muddled together, you will have a great deal of difficulty figuring out how you might do the same thing in the OMG environment tomorrow. As an example, we may have to update the PIDS spec to handle OBV, which wasn't available when we built it. Muddling Part 1 and Part 2 may also prevent the specification from being used in other environments (e.g. ActiveX, RMI, XML, manual process, etc.). This is becomes *vitally* important regarding COAS, as it is going to have to get along with HL7, and HL7 is (justifiably) a wee bit touchy about technology lock in.
Yours,
Harold Solbrig
----------------------------------------
Harold Solbrig
Senior Product Development Specialist
3M Health Care
575 W Murray Boulevard
Murray, UT 84123
(801) 265-4312 (v) (801) 263-3553 (f)
hrsolbrig@wpmail.code3.com
-----------------------------------