“Automation by Nature” is the name of an approach for creating homogenous specifications of heterogeneous systems that are not necessarily intentional and that can involve humans, software and machinery. The consistency of the approach is enforced by some reference systems semantics derived from natural phenomena.

In practice, the approach can be used for creating or integrating enterprise architecture frameworks, specification languages (notably modeling languages), development processes and factories. The languages can be either generic analysis languages or domain specific design and implementation languages. Factories, along with their underlying development process, can be any kind of factory composed of humans, software and machinery for producing specific kind of resources and systems including other factories.

Automation by Nature defines a strategy and a tactical plan to realize its vision. It prescribes guidelines for the execution of the tactical plan. And it provides contents fulfilling the first tactical steps including the reference systems semantics.

For systems and specifications that already exist, the reference systems semantics can be used to identify semantic commonalities and to create integration points that really make sense.

Definitions and Scope

Origin of the approach

Automation by Nature is the result of many years of experience on manifold projects. The scope of these projects range from large scale systems integrations to the production of domain specific development environments. These development environments include lots of business and software modeling, code generation and frameworks running on different platforms.

The holistic approach stems from the different roles I played in various environments where I could learn from team mates, cultures and backgrounds. The roles I played include business and software architect, strategist, R&D manager, development process engineer, project manager, software requirements engineer, user experience designer, software developer…

Audience

As a first stage, direct users of the approach are people and organizations who want to create enterprise architecture frameworks, standard and homogeneous specifications languages and processes along with supporting tools. If we take for example the software industry, these can be enterprise architecture framework designers, Domain Specific Languages [CJKW07] designers, Software Factories [GSCK04] designers...

As a second stage, indirect users are typically requirement engineers and architects who want to leverage the homogeneous specification languages, processes and tools created in the first stage. This could include, for instance, some domain specific Evolution Modeling Language used to capture the evolution of physical, mental or digital resources, or a Role Modeling Language for specifying role organizations where each role could be played by performers including people, software and machinery…

As a third stage, end users are the people who use the target system. Note that, in many cases, the target system is used to create other systems… to create other systems …

The present document is organized into following chapters.

The first chapter is the “Introduction”

· The introduction starts with and “Executive Summary”.

· Under the heading “Definitions and Scope”, we define the scope of the approach called “Automation by Nature”. We talk about the origin of the approach. We describe what you can do with it depending of your specific role or concerns.

· Under the heading “Ultimate Goals”, we determine the ultimate goals. These ultimate goals can be summarized in three words namely “optimized heterogeneous systems”.

The chapter called “The problems” describes some key problems we have for reaching these ultimate goals. It identifies some key reasons for these problems to occur. It finally provides some perspective into the future. Notably, it explains why the problems can only exacerbate if we carry on creating systems the way we do.

The chapter called “Approach” presents the principles, mindset and the overall strategy that we follow for resolving these problems and for reaching our ultimate goals.

This chapter called “Tactical Plan” defines the practical steps for realizing the strategy, including the systems semantics and the specification styles.

The chapter called “Systems semantics” stands at the basis of the approach. It realizes the first step in the tactical plan.

· Under the heading “Setting the stage”, we discuss the natural phenomenon along with the physical, mental and digital spheres. Some general systems semantics apply to any of these spheres. The next chapters present and extend these semantics, step by step, following the evolution of nature.

· Under the heading “Fortuitous System”, we introduce some initial semantics of fortuitous phenomena.

· Under the heading “Intentional Systems”, we extend the semantics with primitive concepts induced by living beings.

· Under the heading “Organized to Optimize”, we further extend the semantics with generic organizational concepts.

· Under the heading “Organized to Optimize across Spheres”, we explain how the organizational concepts can be further optimized by leveraging specific potentials of each sphere. Such optimization leads to systems involving a judicious combination of physical, mental and digital resources.

The chapter called “Some recommended specification styles” introduces common refinement schemes for the specifications. This is used for creating, refining, structuring and classifying specifications following precise refinement grades.

Then we present our Conclusions and Next Steps for realizing the tactical plan. The next steps include the creation of common specification styles (some initial content is already provided) .These specification styles need to combine with the natural systems semantics for creating homogeneous analysis specification languages and processes along with their supporting tools.

We finalize our document with some acknowledgment and references for further readings.

Ultimate Goal

The ultimate goal is to create optimized heterogeneous systems, including and necessarily systems that are used to build others systems.

