Planiranje i izrada dokumentacije za programere

[Deleted member 1735]

Naime,
dosad sam i usrednjoj i sada na faxu nailazio na zestoko isinstiranje na pisanju blok dijagrama kao nacin planiranja programa pre samog kodiranja.Naravno ovo svi mrzimo pa me zanima kako programeri koji rade u firmama za pare i profi se bave programiranjem (znaci veoma profi pristupaju izradi plana) prave plan programa i kako izgleda dokumentacija programa posle napisanog programa ?
Ako ima neka knjiga na ovu temu dobro bi mi dosao neki link ili bar ime ?

Ovo pitam kako bi se od pocetka navikao na ove stvari da se posle ne mucim na ovim stvarima.

 

[soulfly]

Nemoj me hvatati bas za svaku rec, ali otprilike to izgleda ovako:
Ako si nekad imao nekad nekakav strani casopis (pa, sigurno)
na temu programiranja i mozda video nekakav formular koji se popuni
kad hoces da se pretplatis, onda si sigurno video koliko je veliki broj
'podzanimanja' u tome - software architect, project leader, team ldr,
app designer, softw. developer i tako jos gomila slicnih koji ti ne bi tako
lako pali na pamet ako nisi imao prilike da vidis malo drugacije, mislim,
kao nesto izdvojeno jedno od drugog. E sad, neki od tih ljudi dugo &
pazljivo pisu jedan veliki book o tome sta, kako i zasto treba program
da radi, i to im se cesto svodi na sistem 'ko ce duze' pa nakraju budu
happy ako ovi 'pravi' programeri (i ovi sto planiraju su takodje ali imaju
vise iskustva + kvalitetnih programa iza sebe) procitaju to do pola.
Ne znam u stvari sta mislis pod dokumentacijom, valjda kao neki
summary ili sta ili help? Kako to ide ovde ja ne znam.....U stvari, ne znam
ni ovo nego sam samo skontao iz konteksta citajuci gomilu stvari. Valjda
im je fora oko tih dijagrama da naucis pravilno i korak-po-korak da
razmisljas. Mada jeste, sve pocinje od olovke i papira.

 

[Deleted member 1735]

Pa ironija je u tome sto sam nabavljao milion cd-a sa tutorialima i knjigama i pretrazivao sam ceo intenet i prakticno nista posebno o tome nisam nasabicno se ovo moze naci u knjigama sa drugom temom ali jako sturo i nedovoljno za nesto ozbiljno.Dok sam mislio da ce ove tcp/ip knjige nesto da mi daju znanja o tome kada one samu teoriju daju i nista vise,a sta ce mi samo teorija kad ne mogu program na osnovu nje da napisem.

 

[Deleted member 1735]

Pardon,ovo je odgovor za jedno drugo pitanje

Evo pravog odgovora:

mene licno zanima kada programeri dobiju na poso da rade neki zadatak cije resenje od pocetka do kraja ne mogu da drze u glavi pa im treba papir i olovka da svoje planove nekako zapisu kako bi kasnije kodirali.E pa na koji nacin zapisuju taj svoj plan (tj da li koriste blok dijagrame-algoritme koje smo mi ucili u skoli -ono tipa kvadratica trouglova itd.) ?

Sto se tice dokumentacije ukapiro sam.

Ajd malo bolje objasni ovo sto si napisao.

 

[silverglider]

Hugh, jednostavno pitanje, a odgovor pocinje da se komplikuje.

Sa jedne strane, tacna je konstatacija soulflya da u svetu postoji jedna gradacija programerskih zanimanja, koja se kod nas uopste ne pominje uopste. A nije tacan deo koji se odnosi na to da pisanje dokumentacije predstavlja gubljenje vremena, jer niko to ne zeli da procita. O zeli, i te kako. Pogotovo na zapadu, gde je normalno da se menjaju firme, pa kad predjes u neku novu firmu usred projekta ili dobijes u nasledstvo da razvijas dalje neki projekat (tip nova verzija), da vidis kako ces ljubiti svaki list dokumentacije. Nema svaka firma vremena ni ljudstva da odvoji petoricu da tebe upoznaju sa temom "o cemu se radi", niti ce cekati tebe godinu dana dok se ti sam ne upoznas sa materijom. Ovakva fluktuacija radne snage je samo jedan primer gde dokumentacija dobro dodje.

