On the third layer of the SOM enterprise architecture, resources responsible for carrying out the tasks defined in the business process layer are specified. The metaphor of a socio-technical system consisting of personnel, machines & plants, and business application systems is guiding the modeler in perceiving the real world and delimiting the relevant aspects. Again, a multi- view approach is utilized for the specification of business application systems. Two viewpoints, Schema of Conceptual Classes and Schema of Task Classes comprise a business application system specification. The modeling languages of both viewpoints can be derived by a projec- tion onto the business application system meta model. Figure 54 schematically illustrates the modeling scenario for SOM business application system modeling on the resource layer.
SOM Business Application System Specification
Real World Information Processing Tasks Specify Business Application Systems Socio-technical Modeler (Subject) y b _ d e d i u g _ si s e u s r u p Instance_of SOM Modeling Tool
looks_at Mapping Application System meta model Schema of Task Classes System Schema of Conceptual Classes
Figure 54: Modeling Scenario for the SOM resource layer
7.2.2 Step II: Modeling Language
The second step of MUVIEMOT focuses on the specification of the modeling language by considering three aspects: 1) the meta models, 2) the viewpoints, and 3) viewpoint-specific attributes (cf. section 6.3.2). The business process meta model of the SOM business process layer has already been introduced (see Figure 44). Also, section 7.1.2 described the constituents and the semantics of the multiple viewpoints on a SOM business process model. Considering the third aspect of the modeling language step, i.e., viewpoint-specific attributes, additional information has been specified.
Depending on the viewpoint, SOM utilizes different notations for business transactions. Within the decomposition schemata, business transactions are visualized as rounded rectan- gles in a tree-based hierarchy of decompositions. In the Interaction Schema and the Task-Event Schema, however, business transactions are visualized by means of relations, i.e., as directed arrows indication the transaction from outgoing business objects to ingoing business objects, or
sending tasks to receiving tasks in the Task-Event Schema, respectively.
The meta model of the resource layer (see Figure 46) and the modeling language and se- mantics of the two resource layer viewpoints have been specified in section 7.1.3. Viewpoint- specific attributes are realized for the transformation of business transactions. If transformed into a Schema of Task-Classes, business transactions are visualized by means of a relation con- nected by the ingoing or outgoing task specific objecttype. By contrast, if transformed into a Schema of Conceptual Classes, business transactions are visualized by means of a rectan- gle connected with the corresponding object specific, transaction specific, or service specific objecttypes by means of interacts with relationship.
7.2.3 Step III: Modeling Procedure
In the following, the modeling procedure of SOM enterprise modeling is defined by means of Multi-View Modeling Use Cases. Following the specification of these use cases in section 6.3.3, each use case specification is comprised of relationships to other use cases by means of include, extend, or generalization; and relationships to viewpoints by means of triggered-in, effect, or conditional effect. For readability reasons, the specification is visualized in a tabular notation in Table 18. The viewpoints are indicated by their abbreviation: Interaction Schema (IAS), Task- Event Schema (TES), Transaction Decomposition Schema (TDS), and Object Decomposition Schema (ODS). If a certain use case can be triggered in a certain viewpoint, the corresponding cell is marked with an ’T’. Effect relationships are visualized by an ’E’, conditional effect relationships are visualized by a ’C’ in the corresponding cell.
Table 18: Multi-View Modeling Use Cases of SOM business process modeling (cf. (BORK AND SINZ, 2013))
Use Case
Triggered In Effect On
References IAS TES TDS ODS IAS TES TDS ODS
1. Decompose Transaction T T T C C E
2. Decompose Object T T C C E
3. Revoke Decomposition T T C C C C
5. Add Environmental Object T E E E Include(6)
6. Add Enforcing Transaction T E E E
7. Remove Environmental Object T E E E Include(8)
8. Remove Enforcing Transaction T E E E
9. Increase Business Process Level T T E E
10. Decrease Business Process Level
T T E E
11. Switch Transaction Direction T T E E
12. Define Process Behavior T E
13. Delete Internal Event T E
14. Add External Event T E
Legend: T= Triggered-In, Cb = Conditional Effect, Eb = Effectb
The table visualizes only the business process modeling use cases. Two use cases of Table 18 are now described in order to illustrate the procedure and the benefit of the multi-view mod- eling use cases. Generally, the precise specification of the use cases and the conditional effect relationships is performed in the conceptual design step of MUVIEMOT (cf. section 7.2.5 for the Conceptual Design of the SOM tool).
Use case 4. Zooming depicts the functionality of zooming-in and zooming-out of defined SOM business process levels. A business process level is determined by a certain set of cur- rently visualized business objects and business transactions. SOM defines a zoom operator by means of immediately switching between different, already defined, business process levels, i.e., in order to foster understanding and evaluate the correctness of the model. More precisely, a certain hierarchy level of the Object Decomposition Schema and the Transaction Decompo- sition Schema is referred to as a business process level. Hence, the zooming use case can be triggered in the ODS and TDS viewpoints. Changing the visualized business process levels necessarily effects to adopt the Interaction Schema and the Task-Event Schema to the selected
level.
Use case 5. Add Environmental Object is provided to adapt the initial SOM multi-view business process model, consisting of one environmental object, one object of discourse and one enforcing transaction. With this use case, the modeler is able to add more environmental objects, e.g., customer and vendor, in order to match the business process to the system under study. However, as the business process meta model (cf. Figure 44) indicates, a business object always has to have at least one related business transaction. Therefore, this use case is referencing use case 6. Add Enforcing Transaction by an include relationship. Hence, environmental objects can only be added, if at least one additional business transaction is added simultaneously.
7.2.4 Step IV: Viewpoint Dependencies
In the Viewpoint Dependencies step of the MUVIEMOT approach the focus is on the dependen- cies between the multiple viewpoints. Some of these dependencies have a syntactical origin, i.e., they result from overlapping concepts of the viewpoints’ meta models, others have a se- mantical origin, i.e., they result from the semantically overlapping areas of the viewpoints (cf. section 2.2.3).