A "model compiler" is not a single tool, but a characterization of an entire
class of applications.

A model compiler is essentially a program that reads a model and writes
executable code and similar artifacts that realize the model in a target
software architecture.

To do this requires that the models be represented in a form that captures their
semantics.  The content--not the boxes and lines--is what is important.

The model compiler itself, just like a programming language compiler, is
targeted at a particular software architecture.  Some model compilers are
intended for embedded systems, others produce artifacts useful for building
distributed web applications.

As for whether model compilers are "any good," you'll need to define "good."  I
suspect there are many aspects to that question.
- Can a model compiler completely implement a model (does it fully interpret the
semantics of the model)?
- Are the artifacts it produces complete or do they require hand-tweaking? 
(Some of us would argue that anything that generates "//insert code here" is not
a true model compiler.)
- Are the artifacts it produces as good as what can be done by hand-coding?
- Does it enable more rapid, cost-effective, agile/incremental development?

I'm sure that several others in this group will have their ideas as well.  Keep
us posted on what you're doing and don't hesitate to ask questions.

Marc



-- In executableuml@yahoogroups.com, "samirrecife" <samirrecife@...> wrote:
>
> Hi everyone,
>
> I`m a master degree student and I`m at the right begging of my research, so I
still reading more about xUML.
> At the right moment I`m looking for a tool that could help me to understand
some examples of an aplication.
> I heard about a tool called XUML COMPILER, do you know if it is good?
> If you have any tips, i`ll be thankfull!
> Thanks in advance.
>
> Samir Oliveira
>

Hi everyone,

I`m a master degree student and I`m at the right begging of my research, so I
still reading more about xUML.
At the right moment I`m looking for a tool that could help me to understand some
examples of an aplication.
I heard about a tool called XUML COMPILER, do you know if it is good?
If you have any tips, i`ll be thankfull!
Thanks in advance.

Samir Oliveira

On Tue, Oct 13, 2009 at 3:22 PM, mjbalcer <marc@...> wrote:
>
> Recently Leon Starr tweeted:
>
> As much as I try, I just can't avoid using referential attributes. I just
don't know a better way to think about association constraints.
>
> to which I replied
>
> I've abandoned referential attributes entirely by writing identifiers as
"unique" constraints.
>
> and then tried to illustrate the idea in just a few lines of text.
>
> That pushed me to finish a whitepaper I'd been thinking about for some time
now.  I've posted it on my site at Beyond Referential Attributes.
>
> The essential idea is that referential attributes--even in their most
sophisticated uses--are really expressions of constraints and therefore the way
to not use referential attributes is to express those constraints in the models.



In my usage there are essentially two types of referential attributes:

* Those that express "in the context of". A department is unique
within the context of a Company.
    A part number is unique within the context of the manufacturer, etc.
    For these listing the "context" fields feels redundant with the
containment relationship.
    This is especially true if you're not obsessed with thinking
"containment" implies physically
    contiguous storage.
* Those that indicate "this field identifies another object". Leaving
these attributes out has
    always bothered me, because the object has that information whether
or not there is
    a relationship with another class.

Using the 'constraint' approach you describe strikes me as being very
natural for the latter
case, but just as unnatural as referential attributes. "Is defined in
the context of" is a concept
that is very clear to the various non-UML audiences you present ideas
to, it would be nice if
it could be presented with the same ease within UML.

A "constraint" is accurate, and complete, but it makes your audience
think harder than
is really needed. Constraints can represent very complex requirements,
defining scopes
are a much simpler concept that should have a simpler presentation.

As much as I try, I just can't avoid using referential attributes. I just don't know a better way to think about association constraints. 

I've abandoned referential attributes entirely by writing identifiers as "unique" constraints.

