Modeling

UML is a modeling language. Its "expressions" (diagrams/models) represent systems or domains:

Systems include software systems, hardware systems, and organizational systems.

A domain is some part of the real world. Domain elements include descriptions, relationships, and objects. A domain can be broad like "education", less broad like "university" and narrow such as "San Jose State University".

Syntax & Semantics

Like a programming language, a modeling language has syntax (structure) and semantics (meaning).

The syntax of a modeling language specifies what a well-formed model looks like. For example, the following UML model is well formed:

It is well formed because the syntax of UML says that a generalization arrow may connect any two classes. On the other hand, a generalization arrow may not connect a class to an object. Such a model would not be well formed. (My CASE tool wouldn't allow me to draw an example.)

Although the above model is well formed, there is something wrong.

The semantics of a model can be viewed as a function that maps model elements to the system/domain elements they represent.

rep: Model -> System/Domain

The mapping preserves truth in the sense that true statements about the model elements should map to true statements about the system/domain elements they represent.

In the above example we might assume that:

rep(Dog) = the set of all dogs in the present world

rep(Car) = the set of all cars in the present world

Semantically, the generalization arrow maps to the is-a relationship in a system or domain:

rep(generalization) = is-a

The generalization arrow from the Dog class to the Car class suggests that a dog is-a car and therefore a dog can substitute for a car in all contexts, as in: "Lend me the keys to your Buick Dachshund."

Representing Descriptions

While objects in a UML model clearly represent objects in a domain or system, what do classes represent? An important element of any domain or system is a description or definition. For example, "Student" is an important term in the education domain. But what is the definition of this term? At a particular university it might be quite technical:

A student is any person who is currently enrolled in 12 or more units.

This definition is an example of a description.

In a student management system the definition might be even more technical:

class Student extends Person {
   private int numUnits;
   // etc.
}

Most UML elements map to descriptions: use cases, classes, associations, state machines, sequence diagrams. Here's our example in UML:

An important relationship in any system or domain is:

Object x instantiates Description d.

We can replace "instantiates" with "is described by" or "conforms to".

For example, in the education domain a particular student, Bill Smith, instantiates the student description. In a system an object instantiates a class:

Student smith = new Student();

In UML:

Meta Descriptions

We can say that a domain or system consists of descriptions and objects that instantiate those descriptions:

Note: an object may instantiate more than one de4scription. For example, Bill Smith instantiates the Student description and the Person description.

Because our definition of object extends beyond physical objects to include abstractions, we can think of a description as a kind of object:

This opens the possibility of a description instantiating another description. For example, the Java declaration of the student class instantiates the EBNF description of a valid class declaration:

DECLARATION ::= CLASS | INTERFACE | METHOD | VARIABLE | ...
CLASS ::= MODIFIER* class NAME (extends NAME)? (implements (NAME,)* NAME)? { DECLARATION* }

We can think of a description that describes other descriptions as a meta-description. Of course there are meta-meta descriptions, etc.

Descriptions as Patterns

A description can be thought of as a type of pattern. Instances of a description are objects that conform to the pattern.

Patterns can loosely be classified into behavioral patterns (instances are performances or executions) and structural patterns (instances are objects), although some pattern include both behavior and structure.

Here are some examples of patterns:

Scripts, Scores, procedures, and Recipes

A musical score is a pattern. An instance would be a performance or execution.

The same is true for scores, recipes, algorithms, and procedures (such as work flows).

Mathematical Equations

Mathematics is the ultimate pattern language. An equation such as

p' = cp

describes the growth pattern of a population.

Roles

A role is a behavior pattern—the tendency for an actor to behave in a particular way. Compare, for example, the diner and waiter roles.

Regular Expressions

A regular expression is a pattern. For example, the regular expression (01)+ describes all strings consisting of alternating 0s and 1s that start with a 0 and end with a 1. Here are a few instances:

01
010101
01010101010101010101

By the same reasoning, formal grammars are also patterns. Their instances are grammatically correct expressions.

We might attempt to define the language of regular expressions using a regular expression:

RE ::= Token | RE+ | RE* | RE | RE | RERE | (RE)

Note that this is an example of a meta-pattern.

Schemas, Frames, and Scripts

Instantiating cognitive structures such as frames, scripts, and schemas are used to quickly make sense of the world. Examples of frames include the Strict Father frame and the Nurturing Parent frame. These frames have been shown to be involved in formulating political ideologies.

Class and Function Declarations

A class declaration are patterns.

class Account {
   public:
      void withdraw(double amt) { balance -= amt; }
      void deposit(double amt) { balance += amt; }
   private:
      double balance;
};

Instances of classes are objects.

Similarly, function declarations are patterns:

double square(double x) { return x * x; }

Instances of function declarations are function calls or executions.

Design Patterns

A design pattern describes a common collaboration.

Meta Models

Modeling is a domain, just like education. There are modeling systems, such as CASE tools. We can model models. For example, we might specify the syntax and semantics of UML by building a model. We could even build a UML model of UML. This is called the UML meta-model. This is done in the UML meta model specification.

Software engineering is a domain. We can build UML models of the analysis and design models of software engineering. As an example, we specify a CASE tool called InCase.