Uvod u filozofiju dizajna softvera

Filozofija, dizajn, softver
Nauka je ono što se zna. Filozofija je ono što se ne zna.
Ovako je Bertrand Rasel objasnio razliku između nauke i filozofije. Kada neka oblast postane dovoljno egzaktna a pojmovi te oblasti jednoznačni i univerzalno prihvaćeni, ona prestaje da bude interesantna za filozofiju.
Dizajn softvera nije egzaktna nauka. Postoje različita mišljenja šta je dizajn softvera, koje su mu granice u odnosu na analizu zahteva i implementaciju («programiranje»), da li je arhitektura deo dizajna... Dijametralno suprotne metodologije dizajna nekad daju a nekad ne dobre rezultate a da nije potpuno jasno zbog čega. Ne postoji univerzalno prihvaćena procedura kojom bi se ustanovilo da li je dizajn softvera dobar. Zbog toga je vreme da se umesto kreiranja i prihvatanja dogmi koje simuliranju nepostojeće znanje, okrenemo filozofiji dizajna softvera, koja nam može pomoći da, ako ništa drugo, postavimo prava pitanja. A prava pitanja su pola puta do pravih odgovora.
Filozofija nije novost u računarstvu, kako nesrećno na srpski prevodimo ne mnogo lepši engleski termin «computer science». Na mnogim svetskim univerzitetima proučava se filozofija računarstva, najviše u Skandinaviji, SAD i Velikoj Britaniji. Jedan d najaktivnijih timova nalazi se na Univerzitetu u Eseksu[1] a predvodi ga profesor Amnon Eden.
Filozofija i dizajn su takođe termini koji se često sreću zajedno i česte su filozofske, pa i religiozne rasprave koje se tiču dizajna. Dizajn je imenica i glagol. Dizajn kao imenica predstavlja svojstvo svakog postojećeg entiteta, predmeta ili procesa, od atoma do vasione, od dečije igre do života čoveka. Dizajn kao glagol to je proces planiranja entiteta u nastajanju da bi se postigli željeni ciljevi. Izvesno je da će svaki entitet koji je nastao procesom dizajna imati dizajn (pa makar i loš), ali nije izvesno da je je svaki dizajn posledica procesa dizajna kao svesne, namerne, aktivnosti. Bivši američki predsednik Buš je izazvao veliku polemiku u američkoj javnosti zahtevajući da se u školskom sistemu da jednak prostor Teoriji evolucije i Teoriji «inteligentnog dizajna» kada je u pitanju nastanak i razvoj živog sveta na Zemlji.
Filozofija dizajna traži odgovore na pitanja o svrsi dizajna, o načinu i mogućnosti učenja dizajna o osnovnim principima dizajna. Široko je prihvaćno mišljenje da ključ dobrog dizajna leži u jednostavnosti, uz punu svest o tome da je do jednostavnosti, kao izraza potpunog razumevanja, veoma teško doći. Jim Valdo iz Sun Microsystems, u svom briljantnom eseju «On System Design»[2] piše o tome kako je najgora kritika njegovog učitelja dizajna bila «to je previše komplikovano». Albert Ajnštajn je rekao da sve stvari treba predstaviti na najjednostavniji mogući način, ali ne jednostavnije od toga. Antoan de Sent Egziperi je mislio slično: “Izgleda da je nešto perfektno ne kad nema šta da mu se doda, već kad nema šta da mu se oduzme”.

