From owner-shlaer-mellor-users@phoenix.projtech.com Thu Aug 23 02:40:03 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.0/8.11.2) with ESMTP id f7N6e2d500035 for ; Thu, 23 Aug 2001 02:40:02 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id WAA26946 for s-m-users-outgoing; Wed, 22 Aug 2001 22:53:48 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Subject: Re: (SMU) Flat vs. 3D Domain Charts From: bob dodd To: shlaer-mellor-users@projtech.com Date: Thu, 23 Aug 2001 08:53:38 +0300 X-Mailer: NIMS ModWeb Module X-Sender: bob.dodd MIME-Version: 1.0 Message-ID: <998546018.4df5fff7bob.dodd@myrealbox.com> Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by phoenix.projtech.com id WAA26942 Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO bob dodd writes to shlaer-mellor-users: -------------------------------------------------------------------- Accepting for the moment that you *could* nest domain charts in S-M, what do you think the semantics would be? 1) Where can you nest? Only in domains, or in bridges as well? 2) How do you express to a student the difference between "good" domain chart nesting, compared to "poor" subject-level partitioning on the basis of composition? 3) Assuming you are nesting domain charts within a domain: a) Just sticking to "pure" S-M, and not UML semantics, what S-M sematics exist at the encapuslating domain? Can it contain an OIM? If it can, can the contained domains contain objects with the same or more specific meaning, and if so what does that mean for the concept of unique subject matter for each domain? b) What depth of nesting is allowed before you hit a domain which contains an OIM? c) Since bridges are a mapping between two subject matters to resolve service needs, what do bridges between domains that do not contain OIMs represent, what do they contain, and how are they populated? d) Again on bridges. Bridges are mappings within a unioun of the namespaces of the domains to which they are connected. With nesting, do you mean that the namespaces also nest? What notation would you use to express the fully qualified names of objects, attributes, events, parameters etc? I'm not saying that nesting is right or wrong, I'm just wondering how it would affect the semantics. /bob dodd From owner-shlaer-mellor-users@phoenix.projtech.com Mon Aug 27 15:53:29 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.0/8.11.2) with ESMTP id f7RJrRd157779 for ; Mon, 27 Aug 2001 15:53:27 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id LAA07898 for s-m-users-outgoing; Mon, 27 Aug 2001 11:55:14 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <20010827185501.95064.qmail@web14605.mail.yahoo.com> Date: Mon, 27 Aug 2001 11:55:01 -0700 (PDT) From: Bob Dodd Subject: Re: (SMU) Flat vs. 3D Domain Charts To: shlaer-mellor-users@projtech.com In-Reply-To: <3B8991A7.8580C8C2@worldnet.att.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO Bob Dodd writes to shlaer-mellor-users: -------------------------------------------------------------------- --- "H. S. Lahman" wrote: > "H. S. Lahman" writes to > shlaer-mellor-users: > -------------------------------------------------------------------- [snip] > > Let's be more precise, we have converted to a subset of the UML > notation, and stereotyped some of the (few) selected parts. We've > selected those parts and used stereotypes in order to preserve "pure" > S-M semantics as far as possible. And we still try to follow the S-M > process. > > And I agree we should. Alas, UML doesn't fully cooperate on the > mapping. For example, the UML semantics for a dependency in the > package > diagram has to be stereotyped because S-M confers on a bridge a much > richer interpretation. But in general I think the mapping is pretty > uncomplicated. Agreed, at least at DC level. At OIM level, it's a bit of a mess though (no subtyping so we have to pretend inheritance means the same thing, M-M with M on the associatve object falls apart, assigner state models, no access to relationship attributes at OIM level, problems with relationship labelling, no concept of secondary keys... Sorry, just having a quiet moan to myself ;-) For an allegedly feature rich notation, UML has its problems. And that's before I start on state models and event labelling... :-)) > In fact, I often use the example of switching from the original S-M > notation to UML without missing a beat as an example of the > importance > of separating the notation from the methodology. [A problem quite > common in a lot of "methodology" books with 'UML' in the title that > one sees in the bookstores.] Method, not methodology. Method = process + notation. UML is a notation looking for a method. S-M is a method with mulitple notations. Sorry, I have a colleague who corrects me every time I say "methodology", I think it was on one of his exam papers :-) I've learnt the mantra by heart now... [snip] > > Which is all a long way of say that I think it does matter :-)) > > I didn't mean to imply that S-M doesn't matter or that S-M must be > changed. When I referred to the mapping I was referring to issues > specifically like OIMs. Within the S-M context I think one can build > a > strong case for stereotyping a UML subsystem into a <> > subsystem > rather than simply using a UML package or subsystem as is. I could > see > several reasons for doing so... > > In S-M it always has an OIM. This is a particular restriction on the > diagrammatic elements that it collects. > > In S-M it has a very unique suite of characteristics (subject matter, > level of abstraction, and requirements allocation). While the UML > semantics of 'subsystem' in v1.4 is similar, it is nowhere as > narrowly > and precisely defined as in S-M. > > Taking advantage of the UML facilities for defining interfaces and > organizationally nesting domains is more of a supplement to S-M. As > such it would be wise to separate those mainstream UML facilities > from > those that are uniquely S-M. Actually, I would count myself as a bit of a radical: I think S-M *does* need reform, way beyond OOA-96. In particluar I'd pick out improvements to the method to bring in use-cases (and their diagrams) properly, and a more rigourous definition of the DC to allow for "system-level" sequence diagrams across the domain chart. Both cases require changes to the process as well as notation. My only argument about changes is that I'd rather they came from problems directly experienced with using the method, rather than pulling all the toys out of the UML toy-box if you know what I mean. And that when we do want something new, we look very hard at what it does to the existing process as well as the notation. I want a good reason to change, a real demonstrable problem that can be debated to death and its imact assessed. I just haven't seen the proven need for nested domains yet; I don't say they don't exist, just that I haven't seen real examples presented of existing DC(without) v. new DC(with). Coming back to the sterotyping you suggest though, I can certainly see the arguments if you consider just the basic notation. I can also see the argument for package as well though. Just thinking in terms of what you may baseline under a configuration management system, I tend to think in terms of a package as containing the OIM, OCM, SMs, ADFDs, Sequence Diagrams, STTs, population tables... As a result I think in terms of a package for the domain on a DC. But thinking a little more, stereotyping the package to contain subsystems as you defined would also make a lot of sense (Of course I'm not being consistent as bridges contain almost as many configuration items as a domain, but then again isn't a bridge just a domain that shares the namespaces of the two domains it bridges?) /bob dodd __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-shlaer-mellor-users@phoenix.projtech.com Tue Aug 28 01:12:22 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.0/8.11.2) with ESMTP id f7S5CHd233142 for ; Tue, 28 Aug 2001 01:12:21 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id VAA20875 for s-m-users-outgoing; Mon, 27 Aug 2001 21:23:28 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <20010828042311.93531.qmail@web14607.mail.yahoo.com> Date: Mon, 27 Aug 2001 21:23:11 -0700 (PDT) From: Bob Dodd Subject: Re: (SMU) Flat vs. 3D Domain Charts To: shlaer-mellor-users@projtech.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-shlaer-mellor-users@projtech.com Precedence: bulk Reply-To: shlaer-mellor-users@projtech.com Errors-To: owner-shlaer-mellor-users@projtech.com X-Status: Status: RO Bob Dodd writes to shlaer-mellor-users: -------------------------------------------------------------------- --- erick.hagstrom@webmd.net wrote: > erick.hagstrom@webmd.net writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > Ok, sticking to pure S-M semantics, there is no such thing as an > encapsulating domain. What I hear people describing is just a > simplification, if you will, which _represents_ more than one domain. > One box on a diagram representing several domains, just because there > isn't room (or interest) on that diagram to show all of the domains > individually. So we're not talking about domains inside of domains > inside of domains, each potentially holding objects in addition to > other domains. It's just a conceptual collapsing of information that > isn't relevant in detail at the level of the diagram on which it > appears. Yes, there is no such thing as an encapsulating domain in SM, that's what I was trying to say :-)) As far as I can guess, nesting domains *is* about encapsulation: if it is simply not wanting to show some domains on the DC, you would just draw two or more diagrams and use off-page connectors, and that's why I assumed the idea was to really nest subject matter. And that brings us back to what does a box on a DC represent, and what does that definition imnply for our definition of a bridge on a DC? I also see some suggstion that nesting can occur with bridges as well as domains, and again that suggests more impact on semantics than simply creating a collection of domains. I'm not saying nesting is right or wrong, only that for it to make sense it's more than simple containment (though that in itself would cause problems for our defintion of a bridge on the DC). /bob dodd > (This is in the same spirit as the "Subsystem", which doesn't really > exist > in any sense except as a simplification of the OIM. Important > information > is emphasized by hiding details which aren't of immediate interest. > You can > see those details, if you wish, by looking at another Subsystem OIM.) > > This should be easy enough to draw no matter what notation we use. > > I think UML supports this well enough. It also allows you to do other > things, so you might want to make use of stereotyping to restrict > usage in > this manner. Or just don't do "bad" things. (E.g. when I draw a UML > state > diagram, I only specify actions on state entry. I could specify > actions in > several other places, but I restrain myself to keep in the spirit of > S-M. I > don't expect UML or a tool to enforce it, I put that expectation on > the > analyst.) > __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/