Business Capability Definition using PCIML in detail

PMDA provides Business Analysts or Business modelers with the right tool to capture the definition of “how” a capability is defined and delivered. This tool is called Parametric Computation-Independent Modelling Language (PCIML); it is a meta-model which organises and supports the capture of a business definition (Structure, Behaviour and Rules) as represented in the Figure 1 below.

Figure 1 - PCIML Meta-model — Figure 1 – PCIML Meta-model

Thing

The first step in creating definition models using PCIML is to identify the structure of the business by modelling the different Things required to deliver the capabilities.

Therefore, continuing with the example of Entry Management, the Business Analyst looks into the capabilities, requirements and usage scenarios and identifies the following:

There is a need for recording Artists that must be Persons.
There is a need for recording a User profile that is going to be fully defined when defining the Identity Management capability.
There is a need for recording Artefacts. Artefacts are associated with Tags and contain photos that are stored in an Image Store.

As an example, LVD may want to catalogue Critics, General Public, Amateurs and Experts: these new Things could also be modelled as in the example below.

The Business Analyst will then model the things in a class hierarchy as appropriate. The model is then filled with the following list of Things organised hierarchically in Table 1.

Table 1 - Things Hierarchy — Table 1 – Things Hierarchy

Property

After the Things are identified, the Business Analyst defines the Properties for each Thing, remembering that the child Things inherits the Properties of the parent Thing.

Each Thing can have many Properties, some properties known as Relationship Properties are used to connect two things (e.g. isAuthorOf) and others just capture details of a thing (e.g. personID). The Business Analyst produces the list of Properties for each Thing shown in Table 2.

Table 2 - Things properties — Table 2 – Things properties

Agent

With the Properties defined, the Business Analyst starts modelling the Agents that at some point will interact with the Entry Management Capability.

He models the following Agents: ArtistUser, StoreManager, TagCuratorUser and CriticUser.

Figure 2 below is a graphical representation of the structure modelled by the Business Analyst. The Instances in blue are only used for the scenario illustration and are not modelled in PCIML.

Figure 2 - The Entry Management Structure — Figure 2 – The Entry Management Structure

State

Although, State is one of the constructs which define the structure of the business, it makes more sense to explain how to identify the States when defining the behaviour of the business: that is the next task for the Business Analyst.

In order to define the behaviour of the business and identify the States the Business Analyst looks at the Usage scenario described above. Being comfortable with the definition of process flows the Business Analyst produces the process flow shown in Figure 3, which contains the tasks extracted from the usage scenario.

Figure 3 - Process with tasks and achieved States — Figure 3 – Process with tasks and achieved States

The process flow is then supplemented by identifying the States required by the scenario. The Business Analyst then models each State, relating it to the deployed Thing: this amounts to specifying each State as a subclass of some Thing, as shown in Table 3:

Table 3 - Person Management State and Things — Table 3 – Person Management State and Things

Operation

PCIML approaches the behaviour definition by defining state diagrams rather then process flows. With this in mind, the Business Analyst will model not only the States but also the Operations responsible for achieving each State.

Table 4 shows the Operations and the achieving States defined by the Business Analyst:

Table 4 - Person Operations achieving States — Table 4 – Person Operations achieving States

Event

Connected to the Operations, the Business Analyst also models the events that may execute or be sent by the Operations to Agents; these Events contain information or inputs required for executing a state transition. Table 5 and 6 shows the Events modeled.

Inbound Events execute Operations:

Operations send Outbound Events:

Table 6 - Outbound Events Sent by Operations — Table 6 – Outbound Events Sent by Operations

Authorization

The Business Analyst also models part of the rules of the business by defining the Authorization ArtistandArtefactPublishingAuthorization. The Agent ArtistUser is then Authorized By the authorization to perform the above Events.

At this stage, the Business Analyst has modeled most of the behaviour of the business: the state diagram is shown in Figure 4.

Figure 4 - Entry Management State Diagram — Figure 4 – Entry Management State Diagram

State Restrictions

