1. Specification Development and Review Team
OASIS OSLC PROMCODE TC Domain Model Revisited and Use Cases Development Plan of Specifications (Memorandum)
Specification Development and Review Team
Mikio Aoyama, Kazuhiro Funakoshi, Yoshio Horiuchi, Tsutomu Kamimura, Shigeaki Matsumoto, Arthur Ryman, Kazuo Yabuta, Hiroyuki Yoshida
2014/07/21, 08/05, 08/19, 9/02, 9/16, 9/19, 10/01,11/11, 11/25, 12/10

2. Contents Upcoming TC Meeting Schedule Proposed Domain Model Revised
Use Cases and Scenarios
Resources Associated with the Scenarios
TOC of the Draft Specifications
Time Line Revised
References

3. Upcoming TC Meeting Schedule Proposed
オブジェクト指向'98シンンポジウム チュートリアル
Upcoming TC Meeting Schedule Proposed
1998年9月16日
Schedule
Date/Time [EST]
Date/Time [JST]
Note 16
TC Meeting
7.00 p.m., Dec. 9
9:00 a.m., Dec. 10 17
7.00 p.m., Dec. 23
9:00 a.m., Dec. 24 18
7.00 p.m., Jan. 6
9:00 a.m., Jan. 7 19
7.00 p.m., Jan. 20
9:00 a.m., Jan. 21 20
7.00 p.m., Feb. 3
9:00 a.m., Feb. 4 21
7.00 p.m., Feb. 17
9:00 a.m., Feb. 18
Note: Start of US DST: March 8, 2015 (Sun)

4. Domain Model Revised

5. Domain Model v. 2.31(Revised Nov. 25)

6. Domain Model v. 2.30(Revised Nov. 11)

7. Rationale of Proposed Revision to Domain Model [Nov. 11]
Changes arising from Use Cases
Relationship between Plan and Report should be explicitly specified -> Add association: correspondsTo [reportsOn]
Structure of Issue and its Collection
Add IssueCollection similar to ManagedItemCollection
Relate IssueCollection to Project similar to ManagedItemCollection: belongsTo
Add an attribute, RaisedDate, to Issue
State of Issue: Open to users due to its variety in each project (OSLC CM, PMBOK)
Add a property “State” defined by URI like UnitTupe

8. Proposed Revision to Domain Model v. 2.26
State
<-belongsTo
IssueCollection
collects
<-correspondsTo
+raisedDate:
DateTime

9. Domain Model v. 2.26(Revised Sep. 25)

10. Domain Model v. 2.25(Revised Sep. 30/Oct. 1)

11. オブジェクト指向'98シンンポジウム チュートリアル
Issues and Proposed Changes to Domain Model Discussed at the TC on 9/17
1998年9月16日
Update of domain model
Change name:
MeasurementCriteria -> Target
Consistent definition of attributes:
Project -> Add properties (identifier, title, description, plannedStartDate, actualStartDate, plannedEndDate, actualEndDate)
Issue: Need to discuss whether state should be added
Multiplicity: Refer “Properties of Attributes in UML Class Diagrams”
Default value is 1, eliminate * after TypeName
“O..1” represents possibility of null
+ AttributeName : TypeName [*]
Metrics and MeasureType:
Clarify the rationale of using “Measure”
Scenarios
Refine the scenarios by adding concrete resources, and show the usage of domain model
Validating the domain model

12. Reference Properties of Attributes in UML Class Diagrams
Multiplicity [Default value is 1]
1 - this attribute has a single value of the specified Type.
this attribute can have a value of null.
* - this attribute's value is a collection of values.
1..* - this attribute's value is a collection that contains at least one value.
n .. m - this attribute's value is a collection that contains between n and m values.
Reference: Properties of Attributes in UML Class Diagrams,

