Subject: Re: Programs and Models

Message 3/323 From Sandy Tyndale-Biscoe Jan 31, 04 05:49:41 PM +0000

X-Sender: s.tyndalebiscoe@mail.btinternet.com

To: Joaquin Miller <joaquin.no.spam@acm.org>, A&D TF <adtf@omg.org>

RJLRef: $PH/uml2mda/ProgramsVsModels040201.htm

Joaquin's suggestion is good, but I have an alternative suggestion which just happens to be a topic up for discussion in next week's meeting (at the OMG meeting) of the ISO SC7 WG19, the group that is developing the new ISO standard for using UML to represent RM-ODP viewpoint specifications.

This may take some explanation but I'll try to be as brief as possible. Here's the problem:

RM-ODP offers a set of "languages" that correspond to the 5 ODP viewpoints. An <x> viewpoint specification of a system is a model of that system using the <x> viewpoint language, i.e. it is a coherent

set of instances of the <x> language concepts, each of which "models" something in the real world being modelled (the Universe of Discourse, UOD). (I'm being loose here, please try and avoid the temptation to mention that we don't define "something" nor do we mention, what is undoubtedly true, that "something" includes relationships between things in the UOD)

The purpose of the new standard (ISO 19793) is to define a way of using UML to "express" such an ODP (viewpoint specific) model, in a way that is not inconsistent with the intrinsic semantics of UML.

Our problem relating to the tread that Ed has started is that we need to distinguish between the following relationships, and to filter out those that don't interest us:

a. the relationship between the ODP specification and the things in the UOD being modeled

b. the relationship between the UML model and the ODP specification

c. the relationship between the UML model and the things in the UOD being modelled

d. the relationship between the UML notation (the various UML diagrams) and the UML model

e. the relationship between the UML notation and the ODP specification.

for all of the above it could be truthfully said that the A "represents" the B, so we (or at least some of us) are proposing not to use that word at all, as it is too loose.

One word we do have that we can be sure about is "model". Since Part 2 of RM-ODP says that an object is a model of an entity (where an entity is any concrete or abstract thing of interest in the UOD), we can be pretty sure of the meaning of "model", and that is what relationship a above is.

A current proposal that we use the words "maps to (through a profile)" for relationship b above, and "expresses" for relationships d and e above. Relationship c we ignore (thus we do not say "this class models Fred", we say "this class maps to the enterprise object that models Fred, or "this box expresses the enterprise object that models Fred", which could be shortened to "this box expresses the enterprise object Fred").

That proposal may well be modified at next meeting, and it may be of no interest to anyone following this thread, but I think it germane to Ed's and Joaquin's comments.

Message 1/36 From Joaquin Miller Jan 30, 04 02:21:56 PM -0800

Subject: Re: Programs and Models

Ed's message is an excellent contribution (for those of us who read this

thread: apologies to those who have to skip each one).

I'd like to start from it and try to move forward a little bit.

Ed Barkmeyer wrote:

>Unfortunately, I have yet to discover an appropriate English verb to make the critical distinction here:

> diagram "represents1" model, and

> model "represents2" world/problem/solution

>To me, "represents1" and "represents2" are *different* relationships:

Yes. They certainly are.

>"represents1" is the sign-to-thing relationship ("reference")

>"represents2" is the abstraction-to-thing relationship (view? generalization?)

represents2

---------------

I feel that the ordinary meaning of 'represents' is represents2.

But I don't feel that it is best to think of this as abstraction-to-thing relationship. And certainly not a view or generalization. I suggest we think of it as simply the model-to-thing relationship. Which is the modeling relationship. The roles in this relationship are model and thing represented. This is a fundamental relationship. It is the essence of modeling. To attempt to recast it in other terms won't help, instead will hinder understanding.

I strongly recommend that we let those who want to know what a model is in our business watch us and see how we behave when the word, 'model' is used. (Not my original idea, as you all know. This is a practical approach to language, eighty years old at the very least, perhaps thousands of years or tens of thousands. And is how we learn language when we are tiny.)

represents1

---------------

I'll quibble with Ed about 'represents1.' I believe i understand how he sees this as an example of the sign-to-thing relationship, but is is more particular than that. It is the relationship of 'dog' to the idea of dog

and also the relationship of 'Hund' and 'perro' to the idea of dog. That is different from the relationship of the idea of dog to a particular dog, and different from the relationship of the idea of dog to all the dogs.

