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.

Topics - Paolo F Cantoni

Pages: 1 ... 64 65 [66] 67 68 ... 76
Uml Process / Naming - Remove vs Delete vs Purge
« on: April 12, 2006, 02:36:18 am »
In a number of threads in this forum (such as; Not Deleting objects in Project Viewer), I observed that the there was an inconsistency in the way EA treated the delete key.  Also how there was (again) that rather arbitrary distinction between Lines and Shapes.

In another context I got to thinking about the question of naming these types of methods.  I've come up with:

[size=16]Removal vs Deletion vs Purging[/size][/font]
[edit]Since the original publication of this Topic, I've come to the view that Purging is a better description than Destruction (the original term) for this function.  (It also has the benefit of a different first letter  ;) (Apr 2010)[/edit]
Removal merely implies the disassociation between the diagram1 collection and the item
(such as remove class from diagram - but not from model)
Note: Hiding an entire line or shape is conceptually identical to removal.  EA allows the hiding of specific Line Segment - but since they've used "Hiding" for "Removal" - they have to call the functionality Suppress (yet it's inverse is Show - rather than say Restore).

Deletion implies that although the item can be deleted, there is the possibility of recovery (say via undo)

Purging explicitly says there is no recovery from this action!

Consequently,  where an EA operation directly affects the database (and for which, at present, there is no recovery) we should use the verb Purge.  For operations such as on the diagram where there is very often an undo facility we should use Remove or Delete where appropriate.



BTW: you can only suppress one line segment on a line but there must be at least three and it can't be the origin segment.
1clarification as a result of Midnight's post below...
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

Uml Process / Visibility vs Scope
« on: July 17, 2005, 01:32:32 am »
In a number of places, EA uses the term Scope for the enumerate values:


In other places the term Visibility is used with the enumerate values:


(Note the lack of camel case)

UML2 defines VisibilityKind as:


So it's obvious that ER's scope is UML's VisibilityKind,  but what is EA's Visibility in UML terms?

Also, the Class Visibility doesn't appear on the CTF.


Uml Process / Aggregation and Association proposal
« on: February 02, 2010, 11:21:26 am »
This is a proposal for the consistent treatment of UML Associations with and without AggregationKind within EA.
(Because of its length, it is split into two parts...)
Firstly, we need to recognize that UML doesn't have what EA calls "Aggregations" and "Compositions".  UML has Associations with shared or composite aggregation.  However, we can use these terms to identify these subtypes of Associations.

In another post Allow replacement of EA Aggregations, I mention the formal replacement of EAAggregations and EACompositions with true UML Associations (and, I guess, that should probably be the eventual aim).  However this proposal takes an intermediate stance - retaining  "Aggregations" and "Compositions" but attempting to provide a degree of consistent behaviour that would make it easy to (eventually) replace them with true Associations should that be the requirement.

In a further post AggregationKind - one end concept?, I suggest that AggregationKind can, by definition, only be applied to one end of the Association at a time.

In EA, although in some contexts, we can talk of Aggregations and Compositions, there is actually only one type of arc - with type "Aggregation" that covers both forms.  It does this by means of the subtype "Weak" for shared aggregation and "Strong" for composite aggregation.  The subtype is automatically maintained by EA - depending on the AggregationKind state of both ends.

At present in EA, you can create an arc of type "Aggregation" with both ends set to AggregationKind none and EA will still render as though it was a shared aggregation (and is so designated by its subtype in t_connector).  In addition, as mentioned elsewhere, you can set both ends of the arc to AggregationKind set to not none and EA will render the the AggregationKind diamond on one end only - according to an internal Algorithm.  Arcs of type "Association", on the other hand will render both ends if AggregationKind is set.   This is, of course, inconsistent and confusing.

My proposal take the form of connecting the processing of the two type of arcs: "Aggregation" and "Association" so that a EA can provide a consistent representation and rendering.

The first part of the proposal is to ensure that EA ONLY allows AggregationKind to be set on one end of the arc.  The last change to AggregationKind would determine which end had the AggregationKind diamond.

The second part is the "unification" of both types so that an arc can change its type depending upon the settings of AggregationKind.  If both ends of the arc have AggregationKind set to none, the arc's type is set to Association.  If either end of the arc have AggregationKind set to not none, the arc's type is set to Aggregation.  The arc's subtype is set depending upon the setting of the only AggregationKind status.

In this way, EA presents a consistent view both in rendering and within the database.  Also, querying if the arc is an aggregation or not is simplified.

