Preuzmite PROJEKTOVANJE SOFTVERA i više Rezime u PDF od Projektovanje informacionih sistema samo na Docsity!
Elektrotehniči fakultet Univerziteta u Beogradu
Katedra za računarsku tehniku i informatiku
skripta za predmet
PROJEKTOVANJE SOFTVERA
Igor Tartalja
Beograd, 2011.
Besplatan primerak This copy is not for sale
Ova skripta je objavljena u okviru projekta WUS Austria MSDP 2011 The publishing of this script is part of the project MSDP 2011 finansiranog od strane Austrijske agencije za razvoj financed by Austrian Development Agency through WUS Austria
4 Predgovor
Elektrotehnički fakultet u Beogradu
kombinuju, tako da se na predmetu simultano napreduje kroz obe oblasti. Na taj način se studentima omogućava da vrlo rano počnu da uvežbavaju metodologiju projektovanja na jeziku UML uz korišćenje projektnih uzoraka. Iz tog razloga su i projektni uzorci izloženi redosledom primerenim blagovremenom uvežbavanju, počeviši od onih koje je lakše razumeti i primeniti, kombinujući ih sa do tada obrađenim dijagramima jezika UML.
Autor se zahvaljuje svima koji su na bilo koji način doprineli nastanku ovih skripti. Posebnu zahvalnost autor duguje kolegi mr Laslu Krausu. Dugogodišnja saradnja i plodne diskusije o problematici, kako ovog predmeta, tako i predmeta iz objektno-orijentisanog programiranja, pomogle su autoru da izgradi terminologiju i razvije metodologiju rada na predmetu. Kompletiranje završne verzije ovih skripti pomogla je Austrijska agencija za razvoj , kroz projekat Master Studies Development Program (MSDP 2011) , WUS Austrija. Recenzenti izveštaja na projektu MSDP 2011, Johann Höchtl i Sylvia Purgathofer-Müller, dali su korisne savete da skripta dobiju konačni oblik. Konačno, autor se zahvaljuje studentima ranijih generacija koji su ukazali na propuste i greške u ranijim materijalima na osnovu kojih su nastala skripta u ovom obliku.
U uverenju da će skripta biti od koristi studentima koji prate predmet Projektovanje softvera , autor se nada da će im izložena materija biti interesantna i podsticajna, kako za pripremu ispita, tako i za buduću inženjersku praksu. Moli ih da čitaju pažljivo, a za sve propuste i greške koje otkriju i prijave mu, biće im veoma zahvalan.
Beograd, 15.06.2011. Autor
Projektovanje softvera
7
8 Sadržaj
10 Sadržaj
11
Uvod 13
Projektovanje softvera
Uvod
Osnovni pojmovi
- Svaki ozbiljniji projekat prolazi kroz faze:
analiza, projektovanje, implementacija, testiranje
- slično je sa SW projektima, kroz faze se prolazi iterativno
- Objektno-orijentisana metodologija razvoja
- dominantna u proizvodnji softvera danas
- Pojmovi
- objektno-orijentisana analiza – OOA
- objektno-orijentisano projektovanje – OOD
- objektno-orijentisano programiranje – OOP
- objektno-orijentisani jezik – OOL
Objektno-orijentisana analiza
- Tradicionalne tehnike strukturirane analize
- fokus na toku podataka u sistemu
- Booch (1994): Objektno-orijentisana analiza je metod analize koji ispituje zahteve
iz perspektive klasa i objekata pronađenih u rečniku iz domena problema
- Proizvod OOA
- konceptualni model - ulaz u fazu OOD
Objektno-orijentisano projektovanje
- Tradicionalno strukturirano projektovanje
- fokus na algoritamskim apstrakcijama
- Booch (1994): Objektno-orijentisano projektovanje je metod projektovanja
koji obuhvata
- proces OO dekompozicije
- notaciju za predstavljanje
- logičkih i fizičkih
- statičkih i dinamičkih aspekata modela sistema koji se projektuje
- Proizvod OOD
- model projektovane aplikacije ili sistema – ulaz u fazu OOP
Objektno-orijentisano programiranje
- Tradicionalno strukturirano programiranje
- fokus na implementaciji algoritama
- Booch (1994): Objektno-orijentisano programiranje je metod implementacije
po kojem su:
- programi organizovani kao kolekcije objekata koji sarađuju
- svaki objekat predstavlja instancu neke klase i
- sve klase su članovi neke hijerarhije klasa u kojoj su klase povezane relacijama nasleđivanja
- Proizvod OOP
- izvršna aplikacija ili sistem
14 Uvod
Elektrotehnički fakultet u Beogradu
Objektno-orijentisani jezik
- Cardelli & Wegner (1985): Jezik je objektno-orijentisan ako i samo ako ispunjava:
- da podržava objekte koji su apstrakcije podataka sa interfejsom preko imenovanih operacija i skrivenim lokalnim stanjem
- da objekti imaju pridružen tip (klasu)
- da tipovi (klase) mogu nasleđivati atribute nadtipa (natklase)
- Ako jezik samo ne podržava nasleđivanje naziva se objektno-baziranim jezikom
- Objektno-orijentisani jezici su:
- Simula, Smalltalk, Object Pascal, Eiffel, Python, Ada95, C++, Java, C#, Visual Basic.NET, ...
- Objektno-bazirani jezici
- Ada83, VisualBasic v6,...
Principi OO modela
- Booch OOA&D (1994): Osnovni (obavezni) Dodatni (neobavezni) apstrakcija tipizacija kapsulacija konkurentnost modularnost perzistencija hijerarhija
- Modifikacija: Osnovni (obavezni) Dodatni (neobavezni) apstrakcija konkurentnost kapsulacija perzistencija modularnost hijerarhija polimorfizam
Apstrakcija i kapsulacija
- Shaw (1984): Apstrakcija je uprošćeni opis ili specifikacija sistema koja naglašava
neke od detalja ili osobina, dok potiskuje druge
- Booch (1994): Apstrakcija ističe esencijalne karakteristrike objekta koje ga razlikuju
od drugih vrsta objekata i tako definiše jasne konceptualne granice iz perspektive
posmatrača
- Kapsulacija je proces sakrivanja onih elemenata apstrakcije
koji definišu strukturu i ponašanje
- Kapsulacija služi da razdvoji konceptualni interfejs od implementacije apstrakcije
Modularnost i hijerarhija
- Modularnost je osobina sistema da se razlaže
na skup kohezivnih i slabo spregnutih modula
- Moduli su fizičke jedinice (nezavisno prevođenje)
- predstavljaju komponete sistema
- mogu se održavati nezavisno
16 Uvod
Elektrotehnički fakultet u Beogradu
Ciljevi modeliranja
- Model pomaže da se sistem vizuelizuje
- Model omogućava da se specificira
- struktura sistema
- ponašanje sistema
- Model daje šablon koji usmerava konstrukciju sistema
- Model dokumentuje projektne odluke koje se donose
- Model omogućava ispitivanje projektnih odluka po relativno niskoj ceni
OO model i pogledi na model
- Model OO analize i projektovanja obuhvata više pogleda na sistem koji se razvija
- Dve dimenzije pogleda na sistem:
- logički/fizički aspekti
- statički/dinamički aspekti
- AiP OO sistema se obavlja u terminima klasa, objekata, njihovih relacija i interakcija
- Tokom AiP koriste se različiti uglovi gledanja na model sistema u datom 2D prostoru
Dijagrami
- Za svaki pogled na model sistema može se definisati adekvatan dijagram
- Svaki dijagram predstavlja jednu projekciju modela
- Primer - aplikacija sa 100 klasa:
- potrebno je više klasnih dijagrama (svaki prikazuje jedan pogled na model)
- Jedno ime na svakom dijagramu označava isti entitet
(sa izuzetkom operacija zbog preklapanja imena)
Logički i fizički aspekti modela
- Logički model sistema
- opisuje ključne apstrakcije i mehanizme koji
- obrazuju prostor problema ili
- definišu arhitekturu sistema
- definiše
- strukturu i relacije između klasa
- relacije i interakcije između objekata
- Fizički model sistema
- opisuje konkretnu softversku i hardversku kompoziciju
- definiše arhitekturu modula i arhitekturu procesa
Statički i dinamički aspekti modela
- Statički aspekti modela se fokusiraju na strukturu sistema
- Dinamički aspekti modela se fokusiraju na ponašanje sistema
- Realni sistemi uvek imaju dinamičko ponašanje:
- objekti se kreiraju i uništavaju
- objekti šalju poruke drugim objektima nekim redosledom
- spoljašnji događaji izazivaju reakcije izvesnih objekata
Uvod 17
Projektovanje softvera
Notacija za opis modela
- Nekoliko notacija zaslužuju posebnu pažnju:
- Booch i OMT notacija (iz istorijskih razloga)
- UML notacija (standard)
- Pogodnosti standardne formalne grafičke notacije:
- olakšava se komunikacija između korisnika i članova razvojnog tima
- projektant se rasterećuje od nebitnih detalja i koncentriše se na bitne
- omogućava se upotreba automatizovanih alata za proveru konzistencije i korektnosti projekta ili izvršavanje modela
- Nije neophodno koristiti celu notaciju
- na primer Booch Lite , UML Basic (UML User Guide)
- Potrebno je da notacija omogućava različit stepen detaljnosti
(ponekad samo grube skice)
- Notacija treba da bude nezavisna od programskog jezika
- neki elementi notacije nemaju direktnu podršku u konkretnom jeziku
Alati za modeliranje
- IBM Rational: Software Architect
(Rose, Rose XDE Developer, Software Modeler)
http://www-01.ibm.com/software/rational/products/swarchitect/
http://www.borland.com/us/products/together/index.aspx
- Gentleware: Poseidon for UML
http://www.gentleware.com
http://staruml.sourceforge.net/en/
http://www.altova.com/download/umodel/uml_tool.html
http://www.omondo.com
- Sparx Systems: Enterprise Architect
http://www.sparxsystems.com
- Visual Paradigm: Visual Paradigm for UML
http://www.visual-paradigm.com/product/vpuml
- Embarcadero Technologies: ER/Studio Software Architect
http://www.embarcadero.com/products/er-studio-software-architect
http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
UML – Pregled jezika 19
Projektovanje softvera
Istorija UML-a
- 1994: početak rada na UML-u - Rumbaugh se pridružio Booch-u u firmi Rational
- Oktobar 1995: pojavila se verzija 0.8 drafta UM-a ( Unified Method )
- Jesen 1995: Jacobson se pridružio Rational-u – rad na objedinjenju UM sa OOSE
- Jun 1996: pojavila se verzija 0.9 UML-a
- Važniji partneri (učestvovali u definisanju verzije 1.0):
- DEC, HP, IBM, Microsoft, Oracle, Rational, TI, ...
- U januaru 1997: OMG-u ( Object Management Group ) podnet predlog std. UML 1.
- Grupa partnera je proširena drugim podnosiocima predloga:
- npr. ObjecTime, Ericsson,...
- Jul 1997: podnet predlog UML 1.1 koji je prihvaćen od OMG 14.11.1997.
- Jun 1998: verzija UML 1.
- Jesen 1998: verzija UML 1.
- Septembar 2001: verzija UML 1.4 (v. 1.4.2 => ISO std. 19501:2005)
- 2002: verzija UML 1.5 (akciona semantika)
- Jun 2003: v 2.0, februar 2007: v 2.1, februar 2009: v 2.2, maj 2010: v 2.
Konceptualni model UML-a
- Tri osnovna elementa UML modela su:
- Osnovni gradivni blokovi
- Pravila za povezivanje gradivnih blokova
- Opšti mehanizmi koji se primenjuju u UML-u
- Gradivni blokovi UML-a
- Stvari ( things )
- apstrakcije koje su "građani prvog reda" u modelu
- Relacije (relationships)
- Dijagrami ( diagrams )
- grupišu interesantne skupove povezanih stvari
Stvari
- Stvari strukture - statički delovi modela,
reprezentuju konceptualne ili fizičke elemente (imenice)
- Stvari ponašanja - dinamički delovi modela,
reprezentuju ponašanje kroz prostor i vreme (glagoli)
- Stvari grupisanja - organizacioni delovi modela,
kutije u koje model može biti dekomponovan
- Stvari anotacije - objašnjavajući delovi modela,
komentari koji se primenjuju na bilo koji element
20 UML – Pregled jezika
Elektrotehnički fakultet u Beogradu
Stvari strukture – klase i interfejsi
- Klasa je opis skupa objekata koji dele zajedničke
karakteristike (atribute i operacije), ograničenja i semantiku
- Aktivna klasa je klasa čiji objekti imaju vlastitu nit kontrole
i tako mogu da započnu neku upravljačku aktivnost
- Ponašanje objekta aktivne klase je konkurentno sa drugim aktivnim objektima
- Interfejs je kolekcija operacija koje specificiraju servis klase ili komponente
- Interfejs opisuje ponašanje elementa koje je spolja vidljivo
- Interfejs definiše skup specifikacija (prototipova) operacija
ali ne i njihove implementacije
- Klasa i komponenta mogu da implementiraju više interfejsa
Stvari strukture – slučaj korišćenja i saradnja
- Slučaj korišćenja ( use-case ) je opis skupa sekvenci aktivnosti koje
obavlja sistem da bi proizveo vidljiv rezultat vredan za pojedinog aktera
- Jedna sekvenca aktivnosti – instanca slučaja korišćenja (scenario)
- Slučaj korišćenja reprezentuje funkcionalnost sistema
(mada se neki autori ne slažu sa tim)
- Koirsti se da bi se strukturirale stvari ponašanja u modelu
- Realizuje se kroz saradnju (kolaboraciju)
- Saradnja ( collaboration ) definiše zajednicu i interakciju
aktera i drugih elemenata koji dejstvuju zajedno
Prikaz rasporeda casova
IStek
Alarm
postaviVreme() ukljuci() iskljuci()
Tacka
x y rastojanje()