RE: [discussion@2uworks.org] RE: [wg@2uworks.org] Re: Book



Date view Thread view Subject view Author view Attachment view

From: Joaquin Miller (miller@joaquin.net)
Date: Thu 12 Sep 2002 - 11:39:48 BST


>In my deliberations on this so far, I have reached the conclusion that we
>need both the capability to model objects using a UML tool and to model
>prototypical instances (although a prototype may permit a set of instances
>rather than just one), but that the latter should be via additional elements
>in the abstract syntax (what I think of as the "type" domain) rather than by
>using elements from the Semantic (what I call the "instance") Domain. I
>would then not mix the two in a given model, even though I would expect a
>modeling tool to support both. As a modeling tool vendor I can see how to do
>this, but I haven't looked in detail at the formal underpinnings for the
>approach.

This is fine.

Notice, though, that the intent of what is copied above from a previous 
e-mail message does depend on what one wants to mean by 'model.'

So let's derive the meaning of 'model' from what is said.  Here we have two 
different kinds of model elements that we do not want to mix in the same 
model.  So these two kinds of model elements should be used in different 
models.  We can presume that these will be different models of the same 
system.

So we now know that one can have several different models of the same 
system.  That our modeling language has both classes and object.  And that 
we should not mix objects and classes in the same model of a system.

It may help, if we say the same thing using a different language.  IEEE Std 
1471 defines 'view.'

"3.9 view: A representation of a whole system from the perspective of a 
related set of concerns."

Using this word we can write:  So we now know that one can have several 
different views of the same system.  There are two different kinds of model 
elements that we do not want to mix in the same view.

IEEE 1471 goes on to explain:  "Architectural descriptions are the subject 
of this recommended practice.  In the conceptual framework of this 
recommended practice, an architectural description is organized into one or 
more constituents called (architectural) views."

Now, as a software architect, i must be able somehow to specify the 
structure of the system.  By 'structure' i mean: "the aggregate of elements 
of an entity in their relationships to each other."  [Merriam-Webster]

Example:  The primary clearing system shall be at Two Wall Street.  The 
secondary system shall be at the Piscataway data center.  They shall be 
connected by two OC12 fibre links, leased from different providers and 
following different routes.  Each system shall have a clearing engine with 
two identical interfaces to the Federal Reserve Bank of New York and one 
interface to the Federal Reserve Bank of Atlanta.  Each clearing engine 
shall use the services provided by matching engines to match receives with 
delivers.  All trade data shall be replicated in each matching engine.  At 
Two Wall Street there shall be three matching engines, two operational and 
one standby.  There shall be two standby matching engines in 
Piscataway.  Each matching engine shall be placed on a separate dedicated 
node.  No other application objects shall be placed on these nodes.  ...

In order to express this example, i must use objects.  It is simply 
impossible to express this using classes.  (Or just silly and 
self-defeating: using singleton classes.)  But, of course, i want to use 
classes to specify the matching engines, since there are five identical 
matching engines.

We know, from the previous e-mail message, that we don't want the matching 
engine objects and the matching engine class to be in the same view.  We 
can live with that, since we can put them in the same architectural 
description.

OK?

So, when 3C insists that UML users must be able to have both objects and 
classes in the same modeling language and in the same model, this can be 
understood by saying we are using 'model' incorrectly.  That's fine.

To say this correctly, in IEEE 1471 terms: 3C insists that UML users must 
be able to have both objects and classes in the same modeling language and 
in the same architectural description.  (But, if others insist, we can 
accept that both objects and classes should not appear in the same view.)

In order to translate this perfectly reasonable and absolutely correct 
statement back into the language used by the previous e-mail message, we 
will replace 'view' by 'model.'

My question:  What is the correct term to use to replace 'architectural 
description?

To say this correctly, in 2U terms:  3C insists that UML users must be able 
to have both objects and classes in the same modeling language and in the 
same < what? >.

What is the 2U name for the item that is a complete specification of the 
system, written in the modeling language, and composed of models?

Date view Thread view Subject view Author view Attachment view