Issue 4886: Milestone as a metaclass (spem-ftf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde@orange-ftgroup.com) Nature: Uncategorized Issue Severity: Summary: Milestone as a metaclass In 9.1 and 9.2 milestones are defined as special kinds of goals. Because a Milestone is an major concept it could make sense to add a Milestone metaclass inheriting from the more generic metaclass used for Goal. Additionally, a <<milestone>> stereotype could be added in the UML profile. Resolution: see above Revised Text: In 9.1 replace ', called "Milestone" in this case, ' by '(often called a "milestone")' Actions taken: February 22, 2002: received issue October 23, 2002: closed issue Discussion: Resolution: Accept a minor change of wording to emphasize that milestone is just a special kind of goal in certain cases. No new metaclass or profile change. End of Annotations:===== From: BELAUNDE Mariano FTRD/DTL/LAN To: issues@omg.org Cc: spem-ftf@omg.org Subject: New 7 issues to SPEM Date: Fri, 22 Feb 2002 16:01:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e0e167e9-26b0-11d6-b1e5-00508b69ab48" X-UIDL: fg'!!#$kd9O80e9#m#!! 2. Milestone as a metaclass In 9.1 and 9.2 milestones are defined as special kinds of goals. Because a Milestone is an major concept it could make sense to add a Milestone metaclass inheriting from the more generic metaclass used for Goal. Additionally, a <> stereotype could be added in the UML profile. From: BELAUNDE Mariano FTRD/DTL/LAN To: spem-ftf@omg.org Subject: RE: issues 4885 - 4891 -- SPEM FTF issues Date: Thu, 7 Mar 2002 12:03:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-cab0f341-31a2-11d6-b1e7-00508b69ab48" X-UIDL: Z=7!!(5\d9Se;e9TS[!! Thanks Philippe for your feedback on the last issues. I agree on your general comment stating that the aim of the FTF is to resolve problems on the adopted spec (clarifications, ambiguities, inconsistencies&) and not to add new features. If a new feature is explicitly added, a valid and strong justification indeed need to be provided (such as "will prevent interoperability problems" or "will make simpler the implementation"). I had in mind a lot of many nice improvements to SPEM, but I have restricted myself to only report issues that are clearly within the scope of this FTF. My main concerns for SPEM are: remove ambiguities when using the UML profile and ensure that the metamodel can be used as an alternative way to support SPEM. My (optimistic) feeling is that the FTF is currently going the right way to achieve this goals and that we can achieve this in a reasonable time duration (we will problably have less than 50 issues at the end) Additional justification for the issues 4885-4891 is inside the message body. Mariano -----Message d'origine----- De : Kruchten, Philippe [mailto:pbk@rational.com] Envoy : samedi 2 mars 2002 00:06 : spem-ftf@omg.org Objet : RE: issues 4885 - 4891 -- SPEM FTF issues Because of a conflict I will not be able to attend the SPEM meeting on april 12th. I would like however to offer some feedback on Mariano's issues. Metacomment first: We need to finalize the spec, not to expand the scope, add new things. Yes, there are lots of things that could be done, lots of alternatives that can be open (or re-opened), but you are pushing this a bit too far in my opinion. I am on the opinion that we should restrict changes to fixing what is broken, and not open it to: - find nicer alternative - add requirements or features Keep those for SPEM 2, the son of SPEM. Specific comments: see below each one. Thanks, Philippe -----Original Message----- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, March 01, 2002 8:35 AM To: issues@omg.org; spem-ftf@omg.org Subject: issues 4885 - 4891 -- SPEM FTF issues This is issue # 4885 mariano.belaunde@rd.francetelecom.com> a Category should not inherit from ProcessComponent. An explicit metaclass to denote packages used for categorization. To better reflect the semantics of packages that are used to define a category of process elements, it could be useful to add an explicit "Category" metaclass inheriting from Package. Additionnally, a well-formedness rule saying "A Category can only contain Categorizes dependencies" will help to formalize the usage of this. A Discipline Package obviously inherits from Category. However a Category should not inherit from ProcessComponent. In addition, a <> stereotype could be added in the UML profile. The requriements for Category are sort of fuzzy (something DMR was keen on). It seems taht you are adding a feature. MB> The requirement for multiple categorization was a mandatory requirement in the RFP. The SPEM spec proposed an explicit solution for this, which uses Packages that own Categorizes dependencies. So this issue is not proposing a new feature. It is suggesting to use appropriate names to clarify and better reflect the semantics of the packages that are used for categorization. ------------------------------------ This is issue # 4886 mariano.belaunde@rd.francetelecom.com> Milestone as a metaclass Milestone as a metaclass In 9.1 and 9.2 milestones are defined as special kinds of goals. Because a Milestone is an major concept it could make sense to add a Milestone metaclass inheriting from the more generic metaclass used for Goal. Additionally, a <> stereotype could be added in the UML profile. Enhancement, or alternative. Not that the current spec prevents you from having a milestone and a stereotype for it. MB> Here again, the milestone concept is already explicitly defined in the SPEM specification. This is a "renaming" issue just as the previous one on categories. In addition to clarify the semantics, another advantage in the proposal is that it will be easier for an implementation to attach a specific treatment on the milestones body expression (the 'body' expression for milestones is likely to differ from the body of ordinary goals). -------------------------------- This is issue # 4887 mariano.belaunde@rd.francetelecom.com> Capturing distinct kinds of WorkProducts in the metamodel. 3. Capturing distinct kinds of WorkProducts in the metamodel. In the metamodel there is no way to capture both the name and the kind of a workproduct. In contrast, in the UML profile, the kind of a work product can be provided using pre-defined stereotypes (such as <> and <>). In order to solve this and also allow more flexibility to refer to distinct kinds of work products (such as Text Documents, UML model, SDL models, SQL Tables, executables, code librairies, and so on) a WorkProductKind could be added in the metamodel (in the similar manner as the GuidanceKind metaclass). In addition a 'subKind' association between WorkProductKinds could be useful to allow the structuring of allowable product kinds. NOTA: No additional pre-defined UML stereotypes need to be defined since these may depend on the process family being used. New feature. This one could have no end; I can imagine many other cute features to structure workproducts... We have to put a stop somewhere.... MB> Distinct kind of products already exist in SPEM (a product may be a model, a document, ...). The way how it is currently done in the UML profile is by means of stereotypes. This is perfect. However this does not work in the metamodel place. The issue identifies this problem (profile-metamodel inconsistency) and proposes a solution to this. Regarding the structuring of work product kinds (proposal to add a 'subKind' association), the current SPEM spec does not mention explicitly this structuring feature. It is quite possible that, when using the UML profile, SPEM users will tend to use stereotype inheritance to provide, anyway, this structuring feature. That's why I believe that it would make sense to explicitly mention this capability in order to avoid the users to invent distinct ways to express this. The addition of this proposed product-kind decomposition feature needs of course to be discussed. ------------------------------------ This is issue # 4888 mariano.belaunde@rd.francetelecom.com> Need for a minimal extensibility mechanism in the SPEM metamodel. 4. Need for a minimal extensibility mechanism in the SPEM metamodel. When using the SPEM UML profile one can use tagged values to annotate model elements. In order not to loose this information when expressing the SPEM model in terms of the metamodel, we need an equivalent mechanism in the metamodel counterpart. Suggestion: add a Property metaclass with a name and value attributes to be attached to any model element. New feature. Where will we stop....? MB> This is an "implementation" issue. SPEM is a general purpose foundation for distinct methodologies (RUP, DMR ...). To address a specific methodology we can anticipate that designers will use UML tagged values to provide specific information. By providing a simple explicit extension we will minimize the risk for inter-operability problems (prevents extending the SPEM metamodel to capture extra information). -------------------------------- This is issue # 4889 mariano.belaunde@rd.francetelecom.com> Pre-defined UML stereotypes to be used in UML use case diagrams. 5. Pre-defined UML stereotypes to be used in UML use case diagrams. When using a use case diagram to show the relationships between ProcessRoles and WorkDefinitions we may want to distinguish between assist and perform. The <> and <> stereotypes could be defined for this purpose in the SPEM spec. When no stereotype is used, the specification should indicate what is the default interpretation that applies (according to figure 12-2 the default meaning is assistance). In addition, to render in a more user-friendly way the semantics of an association between a ProcessRole and a WorkProduct, we could add a <> stereotype. New feature. We could in turn take each type of diagram, find a way to use it for process description and throw in nice enhancements. If use-case diagrams are broken, my reaction would be to remove them from the SPEM. Class diagrams and activity diagrams were the main ones we intended to use. MB> The use case diagrams are part of the SPEM notation in the adopted specification. The issue addresses a problem on an existing feature: the notation is ambiguous since performance and assistance are rendered in the same way. An important goal for to FTF is to prevent from distinct interpretations of the same model. For me, the introduction of use case diagrams in SPEM was rather a good idea. A use case diagram provides a user-friendly and intuitive way to represent the relationship between activities and roles as well as a global view on work decomposition. ------------------------------- This is issue # 4890 mariano.belaunde@rd.francetelecom.com> Restriction on the model elements that can be annotated with Guidances 6. Restriction on the model elements that can be annotated with Guidances. In 5.2 it is said that a Guidance can be attached to any model element. This is probably to permissive. Maybe we should add a well-formedness rule that restricts this to WorkDefinitions and WorkProducts. I strongly disagree with this. In the RUP we have guidance attached to most elemnets, in particular we have some attached to Activities, to process components.... Your instance of process may decide to be more restrictive. (Funny that you want to be restrictive here, but very open in 4888.) Philippe MB> I was trying to imagine what kind of things could be attached to guidances and I only find work definitions (including activities) and work products. I agree that it can also make sense to attach guidances to process components. If someone find one or more other additional examples, I will strongly agree with Philippe remark for not restricting the metaclasses on which a guidance can be attached. Mariano