AUTOMATION BY NATURE AN OVERVIEW - De Preter Overview.pdf · The roles I played include business...

(C) 2005-2009 Alain De Preter - Tous droits réservés - All Rights Reserved 22 February 2009 1/42

Automation by Nature

AUTOMATION BY NATURE – AN OVERVIEW

CONTENTS

Introduction ........................................................................................................................................................................................ 3

Executive Summary ......................................................................................................................................................................... 3

Definitions and Scope ..................................................................................................................................................................... 4

Origin of the approach ................................................................................................................................................................ 4

Audience ..................................................................................................................................................................................... 4

Contents .......................................................................................................................................................................................... 4

Ultimate Goal ...................................................................................................................................................................................... 6

The Problems ...................................................................................................................................................................................... 7

Example ........................................................................................................................................................................................... 8

Prospectives .................................................................................................................................................................................... 8

Approach ........................................................................................................................................................................................... 10

Principles and Mindset .................................................................................................................................................................. 10

Overall Strategy ............................................................................................................................................................................ 10

Tactical Plan ...................................................................................................................................................................................... 12

Natural Systems semantics ........................................................................................................................................................... 13

Recommended specification styles ............................................................................................................................................... 13

Analysis Specification Languages and Process .............................................................................................................................. 13

Simple domains ............................................................................................................................................................................. 14

Composite domains ...................................................................................................................................................................... 14

Feedback and Refactoring............................................................................................................................................................. 14

Systems Semantics ............................................................................................................................................................................ 15

Setting the Stage ........................................................................................................................................................................... 16

The Natural Phenomenon ......................................................................................................................................................... 16

http://www.depreter.org/AutomationByNature/index.htm


Spheres ..................................................................................................................................................................................... 17

Systems Evolution, By Nature ....................................................................................................................................................... 19

Fortuitous System ..................................................................................................................................................................... 19

Intentional System .................................................................................................................................................................... 20

Organized To Optimized ........................................................................................................................................................... 22

Organized to Optimize across Spheres ..................................................................................................................................... 25

Some Recommended specification styles ......................................................................................................................................... 28

Refinement ................................................................................................................................................................................... 28

Refinement of Concepts ........................................................................................................................................................... 28

Refinement of Work Products .................................................................................................................................................. 28

Refinement of Viewpoints ........................................................................................................................................................ 29

Refinement Schema and Domain Composition ........................................................................................................................ 29

Common refinement scheme for the specifications ..................................................................................................................... 30

Requirements, Analysis, Design and Implementation .............................................................................................................. 30

Other Perspectives .................................................................................................................................................................... 36

Managing Complexity and the Unknown .................................................................................................................................. 38

Conclusions ....................................................................................................................................................................................... 39

Opportunities and Trends ................................................................................................................................................................. 40

Acknowledgement ............................................................................................................................................................................ 42

References ........................................................................................................................................................................................ 42


INTRODUCTION

EXECUTIVE SUMMARY

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

http://www.depreter.org/AutomationByNature/doc/030%20Systems%20Semantics.htm


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 …

CONTENTS

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

http://en.wikipedia.org/wiki/Enterprise_Architecture_framework

http://msdn2.microsoft.com/en-us/vstudio/aa718368.aspx

http://msdn2.microsoft.com/en-us/practices/bb190387.aspx


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.

http://www.webster-dictionary.net/d.aspx?w=Optimize


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

http://msdn2.microsoft.com/en-us/library/ms954811.aspx

http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html



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.


http://en.wikipedia.org/wiki/Software_development_process

http://www.omg.org/technology/documents/formal/spem.htm

http://en.wikipedia.org/wiki/Software_product_lines



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

Analysis Specifications

Design Specifications

Implementations Specifications

Requirements

Induction

Induction


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.

http://msdn2.microsoft.com/en-us/library/ms954811.aspx



http://www.depreter.org/AutomationByNature/doc/030%20Semantics%20and%20Ontology.htm#System


http://www.depreter.org/AutomationByNature/doc/030%20Semantics%20and%20Ontology.htm#Digital


http://www.depreter.org/AutomationByNature/doc/030%20Semantics%20and%20Ontology.htm#Performer


http://www.depreter.org/AutomationByNature/doc/030%20Semantics%20and%20Ontology.htm#Performer

http://www.depreter.org/AutomationByNature/doc/030%20Semantics%20and%20Ontology.htm#Role

http://www.depreter.org/AutomationByNature/doc/030%20Semantics%20and%20Ontology.htm#Participant

http://www.depreter.org/AutomationByNature/doc/030%20Semantics%20and%20Ontology.htm#Process


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 1960th, 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.


http://www.opengroup.org/togaf/



http://msdn.microsoft.com/en-us/library/dd129569.aspx

http://msdn.microsoft.com/en-us/library/dd129569.aspx


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

Automation by Nature (C) 2005-2009 Alain De Preter - Tous droits réservés - All Rights Reserved

http://www.softwarefactories.com/TheBook.html

http://www.softwarefactories.com/TheBook.html


http://www.domainspecificdevelopment.com/

http://www.domainspecificdevelopment.com/


AUTOMATION BY NATURE AN OVERVIEW - De Preter Overview.pdf · The roles I played include business...

Documents

Transcript of AUTOMATION BY NATURE AN OVERVIEW - De Preter Overview.pdf · The roles I played include business...