From owner-shlaer-mellor-users@phoenix.projtech.com Wed Aug 22 20:05:54 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 f7N05qd464823 for ; Wed, 22 Aug 2001 20:05:53 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id QAA28870 for s-m-users-outgoing; Wed, 22 Aug 2001 16:17:38 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <3B843FAC.63818AF3@worldnet.att.net> Date: Wed, 22 Aug 2001 19:26:36 -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: <000401c12a7e$fe52ce10$926464c4@intranet.fastchip.com> 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 Whipp... > > OK - It's my turn again ... ;*) > Now its mine :) Oh, dear, he's back. I thought you were off to the Land of the Lotus Eaters to do non-S-M stuff. I missed you. I haven't killed nearly as many trees on OTUG and comp.object as I did here with you. B-) Alas, I am having some trouble relating your categorization below to the DC semantics... > When I think of multiple dimensions in domain charts, I usually find myself > classifying the dimensions according to the type of requirements-transfer > between domains. This is different to the purely line-crossing 3D that's > been discussed so far; but I thought I'd chip-in anyway. > > I think of the different types of bridges using the analogy of a map > (cartography, not set-theory). > > The most obvious relationship is analogous to a highway connecting 2 towns. > This provides a simple peer-to-peer route for exchanging things This corresponds to the tradition S-M client/service relationship, right? > The next type of relationship is analogous to the multiple lays of > information types. For example, one layer describes contours; another the > streets; another the sewer system. Each of these can stand by themselves, > but the complete picture of the landscape (system) is only achieved by > combining the layers. The is a bit like the concept of weaving in > aspect-oriented programming. This is the one I have the toughest time mapping to DC semantics. What would be an example semantics of one of these layers in a DC? > Another type of relationship is analagous to the "key": roads in blue, red > or yellow depending on their classification; woodland in green; sea in blue. > This mapping is the stuff of code generators, which take an abstract > description and render it in a language of your (their?) choice. OK, I see the colorization angle. But I still have a problem dealing with it at the level of domain bridges in a DC. What is being colorized? Is the intent to be something synchronous vs. asynchronous or explicit vs. implicit? > A similar relationship is seen in the not-to-scale depictions of specific > phenomina. For example, a map of the london underground shows only the > relationships between stations. This lies somewhere between the > multiple-layers concept and the syntax rendering concept. This goes to show > that classification of inter-domain relationships is not black-and-white. > > The one relationship of a map that doesn't appear on a domain chart is that > of scale. Maps sometimes have a cut-out, "see box for detailed view". An OOA > analysis is detailed, using views within a domain. But one could use UML's nesting of elements to provide essentially the same thing. > So my 3 diminsions of the domain chart are: peer-to-peer, layering, and > transformation. A nice characterization, but I am not sure there is sufficient detail at the DC level to warrant it. ************* 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 From owner-shlaer-mellor-users@phoenix.projtech.com Thu Aug 23 17:07:41 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 f7NL7dd35828 for ; Thu, 23 Aug 2001 17:07:40 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id NAA13713 for s-m-users-outgoing; Thu, 23 Aug 2001 13:26:11 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <3B8568ED.3A5B6C41@worldnet.att.net> Date: Thu, 23 Aug 2001 16:34:53 -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: <05256AB0.0049F4E3.00@notes.delphiauto.com> 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 Riemenschneider... > I would like to see a reasoning behind a domain chart with a very large number > of domains. I get the impression of domain models that try to emulate the > layered building block approach, enforcing reuse at the expense of the system, > an attempt to place too many application layers onto one diagram, and/or > multiple service domains that provide the same services. 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: Reuse. Some systems are intrinsically highly modular with an opportunity for a lot of plug & play. For example, large electronic test systems can have two dozen distinct types of instruments (DVMs, function generators, switching modules, etc.) where each one can be routinely swapped for a different manufacturer/model. And those are just the device drivers. Each one has a particular flavor test approach that can also be reused in different system configurations. And on top of that there are several implementation domains that provide things like generic error handling. For the kind of test system that can test all the electronics on a B2 bomber, there could easily be 50 reusable domains. Logical complexity. The example that comes to mind is Email. I remember a presentation by someone developing such an application where the claim was that there are about 30 independent formats for Email messages and that they can even be combined within a single Email. While one might well be able to capture the essential differences of those individual parsers in a couple of objects each within a single domain, it might not be a good idea logically if processing different message formats was pretty much the justification for the application in the first place. A major goal of the model is to provide the most understandable view of the essential processing. Smart bridges. I am very much biased against complex bridges. Too often they are hiding essential problem space processing in what is essentially an architectural unit. While some intelligence is often required in bridges, I get real suspicious when bridge code moves into the KLOC range. In those cases I would prefer to convert the bridges' intelligence into analyzed domains, even if it results in several smallish domains. Some domain clutter is a small price to pay for ensuring that all the important aspects of the problem are exposed in the analysis. [One could analyze all the smart bridges in a single service domain, but that has subject matter coherence problems and the DC dependencies are not intuitive.] Distribution. While subject matter and level of abstraction are paramount, it is usually a good idea to organize an application so that distribution boundaries coincide with domain boundaries. Because one doesn't create separate domains for identical clients, one wouldn't expect a large number of domains per se, but it could be a contributing factor. [Fortunately distribution boundaries usually do coincide with subject matter boundaries. B-)] 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. > It may be that I just haven't encountered the right system yet. Are these large > domain charts multi-application or multi-service domain or both? My main concern > is that a domain chart that requires a 3D point of view or is too cluttered may > hide as much information about the system as it reveals. I would think that > simplicity would be desirable attribute of the domain chart. The main justification for the 3D view is to provide a perspective on bridge crossovers. But I am not convinced that is really necessary because with the crossovers there is still no confusion about which domains are related. So I don't see crossovers and 3D views as emblematic of clutter. OTOH, lots of domains do get cluttered. One way we used to reduce it is to simply not bother showing the relationships with architectural domains. Since those relationships were usually pretty ubiquitous (i.e., the architectural domain was related to everybody above, as in MFC), showing the relationships didn't add anything. 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. > 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. 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. [Note that I don't think the argument that multi-tasking is an architectural issue applies here. Each application is a logical entity in the problem space because it addresses a specific and cohesive set of requirements and it has important interactions with other parts of the overall system. Your example happens to be a good one because it clearly represents a high level subject matter cohesion (system level) compared to individual domains (application level) that is both reasonable and useful for understanding the system.] ************* 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 From owner-shlaer-mellor-users@phoenix.projtech.com Thu Aug 23 17:12:07 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 f7NLC6d39498 for ; Thu, 23 Aug 2001 17:12:06 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id NAA13971 for s-m-users-outgoing; Thu, 23 Aug 2001 13:30:11 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <3B8569DE.3CBA28C0@worldnet.att.net> Date: Thu, 23 Aug 2001 16:38:54 -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: <998546018.4df5fff7bob.dodd@myrealbox.com> 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 Dodd... > 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? I would argue for both. The situation where I see usefulness for both is when the problem space itself provides a hierarchy of abstraction. The example I cited elsewhere was a Digital Test domain that encapsulated In-Circuit Test, Boundary Scan, Signature, and other flavors of digital tests. Some clients could want a more generic interface that doesn't recognize the flavors. That bridge would dispatch to the individual domain bridges for specific flavors. But a more general reason is for the hiding of namespaces and implementations, as you suggest later on. > 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? Like art, you know it when you see it? B-) I don't think nesting affects the primary issues of domain identification and relationships; I see it is primarily an issue of useful navigation and display of the domains that have been identified. (Possibly one could develop some organizational paradigms that would be helpful in identifying domains, but I see that as secondary.) In that case the validation is primarily an aesthetic judgment about whether the model organization is useful. > 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? I don't think this is an issue anymore since everybody has pretty much converted to UML; the questions are really how much of the UML does one want and how should it be interpreted relative to S-M? > b) What depth of nesting is allowed before you hit a domain which contains an OIM? In practice I would be real surprised at more than three levels, especially if one tries to isolate problem space subject matters. But why should there be a limit if the hierarchy depends upon the particular problem -- if the problem structure is arbitrary, why wouldn't the nesting? > 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? I am not sure I understand the question. Don't they represent exactly the same things? Whether a domain is analyzed, realized, or third party should not affect the bridge relationship or the bridge model. > 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 am somewhat confused here as well. The bridge model specifically hides the domain namespaces. The domain interface is the only one that understands contained events, objects, etc. So that namespace is hidden by the domain interface. The bridge connects domain interfaces so the only relevant namespaces exposed outside the domains are those of the domain interfaces. One has: +------------+ +------------+ | Domain A | | Domain B | | | | | | +-----+ +------+ | | | AIO |----------------->| BII | | | +-----+ +------+ | | | Bridge | | | +-----+ +------+ | | | AII |<-----------------| BIO | | | +-----+ +------+ | | | | | +------------+ +------------+ where xIO is the output interface for domain x and xII is the input interface for domain x. The interface namespaces (AII, AIO, BII, BIO) would be exposed at the level of the containing element (subsystem, domain, package, whatever). One of the advantages of providing interfaces for the nesting element is that such an interface can hide the namespaces of the contained domain interfaces from the rest of the application. ************* 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 From owner-shlaer-mellor-users@phoenix.projtech.com Thu Aug 23 17:09:24 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 f7NL9Md35812 for ; Thu, 23 Aug 2001 17:09:22 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id NAA13935 for s-m-users-outgoing; Thu, 23 Aug 2001 13:29:41 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <3B8569B6.E0BAC168@worldnet.att.net> Date: Thu, 23 Aug 2001 16:38:14 -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) Many Domains Question References: <20010822211307.46700.qmail@web14606.mail.yahoo.com> 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 Dodd... > I suspect a lot of people come to grief on domain charts, but then we > don't seem to have many rules to help guide people. We have our 72 OOA > rules in the paper from Neil Lang, but they are specific to an > individual domain, we don't seem to have an equivalent list published > for the domain chart itself... I agree that a lot of people come to grief with them, but I am not sure rules at the level you describe will help a lot. In the original S-M training course I took in the late '80s the instructor told us, "If you spend half a day on the DC, it is too much." I now believe that was absolutely the worst software development advice I've ever had. For larger projects I believe it is the single most important diagram in S-M. If you don't get it right the cohesion of domains will bleed, there will be problems with levels of abstraction, and requirements allocation will be incorrect. In addition, even if one gets the domains to hang together, one is liable to have long-term maintainability problems that result in periodic massive shotgun refactorings of the models and bridges. The problems people have with DCs lie in properly identifying domains and bridges. People also tend to not describe them with sufficient detail and clarity so that can serve as the long term application structure. Unfortunately things like subject matter, level of abstraction, and client/service relationships are all quite touchy-feely and aren't amenable to detailed rules. > A perfect domain chart is one in which can be represented as a directed > graph where: > > (i) if considered to be undirected, the graph is connected. I believe it is always directed and acyclic. That is the nature of client/service relationships. > (ii) there is at least one vertex which is connected by edges which > originate from the vertex, but which is connected by no edges that > terminate at that vertex. > > (iii) there exists no cut set of the graph that contains a Hamiltonian > Circuit. Wow. The last time I encountered a Hamiltonian was solving an N-body problem in a physics course forty-three years ago. There is no way I would recognize one now if I slept with it. > (iv) there is one and only one edge connecting any two vertices. While it is hard to imagine a situation where it would not be true, is this really a necessary condition? While I haven't got a plausible example off the top of my head, one can conceive of an application that operates in different modes that would imply logically distinct bridges. In such a system it might be useful to make that explicit in the model. Another problem I have is that UML distinguishes between dependencies and interfaces in the Package Diagram (v1.4 allows their connections to be shown separately for subsystems). I believe that is a useful thing because I have always been aesthetically displeased by the double duty of a bridge as both a client/service dependency and the only place to describe the inter-domain communications. > (v) the weight of every edge is 1 (one). > > It's very easy to argue with the rules in my theory of the 'perfect' > domain chart (and it doesn't begin to answer sizing and complexity > rules, though it gives a language to express them: tree depth, longest > path, fan-in, fan-out etc.) but it does force the issue of what > represents at least a syntactically correct domain chart e.g. > > * Which bridges (if any) can be omitted? e.g. bridges to architecture > and implementation domains? FWIW, we routinely omitted architecture bridges because they tended to connect to so many domains that the DC clutter wasn't justified by information added. > * Can large domain charts ever be drawn as smaller parts (i.e. mulitple > diagrams) that repeat the names of domains and repeat bridges expressed > on other parts (e.g. as we do with subsystems within a domain), or is > there only one single domain chart? The UML PD already has facilities for this, both for simple off-page connectors and collector nesting of diagrams. My intuitive reaction is: use whatever makes the model in hand most comprehensible. However, as I have indicated elsewhere, I generally like the idea of multiple levels of abstraction for big applications or systems. One should be able to view the structure of such models at different levels and navigate consistently among them. Alas, there is a potential problem in doing that because of the S-M hierarchy of Application, Service, Implementation, and Architecture. In the example in another message of semi-autonomous PC applications, one would like to preserve the hierarchy for each one because they are likely to be developed autonomously in parallel. OTOH, the notion of subject matter kind of suggests one might want to collect logically related domains within an umbrella subject matter within, say, the Service layer. FWIW, since UML allows both, I would be inclined to use both as necessary under the guise of Whatever Works in a particular situation. So long as one has a proper handle on the basics of domain identification, the rest is just a matter of logical presentation. > * Can you ever have two service domains that provide services to each > other, however indirect? (i.e. the Hamiltonian Circuit exclusion rule) Actually, if you work with VXI there is an even more bizarre situation where one has multiple top-level application domains. A VXI device driver is primarily used through a programmatic interface represented by one application domain. But VXI also mandates a "soft front panel" to allow the user to "play" with the instrument through a GUI to gather familiarity with it. The SFP is an entirely separate application control facility from the programmatic interface that has its own bridges to the service domains (e.g., to extract values from the hardware in a "debugging" view). Because VXI mandates both as deliverables in the same system, it is not an option to have independent DCs that simply reuse all the lower domains. > Sorry, maybe this sounds a bit picky, but imagine trying to define an > XML schema/DTD to describe a domain chart so that you can export and > import S-M models between different vendor's CASE tools. S-M is very > precise within a domain, but you can see the problems we have in > writing a validating XML parser for the domain chart... I don't have a problem with the exercise. It is just that the basic DC is already pretty simple, so there isn't a lot of wiggle room. B-) I also think that since all the S-M CASE vendors are now supporting UML subsets, the real issue lies in mapping the desired S-M semantics into the UML PD semantics. ************* 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 From owner-shlaer-mellor-users@phoenix.projtech.com Tue Sep 4 00:13:07 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 f844D5s116435 for ; Tue, 4 Sep 2001 00:13:06 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id UAA22690 for s-m-users-outgoing; Mon, 3 Sep 2001 20:23:25 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f Message-ID: <3B944A3F.4722974F@worldnet.att.net> Date: Mon, 03 Sep 2001 23:27:59 -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: <200108311417.f7VEHdE04770@koadsy11.delcoelect.com> 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 Riemenschneider... > > > The subsystems should not have a lot of relationships with other subsystems, > > > so I fail to find that the subsystems concept adds a lot of maintenance > > > overhead. Of course, the tool used could be a large factor in this argument. > > > > But why would one want to do that? At the domain level S-M provides the > > most disciplined methodology available for dealing with system > > partitioning. I don't see why one would want to give that up when > > splitting up a large domain that has become unwieldy. What one wants > > out of the splitting are just a set of domains that are not unwieldy. > > > Maybe I'm making a bad assumption that bridges cost some overhead in the > generated code. (see now I'm mixing in implementation issues. :-) ) No question there will likely be at least some overhead penalty for applying bridges to the split portions in translation. (In theory one could have the translation eliminate the bridges, but I don't think that is good because...) But that is a tradeoff against testability and long-term maintainability. > > > Again I'll have to disagree. I don't see any added test burden in testing a > > > subsystem vs. testing a domain. Maybe this is a certain amount of naivete on > > > my part, but the argument just doesn't make sense to me. > > > > The problem is that one can't isolate the subsystem for testing if one > > has not encapsulated it with a domain interface. Other than object unit > > testing with the queue manager disabled, the subsystem has to be driven > > from the containing domain interface in situ and that presents the same > > combinatorial test problem as testing the full domain. > > > Maybe this is more of a tool issue, but I envision unit testing on a > subsystem. Since the subsystem should not have many relationships going > outside of it, it shouldn't be a complex matter to introduce drivers and stubs > that replace those relationships. I would expect the events too be limited as > well. > The ability to split off a part of a domain into a seperate domain implies a > looser coupling as well. There are a couple of problems in trying to isolate the subsystem under test. The subsystem may not be able to execute to completion if it expects an event in response to one sent to another subsystem. In theory a tool add-on to the queue manager could handle this, but it would be a complicated tool and you still have to define the event responses. Another problem is accessing attribute data from the other subsystems' objects. Even if you isolate their behavior somehow, you would still have to instantiate and initialize their state data. That instantiation might be test case dependent. Finally, there is the problem of domain synchronous services and object synchronous services that can be invoked from anywhere in the domain. Though these would hopefully be well behaved, one would still have to have object synchronous services in other subsystems instantiated. If there are not so well behaved, they may do nasty things like put events to other subsystems on the queue. I agree, it could be a tool issue, but I think the test harness to properly isolate the subsystem will tend to be a pretty complicated one with a lot of potential gotchas. In addition I think one would need to provide behavior emulation results in the test cases for the stubbed behaviors in other subsystems. If one makes true domains, then isolation comes for free. Free is better, even if you don't live in New Hampshire. [FYI, non-local lurkers: New Hampshire's auto license plates have the motto "Live free or die", which I have always read as a sort of Deterministic Imperative Oxymoron (i.e., Live free or we will kill you). But I digress...] > > H. S. Lahman > > hsl@pathfindersol.com > > Pathfinder Solutions -- We Make UML Work > > http://www.pathfindersol.com > > (888)-OOA-PATH > > > That was a short retirement! :-) I am actually still retired. My affiliation with Pathfinder is pretty much limited to a quid pro quo for their editorial support in the book and articles. In addition we have pretty similar methodological views. Also, since some of the people at Pathfinder as ex-Teradyne types, there is a certain social aspect. B-) > I was actually expecting a book. I guess comp.object wasn't exercising the > analysis itch enough. :-) Unfortunately progress on the book has been rather glacial. I am now officially hoisted upon the same petard I used in referring to the Long Awaited RD Book. ************* 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