On Mon, Mar 25, 2019 at 12:20 PM Jose Valdez <jose.val...@edisoft.pt> wrote:
> Hello Joel, > > > > Thank you for your reply. > > > > I meant by design tools, UML tools (I am targeting component and sequence > diagrams). It seems that you meant that you consider design tools the ones > that are able to produce code from the design. Indeed was not with that > goal in mind, because: > > è RTEMS source code is already defined (although this would not be a > critical point, since reverse engineering would be possible, like will do > the doxygen) > > è As far as I know, most of these tools target code production for > object-oriented languages. This is not the case for RTEMS. > The term design tools covers so much territory that my first Google turned up SysML and MathCAD. It is just too broad a term. > > > What do you mean by a use-case? An example? I tried to quick capture the > main features of the tools and their applicability to our project and, as > you may read in the previous e-mail, the PlantUML and blockdiag are the far > the most suitable. > The definition of use case is " a specific situation in which a product or service could potentially be used." I think that covers my intent. Define how these tools will be used and what's expected. I agree that we are not generating code and are just capturing existing design. But I still don't know what technical data/artifacts are required by the ESA quality standard so can only base the expected use cases on what I would expect. + Document high level architecture in a new document + Document sequences, flows, logic primarily to enhance Doxygen output Any diagrams could also be useful in Classic API Users Guide to document schedulers, etc to users. > > I agree with the approach to generate detail design data from source code > and then for the top level architecture, to use the Design selected tool. > Of course part of the work will be to incorporate functionality that if an > architectural change in the code is made, the user shall be warned to > update the Architectural Design. This shall be done by linking > (traceability) architectural components source code (that’s why defining > architectural components in text files will be useful). > This is a a goal for improving the RTEMS Project processes. Are these being captured? And I would expect a fair number of false positives. I will have 30 years with RTEMS this summer and the basic architecture figures rarely need to change for technical reasons. I'm not trying to be argumentative. Just looking a well-defined process for these tool evaluations: + What will the tool(s) be used for? + What artifacts produced? + What "requirements" of the various quality standards is it meeting? + Does it need to integrate with build processes? I am assuming a high level design document would be natural to go in the RTEMS Documentation Suite. Today, I am sure the rtems-docs build system supports both PlantUML and ditaa. If it doesn't support graphviz/dot and mscgen (used by our Doxygen), then that's has to be addressed. --joel > > > Best regards > > > > José > > > > *From:* Joel Sherrill [mailto:j...@rtems.org] > *Sent:* segunda-feira, 25 de março de 2019 16:31 > *To:* Jose Valdez > *Cc:* rtems-de...@rtems.org > *Subject:* Re: Design Tools for RTEMS Qualification Toolchain > > > > You haven't defined what you mean by design tool. The implication seems to > be > > something to do UML-ish things in. > > > > PlantUML with DITAA, mscgen, and dot (e.g. graphviz) as backups is a > pretty > > good combination for drawing diagrams. > > > > But they are not design tools IMO. They are tools to produce diagrams which > > can be used in design documents. When you say design tools, I think tools > > like Enterprise Architect, Magic Draw, etc. > > > > And for design, there are multiple levels. As a minimum, I would expect a > > higher level architectural view and a low level software design. The former > > is primarily going to be abstract with figures and descriptions. Probably a > > document when it is done. The low level design should be able to be > > captured via Doxygen and the drawing tools above. > > > > Please define the use cases for the tool before dropping into specific > tools. > > > > --joel > > > > On Mon, Mar 25, 2019 at 10:52 AM Jose Valdez <jose.val...@edisoft.pt> > wrote: > > Hello, > > > > I have been doing the Design Tools investigation. I had investigated > several tools with the following features in mind: > > > > è Open Source and active project > > è Text-file based tool, which allows git control and manipulation of the > files with other tools (to add extra functionality) > > è Diagram export to image and possibly to ascii art (if we want to > incorporate some diagrams into source code) > > è User friendly > > è Both component and sequence diagrams available > > > > After my investigation I made the following short list: > > > > è PlantUML: It has all characteristics above listed. Unfortunately, the > export to ascii art diagrams feature is only available in the PlantUML > online editor, also, there is no GUI (at least which I am aware of, but no > big problem) for editing diagrams. Note that although the tool is called > PlantUML, PlantUML is itself a standard, so there are several tools, which > can handle it. > > è Modelio: More GUI based than text file based. Import/Export from/to > html like files is possible, however in a hard-to-understand format > > è Violet: Also a GUI based. It has a simpler interface, but slower > (annoying) than Modelio. The model is saved into html in a hard-to-read > format. > > è UMLet: Also GUI interface (seems not 100 % functional). It outputs to > html, but this html only contains the position of the elements in the UML > drawing and not the relation between components > > è ASCIIFlow: Not properly an UML design tool, but it allows to quickly > design simple component diagrams in ascii art, which can be included in > code. Also allows to import and edit already existing ascii drawings. I > believe It will not be used, but was put here as a reference. > > è blockdiag and seqdiag: (http://blockdiag.com/en/), blockdiag provides > two packages (shall be installed separately), blockdiag and seqdiag to, > respectively, draw block and sequence diagrams. The input is text file > which allows to generate the diagrams. Has also interface with sphinx and > probably it is possible to represent the diagrams in asci art. > > > > I would say that the best candidates are PlantUML and blockdiag. > > > > I found other tools which are either dead projects (most of them) or have > missing features. I will write down the list, If anyone is interested to > have a look: > > è ARGOUML > > è UMBRELLO > > è Dia > > è StartUML > > è UMPLE > > è ZenUML > > > > I know that there is the idea to use the doxygen to generate architectural > components from the code. I believe that any of these tools can be used > when such situation is not possible, or do you think that doxygen alone > will meet our needs? I still did not look at it… > > > > Best regards > > > > José > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