13. On Use of Measure and Metrics SWEBOK
Guide to the Software Engineering Body Of Knowledge (SWEBOK), Version 3, 2014
Chapter 8, Software Engineering Management
6. Software Engineering Measurement
Key terms on software measures and measurement methods have been defined in [ISO ] on the basis of the ISO international vocabulary of metrology [ISO93]. Nevertheless, readers will encounter terminology differences in the literature; for example, the term "metrics" is sometimes used in place of "measures.“
6.2. Plan the Measurement Process
Select measures. Candidate measures must be selected, with clear links to the information needs. Measures must then be selected based on the priorities of the information needs and other criteria such as cost of collection, degree of process disruption during collection, ease of analysis, ease of obtaining accurate, consistent data, and so on [ISO : and Appendix C].
Reference:

14. On Use of Measure and Metrics ISO 15939:2007 Appendix
オブジェクト指向'98シンンポジウム チュートリアル
On Use of Measure and Metrics ISO 15939:2007 Appendix
1998年9月16日
A.2.3 Base measure
A measure defined in terms of an attribute and the method for quantifying it. (A measure is a variable to which a value is assigned.) A base measure is functionally independent of other measures. A base measure captures information about a single attribute. Data collection involves assigning values to base measures. Specifying the expected range and/or type of values of a base measure helps to verify the quality of the data collected.
A Unit of measurement
A particular quantity, defined and adopted by convention, with which other quantities of the same kind are compared in order to express their magnitude relative to that quantity. Only quantities expressed in the same units of measurement are directly comparable. Examples of units include the hour and the meter.
Reference: ISO, ISO/IEC 15939:2007: Systems and Software Engineering –
Measurement Process, 2007.
ISO 9126 Metric
ISO Measure

15. Domain Model v. 2.4(Revised Sep. 16)
オブジェクト指向'98シンンポジウム チュートリアル
Domain Model v. 2.4(Revised Sep. 16)
Add attributes:
identifier
title
description
plannedStartDate
actualStartDate
plannedEndDate
actualEndDate
1998年9月16日
(sizeOfScopeItem) FP
Title: login screen
actualSize: 10
State? FP
Change mame:
MeasurementCriteria
-> Target
metric
KLOC
“CodeSize”

16. Domain Model Issues Related to EMS in Domain Model
Commonality and Difference between EMS and PROMCODE
Policy: If PROMCODE use a concept which is defined in EMS, PROMCODE should not define it, but refer it.
Use of “Estimation in PROMCODE”:
Estimation in EMS is out of scope of PROMCODE. The “planned” value in PROMCODE is a value agreed between an acquirer and an supplier after estimation
Measurement/Measure&Mertics/Measurement
Use consistent model
Measure of ScopeItem is not defined
Associate MeasureType and UnitType to Project
Unification of Vocabulary
Use the same vocabulary to those of the same meaning
metric, unitOfMeasure

17. Domain Model Comparison of EMS and PROMCODE
Estimation and Measurement
Use Estimation and Measurement i
Estimation is out of scope. Planned is a value for agreement between Acquirer and Supplier. Value might be based on estimation, but estimation id not in the included in the activities of project control.
Metric
metric metric:Sloc (URI)
Measure value:Decimal ->
MeasureType [refer to]
MeasurementCriteria
Unit of Measure
unitOfMeasure unit:Loc (URI)
UnitType <-[referred by] Measure
unit ->unitOfMeasure
Measurement
Measurement　
numericValue xsd:double
->
ScopeItem
Unit of PlannedSize is undefined
->Associate MeasureType and UnitType to Project (A unique measure across the project)

18. Domain Model v. 2.2(Revised Sep. 2)

19. Domain Model Revisited for v 2.2 on 9/2
オブジェクト指向'98シンンポジウム チュートリアル
Domain Model Revisited for v 2.2 on 9/2
1998年9月16日
Structure around ManagedItem
Attributes of ManagedItem: Add type for classification
Add “ManagedItemCollection” as a collection of ManagedItem, which represents a collection of status, or snapshot, of the project
Attributes: Add identifier and title
Add “Plan” and “Report” as subclasses of ManagedItemCollection:
Plan reflects an order from the acquirer to Supplier when the project is started
Report reflects a report compiled from the snapshot in ManagedItemCollection
Add “Project” as a reference to the project under management
The entity Project is only for reference, and is considered as out of scope of the PROMCODE domain model

