Is UML fit for embedded work?

I had already asked the question many years ago and the
responses were mixed.

We are currently part designing, part reengineering a big
software project for the control of power stations. Since
the previous release was made without proper design
notation, the company has decided to use UML and a
tool call Visual Paradigm to do the preliminary design.
We won't generate the code.

One aspect that IMO is not satisfactory is that UML
diagrams are not "naturally" fit for expressing requirements
in a way that is consistent and complete enough to
generate usable code and being able to reverse
engineering. With the possible exception of state
diagrams which can be translated into executable
instruction while staying at a rather abstract point of
view. Use cases, sequence diagrams, activity diagrams
are approximate and leave too much room for interpretation
or are cluttered with some detail in an obscure notation.

I have had a look at an European project called "Interested".
They have used tools from different vendors and built the
necessary interfaces. They can generate code for highly
demanding applications such as avionics or nuclear plants.
The problem is those tools are rather hard to use and can
only be used where the generated code is relatively small.

It seems there is a need for tools for large projects with
intermediate safety constraints that are not covered by the
existing ones.

An article expressing my views on UML:

<http://softwarechimps.blogspot.fr/20...ml-or-dsl-for-
embedded.html>

On 4/11/2012 9:05 AM, Lanarcam wrote:
> I had already asked the question many years ago and the
> responses were mixed.
>
> We are currently part designing, part reengineering a big
> software project for the control of power stations. Since
> the previous release was made without proper design
> notation, the company has decided to use UML and a
> tool call Visual Paradigm to do the preliminary design.
> We won't generate the code.
>
> One aspect that IMO is not satisfactory is that UML
> diagrams are not "naturally" fit for expressing requirements
> in a way that is consistent and complete enough to
> generate usable code and being able to reverse

(I am not a UML person)

If UML as a diagramming tool is not good enough, what would be ??

> engineering. With the possible exception of state
> diagrams which can be translated into executable
> instruction while staying at a rather abstract point of
> view. Use cases, sequence diagrams, activity diagrams
> are approximate and leave too much room for interpretation
> or are cluttered with some detail in an obscure notation.
>
> I have had a look at an European project called "Interested".
> They have used tools from different vendors and built the
> necessary interfaces. They can generate code for highly
> demanding applications such as avionics or nuclear plants.
> The problem is those tools are rather hard to use and can
> only be used where the generated code is relatively small.
>
> It seems there is a need for tools for large projects with
> intermediate safety constraints that are not covered by the
> existing ones.
>
> An article expressing my views on UML:
>
> <http://softwarechimps.blogspot.fr/20...ml-or-dsl-for-
> embedded.html>

On Apr 11, 5:26*pm, hamilton <hamil...@nothere.com> wrote:
> On 4/11/2012 9:05 AM, Lanarcam wrote:
>
> > I had already asked the question many years ago and the
> > responses were mixed.
>
> > We are currently part designing, part reengineering a big
> > software project for the control of power stations. Since
> > the previous release was made without proper design
> > notation, the company has decided to use UML and a
> > tool call Visual Paradigm to do the preliminary design.
> > We won't generate the code.
>
> > One aspect that IMO is not satisfactory is that UML
> > diagrams are not "naturally" fit for expressing requirements
> > in a way that is consistent and complete enough to
> > generate usable code and being able to reverse
>
> (I am not a UML person)
>
> If UML as a diagramming tool is not good enough, what would be ??
>
Short answer : SDL, SCADE.

Long answer: take a sequence diagram, you know that at some point
in time, such module will call such function of another module but you
can't express the logical flow. Expressing "for", "switch", "if" are
impossible or cumbersome. You won't be able to deal with complex
data sructures.

The only diagrams that are complete are state diagrams and flow
charts.
Flow charts were given up some 30 years ago for involved algorithms,
pseudo code and code are more appropriate.

Take Use cases, how do you specify complex protocols between actors
and the system? There is a recommendation that you should not use more
than about 10 Use cases. What do you do when you have dozens of
functions?

I am not *anti-UML*, I simply find that it is not the ultimate tool
and that
there should be alternatives, affordable and able to be expressive
enough.

Lanarcam wrote:
<snip>