I feel it is valuable to distinguish constructs (ideas, concepts) from things.

(And, by the way, a diagram is definitely a thing. On the other hand, the model Ed mentions could be (i feel should be) counted as not a thing, but a construct.)

If we agree with Ed that a diagram (or an XMI text) is what theorists call 'a sign,' then, for represents1 i suggest we use 'signifies.' That's what signs do.

.......

represents1: a diagram element and a diagram signify a model.

represents2: model element and a model represent some thing.

Cordially, Joaquin

Message 2/36 From Ed Barkmeyer Jan 30, 04 12:07:01 PM -0500

To: Bob Lechner <lechner@cs.uml.edu>

CC: adtf@omg.org

Subject: Re: Programs and Models

All,

I have a big problem with Bob Lechner's classification, at least based on his proposed definitions:

> Therefore, I would nominate program [artifact] (a hybrid mix

> of declarative=non-executable and procedural=executable

> program components), and diagram [artifact] (a hybrid mix of

> 1D-text labels and 2D-geometry) as major subclasses of model [artifact].

I don't have a problem with this definition of program, and I don't want to carp about the definition of "diagram". But in my view, making "diagram" a subclass of "model" commits a common linguistic/semiotic fault: it confuses the "sign" with the thing it signifies. "Diagram" is NOT a *subtype* of "model". The relationship between diagram and model is "represents", not "is a".

The model itself is the underlying concepts (things, properties, relationships, categories) -- the population of the MOF metamodel, if you like. The "hybrid mix of labels and geometry" are the (unorganized) syntactic elements of *one possible* representation of a model -- the diagram.

Put another way, the analogous definition of "program" would be "a sequence of categorized signs, each sign [token] being formed of written characters according to lexical rules for the category." The *interpretation* of that sequence of signs is the mix of declarative and procedural program components, i.e. the program as a model of computational objects and actions performed on them.

In a similar way, the *interpretation* of the labels and geometric elements that are the signs in a diagram is the concepts and relationships in the model.

To be fair, I think UML v1 supported this confusion of the sign and the signified in many ways, but UML v2 has almost entirely avoided that pitfall.

Unfortunately, I have yet to discover an appropriate English verb to make the critical distinction here:

diagram "represents1" model, and model "represents2" world/problem/solution.

To me, "represents1" and "represents2" are *different* relationships:

"represents1" is the sign-to-thing relationship ("reference")

"represents2" is the abstraction-to-thing relationship (view? generalization?)

But this is also why I think Steve Mellor's distinction between "linear" and "multi-faceted" languages is about syntax. That distinction seems to me to be in the subtypes of "represents1" -- how the model appears -- versus any distinction in the content of the model or in "represents2".

-Ed

J. Barkmeyer Email: edbark@nist.gov

Subject: Re: Programs and Models

To: edbark@nist.gov

Date: Tue, 27 Jan 2004 18:24:02 -0500 (EST)

Cc: adtf@omg.org, lechner@cs.uml.edu (Bob Lechner), steve@projtech.com

I fully agree with Ed.

I tried to think of the minimal UML 'class' model alone (more generally, a static information model) that is executable in the absence of 'any' dynamic behavioral specs. I nominate relational database conversion for this honor:

Suppose two [versions or views of a] subschema are declared and 'stereotyped' as comprising an input view, an output views, with additional tables that associate matching attributes and relations. Then the code to transform any conforming input data set to the corresponding output format may be auto-generatable without dynamic behavioral specs. This fails for more complex conversions, for which additional OCL constraints are needed to declare the post-conditions on more complex transformations that are not simple 1:1 correspondences of tuple instances and attributes.

This tri-part schema is a proper subset of the static UML class models

(even after merging association and entity subtypes of Classifier? :-).

Is it an executable model by itself?

Is there a continuum of progressively more complex OCL constraints

that augment it to expand its 'executability'?

Are more sophisticated transaction models within the scope of OCL?

Does OCL always have a generic code-derivation capabiity

as well as a verification-checking role?

Or is there an end to OCL's power, beyond which procedural

definitions (algorithms) must be customized for the application?

Bob Lechner

lechner@cs.uml.edu

CS Dept UMass Lowell

----------------------------------------------------------------------------------------------

Message 7/36 From Ed Barkmeyer Jan 27, 04 02:15:48 PM -0500

Organization: NIST