--- In executableuml@yahoogroups.com, Ashley at Metamaxim <ashley.mcneile@...>
wrote:
>
> The uncertainty about behavioural conformance stems from uncertainty
> about the semantic relationship between the child and the parent. It
> could be that:
>
>    1. The child is a sub-type and should be substitutable. This means
>       that the child must support at least every behaviour of the parent.
>    2. The child is a specialization of the parent and may, as a result,
>       have set of behaviours that is not as wide (general) as the parent.
>    3. The child is a something that re-uses (by inheritance) behavioural
>       definitions in the parent but is not required to have any
>       particular formal behavioural conformance with its parent.
>
Executable UML doesn't have this uncertainty at the model level. Inheritance is
an implementation mechanism. (See the gray text in section 6.5.1.) This renders
the terms, child and parent, specious in an Executable UML discussion.
The following definitions from the book might help clarify things:

superclass - is a class that generalizes classes in a
generalization-specialization hierarchy.

subclass - is a class that specializes classes in a
generalization-specialization hierarchy.

leaf subclass - is a subclass that is not the superclass of any other class.

object - an instance of a class, or an instance of several classes in a
generalization-specialization hierarchy.

When we refer to behavior, we are referring to the behavior of objects. The
recommendation in the book is to put state machines only in the subclasses when
behavior is specialized. I'm not sure what the full basis is for this
recommendation. My experience suggests that it is due to lack of tool support
for a state model split across multiple classes in a
generalization-specialization hierarchy, and a lesser incidence of need.

On Thu, Jun 11, 2009 at 5:27 AM, Shunaila Amin<shunail_libra@...> wrote:
>
>
> how can i implement action sementics at State machine???
>

Together the State Machine and action semantics are the source code
for the Class.
The action semantics give the detailed actions taken, and the state machine
sequences them.

The two complement each other. There are some corner cases where it is not clear
whether a given behavior is best modeled in actions or by the state
machine itself.
But that is the exception, because generally the two complement each
other very well.

Hi Lee and Shunaila

  > I am unfamiliar with the "base" and "delta" terms applied to state
machines, but a internet search indicates that
  > a base state machine belongs to the general (super) class in a
