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 ... 418
Uml Process / Re: identity for classes
« on: January 08, 2007, 02:56:27 am »

I write for French press a paper comparing tools.

How can I define an attribute as identity (for it becomes a primary key after DDL generation) in an UML class?

I don't see any predefined stereotype.
Thanks for your response.

Hi soutou,  Welcome,

This is primarily a user forum.  To get a more precise response from Sparx Systems, use the [size=13]Support[/size] link at the top of the page.

However, for my own part, I would not (necessarily) expect a stereotype for this purpose.  If you search for the topic DomainKey you may see some discussion on this point.  Some of us take the view that the use of a DomainKey as the primary key is not a good design decision.  We prefer the use of Surrogate keys for that purpose.

Also, if you look into the DDL Transform Template (Settings|Transformation templates... [Ctrl+Alt+H]) you may find some pointers.

Others may have different viewpoints...


Uml Process / Re: Inferred UML elements
« on: November 30, 2006, 05:35:43 am »
Each item can be in one of three states:
Canonical, Derived, Inferred.

Inferred => Derived => ¬Canonical

Thus all Inferred items are, by definition, Derived.  Not all Derived are Inferred.

A Canonical item is neither Derived nor Inferred.

Each diagram shows whatever it needs to show to explain whatever it attempts to explain.

In the twenty-odd (and some have been very odd  ;D) years of modelling, I've managed to need only these three states.  But I'm open to suggestions...  ;)


Uml Process / Re: Inferred UML elements
« on: November 29, 2006, 05:01:34 pm »
Hi Paolo,

Whether you need a model element property <<inferred>> in addition to <<derived>> depends on the purpose of the model you are building. If it is a PIM (a logical/platform independent model like the ones I make at work) with no direct relationship to application code then there is no need for anything beyond <<derived>>.
If your model is platform specific (PSM), intended to be transformed into code, it is already some explicit derivation of the logical view on information. The same <<derived>> property in that model can then be interpreted to control code generation.
Hi Jan,
Well, not withstanding that model levels above PSM have no direct relationship with any specific platform, my comments relating to inferred items don't only relate to generation.  The non-generation of inferred is actually a consequence in the PSM.  However, in an expository sense, inferred items are useful in the higher levels also.  I first started using them in CIM level models.
The dilemma starts IMHO when you are trying to combine both purposes into one model. The PIM always represents a sort of 'ideal' with respect to its realization in physical systems. The PSMs are non-trivial derivatives because they represent the compromises with technical possibilities, the quirks of the organization's etc.
It may be worthwhile to try to separate these two purposes into different models, which would make the compromises explicit. You can use the realization link to indicate the mapping between business objects and the implementation objects.

There will of course be redundancy between the two models. This means duplicate work but if the correspondence is exact, you can refer to classes from the logical model instead of copying and modifying them.

Regards, Jan
I first got interested in inferred items over twenty five years ago, after attending a lecture by James Marting (the then Database guru) on Canonical design of Databases.  It seems to me that in any universe of discourse, you can define a set of canonical items.  The decision as to whether the remainder are derived or inferred, rests with the behavioural aspects of the model (as opposed to the structural).  If the item is traversed or referenced in the course of the execution of a behavioural item, then the item under discussion is marked as derived, otherwise if it is useful to show the item on the model, it is marked inferred.

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

Uml Process / Inferred UML elements
« on: November 09, 2006, 05:31:13 am »
In a recent topic: [size=13]Everything should be derivable[/size] I suggested that it would not be too far beyond the current UML specification to make everything (possibly) derivable.

In this topic I want to discuss a related topic.  That of inferred UMLElements.

Taking strict UML (for the moment), a UMLAssociation can be marked as derived (as Sparxian Ashely King points out, by using the isDerived Custom Property of the EAAssociation).

