The EODiSP user interface is specified through a set of use cases. This page introduces the use case concept as it is used in the EODiSP project and gives access to the detailed description of each EODiSP use case.

The EODiSP defines a set of test cases that are used to illustrate how the EODiSP should be used and to verify that the EODiSP correctly implements its requirements. The test cases are defined as instantiations of the use cases applied to the EODiSP demonstrator. Each test case is therefore associated to a use case of which it is an instantiation. Note, however, that not all use cases have a test case associated to them. Use cases that are very simple or that are defined in terms of other use cases can be easily instantiated by the user and no test case is therefore defined for them. This page gives access to the detailed description of each EODiSP test case.

At present, the EODiSP is still under development. Hence, most of the links provided in this page point to empty placeholders.

Use Case Concept

Use cases are a method to describe the interaction between an actor and the system. These entities are defined as follows:

• An actor is a user of the system. This can be a person or another system interacting with the system to achieve a desired goal.
• The system is the entity which reacts to interactions performed by an actor. It is able to achieve a desired goal. The goal which is to be achieved is specified in each use case. In the EODiSP, the system is one of the EODiSP applications.

A use case describes what happens when the actor interacts with the system. The interactions are performed in a sequential order. Therefore, a use case always starts with an actor interaction, followed by other interactions from the actor or reactions from the system. The use cases used throughout this section are goal-driven, meaning that a use case describes the actions to take (by the actor and the system) to fulfil a desired goal of the actor.

In the EODiSP context, there are three kinds of actors:

• The simulation owner (the person who wishes to use the EODiSP to perform a simulation).
• The model owner (the person who wishes to use the EODiSP to make one or more of his models available to a simulation manager)
• The person who wishes to wrap a simulation package to transform it into an EODiSP-compatible simulation model (this will often be the same as the model owner).

Note that a use case does not describe the 'look and feel' of the graphical user interface. This is an implementation issue and shall be independent of what the system should provide. A use case describes interactions on the level of services. This makes use cases independent from the implementation. It also makes them reusable because they shall apply to every implementation of the system, regardless of how the graphical user interface looks like.

The format of the uses cases in this document is the one which is proposed by Craig Larman in Applying UML and Patterns.

Since it is much easier to read short use cases which have clearly defined boundaries than to read one big use case describing every aspect of an application, the dedicated use cases for each EODiSP application have been split into smaller, more readable use cases.

Every use case description has 3 subsections. The first one is the Definitions section. It includes a table defining the attributes of the use case, such as name, level, description, etc. This information is connected with the use case and shall make its intention clear. A detailed description of every attribute is provided in the following table:

Attribute	Description
Identifier	The use case identifier.
Name	Every use case has a name which is intended to be descriptive and, if possible, unique.
Primary Actor	The primary actor is the actor having a goal requiring the assistance of the system. The use case describes how the primary actor can achieve this goal.
Level	Every use case is assigned a level. This level describes the intention of the use case. Three levels are defined. Summary Level Uses Cases represent collections of user goal level use cases. They describe how several use cases can be assembled together and in which order they can be executed. User Goal Level User Cases describe a goal which the actor can achieve by interacting with the system. These are normally the use cases of greatest interest. Subfunction Level Use Cases represent steps in a user goal use case. These use cases are described as such because they are used in different user goal use cases or because they are too complex to be directly integrated within them.
Description	A high level description of the goal which shall be achieved by the use case. It is a summary of what can be found in more detail in the text of the use case.
Pre-Condition	A description of the states in which the system has to be prior to the start of the use case.
Post-Condition	A description of the state in which the system should be after the main success scenario of the use case has been run.

The second subsection of a use case is the Main Success Scenario. This describes the interactions between the primary actor and the system to achieve the specified goal. The Main Success Scenario includes neither system failures, nor exceptions, nor alternative interactions which may be supported by the system. Therefore, it describes the interactions performed by most actors in most cases. If the main success scenario is finished, the primary actor's intended goal has been achieved. The description is given in text format. The sequence of interactions is taken into account by using a numbered list.

