Messages

1

General Board / Wireframe from existing webpage

« on: August 28, 2018, 11:40:54 pm »

I've searched the forums and online help and haven't found an answer. We have an internal tool whose UI is implemented as an HTML5-based web page. I would like to use EA's wireframing capability to document/trace from screen elements into the tables and columns in our data model (and also to Activities, Requirements, Use Cases, etc.).

Is there a way to take the existing pages/screens and automatically create a wireframe?

Obviously, I could manually create the wireframes from the existing pages. Not only would that be time consuming but also I don't have a way to automatically detect if a screen changes outside of the wireframes without again manually traversing the screens.

As a backup I'm planning to use an automated test tool like Selenium to automate some click-through scripts for the screens that have manually created wireframes. At least then we can detect when changes occur and make the corresponding changes to the wireframes.

2

General Board / Re: Deployment Diagram questions

« on: June 27, 2018, 04:19:08 am »

Hello Casey

Deployment diagram is a structural diagram that shows what things you have and how they fit together.  A node is usually a physical thing - a metal box (server, switch, RAID array etc).  Metal boxes don't have behaviors besides maybe beeping and flashing lights.  They just sit there.
Nodes deploy artifacts that are usually binary files (executables, database instances etc.).  The files also pretty much sit there.

The best way to show how the system behaves is to use a behavioral diagram: in your case I suspect an interaction diagram (sequence or communication) would be best.

If you need to show some behavior information, business rule or constraint on the deployment diagram, the best practice is to add a good ol' text note to the diagram.

More info in "The unified modeling language reference manual" (Booch, Jacobson, Rumbaugh), or The elements of UML 2.0 style (Ambler)

Cheers!

I'll have to get my hands on those books. Thanks!

3

General Board / Re: Deployment Diagram questions

« on: June 22, 2018, 11:54:00 pm »

"We've been simply using a single node using a naming convention 'Cluster'<Type><RootName><Node1Name>/<Node2Name>/etc. So example ClusterAIXFluffA/B/C. However, there are times when we'd like to specify differences in node behavior in instances of the same cluster type. So ClusterAIXFluffA/B/C is a mirrored redundant set of nodes but ClusterAIXPeanutA/B/C has a primary node with two fail-over nodes. Our engineers need to know that a node failure on ClusterFluff is automatically handled and no special code needs to be written."

In my opinion the problem is that this is not information that should described in a deployment diagram.  There are other diagrams where you can describe classifier properties, behavior and interaction logic.

Interesting. What other diagram types would you suggest?

4

General Board / Re: Deployment Diagram questions

« on: June 22, 2018, 11:52:44 pm »

Second, somewhat related, how does one best represent a cluster and its individual nodes on a deployment diagram? We've been simply using a single node using a naming convention 'Cluster'<Type><RootName><Node1Name>/<Node2Name>/etc. So example ClusterAIXFluffA/B/C. However, there are times when we'd like to specify differences in node behavior in instances of the same cluster type. So ClusterAIXFluffA/B/C is a mirrored redundant set of nodes but ClusterAIXPeanutA/B/C has a primary node with two fail-over nodes. Our engineers need to know that a node failure on ClusterFluff is automatically handled and no special code needs to be written. However on ClusterPeanut, they need to know to wait for the failover node to spin up if the primary node goes down, as well as which is the primary,secondary,tertiary node (legacy systems, amiright?). What would be the best way to model the differences and failure details between the two cluster types?

I think, that a cluster is a collection of nodes.  It has no compute resource in of itself (unlike a hypervisor).  So I think Qwerty's advice is spot on, although with what you're trying today a package may be better than a boundary.

In ArchiMate terms you'd use nodes in a grouping and then assign locations to each node.  I must admit I never use Sparx's group element because the shapescript is far harder to deal with than a boundary.

Again, thanks for the thoughtful discussion. More great information I can take back to the team!

5

General Board / Re: Deployment Diagram questions

« on: June 22, 2018, 11:46:26 pm »

querty,Mathew,Paolo:

Thanks for the very thoughtful discussion on the classifier/instance relationship WRT modeling. I can certainly understand why EA behaves the way it does, it just didn't behave the way we expected, which is why I asked the question. This is is good information that I can share with my team so thanks again!

6

General Board / Re: Data Domains

« on: June 22, 2018, 01:26:36 am »

Just closing the loop here. One of our Database Engineers was able to figure out the following:

In EA, you can use the Entity Relationship Diagram Toolbox to create a Logical model.  EA creates this as a Class Diagram with a Stereotype of “ERD_Entity”.  These have a  Type field under “RightClick/Features & Properties/Attributes…” lists just major domains like Int Boolean, Character. 

The Data Modeling tool creates a Table with a Stereotype of “table”.  Here you not only pick the domain, but you also pick a length. 

I have not figured out how to create a custom domain like ZipCode nnnnn-nnnn but I’ll bet you can.  I didn’t find anything on the ea documentation (yet…  I didn’t spend a lot of time digging).

7

General Board / Deployment Diagram questions

« on: June 22, 2018, 01:23:44 am »

I have a couple of questions on Deployment Diagrams.

