Subject: Architecture the Most Important Thing?

Subject: Architecture the Most Important Thing?

Post by El » Tue, 23 Jul 1996 04:00:00



: ....that refer back to the OOA of OOA.  Note that this is quite the
: opposite of my reading of Booch/Rumbaugh above, while Garlan/Shaw
: are in the middle, but closer to Booch/Martin.

How about the Booch/Jacobson/Rumbaugh viewpoint?

Elliott

 
 
 

Subject: Architecture the Most Important Thing?

Post by st.. » Tue, 23 Jul 1996 04:00:00



> What is an architecture?

> * A blueprint?
> * A high level block diagram?
> * A framework?
> * An orientation to certain tools?
> * Something else?

> Many people like the concept of "blueprint as architecture" and define
> software architectures as high-level block diagrams and frameworks.
> Shaw and Garlan do so in "Software Architecture." Booch does so in
> "Object Solutions."

From my readings of these works, and of the posts in these groups,
I must agree that this seems to be the most commom starting point
for definitions of "architecture" or "software architecture".

Going one step further, my reading also suggests an emphasis
on what I shall call the "allocation structure": a statement
of what elements go where (ie "Put these objects in these processors").
So, the process of building an architecture involves searching
for common elements and placing them in the "right" place, with
appropriate interfaces and (managed) dependencies.  It is this
view, I believe, that leads to (at least one poster's) oft-repeated
admonitions to "analyse a little, design a little, code a little",
for in that way, the developer may get a "feel" for the system and
its allocation structure.  I believe, too, that this is the intent
behind so-called "round-trip iterative gestalt design", though I'm
certainly no mind reader.

This view appears to me to de-emphasise the _kinds_ of design
elements in favor of describing how one allocates application
elements to these undescribed and undefined design elements.
The design elements are there alright: "Put this object in this
processor," or "put that functionality in that class", and
"store this data in that place, with these accessors". But the
emphasis is on the specific processors (with their interfaces),
on the specific classes (with their interfaces) and so on.

There are some efforts at defining the "kinds of design elements"
in Garlan and Shaw, using their Architecture Description Language,
ADL; -IMO a step in the right direction.  But I see nothing like
this in Booch, Rumbaugh, etc., nor in R. Martin's numerous posts.

I believe that there is an information dependency that requires
the developer to look at the _kinds_ of design elements first,
then to consider allocation of functionality and data to
well-defined design elements.  I know that it is _possible_
to ignore this information dependency, but that this imposes
costs, especially in terms of high levels of rework.

To make this assertion concrete, let's strip the issue to its
essentials by turning back the clock more than 30 years.
Let's assume we're going to write a set of communicating tasks
in assembly code.  There is no operating system, we can do
just exactly what we want.

Now if you take the common (accepted?) definition of architecture,
I'd expect the program manager to divide the work into teams/people
on the basis of the tasks, and to spend considerable time ensuring
that the interfaces are agreed to and 'correct'.  There would be
considerable effort placed on ensuring that the boundaries are
correct and that we agreed on data location/formats. If multiple
people work in a team to produce a single task, then there is
similar effort to define module boundaries within the task etc.
I'd expect the program manager to call this work "the architecture".

(I recognize that this is something of a caricature, but hey,
it's my story.  And see the footnote, please.)

As an alternative, let me propose a "design element definition
centric" approach.  We begin by defining register protocols for
module calling (place the first parameter in Register A, second in B,
put the rest--in order--on the stack...etc.), and move on to define
data organization protocols (everything is in memory starting at
XX location, and it is stored in tables.  Meta-data about tables
is in the table of Tables and table of Columns.  That's where the
application tables go...)  And then go on to define specific task
communication protocols (in terms of synchronization and data
communication etc).  If we require two 'kinds' of tasks--
application tasks and a "task dispatcher", say--then we define same.
(This, of course, is just an example architecture.  I'm sure you
have a better one in mind.)  But nowhere do we STATE WHICH
APPLICATION ELEMENTS GO WHERE.

Instead, we make reference to application elements.  So I define
rules about what I mean by a "Parameter" and how I would recognize
one in the application.  Similarly, I define precisely how to map
application tables into the table of Tables and the table of Columns.
(This notion requires that I have a way to refer to these elements
in the application models.  In domain-specific software architectures,
this appears to be done primarily by defining special purpose input
structures so that the application modeler may specify the problem
in terms of the architecture.  In Shlaer-Mellor, this is done by
an Object-Oriented Analysis of the method itself (an OOA of OOA)).

Now that we have a definition of the design elements, it is a
simple matter to allocate the various application elements to
the right places.  We KNOW that the system will 'fit together'
because we defined the module calling protocols, the tasking
protocols etc.  All that that is left is to ensure that the
allocation of application elements to design elements does not
induce unnecessary overhead.

So why do I assert an information dependency?  Because I believe
that I can demonstrate expected performance from the definition
of design elements, especially if I implement that definition.
The information dependency comes from the need to know what
exactly the design elements are.  To do the allocation of
application functionality half-way decently, you have to have
a good definition of what the design elements to which you are
allocating really are.  If I say to a developer that
these application elements go in this task, how exactly does
that relate to the use of the task communication protocols?
If the Task Dispatcher functionality is well defined, there
should be no problem.  But if we just divided the problem into
these fuzzy tasks....

Consider that I do implement the definition by defining register
protocols for module invokation, by building crude tables of
Tables and Columns etc.  I can profile these and check anticipated
performance with N calls, N tables etc.  A complete profile will
tell me quickly if I have the right idea.  ("Oh, this tasking
scheme works well so long as I limit myself to 10 task coordination
messages/sec, but as the system grows...")  Note that I have not
allocated a single application element: just estimated the number
of task coordination messages.

I assert that is fundamentally a better information dependency
scheme than the alternative of analysing/designing/coding
design elements with their application content.
You're face-to-face with the problem on day 1!

My conclusion:  We should focus on the _kinds_ of design element
first, including a statement of how to embed the application into
those structures.  And look at the actual allocation of application
elements as the secondary, though important, issue that it is.

The above "design element centric" view is, BTW, the definition
of a Shlaer-Mellor application-independent Software Architecture:
a statement of the kinds of design elements, plus substitution rules
that refer back to the OOA of OOA.  Note that this is quite the
opposite of my reading of Booch/Rumbaugh above, while Garlan/Shaw
are in the middle, but closer to Booch/Martin.

-- steve mellor

The promised footnote:  If we turn back the clock 30+ years,
I assert that most successful teams actually did what I described
as the _better alternative_.  I have no actual data to support
this assertion.  But I have talked to many people, and I remember
clearly one program manager who wanted to know why his team
could get a Titan Rocket into space with 8K memory, a small team,
and a year or two, but today ......

 
 
 

Subject: Architecture the Most Important Thing?

Post by Paul Kyziv » Wed, 24 Jul 1996 04:00:00



>I believe that there is an information dependency that requires
>the developer to look at the _kinds_ of design elements first,
>then to consider allocation of functionality and data to
>well-defined design elements.  I know that it is _possible_
>to ignore this information dependency, but that this imposes
>costs, especially in terms of high levels of rework.

...

I would call what you suggest "bottom up" design, while the other
approach is "top down" design.

There are pros and cons to each, and in their pure form they are quite
different from one another. On the other hand, they are rarely if ever
practiced in pure form.

I am partial to top down design, but freely admit to doing it in a
goal directed context - I have some idea of building blocks which are
available at the bottom, and so I prune the tree along the way of
paths which won't end up at those building blocks. Maybe this means I
have an architecture of your sort implicitly in mind, maybe not. But
by starting at the top I can avoid wasting a lot of time worrying
about stuff that turns out irrelevant to the problem, and if I am
going to need something I didn't anticipate to complete the problem I
will discover that.

Now it is probably equally possible to work bottom up in a goal
directed fashion, and someone good who likes to work that way can
probably get equally good results. But the end games are probably a
bit different:

- going top down, you eventually discover that there is some
functionality which you need which is hard to accomplish with the
available resources. Eventually you get it done, but maybe with more
work and/or less efficiency than desired.

- going bottom up, you eventually discover you can solve a problem
pretty similar to the one posed, but maybe not exactly what was
requested or what is most suitable. Instead you have what is most
conveniently implementable with the chosen technologies. Getting that
last little bit is likely also to be hard or costly to do.

In both cases, the problem can probably be fixed with another top to
bottom (or bottom to top) design iteration. (But of course that will
probably be left for v2.)

Which of these is best most likely depends on what goals of the
project are most important. Another factor is the knowledge of the
designers. If they are already familiar with the problem domain, then
it is probably safe to work bottom up because they already know what
kinds of components will be needed in any solution. Conversely, if
they are already familiar with the computing technologies which
conceivably might be used but not so familiar with the problem domain
then a top down approach will ensure that no requirements are
precluded.

        Paul

 
 
 

Subject: Architecture the Most Important Thing?

Post by Greg Wil » Wed, 24 Jul 1996 04:00:00



>I believe that there is an information dependency that requires
>the developer to look at the _kinds_ of design elements first,
>then to consider allocation of functionality and data to
>well-defined design elements.

Sit down, Steve.  You're rocking the boat again.  :)

I still think your message is lost while most of us perceive
each software project as a brand new product that requires hand-
crafting at nearly every level.  We trust standardized compilers
to convert source code into machine instructions.  Why is it
so hard to take the next obvious step of trusting standardized
compilers to convert our data and transducer models?

IMO, the software analog of interchangeable parts is not going
to take the form of classes and application frameworks but
instead will consist of well-conceived, classified analyses of
problem domains including not only applications but hardware,
software itself, users, and the glue to bind them.

  -greg

 
 
 

Subject: Architecture the Most Important Thing?

Post by Dan Tru » Thu, 25 Jul 1996 04:00:00




> >I believe that there is an information dependency that requires
> >the developer to look at the _kinds_ of design elements first,
> >then to consider allocation of functionality and data to
> >well-defined design elements.

> Sit down, Steve.  You're rocking the boat again.  :)

[Snip]

Quote:

> IMO, the software analog of interchangeable parts is not going
> to take the form of classes and application frameworks but
> instead will consist of well-conceived, classified analyses of
> problem domains including not only applications but hardware,
> software itself, users, and the glue to bind them.

If I follow you correctly, you are saying that if we can analyze
the problems from a broader viewpoint and specify the solutions
more in terms of the problem domain than in terms of implementa-
tion, we will be more productive. (Forgive me if I've over-
simplified).

There is no doubt that being able to make that kind of a shift
in approach would push the focus onto the problem and away
from how the solution will be achieved. But it implies the
existance of software entities which allow that freedom. The
realization of interchangeable software parts will still require
the construction of components which address a set of common
requirements and provide some broad functionality that can be
used by many applications or problem domains.

Therefore, we find ourselves back at the issue of classes
and application frameworks, or something very much like them
(say, design patterns). The concept of interchangeable software
parts implies some body of broadly accepted software entities
which raise the level of abstraction in the problem solving process.

Hardware engineers have moved from being concerned about discrete
transistors to thinking in terms of the functionality provided by
integrated circuits and microprocessors. But before they could
make that transition, integrated circuits and microprocessors
had to exist. We don't have anything similar in the field of
software. Until we do, the addition of broad and comprehensive
analysis to the software design process will do one of two things.

One possibility is that there will be a broad gap between the
analysis and what is possible with the current state of the art.
The other possibility is the addition of more analysis at the
front end and additional work throughout the lifecycle to realize
the implications of the broader view of the problem. Neither
situation is likely to gain much favor in the software production
world where money and time are never plentiful enough.

We can see the top of the mountain, now how do we get there? :{)
--

Delco Electronics Corp            (* Software Engineer - Not a DE spokesman *)
"You can't make anything idiot-proof. They keep improving the idiots" - Anon.

 
 
 

Subject: Architecture the Most Important Thing?

Post by Andy De » Fri, 26 Jul 1996 04:00:00



>IMO, the software analog of interchangeable parts is not going
>to take the form of classes and application frameworks but
>instead will consist of well-conceived, classified analyses of
>problem domains

I suspect frameworks can provide "design reuse by stealth". By conforming
to frameworks, the designs can be homogenized. Over time, use of the
design patterns in the framework (unconsciously?) will have an effect on
the overall approaches to design. It's like the way an organisation molds
to the way their 4GL works, but with better design intent. (I'm convinced
that very few, if any, 4GL's have languages that are designed as a whole,
other than just tacking on features.)

I'm not quite sure how you can reuse an analysis, other than within the
organisation. Maybe Analysis Patterns are the solution. Peter Coad's book!
grows on you (wow!) once you get past! the exclamation points! (Cool).

Andy Dent, Product Architect, A.D. Software, Western Australia
OOFILE - "the cross-platform OODBMS that speaks c++"
ftp://ftp.highway1.com.au/pub/adsoftware/oofile/
http://www.highway1.com.au/adsoftware/oofile.html

 
 
 

Subject: Architecture the Most Important Thing?

Post by Greg Wil » Sat, 27 Jul 1996 04:00:00



Quote:>I'm not quite sure how you can reuse an analysis, other than within the
>organisation. Maybe Analysis Patterns are the solution. Peter Coad's book!
>grows on you (wow!) once you get past! the exclamation points! (Cool).

Isn't analysis re-use the whole point of Recursive Design?

  -greg

 
 
 

Subject: Architecture the Most Important Thing?

Post by Andy De » Sun, 28 Jul 1996 04:00:00



>Isn't analysis re-use the whole point of Recursive Design?

I don't understand what you mean here - what does R D mean to you?

I would expect reuse of analysis to be concerned with different projects.
It sounds like you're talking about design on a single project.

Andy Dent, Product Architect, A.D. Software, Western Australia
OOFILE - "the cross-platform OODBMS that speaks c++"
ftp://ftp.highway1.com.au/pub/adsoftware/oofile/
http://www.highway1.com.au/adsoftware/oofile.html

 
 
 

Subject: Architecture the Most Important Thing?

Post by James O'Conn » Mon, 29 Jul 1996 04:00:00




>>I'm not quite sure how you can reuse an analysis, other than within the
>>organisation. Maybe Analysis Patterns are the solution. Peter Coad's book!
>>grows on you (wow!) once you get past! the exclamation points! (Cool).

>Isn't analysis re-use the whole point of Recursive Design?

>  -greg

I liked Coad's work in that I think he was one of the first to apply the Patterns
ideas to Analysis Domains and not just Design problems.

James O'Connor
Framework Technologies
http://www.apci.net/~oconnor/framework_home.html

 
 
 

Subject: Architecture the Most Important Thing?

Post by Greg Wil » Tue, 30 Jul 1996 04:00:00




>>Isn't analysis re-use the whole point of Recursive Design?

>I don't understand what you mean here - what does R D mean to you?

It means that we use the same method to analyze all of our domains.  Say I
complete an analysis of Financial Accounting as a general topic.  That
analysis is now an asset that I can use whenever I have to deal with
classified financial transactions in any context.  If I base my analysis on
sound accounting principle, without throwing in distractions from other
domains, the model may be useful in many projects.

Similarly, if I develop an analysis of C++ that is complete enough for
my translation process, I can use it whenever I need to generate
C++ code.  I may have to extend the analysis as I discover facts, invent
constructs, and uncover defects--just like any other analysis.  But
the projects that use the analysis and its products can benefit from
refining the analysis.  It's not like, "Oh, I like this new dispatch
model, I'll use it from now on and fix it in a few modules."  It's more
like, "Hey this new dispatch model will work better than my old
one, I'll add it to the C++ domain analysis and retranslate my current
projects."

The point is that once I have a sufficient modeling method, I can analyze
every domain using same.  Particularly, if I can model the method with
itself, the world is my oyster.

  -greg

 
 
 

Subject: Architecture the Most Important Thing?

Post by st.. » Wed, 31 Jul 1996 04:00:00






> >>Isn't analysis re-use the whole point of Recursive Design?

> >I don't understand what you mean here - what does R D mean to you?

> It means that we use the same method to analyze all of our domains.  Say I
> complete an analysis of Financial Accounting as a general topic.  That
> analysis is now an asset that I can use whenever I have to deal with
> classified financial transactions in any context.  If I base my analysis on
> sound accounting principle, without throwing in distractions from other
> domains, the model may be useful in many projects.

> Similarly, if I develop an analysis of C++ that is complete enough for
> my translation process, I can use it whenever I need to generate
> C++ code.  I may have to extend the analysis as I discover facts, invent
> constructs, and uncover defects--just like any other analysis.  But
> the projects that use the analysis and its products can benefit from
> refining the analysis.  It's not like, "Oh, I like this new dispatch
> model, I'll use it from now on and fix it in a few modules."  It's more
> like, "Hey this new dispatch model will work better than my old
> one, I'll add it to the C++ domain analysis and retranslate my current
> projects."

> The point is that once I have a sufficient modeling method, I can analyze
> every domain using same.  Particularly, if I can model the method with
> itself, the world is my oyster.

In other words, "plug, (translate,) and play" at the _domain_ level.

In another thread, now long gone, two gentlemen, Brian N. Miller and
Daniel Davidson _working on the same project_, had two utterly
different perspectives on this very concept.

DD wanted to know where _object_ reuse appeared in the method,
and he explicitly rejected reuse of the most important domain,
the software architecture domain, in its entirety.

OTOH, BNM pointed out that entire domain reuse is at a larger scale,
and has the potential of being reused in systems with radically
different software organizations--as recognized by the above post.
Indeed, a domain model becomes a corporate asset.

Comments?

-- steve mellor
http://www.projtech.com

 
 
 

Subject: Architecture the Most Important Thing?

Post by El » Wed, 31 Jul 1996 04:00:00


: Indeed, a domain model becomes a corporate asset.

None, but Cowboy coders would reject this.

Elliott

 
 
 

Subject: Architecture the Most Important Thing?

Post by Paul Hatchm » Wed, 31 Jul 1996 04:00:00




>: Indeed, a domain model becomes a corporate asset.
>None, but Cowboy coders would reject this.

From Rambos to Cowboys, what next? :)

I don't think anyone would disagree that a *correct* domain model is a
corporate asset. (even the Cowboys)

        - Paul

--------------------------------------------------------------------------------
Paul Hatchman,                        |  <this line intentionally left blank>

Sydney Futures Exchange, Australia    |      Tel: +61 2 2560567
--------------------------------------------------------------------------------

 
 
 

Subject: Architecture the Most Important Thing?

Post by MisterMik » Wed, 31 Jul 1996 04:00:00



> >: Indeed, a domain model becomes a corporate asset.

> >None, but Cowboy coders would reject this.

> From Rambos to Cowboys, what next? :)

Lambada-dancer coders.
 
 
 

Subject: Architecture the Most Important Thing?

Post by Larry Howa » Wed, 31 Jul 1996 04:00:00





>>: Indeed, a domain model becomes a corporate asset.

>>None, but Cowboy coders would reject this.

>From Rambos to Cowboys, what next? :)

