2.3 Information architecture

 < Day Day Up > 



Information architecture has been defined as follows [6]:

An information architecture describes salient phenomena and their static relationships to each other in a defined context.

2.3.1 Data representation

The information in a PDM system is structured to follow an object-oriented product information model. Objects are of two different kinds: business items and data items.

Objects used to represent parts, assemblies, and documents are designated business items or business objects. (To avoid confusion, we will use the terms business item and data item.) A business item contains attributes and metadata, described in Section 2.2.1, which define the properties of the item (e.g., its name or revision). An attribute has a name and one or several values. A PDM system also manages files. A file is represented in the database as a data item. The metadata is separated from the content or actual data (file). This is to enable replication of metadata without necessarily replicating the file. A data item can be reused from several business items. A business item can have a relationship with several data items. This is not possible in a standard file system.

In many cases, PDM extends a function, which is performed on a business item to apply automatically to the data item or data items. For example, when a business item is copied in PDM, the data item is also copied, given a new name, and attached to the new business item.

Relationships are used between objects (both business and data items) to relate them to each other. A product structure consists of objects and relationships together with attributes. Product structures use a special class of business items ( structured business items) with special relationships to support BOM requirements for usage, described in Section 2.5.1, and physical identification. An attribute can be defined either on an object or on a relationship.

Figure 2.8 shows how a document is managed by its metadata through the business item and the file itself in the data item.

click to expand
Figure 2.8: Illustration of representation of documents by both business items and data items.

2.3.2 Information model

An information model is a logical organization of real-world objects, constraints on them, and the relationships between objects (i.e., a network of objects related to each other). An object-oriented information model consists of the following basic object-oriented concepts [7, 8]:

  • Object and object identifier. Any real-world entity is uniformly modeled as an object. An object is associated with a unique identity with which it can be pinpointed.

  • Attributes and methods. Every object can have a state (the set of values for the attributes of the object) and a behavior (the set of methods— program code—that operate on the state of the object). The state and behavior encapsulated in an object are only accessed or invoked from outside the object through explicit message passing.

  • Class. This is a means of grouping all of the objects that share the same set of attributes and methods. An object may belong to only one class as an instance of that class.

  • Class hierarchy and inheritance. This is the derivation of a new class (subclass) from an existing class (super class). The subclass inherits all of the attributes and methods of the existing class and may have additional attributes and methods.

The PDM information model utilizes this object-oriented approach. The PDM information model describes the types of objects, relationships, and attributes used to represent business items, data items, and relationships between them. The information model can be changed to better suit the needs of a particular business solution in a company.

A database system implements an information model, or, in other words, a database language is a concrete syntax for an information model. In most database systems, the object-oriented information model is implemented in tables, concealed from the users by both a graphic interface and several functions on a higher abstraction level. Alternatively, an objectrelational database, an object-oriented database extended with relationships, can be used. Transactions provide support for concurrent usage of the objects.

Figure 2.9 depicts an information model described by a generic product structure. This example is selected from Metaphase [5]. Several PDM systems (e.g., [5, 9, 10]) have an information model partly based on the Standard for the Exchange of Product Model Data (STEP) standard [11]. Most of them, however, only follow this standard to a certain degree.

click to expand
Figure 2.9: Example of an information model.

2.3.3 Version management

Version management is mostly about revisions and versions—how to create them, store them, and retrieve them. Within the PDM system, all items are under version control management.

Versions are at the lowest level. The main characteristic of a version is that when frozen, it can no longer be changed (i.e., it is immutable). It must be checked out instead, which means that the system creates a new, succeeding version (with identical contents), from it which can be edited. When editing is completed, the user checks in the item, making the new version also immutable. Versions are identified with a sequence number starting from one (see Figure 2.10).

Revisions are superimposed on versions. Revisions of business items are often identified with a letter (e.g., A, B, or C). To work with an item, the user checks it out, edits it, and then checks it in again (freezing it), creating a new version with the same revision name. A revision can be revised, which means a new succeeding revision is created and assigned an increased revision letter.

The versions and revisions of an item together constitute its evolution history and can later be viewed by any user. However, only the latest revision and version can be changed (i.e., checked out—B;2 in the Figure 2.10 example).

click to expand
Figure 2.10: Example of the connections between revisions and versions.

PDM does not support concurrent development. When a user checks out an item, this version is locked to prevent other users from checking out the same version. Thus, there is no possibility of creating several versions of an item to exist in parallel with each other. When the item is checked in again, the new version is stored, and the lock is released. That support of concurrent editing of items is not provided is of no great significance for hardware development, but is a clear disadvantage for software development, where concurrent development is more common.



 < 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