From: general-digest-list-request@onemodel.org Subject: general-digest-list Digest V00 #4 X-Loop: general-digest-list@onemodel.org X-Mailing-List: archive/volume00/4 Precedence: list MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----------------------------" To: general-digest-list@onemodel.org Reply-To: general-list@onemodel.org ------------------------------ Content-Type: text/plain general-digest-list Digest Volume 00 : Issue 4 Today's Topics: Re: use cases [ "Tom and other Packers" ] Re: use cases [ Mark Butler ] Re: use cases [ "Tom and other Packers" ] Re: use cases [ Luke Call ] ------------------------------ Date: Wed, 9 Aug 2000 08:26:13 -0600 From: "Tom and other Packers" To: "Luke Call" , Subject: Re: use cases Message-ID: <001601c0020d$dc01a6a0$2e0aa8c0@oemcomputer> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Luke I'll respond in more detail later. For now, what's the difference between class and object? tomp ----- Original Message ----- From: Luke Call To: Sent: Wednesday, August 09, 2000 7:19 AM Subject: use cases Imagine that you are using the phase 1 version of the system. What are the key operations you would want to perform, and what do you expect the system to do as a result? One such operation, with subsequent system actions and response to the user, is a use case. First we make a list of the most important use cases, then we choose the most significant ones to elaborate. One use case can "include" another (use it like you call a function), or can "extend" another (do the same thing only with variations for a particular situation). This is the beginning of the definition of the most basic structure of our system. We need to think together here and converse about this. Here are the ones I thought of. They might sound excessively simple but we have to start somewhere. They need to be detailed (i.e., add sub-steps for each, which I have begun but thought I'd start here to get some feedback or corrections/thoughts from all): - system startup - new class - new object - (navigation among objects--needs to be broken down more concretely) - add a name to a class - add property (to class) - choose property type (required by add property) - edit property - delete property - delete object - delete class - add/edit/delete relationship (between objects; is this just another instance of the "add/edit/delete property" use cases, with the relationship being another type of property?) - possible types of relationships between objects [needs work]: - is-a [i.e., object to class] - is-part-of (reverse is consists-of; which one to use, or both?) - is-contained-in (physically, like things in a room or box) - owns (is responsible for? steward?) - [what others??] Thoughts?? Thanks, Luke ------------------------------ Date: Wed, 9 Aug 2000 08:30:27 -0600 From: lacall To: "'general-list@onemodel.org'" Subject: test: pls ignore Message-ID: Content-Type: text/plain; charset="iso-8859-1" Did I get a rejection for this, plus a note to the maintainer? Luke Call EDM Group Micron Technology, Boise ------------------------------ Date: Wed, 09 Aug 2000 09:19:01 -0600 From: Mark Butler To: general-list@onemodel.org Subject: Re: use cases Message-ID: <39917665.D798344B@middle.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A couple of comments: First of all, you shouldn't make a hard distinction between a class and an object. An object can much more flexibly be treated as a class that has membership one. It is important that each object be able to have its own unique properties and relationships that may not exist anywhere else. I also suggest the use of the word "entity" to describe all class and object abstractions. That way an "is A" relationship can describe both class inheritance and object membership in a class. Strictly speaking every property of an entity is a relationship between that entity and some other entity, however abstract. Neither the types of relationships nor the types of properties should be arbitrarily restricted. Naturally, there need to be certain relationship types that need special support in the system, particularly "is A" relationships. - Mark Luke Call wrote: > > Imagine that you are using the phase 1 version of the system. What are > the key operations you would want to perform, and what do you expect the > system to do as a result? One such operation, with subsequent system > actions and response to the user, is a use case. > > First we make a list of the most important use cases, then we choose the > most significant ones to elaborate. One use case can "include" another > (use it like you call a function), or can "extend" another (do the same > thing only with variations for a particular situation). > > This is the beginning of the definition of the most basic structure of > our system. We need to think together here and converse about this. Here > are the ones I thought of. They might sound excessively simple but we > have to start somewhere. They need to be detailed (i.e., add sub-steps > for each, which I have begun but thought I'd start here to get some > feedback or corrections/thoughts from all): > > - system startup > > - new class > > - new object > > - (navigation among objects--needs to be broken down more concretely) > > - add a name to a class > > - add property (to class) > > - choose property type (required by add property) > > - edit property > > - delete property > > - delete object > > - delete class > > - add/edit/delete relationship (between objects; is this just another > instance of the "add/edit/delete property" use cases, with the > relationship being another type of property?) > - possible types of relationships between > objects [needs work]: > - is-a [i.e., object to class] > - is-part-of (reverse is consists-of; which > one to use, or both?) > - is-contained-in (physically, like things in > a room or box) > - owns (is responsible for? steward?) > - [what others??] > > Thoughts?? > > Thanks, > Luke -- Mark Butler ( butlerm@middle.net ) Software Engineer Epic Systems (801)-451-4583 ------------------------------ Date: Wed, 9 Aug 2000 18:06:05 -0600 From: "Tom and other Packers" To: Subject: Re: use cases Message-ID: <000901c0025f$92031c80$0206a8c0@oemcomputer> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This was pretty much what I was going to say. tomp ----- Original Message ----- From: Mark Butler To: Sent: Wednesday, August 09, 2000 9:19 AM Subject: Re: use cases A couple of comments: First of all, you shouldn't make a hard distinction between a class and an object. An object can much more flexibly be treated as a class that has membership one. It is important that each object be able to have its own unique properties and relationships that may not exist anywhere else. I also suggest the use of the word "entity" to describe all class and object abstractions. That way an "is A" relationship can describe both class inheritance and object membership in a class. Strictly speaking every property of an entity is a relationship between that entity and some other entity, however abstract. Neither the types of relationships nor the types of properties should be arbitrarily restricted. Naturally, there need to be certain relationship types that need special support in the system, particularly "is A" relationships. - Mark Luke Call wrote: > > Imagine that you are using the phase 1 version of the system. What are > the key operations you would want to perform, and what do you expect the > system to do as a result? One such operation, with subsequent system > actions and response to the user, is a use case. > > First we make a list of the most important use cases, then we choose the > most significant ones to elaborate. One use case can "include" another > (use it like you call a function), or can "extend" another (do the same > thing only with variations for a particular situation). > > This is the beginning of the definition of the most basic structure of > our system. We need to think together here and converse about this. Here > are the ones I thought of. They might sound excessively simple but we > have to start somewhere. They need to be detailed (i.e., add sub-steps > for each, which I have begun but thought I'd start here to get some > feedback or corrections/thoughts from all): > > - system startup > > - new class > > - new object > > - (navigation among objects--needs to be broken down more concretely) > > - add a name to a class > > - add property (to class) > > - choose property type (required by add property) > > - edit property > > - delete property > > - delete object > > - delete class > > - add/edit/delete relationship (between objects; is this just another > instance of the "add/edit/delete property" use cases, with the > relationship being another type of property?) > - possible types of relationships between > objects [needs work]: > - is-a [i.e., object to class] > - is-part-of (reverse is consists-of; which > one to use, or both?) > - is-contained-in (physically, like things in > a room or box) > - owns (is responsible for? steward?) > - [what others??] > > Thoughts?? > > Thanks, > Luke -- Mark Butler ( butlerm@middle.net ) Software Engineer Epic Systems (801)-451-4583 ------------------------------ Date: Thu, 10 Aug 2000 07:19:07 -0600 From: Luke Call To: general-list@onemodel.org CC: general-list@onemodel.org Subject: Re: use cases Message-ID: <3992ABCB.9030006@onemodel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Good; this is a very worthwhile conversation. Hang in there while I try to understand. If an object defines a class (I'll use the term "entity" in a bit), then when you create another object and want to indicate that it's of the same class, that part seems straightforward enough--the properties available by default (needn't all be filled or even allocate space--just be conveniently there in the interface if needed, plus an "is-a" reference made), is the "is-a" reference pointing to a class or an object? For example, if I define a truck object, and name it "truck" and "my 1982 mazda", and I then want to create another truck object, is it going to be of type "truck" or a "1982 mazda"? Obviously I want truck, but I'm not (yet) envisioning how the relationship would work there, i.e., how it would know which concept the "is-a" points to (or even if it needs to know). And, if I change the "superclass", how does that affect other objects of the same type? Let's suppose the answer is this: the "is-a" relationship pretty much only exists as a convenience for queries, but not to define what data must be present. And if you change an entity, no problem, it only affects that entity and the rest of the entities in the system are not affected. Simple enough, and very flexible. But then suppose I want to enhance the level of understanding in my system about "trucks", by adding properties to some superclass "physical object" about newtonian physics, with the intent that all entities that are "physical objects" now can have mass, and certain predictable physical behavior, etc. How would that change be propagated? Here's one other idea--maybe we can mark an entity as being the "type definer" for a class, so that changes to it affect all entities which have an "eventual" is-a relationship to it. When making changes to the structure (properties/methods) of some other entity with an upward "is-a" relationship to the "type definer", the system could wonder whether this is an exception ("it's a truck, but it's different from the type-definer truck", which sounds normal enough), or if it will be used as a new "type definer" later, on its own. Maybe some entity becomes a type-definer only when something else points to it with an "is-a" relationship, rather than being specially marked? It may be that if we have the ability to create such flexible is-a relationships throughout the data set, and can easily traverse them, that it meets our needs, but we need to think about the implications for querying, internal coherency (right term?), and support for all the other features we envision. Another idea--is-a relationships may need to be defined or revised after the entities affected already exist. Perhaps the implication is that any entity whose properties aren't all set inherits the values for those properties that are set in the "type-definer" parent, such as size, mass, etc. Could be a timesaver for simulations or depictions where you want to guess at things when you lack actual measurements? And can you have multiple "is-a" relationships? It would be handy for some things, but again, we may want to review the implications as we work through this. Thanks, Luke Tom and other Packers wrote: > This was pretty much what I was going to say. > > tomp > > ----- Original Message ----- > From: Mark Butler > To: > Sent: Wednesday, August 09, 2000 9:19 AM > Subject: Re: use cases > > > A couple of comments: > > First of all, you shouldn't make a hard distinction between a class and an > object. An object can much more flexibly be treated as a class that has > membership one. It is important that each object be able to have its own > unique properties and relationships that may not exist anywhere else. > > I also suggest the use of the word "entity" to describe all class and object > abstractions. That way an "is A" relationship can describe both class > inheritance and object membership in a class. > > Strictly speaking every property of an entity is a relationship between that > entity and some other entity, however abstract. Neither the types of > relationships nor the types of properties should be arbitrarily restricted. > Naturally, there need to be certain relationship types that need special > support in the system, particularly "is A" relationships. > > - Mark > > Luke Call wrote: > > > > Imagine that you are using the phase 1 version of the system. What are > > the key operations you would want to perform, and what do you expect the > > system to do as a result? One such operation, with subsequent system > > actions and response to the user, is a use case. > > > > First we make a list of the most important use cases, then we choose the > > most significant ones to elaborate. One use case can "include" another > > (use it like you call a function), or can "extend" another (do the same > > thing only with variations for a particular situation). > > > > This is the beginning of the definition of the most basic structure of > > our system. We need to think together here and converse about this. Here > > are the ones I thought of. They might sound excessively simple but we > > have to start somewhere. They need to be detailed (i.e., add sub-steps > > for each, which I have begun but thought I'd start here to get some > > feedback or corrections/thoughts from all): > > > > - system startup > > > > - new class > > > > - new object > > > > - (navigation among objects--needs to be broken down more concretely) > > > > - add a name to a class > > > > - add property (to class) > > > > - choose property type (required by add property) > > > > - edit property > > > > - delete property > > > > - delete object > > > > - delete class > > > > - add/edit/delete relationship (between objects; is this just another > > instance of the "add/edit/delete property" use cases, with the > > relationship being another type of property?) > > - possible types of relationships between > > objects [needs work]: > > - is-a [i.e., object to class] > > - is-part-of (reverse is consists-of; which > > one to use, or both?) > > - is-contained-in (physically, like things in > > a room or box) > > - owns (is responsible for? steward?) > > - [what others??] > > > > Thoughts?? > > > > Thanks, > > Luke > > -- > Mark Butler ( butlerm@middle.net ) > Software Engineer > Epic Systems > (801)-451-4583 > > > > > > > -- Help us put all knowledge in one bucket: www.onemodel.org. Note to friends/family: my email address is changing from lcall@pobox.com to lacall@onemodel.org. ------------------------------ Date: Fri, 11 Aug 2000 07:01:45 -0600 From: Luke Call To: general-list@onemodel.org Subject: Re: use cases Message-ID: <3993F939.8030101@onemodel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit My apologies to all - if you posted in the last day or so you got a letter saying you're not in the list. This is supposed to go to people who post but really aren't in the list, but went to the list instead. I don't get why, but I'll remove the feature. (I was hoping to avoid the list getting spammed that way, but maybe I need to cough up the $ to switch to their newer system....) Anyway, the mistake was mine, not yours, and everyone is still subscribed. It also appears that messages were posted from tom and mark during that time, so I don't think anything was lost. It should be back to normal now. Luke -- Help us put all knowledge in one bucket: www.onemodel.org. Note to friends/family: my email address is changing from lcall@pobox.com to lacall@onemodel.org. -------------------------------- End of general-digest-list Digest V00 Issue #4 **********************************************