First, Say I've defined a generic 'Load Balancer' as a <<device>> type and create instances of Load Balancer representing physical servers e.g. LoadBalancerPetra, LoadBalancerAlexandria. Then, realizing my mistake, I change the 'Load Balancer' type to <<node>> since that's really what it should be (if I'm not mistaken). The type correctly changes on the 'Load Balancer' parent but the instances LoadBalancerPetra and LoadBalancerAlexandria still show as type <<device>> and not <<node>>, even though I still see the 'Load Balancer' as the classifier. Shouldn't the instance types have changed to <<node>> as well?

Second, somewhat related, how does one best represent a cluster and its individual nodes on a deployment diagram? We've been simply using a single node using a naming convention 'Cluster'<Type><RootName><Node1Name>/<Node2Name>/etc. So example ClusterAIXFluffA/B/C. However, there are times when we'd like to specify differences in node behavior in instances of the same cluster type. So ClusterAIXFluffA/B/C is a mirrored redundant set of nodes but ClusterAIXPeanutA/B/C has a primary node with two fail-over nodes. Our engineers need to know that a node failure on ClusterFluff is automatically handled and no special code needs to be written. However on ClusterPeanut, they need to know to wait for the failover node to spin up if the primary node goes down, as well as which is the primary,secondary,tertiary node (legacy systems, amiright?). What would be the best way to model the differences and failure details between the two cluster types?

Thanks!

8

General Board / Re: BPMN 2.0: tags not appearing on Activity elements

« on: June 22, 2018, 12:51:39 am »

OK Well at least I'm not *that* crazy.

If we wanted to pursue a BPMN extension, would this thread list the currently accurate starting points?

9

General Board / BPMN 2.0: tags not appearing on Activity elements

« on: June 21, 2018, 11:42:31 pm »

I've searched the Sparx site extensively and haven't found a solution/answer.

We want to indicate an activity's dependent components on our BPMN diagrams so they're apparent instantly when viewing the diagram especially on HTML export. I've asked about that before in this thread. Apparently there's no direct way to accomplish that, like specifying the already-defined components as a resource.

So what we've tried as an intermediate step (among many, many other ideas) is to simply create a custom tag, like refSystem=OurComponent, to the relevant Activity elements. However, the custom tagged values don't appear on the Activity elements but do appear on other elements like basic Class elements, <<Resource>> and <<ResourceRole>> stereotyped elements, etc.

Now, before you ask, yes, we have quadruple-checked that the 'tags' is checked on the 'Feature and Compartment Visibility' dialog for all of the Activities and the diagram settings.

So, what gives? Is there something in BPMN 2.0 that explicitly disallows displaying tags on an Activity? Is there a bug in the BPMN MDG extension?

Thanks!

10

General Board / Re: Connector.SourceColumns,TargetColumns from RTF template not shown on report

« on: June 20, 2018, 05:12:44 am »

I'm afraid you'll have to use an SQL fragment to get that information into a report.

There are a number of topics that discuss the details of how the link between attributes (columns). Look for "link to element feature".

Geert

Geert can you point me to a simple example of embedding SQL into report templates? Or am I completely confused by your statement "you'll have to use an SQL fragment to get that information into a report."?

11

General Board / Re: Connector.SourceColumns,TargetColumns from RTF template not shown on report

« on: June 20, 2018, 05:10:51 am »

OK following the information in this thread I was able to brute-force the source and target column names and connector notes to appear next to one another on my (very ugly) report.

I used the element>connector>source>linked feature>{LinkedSourceFeature.Name} and element>connector>target>linked feature>{LinkedTargetFeature.Name} to get the column names.

What I found was that I had to move the two tables to the same package and run the report on that package to get to the data within those tables, i.e. the template isn't currently traversing sub-packages. So I have some further reading to do.

12

General Board / Connector.SourceColumns,TargetColumns from RTF template not shown on report

« on: June 20, 2018, 01:09:41 am »

Hello,

We're trying to get a fairly simple report that our Database Architects can give to the ETL Engineers for use in a fairly complex data migration effort here. The goal of the report is to show how the columns in an OldTable map to columns in a NewTable, and any explanatory notes to assist the ETL engineers.

So we have the following template for one of the data packages:

Code: [Select]

SOURCE TO TARGET MAPPING DOCUMENT
package >
{Pkg.Name}

diagram >
{Diagram.DiagramImg}
element >
{Element.Owner}.{Element.Name}:{Element.ParentPackage} { {Element.GUID} }
< element
connector >
Source Column Notes Target Column
{Connector.SourceColumns} {Connector.Notes} {Connector.TargetColumns}:{Connector.Type}
< connector

< diagram

connector >
{Connector.Name}:{Connector.GUID}
{Connector.SourceColumns}
{Connector.TargetColumns}

source >
{ConnSource.Stereotype}
element >
{Element.Name}:{Element.GUID}
< element
< source
< connector
< package

But in the connector section , we only see the connector Notes (and the Connectory.Type information I threw in for debugging), not the SourceColumns or TargetColumns. However in the model itself, the connector properties correctly list the source and target columns within our two tables.

Is there a way I'm missing to see that information on the reports?

13

General Board / Star Schema / Dimensional Database

« on: June 08, 2018, 09:49:44 pm »

I see this in the Q&A section of several Database Engineering Webinars:

Q: Does Enterprise Architect support dimensional models?
A: No. Enterprise Architect supports physical data modeling for relational and geospatial databases.

Is this still true? If so, how would one go about modeling a data mart implemented using a star schema?

14

General Board / Re: How to model an API architecture

« on: June 01, 2018, 11:36:46 pm »

We've modeled our ESBs and API Gateways typically as Components & Interfaces, encapsulating them within Execution Environments when appropriate. Depending on how many individual methods are exposed by the API, you can either have one Interface per method, or you can group the methods into logical sets, with each set having its own corresponding Interface object. The Components can then be dissected into Classes and the Classes linked to the corresponding Components.

Hope that helps!

15

General Board / Re: Importing Visio via MDG Add-in - how to improve import quality?

« on: June 01, 2018, 11:25:02 pm »

Thanks everyone for the advice! I'm going to start hosting a series of in-house workshops focused on diagramming and modeling in EA. I have some HOWTO-like documents and some Process Guidance diagrams created for folks new to modeling in general, and EA in particular. Hopefully that will help curtail the F.U.D. - Fear, Uncertainty, and Doubt.