Architektúra

A Programozás Wiki wikiből

Egy kellőképpen homályos, de mindenképp nagyon szakszerűnek ható szó. Érthetjük alatta:

  • A szoftver általános felépítését (háromrétegű architektúra)
  • A szoftver tervezésekor meghatározott magas szintű döntéseket
  • A szoftverek és más alkalmazások együttműködését valamely vállalati környezetben
  • A szoftvert futtató fizikai vagy virtuális gép jellemzőit (intel / risc / nagygépes architektúra)

Ezeken kívül néha használjuk a logikai terv szinonímájaként is (helytelenül).

Ha precízebbek akarunk lenni, akkor programok kapcsán beszélhetünk alkalmazás- és vállalati architektúrákról. Az előbbi alatt érthetjük az önálló alkalmazás tervezésekor magas szinten meghozott döntéseket (pl. az általános felépítését, a telepítés módjait, az általa nyújtott szolgáltatások és adatok körét), az utóbbi pedig egy konkrét környezetben (pl. a megrendelő vállalatnál) írja le a cég üzleti működéséhez szükséges programok kapcsolatát (melyik program hol fut, ki a felelős üzemeltetője, ki a felelőse a továbbfejlesztési igényeknek, mely más programoktól / hardverektől függ, milyen adatokat milyen csatornákon kap meg, stb).

Ennek megfelelően beszélhetünk application architectekről (akik az alkalmazásarchitektúrák gazdái), és enterprise architektekről, akik a vállalati architektúráé.

Architektúratervezés[szerkesztés]

Az alkalmazás architektúráját általában ugyanúgy tervezzük, mint a logikai felépítését: az ügyfél által megfogalmazott követelményeket, és a saját szakmai tapasztalatainkat fordítjuk le tervvé. Az architektúrát jellemzően a nem funkcionális követelmények befolyásolják, mint például:

  • Válaszidő, rendelkezésre állás, skálázhatóság
  • Újrahasznosíthatóság, továbbfejleszthetőség (ezek jellemzően nem kódszintű, hanem üzleti értelemben vett fogalmak)
  • Az ügyfélnél már meglévő rendszerek, szabványos megoldások
  • A piacon jelenlévő technológiák

(Amennyiben nem egyedi megoldást fejlesztünk hanem "dobozos" szoftvert, a fentiekben az ügyfél helyett mindig a megcélzott felhasználói kört kell érteni, így a válaszok néha ellentmondásosak lehetnek - pl. a használt operációs rendszer, vagy böngésző nagyobb vállalatoknál szabványos, dobozos alkalmazásoknál pedig egyáltalán nem az)

Ezek alapján készíthetjük el az alkalmazás magas szintű vázlatát (pl. fusson böngészőben hogy megússzuk a telepítést, vagy legyen egy szerver ami SOAP hívásokat tud párhuzamosan kiszolgálni, és NLB clusteringre is képes, stb). Amint ezek a döntések megszülettek, haladhatunk tovább az alkalmazás logikai tervezésével.