Filozofske discipline značajne za dizajn softvera
Pitanjima poput «Šta postoji?» i «Kakve su veze između onoga što postoji?» bavi se filozofske disciplina koja se zove ontologija. Ontologija dizajna softvera treba da da odgovore na pitanja koji sve entiteti postoje u dizajnu softvera i kakve su međusobne veze između tih entiteta. To bi omogućilo da dizajneri mogu da komuniciraju globalno i da se razumeju nezavisno od toga gde su učili dizajn softvera i i koje metodologije primenjuju.
Početkom ovog, XXI veka, veliku pažnja se poklanja istraživanjima koja omogućavaju inteligentnije pretraživanje informacija na Webu zasnovano na semantici (značenju) a ne samo na ključnim rečima. Osnova za takvo pretraživnje je formalno definisanje onoga što postoji na Webu i veza između toga što postoji. Zato je predloženo više jezika za definisanje ontologije weba od kojih je jedan, Web Ontology Language (OWL), standardizovan. Napravljeni su pionirski pokušaji da se OWL iskoristi i za formalni opis ontologije dizajna softvera[3]. Ovaj primer pokazuje da je preplitanje različitih disciplina dovodi do dvosmernog uticaja. Filozofi, sa retkim izuzetcima poput Aristotela, nisu skloni sistematičnosti i formalizmu. Forma nikada neće biti važnija od suštine, ali prihvatanje formalnih jezika za opis odgovora na filozofska pitanja kao pomoćnog filozofskog sredstva može smanjiti jaz između filozofije i ostalih akademskih disciplina.
Ako objektivna realnost postoji, da li čovek može da je spozna i koje su granice te spoznaje? Koji su najbolji načini učenja? Takvim pitanjima se bavi epistmologija (drugi naziv je gnoseologija). Epistemologija softverskog dizajna bavi se odnosima realnog domena, dizajna softvera koji modelira taj domen, i programa koji kreiramo na osnovu definisanog dizajna. Takođe, epistemologija traži odgovore na pitanja da li dizajn softvera može da se nauči, i ako može, koje su najbolji načini za učenje dizajna.
Iako dizajn može imati različite ciljeve, gotovo uvek su među njima ciljevi koji se odnose i na estetiku. Estetika je grana filozofije koja se bavi pitanjima percepcije nekog entiteta, vrednostima koje nisu vezane za funkcionalnost. Estetika je usko povezana sa umetnošću. Podrazumeva se da su estetski kriterijumi bitni za kvalitet dizajna korisničkog interfejsa. Da li su i za ostale delove dizajna softvera estetske vrednosti od značaja? Da li dizajn uopšte može da ispunjava druge, pragmatične ciljeve ako nema estetske vrednosti? To su pitanja na koje odgovore treba da da estetika dizajna softvera.
Etika zajedno sa estetikom spada u zajedničku oblast filozofije koja se naziva aksiologija ili teorija vrednosti. Etika dizajna softvera definiše šta je dobro, vredno i šta je ispravno u dizajnu softvera. Da li je dobro i ispravno iskoristiti tuđi dizajn koji nije zaštićen patentom? Da li je dobro i ispravno koristiti tuđa iskustva u dizajnu? Da li vredi baviti se dizajnom softvera na filozofski način, što je namera ovog ogleda? Tim pitanjima bavi se etika dizajna softvera.
Logika je grana filozofije koja je od suštinskog značaja za dizajn softvera. Analiza, sinteza, i apstrakcija su samo neki od mnogih alata logike na kojima su zasnovane metodologije dizajna softvera. Dizajner softvera možda i može da bude dobar u svom poslu iako nikad nije proučavao ontologiju, epistemologiju ili etiku. Međutim, nepoznavanje logike ga sigurno diskvalifikuje. Pri tome je važno skrenuti pažnju čitaocima čije je obrazovanje pre svega tehničko da je pogrešno logiku svoditi na matematičku logiku koja je samo jedan njen deo.
U procesu dizajna softvera koristimo različite prirodne i veštačke jezike. Najpoznatiji jezik kojim se opisuje dizajn softvera je UML, univerzalni jezik za modelovanje. Filozofija jezika se bavi prirodom, nastankom i upotrebom jezika. Istraživanja u oblasti filozofije jezika dizajna softvera mogu dovesti do boljih, izražajnih, estetski vrednijih i jednostavnijih jezika.

Realnost, reprezentacija, opis


Za razumevanje filozofskog pogleda na dizajn softvera važna je razlika između:

• Objektivne realnosti, koja (možda) postoji nezavisno od bilo kog posmatrača;
• Subjektivne realnosti koja je individualni mentalni model objektivne realnosti. Taj model nazivamo reprezentacija.
• Opisa realnosti kojim čovek komunicira, razmenjuje svoje reprezentacije sa svetom oko sebe, a pre svega sa drugim ljudima. Opis može biti verbalni, gestovni ili pismeni, iskazan u slobodnoj, umetničkoj formi ili na unapred dogovoren, formalno definisan način.
  
  
  

