The Economics of Reuse

Objectives

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

Objective

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

Objectives

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

 

Projects As Non-Zero Sum Games

Objective

Contracts are as much about collaboration and trust as they are about protection. While projects are not necessarily governed by contracts, all entail some compact between participants. From in-house developments with shared ownership on one hand, to fixed price outsourcing on the other hand, success will depend on collaboration and a community of purpose.

arielSchles_ParTronc
The whole is worth more than its parts (Ariel Schlesinger)

Hence, a first objective should be to prevent prejudiced assumptions and defensive behaviors. Then, taking a cue from Game Theory, compacts should be designed to enhance collaboration between parties by establishing a non-zero sum playground where one’s benefits don’t have to come from others’ losses.

Players and Stakes

Basic participants of engineering projects can be put in two groups, possibly with subdivisions: business units expressing requirements, and engineering units meant to provide solutions.

IntervenantsMatrice
Who’s Who

The former (user, customers, or stakeholder) specify the needs, pay for the outcome, and expect to benefit from its use. Their success is measured by return on investment (ROI) and depends on cost, quality, and timely delivery.

The latter design the solution, develop the components, and integrate them into target environments. Narrowly defined, their success is measured by costs.

planbataille
Project participants should collaborate on features and timing.

Hence, while stakes may clearly conflict on prices, there is room for collaboration on features, quality and timing, and that may bring benefits to both customers and providers.

Communication and Collaboration: Modeling Languages

Understanding is a prerequisite to collaboration, and except for in-house developments, there is no reason to expect immediate (aka mediation free) understanding between business and engineering units. Some common language is therefore required if heterogeneous concerns are to be matched.

Catap_NZSG
Mapping functional and engineering concerns.

While in-house developments under shared ownership can proceed with domain specific languages, collaboration between different organizational units along time can only be supported by modeling languages with non specific semantics.

Assessments and Strategies: Requirements Metrics

If participants are to act rationally based on symmetric information, they must agree on some measurements for size and complexity.

Given that collaboration is not to offset interests by nature different or even conflicting, participants’ strategies must be based on shared and reliable information regarding their respective stakes. Moreover, if timing is to matter, projects’ metrics will have to be reassessed periodically, and strategies redefined accordingly.

Catap_NZSG_tmg
Matching the respective deadlines and strategies of customers and providers

Despite clear shortcomings about targets and accuracy, requirements metrics are nonetheless a necessary component of any collaborative framework, with or without explicit contracts.

First of all, some measurements are required to set schedules and plan resources. Even faulty, those estimators will serve their purpose if agreed upon by all participants, with possible biases redressed by consent, and lack of accuracy reduced or circumscribed progressively.

Then, as engineering projects often come with intrinsic uncertainties, they may go off-trail. Providing timely and reliable indicators, participants should be able to anticipate hurdles, reassess strategies, and amend agreements.

Finally, metrics should make room for arbitrage and differentiated strategies; given trustworthy information and clear acceptance criteria, participants would be in a position to weight their respective stakes with risks, rearrange their priorities, and plan their endgames appropriately.

Prices and Acceptance: Contracts

While trustworthy information is a necessary condition for cooperation, it’s not a sufficient one, as players may be tempted to cheat or defect if they think they can get over with it. Leaving out ethical considerations and invasive regulations, the best policy should be to set rewards and sanctions such as to make a convincing case for cooperation benefits.

That can be achieved if participants can opt for differentiated and non conflicting strategies set according  model layers.

Starting with business processes (aka computation independent models) and expected return on investment, customers consider system functionalities (a) and ask providers for feasibility (b), and schedules (c).

Given a functional architecture (aka platform independent models), participants may define strategies: customers associate features with date and expected benefits, providers plan resources and deliveries for products (aka platform specific models and code).

Commitments, by customers on prices and providers on dates, are made at two levels: functional architectures (d) and features (e).

NZSG_0
Business requirements (a), functional architecture (b), developments (c), architectural commitments (d), incremental developments (e).