Definition of “Optimize”by Webster (http://www.webster-dictionary.net/d.aspx?w=Optimize):

— To make as useful, effective, or functional as possible; as, to optimize the speed of a computer program.

— To get the most out of; to use to the best effect; to exploit fully; as, to optimize one's return on investment.

By « Optimized System » we mean…

A system that organizes selective resources, fortuitously or intentionally, in an optimized fashion, fulfilling defined goals.

By « Optimized Heterogeneous System » we mean…

An optimized system that organizes an optimized combination of physical, mental and digital resources.

As we will see further in this document, a key success factor is the ability to create homogeneous and precise specifications of integrated systems even if these systems span many different domains.

For systems and specifications that already exist, the reference systems semantics can be used to identify semantic commonalities and to create integration points that really make sense.

The Problems

For several decades, the pace of evolution has been accelerating dramatically. A plethora of new approaches, including concepts, notations, specification processes and tools have been created to support the development life-cycle of ‘business organizations”, “IT systems” and all sorts of machineries. The need for standardization led some selected approaches and their underlying terminology to be assembled sometimes in a very sophisticated way. The Unified Modeling Language is an example of such standardization that is aiming at software systems specifications.

The problem is that, even inside the limited scope of software specification, such combination of different semantics and terminologies leads to tremendous complexity and misinterpretation. And the fact that most terminologies are derived from technology (versus from natural concepts that anybody can understand) does certainly not improve the situation.

Things get worth when a combination of technical and non technical terms is used for what is often called ‘business architecture” specifications.

And things get even worth when organizations are aiming at what they call “Business and IT alignment”. The “alignment” is usually very ambiguous because the different sets of concepts, notations, terms and tools do not provide any natural refinement continuum from the mission of a “business organization” down to the programming code.

The problem reaches yet another level of magnitude when the scale of what needs to be designed, combined, re-factored and aligned is getting larger and larger.

Since we are already reaching chaos while we are just trying to specify systems involving humans and software, what would happen if we had to integrate machinery, like an elevator, in the systems specifications? What would happen if we had to include some chemical or physical phenomenon like winds and tides? What would happen if we had to include some fortuitous phenomenon where there is no intentional action whatsoever? And how would we specify not only what is known but also what is unknown?

In other words, what terminology could we use to describe a (real) system spanning the mental, digital and physical spheres all together?

Example

In practice, imagine a large integration project that follows the merger and acquisition of different banks including their subsidiaries. In this project, you have been appointed to define a rational integration of banks organizations along with their IT systems and machinery like door openers, lockers and alarm systems. Some typical problems that you would face include:

1) Semantic ambiguity: Lots of incompatible, redundant and top sacred concepts and jargon related to either the banking business or to the technology. Lack of precise semantics.

2) The relationship between the existing specifications is quite loose and ambiguous. Same for the communication between the different stakeholders.

3) The architectural refinement paths are numerous and uncertain.

4) There is an awful tangle of unrelated or redundant tools.

5) There is no natural and precise business automation process per se.

Or let’s say that you are an advanced software vendor or IT service provider using and creating miscellaneous software factories including domain specific languages (DSLs). In this case, the problem that you will face is integrating different Domain Specific Languages and software factories with each other since you will most probably encounter many semantic mismatches.

Prospectives

As illustrated by the next picture, each technology (being a programming language, a graphical language, an off-the-shelve component, a pattern, a development processes, a development tool…) tends to institute another and different technical jargon.

Unification approaches, like the Unified Process and the Unified Modelling language, are unifying some generic concepts. Many of these unified concepts, like business use cases, use cases, state machines… were initially different and have been accommodated so that they can fit more or less with each other. That was an excellent start. Now, though the concepts are generic, they were derived from different technological approaches, so we already have to deal with lots of complexity.

By definition, a generic approach can not precisely cope with the specifics of real world situations. Hence, platform independent and platform specific dimensions have been added on top of the unified modelling approach. And that would make a lot of sense if the diagramming objectives were driven by some generic semantics. Instead, for historical reasons, the semantics are mainly derived from or accommodated for the diagramming objectives. For the long term, such situation is equivalent to no semantics because it cannot scale without adding unbearable complexity.

In reaction to formal mega-meta-modeling, domain specific approaches, including domain specific languages and factories, are aiming at many simple, precise and pragmatic approaches for each specific domain. There are many benefits of having domain specific languages, development processes and tools. These benefits include simplicity, productivity, quality and cost. However, this does not resolve the problem of having to deal with many different jargons. To the contrary, each domain specific language is potentially yet another technical idiom. Furthermore, if every domain specific approach is created independently, we will have to deal with lots of incompatibilities: Domain specific languages or software factories that cannot be integrated due to semantic mismatches.

Hence, if we no longer want to squander talents at mastering useless technical complexity, we need to come up with some strategy.

Approach

Principles and Mindset

