Design Tools for RTEMS Qualification Toolchain

Wed Mar 27 18:08:41 UTC 2019

Hello Joel,

From the statement of work of the RTEMS Qualification, we have that:

“The Software Design Document (SDD) has to cover ECSS-E-ST-40C clauses 5.4.3.1.a, 5.4.3.2.a, 5.4.3.3.a, 5.4.3.4.a, 5.4.3.5.a, 5.4.3.6.c, 5.5.2.1.a, 5.5.2.1.b, 5.5.2.1.c, 5.5.2.2.a, 5.5.2.3.a, 5.5.2.4.a, 5.5.2.5.a, 5.5.2.6.a, 5.5.2.7.a, 5.5.3.1.a, 5.5.3.2.a, 5.5.3.2.b, 5.8.3.3.a, and 5.8.3.4.a and ECSS-Q-ST-80C clause 7.2.2.3.a.”

The Software Design Document is the document which will contain Architectural Design (“high level”) and Detailed Design (“low level”) of RTEMS. This means that the RTEMS Qualification Toolchain shall cover as much as possible the points above. I expect that some of the points can be done with the help of a tool (e.g. production of detailed component and sequence diagrams) but I haven’t seen a tool that does every content automatically – although of course, this would be great. My best guess is that the qualification toolchain will pick up the design that is made, probably bits of sphynx modules, aggregate them, do some automatic work (e.g. traceabilities, interfaces) and then generate a final Sphynx that could be converted to pdf. For the points above which cannot be automated, they have to be done manually.

I hope that this explanation answers your questions. Note also for your question below: “This is a goal for improving the RTEMS Project processes. Are these being captured?”, yes, we will do it

Best regards

José

From: Joel Sherrill [mailto:joel at rtems.org]
Sent: terça-feira, 26 de março de 2019 14:32
To: Jose Valdez
Cc: rtems-devel at rtems.org
Subject: Re: Design Tools for RTEMS Qualification Toolchain

On Mon, Mar 25, 2019 at 12:20 PM Jose Valdez <Jose.Valdez at edisoft.pt<mailto:Jose.Valdez at 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:joel at rtems.org<mailto:joel at rtems.org>]
Sent: segunda-feira, 25 de março de 2019 16:31
To: Jose Valdez
Cc: rtems-devel at rtems.org<mailto:rtems-devel at 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.Valdez at edisoft.pt<mailto:Jose.Valdez at 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 at rtems.org<mailto:devel at rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190327/392f54bb/attachment-0002.html>