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 - Richard Freggi

Pages: 1 2 [3] 4 5 ... 21
Here's hoping for a fix in EA 16.... this alone would be reason to upgrade

General Board / Re: Modelling design considerations?
« on: June 28, 2020, 01:19:50 am »
Hi Jon,

Is there a standard UML approach to capturing design considerations.

Not in UML proper. Design considerations belong to the realm of requirements, and UML doesn't do requirements. (You can't express design considerations as a use case. At least, you can, I suppose, but what a hell of a life.)

Depending on precisely how you interpret the term I'd say they should be modelled as requirements or requirement types.
If your design considerations are very generic, something like "extensibility" and nothing more, make them requirement types. You will want to nail down what exactly is meant by "extensibility" somewhere along the line.
If your design considerations are more specific, something like "it should be possible to add a new major feature to the solution with no more than six weeks' work", then that's more of a requirement in itself and you could create a DesignConsideration requirement type for it.

Another option might be to turn them into constraint types. I'm less enamored of that, since constraints aren't model elements and therefore can't be traced.



Yes design consideration are a type of requirement and/or constraint, TOGAF is a pretty good way to handle it, the key point of TOGAF requirement management is that the modeler must have the experience and skill to decide which phases  will impacted by  the requirement eg. Phase A, B. C, D, E, F... in practice you need to maintain your use case model, sequence diagram, class diagram, component diagram at conceptual and logical level consistent with the requirement (using tagged values or other Sparx mechanisms to keep track of the original requirement).  Works pretty good after you get some experience.

I think you are very lucky and in the minority to have large quantities of Visio diagrams that actually make sense, first of all individually but even more so as a group.
My experience with Visio is that it's just artwork 90% of the time and needs so much refactoring effort to be used in a real model that building it from scratch in EA is just as quick.  That's just my experience.... so I'm not placing much value on an importer.  (Excel is a different story, it's sometimes the only way to bridge gaps between incompatible tools)

Hello in EA v 1310 I find that my combined fragments move around the diagram randomly when I reopen an old diagram, or when I rearrange other messages in the diagram (both with and without ALT key to move the messages).

I tried adding a message from an actor to the fragment, or adding a gate then having a message from actor to gate and another message from gate to fragment to stop them moving around.  The gate trick seems to help a little (the actor > gate messages does not move, and the fragment moves around less, especially does not jump over the next messages)

I would like to know if different versions maybe have resolved this issue, or if there is some trick to fix it.  Thanks!

Thanks Geert!  I looked at your site before posting but somehow missed it!  Importer downloaded, thanks much!

As far as I know it's not possible to import classes, class description, their attributes and attribute description from csv, tab delimited or excel into EA.. including the MS office integration MDG or similar.  That's my understanding from reading the manuals... am I wrong?  Thanks!

p.s. my workaround would be to create a database with tables and attributes, include their comments and import that as DB reverse engineering, then do a package transformation. Bit it's a route I would prefer not to take.

Bugs and Issues / Re: Quick Linker and Activity diagrams
« on: May 22, 2020, 12:16:26 am »
There are multiple problems with your definitions in a post 15.0 world. (When metamodel constraints were introduced)

First, quicklinker rules that specify exclusive to stereotype on a non-stereotyped element are discarded. This isn't related to metamodel constraints, it is just a fix because they break everything.

Second, I think that the quicklinker is won't see the rules from non stereotyped objects with non stereotyped connectors as adding anything to the base metamodel.

You are seeing the UML control flow rule to your stereotyped actions. Not sure why these aren't showing up from Receive/Send. Likely your situation didn't get the fix to treat them as actions.

I can't reproduce a Control Flow being created when an Object Flow was intended.

Hello Eve

can you expand on your statement on the "post-15 world" and share any links to documents as to how EA 15 is materially/practically different from 13?  Especially metamodel changes got my interest.

The reason is that I am evaluating upgrading to 15 from 1310, but of course having to spend 3 weeks looking for moved menus is a major drawback, and also the benefits of V15 compared to V13 are not enough for me (based on the announcement and release notes).  No sarcasm, I'm asking in all honesty because this is a topic I need to stay current on for my work, so thanks for any guidance!

