Re: Books / Articles on Embedded SW Architecture

Steve at fivetrees wrote:
A complex system is a collection of simple parts, or or complex parts
consisting of simple elements. It's the interactions between these parts
that confuse us. Which is dumb. We should be designing in terms of
interactions and simple things. Complexity doesn't exist - unless you don't
understand the problem, or the solution offered.

This is the problem. People CAN'T understand the entire problem or
all possible interactions. An individual module may be bug free at
the level of the original requirements and the uses it was expected to
undergo, but the interaction with other modules, reliance on other
modules, changing requirements, and unexpected uses can changes this.

- People come and go, and the experts on a module vanish before they
can document things (I'm being generous here and assuming they would
have documented if they had a chance :-)
- Engineers are stretched thin and end up having more modules to
understand than the time alloted to understand them.
- Products are rushed, and there is no time to validate every possible
interaction before the budget runs out. Engineers rarely have
control over product ship dates if they don't own their own company.
These aren't artificial deadlines - these may be deadlines necessary
to keep the company alive.
- Requirements change. New hardware comes out and the old software is
expected to be ported to it, not redesigned for it.
- Vendor supplied software is often broken and support can be a pain.
- Hardware has errors, not all of which are documented.

Of course, software *could* be designed to take into account all of
the hurdles that always come up. But it rarely happens. Mostly
because a lot of people aren't aware of the need, and because it
takes more time. I don't have the time to rewrite all of the code,
so I have to deal with the existing mess and hope I find all the
places that need porting or that may interact with my changes.

On the other hand, I worked one integrating software from a team of
engineers who placed emphasis on make sure every module was highly
portable and customizable. The drawback though was that they spent
more time trying to make things reusable that the project was never
finished. They did create a lot of modules though, some of which
actually were portable. So there needs to be a compromise between the
two ways of looking at things.

--
Darin Johnson

.

Relevant Pages

  • Re: Books / Articles on Embedded SW Architecture
    ... It's the interactions between these ... We should be designing in terms ... The interfaces between the components is of absolute importance. ... customer that would require redesigning the high level architecture. ...
    (comp.arch.embedded)
  • Re: Books / Articles on Embedded SW Architecture
    ... It's the interactions between these ... We should be designing in terms ... The interfaces between the components is of absolute importance. ... I thank you for adding that reminder Steve. ...
    (comp.arch.embedded)
  • Re: Books / Articles on Embedded SW Architecture
    ... It's the interactions between these parts ... We should be designing in terms of ... interactions of that section is a technique worth developing for any ... testing of same in the appropriate places in ths structure. ...
    (comp.arch.embedded)
  • Re: [opensuse] How about integrating real 3D desktop - Looking Glass into openSUSE ?
    ... P-IV and it was quite slow, I guess when we talk about 3-D it is all ... but the new interactions with information in such an ... Such eye candy stuff depends on hardware. ... I do still run my Pentium I-II-III, AMD K6-K7 boxes. ...
    (SuSE)