[es] - Alati za modelovanje

boomLM
Misa Boom

Član broj: 96472
Poruke: 85
*.spicacentar.co.yu.

Profil

^{04.06.2007. u 19:49 - pre 205 meseci}

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...

Odgovor na temu