Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Paolo F Cantoni

Pages: 1 ... 352 353 [354] 355 356 ... 390
5296
Uml Process / Re: AD: Guards and Decisions
« on: May 08, 2005, 09:01:27 pm »
Hi Alexander,

Quote
I think that we should not loose sight of UML's
purpose. Although it allows for a lot of possible
representations for the same sequence of activities, the
purpose is to transfer in an unequivocal way the business
'knowledge' to an engineering language.


The OMG states:
Quote
The OMG's Unified Modeling Language™
(UML®) helps you specify, visualize, and document models of
software systems, including their structure and design, in a way
that meets all of these requirements. (You can use UML for
business modeling and modeling of other non-software systems
too.)


So software modeling, is just one of its uses, albeit the
primary one.

Quote
With that in mind we limit what you can do with UML to a
subset of patterns.


This is a good move... Patterns are extremely useful.  But which
subset, and in which context and what forces?

Quote
In this particular case, we only allow multiple control
flows to enter or exit an activity if it is used to handle
exceptions in which case we use the 'interruption flow'. Any
other control flow should be synchronised (either synchronously
-join- or asynchronously -decision-) before entering the
activity.


Why?  As I hinted in my original post, I got the distinct
impression that this was the case, but I couldn't find any
explicit direction to that effect in the OMG specifications.

Everything said so far about decision or merge nodes appears to
apply equally well to the activity itself (if I've understood
things correctly).

Since, at present, code engineering doesn't touch activity
diagrams, and...
Quote
(Self) However, there is NO provision in UML
to explicitly place the (say) If condition in the Decision node.
You can only do it by implication in the guards associated with
the outflows (as far as I can tell). ).

I don't really see
any practical difference (at this stage).

Quote
In any way, UML allows for a lot of workarounds, you
should decide if your diagram is clearly transmitting what you
want to say... just a thought


Good thought!  But my question still applies...

Paolo

5297
Uml Process / Re: AD: Guards and Decisions
« on: May 08, 2005, 06:29:13 pm »
Quote
Mike,

Thanks for the caveat. I would suggest, however, that such concerns are, IMHO, important only if you are building an executable model or are generating code directly from a statechart or activity diagram.

One thing that I have done when using UML diagrams to convey the design details to others (clients, programmers) and to keep from forgetting exactly what I meant when I put a diagram together is to build a "graphical glossary." By that I mean a package of diagrams, with explanatory notes, showing the constructs used in the actual model and how they are to be understood. I found this to be particularly useful for projects stretching out over any period of time, since memories need refreshing from time to time.


I'm with you Fred.  I have created a "Modelling in a Nutshell" document which I used to hand out during modelling sessions and to people who needed to "appreciate" the models.  Unfortunately, it's oriented toward Data Modelling using some personal extensions to the standard? Entity-Relationship modelling approach.  Hardly anyone read it (who reads user manuals?), but it was still necessary to produce and as you imply, the important point was to keep oneself and others on the "straight and narrow".

Paolo

5298
Uml Process / Re: AD: Guards and Decisions
« on: May 06, 2005, 05:16:16 am »
Hi Mike,

Quote
My only thought is that it is possibly closer to 'programming' to write sequential decisions, than to construct well-formed (i.e. non-overlapping, with always a defined outcome) guard conditions, which have more in common with state transtion diagrams.


On first encounter that might seem to be the case, but I'm not so sure...

Quote
Cf.Activities may describe procedural computation - in which case, explicitly writing out the decisions sequentially gives a closer mapping to how the process will eventually be implemented.


Why is that? (see below)

Quote
If the decisions are described by guards, it might be possible to translate the decision-making process in such a way that it did not literally correspond to the model, because many (most?) implementation languages do not support the construct of N-way predicate-guarded flows of control.


Agreed, I think.  Could you provide an example of this variant translation?
However, there is NO provision in UML to explicitly place the (say) If condition in the Decision node.  You can only do it by implication in the guards associated with the outflows (as far as I can tell).  ???
So, I don't really see any practical difference (at this stage).  And, in fact, it was that line of reasoning that got me into the "use guards directly" mode in the first place. 8)

Quote
If that makes sense to you ...


Sure does!  Thanks for the input!   Any further thoughts?

Paolo

5299
Uml Process / AD: Guards and Decisions
« on: May 05, 2005, 10:47:42 pm »
Under UML 1.x, I often used to have control flows coming directly out of (the equivalent of UML2 Activities) with appropriate guard conditions on them.  Thus I was able to dispense with the decision node. 8)

