AP233 Concepts for Mapping

AP233 is an information model designed as a neutral data exchange capability for data created by Systems Engineering computer applications. This document also specifies how to use the AP233 XML Schema to represent SE concept for exchange between tools. The purpose of this document is to be the target for links from documentation mapping other information models, standards and notations into AP233.

1 Introduction

1.1 The ISO formalities

AP233 is an ISO standard information model that is part of the STEP suite of standards. STEP is formally defined as ISO 10303 Product data representation and exchange. STEP is developed in ISO Technical Committee 184, Subcommittee 4 (ISO TC184/SC4) Industrial data. The STEP standard is broken down into parts some of which are called Application Protocols. AP233 is an Application Protocol, formally ISO 10303-233 Product data representation and exchange - Application Protocol - Systems engineering.

Warning
AP233 is still undergoing standardization in ISO at the time of this publication.

1.2 AP233 Systems Engineering Scope

AP233 supports data exchange in the discipline of Systems Engineering. Systems Engineering is a broad discipline that may vary from organization to organization. AP233 has defined as its scope, the following topics:

  • Project management
    • Product Data Management (PDM) Extensions : data model(s) that extends the STEP PDM Modules resources to service electro-mechanical, system engineering, product life-cycle, and other non-physical domains
      • Model Management : data model that captures meta-data providing the context associated with engineering and business models
      • Change Management : data model that captures issues and tracks these into a resolution process (e.g. Change Orders, Change Requests, Issues, Problem Reports, etc.)
      • Configuration Management : data model that provides versioning and baselining of all product information that is managed.
      • Organizational Structure : data model that provides relationships, functional roles, skill qualification and documentation.
      • Security: data model that identifies project, organization, country and user defined security levels as well as user authentication, access control and intellectual property issues.
    • Work Breakdown Structure : data model that is used to represent the pieces of work necessary to complete a project.
    • Schedule : data model that identifies activities, dependencies, durations and milestones associated with products described in the WBS. Includes the information necessary to produce Workflow Diagrams, Network Schedules, Gantt Charts and Resource Leveling.
    • Issue Tracking : data model that provides information related to issue tracking such as title, status, assignment, classification, description, priority, etc.
    • Cost Models : data model that captures financial resource information e.g. direct, indirect, fixed, variable, material, administrative, finance, and contingency costs and provides linkage to system product structure(s).
  • Systems engineering models
    • Behavioral Models : data models that capture semantics associated with how a system acts or performs (responds to excitation); include functions, inputs, outputs and control operators which define the ordering of functions; includes both Function-based and State-based behaviors; enables generation of Functional Flow Block Diagrams, Finite State Machines, Causal Chain, Data Flows and Sequence Diagrams, etc.
      • Function-based Behavior Model : data model that represents response to excitations based on the transformation of inputs into outputs by functions (activities) including the ordering and triggering of functions.
      • State-based Behavior Model : data model that represents response to excitations in the digital approximation based on state of an object, transitions between states and actions or activities launched by the states or transitions.
    • Requirements : data model that captures requirements as text strings with traceability, allocation, weighting and risk identified with each requirement [Text-based Requirements (TBR)] and that describes requirements as structured and quantified formalisms that may be decomposed from text-based requirements; can include tables, spreadsheets, graphs, charts, pictures and equations [Property-based Requirements (PBR)].
    • Allocation : data model that captures allocation relationships between requirements and functions.
    • Structural Models : data model that captures the organization of a system (e.g. how a system is built, static relationships between subsystems, components, or parts that constitute the system); describes what is designed, characterized built and maintained.
    • Risk Analysis : data model that identifies risk status, relationships, likelihood, consequence, impact, approach strategy, and contingencies.
    • Rules : data model that describes the information associated with constraints imposed on a product or process by system requirements, physical limitations and/or environmental restrictions. The model includes sufficient information to represent and/or support the constraint e.g. predicate calculus, the constraint life-cycle, constraint execution and associated meta-data, such as source, date and time, authorization, justification, description and notes.
    • Validation Model : data model that captures the information used to demonstrate that the emerging product is consistent with the stakeholder needs.
    • Verification Model : data model that captures the information used to demonstrate that the emerging product is consistent with the system requirements.
    • AP Interface Models : a data models that provide interfaces between domain specific data models such as mechanical, electronic, structural analysis, thermal analysis, manufacturing, etc. e.g. the transform between engineering analysis (AP209, STEP-TAS, STEP-NRF, AP235, etc.) and any AP233 module set.
    • Data Presentation : data model that provides a consistent set of presentation mechanisms and advanced schematics product model definitions that present the computer sensible model data (defined in re presentation model space) onto a human understandable schematic diagram (presentation space), conforming to conventional and/or future draughting standards.
    • Measurement : data model that includes information associated with the product development process quantification and its control and optimization.

2 Technical Details

2.1 AP233 as EXPRESS

AP233 was developed in ISO TC184/SC4 using the ISO EXPRESS information modeling language. ISO EXPRESS is formally ISO 10303-11 Product data representation and exchange: Description methods: The EXPRESS Language Reference Manual, Edition 2, 2004. See the exff Web site for a brief introduction to the ISO EXPRESS language in its section called Guides.

It is not necessary for implementers of this CADM-AP233 mapping to understand ISO EXPRESS. However, the text of the AP233 ISO EXPRESS schema is provided in an appendix as it may help some understand the information model represented by the XML Schema upon which implementations are based.

2.2 AP233 as UML

There is not yet a standard mapping between ISO EXPRESS and UML for information modelling purposes. The UML diagrams in this documentation are therefore informative in the ISO sense of the word. They were produced using an open-source tool (see the exff Web site for more deatils).

A few notes about the mapping from EXPRESS to UML will help the reader understand the diagrams.

  • The default relationship between subclasses in UML is disjoint but is overlapping in ISO EXPRESS. This difference is not taken into account in the diagrams so care should be taken as some of the subclasses may actually be overlapping.
  • ISO EXPRESS has several constructs that may be used to constrain the relationship between subclasses that are ignored in the current mapping to UML.
  • ISO EXPRESS has the concept of a union of types (called a SELECT type). This is mapped to a normal UML Class and UML Generalization relationship in the current mapping. These union types appear as Abstract and their names appear in all lower case due to naming conventions in the ISO AP233 schemas. The classes representing these unions often contain tens of subclasses, and only a few are typically shown in any diagram. Reading the the ISO EXPRESS text is the easiest way to see the details of these SELECT types.

2.3 AP233 is Product-centric

AP233, as are all ISO 10303 Application Protocols, is a Product-centric information model. Other information about concepts such as Organization or Activity also exist but less capability is defined in support of those concepts. The following indented list shows the hierarchy of kinds of Product, Product Version and Product View Definitions currently defined in AP233. Further decomposition of this hierarchy is supported by the use of classification rather than in the structure of AP233 itself.

Note
Please keep these in mind when reading the UML diagrams in this document. It is not practical to show this hierarchy in every diagram.
Product
	Attachment_slot
	Breakdown
		Functional_breakdown
		Hybrid_breakdown
		Physical_breakdown
		System_breakdown
		Zone_breakdown
	Breakdown_element
		Functional_element
		Physical_element
		System_element
		Zone_element
	Document
	Interface_connector
	Interface_specification
	Part
	Product_as_individual
	Requirement

Product_version
	Attachment_slot_version
		Attachment_slot_as_planned
		Attachment_slot_as_realized
		Attachment_slot_design
	Breakdown_element_version
		Functional_element_version
		Physical_element_version
		System_element_version
		Zone_element_version
	Breakdown_version
		Functional_breakdown_version
		Hybrid_breakdown_version
		Physical_breakdown_version
		System_breakdown_version
		Zone_breakdown_version
	Document_version
	Interface_connector_version
		Interface_connector_as_planned
		Interface_connector_as_realized
		Interface_connector_design
	Interface_specification_version
	Part_version
	Product_as_individual_version
		Product_as_planned
		Product_as_realized
	Requirement_version