To: "Stephen J. Mellor" <steve@projtech.com>

CC: adtf@omg.org

Subject: Re: Programs and Models

Steve says:

> If it doesn't execute, I'm not interested. That answers

> the remainder of your questions :)

Actually, taking Conrad's contribution into account, it doesn't. Conrad says all models are executable; some just place more limits on conforming execution-occurrences than do others.

But Conrad's observation fails to consider a critical aspect of a model -- its purpose. A model that is not intended to specify "execution" -- i.e. an activity, a behavior -- is not an "executable model".

What Steve is saying is that he is only interested in models *intended* to specify "execution", and following Oliver's reasoning, execution by an "automaton" (without human intervention), although Steve never quite said that.

Once we agree we are talking about models whose purpose is to describe activities that are to be performed by automata, then Conrad is right -- all of *those* models are "executable". The remaining question is: How well do you want to specify the result state? Or how narrowly do you want to specify the actions of the automaton (or equivalently, the allowable snapshot states)? Can one state a well-defined criterion for separating "programs" from "other executable models" in those areas? (I really doubt it.)

OTOH, whether the language is "multi-faceted" or "linear" is only about the syntax for stating the constraints on the execution!

Different "initial constraint sets" -- conformance rules for the fundamental behaviors of the automaton -- are assumed by different languages, and they are very important to the nature and degree of the constraints the model can place on execution-occurrences. But it is not clear that there is any relationship between the characteristics of the "executable UML engine" and the fact that UML is "multi-faceted". The "UML engine" is only different in detail from the JVM; it is not at all different in its fundamental concepts.

The "multi-faceted" characteristic of UML is about separating *viewpoints* -- (not necessarily orthogonal, thank you, Bob) sets of concerns that can be addressed together -- each with a syntax convenient to expressing the execution constraints related to those concerns. But in another sense, that is just a matter of *organizing* the execution constraints differently, and that kind of difference also exists between Java and COBOL (and the runtime engines for Java and COBOL are also only different in detail). The executable UML model, the Java model and the COBOL model are all programs.

The same can be said for programs in LISP and Prolog and eXcel -- they differ markedly in the way in which they organize execution constraints. But they all also have *importantly different* execution engines.

I think the issue with the Agilistas is to what extent their means of judging program robustness and reliability is based on assumptions about the execution engine and its relationship to the structure of the programming language. LISP is a problem because its execution engine doesn't have the JVM straight-jacket (LISP is a von Neumann language -- the program can alter itself); executable UML is a problem because its syntax doesn't have the usual (procedural) relationship to the execution engine. Lack of experience prevents most of us from judging at what point the syntactically correct UML "model" is sufficiently detailed in characterizing execution occurrences to produce the desired quality of results, and we do not have that problem with Java "models". But the presumption that an executable UML program is

*intrinsically* less reliable or robust than a Java program is simply false.

-Ed

Message 7/340 From Bob Lechner Jan 29, 04 11:10:27 PM -0500

To: joaquin.no.spam@acm.org

Cc: lechner@cs.uml.edu (Bob Lechner), adtf@omg.org

Joaquin:

I can't understand what point you are making here (not enough context:

-----------------

> " (So we agree ... that the categories, programming language

> and modeling language, are distinct and non-overlapping.)

> ...

> With that agreement, someone could say: "An executing program is indeed a

> model, as is the data in a database." And would be correct.

> This illustrates that there are two different kinds of models."

---------------

Are you saying that an executing program is different from a program in one KIND of model, but no different in another model KIND? Is an 'executing' program an INSTANCE OF an 'executable' program

or are these terms synonymous?

A few examples cannot define a class - of models or otherwise. As Shlaer and Mellor said, a set of rules is needed to recognize membership in a class and exclude non-members. More detailed rules can partition a class into subclasses, and so on to a finer-grained taxonomy.

Personally I doubt if there exists a rigorous taxonomy for UML models. If we had one, we wouldn't

be spending so much time talking around it :-)

My concern is with the model level which assembles components of various types into an instance of

its abstract superclass (i.e., into any one of these component types). This involves the (recursive) composite design pattern, with compound and simple or non-decomposable subclasses.

Simple subclasses (non-decomposable at their aggregate model level) may decompose into parts at the next lower level of modeling. For example, a state model node has an 'atomic' action (executable within its context) at the state model level; When this action definition is parsed, we can view its static parse tree as another type of diagram. (The familiar SSAD structure chart diagram is a behavioral approximation or model abstraction that is derivable from this parse tree.)

