by Edward N. Baylin

This is a working paper. I invite your comments and critique.

Last updated: January 25th, 2004

Background

After working sporadically on a book over a period of at least ten years, starting in the very late 1970's (when I was still a systems analyst in industry), I officially went public with my ideas on systems theory with three interrelated books, especially Functional Modeling of Systems, published by Gordon and Breach Science Publishers in 1990. Two concurrent "satellite" self-published books accompanied that book, one providing some examples, and the other going into more detail on diagramming methods. My ideas in this area have continued to develop since then.

A superficial reading of my ideas at the time led many to believe that I was another author developing yet another structured method of process modeling, rather than someone who was developing something more along the lines of a general systems theory.

Nowadays, my ideas are explained more in terms of class/object structure diagrams and role playing, which may lead some to believe that I has developed another method for object-oriented computer system analysis, but using some mathematical explanations. Although there is a degree of truth to such claims, it would be more correct to say that I take the approach of a philosopher looking far beyond computer information systems into the realms of epistemology and ontology.

Further generic structural sub-distinctions within any dimension are possible. For instance, within the flow function dimension, programmers usually distinguish sequence, decision, and looping structures (both accumulation and error correction loops). Our books also analyze that dimension in terms of other distinctions, in particular the so-called "intertwine complexity," which constrains flow functions to have the first input (supply acquisition) flow function occur before the first processing (transformation) flow function, and the last output (delivery) flow function after the last processing one. Within those constraints, more than one of each type of flow function can occur in a procedural flow, in any imaginable order. In addition to the flow dimension, a second dimension is often included by those who teach computer algorithms. This is the one that distinguishes levels of control within what I called the "adaptation" functional class. Modular programming and distinguishing this second dimension are the same subject insofar as the modules coincide with control levels. Modules in the flow dimension are, however, the ones that are emphasized by those who teach algorithm theory. Again, this only provides two of about seven dimensions of interest in creating generic structure in algorithms.  I sometimes ask myself whether my books are, in reality, among the most advanced works in the area of algorithm theory, although I'm not sure how others who have produced works on algorithm patterns would react to such a claim. I'll simply have to check out what has been done by others in this area before coming to any kind of conclusions.

But, there is another way of identifying the area covered by the books. This is to see them as being largely in the area of advanced structured algorithm theory. It has always struck me that people who teach computer programming tend to cover everything about algorithms in just a single dimension, i.e., the dimension of what in my books I call "flow functions" (see below). This one-dimensional approach implies a huge lack of conceptual structure, and makes the overall relationships in the flow difficult to follow. My books approach the subject in an approximately seven-dimensional way, thus providing a better way of conceptualizing the generic procedural structure. Moreover, much leveraging of these ideas is possible, since the patterns are recursive. The relation between these various dimensions is discussed further below. Further leveraging of the ideas comes from the fact that this relation is fairly simple.

 As a simple example, applicable to a computer program, lets us add a second dimension, say, to distinguish the set-up (declaration of variables, opening of files, allocation of memory, and so on) and wind-down (de-allocation of memory, etc.) operations. These would be in a separate dimension from the direct operations (called "baseline" in my books). This provides a two-dimensional structure to the conceptualization of the algorithm, instead of putting all these operations into a single, unstructured flow. In other words, you are now looking at a table depicting the program procedural structure with its rows (each depicting a step in the program) divided into two columns.

To conclude this background section, it is important not to lose sight of the fact that, although it may look as if the ideas are very different from what they were in 1990, the core ideas are actually the same as they have always been. What has changed is mostly that I developed some badly needed perspective on them, along with which came a different way of expressing the ideas and understanding their relevance and connections with the ideas of others.
 

A Summary of the Ideas As They Now Stand

• Objects versus object classes

• Types of roles

Objects versus object classes

The role theory developed here is generally applicable both to relationships between objects and to relationships between object classes. However, some roles apply only to relationships between object instances, while others apply only to classes (types, kinds, categories, etc.) of objects. In fact, one type of role provides the relationship between objects and object classes themselves.

