Architecture Management Use Case Scenarios

This document list all the AM use case scenarios that we consider as being of interest to this topic. This page just contains links to a more detailed description. The ordering (and even existence or non-existence) does not imply any priority or level of importance. One of the first goals of this team is to capture all the interesting use cases, and then after discussion and consensus identify key and significant scenarios to work on.

Essential scenarios to support in OSLC AM 1.0 specification

• Basic linking - Analyst links a requirement document to a discovered UML model element that supports/implements/satisfies it. This indicates that the requirement is being addressed in the design. It can be found if given the model element. The model element can be found if given the requirement.
  • Create an elaborates link from an AM resource to a requirement.
  • Remove an existing link from an AM resource to an external resource.
  • Find all AM resource with an implements relationship to a work item resource.

• Link type variance and query - A UML model describes a specification for some desired functionality. It is based on some open standard. A developer creates an implementation for a particular platform (i.e. JEE). The QA team is tasked (via a work item) to test the implementation. This team references the project specific requirements and the open standards. The QA team reviews the design and develops an appropriate plan and test cases. Each scenario, expressed as a UML sequence diagram tagged with some predefined UML stereotype must be associated with at least one test case to ensure coverage. Missing test cases show up in a report or in project viewlet for QA team.
  • Find AM resources with some specific text in the title and description.
  • Get all the known (registered) link types from the OSLC AM service provider.
  • Register new link type.
  • Update a link type description.

• Custom resource metadata - A development organization uses AM resources (both management artifacts, discrete design artifacts and their links to external ALM resources) in many ways and has special needs to associate custom meta data to these resources (i.e. client billing id, due date, ...). When viewing resource or links this information should be available for both a human with a UI or a tool programatically walking the resources.
  • Add a custom property to an existing resource.
  • Update a custom property on a link from an AM resource to CM resource.

Detailed scenario examples (using 1.0 draft spec)

The following detailed examples show how the OSLC AM service interface may be used by clients wishing to:

1. Obtain the AM service URIs.
2. Find AM resources with some specific text in the title and description.
3. Create an elaborates link from an AM resource to a requirement.
4. Update a custom property on a link from an AM resource to CM resource.
5. Remove an existing link from an AM resource to an external resource.
6. Add a custom property to an existing resource.
7. Create a new AM resource.
8. Change the title of an AM resource.
9. Find all AM resource with an implements relationship to a work item resource.
10. Get all the known (registered) link types from the OSLC AM service provider.
11. Obtain the URI for an AM resource via the resource picker.
12. Register new link type.
13. Update a link type description.

Other Related and Considered Scenarios

• Analyze and implement system functionality defined by a requirements set
• Refine design and implementation artifacts for change request
• Generate artifacts (runtime or intermediary) from models (ala MDD/MDA)
• Some simple scenarios
• AmScenariosAccenture

Useful and Related Information

• Development via Open UP

Comments