Objective
The primary objective of this initiative is to demonstrate the benefits of open concepts as a basis of conceptual modeling.
More specifically, the proposed blueprints are to target business objects or activities with regard to their realization footprint, namely the sets of individuals in business environments whose symbolic representation is to be managed by supporting systems.
Topics
Requests must be set into basic categories:
Physical containers
Containers introduced to manage actual objects and processes within address spaces or time frames.
Symbolic containers
Containers introduced to manage descriptions (as opposed to instances) under a single authority. For example, organizational units will usually be simultaneously associated to different physical (locations) and symbolic (business objects and processes) containers.
Systems
Physical realizations of symbolic containers introduced to manage instances (aka surrogates) of digital objects.
Physical objects
Actual objects (active or passive) with stable (but not necessarily persistent) physical identity. Identities, life-cycle and behaviors are set by the businesses under consideration. Documents, systems, or locations can also be defined as physical entities.
Symbolic objects
Describe how instances of objects and activities are to be represented by surrogates, whether as paper or digital documents. Not o be confounded with symbolic physical objects (e.g documents) or digital hybrids (e.g digital signatures).
Person
Active physical entity with social identity.
Organization
Active symbolic entity with social identity.
Role (aka Actor)
Part played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents (physical identity) or associations (static).
Event
Change in the state of business objects, processes, or expectations. Since the execution of activities is defined by time-frames, they appear as events when start and completion cannot be distinguished.
Activity
Functional description of operations and flows (data and control) defined independently of the part played by supporting systems. Equivalent to UML and BPM terms.
Execution state (aka mode)
Operational description of activities with regard to processes’ control and execution.
Refined categories can then be defined by crossing primary ones.
Blueprints Principles
Given requests focused on business objects or activities, suggested blueprints will follow established OO principles:
- Open-Closed Principle (OPC): the proposed blueprints are meant to provide a backbone to be fleshed out but not changed. In other words blueprints are to be specialized, but not generalized. That will ensure that their semantics will not be modified by users-defined extensions.
- Substitution Principle (LSP): sets of instances denoted by specialized concepts are meant to be subsets of the sets denoted by proposed blueprints. That is to ensure the continuity and consistency of identification mechanisms.
- Dependency-Inversion principle (DIP): higher levels semantics are defined independently of lower users-defined levels. That is to provide for consistent yet independent semantics of users-defined sub-types.
- Interface-Segregation Principle (ISP): semantics and features are congruent, i.e all features are meaningful for whoever is using the concept. That ensures that there is no overlapping of semantics even when subsets of individuals overlap.
Format
Proposed blueprints will be presented along three layers:
Identification
The primary objective is to define the identification mechanisms supporting the continuous and consistent alignment of business objects and activities with their symbolic counterpart, namely:
- Source of identification: natural, physical (living or inanimate), or social (institutional, cultural,…) .
- Life-cycle: persistent (objects), transient (activities), or instant (events).
Collections
Abstract constructs used by containers to manage sets of instances, actual or symbolic.
Structural features
Structural features are without identity or life-cycle of their own.
Functional features
Functional features come with identity and life-cycle of their own.
Syntax
The same core UML constructs will be uniformly used for all blueprints, making them directly compatible with most of CASE tools, UML or otherwise.
Structural unit
Indicates that targeted individuals (objects or activities) can be directly and consistently identified across businesses and system.
Feature
Used to describe an attribute or an operation. Functional features have no instances of their own.
Composition
Used for individual components (objects or activities) whose life-cycle is bound to their owner, i.e they have no identity of their own.
Aggregation
Used for individual components (objects or activities) which can be identified independently but must be used in the context of their owner; hence, while they can change owner, they are useless on their own.
Connector
Used to associate individuals; their semantics is set by context: communication channel, reference, data or control flow, transition.
Partition
Used to define subsets of individuals (objects or activities). Depending on context, partitions corresponds to power-types, extension points, gateways, branch and joins.
Inheritance
Contrary to structure and functional connectors that deal with instances, inheritance connectors are used to describe relationships between descriptors. Strong inheritance is the counterpart of composition (inheritance of structural features), and weak inheritance the counterpart of aggregation (inheritance functional features).