Metodologija razvoja softvera Osnovne akademske studije Softversko inenjerstvo

Metodologija razvoja softvera Osnovne akademske studije: Softversko inženjerstvo i informacione tehnologije Predmetni nastavnik: Prof. dr Branko Perišić Saradnici: 1. Aleksandra Mitrović

O predmetu: osnovne informacije � Broj ESPB: 6 � Fond casova: 3+2 � Predmetni nastavnik: Prof. dr Branko Perišić (bperisic@singidunum. ac. rs, Centar Novi Sad, kabinet . ac. rs 20 x). � Predmetni asistent: M. Sc. Aleksandra Mitrović (amitrovic@singidunum. ac. rs, Centar Novi Sad, kabinet . ac. rs K 402, IV sprat). � Stranica predmeta: http: //novisad. singidunum. ac. rs/coursepages/NOVISAD/ 3. � Konsultacije: ◦ Prema objavljenom rasporedu na stranici predmeta ◦ Po potrebi uz najavu na e-mail.

O predmetu: način ocenjivanja �Model: ◦ Za ocenu 6 (polaže se u kolokvijumskim nedeljama) �položeni predispitni kolokvijumi (I i II deo) sa zadacima iz baze koja sadrži zadatke i rešenja i objavljena je studentima pre polaganja kolokvijuma. ◦ Za ocenu 7 ili 8 (polaže se u ispitnom roku) �Ostvarena ocena 6. �Položen ispit sa zadacima koji nisu objavljeni u bazi za ocenu 6 �Opcioni usmeni ispit (u slučaju graničnog broja poena na ispitu za ocenu 7 ili graničnog broja poena na ispitu za ocenu 8 za kandidate koji žele kandidata da ostvare ocenu 8) ◦ Za ocenu 9 ili 10 �Ostvarena ocena 7 ili 8 �Individualna izrada i usmena odbrana projekta koji se predaje u 15 -toj nedelji semestra

Inženjerstvo softvera �Inženjerstvo problema; – obrazovanje za rešavanje ◦ ingeniosus – vešt; ◦ in geniosus – u nepoznatom; �Softver ◦ Proizvod �Klase softverskih sistema; �Opšti zahtevi prema softverskom proizvodu; �Softverski proizvod ◦ Proces: �Aspekti: apstrakcije, predstavljanje, metode, alati, dejstva, komunikacija; �Aktivnosti: razvoj, kontrola, upravljanje, rad; 24. 2. 2021. Prof. dr Branko Perišić 4

Metodologija razvoja softvera Agenda: �Inženjerstvo Softvera �Softverski proizvod �Proces izrade softvera �Odnos proces – proizvod �Inženjerstvo softvera �Odnos programiranja i inženjerstva softvera 24. 2. 2021. Prof. dr Branko Perišić 5

Osnovi Softverskog inženjerstva - 1 U cilju analize uspešnosti 1994. g. istraživanje Standish Group obuhvatilo je 350 kompanija i preko 8000 njihovih softverskih projekata. Rezultati: · 31% projekata nikada nije završeno · u velikim kompanijama samo je 9% projekata isporučeno na vreme i u granicama planiranog budžeta · u malim kompanijama 16% projekata isporučeno na vreme i u granicama planiranog budžeta

Kontekst inženjerstva softvera danas Svaka zrela profesija danas poseduje : 1. 2. 3. 4. 5. 6. 7. 8. 9. Korpus znanja Etički kodeks Standarde Sistem Licenciranja Infrastrukturu Strukovna udruženja Slobodna udruženja i zajednice Tržište Profesionalne kompanije

Kontekst inženjerstva softvera danas OMG AGILE Interne t SEI ACM Softversko inženjerstvo IEEE ISO SWEBOK IBM OPEN SOURCE zajednica MICROSOFT ORACLE SAP ADOBE VMWare Salesforce. c om HCL(HCLTE CH) Fiserc Intuit Amadeus

Kontekst inženjerstva softvera danas

Kontekst inženjerstva softvera danas 4. Cisco Systems is an American multinational technology company. It was founded by Leonard Bosack and Sandy Lerner in 1984.

Kontekst inženjerstva softvera danas 5. Tencent Holdings Limited Tencent Holding Limited is a Chinese multinational company. It works with more than one company, named as Tencent. It was founded by Ma Huateng in 1998.

