Issue 7585: Break the spec into multiple volumes (swradio-ftf) Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com) Nature: Uncategorized Issue Severity: Summary: Break the spec into multiple volumes Proposed solution: UML Profile for SWRadio and Facilities into a separate document of the specification Rationale: Easier to understand, separation of concepts Resolution: Revised Text: Component Framework Volume is as follows: "1 Scope This specification responds to the requirements set by "Request for Proposals for a Platform Independent Model (PIM) and CORBA Platform Specific Model (PSM)" (swradio/02-06-02) of radio infrastructure facilities that can be utilized in developing applications such as waveforms, which promotes the portability of applications across platforms such as Software Defined Radios (SDR). The Component Framework specification is physically partitioned into two major chapters: UML Profile for Component Framework and PSM for CORBA IDL and XML. UML Profile for Component Framework defines a language for modeling application, service, and domain management components by extending the UML language. The profile is specified independently from the underlying middleware technology and is applicable for other domains besides SDR. This specification also provides a mechanism for transforming the elements of the profile model into the platform specific model for CORBA IDL and XML. This mapping definition is given in the PSM (Chapter 8). Finally, the specification provides different compliance points depending on the role the implementer of this specification plays. Those different roles and respective partitioning of this document is given in the Conformance (Chapter 2). 2 Conformance There are two kinds of conformance with respect to the profile: conformance on the part of a model of a specific application, and conformance on the part of a MDA tool. 2.1 Conformance by a Model of a Specific Application A UML model of a specific application either conforms to the profile or it does not. There are no categories of this kind of conformance. Such a UML model conforms to the profile if it satisfies all constraints imposed by the profile package. 2.2 Conformance by a Tool 2.2.1 Definition of Terms for Discussion of Tool Conformance To support the discussion of conformance by a MDA tool, we define two terms: "identified subset of UML 2.0" and "all constructs defined by the profile." The identified subset of UML 2.0 for the profile is the set of packages contained in the UML 2.0 Superstructure specification Part 1 (Structure). Part 1 includes the following packages and the transitive closure of all packages contained by these packages and of all packages upon which these packages depend: ? Classes ? Composite Structures ? Components ? Deployments Hereafter we sometimes use the abbreviated term identified subset to refer to the identified subset of UML 2.0. The term all constructs defined by the profile is defined to mean all constructs that are part of the package's identified subset of UML 2.0, plus all extensions to that subset that the profile defines. Thus this term includes UML constructs that are part of the identified subset but that are not extended by the profile. 2.2.2 Categories of Tool Conformance A tool is considered to be a conformant simple modeling tool for the profile if it does both of the following: ? Supports expression of all constructs defined by the profile, via UML 2.0 notation. ? Supports the UML 2.0 XMI exchange mechanism for the identified subset and for UML 2.0 profiles. A tool is considered to be a conformant CORBA/XML-based forward engineering tool for the profile if it does the following: ? Supports the PIM-to-PSM Mapping defined in Chapter 8. ? Produces applications PSMs that are conformant to the behavior defined in the PIM. Alternately, if a tool only produces an application skeleton, the skeleton must not make it impossible for a full application based on the skeleton to qualify as a conformant application; in other words, the skeleton must be able to form the basis of a conformant application. A forward engineering tool that targets a platform technology other than CORBA/XML can legitimately claim a degree of conformance to the profile and PIM derived from the Profile if it conforms to the PIM-to-PSM Mapping and produces applications PSMs that are conformant applications to the behavior in defined in the PIM, or produces application skeletons that can form the basis of conformant applications. In practice this requires the definition of an alternate PIM-PSM mapping. A forward engineering tool of this nature for the platform "X" is considered to be a conformant X-Based forward engineering tool for the profile. 3 References 3.1 Normative References 3.1.1 UML and Profile Specifications 3.1.1.1 UML Language Specification Unified Modeling Language (UML) Superstructure Specification Version 2.0 Formal OMG Specification, document number: formal/2005-07-04 The Object Management Group, July 2005 [http://www.omg.org] Unified Modeling Language (UML) Infrastructure Specification Version 2.0 Formal OMG Specification, document number: formal/2005-07-05 The Object Management Group, July 2005 [http://www.omg.org] 3.1.1.2 OCL Language Specification Object Constraint Language (OCL) Specification Version 2.0 Final Adopted OMG Specification, document number: ptc/2005-06-06 The Object Management Group, June 2005 [http://www.omg.org] 3.1.1.3 UML Profile for CORBA Specification UML Profile for CORBA Specification V1.0 Formal OMG Specification, document number: formal/2002-04-01 The Object Management Group, April 2002 [http://www.omg.org] 3.1.2 CORBA Core Specifications 3.1.2.1 CORBA Specification Common Object Request Broker (CORBA/IIOP), version 3.0.2 Formal OMG Specification, document number: formal/2002-12-06 The Object Management Group, December 2002 [http://www.omg.org] 3.2 Non-Normative References 3.2.1 Domain XML Profile 3.2.1.1 Domain XML Profile Files Domain XML Profile Files Formal OMG document number:TBD The Object Management Group, TBD 2006 [http://www.omg.org] 4 Terms and Definitions For the purposes of this document, the following terms and definitions apply. Common Object Request Broker Architecture (CORBA) An OMG distributed computing platform specification that is independent of implementation languages. Component A component can always be considered an autonomous unit within a system or subsystem. It can realize interfaces and usually has one or more ports, and its internals are hidden and inaccessible other than as provided by its interfaces. A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component exposes a set of ports that define the component specification in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). Facility An environment providing a realization of certain functionality through set of well defined interfaces. Interface Definition Language (IDL) An OMG and ISO standard language for specifying interfaces and associated data structures. Logical Device A software component that is an abstraction of a hardware device it represents. Mapping The 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 The 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. 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. 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. Service A set of functionality with common characteristics. 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. 5 Symbols (and abbreviated terms) API Application Program Interface BIT Built-In Test CORBA Common Object Request Broker Architecture COTS Commercial Off the Shelf HCI Human-Computer Interface ID Identification, Identifier IDL Interface Definition Language IIOP Internet Inter-ORB Protocol IOR Interoperable Object Reference ISO International Standards Organization N/A Not Applicable OE Operating Environment OMG Object Management Group ORB Object Request Broker OS Operating System OSI Open System Interconnection PIM Platform Independent Model POSIX Portable Operating System Interface PSM Platform Specific Model UML Unified Modeling Language UUID Universally Unique Identifier XML eXtensible Markup Language 6 Additional Information 6.1 Changes to Adopted OMG Specifications The specifications contained in this document require no changes to adopted OMG specifications. 6.2 Guide to this Specification This specification consists of two major parts, contained in the following chapters 7 and 8. ? Chapter 7 defines the modeling language used in this specification in form of a UML profile for a generic component framework. ? Chapter 8 contains a description of the mapping process from the Platform Independent Model (PIM) to a Platform Specific Model (PSM). The normative UML profile referenced in Section 3.1.3.1 is used to generate the class diagrams shown throughout this specification. 6.3 Acknowledgements The following organizations (listed in alphabetical order) contributed to this specification: ? BAE Systems ? BOEING ? Blue Collar Objects ? Carleton University ? Communications Research Center Canada ? École de Technologie Supérieure ? General Dynamics Decision Systems ? Harris ? ITT Aerospace ? ISR Technologies ? L-3 Communications Corporation ? Mercury Computer Systems ? The MITRE Corporation ? Mobile Smarts ? PrismTech ? Raytheon Corporation ? Rockwell Collins ? SCA Technica ? Space Coast Communication Systems ? Spectrum Signal Processing ? THALES ? Virginia Tech University ? Zeligsoft ? 88solutions Section 7 UML Profile for Component Framework This non-normative section defines the UML Profile for Component Framework. This profile is an integral part of the "PIM and PSM for Software Radio Components. The set of stereotypes defined in this profile constitutes the core language for the definition of the SWRadio PIM and PSM. The current UML Profile for Component Framework extends the UML 2.0 meta-language, with emphasis on extensions to the Components package and Deployment package of UML 2.0. The goal of the UML Profile for Component Framework is to enable the development of UML tools to support the development of applications and systems. The objectives are not only to facilitate the modeling of applications and systems, but also to enable the automatic generation of descriptor files (e.g. XML descriptor files) and code (or code skeletons) from UML models. To address the issues of the different actors involved in product developments, the current profile has been developed with two main viewpoints in mind: the viewpoint of application and device developers and the viewpoint of infrastructure/middleware providers. These two viewpoints define distinct sets of concepts (and stereotypes) that are required in different contexts. To be consistent with the two viewpoints introduced above, the UML Profile for Component Framework is partitioned in two main packages: the Applications and Devices package and the Infrastructure package. Each package defines the set of concepts and UML stereotypes required to perform a specific role in the development of a product. The Applications and Devices package defines the set of concepts that are required to develop applications and devices. This package mainly contains a set of stereotypes that extends the UML 2.0 meta-classes Component and Interface. This set of stereotypes includes Resource and Device components." The Infrastructure package defines the concepts that are required to deploy services and applications within a platform infrastructure, and to manage the domain, services, and devices. This package mainly contains a set of stereotypes that extends the UML 2.0 meta-classes Component, Artifact, and Interface. This set of stereotypes includes DomainManager, DeviceManager, ApplicationManager, and ApplicationFactory components." At the start of section 7, add issue 7585 note as follows: "Issue 7585 Breakup spec into multiple volumes, removed SWRadio throughout, replace Core Framework with Component Framework throughout, replace UML Profile for SWRadio" with "UML Profile for Component Framework" throughout spec, replace "SWRadioComponent" with "Component" throughout spec, remove Radio and SWRadio from spec, replace "radio set" and "radio sets" with "platform", replace "RadioProperty" with "Property". Move PIM and PSM for SW Radio Components spec Section 8.1 to Section 7.1 with same name. Move PIM and PSM for SW Radio Components spec Section 8.3 to Section 7.2 except for 8.3.2 Communication Channel, 8.3.3.1.3.1 CommChannel, 8.3.3.1.3.3 RadioManager, and 8.3.3.1.3.4 RadioSystemManager sections. Move PIM and PSM for SW Radio Components spec Section 10 PSM up to and including item 1 and item 4 descriptors of "Other non-CORBA PSM transforms (e.g., XML) are as follows:" to section 8 with same name. After the moves are done make the following changes in spec. Rename 7.2.2 from Radio Management to Platform Management Replace the text in section 7.2.2 Platform Management with the following text "This section defines the stereotypes for platform management. Platform management involves the management of the domain, inclusive of its devices and services. The platform management stereotypes are categorized by domain and device management. The details of these categories are described in the following Domain Management and Device Management subsections." Replace "RadioSet" with "Domain" in text throughout spec. In section 7.1 replace the following text "Device Components - defines stereotypes for the logical device components that represent devices that component are deployed on or use within a SWRadio." with "Device Components - defines stereotypes for the logical device components that represent devices that components are deployed on or use within a platform." In section 7.1.4 Resource Components, replace the following text "Figure 7.4 depicts the base interfaces used in defining software components for applications, logical devices, and communication channels." with "Figure 7.4 depicts the base interfaces used in defining software components for applications and logical devices." In section 7.1.4.1.7 Resource, replace the following text "These interfaces provide basic management interfaces for SWRadio" With "These interfaces provide basic management interfaces for a component." Update Figure 7.3 - ServiceProperty Definition with following figure Figure 7.6 - ResourceComponent M1 Illustration with the following Figure Update Figure 7.8 - SWRadioComponent M1 Illustration with following Figure Update Figure 7.14 - Application M1 Illustration with following Figure Figure 7.15 - ApplicationResourceComponent M1 Illustrationwith following Figure Update Figure 7.33 - ExecutableCode M1 Illustration with following Figure Figure 7.21 - CapabilityModels Definition with following Figure Figure 7.22 - ManagedServiceComponent M1 Illustration with following Figure Figure 7.28 - DomainManagerComponent M1 Illustration with following Figure Figure 7.30 - DeviceManager M1 Illustration with following Figure Update Figure 7.42 with the following figure Add "Issue 7585 note - Break up spec into multiple volumes, renamed SWRadio Artifact to Artifact before section 7.2.3 Deployment" Add "issue note 7585 Breakup Spec into Multiple Volumes, replaced SWRadio with platform before section 7.2.3.2 Applications Deployment In section 7.2.3.2 Applications Deployment, replace the following text "This section defines the interfaces (7.2.3.2.1) and components (7.2.3.2.3) that perform the deployment behavior within a SWRadio." With ""This section defines the interfaces (7.2.3.2.1) and components (7.2.3.2.3) that perform the deployment behavior within a platform." In section 7.2.3.2.1 Applications Deployment Interfaces, replace the following text "This section defines the interfaces that perform the deployment behavior within a SWRadio." With "This section defines the interfaces that perform the deployment behavior within a platform." In section 7.2.3.2.3 Application Deployment Stereotypes, replace the following text "This section defines the components that perform the deployment behavior within a SWRadio. The SWRadio stereotype are depicted in the Table 7.11, which are extensions of the UML Component." With "This section defines the components that perform the deployment behavior within a platform. The component stereotypes are depicted in the Table 7.11, which are extensions of the UML Component." In section 8 Platform Specific Model (PSM) at the end of item 2, replace the following text "devices within the swradio. The interfaces used vary by the type of developers (waveform, device, radio management) for a swradio radio. These developers use different set of interfaces for the components they are developing." with "devices within the platform. The interfaces used vary by the type of developers (waveform, device, domain management) for a platform. These developers use different set of interfaces for the components they are developing." In section 8, Table 8.1 - Core Framework CORBA Module Overview, replace "RadioSet with Domain" and "Radio Management" with "Domain Management" Replace "Core Framework" with "Component Framework" throughout spec. Replace "RadioProperty" with "Property" throughout spec. Replace "UML Profile for SWRadio" with "UML Profile for Component Framework" throughout spec. Remove "Radio" throughout the spec after section 7 after changes are done. Replace "radio set", "RadioSet", RadioSystem" or radio sets" with "platform in section 7 and 8. Replace "SWRadioComponent" with "Component" throughout spec. Remove "SWRadio" throughout the spec after section 7 after changes are done. Remove "SWRAPI" from spec removed SWRAPI interface stereotype from section 7.1.3 Interface and Port Stereotypes Removed SWRADIORealization and SWRadioUsage association sterotypes from section 7.1.4.2 Resource Components Stereotypes. Communication Channel and Equipment Volume Contents is as follows: "1 Scope This specification responds to the requirements set by "Request for Proposals for a Platform Independent Model (PIM) and CORBA Platform Specific Model (PSM)" (swradio/02-06-02) of communication channel creation and interfaces for radio management interfaces that can be utilized in deployment of applications such as waveforms and the modeling of a radio set or radio system. The specification is physically partitioned into three major chapters: UML Profile for Communication Channel, Radio Control Facilities PIM, and PSM for CORBA IDL and XML. UML Profile for Communication Channel defines a language for modeling communication channels, communication equipment and radio management components by extending the UML language. The profile is specified independently from the underlying middleware technology and is applicable for other domains besides SDR. This specification also provides a mechanism for transforming the elements of the profile model into the platform specific model for CORBA IDL and XML. This mapping definition is given in the PSM (Chapter 9). Finally, the specification provides different compliance points depending on the role the implementer of this specification plays. Those different roles and respective partitioning of this document is given in the Conformance (Chapter 2). 2Conformance There are two kinds of conformance with respect to the communication channel profile: conformance on the part of a model of a specific communication channel and channel manager, and conformance on the part of a MDA tool. 2.1 Conformance by a Model of a Specific Application A UML model of a specific communication channel and channel manager either conforms to the communication channel profile or it does not. There are no categories of this kind of conformance. Such a UML model conforms to the communication channel profile if it satisfies all constraints imposed by the profile package. 2.2 Conformance by a Tool 2.2.1 Definition of Terms for Discussion of Tool Conformance To support the discussion of conformance by a MDA tool, we define two terms: "identified subset of UML 2.0" and "all constructs defined by the profile." The identified subset of UML 2.0 for the profile is the set of packages contained in the UML 2.0 Superstructure specification Part 1 (Structure). Part 1 includes the following packages and the transitive closure of all packages contained by these packages and of all packages upon which these packages depend: o Classes o Composite Structures o Components o Deployments 2 Communication Channel and Equipment Specification Hereafter we sometimes use the abbreviated term identified subset to refer to the identified subset of UML 2.0. The term all constructs defined by the profile is defined to mean all constructs that are part of the package's identified subset of UML 2.0, plus all extensions to that subset that the profile defines. Thus this term includes UML constructs that are part of the identified subset but that are not extended by the profile. 2.2.2 Categories of Tool Conformance A tool is considered to be a conformant simple modeling tool for the communication channel profile if it does both of thefollowing: o Supports expression of all constructs defined by the profile, via UML 2.0 notation. o Supports the UML 2.0 XMI exchange mechanism for the identified subset and for UML 2.0 profiles. A tool is considered to be a conformant CORBA/XML-based forward engineering tool for the profile if it does the following: o Supports the PIM-to-PSM Mapping defined in Chapter 9. o Produces comm channel manager components PSMs that are conformant to the behavior defined in the PIM. Alternately, if a tool only produces a component skeleton, the skeleton must not make it impossible for a full component based on the skeleton to qualify as a conformant component - in other words, the skeleton must be able to form the basis of a conformant component. A forward engineering tool that targets a platform technology other than CORBA/XML can legitimately claim a degree of conformance to the communication channel profile and PIM derived from the Profile if it conforms to the PIM-to-PSM Mapping and produces components PSMs that are conformant components to the behavior in defined in the PIM, or produces component skeletons that can form the basis of conformant components. In practice this requires the definitionof an alternate PIM-PSM mapping. A forward engineering tool of this nature for the platform "X" is considered to be a conformant X-Based forward engineering tool for the profile. 3 References 3.1 Normative References 3.1.1 UML and Profile Specifications 3.1.1.1 UML Language Specification Unified Modeling Language (UML) Superstructure Specification Version 2.0 Formal OMG Specification, document number: formal/2005-07-04 The Object Management Group, July 2005 [http://www.omg.org] Unified Modeling Language (UML) Infrastructure Specification Version 2.0 Formal OMG Specification, document number: formal/2005-07-05 The Object Management Group, July 2005 [http://www.omg.org] 3.1.1.2 OCL Language Specification Object Constraint Language (OCL) Specification Version 2.0 Final Adopted OMG Specification, document number: ptc/2005-06-06 The Object Management Group, June 2005 [http://www.omg.org] 3.1.1.3 UML Profile for CORBA Specification UML Profile for CORBA Specification V1.0 Formal OMG Specification, document number: formal/2002-04-01 The Object Management Group, April 2002 [http://www.omg.org] 3.1.1.4 UML Profile for Component Framework Specification UML Profile for Component Framework Specification V1.0 Formal OMG Specification, document number: TBD The Object Management Group, TBD 2006 [http://www.omg.org] 3.1.2 CORBA Core Specifications 3.1.2.1 CORBA Specification Common Object Request Broker (CORBA/IIOP), version 3.0.2 Formal OMG Specification, document number: formal/2002-12-06 The Object Management Group, December 2002 [http://www.omg.org] 3.2 Non-Normative References 4 Terms and Definitions For the purposes of this document, the following terms and definitions apply. Common Object Request Broker Architecture (CORBA) An OMG distributed computing platform specification that is independent of implementation languages. Component A component can always be considered an autonomous unit within a system or subsystem. It has one or more ports, and its internals are hidden and inaccessible other than as provided by its interfaces. A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component exposes a set of ports that define the component specification in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). Facility An environment providing a realization of certain functionality through set of well defined interfaces. Interface Definition Language (IDL) An OMG and ISO standard language for specifying interfaces and associated data structures. 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. 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. Radio Platform The Radio Platform is made of a Hardware Platform and a Software Platform. Radio Set A single radio set unit that can be ground fixed, mounted on a mobile platform or held by hand. Radio System A networked set of radio sets that provide wireless communication facilities between callers and callees. 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. 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. 5 Symbols (and abbreviated terms) CORBA Common Object Request Broker Architecture DSP Digital Signal Processor FPGA Field Programmable Gate Array GPP General Purpose Processor I/O Input/Output IDL Interface Definition Language IIOP Internet Inter-ORB Protocol ISO International Standards Organization N/A Not Applicable OMG Object Management Group ORB Object Request Broker OS Operating System PIM Platform Independent Model PSM Platform Specific Model RF Radio Frequency SDR Software Defined Radio UML Unified Modeling Language XML eXtensible Markup Language 6 Additional Information 6.1 Changes to Adopted OMG Specifications The specifications contained in this document require no changes to adopted OMG specifications. 6.2 Guide to this Specification This specification consists of three major parts, contained in the following chapters 7 to 9. o Chapter 7 defines the modeling language used in this specification in form of a UML profile for Communication Channel, Communication Equipment and Radio Management components. The normative UML Profile specified in model referenced in Section 3.1.3 is used to generate the class diagrams shown throughout this specification. o Chapter 8 contains the Radio Control Facilities Platform Independent Model (PIM). The UML language extended by 6.3 Acknowledgements the communication channel profile defined in Chapter 7 is used to specify this PIM. o Chapter 8 contains a description of the mapping process from the Platform Independent Model (PIM) to a Platform Specific Model (PSM). 6.3 Acknowledgements The following organizations (listed in alphabetical order) contributed to this specification: ? BAE Systems ? BOEING ? Blue Collar Objects ? Carleton University ? Communications Research Center Canada ? École de Technologie Supérieure ? General Dynamics Decision Systems ? Harris ? ITT Aerospace ? ISR Technologies ? L-3 Communications Corporati Actions taken: July 13, 2004: received issue August 2, 2005: closed issue Discussion: Discussion: The group (Jerry, Neli, Tansu) that the resolution for this issue (breaking up the spec into multiple volumes) does belong to this FTF. The group agreed to 3 volumes: PIM (UML Profile), Radio Facilities, and PSM The group also agreed to wait until after the resolution to issue 7742 to take care of this break up. Based on resolution for 8251 and 8259, we'll decide how to break up the spec. Disposition: Deferred The issue is deferred to the follow-on R/FTF, since FTF #2 ran out of time. End of Annotations:===== ubject: PIM and PSM Software Radio Components Issues To: issues@omg.org Cc: swradio-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Wed, 14 Jul 2004 07:12:57 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.13a |April 8, 2004) at 07/14/2004 07:13:00 AM X-SPAM: 0.00 PIM and PSM Software Radio Components Issues are: Issue 8: Break the spec into multiple volumes Proposed solution: UML Profile for SWRadio and Facilities into a separate document of the specification Rationale: Easier to understand, separation of concepts