Issue 11740: 8.6.48:SystemsNodeElements (01) (updm-ftf) Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us) Nature: Uncategorized Issue Severity: Summary: SystemsNodeElements should use Resource instead of OrganizationalResource. SO that SystemsNodes can be nested. Resolution: Revised Text: Actions taken: December 5, 2007: received issue Discussion: End of Annotations:===== ssue XXXX:8.6.48:SystemsNodeElements Source: Fred Mervine Nature: Uncategorized Issue Severity: Moderate Summary:SystemsNodeElements should use Resource instead of OrganizationalResource. SO that SystemsNodes can be nested. Resolution: Revised Text: Actions taken: December 5, 2007: received issue Date: Thu, 06 Dec 2007 17:10:38 +0200 From: Andrius Strazdauskas User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: Fred Mervine Cc: updm-ftf@omg.org Subject: Re: issues 11740 - 11742 -- UPDM FTF issues Fred, we have agreed to remove SystemNodeElements from UPDM and to use composite structures for nesting elements into SystemsNodes. I believe there is no need to raise these issues. 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 Juergen Boldt wrote: issues From: Fred Mervine This is issue # 11740 8.6.48:SystemsNodeElements (01) SystemsNodeElements should use Resource instead of OrganizationalResource. SO that SystemsNodes can be nested. =========================================================== This is issue # 11741 8.6.48:SystemsNodeElements (02) SystemsNodeElements should include SystemGroup so that we can include whole configurations. ============================================================= This is issue # 11742 8.6.48:SystemsNodeElements (03) We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org To: Andrius Strazdauskas Cc: uPDM-ftf@omg.org Subject: Re: issues 11740 - 11742 -- UPDM FTF issues X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Fred Mervine Date: Thu, 6 Dec 2007 10:08:54 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 8.0|August 02, 2007) at 12/06/2007 11:08:56, Serialize complete at 12/06/2007 11:08:56 I don't think we have agreed to removing SystemNodeElements. I know you have proposed that, but we haven't discussed it nor agreed to it. We need to be able to look at a System and determine what SystemsNodes it is deployed in. This issue illustrates a fairly significant difference in our perspectives. Our customners have very large models. We are working on a pilot project with 2 million elements in the models. When working with databases, sequential scans of a small database work for searching for objects, but when we work with large databases, it is necessary to design the database to facility navigation such that queries can actually complete. When we look at these models as data repositories, the same principles must be applied if our customers expect to apply it to large models. For Relational databases, we use indexes and foreign keys. Object databases utilize direct pointers instead of the foreign keys. In the UML models, the associations provide this capability. If I want to find all of the SystemsNodes in which a System is included, then with an association, I can simply follow the SystemNodeElements association and find them. The association implies the structure, but if I use composite structures to simply add a part without using the assoication, then I lose the navigability from System to SystemsNode, unless I do a scan of the model. The problem is exacerbated when these large projects are spread across several models. In this example, I coudl have SystemsNodes in several models, and the Systems that they contain in other models. If I select a System in a model, I have not way to find which SystemsNodes it is deployed in. If I have defined the systemsNode with associations, then there is reference to the SystemsNodes that enables navigation. This same problem occurs when dependencies are used, because in general, we can't know all of the models that exist, so we can't know where to look for dependencies that might exist that point to providers in a given model. with bidirectional associations, the refrences exist. _______________________________ Fred Mervine Executive IT Architect Federal CTO Strategic Technology Team IBM Software Group Federal Phone: 707-468-8460 Cell: 707-367-1541 Andrius Strazdauskas 12/06/07 07:10 AM To Fred Mervine/San Jose/IBM@IBMUS cc updm-ftf@omg.org Subject Re: issues 11740 - 11742 -- UPDM FTF issues Fred, we have agreed to remove SystemNodeElements from UPDM and to use composite structures for nesting elements into SystemsNodes. I believe there is no need to raise these issues. 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 Juergen Boldt wrote: issues From: Fred Mervine This is issue # 11740 8.6.48:SystemsNodeElements (01) SystemsNodeElements should use Resource instead of OrganizationalResource. SO that SystemsNodes can be nested. =========================================================== This is issue # 11741 8.6.48:SystemsNodeElements (02) SystemsNodeElements should include SystemGroup so that we can include whole configurations. ============================================================= This is issue # 11742 8.6.48:SystemsNodeElements (03) We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Date: Fri, 07 Dec 2007 11:58:53 +0200 From: Andrius Strazdauskas User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: Fred Mervine Cc: uPDM-ftf@omg.org Subject: Re: issues 11740 - 11742 -- UPDM FTF issues Fred, You say: " I know you have proposed that, but we haven't discussed it nor agreed to it." We have discussed it in Jacksonville, you said "it is a good candidate to remove". We have also discussed it in London. You were making notes, could you look up to see the resolution? I though we agreed to remove it. In case you want to keep it, you also need to have "SystemElements" for decomposing systems, since now composite structures are suggested. The same story. You will also have problems navigating if elements are linked with Realizations, unidirectional associations between stereotypes, etc. If the main approach would be bidirectional navigability - we would have every element extending Class and every relationship extending Association. We have to reuse knowledge from existing specs and we should not reinvent the wheel. SysML has solved this navigability problem - by adding derived properties where needed, why can't we? Personally, I hate associations, since it is a complex structure that creates association end and pollutes the model. It is also problematic to collect other ends of stereotyped association - you have to get owned attributes, then check if it has association property, if it has, then you have to check the stereotypes. But this is my personal preference. So if you have 2 million elements in your pilot project, you will probably have something like 5 millions in normal project. So I would guess that you will have at least 200000 associations. As every association creates 2 properties, the amount of element will significantly increase, lowering the performance of your tool. 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 Fred Mervine wrote: I don't think we have agreed to removing SystemNodeElements. I know you have proposed that, but we haven't discussed it nor agreed to it. We need to be able to look at a System and determine what SystemsNodes it is deployed in. This issue illustrates a fairly significant difference in our perspectives. Our customners have very large models. We are working on a pilot project with 2 million elements in the models. When working with databases, sequential scans of a small database work for searching for objects, but when we work with large databases, it is necessary to design the database to facility navigation such that queries can actually complete. When we look at these models as data repositories, the same principles must be applied if our customers expect to apply it to large models. For Relational databases, we use indexes and foreign keys. Object databases utilize direct pointers instead of the foreign keys. In the UML models, the associations provide this capability. If I want to find all of the SystemsNodes in which a System is included, then with an association, I can simply follow the SystemNodeElements association and find them. The association implies the structure, but if I use composite structures to simply add a part without using the assoication, then I lose the navigability from System to SystemsNode, unless I do a scan of the model. The problem is exacerbated when these large projects are spread across several models. In this example, I coudl have SystemsNodes in several models, and the Systems that they contain in other models. If I select a System in a model, I have not way to find which SystemsNodes it is deployed in. If I have defined the systemsNode with associations, then there is reference to the SystemsNodes that enables navigation. This same problem occurs when dependencies are used, because in general, we can't know all of the models that exist, so we can't know where to look for dependencies that might exist that point to providers in a given model. with bidirectional associations, the refrences exist. _______________________________ Fred Mervine Executive IT Architect Federal CTO Strategic Technology Team IBM Software Group Federal Phone: 707-468-8460 Cell: 707-367-1541 Andrius Strazdauskas 12/06/07 07:10 AM To Fred Mervine/San Jose/IBM@IBMUS cc updm-ftf@omg.org Subject Re: issues 11740 - 11742 -- UPDM FTF issues Fred, we have agreed to remove SystemNodeElements from UPDM and to use composite structures for nesting elements into SystemsNodes. I believe there is no need to raise these issues. 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 Juergen Boldt wrote: issues From: Fred Mervine This is issue # 11740 8.6.48:SystemsNodeElements (01) SystemsNodeElements should use Resource instead of OrganizationalResource. SO that SystemsNodes can be nested. =========================================================== This is issue # 11741 8.6.48:SystemsNodeElements (02) SystemsNodeElements should include SystemGroup so that we can include whole configurations. ============================================================= This is issue # 11742 8.6.48:SystemsNodeElements (03) We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org