What do I need to read to more effectively use Enterprise Architect?

[Kulagin]

A week ago I started reading a book Martin L. Shoemaker - UML Applied: A .NET Perspective. I choose to use Enterprise Architect because it is the best solution IMO for UML from around 7 UML tools I tried so far(modelio, edraw max, StarUML, draw.io and few others).

But I don't know how to effectively use Enterprise Architect. For example, when I start new use case diagram and I use same actors as in the previous use case diagram, I drop new actors from the toolbox list. Is there a way to create list of actors for a project and use these actors on all diagrams(so I don't drop and rename new actors on each diagram)? So then later on when I want to change the name for that actor, I can change name of that actor in the list, and it will be changed everywhere in all diagrams at once, so I don't have to go through every diagram and change it by hand.

And I would like to achieve the same with all other objects on diagrams: use cases, classes, activities, etc. So objects on the diagrams are more like objects in the code - if I rename it or if I change its definition in any way(like definition of a class), it affects all instances of it in the solution.

And I'm sure there are a lot of functions in this program that I have no idea about.

User Guide is big and I don't know where to start. Can you guys recommend what should I read to be able to create bound objects as described above? Maybe a place to start in User Guide? Or some specific articles?

What else should I read about Enterprise Architect(regarding UML modeling), to be able to create better UML diagrams?

[qwerty]

Maybe this one: https://leanpub.com/entarch. Peter has a new book, but since I'm using EA for almost 20 years I actually haven't read either in detail...

q.

[Geert Bellekens]

I think there's a book that might suit your needs (although I've never read it myself)
https://www.sparxsystems.eu/resources/ea-training-book/?gclid=EAIaIQobChMIjrT6u7bw4gIVBuJ3Ch2DrQkAEAAYASABEgJxu_D_BwE

Some companies hire a consultant such as myself to help them get started and use EA effectively

Geert

[qwerty]

I would recommend those Sparx books only if you need something heavy to support your desk...

Also I never looked really into it. I just saw it lying around on customers desks. And, honestly, I never heard a good word about the books (like "ah, that helped me" or so).

q.

[Kulagin]

Thanks for suggestions.

I would recommend those Sparx books only if you need something heavy to support your desk...

Also I never looked really into it. I just saw it lying around on customers desks. And, honestly, I never heard a good word about the books (like "ah, that helped me" or so).

q.

So what do I do? I'm not a fun of just poking around in a program without understanding how to use it. Even after I learn UML and how to create models of software solutions, I'm not gonna learn EA and its ways of doing stuff(well, I will, but only a little). Like, some programs don't even support idea of a project, so you are forced to create a bunch of unrelated diagrams in different files, that's one of the reasons I chose EA.

There are a lot of stuff in EA I don't understand how to use or what it does. Like, at the start I was just using toolbox and dropping new elements on the diagrams. So I created a lot of copies of the same things in different diagrams. Then I realized that elements in diagrams and elements in the project browser aren't the same thing and it creates links in diagrams to elements in the project browser. For me that meant that I can reuse elements in the project browser and use same element in different diagrams, and refactor stuff: edit element in the project browser or in one of the diagrams and it'll change in all diagrams and in project browser.

But that's like one thing I noticed I was doing wrong at the start. I bet there are many-many other things in EA that I'm doing wrong atm and I will only spot it after some time of creating models, and I'll have to refactor my projects again. And many things I will never spot I do wrong. It's like learning math or programming by yourself from scratch without understanding how it works and without reading books - possible but hundreds(or thousands?) times slower than if you read a book.

[Geert Bellekens]

To be honest, I never read a book about EA or followed a course on EA.
I just sort-of poked around, read the occasional help page, and sometimes asked for help on this forum.
And now (about 14 years later) I think I know a thing or two about EA 

I did have previous experience with another modelling tool (Rational Rose), so that helped a bit.

Geert

[qwerty]

Well, explaining EA is a bit of a PITA. I held courses which worked out OK since people were sitting in front of their machines and could ask. I never felt like writing a book for teaching yourself EA.

Take a look in the ebook(s) (the 2nd from Peter is more like a tutorial you would expect while his first one is more like a compendium of more or less unrelated tips) I recommended above.

q.

[Glassboy]