generalization relationship and (I'm assuming) a
  > delta state machine belongs to a more specialized (sub) class in the
generalization relationship.

As someone who has done a fair amount of research into the question of
state machine refinement (how you alter the state machine of a
super-class to create a valid sub-class state machine) I would say the
following:

     * Quite a lot of academic research has been done on this question (I
       list some below) but without reaching any conclusion or consensus
     * The failure of consensus is mainly a result of uncertainty about
       what kind of "behavioural conformance" there should be between the
       child and its parent.

The uncertainty about behavioural conformance stems from uncertainty
about the semantic relationship between the child and the parent. It
could be that:

    1. The child is a sub-type and should be substitutable. This means
       that the child must support at least every behaviour of the parent.
    2. The child is a specialization of the parent and may, as a result,
       have set of behaviours that is not as wide (general) as the parent.
    3. The child is a something that re-uses (by inheritance) behavioural
       definitions in the parent but is not required to have any
       particular formal behavioural conformance with its parent.

In my view this area is a mess, and my advice is to forget about it
unless you are a serious academic.

Rgds
Ashley

Here are some references (this is a small subset of the total
publications on this topic):

[HAR99] D. Harel and O. Kupferman, /On the Inheritance of Statebased
Object Behaviour/, Technical Report MCS99-12, The Weizmann Institute of
Science, Israel, 1999.

[SCH00] M. Schreft and M. Stumptner, /On the Design of Behavior
Consistent Specializations of Object Life Cycles in OBD and UML/,
published in Advances in Object-Oriented Data Modeling, The MIT Press, 2000.

[EBE94] J. Ebert and G. Engels, /Dynamic Models and Behavioural Views/,
International Symposium on Object-Oriented Methodologies and Systems,
LNCS 858, Springer-Verlag, 1994.

[COO94] S. Cook and J. Daniels, /Designing Object Systems/ /–
Object-Oriented Modelling with Syntropy/, Prentice Hall International, 1994.

[SIM02] A. Simons, M. Stannett, K. Bogdanov and W. Holcombe, /Plug And
Play Safely: Rules For Behavioural Compatibility/, Proc. 6th IASTED Int.
Conf. Software Engineering and Applications, (Cambridge MA: IASTED, 2002).


Lee Riemenschneider wrote:
>
>
> --- In executableuml@yahoogroups.com
> <mailto:executableuml%40yahoogroups.com>, Shunaila Amin
> <shunail_libra@...> wrote:
> >
> > Can any body explain what is the concept of action sementics in uml
> and how we can compair the base state machine and delta state machine
> and how we can apply unl action sementics at any state machine.
> >
> The action semantics define execution behavior for some UML elements.
> Action semantics were a required addition to the UML specification in
> order to support execution. The action semantics are not a language,
> so an "action language" is needed to build executable models.
> I am unfamiliar with the "base" and "delta" terms applied to state
> machines, but a internet search indicates that a base state machine
> belongs to the general (super) class in a generalization relationship
> and (I'm assuming) a delta state machine belongs to a more specialized
> (sub) class in the generalization relationship.
> The search also seemed to only find the usage of "base" in cases where
> one wanted to create a new subclass that inherited (copied) and
> extended the behavior of the superclass.
> An Executable UML generalization relationship is always tagged with
> {disjoint, complete}. The usual handling of state machines in a
> generalization hierarchy is to put them in the final leaf subclasses.
> In terms of this discussion, this would mean that each final subclass
> would have the "base" state machine plus it's own behavioral
> extensions. The only comparison in this case would be to ensure that
> the base state machine was correctly represented in each of the
> subclasses. This is alleviated through the use of polymorphic events
> (which in my view are completely unnecessary in Executable UML).
> Another usage described by Shlaer and Mellor in the Object Lifecycles
> book was to have a partial state machine (base) in the superclass with
> the rest being made complete within each branch of the generalization
> hierarchy. In this case there would need to be no compare.
>
>

--- In executableuml@yahoogroups.com, Shunaila Amin <shunail_libra@...> wrote:
>
> Can any body explain what is the concept of action sementics in uml and how we
can compair the base state machine and delta state machine and how we can apply
unl action sementics at any state machine.
>
The action semantics define execution behavior for some UML elements. Action
semantics were a required addition to the UML specification in order to support
execution. The action semantics are not a language, so an "action language" is
needed to build executable models.
     I am unfamiliar with the "base" and "delta" terms applied to state machines,
but a internet search indicates that a base state machine belongs to the general
(super) class in a generalization relationship and (I'm assuming) a delta state
machine belongs to a more specialized (sub) class in the generalization
relationship.
     The search also seemed to only find the usage of "base" in cases where one
wanted to create a new subclass that inherited (copied) and extended the
behavior of the superclass.
     An Executable UML generalization relationship is always tagged with
{disjoint, complete}. The usual handling of state machines in a generalization
hierarchy is to put them in the final leaf subclasses. In terms of this
discussion, this would mean that each final subclass would have the "base" state
machine plus it's own behavioral extensions. The only comparison in this case
would be to ensure that the base state machine was correctly represented in each
of the subclasses. This is alleviated through the use of polymorphic events
(which in my view are completely unnecessary in Executable UML).
     Another usage described by Shlaer and Mellor in the Object Lifecycles book
was to have a partial state machine (base) in the superclass with the rest being
made complete within each branch of the generalization hierarchy. In this case
there would need to be no compare.

--- In executableuml@yahoogroups.com, "AKHTAR ALI JALBANI" <akjalbani@...>
wrote:
> Can any body explain what is difference between executable UML model and
normal UML model.
>
> I havent yet read the book, I want to know its basic defination and basic
difference.
>
From the book, "Executable UML is a single language in the UML family, designed
for a single purpose: to define the semantics of subject matters precisely.
Executable UML is a particular usage, or profile, the formal manner in which we
specify a set of rules for how particular elements in UML fit together for a
particular purpose.
This book, then, describes a profile of UML for execution."

In the Preface FAQ, the book also states, "Be prepared to unlearn some UML and
habits of mind required to model software structure, but not required to specify
an executable model."

Another good statement from a different book, Model Driven Architecture with
Executable UML by Raistrick, Francis, Wright, Carter, and Wilkie, reads, "This
is not just another Unified Modeling Language (UML) book. It is not about
drawing pictures of your code. It is about realizing value from your
intellectual assets."

C A L L   F O R   P A P E R S
                        =============================
              The 9th OOPSLA Workshop on Domain-Specific Modeling

                              October 25-26, 2009
                             Orlando, Florida, USA
                    http://www.dsmforum.org/events/DSM09

--------------------------------------------------------------------
Call for Papers:

An upward shift in abstraction leads to a corresponding increase in
productivity. In the past this has occurred when programming
languages have evolved towards a higher level of abstraction. Today,
domain-specific languages provide a viable solution for continuing
to raise the level of abstraction beyond coding, making development
faster and easier.

In Domain-Specific Modeling (DSM), the models are constructed using
concepts that represent things in the application domain, not
concepts of a given programming language. The modeling language
follows the domain abstractions and semantics, allowing developers to
perceive themselves as working directly with domain concepts.
Together with frameworks and platforms, DSM can automate a large
portion of software production.

The goals of this year's workshop are to focus on sharing experiences
and demonstrating the DSM solutions that have been developed by both
researchers and practitioners. Some of the issues that we would like
to see addressed in this workshop are:
- Industry/academic experience reports describing success/failure in
   implementing and using domain-specific languages/tools
- Approaches to identify constructs for domain-specific languages
- Tools for supporting domain-specific modeling
- Approaches to implement metamodel-based modeling languages
- Novel approaches for code generation from domain-specific models
- Issues of support/maintenance for systems built with DSMs
- Evolution of languages in accordance with domain
- Metamodeling frameworks and languages
- Demonstrations of working DSM solutions (languages, generators,
   frameworks, tools)
- Specific domains where this technology can be most productive in
   the future (e.g., DSMs to describe aspects of embedded systems,
   product families, systems with multiple implementation platforms)
- Separation of concerns and the application of new modularity
   technologies (e.g., aspect-oriented) to domain-specific languages

---------------------------------------------------------------------
Important Dates:

Initial submission:   August 10
Author Notification:  1 week prior to Early Registration deadline
Final version:        October 5
Workshop:             October 25-26

---------------------------------------------------------------------
Submission Information

The workshop welcomes four types of submissions:

1) Full papers describing ideas on either a practical or theoretical
level. Full papers should emphasize what is new and significant
about the chosen approach and compare it to other research work in
the field.

2) Experience reports on applying DSM. Papers should describe case
studies and experience reports on the application, successes or
shortcomings of DSM. The experiences can be related for example on
language creation or use, tooling or organizational issues.

3) Position papers describing work in progress or an author's
position regarding current DSM practice.