Therefore, I would nominate program [artifact] (a hybrid mix of declarative=non-executable and procedural=executable program components), and diagram [artifact] (a hybrid mix of 1D-text labels and 2D-geometry) as major subclasses of model [artifact].

This is an incomplete partition - I can't predict the future. Class, activity, and state models are diagram artifacts. OCL text (with optional side-effects) is a program artifact. Program artifacts (declarative and/or procedural) can be declared, defined or referenced in text labels on a diagram artifact.

-----------------------------------------------------------------------------------------------

> From omg-list-errors@amethyst.omg.org Thu Jan 29 18:33:01 2004

> To: A&D TF <adtf@omg.org>

> From: Joaquin Miller <joaquin.no.spam@acm.org>

> Subject: RE: Programs and Models

> >...

> >'An executing program is indeed a model by this definition, as is the data

> >in a database. You might not like me using the word model in this context,

> >but I very much doubt you can define "model" in a way that excludes it.'

> It's correct that many executing programs are models of something. Not

> only models of airflow or financial markets, but ordinary record-keeping

> systems, which are models of the world they are keeping records about.

> But that is a different matter from the one that Steve started this

> discussion about. We had better distinguish these two topics in this discussion.

> ------------ an illustration ----------------

> To illustrate my point, let's suppose that we were all to agree that for

> one week we would assume in these discussions, just to see where it lead

> us, that the categories, program and model, were distinct, that no program

> is a model and no model is a program. We agree that by 'program' we mean

> an item in a programming or machine language and by 'model' we mean an item

> in a modeling language. (So we agree, for the purposes of the one week of

> discussion that the categories, programing language and modelling language,

> are distinct and non-overlapping.)

> With that agreement, someone could say: "An executing program is indeed a

> model, as is the data in a database." And would be correct.

> This illustrates that there are two different kinds of models.

> In our discussion for a week with that agreement, the response would and

> should be: "Well, sure. But remember, that is not what we are talking

> about when we use 'model' in this discussion."

> ---------- end of illustration -----------------

> Steve asked a question about what to call certain kinds of models. This

> lead to a discussion about how to use the terms, 'program' and 'model.'

> The discussion is about a particular kind of model.

> UML models are an example of the kind of models we are discussing.

> Children's clay models, dentist's study models, sculpture foundries plaster

> models, meteorologist's weather models, trader's market models,

> accountant's financial models, the model of the finances of the business

> kept in the accounting system, the model of the user's preferences kept in

> the application, ... none of these are examples of the kind of models we are discussing.

> ................................................

> The text quoted at the head of this message is correct, interesting in it's

> own right, perhaps even illuminating in this discussion. But it is

> counterproductive when it is not explicit that this is a different usage of 'model.'

> It may be that we can't define 'model' in a way that excludes this meaning

> (and certainly we don't want to do that, that's a good and ordinary

> meaning), but in this discussion we had best stick to the meaning of

> 'model' that this discussion is about.

> Cordially,

> Joaquin

Message 15/36 From Conrad Bock Jan 24, 04 02:01:16 PM -0500

To: adtf@omg.org

Subject: RE: Programs and Models

Hi Bob,

> What is most challenging is the need to interleave

> declarative and operational models for each component

> during an iterative design process for a hierarchical system.

Declarative and operational are ends of the execution constraint

spectrum I described in the previous message. A declarative model, like

"Always let an object dry after you paint it" is placing a constraint on

execution as much as a detailed procedure for painting. It's just

looser in the first case. These can be unified under a model that

expresses constraints on runtime execution. See www.nist.gov/psl.

Conrad

-----------------------------------------------------------------------------------------------------

Message 14/36 From Stephen J. Mellor Jan 24, 04 02:24:15 PM -0700

Subject: RE: Programs and Models

Conrad Bock wrote:

| Someone may have said this already, but I don't think there is such a

| thing as a non-executable model. A model may loosely constrain

| execution, but that doesn't make it not executable. It just means a lot

| of execution traces conform to the model. What we normally call a

| "program" places a lot of constraints on execution. The so-called

| "discovery" models, like interactions, place fewer.

