From owner-shlaer-mellor-users@phoenix.projtech.com Tue Sep 11 05:35:42 2001 Received: from phoenix.projtech.com (209-234-139-66.twtelecom.net [209.234.139.66] (may be forged)) by saturn.cs.uml.edu (8.11.6/8.11.6) with ESMTP id f8B9Zfs210963 for ; Tue, 11 Sep 2001 05:35:41 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id BAA07291 for s-m-users-outgoing; Tue, 11 Sep 2001 01:57:05 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <00ea01c13a9e$42b6bb00$b7de989e@sfd349> From: "Neil Earnshaw" To: References: <3B9966B5.37CB4BA3@worldnet.att.net> Subject: Re: (SMU) Polymorphic events and other paranormal activity Date: Tue, 11 Sep 2001 09:46:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com Status: RO "Neil Earnshaw" writes to shlaer-mellor-users: -------------------------------------------------------------------- > Jay Case writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > > "Dana Simonson" writes to shlaer-mellor-users: > > -------------------------------------------------------------------- > > As you probably guessed, I just don't like the idea. > Me either [FWIW :)], ... > > Therefore, I'd like to see it stricken from the method as 'bad form'. ;-) > Unless it can be mathematically proven that MDS violates any fundamental > premise, it's hard to justify striking said construct based on just gut > feelings... I'd like to put forward a conjecture that explains why your gut feelings are right in formal terms. Every set of N divergent supertypes originating from a single object in which each supertype hierarchy is truely independent of the others represents a set of N domains colliding. IOW, each _independent_ hierarchy is a separate subject area and MDS's are tell-tale indicators of domain pollution. In the student-engineer example, if the student and engineer subject areas are separated into Student Administration and Engineer Certification domains then the modelling problems go away, re-use of the separate domains becomes possible, no-one has to write test cases for a divergent hierarchy, and our gut feelings return to normal. If the hierarchies are not truely independent then you should be able to remodel them as a single hierarchy or as multiple convergent hierarchies, as per Starr's torpedoes example. If this conjecture is correct then, - independent MDS's represent domain pollution - domain pollution violates the premise that separate subject areas are modelled as separate domains Therefore - they should be removed from the method. Discuss. -- Neil Earnshaw Consultant Software Engineer Object Software Engineers Ltd From owner-shlaer-mellor-users@phoenix.projtech.com Wed Sep 12 14:32:51 2001 Received: from phoenix.projtech.com (209-234-139-66.twtelecom.net [209.234.139.66] (may be forged)) by saturn.cs.uml.edu (8.11.6/8.11.6) with ESMTP id f8CIWoJ103177 for ; Wed, 12 Sep 2001 14:32:50 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id KAA27429 for s-m-users-outgoing; Wed, 12 Sep 2001 10:53:26 -0700 (MST) From: lschneid@eng.delcoelect.com X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-Id: <200109121753.f8CHr7S10258@koadsy11.delcoelect.com> Subject: Re: (SMU) Polymorphic events and other paranormal activity To: shlaer-mellor-users@projtech.com Date: Wed, 12 Sep 2001 12:53:06 -0500 (EST) In-Reply-To: <3B9F7B53.18F597C9@worldnet.att.net> from "H. S. Lahman" at Sep 12, 2001 11:12:19 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com Status: RO lschneid@eng.delcoelect.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > "H. S. Lahman" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Responding to Riemenschneider... > > > > Normal Form requires that an n-ary relation must be unique. The > > > corollary is mutual exclusivity. If a tuple (instance) qualifies as a > > > member of an NF n-ary relation, then it cannot be a member of any other > > > NF n-ary relation. > > > > > OK. I think I see where the crux of our argument lies. When I look at Leon's > > MDS, I don't see 5 relationships (3R1 + 2R3); I see 6 (3R1 * 2R2). Each one of > > these is exclusive. Each relationship is composed from an R1R3 pair. Does that > > clarify things? > > I understand how you wish to view it. My argument is that the view is > not consistent with the relational data model notations and it is not > viable without the relational data model. B-) > The question is if it is consistant with S-M notation. ;-) > The only n-ary relationships defined in the diagram are the five: T|W, > T|L, T|S, T|A, and T|F. Those are, by definition of the relational data > model, mutually exclusive. To address the combinatorial subtypes (T|WS, > T|WL, T|WF, T|AS, T|AL, T|AF) individually in the diagram, they would > have to be explicitly identified as leaf subtypes. > I think this depends on the definition of the "is a" relationship with respect to the supertype. > Without explicitly identifying them, the diagram would be ambiguous to > the translation engine because it could not tell which set of subtypes > to construct. But even if the combinatorial model is always assumed for > MDS (which is not a valid assumption if I simply want to categorize > subtypes for documentation clarity), it is still ambiguous. > It's not ambiguous if the "is a" is considered a bidirectional relationship. i.e. one can create supertype objects first. If this is true, then having an "exactly one subtype" rule and two "is a" relationships becomes ambiguous. It should be noted that OL:MWS states "exactly one subtype". Neither OOSA:MWD or OL:MWS discusses MDS. However, OL:MWS does discuss creating supertypes first. > If I have a relationship from some other class, X, to T|S and there are > both T|WS and T|AS instances, which one does it connect to? What if the > relationship is only valid for T|WS? If T|W has color = puce and T|S > has color = fucia by default, what color is T|WS? > If you had such a thing, then using a MDS would be wrong, and it should be made into a MLS. > And I wouldn't want to hurt my brain by even thinking about the problems > in splicing independent state machines where T|W needs to be on one > state while T|S needs to be in another state at a given moment in time. > Nor would I. :-) This is the "theoretically possible but not experience taught practical" situation that is discussed in the PE section of OOA96. > Your view could be accommodated by S-M, but I think it would be at a > horrendous price. [SNIP] > I think such a system would be highly confusing compared to simply > enumerating the combinatorial types in the OIM and using the OIM as is. > The question is not whether my view could be accomodated by S-M, but whether it is accomodated by S-M. FWIW, I don't think you should ever have state models in both sets of subtypes in my view. This is where the problems you present crop up. I think such a beast would be a nightmare (besides being incorrect). I don't like the idea of two relationship labels representing the same "is a" relationship. I think it would be OK to group subtypes as long as the same relationship label was used, but I wouldn't consider this a MDS. It should be noted that in my view, every MDS can be broken down into an MLS. This could make the MDS an unnecessary construct. I wonder what is the consensus view of the MDS in the S-M community? I am really starting to lean toward putting on my "do not do" list. :-) It looks like anywhere it could be used would be strictly for convenience. I have enjoyed this dialog immensely! :-) -- =========================================================================== Lee W. Riemenschneider lee.w.riemenschneider@delphiauto.com Software Engineer OS/2 user PURDUE alumnus and die-hard FAN! ===========================================================================