Reflections for the Perplexed
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.
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 (aka modal) rules describe possible, necessary or contingent conditions. Used for system modelling, those conditions may be directly applied to symbolic representations. Deontic rules are meant to describe necessary conditions. Used for system modelling, 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 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.
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.
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 it refers to; its intension is the set of characteristics of these objects. 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.
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.
Orchestration vs Choreography
Both describe the arrangement, coordination, and management of activities. Whereas orchestration usually refers to a local perspective (control of different activities contributing to a common goal), choreography more often refers to a distributed perspective (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 of 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, 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 later 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.