In order to propose a sound solution and to avoid common pitfalls, we strived to apply the following principles:

• Start from the essential lessons of nature.

• Keep unbiased, as much as possible. Forget about the solutions we know, at least to start with. Keep only the lessons learned.

• Use common words and common meanings.

• Structure the systems semantics using a model.

Overall Strategy

The ultimate goal is to create optimized heterogeneous systems.

By “heterogeneous system”, we mean any system that can involve any kind of intentional and non intentional phenomena.

By non intentional phenomenon, we designate evolutions that are purely fortuitous including climate, wind, tide, freezing, rusting, etc...

By intentional phenomenon we designate intentional evolutions induced by any kind of performer including human, animal, software and machinery. Such performers usually bear some physical, mental or digital dimension(s). And these performers often play some organized role(s).

In order to create optimized heterogeneous systems, we need to create comprehensive, precise, yet homogeneous specifications.

Specifications must be comprehensive by taking any potential dimensions of some heterogeneous system into account.

Specifications must be precise and meaningful. They should leverage precise terminologies and notations that are specific and meaningful to each domain or perspective.

Specifications must be homogeneous while describing any combination of any fortuitous or intentional phenomena. Such homogeneity is a key success factor for creating clear and precise organizations of collaborating humans, software and machinery.

In order to be comprehensive, precise, and homogeneous, specification should derive from some natural systems semantics that are derived from the natural phenomenon and that span humans, software and machinery.

Finally, in order to create those specifications and produce a corresponding optimized heterogeneous system, we need some optimized development environment. A development environment is also some sort of system that can be made of humans, systems and machinery. Hence, the same approach applies for designing a development environment as it applies to any other kind of heterogeneous system.

The strategy has been refined into the following tactical plan…

Tactical Plan

The following diagram illustrates a tactical plan that realizes our strategy.

We can see on the above figure that the tactical plan starts from the definition of the “natural” systems semantics.

This is followed by the recommendation of some cross-domain specification styles.

From this common ground, some cross-domain analysis specification languages and process can be defined.

Then, coming from general domain, we can then refine into domain specific semantics, languages and specification processes.

Simple specific domains can be combined and refined into composite specific domains.

As a result, all domains are derived, directly or indirectly, from the natural systems semantics.

And this combines with the recommended specification styles to enforce precision, clarity and consistency across all specification languages, specification processes and domains.

The efficiency of the target heterogeneous system is enabled by the fact that each of its specific perspectives has been precisely and unambiguously addressed using a domain specific, yet homogeneous, specification approach.

Execution of the tactical plan

We envisage the first iterations to be one inch wide but one mille deep. In other words, the first iterations should go through all the steps but they should keep the scope of each step as minimal as possible. Each step should be just meaningful enough to provide us with the necessary lessons learned. Several iterations should provide us with a process along with some tools that support the process.

Natural Systems semantics

Automation by Nature already provides an implementation of the first tactical step i.e. some natural, generalized systems semantics derived from the natural phenomena.

Recommended specification styles

These specification styles need to include, for example:

· A common refinement scheme for the specifications.

· A common elicitation approach.

· A common approach for structuring and relating specification items.

· A common naming scheme for specification items. In other words, defining how domain specific terms will be derived from the generic terms defined in the “natural” systems semantics.

· A common notation style applied to specification items. This can include, for example, some common modeling shapes or textual colors applied to resources, evolution (operations, scenarios, processes), events, human performers, software performers, machinery ….

Some guidelines should refer to convergent approaches and enabling technologies. The guidelines should prescribe when and how these convergent approaches and enabling technologies should be leveraged.

Analysis Specification Languages and Process

Using the natural systems semantics and leveraging the recommended specification styles, the next step consists in defining analysis specification languages and process.

We often use analysis languages to sketch some systems that we are envisioning. Later, we will typically refine the analysis specifications into precise specifications that belong to a specific domain.

Analysis languages can also be used to “canonize” concrete syntax patterns (naming, modeling shape, icon, color, font etc...). These concrete syntax patterns can be re-applied while creating various domain specific languages. As a result, distinct languages with similar semantics but that belong to different domains can be made homogeneous (similar look and feel).

For examples, we might have an analysis modeling language to represent generic collaborations between generic performers. Then we can have specific modeling languages to represent collaborations between software applications or between software classes. The systems semantics can be consistent with each other. And in addition, the concrete representations of this semantics can be similar as well.

Simple domains

Each domain will have its own semantic specification languages, development process and development environment.

Based on the generalized semantics and analysis languages, the next step consists in defining domain specific - yet homogeneous – semantics, languages and development processes. Such languages and processes can be used to produce homogeneous specifications of heterogeneous systems. But we don’t want to produce such specifications only by hand...

