Sandra, baš sam se ovih dana spremao da pitam šta bi moglo da dođe u obzir kao case. Nekada sam koristio Rational Rose. Zadnjih par godina ne koristim ništa ali mi sada baš treba. Meni je bitan ceo proces ali najviše modeliranje use case-ova, object model, interaction dijagrami, state dijagrami, generisanje koda i reverzni inžinjering. Baza mi nije prioritet. Naravno, integracija sa VS 2005 je must.

Nisam pomogao ali, bar da malo podrgrejem atmosferu.

Nesto mi se ne cini da smo "podgrejali" atmosferu :))))

Imas Visio, u njemu se svasta modeluje, ja sam ga na kratko koristio za jednu bazu ali brzo sam digao ruke, Erwin je daleko bolji ali je mator, bar ovaj koji ja imam a i mislim da nije dugo izasla nova verzija.

Visio je za crtanje, nisam sigurna bas koliko je to case alat... ERwin je OK, ali ja sam ga uglavnom koristila za modeliranje baze... A sad - hajde da ostavimo po strani alate - koju metodologiju primeniti?

Nisam mnogo radio sa Visiom ali koliko me secanje sluzi mozes dosta toga generisati (recimo iz UML-a u code) ali iskreno uvek sam se pitao ko moze tako da radi, ne znam bar ja ne mogu, bar ne sad. Inace moje misljenje je da modelovanje pomaze u vecim projektima i timovima, ako radis sam/a ili dvoje (recimo kao ja ) to je samo dodatni posao bez kojeg se, u sta sam veoma uveren, moze. Sto se tice metodologije to ce ti morati odgovoriti iskusniji.

Evo par starijih linkova, doduse nisu mozda usko vezani za tvoje pitanje ali mislim da ima dosta kvalitetnih odgovora
http://www.elitemadzone.org/t1...za-projektovanje-baza-podataka
http://www.elitemadzone.org/t8088-0#257612

Nisam probao Visio za 2005 ali, ako nije PUNO bolji od verzije 2003, zaboravite. Doduše, dobar je za crtanje rasporeda nameštaja po sobi, da ne secam šifonjere za badava.

Odlična tema o kojoj ima mnoooogo da se piše!!!

Što se tiče modelovanja...evo ovako stoje stvari:

Osamdesetih godina iskusni programeri su počeli sa opisivanjem kontrolisanog procesa razvoja softvera, od opisa zadatka do održavanja gotovog proizvoda. Ovo je dovelo do stvaranja strukturne metodologije kao što je SSADM (Strukturna Sistem Analiza i Dizajn Metod). Metodologija predstavlja opis koraka kroz koje razvojni tim treba da prođe, a u cilju stvaranja visoko-kvalitetnog sistema.
Devedesetih godina, objektno orijentisano programiranje preuzima dominaciju i projektanti počinju da rade na Objektno-Orijentisanim Metodologijama, prijemčivijim objektno -orijentisanom programerskom stilu. Rane OOM uključuju Booch metod [Booch 93], Objectory metod [Jacobson 92] i OMT [Rumbaugh 91], nastaje i Rational Unified Process kao i metodologija koja sve više dobija na popularnosti eXtreme Programming.

Metodologija je sistematski način rada. Ona je ponavljajući (repeticioni) proces koji omogućava postupak praćenja razvoja softvera od njegove najranije faze do održavanja instaliranog sistema. Metodologija specificira očekivani proizvod prateći njegov proces (kao i formu datog proizvoda).
Iako je većina metodologija dizajnirana da izađe na kraj sa timovima projektanata koji proizvode veliku količinu softvera, razumevanje osnova dobre metodologije je veoma bitno i za projektante koji rade na malim projektima. Razlog za to je :
 Metodologija pomaže pri nametanju discipline prilikom kodiranja.
 Prolaženjem kroz osnovne metodološke korake povećava naše razumevanje problema, poboljšavajući kvalitet našeg rešenja.
 Omogućava nam uočavanje konceptualnih i praktičnih gršaka pre nego što ih unesemo u izvorni kod.
 Na svakom nivou metodologija specifikuje naš sledeći korak.
 Metodologija nam pomaže da proizvedemo proširiv kod ( koji se lako menja ), kod koji se može koristiti za rešenje i drugih problema i koji je lakši za pronalaženje grešaka (jer je dobro dokumentovan).

