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