General Board / Re: No Specialize menu in EA V1310 Professional?
« on: May 08, 2020, 11:30:30 pm »
Thanks Geert, the manual for 1310 says to use Specialize, but I cannot find... as I said it would not be the first time that a feature is missing in an edition but the manual fails to mention it...
Interstingly if I enable Archimate 2 MDG there's an Archimate 2 menu in the ribbon for "Publish", but it only importa Archimate 2 format and the Open Group format is Archimate 3... my luck!

General Board / No Specialize menu in EA V1310 Professional?
« on: May 08, 2020, 11:10:28 pm »
I'd like to import the Open Group IT4IT Archimate model into EA, then extract a UML class diagram that I can use as part of our overall UML architecture for IT services.

My version is 1310 professional, I enabled Archimate MDG but I don't have the "Specialize" menu that the user manual says is needed to import Archimate xml files.  Can anyone confirm if it's not available in 1310, or not available in Professional, or hidden somewhwere in the ribbons?  I know Sparx has the bad habit of not telling you when an edition is lacking features of higher editions...

Or any workaround to import the Archimate xml file into SParx... all I need is the class diagram.

p.s. I should add that I don't know anything about Archimate...

General Board / Re: Connectors on flowchart diagram
« on: May 04, 2020, 09:12:05 pm »
Sparx is a UML tool.  If you are not going to draw UML diagrams, I recommend Powerpoint....
Sparx is a company and EA is an UML tool ;-) But basically yes, the OP should look at Visio and Powerpoint.



General Board / Re: Connectors on flowchart diagram
« on: May 04, 2020, 01:59:34 pm »
I'm trying to create a flowchart diagram.
I add 2 processes to my diagram, but there doesn't seem to be a 'flow' relationship possible.
Trying to add a connector it says a connector is not UML compliant.
Other relationships possible are all dotted lines and not the solid arrowed connector used in the user guide.
Any tips please?

Thanks, Mark

Sparx is a UML tool.  If you are not going to draw UML diagrams, I recommend Powerpoint....

General Board / Re: Diagram choice
« on: April 28, 2020, 09:36:46 pm »
to use EA well and get benefit, you MUST know UML very well.
Sparx recognizes this and has several UML guides for free in their websites.  Additionally, UML books published by o'Reilly or Addison-Wesley are a must.  Good luck!

Halloy all out there.
Very very interesting respond to my "agany" about our requirement work in my latest project.
Yes its not an error of tool, its more lack of good & sound method & proces for Requirement gathering and analyses.
As I work in public Government the Lawyers is always there  to "Correct" and "change" stuff they dont understand and some time the meaning with each requirement is "lost in translation".

In some way I dont see how we could work with an "flat" structure of all those requriement and keep all relations and categories an so on..

Anyway I got some good ideas och hopefully gather some strength from all of you to carry on my crusade to get an workeble requirement methods for my organisation what ever tool we select in the feature. So far I stand with Sparx EA.

Mr. (Ms?) Jensen, TOGAF ADM does a decent job of describing a pretty good way of dealing with requirements during all design and implementation phases.  TOGAF does it in a rather wordy and roundabout way but it's understandable because it tries to describe all possible situations in dealing with requirements, but if you read it a couple of times and try it out it gradually you will see benefits.  p.s. I don't recommend using the Sparx templates for TOGAF or any other methodology not because they are not good but because the point of any methodology is that you HAVE to pick and choose what you need in any specific situation, not just blindly follow it (TOGAF says it right at the beginning, look up 'tailoring').  Good luck!

p.s. @ Paolo: yes it's best to never meet your heroes, but a person is not their ideas and vice versa.  A moron can have a brilliant idea and a genius can have stupid ideas, happens all the time. 

I remember a statement from one of the founders of UML (I think it was Rumbaugh) that reality is not hierarchical.  We try to impose hierarchy on things because this is how we are trained to think, but it's always a square peg in a round hole because reality is not hierarchical.  This is why structured analysis with its hierarchy of functions, requirements, information etc. scales very poorly in any reasonably large project.
The whole point of object orientation is to avoid the rabbit hole of hierarchies.  1000s of requirements structured in a hierarchy sounds like something that cannot represent a business reality... I recommend keeping requirements in an Excel sheet (flat, no hierarchy) and relating each requirement to one or many model elements (use cases, classes, components, whatever object you need).  I treat the requirement as a class and assign an object of the requirement class as a child of whatever element helps to enable that requirement.  If I need to, I can run a query on t_diagramobjects joined to t_object to keep track of which elements enable which requirements and vice versa.

Pages: 1 2 [3] 4 5 ... 21