So what does a derived association mean?  Well, say we have a class OrganizationalUnit and another class Worker.  Each Worker is assigned to an OrganizationalUnit  (in functional notation assignedToOrganizationalUnit(worker) describes the association).  In addition, each OrganizationalUnit has a Worker designated as manager (in functional notation managerOf(organizationalUnit) is the association).  Now, it is often the case that we want to determine the manager of the Worker.  Normally, the Worker's manager is the manager of the OrganizationalUnit the Worker is assigned to.  In functional notation this would be: managerOf(worker).  However as we have just described, the value of managerOf(worker) is not arbitrary.  It is, in fact, managerOf(assignedToOrganizationalUnit(worker)).  Thus we can state that managerOf(worker) is derived by traversal of managerOf(assignedToOrganizationalUnit(worker)).

So now I've described three associations; two are canonical and one is derived.

The [size=13]UML 2.1 Superstructure (interim)[/size] Specification defines isDerived as: Specifies whether the Property is derived, i.e., whether its value or values can be computed from other information. The default value is false.

If I decide to implement the managerOf(worker) association, then I have a derived association.  But supposing I don't want to implement the association, but I'd still like to show it in the model (more specifically on diagrams) so as to aid understanding.  How do I tell an implementable derived association from one one I don't intend to implement?

The solution we've come up with is to mark it as inferred.  Inferred relationships have many uses.  For example, we might have a series of traversals via a set of CORBA interfaces and methods between a class in one component with a class in another component.  To put the full complexity every time on a diagram would quickly make them unmanageable.  Yet, placing only one link of the path doesn't come near telling enough of the story.  

To solve this problem, on the diagram we place an «inferred» relationship between the source class and the target component.  In diagram for the other side, we do the reverse.  A third diagram shows the full traversal (and the relationship of the «inferred» relationships to the others).

Inferred relationships allow the creation of multi-level views and (as we have just seen cross-level relationships).  They are useful summarising and abstraction mechanisms.

In a similar way, we can talk about inferred classifiers.  Typical uses are a classifier in a state.  You can create a specialisation of the classifier with the state as part of the name.  Thus PaidOrder is an inferred specialization of Order.  You can attach the specialized forms of the associations that only apply to PaidOrders and visually see the differences.  Naturally, these associations will be inferred versions of the Order associations.

As suggested above, we currently use «inferred» stereotypes for this purpose, but we feel a proper property would be much better.  It would be really neat if the property also set the rendering (like isDerived sets the "/" prefix).  isInferred might set the prefix "\" or "(/)" or some other distinction.

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

Uml Process / Re: Questions about Activity Diagrams
« on: November 29, 2006, 03:53:28 pm »
I am reading the book 'Learning UML 2.0' by Kim Hamilton, Russell Miles and applying it using Enterprise Architect. I have some questions:

1) The introduction says that tag values can be associated with stereotypes. Here, I think the concept of 'stereotype' introduced in the book is slightly different from the one followed in EA. From reading the book, my understanding is that a stereotype remains distinct from the element it qualifies. If I apply the stereotype <<form>> to a class, the class is a separate element and the stereotype <<form>> is another. Hence, <<form>> can have its own tag values which are shown in a Note attached to the class. In EA however, I have found no way of associating a tag value with a stereotype. The profile package allows us to create stereotypes with tags, but it seems that these 'stereotypes' are classes that can be reused, rather than a 'qualification' that can be applied to a class. Any comments?
No,  In the model, stereotypes are qualifiers that indicate the underlying UML element exhibits some different behaviour.  The diagram may be talking about the metamodel where you can define Stereotypes that can be incorporated in Profiles.  In the metamodel definitions, stereotypes are distinct elements.  I'm not a profile guru but the profile can make the application of a stereotype to a UML element automatically add tagged value entries.
2) The book says that when an action calls other actions it is called a call activity node. It is shown by displaying an inverted fork in the diagram. I have found out that to convert an action into a call activity node i have to go to Advanced -> Custom Properties and set kind = Call Behavior. But how/where do I specify which other actions/activities it will call? What are the meanings of the other options that can be selected for 'kind'? I don't think the documentation offers any hint about them.
I thought Actions were, essentially, atomic.  This is what EA implements.
3) The book says that for object flows between two actions, if only a part of the object is needed, this can be shown via a 'transformation' which is shown as a note with the stereotype <<transformation>> under which is written Order.Cost. This can be done in EA through Notes, but is there any way to describe this 'semantically' to EA. So that EA 'understands' that <<transformation>> is more than a note attached with an arrow?
You can add a stereotype to a Note via the back door: the Properties Window [Alt+1].  If that's enough semantics - you're done.  If not, then EA won't (I believe) do any more.  You'll have to generate some automation to do that.


