Issues for Mailing list of the SPEM 2.0 Finalization Task Force
To comment on any of these issues, send email to spem2-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 11077: Wrong Specification Name
Issue 11078: Fix stereotype extensions for components and update examples in spec
Issue 11079: UML 2 Profile: Missing Profile meta-model diagrams
Issue 11080: Support UML 2 Profiles for SPEM 2.0 meta-model instances
Issue 11081: Meta-Model: Missing relationships in Process Behavior
Issue 11082: Responsibility Assignment Maps shall be specific for the Work Product State
Issue 11083: Meta-Model: Missing association of Task Definition to Qualification
Issue 11084: Remove the word “Map” from various classes in the meta-model
Issue 11266: Page: 159ff
Issue 11284: Section: 14.11 and B.4
Issue 11302: Appendix B is out of date
Issue 12210: specification lacks an overview
Issue 12515: Profile Notation of Process Element
Issue 12517: Section 13.1 figure 13.3
Issue 13128: associations "categorizedElement" and "subcategory" are not implemented
Issue 15113: Reference to unavailable documents
Issue 11077: Wrong Specification Name (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Clarification
Severity: Minor
Summary:
The submission team of the specification had decided to change the name of the specification to “Software & Systems Process Engineering Meta-Model” but keeping the acronym “SPEM” as it is well-know in the industry. Currently the specification is still named as “Software Process Engineering Meta-Model”.
Resolution: We updated specification title, footer, and references to the full name in text to reflect the name change.
Revised Text: "Software & Systems Process Engineering Meta-Model" [in all places in the document where the old name was used]
Actions taken:
May 31, 2007: received issue
January 15, 2008: closed issue
Issue 11078: Fix stereotype extensions for components and update examples in spec (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Revision
Severity: Significant
Summary: UML 2 Profile: Fix stereotype extensions for components and update examples in specification (Thanks to FTF member Chris Armstrong, APG for helping identifying and discussing this issue.) The UML 2 Profile contains errors that prevent specification consumers from remodeling the examples presented in Section 14.7 using UML 2 Components and the supplied stereotypes. The Process Component stereotype extends Package, but UML 2 Components are Classes. Extend the stereotype from UML 2 Class and Package. The latter is necessary, because in SPEM 2 as well as SPEM 1.1 Process Components are derived from UML Package in the meta-model. A profile user shall be able to choose to apply the stereotype to UML Packages or Components. The stereotype definition currently misses a graphical icon that is shown in the examples. Add an icon to the stereotype. The Work Product Port stereotype extends Classifier, but UML 2 Ports are Properties, not Classifiers. Extend the stereotype from UML Port and not Classifier. The examples presented use different graphical icon than defined for the profile’s stereotypes. Redraw the diagrams to be consistent with the profile.
Resolution: - Changed Process Component stereotype to extend Class and Package in model and specification.
- Changed Work Product Port to extend Port.
- Fixed model by assigning the same icon to the Process Component stereotype as listed in the specification.
- Replaced all figures with new diagrams coming from the same UML modeling tool that was used for all other figures in the specification using the fixed profile.
- The old figures used the same names for component, port type, and work product definition name, which was very confusing. We adjusted the names.
Revised Text: - Updated stereotype tables in Sections 14.7, 14.12, and Annex A
- Updated all references to the work product ports "Analysis", "Design" to "Analysis Model" and "Design Model" in Section 14.7
- Updated Figure 14.8
- Updated Figure 14.9
- Updated Figure 14.10
- Updated Figure 14.11
- Updated Figure 14.12
- Updated Figure 14.13
Actions taken:
May 31, 2007: received issue
January 15, 2008: closed issue
Issue 11079: UML 2 Profile: Missing Profile meta-model diagrams (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Clarification
Severity: Significant
Summary: UML 2 Profile: Missing Profile meta-model diagrams The specification does not present a UML model of the UML 2 Profile. Provide a class diagram for the profile.
Resolution: - Added stereotype diagrams to every section that defines a meta-model package. Text for each Figure caption: "The SPEM 2.0 UML 2 Profile stereotypes defined in the <name> package".
- Added stereotype diagrams for the Base Plug-in Profile sections.
- Fixed Figure 11.2 in Section 11.1 which was showing the wrong stereotypes.
Revised Text: - Added text "in a UML 2 stereotype diagrams as well as" to introduction of Section 7.1 to mention the stereotype diagrams
- Added Figure 8.1
- Added Figure 9.1
- Added Figure 11.1
- Fixed Figure 11.3 with correct stereotypes
- Added Figure 12.1
- Added Figure 13.1 (Framemaker displays the wrong caption number (12.1); no idea how to fix this)
- Added Figure 14.1
- Added Figure 18.1
- Added Figure 18.4
- Added Figure 18.5
- Added Figure 18.6
- Added Figure 18.7
Actions taken:
May 31, 2007: received issue
January 15, 2008: closed issue
Issue 11080: Support UML 2 Profiles for SPEM 2.0 meta-model instances (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Enhancement
Severity: Significant
Summary: Meta-Model: Support UML 2 Profiles for SPEM 2.0 meta-model instances The SPEM 2.0 meta-model provides a light-weight extensibility mechanism via the Extensible Element and Kind classes that allow defining special kinds of meta-model elements such as “artifact” versus “deliverable” work product kinds. However, often when the kinds are defined meta-model users also want to define specific attributes or associations for the stereotyped instances such as in UML 2 Profiles. Provide as an additional alternative to the light-weight extensibility mechanism provided in the current specification also the ability to define and UML Profiles for SPEM 2 meta-model instances. As all classes in the SPEM 2 meta-model are derived from classifier the only model change to realize this capability needed would be to merge Infrastructure::Profiles into the SPEM 2 meta-model.
Resolution: - Merged Profiles package from UML2 Infrastructure library in SPEM Complete compliance level.
Revised Text: - Added this text to Section 2.3:
"It is also the only compliance point that merges the Profiles package from the UML 2 Infrastructure, which provides a more complete extensibility mechanism than the light extensibility mechanisms provided in SPEM 2.0 itself. Whereas SPEM 2.0 provides the ability to define instances of a Kind class that allow associating special semantics to meta class instances, UML Profiles allow in addition to that creating and managing stereotype application instances that can store user-defined property values defined for the stereotype with the stereotype instance. SPEM Complete implementers shall either provide both extensibility mechanisms or a mapping of UML Profile stereotypes to SPEM 2 Kinds. The other compliance levels defined in the specification do not require realizing Profiles because the light-weight extensibility mechanisms of SPEM should be sufficient for the audiences listed, but implementers have the option to do so for these levels as well."
- Updated Figure 2.3
Actions taken:
May 31, 2007: received issue
January 15, 2008: closed issue
Issue 11081: Meta-Model: Missing relationships in Process Behavior (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Enhancement
Severity: Significant
Summary: Meta-Model: Missing relationships in Process Behavior Currently the Process Behavior package in Section 10 only provides associations of elements defined in Process Structure to behavioral models. If specification users implement the compliance levels “Complete” or “Method Content” they would also like to provide relationships of the additional elements introduced only in these compliance levels (e.g. work product definition) to behavior models. Provide either an Extended Process Behavior package that provide these missing relationships or package merge these relationships in the already existing packages. Currently there are issues with the following classes: - Work Product Definition needs to be associated to State_ext - Role Definition needs to be associated to Transition_ext - Task Definition or better the general Work Definition which also the generalization of the currently linked Activity needs to be associated to Transition_ext - Default_TaskDefinitionParameter or better its generalization WorkDefinitionParamter which is also the generalization of the currently linked ProcessParameter needs to be associated with State_Ext.
Resolution: - Added package merge relationship from Process Behavior to Method Content
- Modeled association from Work Definition to Transition_ext replacing the existing association from Activity. Renamed association and role names for associations coming from Work Definition. Deleted Activity redefinition from Process Behavior package.
- Added redefinitions for Work Product Definition and Role Definition and associated them to State_ext and Transition_ext respectively. Updated existing association and role names for consistency.
- Replaced the Process Parameter override and relationships to State_Ext with the more generic Work Definition Parameter. Updated association name.
Revised Text: - Updated Figure 2.1:
- Added a sentence in Section 2.2 that described the Process Behavior package:
"; or a Work Product Definition from the Method Content package can be linked to a state machine model that represents its typical lifecycle."
- Updated Figure 10.1:
- Updated text in Chapter 10's introduction
"Figure 10.1 lists the classes from Process Structure and Method Content that shall…."
- Updated former Section 10.4, Process Parameter to Section 10.6, Work Definition Parameter and updated text to:
"Super Class
Classifier (from Constructs in UML 2 Infrastructure)
Description
This package extends the Work Definition Parameter class introduced in the Core package with associations to entry and/or exist states for its Work Product Use or Work Definition parameter values.
Association Properties
entryState: State_ext: Given that an instance of Work Product Definition or Work Product Use has been specified as an input for a specific Work Definition, then the Entry State attribute specifies the desired state of instances of the referenced work product instance when work on the Work Definition is initiated.
For some Work Products Definition or Uses, state is expressed in percentage of completion, compliance to work product checklist, informal state descriptions, etc. Others have very specific states expressed as enumerations such as [identified, briefly described, outlined, detailed] for use cases. Other Work Product states relate to some quality measures or lifecycle states such as [reviewed, implemented, tested].
exitState: State_ex: Given that an instance of Work Product Definition or Work Product Use has been specified as output for a specific Work Definition, then the Exist State attribute specifies the desired state of instances of the referenced work product instances when work on the Work Definition is finished."
Actions taken:
May 31, 2007: received issue
January 15, 2008: closed issue
Issue 11082: Responsibility Assignment Maps shall be specific for the Work Product State (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Enhancement
Severity: Significant
Summary: Meta-Model: Responsibility Assignment Maps shall be specific for the Work Product State In the current SPEM 2.0 meta-model responsibility assignment of roles to work products is a class that associates a role use with a work product use as well as a role definition with a work product definition. However, in many processes these responsibilities might be actually different based on the state of the work product. For example, a “work item” work product to fix a bug might be assigned to a developer in the state “open” and assigned to a tester role instance in the state “resolved”. In the current SPEM 2 specification this can only be modeled by defining different work product use and role use instances with different maps within the context/namespace of an activity, but not independent of activities. Often processes or method content wants to define such relationships independent of a specific activity scope. We therefore propose to turn the assignment maps into such a ternary relationship (still represented as a class) amongst the concepts of role, work products, and state and to package merge in the Process Behavior package an association from the Responsibility Assignment Maps in Sections 9.8 and 12.1 to State_ext.
Resolution: - See changes for Issue 11081
- Added redefinitions of Default Responsibility Assignment and Process Responsibility Assignment (they have been renamed in Issue 11084 to not use the word Map anymore) that are associated to State_ext
Revised Text:
Actions taken:
May 31, 2007: received issue
January 15, 2008: closed issue
Issue 11083: Meta-Model: Missing association of Task Definition to Qualification (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Enhancement
Severity: Significant
Summary: Meta-Model: Missing association of Task Definition to Qualification The SPEM 2 meta-model defines the concept of Qualification in Section 12.6, which is associated to Role Definitions. To fully utilize the concept it shall also be associated to Task Definition. This would allow to define Tasks purely based on the required qualifications and would allow a tool implementation of the meta-model to propose mappings of roles that would be a good fit to be listed a performers of the task based on the qualifications. This would allow to realize a so-called “late-role assignment” for roles to tasks for roles that all provide similar or common sub-sets of qualifications.
Resolution: - Added an association from Task Definition to Qualification and updated existing association name and role name from Role Definition to distinguish qualifications provided by roles from qualification required by tasks.
- Renamed the role name for the association from Role use to Qualification to applied Qualification.
- Added an association from Task Use to Qualification
Revised Text: - Updated Figure 12.3 (formerly Figure 12.2)
- Updated text in Section 12.6, Qualification, Semantics:
"A Qualification documents one specific skill or competency that is used to model and represent the qualifications provided by instances of a Role Definition and/or the qualifications required for the performance of a Task. These qualifications can be used to find and map roles for tasks when assembling method content and assigning organization specific roles to these tasks dynamically. Qualifications can also be used to find individuals (i.e. people) as instances of…"
- Updated role name for Role Definition association to Qualification in Section 12.7 to provided Qualification. Changed text:
"providedQualification: Qualification: Provides a list of qualifications that the role typically provides. This list can be mapped against the required qualifications list defined for Task Definitions (see Section 12.9). The qualifications need to be present by individual that are represented as instances of instances of the Role Definitions."
- Added association to Task Definition in Section 12.9. Added text:
"requiredQualification: Qualification: Provides a list of qualifications that the task typically requires to be performed by one or more roles. This list can be mapped against the provided qualifications list defined for Role Definitions (see Section 12.7)."
- Updated Figure 13.12
- Updated association role for Role Use in Section 13.13:
"appliedQualification: Qualification: A Role Use can select a sub-set of valid Qualifications defined for the Role Definition for this one use of the Role Definition in the context of a particular Activity."
- Added association from Task Use to Qualification in Section 13.14:
"usedQualification: Qualification: A Task Use can select a sub-set of valid Qualifications defined for the Task Definition for this one use of the Task Definition in the context of a particular Activity."
Actions taken:
May 31, 2007: received issue
January 15, 2008: closed issue
Issue 11084: Remove the word “Map” from various classes in the meta-model (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Clarification
Severity: Minor
Summary: Meta-Model: Remove the word “Map” from various classes in the meta-model The word “Map” is commonly used in software development to indicate a collection data structure that “maps keys to values”. The classes that use the word Map in SPEM 2 such as ResponsibilityAssignmentMap or TaskPerformerMap do not provide such a key to value mapping. Remove the word “map” from the class names. The names are clear without them, e.g. “ResponsibilityAssignment or TaskPerformer.
Resolution: - Updated the following classes by removing the word map from their name as well as all association's names they are connected to:
o Work Definition Performer Map
o Process Performer Map
o Process Responsibility Assignment Map
o Default Responsibility Assignment Map
o Default Task Definition Performer Map
Revised Text: - Updated text under Figure 7.1 to reference the Task Definition Performer (not Map)
- Updated Figure 8.3 (formerly Figure 8.2; see Issue 11079; all subsequent figure references will refer to new numbers)
- Renamed Work Definition Performer Map throughout the whole of Section 8.6. The association role has been renamed to 'linkedWorkDefinition'.
- Updated Figure 9.2
- Updated Figure 9.4
- Updated Figure 9.12
- Updated names in Sections 9.1, 9.7, 9.8, 9.9, 9.11
- Updated Figure 12.2
- Updated Figure 12.3
- Updated names in Sections 12.1, 12.3
- Updated Figure 13.2
- Updated Figure 13.8
- Updated names in Sections 13.12
- Updated all stereotype names in Appendix A
- Updated the example in Appendix C.1
Actions taken:
May 31, 2007: received issue
January 15, 2008: closed issue
Issue 11266: Page: 159ff (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Clarification
Severity: Minor
Summary: Section 18.4 defines Process Kinds, but Process is not a meta-model class anymore. These kinds need to be defined as Activity Kinds and need to be moved to Section 18.1.3.
Resolution: - Removed Process Kind stereotype and made all Process Kind specializations specialization of the Process stereotype.
- Moved content of Section 18.4 to Section 18.1.4 to 18.1.6.
- Removed outdated text that was left behind after revisions during the submission stage.
Revised Text: - Updated all stereotype tables in the new Section 18.1 with new values
- Removed outdated text in (new) Section 18.1.3, 18.1.5
Actions taken:
August 9, 2007: received issue
January 15, 2008: closed issue
Issue 11284: Section: 14.11 and B.4 (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Revision
Severity: Significant
Summary: Inconsistent overrides for Extends: User of the SPEM 2.0 implementations EPF Composer and Rational Method Composer complained about an inconsistency in semantics define for the Extends relationship in Section 14.11 (p.136) and Appendix B.4 (p.179). The inconsistency relates to the fact that for to-one relationships and attribute values the extending element can override the inherited values whereas for to-many relationships values of the extending element would be appended to the list of inherited elements. The users preferred to have complete override semantics here as well. In other words, if the extending element would define its own to-many relationship instances the inherited relationships would be completely overridden. If the extending element needed relationships from its base element then users could add them back in manually, which is perceived as a more flexibility solution for using this relationship.
Resolution: - Updated semantics definition for Extends in Section 14.11 and updated Appendix B.4
Revised Text: - Updated sentences in Section 14.11:
"The result of interpretation is that the special element has the same properties as the based-on has, but might override the inherited properties with its own values."
"0..n-association instances: Association instances defined for the based-on Variability Element are inherited to the special Variability Element. If the special Variability Element defines its own association instances, then the inherited ones are ignored."
[Note, Framemaker did not create a change bar here for this text change as the text is position inside a nested table, which the tool does not seem to support for change bars.]
- Updated sentence in Section B.1:
"Extends: Only defines inheritance for the extending element. The base remains untouched. The extending element can override inherited attribute values and association instances by defining their own. If no new values are defined for the extending element it will inherit these values from the base element."
- Updated text in Section B.4:
"The result of interpretation is that the special element has the same properties that the based-on has, but might define its own overrides."
"Outgoing to-many associations of the base element are inherited to the extending element if the extending element does not define its own association instances."
Disposition: Resolved
Actions taken:
August 17, 2007: received issue
January 15, 2008: closed issue
Issue 11302: Appendix B is out of date (spem2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Peter Haumer, phaumer(at)us.ibm.com)
Nature: Clarification
Severity: Minor
Summary: Appendix B is out of date. The diagrams need to be updated to use the correct stereotype names. It misses a section for the extends-replace variability kind.
Resolution: - Updated Appendix B with new images as the examples provided used the wrong stereotypes.
- Added Appendix B.5 for Extends-Replace to complete the specification.
Revised Text: - Updated images in Section B.2:
- Updated images in Section B.3:
- Updated images in Section B.4:
- New Section "B.5: Extends-Replace
Background
The extends and replaces variability relationship combines the effects of extends and replaces variability into one variability type. Whereas replaces variability completely replaces all attributes and outgoing associations of the base element with new values and instances, or removes all values or associations if the replacing element does not define any, extends and replaces variability only replaces values that have been redefined. All other values of the base element are unaffected. In other words, extends and replaces allows users to selectively replace specific attributes and associations of the base elements. This type of variability can be used to generate method plug-ins that rename elements, or replace some descriptions of method elements with new ones, without completely remodeling all other relationships and attributes needed by the base plug-in.
Rules
o Extends and replace variability combines the effects of the extends and the replaces variability. The evaluation will first perform the effects of the extends and then the effects of the replaces variability. This implies the following:
§ First, the new element will inherit all attributes and associations from the base element.
§ Second, the new elements might override inherited attributes or associations.
§ Third, the base element will be replaced with new element using the overridden values and if no override was specified keeping the inherited values.
o If the extends and replaces element defines outgoing associations, they will replace all outgoing associations of the base elements. If the extends and replaces element does not define any new associations, the resulting element will retain the associations of the base element.
o Incoming associations from the base element are added to the replacing element.
o If the extends and replaces element defines attributes, these attributes are replaced in the resulting element including the base element's identifier. Undefined attributes retain values used in the base element.
o The base element of a replaces relationship or an extends and replaces relationship can have only one replaces or extends and replaces element per configuration. If more than one element is present, no replacement takes place.
o The extends and replaces relationship is transitive and evaluated top-down relative to the direction of the replacement. If a replacing element is also replaced, the final replacing element prevails.
o Contributes variability relationships are resolved before replaces and extends and replaces relationships. Extends relationships are resolved last. Variability is always resolved top-down from the base to the variability elements. Within the same level, contributes relationships are resolved first. Replaces or extends and replaces are resolved afterwards.
Example
The example below shows how extends-replace works by having the extends-replacing element p_business_process inherit is base's relationships, but overriding the relationships to guidance elements as part of the replacement.
Actions taken:
August 22, 2007: received issue
January 15, 2008: closed issue
Issue 12210: specification lacks an overview (spem2-ftf)
Click here for this issue's archive.
Source: Cordys (Mr. Fred A. Cummins, fred.a.cummins(at)gmail.com)
Nature: Enhancement
Severity: Significant
Summary: The specification lacks an overview that provides an undestanding of how the problem domain is being addressed. This is important for non-implementers, particularly potential customers of implementations, to understand why they should care if a product implements SPEM
Resolution:
Revised Text:
Actions taken:
February 4, 2008: received issue
Issue 12515: Profile Notation of Process Element (spem2-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: In SPEM 2.0 Profile Notation of Process Element you say: SuperClass of Process Element: BreakDownElement. I believe that's not correct because in BreakDownElement's specification BreakdownElement is a child of Process Element
Resolution:
Revised Text:
Actions taken:
May 30, 2008: received isuse
Issue 12517: Section 13.1 figure 13.3 (spem2-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: Below Figure 13.4 (page 98) text says: "Figure 13.3 depicts a SPEM 2.0 Profile presentation of an Activity called 'Define the System'..." but Figure 13.3 shows a Taxonomy and key relationships of Breakdown
Resolution:
Revised Text:
Actions taken:
June 6, 2008: received issue
Issue 13128: associations "categorizedElement" and "subcategory" are not implemented (spem2-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary: Using the categorization within the SPEM 2.0 Profile we found the following: It seems, that the associations "categorizedElement" and "subcategory" are not implemented. The Category element does not have the two associations in its menue and there are no stereotypes with related names. It is not possible to categorize elements. Associations and stereotypes do not exist in provided ptc/2007-08-09 XMI files also.
Resolution:
Revised Text:
Actions taken:
November 27, 2008: received issue
Discussion:
Issue 15113: Reference to unavailable documents (spem2-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary: n Section 2 (Conformance) of the SPEM 2.0 spec, there is a reference to documents "ad/06-11-04" (XMI Schemata) and "ad/06-11-05" . Neither of these are available. I'd like to access the XMI Schemata for SPEM 2.0 if possible.
Resolution:
Revised Text:
Actions taken:
March 3, 2010: received issue