Messages

1

Suggestions and Requests / Re: Multiple instances of element in diagram

« on: February 21, 2009, 02:14:52 am »

Then remove the non-UML model types from EA. I'm talking about flowcharts, and analysis diagrams where you just need to get your artifacts on a diagram to help present a picture of your enterprise to a bunch of executives.

Sean, I accept your motivation and see your issue. However the problems of duplicate elements will remain, especially when it comes to connecting elements together, changing appearance, creating references or searching in diagrams. This is regardless the type of elements or diagrams you are creating and I assume that the efforts of implementing a clean solution (touching various aspects in the model and diagram handling) which is satisfactory for most application are rather high not justifying the cause.

Oliver

No arguments here, it's a modeling tool not a presentation tool. However as you climb the chain in an organization eventually you need presentations that even numb minded executives with marketing degrees can 'understand'. Visio it is for now.

2

Suggestions and Requests / Re: Multiple instances of element in diagram

« on: February 20, 2009, 02:45:46 am »

Add me to the want list. Even choosing a diagram like Extended->Analysis, which has no restrictions or standards gets you nowhere. So if you have to put together a business, or executive level presentation about business processes you either need to hack up your model with a folder full of 'dupes' or head off to Visio.

Be aware that having multiple objects in one diagram breaks the idea behind most UML diagrams. In the systems modeled there is always only one type of an element and everything else is an instance of that type.

Imagine having a complex activity diagram where the same activity is present in multiple branches which would require that both share the same connections. That would make the diagram totally unreadable. If I added a new connector to one it would surely be valid for the second also.
A class is a unique element type as well as a component and a use case is.
If you want to show the same element in several different aspects it is best practice to show this in a separate view (aka diagram) and do a nested/composite model structure. This also applies to business processes and requirements- not only technical UML models.

Oliver

Then remove the non-UML model types from EA. I'm talking about flowcharts, and analysis diagrams where you just need to get your artifacts on a diagram to help present a picture of your enterprise to a bunch of executives.

"Analysis Diagrams are simplified Activity diagrams used to describe high-level business processes with less UML formality."

That description (by Sparx) is false, the "Analysis" diagram is held to standards. High-level business process to me means something like "Pay Claim", or even "Claims Processing". If I want to create a diagram showing a landscape of applications (as clouds, borders, or whatever) and I want to show the business process inside them (rather then having lines all over which would imply that they all use the same business processing 'service') I can't. A DFD is another example of a diagram that has no such limitation (or real standards).

3

Suggestions and Requests / Re: Multiple instances of element in diagram

« on: February 19, 2009, 07:07:49 am »

Add me to the want list. Even choosing a diagram like Extended->Analysis, which has no restrictions or standards gets you nowhere. So if you have to put together a business, or executive level presentation about business processes you either need to hack up your model with a folder full of 'dupes' or head off to Visio.

4

General Board / Where are tagged values stored in the DB?

« on: May 06, 2009, 08:42:56 am »

I'm writing some custom reporting services reports for EA and wondered if anyone knew where tagged values (like those attached to a Node element) were stored? And how they are linked to the element.

5

General Board / Re: Is there anyway to share Styles?

« on: February 28, 2009, 05:52:56 am »

We are using the shared repository version (SQL Server). I'm the only one who sees my styles.

6

General Board / Is there anyway to share Styles?

« on: February 25, 2009, 02:59:21 am »

The styles bar is a pretty useful feature for standardizing color and look and feel across a shared model. When I create styles, other who are using the shared model don't seem to have access to them. Are these styles stored in the registry? Or a config file? Is there an easy way share these styles across a team.

7

General Board / Re: What determines what shows up in a package ele

« on: February 25, 2009, 03:33:33 am »

Tools | Options | Diagram | Behavior | Show Linked Items in Package.

Excellent. That worked well. Another related question.

I have a diagram out at the root (of a business process model). Under that I have a package called 'Business Process Library'. Then under that I have a bunch of other packages busted up by functional area (Finance, Claims, Actuarial, etc.). Under those packages I have many Business Process elements. I also have some Business Process elements at the 'Business Process Library' level.

When I drag the whole 'Business Process Library' package onto the diagram at the root of my business process model it shows all the subfolders (Finance, Claims, Actuarial, etc.) which is good. But it also drills in and lists all the business processes under those packages? Making that packages visual depiction massive. Is there a way to stop this behavior?

8

General Board / What determines what shows up in a package element

« on: February 24, 2009, 02:37:51 am »

So if I have a diagram showing the relationships between some number of packages (lets say in a component diagram). EA is kind enough to fill in the contents of each package (a line for each item or sub-package). However simple links aren't show in the package? Why not? It's part of the package. Is there a setting to flip this on?

9

Uml Process / Modeling which BPs a system implements

« on: March 10, 2009, 01:50:17 am »

What it is the accepted way of modeling a software system and the (high level) business process(es) that it performs.

Example: I have a system called SuperMax written in C#, running in an IIS host process. I have a node (?) on my component diagram that represents SuperMax.

I have some business processes defined elsewhere in my business process library. SuperMax implements a few of them, it handles 'Customer Management', 'Fulfillment', 'CRM Data Feed' lets say.

Do I create a composite (i.e. drag the BPs onto the node) ?
Or have simple links to the BPs on the diagram and use connectors (implements?) ?

Any recommendations / best practices would be great.

Thanks.