OK. So if we say there's a spectrum of "constrained executability" with the pictures your daughter drew in kindergarten at one end, and a program or fully executable model (as per Executable UML) at the other, that still leaves my original question: How do we distinguish by name models expressed in a linear programming language from a model expressed in a multi-faceted language such as Executable UML. They are both models; they are both executable. And the fact that one can be graphical is specious because of HUTN.

[Human-Usable Textual Notation: A specification for a Human-Usable Textual Notation (HUTN) for expressing other specifications in terms of the UML Profile for Enterprise Distributed Computing (EDOC) and its companion UML Profile for CORBA. HUTN offers three main benefits. (1.) It is a generic specification that can provide a concrete HUTN language for any MOF model; (2.) The HUTN languages can be fully automated for both production and parsing; and (3.) The HUTN languages are designed to conform to human-usability criteria. (www.uml.org.cn/omg/modeling_spec_catalog.htm) - RJL040201]

-------------------------------------------------------------------------------------------

Message 13/36 From Stephen J. Mellor Jan 24, 04 03:25:58 PM -0700

Cc: "'John Wolfe'" <johnw@projtech.com>

Subject: RE: Programs and Models

| But I am still waiting for an answer to my original question: why are we

| discussing this? What was the problem that prompted Steve's to start

| this thread? And what is the context in which the problem arose?

The context is this. I am a signatory to the Agile Manifesto, yet the agilistas are generally perceived as being anti-model.

I am writing about "Agile MDA", the idea that you can build an executable model and close the verification gap the agiloids correctly identified. That is, a reconciliation of these two ideas: (executable) Models and Agile.

To do this, I need three words for models-that-are-programs, fully-executable-models that are not in a 3GL, and models-as-blueprints to be filled in by coders. All three are covered by MDA (if we truly believe a program is a model), though the last cannot be agile because it does not execute.

| (a) UML artifact that is non-executable: Model

| (b) UML artifact that is executable: UML Program

| (c) Traditional 3GL/4GL program: Code Program

These are indeed the ones I am trying to name. These names are (as you say) not great. (I am distressed by "UML program" because of the aspect-oriented, er, aspect of Executable UML and the common insistence then that "you have to convince me your language is better than mine" *based on 3GL criteria!*)

But they do at least focus the discussion away from butterflies :)

| I have to say I don't like these names, and also that the taxonomy is

| probably incomplete. But it's now lunch time, and the sun's shining, and

| a brisk walk in some rather pleasant woodland is beckoning, so I'm going

| to duck out here...

Good plan. I think I'll go to Bondi beach!-- steve

| Regards,

| Oliver

| | -----Original Message-----

| | From: BERRISFORD, Graham

| | Sent: 23 January 2004 18:52

| | To: 'oliver.sims@simsassociates.co.uk'; 'Stephen J. Mellor';

| | 'Adtf@Omg. Org'

| | Cc: 'John Wolfe'

| | Subject: RE: Programs and Models

| |

| | Will "executable" do the job you want here if your definition of a program embraces source code?

| | -----Original Message-----

| | From: Oliver Sims [mailto:oliver.sims@simsassociates.co.uk]

| | Sent: 22 January 2004 11:04

| | To: 'Stephen J. Mellor'; 'Adtf@Omg. Org'

| | Cc: 'John Wolfe'

| | Subject: RE: Programs and Models

| | Steve,

| | Why are you posing this question? Not that it's not interesting; it's just that having some idea of the

| | problem that prompted the question would be useful. My immediate reaction is to consider |

| | executability. Assume a program (yes, a model for some run-time instance) that, when

| | compiled, linked, deployed, and loaded, executes

| | successfully - that is, produces an intended result. This

| | requires the existence of some engine that will actually

| | carry out the set of instructions that comprise the program.

| | Of course, and btw, if the engine is an interpreter, then

| | the compile and link is redundant.

| |

| | Such a program, whether written in UML or Java or whatever,

| | could be called an "executable model", or perhaps a

| | "Computationally Complete Model" (but that would make CCM,

| | which acronym is already taken...)

| |

| | Any other model is a non-executable model.

| |

| | If a non-executable model is built in order directly to

| | support further refinement such that an executable model can

| | be developed, then such a non-executable model could be also

| | called an incomplete model. Or a "Computationally-Incomplete

| | Model" (a CIM??? Hmmm...).

| |

| | Hence:

| |

| | Model

| | /\

| | |

| | -------------------------

| | | |

| | Executable Model Non-Executable Model

| |

