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.

Line Styles

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 the Direct style. The last exception are the control flow, state flow and object flows, for which I use Orthogonal – Rounded.

LineStylesDiagram

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

Set Linestyles menu option

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

'*********EDIT BETWEEN HERE*************
' set here the menu name
menuDefaultLines = "&Set default linestyles"

' 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

[ecwid_product store_id=”6824265″ product_id=”56907450″]

Video

This script has been previously featured in the webinar Introduction to Scripting with Enterprise Architect presented by yours truly.

The script

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

UML Best Practice: 5 rules for better UML diagrams

Following these 5 rules will make your UML diagrams easier to understand, cleaner, and more consistent.

Although that has no effect on the actual model, it will improve the communication with the stakeholders.

Rule 1: Less is more

Large diagrams containing heaps of elements actually convey less information then small focussed diagrams.
When reading such a large diagram your audience will not know what to focus on, and since there’s too much on there to actually pay attention to all elements, they will quickly give up trying altogether.

Show up with a diagram like this at your stakeholder, and you will have already lost his/her attention even before you start talking.

The diagram above is a good indication of how much, or how little, you should put on a diagram. My rule of thumb is that you need to be able to print the diagram on a single A4 sheet while keeping things readable.

Rule 2: No Crossings

This is a fairly common and well known rule. Try to avoid any two lines in your diagram to cross each other.

Uncrossing lines in your diagram sure make it more readable and understandable, but there’s more to it then that.  If you are unable to uncross the lines on your diagram then that is a sign that

  • a) there’s too much on the diagram (see rule 1 Less is more)
    It might be that you are showing two different aspects of the model in one diagram. In that case it might be better to create two different diagrams, each focused on one aspect.
  • b) there is some kind of design flaw in your model
    For some reason well designed models don’t have the crossing lines problem. I have no idea why or what it is exactly, I just noticed that a lot of the times, when I’m unable to “uncross” all the lines in a diagram, I discover a design flaw that, when fixed results in a diagram without crossing lines.
The following diagram contains exactly the same information, but has just been ordered differently as to make sure there are no crossing lines.

Rule 3: Orthogonality

It seems like a small thing, but making the lines in a diagram go only horizontal or vertical, and having all only right angles makes a diagram look better instantly.

The diagram below is uses a direct style for its connectors. they all go directly from one element to the other with a straight line.

The mere fact that the lines have all kinds of angles makes the diagram look a lot messier, and less understandable.

Below here again the same diagram, but now with all connectors styles set to orthogonal.

Exceptions to this rule are (for me) note links and all relations with use cases. For some reason they look better with a direct style.

Rule 4: Parents Up

When drawing generalization or realization hierarchies on a diagram always make sure the parent elements are higher then the child elements so the arrows always point upwards.

This rule is pretty intuitive for most UML modelers. Only now and then I encounter diagrams that don’t follow this rule and have their hierarchies upside down.

Diagrams like this, where the generalization arrows point downwards are harder to read. For some reason it takes a greater mental effort to understand this then when the arrows all point upwards.

In case you have multiple elements all descending from the same parent, it is recommendable to show the hierarchy in a vertical tree style.

Rule 5: Tidy Up

I realize this sound like a nagging mom, but for crying out loud: Tidy Up!

If you want to convey the message that your analysis is a well thought trough construction that will solve your stakeholders problems then you better show up with a nice and clean diagram.

When tidying up think about

  • Aligning elements, either by one of their sides (e.g Top) or by their centers. The latter works best when aligning vertically
  • Make elements the same size where possible

After tidying up the diagram looks a loot better

Now remember, following these diagramming rules will not make you a better analyst, nor will it result in better UML models.

But it will allow you to make a better impression when trying explain the fruits of your hard labor to your stakeholders. You will need less time explaining diagrams, and you will be able to spend more time focusing on the actual content.

More UML best practices

UML is NOT about diagrams

There seem to be a lot of misconceptions about UML in the industry, but one of the most persistent is that UML is all about diagrams.

I’ve heard/read phrases like “UML is a collection of diagrams”, and even the Wikipedia page about UML mostly talks about the different diagrams rather then the actual elements and their structure.

Well let me tell you, UML is NOT about diagrams.

Even OMG thinks so as diagrams are hardly defined in the UML superstructure specification. From the  742 pages there’s 5 pages that deal with diagrams, and there not even in the main specification document, but in Annex A.

Diagrams are tools that allow humans to edit and communicate UML models, because we limited humans are just not that good in reading or editing a vast hierarchical structure. Computers don’t have that problem. When for example a code generator reads a model to generate source code, it will completely ignore the diagrams and focus only the actual hierarchical model.

So diagrams are not essential to the content of the model. You can delete all diagrams from any model of mine and I will not have lost a single byte of model information. What I’ve lost is an effective mean to edit my model, and to communicate it to other humans, but everything is still there.

To use an analogy: Diagrams are like the GUI and Reports of  your typical administrative software. They offer a view on the data, and an access point to the software’s internal logic, but they are not part of the core of the application, and they certainly don’t contain the applications data. If we talk about the core of such software we are usually not referring to the GUI, but rather to the back-end logic and the data structure.

Am I now arguing that diagrams are not important? No! Just like the GUI and the reports, the diagrams are extremely important for any type of human interaction with the model. Messy, badly laid out diagrams lead to poor understanding of your target audience.

To conclude, UML is not about diagrams, but about interrelated elements in a hierarchical model structure, and diagrams are just an aid so we, imperfect humans, can get a grasp on the actual content.