Development environments are engineered in order to support and automate the usage of the defined languages and processes. Hence, meaningful systems specifications can be easily produced. These development environments are heterogeneous systems in the sense that they include people, software, hardware, paperware etc...

The optimized development environments are used to specify and produce optimized heterogeneous systems.

Composite domains

Thanks to the reference systems semantics, specification domains can mix and match. They can integrate heterogeneous systems in a modular fashion. Optimized systems can include fortuitous evolutions and intentional evolutions involving humans, software, machinery and many kinds of other resources that can belong to the physical, mental or digital sphere.

Very composite and heterogeneous systems are comprehended and engineered in a consistent and complementary fashion.

Feedback and Refactoring

The tactical plan mentions the impact of feedback on semantics, specification languages, development processes, development environments and systems in general. The only thing that might never change is that everything changes constantly. Of course, that applies to semantics and to anything that depends on these.

Hence, since iterative feedback and refactoring is our destiny, the challenge is to keep some balance between the need for standards and the necessary adjustments: On one hand, we need to standardize useful semantics since they are the foundation for any kind of economies of scale. On the other hand we need to adapt to all sorts of evolutions.

Such flexibility is our motivation for the “lightly formalizing” of our reference systems semantics.

Systems Semantics

The first step in the tactical plan (described earlier in this document) concentrates on the definition of some common natural systems semantics from which domain specific semantics and languages can be easily derived.

This first step is essential and it is already quite documented and can be summarized as follows…

The systems semantics feature the following properties:

· Intuitive as it conforms to the evolution of nature

· Simple, as we can think and communicate using a common natural language, whatever our background and role can be

· Precise and unambiguous, hence convenient for tools and automation purpose

· Homogenous, like its concepts and terms that are common across the physical, mental and digital spheres. What is thought to be heterogeneous is actually homogeneous

· Flexible, as it allows for any domain specific specializations

· Modular and scalable, as it dissolves very large scale complexity into simpler homogeneous items

Setting the Stage

The Natural Phenomenon

To define some systems semantics featuring the above properties, we simply follow the natural phenomenon. We follow the process of evolution, adding complexity step by step, mimicking the evolution of nature itself.

	The incremental complexity of nature starts from fortuitous physico-chemical systems.
	At some point, life fortuitously appeared along with the intention to survive.
	Step by step, beyond basic intentions, humans tried to organize in order to optimize the way they fulfil their intentions. They delegated part of their work to animals and other humans, then to machinery and finally to computers.
	Today, humans try to rationalize such complex delegations into optimized heterogeneous systems. Humans want to organize and optimize systems involving the physical, mental and digital spheres.

Spheres

The concept of “spheres” is quite easy to grasp. It is just a matter of simple observation. A key observation is the fact that similar things can exist and evolve either mentally, physically or digitally.

For example, the document that you are reading now might exist and evolve in multiple forms:

· A digital resource on the Internet

· Its physical representation on your screen

· A physical paper document in your hands

· A mental resource in your brain (since you are reading and creating a perception of the document)

Similarly, humans, animals, washing machines, cars, engines, computers etc… are performers that belong to and that intentionally influence either the physical, mental or digital sphere (or a combination of those).

We define the physical, mental and digital spheres as follows:

Physical Sphere

The extension of the general conception of the physical nature; the totality of the physical resources and physical phenomena that pertain to this sphere.

Mental Sphere

The extension of the collective aspects of intellect and consciousness; the totality of the mental resources and mental phenomena that pertain to this sphere.

Digital Sphere

The extension of the collective aspects of digital resources including software; the totality of the digital resources and digital phenomena that pertain to this sphere.

Spheres are a consequence of the natural phenomenon. Evolution started in the physical sphere. Today, humans are creating systems spanning the physical, mental and digital spheres.

· Life fortuitously appeared in the physical sphere (NB: We are respecting every belief and it is up to the reader to decide what “fortuitous” really means)

· The mental sphere rose from a conscious and exacerbated intention to survive.

· Intention led to conscious delegation to people, animals, machinery and software. Humans delegate to software by reproducing part of the physical and mental spheres into the digital sphere.

The semantics that we define are derived from patterns that we can easily observe in nature. The systems semantics provide terms to express this semantics. The natural patterns and the semantics apply to all spheres.

Now that we have set the stage, let’s see what these system semantics really are…

Systems Evolution, By Nature

Fortuitous System

We start from a simple perception of the natural phenomenon including the evolution of things in general.

A fortuitous system involves non intentional physical or chemical evolutions like « salt dilution in water».

