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] 2 3 ... 410
1
General Board / Re: Classic menu bar / Standard Menu Bar
« on: June 29, 2018, 04:24:56 pm »
I agree with Geert!

I'm beginning to wonder if Paolo and Geert are the same person ...  :o
Nah... We've just been "together" for longer than we both care to remember. (and qwerty makes three)

Anyway, in some 48 hours or so, I'll be able to wave to Geert as we fly over teh Channel on the way to a four week holiday in the UK (from Oz).

Happy Friday everybody!

Paolo

2
General Board / Re: Classic menu bar / Standard Menu Bar
« on: June 29, 2018, 03:59:51 pm »

But honestly, yes. The ribbons are the worst of all.


I do not agree. I think the ribbons are an improvement of the classic menu structure, especially for new users.

Downside is of course that we "oldies" have to re-learn the location of all actions/buttons.

It is just too bad they couldn't get it right the first time and decided to mix everything up again between v13 and v14

Geert
I agree with Geert!

Paolo

3
While you are at it, you can maybe try to implement the same for other types of objects in the EA world, think connectors, attributes, operations,...


Geert
Yes, that's my plan.  But first t_object!

Paolo

4
Automation Interface, Add-Ins and Tools / Last Editor - functionality
« on: June 29, 2018, 11:30:37 am »
Since it doesn't look like Sparx is going to implement it soon, we've decided to implement "Last Editor" functionality.   In an enterprise-wide environment (as I've mentioned before) the original author of an item in the repository is of only passing (and usually historical) interest.  However, the last person to edit the item s is much more important!

Since EA has only one author field, to add Last Editor functionality, we need to either
  • Hijack the Author Field
  • Add the Last Editor property as a Tagged Value
If we hijacked the Author field, we'd need to add the Original Author property as a tagged value.
We'd also probably add some timepoint properties to record the event.

I guess we'd hook into the OnPostNewXXXX and OnNotifyConttextItemModified events to support this.

Thoughts?
TIA,
Paolo

5
Not sure, it seems to work fine for me.

Is your diagram locked somehow?

Geert
I was trying it on our corporate SQL Server repository with User Security enabled (but diagram editable).  I've now tried it on an unsecured .EAP file and a .EAP clone of the Corporate repository, they both work.  I can't get at the Corporate Repository, while I'm on the bus, but I'll try later.

Thanks for the pointer.

Paolo

[Edit: Rebooted system and restarted EA on the Corporate repository.  All good now.  I noticed EA was in a funny state previously (it seemed to lock up the diagram while demonstrating Virtual Connector Ends - so maybe that was the reason]

6
The Help says:
On a diagram to a file
To create a hyperlink on a diagram to an external file, simply click on the file in a file list (such as Windows Explorer) or on your Desktop and drag it onto the diagram.
A short context menu displays with two options - 'Hyperlink' and 'Artifact'. Click on the 'Hyperlink' option to create the hyperlink on the diagram.
The link is effective immediately, and you can right-click on it to add or change properties as necessary.
Files of most types - including .sql and .ddl - are opened within the appropriate Enterprise Architect code editor.


I tried to drag a number of different types of files onto a diagram.  All I got was the "No go" glyph.  What am I doing wrong?

TIA,
Paolo

7
General Board / Re: Advice - to nest or to compose ?
« on: June 28, 2018, 11:33:29 am »
Consequently, as part of our automated processing, we unnest things that should not be nested - even (and especially) if Sparx EA incorrectly nests them.  Part of the problem is that Sparx EA only PARTIALLY supports Nesting and Visual embedding (and in my view, some of it is just WRONG) and, as a consequence, users find EA's behaviour confusing.

I think the problem is more that sometimes ArchiMate is like UML and other times it isn't, and there is no [consistent] logic to when it is and when it isn't.
No, I think it's just not been thought through before they implemented.  It's a Sparx issue, not ArchiMate.  For me, it's a "first principles" thing - as per my reply in Re: Versioning with composed components.

Paolo

8
General Board / Re: Versioning with composed components
« on: June 28, 2018, 10:49:08 am »
Hi Matthias,

The solution to your dilemma is described in Re: Advice - to nest or to compose?.  EA is incorrectly nesting your components where it should be creating (or in its failure to do so, you need to create) composition relationships.

Your question actually answers itself!  8)  You have a composition NOT a nesting relationship between the service and its components.  Just unnest the components and create the composition relationships.  You can then show the relationships on diagrams correctly and the semantics of your model will be correct.  You can even (using the still to be completed) virtual connector end technology show BOTH versions of the service on the same diagram with the common components in both!

HTH,
Paolo

9
General Board / Re: Advice - to nest or to compose ?
« on: June 28, 2018, 10:39:27 am »
You're thinking from a diagram-centric perspective not a model-centric perspective.  Create explicit relationships so anyone else creating diagrams from the model has access to "the truth".  They can choose to hide any relationships they do not want to show.

Well - I'm not.
The reason I was leaning towards 1 (ie creating explicit relationships) is to ensure that the model is complete and correct - and this seems to be the right way to go, supported by pretty much everyone who has responded.

I guess where I've been confused is with the nesting behaviour that is quite core to Sparx, at least from a project browser perspective, but doesn't seem to be explicitly captured in the model. I figured it must be there for a reason and wondered what I was missing and how I should be using it.

I think the answer is alluded to by Uffe's post - it is important if you need package behaviour. So for modelling detailed behaviour and code generation, I could see it would be useful. But not for what I am trying to achieve,

Thanks all :-)
As qwerty says, I'll have a detailed comment...  ;)