As for any iterative process, changes must be explicitly circumscribed by invariants, e.g functional architecture of supporting systems. Yet, within those constrains, there may be room for adjustments insofar that providers’ costs and customers’ returns are contingent on schedules.

Processes: Time, Risks, Responsibilities and Milestones

As Einstein put it, “The only reason for time is so that everything doesn’t happen at once”. That seems a perfect fit to project planning, as illustrated by two archetypal project configuration:

  • At one extreme, in-house projects with shared ownership may operate within their own time wraps (aka time-boxes) because decisions by customers and providers can be taken jointly and simultaneously independently of external factors.
  • At the other extreme, outsourced projects are set along sequenced milestones and governed by different organizational units, each with its own time scale. With tasks performed independently and decisions made separately, time becomes a factor and processes are introduced to consolidate time-scales and manage risks and decisions alongside.

More generally, engineering processes are introduced when decisions are to be made along time by different organizational entities. Assuming that time is governed by changes and the decisions to be made thereof, the sequencing of tasks should be defined with regard to the nature of events and decision-making:

Technical: engineering processes come with their own intrinsic constraints regarding the sequencing of operations. When those operations can be performed independently of contexts the whole sequence can be seen as a single step wrapped into a time fold. Otherwise they must be associated with distinct process steps.

Contractual: while uncertainties about contexts may affect both expectations and commitment, decisions have to be made notwithstanding. But decisions carry risks and should therefore be factored out, with rationale and responsibilities stated explicitly. While some responsibilities may be shared, decisions about contexts should remain the sole responsibility of the participants directly in charge and appear as milestones set in contracts.

Managed: whatever the number of model layers and automated transformations, engineering processes set about and wind up with human activities. Given that resources and skills are by nature limited, participants have to make the most of their use. But once milestones are set and technical constraints identified, each participant should be able to optimize its own planning.

That makes for three basic project configurations:

  • Requirements analysis is about business requirements and feasibility. Its main objective is to identify technical and contractual milestones.
  • Use case developments are self-contained projects under shared ownership, bounded by contractual milestones. They come with defined prices and schedules whose mix can be managed by consent.
  • System functionalities are set by cross-cutting objectives and their development is therefore governed by contractual milestones and schedules.
NZSG_1
Architectures and Project Configurations

Managing engineering projects along these principles would greatly improve their integration with business needs on one hand, enterprise architecture on the other hand.

Further Reading

External Links

Requirements Capture

Objective

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.

kanji_rekap
Documented communication makes room for mediation

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.

kanji_whorse
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.
RR_MYW
Products and Usage are two different things

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.

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

PtrnRules_Incept
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

Objects with Attitudes

Identities and Aspects

Despite its object and unified vocations, the OMG’s UML (Unified Modeling Language) has been sitting uneasily between scopes (e.g requirements, analysis, and design), as well as between concepts (e.g objects, aspects, and domains).

Where to look  for AAA issues (Maurizio Cattelan)

Those misgivings probably go a long way to explain the limited, fragmented, and shallow footprint of UML despite its clear merits. Hence the benefits to be expected from a comprehensive and consistent approach of object-oriented modeling based upon two classic distinctions:

  • Business vs System: assuming that systems are designed to manage symbolic representations of business objects and processes, models should keep the distinction between business and system objects descriptions.
  • Identity vs behavior: while business objects and their system counterpart must be identified uniformly, that’s not the case for aspects of symbolic representations which can be specified independently.

That two-pronged approach bridges the gap between analysis and design models, bringing about a unified perspective for concepts (objects and aspects) as well as scope (business objects and system counterparts).

Object Oriented Modeling

Object Oriented and Relational approaches are arguably the two main advances of software engineering for the last 50 years. Yet, while the latter is supported by a fully defined theoretical model, the former still mostly stands on the programming languages supporting it. That is somewhat disappointing considering the aims of the Object Management Group (OMG),