At every specific moment in time, an infinite number of entities are in a specific state.

Physical and chemical phenomena naturally trigger evolutions without any intentional intervention.

At this stage everything is fortuitous. Even though recurrent scenarios do take place, nothing can be considered as “intentional”. There is no concept of Goal.

We can summarize these initial semantics with the diagram below. However, we will see that the intentional phenomenon induces a slightly different perspective. The concept of entity has been crossed out because living beings do not fathom nature this way. Indeed, from the perspective of living beings, every entity is a potential resource.

Intentional System

An intentional system involves operations realized by performers e.g. « dropping salt in water».

A performer can be, for instance a plant, an animal, a human. It can also be a software, some machinery or a complex robot to which the human delegates.

From the viewpoint of a living being, every entity in the universe is seen as a potential resource. This resource can be used to fulfill its intention, its goal i.e. the subsistence and “good” state of its species or just of itself.

Resources, that are created or changed over time, are products of fortuitous or intentional evolutions. Basic “intentions” and basic operations are just the result of natural selection of scenarios that work.

Resources have a state. Resources are shown in the above diagram with a green background color

An event is the appearance of some significant resource state, that state being the result of some significant evolution for a particular performer.

Knowledge about desired and non-desired events (the appearance of desired and non-desired states) is important information for performers i.e. for decision makers that need to act and react according to positive or negative evolutions. Information is a kind of resource that performers can acquire or deduce.

A goal is information like the need for food “written” in our brain, SMART goal statements written on paper, formal goal specification written using a computer readable format...

Organized To Optimized

We have seen that a system can present fortuitous and intentional dimensions. Beyond simple intentional patterns like “When tired then sleep”, living beings (performers) “learned” to intentionally organize in order to optimize the way they can reach their goals.

Such organization includes role delegation, resource sharing and process optimization.

Delegation

Performers intentionally delegate roles to other performers for the purpose of resource specialization and optimization.

The farmer delegates the sowing to a sower, assuming that the sower has the capability to play that role. In other words the farmer assumes that the sower controls a sufficient part of the expert domain of resources in order to reach some expected goals. Resources, including performers, can be physical, mental or digital.

Delegating one’s role means delegating some goals. The delegate performer now has expected goals corresponding to the role that he/she/it plays.

A role organization is a hierarchical tree while the performers that play the roles can be organized into a network.

For example, the “shipping” role can be part of your roles organization. However, the performer playing that role can be a performer standing outside your performers organization. An external performer, e.g. “The Shipping Company”, might have been selected to play the “Shipping” role because that external performer organization shows adequate capabilities to play that role.

Sharing Goals and Resources

For a performer (human, software, machinery…) to delegate some role, the performer needs to share some of its controlled resources to its delegate(s). Shared resources can be material, information… or any performer to which further delegation can take place. Conflicts arise from incompatible goals regarding desired state of the shared resources.

Rationalizing roles, goals and resources is much easier when it applies to software or machinery. When it comes to humans, many conflicting roles appear.

Process Optimization

Besides delegation and resource sharing, performers also try to optimize the process starting from an initial state and trying to reach some desired state.

A process is a complex operation with multiple intrinsic variants. A process represents a set of scenarios that have a common initial state. Some scenario(s) will lead to the desired state. Other scenarios will lead to some other, non-desired, resulting state.

Each scenario involves a set of participant roles performing a sequence of operations and a sequence of evolutions including operations performed by the participant roles.

Organized to Optimize across Spheres

Further optimization requires delegation to appropriate performers within appropriate spheres. Appropriate delegation also requires appropriate role decompositions.

Humans delegate operations to software or machinery because these operations are either repetitive or because these operations require some level of performance or physical property (speed, precision, strength, mass...) that humans can’t reach.

In the above picture, delegation is represented by arrows that sometimes cross sphere boundaries. At the most elementary level, “transpheres” require relocation of resources across a common sphere i.e. the physical sphere.

In practice, many processes span multiple spheres. For example

· Read physical slide on the screen or paper and associate with existing mental knowledge

· Print digital ads to physical paper, Post paper. Receiver opens physical envelope, reads physical ads information into mental knowledge, mentally selects preferred product, type product reference onto physical keyboard and “transpher” the reference into the digital on-line ordering system….

· Print digital recipe to physical paper, read recipe into mental knowledge, create mental cooking plan, cook…

The following example shows a student (a performer) taking a calculation exam. In this example, the student delegates some operations to a calculator (another performer).

Note that this is just a sample basic scenario for some basic system spanning multiple spheres. This is not a proposed specification language.

The next diagram depicts the integrated systems semantics where every concept applies to the physical, mental and digital spheres.