But I don't know how to effectively use Enterprise Architect. For example, when I start new use case diagram and I use same actors as in the previous use case diagram, I drop new actors from the toolbox list. Is there a way to create list of actors for a project and use these actors on all diagrams(so I don't drop and rename new actors on each diagram)? So then later on when I want to change the name for that actor, I can change name of that actor in the list, and it will be changed everywhere in all diagrams at once, so I don't have to go through every diagram and change it by hand.

Well the answer to your question would seem to be the Project Browser.  The first thing I recommend you do is find the Perspectives menu item and experiment with a layout that works for you.  The second thing would be to have a look at how you are storing your content.  Maybe have a look in the example project at the examples for the technologies you are using.

[Sunshine]

I've never been on a training course nor read any books on Sparx EA other than the help and user manuals. Most of my learning curve is to set myself a task then try doing it.

I guess the first thing is not to think of Sparx EA as a drawing tool but a modelling tool. So its a database that provides you with views like diagrams, lists and matrices. You have elements shown in the project explorer which can be on zero or more diagrams. If you reference one element from the project browser in many diagrams then if you change the name it will change in all the diagrams. You can also create multiple copies of an element on a diagram or in the project browser too which can lead to confusion.

Choose something you want to do like system use cases then use the look for tutorial on community site or reference user guides for help.

https://community.sparxsystems.com/
https://www.sparxsystems.com/resources/user-guides/14.0/index.html

Break the task into small steps such as ;

• Create use case
• Create Actor
• Add link between user and actor
• Add detailed description to use case
• Add scenarios to use case
• Generate Document

Once you've done that you'll be able to rip though those use cases.

Be prepared for some frustration but persevere and see it through.

[Richard Freggi]

70% of using EA correctly is just UML knowledge.  UML distilled is a good intro book, as are many other titles by Addison-Wesley.
The United Modeling Language Reference manual is the best and easiest way to find out what each UML element you will see in EA is and how it works.

You will need to read several good UML books to get the hang of it, then practice for a few months.

30% of using EA correctly is understanding how the tool works, and the user manuals + this forum do a good job at explaining it!  Still it will take you a few months to figure it out.

After making this investment in time and effort, you will see big returns in terms of your projects quality and speed.  Good luck!

[jfzouain]

Hi

I know the frustration you are going through, after using EA for more than 15 years and training users on EA in the corporate world.
I decided to publish my eBook, it gives you some inside about UML and how to create a BRD with Use Cases, Activity Diagram, etc.
Check it out.
https://leanpub.com/uml-erpworkshop

Happy reading.

[RoyC]

As Sunshine says: "I guess the first thing is not to think of Sparx EA as a drawing tool but a modelling tool."

a)  Create a 'sandpit' model and play in that so that your mistakes don't create problems in your real work
b)  Work in the (Project) Browser window first and decide what you are modeling - a Systems Engineering problem? A business process? A... what?   You need to create a project, and then one or more root nodes to contain the major components or functional areas of the model. Then you decide what lower-level containers (Packages) you need to represent and hold the more detailed components of the 'thing' you are modeling.
c)  Always ask yourself "What am I trying to represent? What is the appropriate structure to represent it? How do I do/create that in EA?" - keep your questions as specific as possible, and use the books that the other guys have recommended, the Help (it's big, so look for the words in your questions to find the relevant information) and the webinars and videos on the Sparx Systems website.
d)  Ask specific questions on this forum.
e)  Diagrams are not the model, but they provide a visual representation of whatever aspect of your model you are exploring, primarily to show how the elements of the model relate or interact with each other in a certain context. One Use Case can appear in one diagram to show how it serves certain requirements, in another to show how it relates to other Use Cases, in a third to show the Actors/roles involved in the Use Case, and in a fourth to show how the Use Case is enacted by Classes and Components. It's the one single Use Case viewed in four contexts. Or however else you want to look at it.
f)  Diagrams can also be used as a quick way to create the elements you need from the Toolbox, so that you can then see if you have the right number of the right type of element to work with in the model

That's all very rough, but you need to start somewhere in order to come up with the questions that people can quickly and easily answer. See how you go.

[timoc]

Thanks for suggestions.

I would recommend those Sparx books only if you need something heavy to support your desk...

