Design Tools for RTEMS Qualification Toolchain

Tue Mar 26 14:31:50 UTC 2019

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