## 4 Case Studies: Using DSM to Address GPM Limitations in DPD
### Modeling a Process with GPM Considering Insight from DSM  
We can use the DPD ontology of PROVE to make a significant reduction of the cognitive modeling problem (of selecting a single modeling tactic from the various alternatives). PROVE's domain ontology allows a process only to use or deliver objects (in PROVE's terminology these are called artifacts; and we use the terms interchangeably), and not to consume objects. Furthermore, its ontology expects artifact states to be explicitly mentioned. Accordingly, we limit our use of OPM links to the instrument-link used from a state to a process, to depict process dependency in an object with a specific state; and to the result-link used from a process to a delivered object's state, to depict a process yielding an object in a specific state. We note that this exercises two different OPM link types. This approach is based on the modeling alternative presented in Figure 8; the result of consistently applying this alternative as a modeling pattern to the entire process description is shown in Figure 9. Obviously, modeling the entire process description to achieve this result would have been considerably more demanding without selecting an ontology-informed tactic. At first glance, the diagram in Figure 9 presents a reasonable model of the process description. However, this model is semantically incorrect: according to OPM, an object is allowed to be in one state at any given time; and therefore, the \"System integration\" process--which according to the process description requires ComponentA to be \"Verified functional\" as well as \"Verified environmental\"--is interpreted in the OPL description as \"requires either Verified environmental ComponentA or Verified functional ComponentA\". That is an incorrect formal model of the given process design! This conflict between OPM's visual representation and OPM's methodology suggests that OPM is insufficient to model our domain. We look for the solution in the DPD domain ontology of PROVE, taking the following approach to solve the above conflict. PROVE's ontology views states as attributes, allowing for multiple attributes to be exhibited by the object simultaneously--manifesting another DPD concept defined by PROVE: the \"composite state\" mechanism. The composite state of an object is considered the set of all its attributes (alternately, the \"elemental states\"); and it embeds the information about the object--throughout the development process--into the object itself, using these attributes and in agreement with object-oriented modeling paradigms. Accordingly, instead of mapping a designated object state to the OPM element-type \"state\", we map it to a more elaborate modeling construct, which is to be associated with the OPM object as an attribute. The result, as projected directly on the aforementioned conflict, is shown in Figure 10. It shows that the relevant model segment is now interpreted (in the OPL description) as \"System integration requires Achieved Verified environmental and Achieved Verified functional\", with the two attributes being \"exhibited\" by Compo  
Figure 9: Complete process description OPM model, after making use of Process Oriented Viewpoint for Engineering (PROVE) methodology. nentA (A DPD domain-specific representation of the OPM text may be used to offer a more \"user-friendly\" statement to the modeler, e.g., \"System integration requires Achieved Verified environmental ComponentA and Achieved Verified functional ComponentA.\"). The modeling construct in Figure 10 is a mechanism to implement PROVE's composite-state ontological concept in OPM. This mechanism was just shown as a necessity in order to represent the provided process description correctly as an OPM model. However, this mechanism presents a complicated construct, which requires 4 steps for each state-definition instead of a single step.