20. オブジェクト指向'98シンンポジウム チュートリアル
Domain Model (Aug. 6)
オブジェクト指向'98シンンポジウム チュートリアル
1998年9月16日

21. Domain Model Revisited (2/2)
オブジェクト指向'98シンンポジウム チュートリアル
Domain Model Revisited (2/2)
1998年9月16日
Structure Measure/Measurement
Add “MeasurementCriteria” as a criteria of Measure
Add attributes of type and title to Measure
Title: Bug density, Type: NoOfBugsPerKLOC, Unit: 1, Value: 3
Attributes
Measurement
MeasurementCriteria
Measure
Title +
Identifier NA
Type

22. Use Cases and Scenarios

23. Use Cases and Scenarios Usage Context of Software Supply Chain
オブジェクト指向'98シンンポジウム チュートリアル
1998年9月16日
Project Context
Context: Data Interface between Acquirer and Supplier
Supply chain is formed by chaining the Acquirer and Supplier through the PROMCODE interface
Scope of time: Assume the plan is completed and the project scope is defined, which implies that scope definition including planning is out of scope of PROMCODE
Acquirer
Supplier
Acquirer
Supplier
Organization A
Organization Bn
Organization
Cnm * *

24. Use Cases and Scenarios Deployment Patterns and High-level Scenario
オブジェクト指向'98シンンポジウム チュートリアル
1998年9月16日
Deployment Pattern A
Deployment Pattern A is appropriate for PROMCODE
PROMCODE Usage Conditions
Assumption
The Acquirer and Suppliers use different PM tools including Excel of different schema.
Use of REST
High-level Scenario
Supplier pushes a report in PROMCODE resources to a PROMCODE Provider deployed in a Web server.
Acquirer collects the reports from the PROMOCDE Provider as a PROMCODE Consumer, and presents the project status on its dashboard. ()
Supplier
Acquirer
PROMCODE
Dashboard
Tool S
Supplier 1
Tool S1 P C
(Tool A)
Push
Pull
Report
(Web
Service)
Report
P: Provider, C: Consumer
Deployment Pattern B
Supplier
Acquirer
Push
P/C
Deployment Pattern C
Supplier
Acquirer
Pull P C

25. Use Cases and Scenarios Use Cases (Top Level)
オブジェクト指向'98シンンポジウム チュートリアル
Use Cases and Scenarios Use Cases (Top Level)
1998年9月16日
Use vocabulary practically common in project management in contracted delivery
Consistent with global standards: PMBOK, ISO 21500:2012
　Project Initiation and Planning
　Project Execution
Acquirer
Supplier
　Project Closing

26. Use Cases and Scenarios Use Cases: Project Execution
オブジェクト指向'98シンンポジウム チュートリアル
Use Cases and Scenarios Use Cases: Project Execution
1998年9月16日
Use vocabulary practically common in project management in contracted delivery
Consistent with global standards: PMBOK, ISO 21500:2012
Project Execution and Control
　Project Start
　Status Reporting
　Status Aggregation
Acquirer
Supplier
Project Closing

27. Use Cases and Scenarios Use Cases: Project Execution
オブジェクト指向'98シンンポジウム チュートリアル
Use Cases and Scenarios Use Cases: Project Execution
1998年9月16日
Use vocabulary practically common in project management in contracted delivery
Consistent with global standards: PMBOK, ISO 21500:2012
Project Execution
　Schedule Problem
　Quality Problem
Acquirer
Supplier
Re-schedule/Re-planning

