From owner-shlaer-mellor-users@phoenix.projtech.com Wed Aug 22 19:58:32 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 f7MNwUd462554 for ; Wed, 22 Aug 2001 19:58:31 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id QAA28841 for s-m-users-outgoing; Wed, 22 Aug 2001 16:17:12 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <3B843F86.5A0FF54D@worldnet.att.net> Date: Wed, 22 Aug 2001 19:25:58 -0400 From: "H. S. Lahman" X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: shlaer-mellor-users@projtech.com Subject: Re: (SMU) Flat vs. 3D Domain Charts References: <000201c12a67$1e8a9040$6998be84@hmeyersonvl400> 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 "H. S. Lahman" writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Meyerson... Be forewarned, because SMU has been pretty inactive I have spent most of my time on OTUG and comp.object. The problem in those worlds the term 'domain' has an entirely different meaning so I have to use the UML terms, package and subsystem, there. So I may have a problem swtiching gears below to the S-M usage. > > Unless the diagram is awfully cluttered I don't see the need for a 3D > > view. If the clutter is that bad, then I would opt to take > > advantage of > > UML's ability to nest by using subsystems to capture related domains. > > I thought that it was a bad idea to use a subsystem where a domain is > appropriate to encapsulate a specific subject matter. I think that depends a lot on what semantics you want to place on it. If the goal is primarily project management (i.e., allowing a team to work semi-autonomously), then the UML Package view of the high level artifact being simply a container of model elements to facilitate configuration management works. S-M already stereotypes the UML interpretation of a dependency in the package diagram, so it isn't that big a conceptual problem. All one may be adding is a suite of defined interfaces, which is not unreasonable in the context. There doesn't need to be any implementation substance to the enclosing Package; that would remain in the domains it collected. In this case I see it as being similar to a supertype state machine -- it is simply a notational artifact to make viewing the application common subtype behavior easier. The high level "subsystems" simply provide a block diagram style, a large scale view of the system but the domains are where the action is. Personally, I like the idea of nesting domains in the UML style for other reasons. Before I retired we made testers that did digital, analog, and mixed signal. There were several flavors of digital and analog tests, each warranting its own domain. But at a higher level they were just analog or digital. Moreover, regardless of which flavor was accessed there was a lot of commonality in the bridges within a category of test, but big differences for analog vs. digital. Most of the rest of the application could care less about flavors of digital test. For example, to deal with mixed signal testing you need an infrastructure that really doesn't care about individual analog or digital flavors. That suggests that the notion of a Digital Domain that had its own interface even though the main work was done in a set of plug & play (the customer bought options) flavors of detailed tests. That would isolate the flavors from the rest of the system through a common interface. It would also allow the high level domain to have some unique smarts that reflected common aspects of each flavor (e.g., putting the tester in a known state). That could be handled through yet another service domain, but that is awkward because it isn't accessed from other domains but directly from the enclosing domain's interface. So having the enclosing domain have its own class level implementation seems interesting, but I am lukewarm about it. The key thing is that I think a simple minded nesting can be quite useful for thinking about large systems in a systematic way (i.e., at different levels of abstraction). That is always a handy way of managing complexity. I think it also allows a way to provide more organization in thinking about partitioning (e.g., "These domains are all related under this subject matter umbrella."). > > > > That said, we have areas in our domains where nesting is > > > > tempting. (e.g. We have three domains > > > > dealing with different aspects, such as handling > > > > commands, velocity control, > > > > and I/O, of controlling one type of hardware.) > > > > > > Let's just agree not to call it 'nesting', because it is > > not that. [The last > > > thing we need is Harel domain charts. :^) ] > > > > I agree it is not Harel-style nesting. However, it is useful for > > collecting related subject matters and level of abstraction. It can > > also be used to define interfaces at difference levels of abstraction > > (e.g., high level vs. low level). > > If it's not nesting, then what is it? I was beginning to be convinced that > any grouping of domains within bigger domains is a bad idea. Subsystems are > inside domains, but they are just a management convenience. It is nesting only in the model element sense of collecting one set of model elements within another. I think that is handy for displaying different levels of abstraction in a complex system. > > I interpreted M[e]yerson to be taking advantage of UML's distinction > > between an interface and a dependency (especially in v1.4 > > where the UML > > definition of a subsystem really is pretty much an S-M domain). That > > has always been a sticking point in S-M because the bridge served a > > double duty as both a client/service relationship for the > > allocation of requirements and as a collection of wormholes > > comprising a communications interface. > > > > UML conveniently allows one to identify both the client/service > > dependency and the communications interfaces in the Package Diagram. > > There are times when it is useful to identify different > > interfaces. For > > example, a service domain may provide both a high level > > interface (e.g., > > Test) and a low level interface (e.g., Setup, Initiate, Fetch) and one > > wants to identify which one a particular bridge will employ. > > I was thinking mostly of bridges between domains, but I threw the interface > term in there to cover all possibilities. OK, so much for interpretation. B-) > My OO training is mostly the > original S-M, but I now coming up to speed on enough UML to get my job done. > (Our organization has already purchased I-Logix Rhapsody as our tool, and > hasn't completely blessed S-M. I am fine if I use S-M concepts within a > UML-based tool and don't get too religious. It is, of course, a fine line.) > We will probably use interface objects to implement the the bridges between > domains, but we'll be careful to avoid any connections between ordinary > objects that live in different domains. > > The notion of domain also exists in UML, implemented as a package, and is > prominently mentioned in the ROPES process promoted by I-Logix. Where they > get it "wrong" is to show the classes/objects within a domain in a domain > diagram, and to allow unconstrained connections. It turns out that in v1.4 of UML the definition of a subsystem is much closer to an S-M domain than a UML package. The package in UML is exclusively a configuration management artifact that doesn't have a lot of application-level semantics associated with it (subject matter, level of abstraction, client/service). But UML does attribute pretty much those things to subsystems. Alas, UML is still a moving target in this area because the v1.4 spec is very different about this than previous releases. I suspect the MDA and action language initiatives at OMG have pointed out that UML didn't deal with logical application partitioning and they are playing catch-up. FWIW, I have some problems with the way they are going. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl@pathfindersol.com Pathfinder Solutions -- We Make UML Work http://www.pathfindersol.com (888)-OOA-PATH