Product_view_definition
	Attachment_slot_definition
	Breakdown_element_definition
		Functional_element_definition
		Physical_element_definition
		System_element_definition
		Zone_element_definition
	Document_definition
		Digital_document_definition
		Physical_document_definition
	Interface_connector_definition
	Interface_specification_definition
	Part_view_definition
	Product_as_individual_view
	Requirement_view_definition

2.4 AP233 and External Class Use

The capability to classify objects using an external class library is built into the AP233 model. By using this capability industries, countries, and organizations can be more specific about the semantics of (i.e. tailor) the use of AP233. Some refer to this capability the use of a taxonomy with a reference model. ISO 10303 STEP Application Protocol AP239 Product Life Cycle Support, a sister of AP233, developers and implementers are standardizing external classes in OASIS for use with AP239 and call the external classes Reference Data in that context. The following figure illustrates the use of external classes during a data exchange.

External Class Use Figure

For the concepts in AP233 that are intended to be extensible, the required additional semantics may be represented using an external class library. For example, the Date_or_date_time_assignment has a Role intended for such a purpose. For the purposes of the DoDAF-AP233 mapping, the use of external class libraries and classification is recommended. The external class library concept is more powerful than specifying those semantics directly in the data exchange file and makes AP233 a more flexible and extensible data exchange standard.

The following UML diagram shows how external class and classification work. Note that the classification_item abstract class actually has many, many subclasses. Only two are shown in the diagram but most things in AP233 can be classified (e.g. Document and Activity).

External Class UML Diagram
Note
For maximum extensibility use classification and external classes where possible to specify semantics.

In some implementation communities for AP233 and other ISO STEP standards, the extensive use of external class libraries in required as part of industry-agreed best practices. This use even extends to the specification of the Identifiers and Names of data objects. For that reason, it is recommended that in scenarios where maximum interoperability with implementations of AP233 and other ISO STEP standards both the normal attribute value and the classification using External Classes should be exchanged. In internal scenarios where an organization has control over both the data exporter and data importer, and where additional capabilities such as specifying multiple identifiers for objects is not required, either approach may be used.

Note
For maximum interoperability include data values as well as using classification and external class to specify semantics.

3 AP233 as XML Schema

In addition to standardizing information models and ISO EXPRESS language, the ISO committee responsible for AP233 also standardizes implementation methods such as file formats and programming interfaces driven directly from the ISO EXPRESS language. The AP233 XML Schema is based on one of those implementation method standards - ISO 10303-28 EXPRESS to XML Bindings, Edition 2, to be published in 2005. ISO 10303-28 is often called "Part 28". That standard allows multiple possible mappings from EXPRESS into XML Schema. For the purposes of AP233 implementation, the simple, default XML Schema resulting from Part 28 is used as the basis of the CADM-AP233 mapping. Since ISO EXPRESS supports, and AP233 contains, the use of multiple inheritance that is no supported by XML Schema, the AP233 EXPRESS inheritance hierarchy is not maintained in the AP233 XML Schema. For example, all attributes are migrated down the inheritance tree into each XML element.

It should be noted that the ISO EXPRESS modeling language is much more powerful than XML Schema. For example, in addition to supporting multiple inheritance, EXPRESS allows the renaming and specialization of the value domain of inherited attributes. Therefore, the automatically generated AP233 XML Schema has a few unexpected characteristics. As an example, in AP233 the concept of a document is managed and versioned similar to the way products are managed and versioned and so document is a subtype (i.e. subclass) of product. That results in Document and Document_version XML elements appearing in the XML Schema. However, the XML element relating the Document_version to the Document is named Of_product as that relationship is inherited from the Product_version to Product relationship.

3.1 Conventions Used In This Document

The following conventions are used within the text of this document.

  • The names of an XML elements in the CADM or AP233 XML Schema are represented in this font.
  • The name of External Classes are presented in this font.
  • Small examples of XML exchange documents are presented like this:
    <ap233:Organization id="i1">
      <Name>Company A</Name>
    </ap233:Organization>
    

3.2 External Class in the AP233 XML Schema

The XML Schema elements involved in the use of external classes are as follows.

  • External_class_library element child Id element which specifies a unique identifier for the external classes. This is often a URI or Web site. A Description child element containing a text description of the library may also be specified.
  • External_class child elements Id that is the unique identifier for the class (often a URI) or Name that is the unique name for the class within the library and External_source which refers to the External_class_library identifying the library in which the class is defined.
  • Classification_assignment element with child elements Assigned_class referring to the External_class element for the class being assigned and Items referring to the AP233 XML elements representing whatever is being classified.

3.3 Context in the AP233 XML Schema

In AP233, the context of the definition data about a thing is represented as objects. All definitions exist in an initial context and may also be applicable in others. This shown in following UML diagram.

Context UML Diagram

The XML Schema elements involved are as follows.

  • Product_view_definition, of which there are many kinds (see AP233 is Product-centric), with child element Initial_context referring to a View_definition_context and optionally Additional_contexts referring to one or more View_definition_context.
  • View_definition_context with child elements Description, Life_cycle_stage and Application_domain containing text.

3.4 Dates and times in the AP233 XML Schema

In AP233, dates and times are represented as objects. An assignment object then links the date and/or time to the items for which it applies. That assignment is then classified to specify the type of the date and/or time or the context of the assignment. The following UML diagram shows how dates and times are related and assigned.

AP233 Date and Time UML Diagram

The XML Schema elements involved are as follows.

  • Calendar_date element with child elements Year_number, Month_in_year_number and Day_in_month_number each containing an integer value representing the year, month and day.
  • Date_time element with child elements Date_component referencing a Calendar_date and Time_component referencing a Local_time.
  • Local_time element with child elements Hour_in_day, optional Minute_in_hour, optional Second_in_minute each containing an integer value representing the hour in the 24-hour clock, minute and second along with a Zone element referring to a Time_offset.
  • Time_offset element with child elements Hour_offset and optional Minute_offset each containing an integer representing the hour and minute difference from the Coordinate Universal Time along with an Offset_orientation element containing one of the fixed strings exact, ahead or behind.
  • Date_or_date_time_assignment element relating the date and/or time and the dated item through its child elements, the Assigned_date element and the Items element which refers to whatever is being assigned a date and/or time. The Role child element and classification specify the meaning of the assignment.

An example XML dataset showing a Calendar_date being classified and assigned follows.

<ap233:Calendar_date id="id-33333">
  <Year_component>2007</Year_component>
  <Month_component>01</Month_component>
  <Day_component>01</Day_component>
</ap233:Calendar_date>

<ap233:Date_or_date_time_assignment id="id-66666">
  <Assigned_date>
    <ap233:Calendar_date ref="id-33333" xsi:nil="true" />
  </Assigned_date>
  <Items>
    <ap233:Interface_connection ref="id-11111" xsi:nil="true" />
  </Items>
</ap233:Date_or_date_time_assignment>

<ap233:Classification_assignment id="id-89898">
  <Items>
    <ap233:Date_or_date_time_assignment ref="id-666666" xsi:nil="true" />
  </Items>
  <Assigned_class>
    <ap233:External_class ref="id-Date_start" xsi:nil="true" />
  </Assigned_class>
</ap233:Classification_assignment>

AP233 also supports the concept of time intervals.

The following UML diagram shows the concept of Time intervals.

AP233 Time interval UML Diagram

The XML Schema elements involved are as follows.

  • Time_interval element with child elements Id, Name and Description.
  • Time_interval_with_bounds element with child elements Id, Name, Description. The time interval is bounded in two possible ways:
    1. child elements Primary_bound and Secondary_bound that each refer to a Date or Event
    2. child elements Primary_bound refering to a Date or Event and a child element Duration_from_primary_bound refering to a Duration/code>
  • Time_interval_assignment element with child elements Assigned_time_interval refering to the Time_interval (possible with bounds), Role refering to a Time_interval_role and Items which is a set of references to AP233 things to which the time interval is applicable.
  • Time_interval_role element with child elements Name and Description.

An example XML dataset showing a Time_interval and Time_interval_with_bounds being assigned follows.