| | However: I'm not sure that this takes us anywhere.

| |

| | Regards,

| | Oliver

| |

| | | -----Original Message-----

| | | From: Stephen J. Mellor [mailto:steve@projtech.com]

| | | Sent: 21 January 2004 21:53

| | | To: Adtf@Omg. Org

| | | Cc: John Wolfe

| | | Subject: Programs and Models

| | |

| | | All,

| | |

| | | A model (loosely) is an abstraction of some other thing.

| | | Under this loose definition, a program is also a model. I

| | | find that intuitive.

| | |

| | | My purpose here is not to argue the definition of "model"

| | | but to ask a question, namely What do we call a

| | | model-that-is-not-a-program?

| | |

| | | Model

| | | /\

| | | |

| | | -------------------------

| | | | |

| | | Program ????

| | |

| | | Note that "graphical model" would not really do, as HUTN is not

| | | really a program. (IMO, the element that distinguishes a

| | | program from a model-that-is-not-a-program is not graphics,

| | | but the fact that a model-that-is-not-a-program is

| | | multi-faceted, not linear like code. But that's another

| | | rathole I'm not interested in.)

| | |

| | | Alternatively,

| | |

| | | ?????

| | | /\

| | | |

| | | -------------------------

| | | | |

| | | Program Model

| | |

| | | Though I find this a bit weird, especially as it increases the

| | | cognitive dissonance between programs and "models."

| | |

| | | Any ideas would be welcome. Thanks

| | |

| | | -- steve

====================================================

Message 8/340 From Bob Lechner Jan 29, 04 05:38:10 PM -0500

Subject: Re: Programs and Models

To: Graham.BERRISFORD@london.sema.slb.com (BERRISFORD Graham)

Cc: lechner@cs.uml.edu (Bob Lechner), adtf@omg.org

My reply to Graham might seem naive or long-winded for

the ADTF list. However, I welcome comments that 'set me straight'

by clarifying what I admit are gross over-simplifications :-)

> From omg-list-errors@amethyst.omg.org Thu Jan 29 07:45:17 2004

> From: "BERRISFORD, Graham" <Graham.BERRISFORD@london.sema.slb.com>

> Subject: RE: Programs and Models

> To: adtf@omg.org

> I have too little time to digest and contribute except to say that

...

> 2) Noting below "I believe this alternation between declarative and

> operational specifications (or non-executable and executable models)"

> Is this confusing declarative with non-executable and operational

> (procedural?) with executable?.

I don't believe it is confusing - I believe they are pairwise equivalent,

for our intents and purposes.

Consider this definition of algorithm (my own:-) :

rules for the stepwise carrying out of a computation process.

That is what I mean by operational or procedural (or imperative).

Consider this definition of declarative specification (my own;-):

the set of constraints by which output can be checked against

input to verify that the output conforms to its requirements.

A complete declarative spec includes constraints on its behavior

as well as on its interface or method call signature (argument types).

IF a 'declarative specification' is claimed to be 'executable',

(i.e., executed on a real computer), then it must be automatically

transformable into a compiled program or interpretable by

some generic interpreter that runs on some computer.

By no means can a mere correctness-constraint checker be said

to execute such a transformation, any more than C's assert macros

can be said to map inputs into outputs.

Given any input,output pair of data states,

declarative (predicate) expressions can be applied to any I/O PAIR

or any initial, final pair of data states, to assess whether

it conforms to declared requirements (I/O relationship).

But the candidate answer (the actual output for a given input)

must be known a priori and this merely renders a PASS/FAIL verdict.

This is 'executability' ONLY in the 'checking-for-correctness' sense:

Executing OCL assertions can only give PASS/FAIL answers

by referring to both initial (input) and final (output) values

of its referenced variables.

Since we cannot predict the future, some 'operational' procedure

must have been executing in parallel to supply the final values.

It is conceivable (given enough time and space :-) that unification or brute-force enumeration