Veliki razvojni projekti su takođe na dobiti:
 Dokumentacija: Metodologija obuhvata postupak dokumentovanja svake faze razvojnog truda, tako da za završeni sistem nije nepristupačno monolitan.
 Smanjenje vremena pristupa: Pošto su poslovni tokovi, aktivnosti, uloge i zavisnosti razumljiviji, javlja se manja mogućnost da proces stoji u redu za čekanje resursa.
 Povećava se šansa za isporukom na vreme i bez probijanja budžeta.
 Princip ponovljivosti: Pošto imamo dobro definisane aktivnosti, slični projekti bi trebalo da se isporučuju sa sličnim vremenskim rokom i sa sličnim cenama. Ako proizvodimo slične sisteme iznova za različite kupce možemo težiti ka metodologiji koja će se koncetrisati na jedinstvene aspekte poslednjeg projekta eventualno možemo automazizovati delove projekta i prodavati ih drugim proizvodnim timovima.

Dobra metodologija je sačinjena od :
 Planiranje: Odluka o tome šta treba da se uradi.
 Spiskovi: Mapiranje stvari koje treba učiniti.
 Sredstva: Proračunavanje ljudskih, softverskih, hardverskih i ostalih potrebnih resursa.
 Poslovni tokovi: Dizajniranje arhitekture sistema, modeliranje domena problema i planiranje projektantskog truda.
 Aktivnosti: Individualni zadaci sa poslovnim tokovima, kao što je testiranje komponenata, crtanje dijagrama klasa ili detaljnog use case dijagrama, ...
 Uloge: Odigrane u okviru metodologije (projektant, tester ili prodavac).
 Edukovanje: Odluka na koji način trenirati osoblje, ukoliko je nephodno, da bi odigrali svoje uloge; odluka na koji način će krajnji korisnici naučiti da koriste sistem.

,a zatim, kao logičan sled se nadovezuju faze u izradi softvera:

Postoje brojne faze koje su zajedničke za razvoj softvera, u zavisnosti od metodologije, počevši od snimanja zahteva pa do održavanja. Tradicionalni pristup omogućava prelaz sa jedne faze na drugu. Moderni, međutim, dozvoljava izvođenje svake faze više od jednom i u bilo kom redu. Sledeća lista objašnjava najčešće faze u izradi softvera.

1. Spisak zahteva
otkriva šta želimo da postignemo sa novim softverom i ima dva aspekta:
 Poslovno modelovanje (Business modeling) – razumevanje konteksta u kom će novi softver raditi
 Funkcionalna specifikacija – definisanje mogućnosti softvera. Šta će novi softver raditi, a šta neće tako da na osnovu toga možemo proceniti kada smo završili i da li smo zadovoljni novim softverom.

2. Analiza
Omogućava da spoznamo „sa čime imamo posla“. Pre nego što dizajniramo rešenje moramo biti svesni relevantnosti, svojstava i veza. Takođe moramo biti u stanju da dokažemo naše razumevanje. Ovo može uključiti kupce i krajnje korisnike jer oni jesu eksperti za datu oblast.

3. Dizajn
U ovoj fazi razmatramo kako rešiti problem. Donosimo zaključke bazirane na iskustvu, proceni, intuiciji, kakav ćemo softver napisati i kako ćemo ga razviti. Sistemski dizajn razbija sistem na logičke podsisteme (procese) i na fizičke podsisteme (kompjuteri i mreže), odlučuje kako će mašine komunicirati, odabira korektnu tehnologiju za posao,... U dizajniranju podsistema odlučujemo kako prevesti logički podsistem u koristan,efektivan i praktičan kod.

