6.2 Different scenarios in an integrated environment

 < Day Day Up > 



For a loose integration, it is necessary to solve problems related to function and data redundancy. It must also be decided which data each system should manage, where the different data should be archived, and which functions from which systems should be used. Dependent on how we make these decisions, we end up with different integrations and with different requirements of the interoperability functions. Data stored in PDM and SCM can be classified according to how it is exchanged (see Figure 6.5):

  1. Information managed exclusively by PDM. Certain types of data will be stored and used only in the PDM system. Documents strictly related to products, hardware components, sales information, or similar are one type of such data. Information in PDM is stored in a standard way as business and data items, shown in Figure 6.5 as metadata and data.

    click to expand
    Figure 6.5: Saving and exchanging data.

  2. Information managed exclusively by SCM. Source code and certain internal files strictly related to the development of software components are saved and managed only in SCM. They are of no interest to PDM. In addition to the data itself (under version control), SCM saves different attributes of data (such as state, lock flag, and user information), which to some extent correspond to metadata in PDM.

  3. Information exported from PDM to SCM. This data will be managed in PDM, exported to SCM, and used in SCM for reading only, without it being possible to modify its contents. For this type of data, it is important that the export function is performed each time data in PDM has been changed, preferably automatically but at least at specified integration points in the development process. When data is exported, the attributes in SCM must also be defined to relate properly with metadata in PDM. Examples of such data are requirements specifications or project plans and overall designs.

  4. Information imported to PDM from SCM. Data that is created and updated in SCM can only be used in PDM without the possibility of change. However, it must be possible to change metadata in PDM. Examples of this type of data include different documents related to software binary files (executables and libraries), particular source code, which are built in SCM systems.

  5. Import/export data. Certain types of data may be created in one system, say PDM, then exported to SCM at an integration point, and set as frozen in PDM. Data is then changed under SCM control and imported back to PDM. There are many examples of information that is related in this way, such as detailed designs of software components and product error reports when errors are corrected in software.

  6. Common data. Data itself (i.e., a data item) is stored in SCM, but metadata (business items) is stored in PDM. There is a reference from metadata to the data saved in SCM. This type of reference is not a reference to data directly (such as a file path), but a specification of an action to be performed in SCM in order to retrieve data. This could be, for example, a “file check out” command. It is required that users of both PDM and SCM should be able to update this data. Many types of documents are in this category. Consistency of data as seen from both PDM and SCM is important here.

  7. Redundant data. This is a variant of the common data and import/export type of data. Redundant data is saved at two places and can be updated from the two systems. This type of data is very likely to cause the state of the system to become inconsistent. For example, data in PDM can be updated but remain unchanged in SCM. To maintain consistency, a means of automatically updating data at both sites must be provided.

An important requirement of an integrated environment is uniformity of user interface, irrespective of where data is stored. A PDM user should be able to independently access a document stored in either the PDM system or an SCM system. Similarly, an SCM user should not perform any additional action when a document stored in the SCM system is related to metadata in the PDM system.

6.2.1 Integration prerequisites

We shall discuss here an example of an integrated environment and identify the resulting requirements. First, we define the basic assumptions for the integration and decide where to store data. We then follow two scenarios containing several use cases. One scenario describes cases for a PDM user, and the other one for an SCM user.

The integrated system has the following characteristics:

  • The PDM system is the umbrella tool and will also manage certain metadata for the software information.

  • The PDM system will manage the product structure and the revisions of all products included.

  • The SCM system is the archive for all software information (i.e., all software files—source code and binary files built from them—will be stored in SCM).

  • Documents related to software are stored in the SCM system, and related metadata is stored in the PDM system in the corresponding business items. The business items will be related to the specific product in the product structure.

  • The items, stored in the SCM system with corresponding metadata in the PDM system, are marked with specific attributes, used to avoid changes being made asynchronously in SCM and PDM.

  • When data stored in SCM with corresponding metadata stored in PDM is changed, SCM automatically sends particular information to PDM (e.g., information about documents—status and other business-related attributes, such as a new version of the document, document number, document name, and author—when they are checked out in SCM).

  • The PDM manages metadata of the delivered products, including its components (i.e., libraries and executables).

  • SCM saves information about all software parts, and the same software parts are included in the BOM.

6.2.2 Scenario A: PDM—User interaction

In this section, we analyze certain scenarios related to users of the PDM system and files stored in the SCM system (i.e., the cases 6 and 7 in Figure 6.5). All functions required by a user are initiated by the PDM system. The use cases show the kind of information the PDM user requires from SCM and how the two systems exchange the information.

