See https://tools.ietf.org/html/draft-betts-netmod-framework-data-schema-uml-04
*Framework for Deriving Interface Data Schema from UML Information Models* See https://tools.ietf.org/html/draft-mansfield-netmod-uml-to-yang-03 *Guidelines for Translation of UML Information Model to YANG Data Model* On Mon, Apr 24, 2017 at 11:01 AM, Ed Warnicke <hagbard at gmail.com> wrote: > I love UML in a variety of contexts, but for expressing things that are > destined to be expressed in yang, or for creating things to be rendered to > yang, in my experience its been a very poor fit. > > Ed > > On Mon, Apr 24, 2017 at 9:41 AM, Brian Hedstrom <brian.hedstrom@ > oamtechnologies.com> wrote: > >> The way to put all these different data models under a single umbrella is >> to create a UML <https://en.wikipedia.org/wiki/Unified_Modeling_Language> >> Information Model using Eclipse/Papyrus (as an open source tool). >> Unified Modeling Language (UML) is a standard syntax for describing the >> architectural design of a system >> >> - Object Management Group (OMG) & ISO standard >> - Originated from object-oriented software development methods >> >> UML includes many diagrams types to graphically represent parts of a >> system?s model, including >> >> - Structural Views: The static nature of the system using objects, >> attributes and relationships (e.g., information or components that must be >> present in the system). This includes class diagrams and component >> diagrams. >> - Behavioral: The dynamic nature of the system through collaboration >> of objects and state changes (e.g., activities performed by the system). >> This includes use case diagrams, sequence diagrams, state machines. >> >> UML is protocol agnostic and therefore these "Information Models" are >> protocol agnostic. >> >> UML models can then be transformed into protocol specific data models >> such as YANG, XML, SMIv2, etc. >> >> Creating a UML Information Model allows data cohesion across the various >> interfaces in the system. Using Interface Realizations >> <http://www.uml-diagrams.org/realization.html>, specific interfaces can >> be modeled. In fact, an interface Information Model could be transformed >> into multiple data models to support multiple management protocols. >> >> Therefore, the focus first is on building a UML Information Model, then >> once that's approved by the organization, then data models and encodings >> can be generated based on the chosen interface protocols. >> >> Thanks, >> Brian >> >> On Sun, Apr 23, 2017 at 5:13 AM, <zhao.huabing at zte.com.cn> wrote: >> >>> Hi Brijesh, >>> >>> You brought up a great topic, we may need to converge at the same >>> aspect, but for different aspects, there are different modelling languages >>> which can better meet the specific requirement of that aspect, and they are >>> very complementary. >>> >>> For example, TOSCA(Heat is another, come with openstack) is a good >>> choice for the topology modelling of cloud application , YANG can be used >>> for the configuration model( normally using for L2 L3, can be used for >>> L4-L7 as well), and BPMN is good at workflow orchestration. >>> >>> It's difficult to put all these different modelling capabilities in a >>> single data model or using an unique DSL, and we don't need to. But It's >>> possible to make them work together smoothly under a unified umbrella >>> system to accomplish the automated close loop and I'm glad to see ONAP has >>> already make a very good start at that job. >>> >>> Thanks, >>> Huabing >>> >>> ???? >>> *???:* BrijeshKhandelwal; >>> *???:*GILBERT, MAZIN E (MAZIN E); denghui (L); JANA,RITTWIK (RITTWIK); >>> onap-discuss at lists.onap.org; onap-tsc at lists.onap.org; >>> *??:* 2017-04-22 11:56:56 >>> *??:Re: [onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th* >>> >>> Greetings, >>> >>> >>> >>> Adding some thoughts on information model: >>> >>> Orchestration need to interoperate among different interfaces, which in >>> turn need to deal with very different payloads in form of YAML, YANG, JSON >>> etc. There will be lots of data processing among these models to process >>> complete service. Handling these templates in orchestrator will impose >>> limitations on capability and performance of orchestrator. >>> >>> So, there should have standardized data model for smooth processing >>> among orchestration steps. >>> >>> >>> >>> Probably first time, orchestration is composing 3 different worlds of >>> Network, Infra, IT, with different tunes of YANG, YAML, JSON/XML. >>> >>> Is there a play to develop standardized data models for orchestration, >>> which will meet needs of each area? Is TOSCA sufficient? Or need some >>> extended JSON data models? >>> >>> >>> >>> >>> >>> -Brijesh >>> >>> >>> >>> *From:* onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-bounces at lists >>> .onap.org] *On Behalf Of *GILBERT, MAZIN E (MAZIN E) >>> *Sent:* Thursday, April 20, 2017 8:30 AM >>> *To:* denghui (L); JANA, RITTWIK (RITTWIK) >>> *Cc:* onap-discuss at lists.onap.org; onap-tsc at lists.onap.org >>> *Subject:* Re: [onap-tsc] Modelling discussion on Friday May 5th >>> >>> >>> >>> Rittwik, Deng, >>> >>> >>> >>> This is great. Thank you for taking the lead. >>> >>> >>> >>> I realize the focus is on TOSCA and parsers. Wonderful! >>> >>> I want to take you one level higher to start by discussing >>> >>> what the framework look like for the information model. Perhaps invite >>> folks who have >>> >>> operational experience. Then start describing the differernt >>> >>> data models and how TOSCA plays a role in driving service chaining and >>> micro services >>> >>> (like analytics, data collections, etc). >>> >>> >>> >>> It would be great if the outcome of this mini session to >>> >>> be a recommendation position/paper or a proposal for a project. >>> >>> >>> >>> Mazin >>> >>> >>> >>> >>> >>> On Apr 20, 2017, at 4:34 AM, denghui (L) <denghui12 at huawei.com> wrote: >>> >>> >>> >>> Hello all >>> >>> >>> >>> We are happy to let you know that we are hosting a modeling session on >>> Friday, May 5th, AT&T Lab. >>> >>> 9:00-10:30 Shitao moderate: TOSCA NFV Profile >>> >>> 10:30-12:00 Rittwik moderate: AT&T Parser >>> >>> 13:30-16:00 DengHui moderate: Modelling & Opendeployment >>> >>> >>> >>> Please kindly help to let us know if you are interested in joining us, >>> so that we can book a proper meeting room for our discussion >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Rittwik & DENG Hui >>> >>> _______________________________________________ >>> ONAP-TSC mailing list >>> ONAP-TSC at lists.onap.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.o >>> nap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeM >>> TSQicvjIg&r=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y&m=HR >>> oKLiOZCWLzl3Z-00DLQIUCwCAWqQL50mUFHtfYXYA&s=731fuCUnXbuPSOGH >>> EcVf4U29cHpOGPKmwevRHGAoeiY&e= >>> >>> >>> >>> ============================================================ >>> ================================================================ >>> >>> Disclaimer: This message and the information contained herein is >>> proprietary and confidential and subject to the Tech Mahindra policy >>> statement, you may review the policy at http://www.techmahindra.com/Di >>> sclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html >>> internally within TechMahindra. >>> >>> ============================================================ >>> ================================================================ >>> >>> >>> _______________________________________________ >>> ONAP-TSC mailing list >>> ONAP-TSC at lists.onap.org >>> https://lists.onap.org/mailman/listinfo/onap-tsc >>> >>> >> >> >> -- >> Brian Hedstrom >> Founder/CEO >> OAM Technology Consulting LLC >> oamtechnologyconsulting.com >> brian.hedstrom at oamtechnologies.com >> 720-470-7091 <(720)%20470-7091> >> >> _______________________________________________ >> onap-discuss mailing list >> onap-discuss at lists.onap.org >> https://lists.onap.org/mailman/listinfo/onap-discuss >> >> > -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedstrom at oamtechnologies.com 720-470-7091 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170424/6d96994e/attachment.html>
