ISO/IEC JTC1/SC7 /N3209

Transcription

1 ISO/IEC JTC1/SC7 Software and Systems Engineering Secretariat: CANADA (SCC) ISO/IEC JTC1/SC7 /N Document Type Title Liaison Documents Liaison statements from ITU-T SG 17 Source ITU-T SG 17 Project Status Final Reference Action ID FYI or ACT Due Date Distribution AG No. of Pages 11 Note Address reply to: ISO/IEC JTC1/SC7 Secretariat École de technologie supérieure Département de génie électrique 1100 Notre Dame Ouest, Montréal, Québec Canada H3C 1K3

2 INTERNATIONAL TELECOMMUNICATION UNION TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD COM 17 LS 33 E English only Original: English Question(s): 15/17 Moscow, 30 March 8 April 2005 Ref: TD 3030 Source: ITU-T SG 17 (Moscow, 30 March - 8 April 2005) Title: Technical Corrigendum 1 to ITU-T Rec. X.952 ISO/IEC LIAISON STATEMENT To: ISO/IEC JTC 1/SC 7 Approval: Agreed to at Study Group 17 meeting For: Action Deadline: 30 May 2005 Contact: Arve Meisingset Rapporteur Q.15/17 Tel: arve.meisingset@telenor.com Q.15/17 has jointly with Q.10/17 reviewed the comments received on the ISO/IEC ballot on Technical Corrigendum 1 to ITU-T Rec. X.952 ISO/IEC , contained in TD 0059 of the Study Group 17 Moscow meeting, 30 March 8 April All comments were accepted The changes made to the Technical Corrigendum are identical to the changes requested in all the ballot comments, that is, the addition of an odp arc and the change of 25 to 26 everywhere. In addition, SG 17 took the opportunity to correct misunderstandings in the initial introduction text on the process for allocating arcs. The process is that arcs beneath the joint-iso-itu-t arc cannot be freely allocated by anybody - their allocation requires a Resolution by both ITU-T SG 17 and JTC 1/SC 6. At this meeting, SG 17 has Resolved to allocate the arc "odp(26)" for odp work (enabling it to allocate an arc for "trader" as required by Technical Corrigendum 1 to ITU-T Rec. X.952 ISO/IEC ) and has issued a liaison to SC 6 to make the corresponding Resolution. The revised Technical Corrigendum 1 to Rec. X.952 ISO/IEC is attached. SG 17 Consented the text and processing for ITU-T Last Call is being held pending confirmation from SC 7 that the text is acceptable as a resolution of the ballot comments. Attachment: Revised Technical Corrigendum 1 to ITU-T Rec. X.952 ISO/IEC (TD 3029) Attention: Some or all of the material attached to this liaison statement may be subject to ITU copyright. In such a case this will be indicated in the individual document. Such a copyright does not prevent the use of the material for its intended purpose, but it prevents the reproduction of all or part of it in a publication without the authorization of ITU.

3 - 2 - COM 17 LS 33 E INTERNATIONAL TELECOMMUNICATION UNION STUDY GROUP 17 TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD TD 3029 English only Original: English Question(s): 15/17 Moscow, 30 March - 8 April 2005 TEMPORARY DOCUMENT Source: Rapporteur Title: Technical Corrigendum 1 to ITU-T Rec. X.952 ISO/IEC ITU-T\COM-T\COM17\LS\33E.DOC

