Issue 4667: Figure 3.8, page 21
Issue 4668: Section 8.1, page 31
Issue 4669: Section 8.3, page 33
Issue 4670: Section 10.4 Precondition and Goal/Example
Issue 4671: Section 12, page 46
Issue 4672: Figure 12-2
Issue 4673: Figure 13-3, page 60
Issue 4674: Need more UML graphical examples
Issue 4675: Section 1.5/Proof of Concept, page 11
Issue 4676: Section 2.1/ Basic Concepts, page 13
Issue 4677: Figure 3.2, page 18
Issue 4678: Figure 6.1, page 25
Issue 4679: Section 7.1/Precedes, page 29
Issue 4680: Figure 8.1, page 31
Issue 4681: Section 8.3, page 33
Issue 4682: Section 8.4, page 34
Issue 4683: Section 9.2 /Example
Issue 4684: Section 12.1 SPEM to UML Correspondence Table
Issue 4685: Figure 12.2, page 50
Issue 4686: Section 12.5, figure 12-3
Issue 4687: Section 12.8, page 79
Issue 4688: Section 12.6
Issue 4689: Typos in the current SPEM document
Issue 4695: trademark notification on page 2.
Issue 4696: .Section 1.2 Modeling Approach on page 7
Issue 4697: Translation table, Annex 1
Issue 4751: SPEM issue - InformationElement
Issue 4786: SPEM issue: URL to issues reporting form is '404'
Issue 4788: SPEM issue: Simplify Preface
Issue 4789: SPEM issue: acknowledgments
Issue 4827: Duplication of 'range' in XMI
Issue 4828: Remove DTD from the document
Issue 4829: Make profile icons available
Issue 4830: Combine classes for Goal and Precondition
Issue 4831: Inconsistent use of name 'ProcessComponent' with EDOC
Issue 4833: Use explicit references for MOF
Issue 4885: a Category should not inherit from ProcessComponent.
Issue 4886: Milestone as a metaclass
Issue 4887: Capturing distinct kinds of WorkProducts in the metamodel.
Issue 4889: Pre-defined UML stereotypes to be used in UML use case diagrams.
Issue 4890: Restriction on the model elements that can be annotated with Guidances
Issue 4891: Icon definition is missing in fig 12-1
Issue 4980: Issue about goals and preconditions
Issue 5086: 4668 makes no sense unless StructuralFeature and Attribute are included
Issue 5087: Figure 11-3 Decomposition of WorkDefinition
Issue 5215: SPEM FTF: Data types (p 2-3)
Issue 5216: SPEM FTF: Figure 3.2 (p. 3-2) and figure 7-1 (p. 7-2)
Issue 5217: SPEM FTF: Figure 3-2 (p. 3-2)
Issue 5218: Precedes dependencies (p. 6-3)
Issue 5219: Activity and step (p. 7-4)
Issue 5220: Transformation to a UML-profile (section 11)
Issue 5221: Standardization
Issue 4667: Figure 3.8, page 21 (spem-ftf)
Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde@orange-ftgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:
- Figure 3.8, page 21 A package cannot import a model element individually (an "Import" dependency (inherited from UML) cannot be used since the client and the supplier need to be Packages (see UML 1.4 and section 7.2) The UML association Package/importedElement/ModelElement need to be included in the SPEM_Foundation package.
Resolution: The SPEM spec does not imply that model elements can be imported individually. It is proposed to reject this issue
I don't see any justification for prohibiting the WorkProducts to have features. Attributes in WorkProducts may be useful to add extra information (such as the version number, creation date, etc). Each SPEM compliant family may define its own set of relevant attributes.
Resolution: We accepted this and voted on 14/1/2002, on the basis that this was a very simple change. However, issue 5086 points out that we were in error to do so because it is not a simple change at all. Therefore on 16/4/2002 we proposed to revisit the issue and to reject it.
"An Activity is owned by a ProcessRole that is the performer (or owner)" Mixing "performer" and "ownership" is very confusing. In the metamodel these two concepts should be clearly distinguished. The "performer" association should not "derive" from the feature/owner association. It's more natural to say that activities are owned by the process (a Package). Features (such as attributes) in roles could be used for another purpose: adding specific information on roles NOTE that this suggested modification need not to impact the UML profile.
Resolution: Accept the first part of the issue. Do not accept attributes on roles: SPEM has no attributes.
The possible states of work products are referenced in pre-conditions and goal but there is no declaration of such potential states in the SPEM metamodel. Solution: add a "validStates" attribute in the "WorkProduct" class.
"The SPEM profile... to give more detail to the work decomposition..." This is not true. Work composition in the SPEM metamodel is recursive (subWork/parentWork), so any detail of decomposition is expressible with the MM. This sentence should be removed.
Resolution: The group did not agree that this sentence should be deleted and rejected the issue on the grounds that the sentence is accurate as it stands. However, consideration of issue 4673 may impact this decision.
In the figure An Actor has attributes. Is this valid in UML 1.4? In the UML 1.4 specification it is only said that an actor may have interfaces.
In the issue "attributes" should read "operations". This is valid UML 1.4. The issue is a question; the answer is confirmed to be yes and supported by both Rational Rose and Softeam Objecteering. It is proposed to accept the issue but make no change to the spec as a result.
This very basic example CANNOT be expressed in the terms of the SPEM metamodel because there is no way to represent fork/joins. I don't see any valid justification for such limitation. A simple solution would be to add a "PseudoActivity" class, inheriting from Activity and having a "kind"attribute (choice, join, fork,...etc.).
Need more UML graphical examples (accompanied with its SPEM translation, using for instance a HUTN notation)
Mention an available implementation of the SPEM metamodel using the the France Telecom Univers@lis repository tool. Add a reference in Section 16: http: /universalis.elibel.tm.fr/site/
"Techniques are modeled by Guidance or Activity(see section 8.3)" In section 8.3 there is no statement regarding how to model Techniques with activities - Figure 3.2, page 18 Prefixes "ak_" and "pdk_" should be removed.
Prefixes "ak_" and "pdk_" should be removed.
This is consistent with UML 1.4. Can be removed for XMI purposes using enumerationUnprefix tag. This has been done for ak_ and pdk_ but needs to be done for pk_ (PrecedenceKind). Action: regenerate DTD with pk_ tag removed.
A guidance may apply to more than one model element (see the "Java Programming Guideline" in page 27) Multiplicity of the association should be 1..*
A short explanation of what is the meaning of finish-start and finish-finish is needed.
Role name "steps" should be renamed "step" (this is the usual convention)
"It may refer addtional...assistants...as additional input parameters..." Too complex. Why not an explicit "assist" relationship in the metamodel between a ProcessRole and an Activity? This will ease implementation of the SPEM metamodel. NOTA: No changes in the UML profile is implied with this change,
"A ProcessRole is responsisble for..." Too complex and unclear. Why not an explicit "responsibleFor" relationship in the MM? This will minimize the size of XMI files generated from SPEM.
Inputs and Outputs for processes are undefined (in contrast with inputs and output for activities which are defined in 8.2)
For clarity alternative representations should appear in the table. For instance UseCases to represent work definitions.
Resolution: Instead of modifying this table, noticing that the later table on page 11-9 duplicates almost all of its information, delete this table
Use <<baseClass>> instead of <<stereotype>> in dependencies.
The relationship between a CallAction and the "behavior" of an operation needs to be clarified.
The Model stereotype conflicts with the UML Model metaclass.
Clarify the meaning of "includes" dependencies in the SPEM UML profile
Resolution: Accept. This refers to the use of Use Case diagrams to show the relationships between roles and work definitions.
TYPO issues
- Section 1.5/UML page 8
"Software Process Engineering Model" should be replaced by
"Software Process Engineering Metamodel"
- Section 1.5/Workflow, page 10
"None of the these areas overlaps the SPE submission" should be
replaced by
"None of these areas overlaps the SPEM submission"
- Section 3.1, page 17
"The SPEM_Foundation:;Data_Types" should be replaced by
"The SPEM_Foundation::Data_Types"
- Section 3.4, page 22
Well-formedness rules need to be re-numbered.
- End of page 27
A dot is expected at the end of the sentence.
- Section 7.1/Categorizes
"Discpline" ==> "Discipline"
- Section 8.2, page 33
"ProcessRoke" ==>ProcessRole
1. trademark notification on page 2. Could you add a following sentence? "SDEM is a registered trademark of Fujitsu in Japan."
2.Section 1.2 Modeling Approach on page 7 Could you add "SDEM" as an example of M1 level.
3. Translation table, Annex 1 Regarding SLCP(ISO/IEC 12207) column, "Lifecycle model" has not been defined in a body of its specification except annex example. "Lifecycle model" of SLCP should not be described in the translation table, should it? And, I think that the SLCP has provided "Iteration". It better describe an "Iteration" on the SLCP Iteration column.
InformationElement in the SPEM specification section 7.1 seems to do nothing that cannot be done by WorkProduct. I believe it is redundant and should be deleted from the model.
Ref: http://www.omg.org/cgi-bin/doc?ptc/2001-12-06 on page 5 it says: All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form at http://www.omg.org/library/issuerpt.htm This page does not exist.
Ref: http://www.omg.org/cgi-bin/doc?ptc/2001-12-06
Suppress the Corba text that is of little relevance to this specification:
-page 11, what is CORBA
- and page 12-13: Corba spec..
Replace by nothing. Or if we need something, have a section
What is UML
and
UML 1.4 specification
instead (which seems more relevant that what is CORBA).
Note: refer to email correspondence with mr. Watson.
Accept. Andrew says "Please work up whatever you feel is appropriate and I'll take a look at it. I have an action to revise the UML preface words to reduce the amount it says about CORBA. I hope to get to this soon. Howeber, if you feel moved to write something that could be the basis for the preface for all OMG modelling specs then I'd be very likely to use it and buy you a beer in payment
Ref: http://www.omg.org/cgi-bin/doc?ptc/2001-12-06 page 14-15 ( numbered viii and ix) It is curious to find that the names of the people who actively contributed have disappeared, but the secondary participants, last minute reviewers or critics have remained. Either we leave just the company names and cut the people page 15, or (in IEEE style), we do list the active contributors page 14,... Steve Cook has spent one or two order of magnitude more time and 3 orders of magnitude more money on this than Mr. BHS...
1. Duplication of 'range' in XMI In the XMI and Rose metamodel the 'Multiplicity' has an explicit 'range' attribute in addition to the 'range' association end which causes a conflict. Proposed resolution: delete the attribute
2. Remove DTD from the document It's not human-readable and so should not be in the document but a separate file. Proposed resolution: delete Chapter 13 and refer to the separate file (which will remain normative).
3. Make profile icons available It would be useful to have bitmaps and Rose definitions for the standard icons as a non-normative 'supporting measure' to ease adoption and encourage consistency.
Goal and Precondition do not need to be separate classes. Could not the same object 'Design Model in state Ready' be used for both the Goal of one Activity and the Precondition of the following activity? By using exactly the same object one can more easily follow state-driven transitions. Proposed resolution: make use of ClassifierInState (added as part of the Activity metamodel extensions)
EDOC uses the name for something completely different: a (higher-level) (software) component that can enact a business process. There are cases where both metamodels need to be combined in the same repository and this causes needless scope for confusion. Proposed resolution: rename 'ProcessComponent' to 'ProcessModule' since it is not a Component in the conventional usage of software having well defined interfaces.
SPEM should use explicit references rather than leaving MOF to generate them, driven by non-navigable association ends. This is because non-navigability has a stronger effect in MOF than just not generating the references, which compromises the ability to perform 'where used' navigations. Adopting this approach will be consistent with UML and CWM metamodels.
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 <<category>> stereotype could be added in the UML profile.
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: 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.
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 <<document>> and <<UMLmodel>>). 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.
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 <<assist>> and <<perform>> 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 <<responsible>> stereotype.
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.
7. Icon definition is missing in fig 12-1 The icon used for denoting the User Models in figure 12-1 is not defined in 11.5 section.
In the SPEM, goals and preconditions are shown as constraints which are shown as owned by WorkDefinitions. This is inconsistent with the UML 1.4 in which constraints are owned by Namespaces. This makes the profile mapping invalid. To make the profile valid it is necessary to state that the constraint must be owned by a namespace: the associated ProcessPerformer would do ok, and also to clarify that the associations between WorkDefinition and Goal/Precondition are actually specialisations of the general constraint/constrainedElement association.
Issue 4668 suggested that WorkProducts can have attributes. However, SPEM does not include StructuralFeatures or Attributes. Issue 4668 therefore makes no sense unless StructuralFeature and Attribute are included.
4668 therefore makes no sense unless StructuralFeature and Attribute are included
I'm trying to map the assocations in Figure 11-3 "Decomposition of WorkDefinition" to those in Figure 7-1 "Process Structure Package" and I have 3 questions: 1. WorkDefinition has a direct association to itself in Figure 7-1 and Operation (to which WorkDefinition is mapped) in Figure 11-3 does not seem to have such direct corresponding association. Does this association map to Operation->ActivityGraph->CompositeState->ActionState->CallAction->Operation in Figure 11-3 ? 2. If the answer to the above question is yes then this question is: the self-assocation of Operation in Figure 11-3 passes through ActionState (to which Step from Figure 7-1 is mapped to) but the self assocation of WorkDefinition in Figure 7-1 does not seem to pass through Step, why ? 3. Step in Figure 7-1 is mapped to ActionState in Figure 11-3 and Step doesn't seem to have any sub-component. In Figure 11-3 ActionState has a composition assocation with Action (+entry), what does this represent ?
Data types (p 2-3) Figure 2-2 (p. 2-3). We think that the stereotype <<datatype>> applied to Boolean should be sub-stituted for <<enumeration>>.
Figure 3.2 (p. 3-2) and figure 7-1 (p. 7-2) In our opinion, WorkProduct should have a role as responsible. Although figure 3-2 considers a "responsibility" association between Role and WorkProduct, this association is not retained in the metamodel definition. Specifically, the process structure package representation (figure 7.1, p. 7-2) does not depict any association meaning "responsibility" between WorkProduct and ProcessPerformer or ProcessRole. Proposed resolution: Incorporate "responsibility" associations between ProcessPerformer and WorkProduct in figure 7-1.
Figure 3-2 (p. 3-2) We believe that it is better to consider that an activity may be performed by a collaboration of more than one role. In this case, two different associations should be provided in order to distinguish between "responsible" and "participant".
Although the precedes dependency may be enough for the family of software development proc-esses whose modelling is the main interest of SPEM, it should be noted that finish-start and finish-finish precedence relationships are clearly insufficient when detailed software processes are to be modelled. Proposed resolution: Incorporate other precedence relationships to the SPEM definition. See, for instance: Schlenoff, C., Gruninger M., Tissot, F., Valois, J., Lubell, J., Lee, J., The Process Specification Language (PSL): Overview and Version 1.0 Specification, NISTIR 6459, National Institute of Standards and Technology, Gaithersburg, MD (2000). Ribσ J.M; Franch X.: Building Expressive and Flexible Process Models using an UML-based approach. LNCS, Vol. 2077. Springer-Verlag (2001).
Activity and step (p. 7-4) The specification document states: "Although it is not explicitly prohibited, an Activity does not normally use the subWork structure inherited from WorkDefinition; instead decomposition within Activity is done using Steps". Steps are atomic elements. In practice, this constraints activity de-composition to two levels. We believe that this is not enough to model detailed and fine-grained processes. Proposed resolution: Remove Step from the metamodel and use the association parentwork-subwork to model Activity decomposition too.
Transformation to a UML-profile (section 11) A model built using the SPEM UML-profile does not conform necessarely with the SPEM metamodel (for instance, since the UML ModelManagement package is retained in the SPEM UML-profile definition, a model can define instances of the Package::importedElement association, which are not part of the SPEM metamodel). Proposed resolution: Incorporate constraints to restrict the use of the UML elements within the SPEM UML-profile.
Standardization SPEM is a MOF-based metamodel (p 1-2) which is defined as an extension of a subset of UML (SPEM foundation; p 1-3). However, SPEM cannot be considered as a conservative extension of the UML metamodel since the SPEM foundation does not keep the semantics of the UML meta-model (i.e., some elements of the SPEM foundation have not the same structure, associations, an-cestors and, hence, semantics as their counterparts in the UML metamodel). This lack of conformance with UML compromises standardization. In particular, the SPEM foundation elements cannot rely on the semantics of the UML metamodel. As a result, the semantics of the SPEM UML-profile are not well-defined and the portability of SPEM models is impaired. * Example 1: A UML metamodel Association, as a GeneralizableElement, inherits several at-tributes (e.g., isRoot, isLeaf). A SPEM Association does not inherit them (since it is not a Gen-eralizableElement). A UML tool may require a value for those attributes in Association in-stances. * Example 2: The UML metamodel defines several constraints on Package regarding the asso-ciation importedElement. Since this association is not defined in SPEM, those constraints make no sense. Proposed resolution: 1. Keep UML metamodel ancestors for all the SPEM foundation elements. 2. Keep UML metamodel associations involving SPEM foundation elements (this includes asso-ciations with elements not belonging to SPEM foundation) 3. Incorporate constraints restricting the semantics of the UML metaelements in a SPEM model (e.g., Add to Package, the constraint: self.importedElement->size=0)
Reject. The SPEM approach follows normal practice for extensions to the UML 1.4 metamodel