UML was born out of the merge of three modeling methods: the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE), all strongly marked by object orientation. Yet, from inception, the semantics of objects were not clearly defined, when not explicitly confused under the label “Object Oriented Analysis and Design” (OOA/D). In other words, the mapping of business contexts to system objects, a critical modeling step if there is any, has been swept under the carpet.

Literal Bird

That’s a lose/lose situation. Downstream, OO approaches, while widely accepted at design level, remain fragmented due to the absence of a consensus regarding object semantics outside programming languages. Upstream, requirements are left estranged from engineering processes, either forcing analysts to a leap of faith over an uncharted no man’s land, or to let business objects being chewed up by programming constructs.

Domains and Images

In mathematics, an image is the outcome of a function mapping its source domain to its target co-domain. Applied to object-oriented modeling, the problem is to translate business objects to their counterpart as system components. For that purpose one needs to:

  1. Define domains as sets of business objects and activities whose semantics and life-cycle are under the authority of a single organizational unit.
  2. Identify the objects and phenomena whose representation has to be managed, as well as the lifespan of those representations.
  3. Define the features (attributes or operations) to be associated to system objects.
  4. Define the software artifacts to be used to manage the representations and implement the features.
From Business Domain to System Image

While some of those objectives can be set on familiar grounds, the four must be reset into a new perspective.

Business Objects are rooted in Concerns

Physical or symbolic, objects and activities are set by concerns. Some may be local to enterprises, some defined by common business activities, and some set along a broader social perspective. The first step is therefore to identify the organizational units responsible for domains, objects identities and semantics:

  • Domains in charge of identities will govern objects life-cycle (create and delete operations) and identification mechanisms (fetch operations). That would target objects, agents, events and processes identified independently of systems.
  • Domains in charge of semantics will define objects features (read and update operations). That would target aspects and activities rooted (aka identified) through primary objects or processes.
Context anchors and associated roles and activities

It must be noted that whereas the former are defined as concrete sets of identified instances governed by unique domains, the latter may be defined independently of the objects supporting them, and therefore may be governed by overlapping concerns set by different domains.

Objects and Architectures

Not by chance, the distinction between identities and features has an architectural equivalent. Just like buildings, systems are made of supporting structures and subordinate constructs, the former intrinsic and permanent, the latter contingent and temporary. Common sense should therefore dictate a clear distinction between modeling levels, and put the focus on architectures:

  • Enterprise architecture deals with objectives, assets and organization associated with the continuity of corporate identity and business capabilities within a given regulatory and market environment. That is where domains, objects and activities are identified and defined.
  • Functional architecture deals with the continuity of systems functionalities as they support the continuity of business memory and operations. At this level the focus is not on business objects or activities but on functions supported by the system: communication, control, persistency, and processing.
  • Technical architecture deals with the feasibility, efficiency and economics of systems operations. That is where the software artifacts supporting the functions are designed .
Objects and Architectures

Objects provide the hinges binding architectural layers, and models should therefore ensure direct and transparent mapping between business objects, functional entities, and system components. That’s not the case for features whose specification and implementation can and should be managed separately.

Fleshing out Objects with Semantic Aspects

Confusing business contexts with their system counterparts leads to mistaken equivalence between features respectively supported by business objects and system artifacts:

  • The state of physical objects may be captured or modified through specific interfaces and persistently recorded by symbolic representations, possibly with associated operations.
  • Non physical (notional) business objects are identified and persistently recorded as such. Their state may also appear as transient objects associated with execution states and processing rules.
  • Events have no life-cycle and therefore don’t have to be identified on their own. Their value is obtained through interfaces; associated messages can be used by control or processing functions; values can be recorded persistently. Since the value of past events is not meant to be modified operations are irrelevant except for interfaces.
  • Actual processes are identified by execution context and timing. There state may be queried through interfaces and recorded, but persistent records cannot be directly modified.
  • Symbolic processes are identified by footprint independently of actual execution. Their execution may be called through interfaces and the results may be recorded, but persistent records cannot be directly modified.
  • External roles are identified by the interfaces supporting the interactions. Their activity may be recorded, but persistent records cannot be directly modified.