To keep down the number of words in the rest of this paper, although the discussion is generally phrased in terms of object instance roles only, class roles are also implied unless otherwise stated.

Types of roles

The latest expression of these ideas includes new facets, and the use of some mathematical set theory. The ideas are now expressed in terms of their providing a canonical, multi-level scheme of types of roles that objects play in their relationships to one another in a system or in modeling a system. An object may also play these roles reflexively and recursively (back on itself), and may engage in parallel in any number of roles in relation to any number of objects.

The role classification is thought to be complete, and consists of:

1. Similarity/anti-similarity roles: Objects can have roles that allow objects to represent one another. In fact, such roles are the basis of modeling relationships between objects. The relative similarity or dissimilarity of objects to one another can be arranged on a fuzzy similarity spectrum, where objects can range from being complete equivalents (e.g., synonyms) to complete opposites (e.g., antonyms) of one another.
   

2. "Primary" causal roles: Such roles include those of:

   • Agent/instrument: That which carries out the process involved.

   • Input: The patient of an action; the operand; that which is transmitted, transformed, transfigured, transmuted, translated, etc.

   • Output: The product of an action; the output of an event.

   • Pattern-provider: The pattern may be a method to be followed, a spatial pattern, a value pattern, or a pattern of meaning. A method, for instance, is the flux pattern, procedure, or series of steps, that the agent/instrument carries out to complete the process involved in the event.

   • Context-provider: Time, space, population, viewpoint/discipline/domain, giving the backdrops against which the event happens.

With respect to thesaurus systems, which involve word relationships, a search that finds "lecture," which is a kind of event, might also find the words for the corresponding:

• Agents, which include teachers and students (who actively participate in their own learning).

• Inputs, which are the students, who are the patients of the lecturing process carried out by the teacher agent and their own participation in it.

• Products, which are the students who have now learned from the lecture.

• Methods, which, for example, include lecture notes to guide the teacher, and steps undertaken by students to integrate the materials of the lecture into their memory circuits.

• Contexts, which include the school or classroom, the time of the lecture, the academic community, and so on.

3. Derived causal roles, i.e., the event role, played by associative objects, derived from the intersecting roles of objects playing the primary causal roles: Whenever an event occurs, a number of objects are involved in these roles.

With respect to the previous example, the happenings during the lecture, such as delivery of materials by the teacher, absorption of the presentation by the students, and internal reflections of people on the subject at hand.

Primary and derived (event) causal roles are understandable only relative to a given system. In the wider scheme of things, all objects (also known as entities) are "eventities," i.e., associative objects as well as "primary" objects (although the converse may not be true).

A mountain can be seen as an event instead of a static object when viewed over millions of years of change in the mountain characteristics. Thus, the word mountain may be understood as being both a verb and a noun [ the many works of Kent Palmer at dialog.net:85/homepage/kent_palmer.html].

4. Hierarchical roles: Hierarchical roles include:

   • Controller/subordinate roles: played in superior versus inferior relationships.

   • Component/composite roles. Such roles are of two kinds: 1) an object is completely and uniquely included in another object; and 2) an object may be a component of more than one other composite object, both of which share the object as a component.

   • Super-class/sub-class roles: applicable only to object classes; analogue of ancestor/descendant roles played by object instances.

   • Ancestor/descendant roles: applicable only to object instances; the analogue of super-class/sub-class roles played by object classes.

   The possible relationships of hierarchical roles (which are the basis of mathematical ordering relations) to causality is mentioned below.
   

5. Classification/Instantiation roles, i.e., roles based on the relationship between an object class and an object that is an instance of that class. Object occurrences may be classified, while object classes may be instantiated to create object occurrences. In object-oriented programming, we speak of instance creation and instance destruction operations (usually referred to as methods), each of which carries out a particular sub-type of instantiation role. This idea can also be thought of in terms of object classification and declassification.

