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 at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170424/3d7365f4/attachment.html>
