UML#: Core Artifacts

Objective

The objective here is to build a consensus about a small set of architecture concepts and constructs with unambiguous meanings common to business and system analysts.

laura_buckley_a_little_more_bonding_1024x768
Building a framework from a small set of core concepts (Laura Buckley)

The litmus test for selected concepts and constructs will be threefold:

  • Concrete abstractions: the objective is not to build another meta-model but to define core concepts targeting actual instances identified (but not described) uniformly across enterprise and system architectures.
  • Shared distinctions: the selected concepts and constructs must support the description of the critical distinctions common to both enterprise and system architectures.
  • Occam’s Razor: the objective is to trim the set of definitions as to obtain the least possible number of concepts and constructs.

Caminao working hypothesis is that those objectives can be achieved with:

  1. Seven concepts to serve as pillars for the whole bridge.
  2. Five structural constructs that could be applied uniformly to pillars.
  3. Four lanes to be used to communicate models between enterprise and system architects and analysts.

This post is to be used as a blackboard for the contributions discussed in the LinkedIn Caminao group.

Seven Pillars

As a preliminary step, one should begin with architecture capabilities and look for a common understanding of seven basic artifacts:

  • Containers (physical & symbolic).
  • Physical entities.
  • Symbolic descriptions.
  • Roles.
  • Events.
  • Activities.
  • Execution states.
Capabs_L1
Architecture Capabilities

They are to identified independently of the labels used by the different methods.

descr110descrPackContainer

Used to represent physical or symbolic holders, the former supporting the management of the locations and behaviors of their elements, the latter for the definition of semantics and structures.

Variants: physical location, system space, semantic domain, application domain.

descr21Physical entity

Used to represent actual objects whose state and behavior is relevant for the business under consideration; not be confused with the description of their symbolic representation by systems.

Variants: humans, systems, devices, passive objects.

descr20Symbolic description

Used to describe how objects and activities are to be represented as system surrogates.

Variants: 

descr30Role

Used to represent the 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).

Variants:

bt31_Event

Used to represent changes in the state of business objects, processes, or users’ expectations.

descr40Activity

Used to describe business logic (operations and flows) independently of supporting systems. Equivalent to UML and BPM terms.

Variants:  

descr41Execution state (aka mode)

Used to describe processes’ control and execution.

Variants:  

Connectors

Cake_connects
Functional Connectors

Constructs

The same structural constructs can be applied to all artifacts:

ccc
Structural Constructs
descrSharpStructural unit

Used to indicate that instances of the artifact (objects or activities) can be directly identified at architecture level. Aspects are non structural units.

descrAttOprFeature

Used to describe an attribute or an operation. Features have no instances of their own.

descrCompComposition

Used for instances (objects or activities) whose life-cycle is bound to the one of their owner, i.e they have no identity of their own.

descrAggrAggregation

Used for instances (objects or activities) which are identified independently but can only be used in the context of their owner; hence, while they can change owner, they are useless on their own.

diag200Connector

Used to associate structural units: communication channel, reference, data or control flow, transition.

descrPwr2Partition

Used to define subsets of instances (objects or activities). Depending on modeling context, it corresponds to power-types, extension points, gateways, branch and joins.

InheritsInheritance

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 of non structural features).

Four Lanes

Structural units can be combined in four types of models corresponding with widely accepted views or perspectives, whose associated diagrams can be build through the customization of leading modeling tools.

Four Lanes, anchors (#) and references (+)
Four Lanes, anchors (#) and references (+)
Actual Contexts

Used to describe physical entities (people, devices, systems), locations, and communication channels.

Symbolic Surrogates

Used to define how entities and behaviors are represented as symbolic surrogates, regrouped in domains, and how they are related.

Business Logic

Used to define activities and business rules and their relationships.

Business Operations

Used to define how activities are executed, and their dependencies.

Across the bridge: Symbolic representations

One of the main pitfall in system modeling is the confusion between targets: while languages like UML can be used to describe business as well as systems objects and behaviors, that has to be done explicitly because the semantics differ. Hence the benefit of a distinction between concepts and documents, symbolic representations, and actual objects and processes. That would outline four basic concerns that may or may not be combined:

  • Thesaurus: ontologies covering terms and concepts.
  • Document Management: ontologies covering documents with regard to topics.
  • Organization and Business: ontologies pertaining to enterprise organization, objects and activities.
  • Engineering: ontologies pertaining to the symbolic representation of products and services.
KM_OntosCapabs
Ontologies: Purposes & Targets

It must be noted that those descriptions should not be seen in terms of abstraction levels but as the complementary descriptions of actual and symbolic objects whose mapping is to provide the backbone of enterprise architectures.

Further Reading

External Links

2 thoughts on “UML#: Core Artifacts”

  2. Remy:

    What definition of “architecture” are you using? If you state that one can examine if the concepts and constructs satisfy “architecting”.

    Physical and spatial aspects dominate most architecture definitions and practices but they are NOT relevant to conceptual subjects, typically software. Yet we find vertical and horizontal boxes, layers describing software architectures. I found DSM Design Structure Matrix better suited for non-physical systems. You may like to refer to them in the development of your new proposals / discussion.

    Best wishes,

    Reply

Leave a Reply