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

COSMOS Use Cases 1.1

COSMOS Project Home > COSMOS Wiki > COSMOS Documents > COSMOS Use Cases >

Contents

Overview

This document provides use cases for all new function that will be provided in COSMOS 1.1. All use cases that existed in the 1.0 timeframe should remain in the COSMOS Use Cases document.

Copied from COSMOS Use Cases:

The purpose of this page is to articulate the function that COSMOS will provide. While enhancement requests are typically created, they tend to be very fine grained or very macro. We intend to use this page to describe from the user's point of view how they can interact with COSMOS. This page as a way to capture the high level function offered by the COSMOS framework.

The emphasis of this page is for us to focus on the value delivered to the community by COSMOS.

We would like to be able to tie back the work we are doing to a specific use case. Therefore, we will add a link to the Use Case as a comment in the enhancement request.

This has been recorded in the COSMOS Development Process

COSMOS Use Cases for SDD

SDD Deployment

This document may be used as a starting point for developing use cases for deployment using the SDD: [1]

This document ([2]) is a subset of all considered use cases, including only those in these categories:

  1. Install an offering
  2. Uninstall an offering
  3. Install maintenance to an installed offering
  4. Rollback installed maintenance

SDD Tooling

Use Case: Create one SDD from build information

Actor: Builder

Description: The user has development work and build information from a build environment such as ant, maven, etc. The tooling will inspect this information to create one SDD.

  1. The Builder configures the plug in for the build environment.
  2. The plug-ins inspect the build information.
  3. The plug-ins parse relevant information to the BTG
  4. The BTG creates the SDD.

Enhancements: 219663

Use Case: Create a partial SDD from an artifact

Actor: Builder

Description: The user has an artifact (for example, a .jar file, a .dll, or an .rpm). The tooling will inspect the artifact and create as much of the SDD as possible. This is useful especially in the case of a 3rd party component, where the build information is not available.

  1. The Builder configures the plug in for the build environment.
  2. The plug-ins inspect the artifact.
  3. The plug-ins parse relevant information to the BTG
  4. The BTG creates the SDD.

Enhancements: 219666

Use Case: Create a plug-in for a specific build system

Actor: Plug-in Developer

Description: The user may have a build system beyond the popular rpm, msi, etc. The tooling will need to easily accommodate adding other build systems, so that metadata from those systems could be brought in.

  1. The Plug-in Developer identifies the build system.
  2. The Plug-in Developer designs plug in for the build system to the BTG.
  3. The Plug-in Developer implements design.

Enhancements: 219667

Use Case: Merge two or more SDDs that describe one product

Actor: Builder

Description: The Builder has two or more SDDs that describe one product deployment. The BTG will combine the information of all the SDDs into one resulting SDD.

  1. The Builder defines and configures the data sources for each BTG plug-in.
  2. The Builder invokes the BTG with the proper command line parameters.
  3. The plug-ins contact the data sources, parse relevant information, and create SDD fragments.
  4. The aggregator collects the SDD fragment from the plug-ins and merges them accroding to the rules.
  5. The BTG saves the resulting SDD to the file system.

Enhancements: 219647

Use Case: Defining Custom Rules

Actor: Rule Developer

Description: The Rule Developer wants to change the behavior of the combination logic. They will write rules to change the default behavior to provide a more customized version of the BTG.

  1. The Rule Developer creates one or more rules files that describe the merging of the SDDs.
  2. The Rule Developer modifies an existing rules file. The user can add a rule or remove or change an existing rule.
  3. The BTG will compile and serialize the new rules for faster running on future attempts.

Enhancements: 219648

Use case: Adding new rules files

Actor: Builder

Description: The Builder is given a set of new rules. The user modifies the BTG configuration file to include these new rules.

Enhancements: 219650

Use Case: New validation rules

Actor: Validation Rule Developer, Builder

Description: The Validation Rule Developer has additional constraints that need to be validated. He/she will add the rules to the validator before running the validation. The validator will process these new rules and throw the proper error messages when they are encountered.

  1. Validation Rule Developer creates the new validation rule
  2. Builder invokes the validator with the new validation rule.