4 - 3 - COM 17 LS 33 E INTERNATIONAL STANDARD ITU-T RECOMMENDATION 1 Introduction ITU-T Rec. X.952 ISO/IEC incorrectly specifies the arc trader(100) under the object identifier {joint-iso-itu-t(2)} in the international registration tree (see ITU-T Rec. X.660 ISO/IEC ). The last number assigned by the Registration Authority (ITU-T SG 17 and ISO/IEC JTC 1/SC 6 acting jointly) under joint-iso-itu-t(2) is 25, so use of the number 100 for ITU-T Rec. X.952 ISO/IEC is incorrect, but in any case it was not allocated by the Registration Authority. The Registration Authority has now assigned arc odp(26) for ITU-T ODP Recommendations in the X.900 series and equivalent ISO/IEC International Standards. The Registration Authority for the odp(26) arc will be maintained jointly by the Editors of these Recommendations International Standards, who will ensure that any allocations made under it (for example, arc "trader(0)" for use in ITU-T Rec. X.952 ISO/IEC ) will be entered into the OID repository. In addition, an OID was incorrectly specified in the ASN.1 modules defined in Annexes A & B of ITU-T Rec. X.952 ISO/IEC The OID {joint-iso-itu-t 2} cannot be used by trader, as it was assigned to ACSE. To correct these errors, ITU-T Rec. X.952 ISO/IEC is modified as detailed below. 2 Changes 2.1 Annex A In the header of the ASN.1 module named TraderDefinitions, replace: TraderDefinitions {joint-iso-itu-t 2} with: TraderDefinitions {joint-iso-itu-t odp(26) trader(0) asn1modules(2) traderdefinitions(0)} In the body of the ASN.1 module named TraderDefinitions, replace: id-trader OBJECT IDENTIFIER ::= {joint-iso-itu-t trader(100)} with: id-trader OBJECT IDENTIFIER ::= {joint-iso-itu-t odp(26) trader(0)} 2.2 Annex B In the header of the ASN.1 module named PrinterServiceOfferDefinitions, replace: PrinterServiceOfferDefinitions {joint-iso-itu-t 2} with: Information Technology Open Distributed Processing Trading Function: Provision Of Trading Function Using OSI Directory Service Technical Corrigendum 1 PrinterServiceOfferDefinitions {joint-iso-itu-t odp(26) trader(0) asn1modules(2) printerserviceofferdefinitions (1)} ITU-T\COM-T\COM17\LS\33E.DOC

5 - 4 - COM 17 LS 33 E In the IMPORTS statement of module PrinterServiceOfferDefinitions, replace: id-trader-at, id-trader-oc-serviceoffer FROM id-trader{joint-iso-itu-t trader(100)}; with: id-trader-at, id-trader-oc-serviceoffer FROM TraderDefinitions {joint-iso-itu-t odp(26) trader(0) asn1modules(2) traderdefinitions(0)}; ITU-T\COM-T\COM17\LS\33E.DOC

6 INTERNATIONAL TELECOMMUNICATION UNION TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD COM 17 LS 36 E English only Original: English Question(s): 15/17 Moscow, 30 March - 8 April 2005 Ref: TD 3031 Rev.1 Source: ITU-T SG 17 (Moscow, 30 March - 8 April 2005) Title: Comments on ITU-T Rec. X.906 ISO/IEC 19793, Use of UML for ODP system specifications LIAISON STATEMENT To: ISO/IEC JTC1/SC 7/WG 19 Approval: Agreed to at Study Group 17 meeting For: Action Deadline: 1 August 2005 Contacts: Arve Meisingset Rapporteur Q.15/17 Thomas Weigert Rapporteur Q.13/17 Tel: arve.meisingset@telenor.com Tel: Fax: thomas.weigert@motorola.com Q.15/17 has together with Q.13/17 reviewed the text of draft Rec. X.906 and offers the following comments: Study Group 17 applauds the efforts to further clarify the concepts of the RM-ODP. In particular, we found the explication of the concepts by clearly specifying their relationship in the form of class diagrams, for example, in Sections 7.1.6, , , and very helpful in aiding the understanding of these concepts. We understand that this document further aims at clarifying the concepts of RM-ODP by translating each RM-ODP concept into a stereotyped UML model element or set of such model elements. However, we believe that the document did not succeed in this, for four main reasons: This translation seems rather incomplete. A detailed examination of many of the RM-ODP concepts so mapped reveals that it is impossible to understand the meaning of the RM-ODP concept in terms of the stereotyped UML model element (or set of model elements). The translation relies on an outdated version of UML. The UML community has long recognized that there are severe shortcomings in that version of UML and a new version, UML 2.0, has since been adopted. UML 2.0 not only resolves many of the defects in the original UML specification, but it also introduces many new concepts that are highly relevant in the explication of RM-ODP concepts. Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of ITU-T.