Some Recommended specification styles

The tactical plan prescribes the definition of common specification styles. These styles apply to the process for creating the specifications and to the resulting specification themselves.

To this end, we provide initial content for key specification styles: the common refinement scheme and the common elicitation approach.

Of course, this document is an overview. So feel free to read the Automation by Nature Contents” for further details.

Refinement

A key aspect of a development process is the refinement of the specifications. We need to define what exact types of specification item we can refine into which other types of specification item. Such refinement needs to be precise and unambiguous. Precise refinement paths and constraints are the prerequisite for automating a development process including actionable guidance, traceability, validation, impact analysis, generators etc… Such precision is also needed for the software specifications to be executable models.

The refinement of specifications is undertaken from different standpoints including refinement of concepts, refinement of work products and refinement of viewpoints.

Refinement of Concepts

Defining Concepts

In order to create precise and consistent specifications end to end, the concepts used in a development process can be derived from or identified in some systems semantics like the one that was described earlier. A concept used in a development process can be for example a “business process” which is derived from the process concept defined in our systems semantics.

Refining Concepts

The refinement of concepts consists in defining what concept is used as input to define/create another concept. For example, one might refine the concept of an “entity” (that belongs to a work product type called “domain model”) into a “database table” or a “C# class”.

Refinement of Work Products

Defining Work Products

Concepts materialize into arbitrary work product types. And there can be many concepts that materialize in a single work product type. For example, the concepts of “data contract” and “service type” can be part of a single work product type that could be called for example “service model”.

Coarse-grained work product types typically aggregate fine-grained work product types.

Refining Work Products

The refinement of work product types consists in defining what work product type is used as input to define/create another work product type. For example, one might refine the coarse-grained work product type “Service Realization” into a work product type “Web Service Component Model”.

Refinement of Viewpoints

Defining Viewpoint

A viewpoint defines a perspective from which a specific aspect of a system can be specified. Such system can be a software system (as described in the Software Factories book [GSCK04] or in the IEEE1471 standard). But here, of course, we consider any system (fortuitous or intentional) that can be made of humans, software and machinery.

Work product types organize into a hierarchy of viewpoints. For example a work product type called “database schema” (that contains a concept called “table” etc…) can be organized into a viewpoint called “Logical database Design“ that could be itself part of a viewpoint called “Data Access Development”.

For further information about Viewpoints, see Microsoft “Software Factories” on MSDN or IEEE 1471-2000 (Recommended Practice for Recommended Practice for Architectural Description of Architectural Description of Software-Intensive Systems).

Refining Viewpoints

The refinement of viewpoints consists in defining what viewpoint is used as input to define/create another viewpoint. For example, one might refine the viewpoint “Logical Database Design” into a viewpoint “Physical Database Design”.

Refinement Schema and Domain Composition

Now, creating domains than can be integrated is not sufficient. We also need an approach for effectively integrating these domains and creating “composite domains”.

A refinement schema is a meta-specification describing how different types of specification are precisely related and refined.

A refinement schema describes notably

· How concepts refine into concepts

· How work product types refine into work product types

· What concepts materialize into what work product type

· How viewpoints refine into viewpoints

· What work product types are part of a viewpoint

· How viewpoints are composed of other viewpoints

Thanks to some semantics-driven and organized approach, refinement schemas can be much more precise, more computer-readable, more integrated and more incremental than the different and often ambiguous meta-models produced by the IT industry.

Many of today’s meta-models are great and useful as long as they are used in isolation. Yet they are often semantically ambiguous, and, most of the time, they are semantically incompatible. “Stitching” these meta-models together would likely lead to a meta-monster.

Here are some categories of meta-models produced by the IT industry.

· Enterprise architecture framework meta-models relating very coarse grained artifacts like business functions, business process and applications.

· Software development process meta-models relating coarse grained artifacts, actions, human roles and tools like the Software and Systems Engineering Meta-model (SPEM).

· (Software) Product Line meta-models, also known as (Software) Factory schemas. Software Product Line meta-models are the supersets of Software development process meta-models. The additional items include notably specifications of re-usable assets and actionable guidance.

Common refinement scheme for the specifications

Requirements, Analysis, Design and Implementation

The journey from requirements to implementation is a journey to knowledge. To undertake this journey in favorable terms, we need a common, precise and unambiguous approach to create, categorize, refine and navigate our specifications.

We re-use the terms “Requirements”, “Analysis”, “Design” and “Implementation” that are ubiquitous in the industry. However, what is also ubiquitous in the industry is the ambiguity of these terms. Hence, to start with, we propose some disambiguation of these words when they apply to specifications:

