Archive for the ‘Uncategorized’ Category

Focus: Business Cases for Use Cases

February 27, 2017


As originally defined by Ivar Jacobson, uses cases (UCs) are focused on the interactions between users and systems. The question is how to associate UC requirements, by nature local, concrete, and changing, with broader business objectives set along different time-frames.


Cases, Kites, and Clouds (Sigmar Polke)

Backing Use Cases

On the system side UCs can be neatly traced through the other UML diagrams for classes, activities, sequence, and states. The task is more challenging on the business side due to the diversity of concerns to be defined with other languages like Business Process Modeling Notation (BPMN).

Use cases at the hub of UML diagrams

Use Cases contexts

Broadly speaking, tracing use cases to their business environments have been undertaken with two approaches:

  • Differentiated use cases, as epitomized by Alister Cockburn’s seminal book (Readings).
  • Business use cases, to be introduced beside standard (often renamed as “system”) use cases.

As it appears, whereas Cockburn stays with UCs as defined by Jacobson but refines them to deal specifically with generalization, scaling, and extension, the second approach introduces a somewhat ill-defined concept without setting apart the different concerns.

Differentiated Use Cases

Being neatly defined by purposes (aka goals), Cockburn’s levels provide a good starting point:

  • Users: sea level (blue).
  • Summary: sky, cloud and kite (white).
  • Functions: underwater, fish and clam (indigo).

As such they can be associated with specific concerns:

Cockburn’s differentiated use cases

  • Blue level UCs are concrete; that’s where interactions are identified with regard to actual agents, place, and time.
  • White level UCs are abstract and cannot be instanciated; cloud ones are shared across business processes, kite ones are specific.
  • Indigo level UCs are concrete but not necessarily the primary source of instanciation; fish ones may or may not be associated with business functions supported by systems (grey), e.g services , clam ones are supposed to be directly implemented by system operations.

As illustrated by the example below, use cases set at enterprise or business unit level can also be concrete:

Example with actors for users and legacy systems (bold arrows for primary interactions)

UC abstraction connectors can then be used to define higher business objectives.

Business “Use” Cases

Compared to Cockburn’s efficient (no new concept) and clear (qualitative distinctions) scheme, the business use case alternative adds to the complexity with a fuzzy new concept based on quantitative distinctions like abstraction levels (lower for use cases, higher for business use cases) or granularity (respectively fine- and coarse-grained).

At first sight, using scales instead of concepts may allow a seamless modeling with the same notations and tools; but arguing for unified modeling goes against the introduction of a new concept. More critically, that seamless approach seems to overlook the semantic gap between business and system modeling languages. Instead of three-lane blacktops set along differentiated use cases, the alignment of business and system concerns is meant to be achieved through a medley of stereotypes, templates, and profiles supporting the transformation of BPMN models into UML ones.

But as far as business use cases are concerned, transformation schemes would come with serious drawbacks because the objective would not be to generate use cases from their business parent but to dynamically maintain and align business and users concerns. That brings back the question of the purpose of business use cases:

  • Are BUCs targeting business logic ? that would be redundant because mapping business rules with applications can already be achieved through UML or BPMN diagrams.
  • Are BUCs targeting business objectives ? but without a conceptual definition of “high levels” BUCs are to remain nondescript practices. As for the “lower levels” of business objectives, users’ stories already offer a better defined and accepted solution.

If that makes the concept of BUC irrelevant as well as confusing, the underlying issue of anchoring UCs to broader business objectives still remains.

Conclusion: Business Case for Use Cases

With the purposes clearly identified, the debate about BUC appears as a diversion: the key issue is to set apart stable long-term business objectives from short-term opportunistic users’ stories or use cases. So, instead of blurring the semantics of interactions by adding a business qualifier to the concept of use case, “business cases” would be better documented with the standard UC constructs for abstraction. Taking Cockburn’s example:

Abstract use cases: no actor (19), no trigger (20), no execution (21)

Different levels of abstraction can be combined, e.g:

  • Business rules at enterprise level: “Handle Claim” (19) is focused on claims independently of actual use cases.
  • Interactions at process level: “Handle Claim” (21) is focused on interactions with Customer independently of claims’ details.

Broader enterprise and business considerations can then be documented depending on scope.

Further Reading

External Links

Thinking about Practices

June 8, 2016

Caminao's Ways

A few preliminary words

A theory (aka model) is a symbolic description of contexts and concerns. A practice is a set of activities performed in actual contexts. While the latter may be governed by the former and the former developed from the latter, each should stand on its own merits whatever its debt to the other.

