## 4 Case Studies: Using DSM to Address GPM Limitations in DPD
### Modeling a Process with GPM (OPM)  
We now model the process description of Table 1 using OPM. (Disclaimer: the approach presented in this section is not the only possible OPM modeling approach. Yet, we believe it is fairly representative of the modeling effort using OPM (if anything, we believe the approach we present is simpler compared with others).) OPM identifies object, process, and state as three fundamental entity types. Table 2 presents the analysis of the process description for OPM modeling. \begin{table}
\begin{tabular}{p{341.4 pt}} \hline \hline
**Process Description to Be Modeled (Extract)** \\ \hline
1. A manufacturing activity produces the component ComponentA, according to a component specification. 2. Functional testing activity verifies ComponentA with respect to its functional requirements. 3. Environmental testing activity approves the component with respect to its environmental operating conditions. 4. A system integration activity integrates the physical component—after it was verified with respect to its functional and environmental aspects—with a designated software version. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Process description to be modeled. We create the identified elements in the OPM tool OPCAT, shown in Figure 1. The modeling toolbox is found at the bottom of the screen; a navigation panel is on the left; the OPD diagram--featuring the elements--is centered; and the corresponding OPL natural-language description is below the OPD. Elements are created by selecting the appropriate tools from the toolbox. It takes 4 steps to create the 4 processes, 3 additional steps to create the objects. States are added to an existing object, by performing 4 additional steps. So far, modeling did not require any cognitively demanding decision making, and was rather straightforward. Now, we try to establish the process description flow. The links that are relevant for connecting Objects and Processes appear in the rightmost batch \begin{table}
\begin{tabular}{c c c c c} \hline
**Process Description** & **Process** & **Input/Output** & **Object** & **Object State** \\ \hline
1 & Manufacturing & Input & ComponentA specification &? (Unspecified) \\ \cline{3-5}  & & Output & ComponentA & Produced \\ \hline
2 & Functional testing & Input & ComponentA & Produced \\ \cline{3-5}  & & Output & ComponentA & Verified functional [our state designation for “verified with respect to functional requirements] \\ \hline
3 & Environmental testing & Input & ComponentA & Produced \\ \cline{3-5}  & & Output & ComponentA & Verified environmental [our state designation for “verified with respect to environmental operating conditions”] \\ \hline
4 & System integration & Input & ComponentA & Verified environmental, Verified functional \\ \cline{3-5}  & & Input & Software &? (Unspecified) \\ \cline{3-5}  & & Output & ComponentA & Software integrated \\ \hline \end{tabular}
\end{table} 
Table 2: Process description analyzed for Object Process Methodology (OPM) modeling. Figure 1: OPM diagram in OPCAT modeling tool, after adding object, process, and state elements. of the toolbox (enclosed using red outline in Figure 1). There are nine link-types: seven of them can be used to connect objects and processes, and five of them can be used to connect states and processes. These representational elements are directional, i.e., they need to be used in the right direction (e.g., either from process to object, or from object to process). This is where decision-making becomes a necessity, and the process modeling itself--and not process design--begins to demand cognitive effort. (We remind readers that this is true to the modeling approach we chose to implement. In other implementations, a demanding cognitive effort concerning modeling may appear even earlier. For example, if one would have chosen to create objects and processes, connect them, and only then create states for the objects and use them, this would have required an increased effort.)