Uml Process / Re: Ownership "Dot"
« on: November 28, 2006, 03:59:35 pm »
An association end has to be owned by something.
OK...  You got me bang to rights, Mr Holmes...   ;D

But surely the dialog control is misnamed... It should be named: [x] Classifier Owned - since, by your own definition, an AssociationEnd is Always owned by something...


I guess the same then applies with the DB Relationships (with the proviso that the owning Classifier is inversed).  My view is that if the Database notations are used, the additional UML ownership dot shouldn't be displayed.

Uml Process / Re: Ownership "Dot"
« on: November 28, 2006, 03:13:19 pm »
Yes, that's the section that I was referring to about the conventions used.

There is no doubt that UML does not mandate the use of the ownership dot.  This is stated in section 7.3.3 (page 41).
My point is there is no way to elect (or not) the notation at a repository level.  (see below)
EA is simply allowing the user to explicitly show ownership on a per connector basis.
We want to constrain our models more globally...
Further, in response to your assertion that if a role is specified then ownership should be automatic.  If you look at the example diagram on that page you will see that having a role specified does not mean that ownership is implied.
Well I would argue that the token endA and endB need not be roles - but merely labels for explanatory purposes.

Notwithstanding that, as Jim Shaw asked (if roles don't signify ownership) what does ownership signify?  I concede that ownership does not require role specification, but I assert that specifying a role implies ownership.


Uml Process / Re: Ownership "Dot"
« on: November 28, 2006, 02:11:56 pm »
UML does not mandate the use of the ownership dot, and neither does EA.

I'm also not convinced that a role means that the property is owned by the opposite classifier.  If I look at the associations that appear in the UML specification (which as discussed in a separate thread uses a different convention for ownership) I see roles specified when ownership doesn't appear to exist.
Hi Simon,

There's some fine print on page 17 of the UML 2.1 specification:
The following conventions are adopted for all metamodel diagrams throughout this specification:
• An association with one end marked by a navigability arrow means that:
• the association is navigable in the direction of that end,
• the marked association end is owned by the classifier, and
• the opposite (unmarked) association end is owned by the association.
(NOTE: This convention was inherited from UML 1.x and was used in the initial versions of the specification because there was no explicit notation for indicating association end ownership. Such a notation was introduced in revision 2.1 (see the notation subsection of the Association metaclass on page 37) but was not applied to the diagrams in the specification due to lack of tool support. In accord with the new notation, the ownership of an association end by the association would continue to be shown by leaving the end unmarked, but the ownership of an end by the classifier would be shown by marking that classifier-owned end with a dot.)
• An association with neither end marked by navigability arrows means that:
• the association is navigable in both directions,
• each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association).
[size=10](my emphasis)...[/size]

In other words, the specification will be self inconsistent...  (diagrams versus text).

I agree that there is some doubt as to whether UML explicitly mandates the dot (although the fine print above is strongly indicative).  Nevertheless, it should be a repository (and/or diagram option) and, if so requested, should be automatic where a role is specified.


Uml Process / Ownership "Dot"
« on: November 27, 2006, 10:30:12 pm »
In the topic: [size=13]Is a Association a Method?[/size] there is mention of the Ownership "dot" that UML 2 introduced.  EA supports this dot, to an extent.  However, there doesn't appear to be sufficient support for it.  If you check [X] Owned then EA will draw the dot for you.  That is, if you check the Target Role, then it will place the dot at the destination end of the Association (and vice versa).

As I mention in the other topic, it seems to us that if a particular AssociationEnd has a role defined, then the [X] Owned checkbox should be checked automatically.

We'd welcome feedback on this before formally requesting same from Sparx.

