[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [COAS-List] Some Ideas from the UML Spec
Harold Solbrig wrote:
> > 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?
I think that's because OBV is not an "interface" (by reference
semantics), it is a "value" (in their terms) so the private data is sent
as part of the value. The implementation of the value on the recieving
side gets it and could test for compliance but other objects on the
receiving side can not get direct access to it. The value object would
hopefully have other operations that allowed some sort of access or
modification of private state.
I reallize none of us have had real experience with OBV yet and we will
discover appropriate and not so appropriate patterns of using it as we
get some experience. The issues I am bringing up are from trying to
mentally project down that path. OBV seems to be appropriate for the
information passed in COAS. I have been trying to think through the
ramifications of doing so.
> > 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.
I'm not so sure we would implement a bank account as an OBV. If I am a
client and get an account sent to me as an OBV I'm not sure what it
would mean to tell this local object to deposit money in its self.
Maybe a deposit object could be an OBV that gets its state set up then
sent to an operation on an account object.
> 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).
Right.
> 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.
Some very good points. As you know I have been thinking more about the
implementation side and as I said I hadn't thought through the model
ramifications. Thanks for starting some good discussions on this.
Tim
begin: vcard
fn: Tim Brinson
n: Brinson;Tim
org: Protocol Systems, Inc.
adr: 8500 SW Creekside Place;;;Beaverton;Oregon;97008-7107;USA
email;internet: tim@protocol.com
title: Systems Software Lead
tel;work: 503 526 4392
tel;fax: 503 526 4200
note: <img src=http://aco.protocol.com/pids/tbrinson.jpg>
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
version: 2.1
end: vcard