The third section is the Alternative Flows. This describes what can happen in addition to the main success scenario. This can be any system exception or alternative steps the primary actor can choose from. A step in the alternative flow can either occur at any time or at a certain step in the main success scenario. To highlight this, steps in an alternative flow are either marked with a '*' (asterisk) or a number. Steps which can occur at any time are marked with an asterisk. Steps which have a corresponding step in the main success scenario are marked with the same number as the one in the main success scenario plus a letter indicating different alternatives.

Some of the use cases might be very similar or even equal for different applications. This is mostly the case for use cases with level 'Subfunction'. Instead of having these use cases in one place, they are repeated for every application. This approach can be rather verbose but is considered more convenient for the reader.

EODiSP Use Cases

The table below lists all the use cases and their associated test cases defined for the EODiSP. The first column in the table gives the use case identifier, the second column gives its name, and the last column gives the name of the test case associated to the use case. Where no test case is associated to a use case, a 'n.a.' entry is made in the last column.

Use Case ID	Use Case Name	Test Case ID
UC_100	Simulation Manager Application Summary	n.a.
UC_102	Set-up Simulation Manager Application	TC_102
UC_104	Configure Simulation Experiment	TC_104
UC_106	Run Experiment	TC_106
UC_108	Load or Save Configuration	TC_108
UC_110	Experiment Abort	TC_110
UC_112	Configure Simulation Manager Application Log	TC_112
UC_200	Model Manager Application Summary	n.a.
UC_202	Set-up Model Manager Application	TC_202
UC_204	Manage Federates in the Model Manager Application.	TC_204
UC_208	Configure Model Manager Application Log	TC_208
UC_302	Generate Wrapper Code for an Excel Workbook	TC_302
UC_304	Generate Wrapper Code for an SMP2 simulation	n.a.
UC_306	Generate Wrapper Code for Matlab-Generated Code	n.a.
UC_308	Generate Wrapper Code for a Matlab Simulation	TC_308
UC_310	Generate Wrapper Code for Source Code	TC_310
UC_312	Generate Wrapper Code for a Standalone Executable	TC_312
UC_314	Generate Wrapper Code for a Data Processing Package	n.a.
UC_316	Creating a New SOM File	TC_316
UC_318	Deploy a federate	TC_318

EODiSP Test Cases

The table below lists all the test cases defined for the EODiSP. Four groups of test cases are identified, one for each of the four applications provided by the EODiSP: the simulation manager application, the model manager application, the repository application, and the support application. The first column in the table gives the test case identifier, the second column gives its name, and the third column gives a one-letter identifier of the application to which the test case refers ('S' for the simulation manager application, 'M' for the model manager application, 'R' for the repository application, and 'U' for the support application).

The test cases are described according to a two-part format. In the first part, a table gives a summary view of the test case. The summary table defines the name and objective of the test case; the actor who should execute the test case; the preconditions for the test case; and the post-conditions that should hold after successful execution of the test case. The second part gives the step-by-step procedure for executing the test case.

Test Case ID	Test Case Name	Application
TC_102	Set-up Simulation Manager Application	S
TC_104	Configure Simulation Experiment	S
TC_106	Run Experiment	S
TC_108	Load or Save Configuration	S
TC_110	Experiment Abort	S
TC_112	Configure Simulation Manager Application Log	S
TC_202	Set-up Model Manager Application	M
TC_204	Manage Federates in the Model Manager Application.	M
TC_208	Configure Model Manager Application Log	M
TC_302	Generate Wrapper Code for an Excel Workbook	U
TC_308	Generate Wrapper Code for a Matlab Simulation	U
TC_310	Generate Wrapper Code for Source Code	U
TC_312	Generate Wrapper Code for a Standalone Executable	U
TC_316	Creating a New SOM File	U
TC_318	Deploy a federate	U
TC_320	Generate an HLA Wrapper Skeleton	U
TC_402	Set-up repository manager application	R
TC_404	Register Simulation Object Models (SOM) in the remote repository	R