Reflections for the Perplexed

In language there are only differences. Even more important: a difference generally implies positive terms between which the difference is set up; but in language there are only differences without positive terms. Whether we take the signified or the signifier, language has neither ideas nor sounds that existed before the linguistic system, but only conceptual and phonic differences that have issued from the system. The idea or phonic substance that a sign contains is of less importance than the other signs that surround it. […] A linguistic system is a series of differences of sound combined with a series of differences of ideas; but the pairing of a certain number of acoustical signs with as many cuts made from the mass thought engenders a system of values.

Saussure, Ferdinand de (1916 [trans. 1959]). Course in General Linguistics.

As a consequence, many concepts are better understood when mirrored with some close relative for which a clear-cut distinction can be enunciated.

Abstract vs Concrete (descriptions)

Contrary to concrete ones, abstract descriptions of physical or symbolic objects or activities are partial and therefore cannot be used to create actual instances of the target.

Actor vs Agent

In UML parlance actors represent roles played by agents in activities; roles are transient by nature but their actions may be persistently recorded. In Caminao parlance agents are active physical beings vested with some responsibility. It must be noted that along such (organizational) reasoning, agents are necessarily humans, as neither devices or systems could take responsibility. Agents must be persistently (and separately) represented if their roles require identification.

Actual vs Tangible

Actual objects or phenomena are best defined as real or factual, but not necessarily tangible or physical.

Aggregate vs Composition

Artifacts can be loosely or strongly connected. Strong connections (aka whole/Parts relationships) are governed by composition patterns. In UML parlance aggregates are elements of a whole with identities of their own. Composition is used when elements have no independent life-cycle (i.e identity).

Alethic vs Deontic (rules)

Alethic logic describes possible, necessary or contingent conditions with regard to truth. Used for system modeling, those conditions may be directly applied to symbolic representations. Deontic logic describes conditions with regard to actual modalities. Used for system modeling, that means conditions to be verified by business contexts independently of symbolic representations. Those must be enforced if system objects are to represent business contexts.

Analysis vs Design (models)

Analysis (aka descriptive) models are symbolic artifacts used to classified a given set of instances, as opposed to design (aka prescriptive) models used to produce an unlimited set of instances. Set in the context of  modeling processes, analysis deals with the system functionalities intended to support business requirements, and design deals with system components implementing system functionalities.

Architecture vs Design (software)

Design deals with resources and mechanisms set within a single address space and operated within a single time-frame (under a single clock). Architecture deals with resources and mechanisms distributed across multiple address space, and operated across different  time-frames.

Architecture vs Process

Architectures deal with shared assets and capabilities; processes deal with specific objectives, activities and outcomes. They are set along orthogonal dimensions,  the former supporting the latter.

Attribute vs Aspect

Attributes define the format and semantics of objects features; contrary to aspects they are not meant to be managed independently. Aspects regroup attributes and operations describing objects roles; whereas they must be associated to identified objects, they may be identified and managed on their own.

Attributes vs Association

The attribute vs aspect alternative can also be resolved at implementation level:  since instances of data types have no identifiers other than their value, there is no key to be used for an association.

Capabilities vs Processes

Capabilities and processes are the two key orthogonal dimensions of systems, the former describing the envelope of activities that can be supported given the architecture, assets, and resources, the latter describing the actual execution of supported activities.

Capability vs Feasibility

With regard to systems, capabilities refer to what can be achieved by a system at functional or technical level. As in a mirror, feasibility is best understood as the assessment of an hypothetical process to be supported by given system capabilities.

Class vs Interface (artifact)

Class and interface are programming artifacts, not modeling ones. The former is used to specify software objects, the latter to describe their behavior. When applied to modeling some caution should be exercised, and their use should be limited to design models.

Conceptual vs Symbolic (representations)

Conceptual relates to representations formed in the mind,  symbolic relates to representations used in social dealings. As a corollary, conceptual representations can remain detached of business world practicalities, whereas symbolic ones have to meet some communication purpose and be sanctioned by their actual performance. Information systems are direct implementations of the latter, with or without use of the former.

Data vs Information

