• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Table 1
 

Table 1

on

  • 1,076 views

 

Statistics

Views

Total Views
1,076
Views on SlideShare
1,076
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Table 1 Table 1 Document Transcript

    • syseng/05-05-01 Object Management Group First Needham Place 250 First Avenue, Suite 100 Needham, MA 02494 Telephone: +1-781-444-0404 Facsimile: +1-781-444-0320 UML Profile for DODAF/MODAF (UPDM) DRAFT Request For Proposal OMG Document: syseng/05-05-01 (To Be Assigned) Letters of Intent due: <month> <day>, <year> Submissions due: <month> <day>, <year> Objective of this RFP This RFP solicits proposals for the following: • UML Profile for the Department of Defense Architecture Framework (DODAF) and the UK’s Ministry of Defence Architecture Framework (MODAF). For further details see Chapter 6 of this document. UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 1
    • syseng/05-05-01 1 2 3 4 5 6 SPECIFIC REQUIREMENTS ON PROPOSALS This section lists the specific requirements for a UML Profile for DODAF/MODAF (UPDM) that provides an industry standard UML representation for DODAF v1.0 architecture products and supports evolution to DODAF v2.0. Utilizing a common modeling language with a standard architecture framework will significantly enhance the quality, productivity, and effectiveness associated with architecture and system of systems modeling, including improved communications, model/data reuse, and tool interoperability; and will reduce re-training requirements for different tools and projects. 6.1 PROBLEM STATEMENT The current DODAF v1.0 Volume II includes guidance for representing DODAF architecture products using UML. However, this guidance is not sufficiently precise or complete. The current guidance has been interpreted many different ways by architects and users of this framework and by vendors who are implementing DODAF in their UML tools. As a result, the DODAF UML representations do not fully serve their intended use to support communications among stakeholders and re- use of the architecture products and data. The different vendor implementations also result in interoperability issues between tools, and additional training requirements for the users. In addition, UML v1.x has been superseded by UML v2.0 that is currently being augmented with a Systems Modeling Language (SysML) profile for Systems Engineering. The latter provides a much more robust system of systems modeling capability. UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 2
    • syseng/05-05-01 Work is currently underway to evolve DODAF v1.0 to DODAF v2.0. This may add new requirements for the UPDM. DODAF v2.0 will define several overlays that support key transformational processes (e.g., acquisition, budgeting and portfolio management) and must maintain architectural consistency across the overlays. [Editor’s Note: elaborate on DODAF v2.0 requirements as they become available]. MODAF is the UK equivalent of DoDAF tailored to meet the needs of the UK Defence community. The UK MOD have built upon the DoDAF views and introduced two new Viewpoints covering Strategic Capability (High-level User requirements and Enterprise capability trade-offs) and Acquisition (Programmatic) issues. These new developments are likely to be used by the International community in the future, when data is exchanged, and so need to be considered in the development of the profile. 6.2 SCOPE OF PROPOSALS SOUGHT The scope of this RFP is for a UPDM that satisfies the requirements outlined below. This includes representations for DODAF/MODAF views and products for modeling of the systems architecture (Systems View) along with their associated standards (Technical View) within the context of the business or enterprise architecture (Operational View). In addition it should be able to represent the UK modeling of the capability and strategic intent of the Enterprise (Strategic View) and the programmatic associated with the procurement of defense systems (Acquisition View). It should also provide a sufficiently robust capability and enhancements needed to support newly defined requirements for DODAF v2.0. Section 6.5 includes the following categories of requirements for the UPDM: • Meta-model (abstract syntax and constraints) • Standard Notation (concrete syntax) • Views and Viewpoints • Architecture products • Extensible library of reusable architecture elements and patterns • Standard data interchange mechanism (e.g., XMI) Submitters may provide partial responses to these requirements, along with a roadmap to address the complete requirements. The evaluations will assess the level of completeness as part of the evaluation criteria. It is expected that follow-on RFP’s may include additional and refined requirements as the user and vendor communities learn from their experiences in applying the profile. UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 3
    • syseng/05-05-01 The intent is to use the UPDM to directly model architectures for a broad range of complex systems, which can include hardware, software, data, personnel, and facility elements. Such an architecture model must support the analysis, specification, design, and verification of complex systems, and is intended to improve the ability to exchange architecture information amongst tools, and to help ensure consistent modeling from the system of systems level down to lower levels of design and implementation. The profile should provide the modeling of operational activities, nodes, systems, hardware, software, and organizational components, interfaces, system functions and services, performance, and physical characteristics. In addition, the profile should allow for the modeling of operational views that span the full spectrum of Doctrine, Organization, Training, Materiel, Leadership & education, Personnel, and Facilities (DOTMLPF and the UK MOD equivalent Lines of Development). The additional MODAF views (and possibly DODAF v2.0) will also introduce a requirement to model capabilities, services, projects, system ports, protocols, physical properties and units of measure. Any profile should take into account aspects of the physical world that UML has not previously addressed. These include usages of systems (i.e. a type of system being used in an assembly structure) and instances of systems, nodes, etc. A great deal could be learned from the SysML experience in this area, as well as from ISO10303 STEP. An extension of UML in response to the UML for Systems Engineering RFP is currently being developed based on UML v2.0 to support the specification, design, and analysis of complex systems. This extension is called the Systems Modeling Language (SysML), and is expected to begin adoption by the OMG in 2005. SysML should provide a foundation for the UPDM to support modeling of system of systems. (Editor’s Note: We expect SysML to be used for this RFP even though it is in draft version at the time of this RFP publication. We expect SysML to be formally adopted before submissions to this RFP are due.) If additional extensions are needed, the UPDM must rely on extension mechanisms provided by UML and MOF. A profile selects and constrains the use of existing UML modeling elements, optionally with new terminology and notations specific to that profile. Other extension mechanisms provided by the UML and MOF specifications may also be used, such as defining new types of UML modeling elements and model libraries. A combination of these extension mechanisms may be used as well. For further information about the mechanisms that UML provides for its own extension, see the specifications referenced in Section 6.3 below. 6.3 RELATIONSHIP TO EXISTING OMG SPECIFICATIONS Proposals may reference and build upon any of the OMG specifications identified in this section. In each case, the most recent version is applicable, unless the most recent version was adopted less than six months before the final submission to this specification, in which case the previous version may be used. Proposals should identify the specific dependencies they have on any of these specifications including UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 4
    • syseng/05-05-01 their specific version. Document numbers that appear below are all available as public documents from the OMG web site. The submitters are encouraged to leverage other work in progress as well. Specification category Topical area / domain Current Adopted Document # Version Meta-Object Facility (MOF™) modeling 1.4 formal/2002-04-03 2.0 finalization ptc/2004-01-13 MOF 2.0 XMI modeling 1.0 finalization ptc/2004-06-11 Unified Modeling Language™ modeling 1.5 formal/2003-03-01 (UML™) - Infrastructure 2.0 finalization ptc/2003-09-15 - Superstructure 2.0 finalization ptc/2004-10-02 - Diagram Interchange 2.0 finalization ptc/2003-09-01 - OCL 2.0 finalization ptc/2003-10-14 UML™ Testing Profile modeling 1.0 finalization ptc/2004-04-02 UML™ For Systems modeling 1.0 TBD Engineering Submission XML Metadata Interchange modeling (XML DTDs) 1.2 formal/2002-01-01 (XMI) modeling (XML Schema) 2.0 formal/2003-05-02 6.4 RELATED ACTIVITIES, DOCUMENTS AND STANDARDS The OMG Systems Engineering Domain Special Interest Group (SE DSIG) website (http://syseng.omg.org) provides extensive background materials, including sources used to derive the requirements included in this RFP that may be of benefit to a submitter. Detailed, up-to-date web links for each of the related activities, documents, and standards summarized in the sections below are provided at http://syseng.omg.org/UPDM.htm. 6.4.1 DoDAF v2.0 DoDAF v2.0 is currently in development, and will focus on defining several overlays to support key transformational processes (e.g., budgeting and portfolio management). To maintain architectural consistency across the overlays, an underlying meta-model of architecture elements and relationships is maintained. The specific requirements for DODAF v2.0 will be incorporated as they become available. 6.4.2 MODAF MODAF is the UK Ministry of Defence Architecture Framework. It is based on DODAF with some minor changes to TV-1, OV-1, OV-2, SV-1 and SV-2. In addition to this, MODAF adds two new viewpoints: UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 5
    • syseng/05-05-01 Strategic Capability Views – these views define the high level capability vision and strategic intent, the capabilities and sub-capabilities (capability functions) required to support that vision. In addition, the dependencies between capabilities, the phasing in and out of systems that support the capabilities (planned time periods of capability), and the organizations in which those systems are to be deployed are also covered. Acquisition Views – these views define the project team structures required to deliver network enabled capabilities (cf NCW). They also define the inter-project dependencies and specify the lines of development status (cf DOTMLPF) at significant project milestones. The UK has aligned the usage of an Architecture Framework to its Communities of Interest (CoI’s) processes, e.g. how MODAF should be used by those involved in Acquisition of Concepts & Doctrine. This approach increases the need to exchange data between the CoI’s. MODAF has begun to develop a UML profile – initially to support XMI-based file exchange between MODAF tools and repositories. The profile covers the whole of MODAF, and is therefore a superset of DODAF. 6.4.3 ISO 10303 (STEP) - AP233 ISO 10303 – AP233 (AP233), the Application Protocol for Systems Engineering, is focused on developing a neutral data format to exchange systems engineering information among tools. AP233 is being standardized under the ISO TC-184 (Technical Committee on Industrial Automation Systems and Integration), SC4 (Subcommittee on Industrial Data Standards), and is part of the larger STEP effort, which provides standardized models and infrastructure for the exchange of product model data. The UPDM development should be closely aligned with the on-going development of AP233, especially in the area of systems, because AP233 is being evaluated as the preferred protocol for exchanging architecture data between tools that are based on the CADM schema and tools that are based on other meta-models, or the MOF. 6.4.4 IEEE 1471 This recommended practice addresses the activities of the creation, analysis, and sustainment of architectures of software-intensive systems, and the recording of such architectures in terms of architectural descriptions. A conceptual framework for architectural description is established. The content of an architectural description is defined. Annexes provide the rationale for key concepts and terminology, the relationships to other standards, and examples of usage. [IEEE 1471] Appendix 3 presents the IEEE 1471 definitions as used in this RFP. UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 6
    • syseng/05-05-01 6.4.5 Other Standards In addition to the above standards, other architecture modeling standards are listed in the references section of this RFP such as ISO/IEC 10746:1998, which is ISO’s Reference Model for Open Distributed Processing; ISO 15704:2000, which is ISO’s document on Requirements for Enterprise-Reference Architectures and Methodologies, and ISO 15926:2003 which is a generic, conceptual data model designed to be used in conjunction with reference data or upper ontology. 6.5 MANDATORY REQUIREMENTS 6.5.1 RFP Requirements Traceability Matrix The “Resolution of RFP requirements and requests” section of any response to this RFP shall include a matrix (see Table 1) indicating how the proposed solution satisfies each requirement in Sections 6.5 and 6.6, supplying the following information about each requirement: a. RFP requirement • Identifier • Descriptor b. Whether the proposed solution is a full or partial satisfaction of the requirement, or whether there is no solution provided c. Summary description of how the profile addresses the requirement d. Specific metaclasses that address the requirement e. Reference to specification sections that address specify the abstract and concrete syntax that satisfies the requirement f. Applicable references to DODAF and other source documentation Table 1. Requirements Traceability Matrix Req't Requirement Compliance Requirement Metaclass Spec Applicable id Descriptor (Y/N, Partial) Satisfaction Extension Reference DODAF Ref Summary UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 7
    • syseng/05-05-01 6.5.2 Sample Problem: A sample architecture model (including an XMI 2.1 representation of the sample model) must also be provided that demonstrates how your submission satisfies the requirements and addresses the issues listed in section 6.7. 6.5.3 List of Mandatory Requirements Notes in the mandatory requirements section have been included to provide additional explanatory information, and are not intended to present mandatory requirements. 6.5.3.1 Meta-model. UPDM shall provide a meta-model that includes: a) Terms and definitions b) Concepts defined as abstract syntax that extend the UML meta-model or an existing profile c) Constraints on elements in the abstract syntax that ensures connectivity and integrity of model 6.5.3.2 Notation. UPDM shall provide a standard notation (concrete syntax) that maps to the meta-model (requirement 6.5.3.1 above) using UML extension mechanisms. 6.5.3.3 Views and Viewpoints. UPDM shall provide the capability to represent views and viewpoints: a. DoDAF and MODAF-specific views and viewpoints. b. A generic mechanism for defining additional views and viewpoints for different stakeholders and overlays. 6.5.3.4 Architecture products. UPDM shall provide the capability to represent architecture products in one or more diagrams and tables using the standard notation (requirement 6.5.3.2 above). 6.5.3.5 Extensible library. UPDM shall provide the capability to represent an extensible library of reusable architecture elements (e.g., UJTLs) and patterns (e.g., C2 organizational construct, document types). 6.6 OPTIONAL REQUIREMENTS 6.6.1 Element Taxonomy. An architecture elements taxonomy may be used to specialize the generic Architecture Framework concepts with commonly used terminology, equipment types, etc. The taxonomy provides specific definitions for the (generic) elements defined in the framework – i.e. it provides reference data. Efforts are underway amongst the US, UK, Canadian and Australian defense UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 8
    • syseng/05-05-01 departments to develop a top-level taxonomy that can be agreed at an international level [IDEAS]. 6.6.2 Extensibility to Other Architecture Frameworks. UPDM may provide a capability to support other military architecture frameworks (e.g., NATO’s AF, France’s Atelier de Gestion de l’ArchiTecturE des SIC (AGATE) AF, Australian Defence Organisation’s AF). 6.6.3 Standard diagram interchange mechanism. UPDM may provide a mechanism for exchange of diagram layout (i.e., Diagram Interchange). 6.7 ISSUES TO BE DISCUSSED The issues below will be considered during submission evaluation. The discussion should not be part of the proposed normative specification but can be included in a non-normative appendix. Proposals shall discuss and/or demonstrate via sample problem how the submission addresses the following concerns: model scalability composition executability traceability of architecture models to requirements various types of architectures (e.g., services oriented architectures and net-centricity, layered) MDA support 6.8 EVALUATION CRITERIA 6.8.1 Clarity of the proposed specification for the purpose of implementing conforming modeling tools; ease of reviewing for correctness. 6.8.2 The precision, completeness, compactness, and clarity of the abstract and concrete syntax. 6.8.3 Level of training required for understanding and use of the language 6.9 OTHER INFORMATION UNIQUE TO THIS RFP None UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 9
    • syseng/05-05-01 6.10 RFP TIMETABLE The timetable for this RFP is given below. Note that the TF or its parent TC may, in certain circumstances, extend deadlines while the RFP is running, or may elect to have more than one Revised Submission step. The latest timetable can always be found at the OMG Work In Progress page at http://www.omg.org/schedules/ under the item identified by the name of this RFP. Note that “<month>” and “<approximate month>” is the name of the month spelled out; e.g., January. Event or Activity Actual Date Preparation of RFP by TF RFP placed on OMG document server Sept. meeting three week rule (August 22, 2005) Approval of RFP by Architecture Board Review by TC TC votes to issue RFP <approximate month> LOI to submit to RFP due <month> <day>, <year> Initial Submissions due and placed on OMG <month> <day>, <year> document server (“Three week rule”) Voter registration closes <month> <day>, <year> Initial Submission presentations <month> <day>, <year> Preliminary evaluation by TF Revised Submissions due and placed on OMG <month> <day>, <year> document server (“Three week rule”) Revised Submission presentations <month> <day>, <year> Final evaluation and selection by TF Recommendation to AB and TC Approval by Architecture Board Review by TC TC votes to recommend specification <approximate month> BoD votes to adopt specification <approximate month> Appendix AReferences and Glossary Specific to this RFP A.1 REFERENCES SPECIFIC TO THIS RFP [AP233] http://step.jpl.nasa.gov/AP233/ ASM TBD [DODAF]http://www.defenselink.mil/nii/doc/ http://www.defenselink.mil/nii/doc/DODAF_v1_Volume_I.pdf http://www.defenselink.mil/nii/doc/DODAF_v1_Volume_II.pdf http://www.defenselink.mil/nii/doc/DODAF_v1_Deskbook.pdf UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 10
    • syseng/05-05-01 [FRI] Friedenthal, S., Kobryn, C. "Extending UML to Support a Systems Modeling Language," Proceedings of the INCOSE 2004 International Symposium, June, 2004 [IDEAS] – the IDEAS Group – www.ideasgroup.org [IEEE 1471] “Recommended Practice for Architectural Description of Software-Intensive Systems,” IEEE, 2000 [IEEE Std 1471 and Beyond] http://members.bellatlantic.net/~rfh2/writings/hilliard01-sei-workshop.pdf [Viewpoint Modeling] http://members.bellatlantic.net/~rfh2/writings/hilliard01b-viewpoint-modeling.pdf [INCOSE] International Council on Systems Engineering http://www.incose.org [ISO/IEC 10746:1998] Information Technology – “Open Distributed Processing -- Reference Model,” ISO, 1998 [ISO/IEC 15926-2:2003] ”Industrial Automation Systems And Integration -- Integration Of Life-Cycle Data For Process Plants Including Oil And Gas Production Facilities -- Part 2: Data model, ISO 2003 [ISO 15704:2000] Industrial Automation Systems – “Requirements for Enterprise-Reference Architectures and Methodologies,” ISO, 2000 [MODAF 2005] MOD Architectural Framework (MODAF), To Be published-July 2005, UK www.modaf.com UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 11
    • syseng/05-05-01 [SE DSIG} Systems Engineering DSIG http://syseng.omg.org/ [SysML -DRAFT] Object Management Group, Systems Modeling Language Draft Specification V0.9 dated January 10, 2005. http://www.omg.org/cgi-bin/doc?ad/05-01-03 A.2 GLOSSARY SPECIFIC TO THIS RFP ADM - Architecture Development Method© (The Open Group) AF - Architecture Framework AGATE AF - Atelier de Gestion de l’ArchiTecturE des SIC AP233 - Application Protocol 233 (part of the STEP - ISO 10303 - standard) CADM - Core Architecture Data Model DARS - DoD Architecture Repository System DoD - Department of Defense DODAF - DoD Architecture Framework DOTMLPF - Doctrine, Organization, Training, Materiel, Leadership & education, Personnel, and Facilities FEAF - Federal Enterprise Architecture Framework IDEF0 - Integrated Definition for Activity Modeling MODAF - Ministry of Defence Architecture Framework, UK NAF - NATO Architecture Framework RM-ODP Reference Model for Open Distributed Processing TEAF - Treasury Enterprise Architecture Framework TOGAF - The Open Group Architectural Framework© UJTL - Universal Joint Task List UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 12
    • syseng/05-05-01 A.3 DEFINITIONS SPECIFIC TO THIS RFP architecture framework - An architecture framework establishes terms and concepts pertaining to the content and use of architectural descriptions. [IEEE 1471] acquirer - An organization that procures a system, software product, or software service from a supplier. (The acquirer could be a buyer, customer, owner, user, or purchaser.) [IEEE 1471] architect - The person, team, or organization responsible for systems architecture. [IEEE 1471] architecting - The activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture. [IEEE 1471] architectural description (AD) - A collection of products to document an architecture. [IEEE 1471] architecture - The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471] life cycle model - A framework containing the processes, activities, and tasks involved in the development, operation, and maintenance of a software product, which spans the life of the system from the definition of its requirements to the termination of its use. [IEEE 1471] system - A collection of components organized to accomplish a specific function or set of functions. [IEEE 1471] system stakeholder - An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. [IEEE 1471] view - A representation of a whole system from the perspective of a related set of concerns. [IEEE 1471] viewpoint - A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. [IEEE 1471] Appendix BGeneral Reference and Glossary B.1 GENERAL REFERENCES The following documents are referenced in this document: [ATC] Air Traffic Control Specification, http://www.omg.org/technology/documents/formal/air_traffic_control.htm UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 13
    • syseng/05-05-01 [BCQ] OMG Board of Directors Business Committee Questionnaire, http://www.omg.org/cgi-bin/doc?bc/02-02-01 [CCM] CORBA Core Components Specification, http://www.omg.org/technology/documents/formal/components.htm [CORBA] Common Object Request Broker Architecture (CORBA/IIOP), http://www.omg.org/technology/documents/formal/corba_iiop.htm [CSIV2] [CORBA] Chapter 26 [CWM] Common Warehouse Metamodel Specification, http://www.omg.org/technology/documents/formal/cwm.htm [DAIS] Data Acquisition from Industrial Systems, http://www.omg.org/technology/documents/formal/dais.htm [EDOC] UML Profile for EDOC Specification, http://www.omg.org/techprocess/meetings/schedule/UML_Profile_for_EDOC_FTF .html [EJB] “Enterprise JavaBeans™”, http://java.sun.com/products/ejb/docs.html [FORMS] “ISO PAS Compatible Submission Template”. http://www.omg.org/cgi- bin/doc?pas/2003-08-02 [GE] Gene Expression, http://www.omg.org/technology/documents/formal/gene_expression.htm [GLS] General Ledger Specification , http://www.omg.org/technology/documents/formal/gen_ledger.htm [Guide] The OMG Hitchhiker's Guide,, http://www.omg.org/cgi-bin/doc?hh [IDL] ISO/IEC 14750 also see [CORBA] Chapter 3. [IDLC++] IDL to C++ Language Mapping, http://www.omg.org/technology/documents/ formal/c++.htm [MDAa] OMG Architecture Board, "Model Driven Architecture - A Technical Perspective”, http://www.omg.org/mda/papers.htm [MDAb] “Developing in OMG's Model Driven Architecture (MDA),” http://www.omg.org/docs/omg/01-12-01.pdf [MDAc] “MDA Guide” (http://www.omg.org/docs/omg/03-06-01.pdf) [MDAd] “MDA "The Architecture of Choice for a Changing World™"”, http://www.omg.org/mda [MOF] Meta Object Facility Specification, http://www.omg.org/technology/documents/formal/mof.htm [MQS] “MQSeries Primer”, http://www.redbooks.ibm.com/redpapers/pdfs/redp0021.pdf [NS] Naming Service, http://www.omg.org/technology/documents/formal/naming_service.htm [OMA] “Object Management Architecture™”, http://www.omg.org/oma/ UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 14
    • syseng/05-05-01 [OTS] Transaction Service, http://www.omg.org/technology/documents/formal/transaction_service.htm [P&P] Policies and Procedures of the OMG Technical Process, http://www.omg.org/cgi- bin/doc?pp [PIDS] Personal Identification Service, http://www.omg.org/technology/documents/formal/person_identification_service.ht m [RAD] Resource Access Decision Facility, http://www.omg.org/technology/documents/formal/resource_access_decision.htm [RFC2119] IETF Best Practices: Key words for use in RFCs to Indicate Requirement Levels, (http://www.ietf.org/rfc/rfc2119.txt). [RM-ODP] ISO/IEC 10746 [SEC] CORBA Security Service, http://www.omg.org/technology/documents/formal/security_service.htm [TOS] Trading Object Service, http://www.omg.org/technology/documents/formal/trading_object_service.htm [UML] Unified Modeling Language Specification, http://www.omg.org/technology/documents/formal/uml.htm [UMLC] UML Profile for CORBA, http://www.omg.org/technology/documents/formal/ profile_corba.htm [XMI] XML Metadata Interchange Specification, http://www.omg.org/technology/documents/formal/xmi.htm [XML/Value] XML Value Type Specification, http://www.omg.org/technology/documents/formal/xmlvalue.htm B.2 GENERAL GLOSSARY Architecture Board (AB) - The OMG plenary that is responsible for ensuring the technical merit and MDA-compliance of RFPs and their submissions. Board of Directors (BoD) - The OMG body that is responsible for adopting technology. Common Object Request Broker Architecture (CORBA) - An OMG distributed computing platform specification that is independent of implementation languages. Common Warehouse Metamodel (CWM) - An OMG specification for data repository integration. CORBA Component Model (CCM) - An OMG specification for an implementation language independent distributed component model. UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 15
    • syseng/05-05-01 Interface Definition Language (IDL) - An OMG and ISO standard language for specifying interfaces and associated data structures. Letter of Intent (LOI) - A letter submitted to the OMG BoD’s Business Committee signed by an officer of an organization signifying its intent to respond to the RFP and confirming the organization’s willingness to comply with OMG’s terms and conditions, and commercial availability requirements. Mapping - Specification of a mechanism for transforming the elements of a model conforming to a particular metamodel into elements of another model that conforms to another (possibly the same) metamodel. Metadata - Data that represents models. For example, a UML model; a CORBA object model expressed in IDL; and a relational database schema expressed using CWM. Metamodel - A model of models. Meta Object Facility (MOF) - An OMG standard, closely related to UML, that enables metadata management and language definition. Model - A formal specification of the function, structure and/or behavior of an application or system. Model Driven Architecture (MDA) - An approach to IT system specification that separates the specification of functionality from the specification of the implementation of that functionality on a specific technology platform. Normative – Provisions that one must conform to in order to claim compliance with the standard. (as opposed to non-normative or informative which is explanatory material that is included in order to assist in understanding the standard and does not contain any provisions that must be conformed to in order to claim compliance). Normative Reference – References that contain provisions that one must conform to in order to claim compliance with the standard that contains said normative reference. Platform - A set of subsystems/technologies that provide a coherent set of functionality through interfaces and specified usage patterns that any subsystem that depends on the platform can use without concern for the details of how the functionality provided by the platform is implemented. Platform Independent Model (PIM) - A model of a subsystem that contains no information specific to the platform, or the technology that is used to realize it. Platform Specific Model (PSM) - A model of a subsystem that includes information about the specific technology that is used in the realization of it on a specific platform, and hence possibly contains elements that are specific to the platform. UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 16
    • syseng/05-05-01 Request for Information (RFI) - A general request to industry, academia, and any other interested parties to submit information about a particular technology area to one of the OMG's Technology Committee subgroups. Request for Proposal (RFP) - A document requesting OMG members to submit proposals to the OMG's Technology Committee. Such proposals must be received by a certain deadline and are evaluated by the issuing task force. Task Force (TF) - The OMG Technology Committee subgroup responsible for issuing a RFP and evaluating submission(s). Technology Committee (TC) - The body responsible for recommending technologies for adoption to the BoD. There are two TCs in OMG – Platform TC (PTC), that focuses on IT and modeling infrastructure related standards; and Domain TC (DTC), that focus on domain specific standards. Unified Modeling Language (UML) - An OMG standard language for specifying the structure and behavior of systems. The standard defines an abstract syntax and a graphical concrete syntax. UML Profile - A standardized set of extensions and constraints that tailors UML to particular use. XML Metadata Interchange (XMI) - An OMG standard that facilitates interchange of models via XML documents. UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 17