VTS Use Case Model
Version 1.0
Architecture & Engineering Team
December 2008
Revision History
Date / Version / Description / Author12/10/08 / 1.0 / Created and distributed for internal Peer Review. / Srinath Vala
Table of Contents
Revision History
Table of Contents
1.Introduction
1.1.Brief Description
1.2.References
2.Actors
2.1.Client Application
2.2.VA Developer
2.3.VHIM Team
3.Use Cases
Figure 1 – VTS Overall Use case Model
3.1.Request Schema
3.2.Register for Service
3.3.Request New Template
3.4.Explore Template Schema
3.5.Register New Schema
3.6.Update Schema
3.7.Delete Schema
VTSUseCase Model
1.Introduction
1.1.Brief Description
This document presents an overview of the use cases identified in the VTS Use Case Model. The VTS Use Cases describe the functional requirements of VTS in the context of the actors (systems) that will interface with VTS.
1.2.References
2.Actors
This section describes each actor identified in the VTS Use Case Model.
2.1.Client Application
This actor will interface with the Registry to obtain the template required.
2.2.VA Developer
This actor will interface with the Registry to explore the templates and request for new templates.
2.3.VHIM Team
This actor will define Authorized Template Developer responsible for creating and updating the schemas.
3.Use Cases
This section lists and describes all of the use cases identified for VTS.
Figure 1 – VTS Overall Use case Model
3.1.Request Schema
By providing a unique identifier client application request for schema. The client can also ask for other metadata like Id, Concept (code), Classification / Classification Scheme, Object Type, Association/Associated Objects, and Artifact attribute value.
3.2.Register for Service
In slightly improved case, the client application then can cache the obtained information and subscribe itself for changes in the registry. If the service's information has been changed in the registry, the registry notifies the client so that it can invalidate its cache and download updated metadata.
3.3.Request New Template
VA developer can request for new template.
3.4.Explore Template Schema
During the design process, architects or molders produce new schemas. Their results can go via an approval process prior publishing in order to ensure their compliance. The registry is the place where architects or molders can find what they need as well as publish what they create. Only then it is possible to apply central policies over the relevant data. Using the registry strongly supports the 'contract first' methodology.
3.5.Register New Schema
Administrators register new schemas.
3.6.Update Schema
Administrators update existing schemas.
3.7.Delete Schema
Administrators delete existing schemas.
December 20081 of 8
Version 1.0