U procesu razvoja softvera pored objektivne realnosti, postoji veliki broj reprezentacija i veliki broj opisa. Reprezentacija ima onoliko koliko ima ljudi uključenih u proces razvoja, ali najvažnije su reprezentacije predstavnika naručioca posla (kupca) preko kojih se predstavnici softverskog tima (analitičar) upoznaje sa realnim domenom koji treba modelirati softverom, reprezentacija analitičara, dizajnera softvera i programera. Ti ljudi razmenjuju svoje reprezentacije realnosti na razne načine, najčešće verbalno.
Softverski inženjering se trudi da te opise učini trajnim (da postoji pisana/elektronska dokumentacija opisa), jednoznačnim i globalno razumljivim. Zbog toga se teži standardizaciji jezika za opis mentalnih modela u kojima grafički elementi zamenjuju reči kad god je to moguće.
Razni filozofski pogledi daju različite odgovore na pitanja da li objektivna realnost uopšte postoji i ako postoji koliko reprezentacija može da se približi objektivnoj realnosti. Tim pitanjima bave se filozofske grane ontologija i epistemologija. Neka istraživanja pokazuju da u zavisnosti od ontološkog i epsitemološkog stava dizajnera zapravo postoje četri suštinki različita pristupa dizajnu softvera[4]. Pokušaj da ta četri pristupa podvedemo pod zajednički okvir doprinosi da se dizajn softvera danas teško može zvati konzistentnom, egzaktnom naukom.

Delokrug dizajna softvera
Ozbiljnijem bavljenjem ontologije dizajna softvera mora da predhodi utvrđivanje granica, delokruga dizajna softvera. Po tom pitanju postoji nekoliko nedoumica.


Pojmovi analize (zahteva) i dizajna (softvera) se često sreću zajedno, posebno kada su u pitanju metodologije. Tako govorimo o objekto orjentisanoj analizi i objetkno orjentisanom dizajnu ili o struktrnoj analizi i strukturnom dizajnu. Proces analize zahteva i dizajna softvera spaja postupak modelovanja, s tim što se tokom analize pravi opis – model realnog domena a u fazi dizajna model budućeg softverskog sistema. Vrlo često, posebno kod manjih projekata, analitičar i dizajner su jedna te ista osoba. Ta osoba često spaja proces analize i dizajna, modelirajući realni domen odamh na način koji omogućava revođenje modela u softver. Ipak, analiza zahteva i dizajn softvera su u generalnom slučaju dva odvojena procesa, sa različitim ciljevima i izlaznim dokumentima namenjenim raznim ciljnim grupama. Opis rezultata analize zahteva mora da bude razumljiv za kupca i ljude koji rade u realnom domenu. Opis dizajna softvera mora da bude razumljiv za programere i druge osobe koje će biti uključene u razne faze razvoja i održavanja softvera.
Druga dilema je vezana za arhitekturu. Da li je ona deo dizajna softvera ili posebna faza u razvoju softvera? Većina autora smatra da je izbor arhitekture sastavni deo procesa dizajna softvera i da sapravo prestavlja dizajn na visokom stepenu apstrakcije. Za ostatak procesa dizajna koji ne spada u arhitekturalni dizajn razni autori koriste različite termine ali se najčešće sreću termini detaljni ili taktički dizajn.
Postoji mišljenje da je samo binarni, izvršni kod pravi program a da je izvorni kod zapravo deo dizajna na niskom stepenu apstrakcije[5]. Proces prevođenja izvornog koda u binarni kod i povezivanja sa programskim bibliotekama je zapravo proces u kome od dizajna softvera nastaje softver, zapravo proces proizvodnje softvera. Ono što softversku industriju razlikuje od ostalih industrija je potpuno automatizovan i praktično besplatan proces proizvodnje. Mora se priznati da, pogotovu danas, sa programskim jezicima i razvojnim okruženjima koji omogućavaju programiranje na visokom nivou apstrakcije, ova teza sigurno nije besmislena. Na primer, definisanje interfejsa klasa je sigurno deo objektno orjentisanog dizajna ali i sastavni deo programskog koda u savremenim C++, Java ili C# okruženjima. Prihvatanje ovakvog stava ima nekoliko interesantnih filozofskih implikacija:
Svi programeri su zapravo dizajneri i moraju da imaju dizajnerske sposobnosti i obrazovanje.
Nepotrebno je tražiti formalne metode za dokazivanje ispravnosti dizajna.Ti metodi su bitni u industrijama u kojima je proces proizvodnje skup i svaka greška u dizajnu mnogo košta. Kad je u pitanju softver, lakše je napraviti proizvod (izvšni kod) i kroz testiranje proizvoda utvrditi valjanost dizajna.
Težnja agilnih pristupa razvoju softvera da se što ranije u razvojnom ciklusu krene sa programiranjem je zapravotežnja da se što ranije krene sa dizajniranjem softvera na niskom nivou apstrakcije.