could search the space of all programs and pick ('generate)' one that satisfies all the constraints for many input-output pairs. Some 'academics' (not me :-) might conclude that because this 'discovered' program satisfies the constraints, the constraints themselves support a 'code-generation' process.

But I cannot conceive this to be a cost-effective way to auto-generate an efficient algorithms for mapping input to output.

Incidentally I believe that an SQL query is executable or procedural because it expresses a query as an expression that interleaves data references with (select, project and join) operator methods.

We trust the query because we are confident that the SQL engine has correctly implementied these operators as algorithmic procedures on well-formed input data.

> I know the declarative/procedural distinction seems immensely important to

> academics - formal proofs of correctness and all that. Most practitioners

No - it is also an important distinction to C programmers:

Most C programmers declare function prototypes in .h interface files

and define the called operations in .c implementation files.

They may also imbed assert macro calls to check correctness conditions.

Interface declarations and assert macros are certainly compilable

but they are executable only as passive constraint checkers.

They cannot produce output data from input data or modify state.

I recommend reserving the term 'executable' program for programs

which transform input data to output data, or modify program 'state'.

(These programs include code generators and constraint checkers :-)

> are likely to see executable OCL as just another programming language (cf.

> SQL?), with its own quirks and foibles.

> Graham

Yes, unfortunately - but OCL has an entirely different purpose than SQL or

any procedural program (including SQL). It makes executable assertions

that reference another program's outputs as well as its inputs.

(AFAIK) They are still incompetent at deriving that other program

(generating its executable code), which is another matter entirely.

Bob Lechner

CS Dept UMass Lowell

lechner@cs.uml.edu

> -----Original Message-----

> From: Bob Lechner [mailto:lechner@cs.uml.edu]

> Sent: 24 January 2004 10:03

> To: adtf@omg.org

> Cc: lechner@cs.uml.edu

> Subject: Re: Programs and Models

> I found the following abstract to be interesting and relevant

> to the current discussion of Programs and Models.

> What is most challenging is the need to interleave declarative and operational models for each component during an iterative design process for a hierarchical system.

> IMO, state models and procedural models are equivalent. A state diagram procedurally decomposes a declarative specification (a set of OCL constraints) for one system component. Before its state actions are defined, this implementation is incomplete as an operational model. To complete the implementation we need to define the action within each state.

> One way to do this is to begin with a declarative specification for each action (i.e., declare its interface PLUS a set of pre- and post-conditions (e.g., OCL constraints on its internal behavior).

> This completes one iteration: one procedural spec to coordinate components plus declarative specs for these components. Now the process of decomposition (or iterative refinement) can begin all over again at the next lower level below this node of the tree.

> I believe this alternation between declarative and operational specifications (or non-executable and executable models) should also be applied at higher levels (use cases, activity and collaboration diagrams) and at lower levels (within procedures) relative to the nodes that are modeled by state diagrams.

> Bob Lechner

> lechner@cs.uml.edu

> www.cs.uml.edu/~lechner>

> ---------------------------------------------------

> Forwarded message:

From seworld-owner@cs.colorado.edu Fri Jan 23 13:15:32 2004

From: Holger Giese <hg@uni-paderborn.de>

To: SEWORLD@ernie.cs.colorado.edu

Subject: (SEWORLD) CFP: Workshop on Scenarios and State Machines at ICSE04

Call for Papers

3rd International Workshop on

Scenarios and State Machines: Models, Algorithms, and Tools (SCESM04)

ICSE Workshop W5S, Edinburgh, May 25th, 2004

http://scesm04.upb.de

Goals and Scope

Scenarios and state machines have emerged as two important modeling perspectives on the reactive behavior of complex systems. Scenarios typically represent a partial view on the interactions between multiple components; state machines typically represent the complete behavior of individual components.

The UML is a prominent example of a modeling language providing both scenario- and state-based description techniques for object- and component behavior. In the telecommunications domain, the ITU standards of MSC (Message Sequence Charts) and SDL (Specification and Description Language) provide a similar distinction between exemplary and complete behavior descriptions. However, the methodological potentials of the combination of partial and complete behavior perspectives have yet to be fully exploited in the development process for complex, reactive systems. Scenarios can form the starting point for synthesis of prototypic state machines, and thus serve as an element in forward engineering. Scenarios and state machines together foster system comprehension when analyzing existing or planned systems.

Scenarios representing traces of system execution help in understanding interacting state machines in a reengineering effort. Both interaction scenarios and state machines can be applied in specifying component interfaces. Simulation tools can use scenarios or animated state machines to make their relationships explicit. To fully unleash their methodological potentials in practice, the relation between scenarios and state machine models needs to be supported by corresponding algorithms and tools. Therefore, automated tool support based on algorithms relating scenarios and state machines for analysis, design, implementation or validation offers great promise for improving the current practice of software engineering.

> [cut]