Displaying items by tag: diagram
Applying Layers to Diagrams in EA 15.1
Diagram Layers
As I'm sure we all know by now EA 15.1 is available for registered users to get to grips with. Like a kid in a candy store I went & grabbed it right away so that I could play with one of the new features in particular...diagram layers.
I was particularly keen to get to grips with this feature as recently I have been building up some beefy BPMN 2.0 Collaboration diagrams for some of our internal processes here at Dunstan Thomas. The challenge I was facing was how do I communicate a large process to a stakeholder that does not understand the notation (or any notation) without making their brain explode? Up until now I had resorted to explaining the process one logical path (and the branches therein) at time and walking through step by step. This works but it's not ideal...luckily some of our favorite Australian developers have had an absolutely great idea of being able to add layers to our diagrams (of our own specification) that will then allow us to toggle said layers on and off, thereby hiding any elements not contained by the layer we are focussing on.
I have found this invaluable already in communicating with non-technical stakeholders larger diagrams as I can temporarily hide anything I am not currently presenting and thus removing the risk of an overwhelmed stakeholder losing interest.
I have put together a short clip on how easy it is to apply layers to your diagrams with EA 15.1: https://youtu.be/cFQ0-ecSsTg
Go and download EA 15.1 and try it yourself, it is so easy to do and we are already finding client interest in this feature.
Tidy Diagrams using Neaten and Auto Route
In Enterprise Architect Version 14, Sparx Systems added functionality to simplify the process of creating neat and tidy diagrams. This tutorial highlights the "Neaten" and "Auto Route" functions, which are a handy means of tidying diagrams.
The Neaten function brings elements together based on proximity and optimized alignment. Try it out on your next diagram via Layout > Tools > Diagram Layout > Neaten.
The Auto Route function tidies the connectors on a diagram, automatically neatening up lines and re-routing them to avoid overlap, where feasible. See, Layout > Tools > Diagram Layout > Auto Route.
To learn more about diagram layout tools in Enterprise Architect, take a look at the Building Models in Enterprise Architect Guidebook, which covers more functions like Neaten and Auto Route.
Copy a Diagram to the Clipboard
Copying a Diagram to the Clipboard
This tutorial is a very simple example, but also very handy when producing reports and documentation.
You can copy and paste your current diagram using the shortcut CTRL+B. It's a simple way of copying and pasting your diagrams into word processors, image manipulation tools or any 3rd party environment that can handle images.
The above image was copied using the default options and the shortcut CTRL+B.
Some preferences exist when copying diagrams to the clipboard.
- By default, Enterprise Architect places a diagram caption and border around diagrams copied to the Clipboard. To turn this off, go to Start > View > Preferences > Diagram > Diagram Frames > deselect Clipboard Images.
- Sometimes it's convenient to turn off the Opacity on Diagram Labels. That can be done from Start > View > Preferences > Diagram > Use Opaque Diagram Labels > deselect Clipboards and Files.
- Images are created in Metafile format by default. Bitmap format can be selected from Start > View > Preferences > General > Clipboard Format.
For more options exporting diagrams from EA, watch our demonstration video Diagram Export Options
Fast access to each diagram in Enterprise Architect
We have often to do with EA models we’ve never seen before. In such cases, you have either to click through the project tree (can be confusing and time-robbing) or you use some pre-defined Model Views.
The picture bellow shows how it could look like on your machine when you’ve read the article to the end.
The feature could be very helpful also in other situations and we wonder why it’s used so rarely. Using Model Views you can create access points to any elements you want independently from its position in the project browser. It can be compared with database views if you are familiar with databases.
The only thing which is a bit annoying while creating a view, you have to create a model search first. If you use the Query Builder, the created search can be used as a basis for a view without any problems. In case the functionality of the Query Builder is insufficient and you need to create an SQL query, it has to fulfill some criteria. Within your query, you need to define three fields: CLASSGUID, CLASSTABLE and CLASSTYPE, as shown in the following example:
SELECT ea_guid AS CLASSGUID, 't_diagram' as CLASSTABLE, Diagram_Type AS CLASSTYPE, Name, [Version], Author, Stereotype, CreatedDate, Diagram_Type, ModifiedDate
FROM t_diagram
WHERE t_diagram.Diagram_Type = 'Statechart'
ORDER BY ModifiedDate ASC
Diagram Views help a lot to explore unknown projects. Thus, we have created views for all common diagram types.
Feel free to download and to use them: Searches and Views
First step – open Model Search / Find in Project dialog and import the xml file that contains the definition of searches:
Second step – activate Model Views window and import the xml file that contains the definition of views:
Enjoy!
Exploring Enterprise Architect through video...part 4
Creating a Diagram
In this latest instalment in the series Phil Chudley will be looking at the basics involved in creating a diagram using Enterprise Architect.
https://www.youtube.com/watch?v=hs98ZjLqCMQ
As always all of our videos are available right now via our YouTube channel ... and don't forget to subscribe!
Set all line styles in an Enterprise Architect diagram automatically
With this script you can change set all the lines styles on a diagram at once, to your preferred style per type of connector.
In Enterprise Architect you can choose from no less then 9 different line styles for the connectors.
Unfortunately you can only choose from the first three to be the default line style for new connectors. Additionally you can also specify the default for Generalization to be Tree Style, but that is it.
For me that is not enough. I have my own habits when making UML diagrams. For most connector types I use Orthogonal – Square, but not for dependencies, use case relations and note links. For those I like theDirect style. The last exception are the control flow, state flow and object flows, for which I use Orthogonal – Rounded.
With this script I can set all the line styles on a diagram to the styles that I like. All I need to do is right click on a diagram and choose Scripts|Set Line Styles
And the script will set all the line styles to the defaults set in the script. If you would like the line styles to be set to your preferences automatically without having to run the script you can use EA-Matic version of this script.
You can set your own preferences in this section of the script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
'*********EDIT BETWEEN HERE************* ' set here the default style to be used defaultStyle = lsOrthogonalSquareTree ' set there the style to be used for each type of connector function determineStyle(connector) dim connectorType connectorType = connector.Type select case connectorType case "ControlFlow" , "StateFlow" , "ObjectFlow" , "InformationFlow" determineStyle = lsOrthogonalRoundedTree case "Generalization" , "Realization" , "Realisation" determineStyle = lsTreeVerticalTree case "UseCase" , "Dependency" , "NoteLink" determineStyle = lsDirectMode case else determineStyle = defaultStyle end select end function '************AND HERE**************** |
Free download
Video
This script has been previously featured in the webinar Introduction to Scripting with Enterprise Architect presented by yours truly.
The script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
option explicit !INC Local Scripts.EAConstants-VBScript ' Script Name: DefaultLineStyles ' Author: Geert Bellekens ' Purpose: Allows to change the linestyles to their default ' Date: 27/04/2015 ' dim lsDirectMode, lsAutoRouteMode, lsCustomMode, lsTreeVerticalTree, lsTreeHorizontalTree, _ lsLateralHorizontalTree, lsLateralVerticalTree, lsOrthogonalSquareTree, lsOrthogonalRoundedTree lsDirectMode = "1" lsAutoRouteMode = "2" lsCustomMode = "3" lsTreeVerticalTree = "V" lsTreeHorizontalTree = "H" lsLateralHorizontalTree = "LH" lsLateralVerticalTree = "LC" lsOrthogonalSquareTree = "OS" lsOrthogonalRoundedTree = "OR" dim defaultStyle dim menuDefaultLines '*********EDIT BETWEEN HERE************* ' set here the default style to be used defaultStyle = lsOrthogonalSquareTree ' set there the style to be used for each type of connector function determineStyle(connector) dim connectorType connectorType = connector.Type select case connectorType case "StateFlow" , "ObjectFlow" , "InformationFlow" determineStyle = lsOrthogonalRoundedTree case "Generalization" , "Realization" , "Realisation" determineStyle = lsTreeVerticalTree case "UseCase" , "Dependency" , "NoteLink" determineStyle = lsDirectMode case else determineStyle = defaultStyle end select end function '************AND HERE**************** sub main dim diagram dim diagramLink dim connector dim dirty dirty = false set diagram = Repository.GetCurrentDiagram 'save the diagram first Repository.SaveDiagram diagram.DiagramID 'then loop all diagramLinks if not diagram is nothing then for each diagramLink in diagram.DiagramLinks set connector = Repository.GetConnectorByID(diagramLink.ConnectorID) if not connector is nothing then 'set the connectorstyle setConnectorStyle diagramLink, determineStyle(connector) 'save the diagramlink diagramLink.Update dirty = true end if next 'reload the diagram if we changed something if dirty then 'reload the diagram to show the link style Repository.ReloadDiagram diagram.DiagramID end if end if end sub main 'gets the diagram link object function getdiagramLinkForConnector(connector, diagram) dim diagramLink set getdiagramLinkForConnector = nothing for each diagramLink in diagram.DiagramLinks if diagramLink.ConnectorID = connector.ConnectorID then set getdiagramLinkForConnector = diagramLink exit for end if next end function 'actually sets the connector style function setConnectorStyle(diagramLink, connectorStyle) 'split the style into its parts dim styleparts dim styleString styleString = diagramLink.Style styleparts = Split(styleString, ";" ) dim stylePart dim mode dim modeIndex modeIndex = -1 dim tree dim treeIndex treeIndex = -1 mode = "" tree = "" dim i 'find if Mode and Tree are already defined for i = 0 to Ubound(styleparts) -1 stylePart = styleparts(i) if Instr(stylepart, "Mode=" ) > 0 then modeIndex = i elseif Instr(stylepart, "TREE=" ) > 0 then treeIndex = i end if next 'these connectorstyles use mode=3 and the tree if connectorStyle = lsTreeVerticalTree or _ connectorStyle = lsTreeHorizontalTree or _ connectorStyle = lsLateralHorizontalTree or _ connectorStyle = lsLateralVerticalTree or _ connectorStyle = lsOrthogonalSquareTree or _ connectorStyle = lsOrthogonalRoundedTree then mode = "3" tree = connectorStyle else mode = connectorStyle end if 'set the mode value if modeIndex >= 0 then styleparts(modeIndex) = "Mode=" & mode diagramLink.Style = join(styleparts, ";" ) else diagramLink.Style = "Mode=" & mode& ";" & diagramLink.Style end if 'set the tree value if treeIndex >= 0 then if len(tree) > 0 then styleparts(treeIndex) = "TREE=" & tree diagramLink.Style = join(styleparts, ";" ) else 'remove tree part diagramLink.Style = replace(diagramLink.Style,styleparts(treeIndex)& ";" , "" ) end if else diagramLink.Style = diagramLink.Style & "TREE=" & tree & ";" end if end function function getConnectorStyle(diagramLink) 'split the style dim styleparts styleparts = Split(diagramLink.Style, ";" ) dim stylePart dim mode dim tree mode = "" tree = "" for each stylepart in styleparts if Instr(stylepart, "Mode=" ) > 0 then mode = right(stylepart, 1) elseif Instr(stylepart, "TREE=" ) > 0 then tree = replace(stylepart, "TREE=" , "" ) end if next if tree <> "" then getConnectorStyle = tree else getConnectorStyle = mode end if end function |
This article was originally published on Bellekens.com
The Well Dressed Model
Seven ways to organise your EA models so that other people can understand them
Ian Mitchell, ian@eaDocX.com
- If you have spent many hours creating a great EA Model, hopefully you want the rest of your organisation to use it as well. But how can you make it readable?
- Or maybe have you just picked-up a model which you created a few years back, only to be baffled by your own work. What exactly was this model all about, and where has all that great stuff gone ?
- Or perhaps you’ve inherited a model from someone else who isn’t available to tell you what’s in it. How are you supposed to sort out what’s complete and useful, from the ‘other stuff’?
Over the years, we’ve come across all of these several times, and have developed a few tricks to avoid them.
If you have more techniques for helping other people to understand your models, please email Ian at eaDocX dot com.
1 A Package is not a Bucket
The most important ‘thing’ in Enterprise Architect is definitely the Package. It’s also the simplest. Just a folder with stuff in it, right?
Wrong.
The Package or rather the family of Packages which you create, say more about your model than anything else. If you just use them as a bucket to put things, then you’re missing-out on a critical way to communicate the intent of your model.
Some rules for Packages:
- Sensible names. It may seem amusing to call a package ‘new stuff’, but nobody else will ever look there to find anything. If it’s ‘new stuff which was invented in the meeting..’ then call it that.
- Descriptions. A Package without a description isn’t just half-dressed, it’s practically naked. There is always something you can say about what’s in the package, where it came from, whether it’s finished or not.
I suggest that anyone who creates a package in a shared model and doesn’t add a description should buy the coffees for all of next week.
- Authors. Enterprise Architect will make the Author of the Package the person who created it. But go further, and make the Author the Owner of the information in it. So, even if someone is totally confused at what’s in the package, they can always email the author…
2 Notes, notes, notes
I’ve been teaching UML and other modelling techniques for more than 15 years, so apologies to all former students for repeating this. If you’re in that select group, can you remember the most important UML (or BPMN, or SysML..) modelling construct ?
The Note.
The humble note.
They don’t cost anything, they never run out, and they can communicate more about whyyour diagrams look the way they do than anything else.
Add them to elements, to links, to anywhere you can think of. But make sure to keep them up-to-date: a diagram with misleading notes is worse than one with no notes at all.
3 Single-purpose Packages
If you’re going to follow the rules above, and describe what’s inside each package, then having one, or a small number, of different types of ‘thing’ in a folder is sensible: it’s easier to find things, and easier to write a quick description.
This also becomes important if you are going to document your model using a document generator – either RTF or eaDocX.
A Package with one type of thing in it can be documented as a simple table, with the Package name becoming a title for the table.
4 Different things get different stereotypes
The idea of the Stereotype is one of the key ideas of UML, which EA has extended to cover all the other model types it supports. So whether you’re creating SysML diagrams, BPMN business processes or Use Cases, you can use stereotypes.
So use them.
A stereotype is just a ‘special kind of’ thing. So if you have use cases which are sometimes complete (all scenarios filled-in) then make them <<fully dressed>>Use Cases, or if not <<partially dressed>> . So a reader finding one of these will know whether it will be completed or not: they know what to expect.
The same can be true of any other element. Using a stereotype can tell your readers what they are looking at.
Stereotyping also makes it easier for documentation tools like eaDocX to change how they format their outputs. For example, a <<fully dressed>> Use Case should print its scenarios, and highlight where they are missing – that’s an error. But <<partially dressed>>Use Cases don’t need to.
5 Status is everything, or Somewhere to Play
When you read a model, probably the most common problem is that you don’t know what the status of something is: a diagram, an element, or a whole package of the model.
Is this completed, signed-off and implemented, or just some ideas I had over coffee one day?
So using the EA ‘Status’ fields (with some sensible values) is really, really useful to readers.
Why not have an area of the model which is just a sandpit? Somewhere where modellers can try things out, and to which no standards apply. Readers are not encouraged to look in these packages. Everything is work-in-progress or incomplete.
Equally, the areas which are for ‘real’ content DO obey all the local rules: packages must have descriptions, only the approved stereotypes are used etc.
6 Public and Private diagrams
The great power of EA is that it allows us to create links between all kinds of elements, depending on what kind of problem we’re trying to solve.
There are several ways to create these links: the Relationship Matrix is a quick way, but diagrams are also very common. And this creates a problem for the reader.
Are they looking a ‘proper’ diagram, which they are supposed to understand, or is this a diagram which you just created to establish some relationships, and isn’t really for public use?
So get used to naming diagrams so that this is obvious, and to prevent accidental printing of these diagrams in documents.
Pick a naming convention for ‘do not print’ documents: we add ‘hidden’ in front of the document name. We’d like to use a diagram stereotype, but that doesn’t appear in the Project Browser. So ‘My untidy diagram’ becomes: ‘Hidden – my untidy diagram’. We also tick the box in the diagram properties to “Exclude image from RTF Documents”. Both the EA RTF generator and eaDocX will take this to mean ‘don’t print in any document’.
So now you’re free to create as many untidy diagrams as you like, and readers will know to ignore them.
7 Pick a meta-model, write it down, and stick to it
This final piece of advice is really a summary of all the others.
Each idea we’ve discussed above contributes to your meta-model.
If that sounds like a scary, super-technical idea, it isn’t.
All of your EA models already have a meta-model, whether you know it or not. The meta-model just says what kinds of ‘stuff’ is in your model.
- What kinds of elements have you used? e.g Requirements and Use Cases, but not internal requirements,
- How have you linked them together?
- What stereotypes have you used, and what does each one mean?
- How have you used things like Element Tests, the Glossary, or Project Tasks?
..so not really complicated. The meta-model is just your local modelling standards.
If you want to find out what your meta-model is, use the eaDocX Model Expert. It will draw a diagram of all the element types, stereotypes and links in your model. Be prepared for a surprise! Big models can be complicated!
This is a good reason to make your meta-model clear and simple. Pick a small number of elements, stereotypes and links, and use them consistently.
Communicating the meta-model is critical: one which only you understand is no use. It MUST be written down, preferably in the model itself, and taught to all of your team.
AND kept up-to-date, as your modelling style evolves, as it will certainly do.
Model Organization with Packages and the Package Diagram
It is no coincidence that the package element in UML is represented by a folder icon, similar to directories in a file system Graphical User Interface (GUI). Packages are used to organize the elements of a model just as folders are used to organize files. The contents of a package are any kind of element that is part of a model, including other packages. Beyond that description there's not much more information on how to use packages in the UML specification. Since they are a general grouping thing, it is up to usage scenarios to suggest what the best practices are for using packages. There are some practices that apply in most situations, and more that depend upon the modeling methodology or the purpose of the model.
First and foremost, use packages to organize your model, regardless of the model purpose. Even the most trivial model quickly becomes unmanageable without some kind of organization. There is no single correct way to organize a model. A modeler may choose to organize around process or product or some combination of the two. Second, use the package diagram to provide visualizations of that organization. The model browser view below illustrates how even a simple model can begin to be confusing with no organization of the model elements.
|
In addition to being able to gather like items together to allow modelers to focus their attention on relevant elements and make those elements easier to find in the browser, packages provide a namespace for the elements they contain. Namespaces allow modelers to create unambiguous named references to each of the elements in a model. This is useful in situations such as when a modeler is evolving a system and creating an as-is and a to-be system model. It is natural to have elements named the same in each model. In order to disambiguate elements with the same name, they can be placed in different packages so that the fully-qualified names are different.
Packages can be placed on a UML package diagram. The modeler might choose to do this to present a high-level view of a model or to show relationships among the packages of elements. Three different package diagrams representing the model organization shown above are presented here. Each of these diagrams uses the optional diagram frame, showing the diagram type (pkg) and diagram name (Use Case View). Note that although the diagram and the package have the same name (Use Case View) this is not required. In the first diagram, the two high-level packages are shown. As with many other modeling situations, only the details we need are presented, and the details of the package contents are elided.
In the second diagram, the packages contained in the Actors package are shown. The labels on the Human and Non-Human package describe the namespace of the containing package. The containment relationship also serves to describe the namespace. In this example, the fully qualified name of the Actor Operator is Use Case View::Actors::Human::Operator.
In the third diagram, the contents of the packages are shown embedded in the package elements. This representation is the third presentation option found in the UML specification.
Your package diagrams will in all likelihood be some combination of each of these styles, as will your choice of organizing principles. Choose the one that is appropriate for its intended use.