duminică, octombrie 21, 2007

Arhitectura unui sistem

Nu putem sa vorbim despre lucruri atat de inalte fara a face referiri la inaintasi. Martin Fowler in articolul sau Who Needs an Architect, pune o intrebare interesanta Ce este un architect? Pentru aceasta trebuie sa raspunda la o alta Ce reprezinta arhitectura unei aplicatii? Si pentru aceasta este nevoit sa dea o definitie arhitecturii. Pentru asta face cateva incercari reusite:

“…the highest level concept of a system
in its environment. The architecture of a software
system (at a given point in time) is its organization
or structure of significant components
interacting through interfaces, those components
being composed of successively smaller components
and interfaces.”

“In most successful
software projects, the expert developers working
on that project have a shared understanding of the
system design. This shared understanding
is called ‘architecture.’ This understanding
includes how the system is divided into
components and how the components interact
through interfaces. These components
are usually composed of smaller
components, but the architecture only includes
the components and interfaces that
are understood by all the developers.”

“…architecture
is the set of design decisions that
must be made early in a project.”

De aici se desprinde ca arhitectura implica:

  • o viziune asupra componentelor constituiente ale unui sistem si a interactiunilor dintre ele
  • un consens intre membrii unei echipe
  • un set de decizii corecte care trebuie luate, sau mai bine zis ar fi de preferat sa fie luate

O greseala des intalnita este aceea de a considera ca rolul arhitecturii e acela de a crea sisteme optimizate. Adevaratul scop al arhitecturii este acela de a oferi o usoara mentenanta a sistemului, faza cea mai lunga a existentei unui proiect. Deci este o chestiune mai mult de organizare, o metoda de a gestiona complexitatea unui proiect prin sinteza, analiza si experienta.

Deci arhitectura = mentenanta.

Desigur aspectele legate de optimizare trebuie sa constituie o preocupare de baza chiar din fazele initiale ale proiectului. Dar din nefericire la un moment dat toate presupunerile devin simple supozitii, daca nu sunt confirmate de masuratori. Trebuie tinut cont ca business-ul modelat evolueaza si complexitatea creste. Deci, undeva in faza finala a unui proiect, cand business-ul implementat este stabil, trebuie sa existe o etapa de masuratori (facute cu un profiler si folosind unelte de stess, load testing, etc. ), care sa spuna in numere performantele, scalabilitatea, etc. unui sistem (link). Un set de citate care confirma cele spuse:

“More computing sins are committed
in the name of efficiency (without necessarily achieving it)
than for any other single reason - including blind stupidity.” - W.A. Wulf

“We should forget about small efficiencies,
say about 97% of the time:
premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%.”- Knuth, paraphrasing Hoare

“The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!):

Don't do it yet.” - Michael A. Jackson

Deci arhitectura!=optimizare.

In principiu putem gandi arhitectura unui proiect indiferent de tehnologiile folosite. Dar trebuie sa recunoastem ca acestea in sine aduc/impun elemente de arhitectura sistemului. Framework-urile alease, implementarile de specificatii, librariile folosite sunt hotaratoare. Cele mai importante sunt cele care impun un model de programare cum ar fi cazul framework-ului Spring sau a specificatiei J2EE. Ele trec peste aspecte specifice cum ar fi prezentarea web, persistenta, spre a oferi o intreaga infrastructura aplicatiei, asa cume cazul serverului de aplicatii in cazul J2EE si a containerului IOC in cazul Spring.