From owner-shlaer-mellor-users@phoenix.projtech.com Sun Aug 26 21:03:23 2001 From: "H. S. Lahman" To: shlaer-mellor-users@projtech.com Subject: Re: (SMU) Flat vs. 3D Domain Charts RJLRef: ~/01f522/smu.vs.uml.010827 "H. S. Lahman" writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Dodd... > > > 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? > > 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. 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.] > I accept there are other ways of applying subject-level partitioning within the UML notation, the way some people develop componentware being one of them, but that's not S-M. There is also nothing wrong with trying to extend the S-M method (process or notation), but when we do propose changes, we need first to consider how those changes impact on the whole of the S-M method, especially if we are challenging core ideas such as "each domain contains a minimum of one information model". Whether the new idea is expressable in UML notation is a secondary consideration, it's the idea and its impact on the S-M method that matters, wherever that idea comes from. > > 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. ************* 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 Sat Aug 25 04:08:48 2001 Subject: Re: (SMU) Flat vs. 3D Domain Charts From: bob dodd To: shlaer-mellor-users@projtech.com Date: Sat, 25 Aug 2001 10:17:20 +0300 bob dodd writes to shlaer-mellor-users: -------------------------------------------------------------------- "H. S. Lahman" writes to shlaer-mellor-users: -------------------------------------------------------------------- [sinip] > > 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? 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. I accept there are other ways of applying subject-level partitioning within the UML notation, the way some people develop componentware being one of them, but that's not S-M. There is also nothing wrong with trying to extend the S-M method (process or notation), but when we do propose changes, we need first to consider how those changes impact on the whole of the S-M method, especially if we are challenging core ideas such as "each domain contains a minimum of one information model". Whether the new idea is expressable in UML notation is a secondary consideration, it's the idea and its impact on the S-M method that matters, wherever that idea comes from. Which is all a long way of say that I think it does matter :-)) /bob dodd From owner-shlaer-mellor-users@phoenix.projtech.com Fri Aug 24 18:05:16 2001 Date: Fri, 24 Aug 2001 17:15:59 -0400 From: "H. S. Lahman" To: shlaer-mellor-users@projtech.com Subject: Re: (SMU) UML problems "H. S. Lahman" writes to shlaer-mellor-users: -------------------------------------------------------------------- Responding to Hagstrom... > The OMG is always eager to hear what people think. Technology adoption at > the OMG is an open process, subject to a great deal of discussion, > negotiation, and compromise. As my company's primary rep to the > OMG--although not a participant in the UML arena--I think I can safely say > that y'all would be quite welcome to come and join the party. Next meeting > is September 10-14 in Toronto. See http://www.omg.org for more details. Alas, I am essentially retired now, so I don't attend a lot of conferences anymore -- especially when I have to pay for them. B-) [I know you aren't doing UML, but it is a knee jerk reaction and you got in the line of fire. Serves you right for trying to be helpful. B-)] FWIW, from my understanding, the MDA steering committee is opting for an interface-based approach that parallels traditional elaboration. That is, an OOD is generated from the OOA that is application specific and that, in turn, is converted into code. The committee seems to be viewing the problem as the need to standardize tool interfaces for moving along that path. (Probably not a big surprise, given the CORBA heavy hitters on the committee.) If so, IMO that is a serious mistake because it ignores almost two decades of very practical application automation experience that dates from before UML existed. It also smacks a lot of the thinking that put engines in the front of automobiles because that's where the horses used to be. (There is an obvious question here: why would one need an application specific OOD model in a process that automatically produces an executable from an OOA model?) While providing for analysis reuse through plugging the OOA model into different OOD model generators, it totally ignores implementation reuse. All of today's code generation tools are built on the premise that one should characterize a particular computing environment once for all the OOAs processed there. But the OMG model reinvents the OOD for each OOA. Worse, any characterization of the computing space is hard-wired into each tool producing OODs for that environment -- essentially each tool reinvents the utilization of the relevant technologies and techniques. A far more useful approach would be for OMG to standardize a meta model of the computing space characterization itself that all tools could use. That would allow the computing space to be characterized in data, which would allow a single code generation tool to be portable across platforms. It would also greatly simplify the translation tools because they would be based upon the invariants of the meta model rather than the specifics of individual platforms. Instead of the OMG model of: UML meta model -------+ | problem v requirements --> OOA model --> OOD model --> OOPL | ^ | ^ | | | | tool interface--+ OOD tool | code generator ^ | | | implementation reqs ---------------+ | | tool interface---+ A better model would be: UML meta model | problem --> OOA model--------+ | requirements | | v v implementation -------------> translation engine ---> executable requirements ^ ^ | | compute space ----> OOD model-----+ | characterization | OOD meta model The OMG model also presents a grave problem for OOA model execution. All commercial model simulators do so by generating code and instrumenting it with calls to their viewing environment. They do this because (a) it allows enormous reuse between the code generator and the simulator, since both do essentially exactly the same thing and (b) they do code generation directly from the OOA model. But this would be impossible with the OMG approach until one went all the way through the entire elaboration. Even then, it requires that the tool generating the code be tied to tool simulating the OOA model despite the OOD being generated in between by yet another tool. [The devil makes me do these things to innocent bystanders.] ************* 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 Mon Aug 27 19:52:30 2001 From: erick.hagstrom@webmd.net Subject: Re: (SMU) UML problems To: shlaer-mellor-users@projtech.com Date: Mon, 27 Aug 2001 18:15:42 -0500 erick.hagstrom@webmd.net writes to shlaer-mellor-users: -------------------------------------------------------------------- Oh, come on. You can flame better than that, even if you are "essentially retired"! Actually it's not a flame at all, it's a good contrast piece showing the differences between the OMG's historical mindset and that of S-M/code generation types. (I emphasize the word "historical".) You do seem, however, to have a couple of misconceptions. A few comments inline... From: "H. S. Lahman" Subject: Re: (SMU) UML problems 08/24/01 03:15 PM >"H. S. Lahman" writes to shlaer-mellor-users: >-------------------------------------------------------------------- > >Responding to Hagstrom... > >> The OMG is always eager to hear what people think. Technology adoption at >> the OMG is an open process, subject to a great deal of discussion, >> negotiation, and compromise. As my company's primary rep to the >> OMG--although not a participant in the UML arena--I think I can safely say >> that y'all would be quite welcome to come and join the party. Next meeting >> is September 10-14 in Toronto. See http://www.omg.org for more details. > >Alas, I am essentially retired now, so I don't attend a lot of >conferences anymore -- especially when I have to pay for them. B-) > > > >[I know you aren't doing UML, but it is a knee jerk reaction and you got >in the line of fire. Serves you right for trying to be helpful. B-)] No good deed goes unpunished, eh? As I said, I'm not participating in UML, but I have played a somewhat minor role in MDA. So I'm a better target than you might have thought! B-) On that note, there is a big difference between the UML efforts and the MDA efforts. Although many of the MDA's models will end up being expressed in UML, there is no requirement that this be so, nor is it even desirable. UML is a useful tool, but no one wants to use it for _all_ models. Even before the MDA came along, we had the Common Warehouse Metamodel for data modeling. >FWIW, from my understanding, the MDA steering committee (the Object and Reference Model Subcommittee, or ORMSC) >is opting for an interface-based approach that parallels traditional >elaboration. That's because it is the OMG's mission to standardize interfaces, not implementations. Yes, there is an Object-Oriented Analysis and Design group which is looking at the implications of MDA for those who actually build software (like me and, until quite recently, you), but the primary thrust of MDA is to change the scope of the OMG's own activities. In the early years the OMG focused on creating CORBA-based standards (generalization, yes, but not too far from the mark). More recently the OMG has undertaken more general activities. Examples would be UML itself for object-oriented (and other kinds of) modeling, the Meta-Object Facility (MOF) (to provide a consistent and coherent foundation for UML), the XML Model Interchange standard (XMI) (especially for translation of model information into XML and back for interchange between tools, but also useful for other XML-related purposes), and the Common Warehouse Metamodel (CWM) (for data modeling). The MDA is a logical extension of this newer tack away from a tight CORBA focus and looking more toward generally useful standards which are independent of implementation technology. >The committee seems to be viewing the problem as the need to standardize >tool interfaces for moving along that path. The ORMSC is primarily concerned, at the moment, with figuring out what it means to be "Platform Independent" (a key MDA concept). Tool interfaces are hoped for, but no one is doing any active tool interface design at the moment, except in a proprietary sense. >(Probably not a big >surprise, given the CORBA heavy hitters on the committee.) The committee is open to any OMG member. Any interested member gets a vote. Regardless, the ORMSC, the Architecture Board (which chartered it) and the OMG in general are very much interested in moving, not away from CORBA, but beyond it. As the OMA (Object Management Architecture, the standard reference architecture for CORBA-based solutions) was to CORBA, so the MDA is to computing technology in general. We are opening up to all of the wild and wonderful new stuff that keeps happening, and striving to standardize interfaces that will live on long after any particular implementation technology has bitten the dust. >If so, IMO that is a serious mistake because it ignores almost two >decades of very practical application automation experience that dates >from before UML existed. It also smacks a lot of the thinking that put >engines in the front of automobiles because that's where the horses used >to be. (There is an obvious question here: why would one need an >application specific OOD model in a process that automatically produces >an executable from an OOA model?) Apart from my previous comment, that the OMG is not in the executable business, there's another misconception evident here. (BTW, MDA uses the term Platform Independent Model (PIM) in the manner in which you're using "OOA", and Platform Specific Model (PSM) in the sense in which you're using "OOD". New TLA, new terminology. It's required by law, isn't it? ;-) ) The MDA doesn't require an application specific PSM _in UML_, just an application specific PSM expressed _somehow_. If the target technology is CORBA, then the PSM could well be in IDL. If the target technology is SOAP, then the PSM could well be in XML. To answer your question, the "executable" _IS_ the PSM if one is using the right technology. >While providing for analysis reuse through plugging the OOA model into >different OOD model generators, it totally ignores implementation >reuse. All of today's code generation tools are built on the premise >that one should characterize a particular computing environment once for >all the OOAs processed there. But the OMG model reinvents the OOD for >each OOA. Worse, any characterization of the computing space is >hard-wired into each tool producing OODs for that environment -- >essentially each tool reinvents the utilization of the relevant >technologies and techniques. No, entirely misunderstood. The MDA envisions standard mappings from platform-independent UML to specific implementation technologies. This enables automated transformations from PIMs to PSMs. The computing environment is characterized once for all PIMs processed there. >A far more useful approach would be for OMG to standardize a meta model >of the computing space characterization itself that all tools could >use. That would allow the computing space to be characterized in data, >which would allow a single code generation tool to be portable across >platforms. It would also greatly simplify the translation tools because >they would be based upon the invariants of the meta model rather than >the specifics of individual platforms. I agree. There are groups working on this very thing. >The OMG model also presents a grave problem for OOA model execution. >All commercial model simulators do so by generating code and >instrumenting it with calls to their viewing environment. I don't think so. I know of--and (used to) use--a model simulator which behaves as an interpreter. > [The devil makes me do these things to innocent bystanders.] No, you do it because you like it, just like I like fanning the flames. B-) > >************* >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