Depending on the tool, you were allowed either only one inbound flow or more than one, only one or more than one outbound flow.

EA allows multiple inbound and multiple outbound control flows to an activity.  If each outbound guard is correctly constructed so that the model is well-formed (see OMG UML Specification section in the EA "Activity" help topic).  Then it aught to be OK?  Yes?

However, reading the UML 2 specification, I distinctly get the impression (more so than UML 1.x), that OMG want you to use the Decision node to do the alternate flow processing.  I say impression, because I can't find any definitive statement to that effect. ::)

Comments or thoughts anyone?

Paolo

5300
Uml Process / Re: Associations vs Dependencies
« on: May 10, 2005, 07:02:12 am »
Quote
I am diagramming a business process.  Its actually just a secretary doing a mail merge and the mail merge creates documents in a file system directory.


Bill, sorry for getting back to this so late, but as shnplr has correctly said, we haven't answered your original question.  One of the reasons is that, I believe, the basis of your original diagram is incorrect.

It isn't, and can't be, a diagram of a business process - because it has NO behavioural elements.  It may be a diagram of a set of structural elements involved in a particular business process.

If I understand your intent, the secretary runs the macro which, either automagically or by user input, locates the Excel data source, takes that data and (again, either automagically or by user input) locates an output file directory and generates a set of TermLetters.

Assuming that is the case, then MSWord accesses the XCellDataSource (an association), it references the FileSystemDir (another association) and it generates TermLetters (a third association).  It is run by Secretary (another association - but reversed in direction from yours).  FileSystemDir contains TermLetter (a composite aggregation association - because if you delete FileSystemDir, the included TermLetters are destroyed).

As far as I can see, as Bruce (Sargasso) pointed out, there are only structural relationships here.  No behavioural (dependency) ones.

Does that help?

Paolo

5301
Uml Process / Re: Associations vs Dependencies vs Attributes
« on: April 09, 2005, 10:40:40 pm »
Hi all,

The issue is further compounded by the fact that the UML2
Infrastructure document specifically states (correctly) that a
navigable association with a role IS an attribute.  (Geoffrey,
did you see this?)

At our site, which currently uses another tool, we have created
our own generators.  We have created composite associations
(with stereotype: <<attributive>>)for each attribute that
references another class (as opposed to a simple datatype).  
Multiplicity is set appropriately at both ends.

Further, to aid visualization and to cross check the model, we
create a dependency (stereotype: <<attributive>>) between the
dependent (home) class and the independent (referenced) class.
We set the multiplicity of the dependency to the number of
attributes that reference the class, and the name of the
dependency (not normally used) to the list of names of the
attributes implying this dependency.

By automating this process and then automatically creating
automata that traversed the model and drew diagrams under our
control we were able to "see" the model in new ways.

Once we started doing this, anomalies in the model suddenly
started to be "in your face"!

Paolo
:)

5302
Uml Process / Re: Standardising Classifier adornments
« on: May 09, 2005, 07:25:40 am »
Quote
I would like a caveat though - I, as the boss honcho
around here want the ability to constrain the monkeys down the
tree from using "pretty" but non-compliant replacement icons,
replacement boxes and TRHC icons unless I SAY IT'S OK both at
the project and diagram level!

Bruce


I think this is a straight forward security issue.  You should
probably start a separate thread.  Although I suspect there
could be a general pattern that could be pretty universally
applied to EA elements.

You point about "down the tree" is well taken.  It seems to me
there ought to be the equivalent of Cascading Style Sheets for
element adornments. As you specialise stereotypes you could
maintain some degree of adornment consistency - something like
the way MS Word manages style hierarchies.

Paolo

5303
Uml Process / Re: Standardising Classifier adornments
« on: May 09, 2005, 03:15:51 am »
Quote
p.s. Paolo - have you seen a spell checker for Firefox?



I believe GNU ASpell can be made to work, but I don't know that for sure...  Look on the site.  If you find one, let us all know as I'm seriously thinking of Firefox.