Enhancements: 219652

Use Case: Validator provides programmatic response describing the validity of an SDD

Actor: Builder, SDD creator, SDD consumer

Description: Programs can call a method in the validator to validate their SDDs. The response returned is able to be programmatically parsed so an application can take the appropriate action.

Enhancements: 219653

Use Case: CLI for Validator

Actor: SDD Creator

Description: The SDD Creator can run validation on an existing SDD from the command line.

Enhancements: 219654

Use Case: Disabling Validation

Actor: SDD Creator, Builder

Description: The SDD Creator or Builder can disable validation during any operation.

Enhancements: 219655

Use Case: Package Generator will bundle referenced files within an SDD and the SDD into package

Actor: Package Creator

Description: The Package Creator wants to create a package that includes all the files referenced in the SDD. He/She will specify a reference location to find the files listed in the package descriptor. The packaging program will bundle the referenced files and the SDD into one package.

  1. Package Creator specifies the referenced location of the files to be packaged
  2. Package Creator invokes the Package Generator with the reference location and the SDD
  3. Package Generator creates package

Enhancements: 219656

Use Case: Package Generator will use a file list to bundle files not referenced within an SDD and the SDD into a package

Actor: Package Creator

Description: The Package Creator wants to create a package that includes files that are not listed in the SDD. He/She will create a list of the needed files and pass that information to the packaging tool. The tool will bundle the referenced files in the SDD, the additional files in the user created list, and the SDD into one package.

  1. Package Creator creates a list of the needed files
  2. Package Creator invokes the Package Generator with the file list, the reference location and the SDD
  3. Package Generator creates the package

Enhancements: 219657

Use Case: Remove artifact input type

Actor: IT administrator

Description: The functionality of expandable artifact input sets is analogous to the Plugin Development Environment within the eclipse IDE. The process of adding a new artifact type definition can be thought of in the same way as adding an editor in Eclipse.

  1. The end user clicks the Configure menu and selects "Remove Artifact Type"
  2. The runtime configuration tool examines an XML file used to track metadata about artifact types that are known and presents the name and description of each to the user
  3. The user chooses the artifacts they no longer are concerned with inspecting for input
  4. The entries are removed from the metadata file, and the corresponding inspection components are removed from the tool's resources.

Enhancements: 219702

Use Case: Add artifact input type

Actor: IT administrator/SDD Author

Description: The functionality of expandable artifact input sets is analogous to the Plugin Development Environment within the eclipse IDE. The process of adding a new artifact type definition can be thought of in the same way as adding an editor in Eclipse.

  1. The end user clicks the Configure menu and selects "Add Artifact Type"
  2. The runtime configuration tool prompts the user for the location of the inspection component (which has a well-defined structure much like an eclipse plugin). The inspection component may be located from the filesystem, a CVS repository, etc. The workflow should mirror the behviour of the Eclipse IDE when you click on "Import" from the file menu or a context menu.
  3. The entries are added to an XML file used to track metadata about artifact types that are known.

Enhancements: 219703

Use Case: Change default directory for SDD outputs

Actor: SDD Author

Description: The author wants to change the default location suggested for saving an SDD.

  1. User clicks the Edit menu and chooses "Preferences".
  2. Within the preferences window that is created, a browser is displayed for selecting the default output location. This might be the local filesystem, a CVS repository, etc.

Enhancements: 219704

Use Case: Edit creation defaults

Actor: SDD Author

Description: The author wants to change the default information which gets pre-populated into an SDD.

  1. User clicks the Edit menu and chooses "Preferences".
  2. A "Creation Defaults" link creates a window that allows user to see a searchable list of all the predefined properties that go into an SDD (Manufacturer names, contact addresses, etc).
  3. User fills in default values for any property they are interested in.

Enhancements: 219706

Use Case: Edit validation defaults

Actor: SDD Author

Description: The author wants to change the allowable value parameters which are used to validate SDDs.

  1. User clicks the Edit menu and chooses "Preferences".
  2. A "Validation Defaults" link creates a window that allows user to see a searchable list of all the predefined acceptable value ranges, etc. than can be used as values within an SDD (for example, the amount of free space required for the installation on the target filesystem).
  3. User fills in default values for any property they are interested in.