Prihatanje, makar delimično, implementacije kao dela dizajna postavlja pred ontologiju problem identifikacije onog dela dizajna koji se odnosi na arhitekturu, dela koji se odnosi na taktički dizajn i dela koji se odnosi na implementaciju. A.Eden i R.Kazman su definisali formalan, matematički kriterijum za podelu dizajna na ova tri dela i nazvali ga «Intension and Locality Criteria»[6].

Opis dizajna softvera
Videli smo da je opis značajna karika u trijadi Realnost-Reprezentacija-Opis i da služi da ljudi razmenjuju svoje reprezentacije. Opis ima poseban značaj za dizajn softvera kada mu je obezbeđena trajnost (perzistentnost) tj kada je u vidu elektronske ili štampane dokumentacije. Takođe, videli smo da se ne može se svaki softver reći da je dizajniran, u smislu svesne aktivnosti, planiranja, samo zato što ima kakav-takav dizajn. Jedan od boljih pokazatelja da je softver dizajniran je postojanje dokumentacije koja opisuje taj dizajn, pogotovu ako je dokumentacija nastala pre implementacije softvera.
Dokumentovanje služi da ono što znamo bude i drugima dostupno čak i kad mi nismo dostupni. Dokumentovenje služi da se i sami dizajneri podsete na zaboravljene elemente sopstvenog dizajna. Ali još važnije, postupak u kome dizajn dokumentujemo ili na drugi način opisujemo nekom drugom koji ima konstruktivan kritički stav prema tom dizajnu, omogućava da potencijalne slabosti dizajna izađu na videlo na vreme.
Standard IEEE 1016-1998 specificira dokumentaciju kojom se opisuje softverska arhitektura i detaljni dizajn softvera.

