Basic Patterns
Context in Context
Context can be embedded in other Contexts. When Context B is embedded in Context A, we call Context B the Child Context of Context A and Context A the Parent Context of Context B.
In Perspectives we have 5 different types of Contexts:
- Domain
- Party
- Case
- Activity
- State
| Domain | Party | Case | Activity | State | |
|---|---|---|---|---|---|
| Domain | X | O | O | O | O |
| Party | X | X | X | O | O |
| Case | X | X | X | O | O |
| Activity | O | O | X | X | O |
| State | O | O | X | X | X |
Context Composition is modelled the same as Context Inheritance. The difference between the two is its cardinality. A Composite (Part) Context in Perspectives can not be a Composite of more than one whole. In inheritance a Parent Context can be the Parent Context of more than one Child Context.
Context Inheritance is differnt from inheritance in OO.
Role in Context
Action in Context
Role in Role
View in Role
Property in Role
Only Roles have Properties. Context also have Properties but they are defined in the Internal and External Role of the Context.
The Role’s Properties are not accessed directly but always via a View. A View is a selection of Properties and has a name. A Role always has a “All Properties View” that contains all the Role’s Properties.
Role in Action
Action in Action
Perspectives Actions are Contexts and just like Contexts they can be embedded in themselves. Typically, during modelling, Business Actions are defined that are translated into Information Actions.
Example: Allocating Resources to Tasks. An Allocation Action binds a Resource to a Task. This means that the Task, after allocation, will contain a Role that is allocated to it.
View in Action
An Action has a View for every Role it contains. This means that it has a View for its Subject Role, the Object Role and, in case of an Action with an Indirect Object Role, for the Indirect Object Role. The Properties of these Views are type constraints on the Roles that will bind on the Action’s Roles.
This means that during Development Time the Tool will attempt to propose appropriate Action’s Object and Action’ s Subject by matching the Properties of the Action Objects Role’s View with the available Roles in the Context of the Action.
This match will result in an ordered list of appropriate Roles dependent on the amount of matching Properties in the Roles or the Properties in their Role Chains.
When only a part of the Properties of the Action’s Roles are covered by Roles in the Context, the Tool will propose to add the missing Properties when one of these Roles is selected.
Property in View
When a Property is added to a Role, its All Properties View will automatically contain it. When a new View is added to a Role, Properties from the Role may be added to the new View.
When the Role is in a Role-Chain, all Properties of the Roles in the Role-Chain are available to be added to the new View. They can be added to new Views of the Role.
Business Patterns
Enterprise Patterns
Public User is a Customer in a Sales Case, serviced by a Sales Person that is a member of the Sales Team as an Employee of an Organisation as Professional User. This pattern is called ad hoc because there is not a Customer Account within the Organisation that is referenced.
The interesting thing about this pattern is that the ContextRole of the transaction in the Payment fills the payment transaction role in the Payment Provider
