Design Tools for RTEMS Qualification Toolchain

Wed Mar 27 19:31:42 UTC 2019

Scott. mentioned you below. Time for you to speak up. :)

On Wed, Mar 27, 2019 at 1:08 PM Jose Valdez <Jose.Valdez at edisoft.pt> wrote:

> 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.”
>

Thanks. The qualification and compliance efforts I have been involved with
or near allow you to do "bespoke" documentation and provide a mapping from
the expected to the actual.More below.

>
>
> The Software Design Document is the document which will contain
> Architectural Design (“high level”) and Detailed Design (“low level”) of
> RTEMS.
>

Using this as an example, we could have an Architecture Design document and
something else for Detailed Design. The mapping document from ECCS to RTEMS
artifacts would go through each of those section numbers, likely repeat the
text, and then explain where the required information is for RTEMS. If
necessary, it will justify the mapping. For example,say we were using a
true modeling tool which generated code, requirements, etc. It is quite
likely that its output is not in the format or names expected by ECCS, NASA
Quaity, DO-178, or another standard.

Providing the mapping document insulates both RTEMS and ECCS from each
other.

This is not to say that the names or artifact list in ECCS is bad -- just
that it is ECCS. And another standard will name the same artifact
differently. We will end up producing mapping documents so we might as well
start with one.

Scott Zemerick did a mapping for a couple of the quality standards when he
gave us the outline of the Software Engineering Guide. If we do an ECCS ->
RTEMS mapping, then the NASA folks should be able to do a NASA Quality and
hopefully DO-178 -> RTEMS mapping document in parallel.

> 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'm old and cynical on the quality of generated output so I am guessing
that we will find some we like and some that sucks. Hopefully the stuff we
have to do by hand is not volatile. Things dependent on source code need to
be generated.

Devil is in the details. We have to push each artifact topic and make it as
easy and maintainable as possible.

>
>
> 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
>

+1 Did my outline for the tools evaluation chapter in the SW Engineering
Guide make sense? I hope so because I think you are working on it now.

If the requirements tool evaluation is nearing an end, posting that as a
patch in Rest for the Guide would be a good start. This will then be
another section in the same chapter.

--joel

>
>
> 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>
> 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/20190327/7c6625fb/attachment-0002.html>