Epistemologija dizajna softvera
Dizajner istorijski važnog IBM DOS/360 operativnog sistema, Fred Brooks, rekao je da je mnogo vremena potrošio u istraživanju šta je zajedničko u uspelim dizajnima. Ispitivao je primenjene metodologije. I zaključio da one nemaju veze sa uspehom dizajna. Da li su u raspoloživi resursi, ljudski i finansijski pre svega ti koji ključno utiču na uspeh dizajna? Ni to nije ključni faktor. “Napraviti multi-milionsku grešku je vrlo ponižavajuće iskustvo... ali je bar nezaboravno” priznao je Brooks iz sopstvenog iskustva. Jedino što je pronašao zajedničko za sve uspele dizajne je da su iza njih stajali uspešni dizajneri. Nije sigurno da će dobar dizajner uvek napraviti dobar dizajn, ali iza svakog dobrog dizajna stoji dobar dizajner. Naravno, time problem nije rešen, pitanje je samo promenjeno. Kako nastaje dobar dizajner?
Engleski filozof Gilbert Ryle, u svojoj uticajnoj knjizi «The concept of mind» uveo je na velika vrata u zapadnu epistemologiju razlikovanje dve vrste znanja: «znati da» i «znati kako». Iako za zapad nova, ta tema je bila prisutna u taoizmu pre više hiljada godina. Na primer, ja znam da je Beograd glavni grad Srbije. Ja znam kako da vozim bicikl. Prva vrsta saznanja «znati da» je relacija između osobe i informacije, nešto što može da se nauči tradicionalnim pedagoškim metodama u školama i na fakultetima. «Znati kako» da voziš bicikl ne može da se nauči iz knjige. Može da se nauči samo velikim brojem pokušaja i neuspeha i novih pokušaja, najbolje uz nadzor i pomoć nekoga ko «zna kako». «Znati da» se lakše nauči, ali i lakše zaboravi. «Znati kako» se teže uči, ali se nikad ne zaboravlja. Znate li nekog ko je naučio da pliva, pa onda zaboravio?
Discipline koje su između nauke i umetnosti, poput softverskog dizajna, zahtevaju kombinaciju te dve vrste znanja. To što poznajemo metodologije i notacije dizajna softvera na znači da znamo kako da dizajniramo softver. Izgleda da je najbolji način da se uči kako dizajnirato softver ne onaj koji se tradionalno primenjuje na tehničkim faklutetima, vać onaj koji se primenjuje na umetničkim fakultetima. Tamo studenti rade veliki broj projekta, različite veličine i kompleksnosti i stalno su izoženi kritici svojih profesora ali i svojih kolega. Ti studeni takođe stalno vide i rad svojih kolega i kritike upućene njihovom radu. To je na umetničkim fakultetima moguće, zato što su grupe mnogo manje, a entuzijazam profesora i učenika obično veći.

Tao dizajna softvera
Razvoj softvera, a dizajn softvera posebno je između inženjeringa i umetnosti. To nije jedina dihtomija koja može da se primeni na dizajn softvera.

Yang • Inženjering • Funkcionalnost • Metodičnost • Znati da

Yin • Umetnost • Estetika • Prilagodljivost • Znati kako

Suprostavljenost funkcionalnosti i estetike, jasnih pravila i improvizacije predstavljaju suštinske probleme sa kojima se dizajner susreće. Taoizam kroz Yin-Yang koncept uči da su suprotnosti samo prividne i da dihtomije predstavljaju dve strane jedne iste medelje. Prihvatanje tih činjenica čini proces dizajna softvera mnogo težim, ali i dostojnijiim čoveka.




[1] http://pcs.essex.ac.uk
[2] «On System Design», J.Valdo, http://research.sun.com/techrep/Perspectives/PS-2006-6.pdf
[3] «Software design process ontology development», P.Whongthongtham, E.Chang, T.Dillon, International Workshop On Web Semantics 2006
[4] «Uncovering the epistemological and ontological assumptions of software designers», D. King, C.Kimble University of York
[5] “What is software design?”, J.Reeves http://www.developerdotstar.com/community/node/135
[6] «Architecture, Design, Implementation», A.Eden, R.Kazman,
http://www.eden-study.org/articles/2003/icse03.pdf

Software factories – korak ka industrijalizaciji razvoja softvera

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

Implicitna lokalizacija web.sitemap fajla (ASP.Net 2.0)

Implicitna lokalizacija web.sitemap fajla korišćenjem resx fajlova u App_LocalResources folderu ne radi. Za razliku od drugih (aspx) fajlova, u ovom slučaju resx fajlove treba smestiti u App_GlobalResources folder. Tako lokalizacija radi, mada se u design-time pojavljuje greška zbog korišćenja tačke u nazivu identifikatora. Grešku treba ignorisati. Korisni linkovi:
http://forums.asp.net/thread/1307123.aspx
http://msdn2.microsoft.com/en-us/library/ms178427(vs.80).aspx

SQL Server 2000-2005 upgrade i dijagrami

Importovao sam bazu sa SQLServer-a 2000 na SQLServer 2005 i suočio se sa nemogućnošću da vidim/editujem dijagrame. Poruka je "Database diagram support objects cannot be installed because this database does not have a valid owner...". Promena vlasnika baze nije pomogla. Rešenje koje je meni pomoglo je na http://www.sql-server-performance.com/forum/topic.asp?TOPIC_ID=10946

In SQL Server Management Studio do the following:

