Re: FW: 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:37:24 BST


Hello

If my intention is to describe program P but you
interpret it as program Q, while yet another
individual interprets it as program S, then that's not
necesarily a recipe for confusion. There should be no
confusion if Q and S are both refinements of P, so
that they are both consistent with P.

And of course, the purpose of a constraint has nothing
to do with whether it should be ambiguous. Regardless
of the level of abstraction, a specification (in a
model) should be unambiguous (or precise). Indeed, a
significant aspect of the field of systems analysis is
devoted to this subject.

If a particular specification is not precise (possibly
intentionally to avoid over-constraining the system at
the current level of abstraction), then the imprecise
aspects of the constraint should be made known. In
such a case, readers of the specification are not
allowed to make any (inconsistent) assumptions about
the imprecise aspects; instead, they should refer to
lower-levels of abstraction for a (constraining)
more-precise specification.

Kinika


 --- "Bauer, Robert" <rbauer@rational.com> wrote: >  
> -----Original Message-----
> From: Bauer, Robert 
> Sent: Friday, October 25, 2002 1:24 PM
> To: 'kokar@coe.neu.edu'
> Subject: RE: Status of UML 2.0
> 
> 
> Mitch,
>  
> If a UML model defines constraints on the programs
> that are consistent with
> the model, then consider the case where there are a
> collection of such
> programs - ie., one model and several programs
> consistent with that model -
> that is, several programs that are not semantically
> equivalent.  Then, well,
> that's clearly the definition of ambiguity - for if
> your intention was to
> describe program P but I interpret it as program Q
> while yet another
> individual interprets it as program S, that's a
> recipe for confusion.  We
> could try use constraints to identify one specific
> program, but of course,
> that's the problem I wrote about.
>  
> With respect to a<b, you wrote: ... They describe
> subsets or classes of
> things.  Is a<b ambiguous on say natural numbers? -
> - the answer is:
>  
> Let a be the set of natural numbers (1,2,3) let b be
> the number 25  is
> (1,2,3) < 25 - I don't know.
>  
> Now if you meant that a, b are restricted to being a
> natural number, and we
> assume you mean a formalization of natural numbers
> isomorphic to peano
> arithmetic without the axiom of infinity, then sure
> a<b isn't ambiguous.
> BUT that's not what you wrote.
> 
> -----Original Message-----
> From: Mitch Kokar [mailto:mitch.vis@verizon.net]
> Sent: Friday, October 25, 2002 12:09 PM
> To: puml-list@cs.york.ac.uk
> Subject: RE: Status of UML 2.0
> 
> 
> Robert,
>  
> I think a UML model defines constaraints on the
> programs that are consistent
> with the model. And constratints don't need to be
> ambiguous just because
> they are constraints. They describe subsets or
> classes of things. Is a<b
> ambiguous on say natural numbers?
>  
> =Mitch
>  
> 
> -----Original Message-----
> From: puml-list-request@cs.york.ac.uk
> [mailto:puml-list-request@cs.york.ac.uk]On Behalf Of
> Bauer, Robert
> Sent: Friday, October 25, 2002 12:58 PM
> To: 'puml-list@cs.york.ac.uk'
> Subject: RE: Status of UML 2.0
> 
> 
> 
> 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
> <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
> <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