Naturally the Automation Interface would respond consistently.

As currently, there will need to be a global setting to control which end of the arc, the AggregationKind diamond is to be placed when drawing the arc (using either the Toolbox or the QuickLinker).  The current [X] Draw Aggregations Reversed would be replaced with [X] Draw Aggregations at Source.  EA would, by default, draw the AggregationKind diamond at the destination end - as at present.

[End of part 1]

Uml Process / AggregationKind - client end concept?
« on: January 30, 2010, 03:47:46 am »
In AggregationKind - one end concept? (which I now realise I should have started in this category), I put forward the notion that only one end of an arc should have AggregationKind set to not none at any one time.

This topic extends that idea and discusses which end it should be.

The vast majority of UML relationships have the origin (source) as the Client end and the destination (target) as the Supplier end.

So, in a meronymy (the relationship between the whole and the part) who is the client and who the supplier?  The holonym (whole) or meronym (part)?

My view, at present, is that (somewhat paradoxically) the holonym is the client and the meronym the supplier.  I take this view because (certainly for composite aggregations and most of the time for shared aggregations) the whole doesn't usually exist without at least one part.

What do others think?

PS: I'm aware that (now much) older versions of UML dictated that the target end was the end containing the AggregationKind.  I'm pretty sure that restriction has been lifted for UML2.  I'm talking here about the conceptualization of the issue.

Uml Process / Instances of Packages
« on: March 19, 2010, 05:22:47 pm »
Here's another of my "left field" questions...

For reasons that I can't disclose at present (but one could consider related to "meta-modelling"), I started playing around with "instances of Packages"...

With appropriate "surgery" I can create such beasts and EA seems to handle them OK.

Can anybody suggest any (conceptual) reason why I shouldn't be able to use them - acknowledging that Sparx can change the universe from under me?


Uml Process / Fact Models - don't...
« on: February 09, 2010, 04:27:15 pm »
It's surprising how easy it is for all of us to make assumptions...

For over twenty years, I've used the term "Fact Model" to describe what these days are known as Instance Models.  That is, models that hold explicit facts about stuff...

"Paolo uses EA";  "Sparx produces EA"; "The current version of EA is 7.5"

You can see that these facts represent tuples.

Pottering about in the Business Rules Composer I came across references to a Fact Model.  The EA Help has an example of this...

When I looked at it, I shook my head....  The Fact Model was described thus in the Help:
In Enterprise Architect a Fact Model is created as a conceptual Class diagram.
How could a Classifier level diagram display Instances?

So I went onto the Net and checked a few definitions.  EA is apparently using "Fact Model" in a common manner.  I'd never gone looking, because I "knew" what a Fact Model was...

So, can someone show me where the "Facts" are in a Fact Model?  That is, which Facts is the model modelling?

The best that my colleagues and I can come up with is that a "Fact Model" is actually a "Fact Rule Model".

[edit]Just to be perfectly clear...  I have no beef with wither Sparx or EA for using this terminology.  I'm just amused by the concept that: "a Fact Model doesn't model any facts..." ::)[/edit]

Uml Process / Directedness and Navigability of Edges
« on: January 03, 2007, 12:21:51 am »
In a related topic ([size=13]XMI Import Data Corruption/Loss in EA 6.5 (802)[/size]) Darren and I mention our view that there is a problem with the way in which EA handles the storage and rendering of edges with respect to the UML notions of Navigability and Directedness.

The [size=13]UML 2.1 Superstructure (interim)[/size] Specification in 7.3.3 Association (from Kernel) defines navigability to have three states:
  • Unspecified
  • Non-Navigable
  • Navigable

Navigable will cause an arrow head , Non-Navigable a cross and Unspecified nothing to be drawn at the appropriate end of the Association.  Thus UML specifies that Navigability is a property of the Edge (Association) End.  This is implemented in EA in the Navigability control of the Source Role and Target Role tabs of the Edge dialog.  These tabs should be, more correctly, named Origin End and Destination End.

The drawing of the arrow head implies a directedness for the edge.  If there is no arrow, it is non-directional.  If there is one arrow it is uni-directional or directed and if there are two arrows it is bi-directional.  Notice that the presence or absence of the cross is irrelevant.

A UML Association is therefore any one of non-directional, uni-directional or bi-directional

In the case of other edge types (For example, Generalization, Realization and Dependency) the allowable values for Navigability are more restrictive:  The only values are Navigable and Unspecified.  In the case of a  Notelink only Unspecified is allowed.  Generalization, Realization and Dependency are explicitly solely uni-directional whereas Notelink is solely non-directional.

