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 ... 351 352 [353] 354 355 ... 415
5281
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]



5282
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

5283
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

5284
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

5285
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

5286
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

5287
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

5288
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

5289
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

5290
Uml Process / Re: Business Rules and UC
« on: June 02, 2006, 04:57:44 pm »
Quote
[size=13][SNIP][/size]
My take on this is that a use case is something we may talk about and also assign a unique name; therefore a use case may be considered to be an object.  Agreeing with Paolo then, I can conceive of talking about the use case's responsibilities.
[size=13][SNIP][/size]
Well Jim, it may be an object, but not as we know it... :)

You may be agreeing with me, but I'm not sure I'm agreeing with you. :D

To be an object, the thing has to be an instance of a Class.  If anything, it might be a meta-object.

In my view, it would only become an object if we were modelling a modelling application (such as EA).

That having been said,  I like the idea of documenting the goals or outcomes (from bruce's suggestions elsewhere)  against the UseCase.  They can be displayed on diagrams by switching to rectangle notation and displaying the responsibilities.

If you wanted to go "the whole hog", one could conceive of the the idea of Design by Contract being applicable to UseCases and documenting the pre-conditions, post-conditions and invariants (during the execution of the UseCase) in this section.  In fact, if we renamed the section Contract, then the aforementioned Responsibilities of a Class would fit right in!

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

5291
Uml Process / Re: Business Rules and UC
« on: June 01, 2006, 09:35:21 pm »
David,

I don't like the idea of distinguishing between an element's internal versus external requirements - to me it's a bit of a non-sense.  However, when Sparx said (in the context of classes) that they were the class' Responsibilities, it made sense (at least to me).

Now, that requires that the tab marked Require be changed.  However, because of the polymorphism, that tab will appear in many other Element types (such as UseCases)..  The concept of an element's responsibilities may not apply to all subtypes of elements...

I think responsibilities are primarily for Objects and Classes (coming from the CRC card process).  Since a UseCase often cuts across a number of Objects, the notion of a UseCase having a set of responsibilities is somewhat suspect.

In fact, I recently observed (in an offline post to Jim Shaw) that just as we have the well known Semantic Impedance between the OO Model and the Relational Model, there is a similar semantic impedance between the Functional (UseCase) Model and the OO Model.

Thus we have an impedance mismatch at both ends!

It is the bridging of these semantic impedances that constitute the more significant challenges for modern systems design.

HTH,
Paolo

5292
Uml Process / Re: Business Rules and UC
« on: June 01, 2006, 04:32:22 pm »
Quote
Thanks Paolo,

This does not sound as bad as I had feared.

Is there any issue with the difference between "internal" and "external" requirements (in the current vernacular), or do they need only to make the changes where Thomas' message suggests?

David
David,

I'm not sure exactly what you are asking here, can you explain more?

Paolo

5293
Uml Process / Re: Business Rules and UC
« on: June 01, 2006, 03:53:51 pm »
Quote
Thomas,

Regarding
Is this from OMG? Or, is it a case of EA not being CCC?

[I'm just trying to determine how concerned I am, and why...]

David
Technically, David, its a low level fracture of CCC...  The  only problem with the EA setup is that the element specific things are ALSO called requirements.(instead of responsibilities).   Sparx have admitted it is better to view them as responsibilities - since they are element specific and good OO design requires (encourages) that...  I strongly agree!  The notion that requirements don't have a possible many-to-many relationship with other elements is risible.

All that remains is for Sparx to change the headings on the element specific responsibilities tab from Require  to: Responsibilities.  That way, it is CCC with the Set Feature Visibility ([Ctrl+Shift+Y]) dialog which already calls them Responsibilities.

HTH,
Paolo

5294
Uml Process / Re: Business Rules and UC
« on: May 30, 2006, 02:32:20 pm »
Quote
Oh! I think the answer is plainly: define a requirement, assign it a <<business rule>> stereotype and create a link.

Well, any opinion is welcome :)
What kind of link did you decide on Thomas?  A straight «trace»  dependency (or something else)?

Paolo

5295
Uml Process / Re: Page flows using UML
« on: July 18, 2006, 05:19:20 pm »
Quote
I suggest you spend significant time exploring how this can be done and decide on a modelling profile suitable for your situation. Models of these types can become very confusing if you don't select a specific mechanism and stick to it rigidly!
bruce
Echoing bruce's comments about sticking to it rigidly...  If you are consistent, you can evolve consistently.  That is to say, if you are disciplined in your approach and you find you are "consistently wrong" at a later stage, you can write some automation to evolve the model from your old understanding to your new one.  It's better to be consistently wrong than inconsistently wrong!

HTH,
Paolo

Pages: 1 ... 351 352 [353] 354 355 ... 415