0

I am working on modeling GPB messages and inter-app communication using MagicDraw's sequence diagramming.

Ultimately, I want to use MagicDraw's C++ code generation tool to export the models into C++ code, and then turn that into .proto files. The goal is to turn the diagrammed models from MagicDraw and convert them into .proto files.

I've spent 5+ hours looking for ways to do this, but it looks like code conversion only works from writing .proto files and then using protoc to turn them into C++, not the other way around.

Is there any way to reverse this process?

ForcePitchForce
  • 1
  • C++ is active code, moving parts. Protobuf is data. What do you mean by having C++ represented as protobuf? Code is not data (for these purposes at least). Something has to be "running" (code runs), to interpret data. What program will consume these proto files you want? – Thomas Jun 01 '22 at 18:19
  • Welcome to StackOverflow. I'm no protobuf expert so this is just my naive view but this sounds to me like directly decompiling executables into C++ code. Sure it works somehow. But the result is very far from pretty (or usable in most cases). – PhilMasteG Jun 01 '22 at 18:20
  • 2
    You will have much better luck going directly from modeling tool -> protobuf without going through C++ on the way. – Ben Voigt Jun 01 '22 at 18:21
  • 2
    I'd say that going _from_ C++ to protobuf sounds like a _hard_ task, but if `MagicDraw` is capable of generating C++ code, perhaps someone has made a protobuf plugin for it so it can generate that too? – Ted Lyngmo Jun 01 '22 at 18:21
  • Hi everyone, thank you for your comments. @ Thomas, I mean representing C++ code as a .proto file. My understanding is that you can create .proto files and use protoc to convert them into different languages. The modeling tool I am using generates C++ code from the models. I'm modeling the GPB messages in MagicDraw, but I can't generate a .proto file, only C++ or these other languages. So, I am looking to input this generated C++ code into some program to end up with a .proto file again. Thank you for the welcome, Phil! – ForcePitchForce Jun 01 '22 at 18:42
  • what exactly do you mean with "representing C++ code as a .proto file" ? Writing a .proto file for a known data structure is relatively easy, parsing C++ code can be arbitrarily complicated. – 463035818_is_not_an_ai Jun 01 '22 at 18:45
  • Whatever format "MagicDraw" saves its own files in is probably much closer to protobuf than C++ is. – Ben Voigt Jun 01 '22 at 18:58
  • Here's what I think you are missing. There is not any relationship between .proto files and "all C++". There is only a relationship between .proto files and C++-files-that-came-from-protoc. Even if you got a tool to "reverse the process" it would only work on C++-that-came-from-protoc, which is not what you have. C++ is not a protocol modelling language, it is a very powerful and flexible programming language. The portion of C++ which protoc spits out is a very very small fraction of "all C++", let's say 0.0001% – Ben Voigt Jun 01 '22 at 19:24
  • Now, the fraction of C++ used by SmartDraw is probably also only 0.0001%, but it's a different 0.0001%. You cannot "end up with a .proto file **again**" for something that has never at any point in its life been a .proto file. There does not exist any .proto file which could be fed to protoc to create the same C++ code that SmartDraw created, just like there is no .proto file that could be fed to protoc to create the Linux source code, or the source code for StackOverflow. – Ben Voigt Jun 01 '22 at 19:25

1 Answers1

0

Ah, the quest for the hallowed model<==>schema<==>code<==>model triangle.

I don't actually have a good answer I'm afraid. The closest I've got to this is Enterprise Architect, XSD, and ASN.1. But this is not complete; Enterprise Architect doesn't sync to XSD; it's a straight forward import/export, so changes made in XSD don't reflect back to Enterprise Architect. In EA, you can define classes (classic UML stuff), and export a package of classes as XSD, which the better ASN.1 tools will consume as a schema (there is an official translation between XSD and ASN.1 schema, and ASN.1 compilers tend to be better at implementing and enforcing things like minoccurs in generated code (a lot of XML/XSD compilers actually do a bad job of such things).

I've kind of given up looking. My suspicion is that tool developers will only do so if there is a market (or an enthusiastic user base willing to contribute donations for OSS). An awful lot of software gets developed without the use of schemas to define data structures (which leads to a large number of the world's buffer overruns, interface bugs, etc), never mind tools that sync code / schemas / models. So I think that there's precious few developers out there who see the actual value of such tooling, and so there's not that much enthusiasm for developing the tools in the first place. It's a classic chicken / egg situation.

Which is a pity. Using a strong schema system like ASN.1, or XSD (with a really good compiler) or perhaps at a pinch JSON (there seems to be more of an emphasis on using schema to check objects, rather than using scheme to define classes) leads to a very agile development path. Particularly with ASN.1, you can have all of a system's messages / data structures and their constraints and all of the system's constants defined once in a schema. You can then use the build system to propagate any changes to every corner of a project automatically. With this pattern embraced you can make late-breaking changes in system interfaces really quite easily and safely.

bazza
  • 7,580
  • 15
  • 22