When we draw an edge on a diagram, we start in one place (the origin) and draw to somewhere else (the destination).  For uni-directional association UML specifies that the end with the arrow head is the Supplier and the end without the arrow head is the Client.  It is natural that when we normally draw an edge, the origin is the Client and the destination the Supplier.  This is supported by EA for the directed edge types mentioned.  However, the support is inconsistent since the Navigability control is available for the Dependency and Realization relations, but (correctly) not for the Generalization relation.

EA, unfortunately, has a dropdown list on the General Tab of the Edge dialog called Direction which contains the values:
Unspecified, Source->Destination, Destination->Source, and Bi-Directional.  It will be apparent from the foregoing that this is a non-sequitur - that is, these values cannot follow from first principles and the UML specification.

So what does this dropdown hold?  If you experiment with the Navigability settings in the Role tabs, you will see that the Direction control is affected by the settings in the Role tabs.  The dropdown is thus a summary control for both the Navigabilities.  But the set of values shown is not correct.  The values should be:

Unspecified->Unspecified   (1)
Unspecified->Navigable   (2)

(1)  The only valid combination that apply to solely non-directional relations (such as Notelink and the like).

(2)  The only valid combination that apply to solely uni-directional relations (such as Generalization, Realization, Dependency and the like).

To make things really clear, one could replace the names by their appropriate glyphs:

Unspecified->Unspecified   -----  -----
Unspecified->Non-Navigable   -----  ---x-
Unspecified->Navigable   -----  ---->
Non-Navigable->Unspecified   -x---  -----
Non-Navigable->Non-Navigable   -x---  ---x-
Non-Navigable->Navigable   -x---  ---->
Navigable->Unspecified   <----  -----
Navigable->Non-Navigable   <----  ---x-
Navigable->Navigable   <----  ---->

For those edges with dotted lines, the ----- would be replaced with -  -  -
For those edges with closed arrowheads, the > would be replaced with |>

Thus the default drawing of a Realization would be:
Unspecified->Navigable   -  -  -  -  -  |>

EA, Unfortunately, has a menu item <context menu>|Advanced|>Reverse Direction which merely swaps the ends (that is the origin becomes the destination and vice versa).  It does not change the value of the Direction dropdown on.  One might view this as strange until one realises (as we have explained above) that the name of the dropdown is really Navigabilities.

However, if you adopt our (more correct) nomenclature, we can propose the following:

For solely uni-directional relations, the menu item should be named: <context menu>|Advanced|>Reverse Direction and it will both swap the ends and swaps the navigability values in the ends.  As a consequence the summary navigability will appear unchanged, but the rendering will be reversed.

For relations that are more flexible in their navigability (such as Associations and the like), there can be up to two menu items: <context menu>|Advanced|>Swap Origin/Destination which will swap the ends (similarly to the current item) but since the navigability is a property of the end, it does not change the navigability of the end. This affects the way in which the relation is persisted.  As a consequence the summary navigability will change, but the rendering will not.

Further, if the relation has different navigabilites in both ends, an additional item: <context menu>|Advanced|>Swap Navigabilities will swap the navigability values for the origin and destination ends.  Both the summary navigability and the rendering will change.   (If the navigabilites are the same, then swapping navigabilities doesn't change any outcome)

In the case of solely non-directional relations (such as Notelinks) it follows, as a natural consequence, that it makes sense to always persist them in the same way.  We propose that in the case of a Notelink, the Note is always stored as the origin and the other end is always the destination.  This means that where the same Note is linked to more than one destination it will be consistently stored as the origin.  This applies in the case of the other end being either a vertex or an edge.

NOTE: We believe it should be possible to refactor existing edges to be consistent with this proposal, but would have to take advice from Sparx on this.

The current EA interface for edges is:
  • less than supportive of the UML 2.1 specification than it should be
  • is to a significant extent self-inconsistent (and in the case of Dependencies violates the UML specification)
  • would appear to have impacted the underlying design of both the database values and the supporting code (such as Import/export) such that refactoring in one area breaks functionality in others

Our proposal is:
  • fully supportive of the UML 2.1 specification and first principles
  • fully self-consistent
  • would make both the database and other code much cleaner

Thoughts?  Votes?
Paolo & Darren
[size=0]©2007 Paolo Cantoni & Darren Sampson, Ripple Systems[/size]

Uml Process / WARNING: Aggregations vs Aggregate Asscociations
« on: June 07, 2005, 01:19:17 pm »
Question:  When is an aggregation NOT an aggregation?

Answer:  When it's an association with aggregationKind not equal to none.

EA, for reasons best known to itself makes a distinction between an association with the aggregation: field set to shared or composite and an aggregation.

What distinction you ask?  Aren't they the same thing?

Well, that depends...  The UML2 specification says:  
An association with aggregationKind = shared differs in notation from binary associations in adding a hollow diamond as a terminal adornment at the aggregate end of the association line. The diamond shall be noticeably smaller than the diamond notation for associations. An association with aggregationKind = composite likewise has a diamond at the aggregate end, but differs in having the diamond filled in.  (ptc-04-10-02.pdf)
But what would they know?   ???

It turns out, that if you draw an aggregation by dragging the "Compose" or "Aggregate" toolbox elements onto the diagram - you create an "aggregation" element (with the aggregation diamond at the target end).  If you change the aggregate field on the target end to to "none" the diamond remains.  Change the aggregation on the target end to composite.  Black diamond.  Change the aggregation to none - unfilled diamond.  Change the source to composite, the diamond switches to a filled diamond at the source end.  Change the source aggregation to none - unfilled diamond appears at the target end... ::)