<ap233:Time_interval id="id-time2007" >
    <Id>2007</Id>
    <Name>2007 calendar year</Name>
  </ap233:Time_interval>
  
  <ap233:Time_interval_assignment>
    <Assigned_time_interval>
      <ap233:Time_interval ref="id-time2007" xsi:nil="true" />
    </Assigned_time_interval>
    <Items>
      <ap233:Document ref="id-doc99000" xsi:nil="true" />
    </Items>
  </ap233:Time_interval_assignment>
  
  <ap233:Time_interval_assignment>
    <Assigned_time_interval>
      <ap233:Time_interval_with_bounds ref="id-time2007h2" xsi:nil="true" />
    </Assigned_time_interval>
    <Items>
      <ap233:Document ref="id-doc99001" xsi:nil="true" />
    </Items>
  </ap233:Time_interval_assignment>
  
  <ap233:Time_interval_with_bounds id="id-time2007h2>
    <Id>2H2007</Id>
    <Name>Second half 2007 calendar year</Name>
    <Primary_bound>
      <ap233:Calendar_date ref="id-20070701" xsi:nil="true" />
    </Primary_bound>
    <Secondary_bound>
      <ap233:Calendar_date ref="id-20071231" xsi:nil="true" />
    </Secondary_bound>
  </ap233:Time_interval_with_bounds>
  
  <ap233:Calendar_date id="id-20070701">
    <Year_component>2007</Year_component>
    <Month_component>07</Month_component>
    <Day_component>01</Day_component>
  </ap233:Calendar_date>
  
  <ap233:Calendar_date id="id-20071231">
    <Year_component>2007</Year_component>
    <Month_component>12</Month_component>
    <Day_component>31</Day_component>
  </ap233:Calendar_date>
        

3.5 Identification in the AP233 XML Schema

In AP233, an identifier is represented as an object that is assigned to the item(s) to which it applies. That assignment is then classified to specify the type of the identifier. This allows any number of identifiers to be assigned to the same object and for the role or type and owner of the identifier to be specified.

The following UML diagram shows the concept of Identifcation_assignment.

AP233 Identification assignment UML Diagram

The XML Schema elements involved are as follows.

  • Identification_assignment element with child elements Identifier containing the text that is the identifier and Items containing references to the things to which the identifier is applicable. The Identification_assignment is then classified. If not otherwise specified in the mapping of a particular concept, classify the Identification_assignment as an Identification_code.
  • Organization_or_person_in_organization_assignment element with child elements Assigned_entity containing a reference to the organization and Items containing references to the identifiers which organization owns. The Organization_or_person_in_organization_assignment is then classified to as specifying the Id_owner.

A small example XML dataset follows.

<ap233:Organization id="i1">
  <Name>Company A</Name>
</ap233:Organization>

<ap233:Identification_assignment id="i20" >
  <Identifier>XYZ</Identifier>
  <Items><ap233:Organization id="i1" xsi:nil="true" /></Items>
</ap233:Identification_assignment>

<ap233:Classification_assignment>
  <Assigned_class>
    <ap233:External_class ref="i20" xsi:nil="true" />
  </Assigned_class>
  <Items><ap233:Organization id="i1" xsi:nil="true" /></Items>
</ap233:Classification_assignment>

<ap233:External_class id="i88">
  <Id>http://www.ap233.org/ap233_classes#DUNS_Code</Id>
  <External_source>
    <ap233:External_class_library ref="i10" xsi:nil="true" />
  </External_source>
</ap233:External_class>

<ap233:External_class id="i89">
  <Id>http://www.ap233.org/ap233_classes#Id_owner</Id>
  <External_source>
    <ap233:External_class_library ref="i10" xsi:nil="true" />
  </External_source>
</ap233:External_class>
  
<ap233:External_class_library id="i10">
 <Id>http://www.ap233.org/ap233_classes</Id>
 <Description>The AP233 Team Classes</Description>
</ap233:External_class_library>

<ap233:Organization_or_person_in_organization_assignment id="i900" >
  <Assigned_entity>
    <ap233:Organization ref="i41" xsi:nil="true" />
  </Assigned_entity>
  <Items>Identification_assignment ref="i20" xsi:nil="true" /></Items>
</ap233:Organization_or_person_in_organization_assignment>

<ap233:Organization id="i41">
  <Name>DUNN and Bradstreet</Name>
</ap233:Organization>

3.6 Text Representations in the AP233 XML Schema

In AP233 it is possible to represent various concepts as text that may be written in a formal notation. This is a different capability from adding simple descriptions using natural language.

The following figure shows the concepts and relationships related to text representations.

AP233 Text Representation UML Diagram

The XML Schema elements involved are as follows.

  • Textual_expression_representation_item with child elememt String_value containing the actual text used in the representation.
  • Textual_expression_composition with child element content which is a list or set of references to instances of Textual_expression_representation_item creating a composite text. Individual statements in a formal notation can be grouped and ordered in this manner.
  • List_of_text_based_item-wrapper and Set_of_text_based_item-wrapper each of which contain references to the Textual_expression_representation_item instances that make up the set or list. See AP233 XML data instance production rules for more on wrappers.
  • Included_text_based_representation with child element source which takes and entire block of text from an existing representation and includes it in a new one enabling reuse.
  • Text_based_representation with child elements Context_of_items referencing a Text_based_representation_context and Items referencing the set of text-related instances that make up the representation.
  • Text_based_representation_context with child elements Id and Kind denoting the identifier and kind.

A small example XML dataset follows.

<ap233:Textual_expression_representation_item id="id-text1">
   <String_value>Text 1</String_value>
 </ap233:Textual_expression_representation_item>
            
 <ap233:Textual_expression_representation_item id="id-text2">
   <String_value>Text 2</String_value>
 </ap233:Textual_expression_representation_item>
 
 <ap233:Textual_expression_composition id="id-composition1">
   <Content>
     <ap233:List_of_text_based_item-wrapper>
       <ap233:Textual_expression_representation_item ref="id-text1" xsi:nil="true" />
       <ap233:Textual_expression_representation_item ref="id-text2" xsi:nil="true" />
     </ap233:List_of_text_based_item-wrapper>
   </Content>
 </ap233:Textual_expression_composition>
 
 <ap233:Text_based_representation id="id-textrep1">
   <Context_of_items>
     <ap233:Text_based_representation_context ref="id-textnotation1" xsi:nil="true" />
   </Context_of_items>
   <Items>
     <ap233:Textual_expression_representation_item ref="id-text1" xsi:nil="true" />
     <ap233:Textual_expression_representation_item ref="id-text2" xsi:nil="true" />
     <ap233:Textual_expression_composition id="ref-composition1" xsi:nil="true" />
   </Items>
 </ap233:Text_based_representation>
 
<ap233:Text_based_representation_context id="id-textnotation1">
  <Id />
  <Kind />
</ap233:Text_based_representation_context>

<ap233:Classification_assignment id="id-notation1-assignment1">
  <Assigned_class>
    <ap233:External_class ref="id-Notation-One" xsi:nil="true" />
  </Assigned_class>
  <Items>
    <ap233:Text_based_representation_context id="id-textnotation1" xsi:nil="true" />
  </Items>
</ap233:Classification_assignment>

3.7 Descriptions in the AP233 XML Schema

In AP233 it is possible to associate a long text description with one or more other objects.

The following UML diagram shows the concept of Description_text and concepts supporting its definition.

AP233 Description_text UML Diagram

The XML Schema elements involved are as follows.

  • Description_text element with a Description child element that contains the text.
  • Description_text_assignment element that assigns the description to one ore more objects with a Description child element containing a reference to a Description_text and an Items child element containing references to the objects with which the description is being associated.

A small example XML dataset follows.

<ap233:Description_text id="i1">
  <Description>A very, very long text description of something of interest can go here.
  Because an assignment is used to relate it to the object, the text can be shared if it applies
  to more than one object.</Description>
</ap233:Textual_expression_representation_item>

<ap233:Description_text_assignment id="i20" >
  <Description>
  <ap233:Description_text id="i1" xsi:nil="true" />
  </Description>
  <Items>
    <ap233:Organization id="o1" xsi:nil="true" />
    <ap233:Organization id="o2" xsi:nil="true" />
  </Items>
