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.
Build to Manage use cases
COSMOS Main Page > COSMOS Use Cases
Contents
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