Issue 2046: What is a UML "profile"? (mof-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The concept of profile may need to be escalated to the MOF level (for example as a subset of metadata constructs packaged together with appropriate classifiers, tags, constraints etc. -). I agree that creating new metamodels for each minor extension is not a tractable solution to the problem - especially if it means tool vendor cost of supporting it is too much. Resolution: Revised Text: Actions taken: October 7, 1998: received issue July 23, 1999: deferred to new RFP/reopened Discussion: One possible interpretation is that a "profile" of a meta-model (aka a Package) is a set of additional Constraints on the Package, that might (for example) disallow the use of certain model elements or combinations that are allowed in the base Package. If so, expressing this using the MOF Model might require changes. For example, constraint [35] says that the 'constrainedElement' of a Constraint must be part of the "extended contents" of the Con-straint's container. Status: Outside the scope of the RTF. UML and MOF profiles need to be precisely defined. This is part of the broader discussion of heavy weight extension mechanisms part of MOF 2.0 and UML 2.0 Implementation: Nothing to do. Done [KR]. One possible interpretation is that a "profile" of a meta-model (aka a Package) is a set of additional Constraints on the Package, that might (for example) disallow the use of certain model elements or combinations that are allowed in the base Package. If so, expressing this using the MOF Model might require changes. For example, constraint [35] says that the 'constrainedElement' of a Constraint must be part of the "extended contents" of the Con-straint's container. Status: Outside the scope of the RTF. UML and MOF profiles need to be precisely defined. This is part of the broader discussion of heavy weight extension mechanisms part of MOF 2.0 and UML 2.0 Implementation. This is supposedly being addressed in either UML 1.4 or the UML 2.0 Infrastructure RFP. End of Annotations:===== Return-Path: From: "Iyengar, Sridhar" To: boi-wg@omg.org, Ed Seidewitz Cc: mof-rtf Subject: RE: What is a UML "profile"? Date: Tue, 6 Oct 1998 19:56:33 -0400 The concept of profile may need to be escalated to the MOF level (for example as a subset of metadata constructs packaged together with appropriate classifiers, tags, constraints etc. -). I agree that creating new metamodels for each minor extension is not a tractable solution to the problem - especially if it means tool vendor cost of supporting it is too much. mainly because of issues related to XMI and general meta data interoperability when a related set of tool developers need to share concepts slightly different from another related set of tool/app developers. I expect this to be an ongoing problem as technologies (i.e. metamodels) evolve over time - especially from a relatively 'immature state' to a more 'mature' one. Note that UML 1.1 metamodel is about a year old now. I can see that a similar requirement is likely to emerge as we define the Common Warehouse metamodel - different tool vendors may want to focus on a 'db admin' pofile, OLAP profile, "DTS' profile (Data transformation services) and so on. Sridhar ------------------------------------------------------------------------ --------------------------------------------- Sridhar Iyengar Unisys Fellow sridhar.iyengar@mv.unisys.com > unisys 714-380-5692 > (Pho) 25725, Jeronimo Rd 714-380-6632 (Fax) Mission Viejo, CA 92691 656-5692 (Net) ------------------------------------------------------------------------ ---------------------------------------------- > ---------- > From: Ed Seidewitz[SMTP:seidewitz@dhr.com] > Sent: Tuesday, October 06, 1998 1:41 PM > To: boi-wg@omg.org > Subject: What is a UML "profile"? > > In my previous message, I suggested that the way to proceed with the > BOI > (at least relative to the ADTF) is to have our RFP request a > standard > "profile" for the use of UML by the distributed enterprise computing > community. This, of course, begs the question of what such a > "profile" > really is. With this message I would like to begin a discussion on > better > defining this term. > > The term "profile", in the more or less the sense I was using it, > was > introduced in the ADTF during the discussion of the Action Semantics > RFP. > After the Helsinki meeting, the writers of that RFP were responding > to > the > criticism that different groups might need the UML action semantics > to > be > made precise in different ways. To answer this they proposed > allowing > the > submission of multiple "semantic profiles" for precise action > semantics. > > In a more general sense, the idea is to embody some commonality of > usage of > UML tailored for a particular community. As a general term, I would > see > such a "profile" as including: > > o definition of a subset of the existing constructs of UML; > > o definition of more rigorous semantics for this subset of > constructs, > tailored to the needs of the community; > > o definition of standard tagged values and stereotypes to provide > additional semantics tailored to the needs of the community > (potentially > along with special icons). > > The use of existing UML constructs, tagged values and stereotypes > should > allow general UML tools to be used for the specific modeling needs > of > the > particular community. The definition of rigorous semantics for the > defined > subset allows for a standard mapping from model to implementation > that > could be implemented as an add-on to the general UML tools. > > Now, in some cases it may be absolutely necessary to actually extend > the > UML metamodel to accommodate the needs of a particular community > (though in > most cases I would expect that this indicates a deficiency in the > UML > metamodel in general that should be corrected). In this case, the > extension > should be made in the form of a small number of new metamodel > subtypes > separately packaged as an optional compliance point. (I really don't > think > this well be necessary for business objects.) > > I believe that in the case of the draft BOI RFPs, what was being > asked > for > really focused a lot on modeling requirements to allow a clean > implementation mapping. This caused some of the confusion in the > ADTF. > I > think the explicit "profile" idea both clarifies what is being asked > for in > terms of the UML as well as the relationship of this to an > implementation > mapping. > > > > ______________________________________________________________________ > _ > Ed Seidewitz Manager, Object Systems Product > Line > DHR Technologies > > (A division of OAO Technology Solutions) > > 10400 Little Patuxent Parkway, Suite 310 Voice: > +1.410.992.4000 > Columbia MD 21044 Fax: > +1.410.992.4500 > > ______________________________________________________________________ > _ > Return-Path: To: "Iyengar, Sridhar" cc: boi-wg@omg.org, Ed Seidewitz , mof-rtf , crawley@dstc.edu.au Subject: Re: What is a UML "profile"? Date: Wed, 07 Oct 1998 12:06:30 +1000 From: Stephen Crawley Sridhar et al, > The concept of profile may need to be escalated to the MOF level (for > example as a subset of metadata constructs packaged together with > appropriate classifiers, tags, constraints etc. -). I agree that > creating new metamodels for each minor extension is not a tractable > solution to the problem - especially if it means tool vendor cost of > supporting it is too much. That is one approach. [I'd be inclined to say that adding profile support to the MOF Model and / or the IDL mapping is beyond the scope of the MOF RTF.] Another approach is to say that a "profile" of a MOF metamodel is really just a self-contained (in terms of dependencies) subset of the metamodel. Hence a repository for a MOF metamodel can act as a repository for any well-formed "profile". Similarly, XMI for the full metamodel can be used to interchange models conforming to the profile. I wave my hands ... >>so<< ... and it goes away! :-) -- Steve Return-Path: From: "Iyengar, Sridhar" To: "Iyengar, Sridhar" , Stephen Crawley Cc: boi-wg@omg.org, Ed Seidewitz , mof-rtf Subject: RE: What is a UML "profile"? Date: Tue, 6 Oct 1998 19:17:49 -0700 There was no implications that the profile would be addressed by an RTF, an RFP etc at his time. - this was the beginnings of a discussion. Sridhar ---------------------------------------------------------------------------- ----------------------------------------- Sridhar Iyengar Unisys Fellow sridhar.iyengar@mv.unisys.com > unisys 714-380-5692 > (Pho) 25725, Jeronimo Rd 714-380-6632 (Fax) Mission Viejo, CA 92691 656-5692 (Net) ---------------------------------------------------------------------------- ------------------------------------------ > ---------- > From: Stephen Crawley[SMTP:crawley@dstc.edu.au] > Sent: Tuesday, October 06, 1998 7:06 PM > To: Iyengar, Sridhar > Cc: boi-wg@omg.org; Ed Seidewitz; mof-rtf; crawley@dstc.edu.au > Subject: Re: What is a UML "profile"? > > > Sridhar et al, > > > The concept of profile may need to be escalated to the MOF level > (for > > example as a subset of metadata constructs packaged together with > > appropriate classifiers, tags, constraints etc. -). I agree that > > creating new metamodels for each minor extension is not a > tractable > > solution to the problem - especially if it means tool vendor cost > of > > supporting it is too much. > > That is one approach. [I'd be inclined to say that adding profile > support to the MOF Model and / or the IDL mapping is beyond the > scope > of the MOF RTF.] > > Another approach is to say that a "profile" of a MOF metamodel is > really > just a self-contained (in terms of dependencies) subset of the > metamodel. > Hence a repository for a MOF metamodel can act as a repository for > any > well-formed "profile". Similarly, XMI for the full metamodel can be > used > to interchange models conforming to the profile. > > I wave my hands ... >>so<< ... and it goes away! :-) > > -- Steve > > Return-Path: To: "Iyengar, Sridhar" cc: Stephen Crawley , boi-wg@omg.org, Ed Seidewitz , mof-rtf Subject: Re: What is a UML "profile"? Date: Wed, 07 Oct 1998 15:15:53 +1000 From: Stephen Crawley Sridhar et al, Sridhar wrote: > There was no implications that the profile would be addressed by an > RTF, an > RFP etc at his time. - this was the beginnings of a discussion. Yes, I realize that how / were any changes to MOF might be done is not the real issue. I was also a bit flippant previously ... sorry. The MOF does perhaps offer a perspective on what exactly a "profile" of a metamodel (such as the UML metamodel) might be. [Please bear with me as I lay some groundwork ...] At the M2 level in the MOF, a metamodel equates to the closure of a Package. At the M1 level, a model is collection of metadata that is described by an M2 level Package. Also at the M1 level, the MOF IDL mapping defines a "package object" interface that acts as a kind of container for a collection of metadata that conform to a metamodel. [It is up to the implementor to decide precisely whether this constitutes one "model", or many "models".] MOF provides 4 distinct ways of composing metamodels / Packages: o Package nesting - a Package may be declared inside another Package. When a Package is nested, it effectively cannot be reused in its own right. o Package importing - when a Package imports another Package, it can depend on it in certain ways; e.g. it can use Classes and DataTypes declared in the imported Package. However, there are certain runtime restrictions on what can be done at the M1 level. o Package inheritance - when a Package inherits from another Package all component Classes, Associations, DataTypes etc are reused in the subPackage. At the M1 level, there is an IS-A relationship between the subpackage and superpackage interfaces. Note however that a superpackage cannot depend on its subpackages. o Package clustering - this is a proposed new composition mechanism in which a number of Packages with import relationships can be consolidated into a new Package. This removes the M1 level restrictions inherent in simple importing. The way that I see it, a "profile" of a metamodel has to be something like an undeclared superpackage; i.e. an undeclared generalization of a Package. Consider a complete metamodel to be a directed graph of concepts formed by closure of a Package and the things that it contains, inherits and depends on. Each node in the graph is a metamodel element (i.e. a Class, Association, Attribute, Operation, Package, etc.) and each link is a dependency. Now "profile" of a metamodel is a proper subgraph of the original graph; i.e. a subgraph such that all dependency links in the subgraph also end in the subgraph. It is fairly easy to see that the complete set of proper subgraphs can be organised as a DAG. In other words it is theoretically possible to express all valid profiles of a metamodel by refactoring the Package(s) with a different Package inheritance hierarchy. However, it is going to be rather difficult to implement profiles neatly. In CORBA IDL (or a typical staticly typed OO language for that matter), retro-fitting a new generalization into a class hierarchy changes the types of all of the classes. This is too disruptive to contemplate. Hence the IDL rendering of a profile would have to be handled as a new set of interfaces that has no inheritance connection with those for the original metamodel. In other words no IDL interface type substitutability. [XMI based model interchange would be possible though, possibly modulo some small changes to the XMI spec.] This leads me back to the point of my original email. Given that metamodel profiles are going to be non-substitutable at the level of the metaobject interfaces (for any statically typed OO language), do we actually want them? Won't it be better just to use the original metamodel and have tools "agree" not to use those parts of the metamodel that are outside the profile? Sridhar brought up the cost of implementing repositories for different metamodels. The same argument applies here. Since a profile's interfaces cannot be a "subtype" of the original metamodel's interfaces, there needs to be a certain amount of reworking of existing server and client code to support a profile. This is not required if the original metamodel is used. [Actually, I think this is a weak argument both against profiles, and against rev'ing the metamodel (as Sridhar used it). If the repository and tool vendors use generators to produce their server code and then access it via the MOF "specific" interfaces, the impact of rev'ing a metamodel is remarkably small. In most cases, you just need to edit the metamodel, rerun the server and interface generators and recompile the clients. Just a few minutes of CPU time ... I kid you not!!] [[ http://web4.searchbank.com/infotrac/session/516/806/25177450w3/3!xrn_4 :-) ]] -- Steve Return-Path: X-Sender: seidewitz@mail.dhr.com Date: Wed, 07 Oct 1998 10:03:30 -0400 To: boi-wg@omg.org, mof-rtf From: Ed Seidewitz Subject: Re: What is a UML "profile"? References: At 03:15 PM 10/7/98 +1000, Stephen Crawley wrote: >... > >This leads me back to the point of my original email. Given that metamodel >profiles are going to be non-substitutable at the level of the metaobject >interfaces (for any statically typed OO language), do we actually want them? >Won't it be better just to use the original metamodel and have tools "agree" >not to use those parts of the metamodel that are outside the profile? This is why I think it is best to define "profile" in terms of the original metamodel, rather than in terms of a new "derived" metamodel. The current draft BOI RFPs effectively ask for the latter. I am proposing revising them to ask for the former. > >Sridhar brought up the cost of implementing repositories for different >metamodels. The same argument applies here. Since a profile's interfaces >cannot be a "subtype" of the original metamodel's interfaces, there needs >to be a certain amount of reworking of existing server and client code >to support a profile. This is not required if the original metamodel is >used. > >[Actually, I think this is a weak argument both against profiles, and >against rev'ing the metamodel (as Sridhar used it). If the repository >and tool vendors use generators to produce their server code and then >access it via the MOF "specific" interfaces, the impact of rev'ing a >metamodel is remarkably small. In most cases, you just need to edit >the metamodel, rerun the server and interface generators and recompile >the clients. Just a few minutes of CPU time ... I kid you not!!] Actually I think that the argument is stronger than you do. Most (perhaps all) current commercial UML modeling tools are not yet based on a generated, MOF-compliant repository. Therefore I think it is unrealistic to assume that "the impact rev'ing the metamodel is...small." (Representatives from the vendor community are welcome to chime in here...) In any case, even if you are right, I don't think we want multiple repositories for separate "profile" metamodels. Most people will be modeling initially in a general purpose tool, with models stored in a general UML repository (implicitly or explicitly). What we want is a smooth path from these models to an eventual mapping to implementation. _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ Return-Path: To: Ed Seidewitz cc: boi-wg@omg.org, mof-rtf Subject: Re: What is a UML "profile"? Date: Thu, 08 Oct 1998 09:09:19 +1000 From: Stephen Crawley > At 03:15 PM 10/7/98 +1000, Stephen Crawley wrote: > >... > > > >This leads me back to the point of my original email. Given that > metamodel > >profiles are going to be non-substitutable at the level of the > metaobject > >interfaces (for any statically typed OO language), do we actually > want them? > >Won't it be better just to use the original metamodel and have > tools "agree" > >not to use those parts of the metamodel that are outside the > profile? > > This is why I think it is best to define "profile" in terms of the > original > metamodel, rather than in terms of a new "derived" metamodel. The > current > draft BOI RFPs effectively ask for the latter. I am proposing > revising them > to ask for the former. Lets be clear. You are saying that the BOI RFPs should not rev' the UML metamodel, but instead propose a subset (profile) of the metamodel to be used for "business objects" work? If so, that sounds reasonable to me. But see below. > >Sridhar brought up the cost of implementing repositories for different > >metamodels. The same argument applies here. Since a profile's interfaces > >cannot be a "subtype" of the original metamodel's interfaces, there needs > >to be a certain amount of reworking of existing server and client code > >to support a profile. This is not required if the original metamodel is > >used. > > > >[Actually, I think this is a weak argument both against profiles, and > >against rev'ing the metamodel (as Sridhar used it). If the repository > >and tool vendors use generators to produce their server code and then > >access it via the MOF "specific" interfaces, the impact of rev'ing a > >metamodel is remarkably small. In most cases, you just need to edit > >the metamodel, rerun the server and interface generators and recompile > >the clients. Just a few minutes of CPU time ... I kid you not!!] > > Actually I think that the argument is stronger than you do. Most (perhaps > all) current commercial UML modeling tools are not yet based on a > generated, MOF-compliant repository. Therefore I think it is unrealistic to > assume that "the impact rev'ing the metamodel is...small." (Representatives > from the vendor community are welcome to chime in here...) Maybe today. But I predict that this will change. > In any case, even if you are right, I don't think we want multiple > repositories for separate "profile" metamodels. Most people will be > modeling initially in a general purpose tool, with models stored in > a > general UML repository (implicitly or explicitly). What we want is a > smooth > path from these models to an eventual mapping to implementation. This argument I mostly agree with. The alternative of creating a "profile" metamodel that >>is not<< expressed as MOF super-Packages of the full UML metamodel would (IMO) be a major mistake. It would create headaches for tool interoperability and model interchange. Creating a "profile" metamodel that >>is<< expressed as a MOF super-Package does not have this problem, but it does mean that the end user wouldn't be able to use all of UML. From the perspective of the UML designers, and a lot of users this would be a BAD thing. On the other hand, the implementation footprint of a repository that implemented a "profile"- only repository would definitely be smaller, and that maps onto lower costs for the vendor and / or the user. The third alternative (that you are advocating I think) is to treat a "profile" as a subset of the metamodel with no impact on the metamodel itself. The implication is that a repository vendor must still implement the full UML metamodel to produce a compliant repository. This would be a cost for vendors and users who wanted to be in the "business objects"-only market. [The cost is in code cutting for the vendor ... unless he uses generators ... and in a larger than necessary repository / tool footprint for the user.] In short, the choice over the kind of "profile" that is specified in the BOI RFPs is a tradeoff between a variety of implementation cost and usability factors. As long as the decisions are made with these trade-offs firmly in mind, we should be OK. -- Steve Return-Path: X-Sender: dfrankel@pop.usit.net Date: Thu, 08 Oct 1998 00:56:01 -0700 To: Ed Seidewitz , boi-wg@omg.org, mof-rtf From: "David S. Frankel" Subject: Re: What is a UML "profile"? References: <199810070515.PAA20384@piglet.dstc.edu.au> All-- My responses are prefaced by [dsf]. At 10:03 AM 10/7/98 -0400, Ed Seidewitz wrote: >At 03:15 PM 10/7/98 +1000, Stephen Crawley wrote: >>... >> >>This leads me back to the point of my original email. Given that metamodel >>profiles are going to be non-substitutable at the level of the metaobject >>interfaces (for any statically typed OO language), do we actually want them? >>Won't it be better just to use the original metamodel and have tools "agree" >>not to use those parts of the metamodel that are outside the profile? > >This is why I think it is best to define "profile" in terms of the original >metamodel, rather than in terms of a new "derived" metamodel. The current >draft BOI RFPs effectively ask for the latter. I am proposing revising them >to ask for the former. [dsf] As the author of the draft RFP in question I wish to state that I've come around to Ed's point of view on this. > >> >>Sridhar brought up the cost of implementing repositories for different >>metamodels. The same argument applies here. Since a profile's interfaces >>cannot be a "subtype" of the original metamodel's interfaces, there needs >>to be a certain amount of reworking of existing server and client code >>to support a profile. This is not required if the original metamodel is >>used. >> >>[Actually, I think this is a weak argument both against profiles, and >>against rev'ing the metamodel (as Sridhar used it). If the repository >>and tool vendors use generators to produce their server code and then >>access it via the MOF "specific" interfaces, the impact of rev'ing a >>metamodel is remarkably small. In most cases, you just need to edit >>the metamodel, rerun the server and interface generators and recompile >>the clients. Just a few minutes of CPU time ... I kid you not!!] > >Actually I think that the argument is stronger than you do. Most (perhaps >all) current commercial UML modeling tools are not yet based on a >generated, MOF-compliant repository. Therefore I think it is unrealistic to >assume that "the impact rev'ing the metamodel is...small." (Representatives >from the vendor community are welcome to chime in here...) > >In any case, even if you are right, I don't think we want multiple >repositories for separate "profile" metamodels. Most people will be >modeling initially in a general purpose tool, with models stored in a >general UML repository (implicitly or explicitly). What we want is a smooth >path from these models to an eventual mapping to implementation. [dsf] I agree with Ed. So, where does that leave us in our quest to formally define "profile?" Let's cite again Ed's original take on this. I'll number the points for easy reference: 1) definition of a subset of the existing constructs of UML; 2) definition of more rigorous semantics for this subset of constructs, tailored to the needs of the community; 3) definition of standard tagged values and stereotypes to provide additional semantics tailored to the needs of the community (potentially along with special icons). We've been focusing on the first point--defining a subset. Although we haven't firmly wrapped up this point, I'd like to discuss the other points. Although I initially felt ok about these points as a general definition, I've been thinking about it and find myself needing more clarity on the difference between the semantics referenced in point 2 and point 3. Point 2 seems to be saying that new semantics need to be specified with respect to the meta-model subset's elements. Ed and I have discussed the fact, for example, that there are no invariant rules referencing AssociationEnd::AggregationKind. Point 2 could be responded to by a submitter by writing such rules in OCL to more precisely define the semantics of the different values of AggregationKind. But such invariant rules should be applicable to all associations and thus should probably belong to UML as a whole--it is hard to see why they should only be in a profile. Wouldn't they actually be part of what we've agreed is the one meta-model, since they would modify or subtype the definitions of AssociationEnd (and perhaps of Association)? So what does it mean to say that they are part of a special profile? I still think that the kind of things I mention here in regard to point 2 will need to be dealt with as part of the BOI. I'm just not sure how we fit them into the genre of a profile. Point 3 seems more straightforward--special tagged values and stereotypes for enterprise computing design probably would not belong in the meta-model as a whole since the meta-model can be used to model very different domains such as real-time and scientific phenomena, which will have their own profiles. Moreover, tagged values and stereotypes are specifically UML's mechanism for adding semantics without modifying the meta-model. --Dave >_______________________________________________________________________ >Ed Seidewitz Manager, Object Systems Product Line >DHR Technologies >(A division of OAO Technology Solutions) >10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 >Columbia MD 21044 Fax: +1.410.992.4500 >_______________________________________________________________________ > ============================= David S. Frankel Director, Advanced Architecture Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= Return-Path: X-Sender: seidewitz@mail.dhr.com Date: Thu, 08 Oct 1998 12:04:04 -0400 To: Stephen Crawley From: Ed Seidewitz Subject: Re: What is a UML "profile"? Cc: boi-wg@omg.org, mof-rtf References: At 09:09 AM 10/8/98 +1000, Stephen Crawley wrote: >... > >Lets be clear. You are saying that the BOI RFPs should not rev' the UML >metamodel, but instead propose a subset (profile) of the metamodel to be >used for "business objects" work? Yes, I believe the intent of the BOI can be achieved without revising the UML metamodel (assuming that "action semantics" revisions are already included in "version 1.5"). If any revisions are necessary, I think they can be handled in the form of well-packaged extensions that themselves become (optional) parts of the "UML standard". What I really don't want to see is another "UML for Business Objects" metamodel "derived" from the UML metamodel but still distinct from it, for many of the reasons you have pointed out. The draft RFPs seemed to call for such a distinct metamodel, and this was the source of much of the discomfort in the ADTF meeting in Seattle. > >If so, that sounds reasonable to me. But see below. > >... > >Maybe today. But I predict that this will change. Eventually. > >> In any case, even if you are right, I don't think we want multiple >> repositories for separate "profile" metamodels. Most people will be >> modeling initially in a general purpose tool, with models stored in >> a >> general UML repository (implicitly or explicitly). What we want is >> a smooth >> path from these models to an eventual mapping to implementation. > >This argument I mostly agree with. > >The alternative of creating a "profile" metamodel that >>is not<< >> expressed >as MOF super-Packages of the full UML metamodel would (IMO) be a >major mistake. It would create headaches for tool interoperability >> and >model interchange. > >Creating a "profile" metamodel that >>is<< expressed as a MOF >> super-Package >does not have this problem, but it does mean that the end user >> wouldn't >be able to use all of UML. From the perspective of the UML >> designers, >and a lot of users this would be a BAD thing. On the other hand, the >implementation footprint of a repository that implemented a >> "profile"- >only repository would definitely be smaller, and that maps onto lower >> >costs for the vendor and / or the user. > >The third alternative (that you are advocating I think) is to treat a >> >"profile" as a subset of the metamodel with no impact on the >> metamodel >itself. The implication is that a repository vendor must still >implement the full UML metamodel to produce a compliant repository. >This would be a cost for vendors and users who wanted to be in the >"business objects"-only market. [The cost is in code cutting for the >vendor ... unless he uses generators ... and in a larger than >> necessary >repository / tool footprint for the user.] My question is whether there is really a viable market for a restricted "UML for Business Objects" repository, anyway? There is no reason why the analysis and design for business objects should not take advantage of the full UML, just like any other object-oriented modeling effort. Indeed, what will be useful in these cases are actually business-object "extensions" to UML (in the form of stereotypes and tagged values) rather than restrictions of the metamodel. The restrictions only become important later, when we are making implementation-oriented decisions to allow an automated mapping. If the restricted metamodel is "UML derived" anyway, I don't see the need for a separate repository to enable this mapping. (Note that the situation with BOCA was different, in my opinion. I see BOCA as raising the semantic level of the implementation-mapping *target*, so that the mapping from design was more direct. This is why it made sense to build the BOCA metamodel up from IDL. I don't think the converse, "building it down" from UML, makes sense.) > >In short, the choice over the kind of "profile" that is specified in >the BOI RFPs is a tradeoff between a variety of implementation cost >and usability factors. As long as the decisions are made with these >trade-offs firmly in mind, we should be OK. Agreed. _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ Return-Path: X-Sender: seidewitz@mail.dhr.com Date: Thu, 08 Oct 1998 17:53:05 -0400 To: boi-wg@omg.org, mof-rtf From: Ed Seidewitz Subject: Re: What is a UML "profile"? References: <1304368286-606371793@mail.dhr.com> <199810070515.PAA20384@piglet.dstc.edu.au> At 12:56 AM 10/8/98 -0700, David S. Frankel wrote: >... >So, where does that leave us in our quest to formally define "profile?" >Let's cite again Ed's original take on this. I'll number the points for >easy reference: > >1) definition of a subset of the existing constructs of UML; > >2) definition of more rigorous semantics for this subset of constructs, >tailored to the needs of the community; > >3) definition of standard tagged values and stereotypes to provide >additional semantics tailored to the needs of the community (potentially >along with special icons). > >We've been focusing on the first point--defining a subset. Although we >haven't firmly wrapped up this point, I'd like to discuss the other points. > >Although I initially felt ok about these points as a general definition, >I've been thinking about it and find myself needing more clarity on the >difference between the semantics referenced in point 2 and point 3. > >Point 2 seems to be saying that new semantics need to be specified with >respect to the meta-model subset's elements. Ed and I have discussed the >fact, for example, that there are no invariant rules referencing >AssociationEnd::AggregationKind. Point 2 could be responded to by a >submitter by writing such rules in OCL to more precisely define the >semantics of the different values of AggregationKind. But such invariant >rules should be applicable to all associations and thus should probably >belong to UML as a whole--it is hard to see why they should only be in a >profile. Wouldn't they actually be part of what we've agreed is the one >meta-model, since they would modify or subtype the definitions of >AssociationEnd (and perhaps of Association)? So what does it mean to say >that they are part of a special profile? This is a good question. Let me try to be clearer on what I was trying to get at with point 2 above. The substantive sections of the UML Semantics document each have three major subsections: o Abstract Syntax. This defines the structural class model for some part of the UML metamodel. o Well-formedness Rules. This specifies the additional constraints (mostly as OCL rules) that must be satisfied by any "well-formed" set of instances of the classes given in the abstract syntax. o Semantics. This defines the actual semantics, that is the "meaning" of a well-formed set of instances as given by the abstract syntax and the well-formedness rules. My point 2 was really targeted at the "semantics" subsection more than the "well-formedness" subsections. The real UML semantics (i.e., the "meaning" of UML constructs) are not actually defined in a rigorous, formal way but are simply described in text. By intention some semantic issues (particularly dealing with behavioral dynamics) are left somewhat ambiguous. What I was trying to get at was that a profile might provide a tighter definition of the meaning of well-formed UML constructs (like the semantics of state machines or the meaning of "active object" or the implications of aggregation), without altering what it means for these constructs to be well-formed in the first place. If the desire actually is, however, to require additional constraints on the use of UML constructs, then I think the best way to do this is via stereotypes. The constraints associated with the stereotype (which could be specified in OCL) would then effectively become additional well-formedness rules that would need to be enforced on any construct tagged with the stereotype. I will admit, though, that it would be useful in many (most?) cases to also use stereotypes to tag that a general UML construct is being interpreted with profile-tailored semantics (as in point 2), even if there are know additional well-formedness constraints. So the line between point 2 and point 3 may be a bit blurred. Nevertheless, I think it still makes sense to have them as distinct points in the definition of a "profile". _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ Return-Path: X-Sender: dfrankel@pop.usit.net Date: Thu, 08 Oct 1998 15:51:21 -0700 To: boi-wg@omg.org, mof-rtf From: "David S. Frankel" Subject: Re: What is a UML "profile"? References: <1304368286-606371793@mail.dhr.com> <199810070515.PAA20384@piglet.dstc.edu.au> Ed-- My comments are in-line. My paragraphs are prefaced with [dsf]. At 05:53 PM 10/8/98 -0400, Ed Seidewitz wrote: >At 12:56 AM 10/8/98 -0700, David S. Frankel wrote: >>... >>So, where does that leave us in our quest to formally define "profile?" >>Let's cite again Ed's original take on this. I'll number the points for >>easy reference: >> >>1) definition of a subset of the existing constructs of UML; >> >>2) definition of more rigorous semantics for this subset of constructs, >>tailored to the needs of the community; >> >>3) definition of standard tagged values and stereotypes to provide >>additional semantics tailored to the needs of the community (potentially >>along with special icons). >> >>We've been focusing on the first point--defining a subset. Although we >>haven't firmly wrapped up this point, I'd like to discuss the other points. >> >>Although I initially felt ok about these points as a general definition, >>I've been thinking about it and find myself needing more clarity on the >>difference between the semantics referenced in point 2 and point 3. >> >>Point 2 seems to be saying that new semantics need to be specified with >>respect to the meta-model subset's elements. Ed and I have discussed the >>fact, for example, that there are no invariant rules referencing >>AssociationEnd::AggregationKind. Point 2 could be responded to by a >>submitter by writing such rules in OCL to more precisely define the >>semantics of the different values of AggregationKind. But such invariant >>rules should be applicable to all associations and thus should probably >>belong to UML as a whole--it is hard to see why they should only be in a >>profile. Wouldn't they actually be part of what we've agreed is the one >>meta-model, since they would modify or subtype the definitions of >>AssociationEnd (and perhaps of Association)? So what does it mean to say >>that they are part of a special profile? > >This is a good question. Let me try to be clearer on what I was trying to >get at with point 2 above. > >The substantive sections of the UML Semantics document each have three >major subsections: > >o Abstract Syntax. This defines the structural class model for some part of >the UML metamodel. > >o Well-formedness Rules. This specifies the additional constraints (mostly >as OCL rules) that must be satisfied by any "well-formed" set of instances >of the classes given in the abstract syntax. > >o Semantics. This defines the actual semantics, that is the "meaning" of a >well-formed set of instances as given by the abstract syntax and the >well-formedness rules. > >My point 2 was really targeted at the "semantics" subsection more than the >"well-formedness" subsections. > >The real UML semantics (i.e., the "meaning" of UML constructs) are not >actually defined in a rigorous, formal way but are simply described in >text. By intention some semantic issues (particularly dealing with >behavioral dynamics) are left somewhat ambiguous. What I was trying to get >at was that a profile might provide a tighter definition of the meaning of >well-formed UML constructs (like the semantics of state machines or the >meaning of "active object" or the implications of aggregation), without >altering what it means for these constructs to be well-formed in the first >place. [dsf] I see where the gap in communication on this occurred. When I speak of semantics, I think of formally declared semantics, not free-form text. [dsf] I can't understand why the semantics would intentionally be left ambiguous. In particular, a lot is known (see the ISO's General Relationship Model and Information Modeling by Haim Kilov and James Ross) about how to precisely declare the invariant rules of basic types of associations and how to formally declare the constraints imposed on association participants. To achieve interoperability at the level of business semantics and not just signature interoperability, these rules must be declared formally. OCL should be quite suitable for this purpose. [dsf] I realize that we will not be able to rid ourselves of the need for some free-formed text in specifications, both of meta-models and of models. However, we can reduce our dependence on it substantially. [dsf] My comments about point 2 were made in this context. > >If the desire actually is, however, to require additional constraints on >the use of UML constructs, then I think the best way to do this is via >stereotypes. The constraints associated with the stereotype (which could be >specified in OCL) would then effectively become additional well-formedness >rules that would need to be enforced on any construct tagged with the >stereotype. > >I will admit, though, that it would be useful in many (most?) cases to also >use stereotypes to tag that a general UML construct is being interpreted >with profile-tailored semantics (as in point 2), even if there are know >additional well-formedness constraints. So the line between point 2 and >point 3 may be a bit blurred. Nevertheless, I think it still makes sense to >have them as distinct points in the definition of a "profile". >_______________________________________________________________________ >Ed Seidewitz Manager, Object Systems Product Line >DHR Technologies <mailto:seidewitz@dhr.com> >(A division of OAO Technology Solutions) <http://www.dhr.com> >10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 >Columbia MD 21044 Fax: +1.410.992.4500 >_______________________________________________________________________ > ============================= David S. Frankel Director, Advanced Architecture Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= Return-Path: X-Sender: seidewitz@mail.dhr.com Date: Fri, 09 Oct 1998 09:05:52 -0400 To: boi-wg@omg.org, mof-rtf From: Ed Seidewitz Subject: Re: What is a UML "profile"? References: <1304253716-613262976@mail.dhr.com> <1304368286-606371793@mail.dhr.com> <199810070515.PAA20384@piglet.dstc.edu.au> At 03:51 PM 10/8/98 -0700, David S. Frankel wrote: Ed-- My comments are in-line. My paragraphs are prefaced with [dsf]. ... [dsf] I see where the gap in communication on this occurred. When I speak of semantics, I think of formally declared semantics, not free-form text. To make the confusion even worse, the entire document is entitled "UML Semantics" as well as specific subsections of the document. So does "semantics" mean the whole metamodel document, the textual semantics sections or a more formal expression of the semantics? Unfortunately, depending on the context, any of the three... [dsf] I can't understand why the semantics would intentionally be left ambiguous. In particular, a lot is known (see the ISO's General Relationship Model and Information Modeling by Haim Kilov and James Ross) about how to precisely declare the invariant rules of basic types of associations and how to formally declare the constraints imposed on association participants. To achieve interoperability at the level of business semantics and not just signature interoperability, these rules must be declared formally. OCL should be quite suitable for this purpose. The semantics were left somewhat ambiguous in some areas basically because the submitters could not agree on what the "one" interpretation should be. For example, even given such work as Kilov and Ross, there was still intense discussion on what "aggregation" meant, with the result being that people more or less agreed to disagree on its meaning. The submitters decided that, in cases of such disagreement, it was not their place to dictate one interpretation, but rather than UML should be able to accommodate different interpretations when reasonably possible. In the case of a more restricted user community, however, it should be easier to get agreement on a standard interpretation in such areas. And this agreement can be included in the profile for the community. [dsf] I realize that we will not be able to rid ourselves of the need for some free-formed text in specifications, both of meta-models and of models. However, we can reduce our dependence on it substantially. Well, yes and no. Remember that the well-formedness (OCL) rules are just that: they place constraints on the well-formedness of UML models. They do NOT specify the "meaning" of those models. To do this formally requires a more sophisticated approach, like denotational semantics (in which well-formed constructs are mapped to mathematical expressions) or operational semantics (in which well-formed constructs are mapped to instructions on a virtual machine). Gunnar Overgaard actually did a lot of work on a complete, formal denotational semantics for UML. I believe at one point this was going to be part of the UML submission, but it turned out to be too difficult to complete in time (partly because it would have required decisions on all the contentious issues). Gunnar is still working on this, though, as part of his doctoral work. _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies <mailto:seidewitz@dhr.com> (A division of OAO Technology Solutions) <http://www.dhr.com> 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ Return-Path: X-Sender: dfrankel@pop.usit.net Date: Fri, 09 Oct 1998 10:04:12 -0700 To: Ed Seidewitz , boi-wg@omg.org, mof-rtf From: "David S. Frankel" Subject: Re: What is a UML "profile"? References: <1304253716-613262976@mail.dhr.com> <1304368286-606371793@mail.dhr.com> <199810070515.PAA20384@piglet.dstc.edu.au> At 09:05 AM 10/9/98 -0400, Ed Seidewitz wrote: At 03:51 PM 10/8/98 -0700, David S. Frankel wrote: Ed-- My comments are in-line. My paragraphs are prefaced with [dsf]. ... [dsf] I see where the gap in communication on this occurred. When I speak of semantics, I think of formally declared semantics, not free-form text. To make the confusion even worse, the entire document is entitled "UML Semantics" as well as specific subsections of the document. So does "semantics" mean the whole metamodel document, the textual semantics sections or a more formal expression of the semantics? Unfortunately, depending on the context, any of the three... [dsf] I can't understand why the semantics would intentionally be left ambiguous. In particular, a lot is known (see the ISO's General Relationship Model and Information Modeling by Haim Kilov and James Ross) about how to precisely declare the invariant rules of basic types of associations and how to formally declare the constraints imposed on association participants. To achieve interoperability at the level of business semantics and not just signature interoperability, these rules must be declared formally. OCL should be quite suitable for this purpose. The semantics were left somewhat ambiguous in some areas basically because the submitters could not agree on what the "one" interpretation should be. For example, even given such work as Kilov and Ross, there was still intense discussion on what "aggregation" meant, with the result being that people more or less agreed to disagree on its meaning. The submitters decided that, in cases of such disagreement, it was not their place to dictate one interpretation, but rather than UML should be able to accommodate different interpretations when reasonably possible. In the case of a more restricted user community, however, it should be easier to get agreement on a standard interpretation in such areas. And this agreement can be included in the profile for the community. [dsf] If I understand you correctly, you're suggesting that we could, for example, model the General Relationship Model (GRM) relationships via stereotypes (and tagged values) as part of the enterprise computing profile, and bake the GRM semantics into the stereotypes' constraints. I think I could live with that if the result is reasonably elegant. [dsf] I realize that we will not be able to rid ourselves of the need for some free-formed text in specifications, both of meta-models and of models. However, we can reduce our dependence on it substantially. Well, yes and no. Remember that the well-formedness (OCL) rules are just that: they place constraints on the well-formedness of UML models. They do NOT specify the "meaning" of those models. To do this formally requires a more sophisticated approach, like denotational semantics (in which well-formed constructs are mapped to mathematical expressions) or operational semantics (in which well-formed constructs are mapped to instructions on a virtual machine). [dsf] Aren't the operational semantics covered by the Action Semantics RFP? Also, the body of known work I mentioined specifies the semantics of the association types declaratively and takes the approach that the combination of a set of constraints constitutes a declaration of meaning. The invariant rules for the various association types are viewed as more than well-formedness rules--they say something signficant about the meaning of the association. The set of pre and post conditions for an operation, taken together, can say something about the meaning. [dsf] For example, take an operation to do the end of month update to a receivables account. Preconditions could be that there are no unprocessed invoices and that the current date is the last working day of the month. Post conditions could be that the 120-day balance is moved to collections, 90-day balance is moved to 120-day balance, 60 to 90, 30 to 60, current balance to 30, and the total of newly processed invoices is moved to the current balance. All of this can be specified declaratively and, taken together, it tells you a lot about the meaning of the operation. Gunnar Overgaard actually did a lot of work on a complete, formal denotational semantics for UML. I believe at one point this was going to be part of the UML submission, but it turned out to be too difficult to complete in time (partly because it would have required decisions on all the contentious issues). Gunnar is still working on this, though, as part of his doctoral work. _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies <mailto:seidewitz@dhr.com> (A division of OAO Technology Solutions) <http://www.dhr.com> 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ ============================= David S. Frankel Director, Advanced Architecture Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= Return-Path: From: "Kilov, Haim (TS&P)" To: "'Ed Seidewitz'" , boi-wg@omg.org, mof-rtf Subject: RE: What is a UML "profile"? Date: Fri, 9 Oct 1998 13:05:55 -0400 Ed, Dave, all, see below. -Haim > -----Original Message----- > From: Ed Seidewitz [SMTP:seidewitz@dhr.com] > Sent: Friday, October 09, 1998 9:06 AM > To: boi-wg@omg.org; mof-rtf > Subject: Re: What is a UML "profile"? > > At 03:51 PM 10/8/98 -0700, David S. Frankel wrote: > [Kilov, Haim (TS&P)] ... > [dsf] I can't understand why the semantics would intentionally be > left ambiguous. In particular, a lot is known (see the ISO's General > Relationship Model and Information Modeling by Haim Kilov and James Ross) > about how to precisely declare the invariant rules of basic types of > associations and how to formally declare the constraints imposed on > association participants. To achieve interoperability at the level of > business semantics and not just signature interoperability, these rules > must be declared formally. OCL should be quite suitable for this purpose. > > > The semantics were left somewhat ambiguous in some areas basically because > the submitters could not agree on what the "one" interpretation should be. > For example, even given such work as Kilov and Ross, there was still > intense discussion on what "aggregation" meant, with the result being that > people more or less agreed to disagree on its meaning. The submitters > decided that, in cases of such disagreement, it was not their place to > dictate one interpretation, but rather than UML should be able to > accommodate different interpretations when reasonably possible. > > In the case of a more restricted user community, however, it should be > easier to get agreement on a standard interpretation in such areas. And > this agreement can be included in the profile for the community. > [Kilov, Haim (TS&P)] Well... let's separate concerns. Both GRM and "Information modeling" do not define what XXX really is (e.g., what "aggregation" really is). On the contrary: they provide invariants (and pre- and postconditions for generic operations) for generic relationships -- different and distinguishable generic constructs. Moreover, relationships between these constructs are also provided (e.g., different "composition" subtypes). Now, _names_ of these generic relationships are of no importance whatsoever (call them AAA, BBB, CCC, DDD, ... instead of "composition", "aggregation", "subtyping", ...) -- they are just abbreviations of appropriate collections of precisely specified rules. [Look at the "name" definition in RM-ODP -- it requires a context and permits synonyms!] A nice quote: "David Hilbert noted that the content of elementary (high-school) geometry does not suffer any changes if we replace the words 'point', 'line', and 'plane' by the terms 'chair', 'table', and 'bar'." [I am using it in my new book on business specifications, to be out in November.] > _______________________________________________________________________ Return-Path: X-Sender: s.tyndalebiscoe@mail.btinternet.com (Unverified) To: "Kilov, Haim (TS&P)" From: Sandy Tyndale-Biscoe Subject: RE: What is a UML "profile"? Cc: "'Ed Seidewitz'" , boi-wg@omg.org, mof-rtf Date: Tue, 13 Oct 1998 07:44:52 +0100 At 1:05 pm -0400 9/10/98, Kilov, Haim (TS&P) wrote: >A nice quote: "David Hilbert noted that the content of elementary >(high-school) geometry does not suffer any changes if we replace the words >'point', 'line', and 'plane' by the terms 'chair', 'table', and 'bar'." [I >am using it in my new book on business specifications, to be out in >November.] I'm sorry Haim, it is a nice quote but I can't let you get away with it. The weakness is that it ignores the baggage that comes with all the words we use. Of course the names are important, because that's where the meaning comes from. Ultimately it's back to Humpty Dumpty, the words meaning "wot we pays them to mean, no more, no less". This is why we conduct these discussions in English not Chinese. (I can't afford the fees Chinese words charge). Hilbert may have been able to understand the laws of elementary geometry with the names changed but an elementary high school student would not. So for Hilbert, it was only because either: 1, he could abstract out the real meaning of the words so that what was left meant something to him, or b. he was happy (as a mathematician) that they should have no meaning in reality (a view to which I believe Prof Stephen Hawking subscribes) Take your proposition to it's logical conclusion and we could discuss this without agreeing on the meaning of any of the words we use, which are only labels for concepts where we share some understanding. And such a discussion would be legitimately described as "noise". But we are actually in the real world, and getting back to where this thread comes from (modelling business objects) we have to express our models and meta models in terms that we can all agree to with reasonable confidence that we are all meaning the same thing. The distinctions between weak and strong aggregation, and the difference between them and composition are crucial to modellers trying to understand, and obtain agreement to, the things that are going on in a business, and what role a machine may take in that business. Interesting question - what was Hilbert's native language? just starting an argument ... Sandy R. Alexander (Sandy) Tyndale-Biscoe Open-IT Limited e-mail: S.TyndaleBiscoe@btinternet.com Vine Cottage phone: +44 1730 812069 West Lavington fax: +44 1730 810722 Midhurst, GU29 0EQ, UK mobile: +44 802 416867 Return-Path: From: "Kilov, Haim (TS&P)" To: "'Sandy Tyndale-Biscoe'" Cc: "'Ed Seidewitz'" , boi-wg@omg.org, mof-rtf Subject: RE: What is a UML "profile"? Date: Tue, 13 Oct 1998 10:41:27 -0400 Sandy thanks for your input. No, I don't want to take my proposition to its logical conclusion. But my point was different. I totally agree with your point below that "The distinctions between weak and strong aggregation, and the difference between them and composition are crucial to modellers trying to understand, and obtain agreement to, the things that are going on in a business, and what role a machine may take in that business." I _never_ said the distinctions were unimportant ("Information modeling", to a large extent, describes these distinctions). However, my point was that it is _not_ important how you name each of these relationships. And I can try to be somewhat more specific: the baggage that comes with words like "point" and "line" is quite different from the baggage that comes with words like "aggregation" and "composition". "Everyone knows" the distinction between points and lines (it has been there for "ever"); but not everyone knows the distinction between aggregation and composition. "A point" does not mean the same as "a line" to most if not all people due to some common knowledge to which you refer below. But "a composition" may well mean the same as "an aggregation" to some people [not a lot of "baggage"], and they need a precise definition to distinguish between the two. Hilbert's point (with which I agree ;-)) is that you need relationships between things to be able to distinguish between them. It is much less important for us to agree that "aggregation means XXX, while composition means YYY" than to agree that: - there are different kinds of relationships - distinctions between these kinds of relationships ought to be precisely defined (eg using invariants) - there are subtypes (in the RM-ODP meaning) of relationship types which also ought to be distinguished. Synonyms exist! So, for example, if you want to attach an abbreviation "strong composition" to the invariant XXX, and I want to attach an abbreviation "strong aggregation" to the same invariant, so be it. As long as this invariant is unambiguously understood, we are both fine. Clearly, neither of us will want to attach an abbreviation "subtyping" to this invariant since "subtyping" already has a different baggage: it is defined (eg) in RM-ODP in a different manner. (Let's reuse the "name in context" construct of RM-ODP.) -Haim PS. Will you be at OOPSLA? If yes we can continue this discussion at our workshop ;-) > -----Original Message----- > From: Sandy Tyndale-Biscoe [SMTP:s.tyndalebiscoe@btinternet.com] > Sent: Tuesday, October 13, 1998 2:45 AM > To: Kilov, Haim (TS&P) > Cc: 'Ed Seidewitz'; boi-wg@omg.org; mof-rtf > Subject: RE: What is a UML "profile"? > > At 1:05 pm -0400 9/10/98, Kilov, Haim (TS&P) wrote: > >A nice quote: "David Hilbert noted that the content of elementary > >(high-school) geometry does not suffer any changes if we replace the > words > >'point', 'line', and 'plane' by the terms 'chair', 'table', and 'bar'." > [I > >am using it in my new book on business specifications, to be out in > >November.] > > I'm sorry Haim, it is a nice quote but I can't let you get away with it. > The weakness is that it ignores the baggage that comes with all the words > we use. Of course the names are important, because that's where the > meaning > comes from. Ultimately it's back to Humpty Dumpty, the words meaning "wot > we pays them to mean, no more, no less". This is why we conduct these > discussions in English not Chinese. (I can't afford the fees Chinese words > charge). > > Hilbert may have been able to understand the laws of elementary geometry > with the names changed but an elementary high school student would not. So > for Hilbert, it was only because either: > > 1, he could abstract out the real meaning of the words so that what > was left meant something to him, or > b. he was happy (as a mathematician) that they should have no meaning > in reality (a view to which I believe Prof Stephen Hawking subscribes) > > Take your proposition to it's logical conclusion and we could discuss this > without agreeing on the meaning of any of the words we use, which are only > labels for concepts where we share some understanding. And such a > discussion would be legitimately described as "noise". > > But we are actually in the real world, and getting back to where this > thread comes from (modelling business objects) we have to express our > models and meta models in terms that we can all agree to with reasonable > confidence that we are all meaning the same thing. The distinctions > between > weak and strong aggregation, and the difference between them and > composition are crucial to modellers trying to understand, and obtain > agreement to, the things that are going on in a business, and what role a > machine may take in that business. > > Interesting question - what was Hilbert's native language? > > > > just starting an argument ... > > Sandy > > R. Alexander (Sandy) Tyndale-Biscoe Open-IT Limited > e-mail: S.TyndaleBiscoe@btinternet.com Vine Cottage > phone: +44 1730 812069 West > Lavington > fax: +44 1730 810722 Midhurst, GU29 0EQ, UK > mobile: +44 802 416867 > > Return-Path: X-Sender: seidewitz@mail.dhr.com Date: Tue, 13 Oct 1998 14:06:30 -0400 To: boi-wg@omg.org, mof-rtf From: Ed Seidewitz Subject: Re: What is a UML "profile"? References: <1304198392-616590627@mail.dhr.com> <1304253716-613262976@mail.dhr.com> <1304368286-606371793@mail.dhr.com> <199810070515.PAA20384@piglet.dstc.edu.au> At 10:04 AM 10/9/98 -0700, David S. Frankel wrote: ... [dsf] If I understand you correctly, you're suggesting that we could, for example, model the General Relationship Model (GRM) relationships via stereotypes (and tagged values) as part of the enterprise computing profile, and bake the GRM semantics into the stereotypes' constraints. I think I could live with that if the result is reasonably elegant. Yes, essentially I think this is possible and desirable (notwithstanding anything I say below!). [dsf] I realize that we will not be able to rid ourselves of the need for some free-formed text in specifications, both of meta-models and of models. However, we can reduce our dependence on it substantially. Well, yes and no. Remember that the well-formedness (OCL) rules are just that: they place constraints on the well-formedness of UML models. They do NOT specify the "meaning" of those models. To do this formally requires a more sophisticated approach, like denotational semantics (in which well-formed constructs are mapped to mathematical expressions) or operational semantics (in which well-formed constructs are mapped to instructions on a virtual machine). [dsf] Aren't the operational semantics covered by the Action Semantics RFP? Also, the body of known work I mentioined specifies the semantics of the association types declaratively and takes the approach that the combination of a set of constraints constitutes a declaration of meaning. The invariant rules for the various association types are viewed as more than well-formedness rules--they say something signficant about the meaning of the association. The set of pre and post conditions for an operation, taken together, can say something about the meaning. I agree, of course, that there are declarative approaches to semantics (and I am actually particularly partial, myself, to the pre/postcondition formalism). However, remember that we are talking about the semantics of the UML *metamodel* itself, not the semantics of a specific system modeled in UML (this is a somewhat tricky distinction, since it is the metamodel semantics that give meaning to the models of the system semantics). In the UML metamodel, OCL rules are currently used ONLY as well-formedness rules. All description of the "meaning" of UML models is given as text. Further, note that there is no dynamic behavioral model for the UML metamodel anyway. None of the metaclasses have operations or state machines. This is because the UML metamodel does NOT describe a dynamic, behavioral system. Rather, it is basically an object-oriented data-structure that defines the abstract syntax of UML models. UML models are inherently static -- they just exist in some repository. Now, the "meaning" of certain UML models (like state machines and collaborations) is, indeed, the description of the dynamic behavior of a system being modeled. The toughest part of the UML semantics is describing such "meaning", i.e., the dynamic semantics represented by essentially static UML models. And this is all done in text (take a look at, e.g., the description of the state machine semantics). When I was talking about "denotational" versus "operational" semantics, I was giving examples of different kinds of formal semantics approaches that could be used to formalize the UML descriptions of dynamic semantics. These approaches necessarily need to map the UML abstract syntax into "something else", since there is no behavioral meaning inherent in the metamodel. This "something else" is usually some mathematical formalism that is already well understood (at least by mathematicians...). For example, an operational approach is used informally already in UML 1.1 in the definition of the semantics of state machines. The behavior of a state machine is defined in terms of a "virtual machine" that maintains the set of currently "active" states and which responds in specific ways to various events. A more formal version of this would define the structure and operation of the virtual machine mathematically rather than in text, but the idea is the same. Responses to the Action Semantics RFP will provide a mechanism within UML for more precisely defining the operational semantics of a system being modeled. In doing this it is likely that the semantics of behavioral modeling within UML will likely also be made more precise in general (with the goal being the ability to "execute" UML models and to generate equivalent code). However, I think it is likely that an Action Semantics submission will still use text to define the metamodel semantics of the action modeling itself (just as the semantics of a programming language are, with very few exceptions, given in text in the language standard, though the syntax is given by a formal grammar). _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies <mailto:seidewitz@dhr.com> (A division of OAO Technology Solutions) <http://www.dhr.com> 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ Return-Path: From: "Kilov, Haim (TS&P)" To: "'Ed Seidewitz'" , boi-wg@omg.org, mof-rtf Subject: RE: What is a UML "profile"? Date: Tue, 13 Oct 1998 14:24:18 -0400 ...and where do invariants belong in this picture? -Haim > -----Original Message----- > From: Ed Seidewitz [SMTP:seidewitz@dhr.com] > Sent: Tuesday, October 13, 1998 2:07 PM > To: boi-wg@omg.org; mof-rtf > Subject: Re: What is a UML "profile"? > > At 10:04 AM 10/9/98 -0700, David S. Frankel wrote: > > ... > > > > [dsf] If I understand you correctly, you're suggesting > that > we could, for example, model the General Relationship Model (GRM) > relationships via stereotypes (and tagged values) as part of the > enterprise computing profile, and bake the GRM semantics into the > stereotypes' constraints. I think I could live with that if the > result is > reasonably elegant. > > > Yes, essentially I think this is possible and desirable > (notwithstanding > anything I say below!). > > > > > [dsf] I realize that we will not be able to > rid > ourselves of the need for some free-formed text in specifications, > both of > meta-models and of models. However, we can reduce our dependence on > it > substantially. > > > Well, yes and no. Remember that the well-formedness > (OCL) > rules are just that: they place constraints on the well-formedness > of UML > models. They do NOT specify the "meaning" of those models. To do > this > formally requires a more sophisticated approach, like denotational > semantics (in which well-formed constructs are mapped to > mathematical > expressions) or operational semantics (in which well-formed > constructs are > mapped to instructions on a virtual machine). > > > [dsf] Aren't the operational semantics covered by the Action > Semantics RFP? Also, the body of known work I mentioined specifies > the > semantics of the association types declaratively and takes the > approach > that the combination of a set of constraints constitutes a > declaration of > meaning. The invariant rules for the various association types are > viewed > as more than well-formedness rules--they say something signficant > about > the meaning of the association. The set of pre and post conditions > for an > operation, taken together, can say something about the meaning. > > > > I agree, of course, that there are declarative approaches to > semantics > (and I am actually particularly partial, myself, to the > pre/postcondition > formalism). However, remember that we are talking about the > semantics of > the UML *metamodel* itself, not the semantics of a specific system > modeled > in UML (this is a somewhat tricky distinction, since it is the > metamodel > semantics that give meaning to the models of the system > semantics). In the > UML metamodel, OCL rules are currently used ONLY as well-formedness > rules. > All description of the "meaning" of UML models is given as text. > > Further, note that there is no dynamic behavioral model for the UML > metamodel anyway. None of the metaclasses have operations or state > machines. This is because the UML metamodel does NOT describe a > dynamic, > behavioral system. Rather, it is basically an object-oriented > data-structure that defines the abstract syntax of UML models. UML > models > are inherently static -- they just exist in some repository. > > Now, the "meaning" of certain UML models (like state machines and > collaborations) is, indeed, the description of the dynamic behavior > of a > system being modeled. The toughest part of the UML semantics is > describing > such "meaning", i.e., the dynamic semantics represented by > essentially > static UML models. And this is all done in text (take a look at, > e.g., the > description of the state machine semantics). > > When I was talking about "denotational" versus "operational" > semantics, I > was giving examples of different kinds of formal semantics > approaches that > could be used to formalize the UML descriptions of dynamic > semantics. > These approaches necessarily need to map the UML abstract syntax > into > "something else", since there is no behavioral meaning inherent in > the > metamodel. This "something else" is usually some mathematical > formalism > that is already well understood (at least by mathematicians...). > > For example, an operational approach is used informally already in > UML 1.1 > in the definition of the semantics of state machines. The behavior > of a > state machine is defined in terms of a "virtual machine" that > maintains > the set of currently "active" states and which responds in specific > ways > to various events. A more formal version of this would define the > structure and operation of the virtual machine mathematically rather > than > in text, but the idea is the same. > > Responses to the Action Semantics RFP will provide a mechanism > within UML > for more precisely defining the operational semantics of a system > being > modeled. In doing this it is likely that the semantics of behavioral > modeling within UML will likely also be made more precise in general > (with > the goal being the ability to "execute" UML models and to generate > equivalent code). However, I think it is likely that an Action > Semantics > submission will still use text to define the metamodel semantics of > the > action modeling itself (just as the semantics of a programming > language > are, with very few exceptions, given in text in the language > standard, > though the syntax is given by a formal grammar). > > > > > > _______________________________________________________________________ > Ed Seidewitz Manager, Object Systems Product > Line > DHR Technologies < > > > (A division of OAO Technology Solutions) < > > > 10400 Little Patuxent Parkway, Suite 310 Voice: > +1.410.992.4000 > Columbia MD 21044 Fax: > +1.410.992.4500 > > _______________________________________________________________________ Return-Path: From: "Iyengar, Sridhar" To: boi-wg@omg.org, mof-rtf , Ed Seidewitz Subject: RE: What is a UML "profile"? Date: Tue, 13 Oct 1998 14:35:24 -0400 Please see the MOF spec for a subset of UML dynamic semantics (eg: associations, classes, packages etc.). The MOF has both the data/object structure (Packages, Classes, Associations) and some dynamic semantics in the various operations on various classes in the metamodel. Also included are patterns (in this case IDL operations) for manipulating instances of metamodels. This is a key aspect of dynamic object repositories such as Unisys UREP (www.urep.com) for a metamodel that has static and dynamic semantics. Sridhar ------------------------------------------------------------------------ --------------------------------------------- Sridhar Iyengar Unisys Fellow sridhar.iyengar@mv.unisys.com > unisys 714-380-5692 > (Pho) 25725, Jeronimo Rd 714-380-6632 (Fax) Mission Viejo, CA 92691 656-5692 (Net) ------------------------------------------------------------------------ ---------------------------------------------- > ---------- > From: Ed Seidewitz[SMTP:seidewitz@dhr.com] > Sent: Tuesday, October 13, 1998 11:06 AM > To: boi-wg@omg.org; mof-rtf > Subject: Re: What is a UML "profile"? > > At 10:04 AM 10/9/98 -0700, David S. Frankel wrote: > > ... > > > > [dsf] If I understand you correctly, you're suggesting > that we could, for example, model the General Relationship Model > (GRM) > relationships via stereotypes (and tagged values) as part of the > enterprise computing profile, and bake the GRM semantics into the > stereotypes' constraints. I think I could live with that if the > result is reasonably elegant. > > > Yes, essentially I think this is possible and desirable > (notwithstanding anything I say below!). > > > > > [dsf] I realize that we will not be able to > rid > ourselves of the need for some free-formed text in specifications, > both of meta-models and of models. However, we can reduce our > dependence on it substantially. > > > Well, yes and no. Remember that the well-formedness > (OCL) rules are just that: they place constraints on the > well-formedness of UML models. They do NOT specify the "meaning" of > those models. To do this formally requires a more sophisticated > approach, like denotational semantics (in which well-formed > constructs > are mapped to mathematical expressions) or operational semantics (in > which well-formed constructs are mapped to instructions on a virtual > machine). > > > [dsf] Aren't the operational semantics covered by the Action > Semantics RFP? Also, the body of known work I mentioined specifies > the semantics of the association types declaratively and takes the > approach that the combination of a set of constraints constitutes a > declaration of meaning. The invariant rules for the various > association types are viewed as more than well-formedness > rules--they > say something signficant about the meaning of the association. The > set of pre and post conditions for an operation, taken together, can > say something about the meaning. > > > > I agree, of course, that there are declarative approaches to > semantics > (and I am actually particularly partial, myself, to the > pre/postcondition formalism). However, remember that we are talking > about the semantics of the UML *metamodel* itself, not the semantics > of a specific system modeled in UML (this is a somewhat tricky > distinction, since it is the metamodel semantics that give meaning > to > the models of the system semantics). In the UML metamodel, OCL rules > are currently used ONLY as well-formedness rules. All description of > the "meaning" of UML models is given as text. > > Further, note that there is no dynamic behavioral model for the UML > metamodel anyway. None of the metaclasses have operations or state > machines. This is because the UML metamodel does NOT describe a > dynamic, behavioral system. Rather, it is basically an > object-oriented > data-structure that defines the abstract syntax of UML models. UML > models are inherently static -- they just exist in some repository. > > Now, the "meaning" of certain UML models (like state machines and > collaborations) is, indeed, the description of the dynamic behavior > of > a system being modeled. The toughest part of the UML semantics is > describing such "meaning", i.e., the dynamic semantics represented > by > essentially static UML models. And this is all done in text (take a > look at, e.g., the description of the state machine semantics). > > When I was talking about "denotational" versus "operational" > semantics, I was giving examples of different kinds of formal > semantics approaches that could be used to formalize the UML > descriptions of dynamic semantics. These approaches necessarily need > to map the UML abstract syntax into "something else", since there is > no behavioral meaning inherent in the metamodel. This "something > else" > is usually some mathematical formalism that is already well > understood > (at least by mathematicians...). > > For example, an operational approach is used informally already in > UML > 1.1 in the definition of the semantics of state machines. The > behavior > of a state machine is defined in terms of a "virtual machine" that > maintains the set of currently "active" states and which responds in > specific ways to various events. A more formal version of this would > define the structure and operation of the virtual machine > mathematically rather than in text, but the idea is the same. > > Responses to the Action Semantics RFP will provide a mechanism > within > UML for more precisely defining the operational semantics of a > system > being modeled. In doing this it is likely that the semantics of > behavioral modeling within UML will likely also be made more precise > in general (with the goal being the ability to "execute" UML models > and to generate equivalent code). However, I think it is likely that > an Action Semantics submission will still use text to define the > metamodel semantics of the action modeling itself (just as the > semantics of a programming language are, with very few exceptions, > given in text in the language standard, though the syntax is given > by > a formal grammar). > > > > > > ______________________________________________________________________ > _ > Ed Seidewitz Manager, Object Systems Product > Line > DHR Technologies < > mailto:seidewitz@dhr.com> > (A division of OAO Technology Solutions) < > http://www.dhr.com> > 10400 Little Patuxent Parkway, Suite 310 Voice: > +1.410.992.4000 > Columbia MD 21044 Fax: > +1.410.992.4500 > > ______________________________________________________________________ > _ > Return-Path: X-Sender: dfrankel@pop.usit.net Date: Tue, 13 Oct 1998 13:40:43 -0700 To: "Iyengar, Sridhar" , boi-wg@omg.org, mof-rtf From: "David S. Frankel" Subject: RE: What is a UML "profile"? All-- I interpret Sridhar's remarks to mean that, since UML is a MOF-compliant meta-model, the meta-objects that represent a particular UML model defined at M1 expose interfaces that have operations. Some of the operations are inherited from the MOF Reflective package and some are generated by applying the MOF-IDL mapping to the UML meta-model. Another interesting point is that many of the well-formedness rules (which are written in OCL) for the UML meta-model define "additional operations" defined in OCL and referenced by the OCL well-formedness expressions. The additional operations don't show up as instances of MOF Operation in the MOF-generated IDL for the UML meta-model. Thus, the meta-objects aren't required to implement the methods directly. These additional operations, are excellent candidates for eventually being promoted to full-fledged operations for the metaclasses they modify. The OCL that defines them could be re-framed as pre & post conditions. However, let's put that aside because I have a more immediately important question that this raises. Could a UML profile contain additional well-formedness rules and, with it, "additional operations?" These rules/additional operations should theoretically propagate to the MOF-generated IDL as instances of MOF Constraint, but the IDL mapping for MOF Constraint propagates only the name of the Constraint, not the expression or the relationship of the expression to other MOF ModelElements. Thus, the IDL generated for these rules/additional operations should be well-isolated as a set of leaf nodes in the IDL hierarchy--that is, this IDL does not reference other interfaces. It should thus be feasible to make support of extra rules/additional operations optional based on whether the profile is supported. In this fashion, additional invariants and operations could be defined as part of the profile with a strictly limited impact on the structure of repository meta-objects. (To address Haim's question about where invariants fit in in the definition of the UML meta-model: I view the well-formedness rules defined in the UML meta-model spec as tightly-focused invariants and see no reason why some of them cannot be somewhat more general, but still precisely specified, invariant rules.) A footnote: The UML specification does not appear to correctly declare the well-formedness rules as instances of MOF Constraint because names for the Constraints are not supplied. A MOF Constraint is a MOF ModelElement and thus must have a name. This is all the more important in light of the fact I mentioned above that the MOF-IDL mapping for MOF Constraint propagates only the name. --Dave At 02:35 PM 10/13/98 -0400, Iyengar, Sridhar wrote: >Please see the MOF spec for a subset of UML dynamic semantics (eg: >associations, classes, packages etc.). > >The MOF has both the data/object structure (Packages, Classes, >Associations) and some dynamic semantics in the various operations on >various classes in the metamodel. Also included are patterns (in this >case IDL operations) for manipulating instances of metamodels. > >This is a key aspect of dynamic object repositories such as Unisys UREP >(www.urep.com) for a metamodel that has static and dynamic semantics. >Sridhar >------------------------------------------------------------------------ >--------------------------------------------- >Sridhar Iyengar >Unisys Fellow >sridhar.iyengar@mv.unisys.com >> unisys 714-380-5692 >> (Pho) >25725, Jeronimo Rd 714-380-6632 >(Fax) >Mission Viejo, CA 92691 656-5692 >(Net) >------------------------------------------------------------------------ >---------------------------------------------- > >> ---------- >> From: Ed Seidewitz[SMTP:seidewitz@dhr.com] >> Sent: Tuesday, October 13, 1998 11:06 AM >> To: boi-wg@omg.org; mof-rtf >> Subject: Re: What is a UML "profile"? >> >> At 10:04 AM 10/9/98 -0700, David S. Frankel wrote: >> >> ... >> >> >> >> [dsf] If I understand you correctly, you're suggesting >> that we could, for example, model the General Relationship Model (GRM) >> relationships via stereotypes (and tagged values) as part of the >> enterprise computing profile, and bake the GRM semantics into the >> stereotypes' constraints. I think I could live with that if the >> result is reasonably elegant. >> >> >> Yes, essentially I think this is possible and desirable >> (notwithstanding anything I say below!). >> >> >> >> >> [dsf] I realize that we will not be able to rid >> ourselves of the need for some free-formed text in specifications, >> both of meta-models and of models. However, we can reduce our >> dependence on it substantially. >> >> >> Well, yes and no. Remember that the well-formedness >> (OCL) rules are just that: they place constraints on the >> well-formedness of UML models. They do NOT specify the "meaning" of >> those models. To do this formally requires a more sophisticated >> approach, like denotational semantics (in which well-formed constructs >> are mapped to mathematical expressions) or operational semantics (in >> which well-formed constructs are mapped to instructions on a virtual >> machine). >> >> >> [dsf] Aren't the operational semantics covered by the Action >> Semantics RFP? Also, the body of known work I mentioined specifies >> the semantics of the association types declaratively and takes the >> approach that the combination of a set of constraints constitutes a >> declaration of meaning. The invariant rules for the various >> association types are viewed as more than well-formedness rules--they >> say something signficant about the meaning of the association. The >> set of pre and post conditions for an operation, taken together, can >> say something about the meaning. >> >> >> >> I agree, of course, that there are declarative approaches to >> semantics >> (and I am actually particularly partial, myself, to the >> pre/postcondition formalism). However, remember that we are talking >> about the semantics of the UML *metamodel* itself, not the >> semantics >> of a specific system modeled in UML (this is a somewhat tricky >> distinction, since it is the metamodel semantics that give meaning >> to >> the models of the system semantics). In the UML metamodel, OCL >> rules >> are currently used ONLY as well-formedness rules. All description >> of >> the "meaning" of UML models is given as text. >> >> Further, note that there is no dynamic behavioral model for the UML >> metamodel anyway. None of the metaclasses have operations or state >> machines. This is because the UML metamodel does NOT describe a >> dynamic, behavioral system. Rather, it is basically an >> object-oriented >> data-structure that defines the abstract syntax of UML models. UML >> models are inherently static -- they just exist in some repository. >> >> Now, the "meaning" of certain UML models (like state machines and >> collaborations) is, indeed, the description of the dynamic behavior >> of >> a system being modeled. The toughest part of the UML semantics is >> describing such "meaning", i.e., the dynamic semantics represented >> by >> essentially static UML models. And this is all done in text (take a >> look at, e.g., the description of the state machine semantics). >> >> When I was talking about "denotational" versus "operational" >> semantics, I was giving examples of different kinds of formal >> semantics approaches that could be used to formalize the UML >> descriptions of dynamic semantics. These approaches necessarily >> need >> to map the UML abstract syntax into "something else", since there >> is >> no behavioral meaning inherent in the metamodel. This "something >> else" >> is usually some mathematical formalism that is already well >> understood >> (at least by mathematicians...). >> >> For example, an operational approach is used informally already in >> UML >> 1.1 in the definition of the semantics of state machines. The >> behavior >> of a state machine is defined in terms of a "virtual machine" that >> maintains the set of currently "active" states and which responds >> in >> specific ways to various events. A more formal version of this >> would >> define the structure and operation of the virtual machine >> mathematically rather than in text, but the idea is the same. >> >> Responses to the Action Semantics RFP will provide a mechanism >> within >> UML for more precisely defining the operational semantics of a >> system >> being modeled. In doing this it is likely that the semantics of >> behavioral modeling within UML will likely also be made more >> precise >> in general (with the goal being the ability to "execute" UML models >> and to generate equivalent code). However, I think it is likely >> that >> an Action Semantics submission will still use text to define the >> metamodel semantics of the action modeling itself (just as the >> semantics of a programming language are, with very few exceptions, >> given in text in the language standard, though the syntax is given by >> a formal grammar). >> >> >> >> >> ______________________________________________________________________ >> _ >> Ed Seidewitz Manager, Object Systems Product >> Line >> DHR Technologies < >> mailto:seidewitz@dhr.com> >> (A division of OAO Technology Solutions) < >> http://www.dhr.com> >> 10400 Little Patuxent Parkway, Suite 310 Voice: >> +1.410.992.4000 >> Columbia MD 21044 Fax: >> +1.410.992.4500 >> ______________________________________________________________________ >> _ >> > ============================= David S. Frankel Director, Advanced Architecture Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= Return-Path: From: "Iyengar, Sridhar" To: "Iyengar, Sridhar" , boi-wg@omg.org, mof-rtf , "David S. Frankel" Cc: Cris Kobryn Subject: RE: What is a UML "profile"? Date: Tue, 13 Oct 1998 19:15:57 -0400 See [Sri] Below for clarifications. Dave - your explanations of my cryptic comments were good. Sridhar > All-- > > I interpret Sridhar's remarks to mean that, since UML is a > MOF-compliant > meta-model, the meta-objects that represent a particular UML model > defined > at M1 expose interfaces that have operations. Some of the > operations > are > inherited from the MOF Reflective package and some are generated by > applying the MOF-IDL mapping to the UML meta-model. > > Another interesting point is that many of the well-formedness rules > (which > are written in OCL) for the UML meta-model define "additional > operations" > defined in OCL and referenced by the OCL well-formedness > expressions. > The > additional operations don't show up as instances of MOF Operation in > the > MOF-generated IDL for the UML meta-model. Thus, the meta-objects > aren't > required to implement the methods directly. > [Sri] Interestingly enough, Unisys in its implementation of UML 1.1 metamodel as a server (so UML repository objects can be manipulates, shared versuioned etc.) DID expose these OCL statements (whenever it made sense) as EXPLICIT operations on the appropriate UML metaclasses. We believe this is a key steps to including these constraints and enforcing them in the metamodel server - this way we save all tools a major headache. Interestingly enough, we have added these 'additional operations's to the metamodel they DO show up as IDL interfaces. > These additional operations, are excellent candidates for eventually > being > promoted to full-fledged operations for the metaclasses they modify. > The > OCL that defines them could be re-framed as pre & post conditions. > [Sri] I strongly recommend this step - definitely for any one building repositories and tools that need to support sharing and concurrency control across teams. > However, let's put that aside because I have a more immediately > important > question that this raises. Could a UML profile contain additional > well-formedness rules and, with it, "additional operations?" These > rules/additional operations should theoretically propagate to the > MOF-generated IDL as instances of MOF Constraint, but the IDL > mapping > for > MOF Constraint propagates only the name of the Constraint, not the > expression or the relationship of the expression to other MOF > ModelElements. > [Sri] Any constraints in the NORMATIVE metamodel will be handled by > MOF (and also XMI) automatically as defined in the MOF-IDL mapping rules > in the MOF spec. > Thus, the IDL generated for these rules/additional > operations should be well-isolated as a set of leaf nodes in the IDL > hierarchy--that is, this IDL does not reference other interfaces. > It > should thus be feasible to make support of extra rules/additional > operations optional based on whether the profile is supported. > > In this fashion, additional invariants and operations could be > defined > as > part of the profile with a strictly limited impact on the structure > of > repository meta-objects. (To address Haim's question about where > invariants fit in in the definition of the UML meta-model: I view > the > well-formedness rules defined in the UML meta-model spec as > tightly-focused > invariants and see no reason why some of them cannot be somewhat > more > general, but still precisely specified, invariant rules.) > > A footnote: The UML specification does not appear to correctly > declare > the > well-formedness rules as instances of MOF Constraint because names > for > the > Constraints are not supplied. A MOF Constraint is a MOF > ModelElement > and > thus must have a name. This is all the more important in light of > the > fact > I mentioned above that the MOF-IDL mapping for MOF Constraint > propagates > only the name. > [Sri] The UML and MOF RTFs (and soon XMI RTF's) need to work together > to solve this problem as soon as practical - defintely before April 1999 when they will coincidentally finish their current RTF cycle. We will also have XMI experience to factor in. > --Dave > > At 02:35 PM 10/13/98 -0400, Iyengar, Sridhar wrote: > >Please see the MOF spec for a subset of UML dynamic semantics (eg: > >associations, classes, packages etc.). > > > >The MOF has both the data/object structure (Packages, Classes, > >Associations) and some dynamic semantics in the various operations > on > >various classes in the metamodel. Also included are patterns (in > this > >case IDL operations) for manipulating instances of metamodels. > > > >This is a key aspect of dynamic object repositories such as Unisys > UREP > >(www.urep.com) for a metamodel that has static and dynamic > semantics. > > >Sridhar > > >--------------------------------------------------------------------- > --- > >--------------------------------------------- > >Sridhar Iyengar > >Unisys Fellow > >sridhar.iyengar@mv.unisys.com > >> unisys > 714-380-5692 > >> (Pho) > >25725, Jeronimo Rd 714-380-6632 > >(Fax) > >Mission Viejo, CA 92691 656-5692 > >(Net) > > >--------------------------------------------------------------------- > --- > >---------------------------------------------- > > > >> ---------- > >> From: Ed Seidewitz[SMTP:seidewitz@dhr.com] > >> Sent: Tuesday, October 13, 1998 11:06 AM > >> To: boi-wg@omg.org; mof-rtf > >> Subject: Re: What is a UML "profile"? > >> > >> At 10:04 AM 10/9/98 -0700, David S. Frankel wrote: > >> > >> ... > >> > >> > >> > >> [dsf] If I understand you correctly, you're suggesting > >> that we could, for example, model the General Relationship Model > (GRM) > >> relationships via stereotypes (and tagged values) as part of the > >> enterprise computing profile, and bake the GRM semantics into the > >> stereotypes' constraints. I think I could live with that if the > >> result is reasonably elegant. > >> > >> > >> Yes, essentially I think this is possible and desirable > >> (notwithstanding anything I say below!). > >> > >> > >> > >> > >> [dsf] I realize that we will not be able to > rid > >> ourselves of the need for some free-formed text in > specifications, > >> both of meta-models and of models. However, we can reduce our > >> dependence on it substantially. > >> > >> > >> Well, yes and no. Remember that the well-formedness > >> (OCL) rules are just that: they place constraints on the > >> well-formedness of UML models. They do NOT specify the "meaning" > of > >> those models. To do this formally requires a more sophisticated > >> approach, like denotational semantics (in which well-formed > constructs > >> are mapped to mathematical expressions) or operational semantics > (in > >> which well-formed constructs are mapped to instructions on a > virtual > >> machine). > >> > >> > >> [dsf] Aren't the operational semantics covered by the Action > >> Semantics RFP? Also, the body of known work I mentioined > specifies > >> the semantics of the association types declaratively and takes > the > >> approach that the combination of a set of constraints constitutes > a > >> declaration of meaning. The invariant rules for the various > >> association types are viewed as more than well-formedness > rules--they > >> say something signficant about the meaning of the association. > The > >> set of pre and post conditions for an operation, taken together, > can > > >> say something about the meaning. > >> > >> > >> > >> I agree, of course, that there are declarative approaches to > semantics > >> (and I am actually particularly partial, myself, to the > >> pre/postcondition formalism). However, remember that we are > talking > >> about the semantics of the UML *metamodel* itself, not the > semantics > >> of a specific system modeled in UML (this is a somewhat tricky > >> distinction, since it is the metamodel semantics that give > meaning > to > >> the models of the system semantics). In the UML metamodel, OCL > rules > >> are currently used ONLY as well-formedness rules. All description > of > >> the "meaning" of UML models is given as text. > >> > >> Further, note that there is no dynamic behavioral model for the > UML > >> metamodel anyway. None of the metaclasses have operations or > state > >> machines. This is because the UML metamodel does NOT describe a > >> dynamic, behavioral system. Rather, it is basically an > object-oriented > >> data-structure that defines the abstract syntax of UML > models. UML > >> models are inherently static -- they just exist in some > repository. > >> > >> Now, the "meaning" of certain UML models (like state machines and > >> collaborations) is, indeed, the description of the dynamic > behavior > of > >> a system being modeled. The toughest part of the UML semantics is > >> describing such "meaning", i.e., the dynamic semantics > represented > by > >> essentially static UML models. And this is all done in text (take > a > >> look at, e.g., the description of the state machine semantics). > >> > >> When I was talking about "denotational" versus "operational" > >> semantics, I was giving examples of different kinds of formal > >> semantics approaches that could be used to formalize the UML > >> descriptions of dynamic semantics. These approaches necessarily > need > >> to map the UML abstract syntax into "something else", since there > is > >> no behavioral meaning inherent in the metamodel. This "something > else" > >> is usually some mathematical formalism that is already well > understood > >> (at least by mathematicians...). > >> > >> For example, an operational approach is used informally already > in > UML > >> 1.1 in the definition of the semantics of state machines. The > behavior > >> of a state machine is defined in terms of a "virtual machine" > that > >> maintains the set of currently "active" states and which responds > in > >> specific ways to various events. A more formal version of this > would > >> define the structure and operation of the virtual machine > >> mathematically rather than in text, but the idea is the same. > >> > >> Responses to the Action Semantics RFP will provide a mechanism > within > >> UML for more precisely defining the operational semantics of a > system > >> being modeled. In doing this it is likely that the semantics of > >> behavioral modeling within UML will likely also be made more > precise > >> in general (with the goal being the ability to "execute" UML > models > >> and to generate equivalent code). However, I think it is likely > that > >> an Action Semantics submission will still use text to define the > >> metamodel semantics of the action modeling itself (just as the > >> semantics of a programming language are, with very few > exceptions, > > >> given in text in the language standard, though the syntax is > given > by > >> a formal grammar). > >> > >> > >> > >> > >> > > ______________________________________________________________________ > >> _ > >> Ed Seidewitz Manager, Object Systems > Product > >> Line > >> DHR Technologies < > >> mailto:seidewitz@dhr.com> > >> (A division of OAO Technology Solutions) < > >> http://www.dhr.com> > >> 10400 Little Patuxent Parkway, Suite 310 Voice: > >> +1.410.992.4000 > >> Columbia MD 21044 Fax: > >> +1.410.992.4500 > >> > > ______________________________________________________________________ > >> _ > >> > > > ============================= > David S. Frankel > Director, Advanced Architecture > Genesis Development Corporation > 741 Santiago Court > Chico, CA 95973-8781 U.S.A. > > > http://www.gendev.com > dfrankel@gendev.com > +1-530-893-1100 phone > +1-530-893-1153 fax > ============================= > Return-Path: X-Sender: dfrankel@pop.usit.net Date: Tue, 13 Oct 1998 18:32:50 -0700 To: boi-wg@omg.org, mof-rtf From: "David S. Frankel" Subject: RE: What is a UML "profile"? Cc: Cris Kobryn Sridhar-- Thanks for your clarifications. Regarding the UML RTF and MOF RTF issues: I would also like to see it possible to indicate that an instance of a MOF Constraint is a pre-condition or post-condition when the constrainedElement is a MOF Operation. Let's not forget, however, the main question I asked, which is can we say that new well-formedness rules can be part of a UML profile? (where well-formedness rules include additional OCL operations in keeping with the UML meta-model specification style, as discussed previously) If the answer is yes, perhaps we can now attempt a generic definition of a profile of a MOF-compliant meta-model, something Sridhar asked about a while back How about this (if we agree we can try to define it more formally): A profile is a subset (not necessarily a proper subset) of a meta-model plus additional formal constraints on the subset (i.e. instances of MOF Constraint expressed in OCL) and additional free-text semantics about the subset. A UML profile is a specialization of a generic profile, in that it also can contain UML stereotypes and tagged values. New well-formedness rules (with the "additional operations") are just an instance of a generic profile's additional formal constraints. A question is: where would the formal definition of a MOF profile and a UML profile reside? It would seem to me that the best place would be in the output of the MOF RTF and UML RTF, respectively. I'd like to attempt to rewrite BOI RFP 1 with the three-week rule deadline looming at the end of this week. I don't think we will be able to issue at Burlingame, but it would be nice to make the 3-week rule just in case. I have time to work on this tomorrow (Wednesday) but am tied up the rest of the week. Therefore, if readers could give me feedback on these definitions, I'd appreciate it. If there seems to be consensus then I'll frame the RFP to call for the items that would be in a UML profile as defined here. However, I won't formally define a generic and UML profile in the RFP. The MOF and UML RTFs can take the promulgation of normative definitions of profiles up in its own time cycle. Feedback please! :) Thanks. --Dave At 07:15 PM 10/13/98 -0400, Iyengar, Sridhar wrote: >See [Sri] Below for clarifications. > >Dave - your explanations of my cryptic comments were good. >Sridhar > >> All-- >> >> I interpret Sridhar's remarks to mean that, since UML is a >> MOF-compliant >> meta-model, the meta-objects that represent a particular UML model >> defined >> at M1 expose interfaces that have operations. Some of the operations >> are >> inherited from the MOF Reflective package and some are generated by >> applying the MOF-IDL mapping to the UML meta-model. >> >> Another interesting point is that many of the well-formedness rules >> (which >> are written in OCL) for the UML meta-model define "additional >> operations" >> defined in OCL and referenced by the OCL well-formedness expressions. >> The >> additional operations don't show up as instances of MOF Operation in >> the >> MOF-generated IDL for the UML meta-model. Thus, the meta-objects >> aren't >> required to implement the methods directly. >> >[Sri] Interestingly enough, Unisys in its implementation of UML 1.1 >metamodel as a server (so UML repository objects can be manipulates, >shared versuioned etc.) DID expose these OCL statements (whenever it >made sense) as EXPLICIT operations on the appropriate UML metaclasses. >We believe this is a key steps to including these constraints and >enforcing them in the metamodel server - this way we save all tools a >major headache. > >Interestingly enough, we have added these 'additional operations's to >the metamodel they DO show up as IDL interfaces. > >> These additional operations, are excellent candidates for eventually >> being >> promoted to full-fledged operations for the metaclasses they modify. >> The >> OCL that defines them could be re-framed as pre & post conditions. >> >[Sri] I strongly recommend this step - definitely for any one building >repositories and tools that need to support sharing and concurrency >control across teams. > >> However, let's put that aside because I have a more immediately >> important >> question that this raises. Could a UML profile contain additional >> well-formedness rules and, with it, "additional operations?" These >> rules/additional operations should theoretically propagate to the >> MOF-generated IDL as instances of MOF Constraint, but the IDL mapping >> for >> MOF Constraint propagates only the name of the Constraint, not the >> expression or the relationship of the expression to other MOF >> ModelElements. >> >[Sri] Any constraints in the NORMATIVE metamodel will be handled by >> MOF >(and also XMI) automatically as defined in the MOF-IDL mapping rules >> in >the MOF spec. > >> Thus, the IDL generated for these rules/additional >> operations should be well-isolated as a set of leaf nodes in the >> IDL >> hierarchy--that is, this IDL does not reference other interfaces. >> It >> should thus be feasible to make support of extra rules/additional >> operations optional based on whether the profile is supported. >> >> In this fashion, additional invariants and operations could be >> defined >> as >> part of the profile with a strictly limited impact on the structure >> of >> repository meta-objects. (To address Haim's question about where >> invariants fit in in the definition of the UML meta-model: I view >> the >> well-formedness rules defined in the UML meta-model spec as >> tightly-focused >> invariants and see no reason why some of them cannot be somewhat >> more >> general, but still precisely specified, invariant rules.) >> >> A footnote: The UML specification does not appear to correctly >> declare >> the >> well-formedness rules as instances of MOF Constraint because names >> for >> the >> Constraints are not supplied. A MOF Constraint is a MOF >> ModelElement >> and >> thus must have a name. This is all the more important in light of >> the >> fact >> I mentioned above that the MOF-IDL mapping for MOF Constraint >> propagates >> only the name. >> >[Sri] The UML and MOF RTFs (and soon XMI RTF's) need to work together >> to >solve this problem as soon as practical - defintely before April 1999 >when they will coincidentally finish their current RTF cycle. We >> will >also have XMI experience to factor in. > >> --Dave >> >> At 02:35 PM 10/13/98 -0400, Iyengar, Sridhar wrote: >> >Please see the MOF spec for a subset of UML dynamic semantics (eg: >> >associations, classes, packages etc.). >> > >> >The MOF has both the data/object structure (Packages, Classes, >> >Associations) and some dynamic semantics in the various operations >> on >> >various classes in the metamodel. Also included are patterns (in >> this >> >case IDL operations) for manipulating instances of metamodels. >> > >> >This is a key aspect of dynamic object repositories such as Unisys >> UREP >> >(www.urep.com) for a metamodel that has static and dynamic >> semantics. >> >> >Sridhar >> >> >--------------------------------------------------------------------- >> --- >> >--------------------------------------------- >> >Sridhar Iyengar >> >Unisys Fellow >> >sridhar.iyengar@mv.unisys.com >> >> unisys >> 714-380-5692 >> >> (Pho) >> >25725, Jeronimo Rd 714-380-6632 >> >(Fax) >> >Mission Viejo, CA 92691 656-5692 >> >(Net) >> >> >--------------------------------------------------------------------- >> --- >> >---------------------------------------------- >> > >> >> ---------- >> >> From: Ed Seidewitz[SMTP:seidewitz@dhr.com] >> >> Sent: Tuesday, October 13, 1998 11:06 AM >> >> To: boi-wg@omg.org; mof-rtf >> >> Subject: Re: What is a UML "profile"? >> >> >> >> At 10:04 AM 10/9/98 -0700, David S. Frankel wrote: >> >> >> >> ... >> >> >> >> >> >> >> >> [dsf] If I understand you correctly, you're suggesting >> >> that we could, for example, model the General Relationship Model >> (GRM) >> >> relationships via stereotypes (and tagged values) as part of the >> >> enterprise computing profile, and bake the GRM semantics into >> the >> >> stereotypes' constraints. I think I could live with that if the >> >> result is reasonably elegant. >> >> >> >> >> >> Yes, essentially I think this is possible and desirable >> >> (notwithstanding anything I say below!). >> >> >> >> >> >> >> >> >> >> [dsf] I realize that we will not be able to >> rid >> >> ourselves of the need for some free-formed text in >> specifications, >> >> both of meta-models and of models. However, we can reduce our >> >> dependence on it substantially. >> >> >> >> >> >> Well, yes and no. Remember that the well-formedness >> >> (OCL) rules are just that: they place constraints on the >> >> well-formedness of UML models. They do NOT specify the "meaning" >> of >> >> those models. To do this formally requires a more sophisticated >> >> approach, like denotational semantics (in which well-formed >> constructs >> >> are mapped to mathematical expressions) or operational semantics >> (in >> >> which well-formed constructs are mapped to instructions on a >> virtual >> >> machine). >> >> >> >> >> >> [dsf] Aren't the operational semantics covered by the Action >> >> Semantics RFP? Also, the body of known work I mentioined >> specifies >> >> the semantics of the association types declaratively and takes >> the >> >> approach that the combination of a set of constraints >> constitutes a >> >> declaration of meaning. The invariant rules for the various >> >> association types are viewed as more than well-formedness >> rules--they >> >> say something signficant about the meaning of the association. >> The >> >> set of pre and post conditions for an operation, taken together, >> can >> >> >> say something about the meaning. >> >> >> >> >> >> >> >> I agree, of course, that there are declarative approaches to >> semantics >> >> (and I am actually particularly partial, myself, to the >> >> pre/postcondition formalism). However, remember that we are >> talking >> >> about the semantics of the UML *metamodel* itself, not the >> semantics >> >> of a specific system modeled in UML (this is a somewhat tricky >> >> distinction, since it is the metamodel semantics that give >> meaning >> to >> >> the models of the system semantics). In the UML metamodel, OCL >> rules >> >> are currently used ONLY as well-formedness rules. All >> description >> of >> >> the "meaning" of UML models is given as text. >> >> >> >> Further, note that there is no dynamic behavioral model for the >> UML >> >> metamodel anyway. None of the metaclasses have operations or >> state >> >> machines. This is because the UML metamodel does NOT describe a >> >> dynamic, behavioral system. Rather, it is basically an >> object-oriented >> >> data-structure that defines the abstract syntax of UML >> models. UML >> >> models are inherently static -- they just exist in some repository. >> >> >> >> Now, the "meaning" of certain UML models (like state machines and >> >> collaborations) is, indeed, the description of the dynamic behavior >> of >> >> a system being modeled. The toughest part of the UML semantics is >> >> describing such "meaning", i.e., the dynamic semantics represented >> by >> >> essentially static UML models. And this is all done in text (take a >> >> look at, e.g., the description of the state machine semantics). >> >> >> >> When I was talking about "denotational" versus "operational" >> >> semantics, I was giving examples of different kinds of formal >> >> semantics approaches that could be used to formalize the UML >> >> descriptions of dynamic semantics. These approaches necessarily >> need >> >> to map the UML abstract syntax into "something else", since there >> is >> >> no behavioral meaning inherent in the metamodel. This "something >> else" >> >> is usually some mathematical formalism that is already well >> understood >> >> (at least by mathematicians...). >> >> >> >> For example, an operational approach is used informally already in >> UML >> >> 1.1 in the definition of the semantics of state machines. The >> behavior >> >> of a state machine is defined in terms of a "virtual machine" that >> >> maintains the set of currently "active" states and which responds >> in >> >> specific ways to various events. A more formal version of this >> would >> >> define the structure and operation of the virtual machine >> >> mathematically rather than in text, but the idea is the same. >> >> >> >> Responses to the Action Semantics RFP will provide a mechanism >> within >> >> UML for more precisely defining the operational semantics of a >> system >> >> being modeled. In doing this it is likely that the semantics of >> >> behavioral modeling within UML will likely also be made more >> precise >> >> in general (with the goal being the ability to "execute" UML models >> >> and to generate equivalent code). However, I think it is likely >> that >> >> an Action Semantics submission will still use text to define the >> >> metamodel semantics of the action modeling itself (just as the >> >> semantics of a programming language are, with very few exceptions, >> >> >> given in text in the language standard, though the syntax is given >> by >> >> a formal grammar). >> >> >> >> >> >> >> >> >> >> >> ______________________________________________________________________ >> >> _ >> >> Ed Seidewitz Manager, Object Systems Product >> >> Line >> >> DHR Technologies < >> >> mailto:seidewitz@dhr.com> >> >> (A division of OAO Technology Solutions) < >> >> http://www.dhr.com> >> >> 10400 Little Patuxent Parkway, Suite 310 Voice: >> >> +1.410.992.4000 >> >> Columbia MD 21044 Fax: >> >> +1.410.992.4500 >> >> >> ______________________________________________________________________ >> >> _ >> >> >> > >> ============================= >> David S. Frankel >> Director, Advanced Architecture >> Genesis Development Corporation >> 741 Santiago Court >> Chico, CA 95973-8781 U.S.A. >> >> >> http://www.gendev.com >> dfrankel@gendev.com >> +1-530-893-1100 phone >> +1-530-893-1153 fax >> ============================= >> > ============================= David S. Frankel Director, Advanced Architecture Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= Return-Path: X-Sender: seidewitz@mail.dhr.com Date: Thu, 15 Oct 1998 12:43:59 -0400 To: boi-wg@omg.org, mof-rtf From: Ed Seidewitz Subject: RE: What is a UML "profile"? At 02:24 PM 10/13/98 -0400, Kilov, Haim (TS&P) wrote: >...and where do invariants belong in this picture? > >-Haim Again, it depends on whether you are talking about invariants on the metamodel or invariants on the model. An invariant implies that something remains true despite changes in state (e.g., the invariants of a class must remain true whatever the values of the attributes of an instance of the class). In UML such invariants are specified at the model level as constraints. In the UML metamodel, however, there is no explicit concept of "changing the state" in the metamodel, so there really are no invariants as such. Of course, the "state" of a model represented in a repository using the UML metamodel can change under the influence of modeling tools. It is this kind of operation that is provided by the MOF-based IDL for the UML metamodel, but these operations are NOT part of the UML Semantics definition. However, one could still, from this repository viewpoint, look at the well-formedness rules as invariants, in the sense that they must be maintained for any well-formed UML model. Even so, it is explicitly necessary for a UML tool to allow the manipulation of partial and "ill-formed" UML models, so the well-formedness rules are not really invariants, either. The well-formedness rules simply identify that subset of storable UML abstract syntax to which the semantics supplies meaning. Now, it is indeed possible for the semantics of a UML construct to implicitly place invariant constraints on a model any time the construct is used. And a stereotype can be used to do this explicitly at the model level. I think this may be closer to the sense of use of "invariants" for semantic definition that you are getting at -- but it this sense is not used in any formal way within the current UML Semantics document. _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ Return-Path: From: "Iyengar, Sridhar" To: boi-wg@omg.org, mof-rtf , Ed Seidewitz Cc: Sridhar Iyengar Subject: RE: What is a UML "profile"? Date: Thu, 15 Oct 1998 13:02:44 -0400 See [Sri] below. > At 02:24 PM 10/13/98 -0400, Kilov, Haim (TS&P) wrote: > >...and where do invariants belong in this picture? > > > >-Haim > > Again, it depends on whether you are talking about invariants on the > metamodel or invariants on the model. An invariant implies that > something > remains true despite changes in state (e.g., the invariants of a > class > must > remain true whatever the values of the attributes of an instance of > the > class). In UML such invariants are specified at the model level as > constraints. In the UML metamodel, however, there is no explicit > concept of > "changing the state" in the metamodel, so there really are no > invariants as > such. > [Sri] This actually reflects a potential problem. One of the main reasons for defining the UML metamodel (and getting it standardized at OMG) was in fact to provide a reference metamodel specification for > tool and repository vendors to build modeling, design and construction > tools for enterprise class distributed applications. If we dont at some > point (via MOF and MOF-IDL mappings a good part of this is done) make the metamodel itself more complete, we will simply have divergent interpretations and implementations (some of which is good if we want UML to be widely applicable] ! In fact - if UML invariants are good enough to be used at model level (which is an implementation of some application) why ISNT it good enough for the metamodel (which is an implementatiom of some tool or repository - ala a more abstract > systems level application? > Of course, the "state" of a model represented in a repository using > the UML > metamodel can change under the influence of modeling tools. It is > this > kind > of operation that is provided by the MOF-based IDL for the UML > metamodel, > but these operations are NOT part of the UML Semantics definition. > > [Sri] Note however these operations are directly derived from the semantics that the MOF infers from the UML meta-model! There is no magic involved. > However, > one could still, from this repository viewpoint, look at the > well-formedness rules as invariants, in the sense that they must be > maintained for any well-formed UML model. Even so, it is explicitly > necessary for a UML tool to allow the manipulation of partial and > "ill-formed" UML models, so the well-formedness rules are not really > invariants, either. The well-formedness rules simply identify that > subset > of storable UML abstract syntax to which the semantics supplies > meaning. > [Sri] A way to eat the 'cake and have it too'is to follow the approach some systems take - allow the constraint checking to be turned on or > off at a repository or package (or if you are into torture at a more granular) level. The MOF accomodates this by freezing the meta-model once it is 'well formed'. Also in XMI we have added clauses which indicate whether an incoming model has been 'verified' or not - explicitly done to allow transfer of incomplete models in early stages of design. > Now, it is indeed possible for the semantics of a UML construct to > implicitly place invariant constraints on a model any time the > construct is > used. And a stereotype can be used to do this explicitly at the > model > level. I think this may be closer to the sense of use of > "invariants" > for > semantic definition that you are getting at -- but it this sense is > not > used in any formal way within the current UML Semantics document. > > ______________________________________________________________________ > _ > Ed Seidewitz Manager, Object Systems Product > Line > DHR Technologies > > (A division of OAO Technology Solutions) > > 10400 Little Patuxent Parkway, Suite 310 Voice: > +1.410.992.4000 > Columbia MD 21044 Fax: > +1.410.992.4500 > > ______________________________________________________________________ > _ > Return-Path: X-Sender: dfrankel@pop.usit.net Date: Thu, 15 Oct 1998 10:52:43 -0700 To: Ed Seidewitz , boi-wg@omg.org, mof-rtf From: "David S. Frankel" Subject: RE: What is a UML "profile"? References: All-- My response is in-line. --David Frankel At 12:43 PM 10/15/98 -0400, Ed Seidewitz wrote: >At 02:24 PM 10/13/98 -0400, Kilov, Haim (TS&P) wrote: >>...and where do invariants belong in this picture? >> >>-Haim > >Again, it depends on whether you are talking about invariants on the >metamodel or invariants on the model. An invariant implies that something >remains true despite changes in state (e.g., the invariants of a class must >remain true whatever the values of the attributes of an instance of the >class). In UML such invariants are specified at the model level as >constraints. In the UML metamodel, however, there is no explicit concept of >"changing the state" in the metamodel, so there really are no invariants as >such. [dsf] You make a good point about the well-formedness rules being different in that partially completed models must be allowed to exist. However, the MOF models a Constraint as having an evaluation policy and one of those policies, "deferred," means that the Constraint is evaluated only when evaluation is explicitly requested via the verify operation supported by all ModelElements. Thus, a UML well-formedness rule is an instance of MOF Constraint with a deferred evaluation policy. > >Of course, the "state" of a model represented in a repository using the UML >metamodel can change under the influence of modeling tools. It is this kind >of operation that is provided by the MOF-based IDL for the UML metamodel, >but these operations are NOT part of the UML Semantics definition. However, >one could still, from this repository viewpoint, look at the >well-formedness rules as invariants, in the sense that they must be >maintained for any well-formed UML model. Even so, it is explicitly >necessary for a UML tool to allow the manipulation of partial and >"ill-formed" UML models, so the well-formedness rules are not really >invariants, either. The well-formedness rules simply identify that subset >of storable UML abstract syntax to which the semantics supplies meaning. > >Now, it is indeed possible for the semantics of a UML construct to >implicitly place invariant constraints on a model any time the construct is >used. And a stereotype can be used to do this explicitly at the model >level. I think this may be closer to the sense of use of "invariants" for >semantic definition that you are getting at -- but it this sense is not >used in any formal way within the current UML Semantics document. >_______________________________________________________________________ >Ed Seidewitz Manager, Object Systems Product Line >DHR Technologies >(A division of OAO Technology Solutions) >10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 >Columbia MD 21044 Fax: +1.410.992.4500 >_______________________________________________________________________ > ============================= David S. Frankel Director, Advanced Architecture Genesis Development Corporation 741 Santiago Court Chico, CA 95973-8781 U.S.A. http://www.gendev.com dfrankel@gendev.com +1-530-893-1100 phone +1-530-893-1153 fax ============================= Return-Path: X-Sender: seidewitz@mail.dhr.com Date: Thu, 15 Oct 1998 15:34:17 -0400 To: boi-wg@omg.org, mof-rtf From: Ed Seidewitz Subject: RE: What is a UML "profile"? References: At 01:40 PM 10/13/98 -0700, David S. Frankel wrote: >All-- > >I interpret Sridhar's remarks to mean that, since UML is a MOF-compliant >meta-model, the meta-objects that represent a particular UML model defined >at M1 expose interfaces that have operations. Some of the operations are >inherited from the MOF Reflective package and some are generated by >applying the MOF-IDL mapping to the UML meta-model. > >Another interesting point is that many of the well-formedness rules (which >are written in OCL) for the UML meta-model define "additional operations" >defined in OCL and referenced by the OCL well-formedness expressions. The >additional operations don't show up as instances of MOF Operation in the >MOF-generated IDL for the UML meta-model. Thus, the meta-objects aren't >required to implement the methods directly. The term "additional operations" is a bit misleading here. These are simply OCL shorthands and not part of the UML abstract-syntax metamodel (as currently defined, at least). That is why they don't show up in the generated IDL (I guess this is pretty much what you meant by "[they] don't show up as instances of MOF Operation..."). > >These additional operations, are excellent candidates for eventually being >promoted to full-fledged operations for the metaclasses they modify. The >OCL that defines them could be re-framed as pre & post conditions. I agree that this would be useful. In the generated IDL, such operations could be used to check on whether various well-formedness conditions are true at a certain point in time. Of course, such operations are still not state-changing operations (they are more like "derived attributes"), so they still don't introduce real dynamic behavior into the metamodel. >... > >A footnote: The UML specification does not appear to correctly declare the >well-formedness rules as instances of MOF Constraint because names for the >Constraints are not supplied. A MOF Constraint is a MOF ModelElement and >thus must have a name. This is all the more important in light of the fact >I mentioned above that the MOF-IDL mapping for MOF Constraint propagates >only the name. > This is because the UML metamodel IDL mapping does not deal with the well-formedness rules at all. I don't think these rules were really considered part of the "facility". The "facility" is based only on the abstract syntax. As I have said, the well-formedness rules are basically just there as part of the semantic definition: only well-formed models have formal "meaning" in UML, but it is still possible to notate ill-formed models. _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________