Good practice has no need to show off theory to hold sway (Demetre Chiparus)

Good practices hold sway without showing off theoretical subtext (Demetre Chiparus)

With regard to Software Engineering, theory and practice are often lumped together to be marketed as snake oil, with the unfortunate consequence of ruining their respective sways.

Software Engineering: from Requirements heads to Programs tails

While computer science deals with the automated processing of symbolic representations, software engineering uses it to develop applications that will support actual business processes; that may explain why software engineering is long on methods but rather short on theory.

Yet, since there is a requirements head (for business…

View original post 661 more words

The Book of Fallacies

June 7, 2016

Caminao's Ways


Whereas the design side of software engineering has made significant advances since the introduction of Object Oriented approaches, thanks mainly to the Gang of Four and others proponents of design patterns, it’s difficult to see much progress on the other (and opening) side of the engineering process, namely requirements and analysis. As such imbalance creates a bottleneck that significantly hampers the potential benefits for the whole of engineering processes, our understanding of requirements should be reassessed in order to align external and internal systems descriptions;  in other words, to put under a single modeling roof business objects and processes on one hand, their system symbolic counterparts on the other hand.

Given that disproving convictions is typically easier than establishing alternative ones, it may be necessary to deal first with some fallacies that all too often clog the path to a sound assessment of system requirements. While some are no…

View original post 784 more words

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

People should not be Confused with their Personas

December 19, 2015

Confronted with the ubiquity of IT systems and the blurring of traditional fences, enterprises grapple with the management of accesses and authorizations. Hence the importance of a clear distinction between agents, organizational units, and systems users.

(E. Erwitt)

Confusing Mimicry: People Impersonating Personas (E. Erwitt)

What is at stake is best understood by looking at the modeling of users’ access, collective agents, and interoperability.

Users’ Access

Roles (or actors in UML parlance) are meant to provide a twofold description of system users in order to combine two perspectives: organization and business process on one hand, system and applications on the other hand.

That can only be achieved by maintaining a clear distinction between actual agents, able to physically interact with systems, and roles, which are symbolic positions defined by and relative to organizations. Since mapping people and organization with systems users is the primary purpose of access rights management, lumping both sides under a single concept would definitely preclude the modeling of typical access scripts:

  • Anonymous: no authentication or authorization.
  • Registered user (role): user name and password are matched to user record.
  • Identified person: authentication of external identity.
  • Registered person: identification of a user with established external identity.
Security: actors vs actual and symbolic counterparts

Security: actors vs actual and symbolic counterparts

Given that authentication and authorization procedures depend on matching actual agents with their system symbolic representations (authentication) and roles (authorization), ignoring those distinctions would sap the whole security architecture.

Collective Agents

Confusing agents and roles may also prevent a proper management of collective authorizations.

At enterprise level parties can be identified physically as individuals or nominally as groups. But from a system perspective interactions can only be carried out by actors with physical identities, whatever their nature, users, systems, or devices.

Parties and actors are set along orthogonal perspectives, identities for the former, role for the latter.

Parties and actors are set along orthogonal perspectives, identities for the former, roles for the latter.

Managing accesses therefore requires an additional level of complexity, namely the relationship between collective and individual rights:

  • Parties can be intrinsically individual, collective, or contingent on circumstances (a).
  • As far as collective entities are concerned, access rights can directly allocated on behalf of group membership or delegated to named individuals (b).
  • Rights may depend on their origin and compatibility (c).
  • Roles allocation may be conditioned by both entitlements and specific rights on operations and objects (d).
Powertypes (2) are introduced to manage categories of roles, operations, and objects.

Powertypes (2) are introduced to manage categories of roles, operations, and objects.

That will not be possible without modeling separately entities identified by organizations (collectively or individually) and their personas while interacting with systems.


From smartphones to dumb appliances, things are unceasingly moving around networks and swapping places with people. Given the number, diversity, and turnover of interacting parties, systems are in no position to keep tabs on what is happening to agents behind the roles. Interoperability is therefore fully subordinate to the reliability and versatility of actors’ functional capabilities with regard to agents (organization) and applications (systems):

  • Agents identified externally are classified with regard to communication capability: users (natural language, digital, analog), systems (digital), and devices (analog).
  • Applications are classified with regard to their communication requirements (services, users interfaces, RT interfaces, …).
  • Actors are used to map agents to applications.

Actors can be used to characterize communication mechanism between actual agents and applications.

That formal distinction between agents and actors comes to be critical when access rights are to be checked for peer-to-peer transactions carried out across multiple participants.


Besides its benefits, the validity of this perspective is borne out by its congruence with enterprise architecture layers (business, systems functionalities, platforms technologies) and model driven engineering (e.g computation independent, platform independent, and platform specific models).

Further Reading

External Links

Focus: Capabilities vs Processes

October 21, 2014


Enterprise architecture being a nascent discipline, its boundaries and categories of concerns are still in the making. Yet, as blurs on pivotal concepts are bound to jeopardize further advances, clarification is called upon for the concept of “capability”, whose meaning seems to dither somewhere between architecture, function and process.


Jumping capability of a four-legged structure (Edgard de Souza)

Hence the benefits of applying definition guidelines to characterize capability with regard to context (architectures) and purpose (alignment between architectures and processes).

Context: Capability & Architecture

Assuming that a capability describes what can be done with a resource, applying the term to architectures would implicitly make them a mix of assets and mechanisms meant to support processes. As a corollary, such understanding would entail a clear distinction between architectures on one hand and supported processes on the other hand; that would, by the way, make an oxymoron of the expression “process architecture”.

On that basis, capabilities could be originally defined independently of business specificity, yet necessarily with regard to architecture context:

  • Business capabilities: what can be achieved given assets (technical, financial, human), organization, and information structures.
  • Systems capabilities: what kind of processes can be supported by systems functionalities.
  • Platforms capabilities: what kind of functionalities can be implemented.
Requirements should be mapped to enterprise architecture capabilities

Architectures Capabilities

Taking a leaf from the Zachman framework, five core capabilities can be identified cutting across those architecture contexts:

  • Who: authentication and authorization for agents (human or otherwise) and roles dealing with the enterprise, using system functionalities, or connecting through physical entry points.
  • What: structure and semantics of business objects, symbolic representations, and physical records.
  • How: organization and versatility of business rules.
  • Where: physical location of organizational units, processing units, and physical entry points.
  • When: synchronization of process execution with regard to external events.

Being set with regard to architecture levels, those capabilities are inherently holistic and can only pertain to the enterprise as a whole, e.g for bench-marking. Yet that is not enough if the aim is to assess architectures capabilities with regard to supported processes.

Purpose: Capability vs Process

Given that capabilities describe architectural features, they can be defined independently of processes. Pushing the reasoning to its limit, one could, as illustrated by the table above, figure a capability without even the possibility of a process. Nonetheless, as the purpose of capabilities is to align supporting architectures and supported processes, processes must indeed be introduced, and the relationship addressed and assessed.

First of all, it’s important to note that trying to establish a direct mapping between capabilities and processes will be self-defeating as it would fly in the face of architecture understood as a shared construct of assets and mechanisms. Rather, the mapping of processes to architectures is best understood with regard to architecture level: traceable between requirements and applications, designed at system level, holistic at enterprise level.

Alignment is direct b

Alignment with processes is mediated by architecture complexity.

Assuming a service oriented architecture, capabilities would be used to align enterprise and system architectures with their process counterparts:

  • Holistic capabilities will be aligned with business objectives set at enterprise level.
  • Services will be aligned with business functions and designed with regard to holistic capabilities.

Services can be designed with regard to holistic capabilities

Moreover, with or without service oriented architectures, that approach could still be used to map functional and non functional requirements to architectures capabilities.


Non functional requirements & architecture capabilities

Further Readings

External Links

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 Metrics Matter

April 9, 2012


Contrary to some unfortunate misconceptions, measurements are as much about collaboration and trust as they are about rewards or sanctions. By shedding light on objectives and pitfalls they prevent prejudiced assumptions and defensive behaviors;  by setting explicit quality and acceptance criteria they help to align respective expectations and commitments.

How to put requirements into equations (Lawrence Weiner)

How to put requirements into equations (Lawrence Weiner)

Since projects begin with requirements, decisions about targeted functionalities and resources commitments are necessarily based upon estimations made at inception. Yet at such an early stage very little is known about the size and complexity of the components to be developed. Nonetheless, quality planning all along the engineered process is to be seriously undermined if not grounded in requirements as expressed by stakeholders and users.

Business vs Functional Complexity

Contracts without transparency are worthless, and the first objective is therefore to track down complexity across enterprise architecture and business processes. For that purpose one should distinguish between business and application domains, business processes, and use cases, which describe how system functionalities support business processes.

Processes are defined on domains, system functionalities are set by use cases

Based upon intrinsic metrics computed at domain level, functional metrics are introduced to measure system functionalities supporting business processes and compare alternatives solutions. Finally requirements metrics should also provide a yardstick to assess development models.

Business Requirements Metrics

The first step is to assess the intrinsic size and complexity of business domains and processes independently of system functionalities, and that can be done according symbolic representations:

  • The footprint includes artifacts for symbolic objects and activities, partitions (objects classifications or activities variants). Symbolic objects and activities are qualified as primary or secondary depending on their identification. The reliability of the footprint is weighted by the explicit qualification of artifacts as primary or secondary.
  • Symbolic representations for objects and activities are associated with features (attributes or operations) defined within semantic domains.

A part from absolute measurements a number of basic ratios can be computed for anchors (primary objects and activities) and associated partitions.

A robust appraisal of the completeness and maturity of requirements can be derived from:

  • Percentage of artifacts with undefined identification mechanism.
  • Percentage of partitions with undefined characteristics (exclusivity, changeability).

The organization and structure of requirements can be estimated by:

  • Average number of artifacts and partitions by domain (a).
  • Total number of secondary objects and activities relative to primary ones.
  • Average and maximum depth of secondary identification.
  • Total number of primary activities relative to primary objects
  • Total number of features (attributes and operations) relative to number of artifacts.
  • Ratio of local features (defined at artifact level) relative to shared (defined at domain level) ones.

Finally intrinsic complexity can be objectively assessed using partitions:

  • Total number of activity variants relative to object classifications.
  • Total number of exclusive partitions relative to primary artifacts, respectively for objects and activities.
  • Percentage of activity variants combined with object classifications.
  • Average and maximum depth of cross partitions.

It must be noted that whereas those ratios do not depend of any modeling method, they can nonetheless be used to assess requirements or refactor them according specific methods, patterns, or practices.

Functional Requirements Metrics

Functional metrics target the support systems are meant to bring to business processes:

  • The footprint of supporting functionalities is marked out by roles to be supported, active physical objects to be interfaced, events to be managed, and processes to be executed. As for symbolic representations, corresponding artifacts are to be qualified as primary or secondary depending on their identification, with accuracy and reliability of metrics weighted by the completeness of qualifications.
  • Functional artifacts (objects, processes, events, and roles) are associated with anchors and features (attributes or operations) defined by business requirements.

From business to functional requirements metrics

Given that use cases are meant to focus on interactions between systems and contexts, they should provide the best basis for functional metrics:

  • Interactions with users, identified by primary roles and weighted by activities and flows (a).
  • Access to business (aka persistent) objects, weighted by complexity and features (b).
  • Control of execution, weighted by variants and couplings (c).
  • Processing of objects, weighted by variants and features (d).
  • Processing of actual (analog) events, weighted by features (e).
  • Processing of physical objects, weighted by features (f).

Additional adjustments are to be considered for distributed locations and synchronous execution.

Use Cases metrics can also provide a basis for quality checks:

  • Average and maximum number of root use cases relative to business and application domains.
  • Average and maximum number of root use cases relative to primary activities.
  • Average and maximum number of secondary use cases relative to root ones.
  • Average number of primary (for identified) and secondary roles relative to root use cases.
  • Average number primary (aka external) and secondary (issued by use cases) events relative to root use cases.
  • Average and maximum number of primary objects relative to  use cases.
  • The number of variants supported by a use case relative to the total associated with its footprint, respectively for persistent and transient objects.

Requirements Metrics, Contracts, and Acceptance Criteria

As noted above, requirements metrics are a means to a dual end, namely to set a price on developments and define corresponding acceptance criteria.  Moreover, as far are business is concerned, change is the rule of the game. Hence, if many projects can be set on detailed and stable requirements, projects with overlapping concerns and outlying horizons will usually entail changing contexts and priorities. While the former can be contracted out for fixed prices, the latter should clearly allow some room for manoeuvre, and requirements metrics can help to manage that room.

  1. Assuming that projects are initiated from clearly identified business domains or processes, requirements capture should be set against a preliminary wire-frame referencing new or existing pivotal elements of business (1) and system (2) contexts. Those wire-frames (aka anchors, aka backbones) will be used both for circumscribing envelops and managing changes.
  2. Envelops should be defined along architecture layers:  enterprise for business objectives (1), functional for supporting systems (2), and technical for deployment platforms (3). That will set budgets outer limits for given architectural contexts.
  3. Moves within rooms (4) are governed by functional requirements and anchored to pivotal business objects or processed (wire-frame’s nodes) . Their estimations should take into account analogies with previous developments.
  4. Acceptance criteria could then be defined both for invariants (changes are not to overstep architectural constraints) and increments (added functionalities are properly implemented).

Pricing the loops

Requirements Metrics and Agile

While agile development models are meant to be driven by business value, project assessment essentially relies on informed guesses about users stories. That let two questions unanswered:

  • Given that the business value of a story is often defined at process level, how to align it with its local assessment by project team.
  • If problem spaces and solution paths are to be explored iteratively, how to reassess dynamically the stories in backlog.

Answers to both questions are to be helped if requirements are qualified with regard to their nature and footprint.

Informed decision making about what to consider and when clearly depend on the nature of stakes. Hence the importance of a reasoned requirements taxonomy setting apart business requirements, system functionalities, quality of service, and technical constraints on platform implementations.

Dynamic assessment and ranking of backlog elements require some hierarchy and modularity:

  • Architectural options, functional or technical, must be weighted by supported business features and quality of services.
  • Dynamic ranking of users’ stories implies that their value can be mapped to features metrics at the corresponding level of granularity.

That can be achieved with functional features assessed along architecture layers.

Requirements should be assessed with regard to their nature and their footprint in functional architecture.

Requirements should be assessed with regard to their nature and their footprint in functional architecture.

Requirements Metrics and Quality Planning

Finally, requirements metrics may also be used to design quality checks to downstream models. With metrics for intrinsic characteristics of business domains on one hand, system functionalities on the other hand, subsequent models can be assessed for consistency, and alternatives solutions compared.

Providing unified OO modeling concepts, metrics can be computed on analysis and design models and set against their counterpart for original requirements. Examples of standard metrics for UML models include:

  • The number of root packages models is to be compared to symbolic containers for business and application domains, and the sub packages to primary (#) objects or activities.
  • The number of classes in models and packages is to be
  • The number of actors is to be set against the number of roles, with primary (#) roles standing for identified agents.
  • The number of root use cases is supposed to coincide with primary (#) activities and roles.
  • The number of structural inheritance hierarchies should be compatible with the number of frozen and exclusive partitions respectively for objects and activities.

Further Reading

External Links


Ahead with the New Year

December 30, 2011

New Grounds or New Holes ?

New years bring new perspectives, but looking ahead is useless without a sound footing. These plain figures may shed some light on the matter.


Looking ahead with hindsight (M. Cattelan)

What: Requirements and Models

Projects should start with some agreement about expectations and commitments. Maturity on that regard can be estimated with:

  • Number of projects started on agreed (actual meeting between stakeholders and providers) requirements, relative to all started developments.
  • Number of agreed requirements as sanctioned by models, relative to all requirements.
  • Number of agreed requirements that included quality plans, relative to all agreed requirements.
  • Number of root artifacts linked to requirements items relative to all root artifacts.
  • Number of requirements items linked to root artifacts relative to all requirements items.

The critical point here is the traceability between rough requirements as initially expressed, and structured and non ambiguous ones agreed upon after analysis.

Who: Stakeholders, Users, Developers

If their maturity is tobe assessed and improved, engineering projects should clearly distinguish between roles, even when they are played by the same persons or in tight collaboration. Here some clues to find out what happens:

  • Planned meetings with differentiated positions relative to all planned meetings.
  • Decision making meetings relative to all planned meetings.
  • Non functional agreed requirements relative to all agreed requirements.
  • Changes in agreed requirements linked to decision makers relative to all changes in agreed requirements.

The focus here should be on the definition of domains and use cases on one hand, traceability on the other hand.

When: Planning

As almost every human endeavour, projects’ success is governed by time and resources, in that case the delivery of system functionalities on time and on budget. On that regard, process maturity assessment should start with:

  • Number of projects not deployed relative to projects started on agreed requirements
  • Time spent in decision-making meetings relative to total project time.
  • Actual resources relative to estimations after agreed requirements.
  • Elapsed time between applications ready to be deployed and actually operational relative to projects duration.

The critical factors here are the traceability of model contents and the mapping of development flows into work units.

How: Tools

Engineering processes are meant to be supported by tools but that’s not necessarily for the best. A rough diagnostic can be based upon:

  • Number of tools installed relative to the number of functions supported by those tools.
  • Number of tools installed during the last year relative to the number of  tools installed.
  • Number of exchanges operated between tools relative to the number of  tools installed.

Further assessment should be set within the MDA/MDE perspective according model transformation policies.

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