Analysis specifications are imprecise specifications of a fictitious system.

Design specifications provide a synoptic and organized view on the implementation of a real system.

Implementation specifications define the precise disposition and behavior of every part of a real system. They are detailed and precise enough for the system to be instantiated exactly as specified.

Requirements are prescribed analysis, design or implementation specifications. A prescribed implementation can be, for example, an existing team of people, a building or a computer infrastructure to be used.

Refinement Grades

We introduce the term “refinement grade” to qualify the level of precision and detail reached by some specification.

Analysis, Design and Implementation are specification refinement grades that qualify any specification in any domain.

What we mean by “Analysis Specifications and Languages”:

— Analysis Specifications

o Are still imprecise specifications of a still fictitious system

o Can be generic or domain specific. There can be analysis specifications that are particular to a domain. But these specifications are imprecise.

o Do not provide a view on the actual implementation because, at this stage of the specification, the real system is still unknown.

— An Analysis Language

o Can be generic or domain specific.

o Is used to specify a still fictitious system when a precise description of a real system cannot be provided yet.

o Can be used to delimit boundaries between the unknown and the known. In other words, it can be used to delimit some scope for which the design of the real system is available

o Cannot be used to specify a real system

What we mean by “Design Specifications and Languages”

— Design Specifications

o Provide an organized, precise but synoptic and non-detailed view on the implementation of a real system.

o Are domain specific.

— A Design Language

o Is domain specific.

o Is used to specify a real system.

o Is a specification language that can be used to provide an organized view on the system’s implementation.

o Can be used to precisely delimit the boundaries between the known and the unknown. In other words, it can be used to delimit some scope inside which design or implementation specification are not available (analysis specifications might exist though).

What we mean by “Implementation Specifications and Languages”

— Implementation Specifications

o Provide detailed specifications of the precise disposition and behavior of every part of a real system.

o Are detailed and precise enough for the system to be instantiated (or even generated) exactly as specified.

o Are domain-specific.

— An Implementation Language

o Is domain specific.

o Is used to specify all meaningful implementation details of real systems.

Then what do we mean by “Requirements”?

Requirements apply to systems that can be heterogeneous. A heterogeneous system can include humans, software, machinery or any natural system that is not necessarily intentional.

In Automation by Nature, we use the word “requirement” as any normal (I mean “non IT” J) person would use it.

Systems requirements can be expressed by any stakeholder. They can address any part or aspect of the system (“functional” or “non-functional”) using any specification language and with any level of precision.

Requirements “induce” some parts of the systems specifications. While other parts of the specifications are “deduced” following some analysis, design and implementation decisions taken by the systems development team.

Are we missing “Business Analysis”?

A “Business” is a system of a certain complexity. It might include many subsystems. The complexity can range from one single human performer to numerous performers of many different kinds.

The “analysis specifications” of a business are imprecise specifications of a fictitious system.

The “design specifications” of a business are precise specifications of a real system including real roles and goals assigned to humans, software or machinery.

Further than this, there cannot be implementation specification for every role. In particular, it doesn't make much sense to create implementation specifications for humans. As far as humans are concerned, very detailed specifications cannot go beyond the analysis grade.

Each of us is a unique instance of a unique type of human performer. We are already instantiated according to some unspecified implementation. And hopefully, for now, each of us is coming with some unique creativity that software and machinery can’t reach.

The figure below illustrates how “Analysis, Design and Implementation specifications” derive from systems semantics:

Other Perspectives

We have seen that specifications are classified following some refinement grades namely Analysis, Design and Implementation.

Within each refinement grade, specifications can be further classified into more detailed perspectives. Some authors call these perspectives “Viewpoints”.

For further information about Viewpoints, see

Microsoft “Software Factories” which are described on the MSDN site

IEEE 1471-2000: Recommended Practice for Recommended Practice for Architectural Description of Architectural Description of Software-Intensive Systems

A system is a recurrent structure of resources involved in recurrent scenarios.

Because a software development system is a system to create systems (aka a “factory”), the systems semantics apply to the software development system as well.

A software development system, in particular, includes human and software resources. Some of these resources are performers collaborating, notably, on the specification of (another) software system.

So the software development system includes performers playing specific roles. And these roles participate in the specification refinement process.

A specification refinement process defines how the state of some resource (the specification considered as a whole with all its detailed constituents) evolves step by step.

A refinement process includes refinement scenarios. A refinement scenario (the dotted line on the figure above) is a recurrent sequence of evolutions of the specification state. This can be depicted using the following subset of the systems semantics. This subset was detailed earlier in this document.

Managing Complexity and the Unknown

Specification is not limited to capturing what is known. There is a lot of unknown and it useful to keep track of it.