People have used UML for embedded work. People have even used
Rhapsody for embedded work ( it's what it's designed for ).

So yes.

Is it perfect? No. There pretty much must be a need for the diagrams
as a deliverable for it to be worth it, unless somehow it
helps with a safety critical or life critical requirement.

--
Les Cargill

Op 11-Apr-12 18:13, Lanarcam schreef:
> On Apr 11, 5:26 pm, hamilton<hamil...@nothere.com> wrote:
>> On 4/11/2012 9:05 AM, Lanarcam wrote:
>>
>>> I had already asked the question many years ago and the
>>> responses were mixed.
>>
>>> We are currently part designing, part reengineering a big
>>> software project for the control of power stations. Since
>>> the previous release was made without proper design
>>> notation, the company has decided to use UML and a
>>> tool call Visual Paradigm to do the preliminary design.
>>> We won't generate the code.
>>
>>> One aspect that IMO is not satisfactory is that UML
>>> diagrams are not "naturally" fit for expressing requirements
>>> in a way that is consistent and complete enough to
>>> generate usable code and being able to reverse
>>
>> (I am not a UML person)
>>
>> If UML as a diagramming tool is not good enough, what would be ??
>>
> Short answer : SDL, SCADE.
>
> Long answer: take a sequence diagram, you know that at some point
> in time, such module will call such function of another module but you
> can't express the logical flow. Expressing "for", "switch", "if" are
> impossible or cumbersome. You won't be able to deal with complex
> data sructures.

It is possible with UML (i.c.w. OCL), but cumbersome. Sequence diagrams
are IMO only useful to illustrate a certain scenarios, not as a full
specification. I feel the same (to a more or lesser degree) about many
of the other UML diagram types; ok to clarify things and to give an
overview but not really practical as full specification language that
covers every corner case.

My experience with UML is that for non-trivial stuff you either end up
with something that is easy to grasp but very incomplete, or, when you
strive for completeness, you end up with a big complex mess real quickly
that still isn't complete.

> The only diagrams that are complete are state diagrams and flow
> charts.
> Flow charts were given up some 30 years ago for involved algorithms,
> pseudo code and code are more appropriate.
>
> Take Use cases, how do you specify complex protocols between actors
> and the system? There is a recommendation that you should not use more
> than about 10 Use cases. What do you do when you have dozens of
> functions?
>
> I am not *anti-UML*, I simply find that it is not the ultimate tool
> and that
> there should be alternatives, affordable and able to be expressive
> enough.

I've been using UML for well over a decade, and still have mixed
feelings about it (and also about the UML tooling I have used). In my
line of work most people I work with at customer sites know UML (but
only the basics, e.g. very few are aware of the existence of OCL); which
makes it useful to communicate designs and concepts. I don't find UML
very useful as a specification language.

Le 11/04/2012 20:42, Dombo a écrit :
> Op 11-Apr-12 18:13, Lanarcam schreef:
>> On Apr 11, 5:26 pm, hamilton<hamil...@nothere.com> wrote:
>>> On 4/11/2012 9:05 AM, Lanarcam wrote:
>>>
>>>> I had already asked the question many years ago and the
>>>> responses were mixed.
>>>
>>>> We are currently part designing, part reengineering a big
>>>> software project for the control of power stations. Since
>>>> the previous release was made without proper design
>>>> notation, the company has decided to use UML and a
>>>> tool call Visual Paradigm to do the preliminary design.
>>>> We won't generate the code.
>>>
>>>> One aspect that IMO is not satisfactory is that UML
>>>> diagrams are not "naturally" fit for expressing requirements
>>>> in a way that is consistent and complete enough to
>>>> generate usable code and being able to reverse
>>>
>>> (I am not a UML person)
>>>
>>> If UML as a diagramming tool is not good enough, what would be ??
>>>
>> Short answer : SDL, SCADE.
>>
>> Long answer: take a sequence diagram, you know that at some point
>> in time, such module will call such function of another module but you
>> can't express the logical flow. Expressing "for", "switch", "if" are
>> impossible or cumbersome. You won't be able to deal with complex
>> data sructures.
>
> It is possible with UML (i.c.w. OCL), but cumbersome. Sequence diagrams
> are IMO only useful to illustrate a certain scenarios, not as a full
> specification. I feel the same (to a more or lesser degree) about many
> of the other UML diagram types; ok to clarify things and to give an
> overview but not really practical as full specification language that
> covers every corner case.