Also I never looked really into it. I just saw it lying around on customers desks. And, honestly, I never heard a good word about the books (like "ah, that helped me" or so).

q.

So what do I do? I'm not a fun of just poking around in a program without understanding how to use it. Even after I learn UML and how to create models of software solutions, I'm not gonna learn EA and its ways of doing stuff(well, I will, but only a little). Like, some programs don't even support idea of a project, so you are forced to create a bunch of unrelated diagrams in different files, that's one of the reasons I chose EA.

There are a lot of stuff in EA I don't understand how to use or what it does. Like, at the start I was just using toolbox and dropping new elements on the diagrams. So I created a lot of copies of the same things in different diagrams. Then I realized that elements in diagrams and elements in the project browser aren't the same thing and it creates links in diagrams to elements in the project browser. For me that meant that I can reuse elements in the project browser and use same element in different diagrams, and refactor stuff: edit element in the project browser or in one of the diagrams and it'll change in all diagrams and in project browser.

But that's like one thing I noticed I was doing wrong at the start. I bet there are many-many other things in EA that I'm doing wrong atm and I will only spot it after some time of creating models, and I'll have to refactor my projects again. And many things I will never spot I do wrong. It's like learning math or programming by yourself from scratch without understanding how it works and without reading books - possible but hundreds(or thousands?) times slower than if you read a book.

On this topic, i have been finding myself switching between stages 1 through 4 of the Kübler-Ross model. The old hands on the forum are at stage 5 as far as i can tell. I also beginning to find myself with a certain amount of Stockholm syndrome, where usability/keyboard shortcut/mouse menu driven UI feels like the being back in the 1990's, still drives me nuts. This post sounds like it comes straight from stage 2, but don't get me wrong, EA is a very capable UML tool, with lots of good stuff baked in.

In my experience so far (~3-6 months of digging), the EA documentation only tells what a feature is, if it has a menu item what it does, sometimes even *how* to use a feature, it mostly of glosses over why. The PDF's I've read are all generated from the same source as the online HTML, so constant repetition is also a frustration. It is at best described as a detailed reference manual, something like the maintenance manual you might get with a new tank. Owning the tank is not the same as driving it or being able to use it for going to the store. Sure it is capable of getting you to the store, but you have to figure out so much about it and the terrain before you can even start the engine.

The current common wisdom is to get in an expert to help you get setup, which is the recommendation at a certain scale of usage, where there is presumably budget for it. The same is true for automating and extending EA to fit into your IT landscape or business processes, it takes extra time and effort. Unless you want to maintain tour own EA development capability (or enjoy it), probably best delegated out.

So it is frustrating that there is not much documentation to help you do more than build UML models, not walk-throughs on to build out your repository capabilities. You have to dig through 'examples' and reverse engineer while referring to the manual. The community site has good articles on how others use EA, but nothing from Sparx on the 'out of the box' Requirements Management process, Project Management process etc. Not even a workflow describing (or ironically a diagram describing) why (for example) Project Tasks can only be one of a hardcoded type Request, Defect or Release, and what (if any) report uses that information. If there is, i have not found it. The saving grace, is of course, that you can script EA, and it is SQL database driven, so you can bend it and the reporting engine to your own process - assuming you can invest the time and effort to do so.

As others have mentioned here, you have to set some goals and feel your way forward and document as you go - so that you can share it with the others in your organization (and the community). Again in my limited experience with a similar need, ask EA technical questions here.  For any why questions, or walk-through style documented examples, refer to the appropriate standard or the docs for other similar/competing modeling tools, and possibly leanpub recommended books.

[timoc]

In addition to RoyC's list.

g) document as you go. Rely on the axiom 'any code, document or model you created more than 3 months ago may as well have been created by someone else'. This is the triple truth when a repository may have multiple editors and a lifetime of years.
h) Version your repository. You need to define a release/publish process and update cycle. This is so you can incrementally evolve (for its users and for feedback) your repository from a bunch of related diagrams, into a source of institutional knowledge for your stakeholders.
i) Define (and document!) navigation routes through your model (using diagram navigation?). It seems to be the best practice for defining views, and cleanly separating the various stakeholder needs.

I am not sure yet myself on best practices (or how to perform!) steps, G, H and I, as i am still trying to figure it all out. They are longer term concerns, but IMHO where the value of EA lives.