I have applied this scheme of primary roles, along with a simple event role, to several object/object class relationship diagrams in the computer systems field, and might provide an important enhancement to methods for creating such diagrams, including the UML (Unified Modeling Language) method that has now become the norm. Ignoring such a scheme for assignment of roles to objects in their relationships to one another may be to ignore basics in favor of idiosyncratic schemes created in a helter-skelter way by a motley crew of information system modelers.

Mapping to Earlier Ideas Formulation

• A general systems theory based on role classifications

• Similar ideas found elsewhere

A general systems theory based on role classifications

As stated, this role theory is basically just a very different way of presenting my earlier ideas on general system process modeling. However, the process modeling ideas in my 1990 books go considerably further, in that they produce many sub-classes of the event roles played by associative objects.

In fact, Functional Modeling of Systems presents various ways of classifying associations (the event role). In that book, a relation between these roles is developed, i.e., a sub-set of the Cartesian product of the different sets of values associated with each type of associative role.

Associative roles in the relationships between associative objects themselves are first sub-classified into baseline versus adaptation functions, based on the factor of directness of relation to objectives. Directness is in the sense used in accounting, rather than in the sense of immediacy. Adaptation functions are those used to plan, organize ("framework"), and control (direct, ensure) a system, while the baseline functions directly carry out the essential purpose of a goal-directed system.

From there, further levels of sub-classification are based on concepts that include:

• Decision-making versus decision-implementing adaptation functions: orthogonal to other distinctions applicable to adaptation functions described below.

• Hierarchical control level of decision-making (adaptation) functions: orthogonal to the distinctions based on other factors described below in this list.

• Adaptation function timing factors:

  • Time frame: long-term, medium-term, short-term, etc. In its simple form, this leads to distinguishing control functions, which are short-term, from planning and framework (organizing) functions, which apply over a relatively longer-term time horizon. Note:  Baseline functions are always short-term, by definition.

  • Time orientation of short-term adaptation functions: initiative, interruptive, and after-the-fact sub-classes, as well as further sub-types of the interruptive sub-class.

• Flow sequence functionality ("flow functions"):

  • Input, process, and output — applicable to both baseline and adaptation functions, and thereby orthogonal to other distinctions described below.

  • Further generic divisions of (adaptation) decision-making flow functions: For instance, sub-types of adaptation process flow functions include investigating a problem or opportunity, laying out alternative solutions, and making an actual decision on what to do. Generic sub-types of input and output flow functions are also distinguishable.

Classification in this generic pattern leads to a first-cut hierarchical functional decomposition of the system, within which further decomposition is possible based on non-generic factors until the required level of magnification of details has been achieved for any purpose at hand. The classification pattern itself is recursive (fractal), perhaps to infinity.

Let me now explain mathematically, using simple set theory, how all these role types are intersected with one another to obtain a general systems process model.

A "system relation" is obtained by composing the set that contains the various above values for primary roles with the relation that describes the derived roles. (Note: As will eventually be seen, this larger relation is still only a projection out of a still larger relation, involving even more sets.)

In mathematical terms, a model is usually thought of as a relation that has a homomorphic relation to another relation that is modeled by the model. In other words, it is a relation between two similar patterns of objects. The model is on the "one" side of this many-to-one relation between relations, and so can potentially be at a more abstract level than the relation representing the system that is being modeled. A model can also be understood to work in the reverse direction, as the specification for a particular system that is constructed based on a meta-model or a theory. The generic model can be used for modeling in both senses. In either case, the generic template can be viewed as a syntactic expression of the patterns of structure and flux (behavior, process) of a system.

The overall composite relation thus obtained can be said to be a generic, or canonical one, since all the sets provide categories that go back into the realm of epistemological or ontological understandings. This generic relation can also be viewed as a generic system model, i.e., as a general template or meta-model, or as a model of a general systems theory. This model is domain and scale independent, i.e., can be used with systems in any application area or of any size.