Let us study the following use cases:

  • Query for a document. The PDM system must (1) search for the document in the SCM system and (2) present a list of all found documents that match the search criteria.

  • Get a document. The PDM system must (1) look up the actual file or files in SCM, (2) make a copy of it, and (3) present the actual document to the user. This is needed when a consumer is to assemble a product.

  • Check out a document. The PDM system must (1) check out the document from SCM, (2) copy the document in the WIP vault in the PDM system, and (3) set all attributes required to synchronize the states of PDM and SCM (e.g., user identity and status). The user may now update the document (see Figure 6.6).

  • Check in a document. The PDM system must (1) check in the file in SCM, (2) set all attributes required to synchronize the states of PDM and SCM, and (3) update the version of the file in PDM.

    click to expand
    Figure 6.6: Check out sequence from PDM into SCM.

  • Delete a document. The PDM system must (1) check if the user has the access rights and is allowed to delete the specified document, and (2) check if the document is included in a frozen product or not. If the document is not included in a frozen product, (3) search for the document in SCM, (4) delete it in SCM,(5) delete attributes in SCM, and (6) delete all metadata and relationships in PDM.

  • Import a document into PDM. A document existing in SCM is copied to the PDM (case 4 in Figure 6.5). PDM (1) issues a query for the document and reads it, and (2) checks it in in PDM. If the document does not exist in PDM, it must be registered first and then checked in. Certain attributes (3) must be updated in metadata (for example a read-only state of the document).

  • Export a document from PDM. A PDM user wants to copy a document from PDM to SCM. PDM (1) checks in the document into the SCM system. The appropriate attributes (2) are set in PDM and SCM.

Figure 6.6 shows a sequence diagram of a check out of a document where the metadata is managed in the PDM system and the actual document is archived in the SCM system (case 6 in Figure 6.5). The figure shows how the PDM system communicates with the SCM system by reading the metadata in the PDM database and forwarding the metadata to the SCM system. The SCM system retrieves the actual file from its database and returns the file to the PDM system.

6.2.3 Scenario B: SCM—User interaction

In this scenario, a user uses only an SCM system, not a PDM system. However, information generated in the SCM system must be automatically updated in the PDM system. The use cases show the kind of information the SCM user requires from the PDM and how the two systems should manage the information correctly. In an ideal situation, all information necessary for further work in SCM will be created in SCM, but in practice there will be cases in which SCM users will wish to create data that belongs in the PDM system. To avoid the use of a PDM system, SCM users can be provided with certain functions for more flexible working procedures. Examples of these functions are registering a new product or registering a new document.

We have identified the following use cases:

  • Register a new product or product revision. A user from SCM registers a new product in the PDM system. The SCM (1) creates a new product item, (2) specifies all of the necessary attributes of the products (such as owner and parent product), and (3) receives the product identity, which may be used in SCM for a different purpose (e.g., for creating a baseline or a new working structure).

  • Register a product revision. The SCM system must know the identity of the next revision of the product. (1) SCM sends an inquiry to PDM for the next revision of the specific product, (2) PDM allocates the product revision, (3) PDM sets appropriate attributes (such as work-in-progress state), and (4) PDM delivers the new product revision identity to SCM.

  • Register a new document. One or several files stored in the SCM system are registered as new items in the PDM system. SCM must provide PDM with (1) the full path to the files and (2) attributes with relevant metadata (for example document status and document revision). SCM must also provide PDM with (3) the identity of the product to which the information belongs. When registering a library or an executable in PDM, (4) the reference to all included software source code files (e.g., the path and configuration specification) is also registered.

  • Import a document into PDM. A document existing in SCM is copied to the PDM (case 4 in Figure 6.5). If the document does not exist, it must be registered first and then copied. Certain attributes must be updated in metadata (e.g., a read-only state of the document).

  • Check out. The file is already registered in PDM and may be frozen. (1) SCM checks if the file has already been checked out. If the file is not checked out, (2) SCM checks out the file in SCM. If there is already an existing copy of the file in the PDM system, it is (3) checked out also in PDM. (4) All attributes required to synchronize the states of PDM and SCM(e.g., user identity and status) are set. The user may now make the changes in the file, as described in Figure 6.7.

    click to expand
    Figure 6.7: Check out sequence from SCM into PDM.

  • Check in. First, SCM (1) will perform a check in of the file, (2) check in in PDM, in cases in which the file is saved in both PDM and SCM (case 7 in Figure 6.5), and (3) set all attributes required to synchronize the states of PDM and SCM (e.g., user identity and status).

  • Uncheck out. SCM unlocks the file lock and changes the status in PDM.

  • Update product status. SCM sets appropriate attributes in PDM, depending on the company-specific development process.

  • Delete document. (1) SCM uses the document number label and searches for the document in PDM. (2) If the document is not included in a frozen product, SCM will delete the document in PDM and (3) in the SCM system, including all labels and attributes. (4) If the document is used in a frozen product, an error message is returned to the user and no document is deleted.

  • Query regarding product revision. SCM will use the product number label and ask PDM for the current revision of this product. The result will be presented to the user.

  • Query regarding a product structure. SCM will use the product number label and request PDM to retrieve the full product structure in which the actual product is included. The result will be presented in SCM to the user.

  • Query regarding documents. An SCM user searches for the documents placed in PDM only (case 1 in Figure 6.5). SCM will (1) use a search key and perform a query inPDMto retrieve the actual document. The result (2) will be presented to the user.

  • Export documents from PDM. An SCM user wants to copy a document from PDM to SCM. SCM (1) issues a query for the documents to the PDM system and accesses them, (2) checks it in the SCM system, and (3) sets the appropriate attributes in PDM and SCM.

The sequence diagram in Figure 6.7 shows a similar complexity of check out activity for an SCM user, as Figure 6.6 shows for a PDM user.



 < Day Day Up > 



Implementing and Integraing Product Data Management and Software Configuration[... ]ement
Implementing and Integrating Product Data Management and Software Configuration Management (Artech House Computing Library)
ISBN: 1580534988
EAN: 2147483647
Year: 2006
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net