(I'll reply to the rest in a separate post)

Paolo

5304
Uml Process / Standardising Classifier adornments
« on: May 09, 2005, 12:54:12 am »
Bruce (Sargasso), in a private message, concerning another post of mine,
made the following comment (which he has permitted me to quote):

Quote
I spend, I reckon, at least a day on each project telling
modellers not to use their own ideas of what's beautiful and
meaningful - and then hacking into the EAP repository to cut out
their beautiful pictures when they ignore me and do it
anyway.


Bruce, here, is talking about the ability to replace the entire
model element (typically a shape only - why?) with an image.
Thus for the actor stereotype we replace the box with a "stick
man".

One of the functions of the model is to communicate, and from
time to time in the past I've used this technique to better
communicate some concept or other to the "punters" - the
stakeholders, users, management, development teams etc.

However, if you observe the UML specifications carefully, you'll
see that "all boxes are equal - but some are more equal than
others".  Some boxes are lucky enough to have icons in their top
right hand corner - Component for example.  I can't quickly see
other examples - and I can't use EA as it isn't always UML
compliant here.

It seems to me that all classifiers should have the ability to
be adorned with icons in the top right hand corner.  Thus, for
example, a boundary entity should have a number of rendering
modes:  Plain "box", Plain box with icon in top right, Icon
replaces box.

We can then extend this to the application of stereotypes, we
can then get:

Standard or icon adorned box with «stereotype» added as text,
Standard or icon adorned box with «stereotype» images added as
icons in top right (or perhaps top left), principal «stereotype»
image replacing box with subordinate «stereotype» text
adornment, principal «stereotype» image replacing box with
subordinate «stereotype» images added as icons (as above).

In this way, we can (possibly) better communicate the
application of multiple stereotypes to a model element.  I
believe multiple stereotypes will become increasingly more
useful as people discover they are possible (compared to single
stereotype UML 1.x)

Thoughts anyone?

Paolo

5305
Uml Process / Re: EA Help file on Choices / Junctions
« on: May 08, 2005, 07:04:01 pm »
Quote
Presumably you, CJ, didn't get where you are today without using Zicom Mentor ;-)

(See http://www.mgnet.karoo.net/cjphrases.htm)


Where are you Reginald Perrin, when we need you? ;D

Paolo

5306
Uml Process / Re: UML 2 MetaModel (Diagrams)
« on: April 29, 2005, 12:26:46 am »
Quote
:D I'm working on UML 2.0 Infrastructure Library model for last four days...


Hi Mr Wolf,

Are you intending to include all the elements mentioned in the infrastructure document?  That would be a great service to the modelling community. 8) 8) :)

Could I ask what is motivating you to do this?

Paolo

5307
Uml Process / Re: UML 2 MetaModel (Diagrams)
« on: April 29, 2005, 12:24:08 am »
Quote
Strike me lucky - I thought trying to understand the d*mn things was bad enough - Paolo wants to work with them???

 ;D
bruce


See, not just me...  :P

Paolo

5308
Uml Process / UML 2 MetaModel (Diagrams)
« on: April 27, 2005, 08:03:35 pm »
Has any kind soul created the UML 2 metamodel diagrams (or knows where they might be found)?

Even a partial implementation would be useful...

Paolo

5309
Uml Process / Re: Modeling web applications with UML
« on: May 03, 2005, 11:42:46 pm »
Quote

In that specific example, no. This is because the nested elements would be instances not the TCP/IP classifier.  So each node would have its own object nested beneath.  Why you would want to have that on a model is oos!

In the case of nested classifiers, I cant think of an example where you would want to have the classifier nested in two places.

bruce



More thoughts...

Agree my specific example is incorrect.  (Slip of the mind :D)

It seems to me now, that if one element is nested within another element, then you can't refer to it without the pathing information via the containing element.

Paolo

5310
Uml Process / Re: Modeling web applications with UML
« on: April 25, 2005, 09:27:15 pm »
Quote
I dont know whether this is the real reason, but I have found the following syntactical use for nesting links in any diagram between (sort of) any element pair.

[SNIP]

IOW, I see the nesting link as a visual highlighter, yes representing "physical containment"  but adding no other implied relationship.

[SNIP]

bruce


Sounds good to me, Bruce, and would be consistent  :D with Thomas's points.

So, if I understand you correctly, syntactically, "nesting" would only apply to those elements that are able to contain (collections of) other elements?

Back to my observation that some tools will automatically alter the browser when you "nest" one element inside another.  In your example, fruit would appear "under" tree and not be visible, until you "opened" tree.  Does that fit in with your ideas?

If so, do you see any problems with multiple containment (such as the TCP/IP stack in multiple nodes).  Would each node become a branch with a stack elements "underneath" (within) it?

Paolo

Pages: 1 ... 352 353 [354] 355 356 ... 390