4) DSM demonstrations describing a particular language, generator,
or tool for a particular domain. During the workshop, the DSM
solution presented in the paper can be demonstrated to the
participants.

Papers should be submitted by August 10, 2009. Please see the
submission details at the workshop webpage at:
http://www.dsmforum.org/events/DSM09. The accepted papers will be
published in the printed proceedings and posted on the workshop web
site.

--------------------------------------------------------------------
Additional Information:

Additional information about the workshop (including contact
information, past workshop papers, presentations, group work results)
is available at the workshop web site:
http://www.dsmforum.org/events/DSM09

--------------------------------------------------------------------
Program committee

Pierre America, Philips
Robert Baillargeon, Panasonic Automotive Systems, USA
Krishnakumar Balasubramanian, Mathworks
Peter Bell, SystemsForge
Jorn Bettin, Sofismo
Philip T. Cox, Dalhousie University
Krzysztof Czarnecki, University of Waterloo
Brandon Eames, Utah State University
Robert France, Colorado State University
Ethan Jackson, Microsoft
Frederic Jouault, University of Nantes
Jürgen Jung, Deutsche Post
Steven Kelly, MetaCase
Guenther Lenz, Microsoft
Shih-Hsi Liu, California State University, Fresno
Kalle Lyytinen, Case Western Reserve University
Juha Pärssinen, VTT
Arturo Sanchez, University of North Florida
Jun Suzuki, University of Massachusetts, Boston
Markus Völter, independent consultant
Jos Warmer, Ordina
Jing Zhang, Motorola Research

