When you specify a URI for a type resource, the syntax is similar to that of a URL: domain-name.suffix/ns/ path# identifier If you are using configuration management, there are options as of version 7.0.1 to use a type system specific to a configuration see the IBM Knowledge Centre for more details.
#DEFINE ARTIFACT SOFTWARE#
If you use common URIs across components and project areas, but the labels differ (for example, one uses SW Requirement and another Software Requirement), Report Builder will choose one of the labels to display. Note: Where possible, keep labels consistent as well. It becomes even more necessary to have consistent URIs when you enable configuration management and introduce the potential for multiple versions of the same types across components, configurations, and project areas. The system also uses URIs when enforcing link constraints in DOORS Next. Report Builder showing attributes with conflicting URIs The screen capture below shows an example where the Stability and Status attributes have been defined in different components with inconsistent URIs: Report Builder would display multiple instances of Business Requirement, which makes it very challenging to select, set conditions, and filter by project area or component. Inconsistent URI usage has impacts when you want to report across project areas: if each Business Requirement type has a unique URI, the system treats those as different artifact types. Note: When no URI is specified, the system defines a unique value internally leaving URI fields blank does not make them equivalent. Conversely, if one project area used a different URI or no URI at all, the system would consider the Business Requirement type in that project area to be a different resource type. So for example, if you have Business Requirement artifacts in different project areas and they all use the same URI for that artifact type, the system considers those types to be the same – even if the project areas use different labels to describe the type (which is not recommended – ideally labels should be consistent too). Two resources that have the same URI are considered to be the same. In this case, the “resources” in question are the artifact types, attributes, enumerations, relationships, and so on that describe your type system.
In fact, a URL (like the address of this web page) is a type of URI. What is a URI anyways?Ī “uniform resource identifier” (URI) identifies a particular resource unambiguously. In this article, we explore in more depth what it means to define URIs, what a URI consists of, and best practices in defining your own URI vocabularies, expanding upon the OASIS Open Services for Lifecycle Collaboration (OSLC) guidelines. This becomes even more important when you use Lifecycle Query Engine (LQE) for reporting, and especially for applications like IBM DOORS Next Generation (DOORS Next) where types can vary greatly across project areas and configurations. In many articles and best practice guidelines for IBM Engineering Lifecycle Management (ELM), we recommend defining URIs for artifact types, attributes, enumeration values, and so on. Defining URIs for artifact types, attributes, and other resourcesīuild basis: IBM Engineering Lifecycle Management 6.x, 7.x
0 kommentar(er)