Enhancements: 219707

Use Case: Edit Content Constraints

Actor: SDD Author

Description: The author wants to change the selectable values available when creating/editing an SDD

  1. User clicks the Edit menu and chooses "Preferences".
  2. A "Content Constraints" link creates a window that allows user to see a searchable list of all the predefined acceptable value ranges, etc. than can be used as values within the unit type (which is specified with a drop down menu whose values are "Installable Unit", "Configuration Unit", and "Localization Unit").
  3. User selects or deselects values which should be hidden or disabled when editing SDDs.

Enhancements: 219708

Use Case: Create a new SDD from scratch

Actor: SDD Author

Description: The SDD Author wants to create a brand new SDD

  1. From the file menu (or context menu), the end user chooses "New Project->SDD Project:No Existing Package"
  2. The end user is prompted to pick a location where the configuration data (e.g. the SDD) will be stored.
  3. The tool creates an empty SDD
  4. The user provides input values for the SDD. Parts that are marked as uneditable in use case 7.6 are either hidden or disabled.
  5. The tool writes out editable parts of the SDD as instructed by the user.
  6. When user has completed input of raw data, they choose either "Validate", "Package", or "Deploy" from the Tools menu.

Enhancements: 219709

Use Case: Create a new SDD from some other build system (rpm, msi, etc)

Actor: SDD Author

Description: The SDD Author wants to create a brand new SDD around an existing installation package.

  1. From the file menu (or context menu), the end user chooses "New Project->SDD Project From Existing Package"
  2. The end user is prompted to pick a location where the configuration data (e.g. the SDD) will be stored.
  3. The end user is prompted to pick the location of the existing package.
  4. If the format of the selected package is one that the SDD cannot process, notify the user and ask if they want to cancel or choose another package.
  5. The tool creates an SDD using as much of the information as it can glean from the chosen package.
  6. The user provides input values for the SDD. Parts that are marked as uneditable in use case 7.6 are either hidden or disabled.
  7. The tool writes out editable parts of the SDD as instructed by the user.
  8. When user has completed input of raw data, they choose either "Validate", "Package", or "Deploy" from the Tools menu.

Enhancements: 219710

Use Case: Edit an existing SDD

Actor: SDD Author

Description: The SDD Author wants to change values in a previously created SDD

  1. End-user launches SDD runtime configuration tool by double clicking the application icon.
  2. From the file menu, they choose "Open" to edit an existing SDD.
  3. The end user is presented with a file browser and prompted to pick the location of the configuration they want to edit.
  4. The user provides input values for the SDD. Parts that are marked as uneditable in use case 7.6 are either hidden or disabled.
  5. The tool modifies editable parts of the SDD as instructed by the user.
  6. When user has completed input of raw data, they choose either "Validate", "Package", or "Deploy" from the Tools menu.

Enhancements: 219711

Use Case: Validate an SDD being edited

Actor: SDD Author

Description: User chooses "Validate" from the tools menu within the context of editing an SDD.

  1. The configuration tool performs XML validation against the SDD schema and checks that the parameters entered by the user make sense. The document validates, and the user is notified with a brief notification dialog.
  2. The configuration tool performs XML validation against the SDD schema and checks that the parameters entered by the user make sense. The document does not validate, and the user is notified with a brief notification dialog.

Enhancements: 219712

Use Case: Package up a completed SDD

Actor: SDD Author

Description: The SDD Author wants to bundle the completed SDD and any corresponding artifacts into one deliverable package.

  1. User chooses "Package" from the tools menu within the context of editing an SDD. Note: We are not creating a package in the sense of an MSI or RPM... We are simply bundling the SDD (which describes those artifacts) with the associated artifacts (which themselves might be MSIs or RPMs).
  2. The configuration tool validates the SDD (see use case 8.4)
  3. The configuration tool creates a deployable entity by bundling together into a package structure (like a self-extracting zip file) one or more Package Descriptors, the Deployment Descriptor, and the associated artifacts specified by the user.

Enhancements: 219713