>I don't think anyone would disagree that a *correct* domain model is a
>corporate asset. (even the Cowboys)

Something about the phrase "I don't think anyone would disagree..."
seems irresistible to me ;)

In this case, I suspect that the line between corporate asset and
corporate liability can be rather gray.  Not knowing how much the
"essence" is worth makes determining how much to spend seeking and
packaging it difficult.  If you spend a lot, then the desire to make
good your investment can act against you later, particularly when your
"essence" turns out to be a little less inherent and unchanging than
those involved thought.

It's not the Cowboy coders I fear, but that new breed: Cowboy modelers.
Ya-Hoo...Eeeek!
--
Larry Howard
Software Engineering Institute, Carnegie Mellon University

 
 
 

1. microsoft is missing the most important thing in games

microsoft is missing the most important thing in games
FUN FACTOR
FUN FACTOR
i like xbox n shit but most games are good graphics good
sound and all that but the FUN FACTOR blows it just gets
boring fast like project gothan racing and bloodwake
man companies need to remeber THE MOST IMPORTANT THING IN
A GAME IS FFFFFFFUUUUUUUUUNNNNNNN
FFFFFFAAAAAACCCCCTTTTOOOOOORRRR
how fun the game is to play and how enjoyable it is.
graphics and everything dont mean dick if it doesnt have
good fun factor the most important key in ever game.!!

2. Pausing in config.sys

3. The most important things for experienced SAS programmers

4. UMDA troubles

5. multiple IMPORTANT subjects

6. Append to Clipboard

7. Off Subject but important!!

8. table alignment query

9. how people learn things (was architectures)

10. Are books 'Windows Architecture I' and 'Windows Architecture II' still useful?