From omg-list-errors@emerald.omg.org Tue Nov 26 16:53:07 2002 Received: from escher.cs.uml.edu (escher.cs.uml.edu [129.63.16.205]) by saturn.cs.uml.edu (8.11.6/8.11.6) with ESMTP id gAQLr72325049 for ; Tue, 26 Nov 2002 16:53:07 -0500 (EST) Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by escher.cs.uml.edu (4.7.0.120) with ESMTP id for ; Tue, 26 Nov 2002 16:38:46 -0500 (EST) Received: from hobbit.omg.org (hobbit.omg.org [192.67.184.3]) by emerald.omg.org (8.11.0/8.9.2) with SMTP id gAQLbR301012 for ; Tue, 26 Nov 2002 16:37:29 -0500 (EST) Received: from mx03.covadmail.net [63.65.120.63] by hobbit.omg.org asmtp(1.4f) id 32700; Tue, 26 Nov 2002 16:41:48 -0500 (EST) Received: (covad.net 23792 invoked from network); 26 Nov 2002 21:37:49 -0000 Received: from h-66-134-137-141.snvacaid.covad.net (HELO orion) (66.134.137.141) by sun-qmail08 with SMTP; 26 Nov 2002 21:37:49 -0000 From: "Stan Hendryx" To: "'Michael Jesse Chonoles'" , "'Michael Latta'" , "'Cory Casanave'" , Cc: "'Thomas Weigert'" , , , Subject: RE: Issues with UML2 support for MDA Date: Tue, 26 Nov 2002 13:37:46 -0800 Message-ID: <003a01c29594$100f93f0$01010101@covad.net> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <007201c294f1$03cc6030$9865fea9@OldLM2ACC> MIME-Version: 1.0 (Generated by Clearswift ES version 4.7.0.120) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: RO There are several applications for UML, as several of you have pointed out. Surveys have shown that the most common use of UML tools is drawing diagrams for documentation. The application that interests me the most is separation-of-concerns modeling with well-defined transformations between models of different concerns, a.k.a. MDA. This is described at length in ormsc/02-10-01, with several scenarios portrayed at high level of how to successively transform and merge models to get to the deployable result. This is what I think of when I hear the term "MDA". I have been particularly interested in modeling business concerns, business rules, in support of domain and requirements analysis by business people, as part of the overall MDA process. I provide here an evaluation of UML for these purposes aided by a set of eight criteria from Terry Halpin for conceptual modeling languages. These are the eight criteria*: Expressibility, Clarity, Simplicity and Orthogonality, Semantic Stability, Semantic Relevance, Validation Mechanisms, Abstraction Mechanisms, and a Formal Foundation. Let's look at how, from the perspective of MDA, UML rates in modeling the three main aspects of an information system -- data, process, and control -- and talk about UML it fits the criteria. I'll try to be specific with my comments, even though that means more words. Data Modeling. UML expresses data in terms of classes, attributes, data types, packages, associations, and OCL constraints. This is quite abstract and general purpose, maximizing the range of domains to which it can be applied, which is good. It is very OO, which is good if you're doing object-oriented analysis, but not always so good if you are not doing OO. There are problems, both with the way the general purpose constructs are implemented, and with the choice of the OO architecture. I point out some of these problems below. Except for multiplicities on association ends, there is no simple, graphical way to express common constraints like mandatory attributes, or the uniqueness of values of combinations of attributes, or constraints on the participation of objects in multiple associations, like subset constraints, irreflexive constraints, exclusionary constraints or inclusive OR constraints. While all of these may be expressed using OCL, this, in my view, falls well short of passing the simplicity, clarity, or orthogonality tests for end-to-end MDA and renders UML practically useless for data modeling or modeling of business concepts, where these kind of constraints are so prevalent. There is no standard equivalent verbal expression of UML constructs in natural language, for the most part. This is a serious drawback for business and requirements modeling. Expression of multiplicities of N-ary associations is incomplete and ambiguous. Unary associations can only be expressed by creating attributes of Boolean type, or through the use of OCL; this is neither simple nor clear, and leads to difficulties with null values. Composition aggregation provides the basis for component-oriented modeling; use of ports and connectors could be clearer. Forcing object orientation with attributes leads to semantic stability problems. For example, when it is discovered that an attribute should really be modeled as a class plus an association, many changes in the model are forced. To objectify an association requires rebuilding the model with an association class. These stability problems of UML are very troublesome, especially in "open world" modeling of pervasive systems, where you cannot ever be sure you have the whole model, and can't easily make these structural changes when you discover a new predicate. Stability problems are also troublesome in business modeling, which is more conceptual, unstructured. The OO paradigm is not a particularly good fit to business modeling, because of this stability problem and the lack of a good natural language verbalization. Not naming associations, or giving them names that are noun phrases, is often awkward and give a cryptic air to UML models. Natural verbalizations of associations use (bi-directional) verb phrases in the language of the domain. Using such verb phrases and avoiding the rote use of trite phrases like "has" would render UML diagrams much easier to understand. UML 2 provides templates for genericity. Association generalization can model covariance. Both of these are useful constructs, but guidelines are needed on how to use them. Process Modeling. There are a plethora of behavioral modeling facilities in the superstructure metamodel. UML behavioral modeling does not meet the simplicity or orthogonality criterion very well. It is possible to create a general behavioral model to which all of the other behavior representations can be mapped, as a metamodel of behavior. Then the different representations become but diagram specifications, projections of different views of the behavior, as Activity Diagrams, Sequence Diagrams, Information Flow Diagrams, Interaction Diagrams, Collaboration Diagrams, etc. This would simplify model transformations, because the transformer would not have to deal with so many alternative representations of behavior, or interpret diagrams, just interpret one general metamodel. For example, a behavior model consisting of interacting state machines, with the interactions based on asynchronous events, and with procedures executing on entry to a state, can be made a very general model of behavior. Arbitrary internal actions and synchronous and asynchronous interactions can be modeled in this way. Activities as separate meta classes seems especially redundant. And I'm wondering why InformationFlow can't be simply represented in the meta model as data associated with events. Control Modeling. Event generation actions and control actions for iterators, accessors, and branching would provide adequate metamodeling capability for flow of control. Semantic Relevance is unquestionably improved in UML 2 by the fine grained factorization. UML has good abstraction mechanisms, in the generalization and the dependency and packages and package extensions, and in its abstract metamodel. The abstractness of UML is often allowed to persist in domain models, which obscures understanding of the domain through the model. Clear guidelines for enforcing separation of concerns and constraining the names of model elements to align with the universe of discourse being modeled, would be very helpful. Guidelines for standard ways of using these abstraction mechanisms to connect a model to a specified set of concerns, or universe of discourse, is highly desirable. UML is a grammar, a general modeling language. For MDA, we need standards for writing with the language, for getting specific, as well as for the grammar itself. The need for a disciplined use of UML is especially acute when it comes to MDA, to set standards for business and requirements modeling; for separating business, architectural, and technical concerns in different models; and for linking the business model with the technical models through standard model transformations. The formal foundation of UML 2 could, in my view, be simplified and improved for the kind of separation-of-concerns MDA modeling I described at the beginning. To support MDA, UML infrastructure needs to comprise a metamodel that supports an integrated and extendable general model of data, process, and control flow, not just a metametamodel core. The superstructure is the provenance of the view, or diagram, definitions. The superstructure kernel should consist of a diagram metamodel, an abstraction of any diagram, including charts, graphs, tables, or text (for business rules). Superstructure metamodel constructs can be mapped onto various diagrams as views of the infrastructure metamodel, friendly to authors and reviewers of the diagram. An instance of the diagram metamodel is a model of a particular kind of diagram, with diagram elements mapped (not necessarily trivially, but invertibly) to the infrastructure metamodel. A particular diagram is an instance of the model of that kind of diagram. The diagrams thus take their semantics from the mapping and the infrastructure semantics. The diagram models and the diagrams should contain the diagram layout metadata and data, respectively. Including the layout coordinates of the diagram as part of the diagram should enable diagram interchange as well as semantic interchange. The language architecture I have described would simplify MDA transformations by enabling more of them to be defined solely on the infrastructure metamodel. It would allow new diagrams to be readily defined, to easily extend the notational power of the language by adding new diagram models and symbols, all rigorously defined in terms of the superstructure diagram metamodel. The key to defining good views is identifying who is the target audience for each model view, or diagram, and then designing the diagram for maximum utility for that group, then mapping the diagram constructs to the infrastructure metamodel. A serious problem with UML is lack of validation mechanisms for many UML models. UML models can be virtually opaque to domain experts, more so when OCL is used to any great extent. Much could be done to improve this, such as including simple symbols for uniquess constraints on sets of attributes and requiring domain language verb phrases on association ends and making proper use of domain terms in assigning names to model elements. Beyond that, developing a natural-sounding, not stilted, alternative natural language verbalization of UML constructs that has an unambiguous, provable mapping to metamodel elements, would greatly aid business models that can be validated by domain experts. Formally defining and linking the business model and business requirements to the other, technical, models through well-defined MDA model transformations would provide a path for initial validation of the design, and an ongoing requirements traceability path to reduce system lifecycle costs. Keep in mind that the cost to industry worldwide for not having this kind of solid requirements and links to implementation, is about $200 billion per year. OMG has an opportunity to address this $200 billion with MDA vigorously supported by UML 2; let's give the marketplace a UML 2 that makes MDA sing, all the way to the bank. I find it hard to understand the U2P submittal. Its organization around the factorization of the metamodel obscures the bigger picture of how the pieces fit together and work together. I feel like I was given a jigsaw puzzle and need to put it together myself before I can see what the whole thing looks like. That is an undue burden on the reader, in my opinion. The language of the submittal is highly technical and difficult at times, and that is probably unavoidable in places, because of the nature of the work; however, more illustrative examples in plain language would be most helpful in elucidating the design of this proposed modeling language. Stan Hendryx CEO Hendryx & Associates 505 S. Murphy Ave. Sunnyvale, CA 94086 phone: 408 773-8089 mobile: 408 218-9455 Stan@HendryxAssoc.com * The criteria: Expresibility -- the expressibility of a language is a measure of what it can be used to say. Clarity -- the clarity of a language is a measure of how easy it is to understand and use. Simplicity and Orthogonality -- use an expression wherever its meaning or value may be used. Semantic stability -- a measure of how well models or queries expressed in the language retain their original intent in the face of changes to the application. Semantic relevance -- only conceptually relevant details need be modeled. Validation mechanisms -- ways in which domain experts can check whether the model matches the application. Abstraction mechanisms -- allow unwanted details to be removed from immediate consideration. Formal foundation -- needed to assure unambiguity and executability and to allow formal proofs of equivalence and implication between models. -----Original Message----- From: Michael Jesse Chonoles [mailto:michael.j.chonoles@acclearning.com] Sent: Monday, November 25, 2002 6:11 PM To: 'Michael Latta'; 'Cory Casanave'; cris.kobryn@telelogic.com Cc: 'Thomas Weigert'; adtf@omg.org; uml2-eval@omg.org; uml2review@omg.org Subject: RE: Issues with UML2 support for MDA - MDA vision should guide us , not overwhelm us with scope creep! I'd agree that problems in the requirements arena are often the biggest cause of project failures. This argues that UML2 support of MDA is less important than support for better Domain and Requirements Analysis. And again, many use UML for non-MDA-like tasks and are eagerly waiting an improved UML. The discussion should be on whether the UML2 proposals actually sufficiently improve UML, as opposed being focused just on suitability for one particular task. Michael Chonoles Chief of Methodology Advanced Concepts Center -----Original Message----- From: Michael Latta [mailto:mlatta@ceira.com] Sent: Monday, November 25, 2002 4:31 PM To: 'Cory Casanave'; 'cris.kobryn@telelogic.com' Cc: Thomas Weigert; adtf@omg.org; uml2-eval@omg.org; uml2review@omg.org Subject: RE: Issues with UML2 support for MDA - MDA vision should guide us , not overwhelm us with scope creep! Cory, Your comments were addressed to Cris, but I have some comments. 1) I would like to know why these issues are being raised now, when we are so close to the final submission date? But, my main issues have more to do with successful processes. 2) I would suggest that the following are characteristics of a successful development process: 2a) Requirements are defined for work to be done. 50% of all IT projects fail, and of these 80% is due to requirements issues or executive support issues. 2b) Changes to requirements are controlled to ensure completion on a reasonable schedule. The industry AVERAGE schedule overrun in software is 100%, and cost overrun is 150%. 2c) Some set of requirements are deferred to a later release to control function creep. In the context of the OMG the ADTF defines requirements, and unfortunately there is no process for revising those requirements after the fact. I too would like to see a shorter development schedule for OMG efforts. (The best way to get there is to have the submitters not invent a lot of new requirements. ) For the time being however the process is already defined. While submitters are allowed to go beyond the RFP, the time for that would seem to me to be long past. I suspect that if you want to persuade the submitters to slip their schedule at this late date, you are going to have to propose very concrete changes, or show very concrete cases for why the current approach does not meet MDA requirements. There are an infinite number of approaches to these problems, so it becomes very difficult to assert that X does not support Y, when Y is a poorly defined (just a concept in this case). It is also true that MDA is not the only use for UML 2.0. There are a lot of people using UML for many modeling tasks not impacted by MDA. There are a lot of organizations that are not going to adopt an unproven approach like MDA, that want improvements to UML. Cory, If you have specific plans that you are calling MDA and feel the current UML 2.0 spec does not support them, please elaborate in detail. Given the time and effort already invested in UML 2.0, the complicated schedule dependencies (UML, MOF, XMI, JMI, CWM), I for one would not support a change in requirements and complex revision process at this late date. Michael Latta -----Original Message----- From: Cory Casanave [mailto:cory-c@enterprise-component.com] Sent: Monday, November 25, 2002 10:04 AM To: 'cris.kobryn@telelogic.com'; Cory Casanave Cc: Thomas Weigert; adtf@omg.org; uml2-eval@omg.org; uml2review@omg.org Subject: RE: Issues with UML2 support for MDA - MDA vision should guide us , not overwhelm us with scope creep! Chris, Perhaps we can pick up on your thread to isolate and clarify a specific issue - is (or should) the UML2 RFP set include support for MDA? Clearly if UML2 is not intended for MDA then enumerating issues with support for MDA is not relevant. In this case we can stipulate as to the issues and move on. I get the sense from below that this is your position, but you would still like to see the issues fully developed. If we accept MDA as fundamental to UML2 and it is felt that U2P fully addresses it then we have another discussion, one in which the development of the detail of the issues would be the most productive. If we accept MDA as fundamental to UML2 and it becomes clear that U2P does not address them we should post-haste try and fix it or explore other alternatives that do. So yes, the fundamental question is one of requirements. It is my opinion, looking all the way back to the UML2-RFI, that UML2 lead to MDA - that they are fundamentally linked, but I also understand your issues with the lack of guidance provided by the RFP requirements and that "MDA" was not explicit. In retrospect it does not seem the requirements are well formed since they don't explain the purpose of the infrastructure. So, are you suggesting that MDA issues are not and should not be considered in evaluating UML2? -Cory > -----Original Message----- > From: Cris Kobryn [SMTP:cris.kobryn@telelogic.com] > Sent: Monday, November 25, 2002 2:32 AM > To: Cory Casanave > Cc: Thomas Weigert; adtf@omg.org; uml2-eval@omg.org; uml2review@omg.org > Subject: RE: Issues with UML2 support for MDA - MDA vision should > guide us, not overwhelm us with scope creep! > > > > > as a USER of the UML I completely disagree with the view presented > > in ad/2002-11/21. Unfortunately, it is difficult to present an > > argument to counter, as ad/2002-11/21 "cries wolf" without really > > pointing out where the wolf is coming from. > > I also share Thomas's concern about "crying wolf," since you provide > little substance in your presentation to back your various strong > claims. It is disturbing that you are expressing such strong concerns > so late in the UML2 > RFP process (2+ years since the RFPs were issued) without specifying how > particular UML2 proposals are failing to satisfy specific RFP mandatory > requirements. When can the ATDF expect to receive the "more detailed > enumeration of the technical issues" that you state in your last slide is > "forthcoming"? > > There is a great danger here of muddling the evolving MDA conceptual > architecture with our basic RFP process. While I am a fan of the MDA > concept, I am also painfully aware that it seems to have as many > interpretations as we have members! Consequently, it is problematic to > use it as the basis for new RFPs, let alone RFPs that were issued > prior to the concept, as was the case with the UML2 RFPs. (UML2 > Infrastructure, Superstructure and OCL RFPs were issued in Sept. 2000, > and the first MDA white paper was issued several months later.) > > We must not confuse the evolving MDA conceptual architecture with our > basic RFP process, where submissions need to be primarily focused on > satisfying the Section 6.5 mandatory requirements and demonstrating > the Section 4.8 Proof of Concept. If we do otherwise, we have no real > standardization process, only anarchy. We will also perform a great > disservice to all those > companies who have worked hard over the last 2+ years to propose UML2 > specifications and prove their technical viability via prototyping and > implementations. > > MDA is an evolving conceptual architecture that will require 2nd > generation modeling standards, such as UML2, XMI2, MOF2 and CWM2 to > make it a bona fide > technical architecture. We will never complete the technical architecture > if > we allow scope creep to prevent us from drying the concrete in its > foundation (i.e., the UML2 Infrastructure). > > The MDA vision should guide us, not overwhelm or paralyze us with > requirements creep. > > Thanks, > > Cris > > > ------------------------------------------------------------------- > Cris Kobryn > Chief Technologist > Telelogic > Phone: +1-760-728-9747 > Fax: +1-760-728-9749 > E-mail: mailto:cris.kobryn@telelogic.com > www: http://www.telelogic.com > -------------------------------------------------------------------