---------------------------------------------------------------------
Organizing committee

Juha-Pekka Tolvanen, MetaCase
Jeff Gray, University of Alabama at Birmingham
Matti Rossi, Helsinki School of Economics
Jonathan Sprinkle, University of Arizona

The main difference between xUML and UML is that the former is an
object-oriented, systems analysis method that has precisely defined semantics
for all the modelling constructs that it makes use of, while the latter is
really just a notation with rather loosely-defined semantics.  There are these
things in vanilla UML that go by the rather quaint name of "semantic variation
points" which is really just another way of saying "we couldn't decide so we
left it up to the developers to solve (or not) the problem of coming up with a
consistent set of semantics"; note that this is marketed under the rubric of
"flexibility".  Executable UML, on the other hand, does make up its mind about
what everything means, which is why it is sometimes ascribed the status of being
a UML profile.

An xUML model IS a UML model, but, because of its rather parsimonious use of
modelling elements, may seem at first sight to be stripped of many of the pretty
doodlings that are more likely to adorn a typical UML model.  For example in a
class diagram, such things as aggregation and containment are not used because
they are redundant, being completely expressed by the less phallic notation of
the ordinary many-to-one (unconditional) relationship, i.e., a function.  State
machines, though they are also expressed as Harel statecharts, only ever have
one level in the hierarchy.  This way they conform much more closely to the
semantics of finite automata.

These are just a few of the differences.  Reading the book will illuminate many
more.

Hi,


Can any body explain what is difference between executable UML model and normal
UML model.

I havent yet read the book, I want to know its basic defination and basic
difference.


Regards,
Akhtar

Hi,

Please help me to find materials related to uml certificattion

Hi Lee

  > Maybe proof was a bad word to use. What I am trying to understand is
  > where Executable UML is perceived to fail outside of the embedded
  > area. (I am targeting the method and not tool support.)

I think if the workshop can achieve a clearer understanding of this,
that would be a good result.

Rgds
Ashley

--- In executableuml@yahoogroups.com, "Srinivas Nedunuri"
<nedunuri@...> wrote:
>
> You have to deal with transactions, bandwith limitations, server
> capacity, memory capacity, communications delays, distribution and
> clustering requirements, fault-tolerance, etc. In fact the problem
> really becomes one of efficiently searching a large search space.

A lot of these issues sound like they would reside in a service domain
rather than the architecture domain, and therefore they aren't the
concern of an Executable UML model compiler.

It sounds like such a compiler, as you described, would be compiling a
domain specific language.

--- In executableuml@yahoogroups.com, "Lee Riemenschneider"
<lwriemen@...> wrote:
>
> --- In executableuml@yahoogroups.com, "Srinivas Nedunuri"
> <nedunuri@> wrote:
> >
> > A further comment. The biggest problem as I understand it is
> > generating production-quality optimized platform-specific code. Even
> > if there are some tools out there that do indeed do wide-spectrum MDA,
> > their techniques are buried inside proprietary code, which means they
> > are not open to examination and widespread understanding. From
> > academia's point of view (this is primarly an academia-driven
> > workshop) this is a no-no. For me a good sign will be when we see a
> > "Dragon book"-like Principles of MDA Compiler Design on the shelves.
> >
> I'm not sure what is an intended definition for "wide-spectrum MDA",
> but since is the Executable UML group, I'll restrict my remarks to
> Executable UML.
>    The Executable UML semantics are pretty clearly defined. A number
> of people have built model compilers without needing access to
> proprietary tool code. It's my understanding that the "Dragon book" is
> as applicable to Executable UML model compilers as it is to 3GL model
> compilers.
>
By wide-spectrum, I was referring to MDA tools that aren't restricted
to specific domains, such as embedded or web services.

