From owner-shlaer-mellor-users@phoenix.projtech.com Mon Aug 27 17:34:49 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 f7RLYmd224391 for ; Mon, 27 Aug 2001 17:34:48 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id NAA11501 for s-m-users-outgoing; Mon, 27 Aug 2001 13:53:17 -0700 (MST) From: lschneid@eng.delcoelect.com X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-Id: <200108272052.f7RKqkp02779@koadsy11.delcoelect.com> Subject: Re: (SMU) Flat vs. 3D Domain Charts To: shlaer-mellor-users@projtech.com Date: Mon, 27 Aug 2001 15:52:45 -0500 (EST) In-Reply-To: <05256AB5.006B9C92.00@notes.delphiauto.com> from "lee.w.riemenschneider@delphiauto.com" at Aug 27, 2001 02:30:46 PM 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 X-Status: Status: RO lschneid@eng.delcoelect.com writes to shlaer-mellor-users: -------------------------------------------------------------------- > "H. S. Lahman" writes to shlaer-mellor-users: > -------------------------------------------------------------------- > > I agree one should be suspicious of large domain charts, but I also > believe there are legitimate reasons for having them. The obvious one > is sheer size. If an application is going to end up with 100 MLOC I > would expect a whole lot of domains. But I think there are a number of > reasons for smaller applications to have lots of domains in particular > circumstances: > [SNIP] > Big domains. When a domain gets into the 100+ class range it starts to > become unwieldy regardless of how cohesive it is. Just getting the > state machines to cooperate properly can be onerous. But the real > problem is testing it. One of the great values of the S-M domain > philosophy is that domains can be fully functionally tested on a > standalone basis quite easily. However, when domains get that large > functional testing quickly becomes intractable because of the > combinatorially large number of test cases. I have never seen a domain > that size that could not be broken up in a reasonable fashion. > Yes, but isn't that what the subsystem concept is for? If all the objects belong to the same domain, then why not keep them there? I don't agree that subsystems make reuse a lot harder than seperate domains as someone suggested. > > But, as I indicated elsewhere, if the number of domains is making the > diagram hard to read, then I would favor a nesting approach. Blowing > out detail from a high level collector is a pretty standard and > intuitive way of managing complexity. > How do you decide what domains to group into a nest? It almost suggests that the domains weren't properly abstracted in the first place. > > To illustrate one type, imagine a PC like closed system, where you have a > twenty > > different applications running on a common platform. These applications don't > > require a lot of interaction, and they use a common subset of services. For > this > > system, I would think that you would want to construct a domain chart for each > > application. Direct interactions between applications could show up with > > application domains shown as service domains on the domain charts. This would > be > > the same approach that one would take when modeling a PC application. > > But let's hypothesize that this is some killer system where all of the > individual applications are supplied as part of the same > system. (Before the advent of DLLs this was pretty much the way large > systems were implemented.) In that case one wants a DC for the whole > system. > If the system really needs to be that tightly coupled, then maybe the different application domains are better shown as subsystems. Of course, if we're talking more from an implementation point of view, then maybe we need a LINK domain. ;-) > Now one has a conundrum when one wants to look at the domains for each > application. One can put them all on the DC, one can have a high level > subsystem for each application that can be blown out to shown its > relevant domains, or one can pretend the applications are completely > separate and provide an unattached DC for each one. The first loses the > notion of individual tasks with completely separate subject matters. > The second introduces a second level of abstraction. The third does not > provide a direct path from the system level to the individual domain > level. Given the choice, I would always opt for the second because it > describes the system structure much better and in a conventional way. > If the third makes perfect sense, then some other document could easily be made that shows all of the applications included in the system. I'm not sure if my suggestion for interactions between application domains works. I can see a number of maintenance problems unless it was possible to link the app as an app domain with the app as a service domain models.