[Modeling] response ro Rado's UN case study

[rce@whitestein.com]

Dear Renato,

here are my answers:

> 1- Class Diagram (complicated only, the simple is of no use)
> 
> The notation looks a little confusing to me, but I sense it at the correct 
> level of abstraction. I would like to discuss Icons and perhaps semantics 
> foe more complex environements *SC-UN) was not exactly challenging).

I used "conventional" UML class diagram, and the model was drawn with
Rose. I used notation of AML (Agent Modeling Language developed at
Whitestein) which is inspired mostly by notation of MESSAGE's modeling
language. Because our aim was not to present the class diagrams, I did
not describe comprehensively the semantics of used modeling elements.
I hoped the description I gave was sufficient, but now I see it was not.
If needed, I can discuss it in details - mainly in the context of AUML
static structure diagrams.

> 2- Interaction Overview
> 
> Loved It!!!!!!!! I can't stress enough. Besides giving a sense of phases of 
> the intreaction I allows one to sees multiple pahts without getting bogged 
> down in details. All in all it has the extra quality of promoting
> reusability.
> 
> One sugestion touhg, the players on each interaction fragment should be 
> depicted in the icon of each fragment.

Yes. The lifeline names can be exposed in the interaction references to make 
the overall picture little bit clearer.

> 3- fragments
> 
> a) I like the generic idea of the multi-lifeline,  I have use it before in 
> my design. I also like the "guard condition" to single an agent of the 
> multi-line. I don't think it may cover all possible multicast cases.

It is allowed to put arbitrary constraint into the guard condition. I
mean Constraint in a sense of UML. Therefore any subset of instances 
represented by a Multi-lifeline can be addressed. Could you please give me 
some examples of multicast which cannot be covered by this mechanism?

> This particular interaction fragment seems that the parallel block is not 
> needed, since the optional block would suffice to express the behavior 
> (pehaps it is there for demonstration purposes)

I wanted to model that the withdraw message can be sent before the
inform message is sent, or after, or in parallel. Another alternatives would
be: a) to abstract from this fact and to put just one optional block after the
inform message, b) to put two optional blocks - one before and one after
the inform message.

> b) change chair
> Similar to my own design to change chair interaction. Important note the 
> use of place holder in defining the agent that is the chair (currect, new), 
> the exact definitions are environment dependent and should be defined at 
> the environment level.
> 
> I like the temporal notation for the loop. I've use it before and it is one 
> of suggestions for temporal constraints (modeling area)
> 
> Rules of nomination have to be defined at environement on non-coloquial 
> language (english is too plausible to misinterpretation)

You are right. Definitions of current and new chair as well as nomination
rules are defined in UN-SC environment. I had it in mind while I was
modeling, but I did not write it in the document. It must be noted that
all interactions I created are owned by UN-SC. Therefore all "interaction
participants" (named ConnectableElements represented by Lifelines) must
be known in the context of UN-SC instance.

> c) vote
> I support the idea of a loop expression which is reacher then automatic 
> iterators can provide. Expression sytax should not be liable for dual 
> interpretation.

Hmmm... Probably the best way how to avoid misinterpretation is to
standardize the looping expression. After several trials to do this, I gave
up because I realized that C++ programmer would prefer C++ syntax, VB
programmer VB syntax, Java programmer ...etc. etc. Each language offers 
different
possibilities. Therefore I think that notation:

loop (<expression>)

, where <expression> is any string, would fit to all of them. Of course we
should suggest some format convention, that by putting into the standard would
influence most of AUML users.


> d) result
> 
> Same remark as in the others, actual decision point should not be in 
> english but rather a clear logic syntax.

Originally I used OCL, but afterwards I changed it to better readable English.

BTW I gave up to use OCL, or any other formal language, in UML models
intended to the people with unknown or various knowledge. Most people around
me do not understand formal specifications, even if they usually have some
mathematical education. Misinterpretation of formal formulas is usually bigger
than impreciseness of natural language.


Regards,

Rado1.
--
Radovan Cervenka | rce@whitestein.com
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5443-5502 | Fax +421(2)5443-5512
--
If you are not the intended recipient of this email,
you are not authorized to make any use of it;
please delete it and notify us by return email.