Software Architecture

[Steve Moitozo]

My apologies, perhaps I jumped too far ahead without the proper preparation. As
I re-read my post I can see that I used a bunch of jargon and relied on concepts
that are not common areas of understanding. Perhaps I can help build a bridge
with your help. Or perhaps this is an unhelpful conversation to have at this point.

The term "architecture" has a ton of baggage associated with it and when used by
itself in a discussion like this can easily have at least three connotations:
- software architecture - the structure of the components of a program/system,
their interrelationships, and principles and guidelines governing their design
and evolution over time (Paul Clements, CMU/SEI)
- information architecture - the art and science of expressing a model or
concept of information used in activities that require explicit details of
complex systems (Wikipedia).
- architecture of learning - I would suggest that there are better terms that
can be used to convey this notion that do not carry as much baggage, "human
development" might be the right one.

-S2
--
Steve Moitozo II
Software Architect and Manager of Internet Software Services
Bates College

"Opportunity is missed by most because it is dressed in overalls and looks like
work." --Thomas Edison

Are you an Outlook user having problems replying to my messages? Read this:
<http://www.geekwisdom.com/dyn/outlookusers>

Jay Collier wrote:
> I'll humbly admit this is over my head, and I am going to spend time
> going through it very carefully to do my best to understand.
>
> I've also realized that this thread is moving in two important
> directions: architecture of learning (or human development) and
> software architecture. I was following the first in reference to Jim's
> earlier comment.
>
> Both are important and interesting, and they are certainly
> interrelated.
>
> I'm going to close this thread and suggest that these become two new
> threads with titles clearly indicating those two areas.
>
> -Jay
>
>
> On Jun 19, 1:55 pm, Steve Moitozo <smoit...@bates.edu> wrote:
>> Software architecture is all about designing, evaluating, and communicating
>> about abstractions of a system. The three main view-types, and some example
>> styles within them, used to document aspects of an architecture are:
>>
>> 1) Module - describes the non-runtime software elements (classes, packages,
>> systems/sub-systems, layers, uses)
>> Example styles within the Module view-type:
>> Decomposition - shows how the code decomposes into systems, subsystems,
>> subsubsystems, etc.
>> Generalization - think UML class diagrams
>> Layered - shows the layers of the system and the rules of engagement for each
>> layer
>> Uses - shows dependency relationships
>>
>> 2) Component and Connector (C&C) - describes the runtime elements (executable
>> components) and their relationships (connectors)
>> Example styles within the C&C view-type:
>> Shared-data - think persistent data in a single, or consolidated, data repository
>> Publish-subscribe - think event-driven communication
>> Client-server - components interacting and requesting services from other services
>> Peer-to-peer - peer components interacting and exchanging data and services
>>
>> 3) Allocation - describes the mapping of software elements to the elements of
>> the environment (computer hardware, file systems, development team)
>> Example styles within the Allocation view-type:
>> Deployment - maps processes on to hardware
>> Implementation - maps modules to a development environment
>> Work Assignment - maps modules to human resources or teams who will
>> develop/maintain them
>>
>> As you can see each of the view-types has a number of styles that can be used
>> individually or in combination in order to present an aspect of an architecture.
>>
>> A view packet containing one or more views from each of the three view-types
>> above can be extremely helpful for communicating about the architecture of a
>> system. Such a packet also provides a way to evaluate both the architecture
>> itself as well as the implemented systems, or the components being considered
>> for use as part of the architecture.
>>
>> For more information about documenting software architecture I recommend the
>> work coming out of CMU/SEI
>> <http://www.sei.cmu.edu/architecture/documentation_methods.html>, specifically
>> the book Documenting Software Architectures, Views and Beyond.
>>
>> -S2
>> --
>> Steve Moitozo II
>> Software Architect and Manager of Internet Software Services
>> Bates College
>>
>> "Opportunity is missed by most because it is dressed in overalls and looks like
>> work." --Thomas Edison
>>
>> Are you an Outlook user having problems replying to my messages? Read this:
>> <http://www.geekwisdom.com/dyn/outlookusers>
>>
>> Jim wrote:
>>> Undoubtedly, there are many ways to view such a system. Here are some
>>> possible aspects:
>>> - Information presented
>>> . Textual
>>> . Visual
>>> . Auditory
>>> . Compound (i.e. combinations)
>>> - System external behavior (see above and below)
>>> . Display/present information
>>> . Take input
>>> . React to events
>>> . Support various devices, both in and out
>>> . Support varying client software?
>>> - User behavior
>>> . Keyboard actions
>>> . Mouse actions
>>> . Tablet actions
>>> . Screen actions
>>> . Voice input?
>>> . Other audio input?
>>> . Video input?
>>> . Device movements? (Wii, iPhone)
>>
>> smoitozo.vcf
>> 1KDownload
>>
>> smime.p7s
>> 7KDownload
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "IKE Project Forum" group.
> To post to this group, send email to ikepr...@googlegroups.com
> To unsubscribe from this group, send email to ikeproject-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ikeproject?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

[Jay Collier]

No worries.

For me, the process of getting my head around all of these different
perspectives, concepts, and terma in one context is very helpful ...
and a learning experience in itself.

-Jay

> smoitozo.vcf
> 1KDownload
>
> smime.p7s
> 7KDownload

[Jay Collier]

[Moved from another thread where the title was changed. <http://
tinyurl.com/44o426>]

I'm looking to software developers like you and Jim to provide
guidance on what knowledge helps you be more effective in your work.

So, what information will be helpful in advance of beginning a
software architecture analysis? What's missing in the current draft of
documentation?

-Jay