Sami blok-dijagrami se ne koriste toliko mnogo u praksi. Pogotovo ne za sitne zadatke, kao sto forsiraju u skolama. Sam naglasak na blok-dijagram je nestao prelaskom sa strukturiranog programiranja na objektno. Onda su se i dijagrami morali baviti malo apstraktnijim stvarima i uvidelo se da nisu dovoljni da opisu stanje i ponasanje klasa i slicno. Osim toga, kada bi se svaka sitnica opisivala dijagramima, dokumentacija bi bila veca od svakog programa. Zato se to sve prosirilo i opisuje se danasnjim UML alatima (Unified Modeling Language). Takvi alati moraju objedinjuju funkcionalne opise sa apstraktnog gledista, dakle Use Cases, sa tokovima podataka, kao i modelovanje klasa. Vecina njih omogucava povezivanje modeliranja klasa sa modeliranjem modela baza podataka, gde se se objekti definisanih klasa skladistiti. Definicije klasa, relacije izmedju njih, gradjenje komponenti programa od tih klasa, definicija dogadjaja, zadataka, itd. U takvim alatima je predvidjeno da se lako odradi dokumentacija za svaki definisani entitet. Ako se ne radi suvise apstraktno, takav alat moze da generise kod na osnovu sintakse koju podrzava (prihvatljvo uz neke rucne izmene generisanog koda). Bolji UML alati podrzavaju i re-inzenjering, tj obrnuti put - da imporujtujes source (recimo header fajlove) i on ce od toga generisati dijagrame i ostalo. Uglavnom, da ne komplikujem sada odgovor, to predstavlja vrlo siroko polje, pocni od par sajtova koji opisuju UML, kao sto je ovaj.

Posto se uglavnom polazi od premise da se posao zna uraditi, zadatak ovakvih alata je da odredi nacin na koji ce se zadatak implementirati. Na primer, kao single-exe, sa dll-ovima, sa pluginovima i slicno. To utice dobrano na strukturu programa/paketa i odabir tehnologija (COM/DCOM, vrsta baze, itd). Ako se vratimo skaliranju programerskih zanimanja, taj posao radi Software Architect. Dakle, covek koji ima iskustvo, siroko znanje, dobar OO dizajn i smisao za planiranje. U timu treba da postoji jos par Software Developera, koji uticu na dizajn i preuzimaju na sebe implementaciju pojedinih delova sa svojim pod-timovima. U pod-timu se nalaze obicni programeri kao "fizikalci", grubo receno.

 

[soulfly]

Tacno je ovo sto je napisao silverglider. Same te blok-seme se vrlo malo, skoro uopste i ne koriste. Logicno je - za nesto jednostavno dijagram ti bas i ne treba, a za ozbiljne stvari bi to bilo suvise glomazno i skroz neprakticno. Koristi se UML, i to kao sto si cuo najvise za klase i uopste OOP, npr. Visual UML uopste ni nema podrsku za form-module u VB-u, a mislim ni za obicne module, nisam siguran. Ima i onaj BizTalk za internet-related stvari, to je stvar licnog ukusa i/ili firme, ali UML je standard. Imas knige u vezi s njim naravno, i nasi su izdali/preveli neke. Cilj je da tebi ili developerima bude rasclanjeno i jasno kako stvar funkcionise, kao i novopridoslim, kao sto kaze sg. Ono sto je banalno ili jednostavno uglavnom nema potrebe ni za kakvim grafickim prikazom, dosta tu prodje vremena osim ako nekom to crtanje nije jako zabavno, vec za prave projekte koji se sastoje iz vise DLLa i pomocnih fajlova, a pogotovo za internet aplikacije (transferi i sl.). Ti alati imaju dosta stvari koje olaksavaju zivot, pocni recimo od Visual Modelera iz VStudia.

 

[macak]