NOTE: your experience may vary it is not certain that the same sequence of events will yield the same result.  However, the upshot is that the visual picture you see on the screen may bear NO relationship to the settings you have made within the element.

Now, draw an ordinary association.  Change the aggregation at either end.  The aggregate diamond appears at the desired end.  If you then change the aggregation on the other end to other than none you get this magical "double ended" aggregation - UML compliant?  I think not... :o

Another difference between the the "aggregation" and the "aggregate association" is the treatment of navigability arrows.  I won't go into details here, but suffice to say they behave differently...

It would appear that XMI import from other tools treats an "aggregation" as an aggregate association, whereas an XMI import from EA treats it as an "aggregation".

Can anybody tell me how I'm supposed to model consistently in such an environment? >:(

Based on the experimental evidence above, would you advise using EA "Aggregations" or sticking to "Aggregate Associations" as defined by UML? :'(


Consistency, consistency, consistencyTM

Uml Process / Target Class as Aggregate
« on: June 05, 2005, 03:53:06 am »

Below is a quote from the new Build 766 Help file:
Draw Aggregations Reversed - By default, aggregate and composite connectors are drawn in EA from Source to Target. In some modelling tools they are drawn in the opposite direction. When this option is set, EA will mimic those other tools. (ab All tools will have the parent as the target and the child as the source of the connector, that is a requirement of UML; only the direction of dragging the mouse to draw the connector is changed).

While I appreciate the need for the option (and indeed, it would be nice to be able to use it dynamically  - say CTRL+Drag will reverse the current direction);  I can't find where in the UML specifications it says that the target is the parent (aggregate) and the source is the child.

If you find the reference can you quote the section with respect to the ptc-04-10-02.pdf (Revised Superstructure) document.

Why is this important (at least to me)?

Well, for a start, if UML requires that, why do ALL tools allow you to set either end as the aggregate? ???

But, more importantly for me, I may need to internally refactor a large model I've imported into EA from Rose  - where it was originally sourced from an ER diagram.

Over the last few years I've been developing a Conceptual (Domain) Modelling technology that allows me to develop "industrial strength" domain models.  

Part of the process is the ability of the model to generate synthetic narrative by traversing the model connectors (both associations and relations).  The model contains both the name of the 'forward' and 'inverse' associations (actually called 'access functions' in the original terminology - related to ORM), but only displays the 'forward' access function name.

But which direction is "forward"?  Source to destination?
It hasn't been all that obvious to me in the past.
I standardised on deciding which access function was the "stronger" and drew the link from the "weaker" source to the "stronger" destination, and so visibly named it.  For the vast majority of the associations and aggregations in the model, this poses no problem, but most of the aggregations are named and drawn in the "wrong" direction" if the UML requirement is actually true.

I think I can locate and refactor these "errant" associations, but I'd rather be sure it needs to be done first.

Any input appreciated.


Uml Process / Navigability and aggregation
« on: April 18, 2005, 02:28:40 am »
This post is partly aimed at EA and partly at UML itself.

I've got used to drawing associations from source to destination.  (In my specialised Conceptual Modelling syntax, directionality is important - but that's another story).

Having created the association I open its properties and find source role and target (not destination) role ::) and direction (not navigability)  ::) as source and destination combinations.

