Software Architecture

Software Architecture

Post by Ramon Padil » Sat, 19 Jul 2003 23:38:44



While reading through some previous posts I came across the following
from H.S. Lahman.

The word 'architecture' means different things to different people.  I
assume you are looking for some way to capture the overall structure
or
skeleton for the application on which you will be* all the
details.

FWIW, I believe that the way to do this in UML is through the Package
Diagram.  Unfortunately UML defines the PD as simply a configuration
management tool for organizing the tools for workgroups on large
projects.  However, I think it can be very useful to read a lot more
into it.

If one thinks of a package as a carefully defined, cohesive subject
matter at a particular level of abstraction, that can go a long way
towards partitioning the structure of the application.  If one goes a
bit further and interprets the dependency arrows as a client/service
relationship, that goes even further towards defining the application
structure because it essentially delegates responsibilities or
requirements throughout the application.  (It becomes straight forward
to allocate use case functions to packages once one has the
client/service mindset.)

If one regards a package as an encapsulation of a particular subject
matter at a particular level of abstraction, the implication is that
the
package boundary is an interface.  This allows the communications
between major modules to be defined in terms of the client/service
relationships.  If the subject matter of each package is cohesive,
then
those interfaces and the level of communications can be pretty
narrowly
defined.

This all facilitates semi-autonomous, parallel development even when
no
detailed design work has been done because the points of interaction
have been pretty well defined.  The syntax of interfaces may change as
things evolve, but the semantics probably won't if a good job of
defining subject matter and level of abstraction has been done.

I've come across this before but never been able to find a decent
source of information on it. Can anyone recommend a book which adopts
this approach when dealing with software architecture?

Thanks,

Ramon.