1. Right Click on your database, choose properties
2. Goto the Options Page
3. In the Dropdown at right labeled "Compatibility Level" choose "SQL Server 2005(90)"
4. Goto the Files Page
5. Enter "sa" in the owner textbox.
6. Hit OK

Druga varijanta (koju nisam probao) je:

EXEC sp_dbcmptlevel 'yourDB', '90'
go
ALTER AUTHORIZATION ON DATABASE::yourDB TO "yourLogin"
go
use [yourDB]
go
EXECUTE AS USER = N'dbo' REVERT
go

Računari i korišćenje naših slova

Danas, kada je prošlo skoro 10 godina od kada je korišćenje znakova iz raznih alfabeta u dokumentima koji se pamte u elektronskom obliku i razmenjuju preko Interneta rešeno na globalnom nivou i teorijski i praktično u Srbiji se idelje diskutuje na tu temu i veliki broj korisnika računara, pa i profesionalaca, ne zna da koristi naša slova tako da svima budu vidljiva, ili, što je možda i gore, izbegava da koristi naša slova. Tako treba dobro promisliti da li je „kuce“ zapravo kuče, ili su u pitanju kuće ili ipak kuce u smislu mali kučići. Ako spadate u ovu kategoriju korisnika a teorijska priča i hronologija ovog problema vas ne interesuje, idite pravo na kraj teksta gde su preporuke šta vam je činiti. U suprotnom, čitajte redom...

Jedan od najstarijih oblika elektronskog zapisa teksta je ASCII standard. Prvobitno je za zapis znakova koristio 7 bitova, što je davalo mogućnost za kodiranje ukupno 128 znakova. U tih 128 znakova spadaju slova engleskog alfabeta, brojevi, znakovi interpunkcije i slično. Kasnije je broj bitova koje ASCII koristi za kodiranje jednog znaka povaćan na 8 (jedan bajt), i to je tzv. prošireni ASCII u kome postoji prostor za još 128 znakova. To je prvi standard koji se koristio u PC eri. Inicijalno, tih dodatnih 128 znakova se koristilo za grafičke simbole za crtanje linija, uglova prozora i slično (za svakog DOS programera čuveni znakovi poput ╣╦╔). Istovremeno, tih 128 dodatnih znakova se koristilo i na druge načine, najčešće da se kodiraju znakovi nacionalnih alfabeta koji ne postoje u engleskom alfabetu. Tako su, na osnovu raznih interpretacija „gornjih“ 128 kodova, nastale čuvene kodne strane. Za naše potrebe Microsoft je definisao kodnu stranu 852 u kojoj razni kodovi od 129-255 označavaju naša slova.

Ali pošto smo mi u fazonu „neće nama neko da diktira standarde“ kod nas se odomaćio potpuno lokalni, nigde priznati nestadard zvan YUSCII koji je „gurnuo“ naša slova u prvih, „donjih“ 128 kodova i to preko nikom, jel, potrebnih znakova kao što su {, }, \ i slično. Primena je bila harrrrrddd/porno – YUSCII je zakivan u EPROM-e (tada aktuelnih) Hercules video kartica i matričnih štampača, dletom i čekićem graviran na tastaturama umesto bespotrebnih izgnanih karaktera... Prva fatalna posledica je bila da je su programeri, kojima su izbačeni znakovi bili potrebni zbog sintakse jezika u kojima su programirali, naša slova omrznuli za mnogaja ljeta, pa i dan danas mnogi kupuju engleske tastature umesto onih sa našim slovima „zato što im računar treba za programiranje“. Druga je bila vizuelna tortura koju trpimo do dan danas –YUSCII je u windows eri implementiran pomoću posebnih fontova, pa YUSCII znakovi, ili nestanu ili grozno izgledaju kad se provuku kroz DTP alate.
Ko nam je „podmetnuo“ YUSCII, o tome se mogu naći razne teorije na Internetu, slične onima na temu ko je Srbima podmetnuo boljševizam. U jednom trenutku to je delovalo kao dobra ideja, ali se istorijski, kao i gore pomenuti boljševizam, pokazala fatalna za dragi nam narod kome pripadamo.