I'll give you that you could probably use many of the front-end
parsing and dataflow analysis ideas from the Dragon Book for
translating a UML+AS model, that is only a small (and shrinking) part
of what goes into a good compiler. The real value added is in the
platform specific code generation. Generating quality code for (say)
an app server is a more complex task than for an x86 instruction set.
You have to deal with transactions, bandwith limitations, server
capacity, memory capacity, communications delays, distribution and
clustering requirements, fault-tolerance, etc. In fact the problem
really becomes one of efficiently searching a large search space.
IMHO, an MDA dragon book would have to cover at least some of these
issues.

As I said before, I'm not denying that there's quality tools out there
that have solved some of these problems but (for obvious competitive
advantages) their solutions are not open to examination, and its
likely (though not certain) that at least some of the solutions are
ad-hoc, driven by the particular business requirments of the vendor.
Hence the need for academic conferences..

cheers

--- In executableuml@yahoogroups.com, Ashley at Metamaxim
<ashley.mcneile@...> wrote:
>
>  >> I think the latter is true of Executable UML, which seems to have no
>  >> profile outside of the embedded systems area (apart from text book
>  >> examples). Please correct me if I am wrong about this.
>  >>
>  > I've seen this statement many times, but never with any evidence to
>  > back it up. I would be interested in seeing some proof.
>
> I think the proof needs to be that Executable UML *is* applicable to
> other domains, by the publication of case studies of its use. These are
> lacking at present, and without them it is not possible to tell if
> anything is going on!
>
I agree that it would be nice to see some more detailed literature on
Executable UML projects both in and out of the embedded area, but what
is wrong with the online bookstore example? It is certainly not an
embedded application.

Maybe proof was a bad word to use. What I am trying to understand is
where Executable UML is perceived to fail outside of the embedded
area. (I am targeting the method and not tool support.)

Hi Lee

  >>
  >> I think the latter is true of Executable UML, which seems to have no
  >> profile outside of the embedded systems area (apart from text book
  >> examples). Please correct me if I am wrong about this.
  >>
  > I've seen this statement many times, but never with any evidence to
  > back it up. I would be interested in seeing some proof.

I think the proof needs to be that Executable UML *is* applicable to
other domains, by the publication of case studies of its use. These are
lacking at present, and without them it is not possible to tell if
anything is going on!

Rgds
Ashley

--- In executableuml@yahoogroups.com, "Srinivas Nedunuri"
<nedunuri@...> wrote:
>
> A further comment. The biggest problem as I understand it is
> generating production-quality optimized platform-specific code. Even
> if there are some tools out there that do indeed do wide-spectrum MDA,
> their techniques are buried inside proprietary code, which means they
> are not open to examination and widespread understanding. From
> academia's point of view (this is primarly an academia-driven
> workshop) this is a no-no. For me a good sign will be when we see a
> "Dragon book"-like Principles of MDA Compiler Design on the shelves.
>
I'm not sure what is an intended definition for "wide-spectrum MDA",
but since is the Executable UML group, I'll restrict my remarks to
Executable UML.
    The Executable UML semantics are pretty clearly defined. A number
of people have built model compilers without needing access to
proprietary tool code. It's my understanding that the "Dragon book" is
as applicable to Executable UML model compilers as it is to 3GL model
compilers.