Yes, you should use explicit relationships to indicate the meronymy (relationship of the whole to part), but you MUST differentiate between the Composition relationship and the Nesting relationship.  Formally, the Nesting relationship is about access/addressing (think of file in folder system) to access the file (using the normal browser analogy) you have to traverse the folders to get to the file - thus items in Sparx EA are nested in folders (see Copy Node path to Clipboard function, also Show namespace function for diagrams).   Similarly, Ports have to nested in classes (you can't conceptually have a port without its parent class). Now there is a containment relationship (a meronymy - specifically composition) between the parent (folder/item) and the child (item/folder) but that is a consequence of the Nesting, NOT the other way around!
If you merely have a pure composition relationship between the whole and the part (such as between Car and Wheels) then that is expressed as composition only.  There is NO requirement that they be visually "nested" in a browser nor visually embedded on a diagram.  (Notice the careful separation of the two concepts).  Indeed, when considering classifier models, the same meronym (part) could be composed into multiple holonyms (wholes) - Wheels in Cars and Wheels in Aircraft.  Which one should you "nest"  under (since you can only nest in one!)?
Only at the instance model level can you (as a part) only be composed into one whole.

Consequently, as part of our automated processing, we unnest things that should not be nested - even (and especially) if Sparx EA incorrectly nests them.  Part of the problem is that Sparx EA only PARTIALLY supports Nesting and Visual embedding (and in my view, some of it is just WRONG) and, as a consequence, users find EA's behaviour confusing.

Once we had conceptually separated Nesting and Composition relationships and Visual Nesting and Visual Embedding (as 4 separate, but related concepts), we found the semantics of our models improved greatly.

HTH,
Paolo

10
General Board / Re: Lock Root Node
« on: June 27, 2018, 03:48:30 pm »
but can you elaborate on the meaning of Security Level.
Okay, okay...

I think the word level is just a hangover from an earlier stage of implementation which used levels.

My understanding is that there are 19 filtered views of the model and one complete view. Each element will be in either 1 filtered view or all of them.
Did you mean that each element will be in either 1 filtered view or the complete view.
Or did you mean that by default an element is in all views but can be restricted to just one?

Still not clear enough for my pedantry.  ;)

Paolo

11
General Board / Re: Status Types per Package
« on: June 27, 2018, 12:12:40 pm »
Your surmise is correct. There is only one set of status values per project.

So - I'm looking for something like what cgreuter requested, specifically to have discrete set(s) of status field values for different types - actually for different stereotypes (using Archimate).  For example:
- Capability: Initial, Repeatable, Defined, Managed, Optimising
- Application Component: Tolerate, Invest, Migrate, Eliminate
- Project (work package): Proposed, Mandatory, Discretionary, Implemented

