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 ... 353 354 [355] 356 357 ... 417
5311
Uml Process / Re: Navigability
« on: November 02, 2006, 06:09:19 am »
As I read the [size=13]UML 2.1 Superstructure (interim)[/size] Specification (6.5.2 Diagram format), this is now a non conforming representation.

That is to say that since both ends are named it is, prima facie, navigable in both directions.  

If the Association is navigable in both directions, then under UML 2.1 there should be NO arrows.

The diagram is therefore non-conformant.

In addition, since setting the EA association to be bi-directional will cause EA to draw arrows at both ends, EA is therefore (currently) non-conformant.

HTH,
Paolo

5312
Uml Process / Re: implicit primary key?
« on: November 02, 2006, 05:51:39 pm »
Hi,

I think you are describing what is more commonly called a Surrogate Key:

"Sometimes, it is useful to allocate a special column to use as the primary key of a table.  We can enforce a high degree of stability by ensuring that no external (or domain) column is used as any part of the key.  The special column “takes the place of” the other columns that would normally constitute a candidate key in the external domain.  In other words, this key is a surrogate for the external candidate, hence: surrogate key."

I would model the column, make it a PK and then add the additional stereotype (which you can now do with 6.5) of «surrogate».

HTH,
Paolo

5313
Uml Process / Re: navigability and OCL
« on: November 02, 2006, 05:46:16 am »
If you give us a reference in the UML specification, we'll have another go at answering your question...

Paolo

5314
Uml Process / DB relationships vs UML Associations
« on: October 19, 2006, 01:30:53 am »
EA handles Data Modelling using a Rational/IBM de facto standard. There is an RFP which has now closed for an OMG specification: [size=13]ab/05-12-02 (Information Management Metamodel (IMM) RFP)[/size]. The EA approach is documented in: [size=13]Database Modeling in UML[/size].

Apart from some bugs - which are just defects in implementation not conceptual problems - the way in which EA has implemented Data Modelling is adequate. An example of such a bug can be found at: [size=13]Bug: DB Relationship Roles[/size]

However, there are some consequences of this implementation that may not be obvious to the casual observer (Me... :D).

Normally, in UML we have the concept that "a named navigable AssociationEnd is an Attribute" [size=10](my emphasis)[/size]. As I point out in: [size=13]BUG: Attribute/AssociationEnd NOT paired[/size], this means that the Target Roles are (the names of) the Source Class' Attributes... (and vice versa...)

However, in EA if the class is stereotyped as «table», this isn't the case.  If the table is the target, for the target role you get a list of the target's unique indexes (including the primary key) only. (Actually you get the names of the appropriately stereotyped operations). If the table is the source, for the source role you should only get the source's defined foreign key constraints.

Now this is as it should be - as per generally accepted data modelling practice. But it isn't standard UML. So be careful!

(Try adding/removing the «table» stereotype and observe the changes in EA's behaviour. Again, I stress this is as it should be - but needs some getting used to...)

As a safeguard, I recommend that you explicitly use one of the two available Data Modelling notations (IDEF1X or Information Engineering) for the inter-table relationships. This can be done via the Diagram Properties dialog. This will alert the user that the behaviour of the Roles will be different!

However, as I point out in: [size=13]Mixed connector notation on diagrams[/size] we will increasingly be mixing association types on the same diagram and will need to be able to alert the user as to the different behaviours by individually assigning the rendering.

HTH,
Paolo
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

5315
Uml Process / Re: Structured Activity Nodes
« on: October 18, 2006, 11:38:13 pm »
Quote
Hi Paolo,
probably I'm on a totally different boat. To me both represent shadows (in Platon's sense) on the wall stemming from the same "algorithm". But probably I'm completely wrong here. No need for discussion  ;)
OK  Thomas...  But I, at least, would appreciate someone confirming I haven't "got hold of the wrong end of the stick"...

Paolo

5316
Uml Process / Re: Structured Activity Nodes
« on: October 18, 2006, 01:30:37 am »
Quote
A bit off-topic, but what is the advantage of a diagram like Figure 10 over the code in Figure 9? Except maybe it takes 10 times more time to understand Figure 10 than 9 and probably 100 times longer to create the drawing.
Thomas,

It's not a question of advantage.  The two figures are doing completely different jobs.  If anything, Figure 9 is the outcome of the repository traversal in Figure 10.  Figure 10 is there to tell Sparx how their internal representation of the concepts in Figure 9 is to be set up (at least on a conceptual or API level).

HTH,
Paolo

5317
Uml Process / Re: CombinedFragment - naming anomaly
« on: September 29, 2006, 01:03:17 am »
We've been looking at ways to reduce the complexity of some of our sequence diagrams and we've come to the following conclusion:

