Issue 11420: Extensions section should not be empty,ie section 8.2.2.1 (updm-ftf) Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: Even is the stereotype generalizes other stereotype, its Extensions section should not be empty, since extension is inherited. Currently the spec if very hard to read. Resolution: Revised Text: Actions taken: September 18, 2007: received issue Discussion: Extensions section should not be empty End of Annotations:===== s is issue # 11420 Extensions section should not be empty,ie section 8.2.2.1 To: uPDM-ftf@omg.org Cc: selic@acm.org Subject: Re: Ballots 3 and 4 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Fred Mervine Date: Tue, 15 Jan 2008 14:25:45 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 8.0|August 02, 2007) at 01/15/2008 14:25:48 This doc contains the entries that Andrius noted with the discussion. The e-mail has just the discussion sections. ==================================================== Issue 11420: Extensions section should not be empty,ie section 8.2.2.1 (updm-ftf) I changed the proposed Resolution to add the estensions, but see discussion as to why I think we should vote NO. Bran, Pete - what is the correct convention here, or is there one? Discussion: Extensions section should not be empty I think this should be resolved as not an Issue because other UML documents do not include the extension if the stereotype specializes another stereotype. I changed the proposed Resolution to add the estensions, and I recommend we vote NO on this issue. Adding Extensions section to every element increases the readability of the spec. This is also easily done. I can do the changes, if needed. ============================================ Issue 11438: Section 8.3.24.3 (updm-ftf) OOPS - copy/paste error - the proposed solution should be to fix the diagrams and remove the association. =============================================================== Issue 11441: Section 8.4.8.3 (updm-ftf) I changed the proposed Resolution to remove the associations from the diagrams, but I think they should be kept. ANyone else have an opinion? Discussion: - Note an information flow has an association to the implementing connector that can be typed by an association, so a relationship to Needline or SysInterface would be redundant. . InformationExchange and DataExchange extend InfformationFlow. InformationFlow has an association . ReaalizingConnector. Given an InformationFlow, I can find the connectors that realize it. For an InformationExchange or DataExchange these connectors are constrained to be Needline or SystemInterface respectively. Connectors can be typed by Associations, so a connector that is a Needline should be typed by the corresponding Needline/Association that must exist between the two OperationalNodes that are the types of the parts connected by the Needline/Connector. Assuming that the modeler, or more desirably, the tooling, makes sure that these elements are correctly typed and related, one can start at an InformationExchnage and find the connectors and thus the Needlines along which the information flows. However, given a Needline (connector or association), one cannot necessarily fine the associated InformationFlows since the ..realizing.. assoociations are all one way, hence the need for the one way association between Needline/SystemInterface and the respective InformatijonExchange and DataExchange. (Same is true for DataExchange and SystemInterface). If UML metaproperties are reused, so diagram should be updated and associations removed. The uni-directional association still exists from Needline and SystemInterface to InformatonExchange and SystemInterface to DataExchange. The question here is should those uni-directional associations be shown on the InformationExchange and DataExchange. I think the associations should remain in the diagrams. =================================================== Issue 11482: Section 8.6.43 (updm-ftf) Discussion: - This may be a tooling issue. It is certainly implementable: - This is surely implementable in most of the tool, but that is not the point. The point is that it only can be visualized, if both Needline and System Interface are on the same diagram. Given that there will be many of those relations, the visualization is troublesome, since you will have to basically merge OV-2 and SV-1 in to single diagram, just to visualize it. - I don..t see how one could visualize the relationship if the aren..t both on the diagram. Does Andrius have some proposal to visualize this relationship when they aren..t both on the same diagram that we can vote on? If so we can make that the proposed solution, and vote on it. =================================================== Issue 11802. This is more of a question - why Asset was removed? I believe that it was used for depicting abstract entities. With removal of Asset, what is the proposed solution for doing something like OV-1? There is an issue to remove Asset and AssetMapping, and I thought we had voted on it in Ballot 1 or 2, but we haven't voted on it yet. I'll take this off this ballot and put them all together on another ballot. _______________________________ Fred Mervine Executive IT Architect Federal CTO Strategic Technology Team IBM Software Group Federal Phone: 707-468-8460 Cell: 707-367-1541 Andrius Strazdauskas 01/15/08 08:27 AM To uPDM-ftf cc Subject Ballots 3 and 4 Fred and all, I've reviewed the resolutions. Here are some comments. Ballot 4 is OK, with exception to the Issue 12019, are we sure that MOD thinks that this is not an issue? Ballot 3 comments: Issue 11420. Adding Extensions section to every element increases the readability of the spec. This is also easily done. I can do the changes, if needed. Issue 11438. So what is the purpose of Enterprise being a Package? Anyway, the diagram for the Enterprise should be updated. Issue 11441, Issue 11462. If UML metaproperties are reused, so diagram should be updated and associations removed. Issue 11482. This is surely implementable in most of the tool, but that is not the point. The point is that it only can be visualized, if both Needline and System Interface are on the same diagram. Give that there will be many of those relations, the visualization is troublesome, since you will have to basicall merge OV-2 and SV-1 in to single diagram, just to visualize it. Issue 11802. This is more of a question - why Asset was removed? I believe that it was used for depicting abstract entities. With removal of Asset, what is the proposed solution for doing something like OV-1? Everything else looks OK. Andrius -- -- Andrius Strazdauskas Product Research and Development Manager No Magic Lithuanian Development Center Savanoriu pr. 363, LT 49425 Kaunas Phone: +370 37 705889 Fax: +370 37 320670 E-mail: andriuss@nomagic.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture Made Simple Ballot-4 discussion.doc Even is the stereotype generalizes other stereotype, its Extensions section should not be empty, since extension is inherited. Currently the spec if very hard to read.