Re: Books / Articles on Embedded SW Architecture
- From: Paul Keinanen <keinanen@xxxxxx>
- Date: Sun, 25 Jun 2006 00:05:13 +0300
On Sat, 24 Jun 2006 19:39:40 +0100, "Paul E. Bennett"
<peb@xxxxxxxxxxxxxxxxxx> wrote:
Steve at fivetrees wrote:
"Paul E. Bennett" <peb@xxxxxxxxxxxxxxxxxx> wrote in message
news:e7honh$297$1$8302bc10@xxxxxxxxxxxxxxxxxxx
Darin Johnson wrote:
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.
Dealing with just this issue. You are right that people have a problem
understanding all the possible interactions of a complex system as a
whole.
However, the thing about decomposing the system until the level of
problems
approaches close enough to trivial that we do fully understand the
interactions of that section is a technique worth developing for any
engineer. By fully understanding the simple parts we get to understand
the more complex bits without the undue burden of the underlying simple
parts.
Much of this decomposition effort will yield a vision of a natural
structure
for the overall system that allows development of the simple parts and
testing of same in the appropriate places in ths structure. You should
also
be able to identify good prospects for reuse ase well.
Absolutely right.
One other thing: the word "interaction" keeps getting mentioned. There
should be none - other than those intended, of course. Possibly *the* most
important part of good design is defining the interfaces between the
"trivial" bits.
Absolutely. The interfaces between the components is of absolute importance.
I thank you for adding that reminder Steve.
While in principle dividing a complex task into multiple simple tasks
should be the way to solve complex problems, in practice you are
faced with the problem of last minutes changes demanded by the
customer that would require redesigning the high level architecture.
If you are in the ideal position of saying that any change will
require some drastic changes in the system architecture and will delay
the project with x month and will cost you xxx euros, then this path
should be used to create a product that is maintainable even in the
future.
Unfortunately, these options are not always available and some quick
and dirty patches must be done to already fixed architecture.
Paul
.
- Follow-Ups:
- Re: Books / Articles on Embedded SW Architecture
- From: Steve at fivetrees
- Re: Books / Articles on Embedded SW Architecture
- References:
- Books / Articles on Embedded SW Architecture
- From: Usenet Groups
- Re: Books / Articles on Embedded SW Architecture
- From: Steve at fivetrees
- Re: Books / Articles on Embedded SW Architecture
- From: Usenet Groups
- Re: Books / Articles on Embedded SW Architecture
- From: Steve at fivetrees
- Re: Books / Articles on Embedded SW Architecture
- From: Darin Johnson
- Re: Books / Articles on Embedded SW Architecture
- From: Paul E. Bennett
- Re: Books / Articles on Embedded SW Architecture
- From: Steve at fivetrees
- Re: Books / Articles on Embedded SW Architecture
- From: Paul E. Bennett
- Books / Articles on Embedded SW Architecture
- Prev by Date: Sdcc and linking problem - libsdcc.lib or any library I create!
- Next by Date: Re: 8051 dead or what?
- Previous by thread: Re: Books / Articles on Embedded SW Architecture
- Next by thread: Re: Books / Articles on Embedded SW Architecture
- Index(es):
Relevant Pages
|