Kontekst inženjerstva softvera danas 7. SAP stands for Systems, Applications and Products in data processing. It is an German multinational software company that makes Enterprise Software to manage business operation. 8. Saleforce. com is an American cloud based software company. It was founded by Marc Benioff in 1999. He was former Oracle executive. 9. Adobe is an American multinational computer software company. It was founded by John Warnock and Charles Geschke in 1982.

Kontekst inženjerstva softvera danas

Kontekst inženjerstva softvera danas AGILE OMG OPEN SEI SOURCE Korpus znanja (SWEBOK - Soft. Ware Engineering Body of zajednica Knowledge (Korpus znanja u softverskom inženjerstvu. ) (https: //www. sebokwiki. org/wiki/Guide_to_the_Software_Engineering_Bo dy_of_Knowledge_(SWEBOK) ) ACM Softversko Etički kodeks inženjerstvo Internet (Software Engineering Code of Ethics and Professional Practice) (https: //ethics. acm. org/code-of-ethics/software-engineering-code/) IEEE MICROSOFT ISO IBM SWEBOK

Kontekst inženjerstva softvera danas AGILE OMG SEI OPEN Association for Computing Machinery SOURCE Strukovno udruženje/Standardizacija zajednica (https: //www. acm. org/) ACM Softversko inženjerstvo Internet IEEE MICROSOFT ISO IBM SWEBOK

Kontekst inženjerstva softvera danas AGILE OMG OPEN SOURCE zajednica SEI ACM Institute of Electrical and Electronics Engineers Strukovno udruženje/Standardizacija (https: //www. ieee. org/ ) Softversko Internet inženjerstvo IEEE MICROSOFT ISO IBM SWEBOK

Kontekst inženjerstva softvera danas AGILE OMG OPEN SOURCE zajednica SEI ACM IEEE Softversko Internet inženjerstvo Institute of Electrical and Electronics Engineers Strukovno udruženje/Standardizacija (https: //www. ieee. org/ ) MICROSOFT ISO IBM SWEBOK

Odnos proces - proizvod INŽENJERSKA AKTIVNOST PROCES PROIZVO D

Odnos proces - proizvod INŽENJERSKA AKTIVNOST PROCES PROIZVO D

Odnos proces - proizvod

Softverski proizvod – 1. Softverski proizvod Klase softverskih sistema Opšti zahtevi prema softverskom proizvodu

KLASE SOFTVERSKIH SISTEMA ODNOSI PREMA OKRUŽENJU INTERNE KARAKTERISTIKE BATCH AVIO SAOBRAĆAJ TABLE DRIVEN INTERAKTIVNI REAKTIVNI GENERIČKA OBLAST PRIMENE PROCCESS DRIVEN KOMUNIKACIONI SISTEMI REAL TIME SADRŽANI (EMBEDED) KNOWLEDGE BASED DISTRIBUIRANI OPERATIVNI SISTEMI ZA RUKOVANJE BAZAMA PODATAKA KONKURENTNI CASE, CAD, CAM ALATI MREŽNI 24. 2. 2021. Prof. dr Branko Perišić 22

Softverski proizvod – 2. Softverski proizvod Klase softverskih sistema Opšti zahtevi prema softverskom proizvodu

OPŠTI ZAHTEVI PREMA SOFTVERSKOM PROIZVODU DOSTUPNOST (ACCESSABILITY) PRENOSIVOST (PORTABILITY) ADAPTIVNOST (ADAPTIBILITY) ZAŠTITA (PROTECTION) RASPOLOŽIVOST (AVAILABILITY) KOMPATIBILNOST (COMPATIBILITY) BEZBEDNOST (SAFETY) SIGURNOST (SECURITY) POUZDANOST (RELIABILITY) KOREKTNOST (CORRECTNESS) ROBUSTNOST (ROBUSTNESS) OTPORNOST NA GREŠKE (FAULT TOLERANCY) INTEGRITET (INTEGRITY) PONOVNA ISKORISTIVOST (REUSABILITY) OPERATIVNOST (INTEROPERABILITY) MOGUĆNOST TESTIRANJA (TESTABILITY) MOGUĆNOST ODRŽAVANJA (MAINTAINABILITY) MOGUĆNOST KORIŠĆENJA (USABILITY) PERFORMANSA (PERFORMANCE) EFIKASNOST (EFFICIENCY) 24. 2. 2021. Prof. dr Branko Perišić 24

Odnos proces - proizvod INŽENJERSKA AKTIVNOST PROCES PROIZVO D

Proces – 1.

Proces – 2. 1. Propisuje sve glavne aktivnosti. 2. Poseduje skup vodećih principa koji definišu ciljeve pojedinačnih aktivnosti. 3. Aktivnosti su organizovane u nizove (sekvence). sekvence 4. Svaka aktivnost u procesu ima kriterijum za pokretanje i završetak. 5. Koristi resurse u skladu sa postavljenim ograničenjima i daje prelazne i/ili konačnu formu proizvoda 6. Može posedovati unutrašnju stukturu.

RAZVOJ (zahtevi, analiza, specifikacija dizajna, implementacija, testiranje) ASPEKTI 1 A K T I V N O S T I 2 9 8 3 KONTROLA 6 4 (potvrda kvaliteta, konfigurisanje, validacija i verifikacija) 7 UPRAVLJANJE 10 (planiranje projekta, alokacija resursa, procena troškova, Ugovaranje, . . . ) 5 RAD (obuka, prelazak, operativni rad, gašenje) APSTRAKCIJE KOMUNIKACIJE PREDSTAVLJANJE METODE DEJSTVA ALATI 24. 2. 2021. Prof. dr Branko Perišić 28

APSTRAKCIJE: OBUHVATAJU FUNDAMENTALNE PRINCIPE I FORMALNE MODELE • MODELI PROCESA RAZVOJA SOFTVERA (VODOPAD, SPIRALNI, . . IZRADA PROTOTIPA I SL. ) PREDSTAVLJAJU MODELE EVOLUCIJE SOFTVERA; • KONAČNI AUTOMATI i PETRIJEVE MREŽE PREDSTAVLJAJU MODELE ZA ISKAZIVANJE SEKVENCIJALNE i KONKURENTNE OBRADE; • 24. 2. 2021. Prof. dr Branko Perišić 29

PRETSTAVLJANJE: OBUHVATA NOTACIONE ASPEKTE I JEZIKE JAVA • PROGRAMSKI JEZIK (IMPLEMENTACIONA NOTACIJA) • 24. 2. 2021. Prof. dr Branko Perišić 30

METODE: OBUHVATAJU Formalne metode, metodologije i tekuću praksu q DOKAZ KOREKTNOSTI PROGRAMA (Formalni metod verifikacije); q OBJEKTNO ORIJENTISANI DIZAJN - (OOD) (Metodologija projektovanja); q OBJEKTNO ORIJENTISANO 24. 2. 2021. Prof. dr Branko Perišić 31

ALATI: OBUHVATAJU POJEDINAČNE SOFTVERSKE ALATE KAO I INTEGRISANE SKUPOVE ALATA (UKLJUČIVO I HARDVERSKA SRETSTVA) Ø 24. 2. 2021. Prof. dr Branko Perišić 32

DEJSTVA: OBUHVATAJU MERENJA, ANALIZU i EVALUACIJU SOFTVERSKIH PROCESA, UTICAJ SOFTVERA NA ORGANIZACIONE SISTEME, MERE i STANDARDE. v PREDMET MERENJA (Šta se meri? ); v SOFTVERSKE METRIKE (Čime se iskazuje? ); v ALATI ZA MERENJE (Čime se meri? ); v 24. 2. 2021. Prof. dr Branko Perišić 33

KOMUNIKACIJA: o PISANA KOMUNIKACIJA; o GOVORNA KOMUNIKACIJA; o DOKUMENTACIJA: § ON-LINE (Help, Kontekstna pomoć); § OFF-LINE (Uputstva, Priručnici); § IN-LINE (Komentari u programu); § TUTORIAL (Asistencija pri ovladavanju upotrebom). 24. 2. 2021. Prof. dr Branko Perišić 34

Konačni model proces – proizvod AKTIVNOS TI Klase softverskih sistema ASPEK TI Opšti zahtevi prema softverskom proizvodu

Programiranje : Inženjerstvo softvera Programiranje Inženjerstvo softvera PSW -Upravljanje softverskim projektom

Upravljanje PSW -Upravljanje softverskim projektom

Projektovanje softvera ? ? PSW -Upravljanje softverskim projektom

Pristupi razvoju softvera Varijable Programska paradigma Strukture Klase, objekti Struktura problema Tipovi podataka Dizajnerski šabloni Komponente Arhitektura softvera Radni okviri (Frameworks)

Programska paradigma-grčka reč koja znači primer, u žargonu ukalupljeno rezonovanje Varijable Programska paradigma Strukture Sa aspekta najnižeg nivoa apstrakcije (programiranje) možemo konstatovati da princip programiranja podrazumeva razvoj produkata čiji je osnovni zadatak da obezbede ”izračunavanje” izračunavanje nečega. Računarski program je komponovan od promenljivih (X, Y, Z, . . . ) i programskih struktura (sekvence, petlje i sl. ) iskazanih lingvističkim konstrukcijama, tako da programska paradigma konstrukcijama u stvari specificira različite načine programiranja.

Programska paradigma Varijable Programska paradigma Strukture Jedan od prvih izazova u automatskoj konstrukciji softvera vezan je za programsku platformu i najčešće eksploatisan u procesu konstrukcije prevodilaca interpretera Očigledno je da je ovaj sloj, u sklopu celokupnog softverskog proizvoda, nezaobilazan i kada razmatramo metode i tehnike brzog razvoja softvera

Struktura problema Šta je potrebno učiniti da bi programa, kao produkt procesa programiranja, transformisali u “softver”? Pored algoritama i strukture podataka, specificiranje celokupne strukture problema odnosno rešenja izranja kao potpuno nova kategorija. Klase, objekti Struktura problema Tipovi podataka

Struktura problema Klase, objekti Struktura problema Tipovi podataka Ovaj nivo apstrakcije omogućava razmatranje krupnijih gradivnih elemenata programskog rešenja, njihovo predstavljanje i automatsku konverziju na elemente programske paradigme na bazi metoda programiranja (objektno, strukturalno, funkcionalno i sl. ). Modelovanje statičke strukture problema odnosno rešenja stvara podlogu za modelom upravljanu konstrukciju programskog koda.

Struktura problema Klase, objekti Struktura problema Tipovi podataka Ovaj korak automatizacije nije moguć bez precizno definisanih standarda za preslikavanje elemenata modela podataka i transformacija u varijable i programske strukture Savremeni alati, oslonjeni na ovaj nivo apstrakcije, uglavnom omogućavaju generisanje deklaracionih segmenata: programske strukture, neproblemskih delova koda i deklaracionih segmenata strukture podataka. Na ovoj poziciji dolazi do kvalitativnog razdvajanja savremenih i savremenih tradicionalnih metoda automatske konstrukcije koda. tradicionalnih

Savremeni pristup Savremeni pogled na automatsku konstrukciju softvera oslonjen je na hijerarhiju gradivnih elemenata prikazanu na donjoj slici. Dizajnerski šabloni Komponente Arhitektura softvera Radni okviri (Frameworks)

Dizajnerski šabloni - Dizajnerski šabloni su najpoznatija grupa šablona sa najširim iskustvima primene. q enkapsuliraju i strategije niskog nivoa apstrakcije (nužne za dizajn i konstrukciju softvera) Dizajnerski šabloni q strategije visokog nivoa apstrakcije (koje direktno utiču na dizajn i konstrukciju celokupnog softverskog sistema – rešenja). q arhitektonski šabloni, q dizajnerski šabloni i q idiomi

Dizajnerski šabloni - Arhitektonski šabloni: šabloni kanonizuju strategije visokog nivoa apstrakcije primerene složenim i vrlo složenim komponentama, globalnim karakteristikama i mehanizmima posmatranih sistema i imaju implikacije na celokupnu strukturu i organizaciju rešenja (softverskog sistema). Dizajnerski šabloni: šabloni kanonizuju strategije Dizajnerski šabloni srednjeg nivoa koje se odnose na strukturu i ponašanje gradivnih elemenata (entiteta) i njihovih međusobnih veza. Oni nemaju uticaja na ukupnu strukturu sistema već definišu mikroarhitekturu podsistema i komponenti. Idiomi: Idiomi usko vezani za konkretnu platformu i tehnike specifičnim za različite programske jezike, spadaju u apstrakcije niskog nivoa koje odslikavaju detalje unutrašnje strukture i unutrašnjeg/spoljašnjeg ponašanja komponenti rešenja (softverskog sistema).

Dizajnerski šabloni - Oslonac na ovaj nivo apstrakcije podrazumeva usvajanje koncepta šablona kao standardne podloge za automatsku konstrukciju koda koji implementira osnovne elemente šablona na bazi konkretnih vrednosti njegovih konstrukcionih parametara i meta-modela dizajn šablona. Dizajnerski šabloni Oslonac na modelovanje podrazumeva proširivanje klasičnog modela statičke strukture problema ili rešenja (npr. model klasa) granulatima višeg nivoa koji predstavljaju apstrakcije dizajn šablona (model šablona).

Savremeni pristup - Savremeni pogled na automatsku konstrukciju softvera oslonjen je na hijerarhiju gradivnih elemenata prikazanu na donjoj slici. Dizajnerski šabloni Komponente Arhitektura softvera Radni okviri (Frameworks)

Komponente - Pristup inženjerstvu softvera na bazi komponenti (Component-based Software Engineering) (CBSE) stavlja naglasak na pribavljanje i integraciju komponenti u cilju izgradnje složenih i obuhvatnih softverskih rešenja (complex and largescale software solutions). Komponente U literaturi danas preovladava stav da koristi od primene CBSE pristupa obuhvataju: podizanje ukupnog kvaliteta softverskih sistema, kraće vreme do izlaska na tržište i unapređenje rukovanja kompleksnošću softvera.

Komponente - Osnovna vizija CBSE bazira se na: pogledu na sistem kao na ansambl komponenti i hipotezi Komponente da će funkcionalnost novokonstruisanog sistema biti postignuta sa minimumom napora, budući da su komponente već razvijene, testirane te da poseduju visok stepen zrelosti na osnovu proverene i dugotrajno potvrđene primene u sklopu različitih konteksta

Komponente - Oslonac na ovaj podrazumeva: Komponente nivo apstrakcije usvajanje koncepta softverskih komponenti kao standardne podloge za automatsko ponovno korišćenje koda koji implementira komponente na bazi specifikacije njihovih interfejsa i modelovanja njihove adaptacije. Oslonac na modelovanje podrazumeva proširivanje klasičnog modela statičke strukture problema ili rešenja (npr. model klasa) granulatima višeg nivoa koji predstavljaju apstrakcije komponenti (model komponenti).

Komponentno baziran razvoj softvera: osnovna ideja � Zagovornici komponentno-baziranog razvoja softvera zastupaju idealan scenario razvoja softvera kao izgradnju aplikacije putem asembliranja komponenti visokog nivoa. � Ako potrebna komponenta ne postoji, ona se mora izgraditi korišćenjem komponenti nižeg nivoa koje se, dalje, ponekad moraju impelmentirati u nekom programskom jeziku. � Dakle, komponente se prave na dva načina: ◦ (1) komponovanjem (postojećih komponenti) ili ◦ (2) programiranjem komponenti.

Softverska komponenta �Softverska komponenta je bilo koji artefakt koji se može integrisati i jasno identifikovati u softverskom sistemu. �Višekratno upotrebljive softverske komponente su samostalni, jasno prepoznatljivi artefakti koji opisuju i/ili izvršavaju specifične funkcije i imaju jasne interfejse, odgovarajuću dokumentaciju i definisan status ponovne upotrebljivosti.

Softverska komponenta: atributi �Samostalnost �Mogućnost identifikacije �Funkcionalnost �Interfejsi �Dokumentacija �Status ponovnog korišćenja

Atributi softverske komponente: Samostalnost Komponente treba da budu samostalne, t. j. ponovno upotrebljive bez potrebe za uključivanjem drugih komponenti. � U tom smislu, funkcija je komponenta ukoliko se može ponovno upotrebiti sama za sebe, odnosno ako joj za ponovnu upotrebu ne treba nikakva druga funkcija. Ako su druge funkcije potrebne, tada se čitav taj skup funkcija posmatra kao ponovno upotrebljiva komponenta sa jednom od komponenti koja služi kao interfejs prema celoj grupi. � Zbog toga programski jezici imaju koncepte modula i paketa. Biblioteke funkcija su skupovi sa svojstvom ponovne upotrebljivosti. � Isto važi i za kompomenete višeg nivoa kao što su moduli, procesi, pa čak i aplikativni okviri gde je cela kolekcija klasa, a ne pojedinačna klasa, predmet ponovne upotrebljivosti. � Ima i situacija kada je nepraktično integrisati sve delove, ali tada zavisnosti moraju da budu jasno dokumentovane. �

Atributi softverske komponente: Mogućnost identifikacije �Komponente moraju biti jasno prepoznatljive (n. pr. skladištene u jedinstven fajl) a ne rasute na više lokacija i izmešane sa drugim artifaktima softvera ili dokumentacije.

Atributi softverske komponente: Funkcionalnost �Komponente opisuju i/ili obavljaju specifične funkcije. �Dakle, softverske komponente mogu da budu i opisi funkcionalnosti bez obaveze implementacije te funkcionalnosti ◦ tipičan primer opisujućih komponenti su specifikacije, dokumenti dizajna i sl.

Atributi softverske komponente: Interfejsi �U računarstvu, interfejs je deljena granica preko koje dve ili više odvojenih komponenti računarskog sistema razmenjuju informacije. �Razmena može da se vrši između softvera, računarskog hardvera, perifernih uređaja, ljudi i kombinacija navedinih učesnika u razmeni. �Komponente moraju da imaju jasne interfejse i da skrivaju detalje koji nisu potrebni za ponovnu upotrebu.

Atributi softverske komponente: Dokumentacija �Dokumentacija je neizbežna za višekratnu upotrebu. �I najkorisnije komponente su neupotrebljive bez prikladne dokumentacije. �Prikladnost dokumentacije zavisi od vrste komponente i njene složenosti. Moraju se obezbediti informacije za: ◦ Pronalaženje komponente u repozitorijumu (komponente se skladište u repozitorijumima), ◦ Evaluaciju upotrebljivosti komponente za određeni kontekst višekratne upotrebe, eventualno adaptiranje i integrisanje komponente u novo okruženje.

Atributi softverske komponente: Status ponovnog korišćenja �Komponente se moraju održavati tako da podrže sistematično ponovno korišćenje, t. j. da budu komplementirane odgovarajućim informacijama. ◦ To su informacije o vlasniku komponente, onom koji komponentu održava, koga treba kontaktirati u slučaju problema i o statusu kvaliteta komponente. ◦ Ove informacije su posebno važne ako se komponenta koristi u širem krugu (recimo, van granica neke firme).

Savremeni pristup - Savremeni pogled na automatsku konstrukciju softvera oslonjen je na hijerarhiju gradivnih elemenata prikazanu na donjoj slici. Dizajnerski šabloni Komponente Arhitektura softvera Radni okviri (Frameworks)

Arhitektura softvera - Neophodno je razlikovati dva nivoa arhitekture: funkcionalnu arhitekturu sistema i tehničku arhitekturu rešenja. orijentisana ka domenu problema i bavi se: Funkcionalna arhitektura: Arhitektura softvera razumevanjem i shvatanjem procesa, odgovornosti, različitosti isl. odnosno aspektima onoga što bi sistem trebao da radi! Tehnička arhitektura: implementacije arhitekture (da obuhvata načine funkcionalne li posedujemo komponente, model baze podataka, topologija sistema i sl. )

Arhitektura softvera - Večina autora se slaže da, u današnjim uslovima, arhitektura softvera još uvek značajno zavisi od tehnologija koje se koriste u procesu inženjerstva softvera, što prvi problem koji je neophodno rešiti u inžinjerstvu softvera. predstavlja Arhitektura softvera web-servis arhitektura (tipična floskula) komunikacioni aspekt sistema – samo jedna dimenzija sistema web-servisi – samo jedna tehnologija za implementaciju komunikacija u sklopu sistema. EJB arhitekture, Arhitektura tankih klijenata (Thin Client Architecture) i sl.

Arhitektura softvera - Arhitektura softvera Ako se konkretne implementacione tehnologije u razmatranja uključe suviše rano, kao posledica se često javlja isključivanje niza ostalih, potencijalno primerenijih, tehnologija što obično dovodi do: komplikovanijeg modela programskog rešenja, poteškoća u procesu testiranja i nižeg stepena fleksibilnosti. To je posebno važno u uslovima primene metoda i tehnika brzog razvoja softvera, odnosna rešavanja problema koji su nepotpuno ili nedovoljno specificirani.

Arhitektura softvera - Drugi problem predstavlja usvajanje određenog arhitektonskog stila odnosno šablona, pri čemu su osnove na kojima počivaju određeni stilovi nedovoljno jasno definisane ili o njima ne postoji opšta saglasnost. Arhitektura softvera Tipičan primer su servis orijentisane arhitekture (SOA). Još uvek ne postoji opšta saglasnost oko toga šta one predstavljaju i po čemu se razlikuju od npr. sistema koji su izgrađeni na bazi komponenti. Prisutno je i nerazumevanje npr. da kada neko pomene SOA drugi to shvataju isključivo kao web-servise.

Arhitektura softvera - Treći problem predstavljaju industrijski standardi tzv. Nekada davno proces standardizacije je uključivao sledeće korake: Arhitektura softvera Ø isprobavanje nekoliko varijanti rešenje Ø izbor onog rešenja koje se najbolje pokazalo u praksi Ø formirajnje komiteta za definisanje standarda na bazi prethodnog izbora čime ustvari standard promoviše partikularno rešenje koje je u određenim rešenje okolnostima dalo najbolje rezultate!

Arhitektura softvera - U današnje vreme standarde obično definišu posebne grupe koje čine zainteresovane strane, najčešće budući proizvođači onoga što je predmet standardizacije. Arhitektura softvera Pri tome oni ili već poseduju alate pa standard mora obuhvatiti sve karakteristike alata proizvođača koji čine grupu, ili uopšte ne postoji prethodno iskustvo tako da se standard definiše “ni iz čega”. Posledice: standard obično ili nije primenljiv (jer ne postoji prethodno iskustvo i aplikativna provera) ili njegova primena rezultira komplikovanim postupcima (jer predstavlja uniju karakteristika konkretnih alata).

Arhitektura softvera - Činjenica je da ako se prevelik deo sistema standardizuje on obično postaje složeniji nego što je stvarno potrebno. Tehnologije, arhitektonski stilovi i industrijski standardi u mnogome sputavaju projektante pri razmatranju stvarno relevantnih aspekata arhitekture softvera. Arhitektura softvera Jedan deo autora smatra da relevantni aspekti arhitekture obuhvataju: q arhitektonske šablone, q logičke strukture (arhitektonski metamodeli), q programske modele, q mehanizme za podršku testiranju i q osnovne pokazatelje kvaliteta usluga (Qo. S – Quality of Services).

Arhitektura softvera - Arhitekturu softvera možemo grubo posmatrati kroz skup pogleda (views) koji određuju način posmatranja softverskog rešenja. Konceptualni pogled Pogled sa aspekta modula Arhitektura softvera Pogled sa aspekta koda Pogled sa aspekta izvršavanja

Konceptualni pogled - Konceptualni pogled predstavlja najviši nivo apstrakcije softverskog rešenja sa aspekta arhitekture. Konceptualni pogled On ne vodi računa o načinu implementacije već enkapsulira statičke i dinamičke karakteristike projektovanog softverskog rešenja iskazanog apstrakcijama koje su bliske domenu primene (domenu problema).

Konceptualni pogled - Sa inženjerskog aspekta konceptualni pogled mora obezbediti odgovore na sledeća pitanja: Konceptualni pogled Na koji način sistem ispunjava postavljene zahteve? Na koji način se nezavisno razvijene komponente (COTS) integrišu u sistem i komuniciraju sa ostatkom sistema? sistema Na koji način je domen-specifični hardver i/ili softver integriše u sistem? softver Na koji način je izvršeno grupisanje funkcija sistema u različite verzije proizvoda? proizvoda Na koji način sistem uključuje ranije verzije proizvoda i podržava razvoj budućih? budućih Na koji način je moguće minimizirati odnosno amortizovati uticaj promena zahteva? zahteva

Konceptualni pogled - Zavisno od prirode problema koji se rešava moguće je apstraktnu predstavu konceptualnog pogleda iskazati u formi: modela slučajeva korišćenja (USE-CASE), konceptualnog modela šeme baze podataka (CMDB), Konceptualni pogled modelom servisa (SOA), modelom poslovnih procesa (BPM), komponent modelom (CM), modelom raspoređenosti (DM) i sl.

Pogled sa aspekta modula - Pogled sa aspekta modula predstavlja sledeći nivo apstrakcije arhitekture koji vodi računa o organizaciji arhitektonskog modela i pakovanju funkcija u krupnije celine - module. Bavi se načinom na koji je moguće konceptualno rešenje realizovati uz oslonac na savremene softverske platforme i tehnologije. Pogled sa aspekta modula Kada je modularizacija u pitanju neophodno je voditi računa o dva aspekta koji definišu kvalitet modularizacije: unutrašnja funkcionalna snaga modula (kohezija-cohession) snaga veza između modula (sprezanjecoupling)

Pogled sa aspekta modula - Sa inženjerskog stanovišta neophodno je dati odgovor na sledeća pitanja: Pogled sa aspekta modula Na koji način je proizvod preslikan na softversku platformu kojom se implementira? Koje sistemske podrške/servise koristi i gde? Na koji način je podržano testiranje? testiranje Na koji način je moguće minimizirati međuzavisnosti modula? modula Na koji način je moguće maksimizirati ponovno korišćenje modula i podsistema? podsistema Na koji način je moguće izolovati proizvod od promena koje se dešavaju promena u komercijalnim komponentama, softverskim platformama i standardima?

Pogled sa aspekta izvršavanja - Pogled sa aspekta izvršavanja predstavlja sledeći nivo apstrakcije arhitekture koji obezbeđuje: preslikavanje modula na elemente izvršne platforme i platforme definisanje izvršnih svojstava sistema uključujući i: korišćenje memorije, namenski hardver i sl. Pogled sa aspekta izvršavanja Pored toga on specificira tok kontrola u sklopu izvršne platforme.

Pogled sa aspekta izvršavanja - Sa inženjerskog stanovišta neophodno je dati odgovore na sledeća pitanja: Na koji način je sistem zadovoljava zahteve prema performanisi, oporavku i rekonfigurisanju? Pogled sa aspekta izvršavanja Na koji način je moguće balansirati korišćenje resursa? Na koji način je moguće podržati konkurentnost, replikaciju i distibuciju bez usložnjavanja kontrolnih mehanizama? Na koji način je moguće minimizirati uticaj promena u sklopu izvršne platforme?

Pogled sa aspekta koda - Pogled sa aspekta koda predstavlja sledeći nivo apstrakcije arhitekture koji vodi računa o: preslikavanju elemenata izvršne platforme na komponente izvornog koda (source components) i Pogled sa aspekta koda formiranju instalacionih (deployment) komponenti na bazi komponenti izvornog koda. Postoji čitav niz formata (file types), više različitih verzija (rukovanje konfiguracijom) i organizacija kontejnera koda sa ciljem da se podrži ponovno korišćenje.

Pogled sa aspekta koda - Sa inženjerskog stanovišta odgovoriti na sledeća pitanja: neophodno je Na koji način je moguće minimizirati napor i potrebno vreme za formiranje delova softverskog proizvoda? Pogled sa aspekta koda Na koji način je moguće rukovati verzijama i izdanjima proizvoda? Na koji način je moguće redukovati vreme izgradnje (build-time) verzija i izdanja proizvoda? Koji alati su potrebni za podršku razvoju? Na koji način je podržana integracija i testiranje?

Savremeni pristup - Savremeni pogled na automatsku konstrukciju softvera oslonjen je na hijerarhiju gradivnih elemenata prikazanu na donjoj slici. Dizajnerski šabloni Komponente Arhitektura softvera Radni okviri (Frameworks)

Radni okviri - Radni okviri (Frameworks) Radni okvir (framework) spada u kategoriju opštih pojmova (kao npr. sistem, objekat i sl. ) čije značenje direktno zavisi od konteksta u kome se koristi. U kontekstu komponent-baziranog razvoja softvera ne postoji precizna definicija radnog okvira, ali se uglavnom koristi u smislu definisanja okruženja za razvoj i izvršavanje softvera pri čemu su komponente tretirane kao binarni izvršni elementi. U kontekstu objektno-orijentisanog razvoja softvera nailazimo na sledeće definicije: . . “ponovno iskoristivi dizajn dela ili celine sistema opisan nizom apstraktnih klasa i interakcijom njihovih instanci”. . . “predstavlja kostur (skeleton) aplikacije koji je moguće prilagođavati”, . . “skeleton program koji uokviruje ponovno iskoristivu arhitekturu softvera u formi ugovora o saradnji između apstraktnih klasa i skupa varijacija”. . . arhitektura sistema

Radni okviri - U opštem slučaju bilo koja apstrakcija se može smatrati frejmvorkom (operativni sistem, jezici višeg nivoa i sl. ) budući da olakšava konstrukciju homogenih aplikacija apstrahiranjem nižih nivoa i uvođenjem novih – apstraktnijih koncepata. Radni okviri (Frameworks) Sa aspekta objekt-orijentisanog radnog okvira ponovno iskoristiva komponenta predstavlja radni okvir, koristi se kao kostur za nadogradnju a ne kao okruženje za ugradnju ponovno iskoristivih komponenti. Neki autori pod komponentama podrazumevaju ponovno iskoristive elemente aplikacije. U aplikaciji koja nastaje iz OO-radnog okvira nemoguće je uočiti jasno razgraničenje između radnog okvira i prilagođenog programskog koda, dok je kod radnog okruženja komponenti (component framework) ta distinkcija vrlo jasna budući da komponente predstavljaju posebne izvršne module – datoteke.

Radni okviri - Stepen ponovne iskoristivosti direktno utiče na brzinu razvoja softverskih proizvoda koji kao skeleton koriste proverene apstraktne radne okvire. Radni okviri (Frameworks) Nivo apstrakcije radnog okvira varira čime se prostor automatizacije izrade softvera adekvatno sužava ili širi. Tehnologija i radni okviri u današnje vreme stimulišu ponovno korišćenje

Metodologija razvoja softvera(MRS) Metodologija razvoja softvera Pregled ?