I was inspired to write this post by Ian Mitchell from eaDocX’s use case discussion at today’s European EA User Group in London. It got me thinking about traps I’ve fallen into and tips that aren’t immediately obvious when starting out with the structured scenario editor.
1. Writing unstructured text first and generating structure
This one I think is the biggest time saver and deserves it’s spot at the top of this list. While the rigid structure of the structured editor has many benefits, free-flowing writing and focusing on content is not one of them – and in my opinion it should be the focus of effort of the first draft of content.
My advice? When writing up the skeleton of your use case stick to the standard ‘Description’ tab to get all your content on paper. Don’t worry about numbering lines, just get it down! Key here is your writing can be fluid and you can capture the detail of your use case flow without having to worry about structure.
Once you’ve got your basic content on paper its a simple two clicks to create a structured scenario. Right click –> Create Structure From Notes –> New Line Delimited.
Having gone down the path of creating scenarios solely in the structured scenario editor initially – personally I find the process to stilted for my workflow. Having to stop at the each step, add new step, move cursor, get distracted by the context references and whether EA has incorrectly assigned a Actor icon to a system step.. Maybe it’s just my workflow but I prefer to get the basic content down first – then play with the structure.
2. Context references – the magical linkage between elements
Context references is where I first saw the benefit of using the structured scenario view. It allowed me to add references to my model, enforce a standard vocabulary and promote re-usability – all really good things.
So how does it work?
In our example before we had no references, just plain text. So lets reword the ‘user’ into something more realistic, select it and right click it to see what we can do with it.
So I’ve renamed user to Librarian and now I can create a new element for this new actor I’ve defined.
Select the Use Case Toolset to find the ‘Actor’ element and notice the name has already been pre-populated for you. The actor element has been added to the project browser as well so it can be re-used – bonus!
Now that we have established this reference it will be used every time the word ‘Librarian’ is entered into the use case text – both in the main scenario or any alternate/exception flows.
This works for existing model elements as well, simply select the text as before but instead of creating a new element, select ‘Insert context reference’
3. Working with the scenario editor as a window
When you want to quickly flick between scenario content it is pain to have to open a use case via the properties, switch the scenarios tab, and view the structure, only to find it was the wrong use case element and have to open 3 more use cases and repeat the process before you find the step you were looking for.
It can handy to display the scenarios editor as a separate window rather than an inline element.
To do this in EA v10, from the ‘Element’ file menu, select ‘Scenarios and Rules’ (in v9 it can be found in ’View’ ->’More element tools’ – thanks to Rafal Dmowski for pointing this out)
This will popup the scenario and rule window as a separate dialogue which you can have open while you flick between multiple use case elements, either from the canvas or the project browser.
4. Define a glossary to give further context
If you have ever added items to EA’s severely under-utilised glossary, you will have noticed these terms appear underlined and referenced many places within EA.
To add terms to the glossary, hit Alt + 2 or select ‘Project’ –> ‘Glossary’ from the file menu and start adding terms. (Note: you may need to add a glossary type first before you can save a anything – hit the .. and enter a glossary name!)
I’ve gone and added a few terms to my sample glossary and now lets take a look at our scenario from before.
I should point out here that this is not limited to just the structured scenario but any field where the term is used – EA will underline the item to show a reference to a glossary item has been made.
So whenever the cursor is rolled over the underlined term – a definition is displayed!
5. Changing those scenario type names
Now the standard set of scenario types might be best practise and perfectly fine for your modelling needs – but I have found some engagements where the need to use further granularity for types. Previously this was fine before structured scenarios came along as you could name your scenario and type however you pleased but with structured comes rules.
To edit these types, Select ‘Settings’ –> ‘General Types’ from the file menu
and you are presented with the following screen.
This presents the default set of types which can be added to. Let’s add one called fatal exception – perhaps not a great example but it illustrates my point.
Now return to our scenario view and see what this does.
Not much other than add a new type to dropdown. EA thinks in the main 3 types still but you can trick it into accepting your new exception type.
Drill into your alternate exception by double clicking it in the ‘entry points’ dialogue.
Try changing the type of this from it’s existing ‘Alternate’ to our new ‘Fatal Exception’.
Saves ok – great news!
So while EA will only allow you two ‘create’ the two standard sub types, you can simply swap these out for your own custom types as afterwards – semi-circumventing the process.
This may go somewhere towards getting around the ‘no alternate, alternates’ problem discussed before.