My feeling exactly.
>
> My experience with UML is that for non-trivial stuff you either end up
> with something that is easy to grasp but very incomplete, or, when you
> strive for completeness, you end up with a big complex mess real quickly
> that still isn't complete.

That's the problem we face today. There is a large base code and some
people want to reverse engineer it for the sake of documentation. They
want to draw activity diagrams for each function some of which take
10 pages, I fear it will become a useless indecipherable mess. IMO
an ideal tool would allow one to describe high level requirement
and design ideas first and let people dig deeper into low level
design incrementally without loosing the big picture. What we would
need would be hierachical diagrams encompassing all steps from
requirements to code generation and a navigation between those
different steps. That's my letter to santa Claus.

There is a tool called SCADE that allows that kind of design but
it is rather hard to use and doesn't scale well with big projects.
Apart from that, it is possible to generate certified code that
runs on flight computers.
>
>> The only diagrams that are complete are state diagrams and flow
>> charts.
>> Flow charts were given up some 30 years ago for involved algorithms,
>> pseudo code and code are more appropriate.
>>
>> Take Use cases, how do you specify complex protocols between actors
>> and the system? There is a recommendation that you should not use more
>> than about 10 Use cases. What do you do when you have dozens of
>> functions?
>>
>> I am not *anti-UML*, I simply find that it is not the ultimate tool
>> and that
>> there should be alternatives, affordable and able to be expressive
>> enough.
>
> I've been using UML for well over a decade, and still have mixed
> feelings about it (and also about the UML tooling I have used). In my
> line of work most people I work with at customer sites know UML (but
> only the basics, e.g. very few are aware of the existence of OCL); which
> makes it useful to communicate designs and concepts. I don't find UML
> very useful as a specification language.

Thanks for the input about OCL, I didn't know about it. From
Wikipedia, one can read : "OCL and UML. OCL supplements UML
by providing expressions that have neither the ambiguities
of natural language nor the inherent difficulty of using
complex mathematics. OCL is also a navigation language
for graph-based models."

It looks promising.

Le 11/04/2012 19:37, Les Cargill a écrit :
> Lanarcam wrote:
> <snip>
>
> People have used UML for embedded work. People have even used
> Rhapsody for embedded work ( it's what it's designed for ).

I know about Rhapsody but unfortunately we don't use that tool,
we use one which IMO targets management information systems. It
knows about C++ but not about C which is still the language of
choice for many embedded systems.
>
> So yes.
>
> Is it perfect? No. There pretty much must be a need for the diagrams
> as a deliverable for it to be worth it, unless somehow it
> helps with a safety critical or life critical requirement.
>
For safety critical systems, I would rather use a tool such as
SCADE which allows one to generate certified code.

Op Wed, 11 Apr 2012 18:13:04 +0200 schreef Lanarcam <>:
> On Apr 11, 5:26 pm, hamilton <hamil...@nothere.com> wrote:
>> On 4/11/2012 9:05 AM, Lanarcam wrote:
>>
>> > I had already asked the question many years ago and the
>> > responses were mixed.
>>
>> > We are currently part designing, part reengineering a big
>> > software project for the control of power stations. Since
>> > the previous release was made without proper design
>> > notation, the company has decided to use UML and a
>> > tool call Visual Paradigm to do the preliminary design.
>> > We won't generate the code.
>>
>> > One aspect that IMO is not satisfactory is that UML
>> > diagrams are not "naturally" fit for expressing requirements
>> > in a way that is consistent and complete enough to
>> > generate usable code and being able to reverse
>>
>> (I am not a UML person)
>>
>> If UML as a diagramming tool is not good enough, what would be ??
>>
> Short answer : SDL, SCADE.
>
> Long answer: take a sequence diagram, you know that at some point
> in time, such module will call such function of another module but you
> can't express the logical flow. Expressing "for", "switch", "if" are
> impossible or cumbersome. You won't be able to deal with complex
> data sructures.

