Archive for the ‘representation patterns’ Category

Focus: Business Processes & Abstraction

July 16, 2016


Abstractions, and corollary inheritance, are primarily understood with objects. Yet, since business processes are meant to focus on activities, semantics may have to be refined when abstraction and inheritance are directly used for behaviors.


How to apply abstraction to processes ?  (E. Gimenez Velilla)

Considering that the primary purpose of abstractions is to tackle business variants with regard to supporting systems, their representation with use cases provides a good starting point.

Business Variants: Use case’s <extend> & <include>

Taking use cases as a modeling nexus between business and systems realms, <extend> and <include> appear as the default candidates for the initial description of behaviors’ specialization and generalization.

  • <include>: to be compared to composition semantics, with the included behaviors performed  by instances identified (#) by the owner UC (a).
  • <extend>: to be compared to aggregation semantics, with the extending behaviors performed  by separate instances with reference to the owner ones (b).
Included UCs are meant to be triggered by owners (a); that cannot be clearly established for abstract use cases and generalization (c).

Included UCs are meant to be triggered by owners (a); that cannot be clearly established for abstract use cases and generalization (c).

Abstract use cases and generalization have also been mentioned by UML before being curiously overlooked in following versions. Since none has been explicitly discarded, some confusion remains about hypothetical semantics. Notionally, abstract UCs would represent behaviors never to be performed on their own (c). Compared to inclusion, used for variants of operations along execution paths, abstract use cases would describe the generic mechanisms to be applied to triggering events at UC inception independently of actual business operations carried out along execution paths.

Nonetheless, and more importantly, the mix-up surrounding the generalization of use cases points to a critical fault-line running under UML concepts: since both use cases and classes are defined as qualifiers, they are supposed to be similarly subject to generalization and specialization. That is misguided because use cases describe the business behaviors to be supported by systems, not to be confused with the software components that will do the job. The mapping between the former and the latter is to be set by design, and there is no reason to assume a full and direct correspondence between functional requirements and functional architecture.

Use Cases Distilled

As far as use cases are considered, mapping business behaviors to supporting systems functionalities can be carried out at two levels:

  • Objects: UCs being identified by triggering agents, events, and goals, they are to be matched with corresponding users interfaces and controllers, the former for the description of I/O flows, the latter for the continuity and integrity of interactions.
  • Methods: As it’s safe to assume that use cases are underpinned by shared business functions and system features, a significant part of their operations are to be realized by methods of shared business entities or services.

Setting apart UIs and controllers, no direct mapping should be assumed between use cases and functional qualifiers.

The business variants distilled into objects’ or services’ methods can be generalized and specialized according to OOD principles; and the same principles can be applied to specific users’ interfaces. But since purely behavioral aspects of UCs can neither be distilled into objects’ methods, nor directly translated into controller objects, their abstraction semantics have to be reconsidered.

Inheritance Semantics: Structural vs Functional

As far as software artifacts are concerned, abstraction semantics are set by programming languages, and while they may differ, the object-oriented (OO) paradigm provides some good enough consolidation. Along that perspective, inheritance emerges as a critical issue due to its direct impact on the validity of programs.

Generally speaking, inheritance describes how structural or behavioral traits are passed from ancestors to descendants, either at individual or type level. OO design is more specific and puts the focus on the intrinsic features (attributes and operations) supported by types or classes, which ensues that behaviors are not considered as such but through the objects’ methods that realize them:

  • Structural inheritance deals with attributes and operations set for the whole life-cycle of instances. As a consequence corresponding inheritance is bound to identities (#) and multiple ascendants (i.e identities) are ruled out.
  • Functional inheritance deal with objects behaviors which may or may not be frozen to whole life-cycles. Features can therefore be inherited from multiple ascendants.

That structural vs functional distinction matches the one between composition and aggregation used to characterize the links between objects and parts which, as noted above, can also be applied to uses cases.

Use Cases & Abstraction

Assuming that the structural/functional distinction defined for objects can also be applied to behaviors, use cases provide a modeling path from variants in business processes to OOD of controllers:

  • Behaviors included by UCs (a) are to be set along the execution paths triggered by UC primary events (#). Inheritance is structural, from UCs base controllers to corresponding (local) ones, and covers features (e.g views on business objects) and associated states (e.g authorizations) defined by use case triggering circumstances.
  • Behaviors extending UCs (b) are triggered by secondary events generated along execution paths. Inheritance is functional, from extending UCs (e.g text messaging) to UCs primary controllers.

Yet this dual scheme may not be fully satisfactory as it suffers from two limitations:

  • It only considers the relationships between UCs, not with the characteristics of the use cases themselves.
  • It ignores the critical difference between the variants of business logic and the variants of triggering conditions.

Both flaws can be patched up if abstract use cases are specifically introduced to factor out triggering circumstances (c):

Use cases provide a principled modeling path from variants in business processes to the OOD of corresponding controllers.

Use cases provide a principled modeling path from variants in business processes to the OOD of corresponding controllers.

  • Undefined triggering circumstances is the only way to characterize abstraction independently of what happens along execution paths.
  • Abstract use cases can then be used to specify inception mechanisms to be inherited by concrete use cases.

That understanding of abstract use cases comes with clear benefits with regard to security and confidentiality.

What is at Stake

Factoring out authentication and authorization epitomizes the benefits of abstract UCs:

  • Concrete schemes with included UC will give access to all registered users with the particulars of managers or customers checked later (a).
  • Alternatively, abstract schemes will use inheritance of inception mechanisms in order to explicitly prevent separate access (c).
  • Applying <include> with abstract UC should be ruled out because it would make room for the execution of operations with undefined triggering circumstances.
Interactions can only be triggered by concrete actors.

Interactions can only be triggered by concrete actors.

As a conclusion, by enabling a clear distinction between business logic and operational circumstances, abstraction can reinforce the security of functional architectures.

Further Reading


UML’s Semantic Master Key, Lost & Found

April 25, 2016


When its first version was published twenty years ago the prognosis for OMG’s UML (Unified Modeling Language) was of rapid and wide expansion. It didn’t happen, and notwithstanding a noteworthy usage, UML has not become  “the” unified modeling language. Beyond the diverse agendas of methods and tools providers, this falling short may have something to do with a lack of robust semantics, as illustrated by UML 2.5’s halfhearted attempt to define individuals.

(Jonathan Monk)

Actual & Digital Identities (Jonathan Monk)

UML 2.5 Aborted Attempt with Individual 

UML 2.5 has often been presented as an attempt to redress the wayward and increasingly convoluted paths taken by the previous versions. Yet, beside some useful (and long needed) clarifications and adjustments, its governing group failed to agree on some compact and unambiguous semantics and had to content itself with perfunctory guidelines introduced as an afterthought.

As a matter of fact the OMG committee may have tried to get its semantics in order, as suggested by the chapter “On semantics” making the point right away with a distinction between the things to be described and the categories to be applied:

“A UML model consists of three major categories of model elements [classifiers, events, and behaviors], each of which may be used to make statements about different kinds of individual things within the system being modeled (termed simply “individuals”in the following)”.

That straightforward understanding (UML is meant to describe individual objects, events, or behaviors) could have provided the semantic cornerstone of a sound approach. Surprisingly, and for obscure reasons, it is soon smudged by syntactical overlapping and semantic ambiguity, the term “individual” being used indifferently as adjective and noun, and then appears to be restricted to classifiers only. That leaves UML with a dearth of clear semantics regarding its scope.

Individual as a Semantic Master Key

The early dismiss of individual as a constitutive concept is unfortunate because, taking a leaf from Archimedes, it could have been the fulcrum on which to place the UML lever.

To begin with, no modeling language, especially one supposed to be unified, can do without some convincing semantics about what it is supposed to describe. Furthermore, such a requirement is of primary importance for UML whose scope straddles the divide between business and systems realms, and must therefore rigorously define what they share and how they differ.

And that could have been neatly achieved with a comprehensive and unified interpretation of individuals, combined with a clear taxonomy of the aspects to be modeled:

  • Individuals are whatever occurrences (in business or systems contexts) with identities of their own.
  • These individuals (objects, events, or behaviors) can be specified with regard to their structure and relationships.

The logical primacy of this approach is reinforced by its immediate, practical, and conclusive benefits for business processes modeling on one side, model based engineering processes on the other side.

A Key to Business Processes Modeling

As far as business processes are concerned, modeling the part played by supporting systems turns around few critical issues, and these issues can be dealt more clearly and consistently when set in reference to individuals taxonomy (objects, behaviors, events) e.g:

  • Functional or non functional requirements ? The former can be associated with individuals, the latter cannot.
  • Architecture or application ? The former affect the specification of interactions between individuals, the latter affect only their local features.
  • Synchronous or asynchronous ? Specifications can only be made with regard to life-cycles and time-frames: system (objects), process (behaviors), or instant (event).
  • Structures or Relationships ? The former are bound to individuals’ identity, the latter are used between different individuals.
  • Inheritance or Delegation ? The former is used for the specification of structural or functional features, the latter for individuals’ behaviors.

More generally that understanding of individuals should greatly enhance the alignment of systems functional architectures with business processes.

A Key to Model Based Systems Engineering

As should be expected from a lack of semantic foundations, one of the main characteristics of the UML community is its fragmented practices, regrouped around diagrams (e.g Use case or Class) or task (e.g requirements analysis or code generation).

The challenge can be directly observed for model based system engineering and software development: with the exception of Statecharts for RT modeling, Class diagrams are the only ones used all along engineering processes; the others, when used, are reduced to documentation purposes. That bottleneck in development flows can be seen as the direct consequence of UML restricted semantics: since behaviors are not identified as individuals in their own right, their description cannot be directly translated into software artifacts, but have to be understood as part of active objects descriptions before being translated into class diagrams. Hence the apparent redundancy of corresponding diagrams.

As a corollary, reinstating a unified semantics of individual for both classifiers and behaviors could be the key to a seamless integration of the main UML diagrams. Most important, that would bear out the cross benefits of combining UML and MBSE.

Further Readings

Conceptual Models & Abstraction Scales

March 22, 2016

Following the recent publication of a new standard for conceptual modeling of automation systems (Object-Process Methodology (ISO/PAS 19450:2015) it may be interesting to explore how it relates to abstraction and meta-models.


Meta-models are drawn along lean abstraction scales (Oskar Schlemmer )

Models & Meta Models

Just like models are meant to describe sets of actual instances, meta-models are meant to do the same for sets of modeling artifacts independently of their targets. Along that reasoning, conceptual modeling of automation systems could be achieved either with a single language covering all aspects, or with a meta-language dealing with different sets of models, e.g MDA’s computation independent, platform independent, and platform specific models.

Modeling Languages covering technical, functional, and business concerns.

Two alternative options for the modeling of automation systems: unified language, or a meta language covering technical (e.g PSMs), functional (e.g PIMs), and business (e.g CIMs) scopes.

Given a model based engineering framework (e.g MDA), meta-models are generally used to support downstream models transformation targeting designs and code. But when upstream conceptual models are concerned, the challenge is to tackle the knowledge-to-systems transition. For that purpose some shared modeling roof is required for the definition of the symbolic footprint of the targeted business in the automation system under consideration.

Symbolic Footprint

Given that automation systems are meant to manage symbolic objects (aka surrogates), one should expect the distinction between actual instances and their symbolic representations to be the cornerstone of corresponding modeling languages. Along that reasoning, modeling of automation systems should start with the symbolic representation of actual business footprints, namely: the sets of objects, events, and processes, the roles played by agents (aka active objects), and the description of the associated states and rules. Containers would be added for the management of collections.

Automation systems modeling begins with the symbolic representation of actual instances

Automation systems modeling begins with the symbolic representation by systems of actual instances of business related objects and phenomena.

Next, as illustrated by the Object/Agent hierarchy, business worlds are not flat but built from sundry structures and facets to be represented by multiple levels of descriptions. That’s where abstractions are to be introduced.

Abstraction & Variants

The purpose of abstractions is to manage variants, and as such they can be used in two ways:

  • For partial descriptions of actual instances depending on targeted features. That can be achieved using composition (for structural variants) and partitions (for functional ones).
  • As hierarchies of symbolic descriptions (aka types and sub-types) subsuming variants identified at instances level.

On that basis the challenge is to find the level of detail (targeted actual instances) and abstraction (symbolic footprint) that will best describe supporting systems functionalities. Such level will have to meet two conditions:

  1. A minimal number of comprehensive and exclusive categories covering the structural variants of the sets of instances to be uniformly, consistently, and continuously identified by both enterprise and supporting systems.
  2. A consistent but adjustable set of types and sub-types anchored to the core structural categories and covering the functional variants .

Climbing up and down abstraction ladders looking for right levels is arguably the critical part of conceptual modeling, but the search will greatly benefit from the distinction between models and meta-models. Assuming meta-models are meant to ignore domain specific features altogether, they introduce a qualitative gap on abstraction scales as the respective hierarchies of models and meta-models are targeting different kind of instances. The modeling of agents and roles epitomizes the benefits of that distinction.

Abstraction & Meta Models

Taking customers for example, a naive approach would use Customer as a modeling type inheriting from a super-type, e.g Party. But then, if parties are to be uniformly identified (#), that would preclude any agent for playing multiple roles, e.g customer and supplier.

A separate description of parties and roles would clearly be a better option as it would unify the identification of the former without introducing unwarranted constraints on the latter which would then be defined and identified as the realization of a relationship played by a party.

Not surprisingly, that distinction would also be congruent with the one between models and meta-model:

  • Meta-models will describe generic aspects independently of domain-specific considerations, in particular organizational context (units and roles) and interactions with systems (a).
  • Models will define StaffSupplier and Customer according to the semantics of the business considered (b).
Composition, partitions and specialization can be used to detail the symbolic footprint

Composition, partitions and specialization can be used along two different abstraction scales.

That distinction between abstraction scales can also be applied to the conceptual modeling of automation systems.

Abstraction Scales & Conceptual Models

To begin with definitions, conceptual representations could be used for all mental constructs, whereas symbolic representations would be used only for the subset earmarked for communication purposes. That would mean that, contrary to conceptual representations that can be detached of business and enterprise practicalities, symbolic representations are necessarily built on design, and should be assessed accordingly. In our case the aim of such representations would be to describe the exchanges between business processes and supporting systems.

That understanding neatly fits the conceptual modeling of automation systems whose purpose would be to consolidate generic and business specific abstraction scales, the former for symbolic representations of the exchanges between business and systems, the latter symbolic representation of business contents.

At this point it must be noted that the scales are not necessarily aligned in continuity (with meta-models’ being higher and models’ being lower) as their respective ontologies may overlap (Organizational Entity and Party) or cross (Function and Role).

Toward a System Modeling Ontology

Along an analytic perspective, ontologies are meant to determine the categories that can comprehensively and consistently denote the instances of a domain under consideration. With regard to the modeling of automation systems, a relevant ontology would map a subset of semantic categories (for conceptual representations) to functional ones (for systems symbolic representations).

Further Reading

External Links

The Economics of Reuse

May 15, 2012


Reusing artifacts means using them in contexts that are different of their native ones. That may come by design, when specifications can anticipate on shared concerns, or as an afterthought, when initially unexpected similarities are identified later on.

Economics of Reuse (Sergio Silva)

Economics of Reuse (Sergio Silva)

Planned or opportunistic, reuse brings benefits in terms of costs, quality, and continuity:

  • Cost benefits are most easily achieved for component engineering but may also be obtained upstream with model reuse and patterns.
  • Quality benefits are first and foremost rooted at model level, especially when components implementation is supported by automated tools.
  • Continuity benefits are to be found both along the business (semantics and business rules) and engineering (functional architecture and platform implementations) perspectives.

Reuse policies may also bring positive externalities by inducing a comprehensive approach to software design.

Yet, those policies will usually entail costs and may as well bear negative externalities:

  • Artifacts designed for reuse are usually most costly to develop, even if part of additional costs should be ascribed to quality management.
  • Excessive enforcement policies may significantly hamper projects ability to meet business needs in time.
  • Managing reusable assets usually induces overheads.

In order to assess those policies, economics of reuse must be set across business, engineering or architecture perspectives:

  • Business perspective: how to factor out and reuse artifacts associated with the knowledge of business domains when system functionalities or platforms are modified.
  • Engineering perspective: how to reuse development artifacts when business contents or system platforms are modified.
  • Architecture perspective: how to use system components independently of changes affecting business contents or development artifacts.

That can be achieved by managing development assets along model driven architecture: CIMs for business and enterprise architecture, PIMs for systems functional architecture, and PSMs for systems technical architecture.

Contexts & Concerns

Whatever their inception, reused artifacts are meant to be used independently of their native context and concerns: opportunistic reuse will map a specific purpose to another one, planned reuse will map a shared concern to a specific purpose. As a corollary, reuse policies must be supported by some traceability mechanism linking concerns and purposes across contexts and architectures.

From the enterprise perspective, the problem is to reuse the knowledge of business domains and processes. For that purpose different mechanisms can be considered:

  • The simplest solution is to reuse generic components, with the business knowledge directly transferred through parameters.
  • Similarly, business rules can be separately edited and managed in business contexts before being executed by system components.
  • One step further, business semantics and rules can be fenced off with domains and applied to different objects and applications.
  • Finally, models of business objects and processes can be capitalized and managed as reusable assets.

Reuse Policies with Model Driven Architecture

Once business knowledge is duly capitalized as functional assets, they can be reused along the engineering perspective:

  • System functionalities: functional patterns are (re)used to map functional requirements to functional architecture, and services are (re)used to support business processes.
  • Software architecture: Object and aspect oriented designs, using inheritance and polymorphism.
  • Software implementations: Component-based development and information hiding.

Along the architecture perspective information hiding is generalized to systems, and reuse is masked by the definition of services.

It must be noted that, contrary to misleading similarities, refactoring is the opposite of reuse: instead of building from well understood and safe artifacts, it tries to extract some reusable chunks from opaque and unsafe components.

Knowledge Reuse

Enterprise and business knowledge may affect the full scope of system functionalities: boundaries (e.g users authorizations), controls (e.g accounting rules), and persistency (e.g consistency constraints). Whereas there isn’t much to argue about the benefits of reusing enterprise and business knowledge, costs may significantly diverge depending on the way corresponding assets are managed:

  • Domain specific knowledge are rooted at requirements level. That’s typically achieved when use cases are introduced to describe how systems are meant to support business processes. With different use cases targeting different aspects of the same business objects and processes, overlaps must be identified and factored out in order to be reused across processes.
  • Business knowledge may also be global, i.e shared at enterprise architecture level, defining objectives, assets and organization associated with the continuity of corporate identity and business capabilities within a regulatory and market environment.

Use cases access to respectively shared (a,b) and specific (c,d) knowledge for objects and application domains

In any case, the challenge is to map business knowledge to system models, more precisely to embed reused descriptions of business objects and process to corresponding development artifacts. At architecture level the mapping should target objects or processes identities, at domain level the focus will be on aspects and views.

As epitomized by service oriented architectures, business architectures can be mapped to system ones through delegation, either directly (business processes calling on services), or indirectly (collaboration between services). That will establish a clear distinction between shared (aka global) and domain specific knowledge, and consequently between respective economics of reuse.

  • Given that shared knowledge must be reused across domains and applications, there can be no argument about benefits. That will be achieved by a messaging model built on a need-to-know basis. And since such model is an intrinsic feature of the functional architecture, it incurs no additional overheads.
  • Specific knowledge for its part is managed at domain level and therefore masked behind services interfaces. Whatever reuse occurs there remains local and an intrinsic part of domain design.

Knowledge Reuse through services (a), boundaries (b), controls (c), and entities (d).

Things are not so clear when business knowledge is not managed by services but distributed across domains, mixing specific and global knowledge. Managing reusable assets would be easy were the distinction between business and functional requirements to coincide with the one between shared and specific knowledge; unfortunately that’s seldom the case, and requirements, functional or business, will have to be sorted out at architecture or design level.

Whereas Service Oriented Architectures (SOA) put functionalities in the driving seat, Enterprise Application Integration (EAI) gives the lead to applications for which it provides adapters. As maintenance of integration adapters is a very poor substitute for knowledge management, reuse is mostly limited to legacy applications.

Maintaining adapters across layers of applications induces significant overheads

At design level knowledge is weaved into canonical data models (entities), functional architectures (controls), and user interfaces frameworks (boundaries).

Mixed concerns: business requirements can be specific, functional ones can be global.

On one hand, tracing reuse to requirements may be problematic as they are by nature concrete and unstructured, hence not the best support for generalization or the factoring out of shared features. Assuming business analysts can nonetheless separate reusable wheat from specific chaff, knowledge management at this level will require a dedicated framework supporting comprehensive and differentiated traceability. Additional overheads will have to be taken into account and compared to potential benefits.

On the other hand, canonical data models and functional architectures are meant to provide unified views of shared objects and semantic domains. Yet, canonical models are by nature unwieldy as they carve structures, features, and connections of business objects, without clear mechanisms to combine shared and specific knowledge. As a corollary, their use may reduce flexibility, and their management usually induces significant overheads.

Artifacts Reuse

With enterprise and business knowledge capitalized as development assets, the engineering case for reuse may appears indisputable, but business cases are often much more controversial due to large overheads and fleeting returns. Taking cues from Barry Boehm (“Managing Software Productivity and Reuse”),  here are some of the main pitfalls of artifacts reuse:

  • Repository delusion: knowledge being by nature contextual, its reuse is driven by circumstances and purposes; as a consequence the availability of large repositories of development assets will probably be ignored without clear pointers rooted in contexts and concerns.
  • Confusion between components (or structures) and functionalities (or interfaces): under the influence of the object oriented paradigm, the distinction between objects and aspects is all too often forgotten. That’s unfortunate as this difference is congruent with the one between business objects on one hand, business operations on the other hand.
  • Over generalization: reuse is usually achieved by factoring out useful aspects or factoring off useless ones. In both cases the temptation is to repeat the operation until nothing could be added to the scope. Such “flight for abstraction” will inevitably overtake the proper level of reuse and begets models void of any anchor to business relevancy.
  • Scalability: while reuse is about separation of concerns and complexity management, those two criteria don’t have to pull in the same direction. When they don’t, variants will be dispersed across artifacts and their processing will suffer a combinatorial explosion if the system has to be scaled up.
  • Obsolescence: shelf lives of development assets can be defined by each or both business or technical relevancy. Assuming spans either coincide or are managed independently, they should be explicitly taken into account before any reuse.

Those obstacles can be managed providing that models:

Sorting out reuse concerns with differentiated inheritance.

Economics of Reuse and Sustainable Development

Sustainable system development is the ability to meet present business requirements while enhancing system capability to support future ones. Clearly reuse is not the only factor of sustainability, with architectures, returns, and risk management being pivotal. But the economics of reuse encompass most of other factors.

Architectures are clearly first to be considered, as epitomized by MDA:

  • Reuse of development assets rooted in enterprise architecture is not an option: system functionalities are meant to support business processes as they are (a).
  • At the other end of the development process, reuse of software designs and components across technical architectures should bring benefits in quality and costs (c).
  • In between reuse of system functionalities is necessary to guarantee the robustness and continuity of functional architectures; it should also leverage the benefits of reuse of enterprise and development assets (b).
Reuse of models is at the core of the MDA framework

Reuse of models is at the core of the MDA framework

Regarding returns, reuse through generic components, rules engines, or semantic domains can be directly supported by development tools, bypassing explicit models of functional architectures. That makes their costs/benefits analysis both simpler and well circumscribed. That is not the case for system functionalities which stand at the hub of perspectives. As a consequence, costs/benefits should be analyzed as a whole:

  • Regarding business assets, a clear distinction must be maintained between specific and shared knowledge, reuse being considered for the latter only.
  • Regarding the reuse of business assets as functional ones, services clearly offer the best returns. Otherwise costs/benefits are to be assessed, from reuse of vocabulary and semantics domains (straightforward, limited overheads), to canonical models and enterprise application integration (contingent, significant overheads).
  • Economics of reuse will ultimately be set by traceability mechanisms linking enterprise and business knowledge on one hand, components designs on the other hand. Even for services (c), if at a lesser degree, the business case for reuse will be decided by leveraged benefits and non cumulative costs. Hence the importance of maintaining the distinction between identified structures and associated aspects from business (a) and functional (b) requirements, to components interfaces (d) and structures (e).

Maintaining the distinction between structures and aspects from business (a) and functional (b) requirements, to components interfaces (d) and structures (e).

Finally, reuse may also play a significant role in risk management, especially when risks are managed according to their source:

  • Changes in business contexts can usually occurs along two frequency waves: short, for market opportunities, and long, for an organization’s continuity. Associated risks could be better managed if corresponding knowledge were managed accordingly.
  • System architectures are meant to evolve in synch with organization continuity; were technological environment or corporate structures subject to unexpected changes, reusable functional assets would be of great help.
  • Given that enterprise IT can no longer be self-contained and operate in isolation, reusable designs may provide buffers to technological risks and help exploiting unexpected business opportunities.

Further Reading

The Cases for Reuse

April 9, 2012


Reuse of development artifacts can come by design or as an afterthought. While in the latter case artifacts may have been originally devised for specific contexts and purposes, in the former case they would have been originated by shared concerns and designed according architectural constraints and mechanisms.

Reinventing the Wheel ? (Ready-made, M. Duchamp)

Architectures for their part are about stable and sound assets and mechanisms meant to support activities which, by nature, must be adaptable to changing concerns. That is precisely what reusable assets should be looking for, and that may clarify the rationale supporting models and languages:

  1. Why models: to describe shared (i.e reused) artifacts along development processes.
  2. Why non specific languages: to support the sharing of models across business domains and organizational units.
  3. Why model layers: to manage reusable development assets according architectural concerns.

Reuse Perspective: Business Domains vs Development Artifacts

As already noted, software artifacts incorporate contents from two perspectives:

  • Domain models describe business objects and processes independently of the way they are supported by systems.
  • Development models describe how to design and implement system components.

Artifacts reflect external as well as development concerns.

As illustrated by agile methods and domain specific languages, that distinction can be ignored when applications are self-contained and projects ownership is shared. In that case reusable assets are managed along business domains, functional architectures are masked, and technical ones are managed by development tools.

Otherwise, reusable assets would be meaningless, even counterproductive, without being associated with clearly defined objectives:

  • Domain models and business processes are meant to deal with business objectives, for instance, how to assess insurance premiums or compute missile trajectory.
  • System functionalities lend a hand in solving business problems. Use cases are widely used to describe how systems are to support business processes, and system functionalities are combined to realize use cases.
  • Platform components provide technical solutions as they achieve targeted functionalities for different users, within distributed locations, under economic constraints on performances and resources.
Problems and solutions must be set along architecture layers

Context and purpose of reusable assets

Whatever the basis, design or afterthought, reusing an artifact comes as a solution to a specific problem: how to support business requirements, how to specify system functionalities, how to implement system components. Describing problems and solutions along architecture layers should therefore be the backbone of reusable assets management.

Model and Architecture Layers

According model driven architecture principles, models should be organized around three layers depending on contents:

  • Computation independent models (CIMs) describe business objects and processes independently of the way they are supported by system functionalities. Contents are business specific that can be reused when functional architectures are modified (a). Business specific contents (e.g business rules) can also be reused when changes do not affect functional architectures and may therefore be directly applied to platform specific models (c).
  • Platform independent models (PIMs) describe system functionalities independently of supporting platforms. They are reused to design new supporting platforms (b).
  • Platform specific models (PSMs) describe software components. They are used to implement software components to be deployed on platforms (d).

Model and Architecture Layers

Not by chance, invariants within model layers can also be associated with corresponding architectures:

  • Enterprise architecture (as described by CIMs) deals with objectives, assets and organization associated with the continuity of corporate identity and business capabilities within a regulatory and market environment.
  • Functional architecture (as described by PIMs) deals with the continuity of systems functionalities and mechanisms supporting business processes.
  • Technical architecture (as described by PSMs) deals with the feasibility, interoperability, efficiency and economics of systems operations.

That makes architecture invariants the candidates of choice for reusable assets.

Enterprise Architecture Assets

Systems context and purposes are set by enterprise architecture. From an engineering perspective reusable assets  (aka knowledge) must include domains, business objects, activities, and processes.

  • Domains are used to describe the format and semantics of elementary features independently of objects and activities.
  • Business objects identity and consistency must be maintained along time independently of supporting systems. That’s not the case for features and rules which can be modified or extended.
  • Activities (and associated roles) describe how business objects are to be processed. Semantics and records have to be maintained along time but details of operations can change.
  • Business processes and events describe how activities are performed.

Enterprise Architecture Assets (anchors and semantic domains)

As far as enterprise architecture is concerned, structure and semantics of reusable assets should be described independently of system modeling methods.

Structures can be unambiguously described with standard connectors for composition, aggregation and reference,  and variants by subsets and power-types, both for static and dynamic partitions.

Combining Object and Aspect Oriented principles, reuse of enterprise architecture assets should distinguish between identities and structures on one hand, semantics on the other hand.

With regard to business activities, semantics are set by targets:

  • Processing of physical objects.
  • Processing of notional objects.
  • Agents decisions.
  • Processing of events.
  • Computations.
  • Control of processes execution.

Regarding business objects, semantics are set by what is represented:

  • State of physical objects.
  • State of notional object.
  • History of roles.
  • Events.
  • Computations.
  • Execution states.

Enterprise Architecture Assets (with variants and stereotypes)

Enterprise assets are managed according identification, structure, and semantics, as defined along a business perspective. When reused as development artifacts the same attributes will have to be mapped to an engineering perspective.

Use Cases: A bridge between Enterprise and System Architectures

Systems are supposed to support the continuity and consistency of business processes independently of platforms technologies. For that purpose two conditions must be fulfilled:

  1. Identification continuity of business domains: objects identities are kept in sync with their system representations all along their life-cycle, independently of changes in business processes.
  2. Semantic continuity of functional architectures: the history of system representations can be traced back to associated business operations.

Hence, it is first necessary to anchor requirements objects and activities to persistency and functional execution units.

Reusing persistency and functional units to anchor new requirements to enterprise architecture.

Once identities and semantics are properly secured, requirements can be analyzed along standard architecture levels: boundaries (transient objects, local execution), controls (transient objects, shared execution), entities (persistent objects, shared execution).

The main objective at this stage is to identify shared functionalities whose specification should be factored out as candidates for reuse. Three criteria are to be considered:

  1. System boundaries: no reusable assets can stand across systems boundaries. For instance, were billing outsourced the corresponding activity would have to be hid behind a role.
  2. Architecture level: no reusable assets can stand across architecture levels. For instance, the shared operations for staff interface will have to be regrouped at boundary level.
  3. Coupling: no reusable asset can support different synchronization constraint. For instance, checking in and out are bound to external events while room updates and billing are not.

Using  stereotypes to identify shared functionalities along architecture levels

It’s worth to note that the objectives of requirements analysis do not depend on the specifics of projects or methods:

  • Requirements are to be anchored to objects identities and activities semantics either through use cases or directly.
  • Functionalities are to be consolidated either within new requirements and/or with existing applications.

The Cases for Reuse

As noted above, models and non specific languages are pivotal when new requirements are to be fully or partially supported by existing system functionalities. That may be done by simple reuse of current assets or may call for the consolidation of existing and new artifacts. In any case, reusable assets must be managed along system boundaries, architecture levels, and execution coupling.

For instance, a Clean Room use case goes like: the cleaning staff manages a list of rooms to clean, checks details for status, cleans the room (non supported), and updates lists and room status.

Reuse of Functionalities

Its realization entails different kinds of reuse:

  • Existing persistency functionality, new business feature: providing a cleaning status is added to the Room entity, Check details can be reused directly (a).
  • Consolidated control functionality and delegation: a generic list manager could be applied to customers and rooms and used by cleaning and reservation use cases (b).
  • Specialized boundary functionality: staff interfaces can be composed of a mandatory header with optional panels respectively for check I/O and cleaning (c).

Reuse and Consolidation of functionalities

Reuse and Functional Architecture

Once business requirements taken into account, the problem is how to reuse existing system functionalities to support new functional requirements. Beyond the various approaches and terminologies, there is a broad consensus about the three basic functional levels, usually labelled as model, view, controller (aka MVC):

  • Model: shared and a life-cycle independent of business processes. The continuity and consistency of business objects representation must be guaranteed independently of the applications using them.
  • Control: shared with a life-cycle set by a business process. The continuity and consistency of representations is managed independently of the persistency of business objects and interactions with external agents or devices.
  • View: what is not shared with a life-cycle set by user session. The continuity and consistency of representations is managed locally (interactions with external agents or devices independently of targeted applications.
  • Service: what is shared with no life-cycle.

The Cases for Functional Reuse

Assuming that functional assets are managed along those levels, reuse can be achieved by domains, delegation, specialization, or generalization:

  • Semantic domains: shared features (addresses, prices, etc) should reuse descriptions set at business level.
  • Delegation: part of a new functionality (+) can be supported by an existing one (=).
  • Specialization: a new functionality is introduced as an extension (+) of an existing one (=).
  • Generalization: a new functionality is introduced (+) and consolidated with existing ones  (~)  by factoring out shared features (/).

It must be noted that while reuse by delegation operates at instance level and may directly affect coupling constraints on functional architectures, that’s not the case for specialization and generalization which are set at type level and whose impact can be dealt with by technical architectures.

Those options can also be mapped to agile development principles as defined by R.C. Martin:

  • Single-Responsibility Principle (SRP) : software artifacts should have only one reason to change.
  • Open-Closed Principle (OCP) : software artifacts should be open for extension, but closed for modification.
  • Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types. In other words a given set of instances must be equally mapped to types whatever the level of abstraction.
  • Dependency-Inversion principle (DIP): high level functionalities should not depend on low level ones. Both should depend on abstract interfaces.
  • Interface-Segregation Principle (ISP): client software artifacts should not be forced to depend on methods that they do not use.

Reuse by Delegation

Delegation  should be considered when different responsibilities are mixed that could be set apart. That will clearly foster more cohesive responsibilities and may also bring about abstract (i.e functional) descriptions of low level  (i.e technical) operations.

Reuse by Delegation

Reuse may be actual (the targeted asset is already defined) or forthcoming (the targeted asset has to be created). Service Oriented Architectures are the archetypal realization of reuse by delegation.

Since it operates at instance level, reuse by delegation may overlap functional layers and therefore introduce coupling constraints on data or control flows that could not be supported by targeted architectures.

Reuse by Specialization

Specialization is to be considered when a subset of objects has some additional features. Assuming base functionalities are not affected, specialization fulfills the open-closed principle. And being introduced for a subset of the base population it will also guarantee the Liskov substitution principle.

Reuse by Specialization

Reuse may be actual (a base type already exists) or forthcoming (base and subtype are created simultaneously).

Since it operates at type level, reuse by specialization is supposed to be dealt with by technical architectures. As a corollary, it should not overlap functional layers.

Reuse by Generalization

Generalization should be considered when different sets of objects share a subset of features. Contrary to delegation and specialization, it does affect existing functionalities and may therefore introduce adverse outcomes. While pitfalls may be avoided (or their consequences curbed) for boundary artifacts whose execution is self-contained, that’s more difficult for control and persistency ones, which are meant to support multiple execution within shared address spaces.

When artifacts are used to create transient objects run in self-contained contexts, generalization is straightforward and the factoring out of shared features (a) will clearly further artifacts reuse .

Reuse by generalization put open-closed and interface-segregation principles at risk.

Yet, through its side-effects, generalization may also undermine the design of the whole, for instance:

  • The open-closed principle may be at risk because when part of a given functionality is factored out, its original semantics are meant to be modified  in order to be reused by siblings. That would be the case if authorize() was to be modified for initial screen subtypes as a consequence of reusing the base screen for a new manager screen (b).
  • Reuse by generalization may also conflict with single-responsibility and interface-segregation principles when a specialized functionality is made to reuse a base one designed for its new siblings. For instance, if the standard reservation screen is adjusted to make room for manager screen it may take into account methods specific to managers (c).

Those problems may be compounded when reuse is applied to control and persistency artifacts: when a generic facility handler and the corresponding record are specialized for a new reservation targeting cars, they both reuse instantiation mechanisms and methods supporting multiple execution within shared address spaces; that is not the case for generalization as the new roots for facility handler and reservation cannot be achieved without modifying existing handler and recording of room reservations.

Reuse by Abstraction: Specialization is safer than Generalization

Since reuse through abstraction is based on inheritance mechanisms, that’s where the cases for reuse are to be examined.

Reuse by Inheritance

As noted above, reuse by generalization may undermine the design of boundaries, control, and persistency artifacts. While risks for boundaries are by nature local and limited to static descriptions, at control and persistency layers they affect instantiation mechanisms and shared execution at system level. And those those pitfalls can be circumscribed by a distinction between objects and aspects.

  • Object types describe set of identified instances. In that case reuse by generalization means that objects targeted by new artifact must be identified and structured according the base descriptions whose reuse is under consideration. From a programming perspective object types will be eventually implemented as concrete classes.
  • Aspect types describe behaviors or functionalities independently of the objects supporting them. Reuse of aspects can be understood as inheritance or composition. From a programming perspective they will be eventually implemented as interfaces or abstract classes.

Unfettered by programming languages constraints, generalization can be given consistent and unambiguous semantics. As a consequence, reuse by generalization can be introduced selectively to structures and aspects, with single inheritance for the former, multiple for the latter.

Not by chance, that distinction can be directly mapped to the taxonomy of design patterns proposed by the Gang of Four:

  • Creational designs deal with the instanciation of objects.
  • Structural designs deal with the building of structures.
  • Behavioral designs deal with the functionalities supported by objects.

Applied to boundary artifacts, the distinction broadly coincides with the one between main windows (e.g Java Frames) on one hand, other graphical user interface components on the other hand, with the former identifying users sessions. For example, screens will be composed of a common header and specialized with components for managers and staffs. Support for reservation or cleaning activities will be achieved by inheriting corresponding aspects.

Reuse of boundary artifacts through structures and aspects inheritance

Freed from single inheritance constraints, the granularity of functionalities can be set independently of structures. Combined with selective inheritance, that will directly benefit open-closed, single-responsibility and interface-segregation principles.

The distinction between identifying structures on one hand, aspects on the other hand, is still more critical for artifacts supporting control functionalities as they must guarantee multiple execution within shared address spaces. In other words reuse of control artifacts should first and foremost be about managing identities and conflicting behaviors. And that can be best achieved when instantiation, structures, and aspects are designed independently:

  • Whatever the targeted facility, a session must be created for, and identified by, each user request (#). Yet, since reservations cannot be processed independently, they must be managed under a single control (aka authority) within a single address space.
  • That’s not the case for the consultation of details which can therefore be supported by artifacts whose identification is not bound to sessions.

Reuse of control artifacts through structures and aspects inheritance

Extensions, e.g for flights, will reuse creation and identification mechanisms along strong (binding) inheritance links; generalization will be safer as it will focus on clearly defined operations. Reuse of aspects will be managed separately along weak (non binding) inheritance links.

Reuse of control artifacts through selective inheritance may be especially useful with regard to dependency-inversion principle as it will facilitate the distinction between policy, mechanism, and utility layers.

Regarding artifacts supporting persistency, the main challenge is about domains consistency, best addressed by the Liskov substitution principle. According to that principle, a given set of instances should be equivalently represented independently of the level of abstraction. For example, the same instances of facilities should be represented identically as such or according their types. Clearly that will not be possible with overlapping subsets as the number of instances will differ depending on the level of abstraction.

But taxonomies being business driven, they usually overlap when the same objects are targeted by different business domains, as could be the case if reservations were targeting transport and lodging services while facility providers were managing actual resources with overlapping services. With selective inheritance it will be possible to reuse aspects without contradicting the substitution principle.

Reuse of persistency artifacts through structures and aspects inheritance

Reuse across Functional Architecture Layers

Contrary to reuse by delegation, which relates to instances, reuse by abstraction relates to types and should not be applied across functional architecture layers lest it would break the separation of concerns. Hence the importance of the distinction between reuse of structures, which may impact on identification, and the reuse of aspects, which doesn’t.

Given that reuse of development artifacts is to be governed along architecture levels (enterprise, system functionalities, platform technologies) on one hand, and functional layers (boundaries, controls, persistency) on the other hand, some principles must be set regarding eligible mechanisms.

Two mechanisms are available for type reuse across architecture levels:

  • Semantics domains are defined by enterprise architecture and can be directly reused by functionalities.
  • Design patterns enable the transformation of functional assets into technical ones.

Otherwise reuse policies must follow functional layers:

  1. Base entities are first anchored to business objects (1), with possible subsequent specialization (1b). Generalization must distinguish between structures and aspects lest to break continuity and consistency of representations.
  2. Base controls are anchored to business activities and may reuse entities (2). They may be specialized (2b). Generalization must distinguish between structures and aspects lest to break continuity and consistency of business processes.
  3. Base boundaries are anchored to roles and may reuse controls (3). They may be specialized (3b). Generalization must distinguish between structures and aspects lest to break continuity and consistency of sessions.

Reuse across architecture layers

Further Reading

Requirements Capture

March 1, 2012


Requirements are not manna from heaven, they do not come to the world as models. So, what is the starting point, the primary input ?  According to John,  “In the beginning was the word …”, but Gabriel García Márquez counters that at the beginning “The world was so recent that many things lacked names, and in order to indicate them it was necessary to point. ”

Frog meditating on requirements capture (Sengai)

Requirements capture is the first step along project paths, when neither words nor things can be taken for granted: names may not be adequately fixed to denoted objects or phenomena, and those ones being pointed at may still be anonymous, waiting to be named.

Confronted with lumps of words, assertions and rules, requirements capture may proceed with one of two basic options: organize requirements around already known structuring objects or processes, or listen to user stories and organize requirements alongside. In both cases the objective is to spin words into identified threads (objects, processes, or stories) and weave them into a fabric with clear and non ambiguous motifs.

From Stories to Models

Requirements capture epitomizes the transition from spoken to written languages as its objective is to write down user expectations using modeling languages. Just like languages in general, such transitions can be achieved through either alphabetical of logographic writing systems, the former mapping sounds (phonemes) to signs (glyphs), the latter setting out from words and mapping them to symbols associated with archetypal meanings; and that is precisely what models are supposed to do.

From words to strokes: how to figure out users expectations.

As demonstrated by Kanji, logographic writing systems can support different spoken languages providing they share some cultural background. That is more or less what is at stake with requirements capture: tapping requirements from various specific domains and transform them into functional requirements describing how systems are expected to support business processes. System functionalities being a well circumscribed and homogeneous background, a modeling framework supporting requirements capture shouldn’t be out of reach.

Getting the right stories

If requirements are meant to express actual business concerns grounded in the here and now of operations, trying to apprehend them directly as “conceptual” models would negate the rationale supporting requirements capture. User stories and use cases help to prevent such misgivings by rooting requirements in concrete business backgrounds of shared references and meanings.

Requirements capture should never flight to otherworldly expectations

Yet, since the aim of requirements is to define how system functionalities will support business processes, it would help to get the stories and cases right upfront, in other words to organize them according patterns of functionalities. Taking a cue from the Gang of Four, three basic categories should be considered:

  • Creational cases or stories deal with the structure and semantics of business objects whose integrity and consistency has to be persistently maintained independently of activities using them. They will govern objects life-cycle (create and delete operations) and identification mechanisms (fetch operations).
  • Structural cases or stories deal with the structure and semantics of transient objects whose integrity and consistency has to be maintained while in use by activities. They will govern features (read and update operations) and target aspects and activities rooted (aka identified) through primary objects or processes.
  • Behavioral cases or stories deal with the ways objects are processed.

Behavioral stories may introduce different perspectives

Not by chance, those categories are consistent with the Object/Aspects perspective that distinguish between identities and objects life-cycle on one hand, features and facets on the other hand. They are also congruent with the persistent (non-transactional)/transient (transactional) distinction, and may also be mapped to CRUD matrices.

Since cases and stories will often combine two or three basic categories, they should be structured accordingly and reorganized as to coincide with the responsibilities on domains and projects defined by stakeholders.

User Stories vs Use Cases

Other than requirements templates, user stories and use cases are two of the preferred methods for capture requirements. Both put the focus on user experience and non formal descriptions, with use cases focusing at once on interactions between agents and systems, and user stories introducing them along the course of refinements. That make them complementary:

  • Use cases should be the method of choice when new functionalities are to be added to existing systems.
  • User stories would be more suited to standalone applications but may also be helpful to single out use cases success scenarii.

Depending on circumstances it may be easier to begin requirements capture with a success story (green lines) and its variants or with use cases (red characters) with some activities already defined.

User Stories vs Use Cases

Combining user stories and use cases for requirement capture may also put the focus on system footprint, setting apart the activities to be supported by the system under consideration. On a broader perspective, that may help to position requirements along architecture layers: user stories arise from business processes  set within enterprise architecture, use cases are supported by functional architecture.

Spinning the Stories

Given that the aim of requirements is to define how systems will support processes execution and objects persistency, a sound policy should be to characterize those anchors meant to be targeted by requirements nouns and verbs. That may be achieved with basic parsing procedures:

  • Nouns and verbs are set apart and associated to candidates archetypes for physical or symbolic object, physical or symbolic activity, corresponding container, event, or role.
  • Among them business concerns should point to managed individuals, i.e those anchors whose instances must be consistently identified by business processes.
  • Finally business rules will be used to define features whose values are to be managed at instances level.

Spinning words into archetypes

Parsing nondescript requirements for anchors will set apart a distinctive backbone of clear and straight threads on one hand, a remainder of rough and tousled features and rules on the other hand.

Fleshing the Stories out

Archetypes are like clichés, they may support a story but cannot make it. So it goes with requirements whose meaning is to be found into the intricacy of features and business rules.

However tangled and poorly formulated, rules provide the substance of requirements as they express the primary constraints, needs and purposes. That jumble can usually be reshaped in different ways depending on perspective (business or functional requirements),  timing constraints (synchronous or asynchronous) or architectural contexts; as a corollary, the way rules are expressed will have a significant impact on the functional architecture of the system under consideration.

If transparency and traceability of functional arbitrages are to be supported, the configuration of rules has to be rationalized from requirements inception. Just like figures of speech help oral storytelling, rules archetypes may help to sort out syntax from semantics, the former tied to rules themselves, the latter derived from their targets. For instance, constraints on occurrences (#), collections (*) or partitions (2) should be expressed uniformly whatever their target: objects, activities, roles, or events.

From rules syntax to requirements semantics

As a consequence, and to all intents and purposes, rules analysis should not only govern requirements capture, it should also shadow iterations of requirements analysis, each cycle circumscribed by the consolidation of anchors:
  • Single responsibility for rule implementation: project, architecture or services, users.
  • Category: whether a rule is about life-cycle, structure, or behavior.
  • Scope: whether enforcement is transient of persistent.
  • Coupling: rules triggered by, or bringing change to, contexts must be set apart.
  • Control: whether enforcement has to be monitored in real-time.
  • Power-types and extension points: all variants should be explicitly associated to a classification or a branching rule.
  • Subsidiarity: rules ought to be handled at the lowest level possible: system, domain, collection, component, feature.

Pricing the Stories

One of the primary objectives of requirements is to put a price on the system under consideration and to assess its return on investment (ROI). If that is straightforward for hardware and off-the-shelf components, things are not so easy for software developments whose metrics are often either pragmatic but specific, or  inclusive but unreliable.

Putting aside approaches based on programs size, both irrelevant for requirements assessment and discredited as development metrics, requirements can be assessed using story or function points:

  • Story points conduct pragmatic assessments of self-contained stories. They are mostly used locally by project teams to estimate their tasks and effort.
  • Functional metrics are more inclusive as based on principled assessment of archetypal system functionalities. Yet they are mostly confined to large organizations and their effectiveness and reliability highly depends on expertise.

Whereas both approaches start with user expectations regarding system support, their rationale is different: function points (FPs) apply to use cases and take into account the functionalities supported by the system; story points (SPs) apply to user stories and their scope is by definition circumscribed. That difference may be critical when categories are considered: points for behavioral, structural and creational stories should be weighted differently.

Yet, when requirements capture is supported both by stories and use cases, story and functions points can be combined to obtain functional size measurements:

  • Story points are used to assess business contents (aka application domain) based on master data (aka persistent) entities, activities, and their respective power-types.
  • Use case points target the part played by the system, based on roles and coupling constraints defined by active objects, events, and controlling processes.

Function Points as Use Case Points weighted by Story Points

Non adjusted function points can then be computed by weighting use case function points with the application domain function points corresponding to use case footprint.

Further Reading

Models, Architectures, Perspectives (MAPs)

December 20, 2011

What You See Is Not What You Get

Models are representations and as such they are necessarily set in perspective and marked out by concerns.

Model, Perspective, Concern (R. Doisneau).
  • Depending on perspective, models will encompass whole contexts (symbolic, mechanic, and human components), information systems (functional components), software (components implementation).
  • Depending on concerns models will take into account responsibilities (enterprise architecture), functionalities (functional architecture), and operations (technical architecture).

While it may be a sensible aim, perspectives and concerns are not necessarily congruent as responsibilities or functionalities may cross perspectives (e.g support units), and perspectives may mix concerns (e.g legacies and migrations). That conundrum may be resolved by a clear distinction between descriptive and prescriptive models, the former dealing with the problem at hand, the latter with the corresponding solutions, respectively for business, system functionalities, and system implementation.

Models as Knowledge

Assuming that systems are built to manage symbolic representations of business domains and operations, models are best understood as knowledge, as defined by the pivotal article of Davis, Shrobe, and Szolovits:

  1. Surrogate: models provide the description of symbolic objects standing as counterparts of managed business objects and activities.
  2. Ontological commitments: models include statements about the categories of things that may exist in the domain under consideration.
  3. Fragmentary theory of intelligent reasoning: models include statements of what the things can do or can be done with.
  4. Medium for efficient computation: making models understandable by computers is a necessary step for any learning curve.
  5. Medium for human expression: models are meant to improve the communication between specific domain experts on one hand, generic knowledge managers on the other hand.

Surrogates without Ontological Commitment

What You Think Is What You Get

Whereas conventional engineering has to deal with physical artifacts, software engineering has only symbolic ones to consider. As a consequence, design models can be processed into products without any physical impediments: “What You Think Is What You Get.”

Products and Usage are two different things

Yet even well designed products are not necessarily used as expected, especially if organizational and business contexts have changed since requirements capture.

Models and Architectures

Models are partial or complete descriptions of existing or intended systems. Given that systems will eventually be implemented by software components, models and programs may overlap or even be congruent in case of systems made exclusively of software components. Moreover, legacy systems are likely to get along together with models and software components. Such cohabitation calls for some common roof, supported by shared architectures:

  • Enterprise architecture deals with the continuity of business concerns.
  • System architecture deals with the continuity of systems functionalities.
  • Technical architecture  deals with the continuity of systems implementations.

That distinction can also be applied to engineering problems and solutions: business (>enterprise), organization (supporting systems), and development (implementations).

Problems and solutions must be set along architecture layers

Problems and solutions must be set along architecture layers

On that basis the aim of analysis is to define the relationship between business processes and supporting systems, and the aim of design is to do the same between system functionalities and components implementation.

Dial M for Models

If systems could be developed along a “fire and forget” procedure models would be used only once. Since that’s not usually the case bridges between business contexts and supporting systems cannot be burned; models must be built and maintained both for business and system architectures, and the semantics of modeling languages defined accordingly.

Languages, Concerns, Perspectives

Apart for trivial or standalone applications, engineering processes will involve several parties whose collaboration along time will call for sound languages. Programming languages are meant to be executed by symbolic devices, business languages (e.g B.P.M.) are meant to describe business processes, and modeling languages (e.g UML) stand somewhere in-between.

As far as system engineering is concerned, modeling languages have two main purposes: (1) describe what is expected from the system under consideration, and (2) specify how it should be built. Clearly, the former belongs to the business perspective and must be expressed with its specific words, while the latter can use some “unified” language common to system designers.

The Unified Modeling Language (UML) is the outcome of the collaboration between James Rumbaugh with his Object-modeling technique (OMT), Grady Booch, with his eponymous method, and Ivar Jacobson, creator of the object-oriented software engineering (OOSE) method.

Whereas UML has been accepted as the primary standard since 1995, it’s scope remains limited and its use shallow. Moreover, when UML is effectively used, it is often for the implementation of Domain Specific Languages based upon its stereotype and profile extensions. Given the broadly recognized merits of core UML constructs, and the lack of alternative solutions, such a scant diffusion cannot be fully or even readily explained by subordinate factors. A more likely pivotal factor may be the way UML is used, in particular in the confusion between perspectives and concerns.

Perspectives and Concerns: business, functionalities, implementation

Languages are useless without pragmatics which, for modeling ones means some methodology defining what is to be modeled, how, by who, and when. Like pragmatics, methods are diverse, each bringing its own priorities and background, be it modeling concepts (e.g OOA/D), procedures (e.g RUP), or collaboration agile principles (e.g Scrum). As it happens, none deals explicitly with the pivotal challenges of the modeling process, namely: perspective (what is modeled), and concern (whose purpose).

In order to meet those challenges the objective of the Caminao framework is to provide compass and signposts for road-maps using stereotyped UML constructs.

Models, Architectures, Perspectives (MAPs)

Caminao maps are built from models, architectures, and perspectives:

  • Models set the stages, where targeted artifacts are defined depending on concerns.
  • Topography put objects into perspective as set by stakeholders situation: business objectives, system functionalities, system implementation.
  • Concerns and perspectives must be put into context as defined by enterprise, functional or technical architectures.

The aim of those maps is to support project planning and process assessment:

  • Perspective and concerns: what is at stake, who’s in charge.
  • Milestones: are expectations and commitments set across different organizational units.
  • Planning: development flows are defined between milestones and work units set accordingly.
  • Tasks traceability to outcomes and objective functional metrics provide for sound project assessment.
  • Processes can be designed, assessed and improved by matching  development patterns with development strategies.

Matching Concerns and Perspectives

As famously explained by Douglas Hofstadter’s Eternal Golden Braid, models cannot be proven true, only to be consistent or disproved.

Depending on language, internal consistency can be checked through reviews (natural language) or using automated tools (formal languages).

Refutation for its part entails checks on external consistency, in other words matching models and concerns across perspectives. For that purpose modeling stations must target well defined sets of identified objects or phenomena and use clear and non ambiguous semantics. A simplified (yet versatile), modeling cycle could therefore be exemplified as follows:

  1. Identify a milestone  relative to perspective, concern, and architecture.
  2. Select anchors (objects or activities).
  3. Add connectors and features.
  4. Check model for internal consistency.
  5. Check model for external consistency, e.g refutation by counter examples.
  6. Iterate from 2.

Further Reading

External Links

Requirements Rounds up

December 8, 2011


Whereas it is based upon well known concepts and accepted standards, the Caminao approach entails a new modeling perspective which calls for change of habits, mostly at requirements level. The objective here is to experiment some Proof of  Concept by contriving requirements on-line along the Caminao path.

Requirements Rounds up

For that purpose the proposed experiment makes use of four principles:

  • Crowd-sourcing: except for Caminao stereotypes, understanding do not come from a special expertise or best-practices but is built on collective wisdom.
  • Iterations: stakeholders and analysts are circling topics until they agree on clear and unambiguous pictures.
  • Illustrations: requirements begin as expectations, as such they should be best captured through pictures before being analyzed through models.
  • Assertions: requirements are meant to translate into commitments, hence, associated models should be settled by explicit constraints and expressions.

Requirements loops: from expectations to commitments.

On that basis stakeholders will introduce their requirements as illustrations, analysts will try to translate them into models which, after being accepted by stakeholders,  will subsequently be decorated by assertions.

Modus Operandi

  • Requirements rings are managed through the  G+ Caminao Rings page.
  • In order to submit a project, candidate stakeholders must belong to the circle of fellows.
  • Fellows stakeholders may submit projects by creating their own G+ pages and circles and identifying them with the Caminao G+.  A new page is created for each project, to be matched with the fellow G+ circle.
  • Fellow analysts propose models capturing all or parts of illustrated requirements.
  • Stakeholders may accept, reject, or hold back their decision. Refusals can be commented but reservations can only be qualified with additional illustrations.
  • Once approved models may subsequently be fleshed out with expressions, constraints and rules.


Fellow analysts can propose two types of models:

  • Horizontal models describe individual artifacts and their connections.
  • Vertical models are anchored to single artifacts and focus on their partitions and inheritance relationships.

While it’s recommended to walk along basic UML conventions, models may include any kind of artifacts providing they are qualified by Caminao stereotypes for actual or symbolic objects and activities, roles, or events.


Caminao stereotypes for nodes

Stereotypes for containers use the same principle for organizational units (110) physical locations (121), physical executions (141), business domains (120), business activities (140).

The semantics of connectors (association, flow, transition, or channel) can remain implicit and defined by context. They may be stereotyped using standard set operators.

Set-based stereotypes for Connectors

By convention, objects, events and roles are labelled with singular nouns, activities use infinitive verbs, and processes use present progressive ones. Containers are named with plurals.

Who’s in the Loops

Four types of players may appear in requirements loops:

  • Stakeholders (one by project) set the context and objectives with pictures, photos or drawings. Textual descriptions are not allowed. Stakeholders accept or reject artifacts.
  • Users and business analysts add to the stakeholder requirements using the same media (no texts); they also may qualify model artifacts with formal expressions, constraints or rules.
  • System analysts suggest artifacts.
  • Architects (one by project) accept or reject qualifications on artifacts.

Who’s in the Loop

Mind Your Words

Language and meanings may be baffling bedfellows, as what is said is not necessarily what is meant. As a boost to requirements transparency, a simple gizmo may be used  by players to speak their mind, for their interlocutor (talking bubble) or only for the audience (thinking bubble).

Say What You Mean, Mean What You Say

Price Your Words

Assuming clear understanding and good faith, customers and providers must agree on a price, and for that purpose they must align their respective expectations and commitments.

Expecting to take advantage of business opportunities at a given time, customers define system requirement along a black box perspective; in return, providers analyze those requirements along a white box perspective and make an estimate of cost and duration. Their respective expectations are consolidated and commitments made, customers regarding payment, provider regarding delivery.

As far as customers are concerned, success is measured by the return on investment (ROI), which depends on cost, quality, and timely delivery. Providers for their part will design the solution, develop the components, and integrate them into targeted environments. Narrowly defined, their success will be measured by costs. Those concerns may be played along a non-zero sum game:

  • Customers assess the benefits (a) to be expected from the functionalities under consideration (b).
  • Providers consider the solutions (a) and estimate their costs (b).
  • Customers and providers agree on functionalities, costs and schedules (c).

Matching respective expectations and commitments of customers and providers.

Hence, while stakes are clearly conflicting on costs, there is room for collaboration on quality and timing, and that will bring benefits to both customers and providers.

Square the Rings

Even for standalone applications, it’s safe to assume that requirements will have to take into account external factors and constraints. Since those requirements will usually be managed by different organizational units, they must be sorted out upfront:

  • Non functional constraints deal with performances and resources.
  • Cross functional requirements deal with system functionalities shared by different business processes.
  • Application specific requirements deal with system functionalities supporting a single business process.

Squaring requirements rings

Those rings are used to organize projects according the requirements architectural footprint and associated responsibilities.

Requirements Analysis

October 18, 2011


As the point source of the full development process, requirements are also the usual suspect if something goes wrong somewhere downstream. Since that happens more than it should, much attention has been given to the way requirements are expressed. Yet few of the proposed solutions have taken into account an uncomfortable truth: as the inception of a customer/provider transaction, requirements are by nature conflicting, informal, and subject to change. That doesn’t mean that requirements are necessarily captured as a lump of contradictory and ambiguous expectations; on the contrary, conflicting objectives must be clearly identified as well as options subject to reassessment. That is the aim of requirements analysis.

As a prerequisite, it is necessary to distinguish business requirements from functional ones: the former deal with business concerns, the latter with the support provided by the system under consideration. The focus now is on functional requirements.

Whatever the methodology, modeling processes can be mapped by a limited number of typical alternatives. Whereas some are fully set by technical contexts, critical ones are often rooted in requirements and subsequently govern development paths. The objective is therefore to identify archetypal crossroads and consistent signposts with rationale rooted at requirements.

Crossroads call for consistent signposts, not best practices.

Once dubious adornments and superfluous appendages have been cut off, core UML constructs are grounded on consistent and robust semantics. Hence the importance of a corresponding understanding of those constructs when archetypal crossroads call for direction:

  • Functional or Non Functional ?
  • Domain or Use Case ?
  • Actual or Symbolic ?
  • Power-type or Subtype ?
  • Object, Aspect, or Attribute ?
  • Attribute or Relation
  • Aggregate or Composite ?
  • Inheritance or Delegation ?
  • Static or Dynamic Rule ?
  • Milestone or Iterations ?

It must be noted that those signposts are not best practices but principled guidelines supporting clear-cut decision making.

Functional vs Non Functional

If the full model life cycle is to be traced back to requirements, and the spaghetti syndrome is to be avoided, a proper capture of requirements nature is clearly essential.

Whereas there is a broad consensus about functional requirements, namely how the system is expected to support business processes, opinions diverge regarding non functional ones, which range from standards to platforms and resources, with performances and security in between.

There is essentially three criteria to consider before setting a requirement apart as non functional:

  1. User experience: can the requirement under consideration be assessed by business users.
  2. Footprint: can the requirement be factored out and dealt with independently of any specific use case.
  3. Authority: is the requirement to be managed by a separate organizational unit.

The first two criteria can be decided in relation to established functional requirements, the third one is a matter of policy: defining some requirements as non functional put them under the authority of a separate organizational unit with its own agenda and decision making capacity.

Dial M for Models

Domain vs Use Case

Business domains (aka domains) describe the semantics and consistency rules of interrelated business objects whose persistency has to be managed as a whole independently of their use. Semantics and consistency rules must be set by a single authority.

Use cases (aka application domains) describe how a system is expected to support a business activity triggered by a single event and identified by a self contained objective.

Whereas initial requirements may present a mixed view of business and application domains, a cross analysis of business processes and objects may  help to sort things out; taking advantage of CRUD matrices usually supported by requirements tools, two criteria should be used:
– Separation of concerns: domain perimeters are meant to be set by Create and Delete operations, use cases by Read and Update. Overlaps are to be reduced by the separation of concerns.
– Separation of responsibilities: domains and use cases perimeters should coincide with the access rights of actors.

Identifying Domains and Use Cases from activities and Responsibilities

That would translate into a two-staged procedure: a first stage for identification based upon primary entities or triggering events, a second stage for refinement based upon the singling out of responsibilities and rules enactment.

Those principles are enacted by DDD (Domain Driven Development) methodologies and the CQRS (Command and Query Responsibility Segregation) design pattern.

It must be noted that those principles put special relevance to the definition of agents and the roles they are entitled to play as actors. And since that is clearly an organizational matter, it can be set fully and precisely upfront with requirements.

Actual vs Symbolic

As illustrated by the emergence of 3D printing in manufacturing, the distinction between symbolic and actual artifacts is not as straightforward as it used to be. Moreover, that distinction  may be critical for system modeling when architecture design is all about decisions between hardware and software.

To begin with, artifact semantics must be stated explicitly for actual or symbolic objects or activities. Yet, while symbolic artifacts will always be necessary (computers are meant to process symbolic data), that is not the case for actual ones whose description is only required when coupling constraints are to be supported, namely:

  • When active objects interact with the system using non symbolic languages. In that case actual objects and their symbolic counterparts must be modelled simultaneously in order to specify functional boundaries and the associated coupling constraints.
  • When the system must keep track of the state of actual activities. In that case activities and flows (data and control) will have to be associated with state machines describing actual execution and time synchronization.
Explicit modeling of actual objects and states.

While actual objects may or may not require state modeling (gates do,  meters don’t), their explicit modeling must be justified by some actual interaction (capture of gates position or bell alarm).

Power-type vs Subtype

Power-types define partitions, each instance being associated with subsets of targeted populations to which they provide shared values for selected attributes. Subtypes describe additional features specific to subsets of targeted populations.

A sound procedure is therefore:

  • Begin with partitions.
  • Proceed with power-types if targeted objects are fully described by the same set of features.
  • Introduce subtypes when some subsets make use of specific features.
Simple power-type (status), specialized one (occupation), associated with subtypes (gender).

Object, Aspect, or Attribute

The purpose of analysis models is to define the symbolic objects that will represent the actual business objects and activities. That calls for three levels of granularity:

  • At the root one will need persistency and execution units whose identity is to be used to anchor symbolic representations to their actual counterparts, either persistently or until activity completion. For instance, repairs are actual processes ordered by actual customers.
  • One level down, aspects are functional units meant to represent roles whose continuity and consistency can be described independently of the associated units. For instance, transactions regarding delivery or bills can be conducted by the owner or his representatives; and invoice can be computed independently.
  • Finally, attributes are descriptions of formats and semantics used to describe the features of objects or aspects.
Description levels for objects and activities

Whereas setting attributes apart should be straightforward considering they are meaningless on their own, that nonetheless must be checked against business concerns: addresses are usually seen as attributes when associated to customers, yet are definitively business objects for courier or real estate companies.

Distinguishing between objects and aspects is not always straightforward as it entails organizational considerations. Yet, those requirements can usually be expressed through identification and functional dependencies:

  • Aspects or roles are not necessarily bound to actual objects or agents; e.g, one may manage a property’s insurer independently of actual incumbents, with the possibility of obligations being transferred between insurers.
  • Functions are not necessarily bound to execution units; e.g, indemnities may be computed on a standalone basis, independently of specific contracts.

Attribute vs Relationship

Modeling objects and relations with graphical editors may blur the line between business requirements (aka CIMs) and system analysis (aka PIMs); yet the alternative between attributes and relationships must be decided on the basis of:

  1. Formal analysis of functional dependencies (normalization along relational theory).
  2. Business needs: attributes can be used on their own contrary to relationships which remain useless until the referenced object can be fetched (denormalization).

It must be noted that decision can (even should) be made upfront with business requirements, e.g a bank clerk who needs to fetch all the customer file or can do with his last year income. Yet, while it’s purely computation independent, it’s nonetheless critical for architecture design.

The same reasoning can be extended to other connectors, e.g when deciding if an activity is described as a local operation (as for an attribute) or delegated through a flow (as for a relationship).

Aggregate vs Composition

While modeling languages (e.g UML) or methods (e.g DDD) provide good notations and principles to describe how artifacts are connected, the focus is usually on design, with the risk of introducing some bias in requirements. Hence, before deciding if different aspects of objects are to be stored together or separately (design perspective), it is necessary to describe how they are connected (analysis perspective). And that can be achieved using standard connectors with functional stereotypes.

Functional stereotypes for connectors

Taking Scrum for example, products, sprints, and releases share a common identity and can therefore be represented by a UML composite or  DDD aggregates. While both descriptions are correct, the former may induce a poor design and the latter compels business analysts to consider implementation details.

Scrum Product: (a) UML composite, (b) DDD aggregates, (c) functional stereotypes

Inheritance vs Delegation

Analysis is all about making distinctions out of differences. One step further, those variants will have to be represented by symbolic descriptions of structural and functional specializations:

  • Structural specialization add extensions to base types, using inheritance of features and behaviors to describe instances. Inheritance may be introduced through two very different operations, namely specialization or generalization, and , as already mentioned, generalization should only be used when consolidation is necessary.
  • Functional specialization deals with behaviors and therefore can be achieved through delegation, without taking into account object structures.

If requirements are to be neutral regarding their subsequent symbolic representation they must remain closely associated to actual business objects and processes. As a corollary, subtypes should be defined from subsets, as opposed to abstraction levels which are meant to be introduced at a later stage. Along the same reasoning, the nature of variants must be clearly established either as structural (different features of persistent objects) or functional (different operations of transient objects). Those  can be achieved using roles:

  • Both specialization can be uniformly described by subtypes of objects (structural) or roles (functional).
  • Since inheritance of structural features is bound to identities, multiple structural inheritance is not possible.
  • Role inheritance, simple or multiple, can be transformed into delegation without modifying requirements semantics.
Mixed inheritance (a),  role inheritance (b),  delegation (c).

Static vs Dynamic Rules

Rules are the flesh of requirements, pervading every corner as they span bridges across objects and processes. Their sheer ubiquity makes them difficult to capture and to fasten to specific targets. As already noted, rules can be analyzed along two criteria, target and enforcement:

  • Structural rules and constraints target business objects, functional rules target business processes. While the former can be enforced both by persistency or execution units, the latter can only be supported by execution units.
  • Rules, structural or functional, can be enforced as conditions (before objects are updated or actions executed) or as consequences (after objects are updated or actions executed).

Since the way business rules and constraints are implemented may significantly impact on system architecture, their expression must be kept neutral and strictly adhere to the necessary restrictions. Hence, as a complement to functional stereotypes and rule patterns, a number of generic principles should be applied:

  • Rules and constraints on persistency units must be set apart from those on execution units (a).
  • Rules and constraints on occurrences of persistency or execution units must be set apart from those dealing with their local consistency (b).
  • Rules and constraints must be set at the lowest possible level: domain/use case, collection, persistency/execution unit, attribute/operation (c).
  • Rules and constraints on connectors must be expressed using functional stereotypes (identification, exclusion, inclusion, etc) instead of numeric cardinalities (d).
Rules analysis (symbolic level)

As it happens, those principles deal with rules targeting symbolic objects representing persistency or execution units. While they do cover time constraints, they don’t take into account synchronization constraints associated with to objects representation or processes execution. For that purpose it will be necessary to introduce external eventsexplicitly and redefine rules accordingly.

Dynamic rules set constraints on actual processes or triggers on actual changes

It must be reminded that triggering rules tied to symbolic units (persistent or transient) can be defined independently of external events whatever their subsequent event-driven implementation.

Milestone vs Iterations

Behind the (often ineffectual) debate between waterfall and agile proponents, the problem it to set milestones when and where it is necessary to validate project deliverables or consolidate them with associated  ones. If agile principles are to be heeded, such decisions should clearly be made on a case-by-case basis: sequencing is required when the footprint of a decision overlap the ones managed outside the project, otherwise iterative development is to be the organization of choice.

If development sequencing is to be based on requirements, functional and technical dependencies must be identified upfront in order to fence the areas within which iterations can be safely conducted.

Analysis, Patterns, Anti-Patterns

Requirements analysis (RA) goes in both directions, forward as projects use patterns to set their path, and backward as crossroads are checked for anti-patterns.

As a forward modeling process RA sieves through requirements looking for anchors identified by persistency or execution units. Those anchors will be refined along stereotyped structures, and serve as roots to primary threads weaved according to semantic patterns.

Requirements analysis can also proceed backward to review the outcome and check for completeness and consistency. The proportion of stereotyped artifacts provide a straightforward measure of completeness, with their consistency easily checked. Crossroads along primary threads can also be reviewed and checked for anti-patterns.

UML# Manifesto

October 18, 2011


Taking a cue from Ivar Jacobson (“The road ahead for UML“), some modularity should be introduced in order to facilitate the use of UML in different contexts, organizational, methodological, or operational. Three main overlapping objectives should be taken into consideration:

  • Complexity levels: the language features should be regrouped into clearly defined subsets corresponding to levels of description. That would open the way to leaner and fitter models.
  • Model layers: the language constructs should be re-organized along MDA layers if models are to map stakeholder concerns regarding business requirements, system functionalities, and system design.
  • Specificity: principled guidelines are needed for stereotypes and profiles in order to keep the distinction between specific contents and “unified” ones, the former set with limited scope and visibility, the latter meant to be used across model layers and/or organizational units.

As it happens, a subset of constructs centered on functional architecture may well meet those three objectives as  it will separate supporting structures (“charpentes” in french) from features whose specifications have no consequences on system architectures.

“Charpente” is french for supporting structure

State of The Art

Information technologies progress crab-like, the hardware leg striding forward with Moore Law, and the software leg crawling on practices, with rare real leaps like relational (more than 30 years ago) and object (10 years later) technologies. The adoption 15 years ago of UML as a modeling standard could have spurred a new start of innovation for software engineering; instead, its protracted diffusion and shallow or biased usage suggest a latent factor behind the limping progresses of software technologies. The absence of clear advances for the last 20 years, despite the undisputed soundness and cogency of available concepts and tools, may hint at some basic focusing error regarding what is to be considered.

When objects are considered, focus is what matters

Whereas object oriented approaches to software analysis and design are now broadly accepted, there is no consensus regarding the nature of targeted objects; more precisely, there is no explicit distinction between symbolic objects and processes on one hand, and their operational counterparts on the other hand. Such a confusion can be observed at different levels:

  • Requirements: the perspective is limited to a dual distinction between problem (what) and solution (how) spaces. That approach is much too simplistic as it overlooks the functional dimension, namely how a software solution (nothing more than a piece of code) is to be used within operational systems (a distributed set of agents, devices, and symbolic machines).
  • Time-scales: when models are used (that’s not always the case), operational contexts (business objects and processes) are captured at inception time and their description frozen as snapshots until further notice. This lack of synchronized context and system models rules out any explicit management of systems life-cycles and transformation.
  • Model contents: the aim of model driven (or based) approaches is to define development flows in terms of models and organize engineering processes accordingly. But that may not be possible if the semantics of model contents are not properly differentiated between modeling stages, the consequence being a lack of principled support for model transformation. That point is best illustrated by the perplexing debate about executable models and models as code.
  • Architectures: blurred focus on systems and contexts necessarily entails a confusion between enterprise, functional, and technical architectures. That confusion is proving to be critical when service oriented architectures (SOA) are considered.
  • Processes: the aim of development processes is to manage concerns set by different stakeholders, based upon different rationales, and subject to changes along different time-frames. If those concerns cannot be specified independently, the design and assessment of engineering processes will lack a sound basis.

Yet, since all those problems stem from the same blurred focus, they may also be deal with a shift in modeling paradigm. Moreover, that shift could be especially productive given the availability of the conceptual constructs associated with object oriented approaches and UML. For that purpose it is necessary to clarify model purposes and customize the language accordingly.

Two Legs and a Bridge

Models provide a bridge between business goals and system implementation. While simple or standalone applications may often be developed without mediation, that’s not the case for shared applications deployed across distributed system with independent life-cycles.

  • Enterprise architecture: business requirements are not necessarily expressed with modelling languages.
  • Functional architecture: functional (aka system) requirements should be expressed with modelling languages.
  • Technical architecture: non functional requirements are not expressed with modelling languages.

Dial M for Models

Grammars and Semantics

Whatever the editor, graphical or otherwise, models are built from expressions according to grammatical rules. Some rules are meaningless as they only define what is possible, i.e how to form correct expressions; others are mixed as the associated constructs may also convey some meaning.

Expressions are not necessarily textual: this one means “Sign Language”

In any case, those rules have to deal with three types of considerations: lexical, syntactic, and semantics.

  1. Legitimate items, words or symbols, are defined by the lexical layer.
  2. The way lexical items can be used to build well-formed expressions is defined by syntactic rules.
  3. Finally, language semantics define the relationships between expressions and targeted contexts.

The Unified Modeling Language (UML) is the outcome of the collaboration between James Rumbaugh with his Object-modelling technique (OMT), Grady Booch, with his eponymous method, and Ivar Jacobson, creator of the object-oriented software engineering (OOSE) method. Whereas the Three Amigos did a pretty good job in consolidating the best of different approaches, UML 1.x was not built from scratch along the ideal template: instead of drawing clear lines between lexical, syntactic, and semantics layers, constructs were first established along semantic perspectives, namely static (aka structural) and dynamic (aka behavioral) views. Formal syntactic definitions of qualifiers and expressions came almost as an afterthought.

As is often the case when ambitious objectives set by visionaries are taken over by committees, things certainly didn’t improve with UML 2.x. Having to face a growing complexity without a solid grammatical ground, the OMG turned simultaneously to abstraction and specificity: on one hand Meta-Object Facility (MOF) is meant to bypass classical grammars descriptions by bringing every modeling language under a single meta-language roof; on the other hand stereotypes and profiles provide a very practical way to tailor UML to specific domains and organizations.

But those options have driven UML into opposing directions: on one hand meta-models do nothing to improve UML capabilities and usability as their aim is mainly to enable some interoperability between tools providers; on the other hand stereotypes and profiles push UML users into specific corners, which is not what a “unified” modelling language is supposed to do. As a consequence, more than 15 years since it became a standard, UML is still not widely accepted as such; and when it is used, it is all too often on a very limited scope, or for very specific purpose, or without much of methodology.

Lean, fit, and Sharp, as in “Charpente”

The proposed approach takes advantage of UML stereotyping mechanism to reorganize the semantics around a kernel of simple syntactic constructs dealing with:

Syntactic Constructs for Charpente Descriptions

All structures (nodes, connectors and features) are to be described uniformly with a single set of standard operators.

The semantics layer is to use a finite set of stereotypes to characterize:

  • Artifacts life-cycle, transient or persistent.
  • Artifacts nature, actual or symbolic.
  • Identification mechanisms: standalone, dependent, joint, continuous.

Charpente semantics

Traceability with “Charpentes”

Finally, semantics are needed to support built-in traceability of dependencies across models or along development cycles.

Built-in Traceability

Those dependencies must be managed depending on their scope and nature.

Regarding scope, one must distinguish between dependencies involving operational contexts and those limited to symbolic artifacts.

Modeling dependencies stem from requirements and refer to both operational contexts and their symbolic representations:

  • Representation dependencies between business objects or behaviors and their symbolic counterparts.
  • Structural dependencies between roots and members.
  • Functional dependencies between connected nodes.

Development dependencies arise from modeling decisions and refer solely to symbolic artifacts:

  • Ownership dependencies between address spaces and artifacts.
  • Usage dependencies through reused features, either shared or inherited.
  • Abstraction dependencies

Regarding the nature of dependencies, a clear-cut distinction must be maintained between those rooted to decisions and those born from necessity.


Taking inspiration from the Capability Maturity Model Integration (CMMI), the benefits of UML# and, more broadly, from architecture driven modelling can be identified for product, project, and process areas:

  • Traceability is obviously a starting point as it is a prerequisite for streamlined engineering (product), portfolio and risk management (project), and application life-cycle management (process).
  • Measurement comes close, with built-in unbiased estimators, project workloads, and process assessment.
  • Quality management would clearly benefits from layered traceability and objective measurements, with built-in controls, non-regressive testing, and model-based validation.
  • Reuse provides another path to quality, with patterns (product), profiles (project) and development strategies (processes).
  • Finally, collaboration is to be facilitated between engineering processes targeting heterogeneous platforms, using different methodologies, across independent organizations.

That should open new perspectives to projects productivity and effectiveness.


A shallow implementation will simply add  UML# stereotypes to core UML diagrams.


Shallow implementation: UML# stereotypes can be applied to nodes, references, connectors, and operators for composition and inheritance

Depending on tools it may be possible (e.g with No magic) to customize diagrams or even define new ones.

A deep implementation will entail the development of a two-level interpreter, one for UML# syntax, the other for the semantics.


Deep implementation: models semantics are added to a core of syntactic constructs