</ap233:Description_text_assignment>

<ap233:Classification_assignment>
  <Assigned_class>
    <ap233:External_class ref="i88" xsi:nil="true" />
  </Assigned_class>
  <Items>
    <ap233:Description_text_assignment id="i20" xsi:nil="true" />
  </Items>
</ap233:Classification_assignment>

<ap233:External_class id="i88">
  <Id>http://www.ap233.org/ap233_classes#Contract_negotiation_guidance</Id>
  <External_source>
    <ap233:External_class_library ref="i10" xsi:nil="true" />
  </External_source>
</ap233:External_class>

3.8 Organizations and People in the AP233 XML Schema

In AP233, organizations are represented as objects. Organizations may be broken down and types of organizations are supported. Organizations may have people associated with them. Organizations may have addresses and/or locations associated with them.

AP233 Organizations UML Diagram

The XML Schema elements involved are as follows.

  • Organization element with an assigned identifier and an assigned identifier classified as a Name.
  • Organization_type with an assigned identifier classified as a Name element with an optional child element Description containing text.
  • Organization_relationship element with child elements Relating_organization and Related_organization each containing references to the Organizations involved. Organization_relationship may then be then classified as a Decomposition where the relating is the parent and the related is the child.
  • Organization_or_person_in_organization_assignment element with child elements Assigned_entity containing a reference to the organization and Items containing references to the thing to which the organization is assigned. The Organization_or_person_in_organization_assignment is then classified to as specifying its meaning.

In AP233, People can be associated with skills as well as Organizations.

AP233 Person UML Diagram

The XML Schema elements involved are as follows.

  • Person element with child element Last_name and optional child elements First_name containing text and optional Middle_names, Prefix_titles and Suffix_titles each containing a list of text strings.
  • Person_in_organization classified to specify the role(s) the person plays in the organization, with child element Containing_organization referring to the Organization and child element Concerned_person referring to the Person

A small example XML dataset follows.

<ap233:Organization id="i1">
  <Name>ABC Engineering</Name>
</ap233:Organization>

<ap233:Organization id="i2">
  <Name>ABC Systems Engineering</Name>
</ap233:Organization>

<ap233:Organization_relationship id="i3">
  <Relating_organization>
    <ap233:Organization ref="i1" xsi:nil="true" />
  </Relating_organization>
  <Related_organization>
    <ap233:Organization ref="i2" xsi:nil="true" />
  </Related_organization>
</ap233:Organization_relationship>

<ap233:Classification_assignment>
  <Assigned_class>
    <ap233:External_class ref="i10" xsi:nil="true" />
  </Assigned_class>
  <Items><ap233:Organization_relationship id="i3" xsi:nil="true" /></Items>
</ap233:Classification_assignment>

<ap233:External_class>
  <Id>http://www.ap233.org/ap233_classes#Hierarchy</Id>
  <External_source>
    <ap233:External_class_library ref="i10" xsi:nil="true" />
  </External_source>
</ap233:External_class>
  
<ap233:External_class_library id="i10">
 <Id>http://www.ap233.org/ap233_classes</Id>
 <Description>The AP233 Team Classes</Description>
</ap233:External_class_library>

3.9 Documents in the AP233 XML Schema

In AP233, documents are typically represented as being managed and under revision control. The identification and revisioning of documents is represented separately from the definition of the document (e.g. the file where it is located). The following UML diagram shows that Documents are kinds of Products.

AP233 Document UML Diagram

The XML Schema elements involved are as follows.

  • Document element with an assigned identifier classified as a Document_identification_code and child elements Name and optional Description each containing text.
  • Document_version element with an assigned identifier classified as a Document_identification_code and child elements Of_product referencing the Document of which it is a version and optional Description containing text.
  • Document_definition element with an assigned identifier classified as a Document_identification_code and a second classified as Name and child elements Defined_version referencing the Document_version of which it is a definition and optional Description containing text.
  • Physical_document_definition and Digital_document_definition work like Document_definition and are used when whether a the definition is a physical (i.e. paper) or digital (i.e. files on a computer) document definition are of concern.
  • Document_definition_relationship when classified as a Decomposition defines a document definition breakdown The Relating_document_definition refers to the parent and Related_document_definition refers to the child. Other relationships are also possible.
  • Document_assignment element with child elements Assigned_document containing a reference to the Document or Document_version and Is_assigned_to containing a reference to the object with which the document or version is related. Document_assignment may then be then classified to specify the type or role of the assignment.

In AP233, documents are assigned to various other AP233 concepts. The following UML diagram shows how the assignment works. In the diagram only a few of the many kinds (e.g. Activity) of concepts to which documents may be assigned.

AP233 Document Assignment UML Diagram

The XML Schema elements involved are as follows.

  • Document_assignment element with child elements Assigned_document containing a reference to the Document, Document_version or Document_definition and Is_assigned_to containing a reference to the object with which the document is related. Document_assignment may then be then classified to specify the type or role of the assignment.

An example XML dataset showing a Document_assignment follows.

<ap233:Document_assignment id="id-docassn26022">
  <Assigned_document>
    <ap233:Document_definition ref="id-docdef8757" xsi:nil="true" />
  </Assigned_document>
  <Is_assigned_to>
    <ap233:Interface_connection ref="id-iconn16650" xsi:nil="true" />
  </Is_assigned_to>
  <Role>System_interface_description_element</Role>
</ap233:Document_assignment>

<ap233:Classification_assignment id="id-260229494">
  <Items>
    <ap233:Document_assignment ref="id-docassn26022" xsi:nil="true" />
  </Items>
  <Assigned_class>
    <ap233:External_class 
      ref="id-System_interface_description_element" xsi:nil="true" />
  </Assigned_class>
</ap233:Classification_assignment>

In AP233, documents can be related to Uniform Resource Locators (as well as any other external location). The following UML diagram shows how the assignment works.

AP233 Document URL UML Diagram

The XML Schema elements involved are as follows.

  • File_location_identification element with child element Item containing a reference to the Digital_document_definition located. The File_location_identification may then be classified to specify the type of location (e.g. URL) and has an assigned identifier that is text representing the location (e.g. URL string value such as "HTTP://www.example.org/index.html") also classified as appropriate (e.g. URL).

A small example XML dataset follows.

3.10 Activities in the AP233 XML Schema

In AP233, activities are represented as a set of objects. There are three stages in the life cycle of an activity that are supported. These are defined as follows.

typical activity
an activity that may happen (i.e. the design of the activity)
planned activity
an anticipated occurrence of a typical activity that is planned at some time in the future
actual activity
an actual occurrence of a typical activity that has taken place

The following diagram shows how the stages of activity relate.

AP233 Activity Concepts

An AP233 typical activity can be considered the design or concept of an activity. It is represented in AP233 as an Activity method. The following UML diagram shows the concepts related to Activity methods.

AP233 Activity Method UML Diagram

The XML Schema elements involved are as follows.

  • Activity element with child elements Id, Description and Name each containing text, as well as Chosen_method referring to an Activity_method.
  • Activity_method element with child elements Id and Name each containing text. The classified as a Typical_activity in the case that the activity is not part of an explicit plan and has not yet already occurred (i.e. when it is the design of an activity that might occur).
  • Activity_relationship element with child elements Relating_activity and Related_activity each containing a reference an involved Activity. Activity_relationship may then be then classified as a Activity_decomposition where the relating is the parent and the related is the child.
  • Activity_method_relationship element with child elements Relating_activity_method and Related_activity_method each containing references to the Activitys involved. Activity_method_relationship may then be then classified as a Activity_decomposition where the relating is the parent and the related is the child.

A small example XML dataset follows.

<ap233:Activity id="i1">
  <Name>Top step</Name>
</ap233:Activity>

<ap233:Activity_method id="i2">
  <Name>Lower step</Name>
</ap233:Activity_method>

<ap233:Activity_relationship id="i3">
  <Relating_activity>
    <ap233:Activity ref="i1" xsi:nil="true" />
  </Relating_activity>
  <Related_activity>
    <ap233:Activity ref="i2" xsi:nil="true" />
  </Related_activity>