I note that there are some 'special case' status fields for tests and constraints (which seem to be special types of elements in the Sparx model).  However, I'm going to assume by the lack of activity and participation in this topic that there was not general interest in extending this as described above.

I gather that I could do this by extending / sub-typing the elements and adding tagged values ... ?
(My emphasis)

yes, that's what we've done.  We've also created shapescript widgets to "surface" the values on the diagram (usually in the form of small coloured rectangles).

Paolo

12
General Board / Re: Lock Root Node
« on: June 27, 2018, 12:09:28 pm »
[BUMP]

http://www.sparxsystems.com/enterprise_architect_user_guide/14.0/model_repository/visibility_levels.html
Hi Simon,

I know you've probably touched on this before, but can you elaborate on the meaning of Security Level.   The definition of "Level" in our Ontological model is: A position on a scale of intensity or amount or quality.  A relative position or degree of value in a graded group
This implies that if you can see records at one level you can see the records in the level(s) below.  However, as  I read the explanation in the link, it may be that the 'levels' (Sparx's quotation marks, not mine) are actually independent.  Thus if you can see records in Level X, you can't see records in any other level.

Which is it?

Paolo

13
Hi Uffe,

as you probably know, I've been arguing (with myself) about what does "instance" actually mean?.  Your recent posts (this and the one on Artifacts)  has got me thinking again and I may have made some progress as a result.

As you'd expect, any insight I might have has to do with the semantics involved.  Also, it involves "first principles".

As one should expect, the notion of a classifier is a mechanism to describe a number of instances having common values for one or more of the classifier's features.

In UML, a Class is a classifier from which may be generated transient run-time instances called Objects - for the purposes of running a software system.  The key thing for me here is that the Objects don't have a lifetime of their own, they are merely "alive" for the time the instance of the software.

If we are modelling the real world, however, instances have their own lifetimes (it could be argued - and I do! - that they are not tied to the lifetimes of their - potentially multiple - classifiers).  Consequently, I now believe that one should NOT use Objects for modelling instances (other than the transient instances of software systems).  Indeed one can see this in the concept of the Object's RunState - it is about the state while it is running (that is, alive, in the software system)!  This is the insight, I  believe I've just had.  I should stop using the term Object for anything other than the transient instances within the software system.

That leaves us with the notion of specific versus placeholder instances (What is an "Instance"? mentions specific vs generic, but I believe placeholder is more semantically correct) contrasted with the notion of a classifier.

I'm now of the view that, for example, modelling Business Actors (in the ArchiMate sense) each item we create of metatype Actor is either a specific or a placeholder instance (but ALWAYS an instance).  Thus we can have "John Smith" and "ABC Corporation" as specific instances and "a customer" and "a supplier" as placeholder instances (note the use of the indefinite article) where we can define a restrictive query to validate whether a specific actor instance can be substituted, as required.  "a customer" is defined as "a business entity" that has ordered (or has the ability to order) "a good and/or service" from us.  "Actor" is the metatype (Classifier) which defines which features all Actor instances can have.

So, it seems to me that EA is actually working (relatively) correctly.  Since, by the above, you should be using Restrictive (Specialized) Artifacts to create placeholder and thence specific instances.

Does that help?

Paolo

14
We're looking at possibly intercepting EA when a user attempts to visually embed one item "into" another.  However, looking at the list of Broadcast Events, I can't see anything I can leverage to detect an attempt at visual embedding.

Can anyone suggest a mechanism that we could use (even outside EA) to detect the "dropping" of one item into another or the removal of a visually embedded item out of the encompassing item?

TIA,
Paolo

15
General Board / Re: Deployment Diagram questions
« on: June 22, 2018, 11:39:50 am »
Hi Matthew,

An interesting question.  Certainly, from a theoretical point of view, the change should flow through from the Classifier to the Instance.  However, in an enterprise situation where a modeller may not be aware that others have created such instances, it should NOT flow through automatically.  The tool should observe that there are instances (optionally list them) and ask if the change should be flowed.  It may be, as qwerty suggested, that the original model may have been slightly defective and just changing the Classifier type may be injecting more issues.

Paolo

Pages: [1] 2 3 ... 410