Issue 15129: Provide detailed information about dependencies between KDM packages (kdm-rtf) Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com) Nature: Uncategorized Issue Severity: Critical Summary: Description: As per issue JP7 raised by the Japan delegation to ISO during the KDM review, it was stated that “Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.)”. The suggested resolution was to Describe it using Package diagram. KDM 1.1 RTF decided not to replace the existing architectural illustration of the layers (as per issue resolution 13828) with the UML package diagram in order not to complicate the introductory part of the specification and not to complicate the maintenance of the formal machine readable documents of the specification. Also, the UML package diagram was not considered to be detailed enough. However, useful detailed relations between packages can be added as a non-normative appendix to the specification. Resolution: Revised Text: Actions taken: March 24, 2010: received issue Discussion: It is not clear whether the issue is with the general approach within KDM to representing packages in existing systems, or about Figure 8.1 in the KDM specification, showing packages on KDM itself. Additional discussion on November 30: Clarification request: The issue is about the modelling elements of the KDM that allow representation of the packages within some existing system, as well as relationships between these packages, so that the corresponding KDM view can be described using a UML package diagram. Please let me know if this interpretation of the issue is correct. Assuming that this interpretation is correct, existing KDM specification already has several relevant mechanisms. KDM has Package meta-model element (section 12.5.6, part of the Code package and the corresponding Code viewpoint). This element represents packages in existing software systems, as well as similar module constructs. The Package element is the endpoint of several KDM relationships. First, a Package may "contain" other KDM elements. Second, some element may "import" a Package using the Imports relationship, or be "Visible in" a Package using the "VisibleIn" relationship. However, most importantly, KDM defines the mechanism of "aggregated relationships" by which relationships between Packages can be derived from the individual relationships between the contained elements of these Packages. KDM specification does not define any diagrams, however the KDM Code views involving Packages can be mapped to a UML Package diagram. So, provided my interpretation of the issue is correct, KDM already has the necessary modelling elements to describe relationships between packages of existing software systems. In fact, several KDM compliant tools already produce package diagrams of existing software based systems. Response from the originator of the comment: I checked KDM spec. again. “Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.)”. The suggested resolution was to >Describe it using Package diagram. The issue is about the modelling elements of the KDM that allow representation of the packages within some existing system, as well as relationships between these packages, so that the corresponding >KDM view can be described using a UML package diagram.” Your interpretation is correct. My comment means that it is necessary to define package structure using Package diagram. “KDM has Package meta-model element (section 12.5.6, part of the Code package and the corresponding Code viewpoint). This element represents packages in existing software systems,” <..> my original question is based on the Figure 8.1 Page 11. This figure shows package structure of KDM. In general, multiple Package structure specification like UML need to be defined using Package diagram, to clarify their structure/relationship. This Figure 8.1 is not precise definition of Package structure (different from regular definition). To clarify this structure, it is necessary to specify the Package structure usign UML, because there is no precise way to define package structure except UML package diagram. According to this spec(P64), "Package" is subclass of Modules. In that case, what is the base class of Module? (CodeItem is superclass of Module. However, CodeItem is not original UML base element.) Considering above, it seems this "Package" is different from original UML Package. From my understanding, (I think,) if this spec use the Module, Module is a subclass of Package (which is from original UML), and change the name of "Package", which are shown in Page 64 and Page 66, to "Container" (something like that). Disposition: Deferred End of Annotations:===== m: "Nikolai Mansourov" To: "'Juergen Boldt'" Cc: Subject: KDM issue Date: Wed, 24 Mar 2010 22:23:46 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcrLwjKE04BQs6QkQLqK1zHeBPHPxA== X-Authenticated: nickmansurov - (MERGANSER) [12.52.72.10] Hi Juergen, Could you please give me the issue number for the following issue asap. -------------------------------------------------------------- Issue: Provide detailed information about dependencies between KDM packages Description: As per issue JP7 raised by the Japan delegation to ISO during the KDM review, it was stated that .Existing software based systems have the relationship among packages. But this standard doesn't mention it precisely. (Conceptually, this shows package structure.).. The suggested resolution was to Describe it using Package diagram. KDM 1.1 RTF decided not to replace the existing architectural illustration of the layers (as per issue resolution 13828) with the UML package diagram in order not to complicate the introductory part of the specification and not to complicate the maintenance of the formal machine readable documents of the specification. Also, the UML package diagram was not considered to be detailed enough. However, useful detailed relations between packages can be added as a non-normative appendix to the specification. Nikolai Mansourov Chief Technology Officer KDM Analytics cell (613) 276-2323 www.kdmanalytics.com e-mail: nick@kdmanalytics.com