Issue 11452: Section 8.4.31.3 (updm-ftf) Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: DoDAF spec says about command, control, coordination, etc organizational relationships. UPDM says about solid and dotted. It is incorrent to have graphical difference as data type. Resolution: Revised Text: Actions taken: September 18, 2007: received issue Discussion: End of Annotations:===== m: Andrius Strazdauskas This is issue # 11452 Section 8.4.31.3 Date: Wed, 23 Jan 2008 19:11:03 +0200 From: Andrius Strazdauskas User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: uPDM-ftf Subject: Some more resolutions All, Fred collected some Bug-type issues. Here's an attempt to suggest a resolution. Please let me know if there are arguments before I proceed with resolutions. With issue 11452 I still insist on changing the metaclass from Association to Usage. There was an email thread between Bran, Fred and me, but one thing was left unanswered. So there are two competing notations: Association: Usage: Given UML definition for association notation: "On a binary association drawn as a solid line, a solid triangular arrowhead next to or in place of the name of the association and pointing along the line in the direction of one end indicates that end to be the last in the order of the ends of the association. The arrow indicates that the association is to be read as associating the end away from the direction of the arrow with the end to which the arrow is pointing (see Figure 7.21). This notation is for documentation purposes only and has no general semantic interpretation." Given David Fado quote from today: "..we need to recognize the UPDM was built with a primary consideration on delivering the reports.." So, if a tool wants to automate a documentation production from an organizational model, specifically what OrgResources report to a give or OrgResource, for example: OrganizationalResource Peter Reporting personnel: Tom It is impossible to do so in case of association, since it has no direction implied. The only direction available is notational, not semantic. The model does not hold information which end is target, which is supplier. This is a huge issue. Fred, please don't bring the backward navigability argument, since there are ways to solve it: Additional tag in the target element Pete's statement on bidirectionality of non-navigable MOF association ends. 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 Date: Wed, 13 Feb 2008 15:32:24 +0200 From: Andrius Strazdauskas User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: Fred Mervine Cc: uPDM-ftf Subject: Re: Operational Issues Ballot 2 Fred, if your knowledge of defining possible kinds of OrganizationalRelationship is not deep enough, you should refer to domain experts - Fatma, Ron, or others. As far as the DoDAF spec says - the possible kinds are listed below, within my suggestion. However, I also believed, that if there is a case that is not covered by the profile, we always have "custom" kind. Personally, I don't like such "custom" things. Standard should be built to define one strict way to model, without much freedom of reinventing it from project to project. Andrius Fred Mervine wrote: Re: 11452 - There are other issues that refer to this. I don't believe we should even be trying to specify a RelationshipKind, since there is just no way to cover the ways people think of these. I think we should dump it altogether. _______________________________ Fred Mervine Executive IT Architect Federal CTO Strategic Technology Team IBM Software Group Federal Phone: 707-468-8460 Cell: 707-816-6218 Andrius Strazdauskas 02/12/08 06:41 AM To uPDM-ftf cc Subject Operational Issues Ballot 2 Attached are No Magic votes for Operational Issues 2 Ballot. All description issues - NO. To my knowledge Fatma was working on those and already has sent in resolutions. I've seen those resolutions and I think they are better. It is also not very clear to me why we are duplicating work, especially when timing is critical. Issue 11586 - NO. If element is needed for constraint, it is not needed at all. Constraint can be moved to relation or connected entity (OperationalNode in this case) Issue 11452 - NO. As I have expressed it multiple times, it is not correct from both profiling and domain sides. I've sent the resolution for this issue: 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 DoDAF spec says about command, control, coordination, etc organizational relationships. UPDM says about solid and dotted. It is incorrent to have graphical difference as data type.