</ap233:Activity_relationship>

<ap233:Classification_assignment>
  <Assigned_class>
    <ap233:External_class ref="i10" xsi:nil="true" />
  </Assigned_class>
  <Items>
     <ap233:Organization_relationship id="i3" xsi:nil="true" />
  </Items>
</ap233:Classification_assignment>

<ap233:External_class>
  <Id>http://www.ap233.org/ap233_classes#Activity_decomposition</Id>
  <External_source>
    <ap233:External_class_library ref="i10" xsi:nil="true" />
  </External_source>
</ap233:External_class>
  
<ap233:External_class_library id="i10">
 <Id>http://www.ap233.org/ap233_classes</Id>
 <Description>The AP233 Team Classes</Description>
</ap233:External_class_library>

3.10.1 Tasks in the AP233 XML Schema

In AP233, when the concept of activity is related to a structured set of tasks or processes needed to perform an activity it is represented using the AP233 Task Method concept. The following UML diagram shows the concepts related to Task Methods.

AP233 Task Method UML Diagram

3.11 Breakdowns in the AP233 XML Schema

In AP233, breakdowns are represented as a set of objects that may be change managed and version controlled. The breakdown of systems into constituents can also be change managed and version controlled. This is typically more capability than is found in diagram-based tools for system engineering. However, it enables rigorous control of the systems descriptions as they go through their development. The breakdown itself is treated separately from the thing it breaks down. These concepts are outlined in the following figure.

Conceptual View of Breakdowns
Note
The above figure was borrowed from documentation explaining ISO 10303-239 AP239 Product Life Cycle Support. Because AP233 is one of the ISO STEP suite of modular standards, the concept of breakdowns is identical in both standards.

Several types of breakdowns are supported by AP233. These are described as follows.

  • System breakdown (e.g. systems and subsystems)
  • Functional breakdown (e.g. functions and sub-functions)
  • Physical breakdown (e.g. a real-world breakdown)
  • Zone breakdown (e.g. based on a spatial location)
  • Hybrid breakdown which contain a mixture of the other types of breakdown elements

Each of the types of breakdown supported by AP233 is represented in the AP233 XML Schema as separate elements, for example System_breakdown is a separate XML element from Functional_breakdown. However, the overall structure of each follows the same pattern.

Kinds of system, functional, physical or zone breakdowns are specified using the normal AP233 classification capability to specify its type.

The following UML diagrams provides more detail about how breakdowns work in AP233. The UML classes were generated directly from the AP233 EXPRESS schema. The first diagram shows how breakdowns are identified and related to the thing they break down.

Identification of Breakdowns

The second diagram shows how the elements of the breakdown are related, through the Breakdown_element_usage class. The Relating_view is the parent and the Related_view is the child.

The Parent-Child Relationship as Usage

For each type or kind of breakdown, subclasses of the general breakdown-related classes are used in AP233. These are explained in other sections of the mapping and are where the elements that actually get used in the data exchange in most cases are specified.

3.11.1 System Breakdowns in the AP233 XML Schema

In AP233, systems are represented as a set of objects that may be change managed and version controlled. System breakdowns are kinds of breakdown in AP233 (see AP233 breakdowns for an overview).

The XML Schema elements involved are as follows.

  • The link between the thing being broken down and the breakdown itself.
    • System_breakdown with an assigned identifier and child elements Name and optional Description each containing text.
    • System_breakdown_version with an assigned identifier, refers to the System_breakdown using the Of_product child element and has an optional child element Description containing text.
  • The identification of the elements of the system breakdown.
    • System_element with an assigned identifier and child elements Name and optional Description each containing text.
    • System_element_version with an assigned identifier, refers to the System_element using the Of_product child element and has an optional child element Description containing text.
    • System_element_definition with an assigned identifier and refers to the System_element_version using the Defined_version child element.
    • System_element_usage classified as a Decomposition, which defines the decomposition relationship for the system breakdown, with a child element Relating_view referring to the parent System_element_definition in the decomposition and a child element Related_view referring to the child System_element_definition in the decomposition.
    • System_breakdown_context with an assigned identifier and refers to the System_breakdown_version using the Breakdown child element and refers to the System_element_definition using the Breakdown_element child element.

An example XML dataset showing a Product, Breakdown and System_element follow.

<ap233:Product id="id-Product-8769">
  <Id>505051</Id>
  <Name>TRP Network Alpha K-0</Name>
  <Description>Planned network for the Army TR generation.</Description>
</ap233:Product>

<ap233:Classification_assignment id="id-876994049494">
  <Items>
    <ap233:Product ref="id-Product-8769" xsi:nil="true" />
  </Items>
  <Assigned_class>
    <ap233:External_class ref="id-Network" xsi:nil="true" />
  </Assigned_class>
</ap233:Classification_assignment>

<ap233:Product_version id="id-Product_version-8769">
  <Id>1</Id>
  <Of_product>
    <ap233:Product ref="id-Product-8769" xsi:nil="true" />
  </Of_product>
</ap233:Product_version>

<ap233:Product_view_definition id="id-Product_view_definition-8769">
  <Id>1</Id>
  <Name>TRP Network Alpha K-0</Name>
  <Defined_version>
    <ap233:Product_version ref="id-Product_version-8769" xsi:nil="true" />
  </Defined_version>
  <Initial_context>
    <ap233:View_definition_context ref="" xsi:nil="true" />
  </Initial_context>
</ap233:Product_view_definition>

<ap233:System_element id="id-sysel8769">
  <Id>505051</Id>
  <Name>TRP Network Alpha K-0</Name>
  <Description>Planned network for the Army TR generation.</Description>
</ap233:System_element>

<ap233:Classification_assignment id="id-sysel876993039">
  <Items>
    <ap233:System_element ref="id-sysel8769" xsi:nil="true" />
  </Items>
  <Assigned_class>
    <ap233:External_class ref="id-Network" xsi:nil="true" />
  </Assigned_class>
</ap233:Classification_assignment>

<ap233:System_element_version id="id-syselver8769">
  <Id>1</Id>
  <Of_product>
    <ap233:System_element ref="id-sysel8769" xsi:nil="true" />
  </Of_product>
</ap233:System_element_version>

<ap233:System_element_definition id="id-syseldef8769">
  <Id>1</Id>
  <Name>TRP Network Alpha K-0</Name>
  <Defined_version>
    <ap233:System_element_version ref="id-syselver8769" xsi:nil="true" />
  </Defined_version>
  <Initial_context>
    <ap233:View_definition_context ref="id-sv2" xsi:nil="true" />
  </Initial_context>
</ap233:System_element_definition>

<ap233:System_breakdown id="id-System_breakdown-8769">
  <Id>505051</Id>
  <Name>Breakdown of: TRP Network Alpha K-0</Name>
  <Description>Breakdown of network</Description>
</ap233:System_breakdown>

<ap233:System_breakdown_version id="id-System_breakdown_version-8769">
  <Id>1</Id>
  <Of_product>
    <ap233:System_breakdown ref="id-System_breakdown-8769" xsi:nil="true" />
  </Of_product>
</ap233:System_breakdown_version>

<ap233:Breakdown_of id="id-Breakdown_of-8769">
  <Id>505051</Id>
  <Name>Breakdown of: TRP Network Alpha K-0</Name>
  <Description>Breakdown of network</Description>
  <Breakdown>
    <ap233:System_breakdown_version 
      ref="id-System_breakdown_version-8769" xsi:nil="true" />
  </Breakdown>
  <Of_view>
    <ap233:Product_view_definition 
      ref="id-Product_view_definition-8769" xsi:nil="true" />
  </Of_view>
</ap233:Breakdown_of>

<ap233:Breakdown_context id="id-Breakdown_context-8769">
  <Id>505051</Id>
  <Name>Breakdown of: TRP Network Alpha K-0</Name>
  <Description>Breakdown of network</Description>
  <Breakdown>
    <ap233:System_breakdown_version 
      ref="id-System_breakdown_version-8769" xsi:nil="true" />
  </Breakdown>
  <Breakdown_element>
    <ap233:System_element_definition ref="id-syseldef8769" xsi:nil="true" />
  </Breakdown_element>
