1. UVOD
Termin „software factory“ ima najmanje dva značenja. Može označavati organizaciju koja se bavi razvojem softvera tako da pojedine faze u razvoju (arhitektura, dizajn, konstrukcija, integracija, testiranje...) izvršava u diskretnim radnim centrima. Termin takođe označava razvojno okruženje prilagođeno brzom a ipak kvalitetnom razvoju određenog tipa softverske aplikacije primenjujući principe po kojima funkcioniše klasična industrija. Ovaj tekst se bavi softverskim fabrikama u ovom drugom smislu.
Razvoj softvera je između umetnosti i inženjerske delatnosti. Mnogi eksperti misle da je upotreba termina „softverski inženjering“ neopravdana. Inženjering podrazumeva jasne, u praksi dokazane i retko/sporo promenljive procese i procedure, dok je razvoj softvera kroz pola veka svog postojanja prošao kroz mnoge revolucije i nema garancija da tako neće biti i u budućnosti. S druge strane, upotreba termina „softverska industrija“ izaziva manje kontroverzi, iako mnogi od principa koji su suština industrijske proizvodnje nikad nisu u potpunosti primenjeni u razvoju softvera. Softverski proizvod je najčešće mnogo manje pouzdan nego tipični industrijski proizvod, nema proizvodnje palete sličnih proizvoda u velikim serijama koji se razlikuju u malim detaljima, ljudski rad je u proizvodnji softvera mnogo intenzivniji a automatizacija mnogo manja nego u industrijskoj proizvodnji.
Sve veći zahtevi po pitanju kvaliteta i kvantiteta koji se postavljaju pred proizvođače softvera mogu se zadovoljiti smanjivanjem razlika između rezvoja softvera i industrijske proizvodnje. Značajan deo softverske proizvodnje moraće da se automatizuje, a ljudska kreativnost, kao nepredvidljiva, nepouzdana i najskuplja komponenta proizvodnje koristiće se samo u onim fazama proizvodnog procesa u kojima je nepohodna.
Elementi industrijalizacije i automatizacije neosporno već postoje u razvoju softvera. Pitanje višestruke upotrebe programskog koda (code reuse) je istorijski rešavano funkcijama, bibliotekama, komponentama, objektno-orjentisanim programiranjem i uptrebom framework-a. U zadnjih desetak godina se sve više pažnje poklanja i višestrukoj upotrebi konceptualnih rešenja, tzv. design patterns. Često se takva konceptualna rešenja konkretizuju za određenu razvojnu platformu u vidu mustri (templates) ili čarobnjaka (wizards) koji trasiraju put do konačnog rešenja u vidu programskog i izvršnog koda. Savremena okruženja za razvoj softvera su nezamisliva bez dizajnera – alata koji omogućavaju modeliranje delova aplikacije na višem novou apstrakcije, često vizuelno, uz automatizaciju generisanja programskog koda.
2. MICROSOFT SOFTWARE FACTORIES
Microsoft Software Factory (u daljem tekstu SF) je kombinacija dodataka za Visual Studio, programskog koda (u izvornom i izvršnom obliku) i literature koji imaju za cilj uvođenje elemenata industrijalizacije u proizvodnju softvera. U trenutku pisanja ovog rada (januar 2008.) Microsoft je izdao četri SF koji automatizuju razvoj četri različita tipa softverskih aplikacija:
· Smart Client Software Factory (u daljem tekstu SCSF) namenjen automatizaciji izrade naprednih desktop aplikacija.
· Web Service Software Factory (WSSF) namenjen automatizaciji izrade web servisa.
· Web Client Software Factory (WCSF) namenjen automatizaciji izrade kompleksnih web aplikacija zasnovanih na ASP.Net tehnologiji.
· Mobile Client Software Factory (MCSF) namenjen automatizaciji izrade Windows Mobile aplikacija za uređaje koji se povremeno konektuju na centralni back-end sistem.
Svi SF su razvijeni od Microsoftog tima koji se zove „Patterns & practices“3 i besplatno su dostupni za preuzimanje sa MSDN sajta. Iako svaki od SF ima specifičnosti, svi sadrže mustre, čarobnjake, dizajnere i aplikativne blokove (application blocks) - softverske komponente optimizovane za višestuku upotrebu. Blokovi za keširanje, kriptografiju, logovanje, pristup podacima, rukovanje izuzecima itd. su gotova, testirana i konfigurabilna rešenja za tipične zadatke sa kojima se programeri sreću. Izvorni kod blokava je takođe javno dostupan. Aplikativni blokovi se mogu koristiti i nezavisno od SF. Veliki broj aplikativnih blokova opšte namene je sakupljen u jednu često korišćenu biblioteku - Enterprise Library4.
SF su praćene dokumentacijom i referentnim aplikacijama. Automatizacija je prisutna u svim fazama izrade aplikacije pomoću SF – od generisanja inicijalne strukture Visual Studio solution-a, preko primene određenih koncepta i generisanja ljuštura potrebnih klasa i metoda. Ideja je da kada softverski inženjer jednom shvati koncepte i način funkcionisanja SF, preostaje mu da se skoncetriše samo na poslovnu logiku specifičnu za procese koje modelira.
3. BUS BESTIA
Posle 15 godina korišćenja, stara verzija Moreninog softvera za autobuske stanice5 je postala zrela za penziju. Nova verzija, komercijalno nazvana Bus Bestia, morala je da zadovolji sledeće zahteve:
· Prodaja autobuskih karata kako sa prodajnih mesta u dometu lokalne računarske mreže tako i sa udaljenih lokacija koje će sa aplikativnim serverom biti povezane relativno sporim komunikacionim linijama.
· Mogućnost delimičnog off-line rada kada veza sa aplikativnim serverom ne funkcioniše. U tom slučaju nije moguće izdavati karte na međugradskim polascima za koje je potrebna rezervacija sedišta (ili je moguće iz ograničenog, unapred definisanog kontigenta karata namenjenog samo tom prodajnom mestu) ali je moguće izdavati karte za lokalne polaske na kojima nema numeracije sedišta.
· Kompozitni šalterski GUI koji objedinjava veliki broj slučaja upotrebe (prodaja putničkih karata, peronske, mesečne karte, rezervacije, iskazi-izveštaji za vozače...) pri čemu su, u zavisnosti od radnog mesta i prava prijavljenog korisnika dostupni samo neki slučajevi upotrebe.
· Off-site održavanje aplikacije i otklanjanje softverskih problema za koje je verovatno da će se pojaviti u prvim mesecima rada.
· Višeslojna arhitektura u kojoj je GUI što tanji, relativno lako zamenljiv sloj sa ciljem da postoji više vrsta korisničkog interfejsa (desktop, web, mobile) koji se oslanjaju na istu poslovnu logiku. Takođe, mogućnost naknadne promene/dorade korisničkog interfejsa produžiće životni vek proizvoda na najmanje jednu deceniju.
· Što bogatiji GUI koji će biti motivacija potencijalnim korisnicima za prelazak sa postojećih informacionih sistema u kojima je GUI zasnovan na tekstu, prečicama na tastaturi i bez estetskih pretenzija. Nije teško ustanoviti da je ovaj zahtev delimično u suprotnosti sa predhodnim.
· Korišćenje gotovih podsistema gde god je to moguće, a posebno kad su oni besplatni, testirani i visokog kvaliteta.
Za razvojno okruženje je izabran Visual Studio 2005, za RDBMS SQL Server 2005 uz zadržavanje kompatabilnosti sa SQL Serverom 2000. Nakon višemesečnog istraživanja, inženjeri Morene su došli do zaključka da Microsoft Software Factories nude rešenja za većinu zahteva koji se postavljaju pred Bus Bestiu. Serverski do aplikacije zasnovan je WSSF a za prvu verziju klijentskog dela aplikacije izabrano je smart client desktop rešenje zasnovano na SCSF.
SCSF se naslanja na kompleksni aplikativni blok koji se zove Composite UI Application Block (CAB6). CAB omogućava da se pojedini slučajevi upotrebe (use-cases) razvijaju i testiraju kroz posebne projekte – biznis module, koji se integrišu u zajedničku aplikaciju - školjku (shell) koja je takođe poseban projekat. Biznis moduli u vreme izvršenja dodaju u školjku elemente korisničkog interfejsa (stavke menija, dugmiće na traci alata...) koji omogućavaju pokretanje slučaja upotrebe koji su sadržani u biznis modulu. Pri pokretanju aplikacije, pomoću konfiguracionih fajlova i na osnovu privilegija prijavljenog korisnika određuje se koji se biznis moduli učitavaju. Nadgrađujući infrastrukturu koju nudi CAB i Enterprise Library, u Bus Bestiji smo postigli da su podaci o pravima pristupa i konfiguracija aplikacije potpuno izdvojeni iz aplikativnog koda i smešteni u bazu podataka i XML fajlove.
Prividnu suprotnost između zahteva da GUI bude bogat a ipak lako zamenljiv rešili smo upotrebom M-V-P konceptualnog rešenja. Koncept nalaže da se svaki slučaj upotrebe realizuje kroz tri klase – Model, View i Presenter. Model sadrži podatke, najčešće biznis entitete. Presenter implemetira poslovnu logiku slučaja upotrebe, uključujući pribavljenje potrebnih podataka iz modela i modifikaciju podataka u modelu u slučaju potrebe. View je klasa koja implementira elemente korisničkog interfejsa ali se za bilo kakvu poslovnu logiku oslanja na Presenter, uključujući reakciju na akcije korisnika. Pri tome, Presenter ne sadrži direktnu referencu na View, već na IView interfejs. View klasa implementira IView interfejs.
Na taj način se jedna (prilično „šuplja“) View klasa koja realizuje npr. WinForm interfejs bez izmena ostatka koda može zameniti bilo kojom klasom koja implementira IView interfejs, recimo klasom koja realizuje mobilni ili ASP.Net GUI. Druga prednost M-V-P koncepta je što se u testiranju poslovne logike GUI implementacije View klase mogu zameniti posebnim klasama napravljenim za svrhe testiranja.
M-V-P koncept je star gotovo dve decenije, ali je njegova realizacija bez čarobnjaka, musti i ostalih olakšanja koje donose SF bila zahtevna, pa je većina današnjih programera porasla pored alata (npr. Visual Basic) koji podstiču mešanje poslovne logike i GUI implementacije u jedan fajl / jednu klasu što bitno otežava analizu, testiranje i naknadnu promenu korisničkog interfejsa7.
Problem off-line rada kada je u pitanju prodaja karata rešili smo primenom Cashing Application Block-a koji je deo Enterprise Library. Evidencija vanrednih događaja rešena je primenom Logging Application Block-a koji je takođe deo Enterprise Library.
Od velike koristi u razvoju Bus Bestie se pokazao koncept service agent-a. Biznis moduli nemaju referencu direktno na web servis (ili web servise) i kada su im potrebne usluge web servisa pozivaju metode posebne klase koja se zove servis agent i izdvojena je poseban projekat. Unutar servis agenta se vrši mapiranje podataka iz oblika u kome ih koristi web servis (u našem slučaju XML dataset) u biznis entitete (ili kolekcije biznis entiteta) koje koriste poslovni moduli i obrnuto. Tako biznis moduli ne znaju ništa o tabelama, relacijama i drugim objektima karakterističnim za relacioni model podataka. Biznis moduli barataju isključivo objektima i kolekcijama objekata, a programeri koji se bave biznis modulima ne moraju da znaju ništa o RDBMS, SQL-u ili strukturi konkretne baze u kojoj su podaci smeštani.
4. KAKO POČETI
Rad sa SF donosi velike koristi ali zahteva značajan incijalni mentalni napor i u početku je kriva učenja relativno malog nagiba što mnoge natera da odustanu i pre pravog početka. Početi sa SF od SF je greška. SF je samo šlag na torti koja se sastoji od aplikativnih blokova i implementacije koncepata dokazanih u praksi. Ukoliko do sada niste radili sa aplikativnim blokovima (pre svega onih sadržanim u Enterpise Library), njihova instalacija, proučavanje literature i probni projekti treba da budu prvi korak u savladavanju SF. Kada je u pitanju SCSF, nužno je predhodno i poznavanje CAB-a. CAB je jedan od najkompleksnijih aplikativnih blokova i budite spremni da na njegovo inicijalno proučavanje potrošite više radnih dana. Koncepti (patterns) koji se primenjuju uz izabrani SF su uvek dati u posebnim sekcijama literature koja stiže uz SF. Ponekad ih nije lako unapred razumeti bez praktičnog iskustva u radu sa njima, ali ne treba odustati. Na taj deo literature se treba vraćati s vremena na vreme, i svaki put će biti sve jasniji.
Na Internetu se mogu pronaći sajtovi, diskusione grupe i blogovi vezani za SF. Jedan od boljih arhitekturalnih vodiča kroz SCSF i CAB je rad zasnovan na iskustvima implementacije IS u Raiffeisen Banking Group u Austriji8.
5. PROBLEMI NA KOJE TREBA RAČUNATI
SF nemaju široku korisničku bazu kao većina drugih Microsoft proizvoda. To za posledicu ima povećanu mogučnost da naiđete na bagove koje drugi nisu opisali i čije rešenje ne možete naći na Internetu. Jedan od neprijatnih bagova sa kojim smo se mi susreli je nefunkcionisanje „Add Smart Web Reference“ čarobnjaka u slučaju da nazivi web metoda sadrže naša slova.
Zbog „hladnog starta“ sa SF mi smo probili rokove koji su bili postavljeni za isporuku softvera. Za prvi SF projekat, pomnožite vreme koje ste inicijalno predvideli za realizaciju sa 2, i dobićete približno tačno vreme završetka projekta. Naravno, za sledeće projekte utrošeno vreme biće monog manje.
Iako je za uspešno razumevanje CAB-a preduslov za poznavanje SCSF, neki CAB koncepti su u u SCSF implementaciji značajno promenjeni što može da zbuni. Tako je M-V-C koncept u CAB-u zamenjen M-V-P konceptom u SCSF, a osnovna CAB klasa koja enkapsulira jedan slučaj upotrebe, WorkItem, u SCSF se koristi samo posredno, preko ControlledWorkItem klase.
Neki koncepti koji se ugrađuju u nove verzije .Net Framework ili u nove verzije Visual Studia kao osnovnog razvojnog okruženja su u suprotnosti sa konceptima sadržanim u pojedinim aplikativnim blokovima. Tako je Visual Studio 2005 proširio koncept Dataset-a uvođenjem TableAdapter-a, klase koja se kreira novouvedenim dizajnerom i čarobnjakom i koja enkapsulira pristup objektima u bazi podataka (tabelama, upitima, funkcijama i uskladištenim procedurama) dok se široko korišćeni Data Access Aplication Block9 (DAAB) i dalje zasniva na klasama (DataReader i DataAdapter) koji isključuju upotrebu TableAdapter-a. Iako postoje hibridna rešenja, mi smo se odlučili da Bus Bestia u Data Layer-u web servisa koristi TableAdapter-e umesto DAAB-a.
Iako su svi koncepti koje SF mogu da implementiraju nesumnjivo korisni, većina njih unosi dodatni stepen kompleksnosti. „Kvaka“ je u tome što je teško znati u napred da li je korist od primene koncepta veća od cene koja se plaća dodatnim stepenom kompleksnosti. Na primer, u prvoj fazi razvoja, Bus Bestia je intenzivno koristila „Asynchronous Web Service Invocation with Timeout“ koncept koji omogućava kombinovanje dobrih stvari iz asinhronog pozivanja web metoda (bolje korisničko iskustvo zato što GUI nije blokiran čekanjem na odgovor servisa) i sinhornog pozivanja web metoda (ako servis nije dostupan, posle definisanog timeouta, kontrola se vraća metodu koji je pozvao web servis). Veoma brzo smo ustanovili da je cena koju moramo da platimo zbog toga što rezultati poziva servisa stižu u drugom thread-u visoka – promene podataka u View moraju da se obavljaju Invoke metodama, a greške koje nastanu zbog previda programera da to uradi se teško otkrivaju zato što se manifestuju sporadično kao „zamrzavanje“ aplikacije u vreme izvršenja. Relativno kompleksan kod koji implementira koncept asinhornog poziva servisa uz timeout automatski kreira čarobnjak koji je deo SCSF. Međutim, dodatne teškoće u razvoju nastale su u slučajevima promene intefejsa web servisa, kada ne postoji mogućnost dopune postojećeg koda čarobnjakom, već se više desetina fajlova u kojima se generisani kod nalazi mora izbrisati i ponovo kreirati čarobnjakom što nam je napravilo dosta problema u kombinaciji sa Visual Source Safe alatom koji smo koristili.
6. GLAVNE KORISTI
Koristi od upotrebe SF imaju svi: korisnici softvera, projektanti, programeri i inženjeri koji rade na instalaciji i održavanju.
Korist za korisnika ogleda se u konzistentnom korisničkom interfejsu koji smanjuje vreme obuke i jednostavnom dodavanju novih slučaja upotrebe.
Glavna korist za projektante je da primenom proverenih koncepta minimizuju rizik od arhitekturalnih greška. Upotreba SF im omogućava da programerima nametnu zajedničku strukturu rešenja za sve slučajeve upotrebe što vodi lakšem testiranju i bržem uključivanju novih članova tima. Tu je i mogučnost da brzo implementiraju prototip buduće aplikacije koji će sadržati samo kritične delove i na taj način otkriju rizike u ranoj fazi razvoja.
Programerima upotreba SF donosi automatizaciju većine zadataka koji su nekreativni što im omogućava da se fokusiraju na implementaciju poslovne logike. Programer koji je jedanput savladao određeni SF, mnogo lakše će se uključiti u projekat baziran na SF nego u projekat pisan „od nule“.
Inženjeri koji rade na instalaciji i održavanju dobijaju aplikacije koje se lakše konfigurišu i instaliraju nego tradicionalne aplikacije.
7. ZAKLJUČAK
Iako je naziv „software factory“ pomalo bombastičan, koncept je korak u dobrom pravcu. Mada će u nekim segmentima razvoja softvera uvek biti neophodan ljudski genije, industrijalizacija proizvodnje je logičan odgovor na sve veće zahteve u pogledu kvaliteta i kvantiteta koji se postavljaju pred proizvođače softvera10. Morena inženjering će i u budućnosti koristiti software factories za razvoj svojih proizvoda.
LITERATURA
[1] Wikipedia - Software factory
[2] Wikipedia - Debates within software engineering
[3] msdn2.microsoft.com/en-us/practices/default.aspx
[4] msdn2.microsoft.com/en-us/library/aa480453.aspx
[5] http://www.morenaict.com/
[6] msdn2.microsoft.com/en-us/library/aa480450.aspx
[7] martinfowler.com/eaaDev/uiArchs.html
[8] Mario Szpuszta - „Designing Smart Clients Based on CAB and SCSF“
[9] msdn2.microsoft.com/en-us/library/aa480458.aspx
[10] http://www.blogger.com/UsersData/DocumentsandSettings/nikola/My%20Documents/www.softwarefactories.com