7 - 2 - COM 17 LS 36 - E This document attempts to use profiles to define this mapping. While a profile is an appropriate technique, the way this is done in the document does not follow the typical way of defining a profile. The document is further hampered in that the profile mechanism supported in the UML version utilized was rather poor. UML 2.0 offers much enhanced facilities for such definitions. The document relies in the development of these mapping centrally on the UML profile for EDOC. Unfortunately, this profile is not really a profile, and it is technically rather poor and filled with errors. It is unadvisable to base this document on such inadequate foundations. Again, UML 2.0 would have provided many of the concepts that the EDOC profile is intended to introduce. We believe it is critical for the understanding of the document and its successful use by developers that the reasons cited above are addressed. The document should be rewritten based on the UML 2.0 specification, using the UML 2.0 profiling mechanism, and avoid utilizing the EDOC or other UML 1.0 profiles. In addition, the mapping should be done completely, so that each RM-ODP concept can be fully understood by examining the stereotyped UML model element (or set of model elements) the RM-ODP concept maps to. In order to get a better understanding of the issues involved, we think that a joint meeting would be beneficial. Study Group 17 therefore offers to host a joint meeting of ISO/IEC JTC 1/SC 7/WG 19 and ITU-T SG 17 Q.15/17 during the SG 17 meeting in Geneva October The dates October may be convenient for the joint meeting. SG 17, in particular Q.13/17, has been active in developing UML profiles and has developed the first standardized UML profile (Z.109). SG 17 offers to share this experience with ISO/IEC JTC 1/SC 7/WG 19. The remainder of this liaison statement offers more detailed and specific comments on the document. However, the comments above should be considered as the most pressing.

8 - 3 - COM 17 LS 36 - E ISO/IEC JTC 1/SC 7/WG 19 Title: ITU-T SG 17 comments on CD Use of UML for ODP system specifications Source: ITU-T Study Group 17 Status: Approved by ITU-T Study Group 17 for submission to SC 7/WG 19 at SC 7 meeting, Helsinki, May 2005 Date: April 8, 2005 ITU-T Study Group 17 offers the following comments on the CD of ISO/IEC This document is formatted in accordance with the SC 7 conventions for Ballot Comment (as amended by the Working Group) and uses the following categorisation of comments. Category Description Impact G General Applicable generally i.e. in multiple places throughout E Editorial Cosmetic including typographical and grammatical TL TH Technical Low (Minor) Technical High (Major) Rejection of the comment would not prevent changing a negative vote to a positive one. Considered to be an immovable position i.e. a negative vote would remain unless this was satisfactorily addressed

9 ITU1 Cat TH Page 4, Figure COM 17 LS 36 - E We find this figure to be confusing, as it does not clearly identify at which level (meta schema, schema or population) the statements are made, does not clearly identify which relationships are addressed according to Ogden s triangle (between terms, concepts and things) and also introduces notions which are not needed in this context, such as UML models. The key difficulty with Section 6.2 is the unclarity surrounding the bidirectional arrow indicating the mapping between an ODP specification and a UML model. Clearly this mapping cannot be bidirectional (and it is not bidirectional in the subsequent document). But it is rather unclear what the direction of the arrow should really be. Two interpretations are possible: The meaning of ODP concepts is given by mapping them into a UML model, or The meaning of a UML model is given by mapping it into a set of ODP concepts. The former would aim at enabling users to create ODP specifications, but to understand the meaning of those specifications (in other words, what entities in the Universe of Discourse this specification describes) it would rely on the familiar concepts of the UML. The latter would aim at enabling users to create UML specifications, but to understand the meaning of those specifications it would rely on the familiar concepts of the RM-ODP. The purpose of this document should be made very clear. Replace Figure 1 with the following: UML notation Profile ODP concepts Design Specification according to ODP Use Describe Universe of Discourse (UOD) Instance population according to ODP Describe Actual World Figure 1 The roles of ODP notions and specifications If our interpretation of draft X.906 as provided in Figure 1 is correct, we also propose to rewrite the text of section 6.2, but we will defer this issue until agreements on the figure are reached. The essential message is that the definition of the ODP concepts (in this draft standard) contains a definition of all generic ODP concepts and their associations (using free text), and the definition of a mapping (using free text) to UML notions that further constrains the behaviour of the generic ODP notions. All four parts relate to the ODP concepts box and the Profile mapping in Figure 1. These parts define all generic ODP concepts.