Fleshing out Aspects

By introducing complementary levels of indirection between business and system objects on one hand, identities and features on the other hand, the proposed approach significantly further object-oriented modeling from requirements analysis to system design. Moreover, this approach provides a robust and effective basis for the federation of business domains, by modeling separately identities and semantic features while bridging across conceptual, logical and physical information models.

Untangling 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 differently 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. Hence, if transparency and traceability of functional and technical arbitrages are to be supported, the configuration of rules has to be rationalized from requirements inception. And that can be achieved if rules can be organized depending on their footprint: domains,  instances, or attitudes.

From Objects to Artifacts

Requirements analysis is about functional architecture and business semantics, design is about software artifacts used to build system components. The former starts with concrete descriptions and winds up with abstract ones, the latter takes over the abstractions and devise their concrete implementation.

Uphill to functionalities, downhill to implementations

Somewhat counter-intuitively, information processing is very concrete as it is governed by actual concerns set from biased standpoints. Hence, trying to abstract requirements of supporting systems up to some conceptual level is a one way ticket to misunderstandings because information flows are rooted in the “Here and Now” of business concerns. Abstract (aka conceptual) descriptions are the outcome of requirements analysis, introduced when system symbolic representations are consolidated across business domains and processes.

Starting with a concrete description of identified objects and processes, partitions are used to analyze the variants and select those bound to identities. Inheritance hierarchies can organized accordingly, for objects or aspects.

Inheritance of identities vs inheritance of aspects.

While based on well understood concepts, the distinction between identity and aspect inheritance provides a principled object-oriented bridge between requirements and models free of any assumption regarding programming language semantics for abstract classes or inheritance.

Objects, attitudes, and Programming Languages

Because object-oriented approaches often stem from programming languages, their use for analysis and design is hampered by some lack of consensus and a few irrelevant concepts. That is best illustrated by two constructs, abstract classes and interfaces.

  • Most programming languages define abstract classes as partial descriptions and, as a result, the impossibility to be instantiated. When applied to business objects the argument is turned around, with the consequence, no instance, taken as the definition.
  • Interfaces are also a common features of object-oriented languages, but not only, as they may be used to describe the behavior of any software component.

Those distinctions can be settled when set within a broader understanding of objects and aspects, the former associated with identified instances with bound structures, eventually implemented as concrete classes, the latter with functionalities, eventually implemented as abstract classes or interfaces.

From Analysis to Design

A pivotal benefit of distinguishing between objects identity and aspects is to open a bridge between analysis and design by unifying respective patterns along object-oriented perspective. Taking a cue from the Gang of Four, system functionalities could be organized along three basic pattern categories:

  • Creational functionalities deal with the life-cycle (create and delete operations) and identification mechanisms (fetch operations)  of business objects whose integrity and consistency has to be persistently maintained independently of activities using them.
  • Structural functionalities 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 functionalities deal with the ways objects are processed.

Mapping analysis patterns to design ones will greatly enhance models traceability; moreover, taking advantage of the relative maturity of design patterns, it may also boost quality across model layers as well as the whole effectiveness of model driven engineering solutions.

Objects Oriented Modeling and Model Driven Engineering

The double distinction between contexts and systems on one hand, objects and aspects on the other hand, should help to clarify the contents of modeling layers as defined by OMG’s model driven architecture (MDA):

  • Computation independent models (CIMs) are structured around business objects and processes identified on their own, associated with organizational details for roles and activities.
  • Platform independent models (PIMs) are organized on two levels, one for functional architectures (boundaries, processes, persistency, services, communication), the other one for associated aspects.
  • Platform specific models (PSMs) are similarly designed on two levels, one mapping functional architectures, the other one implementing aspects.
MDA with UML#

Using  UML#, object-oriented concepts can therefore be applied uniformly from requirements to design without forcing programming semantics into models.

Further Readings

2012: Ahead with the New Year

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.

vvvv
Looking ahead with hindsight (Where to look  for AAA issues (Maurizio 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.