28. Use Case “Project Start with PROMCODE” [Nov. 25]
Preconditions
Scenario
An acquirer registers “Project ID”, “Project plan”, and “Mapping Rules” to the PROMCODE Consumer.
The acquirer generates a data in the PROMCODE model with the PROMCODE Consumer and stores it to a DB.
A supplier registers the “Project ID”, “Project Plan”, and “Mapping Rules” to the PROMCODE Provider.

29. Use Case “Project Execution with PROMCODE” [Nov. 25/Dec. 10]
Preconditions
The acquirer and supplier respectively register “Project ID”, “Project plan”, and each “Mapping Rules” to the PROMCODE.
The supplier agreed to push the Report to the PROMCODE Provider on the Web until the specified date and time.
The acquirer and suppliers agreed to the schema of the “Report” to be reported from suppliers to the acquirer.[要補足説明: 差分，スナップショット]
Scenario
A supplier registers its “Report” data to the PM tool S1.
The supplier converts the “Report” from the PM tool S1 to the PROMCODE resources.
The supplier pushes the “Report” in the PROMCODE schema to the PROMCODE Provider on the Web.
The Acquirer, a PROMCODE Consumer, pulls the collection of “Reports” from the PROMCODE Providers.
The Acquirer converts the collection of the “Reports” in the PROMCODE resources to the PM tool A.
The Acquirer reviews the “Report” on the PM tool A.

30. Use Case “Project Execution with PROMCODE” Review and Actions for Schedule Problem [Dec. 10]
Schedule Delay
PM-A compares previous report and current report and highlights the difference.
Reviews the difference and raises a concern if the following is observed.
No progress from the previous report
Risk of not meeting a schedule emerges with the current pace of progress.
May use past data on productivity to project risk.
PM-A interacts with PM-S on further update.
Reasons for delay
Outlook of meeting a schedule.
Based on the interaction, PM-A takes one of the following actions.
No formal action, but with notice on the situation to monitor.
Raise an issue on the situation and create actions
Escalate to stakeholders for possible plan change.
If it is necessary, plan will be changed [See details in “Plan Change” scenario]

31. Use Case “Project Execution with PROMCODE” Review and Actions for Quality Problems [Dec. 10]
Quality Concern
PM-A compares previous report and current report and highlights the difference.
Reviews the difference and raises a concern if the progress is not sufficient and there is a risk of not meeting quality goal.
PM-A interacts with PM-S on further update.
Reasons of the current problem
Outlook of meeting a goal
Assess the impact to the overall project.
Based on the interaction, PM-A takes one of the following actions.
Raise an issue on the situation and create actions
Escalate to stakeholders for possible plan change.
If it is necessary, actions will be taken place [see details in “Quality Action” scenario]

32. Use Case “Project Execution with PROMCODE” Plan Change[Dec. 10]
About Plan Change: “Plan change” may change
ScopeItem including “PlannedSize”, and entities in the ScopeItem
WorkItem including PlannedEndDate, and
Artifact
Scenario of Plan Change [Change of Scopeitem]
The Acquirer determines to change the ScopeItem
The Acquirer notifies the changes of ScopeItem and associated new plan to appropriate Suppliers.
The Supplier reviews the new ScopeItem and associated new plan, and notify its agreement to the sustimer.a
The Acquirer and Supplier get agreed.
The Acquirer set the new plan to the “plan”.
The Acquirer and Supplier review the ScopeItem revised, and associated WorkItem nd WorlItem if necessary

33. Use Case “Project Execution with PROMCODE” Plan Change[Dec. 10]
スコープ(ScopeItem), 納期，予算，成果物(Artifact)の変更
ScopeItem: 要素の増減とサイズの変更
納期変更: 延伸
予算: 追加
成果物: 要素の増減とサイズの変更[ScopeItemによる]
シナリオ[スコープの変更]
A: ScopeItemの(要素の)変更を決定
A: 削減したScopeItemの内容とPlanを該当するSへ通知
S: 通知されたScopeItemの内容とPlanをレビューし，妥当であれば，その旨をAへ通知
S&A: Planを合意する
A: 合意したPlanを新しいPlanとする
A&S: 変更されたScopeItemに対応して必要であればArtifactとWorkItemを変更

