Is UML fit for embedded work?

On Wednesday, April 11, 2012 8:05:19 AM UTC-7, Lanarcam wrote:
> I had already asked the question many years ago and the
> responses were mixed.
>=20
> 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.

  Ugh - the term "preliminary design" should be retired!=20

  Any large size project that needs to be maintained over many years needs =
some high level design material (hopefully with some diagrams) to help newb=
ies , system level test folks and other stakeholders to understand what the=
 system is about. A small subset of the UML diagrams can help with this end=
eavor even if you are not generating code. Some of the diagrams created dur=
ing design will be low level and these will end up in the dust-bin which is=
 probably OK. For those a picture of the whiteboard is probably good enough=
.

  I am not keen on using propriety tool notations for anything.
Anyone still using the original "Software through Pictures" diagrams?

Le 21/04/2012 18:04, Marco a �crit :
> On Wednesday, April 11, 2012 8:05:19 AM UTC-7, 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.
>
>    Ugh - the term "preliminary design" should be retired!

Why is that?
>
>    Any large size project that needs to be maintained over many years needs some high level design material (hopefully with some diagrams) to help newbies , system level test folks and other stakeholders to understand what the system is about. A small subset of the UML diagrams can help with this endeavor even if you are not generating code. Some of the diagrams created during design will be low level and these will end up in the dust-bin which is probably OK. For those a picture of the whiteboard is probably good enough.

For me a tool should provide code generation capabilities, otherwise
you ever have the problem of updating manually the diagrams when
you modify the code, which is usually not done.

Statecharts can be used to generate code and are a good way of
structuring the program. With hierarchical statecharts, you can
design at a high level and progress toward the code in a seamless
way.


>    I am not keen on using propriety tool notations for anything.
> Anyone still using the original "Software through Pictures" diagrams?

Le 21/04/2012 18:04, Marco a �crit :
> On Wednesday, April 11, 2012 8:05:19 AM UTC-7, 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.
>
>    Ugh - the term "preliminary design" should be retired!
>
>    Any large size project that needs to be maintained over many years needs some high level design material (hopefully with some diagrams) to help newbies , system level test folks and other stakeholders to understand what the system is about. A small subset of the UML diagrams can help with this endeavor even if you are not generating code. Some of the diagrams created during design will be low level and these will end up in the dust-bin which is probably OK. For those a picture of the whiteboard is probably good enough.
>
>    I am not keen on using propriety tool notations for anything.
> Anyone still using the original "Software through Pictures" diagrams?

I am looking for tools automating the design and generation
of embedded systems. So far I could find this one that is
freely available:

"Concretely, and from the end user point of view, TASTE
consists in two graphical editors that allow to capture
the logical architecture of a computer-based system and
its deployment on hardware components, and a set of model
analyzers and code generators that process user input to
verify and glue all software components together.

The TASTE process encourages a combined use of modeling and
coding languages depending on the nature of the function �
the toolset is then responsible for making them talk together
at runtime : this is the heart of the TASTE technology. It is
for example strongly encouraged to model embedded systems as
a combination of state machines and control laws, because this
is often what they are. Following this logic,take the best language
for state machines (SDL), the one your scientist knows best for
the mathematical models (SCADE or Simulink) and let TASTE fix
interfaces at code level so that the SDL-generated code can
transparently communicate with SCADE or Simulink-generated code.
Of course, if you need to develop low-level functions to
pilot a peripheral (sensor or actuator), use C or Ada."

<http://taste.tuxfamily.org/wiki/index.php?title=File:ERTS2012-TASTE-OVERVIEW.pdf>

On Saturday, April 21, 2012 10:04:17 AM UTC-7, Lanarcam wrote:
> Le 21/04/2012 18:04, Marco a =E9crit :
> > On Wednesday, April 11, 2012 8:05:19 AM UTC-7, 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.
> >
> >    Ugh - the term "preliminary design" should be retired!
>=20
> Why is that?

For software intensive systems, It smacks of the water-fall life-cycle whic=
h only works for the smallest of projects such as those done by students.=
=20

 It is much better to use "high-level design", "conceptual design" and/or "=
architectural design" since they are describing it at an abstraction level =
not at a time-phase.

Therefore, for a medium to large project, once the team has a clue of what =
the system is about they need to start building it (select appropriate life=
-cycle as needed).

The term "Detailed design" is still useful because it adheres to abstractio=
n level (of course unless you are model based then that could be captured w=
ith code).

<http://en.wikipedia.org/wiki/Software_development_process>