</ap233:Breakdown_context>

3.11.2 Functional Breakdowns in the AP233 XML Schema

In AP233, functions are represented as a set of objects that may be change managed and version controlled. Functional breakdowns are kinds of breakdown in AP233 (see AP233 breakdowns for an overview). As was stated in the overview of AP233 breakdowns, a single pattern is followed for all types or kinds of breakdowns. Therefore, the representation of AP233 functional breakdowns works in exactly the same manner as the AP233 system breakdowns work. As an earlier section described system breakdowns in detail, the pattern applied there need not be repeated here. All of the mapping specified in AP233 System Breakdowns is to be applied except for the following change of XML element names.

  • Functional_breakdown replaces System_breakdown
  • Functional_breakdown_version replaces System_breakdown_version
  • Functional_element replaces System_element
  • Functional_element_version replaces System_element_version
  • Functional_element_definition replaces System_element_definition
  • Functional_element_usage replaces System_element_usage
  • Functional_element_context replaces System_element_context

3.12 Interfaces and connections in the AP233 XML Schema

The terms used in AP233 related to interfaces and connections does not align exactly with the terms used in other standards, so special care should be taken when implementing this section of the CADM-AP233 mapping.

In AP233, an Interface connector is the term for the part of a system that interacts with other systems or the environment and the Interface connection is the link between connectors. This is illustrated in the following figure.

AP233 Interface Connectors and Interface Connections Concept
Note
AP233 has a lot of capability in the area of interfaces and connections. However, the simpler forms of AP233 connection and connectors are sufficient for the DoDAF views considered in the current mapping.

The following UML diagram shows how the concept of Interface Connection (i.e. the line between two connected things in a diagram) works. The connection can be made between, among other things not shown on the diagram, any kind of Breakdown element.

AP233 Interface Connection UML Diagram

The following UML diagram shows how the concept of Interface Connectors. Interface connectors are often called Ports. Interface connectors are change managed and so are kinds of AP233 Product.

AP233 Interface Connector UML Diagram

The XML Schema elements involved are as follows.

  • Identifying the connection (aka the interface)
    • Interface_definition_connection with an assigned identifier and optional child element Description containing text and two child elements Connecting and Connected that refer to the things which are connected. The Interface_definition_connection may then be classified to specify additional information as required (e.g. to specify a key interface).
  • Identifying the connector, if necessary
    • Interface_connector with an assigned identifier and optional child elements Name and Description containing text.
    • Interface_connector_version an assigned identifier and a child element Of_product referring to the Interface_connector.
    • Interface_connector_definition an assigned identifier, a child element Defined_version referring to the Interface_connector_version and a child element Connector_on referring to the definition of the thing on which the connector (i.e. Port) exists.

An example XML dataset showing an Interface_connection follows.

<ap233:Interface_connection id="id-iconn16650">
  <Id>1007</Id>
  <Description>Interface between TRP-MAPAM and TRP-UM</Description>
  <Connection_type>System_interface</Connection_type>
  <Connecting>
    <ap233:System_element_definition ref="id-12699" xsi:nil="true" />
  </Connecting>
  <Connected>
    <ap233:System_element_definition ref="id-12783" xsi:nil="true" />
  </Connected>
</ap233:Interface_connection>

<ap233:Classification_assignment id="id-1665093039">
  <Items>
    <ap233:Interface_connection ref="id-iconn16650" xsi:nil="true" />
  </Items>
  <Assigned_class>
    <ap233:External_class ref="id-System_interface" xsi:nil="true" />
  </Assigned_class>
</ap233:Classification_assignment>

3.13 Locations and facilities in the AP233 XML Schema

In AP233, locations and/or facilities where activities can occur or products are represented as objects to which activities, products, etc. are assigned. The following figure shows how locatations themselves are represented. The location may have a detailed representation, for example using a grid representation, or may simply be a location with only a simple text description. In the diagram, the detailed representation of Organization and Address are shown but the other three are not for brevity.

Representing a Location UML diagram

In AP233 an assignment links the location with the thing which has that location. The following UML diagram shows these structures. Note that only a few of the kinds of things to which locations can be related are shown - many things can have locations. Also note that locations can be related to each other (e.g. room within a building).

Assigning a Location to a Something UML diagram

The XML Schema elements involved are as follows.

  • Location with an child element Name and optional child element Description containing text.
  • Location_assignment with a child element Entity_for_location referring to the thing located at the location and child element location_for_assignment referring to the Location.
  • Location_relationship with child elements Relating referring to the containing Location and Related referring to the contained Location.
  • Address_based_location_representation with a child element Postal_address referring to the Address of the location.
  • Organization_based_location_representation with a child element Organization_for_location referring to the Organization that is the location.
  • Global_location_representation with child elements Latitude and Longitude (using Numerical_item_with_unit and unit Plane_angle_unit, see Property values), optional Altitude (using Numerical_item_with_unit and unit Length_unit) and optional Geographical_area containing text specifying the location's geographical, physical or political region ed location (e.g. Pacific Ocean).
  • Regional_grid_location_representation with child elements Name and optionally a Description of the location. Also, one or more Regional_coordinates refer to the Regional_grid_location_representation through Grid_system and have a Name containing text and a Coordinate_value with a value (see Property values).
  • Product_based_location_representation with child elements Referenced_product referring to the thing that is the location (e.g. a Interface connection, Interface definition connection, or Breakdown), Location_identification containing text that identifies the location and an optional Location_name containing text.

3.14 Assignments (aka Relationships/Associations) in the AP233 XML Schema

In AP233, associating items such as documents and approvals with things is represented using an assignment pattern. This holds for most cases of interest in the CADM-AP233 mapping. The general pattern is shown in the following diagram.

Assignment Pattern Example - Security Assignment