34. Use Case “Publishing Issue(s) with PROMCODE” [Nov. 25]
Precondition
Acquirer creates an instance of “IssueCollection”.
Scenario
A Supplier registers an “Issue(s)” to the PROMCODE Provider.
The PROMCODE provider notifies the registration of the “Issue(s)” to the Acquirer.
The Acquirer, a PROMCODE Consumer, pulls the published “Issue(s)” from the PROMCODE Provider.
The Acquirer reviews the “Issues”.

35. Use Case “Project Start” Revised [Nov. 11]
Obsolete
Preconditions
Project Plan is determined and agreed by both acquirer and supplier.
The size measure and its unit of Scope are respectively defined by “MesureType” and “UnitType” , which are specified by the URIs.
The measure and its unit of the Artifact are respectively defined by “MesureType” and “UnitType” , which are specified by the URIs.
Scenario
Acquirer creates a Project resource, and sets the measure and its unit of project scope to typeOfMeasure and unitOfMeasure of Project.
Acquirer creates a ScopeItem.
Supplier creates an Artifact and its subclasses to meet the ScopeItem, and allocates the Artifacts to the ScopeItem.
Supplier creates a set of WorkItem to produce the Artifacts, and allocates the WorkItems to the Artifacts.
Supplier appoints a Person as a representative to the ScopeItem.

36. Use Case “Project Execution with PROMCODE” Simple Use Case
Obsolete
User roles
Project manager of acquirer (PM-A)
Project manger of supplier (PM-S)
Pre-condition
A legal contract to bind an acquirer and a supplier is handled separately.
There is no cascading of acquirer-supplier relationships.
Project environment of an acquirer and a supplier are not shared; i.e., project environment of a supplier is not accessible to PM-A and therefore, project information needs to be sent to PM-A for project management by an acquirer.
Steps
PM-A and PM-S work together to define ScopeItems, WorkItems and artifacts as a plan and establish agreement between them.
Details of steps in establishing agreement may vary and we will not specify them further. .
PM-S updates on regular basis actual values of properties of WorkItems and of measurements and measures attached to artifacts.
This can be done by PM-A requesting a report to PM-S or by PM-S posting a report to an agreed location.
PM-S sends an update as a Report to PM-A.
PM-A reviews updates and takes actions such as such as creating and managing Issues. In particular,
Review the possibility of schedule delay
Review Quality
Details of these will be elaborated in the next pages.
Repeat Steps 2-4 as necessary
Conduct acceptance review and close a project

37. Resources Associated with the Scenarios

38. Resources Created before “Start Project”(1/3)[Nov. 11]
Attributes
Creator
Value
Project
Identifier
Acquirer
Title
Description
plannedStartDate
plannedEndDate
typeOfScopeItemSize
URI
unitOfScopeItemSize
Resource
Attributes
Creator
Value
Plan
Identifier
Acquirer
Title
Date
belongsTo
collects

39. Resources Created before “Start Project”(2/3)[Nov. 11]
Attributes
Creator
Value
ScopeItem
Identifier
Acquirer
Title
Description
plannedSize
isPartOf
Resource
Attributes
Creator
Value
WorkItem
Identifier
Acquirer
Title
Description
plannedStartDate
plannedEndDate
isPartOf
requiredBy
representedBy
Supplier

40. Resources Created before “Start Project”(3/3)[Nov. 11]
Attributes
Creator
Value
Artifact
Identifier
Acquirer
Title
Description
isPartOf
producedBy
Resource
Attributes
Creator
Value
Target
Identifier
Acquirer
Title
determines
designedFor
Resource
Attributes
Creator
Value
Measure
Identifier
Acquirer
Title
typeOfMeasure
unitOfMeasure

