From: Joaquin Miller (firstname.lastname@example.org)
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?