Danasnje softverske kuce koje drze do sebe vrse projektovanje sistema na nacin i koristeci strucnjake i alate koje su gore opisali silverglider i soulfly.
Medjutim, poenta je zasto se sve to bas tako radi.
Kada o ovome pricamo ne misli se na neke sicusne programcice od par stotina linija koda (mada zavisi od kompleksnosti), vec na projektovanje tzv. "softverski intenzivnih sistema". Nekada, kada su programi bili linearni i OS bili monoprogramski, dosta su se koristili flowchart dijagrami, ali i oni samo za opis nekih zestokih rutina i na razlicitim nivoima hijerarhije. Danas su sistemi mnogo komplikovaniji bilo to obicni programi, OS ili softverski intenzvini sistemi: imas multiprogramske OS, programi su event-driven i daleko od linearnosti, multithread gde svaka nit ima svoj prioritet, programiranje sistema za rad u realnom vremenu... Opsti show danas moze da se konstriuse.
Fora je u 3 stvari: poimanje problema projektanta sa porastom slozenosti drasticno opada, potrebno je sto vise omoguciti ponovno koriscenje koda (reusable code) i potrebno je omoguciti sto je moguce lakse odrzavanje (to ti je ono: kada posle godinu dana pogledas kako nesto radi, da ti na osnovu modela i dijagrama odmah bude jasno sta si radio, da ne lupas glavu zasto je to bas tako i ako sada nema nikakve logike u tome ).
Na ove dve poslednje stvari mnooogo love odlazi. Zato je i uvedeno objektno (orijentisano) programiranje OOP i modelovanje.
Osnovni principi objektnog modelovanja su: apstrakcija - apstrahovanje problema i resavanje problema iz ugla korisnika, a ne programera ; hijerarhija - nasledjivanje i sta kome pripada; enkapsulacija - tajnost koda (zato postoji private i protected prava pristupa i header i cpp fajlovi) i modularnost - podela problema na fizicki razdvojene module. Sve ovo vodi do toga da se prvo do detalja projektuje neki softver, pa posle pisanje koda predstavlja samo puko fizikalisanje, mada ti u tome moze delimicno pomoci CASE alat, kao sto je recimo Rose firme Rational koji ima opciju generate code.
Npr. danasnji C++ kompajleri mnogo bolje mogu da optimizuju kod po pitanju brzine i velicine nego sto bi to uradila gomila programera. Zato se ne ide na neko posebno optimizovanje koda (da li program ima 2.2MB ili 2.195MB - nebitno!) vec se naglasak baca na citljivost. Hakerisanje po kodu (kao pisanje rutina u asembleru pod DOS-om da bi program bio sto brzi, manji i nerazumljiviji) nije pozeljno. Potrebno je pisati CITLJIVE programe, jer kada ti posle 6 meseci dodje sef i kaze da treba da se napravi verzija 2.0 programa na kojem ste radili 5 meseci i ako tebi treba 2 meseca da ti samo provalis tvoj prethodno napisani kod (a sveki sat se placa!) - letis s posla.
Zbog svega ovoga, prvo se ispituje sta i kako program treba da radi (mozda se i trziste ispituje radi isplativosti pokretanja projekta). Potom se uradi detaljna specifikacija sta, gde i kako treba da izgleda i da radi. Onda razni Software Architect, Designer, Developeri i ostala ekipa se odluce i dogovore o vrsti arhitekture, protokolima, i svemu relevantnom u vezi paketa i kada se odluce (eventualno mozda urade simulaciju preliminarnog projekta - sve zavisi od slozenosti i sistema, mozda je potreban i neki specifican hardware koristiti) onda se sistem deli na podsisteme. Specificira se svaki podsistem i strogo i tacno se definisu veze sa ostalim podsistemima. Takodje se na nivou sistema i podsistema sa odredjenim stepenom detaljnosti opisuju staticke karakteristike (dijagram klasa, paketa,...), kao i dinamicke karakteristike (dijagrami interakcija, kolaboracija,...) - sve ovo se obicno radi u nekom programskom paketu specijalizovanm za to, npr. Rational Rose-u koji koristi UML (imas i super knjigu o UML-u koji je danas neka vrsta standarda). Ovaj opis sistema obicno radi covek zaduzen za to ili ceo tim i oni su ti koji modeluju sistem na osnovu nekih specifikacija. Recimo, neki softverski paket koji sadrzi u sebi 450 klasa - bez CASE alata je nemoguce pohvatati sve veze i zavisnosti, jos ako imamo i aktivne objekte (threads)... Na kraju, na osnovu dobro definisanog sistema u UML-u, vrsi se pisanje koda koje predstavlja vise manje rutinu, sem mozda nekih vremenski ili hardverski kriticnih delova kojima se poklanja posebna paznja, ali oni obicno i cine samu srz sistema.
Na kraju se obicno za svaki deo sistema i koda pise dokumentacija koja opisuje sta i kako radi, prilaze se source sa svim header i eventualno .cpp fajlovima kao i modeli na svim nivoima u UML-u (ima i drugih, ali ovaj jezik je danas neka vrsta standarda) - i sve to bi vise manje cinilo dokumentaciju nekog dobro projektovanog i opisanog sistema.

Uhhh, ceo esej! Malo sam udavio, ali generalno sa nekim manjim ili vecim razlikama to otprilike (bar bi tako trebalo) ide.
Tako da, nauci ti za pocetak flow-charts, a onda ces vec videti sta te ceka ako odes u iole ozbiljniju firmu jer projektovanje bez ovih alata je muka teeeska (znam iz iskustva).