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 ... 349 350 [351] 352 353 ... 411
Uml Process / Components and embedded Elements
« on: June 28, 2006, 05:37:25 am »
While having a look at Tony Evan's problem with Interfaces and Components Component/ports/interface + Comp. internals Model, I was playing with EA's implementation of the the [size=13]UML 2.0 Superstructure (formal)[/size] Specification (and, as far as I can see, the [size=13]UML 2.1 Superstructure (interim)[/size] Specification)  in this area.

First some assertions (which may or may not be correct - I'd appreciate some guidance):

With respect to Components, a Part is an instance of a base Classifier in a certain role.  A required or provided Interface is an instance of an base Interface in a one of two roles (provided or required).  A Port is an instance of a base Classifier, again in a certain role.

From EA's behaviour, it would appear that a Part MUST always be an instance of a base Classifier, while a Required/Provided Interface or Port are, by default, not attached to a base Classifier.  Once attached to a base Classifier however, they must REMAIN attached to an Classifier.  That is, the type of the Property cannot be reset to <none>.

From the Superstructure document it can be seen that a Component may expose an Interface directly or via a Port.

EA's rendering of the Assembly connector seems a little amiss.  The UML specifications show the ball and socket icon only for Assemblies that connect Components or Ports directly.  Where an Required Interface is connected to a Provided Interface, the UML specification seems to require a simple dependency to link the Required Interface to the Provided Interface.  NOTE: I'm talking only about rendering here.  It would seem appropriate that the Assembly dependency have a rendering toggle to render the Required Interface, Assembly Dependency, Provided Interface combination as an Integrated Assembly rendering or as the individual items.

It would appear that Ports are optional.  Since you can run a Delegate directly from an Interface to a Part or another Interface.  (Although I think I found a few bugs in the linkages here)

There doesn't seem to be any way to connect/disconnect an existing Required/Provided Interface to/from and existing Port.  Is that correct?


[Note: Edit to replace Class and Element with Classifier - to comply with UML specification]

Uml Process / Re: Responsibilities - let's fix it!
« on: June 04, 2006, 08:41:41 pm »
Quote: I guess it also should be the case that any given Responsibility should be the responsibility of only one UseCase?

I don't see that as necessarily true - in fact there are many world examples where different UseCases may "share" responsibilities.  There are also a set of responsibilities that should not be shared!

For example: Many UseCases may have the responsibility "creates transaction log entry" but in given system maybe there is a constraint that only one UseCase can have the responsibility "creates customer account".
Good point, bruce!

The question then is which are common and which are unique to one UseCase?  I think we can take an idea out of AOP (Aspect Oriented Programming)  We can separate those responsibilities that are related to cross-cutting concerns:  From Wikipedia on AOP: Logging offers the prototypical example of a crosscutting concern, because a logging strategy necessarily affects every single logged part of the system. Logging thereby crosscuts all logged classes, methods, and procedures..  These responsibilities can be shared; others, perhaps shouldn't be.  It may be necessary to decompose a UseCase into smaller UseCases (which can be referenced in multiple UseCase) so that the responsibility is correctly (uniquely) located.



Uml Process / Re: Responsibilities - let's fix it!
« on: June 04, 2006, 06:01:13 pm »
Not knowing a great deal about this Design-by-contract approach, I'm not to sure whether using the term contract would be more of the same problem as "requirement".
bruce, check out:
[size=13]Building bug-free O-O software: An introduction to Design by Contract(TM)[/size]
[size=13]Design by contract (Wikipedia)[/size]
For a quick overview.
A contract to me, implies two parties are involved.  This is a fine viewpoint for the behavioural features of an element but maybe not so for the overall element itself.
Au contraire (IMV)...
Then again maybe this is where the fundamental issue needs to be looked at.  EA seems to have got to a point where the UML element & feature attributes are now implemented in a variety of different ways. IOW, not only is  the UI unique, but also the UML!.
I think I follow... Are you saying that EA has done things that are not mentioned in the UML specs - that's true, but in the main,they are extensions and don't contradict UML (but then I like everyone else can't take in all the features of EA in one go!)  If I've misunderstood, then please correct me.
Looking at the latest spec I have I note that, for example,
a constraint is a packageable element in its own right.  IMO this means that the constraint attributes of an element should be likened unto the "external requirement"  beasty.  That is, manipulatable within the element but existent as a separate element.
Missed that! But interesting!
So it seems to me that this is a much wider review of EA than just the requirement/responsibility/contract matter.
I'm not averse to opening Pandora's box!
IMO use cases, being a behavioural element have all the right in the world to have responsibilities!
I see the example in the other thread.  Looks OK.

I guess the only thing I'd add is that each UseCase responsibility would need (eventually) to be distributed to one or other of the constituent Classes (or decomposed further and redistributed).  A bit like tracing requirements, but in this case tracing Responsibilities.

I guess it also should be the case that any given Responsibility should be the responsibility of only one UseCase?


Uml Process / Responsibilities - let's fix it!
« on: June 03, 2006, 02:27:16 am »
In another thread on [urrl=;action=display;num=1149007845;start=15#15]Business Rules and UseCases[/url], I once again brought up the dichotomy within EA regarding the Require tab enabled on many classifiers.

The EA Help file says:
Internal requirements in EA are class (or any element) Responsibilities

Looking around at the various parts of EA - the majority seem to label what is being input here as Responsibilities.  Thus it seems to me that it is time Sparx put an end to this confusion and labelled the tab consistently.

However, before they do, I want to put forward this idea from the other thread...
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![size=13][SNIP][/size]
If the tab were labelled Contract, then one could subsume the existing Responsibilities and start to extend it toward Design by Contract capabilities.  It seems to me that Design by Contract concepts are more widely applicable to more Classifiers (and other elements) than straight Responsibilities (or the, hopefully, deprecated internal requirements).

Consistency, Consistency, Consistency! TM

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

Uml Process / Re: Question on UC generalization/specialization
« on: June 24, 2006, 03:01:34 am »
Take a look at Scott Ambler's "The Elements of UML 2.0 Style" for some additional pointers on when specialization is preferable to using <<extend>>.
Hi David,

As you know, Jim Shaw is preparing an article for the EA Wiki Use Case Description.  Offline, we've been discussing Use Case Generalization.  

If you look at Scott's stuff on the Web, he mainly deals with Essential Use Cases (a very important topic) as the generalization process.  The only direct references I can find to the (Classifier) Generalization relationship are in his University Enrollment examples (Reuse in Use-Case Models: <<extend>>, <<include>>, and Inheritance).  They are presented undescribed and I'm actually a ta loss to see where the Generalization is.  Can you summarise your/his view on this, as I don't have Scott's book.  :(

Could you explain  how Enroll Family Member in University is a specialization of Enroll in University (and not just another instance of Enroll in University) and why Student is the only primary actor for Enroll Family Member in University.  It doesn't make sense to me.  ???


Uml Process / Re: Question on UC generalization/specialization
« on: June 24, 2006, 02:43:45 am »
Paolo, do they offer a good relocation package?  :D
I'll ask at the interview (if I get that far...)   ;D


Uml Process / Re: Question on UC generalization/specialization
« on: June 22, 2006, 05:56:45 am »
Sure, although I might know the answer already ;D
It wasn't a rhetorical question, I'm after your views...

There are a number of process improvement jobs on offer around here...


Uml Process / Re: Question on UC generalization/specialization
« on: June 22, 2006, 12:11:17 am »
ROFL That's a real life example I encounter almost every day. I still wonder what all this BPMxyz stuff can do about it. Business is burned into peoples brains and even the slightest changes will not be accepted. Funny enough: if for some chance the management decides to re-organize business according to some re-engineering, it will fail in almost all cases. I guess we need more social engineers...
Thomas, in the highlighted section, you are meaning that if management initiates a Business Process Re-Engineering (BPR) effort - typically by calling in BPR experts, it will usually fail; are you not?

Having observed a few BPR "experts" and talked to them, I can put forward some reasons why the BPR efforts fail.

Care to share some thoughts on why?


Uml Process / Re: Question on UC generalization/specialization
« on: June 21, 2006, 05:57:17 pm »
I'm wondering... I'm doing business analysis and having a time finding the line.  It appears that you are quite a bit farther along if you are trying to capture things in classes.   Does the business analysis break things down into classes?  If not, how do you document that there are different services, or different reports?
Yes, Jan, the BA should be able to create classes.  Just remember that the Classes the BA creates are conceptual - that is, are at abstraction levels of CIM (Computationally Independent Model) or higher.  That way, you are describing the business environment your Use Case exists in.  The downstream architects developers will be developing the PIM (Platform Independent Model) and PSM (Platform Specific Model) Classes, which should be derivable from yours.  If they aren't, then there's a disconnect between the the front-end and back-end processes which should be resolved ASAP.


Uml Process / Re: Question on UC Generalization/Specialization
« on: June 19, 2006, 05:27:32 am »
I sort of agree now as well. Seems more "natural".

On a similar note, say the Client Worker has another use case called Print Client Report which he uses to print out a report from a set of predefined reports, then where would we indicate what those reports are, their structure, format etc in our model?
Firstly,  getting back to Request a Service - you should only create extension UseCases when there is an essential behavioural difference.  If there's no essential behavioural difference, then the main use case should suffice...

So, with respect to Print Client Report we can apply the same concept...

There should be as many UseCases as there are essential behavioural differences.  In this case, I suspect there won't be.  (Select Menu Item, Select Report, Enter Parameters, Execute Report)  You'll be able to create a hierarchy of classes corresponding to the different types of reports.

Does that help?

Uml Process / Re: Question on UC Generalization/Specialization
« on: June 19, 2006, 04:04:08 am »
As Jim Shaw points out on the EA Wiki:
Use Case Textual Specifications
A use case is, all at the same time:

a Specialization of the BehavioredClassifier in the UML meta-model
a Type classifier;
a Behavior Specification; and,
a Scenario Template

In addition, a use case may be in a relationship with actors and other use cases. The nature of these relationships are important to the use case's behavior. Failure to grasp these concepts leads to much confusion in writing use cases.

So, since it is a BehavioredClassifier, it could be Generalized/Specialized.

However the question is should it?

I agree with your coworker.  The Services are NOT the UseCase.  Each «extended» UseCase uses the appropriate Specialized Service.  The Services should be represented as Classes.

If Generalization of UseCases were more common, it would have been mentioned in the [size=13]UML 2.1 Superstructure (interim)[/size] Specification.  That's not to say it can't happen, it's just it would be extremely rare.

My AU$0.05

Uml Process / Re: Stereotype question
« on: June 20, 2006, 03:58:17 pm »
I thought pretty much the same things; as I spotted this when I asked the question on Stereotype groups.  But, I thought, Thomas doesn't post enough these days, so I'll let him ask the questions  ;D

Makes you wonder though?


Uml Process / Re: What's the closest thing to DFDs in UML/EA?
« on: April 18, 2006, 04:20:57 pm »
There is no equivalent--DFDs really have no place in OO modeling (which is what UML is designed for). As a developer friend of mine once said, "data doesn't flow".
Hi Kevin,
While your developer friend is technically correct, the observation, to me, seems a bit simplistic.

While the data doesn't flow, the facts represented by the data do "flow" (as per the dictionary definition).  The act of assignment creates a flow of a "fact" from the RValue to the LValue.

The ObjectFlow within UML has these types of characteristics: An object flow is an activity edge that can have objects or data passing along it.  As your friend observed, the objects don't actually flow, but the facts they represent do.  In fact, the [size=13]Superstructure[/size] Specification goes on to say... An object flow models the flow of values to or from object nodes.  The values (in association with the object feature) are the "facts".

My AU$0.05


Uml Process / Re: UML 2 Superstructure Model
« on: June 08, 2006, 08:02:29 pm »
There are Rose models and .cat files at OMG. I do not know of any reliable reader that produces XMI. I am also not inclined to acquire Rose for this purpose only..
They're the ones I'm talking about.

I've successfully round-tripped models from Rose to EA and vice versa, but they needed to be well formed.

If someone has Rose 2003 and the UNISYS XMI exporter Add-ins, that's all that's required (I think)


Uml Process / UML 2 Superstructure Model
« on: June 08, 2006, 06:57:26 pm »
Does anybody have an EA copy of the OMG UML superstructure model?

Is anyone else interested in such a beast?

I have obtained copies of the Rational Rose version and supporting files.  However,the Rose version I have is too old (2002).  The model imports, after a fashion (but with errors).  Since it won't validate, it won't export with the UNISYS XMI exporter.

Is there a kind soul who could take this model and covert it to EA?  Failing that, provide an XMI export?

Can Rational Software Architect read Rose models?


Pages: 1 ... 349 350 [351] 352 353 ... 411