Issue 18577: PIM Logical Service Specification (updm-2-0-rtf) Source: Scientific Research Corporation (Mr. Kent Laursen, klaursen(at)scires.com) Nature: Revision Severity: Summary: An import use of architecture is to provide sufficient information to guide the design and implementation that realizes the architecture in the actual solution space. By definition, architecture dictates neither the design nor the implementation that realizes it, though this boundary is often blurred to a certain degree by a particular organizations methodology or pragmatic need of a projects. As SOA is an a widely employed architectural pattern where by systems interact with each other, it would seem important that the expression of SOA in UPDM be fit for purpose, sufficiently accurate and information complete to reduce the conceptual gap between architecture and design+implementation. Further, the rendering or specification of SOA interfaces and used datatypes should be sufficiently fine grained to allow such possibilities as: Transformation into constructs used in design and implementation workflows, e.g. Code Skeletons, XML Schema, etc. Supporting the expression of test cases and declarative expressions of architectural instrumentation for such purposes as monitoring and analytics. In this particular issue we focus on the SvcV-1 and SvcV-2, which would be the natural place to specify the actual SOA related elements. The following diagram provides a context from an external, classifier derived perspective. Focusing on the services themselves, the diagram below shows an intended The SvcV-1 that illustrate the specification down to the actual operations is shown in the following diagram The issue submitter acknowledges that there are arguably some other ways to represent services, given such constructs as ServiceFunction, etc., but the method depicted above “feels” more accurate and aligned with downstream design and implementation, especially in the context of UML that might be used by teams independent of UPDM. In conclusion, the issue submitter, along with project colleagues, wish to have a useful set of mechanisms/metamodel constructs that allow the expression on services, their interactions and the flow of data between them at the PIM/Logical level using, logical data captured as EntityItem that details conceptual data captured as ExchangeElement. This would allow direct traceablity from conceptual interchange expressed at the OV level with how it is addressed at the SV level. In simpler terms, when two activities exchange information at the business process level, we can easily find how this conceptual interaction is realized as SOA services. Once establishing this in the model we can then hand it off to design and implementation workflows in a more accurate, traceable and useful architectural specification form. Significantly, such and architecture might prove much more fit-for-purpose for model related practices, transformations and automations involving the instrumentation, simulation and observation of the architecture in its solution realized forms. Also tests might be expressed more tightly. Resolution: Part of the resolution would be related to the fact that and ExchangeElement is subtyped from ResourceInteractionItem whereas EntityItem is subtyped from Class. The result is that a logical data structure captured as an EntityItem cannot be the conveyed item in a ResourceInteraction. We would either need to revise the metamodel related to ResoureInteractionItem or add some new construct, say something like DataInteractionItem and DataInteraction that could be used to express the flow of logical data, which the issue submitter models using EntityItem in DIV-2 package structures. On the profile diagram below, one can observe the absence of EntityItem There are related traceablity issues that will the subject of further submissions, however, this submission focuses on the essential part of expressing the set of SOA ports, interfaces and data flows in an architecture. Resolution: Revised Text: Actions taken: March 23, 2013: received issue Discussion: End of Annotations:===== m: "Laursen, Kent" To: "Juergen Boldt (OMG)" CC: "Lonnie VanZandt (NoMagic)" , "Graham Bleakley (IBM)" , "Matthew Hause (Atego)" Subject: FW: UPDM 2.2 RTF Issue - PIM/Logical Service Specification Thread-Topic: UPDM 2.2 RTF Issue - PIM/Logical Service Specification Thread-Index: Ac4n+QzysIQvtyrwSgux8GhwjVxHzgCNBU5A Date: Tue, 26 Mar 2013 14:23:23 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [107.201.230.55] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi Juergen, I haven.t seen that the issue submitted below has been logged with the others that came out of the Reston meeting. Is there anything else I need to do? Regards, Kent Laursen Senior Systems Engineer Scientific Research Corporation 3015 Saint Charles Street, Suite B San Diego, CA 92110 Mobile: 843-737-3401 E-mail: klaursen@scires.com Web: www.scires.com Office Tel: 619-686-2022 Office Fax: 619-686-2096 From: Laursen, Kent Sent: Saturday, March 23, 2013 12:13 PM To: Juergen Boldt (OMG) Cc: Lonnie VanZandt (NoMagic); Matthew Hause (Atego); Graham Bleakley (IBM); Fatma Dandashi (Mitre); Lars-Olof KihlströSyntell); Laura Hart (Lockheed); Aurelijus Morkevicius (No Magic); Walt Okon (OSD); Vince Quesnel (vincent.quesnel@forces.gc.ca) Subject: UPDM 2.2 RTF Issue - PIM/Logical Service Specification Hello Juergen, Can you please log the new attached issue against the UPDM 2.2 RTF? I have also attached the actual model developed for the issue, in case it is of use to anyone. The exercise also served to bring up other issues such as ease and completeness of tracability, which will be the focus of other submissions. Regards, Kent Laursen Senior Systems Engineer Scientific Research Corporation 3015 Saint Charles Street, Suite B San Diego, CA 92110 Mobile: 843-737-3401 E-mail: klaursen@scires.com Web: www.scires.com Office Tel: 619-686-2022 Office Fax: 619-686-2096 CONFIDENTIALITY NOTICE: This email constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. 2510, and its disclosure is strictly limited to the named recipient(s) intended by the sender of this message. This email, and any attachments, may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, any copying, using, disclosing or distributing to others the information in this email and attachments is STRICTLY PROHIBITED. If you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts or hard copies of the email and attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. UPDM-Issue-PIM-Logical-Service-Specification1.doc UPDM-Issue-PIM-Logical-Service-Specification1.doc UPDM-Issue-PIM-Logical-Service-Specification.mdzip1 UPDM-Issue-PIM-Logical-Service-Specification.mdzip1