A further comment. The biggest problem as I understand it is
generating production-quality optimized platform-specific code. Even
if there are some tools out there that do indeed do wide-spectrum MDA,
their techniques are buried inside proprietary code, which means they
are not open to examination and widespread understanding. From
academia's point of view (this is primarly an academia-driven
workshop) this is a no-no. For me a good sign will be when we see a
"Dragon book"-like Principles of MDA Compiler Design on the shelves.

cheers

--- In executableuml@yahoogroups.com, Ashley at Metamaxim
<ashley.mcneile@...> wrote:
>
> Hi Lee
>
> The "if they work at all" comment referred to the fact that some
> so-called MDA tools can only generate skeletons and/or only generate
> CRUD behaviour (so cannot handle more complex transactional updates).
>
> The "restricted to specific application areas" refers to the fact that
> some MDA techniques, because of the forms of behavioural modelling
> semantics they use, have less than universal applicability.
>
> I think the latter is true of Executable UML, which seems to have no
> profile outside of the embedded systems area (apart from text book
> examples). Please correct me if I am wrong about this.
>
> There was no intent to insult anyone, except perhaps those who believe
> that the MDA vision has actually been realised, in a consistent way,
> across the spectrum domains that it professes to address.
>
> Perhaps you would like to submit a paper? You would be welcome!
>
> I hope you decided to laugh rather than cry.
>
> Rgds
> Ashley
>
>
>
> Lee Riemenschneider wrote:
> >
> > I wasn't sure whether I should laugh or cry when reading the text of
> > this posting. This really makes one realize why Pascal and Date felt
> > compelled to create the Database Debunkings web site.
> >
> > > Call for Papers
> > >
> > > *The First Workshop on Behavioural Modelling in Model-Driven
> > > Architecture (BM-MDA) http://www.ou.nl/bm-mda
<http://www.ou.nl/bm-mda>
> > > University of Twente, Enschede, The Netherlands. 23 June 2009*
> > >
> >
> > Consider the following:
> >
> > > To date, the fully automatic generation of the code from models is
> > still
> > > a dream and, if it works at all, restricted to specific application
> > > areas. One of the main obstacles is the lack of adequate models
for the
> > > behaviour of the software and of mechanisms to integrate behaviour
> > > models with structural models and with other behaviour models.
> >
> > This is an insult to practitioners of Executable UML. We've had
> > application area independent "fully automatic generation of the code
> > from models" for well over a decade. The Executable UML method clearly
> > defines integration of behavioral and structural models.
> >
> > > There are different approaches for modelling behaviour in the UML:
> > >
> > > * Use UML Behavioural State Machines ("Executable UML"), which have
> > > semantics that borrow largely from work in real-time systems.
> > [SNIP]
> > > Although there are many different approaches for modelling
> > behaviour, none of them enjoys the same universality as the UML class
> > diagrams do for the structural parts of the software.
> > >
> >
> > I find this to be a contradiction per my statements above. The only
> > way it isn't is if the reference, "("Executable UML")", actually
> > refers to "executable UML". I like to make the E vs. e distinction
> > rather than using the phrase, "Executable and Translatable UML",
> > because I failed to find any usage of the term, "Executable UML",
> > before the Shlaer-Mellor people started using it. IIRC, the Mellor and
> > Balcer book also preceded any alternative usage of the term.
> >
> > > Further evidence of confusion about PIM level behavioural modelling
> >
> > It's not hard to find evidence of confusion on almost any subject
> > pertaining to software development. Pretty much all of it can be
> > traced to ignorance, and a lot of the ignorance is due to
> > unwillingness to learn. This isn't endemic to software developers, and
> > seems to be a societal issue.
> >
> >
>

--- In executableuml@yahoogroups.com, Ashley at Metamaxim
<ashley.mcneile@...> wrote:
>
> I think the latter is true of Executable UML, which seems to have no
> profile outside of the embedded systems area (apart from text book
> examples). Please correct me if I am wrong about this.
>
I've seen this statement many times, but never with any evidence to
back it up. I would be interested in seeing some proof.