Hi my name's Scott Hubbard from Sparx Systems. In this webinar I will present effective
Use Case Analysis in Enterprise Architect. There are many effective ways of writing use cases,
however in this webinar I will focus on the tools within Enterprise Architect. That assists
with building Use Cases, Structured Scenarios and generating Downstream artifacts. Undertaking Use
Case Analysis is a well-established technique to identify and improve system requirements
typically associated with software or process design. Use Case Analysis is an iterative design
process that examines how users can achieve system goals. On screen we have a number of
actors listed that represent key decision-makers for a Shuttle launch. We've modeled a simple
Use Case diagram that represents how the Ground Crew interacts with the Launch Pad in order
to prepare for a Shuttle launch. We've taken a user story to create a Structured Specification
in Enterprise Architect. The links to various States Uses and results. The Use Case has a basic
path or sunny day scenario and it also lists an exception path. We begin by identifying all the
main actors and interact with a Shuttle launch including the Launch Director, Console Operator,
the Shuttle Crew and of course the Ground Crew. The key decision-makers are drawn as Actors
within Enterprise Architect and can be used on a number of different Use Case diagrams.
There are a number of steps that need to be modeled in order for the Shuttle
launch to be timely cost-effective safe and meet overall mission objectives.
Mission control needs to consider factors such as weather conditions,
fuel delivery and ice and debris removal before a countdown can even commence. Enterprise
Architect can model Structured Scenarios and automatically generate Downstream artifacts.
This webinar will model a Shuttle launch and introduce effective Use Case Analysis.
We can use the model Wizard to rapidly build a Use Case from an existing pattern,
which includes sample actors and a basic use case. You can then use the Toolbox or the spacebar
to add a New Actor. Provide the actor with a detailed description about the corresponding
role. For example the Launch Director has ultimate responsibility for approving the
launch and can abort at any time. That brings us to the word “Abort” the underlined text refers
to a glossary term. You can create a glossary term via the Context Menu. Glossary definitions
help make sure everyone on the team understands the definition of terms helping to remove any
ambiguity. From the requirements definitions for example the term “Abort” is a launch event,
that is used to signal the termination of a Shuttle launch. We can now add other actors
such as a Console Operator, Shuttle Crew and the Ground Crew. Each of the key decision-makers have
now been modeled as an actor and have been placed on the diagram entitled Actor as shown on screen,
to help the audience better understand our goals. I want to briefly look at a completed
Structured Scenario. Then I'll step through the process of creating one from scratch on screen.
We have four different actors that represent key decision-makers for our Shuttle launch.
The diagram on-screen is our primary Use Case. A system boundary outlines the interface between
the Ground Crew on the use case to prepare the Launchpad opening. The properties on the use
case. I can select the Scenarios tab to see a detailed Structured Scenario that outlines each
step required by the actor and the corresponding system. In the bottom half of the dialogue we can
see our basic and alternate paths listed allowing us to easily switch between the two at any time.
We also have a series of requirements listed. Each requirement is realized by a use case. Enterprise
Architect helps to manage every aspect of Use Case Analysis including Model Traceability, Requirement
Validation, Verification and Testing. You can also use the Tools menu as an alternative method
to access the Structured Scenario Editor. You can instantly access properties of a requirement with
a single click. For example the first requirement details that all ice and debris must be removed
before the Shuttle can be placed on the Launch Pad. The second requirement indicates that only
the Launch Director can authorize for the Shuttle to be tethered to the Launch Pad and only after
the debris has been cleared. Each requirement helps reinforce the sequence of steps and ensures
that the launch is by safe and well structured. Finally we have a number of states listed that
describe the state of the Launch Pad at any given time. We can easily access definitions
for Actors and Glossary Terms to ensure that the entire team is always on the same page.
The example on-screen is a finished Structured
Specification, which can be used to generate Downstream Artifacts.
The Exception Path is currently displayed on-screen. This path only occurs in the
exceptional case, when debris has damaged the launch platform. Use the Toolbar to
return to the basic path. We can now add to a Structured Scenario by including an
Alternate Path to do this press the third icon on the Toolbar provide a suitable name
for the Alternate Path and indicate the step where the alternate joins.
Let's assume that a user story has been written by Business Analysts in a word processor. We
can copy the text and paste it directly into the description tab of our Structured Scenario Editor.
Enterprise Architect has automatically highlighted any words that appear in the project glossary.
Enterprise Architect will automatically generate out a Structured Specification using the context
menu. There are two options; the sentence delimited option is used for a paragraph of
text. Well the new line delimited option is used for bullet points or separate lines as
shown with the example on-screen. Enterprise Architect will attempt to guess if each step
is a system or user step. You can see how easy it is to rapidly build a detailed specification
based on little more than plain text. In a project we'll define each step as either a
system step represented by a computer icon or a user step represented by a stick figure. If any
of these steps have been incorrectly allocated. Simply click on the icon to override as shown
on screen. You'll also note on the bottom of the screen that the entry points adjoins
are clearly labeled for each path. Right-click within the users column and link to an existing
model element. I plan on linking this step to a functional requirement stored within my model,
that describes ice and debris removal. The first step in the scenario indicates that the Ground
Crew prepares the Launchpad by removing any debris or ice. This step now uses a Functional
Requirement that details, what needs to be done. We've also established traceability between
the use case scenario step and a functional requirement. Let's look at another example.
Step 6 indicates that the Shuttle needs to be tethered to the Launchpad by the Ground Crew. Once
again this step uses a Functional Requirement. We can link to a requirement number 2 entitled;
Tether Shuttle. Please note it is also possible to link to features or other model elements.
We can also link to two or more requirements per use. During step 12 the Ground Crew undertakes
the satellite payload change-out and the step requires requirement number 3 entitled Payload
Delivery. It is very easy to insert a use with little more than a few button clicks.
The Structured Specification has three columns to store uses results and states. This information is
valuable when managing traceability, producing downstream model artifacts and diagrams. While
I complete the process of entering additional uses. Let's briefly review what we've covered
so far. We started by using the Model Wizard to build a use case from an existing template. We
adapted the template to suit our particular needs to model a Shuttle Launch. Illustrated how easy
it is to describe actors and add terms to the project glossary to help avoid any ambiguity
in our requirements definitions. Looking at a completed model we saw how a structured scenario
could be linked to users results and states. I showed a series of requirements each of these
requirements govern a key aspect of launch or safety procedures. I've also shown, how you can
easily add an alternate path and rapidly build a structured scenario from little more than plain
text. Now let's return to our requirements. Use Case Analysis helps us to refine our requirements
definitions. The diagram ListView provides a text-based view of elements in a selected
diagram. It is displayed in the main workspace and helps to streamline the process of adding
elements such as requirements or features. We can easily add requirements with just a few mouse
clicks. While the tabular view makes editing and reviewing a breeze. We can edit the properties of
any element by their properties dialog or simply use the notes view to make changes more directly.
To access the notes view simply use a Context Menu and select Edit Notes.
With the notes view open we can now click on each requirement to review the relevant notes
in rapid succession. The example on screen now includes additional requirements to deal
with robotic arm communication and safety. Many business analysts and developers that
prefer Tech's fondness is a convenient way to rapidly document use cases or requirements.
When you're finished simply switch back to the diagram view. The diagram view is used to sort
and arrange requirements helping to clearly establish relationships and dependencies where
they exist. For example this diagram separates Launch Requirements from Safety Requirements.
If I switch back to the scenario tab you'll note that the tab is empty until I select the
relevant use case from the Project Browser. Now that we've added two additional requirements to
our model. We can use in reference page requirements from within our scenario.
For example step 9 indicates that the Ground Crew installs the Shuttle remote manipulator
system also known as a robotic arm or SRMs. This step now uses requirement 7 that establishes SRMs
Communication. Without this communication you can't load satellites into the cargo bay. Step
11 indicates that the Ground Crew must ensure that SRMs is fully retracted and this step uses
a requirement about safety to ensure that the Ground Crew are not crushed during the retraction
of the robotic arm. Once we have updated this scenario, we can save our changes. When you hover
over a use case, you'll see three icons. These icons allow you to access the Properties view
and Diagrams or locate in the Project Browser. Upon reviewing the requirements I noticed that
I failed to use the correct naming convention. I bring up the Properties for the robotic arm. I can
update and make these changes. If I switch back to the scenarios tab those changes are automatically
displayed in my Structured Specification. I shall now record and store state information
with respect to the Launch Pad. In step 1 the Launch Pad is declared “not safe”. This state
will only change after the Ground Crew has cleared the ice and debris that may have resulted from a
previous launch or adverse weather conditions. Once the Ground Crew has completed the cleanup
the Launch Pad state becomes “safe”. In step 2 each Launch Pad state has a significant impact on
Shuttle operations. For example the cargo cannot be delivered to the Launch Pad until the Launch
Pad is safe and in a cargo “ready” state debris could damage the cargo costing millions of dollars
and endangering mission objectives. Other states include when the Launch Pad is considered to be
tethered to the Shuttle or when the robotic arm is retracted. Each of these states impact what the
Ground Crew and Shuttle Crew are authorized to do. Use Case Analysis helps to improve the sequence of
events and the robustness of the corresponding requirements. It’s not until step 24 that the
Launch Pad is finally countdown ready. Once you've completed entering all of the state information.
Select the Generate Diagram button on the Toolbar and automatically generate your State diagram.
I'm choosing to preserve my existing layout. However you can choose to layout the diagram
in a format that suits your individual needs. The State diagram clearly outlines the launch events
and decisions that impact the state of the Launch Pad. This information can be analyzed to identify
safety problems or as a means to facilitate process improvement. The values in the uses
results and state columns whilst optional are significant if you want to generate a
diagram from the specification. We can generate an Activity diagram with corresponding action. As
we scroll down. We can see the various activity paths that are taken. This information can be
used in Use Case Analysis to better understand the activity required for a successful Shuttle
launch. You may choose to tidy the diagram layout and add additional detail or headings as required.
Software is expected to produce results which can be documented. In the results column of
the Structured Specification. For example step 13 produces the result that the payload weight
is confirmed. This is obviously essential for calculating fuel loads and must be passed on to
Mission Control and the crew to calculate escape velocity and achieve our mission objectives.
This information can be used in Downstream Artifacts diagrams and even Test Cases to
ensure that the system produces expected results. When you have defined a scenario,
you can automatically generate one of a number of Test Cases from it. Including a test suite
in a horizontal layout a test suite in a vertical layer an internal test case or an
external test case. You can examine each test in a test window outlining details such as:
Who run the tests. Who checked the test. The status of each test in any acceptance criteria
or input that is required to make the tests work in conjunction to Use Case Analysis. You can
manage your testing within Enterprise Architect to validate your design. The assumptions pre
and post conditions, basic alternate and exception paths are all source material
for creating good test scripts and ensuring that your software produces expected results.
Another valuable Use Case Analysis tool is the Relationship Matrix. Select Tools followed by
the Relationship Matrix to quickly identify in your requirements that are not realized or
dependent on a use case. Requirement number six determines if the Launch Pad is safe.
I can use a context menu to rapidly find this requirement in diagrams or the project browser.
I do this to investigate why it is not being used, clearly the requirement is crucial to
Shuttle safety. I can add the requirement to the exception path for when the Ground
Crew repairs the Launch Pad. This process is a powerful technique to verify that all
requirements are being implemented correctly and realized by a given use case. Finally when
I return to Relationship Matrix, I can see that requirement number six has now been satisfied.
In this webinar we have discussed, how to create an effective use case model.
We learned how to generate Structured Scenarios from plain text. Outlined how
to create glossary terms within Enterprise Architect. We successfully linked scenario
steps to users results and states within our model. We saw how easy it was to create basic,
alternate and exception paths. Finally we automatically generated Downstream Artifacts
including State diagrams Test cases and Activity diagrams. For more information
about Use Case Analysis in Enterprise Architect please visit www.sparxsystems.com