HistoryViewLinks to this page 2012 September 7 | 02:32 pm

This set of scenarios demonstrates the variability of link types that can be used in links between resources across domains.

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.

Goal: A developer wants to link an AM resource with a generic WWW web page that contains specifications that the design is based on. This reference helps explain the motivation and decisions made in the desig.

  1. A developer navigates to a AM resource through the system.
  2. The developer wants to create a “references” link from a service specification design model to a public document (on the web) that the design is based on. The developer invokes an action in the UI to create new links.
  3. The system returns with a prompt for the developer to either enter in a generic WWW URL (with a comment) or to select a service provider catalog that has been associated with the service that manages the AM resource.
  4. The developer enters in a generic URL and provides a short decription to accompany the link. The developer saves the link.

Goal: A developer wants to link an AM resource with a requirement

  1. A developer, with an AM resource in contex, invokes the create new link action.
  2. The system returns with a prompt for the developer to either enter in a generic URL or to select a service provider catalog that has been associated with the service that manages the AM resource.
  3. The developer selects the requirements service provider.
  4. The system invokes the resource picker for the selected service provider.
  5. The developer interacts with the resource picker to find (or create) the desired requirement document.
  6. The developer selects a link type from a list of available link types. This list of link types is provided by the AM service provider, and each link type displays a label and description (possibly as hover help). The actual link type is a URI, and used as an RDF predicate. The user can add additional information (i.e description) if the service permits.
  7. The developer creates the link.
  8. The system adds a new link (and optional annotations) from the AM resource to the requirement with the specific link type.

Goal: A member of the test team reviews a design for a test case. The design is an architecture resource (UML sequence diagram) that specifies the details of some scenario to test.

  1. The tester navigates to a AM resource (UML sequence diagram), and studies the resource. This resource outlines the requirements for the test case.
  2. The tester viewing the diagram sees links from this diagram to other resources. The tester can navigate to those resources by selecting the link. If available, extended hover help is also available for these resources.
  3. The tester can create additional links to related test case from the AM resource.

Query for resources

Goal: A developer wants to know which AM resources of a specific type that have a links of a specific type to test cases.

  1. The developer creates a new query on the service provider. The query uses the Simple Query syntax to express “All AM resources whose dc:type is sequence diagram” and to return only “the resource URI, name, and links of type oslc:testedBy”.
  2. The developer can review the results to determine which diagrams have test plans/cases and which ones do not.