10 - 5 - COM 17 LS 36 - E Note that we have provided one-way mappings in Figure 1 complying to the given role labels. This may be extended to two-way associations. Also, the labels may be revised. Note that Specification according to ODP is here used to denote specifications using the ODP concepts. Annex B shows two examples of Specifications according to ODP. See this box in the Figure. Note that we have not introduced a distinction between concepts and terms in the above Figure, as we think this is not needed and would add to the complexity of the message. We have, however, shown the mapping to the UoD, as this may help to clarify notions on modelling when being relevant. Introduction of terms would have resulted in a similar column as under ODP concepts, with denotation mappings from the added boxes to the current concept boxes, and similar mappings from the added boxes to the UoD boxes. ITU2 Cat TH Figure 4 We think that the mapping of information viewpoint via the computational, engineering and technical viewpoints is unsatisfactory in many cases, and that a more elaborate data architecture is needed, e.g. comprising layout (on screens), contents (of screens), external terminology (at user interfaces), concepts/information viewpoint, internal terminologies (in databases and at interfaces), distribution message contents, and internal physical formats and encodings. Since you may map directly from the Enterprise Viewpoint to the Computational Viewpoint, is then the Information Viewpoint not required in all cases, while all other viewpoints are required to provide an implementable design? We do not have a proposal, as this would have exceeded the scope of RM-ODP. ITU3 Cat E scope (of a system) The behaviour that system is expected to exhibit. An article a (or the ) is missing in front of system. Replace by: The behaviour that a system is expected to exhibit.

11 - 6 - COM 17 LS 36 - E ITU4 Cat E 7.2 para 2 An a in in way. Write: in a way. ITU5 Cat E 7.4 by design the community includes the object; A comma is missing after design. Write: by design, the community includes the object; ITU6 Cat E bullet 2 that that spe cify information or information processing of an enterprise object fulfilling that role; There is a that too much and a blank too much. Write: that specify information or information processing of an enterprise object fulfilling that role; ITU7 Cat G Schemata The Enterprise Viewpoint contains neither Schema nor Template notions, however, Policy may be considered being a template. We understand that the Enterprise Viewpoint may cover several systems and their environments, but would it not be beneficial to have schemata at every viewpoint and mappings between these? Why is not the Schema notion provided for the Computational Viewpoint, etc? Would it not be beneficial to provide a more unified terminology across all viewpoints? No viewpoint seems to define the scope of a Schema; should there be one Schema per Module, per Screen, per System, per Partition/database or other? Is there not a need for more clarity on the scope/extension, role and purpose of the schemata? We have no proposal, as we think more discussions are needed before a proposal can be made, ie. both on schemata and templates.

12 - 7 - COM 17 LS 36 - E ITU8 Cat TH Correspondences We think that the notions of consistency, completeness and relevance are not sufficiently well introduced. Does required correspondences mean those mappings that must be provided in order to get a running application? If so, what is the purpose of the remaining correspondences? Is there any notion of completeness and relevance of the mappings? For example, given a Computational Viewpoint specification, what is required of a corresponding Engineering Viewpoint specification etc? ITU9 Cat E Frames Many Figures have an extra frame line around them. Remove the Frames. ITU10 Cat E Figures The styles of the various meta-model graphs are different, eg. dependent on the tools used. We propose that the styles be aligned. ITU11 Cat TH MDA As indicated in the notes of Draft X.906, we think that presentation of and mapping to MDA should go into an Annex. This Annex may be referenced in the Introduction. Move the sections on MDA to an Annex.