Now, EA (in common with most tools) forces you to draw aggregation associations with the aggregation at the destination (target) end.  (I happen to prefer the other way but...)

The default direction (navigability) is shown as source->destination - but there is NO navigability arrow shown - when I draw the aggregation.  If I set the direction to other than source->destination (or unspecified) I get the expected navigability arrows.

Since one the explicit changes in UML2 was to explicitly highlight the differences beween unspecified navigability and the others, this needs to be rectified.

Now the hard bit...

Can anybody point me at where in the UML 2 specifications it says that aggregations have to be the drawn the reverse way around from all the other associations?
(I don't have access to the specifications at present - but from memory, I couldn't find it last time I looked as this is a particular peeve of mine)

How should aggregation associations be drawn so they are consistent?  This last is a genuine question (not rhetorical).  For example, should they be defaulted to aggregation at source, default navigability source->destination (my preferred option) or is there a more consistent way of doing it?


Uml Process / When is a Classifier
« on: January 26, 2010, 04:45:51 pm »
I've been playing a lot with instance models recently.  In that process, I investigated the relationship between the instance and its classifier.  EA allows you to take a classifier (say a component) and (by means of its inconsistent EAUI) turn it into a component instance.  Elsewhere I have mentioned a number of inconsistencies in the way instances are handled by EA but this topic is about some thougthts that one of those inconsistencies triggered.

So, it turns out that if you try to assign a classifier using the <context menu>|Advanced>|Instance Classifier... [Ctrl+L] functionality, in the list of available classifiers will be found instances - such as the component instances above - (presumably because of a bug in the filtering process).

(expletive)! I thought another EA bug - which it is.  But then my mind went back nearly 20 years to a presentation I attended in Sydney, Australia on "Classless Objects".  The thesis of the presentation was that there weren't such things as classes, just "naked" objects that could be grouped at run time according to some selection criteria.  I let the presenter get to the end of his presentation and asked him if the selection process classified the objects into groups?  He agreed it did!  So I then asked him what a class was - if not a classification of objects?

So that got me wondering again...  What is a Classifier?  Here's what the UML 2.2 Superstructure (formal) Specification says (in part) on the matter:

[size=14]7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)[/size]
A classifier is a classification of instances, it describes a set of instances that have features in common.

A classifier is a namespace whose members can include features. Classifier is an abstract metaclass.
A classifier is a type and can own generalizations, thereby making it possible to define generalization relationships to other classifiers. A classifier can specify a generalization hierarchy by referencing its general classifiers.
A classifier is a redefinable element, meaning that it is possible to redefine nested classifiers.

So, we see that the only real definition is a set of instances that have features in common.

We know that we can ascribe values to the features using the RunState.  Here's an instance of Bank Account with feature OwnerName=Paolo.  So far so good.

Suppose though, I want to show how this (particular) bank account goes through a cycle of states.  Is the set of Bank Account instances all with OwnerName=Paolo a set of instances having features in common?  I'd suggest yes!  So, does that make the original instance a classifier for this set?  Well that's the question...

What do others think?


Uml Process / Relationships between behavioural elements
« on: September 19, 2009, 09:01:10 pm »
I'm involved in a form of Business Process Modelling we're calling Programme Modelling (as in Programme of Works) (PM).  This form of modelling concentrates on the Actors and Artifacts and their relationship to the Activities.

We track the nature of the participation between the actor and the activity.  We've created a new diagram type (for our eventual MDG) called a Particigram (after Organogram - the new term for Organization Charts).  The Particigram takes an actor as it's root item and uses the relationships to the various behavioural elements to draw the links that it participates in.  

Now, as long time readers will know, I'm a big advocate of rendering implicit relationships.

So, an actor (in a Particigram) will have relationships (both explicit and implicit - derived from the explicit relationships) to behavioural elements at various levels (in the case of PM: Phase, Stage, Activity and Action).  For example, if an actor is an explicit Decider in an Action, they are an implicit Decider in the enclosing Activity, Stage and Phase.

Within the Repository, the relationships between the behavioural elements is managed by a combination of the browser (parent element) and diagrams (as has been discussed elsewhere).

Elsewhere, I've championed the rendering of these (structural)relationships on diagrams.  This is so that when two elements are placed on the same diagram, the nature of their relationship can be visualised.

So, finally, to the question at hand...

How should I render the relationship between a behavioural element and its enclosing elements?  It's clearly a meronymy - but should I use Aggregation or Nesting?