Data is a set of signs, symbolic (text, numbers) or otherwise (visuals, sounds), to be taken at face value i.e independently of interpretation. Data may or may not be transformed into information providing it can be mapped to categories supporting the symbolic representation of a domain of concern.

Derived vs Prime (representations)

Prime symbolic representations stand for business objects or processes, derived representations are computed from other symbolic representations.

Event vs Activity

Events are changes in the state of objects, activities, or expectations. Activities may appear as events when their beginning and end coincide, i.e nothing relevant is supposed to happen during their execution.

Execution vs Simulation (models)

Since execution can only be defined for software, executable models are supposed to be directly transformed into code. As a corollary, the behavior of systems combining software, devices, and agents can only be simulated. That restriction also applies to distributed systems because synchronization of processes executed under different clocks in different locations can only be simulated. Those limits can be managed using simulation; mixing executable components with other resources, it reproduces system behaviors regarding (1) business contents, (2) system functionalities, and (3) operational deployment.

Extension vs Intension (symbols)

The extension (aka denotation) of a symbol (see below) is the actual set of objects and behaviors it refers to; its intension is a selected set of features shared by these instances. This distinction is pivotal in model semantics and validation.

Functional vs Business (requirements)

Business requirements deal with objects and activities relevant for the business stakeholders, functional requirements describe how the targeted business processes are meant to be supported by the system under consideration.

Functional vs Non Functional (requirements)

As every classification the functional/non functional one is a  conceptual tool designed for a purpose, namely to put the respective expectations and commitments of business and system analysts on a common track. Hence, the distinction is not objective: depending on the business under consideration, requirements like standards or response time may be seen as technical or regulatory, and therefore be classified as functional or non functional. The classification may even be overlapping, for instance when performance requirements are simultaneously governed by accuracy demands (e.g high-frequency trading or missile target acquisition) and computing resources. That is not to say that the distinction is arbitrary; on the contrary, it conveys an implicit policy regarding platform dependency: defining some requirements as non functional put them under the authority of a separate organizational unit with its own decision-making capacity.

Implicit vs Explicit Knowledge

Assuming knowledge is the acquired (or memorized) ability to figure out situations and solve problems, implicit knowledge doesn’t depend on symbolic representations.

Information vs Knowledge

Knowledge is information put to use

Layers vs Levels

Layers often refer to architectures and levels to models, but beyond lexical controversies, what is at stake is the alignment of two basic scales:

• Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
• Models: conceptual (business context and organization), analysis (symbolic representations), design (physical implementation).

Metaphors vs Metonymies

Metonymy (or proximity) and metaphors (or analogy) are universal cognitive mechanisms used to organize and ultimately align actual (perceptions) and symbolic (concepts) realms. When applied to ontologies they are best understood in terms of extensions and intensions, extensions standing for actual sets of objects and behaviors, and intensions for sets of features that characterize these instances.

Models vs Meta-models

Just like models are meant to describe sets of instances, meta-models are meant to describe instances of models independently of their respective semantics.

Model vs Program

Models are partial or complete descriptions of existing or intended systems, programs are complete descriptions of software components. Since software components are parts of systems, models and programs may fully overlap  for systems made exclusively of software components. Yet, whereas the difference between existing and intended descriptions is pivotal for systems, it is irrelevant for program except for their reverse translation into models.

Modeling vs Programming Languages

Modeling languages describe systems, programming ones describe software components. Except for systems reduced to non distributed software components, programming languages are not substitutes for modeling ones.

Objective vs Subjective (symbolic representations)

Objective representations are open to falsification with regard to actual observations, subjective ones are not.

Ontology vs Epistemology

An ontology is a symbolic construct whose purpose is to specify a finite set of concepts, not to be confused with epistemology, which  is a discipline whose purpose it to validate the concepts with regard to domains of concerns.

Orchestration vs Choreography

Both describe the arrangement, coordination, and management of activities. As far as the W3C is concerned, orchestration is set under a single authority (control of different activities carried out by different systems contributing to a common goal), and choreography refers to a distributed environment (coordination of different activities independently run by different agents, without a central controller).

Pattern vs Stereotype

