|2.3 Conceptual Modeling|
|Home||Business Rules||Rule Based Systems||Rule Engines||Semantic Web||Links||Under the Hood|
The Wikipedia defines a model as "an abstract (or actual) representation of an object or system from a particular viewpoint".
There are three parts to the definition - an object or system, a representation and a viewpoint. It is critical to understand the role of each element of a model.
An "object or system" is essentially an unknown and perhaps unknowable thing; an object as something in the world to be modeled has potentially an unlimited amount of information associated with it. For instance, a chair as an actual physical object in the world possesses innumerable structural characteristics, such as materials and their strengths, as well as myriad facts about the styles of the chair or its history, for instance who sat upon it ( say, it was your great grandfathers chair and consequently is irreplaceable ). There might be many thousands of possible facts associated with a single chair.
Of all the many possible characteristics of given object, there often is only a single fact or facet that is of interest to us, a few dozen facts as opposed to many thousands. Whenever we use a chair, our mental representation of the object discards at least 99.9% of all information about chairs and focuses exclusively on the 0.01 % of the characters that effect us, most commonly whether it will hold me up without breaking or tipping over.
The representation of an object is further simplified by picking a particular viewpoint according to the need of the moment. For instance, if someone is considering standing on a chair to reach something on a shelf rather than just sitting on it, the fact that the seat is made of woven cane would be the most important aspect of the chair for from that particular viewpoint - it would be more likely to break than a metal chair. Even if it were a fairly substantial chair, the fact that it was your grandfather's chair might make it unusable as a step ladder - far better to make a trip to the basement and get a ladder rather than risk breaking it.
We perform the mental gymnastics of mapping from object to representation to viewpoint effortlessly and naturally. Many people are unaware that they are doing it. However, when one is forced by circumstance ( or inclination ) to try to get a computer to perform commonsense tasks of this sort, it can be a very difficult to accomplish
Function, Structure and Behavior
the late 1980s, a group of academics investigating models of physical systems developed a set
of guiding principles to help them perform simulations. The purpose was to perform an amazing
and unprecedented feat of computation - predicting that water spilled on the top
of a table would eventually drip on the floor.
It may not sound like an impressive achievement but it was huge step forward for conceptual modeling. Before their conception of qualitative physics, a simulation would require the solution of complex simultaneous equations, a computational task not far from calculating the course of individual water atoms.
The central figures were Kenneth Forbus and Johan de Kleer, who edited the classic text of the field, "Qualitative Reasoning about Physical Systems". It sparked a small and very quiet revolution in computer simulation of complex physical systems. Interest also spread to human cognitive processes than could be called commonsense reasoning,.
The cornerstone of idea was a very simple. There were three components to a physical simulation - function, structure and behavior. The modeler starts with one of the three components, say a structure, and then derives the function of that structure ( what can be accomplished with it ) for a given set of behaviors ( actions ).
A typical example might start with the structural description of a hammer and a inventory of possible behaviors ( actions ), such as - 1 ) swing it from the handle, 2 ) throw it, 3 ) lay it on top of something, 4 ) attach it to something, etc. From these behaviors, one can derive the functions of 1 ) driving a nail, 2 ) driving away pesky critters from the garbage bin, 3) keeping papers form blowing away, 4 ) sinking something that floats, etc.
There are six possible mappings between the three components.
The conceptual framework is quite simple to use. For instance, if someone needed to drive a nail but did not have a hammer, one might look for things structurally similar to a hammer ( solid, heavy ) that could be used with the same action as a hammer ( pounding on the nail ) to achieve a given function ( to drive the nail into a board ). This would be the equivalent of the fifth type of mapping on the list, that is from function ( drive nail ) to structure ( something like a hammer ) for a given behavior ( pounding ).
Note that the order is important. It is not likely that someone would whack on the nail with a heavy glass vase - the search is for something structurally similar to a hammer. The question is, what can I use to pound the nail into the board ? The required 'what' is something like a hammer, so the variable output is structure, not behavior or function, which are both fixed.
It is a very simple conceptual framework, but has surprising power to describe the workings of physical systems at a high level of abstraction. The concept was so powerful that that it was picked up by software architects to describe non-physical systems, such as the workings of object-oriented software.
The first mention of design patterns in relation to software was made in 1987 by Kent Beck and Ward Cunningham
( who also invented CRC Cards ). The idea of design patterns then kicked around for a
few years, but became popular in 1994, with the classic text "Design Patterns: Elements of Reusable Object-Oriented Software",
edited by Erich Gamma, Richard Helm, et al.
The Wikpedia defines a design pattern as "a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations".
Since 1994, the number of design patterns has proliferated but Gamma's original text identified three types of design patterns - structural, behavioral and creational patterns. The creational patterns are roughly equivalent to the functional component of the function-structure-behavior model. An example of a structural pattern is a "Composite", which composes individual objects into a collection, often represented as a hierarchical "tree" structure. An example of a behavior is the "Mediator" pattern, which determines how two objects interact independently of the object themselves, decoupling explicit references to one another, somewhat like a business rule.
A Generic Conceptual Framework
Six Categories of Questions
Mapping Subjects to Categories
Journalism majors know the drill by heart. The First Law of Journalistic Excellence, the 5 "Ws" of Reporting ( and an "H" throw in just to make life difficult for journalism students ). The Law states: every journalistic oeuvre must answer these eternal questions - who, what, when, where, why and how. That's a fine principle for overworked journalism students, but what about the rest of us, for example they who toil tirelessly in the murky mines of Infotechnology.
Enter the Zachman Framework.
A Zachman Framework provides a generic analytic template that can be used to model ( in theory ) any entity that exists or can be thought to exist, more specifically the interactions between the entities. It is in the form of a table or spreadsheet with the top row containing the six questions and the left column containing the subjects of attention or under discussion. In practice, the model is usually centered on business process.
Note that in the "Real" Zachman Framework, the subject on the left side are 5 "stakeholders" in the business enterprise - the Planner, Owner, Designer, Builder and Subcontractor. While these five categories have some relevance to a Semantic Web, at the level of conceptual modeling their usefulness is limited. In fact, any 'well-formed' collection of interacting subjects will work in a Zachman model.
Below is a simplistic example of a customer ordering a product, with approval from the credit department of course.
Usually the empty slots in the framework fill in easily and fairly naturally, giving a basic sense of who the players are and what they are doing. The order of the questions in the row can be significant. The model above is focused on 'why' and 'who'. From the perspective of the order fulfillment process, the questions 'what', 'where' and 'how' might be the most significant. Each category of question can become a pivot point for a greater level of detail in the model.
Deeper Understanding of the Six Categories
Fuzziness of Subject
Fuzziness of Categories
Leveling the Model
Below are more detailed descriptions of the six categories. The definitions are fairly flexible, indeed, they need to be.
Sometimes, there are subtleties in the interaction between the subjects and questions that require a deeper understanding of the subject in order to assign them to a specific slot.
For example, there might be a business policy saying that all orders for a highly profitable product that happen to be out of stock in one location will be shipped out the next nearest location, even at a higher shipping cost for the company. In others words, locations of shipping point and distances between them are suddenly an important factor - it requires a fairly complex locator function to map from "what gets shipped from where" to "where it gets shipped to". A deeper understanding of 'where' is required.
There may be significant features of a situation that demand a stretching of the categories themselves. For instance, the category of 'where' can include a sense of 'where are we in moving toward our objective", with a clear sense of moving nearer or farther away from it as if it were a definite location. The category 'when' may refer to a window of opportunity rather than definable instant or duration of time. In this case, there is a sense is of moving in time toward the window, but once it is past, that time is no longer accessible, it's too late. In other words, a window of opportunity behaves more like a 'when' than a 'what' or 'where'.
Often the fuzziness is based on the type of task being performed. For instance, detailed planning tasks have strong elements of 'how' and 'when', mixed with in 'what', in the sense of the plan itself as a concrete structure of tasks. There is also a sense of 'what' tasks need to be performed, although these tasks are probably more properly modeled as 'hows'.
More confusion can arise by mixing different levels of interaction among the subjects, such as mixing the high level concepts of' why' or 'what to do' with lower level concepts, 'when, 'where' and 'how' to do it. In the case of a framework for planning, the model would show the interactions between the plan and other plans or objective in the organization. It would not work to mix interactions between the plan and its constituent parts within the same subject framework. The framework needs to be 'leveled' the same as any other model - things of basically the same type need to be shown at roughly the same level of the model.
The E-Z Framework
Is It A Meta-Model ?
Mapping the FSB Criteria to the E-Z Framework
Zachman Framework is both powerful and flexible. There are several
extensions and variations of the Zachman Framework available in the
marketplace. In fact, it can be used as a form of 'meta-model' to
map the features of two models.
Mapping the three model qualitative reasoning concepts, Function, Structure and Behavior ( "FSB" ), against the six categories of the Zachman Framework produces a sort of 'main sequence' of shared characteristics, running from the top left to the bottom right.
This diagonal mapping implies that subjects will tend to group themselves according to the FSB criteria. A paragraph above said that "things of basically the same type need to be shown at roughly the same level" of the model - the 'types' correspond to the FSB criteria.
For instance, in the example of a customer ordering a product, the subjects on the right are mostly functional subjects rather than structural or behavioral. If the subject were production planning, the subjects would be mainly structural descriptions, such as product configuration, raw components and sub-assemblies, inventory locations, highly structured production schedules reflecting aggregated lead-times for processing steps, etc. At a lower level would be behavioral descriptions of specific processing steps, such as stamping or lathing, mixing chemicals and maintaining a certain pressure and temperature for some duration of time.
Each E-Z Framework model will show a type of subject and interactions between them. Each will also have aspects of all six categories of questions within them - even a lower level manufacturing step has a 'why' associated with it. But a processing step is primarily a behavioral 'how' and 'when' and not a functional 'why', it would be modeled properly on the same level as other behavior entities, rather than mixing up it with functional and structural entities.
Don't Forget Good, Old Fashioned Objects
The Object Role Model
So far, the
discourse has avoiding the siren call of 'computer-friendly"
objects in favor of "people-friendly" subjects and the subject
distinction will be maintained as long as possible.
But, sometimes, there's nothing like an object. It knows things, it knows how to do things and knows other objects that know how to do things ( like the CRC Cards mentioned in a previous section ).
A most critical facility provided by object technology for the semantic web are so-called 'object ontologies'. Haley has an excellent definition of ontology.
It would be comforting to think that an object ontology can somehow be reduced to a 'subject' ontology, but it is not really true. There are significant features of the popular OWL ontology language that require an understanding of objects in order to use effectively. This topic will be revisited in a later section on modeling with objects.
Another object technology supporting the semantic web is Object Role Modeling.
Note the key words are "natural language" and "intuitive diagrams", suitable for non-computer people. While ORM can used fairly easily in developing computer applications, the whole topic of object technology is too computer technical for this section, and will be discussed in the Inference Engines section.
Task Models versus Process Design Patterns
A KADS Ontology
Generic Tasks as Stereotypes
task models are similar to design patterns. In fact, doing a
search on "process design patterns" will reveal an entire
world of software development disciplines and methodologies offering
'descriptions of how to solve a problem' in the design of business
systems and processes. However, there is a clear distinction
between process patterns, which are derived ad-hoc from experience, and
generic task models, which are derived from first principles and are
intended to describe all knowledge-intensive tasks systematically and
The premier methodology is is called "Knowledge Based Systems Analysis and Design Support", hereafter referred to as 'KADS'. The most generally useful text on the subject is "Knowledge Based Systems Analysis and Design: A Kads Developer's Handbook", by D. S. W. Tansley and C. C. Hayball, currently unavailable on Amazon.com.
The original objectives of generic tasks were fairly modest, to help build KADS Expertise Models, that is the steps a knowledgeable person would take in solving a problem or analytic challenge of some sort, for example, diagnosis, fault determination, etc. The specific generic tasks identified by the KADS methodology turned out to be applicable to many area outside of software design.
Generic task models have been around for years in Europe, but have had surprisingly little impact into advanced information technology in the United States. In fact, interest in KADS has even languished in Europe since the ESPRIT project began to wind down. To some extent, the ideas of KADS have been absorbed into commercial tools and methodologies that are more focused business processes, such as Carnot. Most of the benefits of generic tasks models were lost in the process.
One gleam of light in the gloom is a fascinating site from Australia ( not Europe ). WebKB has an interesting comment about itself: "WebKB refers to the knowledge base (KB) servers WebKB-1 and WebKB-2. KB servers are not Web search engines ...". It is a cogent observation on one of the ongoing debates about the term 'semantic web', which can be taken to be no more than advanced search engines.
The concept of generic tasks has great power but can also become very complex as the size of the problem grows. However, they will be useful as simple stereotypes when modeling relatively complex workflow processes. The subject of generic tasks will be revisited in the section on Modeling Workflows.