Category: SysML

Unified Architecture Framework Profile (UAFP): Lost in Translation ?

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.”

Detached Architecture (Víctor Enrich)

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.

Meta-models takes a higher view of domains, meta-languages don’t.

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:

UAFP for PropertySet (italics are for abstract)

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:

Property must be stereotyped with regard to induced 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.

“isAbstract” has no bearing on horses and carts, only on the meaning of the class PhysicalResource.

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.
Abstraction & Symbolic representation

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
A simple profile for enterprise architecture

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:

KM_CaseRaw
RDF graphs (top) support formal (bottom left) and domain specific (bottom right) semantics.

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:

Ontologies, capabilities (Who,What,How, Where, When), and architectures (enterprise, systems, platforms).

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.
KM_OntosCapabs
Ontologies: Purposes & Targets

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
Architectures
Enterprise Architecture
UML

External Links

A personal view of SysML Block Diagrams

Synopsis

SysML is an UML reconfiguration (subset, extensions, and profile) dedicated to systems modeling. The introduction of blocks as the basic unit of systems description can be seen as  its  pivotal change, in particular when block diagrams are used as substitutes for class ones.

(marceloCidade)
What are blocks standing for ? (Marcelo Cidade)

But the generalized employ of block diagrams may raise a few questions: should its scope be limited ? what kind of systems are targeted ? what kind of models are to be built ? and what are the benefits for modeling processes ?

Scope: Actual Objects & UML blind spot

The description of instances has always been a well known weakness in UML. To be sure, object diagrams were part of UML initial specifications; yet, they have been jettisoned due to their lack of clear definition and purpose; finally they have been “overlooked” in UML last versions.

That neglect has left a blind spot in UML modeling apparatus: if components and deployment diagrams are available to deal with logical and physical instances at the end of the engineering process, UML 2.5 has nothing equivalent for the context “as-it-is” at development process inception.

So, SysML new focus on physical systems offers a worthwhile opportunity to make up for the disappointments of object  diagrams, introducing the block diagram as the tool of choice for requirements specifications relative to existing systems and environment, along class diagrams for the definition of their logical counterpart, and components and deployment diagrams for logical and physical implementations.

Such a restricted focus on physical instances would meet the parsimony principle (aka Occam’s razor) and would provide for continuity with UML and clarity of semantics and purposes.

Blocks can be used all along, for physical as well as logical components
Actual objects: a blind spot for UML, a blurred one for SysML

But that opportunity is to be missed if, instead of focusing on the blind spot of requirements with regard to actual configurations, block diagrams are used indiscriminately for instances and classes, blurring the critical distinction between physical and logical components, and introducing overlaps and semantic ambiguities across diagrams.

Target: Mechanical vs Logical Systems

Whereas SysML clearly suits the needs of mechanical and civil engineering, its preferred hierarchical approach may fall short when systems cannot be reduced to equipment built from hardware and software.

Nowadays, with software colonizing every nook and cranny of actual and virtual worlds (soon to be known as the Internet of Things), a broader systemic approach may be necessary, with systems modeled as collaborative frameworks between agents, devices, and computer systems.

vvvv
Systemic designs are better driven by functional architectures

Being by nature logical, distributed, heterogeneous, and in continuous mutation, these systems are not easily described by hierarchies of physical components. And even when blocks can be used to represent hardware and software, separately or jointly, block diagrams tend to privilege trees of physical components intertwined by logical or functional associations.

That bias in favor of physical architectures may put functional ones on the passenger seat; as a consequence, critical software alternatives may be shrouded, bypassed, or emerge at lower levels of composition; too late and too local for sound architectural decision-making.

Models: Requirements vs Design

The bias introduced by block diagrams may be of no consequence as far as SysML is used for requirements specifications. But that may not be the case if it is also used for design, especially if block diagrams are used all along without a transition being clearly marked between requirements and design.

At issue here is the qualitative and quantitative edge of software capabilities over hardware ones: a prejudice for block hierarchies could compromise the plasticity (ability to change architecture without affecting performances) and versatility (ability to perform different activities without changing the architecture) of systems designs.

Moreover, apart from being inherently more rigid than networks, block hierarchies are built along a single dimension combining logical and physical features. The overall plasticity of such hierarchies is to be constrained by the plasticity of their physical elements, and their versatility will be similarly limited by hardware constraints on software interfaces.

Finally, as the semantics of ports and flows used to define communication between blocks don’t force an explicit typed distinction between hardware and software, chances are for mixed designs to limit systems modularity. That points to the shortcomings of untyped modeling constructs.

Processes: Overheads of Untyped Constructs

Paradoxically for a supposedly specific profile, SysML’s blocks can be seen as untyped constructs to the extent that they apply to both physical and logical objects, as well as constraints.

Like their programming counterparts, non typed modeling constructs induce ambiguities which have to be clarified by comments or additional constructs. That is where SysML requirements diagrams come into view.

To begin with, requirements are meant to be the source of engineering processes before anything can be assumed with regard to their format or modeling constructs.

Given that premise, usually accepted by leading tools providers, they are to be expressed through text; the very notion of “requirements diagram”, which suggests some formalism, may sound like an oxymoron, and “requirements editor” would be less confusing.

Alternatively, e.g for scientific applications, if the assumption can be dropped requirements can be directly captured using formal expressions and constraints.

Whereas SysML supports both options, the use of untyped blocks may begets redundancy and confusion. Since block diagrams can be used for (physical) targets as well as for (logical) constraints, three policies can be considered:

  • Text: requirements are documented with their own diagram and linked to physical blocks (a).
  • Constraint: requirements are represented by logical blocks linked to physical ones (b).
  • Text and constraint: requirements are documented with their own diagram and linked to constraints represented by logical blocks, themselves linked to physical blocks (c).
Three different approaches to requirements management
Three ways to document requirements: (a) text, (b) constraint, (c) text and constraint.

Embarrassment of riches may be especially challenging when the problem is to bring some order to unstructured and ambiguous inputs. In the case of requirements traceability, adding layers of dependencies may rapidly result in acute “spaghetti syndrome”.

Moreover, the apparent benign choice of diagrams may compound the risks on design mentioned above by masking the critical transition from requirements (documented as such or by constraints) to architectures (as described by physical blocs).

Conclusion

The proper use of block diagrams  has to make up for being simultaneously too restrictive and too permissive.

With regard to structures (and consequently architectures) block diagrams strongly lean towards physical hierarchies; to quote: “blocks provide a general-purpose capability to model systems as trees of modular components.”

With regard to semantics blocks put no limit on what can be represented; to quote: “The specific kinds of components, the kinds of connections between them, and the way these elements combine to define the total system can all be selected according to the goals of a particular system model.”

Since, to quote: “SysML blocks can be used throughout all phases of system specification and design, and can be applied to many different kinds of systems”,  no wonder block diagrams tend to put class diagrams and their sound and consistent semantics to the margins.

These pitfalls can be avoided by using SysML as a typical UML profile, in particular by limiting the use of block diagrams to the modeling of systems as-they-are, and using standard UML2 diagrams with SysML profile and stereotypes otherwise.

PS. SysML 1.4 appears to make amends by deprecating or clarifying some redundant or confusing elements with regard to UML.

Further Readings

External Links