Konfuzija je pojačana sa pojavom Windowsa 95 u kome je podrška za kodnu stranu 852 i neke druge East-Europian kodne strane zamenjena jedinstvenom kodnom stranom 1250 (latinica) odnosno 1251 (ćirilica). U skladu sa našim ustavnim opredeljenjima za srpska regionalna podešavanja prirodan izbor je bila ćirilica. Uz ispravnu instalaciju i izbor kodne strane, naša slova su bila vidljiva u svim standardnim fontovima (Arial, Times New Roman...) ali je ljubav ka YUSCII kvazistandardu i YuTrtmrt.tft fontovima preovladala pa su se odmah pojavile razne zakrpe koje su omogućavale korišćennje YUSCII, a ponekad i 852 kodnog rasporeda na Windows-u (svaka čast momcima koji su ih zakrpe pravili, bili su vođeni zahtevima tržišta... mada se isto može reći za Pink TV recimo). Kao šlag na torti pojavljuje se (sa jedno 10 godina zakašnjenja) i organizacija koja je zadužena za standarde, ISO, i donosi svoj standard za kodiranje slova iz istočnoevropskih apfabeta, ISO8859-2, koji je taman toliko različit od Microsoft CP1250 da zagorča život. Tako smo pre 10 godina već imali potpuni haos – YUSCII, 852 i 1250 kodne strane, plus ISO8859-2, plus razna „home made“ rešenja pa sve to puta 2 kad se u obzir uzme i ćirilica. Veselju nije bilo kraja kad na Windows-u koji podržava CP1250 korisnik hoće da koristi YUSCII a da dokument odštampa na svom matričnom štampaču koji ima 852 kodnu stranicu ugrađenu u EPROM. Frustracije iz tog perioda mnoge nisu napustile do danas, pa beže od korišćenja naših slova ko đavo od krsta.

Rešenje iz ove konfuzije nije nađeno specijalno za Srbe, već za ceo svet i zove se Unicode. Do Unicode standarda nisu doveli (specifično srpski) problemi koje sam opisao, već potreba da se u jednom tekstu slobodno mešaju znakovi koji su do tada pripadali raznim kodnim stranama (zapravo raznim jezicima i pismima). Sporedna, ali za nas veoma važna posledica primene Unicode standarda je da je tekst sa našim slovima čitljiv na svim operativnim sistemima i u svim programima koji taj standard podržavaju. A to su, danas se slobodno može reći, praktično svi programi. Nije bilo lako anglosaksoncima da prihvate Unicode. Jasno je da jedan bajt više nije dovoljan da bi se zapamtio jedan znak i da će dokument koji je kodiran po Unicode standardu biti mnogo duži (u bajtovima) nego dokument kodiran ASCII-jem ili nekim drugim 8-bitnim kodom. To znači više prostora na memorijskim medijima i duže poruke koje se šalju komunikacionim kanalima (Internet). Jednom rečju, koštaće para. Međutim, potrebe globalizacije zahtevale su da se „proguta knedla“ i zapadni svet je prešao na Unicode. Postoji više varijanti implemantacije Unicode standarda koje imaju za cilj da uz zadržavanje podrške za razne alfabete optimizuju (minimizuju) dužinu tekstualnog dokumenta. Za latinične tekstove optimalan i svuda podržan je UTF-8 standard.

Unicode je u svetu široko prihvaćen. Od Windowsa 2000/XP, Unicode je prirodni način za kodiranje teksta u Microsoft operativnim sistemima. Podržan je u sistemima za upravljanje bazama podataka, Office paketu itd. Za razliku od zapadnog sveta, mi, koji imamo direktnu korist od primene Unicode jako smo spori u njegovom prihvatanju iako, realno, za to nema razloga. Jednostavno, Unicode je standard prihvaćen u celom svetu, nezavistan od platforme, i nema indicija da će ga nešto drugo zameniti u skorije vreme. Zato svi u Srbiji treba da se okanu ćorava posla i pređu na Unicode ako već nisu.

