# Domain Model Based Design of Business Process Architectures
## 5 The dBPA Method
### Procedure
The set of states for Courier is [_i,created, deleted_], which was assumed to have a generic behavior. * **Build OLC for each business entity. ** The OLC \(l\) (resp. \(l_{g}\)) for each business entity \(b\)\(\in B\) needs considering individual behavior as well as interactions between business entities. If an OLC for the business entity \(b\) is available, it should be checked against the aspects described in the following and adapted if necessary. * **4a. Build preliminary OLCs. *
* Before addressing relations between OLCs of different business entities, the focus is on building a preliminary OLC for each business entity \(b\). Such an OLC \(l\) must contain the following:
* The set of states \(S\) is identified in the previous step. Additionally, a concurrent state-independent region is added to the OLC \(l\) whenever the class \(c\) from which \(b\) was derived is the super-class of a state-independent hierarchy in the domain model. The sub-classes of the state-independent hierarchy are mapped into states within the state-independent region. * The set of transitions \(T\) that allow reachability of all states in \(S\). \(T\) is identified using domain-expert knowledge. * The set of labels \(\Sigma\) of which the label \(\sigma_{i}\in\Sigma\) is assigned to \(t_{i}\in T\). For each label \(\sigma_{i}\), its mandatory \(proc\) element represents is the process that is executed for the corresponding transition to occur. For each label \(\sigma_{i}\), its optional _guard_ element refers to a condition for enabling the transition. This condition may verify process parameters (e.g., fixed-term contract), or concurrent states (using the form in _state.substate..._ e.g., in _placed_). _In the example._ Figure 4 shows the OLCs for the business entities of the retail company, and the OLCs of Invoice and of Purchase are described in the following to illustrate building preliminary OLCs. First, the OLC of Invoice shows the simplest case of an OLC that remains unaltered from its preliminary version. This OLC includes the set of states [_i, issued, paid_] and the transitions with the set of labels [_issue, collect_]. The transition _issue_ represents the existence of a process called _issue_ whose goal is to transform an instance of Invoice into an _issued_ one. On the other hand, the _collect_ process transforms an _issued_ Invoice into a _paid_ one. Second, the OLC of Purchase is addressed. Though the preliminary version of this OLC differs from its final version shown in Figure 4, the use of a state-independent region and guards remains unchanged and is described in the following. The OLC of Purchase holds two concurrent regions: _status_ representing behavioral aspects and _type_ representing static aspects of a Purchase. Notice that static aspects are only part of an OLC whenever the corresponding class is part of a static hierarchy, as is the case of Purchase that differentiates between regular--national--purchases and international ones, as shown in Figure 3. The OLC of Purchase contains _guards_: some of them are related to parameters (e.g., (_national_)) while others correspond to state verifications (e.g., _(in type.national_)). The latter case represents two variations over the _deliver_ process. 4b. Enrich OLCs with association-based interactions.Once preliminary OLCs are built, the interactions between them are included to obtain the final OLCs. An interaction between the OLCs of two business entities \(b^{\prime}\) and \(b^{\prime\prime}\) is given whenever an association \(a_{k}\in A\) in the domain model relates the classes \(c^{\prime}\), \(c^{\prime\prime}\in C\) on which \(b^{\prime}\), \(b^{\prime\prime}\in B\) are based, respectively. * **General case. ** Let the relation between \(c^{\prime}\) and \(c^{\prime\prime}\) be represented by the association \(a_{k}\), where \(c^{\prime}\) is the source class and \(c^{\prime\prime}\) is the target class according to the direction \(dir(a_{k})\).