Stereotypes are semantics labels attached to artifacts. Patterns are structural prescriptions to which model artifacts are meant to conform. The former are extrinsic and their use discretionary, the latter are intrinsic and their use mandatory.

Persistent vs Transient

Persistent objects have a life-cycle of their own and their state must remain consistent whatever the processes accessing them. Transient objects have their life-cycle managed by a single process which also governs their access.

Problem vs Solution (spaces)

Problems and solutions spaces overlap all along application life-cycle depending on perspective. For business analysts, problems are set on their own merits (e.g how to assess insurance premiums or compute missile trajectory), with supporting systems being part of the solution. Then, system analysts will see those expected functionalities as problems to be solved by system design.           

Requirements vs Specifications

Requirements describe what is expected from the artifact under consideration, specifications define how it is to be designed.

Roles vs Relations

Roles are placeholders describing the participation of objects within a given context. Targeted objects are necessarily symbolic but can be active (roles played by agents in activities, aka actors) or passive (roles as functional relationships). While the former usage is straightforward, the latter overlaps with standard relationships and can be ignored.

Roles vs Polymorphism

Roles and polymorphism are dual facets of indirection: the former are static descriptions used when different types of objects can play the same part in activities; the latter is a dynamic description used when objects with undefined type are to behave differently when receiving the same message.

Specialization vs Generalization

Specialization and generalization can be understood as modeling steps or the resulting artifacts thereof. Specialization introduces new features (attributes or behaviors) to existing descriptions, generalization consolidates existing ones. Contrary to appearances, there is no symmetry since specialization has no effect whatsoever on initial model contents, whereas generalization does modify prior model semantics.

Specific vs Universal (Modeling languages)

Domain Specific Languages (DSLs) target particular activities (e.g insurance) or problems (e.g real-time); universal ones are meant to be neutral and to support the modeling of every business for every architecture or platform. By nature the former are like “boutique hotels” targeting narrow and specialized trades, while the latter are caravanserails open all kind of traders. Thanks to its stereotyping mechanism, UML (Unified Modeling Language), initially drafted as a universal language, may also be used to develop specific ones. That can introduce some confusion as it put modelers somewhere between the devil of details and the deep blue sea of abstractions.

Signal vs Icon (reference)

Both are references pointing to actual objects of phenomena, but signals operate through direct association (metonymy) while icons operate through similarity (analogy).

Signal vs Symbol (reference)

Both are references pointing to actual objects or phenomena, but signals operate through direct association while symbols use the mediation of semantic constructs.

Symbol vs Symbolic Object

A symbol is a sign pointing to something else (aka referent), a symbolic object is an object representing a referent. The former belongs to the realm of language, the latter belongs to the practical world and is meant to be used as a substitute.

Symbolic vs Actual (business objects)

Actual business objects stand on their own, symbolic ones stand for actual ones. Literally, the terminology can be somewhat confusing since, eventually, symbolic representations will have to be physically implemented as system components. Moreover, as epitomized by contracts, actual objects are not necessarily tangible even if supporting documents are originally both physical and symbolic. Understood in the context of system functionalities, the point is to set apart objects in business contexts from their system counterparts.

Synchronic vs Diachronic (model)

Synchronic models are bound to business contexts, diachronic ones are bound to other models. That distinction play a pivotal role in traceability and more generally in the organization of modeling processes. Requirements and analysis models belong to the former category as they must be congruent with business concerns, design and deployment models belong to the latter category as they are set within development cycles.

Synchronous vs Asynchronous (activities)

A synchronous activity must be executed as if nothing may change until it completes. An asynchronous one is not affected by what happens while it is performed.

Syntax vs Semantics

Syntax describes the relationships between symbols (see above), semantics describes the relationships between symbols and their referents. This distinction is at the core of UML# manifesto.

System vs Application

Applications deal with symbolic representations fully under their control, i.e directly accessible and under a single clock. Systems deal with distributed actual and symbolic objects, i.e not directly accessible and under different time-frames.

Validation vs Verification

Whatever the target of quality assurance (specifications, models, source code, documents, etc), verification will check the target by itself whereas validation will compare the target to some external reference.