Remodelling Process Input Specification

[FlavioRizzolo]

Process Input Specification specifies types of inputs for Process Design (and Process Design can have multiple Process Steps associated with it (see diagram below). Then how do we know which input corresponds to which of these multiple Process Steps? Currently, Process Input Specification is a collection of inputs for a Process Design which has multiple Process Steps, but there is no way which input is for which Process Step. Similarly, Process Input Specification is not aligned one to one with Process Step, it describes a collection inputs and we don’t have the specificity of saying which one is which.

One way to fix this is to make one-to-one relationship so that one Process Input Specification is associated with single input

[InKyungChoi]

Related issue:

why sub-types of inputs are "attributes" for Process Input Specification (design-time) while sub-types of inputs are "classes" for Process Input (run-time)?

[FlavioRizzolo]

Proposed solution:

• Added three sub-classes of ProcessInputSpecification
• Added one association (uses) from Process Step to ProcessInputSpecification
• Changed cardinalities (in red)
• Proposed name changes (in red)
• Proposed removing one redundant association (implemented by)

[JALinnerud]

Association between Process Design and Process Input Specification. I prefer has. Association between Process Step Instance and Process Input. I prefer uses.

[InKyungChoi]

The cardinality "1..*" between Process Step and Process Input Specification - is it because Process Step can have multiple Process Steps in it? If so, do we not have the same issue of not knowing which input is for which step?