Praktične preporuke (uglavnom vezane za rad u Windows okruženju):
Izbrišite sa svog računara sve fontove koji počinju sa YU. Ukoliko vam bude potrebno da koristite neke stare dokumente, pisane po YUSCII , 852 ili sličnim standardima, iskoristite neki od besplatno dostupnih konvertora da stare dokumente prebacite u Unicode/UTF-8. Ja lično koristim VIA konvrtor.
Kupite YU tastaturu ako je nemate. Ignorišite eventualne sugestije prodavca da uzmete englesku. Ili su neobavešteni, ili na engleskim tastaturama koje se prave u većim serijama imaju veću profitnu marginu.
Podesite operativni sistem za na Serbian/Latin kombinaciju.
U e-mail porukama koristite za encoding auto-select ili UTF-8 encoding. Svi će videti naša slova u vašim porukama, bez obzira kakvu tastaturu ili regionalno podešavanje imaju. Jedini izuzetak može da bude Subject poruke ili vaše ime – pojedine „kapije“ kroz koje vaš mail treba da prođe do odredišta mogu da pojedu naša slova u poljima zaglavlja.
Word dokumente pišite korišćenjem naših slova i standardnih fontova. Ceo svet će moći da ih pročita...dobro, bar onaj deo koji je prevazišao Windows 95.
Internet stranice postavljajte sa našim slovima po Unicode/UTF-8 standardu. Ako ručno editujete stranice, u zaglavlju HTML strane treba da piše: meta equiv="Content-Type" content="text/html; charset=utf-8". Tako će ceo svet moći da vidi u njima naša slova.

Kako kroz ASP.Net prikazati slike iz Access baze?

Access pamti OLE objekte a ne slike u bazi pa svaka slika ima dodatni OLE header, koji je dužine 78bajtova (uvek?). Tih 78 bajtova treba skinuti da bi se dobila čista slika. Dalje, Access pamti slike u bmp formatu koji je prevelik za Internet. Zato je poželjno izvršiti konverziju, recimo u jpeg. Evo primera za ASP.Net 2.0. Predpostavka je da Select metod ObjectDataSource1 objekta vraća jedan slog u kome se nalazi polje "slika".

DataView dv = (DataView)ObjectDataSource1.Select();
byte[] b = (byte[])dv[0]["slika"];
MemoryStream ms = new MemoryStream(b, 78, b.Length - 78);
Image i = new Bitmap(ms);
Response.ContentType = "image/jpeg";
i.Save(Response.OutputStream, System.Drawing.Imaging.ImageFormat.Jpeg);
Response.End();

ADO.NET 2.0 TableAdapter

Kad softveraš prelazi iz VS2003/.Net1.1 u VS2005/.Net2.0 okruženje lako odođe u iskušenje da jednostavno konveruje svoje aplikacije koje barataju bazama podataka. Objektni model ADO.Net 2.0 nije mnogo drugačiji od onog u 1.1 verziji. I dalje osnovu čini tandem Dataset i DataAdapter klasa. Međutim u VS2005 okruženju glavnu ulogu preuzima TableAdapter. TableAdapter-i nisu deo framework-a, već se radi o klasama koje generiše VS dizajner (najčešće novi Data Source Confiration Wizard), koje za programera enkapsuliraju rad sa DataAdapter i Connection objektima i koje su intenzivno podržane od vizuelnih alata u VS2005. Velika je stvar što TableAdapter podržava proizvoljan broj select upita (za razliku od DataAdaptera koji podržava jedan select upit) pri čemu wizard za svaki upit generiše metode koji pune/kreiraju Dataset za programera. Na primer, programer sada koristi jedan isti TableAdapter MyTableAdapter da bi dobio spisak artikala, artikle koji pripadaju jednoj grupi ili pojednični artikal ili tako što poziva metode MyTableAdapter.GetProducts(), MyTableAdapter.GetProductsByCategory(string category), MyTableAdapter.GetProductsById(int id).
Iz mog dosadašnjeg iskustva u radu sa TableAdapter-ima mislim da je pri prelasku na VS2005 bolje od početka napisati deo aplikacije koji komunicira sa bazama podataka i iskoristi prednosti koje nudi VS2005 (pored TableAdapter-a tu su i Data Sources i druge džidža midže) nego prosto konvertovati VS2003 projekat.