Pateiksime keletą praktinių patarimų, kaip pasiekti, kad programinės įrangos architektūros projektavimas būtų efektyvus ir teiktų ilgalaikę naudą — leistų efektyviau realizuoti kokybišką ir nesunkiai palaikomą programinę įrangą.
Pirmas žingsnis: Projektavimo veiklos apibrėžimas
Visų pirma reikia įvertinti projektavimo veiklos svarbą planuojant ir išskirti jai pakankamai laikoTaip pat reikia nutarti, kas iš projekto vykdytojų bus atsakingas už programinės įrangos architektūrą. Didesniuose projektuose reikalinga sistemų architekto specializacija, o mažesniuose projektuose tai gali atlikti ir programuotojai. Taip pat svarbu apibrėžti projektavimo sprendimų dokumentavimo taisykles, nustatyti jų aptarimo ir priėmimo procedūras.
Antras žingsnis: UML modeliavimo kalbos įsisavinimas
Šiuo metu UML modeliavimo kalba yra standartinė projektavimo priemonė, kuri visuotinai naudojama pasaulyje ir praktiškai neturi rimtesnių “konkurentų”. Todėl, jeigu siekiate standartizuoti modeliavimo notaciją, kuri būtų plačiai suprantama, vienareikšmiškai rekomenduojame pasirinkti UML. UML apibrėžia 12 rūšių diagramas, kurios leidžia specifikuoti įvairius architektūros aspektus. Tačiau tikrai nebūtina naudoti visų diagramų. Čia, kaip ir daugelyje kitų sričių galioja 80/20 taisyklė: 80% projekto užtenka 20% UML galimybių. Nebūtinai reikia ir specializuotų UML įrankių – nedideliuose projektuose galima braižyti UML diagramas bendrais diagramų modeliavimo įrankiais, pvz. Microsoft Visio, arba tiesiog ranka ant popieriaus ar lentos. Visgi didesniuose projektuose specializuotų UML įrankių naudojimas leidžia dirbti daug efektyviau.
Naudojant UML, galima modeliuoti sistemą skirtingais abstrakcijos lygiais. Pavyzdžiui, kuriamos sistemos esybes ir jų ryšius vaizduojanti klasių diagrama gali būti naudojama reikalavimų analizės metu, o vėliau pagal ją gali būti sukuriama detali realizacijos klasių diagrama, kurioje nurodomi specifiniai realizacijos kalbos duomenų tipai, atliekamos reikalingos ryšių transformacijos, pridedamos tik realizacijai reikalingos savybės, tokios kaip identifikaciniai kodai. Modeliavimas skirtingais abstrakcijos lygiais leižia glaudžiau susieti programinės įrangos architektūros projektavimą su reikalavimų analizės veikla.
Trečias žingsnis: Projektavimo principų žinojimas ir taikymas
Norint priimti gerus projektavimo sprendimus, reikia žinoti ir taikyti projektavimo principus, kurie yra išbandyti ir pasiteisinę praktikoje. Tokių principų pavyzdžiai: sistemų skaidymas į posistemių sluoksnius, MVC ( Model-View-Controller ) karkasas, projektavimo šablonai, aprašyti klasika tapusioje Design Patterns: Elements of Reusable Object-Oriented Software bei kitose knygose. Principų ir šablonų naudojimas leidžia panaudoti sukauptą projektavimo išmintį, nekartoti klaidų ir “neišradinėti dviračio”.
Yra daug gyvenimiškų principų, kurie puikiai tinka projektuojant programinę įrangą. Vienas iš tokių — dar romėnų imperijos kūrimo laikais taikytas “skaldyk ir valdyk”. Bet kurią sudėtingesnę programinės įrangos sistemą reikia suskaidyti į dalis, kad būtų galima efektyviai padalinti kūrimą grupei žmonių. Čia labai svarbu tiksliai apibrėžti tų dalių bendravimo principus ir sąsajas. Vienas iš plačiausiai taikomų sprendimų — sluoksniuotos posistemių architektūra, kurioje bendravimas tarp sluoksnių yra griežtai ribojamas hierarchijos — auščiausio lygio sluoksnis bendrauja tik su po juo esančiu sluoksniu, šis su dar žemesniu ir t.t. Nėra leidžiamas bendravimas iš žemesnių sluoksnių į aukštesnius arba “peršokant” tarpinius sluoksnius. Toks sistemų organizavimas labai palengvina sistemų palaikomumą. Sluoksniuota architektūra dažnai jungiama su MVC (angl. Model-View-Controller) šablonu, kuris siūlo skaidyti programinę įrangą į vartotojo sąsajos, duomenų modelio ir veiklos logikos dalis.
1 paveikslas. Sluoksniuota trijų lygių architektūra pagal MVC projektavimo šabloną
Sluoksniuotos architektūros, pagrįstos MVC šablonu, schema puikiai tinka taikyti daugumoje programinės įrangos sistemų, kadangi tiek vartotojo sąsaja, tiek duomenys yra praktiškai bet kurioje programinėje įrangoje, o didesnėse verslo optimizavimui skirtose sistemose dažniausiai yra pakankamai sudėtinga veiklos logika, kuri gali kisti priklausomai nuo įmonės strategijos, todėl ją verta išskirti kaip atskirą modulį. Toks organizavimas leidžia realizuoti nesunkiai praplečiamą ir palaikomą programinę įrangą bei lengvai paskirstyti darbus.
Ketvirtas žingsnis: Projektavimo sprendimų dokumentavimas
Tam, kad projektavimo sprendimai būtų gerai suprantami ir įsisavinami, juos būtų galima analizuoti ir įvertinti, reikia dokumentuoti svarbiausius projektavimo sprendimus. Paprastai dokumentavimą labai palengvina ruošinio, kuriuo apibrėžta dokumento struktūra ir paaiškinta, ką ir kaip kiekviename skyriuje reikia aprašyti. Žemiau pateikta pavyzdinė programinės įrangos architektūros dokumento struktūra, kuri yra siūloma RUP proceso ruošinyje (Rational Unified Process).
Modeliuojant projektavimo sprendimus ir juos dokumentuojant, taip pat reikia laikytis modeliavimo stiliaus taisyklių, kurios leidžia sukurti paprastesnes, aiškesnes ir geriau suprantamas diagramas. UML stiliaus taisyklių rinkinys pateiktas knygoje The Elements of UML Style.
Tokių taisyklių pavyzdžiai:
- diagramoje turėtų būti 7±2 elementai, o didesnes diagramas reikia skaidyti į keletą mažesnių;
- vengti besikertančių, vingiuotų, ilgų linijų, vaizduojančių ryšius tarp elementų;
- naudoti spalvas skirtingiems pagal reikšmę elementams atskirti;
- stengtis išlaikyti diagramos elementų išdėstymo simetriją.
Penktas žingsnis: Projektavimo sprendimų aptarimas
Projektavimo sprendimus būtina aptarti ir įvertinti, kad būti priimti geriausi ir visi juos puikiai suprastų ir pritaikytų. Tai daroma organizuojant techninių sprendimų pristatymo ir aptarimo susirinkimus, kurie gali būti tiek formalūs, tiek neformalūs. Taip pat rekomenduojama atlikti periodines peržiūras. Kai dirbama su naujomis technologijomis arba pagal naują metodiką patartina samdyti techninius konsultantus.
Šeštas žingsnis: programinio kodo atitikimo architektūrai analizė
Reikia ne tik suprojektuoti ir dokumentuoti programinės įrangos architektūrą, bet ir siekti, kad ji būtų tinkamai perkeliama į programinį kodą nepažeidžiant architektūroje nustatytų principų. Pirminis įrankis analizuojant programinio kodo atitikimą architektūrai yra programinio kodo peržiūros, kurias taip pat rekomenduotina atlikti periodiškai ir įtraukti į projekto planus. Programinio kodo peržiūrai ir vertinimui gali labai padėti specializuotų kodo statinės analizės įrankių naudojimas. Analizuoti kodą padeda ir UML įrankiai, tokie kaip MagicDraw UML, palaikantys atgalinės inžinerijos funkcijas, leidžiančias atstatyti programinės įrangos realizacijos modelį iš programinio kodo ir jį vizualizuoti bei analizuoti.
Daugiau skaitykite straipsnyje „Programinės įrangos architektūros projektavimas“.
Paieška archyve