Use Case: Deploy a packaged SDD

Actor: SDD Author

Description: The SDD Author wants to deploy their newly packaged SDD.

  1. User chooses "Deploy" from the tools menu within the context of editing an SDD.
  2. If no package has been created from the SDD, the configuration tool creates one (see use case 8.5).
  3. The configuration tool invokes the SDD runtime system with the package created from the SDD.

Enhancements: 219714

COSMOS Use Cases for Resource Modeling

SML and SML-IF validation support

Actor: web developer, Eclipse developer, COSMOS framework

Description:

  1. SML validator implementation for validating SML and SML-IF documents
    1. A web developer builds a set of XML documents that conform with the SML specification. He needs a validator to validate the XML documents. He then goes to the COSMOS web page and downloads the package containing the SML validator. Since this validator is rather small, under 1M, and not related to the COSMOS management framework, it is important to be able to download it separately from the COSMOS framework. The user validates the files by running a set of SML validation APIs provided by COSMOS.
    2. An Eclipse user builds SML documents. He needs a validator to validate these documents. He then points to the Update Manager site and tries to install the SML validator feature offered by COSMOS. This user will also require Eclipse based actions that integrate with the Eclipse framework: Validate SML popup action on an SML file, list of files or folder. The user can exchange data by running Export, Import to SMLIF actions on a set of SML documents.
    3. The COSMOS framework will exchange SML documents, packaged or not in an SML-IF envelope. This information may need to be validated, in which case the SML validation tool will be used. Depending on the location where data is validated, the COSMOS framework may require the validator to be run in or outside of the Eclipse framework.
  1. SML-IF editor for importing and exporting SML documents from an SML repository
    1. A web developer builds an SML repository. He needs to exchange these documents with other repositories. He then goes to the COSMOS web page and downloads the package containing the SML-IF import/export APIs. Since SML-IF package is rather small, under 1M, and not related to the COSMOS management framework, it is important to be able to download it separately from the COSMOS framework. The user exports and imports SML documents by running a set of SML validation APIs provided by COSMOS. The SML-IF editor, which is Eclipse based, will not be used here.
    2. An Eclipse user builds an SML repository. He needs to exchange these documents with other repositories. He then points to the Update Manager site and tries to install the SML-IF feature offered by COSMOS. This user will also require the SML-IF editor.
    3. The COSMOS framework will exchange SML documents, packaged in an SML-IF envelope. It will use a set of APIs to import and export to SML-IF. The SML-IF editor will not be used here.
  2. SML representation of a simple Data Center repository
    1. COSMOS framework may use this to define a common taxonomy for exchanged data.
    2. An end user may need this to play with SML and SML-IF structures.

The following conditions need to be in place to support this use case:

  1. The SML and SML-IF validation needs to comply with all required and optional features of the SML specification, version 1.1.
  2. The Data Center definition and instances should comply with this new specification.
  3. Any other COSMOS framework that makes use of specific SML constructs needs to support version 1.1; SML repository API may be one target.
  4. The SML-IF editor should match the new SML and SML-IF specification.

Enhancements: 205825, 205826, 237872, 237921, 238000, 237924

Contextual help for SML tooling

Actor: web developer, Eclipse developer

Description: A web developer is using the SML-IF import utility, SML-IF export utility, SML-IF editor, or SML-IF new wizard, and wants to see more information on what should be entered in the input fields.

Enhancements: 213635 (i4)

Federation and reconciliation catalog

Actor: System Administrator

Description: A systems administrator has multiple data repositories he wants to federate (as defined in the CMDBf specification). To achieve this, he wants a basic set of resource types and the properties typically used to identify instances of each resource type. The purpose of this is to describe enough information about a resource (e.g., a computer system) to determine whether two management data repositories have data about the same resource, even given that each repository uses a different data model.

Enhancements: 270836 (i4), 242818

COSMOS Use Cases for CMDBf

Other COSMOS Use Cases

Retrieved from "https://wiki.eclipse.org/index.php?title=COSMOS_Use_Cases_1.1&oldid=147370"

This page was last modified 13:12, 1 April 2009 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top