It is therefore useful to capture and organize the boundaries of the unknown.

· Where is there something to be further discovered, hence to optimize?

· What is the scope of this unknown?

Managing complexity includes the ability to zoom into details when needed, when known or when specifying the known.

The natural systems semantics can be leveraged to keep track of the unknown in terms of marked delimited black boxes.

These black boxes can be later pinpointed and refined into white boxes.

Let’s take some example …

In the above picture we can see that there is some evolution from one state to the other. However, we don’t know exactly how this evolution takes place and we don’t know any detail about these states.

Unknown Evolution: We know there is an evolution from state Invoiced to state Paid. But intermediary states are unknown along with the involved operations, scenarios, performers, roles…

Unknown State Details: We might have summary information about some state. We see that something (?) is « Paid », but we still need some measurable account details.

Conclusions

Up to the 1960^th, automation was limited to the physical sphere i.e. delegating human physical operations to machinery. This was regarded as sacred by the industrial revolution and idealized by the Russian revolution and by Taylorism. Resource organization and optimization was addressing the mental and the physical spheres i.e. people, animals and machines.

From 1960 onwards, it is the advent of the digital sphere. Humans delegate to software. Resource organization and optimization address the physical, mental and digital spheres.

Today, we are facing overwhelming complexity. Technology centric approaches, concepts, notations, specification processes and tools are numerous and often incompatible with each others.

Rather than “fixing” and simplifying existing semantics, and specification languages, Automation by Nature is an approach that was built from the ground up i.e. from the essential lessons of nature.

Automation by Nature defines a strategy along with a tactical plan leading to optimized heterogeneous systems. Such systems can be optimized development environments that are used to build other systems. The process for executing the strategy is summarized in the tactical plan. It goes without saying that this process is iterative. Feedback is important since specific domains appear and evolve over time.

Automation by Nature also provides an implementation of the first tactical step along with some guidelines for realizing the next steps. The first tactical step consists in some natural systems semantics that is derived from the natural phenomena including natural evolution and patterns. The guidelines include an approach for precise specification styles. These specification styles comprise a refinement scheme along with some initial input for the elicitation approach.

Opportunities and Trends

As usual, the maturity of enabling-technology is determining, especially when it comes to

· Creating and integrating refinement schemas (meta-models)

· Defining domain specific languages and designers for each specific domain defined in the refinement schema

· Integrating domain specific languages and designers

· Managing and operating persistent stores of models and meta-models

· Interpreting integrated model instances or generating code from these model instances

· …

Within the software industry, Enterprise architecture framework endeavors (for example TOGAF), Domain Specific Language [CJKW07] and Software Product Lines / Software Factories [GSCK04] approaches, and repository platforms (like the Oslo Repository) can ease the realization of this vision.

Such opportunities are illustrated by the next picture. Here we can see that, thanks to Domain Specific Language and Software Factories authoring tools, we will be able to create homogeneous specifications and optimized development environments as long as they all derive from some common systems semantics.

Next suggested reading: Reference Systems Semantics

Acknowledgement

In order to create our natural systems semantics, I decided to follow the “natural phenomenon” (or at least my perception of what that is), forgetting the solutions I know while keeping only the lessons learned. I have been searching widely and deeply for similar approaches during (too) many years. And for now, as far as I know, only Automation by Nature has been taking that way. Hence I would like to thank Nature for its tremendous works of art. Note that as a result, and almost “by definition”, our Reference section does not include many entries.

Of course, being entirely unbiased is quite illusory. Things I could not forget, and that influenced me for sure, were these principles of impartial observations that my friend Eric Dubois had been teaching me some time ago during passionate discussions.

The tactical plan utilizes generic and domain specific paradigms for systems specifications and development in general. Our adoption of the domain specific paradigm has been largely influenced by these great innovations called Software Factories [GSCK04] and Domain Specific Languages [MSDSL05].

References

[NATURE] Nature, Unknown issue date.

[GSCK04] Jack Greenfield, Keith Short, Steve Cook, and Stuart Kent. Software Factories, Assembling Applications with Patterns, Models, Frameworks, and Tools. John Wiley & Sons, 2004.

[MSSF05] http://msdn2.microsoft.com/en-us/practices/bb190387.aspx: “Software Factories” on Microsoft Website

[CJKW07] Steve Cook, Gareth Jones, Stuart Kent, Alan Cameron Wills. Domain Specific Development with Visual Studio DSL Tools. Addison-Wesley, 2007.

[MSDSL05] http://msdn2.microsoft.com/en-us/vstudio/aa718368.aspx: “Domain Specific Languages” on Microsoft Website