Synopsis
The intent of Unified Architecture Framework Profile (UAFP) is to “provide a Domain Meta-model usable by non UML/SysML tool vendors who may wish to implement the UAF within their own tool and metalanguage.”
But a meta-model trying to federate (instead of bypassing) the languages of tools providers has to climb up the abstraction scale above any domain of concerns, in that case systems architectures. Without direct consideration of the domain, the missing semantic contents has to be reintroduced through stereotypes.
Problems with that scheme appear at two critical junctures:
- Between languages and meta-models, and the way semantics are introduced.
- Between environments and systems, and the way abstractions are defined.
Caminao’s modeling paradigm is used to illustrate the alternative strategy, namely the direct stereotyping of systems architectures semantics.
Languages vs Stereotypes
Meta-Models are models of models: just like artifacts of the latter represent sets of instances from targeted domains, artifacts of the former represent sets of symbolic artifacts from the latter. So while set higher on the abstraction scale, meta-models still reflect the domain of concerns.
Things are more complex for languages because linguistic constructs ( syntax and semantics) and pragmatic are meant to be defined independently of domain of discourse. Taking a simple example from the model above, it contains two kinds of relationships:
- Linguistic constructs: represents, between actual items and their symbolic counterparts; and inherits, between symbolic descriptions.
- Domain specific: played by, operates, and supervises.
While meta-models can take into account both categories, that’s not the case for languages which only consider linguistic constructs and mechanisms. Stereotypes often appear as a painless way to span the semantic fault between what meta-models have to do and what languages use to do; but that is misguided because mixing domain specific semantics with language constructs can only breed confusion.
Stereotypes & Semantics
If profiles and stereotypes are meant to refine semantics along domains specifics, trying to conciliate UML/SysML languages and non UML/SysML models puts UAFP in a lopsided position by looking the other way, i.e towards one-fits-all meta-language instead of systems architecture semantics. Its way out of this conundrum is to combine stereotypes with UML constraint, as can be illustrated with PropertySet:
Behind the mixing of meta-modeling levels (class, classifier, meta-class, stereotype, meta-constraint) and the jumble of joint modeling concerns (property, measurement, condition), the PropertySet description suggests the overlapping of two different kinds of semantics, one looking at objects and behaviors identified in environments (e.g asset, capability, resource); the other focused on systems components (property, condition, measurement). But using stereotypes indifferently for both kind of semantics has consequences.
Stereotypes, while being the basic UML extension mechanism, comes without much formalism and can be applied extensively. As a corollary, their semantics must be clearly defined in line with the context of their use, in particular for meta-languages topping different contexts.
PropertySet for example is defined as an abstract element equivalent to a data type, simple or structured, a straightforward semantic that can be applied consistently for contexts, domains or languages.
That’s not the case for ActualPropertySet which is defined as an InstanceSpecification for a “set or collection of actual properties”. But properties defined for domains (as opposed to languages) have no instances of their own and can only occur as concrete states of objects, behaviors, or expectations, or as abstract ranges in conditions or constraints. And semantics ambiguities are compounded when inheritance is indifferently applied between a motley of stereotypes.
Properties epitomize the problems brought about by confusing language and domain stereotypes and point to a solution.
To begin with syntax, stereotypes are redundant because properties can be described with well-known language constructs.
As for semantics, stereotyped properties should meet clearly defined purposes; as far as systems architectures are concerned, that would be the mapping to architecture capabilities:
- Properties that can be directly and immediately processed, symbolic (literal) or not (binary objects).
- Properties whose processing depends on external resource, symbolic (reference) or not (numeric values).
Such stereotypes could be safely used at language level due to the homogeneity of property semantics. That’s not the case for objects and behaviors.
Languages Abstractions & Symbolic Representations
The confusion between language and domain semantics mirrors the one between enterprise and systems, as can be illustrated by UAFP’s understanding of abstraction.
In the context of programming languages, isAbstract applies to descriptions that are not meant to be instantiated: for UAFP “PhysicalResource” isAbstract because it cannot occur except as “NaturalResource” or “ResourceArtifact”, none of them isAbstract.
Despite the appearances, it must be reminded that such semantics have nothing to do with the nature of resources, only with what can be said about it. In any case the distinction is irrelevant as long as the only semantics considered are confined to specification languages, which is the purpose of the UAFP.
As that’s not true for enterprise architects, confusion is to arise when the modeling Paradigm is extended as to include environments and their association with systems. Then, not only that two kinds of instances (and therefore abstractions) are to be described, but that the relationship between external and internal instances is to determine systems architectures capabilities. Extending the simple example above:
- Overlooking the distinction between active and passive physical resources prevents a clear and reliable mapping to architecture technical capabilities.
- Organizational resource lumps together collective (organization), individual and physical (person), individual and organizational (role), symbolic (responsibility), resources. But these distinctions have a direct consequences for architecture functional capabilities.
Hence the importance of the distinction between domain and language semantics, the former for the capabilities of the systems under consideration, the latter for the capabilities of the specification languages.
Systems Never Walk Alone
Profiles are supposed to be handy, reliable, and effective guides for the management of specific domains, in that case the modeling of enterprise architectures. As it happens, the UAF profile seems to set out the other way, forsaking architects’ concerns for tools providers’ ones; that can be seen as a lose-lose venture because:
- There isn’t much for enterprise architects along that path.
- Tools interoperability would be better served by a parser focused on languages semantics independently of domain specifics.
Hopefully, new thinking about architecture frameworks (e.g DoDAF) tends to restyle them as EA profiles, which may help to reinstate basic requirements:
- Explicit modeling of environment, enterprise, and systems.
- Clear distinction between domain (enterprise and systems architecture) and languages.
- Unambiguous stereotypes with clear purposes
On a broader perspective understanding meta-models and profiles as ontologies would help with the alignment of purposes (enterprise architects vs tools providers), scope (enterprise vs systems), and languages (modeling vs programming).
Back to Classics: Ontologies
As introduced long ago by philosophers, ontologies are meant to make sense of universes of discourse. To be used as meta-models and profiles ontologies must remain neutral and support representation and contents semantics independently of domains of concern or perspective.
With regard to neutrality, the nature of semantics should tally the type of nodes (top):
- Nodes would represent elements specific to domains (bottom right).
- Connection nodes would be used for semantically neutral (aka syntactic) associations to be applied uniformly across domains (bottom left).
That can be illustrated with the simple example of cars:
With regard to contexts, ontologies should be defined according to the nature of governance and stability:
- Institutional: Regulatory authority, steady, changes subject to established procedures.
- Professional: Agreed upon between parties, steady, changes subject to accords.
- Corporate: Defined by enterprises, changes subject to internal decision-making.
- Social: Defined by usages, volatile, continuous and informal changes.
- Personal: Customary, defined by named individuals (e.g research paper).
Ontologies set along that taxonomy could also be refined as to be aligned with enterprise architecture layers: enterprise, systems, platforms, e.g:
With regard to concerns ontologies should focus on the epistemic nature of targeted items: terms, documents, symbolic representations, or actual objects and phenomena. 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.
More generally, understanding meta-models and profiles as functional ontologies is to bring all EA business and engineering concerns within a comprehensive and consistent conceptual framework.
A workbench built with the Caminao ontological kernel is meant to explore the scope and benefits of that approach, with a beta version (Protégé/OWL 2) soon available for comments on the Stanford/Protégé portal.
Further Reading
Models
- Modeling Paradigm
- Ontologies & Models
- Conceptual Models & Abstraction Scales
- Models & Meta-models
- Open Concepts Will Make You Free
- Conceptual & Functional Blueprints
- Views, Models, & Architectures
Architectures
- Relating to Functions
- Capabilities vs Processes
- From Processes to Services
- Alignment: from Empathy to Abstraction
Enterprise Architecture
- Thread: Enterprise Architecture
- Where to Begin with EA
- EA: Maps & Territories
- EA Frameworks: Non Negotiable Features
- Caminao & DoDAF
UML
- UML’s Semantic Master Key, Lost & Found
- UML and Users’ Concerns
- A personal view of SysML
- UML# Manifesto
- UML#: Core Artifacts
- Focus: UML Reenacted
- Focus: UML & MDA
I really like reading through an article that can make people think. Also, many thanks for allowing me to comment!|