Squared Outline: Actors


UML Actors (aka Roles) are meant to provide a twofold description of interactions between systems and their environment: organization and business process on one hand, system and applications on the other hand.

That can only be achieved by maintaining a conceptual distinction between actual agents, able to physically interact with systems, and actors (aka roles), which are their symbolic avatars as perceived by applications.

As far as the purpose is to describe interactions, actors should be primary characterized by the nature of language (symbolic or not), and identification coupling (biological or managed):

  1. Symbolic communication, no biological identification (systems)
  2. Analog communication, no biological identification (active devices or equipments)
  3. Symbolic communication, biological identification (people)
  4. Analog communication, biological identification (live organisms)

While there has been some confusion between actors (or roles) and agents, a clear-cut distinction is now a necessity due to the centrality of privacy issues, whether it is from business or regulatory perspective.

FURTHER READING

Squared Outline: States

States are used to describe relevant aspects in contexts and how the changes are to affect systems representations and behaviors.

On that account, events and states are complementary: the former are to notify relevant changes, the latter are to represent the partitions (²) that makes these changes relevant. Transitions are used to map the causes and effects of changes.

  1. State of physical objects.
  2. State of processes’ execution.
  3. State of actors’ expectations.
  4. State of symbolic representations.

Beside alignment with events, defining states consistently across objects, processes, and actors is to significantly enhance the traceability and transparency of architectures designs.

FURTHER READINGS

Squared Outline: Cases vs Stories

Use cases and users’ stories being the two major approaches to requirements, outlining their respective scope and purpose should put projects on a sound basis.

To that end requirements should be neatly classified with regard to scope (enterprise or system) and level (architectures or processes).

  • Users stories are set at enterprise level independently of the part played by supporting systems.
  • Use cases cut across users stories and consider only the part played by supporting systems.
  • Business stories put users stories (and therefore processes) into the broader perspective of business models.
  • Business cases put use cases (and therefore applications) into the broader perspective of systems capabilities.

Position on that simple grid should the be used to identify stakeholders and pick between an engineering model, agile or phased.

FURTHER READING

Squared Outline: Layers

The immersion of enterprises into digital environments is blurring the traditional distinctions between architecture layers. Hence the need of clarifying the basic notions.


Pagoda Architecture Blueprint

Beyond the differences in terminologies (layers, levels, tiers, etc), four basic taxonomies can be applied:

  1. Enterprise architecture: business processes and organization, systems, platforms (Pagoda blueprint).
  2. Functional architecture: interfaces, control, persistency, services (Model/View/Controller).
  3. Representation: physical, logical, conceptual (Pagoda blueprint).
  4. Economic intelligence: data, information, knowledge

While some alignments are intrinsic, making explicit use of taxonomies is useful because they serve specific purposes.

n.b. The term “application layer” is usually defined in the context of communication architectures.

Further Reading

Squared Outline: Events

In line with the Symbolic Systems paradigm, events are best understood in terms of interactions between systems (or enterprises) and the environment they represent (or live off).


Events with regard to nature and coupling

On that account events are to be associated with four kinds of notifications:

  1. Actual (aka non symbolic) changes in the state of objects.
  2. Actual (aka non symbolic) changes in the state of activities.
  3. Changes in the state of expectations (e.g requests/acknowledgments).
  4. Neutral changes in symbolic representations (e.g messages).

That classification is of particular importance for the definition of time which, taking a leaf from Einstein, is the only reason so that events don’t happen at once.

FURTHER READINGS

Squared Outline: Ontologies

The upsurge in the scope and performances of artificial brains sometimes brings a new light on human cognition. Semantic layers and knowledge graphs offer a good example of a return to classics, in that case with Greek philosophers’ ontologies.

According to their philosophical origins, ontologies are systematic accounts of existence for whatever can make sense in an universe of discourse. From that starting point four basic observations can be made:

  1. Ontologies are structured set of names denoting symbolic (aka cognitive) representations.
  2. These representations can stand at different epistemic levels: terms or labels associated to representations (nothing is represented), ideas or concepts (sets of terms), instances of identified objects or phenomena, categories (sets of instances), documents.
  3. Ontologies are solely dedicated to the validity and internal consistency of the representations. Not being concerned with external validity, As they are not meant to support emprical purposes.
  4. Yet, assuming a distinction between epistemic levels, ontologies can be used to support both internl and external consistency of models. 

That makes models a refinement of ontologies as they are meant to be externally consistent and serve a purpose.

FURTHER READING

EXTERNAL LINKS

Squared Outline: Requirements

Depending on context and purpose requirements can be understood as customary documents, contents, or work in progress.

piano
Partial & Biased Agendas
  1. Given that requirements are the entry point of engineering processes, nothing should be assumed regarding their form (natural, formal, or specific language), or content (business, functional, non-functional, or technical).
  2. Depending on the language used, requirements can be directly analyzed and engineered, or may have to be first formatted (aka captured).
  3. Since requirements reflect biased and partial agendas, taxonomy, in particular the distinction between functional and non functional concerns, is in the eyes of the stakeholders.
  4. Depending on content and context, requirements can be engineered as a whole (agile development models), or set apart as to tally with external dependencies (phased development models).

Further Reading