Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Build to Manage use cases

COSMOS Main Page > COSMOS Use Cases

General Requirements

  • SML -- How do we use this as an integration technology
    • What are the use cases that bring together/integrate the current "build to manage" toolkits
  • How to link this with the SML editors
    • Is this really part of the e2e use cases?
  • What information about the managed resource do we need to capture in SML?
  • What kinds of things do we need to generate out from this?
    • probkit insertion points?
    • wsdm manageability endpoints?
    • what about other monitoring infrastructures??



Use Case 1: Select code to instrument

Actor: Software Developer

System: Eclipse

Pre-Conditions: The developer knows the following information: What methods will be instrumented, what type of instrumentation to use

Short Description: The developer uses a view in Eclipse to select which methods to instrument for one type of instrumentation

Success Post-Condition: The developer receives an indication that the code has been instrumented

Failure Post-Condition: The developer receives no indication of success

Trigger: The developer selects the code to be instrumented

BASIC FLOW

1. Developer selects class/object to instrument

2. Developer selects valid options

3. Developer selects the type of instrumentation, eg ARM/JMX/CBE

4. System displays instrumentation wizard

5. Developer selects methods to instrument

6. Developer selects finish from wizard

7. System updates instrument list

8. System makes changes to instrumentation repository

9. System saves changes

10. Instrumentation wizard disappears

ALTERNATIVE FLOW

1. Developer selects class/object to instrument

2. Invalid type select

3. System displays no options

ALTERNATIVE FLOW

1. Developer selects method from editor view

2. Developer selects the type of instrumentation, eg ARM/JMX/CBE

3. System updates instrument list

4. System makes changes to instrumentation repository

5. System saves changes

Use Case 2: Select option for instrumentation

Actor: Software Developer

System: Eclipse

Pre-Conditions: The developer knows what mechanism to use for instrumentation

Short Description: The developer changes an option to select what mechanism to use for instrumentation

Success Post-Condition: The option view disappears and the selection is saved

Failure Post-Condition: The developer receives an indication that the selection cannot be saved

Trigger: The developer changes the mechanism to use for instrumentation

BASIC FLOW

1. Developer selects the BtM options view

2. Developer selects a mechanism for instrumentation, eg AspectJ, TPTP Probekit, or source editing

3. Developer pushes the OK button

4. System saves settings

5. BtM options view is no longer visible

ALTERNATIVE FLOW

1. Developer selects the BtM options view

2. Developer selects a mechanism for instrumentation, eg AspectJ, TPTP Probekit, or source editing

3. Developer pushes the Cancel button

4. System does not save settings

5. BtM options view is no longer visible

ALTERNATIVE FLOW

1. Developer selects the BtM options view

2. Developer selects a mechanism for instrumentation, eg AspectJ, TPTP Probekit, or source editing

3. Developer pushes the Apply button

4. System saves settings

5. BtM options view remains visible

Use Case 3: Run program with instrumentation

Actor: Software Developer

System: Eclipse

Pre-Conditions: The developer intends to run the program with instrumentation

Short Description: The developer runs the program with instrumentation, interacting with the instrumentation and/or checking the instrumentation output

Success Post-Condition: Interactions with the instrumentation succeed and/or the instrumentation output is acceptable

Failure Post-Condition: Interactions with the instrumentation fail or the instrumentation output is incorrect

Trigger: The developer runs the program with instrumentation

BASIC FLOW

1. Developer runs the program with instrumentation

2. Developer uses an external tool to interact with the instrumentation

3. Developer completes the program execution

4. Developer checks the output of the instrumentation

ALTERNATIVE FLOW

1. Developer exports the program with instrumentation as a package

2. Developer deploys the program package to a test system

3. Developer runs the program with instrumentation on the test system

4. Developer uses an external tool to interact with the instrumentation

5. Developer completes the program execution

6. Developer checks the output of the instrumentation

Back to the top