By now you have probably seen literally dozens of articles I’ve written on PTC Integrity Lifecycle Manager, talking about the ins and outs of various pieces of functionality. Today I thought it was time to go into greater detail on documents and how they are constructed in PTC Integrity Lifecycle Manager.
As you probably know by now there are two main categories of item types in PTC Integrity Lifecycle Manager, Process Items and Document Domains (Sometimes referred to as Document Types). While a Process Item is typically a “flat” item, used in things like Defects and Change Requests, a Document Domain is a more complex item type that is actually made up of three separate item types. These item types are the Document Item, the Content Item, and the Shared Content item. The goal behind this design is to allow you to produce something that looks like a document from in a word processor complete with sections and subsections, while allowing the end user to perform functions like tracing, and branching.
I will discuss each of these item types below:
- The Document Item is the container that binds the whole document together. Typically it contains the metadata regarding the overall document. The structural relationship that binds the document together (the Contains/Contained by relationship) starts at the highest level here in the Document Item.
- The Content items are the individual pieces of content that make up the document. Content items come in two main forms, meaningful items and non-meaningful items. The meaningful items are the content that is truly important in the document. In a Requirement Specification, these are the items that explain exactly what the required design should look like. In short, these are the items you will want to establish trace relationships to in other documents.Conversely, non-meaningful items are those things like headings and comments that while useful in organizing your document don’t advance the subject matter in any way. These are items that you do not want to use for trace relationships.Another thing to notice about the content items, is the structural relationship. Notice in the drawing above how the structure initially starts with the Document Item, but later on the lower content items have a structural relationship seeming starting off of another content item. This corresponds to how you layout your sections within your document. The lower sections are Contained By the section one level above. (Often section headings can contain several content items underneath them.)One further thing to mention about content items, is that content items are defined within the context of a given document domain. This means that if you have a Requirement item that was originally defined as part of a Requirement Specification, you cannot place that Requirement item directly within a Design Specification or any other document type for that matter, other than a document that is also a Requirement Specification.
- The Shared Content item is that last part that makes up the document domain. Basically the shared item is a hidden item, the average user may not even know it exists. It’s on the Shared Content item where the important information about the content is actually maintained. In the diagram below you can see an example of how this works.
The content item and the shared content are linked together by way of the References/Referenced By relationship. The important fields, in this case the Category and Text fields, are actually maintained on the shared content item. What you see on the Content item are Field Value Attribute fields (FVAs). Think of an FVA as an interactive reflection of what’s in the corresponding shared field. Although, this looks strange, the purpose of this will become clear when we talk about how branching works. That of course will be discussed in a future blog article.
I have attempted in this document to shine a light on what happens behind the scenes with documents in PTC Integrity Lifecycle Manager. As you are now aware a Document Domain in PTC Integrity Lifecycle Manager is a complex type made up of several different parts all working together to give the end user a Word like experience while still allowing for things like tracing and branching, things you can’t necessarily do within a word processor application.
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