In AP233, the assignment pattern consists of the following kinds of objects.

  • A things to which something may be assigned. These are made subclasses of a general purpose class (in ISO EXPRESS these are select types that are more like a union than a generalization). In the security classification example, this is the security_classification_item which has many subclasses only a few of which are shown in the above figure.
  • The thing being assigned. The Security_classification in the security classification example.
  • The assignment itself which references specific things to which something is assigned via the Items element and which reference the thing being assigned through another child element (the Classification element in the figure above. One assignment can typically be used to assign one concept to many things (e.g. the same security level can be assigned to thousands of documents).

An example XML dataset showing Security_classification applied to an Interface_connection follows.

<ap233:Interface_connection id="id-11111">
  <Id>1007</Id>
  <Description>Interface between TRP-MAPAM and TRP-UM</Description>
  <Connection_type>System_interface</Connection_type>
  <Connecting>
    <ap233:System_element_definition ref="id-22222" xsi:nil="true" />
  </Connecting>
  <Connected>
    <ap233:System_element_definition ref="id-33333" xsi:nil="true" />
  </Connected>
</ap233:Interface_connection>
    
<ap233:Security_classification_assignment id="id-90909">
  <Classification>
    <ap233:Security_classification ref="id-Unclassified" xsi:nil="true" />
  </Classification>
  <Items>
    <ap233:Condition ref="id-11111" xsi:nil="true" />
  </Items>
</ap233:Security_classification_assignment>

3.15 Conditions in the AP233 XML Schema

AP233 supports the concept of conditionals applied to data.

The following UML diagram shows the concept of Condition and concepts supporting its definition.

AP233 Condition UML Diagram

The following XML elements are used to represent AP233 conditions.

  • a Condition with child elements Name and optional Description
  • a Condition_assignment with child element Assigned_condition refering to a Condition and Item refering to another AP233 concept (most concepts can have conditions applied).

An example XML dataset showing a Condition and related assignment follows.

<ap233:Condition id="id-11111">
  <Id>1007</Id>
  <Description>Was Approval of US Navy CONOPS Received</Description>
</ap233:Condition>

<ap233:Condition_assignment id="id-90909">
  <Assigned_condition>
    <ap233:Condition ref="id-11111" xsi:nil="true" />
  </Assigned_condition>
  <Item>
    <ap233:Interface_connection ref="id-11111222" xsi:nil="true" />
  </Item>
</ap233:Condition_assignment>

3.16 Approvals in the AP233 XML Schema

In AP233, associating approvals with items such as documents is represented using a specific kind of assignment. The following UML diagram shows how this works. There are many things that can be approved even though only Product View Definition is shown in the diagram. See AP233 Dates and times for more detail on assigning a Calendar Date for the Approval. The Approving Person and/or Organization can also be assigned.

AP233 Approvals UML Diagram

The XML Schema elements involved are as follows.

  • Approval with child elements Purpose containing text and optional Planned_date and Actual_date referring to the Calendar_date when the approval was planned or actually occurred. The Approval is then classified with an appropriate status (e.g. Approved).
  • Approval_assignment, with child elements Assigned_approval referring to the Approval and Items creferring to the items. The Approval_assignment is also classified to specify its type.
  • Approving_person_organization with child elements Authorized_approval referring to the Approval, Person_organization referring to the Person or Organization and Approval_date referring to the Calendar_date when the approval by the particular person or organization occurred. Note that more than one person or organization may be required to approve something before the entire Approval itself is complete. The Approving_person_organization is then classified to specify the role the person or organization played for the Approval.

3.17 Properties in the AP233 XML Schema

In AP233, properties, such as cost or mass, related to things are handled in a very generic manner. This enables the AP233 XML structures to represent many different kinds of properties. However, that means the specific properties of interest in the systems architecture and engineering discipline are not standardized in AP233. The AP233 classification capability is used to specify the properties of interest.

3.17.1 Representing Property Values in the AP233 XML Schema

In AP233, the representation of a property value is separated from the specification that a thing has a property. This allows for a variety of representations, with different values and units to be defined. The following UML diagram shows the concepts and their relationships.

AP233 Property Values UML Diagram

A small example XML dataset for representing a monetary value follows.

<ap233:Property_value_representation id="id-4" >
  <Context_of_items>
    <ap233:Numerical_representation_context ref="id-20" xsi:nil="true" />
  </Context_of_items>
  <Items>
    <ap233:Numerical_item_with_unit ref="id-5" xsi:nil="true" />
  </Items>
</ap233:Property_value_representation>

<ap233:Numerical_item_with_unit id="id-5" >
  <Value_component>12300.00</Value_component>
  <Unit>
    <ap233:Unit ref="id-7" xsi:nil="true" />
  </Unit>
</ap233:Numerical_item_with_unit>

<ap233:Unit id="id-7">
  <Name>US Dollars</Name>
  <Si_unit>false</Si_unit>
</ap233:Unit>

<ap233:Unit id="id-77">
  <Name>British Pounds</Name>
  <Si_unit>false</Si_unit>
</ap233:Unit>

<ap233:Numerical_representation_context id="id-20" >
  <Id>Currency</Id>
  <Kind>Valid World Currencies</Kind>
  <Units>
    <ap233:Unit ref="id-7" xsi:nil="true" />
    <ap233:Unit ref="id-77" xsi:nil="true" />
  </Units>
</ap233:Numerical_representation_context>

3.17.2 Assigning General Properties in the AP233 XML Schema

In AP233, a characterization of the circumstances under which a thing has a related property is supported. For example, whether the property is measured, predicted or required can be stated. The AP233 classification capability is used to specify this and is applied to the Assigned_property.

The following UML diagram shows the details of how general properties work in AP233. The UML classes were generated directly from the AP233 EXPRESS schema. In the diagram only Interface_connection is shown as a subclass of property_assignment_select as an example, there are many other concepts to which this general property capability may be assigned. Please see the special case capability for Activity Properties and Resource Properties.

AP233 Property Assignment UML Diagram

3.17.3 Assigning Activity Properties in the AP233 XML Schema

In AP233, a characterization of the circumstances under which a thing has a related property is supported. For example, whether the property is measured, predicted or required can be stated. The AP233 classification capability is used to specify this and is applied to the Activity_property.

The following UML diagram shows the details of how activity properties work in AP233. The UML classes were generated directly from the AP233 EXPRESS schema.

AP233 Activity Property UML Diagram

A small example XML dataset for linking a cost to an activity. See AP233 property value approach for an example of representing the cost value itself.

<ap233:Activity id="id-1" >
</ap233:Activity>

<ap233:Activity_property id="id-2">
  <Name>Cost</Name>
  <Description></Description>
  <Described_element>
    <ap233:Activity ref="id-1" xsl:nil="true" />
  </Described_element>
</ap233:Activity_property>

<ap233:Classification_assignment>
  <Assigned_class>
    <ap233:External_class ref="id-8" xsi:nil="true" />
  </Assigned_class>
  <Items><ap233:Activity_property id="id-2" xsi:nil="true" /></Items>
</ap233:Classification_assignment>

<ap233:External_class id="id-8">
  <Id>http://www.ap233.org/ap233_classes#Estimated_Cost</Id>
  <External_source>
    <ap233:External_class_library ref="id-100" xsi:nil="true" />
  </External_source>
</ap233:External_class>

<ap233:External_class_library id="id-100">
 <Id>http://www.ap233.org/ap233_classes</Id>
 <Description>The AP233 Team Classes</Description>
</ap233:External_class_library>

<ap233:Activity_property_representation id="id-3" >
  <Property>
    <ap233:Activity_property ref="id-2" xsl:nil="true" />
  </Property>
  <Rep>
    <ap233:Property_value_representation ref="id-4" xsi:nil="true" />
  </Rep>
</ap233:Activity_property_representation>

<ap233:Property_value_representation id="id-4" >
  <Context_of_items>
    <ap233:Numerical_representation_context ref="id-20" xsi:nil="true" />
  </Context_of_items>
  <Items>
    <ap233:Numerical_item_with_unit ref="id-5" xsi:nil="true" />
  </Items>
</ap233:Property_value_representation>

3.17.4 Assigning Resource Properties in the AP233 XML Schema

In AP233, a characterization of the circumstances under which a thing has a related property is supported. For example, whether the property is measured, predicted or required can be stated. The AP233 classification capability is used to specify this and is applied to the Resource_property.

The following UML diagram shows the details of how resource properties work in AP233. The UML classes were generated directly from the AP233 EXPRESS schema.

3.18 Statecharts and State Machines in the AP233 XML Schema

In AP233, the representation of Statecharts/State Machines is supported by two key concepts, State definition and State transition definition. There are several kinds of Statecharts and State Machines and so a flexible approach making use of AP233 classification is utilized.

The following UML diagram shows the concept of State definition and its basic relationships. State defintions can be composed and transitions between them defined. State definitions may also have Activity methods related to them. An Activity method is always used to represent the design or class or type of an activity, behavior or event.

AP233 State Definition UML Diagram

The XML Schema elements involved are as follows.

  • State_definition element with child elements Name and Description each containing strings.
  • Composition_of_state_definition element with child elements Name and Description each containing strings, and child elements Relating and Related representing the whole and part State each referencing a State_definition.
  • A Typical activity represented as an Activity_method as specified in Activities in AP233 assigned to the State_definition.

The following UML diagram shows the concept of State transition definition and concepts supporting its definition. State transition definitions may have Conditions related to them. The related Condition must be true before the transition can occur.

AP233 State Transition Definition UML Diagram

The XML Schema elements involved are as follows.

  • State_transition_definition element with child elements Name and Description each containing strings, and child elements Relating and Related representing the source and target and each referencing a State_definition.
  • Condition element with child elements Name and Description each containing strings, and a related Condition_assignment with child element Item referencing the State_transition_definition and child element Assigned_condition referencing the Condition.
  • A Typical activity represented as an Activity_method as specified in Activities in AP233 assigned to the State_transition_definition.
Warning
The following section concerning Parameters is an initial statement of the needs, not the final AP233 support for Parameters.

The following UML diagram shows the example of Activity method and relating a General Model Parameter to the Activity method. The diagram does not show everything to which a General Model Parameter can be associated nor all the possible default values of the parameter.

AP233 State-related Activity Method Paremeters UML Diagram

3.19 Risk Management in the AP233 XML Schema

AP233 includes support for Risk Management.

Note
AP233 Risk Management is one of its least mature capabilities. Therefore, only the core concepts are utilized in this version of this documentation.

The following UML diagram shows the concept of Risk.

AP233 Risk UML Diagram

The XML Schema elements involved are as follows.

  • Risk containing Id, Name and optional Description each containing text.
  • Risk_relationship containing Id, Name and optional Description each containing text. Also containing a Relating_risk and Related_risk that each refer to a Risk.

3.20 General Group Mechanism in the AP233 XML Schema

AP233 includes a general grouping mechanism. This flexible approach requires the use of the AP233 classification capability to specify the details of what the AP233 Group is used to represent. Almost every concept in AP233 can be grouped using this mechanism. AP233 Groups can also be related to each other.

The following UML diagram shows the Group concepts.

AP233 Group UML Diagram

The XML Schema elements involved are as follows.

  • A Group element containing the following that defines an AP233 Group.
    • an optional child element Id that is text
    • a Name child element that is text
    • an optional Description child element containing text
    • an Elements child element that contains references to the other AP233 XML data that is part of the group.
  • A Group_relationship element containing the following that relates AP233 Groups.
    • an optional Description child element containing text
    • a Relation_type containing text
    • a Relating_group child element that contains a reference to the first an AP233 Group.
    • a Related_group child element that contains a reference to the second AP233 Group.

An example AP233 XML dataset follows.

<ap233:Group id="id-1005555">
  <Name>Example Group Number 1 grouping two Activity Methods</Name>
  <Elements>
    <ap233:Activity_method ref="id-1000027" xsi:nil="true" /> 
    <ap233:Activity_method ref="id-1000035" xsi:nil="true" /> 
  </Elements>
</ap233:Group>
<ap233:Classification_assignment id="id-ca1005555">
  <Items>
    <ap233:Group ref="id-10055555" xsi:nil="true" />
  </Items>
  <Assigned_class>
    <ap233:External_class ref="id-Activity_set" xsi:nil="true" />
  </Assigned_class>
</ap233:Classification_assignment>
<ap233:Group_relationship>
  <Relation_type>Group</Relation_type>
  <Relating_group>
    <ap233:Group ref="id-1005555" xsi:nil="true" /> 
  </Relating_group>
  <Related_group>
    <ap233:Group ref="id-1005556" xsi:nil="true" /> 
  </Related_group>
</ap233:Group_relationship>

3.21 Requirements Management in AP233

AP233 provides support for Requirements Management in the same way that is supports the management of other kinds of items, by treating a Requirement as a kind of Product. This enables Requirements to have versions, different definitions, different representations and be managed by organizations, with associated dates, status, etc.

The following UML diagram shows the basic structure of the AP233 Requirements concepts.

AP233 Requirements Basics UML Diagram

AP233 supports the versioning of requirements and allows for multiple definitions of the same version (e.g. a text- and property-based definition of the same requirement).

An example AP233 XML dataset follows.

<ap233:Requirement id="id-req12699">
  <Id>24100226</Id>
</ap233:Requirement>

<ap233:Requirement_version id="id-reqver12699" >
  <Id>1</Id>
  <Of_product>
    <ap233:Requirement ref="id-req12699" xsi:nil="true" />
  </Of_product>
</ap233:Requirement_version>

<ap233:Requirement_view_definition id="id-reqdef1111">
  <Id>24100226-DEFN-1</Id>
  <Name />
  <Defined_version>
    <ap233:Requirement_version ref="id-reqver12699" xsi:nil="true" />
  </Defined_version>
  <Initial_context>
    <ap233:View_definition_context ref="id-ov3" xsi:nil="true" />
  </Initial_context>
</ap233:Requirement_view_definition>

AP233 supports the concept of a Requirements Collection which groups together sub-requirements into a super-requirement.

An example AP233 XML dataset follows.

<ap233:Requirement_view_definition id="id-reqdef1111">
    <Id>24100226-DEFN-1</Id>
    <Defined_version>
      <ap233:Requirement_version ref="id-reqver12699" xsi:nil="true" />
    </Defined_version>
    <Initial_context>
      <ap233:View_definition_context ref="id-ov3" xsi:nil="true" />
    </Initial_context>
  </ap233:Requirement_view_definition>
  
  <ap233:Requirement_view_definition id="id-reqdef2222">
    <Id>24100226-IER_FREQ_HIGH_QY-DEFN-1</Id>
    <Defined_version>
      <ap233:Requirement_version ref="id-reqver12699" xsi:nil="true" />
    </Defined_version>
    <Initial_context>
      <ap233:View_definition_context ref="id-ov3" xsi:nil="true" />
    </Initial_context>
  </ap233:Requirement_view_definition>
  
  <ap233:Requirement_collection_relationship id="id-reqcol5000">
    <Relating_view>
      <ap233:Requirement_view_definition ref="id-reqdef1111" xsi:nil="true" />
    </Relating_view>
    <Related_view>
      <ap233:Requirement_view_definition ref="id-reqdef2222" xsi:nil="true" />
    </Related_view>
</ap233:Requirement_collection_relationship>

As with other AP233 concepts, the use of classification enables the specification of any number of categories or types of requirements.

The following UML diagram shows the mechanism for handling the categorization or classification of AP233 Requirements concepts. In the diagram, one example External_class representing the possible classification of a requirement as being a FunctionalRequirement is shown. Practically, this means that a FunctionalRequirement is a kind of (or subclass of) Requirement.

Note
In UML an instance of a class is denoted by a box with the class name underlined. The name of the instance precedes the class name separated by a colon.
AP233 Requirements Categories UML Diagram

AP233 provides the capabilbity of specifying the source of a requirement. Many kinds of possible sources are supported - not all of which are shown in the following UML diagram.

The following UML diagram shows AP233 support for the sources of Requirements.

AP233 Requirements Sources UML Diagram

Requirements can be assigned to many concepts in AP233. The semantics of the assignment are specified directly in some cases but are specified using classification in other cases.

The following UML diagram shows the AP233 Requirements Assignments.

AP233 Requirements Assignments UML Diagram

3.22 AP233 XML data instance production rules

When producing an AP233 XML Schema-based dataset, the following rules are applicable.

  1. When the ref XML attribute is used to make a reference to an XML element, xsi:nil="true" must be specified. For example, here's a Relating_method attribute value for a Activity_method_relationship element:
         <Relating_method>
           <ap233:Activity_method ref="id-1000027" xsi:nil="true" /> 
         </Relating_method>
         
  2. In some cases an artifical wrapper is created in the XML binding of the ISO EXPRESS information modeling language. This happens when it is necessary to allow for the coercion the type of an instance or value into the appropriate datatype. For example, in the following case a wrapper is used to specify that the collection of Textual_expression_representation_items is indeed a list, and not simply a set.
          <ap233:Textual_expression_composition id="id-composition1">
           <Content>
             <ap233:List_of_text_based_item-wrapper>
               <ap233:Textual_expression_representation_item ref="id-text1" xsi:nil="true" />
               <ap233:Textual_expression_representation_item ref="id-text2" xsi:nil="true" />
             </ap233:List_of_text_based_item-wrapper>
           </Content>
         </ap233:Textual_expression_composition>
       

4 Appendix A : AP233 schemas, models and ontology files

AP233 is available in several formats. This appendix contains links to AP233 represented in various computer interpretable formats for use by implementers.

Warning
AP233 and its XML Schema and XMI representation were still undergoing ISO standardization at the time of the publication of this document.
AP233 formatFile location
ISO EXPRESS text zippedexp.zip of AP233 Working Draft 2 edited to fix several issues.
ISO XML SchemaAP233 XML Schema zipped that imports a related utility XML Schema
XMIAP233 XMI file zipped generated using the exff toolkit and provided as a convienence for implementers. This XMI file was the basis for all the UML diagrams in this documentation.
AP233 MagicDraw 11 UML 2 File (import of UML 1.5 XMI file) mdzip