RE: Status of UML 2.0



Date view Thread view Subject view Author view Attachment view

From: Kinika Tasie-Amadi (kinika@yahoo.com)
Date: Sat 26 Oct 2002 - 23:59:29 BST


Hello Robert

Part of the UML includes describing system behaviour
in terms of use cases. Now, assume that a use case is
specified by a UML state machine (or UML statechart),
of which there are a number of (proposed) formal
semantics. Then, a specification of the behaviour of a
use case can be precise. This would still allow a
developer to use concurrent states to define a
partial-ordering of interactions and messages
(possibly to avoid over-constraining the system). The
resulting state machine will nevertheless, be a formal
model with well-defined unambiguous behaviour.

If the semantics of UML state machines are as formal
as other state machine (or statechart) formalisms,
then elements described by UML state machines (such as
use cases and objects) can also be described formally,
so that UML can describe unambiguous behaviour.

Kinika




 --- "Bauer, Robert" <rbauer@rational.com> wrote: >
Hi,
> 
> Let me address the various responses in this one
> email.  If I forgot
> something, well, sorry.
> 
> The first thing is to understand what it means to
> formal specify a
> programming language.  We specify
> a programming language so that we can understand
> what a program means.  We
> describe that understanding
> by defining how the "state" (I use this in a very
> generic sense to encompass
> not only memory, but
> registers, i/o channels, etc) is modified via the
> "execution" of the
> program.  Irrespective of the
> mechanism of the semantics (e.g., operational,
> axiomatic, denotational),
> determining the meaning of the
> program results in a sort of symbolic execution of
> the program.  As a
> consequence, for specific programs,
> etc., one can determine whether two programs are
> equivalent in the sense
> that their finals states are
> equivalent, though this problem is known to be
> np-complete.
> 
> So, in a very real sense, that the specification
> language is undeciable,
> semi-undeciable, etc., is
> not critical, because we are only interested in
> identifying how various
> constructs in the programming language
> being described modify the state.  Hence, languages
> like Z and HOL are quite
> beneficial.  Yet, I can
> write sentences whose truth value cannot be
> determined in both Z and HOL;
> however and fortunately, these kinds
> of sentences do not show up to describe
> modifications made by constructs in
> a programming language.
> 
> So, if one were to use, say HOL to describe UML, it
> begs an important
> questions - what about UML is being
> described?
> 
> UML is not a programming language nor is it a
> semantic language that
> describes how the constructs of a programming
> language modify the state.  At
> best, UML seems to capture some information about
> the static
> structure of a system and it is able to capture some
> information about the
> dynamic behaviour of the system in terms of objects
> that get created and
> some of the communication among objects.
> 
> So, at least to me, it appears that we understand a
> UML model by the program
> that gets generated from the UML model.  But the UML
> model is not a complete
> specification of that program, since to do that
> would require a complete
> specification of the programming language in which
> that program is generated
> as well a formal specification of the desired
> program (and if we had the
> latter, we wouldn't need the model except as an
> example of "one" implementation of the specifcation
> - we know that in each
> programming language there are a countably finite
> set of programs with
> equivalent semantics).
> 
> Following this chain of reasoning - then UML stands
> as sort of meta-program
> that by definition is an incomplete description of
> the program being
> represented.  This begs the question to determine
> what parts of the program
> are represented?  And, of course, how are they being
> represented?  It is my
> contention that any such representation may be
> ambiguous (unambiguity can't
> be proven)/inconsistent (inconsistency can't be
> proved).
> 
> robert
> 
> -----Original Message-----
> From: Niall@feabhas.com [mailto:Niall@feabhas.com]
> Sent: Friday, October 25, 2002 7:55 AM
> To: puml-list@cs.york.ac.uk
> Subject: RE: Status of UML 2.0
> 
> 
> 
> > -----Original Message-----
> > From: Hubert Baumeister
> [mailto:baumeist@informatik.uni-muenchen.de] 
> > > 
> > > For example, given some program P, I wish to
> determine it's 
> > meaning.  
> > > To
> > > do so requires that I have
> > > a formal semantics, one that is unambiguous and
> complete in 
> > the sense 
> > > that every sentence constructed
> > > in the implementation language has only one
> interpretation in the 
> > > specification language - but that requires
> > > me to show that the specification language
> itself is 
> > unambiguous - which 
> > > in general can't be done.
> > 
> > So what your are saying is, that it is impossible
> to give a 
> > precise mathematical semantics to 
> > programming language constructs?
> 
> Correct me if I'm wrong but I believe Modula-2 was
> specified using VDM.
> 
> 
> 
> To remove yourself from this list please mail
> puml-list-request@cs.york.ac.uk
> with a message containing the word "unsubscribe".
>  

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Date view Thread view Subject view Author view Attachment view