With the state diagram defined, the BA goes back to defining the business structure and starts defining the State Restrictions, which defines the criteria used to identify the State of an instance of the deployed Thing at a particular point in time.

The Business Analyst defines then the New Artist State Restriction. In order to define this restriction the BA identifies the need to create another Property for Artist, that is createdDate. The State Restriction defines that Any Artist that does not have the Property createdDate defined is a New Artist.

The BA defines then the Created Artist State Restriction. In order to define this restriction the BA also uses the Property createdDate. The State Restriction defines that Any Artist that has at least one createdDate defined is a Created Artist.

The BA defines then the Active Artist State Restriction. In order to define this restriction the BA identifies the need to create another Property for Artist that is activatedDate. The State Restriction defines that Any Artist that has at least one activatedDate is an Active Artist.

Filter

After defining all States Restrictions, the BA completes the business behaviour definition by defining the Filter. The Filter is used to define propositions connecting two different States in a Subject Predicate Object Relationship.

The PMDA behaviour uses the Filter to enable State Transitions via Operations; the transition is enabled only when the Filter‘s proposition is true.

The BA defines the following Filters, show in Table 7, using the defined States to form the proposition that will enable the following Operations.

Table 7 - Person filters and operations — Table 7 – Person filters and operations

After modelling the Filter, part of the Entry Management PCIML definition is graphical represented on Figure 5.

Figure 5 - State diagram with filter — Figure 5 – State diagram with filter

The behaviour of the business is then driven by the Filter–Operation–State transition. In this way, when the Filter‘s proposition is true, an Operation or Operations are going to be enabled. When one of these Operations is executed a change of State is going to occur and another Filter becomes true for the Object, starting a new transition.

Figure 6 - State transition — Figure 6 – State transition

Condition

At this stage, the BA has already defined both the structure and behaviour of the Business. Now the BA is going to finish defining the Rules, which govern the business.

The Business Analyst starts creating the Conditions which must be true in order for each State change to happen. This means that each State is validated against Conditions. The Table 8 shows the State Conditions defined by the Business Analyst .

Table 8 - State Conditions — Table 8 – State Conditions

The Condition works like a gate between the Operation and the new State. In case all Conditions are true for the state target by the transition, the transition happens and a new State is achieved. In case where at least one Condition is not true an outbound event is going to happen spelling the constraints generated by the Condition and the object State is kept as in the start of the transition.The Figure 7 represents graphically the state transition from New Artefact State to Created Artefact State via the Create Artefact Operation.

Figure 7 - Condition State transition example — Figure 7 – Condition State transition example

Derivation

After the Business Analyst is going to define the Derivation that is the last of the steps in defining the Executable Models. The Derivation is used to define rules used to derive the information required by each transition based on the Agent performing it.

Derivations can be of many types such as: (1) Object property parameters that are configured by the user admin that manages the System Configuration. (2) Parameters that define the values that are included in the value set Properties. (3) Formulas used to define Property values that are calculated based in a formula or by a function. (4) Data sets used to filter by User Domains, business unit, sales regions, etc within domains. (5) External objects that are required by the business object behaviour or by specific functions.

The Business Analyst starts then defining some Formulas required by the same transition used to describe the Condition. Since the Business Analyst defined using State Restrictions that “Any Artefact that does not have the Property createdDate defined is a New Artefact” and also that the Created Artefact is “Any Artefact that has at least one createdDate defined is a Created Artefact ”

In order to create the logic of the transition the Business Analyst defines the following Derivations shown in Table 9:

Table 9 - Derivation garantees states — Table 9 – Derivation garantees states

With this derivation, The Created Artefact State is guaranteed by deriving a value for the property createdDate. The Figure 8 represents graphically the derivation of the state transition from New Artefact State to Created Artefact State via the Create Artefact Operation.

Figure 8 - Derivation transition example — Figure 8 – Derivation transition example

At this stage, the Business Analyst has totally defined the Entry Management Definition Model by following the PCIML meta-model. In order to simplify the explanation of the method, we assumed the entire definition is modelled in one single model.

Universe, Component and Object Definition Models (PCIML)

