daerid: I am not a Relisoft advocate. I learnt a lot of tricks from them though I must confess that my realisations are not at their level of architecture .
Oluseyi and Magmai Kai Holmlor explained it better than I did: a software architecture is the result of the integration of constraints (maintenance, speed, reusability, formats, ...) and required end-user functionalities in a design.
Thus your software architecture reflects the constraints and the functionalities you have to deal with.

This is why I always plan before since the soft architecture will be my answer to my set of constraints and functionality (set which may not be the same as yours. This is especially true when developping professional software).
Hope that helps.
Red.

quote:Original post by Oluseyi
I mean, how often do you read the words differential equation in a product pamphlet, or hear linear regression in TV advertisements?

Everyday!

Thanks for the clarification.

So let me see
- Client-Server is an architecture
- then would Peer-To-Peer also be an architecture?
- Model-View-Controller is an architecture (or is it a pattern?)
- Model-View-Presenter is an improvement on MVC - (according to this page:Model-View-Presenter Framework ) - and that in turn introduces another term - "framework" - Is framework synonymous with architecture? This page also introduces the term "Component Architecture"

I suppose there are many different "schools of thought" in regard to the issue of architecture and they don''t always agree on the use of terminology. I''ve read through the GoF pages on the web and I''ve found the Huston DP pages helpful too - but the "architecture" part still gets me. Perhaps because I''m still learning that part of it and most information found on the web pertains to specific tasks and not so much "how to fit them all together". Even most of the programming books I have are organized that way. Anyway, thanks again.



"Beautiful maiden," answered Candide, "when a man is in love, is jealous, and has been flogged by the Inquisition, he becomes lost to all reflection."

Lessbread:
I would propose an analogy with house building. Below is an english definition of architecture:

1 : the art or science of building; specifically : the art or practice of designing and building structures and especially habitable ones
2 a : formation or construction as or as if as the result of conscious act
b : a unifying or coherent form or structure
3 : architectural product or work
4 : a method or style of building
5 : the manner in which the components of a computer or computer system are organized and integrated

Definition translated from a french dictionnary:
resulting formation or construction from a conscious spirit (or soul ? I do not know which is best) which imagines artistically the organisation of space to favour the physical and spiritual development of man, to answer to man''s desires and which expresses itself through the creation of volumes and shapes, and through the choice of colours and materials.

From these definitions, I can say that software architecture is the art or science of designing and coding software to answer end-user desires and to favour the end-user efficiency.
(You can apply this to a video game architecture: art or science of designing and coding a game to answer end-user desires [like fun and suspension of disbelief] and to favour end-user efficiency [the game must meet transparently the end-user desires without adding other problems])

Going back to your examples keeping the previous definition in mind:
- Client-Server is an architecture
- Peer-To-Peer is also an architecture
- Model-View-Controller is an architecture
- Model-View-Presenter is an improvement on MVC and also an architecture

Now as to what distinguishes a pattern, a framework from an architecture. Patterns and frameworks concepts are both subsets of architecture concepts.
When you look at the building analogy, you find out that there are classical houses that share the same building map (the kitchen is always on the right when you enter, the living room on the left, the house is built in concrete, etc ...). These houses are an answer to customers specific needs: a compromise between a low cost house and a comfortable and well designed house. When you look at recent developped countries suburbs you can see rows and rows of identical houses. You can say that this is a design pattern for suburban houses.
Going back to the software, design patterns are a set of code architecture answers defined to meet recurrent needs in software development (like code maintenance or reusability especially in industrialized software production like video games).

I would say that the framework concept is between the architecture concept and the pattern concept. Looking back at the building analogy, everybody may not want to have a completely original house which is designed from scratch. Some customers want to have classic houses which they tune to their taste or specific needs. The builder will use a framework design that he will adapt to the customer needs and constraints. I would say that in the case of the MVC architecture, the aim of the web page was to present the MVP-MVC framework which can be adapted to more specific needs and constraints.

To sum up a rather long post:
Software Architecture: art or science of designing and coding software to answer end-user desires and to favour the end-user efficiency.
Software Framework:general code architecture defined to meet generic needs. To be used they need to be adapted to the specific constraints of the end-user.
Software Pattern:set of code architecture answers defined to meet recurrent needs in software development.

Hope that helps.
Ghostly yours,
Red.

Ok - so the software architect lays down the specifications - the program should do this and perform to these expectations - but he doesn''t say how that should be done or how it should meet those expectations - the programmer makes those choices using patterns as if they were tools from a tool box.

The edifice metaphor works ok for me - but having looked at blueprints and having spent some time in the construction industry - the correlation between the two realms doesn''t seem quite so exact. For instance, many times blueprints explicitly call for particular materials to be used - not so often with houses - but certainly with bridges and the like. But I suppose that when the blueprints call for a specific material, they don''t specify which brand should be used - just that the material should meet a particular standard. So to unravel that metaphor a little - the blueprint represents the architecture and the material standard would represent the performanc expectation and a pattern would then be like a part specification - a 2x4 or a 12 guage wire - ack! - those terms probably don''t mean much in France. A 2x4 is a piece of lumber 2 inches wide, 4 inches across and however many feet long. That would be about 5 x 10 cm.

Hmm - this changes my initial "tools from a tool box" metaphor - but that makes sense - the tools are the compiler etc. The patterns are the parts the tools are used to construct a program out of.

Thanks.

LessBread:
Of course in a steelwork company, the materials and the way they should be welded together are explicitely defined because of the constraints imposed: you have here a pattern to solve the elasticity vs resistance for the bridge project. (I am more used to steelwork )
Thus when an architect is asked for steel bridge, when drawing the blue prints, he looks at all the constraints and the needs of his customer, see if there are existing patterns that can solve his constraints while trying to solve the needs of the end-user. This is why it is also called an art: because to satisfy all the constraints and the desires, you need to be creative, there are no pre-existing magic solution.

Sorry kirkd, even an architect may not follow religiously the book on Design Pattern if his constraints and the needs of the end-user are not adressed by the book.

Ghostly yours,
Red.

I am sure most of you already know this, but I thought it might be good to give a real life example to go along with this discussion.

On a less metaphorical note, it is always good to be aware of the existance of many patterns before designing your architecture.

I heve heard, practiced and read many times the best thing to do is to just read the basic introduction to each pattern in your pattern book of choice, and understand its reasoning. Then when its time to develop a piece of software, you have a better place to start. Once you know the problem, and hopefully can relate it to one the patterns you read about, you then go back and read up on it in more detail. At this time, you start designing your true architecture, adapting to the pattern as much as you want.

For example, I am familiar with all the patterns in "Core J2EE Patterns". When a client comes to me with a web application they want to make, I can relate the problem to one of them. I don''t know them all in detail, but I know them enough I can do this. It then makes it much easier deciding how big of a project it will be and an estimated cost.

I could go at length, but it''s be easier just to plug a book

"Software Architecture in Practice" by Len Bass, Paul Clemments, Rick Kazman
While hardly a "final word" on the subject, they present a well-organize treatise (it is THE most boring book I have ever read though - well, maybe mpeg2 ISO docs were worse)

Thanks for the reference MKH - that book does look very dry.