From owner-shlaer-mellor-users@phoenix.projtech.com Thu Aug 23 01:01:15 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 f7N51Ed491018 for ; Thu, 23 Aug 2001 01:01:14 -0400 (EDT) Received: (from majordom@localhost) by phoenix.projtech.com (8.9.3+Sun/8.9.1) id VAA26371 for s-m-users-outgoing; Wed, 22 Aug 2001 21:11:15 -0700 (MST) X-Authentication-Warning: ns.projtech.com: smap set sender to using -f From: "David Whipp" To: Subject: RE: (SMU) Flat vs. 3D Domain Charts Date: Wed, 22 Aug 2001 21:10:04 -0700 Message-ID: <000601c12b89$7d0ea430$926464c4@intranet.fastchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B843FAC.63818AF3@worldnet.att.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 "David Whipp" writes to shlaer-mellor-users: -------------------------------------------------------------------- "H. S. Lahman" replied to me: > Oh, dear, he's back. I thought you were off to the Land > of the Lotus Eaters to do non-S-M stuff. :-) Well, I still do code generation / recursive design. But I often don't start with an OOA. I develop my systems using iterative/elaborative development, but I'm as likey to elaborate a "generator" as the "source". Leon might think of me as an unredeemable model-hacker. One of the first things I did on my current project was to bootstrap a code generator into UML. I can talk more about it later. > Alas, I am having some trouble relating your categorization > below to the DC semantics... I'm not sure whether the DC semantics are effected. It more a characterization of the bridges that connect the domains. > > 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 traditional S-M client/service relationship, > right? Right. Specifically it corresponds to explicit bridging. > > The next type of relationship is analogous to the multiple lays of > > information types. [...]. 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? This type of bridge is likely to be implicit from the perspective of the client. In my current project, the implementation of the bridge would be to take the two XML source files representing the domains and to produce a new XML file that combines them. I've been known to use this to cheat. For example, I had dificulty describing some aspects in UML, so I created one domain in UML, generated it into XML, then combined it with a second file of hand-coded XML. Arguably, these were not different domains. However, at other times it is less clear. I have one domain that describes a state machine from a "functional" level. Another domain describes how to synchronize this (specific) state machine using information from a verilog implementation of the system (i.e. when are the events actually delivered). These are combined into a system that can track the high level transactions through the verilog rtl simulations. The combined XML is then generated into a perl testbench. You can think of this type of combination of domains as being somewhat architectural, though in my world I'm not sure that I can always distinguish application from architecture. There is a continuum. For example, the purpose of the system is to verify the rtl, so the timing of event delivery is an application-level concept, not architectural. > > 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? Bad definition on may part. The use of colours is not really relevant. The point is that the server domain acts as the key that is used to render the client. For example, the XML tag " ... will be rendered in perl as a "package foo;" statement; or in C++ as a class. But, yes, I can add additional attributes/elements in my XML that effect the rendering, analagous to SM coloration. The server domain here might, in SM, be represented as a set of archtypes. I would usually want to go though a series of layer/aspect combinations before I get the final XML file that I render into my programming language. I sometimes find myself doing an additional layer combination to mix generated code with hand-coded blocks. In C++, this is needed because classes are closed. You can't add additional methods without editing the .h file. In perl this is not necessary because you can define the class over multiple files. > A nice characterization, but I am not sure there is sufficient > detail at the DC level to warrant it. >From my point of view, the key thing is that not all (most?) of my domains are not described with OOA. If each domain/bridge has its own meta-model, then that characterization is probably useful at the DC level. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.