I tend to favour Aggregation since an arbitrary element can be a meronym of more than one holonym.

However, I welcome input as to which should be more accurate (or even if another relationship type might be).


Uml Process / Implicit read in CRUD Update?
« on: September 19, 2009, 11:35:53 pm »
Elsewhere, I've indicated I'm doing some modelling involving CRUD (Create, Read, Update, Delete) relationships between behavioural elements and artifacts.

I've modelled "read" separately from "update" (that is, two relationships) - but I find I'm getting sooo many relationships that the diagrams are somewhat unreadable.

I couldn't find any explicit definition, to this effect, but it seems to me that a normal update implies and implicit read.  So I can retain "read" for a read-only - no consequent update.

This would allow me to cut the number of relationships significantly.

In the unlikely event that I needed a "write-only" function (writing without a preceding read) I could extend the set to "write".


Uml Process / Consistency in assigning Classifiers
« on: December 11, 2008, 01:07:43 pm »
[Edit]See following posts... The whole topic is not relevant.  The UI already works as requested...[/Edit]I'm placing this topic here in the UML category prior to submitting a bug report to Sparx.  It's here instead of Bugs and Issues, because there are UML theoretical issues involved first.  I hope to elicit some discussion and provide a considered user view.

When you assign a type to an attribute, you are, essentially, performing the same function as assigning a classifier to an instance.  The only difference is that an attribute can have a type that isn't a classifier.

Indeed, EA actually implements this.  The text of the type in the Type control is persisted to the Type column in t_attribute.  If the Type is an existing Classifier and you've selected it from the drop-down, EA sets the Classifier column to the Object_ID of the selected Type object.

So far so good.  However, assigning a classifier to an instance uses a different control to do this.  In that classifier selection control, you get the ability to filter on namespaces and you also get additional information about the type and location (package) of the classifier you are about to select.  This is to allow you to select the correct one.

My question is:  Why can't we do that for the attributes?

In a serious model, there are often many classifiers with the same name.  In particular, if you are trying to implement OMG multi-level views (CIM, PIM PSM etc) you WILL get name ambiguation.  We do have such a model and it's really starting to hurt...  Sometimes we have as many as 6 entries for the same identifier and no way to distinguish the one we want!

We need the assigning of Classifiers to be consistently presented.  The control engaged when you type [Ctrl+L] should be used for assignment of type to an attribute (and in any other applicable places).  That is, instead of a combo box, there should be a text box and a builder button [...].  Pressing the builder button would engage the Assign Classifier from namespace control.

Consistency, Consistency, Consistency! TM[/s]

Uml Process / "Implicit" relationships (tool support?)
« on: November 14, 2008, 11:36:38 am »
One aspect of models in general, but data models in particular, is the ability to determine what the canonical model is.  The canonical model is the smallest set of vertexes (shapes, nodes) and edges (lines) that can provide the semantic richness required by the domain (and from which other semantic facts can be derived).

Specifically, in the case of data models, the canonical model represents the smallest set of tables and foreign key constraints; over which can be laid all the necessary views and joins to meet the data requirements.

Consequently, a canonical relationship is not a derived relationship.  UML provides the IsDerived property for relationships to handle this.

There are two basic mechanisms by which relationships are derived:  Transitive closure and implication via Generalization.

Derivation by transitive closure is by traversal of a set of canonical relationships.  Example:  “My manager is the manager of the organizational unit to which I am appointed”.  “My Manager” is the derived relationship and “manager of the organizational unit to which I am appointed” is the canonical path by which “My Manager” can be derived.

Derivation by implication involves some form of Generalization / Specialization.  Example: “A dog must have four legs.”  “An Alsatian is a dog.”  Therefore, by implication, “An Alsatian must have four legs.”  Similarly, “A dog is an animal.”  Therefore, by implication, “An animal may have four legs.”  (Notice the subtle change in cardinality, in the second example).

One feature of implication is that if the canonical relationship is on the same diagram as the implicit relationship, the implicit one should be suppressed.  This is not the case with the traversal derived relationship (unless one is specifically rendering only the canonical model).

The primary use of implicit relationships is during analysis.  As the diagram above says – when you drag two vertexes with an implied relationship onto the same diagram, it can raise questions.  Support for this would include the ability to easily suppress/restore the display of implicit relationships.

This topic is a starting point for possible support by EA for the notion of canonical modelling (in general) and specific support for implication.


Pages: 1 ... 64 65 [66] 67 68 ... 76