In addition, in [size=13]DB relationships vs UML Associations[/size] I note that DB RelationshipEnds are the inverse UML AssociationEnds.  In DB modelling, it is not really relevant to discuss the Ownership of the end as it is specified by definition.  If the Edge is a DB relationship, should the [  ] Owned checkbox be disabled and unchecked?


Uml Process / Re: Is a Association a Method?
« on: November 27, 2006, 02:17:33 pm »
In a CIM, but also in the context of this thread, what does "ownership" mean?  What difference, to the modeler, does it make which element "owns" an association end or "owns" a role?
Hi Jim,
I don't think the model level affects the ownership property.  As to what it means, my subsequent post should have sorted that.


Uml Process / Re: Is a Association a Method?
« on: November 26, 2006, 02:14:45 pm »
What are you talking about?   ???   If I check that checkbox I get the ownership dot drawn.  I have since the checkbox was introduced.
oops!!  Mea culpa...  I didn't have a copy of EA to check...  I should have waited...   :-[

Nevertheless, I believe my observation regarding the ownership and roles is still valid.

You can have the dot without the role, but is you have the role you must have the dot.


Uml Process / Re: Is a Association a Method?
« on: November 24, 2006, 11:42:21 pm »
Is this where we should have the black dot (where the line connects with the classifier) ?

EA doesn't (yet) support the ownership dot.   The check-box is there to support it when it comes. [Edited in the light of subsequent postings...]  My comments related to the fact that if you selected a role, then you are specifying that the End is owned.  Technically, EA should check that box automatically if you select a role.  Sparx have recently conceded that they should (and will) be synchronizing owned AssociationEnds and Attributes better.  In the meantime - they have (with build 800) added some cross-checking.  This should be included (see below).

I don't know how familiar you are with modelling tools in general, but for the most part, when a tool manufacturer says they support a particular version of a standard they usually mean "What is the absolute minimum I can do and still get away with saying I support it...".

Sparx are no worse than others and better than most...

Put in a formal change request - both for the dot and the checkbox.


Uml Process / Re: Is a Association a Method?
« on: November 24, 2006, 05:17:31 pm »

I don't know enough about Java; but 'Getters' and 'Setters' are methods... can remember something about being good encapsulation practise, before we got C# and first class Properties. ::)

And I haven't quite worked out 2.1 'Owned end' options yet; if it's own then the end belongs to the class otherwise the association; presumably some kind of accessor function would be needed.

Doe's UML say anything about how you implement association in a runtime?

Or am I just rambling, it's gone midnight.

Hi Kevin,

In [size=13]Property Redux[/size] I agree with you that 'Getters' and 'Setters' are just methods (my emphasis).

As to owned Ends...  If the AssociationEnd has a Role, then that End is owned by the Classifier at the other End.  (That's why the dropdown on the Roles shows the opposite End's attributes - but see: [size=13]DB relationships vs UML Associations[/size]).  If the Association has no role on that End, then the End is owned by the Association.


Uml Process / Re: Is a Association a Method?
« on: November 24, 2006, 04:16:05 pm »
An Association is a link between two objects.  It is definitely not a method.  Therefore, one would not find it in the project browser.  Links appear as a line between the two objects in a diagram.  As normally implemented in code, and depending on the navigation directionalities, links appear as attributes in the associated objects.

I'm really surprised to hear that RSM treats associations as methods.
Most modelling tools DO show Associations in the browser (typically below methods).  They appear twice - once for each end.  That's probably what Ralph is referring to.

When you first come across to EA, it is a bit of a shock not to see them there...  EA's UI (Unique Interface) strikes again.  However, it must be said, that after a while you don't really miss them not being there too much, as other windows DO show them (Hierarchy window [Ctrl+Shift+4]).  But since you can't get at their properties through these windows, it doesn't quite give you the same functionality as the other products.


Uml Process / Re: how to copy and paste a whole sequence digram
« on: November 23, 2006, 02:38:28 pm »

I want to know, how I can copy a whole sequence diagram within the messages (not only the lifelines)? Any idea?
Using EA 6.5.797

We've had some success doing it via queries directly to the DB.

(usual caveats).

As I've said elsewhere, Sequence diagrams are distinctly different from most others.  If you need more help - just ask.


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