4. Specifikacija
Specifikacija je jedna od često ignorisanih i zanemarenih faza u procesu razvoja.Sam termin „specifikacija“ se koristi u različitom kontekstu što zavisi od projektanata.Npr. izlaz iz faze „spisak zahteva“ je specifikacija koja kazuje za šta je sistem osposobljen , izlaz iz analize je specifikacija koja nam ukazuje sa čime radimo „sa čim imamo posla“.Specifikacija klase je čist, precizan opis korištenja komponenti našeg softvera, njihovog ponašanja ukoliko se koriste pravilno. Specifikacija se koristi u sledećim slučajevima:
• Kao osnova za dizajniranje test softvera za ispitivanje sistema
• Za demonstraciju korektnosti,ispravnosti softvera
• Za dokumentaciju softverskih komponenti i okvira u kojima se mogu koristiti od strane trećeg lica
• Za opis ponovnog korištenja koda u okviru drugih aplikacija
Faze koje spadaju u klasične faze razvoja softvera su uvođenje i održavanje.

, pa onda metode ili modeli (Vodopada,Spiralna, iterativna,inkrementalna,...).

Sto se tiče SSA_DM (gore pomenute) ona se sastoji iz sledećeih koraka:
1. Analiza sistema
Poznata i kao „Studija izvodljivosti“. Koristi Dijagram Toka Podataka za opis rada sistema i vizualizaciju poznatih problema.
Obuhvata sledeće korake:
a. Razvoj Business Activity Model-a. Poslovni događaji i pravila se istražuju kao ulaz u specifikaciju novog automatizovanog sistema.
b. Pronalaženje (Ispitivanje) i definisanje zahteva. Identifikuju se problemi u vezi sa okruženjem koji će biti rešeni od strane novog sistema.
c. Ispitivanje procesiranja. Istražuju se tokovi informacija u saradnji sa postojećim uslugama i opisuju u formi Modela Toka Podataka. U datom stadijumu MTP predstavlja tekuće servise (usluge) sa svim nedostacima.
d. Ispitivanje tekućih podataka. U ovom koraku se identifikuje i opisuje struktura podataka sistema nezavisno od načina trenutnog skladištenja i organizovanja podataka.Ovaj korak rezultira kreiranjem modela podataka koji podržava tekuće servise (usluge).
e. Izvođenje logičkog pogleda tekućeg servisa. Razvija se logički pogled na dati sistem kako bi se omogućilo razumevanje problema tekućeg sistema.

2. Opis poslovne specifikacije
Poznata i kao logička etapa specifikacije sistema. Sastoji se iz dva dela. Prvi deo je istraživanje postojećeg okruženja i obuhvata identifikovanje zahteva sistema i modelovanje poslovnog okruženja. Modelovanje čini kreiranje DTP i Logičke Struktura Podataka za procese i strukture podataka koji su deo sistema. Drugi deo se sastoji u odabiru i izgradnji jedne od 6 Poslovnih Opcija Sistema (Business Systems Options). Sledeći koraci su deo etape:
a. Definisanje BSO. Identifikuje se broj mogućih rešanja sistema koji udovoljavaju definisanim zahtevima od kojih će korisnik načiniti odabir.
b. Odabir BSO. Vrši se prikazivanje BSO korisnicima i zatim korisnik odabira željenu opciju.

3. Detaljna specifikacija sistema
Poznata kao specifikacija zahteva. Obuhvata sledeće korake:
a. Definisanje zahtevanog procesiranja sistema. Ovaj korak teži ka prilagođavanju zahteva kako bi reflektovali odabran BSO , opisali zahtevani sistem u pogledu tokova podataka sistema, i definisali korisničke uloge novog sistema.
b. Razvoj modela podataka. Ovaj korak se odvija paralelnoi sa prethodnim. Logički model podataka datog okruženja se prosiruje kako bi podržao sva procesiranja u odabrana u BSO.
c. Izvođenje funkcija sistema. Za vreme paralelnog definisanja podataka i procesa, dodatni događaji su identifikovani, što je dovelo do ažuriranja postojećih i definisanja novih funkcija.
d. Razvoj specifikacije korisničkih poslova. Razvijen je Work Practice Model kako bi se dokumentovalo razumevanje poslova korisnika u potpunosti.
e. Poboljšanje modela podataka. Poboljšanje kvaliteta logičkog modela podataka datog sistema primenom relacione analize podataka (poznate i kao normalizacija)
f. Razvoj prototipa specifikacije. Opisuje odabrane delove sistema u prilagodljivoj formi demonstracije za korisnika.
g. Razvoj specifikacija obrade (procesiranja).
h. Potvrda sistemskog cilja (pravca sistema)