Using the idea of model in the first above sense, system instances, or sub-classes of generic system models applicable to generic system types (e.g., allopoietic, dissipative, autopoietic, or reflexive systems, according to the to-be-described Palmer's ontology) may be modeled by plugging in different detail levels of more specific values. Thus, when the template is applied either to model a particular system, or to specify a to-be-developed system instance, semantic content is added to the various placeholder positions in the template. In this addition, the syntactic expression of structural and behavioral patterns is supplemented with domain and application-specific semantic content that expresses the patterns of value and meaning of a system instance, as well as the details of the structural and behavioral patterns giving that system occurrence its unique features.

Examples of application (instantiation of placeholders) of the template to modeling systems are provided in one of my two satellite books, Conceptual Prototyping of Business Systems: A Templating Approach to Describing System Functions. In that book, I showed that four apparently completely different allopoietic business systems are actually isomorphic (equivalent) to one another. For simplicity, the entire template was not applied to these systems. Placeholders for planning and organizing (framework) functions were left essentially unfilled. That is, by elimination, I modeled only the "operating core" of these systems with the template. This operating core includes the so-called "transaction-processing" information systems, which are part of the operating core control systems.

The general system model in Functional Modeling of Systems book not only further sub-classifies the event role, as described, but also applies the time frame (one-shot, short-term, medium-term, long-term) idea to engender different sub-classes of agent/instrument and method pattern-provider causal role types.

Similar Ideas Found Elsewhere

General systems models

My generic meta-models can be usefully compared to other attempts that have been made, mostly in the 1970's, to develop general system models that are somewhat analogous to one another and to my models. Examples of this way of thinking are found, for instance, in books such as those authored by J.G. Miller or Stafford Beer. However, those authors are as different from one another as they each are from me with respect to how their ideas are developed and expressed.

Miller expresses the ideas based on a model of the organism, which is a kind of root metaphor used by us for a system (as we project our own organization on ontic phenomena). Beer, on the other hand, tends to approach the subject from the viewpoint of business or other organizations and their management (command and control structures). In both cases, the authors tried to stretch the idea of the allopoietic system to fit what are perhaps better modeled as autopoietic or reflexive systems.

My expression reflects the experience I had during my career as a business computer systems analyst, during the era when the structured approach to process modeling was in its heyday.

The ideas are expressed in my books in terms of a new, very complex diagrammed method called the "structure-flow chart." The development of the latter coincided with some general research on procedural diagramming, which was published in one of my satellite books in 1990, namely, Procedural Diagramming for System Development: From a More Scientific Viewpoint.

Thesaurus relationship theory

Application of something along lines that are comparable to my role theory can be found in works on thesaurus relationships, i.e., the theory of relationships between words.

A good paper on how this has been done can be found in an article by Tudhope, Alani, and Jones, in the Journal of Digital Information, volume 1, issue 8, February 5, 2001. To locate this article, "Augmenting Thesaurus Relationships: Possibilities for Retrieval," on the Web, jodi.ecs.soton.ac.uk/Articles/v01/i08/Tudhope/. Beware in looking at this article that the similarities and relationships to my role theory are not immediately apparent, since the manner of expression and domain of study are quite different.

Thesauri concentrate on similarity ("use for") and classification (narrower/wider than) relationships between words. If the thesaurus is for a particular discipline or domain, the context relationship also becomes important, giving the viewpoint of that domain. Any other word relationships are usually simply grouped under the umbrella of "related-to" relationships. Note: By "classification," librarians not only refer to the meaning of the word just explained, but also refer to the context causal role. These two roles are separated, as seen above.

Philosophy

Although it is focused in a very different way, the core idea involved in my role theory can be roughly mapped to Palmer's [ archonic.net/] four viewpoints for studying real-time systems, as well as to Aristotle's theory of causality (perhaps as extended by the differentiation of being from existence [ www.cathinsight.com/philosophy/causality.htm]). The latter's kinds of ideas have been extended to include:

1. The context role type, for objects representing space, time, or population, and perhaps other types of context.

2. Various sub-classes of all the role types, whereby particular types of formal (pattern), material (input), efficient (agent/instrument), and teleological (see next) cause are delineated.

3. An arguably correct reinterpretation of teleological cause in terms of different types of hierarchical roles, including decomposition and classification hierarchy sub-types. As well, the output role arguably maps to Aristotle's teleological (final) cause. Hierarchical roles can perhaps also be interpreted as related to teleological cause as follows:

   • In the case of decomposition (part/whole) hierarchies, the role of the part is to help fulfill the role of the whole.

   • In the case of classification (typing, specialization) hierarchies, the role of the ancestor or the super-class is to form a cohesive, more core-centered purpose for all its more specialized descendants, of which the ancestor forms the core.

4. A different kind of treatment of Aristotle's formal cause role type, whereby it is discussed at the level of the object (what Palmer calls the "form"), as well as below the level of the object, at what Palmer calls the pattern level. Moreover, different "views" (for want of a better term) of the object (form) or patterning are identified by Palmer.

Further Possible Development

The system meta-model represented by my generic relation goes back to the levels of ontology and epistemology, which are branches of philosophy. Going back to these roots, here is a far more interesting and fundamental further set that can be composed with my system relation, a set not known to me in 1990. That further set can be seen as being at a meta-level to the composed relation, since it affects how the relation set itself is viewed.

This set is based on Palmer's theory of modes of Being and Existence. Palmer proposes four modes of Being, one of which allows us to see the world in terms of allopoietic systems. It is the latter way of seeing the world, called Pure Presence by Palmer, which is selected from this set in Functional Modeling of Systems. However, for dissipative, autopoietic, and reflexive systems, other values of this set would be more appropriate.

Other elements in this set provide us with an increasingly less frozen kind of Being. Palmer calls these Process Being (associated with dissipative systems), Hyper Being (associated with autopoietic systems), and Wild Being (associated with reflexive systems), successively. The fifth element of this set is Existence itself, which can be seen as the null set. If Existence were to have been selected as part of the relation in question, the relation itself would be canceled, since Existence is emptiness, or the void, where distinctions such as those made in the other sets in this relation cease to have any meaning.

I would like to extend my theory of role relations to include the ideas of types of systems and system environments as developed by Kent Palmer. In this way, specific, canonical/generic relation sub-classes can be specified. The extended theory would be more appropriate for modeling dissipative, autopoietic, and reflexive systems.

The application of the theory to these other kinds of systems is a problem whose complexity has hardly been mentioned so far. Although the popular term "system" is applied to dissipative/autopoietic/reflexive systems, such mental templates (schemas) may perhaps be more appropriately viewed as systems inter-penetrated by the system environment in varying degrees. This degree of environmental inter-penetration increases as we go from dissipative, to autopoietic (self-organizing, organism), to reflexive (social) systems.

My ideas are based on the allopoietic system schema (normally what we mean by a system), which has to be unnaturally stretched for it to apply to phenomena that we have a tendency to schematize as dissipative, allopoietic, and reflexive systems. In Palmer's hierarchy of mental templates that we can project upon phenomena (called the "ontological hierarchy"), there are ten basic levels, with the system level being near the middle. Palmer's three "special systems," the dissipative, autopoietic, and reflexive, actually form three sub-levels above the system level, right at the center of this hierarchy, between the system mental template and the mental template of the system environment. (These templates of understanding themselves are some sort of relation founded on the Cartesian product of certain fundamental philosophical categories, the kinds of Being, and another classification scheme that Palmer calls "aspects of Being.")

Palmer has managed to put his insightful ideas into a kind of "theory of everything" that is perhaps unlike anything seen before except in the latest physics (with its 11-dimensional string-based theory). His idea of autopoietic systems solves some fundamental contradictions inherent in the explanations of such systems in systems theory/science thinking.

Back (Up a level)