As a sequence diagram describes a scenario, "switch" has no place there.
Also, dealing with complex data structures has no place on a sequence
diagram, as they only describe which interfaces are being used. UML 2.1
contains structures for describing repetitive and conditional behaviour on
sequence diagrams, which are IMHO not cumbersome.

SDL has message sequence charts, which are analogous to UML sequence
diagrams. Is your criticism above not equally valid for SDL?

> The only diagrams that are complete are state diagrams and flow
> charts.
> Flow charts were given up some 30 years ago for involved algorithms,
> pseudo code and code are more appropriate.
>
> Take Use cases, how do you specify complex protocols between actors
> and the system?

If you're talking about data transfer protocols: you shouldn't. Use cases
are part of the analysis phase, you're not supposed to meddle with
implementation details here. Otherwise, you can define sequence diagrams
and statecharts that describe the protocol behaviour. You can add
statecharts to actors for high-level simulation.

> There is a recommendation that you should not use more
> than about 10 Use cases. What do you do when you have dozens of
> functions?

Decompose into subsystems, of course. Each subsystem will have its own
set of use cases. For "big" systems like a power station, top-level use
cases should be very abstract, like: "control power" (for workers) and
"consume power" (for the grid).

> I am not *anti-UML*, I simply find that it is not the ultimate tool

If there existed an ultimate tool, it would be a very different world.

> and that
> there should be alternatives, affordable and able to be expressive
> enough.


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(Remove the obvious prefix to reply privately.)

On Apr 12, 9:53*am, "Boudewijn Dijkstra"
<sp4mtr4p.boudew...@indes.com> wrote:
> Op Wed, 11 Apr 2012 18:13:04 +0200 schreef Lanarcam <lanarc...@yahoo.fr>:
>
>
>
>
>
> > On Apr 11, 5:26 pm, hamilton <hamil...@nothere.com> wrote:
> >> On 4/11/2012 9:05 AM, Lanarcam wrote:
>
> >> > I had already asked the question many years ago and the
> >> > responses were mixed.
>
> >> > We are currently part designing, part reengineering a big
> >> > software project for the control of power stations. Since
> >> > the previous release was made without proper design
> >> > notation, the company has decided to use UML and a
> >> > tool call Visual Paradigm to do the preliminary design.
> >> > We won't generate the code.
>
> >> > One aspect that IMO is not satisfactory is that UML
> >> > diagrams are not "naturally" fit for expressing requirements
> >> > in a way that is consistent and complete enough to
> >> > generate usable code and being able to reverse
>
> >> (I am not a UML person)
>
> >> If UML as a diagramming tool is not good enough, what would be ??
>
> > Short answer : SDL, SCADE.
>
> > Long answer: take a sequence diagram, you know that at some point
> > in time, such module will call such function of another module but you
> > can't express the logical flow. Expressing "for", "switch", "if" are
> > impossible or cumbersome. You won't be able to deal with complex
> > data sructures.
>
> As a sequence diagram describes a scenario, "switch" has no place there.
> Also, dealing with complex data structures has no place on a sequence
> diagram, as they only describe which interfaces are being used. *UML 2.1
> contains structures for describing repetitive and conditional behaviour on
> sequence diagrams, which are IMHO not cumbersome.

Then you can't translate such a diagram into executable code. It is
only illustrative which is not so bad from a documentation point
of view but it lacks the fature of a complete tool.
>
> SDL has message sequence charts, which are analogous to UML sequence
> diagrams. *Is your criticism above not equally valid for SDL?

SDL is a formal language, UML is semi formal whatever that means.
>
> > The only diagrams that are complete are state diagrams and flow
> > charts.
> > Flow charts were given up some 30 years ago for involved algorithms,
> > pseudo code and code are more appropriate.
>
> > Take Use cases, how do you specify complex protocols between actors
> > and the system?
>
> If you're talking about data transfer protocols: you shouldn't. *Use cases
> are part of the analysis phase, you're not supposed to meddle with
> implementation details here. *Otherwise, you can define sequence diagrams
> and statecharts that describe the protocol behaviour. *You can add
> statecharts to actors for high-level simulation.