4. Logički dizajn podataka
Poznat i kao logička specifikacija sistema. Vrši se odabir opcija koje su tehnički naj izvodljivije. Razvojno/implementaciona okruženja se specificiraju na osnovu ovog izbora.
Faza je sastavljena iz :
a. Definisanja BSO. Uvom slučaju identifikuju se i definišu mogući pristupi fizičkoj implementaciji kako bi se udovoljilo definiciji funkcija.Takođe se vrši validacija zahteva na nivou servisa za predloženi sistem u svetlu tehničkog okruženja.
b. Odabir BSO. Ovaj korak obuhvata prezentaciju BSO-a korisnicima i odabir željene opcije.

5. Logički dizajn procesa
Takođe poznat kao logička specifikacija sistema. Vrši se ažuriranje logičkog dizajna i procesa. Moguća je i specifikacija dijaloga.
Obuhvata :
a. Definisanje korisničkih dijaloga. Definiše se struktura svakog dijaloga.
b. Definisanje procesa ažuriranja. Specificira se postupak ažuriranja za svaki događaj i definiše obrada greške za svaki događaj.


6. Fizički dizajn
Cilj ove faze je specifikacija fizičkog dizajna podataka i procesa, korišćenjem rečnika i karakteristika odabranog fizičkog okruženja i inkorporiranih standarda.
Delovi etape:
a. Priprema za fizički dizajn
 Korištenje pravila implementacionog okruženja;
 Pregled preciznih zahteva za logičko i fizičko mapiranje;
 Planski pristup;
b. Kompletiranje specifikacije funkcija
c. Inkrementalno i repetitivno razvijanje dizajna podataka i procesa.



Tri najbitnije tehnike koje se koriste u SSADM su:
1. Logičko modelovanje podataka – identifikacija, dokumentovanje, modelovanje zahteva sistema koji se dizajnira.
2. Modelovanje toka podataka - identifikacija, dokumentovanje, modelovanje prenosa podataka u informacionom sistemu.
3. Modelovanje ponašanja entiteta - identifikacija, dokumentovanje, modelovanje događaja koji utiču na svaki entitet i sekvenci u kojima se „okidaju“ događaji.

Inače se koristi CASE alat ProcessAnalyst ( .pam -model)




Objektno orijentisana metodologija (UML!!! PowerDesigner toplo preporučujem – što noviji to boljiji )

Globalno govoreći, sve objektno orijentisane metodologije su slične, imaju slične faze i artifakte, ali postoje brojne male razlike.
Namera OOM nije da propisuje pravila: projektanti imaju brojne mogućnosti i slobode izbora oko korištenja dijagrama ili nekih drugih artifakta. Međutim, projektni tim mora izabrati jednu metodologiju i složiti se oko artifakta koje će stvarati, pre nego što počne bilo kakvo detaljno planiranje ili popis.
Generalno, svaka metodologija upućuje na:
• Filozofiju iza svake faze
• Poslovne tokove i individualne aktivnosti svake faze
• Artifakte koje treba proizvesti (dijagrami, tekstualni opisi i kod)
• Zavisnosti između artifakta
• Potrebu za modelovanjem statičke strukture i dinamičkog ponašanja

