Issue 6026: Terms and Definitions chapter is empty (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: Reformatting the submission to match the ISO format created an empty "Terms and Definitions" chapter. We must fill it with some content. >From the template: "For the purposes of this specification, the following terms and definitions apply /the terms and definitions given in [list of other documents] and the following apply. The Terms and definitions clause is an optional element giving definitions necessary for the understanding of certain terms used in the specification. The term and definition list is introduced by a standard wording (above), which shall be modified as appropriate." This chapter should probably define concepts like Component, Component Package, Assembly, Repository, Domain, ... Resolution: Revised Text: Actions taken: July 28, 2003: received issue Discussion: End of Annotations:===== ubject: Terms and Definitions chapter is empty Date: Mon, 28 Jul 2003 16:40:58 -0400 Thread-Topic: Terms and Definitions chapter is empty Thread-Index: AcNVSIy0qFhhreMYSGG1MuSSAsnYGA== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h6SKbYkM031102 This is a new issue for the Deployment FTF. Reformatting the submission to match the ISO format created an empty "Terms and Definitions" chapter. We must fill it with some content. >From the template: "For the purposes of this specification, the following terms and definitions apply /the terms and definitions given in [list of other documents] and the following apply. The Terms and definitions clause is an optional element giving definitions necessary for the understanding of certain terms used in the specification. The term and definition list is introduced by a standard wording (above), which shall be modified as appropriate." This chapter should probably define concepts like Component, Component Package, Assembly, Repository, Domain, ...  Subject: Proposed resolution for issue 6026: terms and definitions chapter is empty Date: Thu, 4 Dec 2003 10:07:42 -0500 Thread-Topic: Proposed resolution for issue 6026: terms and definitions chapter is empty Thread-Index: AcO6eF2BCDAkr3ncSB2JMbK6gWD25g== From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id hB4F60NA026006 Proposed resolution: In section 5, "Terms and Definitions", replace the text "[To Do]" with the following: 5.1 Bridge Provides a communication path between interconnects, and thus an indirect communication path between nodes. 5.2 Capability A feature offered by a component implementation. 5.3 Component Assembly Implements a specific component interface using a set of interconnected components and a mapping of the implemented component interface's features to these subcomponents. 5.4 Component Implementation Either a Monolithic Implementation or a Component Assembly. 5.5 Component Package A set of alternative component implementations (of the same component interface) and their metadata. 5.6 Deployment A mapping of a configured application into a domain. Includes mapping monolithic implementations to nodes, connections to interconnects and bridges, and requirements to resources. 5.7 Domain A set of nodes, interconnects, bridges and resources. 5.8 Interconnect Provides a shared communication path between two or more nodes. 5.9 Implementation Artifact An artifact that constitutes a partial or complete monolithic implementation (usually "executable code"). 5.10 Monolithic Implementation An indivisible implementation of a specific component interface using one or more deployable implementation artifacts. 5.11 Node A target of execution, capable of hosting monolithic implementations. 5.12 Requirement A feature requested by component implementations. Monolithic implementation requirements must be satisfied by node resources. Assembly subcomponent requirements must be satisfied by component implementation capabilities. Assembly connection requirements must be satisfied by interconnect and bridge resources. 5.13 Resource A feature offered by a node, interconnect or bridge. 5.14 Shared Resource A feature that is shared between two or more nodes. Either node can host monolithic implementations with a requirement that is satisfied by a Subject: Proposed resolution for issue 6026 Date: Fri, 6 Feb 2004 11:10:47 -0500 X-MS-Has-Attach: yes Thread-Topic: Proposed resolution for issue 6026 Thread-Index: AcPsy8cCUa+X1HfeRMSZfs76a8YIWg== From: "Pilhofer, Frank" To: We revisited this issue, the empty Terms and Definitions chapter, in Anaheim. The term for "Configuration" was still in doubt, but we didn't come up with better wording. So, on David's suggestion, we decided not to delay this proposal because of a single term. Thus we decided to endorse the proposed resolution as is, with the possibility of filing issues about individual terms in the future, if necessary. Attached is the latest text for the Terms and Definitions, with changes tracked against the prior revision (from Jan 21). The only changes are the updated numbering and the completion of an incomplete sentence in the definition of "Deployment Plan". Terms_Definitons Feb 4.doc 5.1X Artifact [UML2S] A physical piece of information that is used or produced by a deployment process. Examples of Artifacts include models, source files, scripts, and binary executable files. An artifact may constitute the implementation of a deployable component. 5.21 Bridge A resource that provides connectivity between interconnects, supplying an indirect communication path between nodes. 5.32 Capability A feature offered by a component implementation. 5.4X Component [UML2S] A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior 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). 5.53 Component Assembly An implementation of a specific component interface using a set of interconnected components and a mapping of the implemented component interface's features to these subcomponents. 5.64 Component Implementation An abstract class that contains the attributes and associations that are common to both a Monolithic Implementation and a Component Assembly. 5.7X Component Interface A named set of provided and required interfaces that characterize the behavior of a component. 5.85 Component Package A set of alternative implementations of a component interface contained in a set of artifacts and compiled code modules. (Has a set of component implementations, and each of these implementations is equally valid.) 5.9X Configuration A set of default run-time application options used to customize non-deployment related application features. (see section 1.3.3 for further information) 5.106 Deployment Plan A mapping of a configured application into a domain, this includes mapping monolithic implementations to nodes, connections to interconnects and bridges, and requirements to resources. Output of Planning, input to Preparation. 5.117 Domain A target environment composed of independent nodes, interconnects, bridges and resources. 5.12X Installation The act of taking a published software package and bringing it into a repository. See section 1.3.2 for further information. 5.138 Interconnect A target used for the deployment of connections between components. 5.14X Interface [UML2S] A named set of operations that characterize the behavior of an element. 5.159 Implementation Artifact A artifact used or produced as a result of an implementation. These are commonly constituted as partial component implementations or monolithic implementations (usually "executable code"). 5.16X Launch The process of instantiating components on nodes in the target environment according to a deployment plan. Launching includes interconnecting and configuring component instances, as well as starting execution. See section 1.3.6 for further details. 5.17X Metadata Information that characterizes data, Metadata are used to provide documentation for data products. In essence, metadata answer who, what, when, where, why, and how about every facet of the data that are being documented. 5.1810 Monolithic Implementation An indivisible implementation of a specific component interface using one or more deployable implementation artifacts. 5.191 Node [UML2S] A run-time computational resource which generally has at least memory and often processing capability. Run-time implementation objects and components may reside on nodes. 5.20X Planning The process of taking the requirements of the component package to be deployed and the resources of the target environment (where the software will be executed), and deciding which implementation and how and where the software will be run in that environment. See section 1.3.4 for further information. 5.21X Preparation The process of performing work in the target environment to be ready to launch the software, such as moving binary files to the specific nodes in the target environment on which the software will execute. See section 1.3.5 for further information. 5.X22 Repository A facility for storing metadata, and implementations. 5.123 Requirement A feature requested by component implementations. Monolithic implementation requirements must be satisfied by node resources. Assembly subcomponent requirements must be satisfied by component implementation capabilities. Assembly connection requirements must be satisfied by interconnect and bridge resources. 5.2413 Resource A feature offered by a node, interconnect or bridge. 5.2514 Shared Resource A feature shared between two or more nodes. Either node can host monolithic implementations with a requirement that is satisfied by a shared resource. shared resource.