| Goal in Context: The goal of this use case is to maintain a catalog of data entities which describes a specific part within the metadata of a test. |
| |
| Scenario "Creating a Catalog Component": A new Catalog Component should be created for specific type (UnitUnderTest, TestSequence, TestEquipment). |
| Precondition: There is no Catalog Component with the same name with the specified type. |
| |
| Scenario "Modifying a Catalog Component": An existing Catalog Component should be modified. This includes the specification of a description and a set of attributes. The attributes in turn have fields to specify, which are described in the business object model. |
| Precondition: The deletion of attributes is allowed only if it is not referenced within any template. |
| |
| Scenario "Delete Catalog Component": An existing Catalog Component should be deleted from persistance. |
| Precondition: The deletion is allowed only if it is not referenced within any template. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to define a catalog of templates, which define the characteristics of specific components with the test metadata. |
| |
| Scenario "Creating a Template Component Structure": A new Template Component Root or a Template Component should be added to the persistance. Template Components can be nested under other Templates Components to provide a logical structure. Template Component Roots acts as root within this structure. Each structure is associated with a Component Type (UnitUnderTest, TestSequence, TestEquipment). |
| Every Template Component has to assigned with a specific Catalog Component, which was defined earlier. The Component Type have to be the same. |
| Precondition: Template Component Root names must be unique within its Component Type. The Template Component names must be unique within the structure under the root. |
| |
| Scenario "Modifying a Template Component Structure": The definition of an existing Template Component structure should be modified. Every Template Component inherit its attributes from the associated CatalogComponent. Within the Template Component attributes are activated, so that will be valid and visible in the metadata of the related test later on. All fields of the attribute are modifiable except name, datatype and unit. |
| In addition the context information "optional","default active" and "teststep variable" have to be specified. |
| Precondition: Template Component structure is in state "editing". |
| |
| Scenario "Delete within a Template Component Structure ": An existing Template Component Root or a Template Component should be deleted from persistance. Every element which is located logical under the element to delete, should be deleted also. |
| Precondition: Template Component structure is in state "editing". |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to maintain a catalog of enumerations which can be used for the the value set of a catalog attribute. |
| |
| Scenario "Creating an Enumeration": A new Enumeration should be added to persistance. |
| Precondition: There is no Enumeration with the same name. |
| |
| Scenario "Modifying an Enumeration": The definition of an existing Enumeration should be modified. This includes the adding and deletion of new value pairs and modification of existing value descriptions. |
| |
| Scenario "Delete an Enumeration": An existing Enumeration should be deleted from persistance. |
| Precondition: The deletion is allowed only if the enumeration is no standard openMDM Enumeration as described in the business object model. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to maintain a catalog of attribute mapping to third-party systems. |
| |
| Scenario "Creating an External System Mapping": A new ExtSystem mapping should be added to the persistance. |
| Precondition: There is no ExtSystem with the same name. |
| |
| Scenario "Modifying an External System Mapping": The definition of an existing ExtSystem should be modified. This includes the definition of attribute values from the third-party system on the one hand and one ore more openMDM template attributes on the other hand. |
| |
| Scenario "Delete an External System Mapping": An existing ExtSytem should be deleted from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to maintain a catalog of measurement quantities, which is used to define sensors. |
| |
| Scenario "Creating a Measurement Quantity": A new Measurement Quantity should be added to the persistance. |
| Precondition: There is no Measurement Quantity with the same name. |
| |
| Scenario "Modifying a Measurement Quantity": The definition of an existing Measurement Quantity should be modified. This includes the definition of attributes as described in the business object definition |
| |
| Scenario "Delete a Measurement Quantity": An existing Measurement Quantity should be deleted from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to define templates for measurement results, especially their Submatrices and Paramater Sets. |
| |
| Scenario "Creating a Measurement Result Template": A new Measurement Result Template should be added to the persistance. |
| Precondition: There is no Measurement Result Template with the same name. |
| |
| Scenario "Modifying a Measurement Result Template": The definition of an existing Measurement Result Template should be modified. This includes the definition of Submatrices and Paramater Sets. |
| |
| Scenario "Delete a Measurement Quantity": An existing Measurement Result Template should be deleted from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to maintain a catalog of physical dimensions, as defined by ASAM ODS. |
| |
| Scenario "Creating a Physical Dimension": A new Physical Dimension should be added to the persistance. |
| Precondition: There is no Physical Dimension with the same name. |
| |
| Scenario "Modifying a Physical Dimension": The definition of an existing Physical Dimension should be modified. This includes the definition of attributes as described in the business object definition |
| |
| Scenario "Delete a Physical Dimension": An existing Physical Dimension should be deleted from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to maintain a catalog of user roles, as defined by ASAM ODS. |
| |
| Scenario "Creating a User Role": A new Role should be added to the persistance. |
| Precondition: There is no Role with the same name. |
| |
| Scenario "Modifying a User Role": The definition of an existing Role should be modified. This includes the definition of attributes as described in the business object definition |
| |
| Scenario "Delete a Role": An existing Role should be deleted from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to manage templates within a temporal and structural context. |
| |
| Scenario "Status of Templates": After creation every template is in state "editing". Only in the state "editing" it is allowed to edit this template. If the template is finished then the state has to be set to "valid". In this state it is merely possible to reference it in other templates. |
| At any time within the process the template could be outdated, because a different set of attributes are needed for example. Then the state should be changed to "archived". From then on the related template can not be used for the planning of new tests. |
| |
| Scenario "Change of Templates": The workflow for templates should be "editing", "valid" and "archived". |
| |
| Scenario "Versioning of Templates": Every template is associated with a single version number. And so every test is associated with a specific version of a template. |
| After creation the template should automatically considered as version 1. At any time a new version (increment) of an existing template can be created. The characteristics of the new version are exactly the same than the old version. The new template is in state "editing". |
| For convenience purposes is should be possible to create simultaneously new versions of every template the specific template is referenced. |
| |
| Scenario "Structuring of Templates": Every template should be stored within a file system like structure. It should be possible to move a template within this structure at any state. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to define a catalog of test templates, which define the characteristics of the complete test metadata. |
| |
| Scenario "Creating a Test Template": A new Test Template should be added to the persistance. |
| Precondition: There is no Test Template with the same name. |
| |
| Scenario "Modifying a Test Template": The definition of an existing Test Template should be modified. This includes the definition of template specific extensions and references to TestStep Templates. For every TestStep Template it should be possible to specifiy if it's mandatory. |
| The extensions cover the following use cases: |
| NameHelper: NameHelper generating test data names. The generation should be implementation specific. Most of them will use test metadata as generation criteria. |
| External Sources: To avoid retyping of existing data it should be possible to provide an interface for metadata input. The user should be able to search for a set of data, which is filled automatically within the metadata during the test plan process. |
| Test Order Actions: Test Order Actions are generic processes (e.g. jobs, see Worker interface), which should be executed if the planning of the test is finalized. |
| Precondition: Test Template is in state "editing". |
| |
| Scenario "Delete a Test Template": An existing Test Template should be deleted from persistance |
| Precondition: Test Template is in state "editing". |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to define a catalog of test templates, which define the characteristics of a single test step. |
| |
| Scenario "Creating a Test Step Template": A new Test Step Template should be added to the persistance. |
| Precondition: There is no Test Step Template with the same name. |
| |
| Scenario "Modifying a Test Step Template": The definition of an existing Test Step Template should be modified. This consists of the association of a single Component Template for the parts UnitUnderTest, TestSequence, TestEquipment and MeaResult. |
| Precondition: Test Step Template is in state "editing". |
| |
| Scenario "Delete a Test Step Template": An existing Test Step Template should be deleted from persistance |
| Precondition: Test Step Template is in state "editing". |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to maintain a catalog of units, as defined by ASAM ODS. |
| |
| Scenario "Creating a Unit": A new Unit should be added to the persistance. |
| Precondition: There is no Unit with the same name. |
| |
| Scenario "Modifying a Unit": The definition of an existing Unit should be modified. This includes the definition of attributes as described in the business object definition |
| |
| Scenario "Delete a Unit": An existing Unit should be deleted from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to maintain a catalog of users, which have access to the system and its data. |
| |
| Scenario "Creating an User": A new Usershould be added to the persistance. |
| Precondition: There is no User with the same name. |
| |
| Scenario "Modifying an User": The definition of an existing Unit should be modified. This includes the definition of attributes as described in the business object definition and assignment of roles. |
| |
| Scenario "Delete an User": An existing User should be deleted from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to maintain a catalog of value lists, as defined by ASAM ODS. |
| |
| Scenario "Creating a Value List": A new Unit should be added to the persistance. |
| Precondition: There is no Value List with the same name. |
| |
| Scenario "Modifying a Value List": The definition of an existing Value List should be modified. This includes the definition of attributes as described in the business object definition |
| |
| Scenario "Delete a Unit": An existing Value List should be deleted from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to provide a transaction mechanism for write operations. Transaction in this context is similar to the meaning in a database context. |
| |
| Scenario "Start a New Transaction": A new transaction should be initiated. All following write operations are bind to this transaction. The transfer to persistance must not happen until the transaction is commited. |
| Precondition: There is no active transaction or otherwise and error must be thrown. |
| |
| Scenario "Commit a Transaction": All operations, belonging to a transaction context, are done and the transfer to persistance should be done. |
| If the transfer/saving process is not successful, than an detailed information about the errors should be provided. Within this error information it must be obvious which operation failed and why it's happen. |
| Precondition: There is an active transaction. |
| |
| Scenario "Abort a Transaction": An existing transaction should be cancelled and all save operations within this context should be reverted. Then the transaction is closed and a new transaction can be started in the future. |
| Precondition: There is an active transaction. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to fetch a previous defined query and execute it with optional modifications. |
| |
| Scenario "Load a Query": A previous defined query identified by an unique name should be loaded from persistance. The result should be the same as the query was defined during runtime. After the query is loaded it behaves like an normal query so that modification are possible for example. |
| Precondition: A query with the selected identifier must be stored in the related persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to store a defined query with an unique identifier within a specific persistance. |
| |
| Scenario "Persist a Query": A query, which was defined at runtime, should be transferred to persistance. This must be done in a form, so that the query can be reconstructed after loading. |
| Precondition: The identifier must be unique. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to provide business objects with context information to mark them for other use cases. |
| |
| Scenario "Mark a Bussiness Object": Add new piece of context information should be added to a business object. A query for a specific context information should be possible. |
| |
| Scenario "Remove Tag from a Bussiness Object": An existing piece of context information should be removed from a business object. |
| |
| Precondition: Bussiness object is tagged already. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to fetch data from the data layer. Performance is especially important for this use case, because it inflicts all components, which uses the business layer. |
| |
| Scenario "Query Data": The business layer should provide an "SQL-like" query service. The result should be handed out in a form so that it can be processed as simple as possible. If the query fails it should become obvious what is not correct. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to get statistic data of the content of the persistance. |
| |
| Scenario "Creation of Business Objects Over Period": Get information of how many business objects of a specific type are created within a specific period. For example: "122 test were created in the last month" |
| |
| Scenario "Modification of Business Objects Over Period": Get information of modification of specific business objects. This includes general modification or modification of a specific property. (for example: state of a test) |
| |
| Scenario "Deletion of Business Objects Over Period": Get information of how many business objects of a specific type are deleted within a specific period. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to get get access to data which is persist with the ASAM ODS standard. |
| Performance is important for every use case which operate on test data, because it inflicts all components, which uses the business layer. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to build an User specific openMDM business object collection. |
| |
| Scenario "Build a new Favorite List": A new Favorite List should be build out of a collection of test data. |
| Precondition: There is no Favorite List with the same name. |
| |
| Scenario "Modifying a Favorite List": Test data objects should be added or removed from a Favorite List. |
| |
| Scenario "Delete a Favorite List": A Favorite List should removed from persistance. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to relate test data objects with context classification data. This data consists of: |
| Status |
| Domain |
| Project Domain |
| With this context information test data can handled within a particular workflow. |
| |
| Scenario "Change Classification": The relation to a specific classification object (Status, Domain, ProjectDomain) should be created. For every type only one relation is allowed. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to create new instances of test data and persist them in ASAM ODS standard. |
| |
| Scenario "Create a Test Data Instance": Before the data is passed to the persistance service it should be possible to create a local data structure. This is beneficial for perfomance and modeling purposes. So the components can share a local temporary data model. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to read test data from a specific openMDM persistance and copy them in an other openMDM persistance. |
| |
| Scenario "Import Test Data": Test data should be copied from a ODS compatible source to an openMDM system. |
| In some use cases a mapping of data is necessary. |
| The source could not fully compatible to the target system. This includes constraint violations or incomplete data. Therefore there should be an validation process, which must present all incompatibilities in a detailed result. |
| In some use cases it is intended to overwrite data. |
| |
| Scenario "Preparing Test Data": Not in every case the test is provided in ODS format. So the data has to be converted to an ODS format before it can be imported. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Goal in Context: The goal of this use case is to modify existing instances of test data and persist the changes in ASAM ODS standard. |
| |
| Scenario "Modify a Test Data Instance": Before the data is passed to the persistance service it should be possible to modify a local data structure. This is beneficial for perfomance and modeling purposes. So the components can share a local temporary data model. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