Statičko modelovanje obuhvata delovanja nad logičkim i fizičkim delovima sistema i načinu na koji će oni biti povezani. Dinamičko modelovanje je posvećeno izboru načina kolaboracije statičkih delova. Grubo govoreći, statički model opisuje konstrukciju i inicijalizaciju sistema, dok dinamički model opisuje kako će se sistem ponašati za vreme rada. Uglavnom se proizvede jedan statički i jedan dinamički model u toku svake faze modelovanja.


UML, RUP i XP
Godine 1996, Jacobson i Rumbaugh pridružili su se Rational Corporation (osnovane od strane Booch-a), i razvili set notacija koje su postale poznate kao Unified Modeling Language (UML). Neki projektanti svrstavaju UML kao notaciju za brainstorming i dokumentovanje na visokom nivou, drugi pak svrstavaju UML u slikovni programski jezik, koji generiše nov kod iz postojećeg koda.
Cilj jednistvenog jezika modeliranja (UML-a), kako su ga postovali njegovi autori, je višestruk:
• da predstavi kompletni sistem (ne samo softverski deo) korišćenjem OO koncepata;
• da uspostavi eksplicitnu vezu između koncepata i izvršnog koda
• da uzme u obzir faktore skaliranja koji su ugrađeni u kompleksne i kritične sisteme
• da bude sredstvo modeliranja upotrebljivo i za čoveka i za mašinu


Rational Unified Process je spiralni, iterativni, inkrementalni metod nastao od tvoraca UML-a. Može se reći da je to metodologija koja izdvaja najbolje aspekte UML-a.

Još jedna popularna metodologija je eXtreme Programming [Beck 99] smatra se brzom,efikasnom metodologijom jer dozvoljava i reaguje na promene. XP se odlikuje dvema osnovnim idejama: par programera i projektovanje navođeno testiranjem. Programeri rade, pre svega, na poboljšanju kvalieta softvera i na testiranju ali tako da test bude napisan i pre samog koda.

UML Standard koji se primenjuje kod objektno orijentisanog pristupa predviđa sledeće poglede na sistem, s tim što se u svakom pogledu sistem može opisati sa statičkog (strukturnog) i dinamičkog aspekta:

• Pogled slučajeva korišćenja(Use-case view) - predstavlja skup slučajeva korišćenja. Predstavlja se preko dijagrama slučajeva korišćenja - statički aspekt. Dinamički aspekt sistema se ovde daje bilo verbalnim opisom slučajeva korišćenja, ili formalnim opisom, preko dijagrama interakcije, dijagrama aktivnosti i dijagrama promene stanja.

• Projektni pogled (Design view): Statički aspekt sistema se ovde prikazuje preko dijagrami klasa i dijagrami objekata, a dinamički aspekt preko dijagrama interakcije, dijagrami promene stanja i dijagrami aktivnosti.

• Procesni pogled (Process view)- prikazuje "niti upravljanja" i procese preko kojih se ostvaruje konkurentnost i sinhronizacija procesa u sistemu. Preko ovoga pogleda prvenstveno se analiziraju performanse, skalabilnost i propusnost sistema. Pretstavljaju se sa istom vrstom dijagrama kao i projektni pogled, samo se akcenat stavlja na "aktivne klase"- klase koje reprezentuju procese i niti.

• Implementacioni pogled (Implementation view) - prikazuje komponente i fajlove sa kojima se sistem realizuje. Statički aspekt se prikazuje dijagramima komponenti, a za dinamički se koriste dijagrami interakcije, dijagrami promene stanja i dijagrami aktivnosti.

• Pogled razmeštaja (Deployment view) - prikazuje sistemsko- hardverska topologiju. Prikazuje se distribucija hardverskih komponenti i instalacija softverskih komponenti na njima. Statički aspekt se opisuje dijagramima razmeštaja, a za dinamički se ponovo koriste dijagrami interakcije, dijagrami promene stanja i dijagrami aktivnosti.


Ako vas zanimaju i detalji i konkretna realizacija rado ću vam ostaviti još dosta texsta čim završim diplomski koji pišem na tu temu (Projektovanje i implementacija softvera...)
inače ovo je samo deo priče o razvoju softvera, metodologijama koje se koriste itd...