In reality, PMDA proposes to subdivide a domain like Entry Management in small building blocks that can be plugged when necessary in order to provide a solution which is scale-invariant where some “domains” can be contained within other “domains” and also be object oriented.

By doing this, the building blocks will be kept decoupled from the broader domain, being available to be developed, tested and used separately from other broader domains, which enables the scale invariance. Each model also becomes a deliverable unit where estimation and resources can be allocated.

PMDA approaches definition starting from dividing the Domain in hierarchical smaller Building Blocks (BB) Domains. The smallest BB are called Object Definition Models, where in this case the Business Analyst would define one object model for each Thing defined.

In this way, the Business Analyst creates five separate Business Object Definition Models that are Person, User, Artefact, Tag and Image Store. As described, an Object Definition Model defines the objects structure, its state diagrams and the rules that are captured using the PCIML.

PMDA assures the object model controls the object definition only. It is independent of any other object that also forms the domain. From a Service Oriented Architecture (SOA) perspective, this subdivision enables the creation of unassociated, loosely coupled units of behaviour and functionality that have no calls to each other embedded in them.

Object Definition Models are then imported by Component Definition Models filtering the scope to the specific area of endeavour addressed by that Domain that are then imported by Universe Definition Models that define a broader area of endeavour. Following this principle, the Business Analyst creates a Component Model called Entry Management that is going to be imported by the Arts Exchange Universe Model.

As a result, each individual Object model would be included inside the Entry Management Component Model shown in the Picture 9 below.

Figure 9 - Entry Management Models — Figure 9 – Entry Management Models

PMDA delivers two types of relationships between models that are used to relate Object Definition Models that are part of the same Logic Component Definition Model.

The relationships are recorded at the broader level, this means that the Object Definition Models can be related via a Component Definition Model and two Component Definition Models can be connected via a Universe Definition Model without changing the child in this Parent Child relationship.

The first type of relationship is about the Hierarchy Relationship (owl:imports), The Figure 10 shows the Entry Management Component and its constituents objects.

Figure 10 - Entry Management Structure separate by models — Figure 10 – Entry Management Structure separate by models

The Imports (owl:imports) relationship defines the Parent-Child relationship between Definition models that are part of the same Domain. This relationship type is responsible for defining the Domain Architecture boundaries, Domain Dependencies and Domain Structure.

PMDA allows the import and remove of a model from a component or universe model. Therefore, a Business Universe Definition Model will import many Business Component Definition Models, which then will import many Business Object Definition Models.

When the Business Analyst includes the five Object Definition Models that are used to define each Thing inside the Entry Management Component Definition Model, the Main Things of the Imported Object Model becomes a subclass of the Main Thing of the broader domain model and the Main Operation of the Imported Object Model will have the Main Operation of the broader domain model as parent.

The Business Analyst creates the Entry Thing in order to be the superclass of Person, Artefact, Tag, User and Image Store. (S)he also creates the operation Entry Management in order to group the Person, Artefact, Tags, user and Image Store operations used to calculate the domain vocabulary and business operations taxonomy.

The Second type of relationship is about the Behavioural / Functional Relationship between Definition Models which are imported by the same Component or Universe. It is about building the Component or Universe State charts by relating all required Object or Component state charts recursively.

The Table 10 below represents the Filter defined by the Business Analyst in each separate object Model.

Table 10 - The Filters and Operations separated by object models — Table 10 – The Filters and Operations separated by object models

In order to connect the individual models, the Business Analyst connects the Object behaviour using the Filter Proposition that is defined inside the Entry Management Component Model connecting a State from one Model as Subject with another State as Object from another model using a predicate that is also defined in the Subject model.

After importing the Object Models inside the Entry Management Model, the Business Analyst will extend the Filters defined above, by completing the Filter propositions and also enabling Operations coming from different models inside the broader model shown in Table 11 below in RED.

Table 11 - The Filters and Operations connected in the Entry Management Component — Table 11 – The Filters and Operations connected in the Entry Management Component

By doing that, the individual behaviors of the object models are replaced by the behavior required by the Entry Management Component.

Owl Nest Blog

The place to nurture your business models