if there is only one allowable operand for the interactionOperator (such as opt, loop, break or neg); then the operand (EA's Condition) should be rendered within the name and operator panel:

---------------------------------------------------
|<fragment name> <operator> <operand> |
|--------------------------------------------/
|

where there are more than one possible operand, then:

---------------------------------------------------
|<fragment name> <operator> |    [size=16][<operand>][/size]
|-------------------------------/
|
|
|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|        [size=16][<operand>][/size]

The operand is more prominent in the second case because it needs to be distinguished from the surrounding text.

(Figure 14.11 in the Superstructure Specification is one of the better examples of this...)

I hope this will be a reasonable suggestion...

Thoughts?

Paolo
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]



5318
Uml Process / Re: CombinedFragment - naming anomaly
« on: September 29, 2006, 12:34:45 am »
Quote
And mine.

However, there should be an option to display as per the UML 2.1 specification if that is different. Thus we preserve the ability to be compatible. Meanwhile, who of us have an ear at the OMG UML table, and can raise this as an issue to be solved later? [My "ear" is on another committee; a direct path would be better.]
Dave,

As Jim points out, the UML specification is a bit self contradictory in this area.

My suggestions are designed to be more consistent than the specification, but still compatible with as much of it as possible.

Paolo

5319
Uml Process / Re: CombinedFragment - naming anomaly
« on: September 27, 2006, 07:23:46 pm »
Quote
Paolo;
Looking at Fig 14.24, I see your point.  However, I'm having trouble explaining the presence of "SD" in the diagram.  "SD" normally appears in the diagram frame title, not in a fragement frame title (to my way of thinking). :-/

I now believe that both the UML 2.1, Figure 14.24 and EA have issues that need resolution. ???
Yes, I agree...

My vote for fragments would be:  

<fragment name> <operator>
[constraint]
-------------------------
[constraint]

Paolo

5320
Uml Process / Re: CombinedFragment - naming anomaly
« on: September 27, 2006, 07:32:19 am »
Jim,

some examples are to be found in Figure 14.24 - Ignore, Consider, assert with State Invariants on page 532.

HTH,
Paolo

5321
Uml Process / CombinedFragment - naming anomaly
« on: September 27, 2006, 04:38:23 am »
The rendering of CombinedFragments (see Help under Interaction Operators) seems t be defective.  As I understand the [size=13]UML 2.1 Superstructure (interim)[/size] Specification 14.3.3 CombinedFragment (from Fragments), where a fragment is not anonymous, the name precedes the operator:
sd <name> (ignore | consider) { <message-name> [, <message-name>]* }

however, if the fragment is anonymous, then the operator suffices:
loop

If I add a name to the above anonymous loop, I should see:
sd <name> loop

or at least:
<name> loop

EA places the name after the operator, leading to incongruous syntax and confusing semantics.

Have I go t this the the wrong way round?  Or does it need fixing?

TIA,
Paolo

5322
Uml Process / Re: Stupendiously stumped on Stubs
« on: September 21, 2006, 05:03:43 pm »
Quote
I'd say that the stub DEFINES the interface while the implementation REALIZES it. IOW stub = socket symbol, implementation the box.
Well, in the general case, many stubs contain some limited functionality, and there may be many stubs (aka "Mocks") (see Domain Driven Design forums).  For example, an in memory mock, an XML based mock, the full code - all implementing a Data Transfer Component interface.

From a modeling perspective, I feel it's better to define the interface and then provide a variety of "mocks" up to to the full implementation.

Also, taking this route opens up the possibility of many full implementations, each technology specific.

Paolo

5323
Uml Process / Re: Stupendiously stumped on Stubs
« on: September 21, 2006, 06:21:14 am »
Quote
How does a realization feel? From UML 2.1:
You actual code is the specification (i.e. supplier) and your stub code is an implementation of the specification (i.e. client).
Guys,

I would have said both codes (the stub and the full) implementations are Realizations of the Interface.

I mean, isn't that the point of the stub?

My AU$0.05
Paolo

5324
Uml Process / Re: How to load rose files?
« on: August 13, 2006, 03:05:14 am »
Search the forum for "Rose Unisys XMI"  within the last 400 days...

You need to to get the 1.3.6 Unisys XMI export utility for Rose from the IBM site...

I've moved some models in both directions

HTH,
Paolo

5325
Uml Process / Re: Abstract child of an instantiable class
« on: August 11, 2006, 06:19:37 am »
Quote
Is it conceptually "fit and proper" to have a specialised class marked as abstract when its parent(s) are instantiable?
I got asked this today and cant find an answer.
Further, is it allowable (or more correctly, how can one model) a class that is abstract in certain (general) circumstances, but instantiable in other (privileged) circumstances?
bruce
bruce,

Some languages, notably Eiffel (and, I think, C++), allow this.  In Eiffel terms you are creating a Deferred descendant from an Effective ancestor.  This process is called Undefinition.
(See 14.5 Deferred Features and Classes in Object Oriented Software Construction II)

As to your second question, I suspect that the same class can't be, since whether a Class is Effective or Deferred is a design time decision.  However, I stand to be corrected on that.

HTH,
Paolo

Pages: 1 ... 353 354 [355] 356 357 ... 417