41. Resources Created/Changed in “Status Reporting”(1/2)[Nov. 11]
Attributes
Creator
Value
Report
Identifier
Acquirer
Title
Supplier
Date
correspondsTo
belongsTo
collects
Resource
Attributes
Creator
Value
WorkItem
actualStartDate
Supplier
actualEndDate
Resource
Attributes
Creator
Value
Measurement
Date
Supplier
Resource
Attributes
Creator
Value
Measure
Supplier

42. Resources Created/Changed in “Status Reporting”(2/2)[Nov. 11]
Attributes
Creator
Value
IssueCollection
Identifier
Acquirer
Title
Supplier
Date
collects
Resource
Attributes
Creator
Value
Issue
Identifier
Acquirer/Supplier
Title
raisedDate
Description

43. Resources Created/Changed in “Project Closing”[Nov. 11]
Attributes
Creator
Value
Project
actualEndDate
Supplier
Resource
Attributes
Creator
Value
ScopeItem
actualSize
Supplier

44. TOC of the Draft Specifications

45. TOC of Draft Specification (1/2)
TOC Based on OASIS TOSCA
PIC
PROMCODE Spec 1.0
1. Introduction
Mikio
2. Interface Specification Design
2.1 Dependencies on Other Specs
4.2 Compliance ?: Core, FOAF,
2.2 Notational Conventions
2.3 Normative References
5. References
2.4 Non-Normative References
2.5 Typographical Conventions
2.6 Namespaces
4.2.2 Namespaces
2.7 Extensibility ?
3. Core Concepts and Usage Patterns
3.1 Core Concepts
Mikio,
Matsumoto
Supply Chain Concept
2. PROMCODE Modeling Framework
3.2 Use Cases
New

46. TOC of Draft Specification
TOC Based on OASIS TOSCA
PIC
PROMCODE Spec 1.0
4. PROMCODE Domain Model
Yoshida
3. PROMCODE Domain Model
4.1 Domain Model
3.1 Domain Model
4.2 Examples of Project Models
3.2 Examples of Project Models
5. PROMCODE Resource Definitions
Wakao,
Horiuchi
4. PROMCODE Service Specification
5.1 PROMCODE Resource Definitions
4.3 PROMCODE Resource Definitions
6. PROMCODE Service Specification
4.4 Service Provider Capabilities
7. Common Practices for Adoption
4.5 Common Practices for Adoption
Appendix: Example
Appendix: Vocabulary, Resource Shape
Funakoshi,
Arthur

47. オブジェクト指向'98シンンポジウム チュートリアル
Time Line Revised
1998年9月16日
Milestone
Initial Plan
Revised
TC Launched
Mar. 25, 2014
Start Writing Initial Working Draft
Aug. 5, 2014
Initial Working Draft
May 26, 2014
Sep. 16, 2014
Committee Working Draft
Jun. 30, 2014
Oct. 2014
Committee Spec. Public Review
Jul. 31, 2014
Nov. 2014
Committee Specification
Sep. 15, 2014
Dec. 2014
Candidate of OASIS Standard
Feb. 2015
OASIS Standard
Mar. 2015
Specification Development Team:
Aoyama, Funakoshi, Horiuchi, Matsumoto, Wakao, Yoshida
Specification Review Team: Development Team and
Kamimura, Ryman, Yabuta

48. References
[ 1] R. Cyganiak, et al. (eds.), RDF 1.1 Concepts and Abstract Syntax, W3C
Recommendation, 25 February 2014,
[ 2] R. Cyganiak, An RDF Design Pattern: Inverse Property Labels, Jun. 2006,
[ 3] A. G. Ryman, OSLC Resource Shape: A Language for Defining Constraints on
Linked Data, .
[ 4] A. G. Ryman, Vocabulary Annotation Vocabulary, Sep. 2013,
[ 5] A. G. Ryman, Resource Shape 2.0, W3C Member Submission, Feb. 2014,