Sjajan tekst, nema sta :) Hvala! Ako imas konkretan primer, koji prolazi kroz sve faze modelovanja RUP-a ili neke druge metodologije, to bi bilo sjajno.

Object-Orijented Analysis & Design (Understanding System Development with UML 2.0) Mike O'Docherty
Korak po korak...
Toliko za sada

Zaboravili ste i Agile modelling.


Ja bih licno savetovao oprez. Opsta je pomama svuda u svetu da se skracuje development proces i mnogi obecavaju kule i gradove kroz svoje metodologije i tehnike, iako im to nije osnovna namena. Na kraju se sve to pretvori u los proizvod kad metodologija ne ispuni ocekivanja i kad krenu da se skracuju rokovi i funkcionalnosti da bi se ispostovao nerelan budzet/timeline.

UML je odlican, ali evo ima bar 5 godina kako nisam video nijedan UML dijagram niti radio ijedan, jednostavno business nije zainteresovan da ceka izrade monolitnih aplikacija sa sve projektantskim delom, oni hoce rapid response na promene na trzistu. Puno ljudi se zakacilo za XP kao odgovor na te zahteve i to je uz retke izuzetke bila totalna propast. Ako sad pogledate internet na 1 clanak/knjigu o XPu ide 10 clanaka/knjiga na temu "kako prepoznati XP pitfalls", "kako resiti probleme izazvane XPem", itd, itd. Realno kad pogledas sve korake opisane u boomLM-ovom postu vidi se da ti treba armija ljudi i resursa da isprojektujes softver pre nego se ukuca i linija koda, i to je totalno ispravan i odlican proces, ali proces koji je veoma tesko prodati biznisu i tu se prave kompromisi koji ce na kraju sahraniti projekat.

Od svih tih post-UML new age metodologija jedino je (bar po meni) Agile u situaciji da nesto realno doprinese, pod uslovom naravno da prodje test vremena. Kao dodatak na Agile, Agile modeling nudi da u taj rapidni proces unese UML modeling. Posto ja jos nisam imao prilike da to vidim na delu, bilo bi super ako je neko radio Agile modelling na konkrentom projektu da iznese svoje utiske...

Slažem se sa Sandrom da je text sjajan. Mene interesuju klasične faze kod razvoja softvera:)

To bi verovatno bio Waterfall model. Koliko sam shvatio (malo više teorije, a manje prakse;)), u modernom projektovanju nijedna faza nije baš 100% gotova odjednom, već prolazi kroz niz iteracija i "popravki", što je u suprotnosti sa pomenutim vodopadom...

Evo dela diplomskog rada radjenog na T.F. "Mihajlo Pupin"
Pridodat je samo teoretski deo bez UML modela jer to je vec posebna priča...
Nadam se da će nekome pomoći, a očekujem i sve vrste kritika... [email protected]
Poz

Ovaj rad mi je od veeelike pomoći,nadam se da još neko ima nešto na ovu temu. Hvala najljepša. Drago mi je da na forumu ima ovako dobrih ljudi. Nadam se da ću i ja biti nekom od pomoći

<sub>[Ovu poruku je menjao VIJA dana 23.08.2007. u 11:32 GMT+1]

[Ovu poruku je menjao VIJA dana 23.08.2007. u 11:59 GMT+1]</sub>

ne znam da li nekoga zanima modelovanje (ili modeliranje, šta je ispravno?) poslovnih procesa, ali jedan od moćnijih alata sa kojima sam se susreo je ARIS koji je razvio IDS Scheer, originalno u saradnji sa SAP R/3. to je grafička metoda koja koristi EPC (Event-driven Process Chains) dijagrame za predstavljanje poslovnih procesa. pruža dosta mogućnosti a relativno je jednostavan i intuitivan, i razumljiv (što je i bio cilj) različitim ljudima, bez obzira na to koliko su ljudi upoznati sa poslovnim procesima i modeliranjem istih.

Koliko desetina hiljada eura kosta licenca?