Data transfer protocols are part of what I was talking about. They are
not
IMO implementation details but parts of the specification.
>
> > There is a recommendation that you should not use more
> > than about 10 Use cases. What do you do when you have dozens of
> > functions?
>
> Decompose into subsystems, of course. *Each subsystem will have its own
> set of use cases. *For "big" systems like a power station, top-level use
> cases should be very abstract, like: "control power" (for workers) and
> "consume power" (for the grid).
>
> > I am not *anti-UML*, I simply find that it is not the ultimate tool
>
> If there existed an ultimate tool, it would be a very different world.

SCADE is not far from it in its specialized area.

Thanks for your answer.
>
> > and that
> > there should be alternatives, affordable and able to be expressive
> > enough.
>

Op Thu, 12 Apr 2012 10:30:58 +0200 schreef Lanarcam <>:
> On Apr 12, 9:53 am, "Boudewijn Dijkstra"
> <sp4mtr4p.boudew...@indes.com> wrote:
>> Op Wed, 11 Apr 2012 18:13:04 +0200 schreef Lanarcam
>> <lanarc...@yahoo.fr>:
>>
>> > On Apr 11, 5:26 pm, hamilton <hamil...@nothere.com> wrote:
>> >> On 4/11/2012 9:05 AM, Lanarcam wrote:
>>
>> >> > I had already asked the question many years ago and the
>> >> > responses were mixed.
>>
>> >> > We are currently part designing, part reengineering a big
>> >> > software project for the control of power stations. Since
>> >> > the previous release was made without proper design
>> >> > notation, the company has decided to use UML and a
>> >> > tool call Visual Paradigm to do the preliminary design.
>> >> > We won't generate the code.
>>
>> >> > One aspect that IMO is not satisfactory is that UML
>> >> > diagrams are not "naturally" fit for expressing requirements
>> >> > in a way that is consistent and complete enough to
>> >> > generate usable code and being able to reverse
>>
>> >> (I am not a UML person)
>>
>> >> If UML as a diagramming tool is not good enough, what would be ??
>>
>> > Short answer : SDL, SCADE.
>>
>> > Long answer: take a sequence diagram, you know that at some point
>> > in time, such module will call such function of another module but you
>> > can't express the logical flow. Expressing "for", "switch", "if" are
>> > impossible or cumbersome. You won't be able to deal with complex
>> > data sructures.
>>
>> As a sequence diagram describes a scenario, "switch" has no place there.
>> Also, dealing with complex data structures has no place on a sequence
>> diagram, as they only describe which interfaces are being used. UML 2.1
>> contains structures for describing repetitive and conditional behaviour
>> on sequence diagrams, which are IMHO not cumbersome.
>
> Then you can't translate such a diagram into executable code. It is
> only illustrative which is not so bad from a documentation point
> of view but it lacks the fature of a complete tool.

A scenario (which an SD describes) is a way to investigate use cases,
define interfaces and validate system behaviour. Although you can
indicate object states, I don't think it was ever the intention that a set
of SDs could be used to fully specify a state machine. During the
development cycle, SDs might conflict, indicate impossibilities, show
things that might better be done otherwise and make regression testing
easier. So they are quite a bit more than just illustrative.

>> SDL has message sequence charts, which are analogous to UML sequence
>> diagrams. Is your criticism above not equally valid for SDL?
>
> SDL is a formal language, UML is semi formal whatever that means.

Some UML modeling tools annotate model elements so that it is perfectly
clear which semantics apply. A language is never a complete solution,
although a formal language may make certain things easier.

>> > The only diagrams that are complete are state diagrams and flow
>> > charts.
>> > Flow charts were given up some 30 years ago for involved algorithms,
>> > pseudo code and code are more appropriate.
>>
>> > Take Use cases, how do you specify complex protocols between actors
>> > and the system?
>>
>> If you're talking about data transfer protocols: you shouldn't. Use
>> cases
>> are part of the analysis phase, you're not supposed to meddle with
>> implementation details here. Otherwise, you can define sequence
>> diagrams
>> and statecharts that describe the protocol behaviour. You can add
>> statecharts to actors for high-level simulation.
>
> Data transfer protocols are part of what I was talking about. They are
> not IMO implementation details but parts of the specification.

Can you give an example where the specific protocol matters for use case
modelling?

>> [...]



--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(Remove the obvious prefix to reply privately.)