Osnove Industrijskog Razvoja Softvera - Udžbenik

Home , Bitbucket, CakePHP, Dimensions CM, Larry McVoy, Li3 (software), Padrino (web framework)

TEHNIČKI FAKULTET “MIHAJLO PUPIN” ZRENJANIN

OSNOVE INDUSTRIJSKOG RAZVOJA SOFTVERA - UDŽBENIK –

RADNA VERZIJA

Autori:

Doc. dr Ljubica Kazi Prof. dr Dragica Radosav Prof. dr Biljana Radulović Aleksandar Žarkov Miša Varga Marija Subić

ZRENJANIN, 2018.

SADRŽAJ I ORJENTACIONA ISPITNA PITANJA

1. CAS - STANDARDI SWEBOK I PMBOK, PARADIGME INDUSTRIJSKOG RAZVOJA SOFTVERA  UVOD - savremeni proces industrijskog razvoja softvera, upravljanje softverskim projektima, paradigm industrijskog razvoja softvera(objektno- orjentisani razvoj, agilni razvoj, kvalitet programskog koda, model-bazirani razvoj, test-bazirani razvoj, distribuirani timski razvoj), standardi, radne pozicije i alati ************************************************************ 2. CAS - PROCES RAZVOJA SOFTVERA, ARHITEKTURA INFORMACIONOG SISTEMA I SOFTVERA  PROCES RAZVOJA SOFTVERA I AGILNI PRISTUP - Proces razvoja softvera (Rational unified process, Basic unified process - BUP), radne uloge u BUP i artefakti, kategorizacija softvera i softverskih projekata, zakoni evolucije softvera, karakteristike agilnog pristupa razvoju softvera, komparacija agilnih metoda razvoja softvera, uloga modelovanja i dokumentovanja u agilnom pristupu razvoja softvera, disciplinovani agilni pristup razvoju softvera  ARHITEKTURA informacionog sistema, ARHITEKTURA softvera - definicija, ciljevi, principi, tipovi softverske arhitekture, arhitekturni paterni, UML za prikaz softverske arhitekture. ************************************************************ 3. CAS - DISTRIBUIRANI SISTEMI, SOFTVERSKE ARHITEKTURE  DISTRIBUIRANI SISTEMI - distribuirano/paralelno/konkurentno racunarstvo, definicija distribuiranih sistema, karakteristike distribuiranih sistema, prednosti, rizici/problemi, tipovi (distribuirani računarski sistemi, distribuirani informacioni sistemi, distribuirani embedded sistemi), distribuirani računarski sistemi (klaster, grid, cloud), distribuirani informacioni sistem (distribuirana baza podataka,distribuirana obrada podataka-softverske komponente), distribuirano programiranje - osnovni pojmovi (poruka, protokoli za razmenu poruka, aninhrona-sinhrona komunikacija, softverski servisi, distribuirani objekti, udaljeno pozivanje procedura).

 SOFTVERSKE ARHITEKTURE - klijent-server arhitektura, višeslojna objektno- orjentisana arhitektura,MVC pristup, prezentacioni sloj, middleware i razlika prema srednjem aplikativnom sloju, workflow management sistemi (orkestracija web servisa i jezik WS-BPEL), poslovni entiteti, sistemi za upravljanje poslovnim pravilima, sloj za rad sa podacima (DAL, pojam CRUD), Servisno-orjentisana arhitektura (SOA). ************************************************************ 4. CAS - SOFTVERSKE ARHITEKTURE (dopuna)  Standardna dokumentacija u razvoju softvera. Uloga softverske arhitekture u SCRUM agilnom pristupu razvoja softvera. Tipovi arhitektura u organizaciji enterprise arhchitecture - business architecture, software application architecture, information architecture, information technology architecture). Istorijat razvoja softverskih arhitektura. Osnovni principi arhitekturnog dizajna. Arhitektonski stil. Osnovne vrste arhitekturnih stilova. Osnovni dizajn paterni objektno-orjentisanog razvoja i komponente višeslojne arhitekture. Servisno bazirane arhitekture (SOA i mikroservisi). Arhitekturni paterni - tradicionalni slojeviti, orjentisani na događaje (medijator i broker tip), mikrokernel. Arhitekture mobilnih aplikacija.

 PRIMERI: VIŠESLOJNA PHP WEB APLIKACIJA, VIŠESLOJNA ASP.NET MVC APLIKACIJA UZ PRIMENU WEB SERVISA, DISTRIBUIRANE BAZE PODATAKA, TEHNOLOGIJE DISTRIBUCIJE PODATAKA MOBILNIH APLIKACIJA ************************************************************ 5. CAS - KVALITET SOFTVERA  Kvalitet softvera (različiti pogledi u odnosu na učesnike - development team, project sponsor, users, tri aspekta kvaliteta softvera: procesa razvoja, funkcionalnosti i strukture)  Standardi kvaliteta softverskog proizvoda (ISO 9126, ISO/IEC 25010:2011) - karakteristike: funkcionalnost, pouzdanost, iskoristivost, efikasnost, podesnost za održavanje, portabilnost. Kvalitet softverskog proizvoda i kvalitet proizvoda u korišćenju  Standardi kvaliteta procesa razvoja softvera (ISO/IEC 15504 baziran na standardu za životni ciklus razvoja softvera ISO/IEC 12207). Pet nivoa zrelosti organizovanja procesa razvoja softvera prema CMMI. Metrička zasnovanost podrške odlučivanju i upravljanju.  Softverske metrike za kvalitet artefakta i aplikativnog softvera u oblasti informacionih sistema. Van Belle-ov framework (sintaksni, semantički, pragmatički aspekt) za vrednovanje modela u razvoju informacionih sistema. Primer metričkih modela za model poslovnih procesa, model softverskih funkcija, konceptualni model podataka. Metrički model za vrednovanje kvaliteta podataka koji se koriste od strane aplikativnog softvera. McCall-ov model sa 3 nivoa vrednovanja softvera (user's view, manager's view, developer's view)  Preporuke i konvencije za pisanje kvalitetnog koda. Elementi programskog stila. Čitljivost programskog koda.  Refaktorisanje programskog koda (unapređivanje kvaliteta, prvenstveno strukture i performansi programskog koda bez izmene funkcionalnosti), uobičajen katalog tehnika refaktorisanja. Primeri situacija kada treba refaktorisati programski kod i predlog načina kako realizovati refaktorisanje.

************************************************************ 6. CAS - TESTIRANJE SOFTVERA  Faze razvoja softvera, najvažniji artefakti i radne pozicije, struktura idejnog, glavnog i detaljnog projekta. Opis posla business analyste, solution architect, agile product owner, scrum master.  Standardni proces razvoja i dokumenti  Struktura dokumenata: software requirements dokument, software architecture dokument, project charter, project plan, user story  Merenje uspeha projekta ili procesa razvoja, zbog unapredjenja CMM zrelosti. Metricki sistem. KPI - key performance indicators, KSI - key success indicators. Strateski plan kontinualnog unapredjenja.  Testiranje softvera - standard ANSI/IEEE 829 za software test documentation. Definicija "software bug". Posao testera. Artefakti testiranja. V model povezanosti ulaznih artefakta i faza razvoja softvera i obuhvata i vrste testiranja. Test dokumentacija. Pojmovi (precision/accuracy, verification/validation, quality/reliability, testing/quality assurance. Metode testiranja (black box-white box, static'dynamic, visokog nivoa- niskog nivoa, varijante (kombinacije). Oblasti testiranja.  Test to pass-to fail, equivalence partitioning, tehnike ponavljanja, stress i load. Tehnike statičkog white box testiranja - review, walktrough, inspections. Forsiranje grešaka.  Karakteristike kvaliteta dobrog korisničkog interfejsa.  Tipovi testiranja - adhoc, primenom metoda, alfa verzija, beta testiranje, automatizacija testiranja  Struktura dokumenata: test plan.  Struktura test slučaja.  Agilno testiranje - principi.

************************************************************ 7. CAS DISTRIBUIRANI TIMSKI RAZVOJ SOFTVERA

Distribuirani razvoj softvera, kolokacijski rayvoj, taksonomija distribucije (objekti distribucije - ljudi, artefakti, zadaci; organizacija distribucije - fizička distribucija, organizaciona distribucija, vremenska distribucija), koordinacija-kooperacija- kolaboracija, Organizacione forme distribuiranog razvoja softvera(virtualni timovi, outsourcing, open-source razvoj), prednosti distribuiranog razvoja softvera, karakteristike open-source razvoja softvera, primeri realizovanih rešenja u open- source organizaciji, problemi distribuiranog razvoja softvera, standard ISO/IEC 15940 za razvojna softverska okruženja, funkcionalne karakteristike alata za podršku kolaborativnom razvoju softvera, tehnološka rešenja za pojedinačne funkcionalne elemente alata kolaborativne podrške, primeri alata za pojedine funkcionalne aspekte alata za podršku kolaborativnom razvoju softvera.

************************************************************ 8. CAS ODRŽAVANJE softvera

Definicija održavanja softvera, pozicija u životnom ciklusu softvera, održavanje u ugovornom periodu probnog korišćenja i nakon probnog korišćenja, troškovi održavanja u odnosu na ceo životni ciklus razvoja softvera, tipovi održavanja (korektivno, adaptivno, preventivno, perfektivno), održavanje softvera u agilnom razvoju softvera, grupe aktivnosti u održavanju softvera (primarni procesi, procesi podrške, organizacioni procesi), planiranje izmena softvera, koraci i aktivnosti u održavanju softvera, modeli održavanja softvera (quick-fix, Boehmov, Ozbornov, Iterativni model unapređenja softvera, Reuse-oriented model), SLA (Service level agreement), reinženjering, reverzni inženjering, upravljanje konfiguracijom softvera (definicija), softverski alati za praćenje verzija softvera - tri modela (model sa lokalnim podacima, klijent-server model, distribuirani model).

************************************************************

9. CAS - PRINCIPI pravilnog dizajna objektno-orjentisanog softvera i REUSABILITY programskog koda  MODELOVANJE SOFTVERA PRIMENOM UML - PONAVLJANJE  ISTORIJAT OBJEKTNO-ORJENTISANOG PRISTUPA  OSNOVNI POJMOVI OBJEKTNO-ORJENTISANOG PROGRAMIRANJA  OSNOVNI PRINCIPI OBJEKTNO-ORJENTISANOG PROGRAMIRANJA  HEURISTIČKA UPUTSTVA pravilnog dizajna objektno-orjentisanog softvera  DIZAJN PRINCIPI OBJEKTNO-ORJENTISANOG PROGRAMIRANJA (SOLID)  REUSABILITY PROGRAMSKOG KODA ************************************************************

CAS 10 - SCRUM metodologija, SLOJEVI I PODSLOJEVI VISESLOJNE APLIKACIJE, DIZAJN PATERNI, MVC  UVOD I KONTEKST TEORIJSKIH KONCEPATA - ISKUSTVA FIRME Levi 9 (Continuous delivery proces rada počevši od zahteva korisnika evidentiranih kroz tikete do postavljanja nove verzije softvera kroz RELEASE na PRODUKCIONI SERVER korisnika, SCRUM metodologija, automatsko i manuelno testiranje, timski rad, sinhronizacija, alati za podršku timskom radu)  Detaljno objašnjenje osnovnih elemenata SCRUM METODOLOGIJE (Backlog, sprint, sastanci - daily, refinement sa procenom tezine tiketa u story points, review, retrospective)  SLOJEVI višeslojne arhitekture poslovnih web aplikacija  SOFTVERSKI DIZAJN PATERNI - značaj i vrste.  Prezentacioni sloj - ciljevi, podslojevi i dizajn paterni, MVC dizajn patern.  Sloj servisa - servis kao međusloj, servis kao osnova implementacije slučaja korišćenja, servis kao funkcionalnost koju klijent poziva. SOA i web servisi. Dizajn paterni sloja servisa.  Poslovni sloj - elementi (poslovni objekti, poslovna pravila, servisi funkcionalnosti, radni tokovi) i dizajn paterni.  Sloj za pristup podacima, ciljevi, zadaci, podslojevi i dizajn paterni.  Antipatern - definicija i primeri.

CAS 11 - SOFTVERSKI RAZVOJNI OKVIRI (framework) Softverski framework - Definicija, ciljevi, karakteristike, primena, frozen spots/hotspots, prednosti i nedostaci, kategorizacija, najčešće korišćeni frejmworci u raznim programskim jezicima. Pojmovi ORM i AJAX.

CAS 12 - WEB SERVISI Pojam SOAP i REST web servisa. komparacija karakteristika. OASIS standard ya autentifikaciju i bezbednost prilikom povezivanja i korišćenja web servisa.

CAS 13 - FORMATI ZA RAZMENU PODATAKA. XML i JSON - značenje skraćenica. Primena uz SOAP i REST web servise. Karakteristike, prednosti i nedostaci XML. Primena JSON u okviru Java script-a (parsiranje, tj. izdvajanje elemenata). Komparacija karakteristika XML i JSON. Primer XML fajla. Primer JSON fajla (primer Google Maps i Facebook JSON fajla za razmenu podataka izmedju aplikacija koje koriste FAcebook, npr. mobilne aplikacije i samog Facebook-a putem Facebook API).

UVOD

Osnovni udžbenik za predmet SOFTVERSKO INŽENJERSTVO 2, kao i pomoćni udžbenik za predmet INFORMACIONI SISTEMI 2 i DISTRIBUIRANI INFORMACIONI SISTEMI.

PRVI ČAS

SADRŽAJ:

PARADIGME SAVREMENOG PRISTUPA RAZVOJU SOFTVERA  Software factory, product lines  objektno-orjentisani razvoj  model-bazirani razvoj  test-bazirani razvoj  distribuirani timski razvoj  kvalitet programskog koda – čitljiv, lak za održavanje, brzo radi  agilni razvoj – agilni manifesto

SAVREMENI PROCES INDUSTRIJSKOG RAZVOJA SOFTVERA  Standard SWEBOK: Faze razvoja softvera

UPRAVLJANJE SOFTVERSKIM PROJEKTIMA  Standard PMBOK – 10 oblasti  Project charter i project plan

RADNE POZICIJE  projektni menadzer  system analitičar  sistem arhitekta  tester  programer

ALATI  za upravljanje projektima  za dizajn i modelovanje  za programiranje  za testiranje  za praćenje verzija softvera  za podršku timskom radu

PARADIGME SAVREMENOG PRISTUPA RAZVOJU SOFTVERA

Software factory, software product lines

Software factory- integracija alata, procesa i sadržaja baziranih na templejtima, dizajn paternima, ponovnoj iskoristivosti koda, kako bi se postigla automatizacija razvoja, unapredila adaptibilnost softvera na promene i minimizovao uticaj ljudskog faktora u razvoju softvera. Software Factory Definition A Software Factory is defined as a facility or process that assembles (not codes) software applications to conform to a Specification following a strict Manufacturing Methodology. By utilizing the fundamentals of industrial manufacturing – standardized components, specialized skill sets, parallel processes and a predictable and scalable level of quality – a true Software Factory can achieve a superior level of application assembly even when assembling new or horizontal solutions. Just as industrialization of the automobile manufacturing process led to increased productivity and higher quality at lower costs, industrialization of the software development process is leading to the same advantages. Software factories have gained recent popularity as a cost-effective way to reduce the time it takes to develop software. Conceptually, software factories represent a methodology that seeks to incorporate pre-built, standard functionalities into software through configuration – not code. A Software Factory uses a Software Manufacturing process and productivity tools which enable this process. Software Manufacturing is a horizontal process for the code-less assembly of any Business Software Application from 100% proven / reusable components, exactly to specification for an end user, that are delivered in consistent and predictable timeframes. The Software Manufacturing process is only achieved through the use of a set of productivity tools that allow existing components, applications, services, and systems to be easily consumed, integrated and orchestrated into the end product without the use of custom code. If there is any custom code in the application layer, it is not assembled and therefore it was not created using a manufacturing approach. Software Factories, assembly processes and true software manufacturing are enabled through the use of Productivity Tools. Simply defined, Productivity Tools allow non-developers / non-programmers (or, in the industrial manufacturing analogy, non skilled craftsman) to use easily acquired skills that enable them to leverage drag and drop, snap in, or point and click methodologies to create either specific deployable pieces of functionality, or, fully customized solutions that conform 100% to any horizontal software specification (http://www.objectbuilders.com/software-factory-definition.html)

Software product line – skup metoda, alata i tehnika za kreiranje kolekcije sličnih softverskih sistema na osnovu deljenih softverskih resursa koristeći zajednička sredstva produkcije. Carnegie Mellon Software Engineering Institute defines a software product line as "a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

PARADIGME  objektno-orjentisani razvoj – osnovni principi: enkapsulacija, nasleđivanje, polimorfizam  model-bazirani razvoj – kreiranje modela I generisanje koda automatski na osnovu modela  test-bazirani razvoj – zahtevi se formulišu u formi test slučajeva I implementiraju, kako bi se obezbedilo da softver sadrži ono što je zahtevano  distribuirani timski razvoj – razvoj softvera u timovima koji su često prostorno udaljeni  kvalitet programskog koda – čitljiv, lak za održavanje, brzo radi  agilni razvoj – agilni manifesto (http://agilemanifesto.org/):

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

12 PRINCIPA:

 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.  Business people and developers must work together daily throughout the project.  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.  Working software is the primary measure of progress.  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  Continuous attention to technical excellence and good design enhances agility.  Simplicity--the art of maximizing the amount of work not done--is essential.  The best architectures, requirements, and designs emerge from self- organizing teams.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

1. SAVREMENI PROCES INDUSTRIJSKOG RAZVOJA SOFTVERA

Standard SWEBOK:

Faze razvoja softvera - ISO/IEC/IEEE 12207,Software Life Cycle Processes

 Software requirements o funkcionalni i nefunkcionalni zahtevi o zahtevi za proizvod ili proces o merljivi zahtevi o izdvajanje zahteva: . u odnosu na ciljeve (strateške, operativne), domensko znanje, zainteresovane strane, poslovna pravila, radno okruženje . tehnike: intervju, scenario (use case), prototip, sastanci, posmatranje, korisnikove price (“user story” – As a ROLE, I want GOAL so that BENEFIT) o analiza, klasifikacija zahteva – prioriteti, stabilnost o modelovanje – konceptualno modelovanje (UML, modeli podataka), dizajn arhitekture i upoređivanje sa zahtevima o specifikacija zahteva = kreiranje dokumenta: definicija sistema (zahtevi za sistem visokog nivoa, u skladu sa domenom, ciljevi sistema, ciljno okruženje, ograni;enja, pretpostavke, nefunkcionalni zahtevi, konceptualni modeli kojima se ilustruje kontekst sistema, scenariji korišćenja, domenski entiteti i radni tokovi), zahtevi sistema, zahtevi softvera (sadrže opis softverskog proizvoda – šta će biti, a šta neće obuhvaćeno).

 Software design – oblasti znanja:

Dizajn softvera je process i rezultat procesa definisanja arhitekture, komponenti, interfejsa I drugih karakteristika sistema ili komponenti. U toku dizajna, kreiraju se različiti modeli koji predstavljaju osnov za rešenje koje treba da bude implementirano. o Dve vrste: . Dizajn arhitekture – dizajn visokog nivoa, struktura, komponente . Detaljni dizajn – detaljni dizajn komponenti dovoljno precizno da bi se omogućila konstrukcija, struktura I ponašanje komponenti. o Principi dizajna softvera: apstrakcija, nezavisnost i kohezija (coupling and cohesion), dekompozicija i modularizacija, enkapsulacija, razdvajanje interfejsa I implementacije, kompletnost I primitivnost, razdvajanje aspekata (separation of concerns) o Elementi dizajna: . Struktura softvera, arhitektura, dizajn paterni . Dizajn korisničkog interfejsa (prezentacija, lokalizacija I internacionalizacija, metafore) o Strategije dizajna: . Funkcionalno orjentisani (strukturni) dizajn . Objektno-orjentisani dizajn . Dizajn orjentisan na strukture podataka . Dizajn orjentisan na komponente

 Software construction o Strategije: . Minimizacija kompleksnosti . Predviđanje promena . Konstrukcija pogodna za verifikaciju . Ponovna iskoristivost koda . Usklađenost sa standardima o Modeli životnog ciklusa: . Linearni - Waterfall . Iterativni – evolucioni prototyping, agilni razvoj

 Software testing o Obuhvat – moduli (unit), integracija, sistem, funkcionalne karakteristike, nefunkcionalne karakteristike, pouzdanost, bezbednost, upotrebljivost, interfejs, stress testing, recovery testing… o Tehnike – bela kutija (uzima se u obzir kod kako je napisan), crna kutija (samo ponašanje softvera): . Tehnike bazirane na iskustvu i intuiciji softverskog inženjera . Tehnike bazirane na ulaznom domenu (particionisanje ulaznih podataka, analiza graničnih vrednosti, random) . Tehnike bazirane na kodu (control flow, data flow) . Tehnike bazirane na greškama(pretpostavke I istorija grešaka programa, mutaciono testiranje) . Tehnike testiranja korišćenja (operacioni profil, posmatranje korisnika) . Model-bazirane tehnike (stabla odlučivanja, mašine konačnog stanja, formalne specifikacije, modeli radnog toka)

 Software maintenance o Post-delivery aktivnosti – modifikacije softvera, obuka, pomoć za korišćenje o Koncept: Evolucija softvera o Obuhvat održavanja – korigovanje grešaka, unapređenje dizajna, implementacija unapređenja, interfejs sa drugim softverom, adaptiranje programa na različite tehnološke platforme, migracija starog softvera (legacy). o Aspekti – kontrolisanje svakodnevnog funkcionisanja, kontrolisanje izmena, unapređenje postojećih funkcija, identifikacija bezbedonosnih nedostataka i popravke, prevencija softverskih performansi od degradacije do neprihvatljivog nivoa. o Tehnike – reinženjering, reverzni inženjering, migracija o Kategorije (standard IEEE 14764): . Korektivno održavanje – korigovanje grešaka I uklanjanje problema . Adaptivno – usklađivanje sa promenama radnog okruženja . Perfektivno – unapređenje funkcionalnosti ili dokumentacije, radi unapređenja performansi softvera, boljeg održavanja… . Preventivno – korekcije da ne bi došlo do greške

Oblasti:  Software configuration management – izmene softvera. Važni pojmovi: Softverske biblioteke, upravljanje isporukom softvera  Software engineering management – studija izvodljivosti, planiranje softverskog projekta, upravljanje projektima, monitoring, kontrola I izveštavanje, merenje uspeha projekta  Software engineering process – životni ciklusi softvera  Software engineering models and methods: o Sintaksni, semantički i pragmatički aspect o Modelovanje informacija, ponašanja i strukture  Software quality  Software engineering professional practice – pravna regulative, etički principi, uticaj softvera na društvo, kvalitet ljudskog faktora (grupna dinamika, psihologija, komunikacione sposobnosti, sposobnosti prezentovanja, tehnička pismenost)  Software engineering economics – troškovi, performance, upravljanje vrednostima, rizici OSNOVE:  Computing foundations – programiranje, debugging, strukture podataka, algoritmi, organizacija računara, kompajleri, operativni sistemi, baze podataka, računarske mreže, paralelno I distribuirano računarstvo, bezbednost, korisnički interfejs I ljudski faktor  Mathematical foundations – skupovi, relacije, funkcije, matematička logika, grafovi I stabla, formalna gramatika, algebra, teorija brojeva…  Engineering foundations – modeli, simulacije, prototip

UPRAVLJANJE SOFTVERSKIM PROJEKTIMA

Osnovni pojmovi (SWEBOK): - projekat – privremen poduhvat preduzet radi kreiranja jedinstvenog proizvoda, usluge ili rezultata. - Program – skup povezanih projekata kojima se koordinira - Portfolio – skup projekata ili programa radi ostvarivanja strateškog cilja - Životni ciklus softverskog proizvoda – sve aktivnosti na definisanju, kreiranju, izvršavanju, održavanju I povlačenju softverskog proizvoda. - Projektni životni ciklus – uključuje 5 procesnih grupa: inicijaciju, planiranje, izvršavanje, monitoring, kontrolu I zatvaranje.

 Standard PMBOK

Grupe procesa u upravljanju projektima:  Inicijacija  Planiranje  Izvršavanje  Monitoring I kontrola  Zatvaranje

Životni ciklus softvera:  Prediktivni – linearni  Iterativni I inkrementalni  Adaptivni – agilne metode, change-driven

 10 oblasti znanja, procesi i dokumentacija:

 DOKUMENTACIJA - Project charter

ULAZNI PODACI 4.1.1.1 Project Statement of Work The project statement of work (SOW) is a narrative description of products, services, or results to be delivered by a project. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, product, or service requirements. For external projects, the statement of work can be received from the customer as part of a bid document, (e.g., a request for proposal, request for information, or request for bid) or as part of a contract. The SOW references the following: • Business need. An organization’s business need may be based on a market demand, technological advance, legal requirement, government regulation, or environmental consideration. Typically, the business need and the cost-benefit analysis are contained in the business case to justify the project. • Product scope description. The product scope description documents the characteristics of the product, service, or results that the project will be undertaken to create. The description should also document the relationship between the products, services, or results being created and the business need that the project will address. • Strategic plan. The strategic plan documents the organization’s strategic vision, goals, and objectives and may contain a high-level mission statement. All projects should be aligned with their organization’s strategic plan. Strategic plan alignment ensures that each project contributes to the overall objections of the organization. 4.1.1.2 Business Case The business case or similar document describes the necessary information from a business standpoint to determine whether or not the project is worth the required investment. It is commonly used for decision making by managers or executives above the project level. Typically, the business need and the cost-benefit analysis are contained in the business case to justify and establish boundaries for the project, and such analysis is usually completed by a business analyst using various stakeholder inputs. The sponsor should agree to the scope and limitations of the business case. The business case is created as a result of one or more of the following: • Market demand (e.g., a car company authorizing a project to build more fuel- efficient cars in response to gasoline shortages), • Organizational need (e.g., due to high overhead costs a company may combine staff functions and streamline processes to reduce costs.), • Customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park), • Technological advance (e.g., an airline authorizing a new project to develop electronic tickets instead of paper tickets based on technological advances), • Legal requirement (e.g., a paint manufacturer authorizing a project to establish guidelines for handling toxic materials), • Ecological impacts (e.g., a company authorizing a project to lessen its environmental impact), or • Social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of cholera). Each of the examples in this list may contain elements of risk that should be addressed. In the case of multiphase projects, the business case may be periodically reviewed to ensure that the project is on track to deliver the business benefits. In the early stages of the project life cycle, periodic review of the business case by the sponsoring organization also helps to confirm that the project is still aligned with the business case. The project manager is responsible for ensuring that the project effectively and efficiently meets the goals of the organization and those requirements of a broad set of stakeholders, as defined in the business case. 4.1.1.3 Agreements Agreements are used to define initial intentions for a project. Agreements may take the form of contracts, memorandums of understanding (MOUs), service level agreements (SLA), letter of agreements, letters of intent, verbal agreements, email, or other written agreements. Typically, a contract is used when a project is being performed for an external customer. 4.1.1.4 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can influence the Develop Project Charter process include, but are not limited to: • Governmental standards, industry standards, or regulations (e.g. codes of conduct, quality standards, or worker protection standards), • Organizational culture and structure, and • Marketplace conditions. 4.1.1.5 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence the Develop Project Charter process include, but are not limited to: • Organizational standard processes, policies, and process definitions, • Templates (e.g., project charter template), and • Historical information and lessons learned knowledge base (e.g., projects, records, and documents; all project closure information and documentation; information about both the results of previous project selection decisions and

STRUKTURA • Project purpose or justification, • Measurable project objectives and related success criteria, • High-level requirements, • Assumptions and constraints, • High-level project description and boundaries, • High-level risks, • Summary milestone schedule, • Summary budget, • Stakeholder list, • Project approval requirements (i.e., what constitutes project success, who decides the project is successful, and who signs off on the project), • Assigned project manager, responsibility, and authority level, and  • Name and authority of the sponsor or other person(s) authorizing the project charter.

DOKUMENTACIJA - Project plan 4.2.3.1 Project Management Plan The project management plan is the document that describes how the project will be executed, monitored, and controlled. It integrates and consolidates all of the subsidiary plans and baselines from the planning processes. Project baselines include, but are not limited to: • Scope baseline (Section 5.4.3.1), • Schedule baseline (Section 6.6.3.1), and • Cost baseline (Section 7.3.3.1).

Subsidiary plans include, but are not limited to: • Scope management plan (Section 5.1.3.1), • Requirements management plan (Section 5.1.3.2), • Schedule management plan (Section 6.1.3.1), • Cost management plan (Section 7.1.3.1), • Quality management plan (Section 8.1.3.1), • Process improvement plan (Section 8.1.3.2), • Human resource management plan (Section 9.1.3.1), • Communications management plan (Section 10.1.3.1), • Risk management plan (Section 11.1.3.1), • Procurement management plan (Section 12.1.3.1), and • Stakeholder management plan (Section 13.2.3.1). Among other things, the project management plan may also include the following: • Life cycle selected for the project and the processes that will be applied to each phase; • Details of the tailoring decisions specified by the project management team as follows: ○○ Project management processes selected by the project management team, ○○ Level of implementation for each selected process, ○○ Descriptions of the tools and techniques to be used for accomplishing those processes, and ○○ Description of how the selected processes will be used to manage the specific project, including the dependencies and interactions among those processes and the essential inputs and outputs. • Description of how work will be executed to accomplish the project objectives; • Change management plan that documents how changes will be monitored and controlled; • Configuration management plan that documents how configuration management will be performed; • Description of how the integrity of the project baselines will be maintained; • Requirements and techniques for communication among stakeholders; and • Key management reviews for content, the extent of, and timing to address, open issues and pending decisions.

RADNE POZICIJE

HTTPS://STARTIT.RS/POSLOVI/

 ------MODELOVANJE, ARHITEKTA ------ BUSINESS PROCESS ANALYST (https://abiscompany.secure.force.com/FCMS__CMSLayout?jobIds=a0d3600 0002HEjdAAG&page=JobDetailPage&sessionId=&jobSite=default&p=Candida te)  SYSTEM ARCHITECT, product engineering  DATA ARCHITECT  CORE ARCHITECT

 ------TESTIRANJE SOFTVERA------ QA engineer ……(tester)  Test engineer  Test developer

 ------MENADZMENT------ Technology lead  Technical lead  Technical director  Product manager  Team lead  Project manager  Marketing, PR  Head of data and data operations  Content marketing strategist  IT recruitment manager

 ------PROGRAMIRANJE------ (TEHNOLOGIJA – Web) programmer  Developer (full stack)  Software engineer za TEHNOLOGIJU  Delivery engineer  TEHNOLOGIJA developer  Programer (full stack)  API developer

 ------SLOJEVI PROGRAMIRANJA------ Frontend developer-engineer  Backend developer  SEO specialist – search engine optimization, digital marketing  HTML.CSS developer  Web and graphic designer

 ------PODRŠKA ------ Security system engineer  Support engineer  System engineer  Administrator sistema  Copywriter  IT system engineer  Embedded engineer  Hardware designer  User admin + tech support

 ------GRAFIKA, MULTIMEDIJA------ UI-UX dizajner  3d CHARACTER ARTIST for games  C++ computer vision developer  Music abel manager   ------ANALIZA PODATAKA ZA PODRŠKU ODLUČIVANJU------ Data Analyst  Business intelligence developer  Big data engineer  Business system analyst (http://www.readinghealthsystem.jobs/search/jobdetails/business-system- analyst/1cb2dffc-c0a4-4790-a137-6d450c148d69?s_cid=nas)

ALATI  za upravljanje projektima  za dizajn i modelovanje  za programiranje  za testiranje  za praćenje verzija softvera  za podršku timskom radu

DRUGI CAS

PROCES RAZVOJA SOFTVERA

Basic unified process

Razvoj softvera u poslovnom okruženju

Osnovne i dodatne aktivnosti u razvoju softvera

RADNE ULOGE U RAZVOJU SOFTVERA

BASIC UNIFIED PROCESS - uloge u timu:

 ANALISTA (Analyst) – odgovoran za prikupljanje zahteva i njihovo dokumentovanje. U malim i agilnim projektima, predstavnik korisnika može imati ovu ulogu.  ARHITEKTA (Architect) – odgovoran za softversku arhitekturu, koja uključuje ključne tehničke odluke koje usmeravaju generalni dizajn i implementaciju implementation u okviru projekta.  Developer – kreira rešenje ili modul kroz dizajn, implementaciju, testiranje modula I integraciju komponenti.  TESTER – odgovoran za testiranje sistema sa šire perspektive nego programer, vodeći računa o tome da sistem funkcioniše kako je i zahtevano i da je prihvaćen od strane korisnika.  MENADŽER PROJEKTA (Project Manager) – planira i rukovodi projektom, koordinira interakcije sa svim učesnicima, utiče ne fokusiranost tima na rezultate i rokove.  Ostale uloge – podnošenje i izvođenje promena, učešće na sastancima, revizije… „ [Balduino]

КАТЕГОРИЗАЦИЈА СОФТВЕРА

Међународне организације, међу којима је и организација Уједињених Нација, реализују класификацију производа и услуга која би представљала међународни стандард и омогућила интеграцију у пословању различитих земаља. Тако је реализован у оквиру Уједињених Нација документ UNSPSC (United Nations Standard Products and Services Code) , где се сви производи и услуге категоришу користећи 4 нивоа: „Segment, Family, Class and Commodity“. Софтвер према наведеној класификацији категорише се у односу на намену као:

11- 43230000 (Software):  432315 - BUSINESS FUNCTION SPECIFIC SOFTWARE  432316 - FINANCE ACCTING, ENTERPRISE RESOURCE PLANNING ERP SOFTWARE  432320 -COMPUTER GAME OR ENTERTAINMENT SOFTWARE  432321-CONTENT AUTHORING AND EDITING SOFTWARE  432322-CONTENT MANAGEMENT SOFTWARE  432323-DATA MANAGEMENT AND QUERY SOFTWARE  432324-DEVELOPMENT SOFTWARE  432325-EDUCATIONAL OR REFERENCE SOFTWARE  432326-INDUSTRY SPECIFIC SOFTWARE  432327-NETWORK APPLICATIONS SOFTWARE  432328-NETWORK MANAGEMENT SOFTWARE  432329-NETWORKING SOFTWARE  432330-OPERATING ENVIRONMENT SOFTWARE  432332-SECURITY AND PROTECTION SOFTWARE  432334-UTILITY AND DEVICE DRIVER SOFTWARE  432335-INFORMATION EXCHANGE SOFTWARE  432336-ELECTRICAL EQUIPMENT SOFTWARE  432337-SYSTEM MANAGEMENT SOFTWARE

USLUGE U OBLASTI IT 11- 81160000 (Information Technology Service Delivery):  811615 - ACCESS MANAGEMENT SERVICES  811616 -ELECTRONIC MAIL AND MESSAGING SERVICES  811617- TELECOMMUNICATION SERVICES

У истраживањима у области развоја софтвера, различити аутори дају класификације у складу са садржајем одговарајућих истраживања:

I) Рачунарски софтвер се може поделити према намени на [Turban et al, 2013]: 1. Системски софтвер (нпр. оперативни системи,услужни софтвер, драјвери уређаја, антивирусни програми итд.) 2. Апликативни софтвер различите намене: - апликативни софтвер опште намене (софтвер за подршку канцеларијском пословању – word процесори, рад са презентацијама, рад са табелама...) - апликативни софтвер специфичне намене (пословне апликације, индустријски софтвер итд.) 3. Софтвер за развој апликација (алати за програмирање, тестирање софтвера итд.)

II) Рачунарски софтвер се може поделити према корисницима на [Turban et al, 2013]: - Рачунарски софтвер опште намене - Специфичан рачунарски софтвер за одређену категорију корисника - Специфичан рачунарски софтвер који се реализује за конкретног корисника

III) Рачунарски софтвер се може поделити према типу корисника на [Nguyen, 2006]: - Комерцијални софтвер (за општу намену, за шири круг корисника) - Софтвер по наруџби (за конкретног корисника) УПРАВЉАЊЕ СОФТВЕРСКИМ ПРОЈЕКТИМА

Управљање софтверским пројектима припада областима развоја софтвера и управљања пројектима [Berntsson-Svensson&Aurum, 2006]. Основне фазе и активности у управљању софтверским пројектима зависе од усвојене методологије развоја софтвера, као и методологије управљања пројектима, али према [Berntsson-Svensson&Aurum, 2006] основне фазе управљања софтверским пројектима се у суштини могу представити следећом табелом:

Фазе и активности у управљању софтверским пројектима, према Berntsson-Svensson&Aurum ([Berntsson-Svensson&Aurum, 2006]) Концепт Планирање Извршавање Завршавање пројекта Идентификација Припрема планова Извршавање Пренос потреба посла одговорности Успостављање Припрема плана Набавка Ослобађање циљева буџета материјала ресурса Утврђивање Припрема Изградња и тест Трансфер чланова изводљивости временског плана тима –распореда Припрема Окупљање Верификација Награђивање предлога пројектног тима перформанси људи Процена времена Изградња и Модификација по Спровођење и ресурса (грубо) тестирање потреби ревизије прототипова Идентификација Добијање кључних људи сагласности за следећу фазу Добијање сагласности

KАТЕГОРИЗАЦИЈА СОФТВЕРСКИХ ПРОЈЕКАТА

Према [Shenhar et al, 2000] [Shenhar et al, 2001], пројекти се могу класификовати према нивоу значаја и нивоу управљања на:  Операционално управљане пројекте („operationally managed projects“) – фокусирани су на испуњење краткорочних циљева: извршавање посла и испоруку резултата у оквиру планираног времена и буџета  Стратегијски управљане пројекте („strategically managed projects“) – фокусирани су на постизање пословних резултата, задовољавањем потреба корисника, компетитивне предности и будућег успеха у освајању тржишта, дугорочне циљеве за добробит пословања

Према [Chow&Dac-Buu, 2008] софтверски пројекти се могу класификовати на „животно-критичне“ и „животно-не критичне“ у смислу утицаја примене софтвера на ризик за животну опасност човека који би био обухваћен системом који га користи.

Пројекти, па тако и софтверски пројекти, могу се категорисати и на основу нивоа познавања технологије у тренутку иницијације пројекта („level of technological uncertainty at the moment of project initiation.“), која представља основ реализације [Shenhar&Dvir, 1996] [Shenhar et al, 2001] [Dvir et al, 1998]:  Пројекти ниског нивоа технологије („Low-Tech Projects“) базирају се на постојећој и добро познатој технологији, где се најчешће реализује понављање изградње истог производа  Пројекти средњег нивоа технологије („Medium-Tech Projects“) ослањају се највише на постојеће базичне технологије, али укључују и нове технологије или особине. То су пројекти инкременталне иновације као и унапређења и модификације постојећих производа  Пројекти високе технологије („High-Tech Projects“) су дефинисани као пројекти у којима је већина коришћене технологије нова, али постојећа, развијена непосредно пре покретања овог пројекта. То су пројекти развоја нових компјутерских система или одбрамбених система.  Пројекти супер високе технологије („Super High-Tech Projects“) базирани су примарно на новим, до тада непостојећим технологијама, које морају бити развијене у току извршавања пројекта. Овакви пројекти су ретки и изводе се од стране неколико најчешће великих организација или владиних агенција.

Категоризација софтверских пројеката може се вршити у односу на више критеријума [Berntsson-Svensson&Aurum, 2006]: 1. Према типу активности:  Софтверски пројекат развоја новог софтвера  Софтверски пројекат одржавања постојећег софтвера  Софтверски пројекат унапређења постојећег софтвера. 2. У односу на однос клијента и добављача софтвера могу категорисати као:  Клијент орјентисани пројекти развоја софтвера („Bespoke software development“) – развија се специфични „custom-made“ производ или услуга за једног или неколико клијената  Тржишно-орјентисан развој софтвера – добављач развија производ за специфично тржиште без дефинисања клијента унапред  Комбиновани клијентски и тржишно орјентисани развој софтвера – добављач развија производ за специфично тржиште, али са намером да је могуће да се прода производ клијенту са специфичним подешавањима.  Интерни развој софтвера – добављач је истовремено и клијент. Систем се развија за своју компанију или организацију.

Према [Nassif, 2012] [Boehm, 1981], софтверски пројекти се могу категорисати у односу на искуство учесника тима и променљивост захтева као:  Органски (Organic) – пројекти где мањи тим са добрим искуством ради на пројекту са флексибилним захтевима (non-strict requirements)  Полу-зависни (Semi-detached) – пројекти где тим средње величине са мешовитим искуством ради на пројекту са помешаним строгим и флексибилним захтевима  Угњеждени (Embedded) – пројекти са строгим ограничењима (tight constraints).

На основу [Reifer, 2000], софтверски пројекти се могу категорисати према технологији реализације на:  Традиционалне софтверске пројекте  Софтверске пројекте развоја Web апликација. Наравно, савремена технолошка решења укључују и друге категорије софтверских пројеката, нпр. пројекти развоја мобилних апликација итд.

Развој софтвера често припада широј категорији IT (Информационе технологије) пројекта. Посебној категорији IT пројеката припадају пројекти у области развоја информационих система. Према [Cadle&Yeates, 2008], пројекти у области информационих система се могу поделити у 9 категорија:  Развој софтвера (Software development) – развој новог софтверског производа, у складу са захтевима корисника  Имплементирање готовог софтверског пакета (Package implementation) – инсталација и подешавање готових софтверских решења специфичним потребама конкретног клијента  Унапређење постојећег система (System enhancement) – додавање нових функција, усклађивање са променама у окружењу, првенствено са променама прописа  Консултантске услуге анализе пословног проблема и истраживању и предлогу бољег решења (Consultancy and business analysis assignments)  Миграција система (Systems migration) – превођење на нови систем (који је исти али треба да функционише у оквиру другог технолошког окружења или се мења из наведеног разлога) уз минимални утицај на радне активности које користе систем  Промена инфраструктуре (Infrastructure implementation) – увођење нових или замена постојећих хардверских и мрежних уређаја  Outsourcing и-или in-sourcing пројекти – ангажовање других фирми у реализацији појединих IT послова  Пројекти опоравка система (Disaster recovery) – уколико због временских непогода, вируса или других разлога дође до оштећења опреме или софтвера, реализују се пројекти опоравка система; наравно, било би боље превентивно реализовати активности како би се спречиле последице оваквих ситуација  Мали пројекти информационог система (Smaller IS projects) – мања унапређења система ипак захтевају примену техника управљања пројектима, са документацијом која је због тога што је мањи пројекат, адекватно умањена.

Закони еволуције софтвера

Појам адаптивности јавља се и у оквиру активности одржавања софтвера, тј. у активностима након испоруке. E.B. Swanson је у оквиру рада [Swanson, 1976] иницијално дефинисао три категорије одржавања: корективно, адаптивно и перфективно. У оквиру стандарда ISO/IEC 14764 дефинисано је 4 категорије одржавања:  Корективно одржавање: реактивне модификације софтверског производа које се реализују након испоруке како би се кориговали утврђени проблеми.  Адаптивно одржавање: Модификација софтверског производа извршена након испоруке како би се одржао софтверски производ употребљивим у измењеном окружењу или окружењу које се стално мења.  Перфективно одржавање: Модификације софтверског производа након испоруке како би се унапредиле перформансе или могућност одржавања.  Превентивно одржавање: Модификација софтверског производа након испоруке да бисе детектовале и кориговале латентне грешке у софтверском производу пре него што постану ефективне грешке.

Према [Lehman, 1996], формулисано је 8 закона еволуције софтвера, који су раније дефинисани у [Lehman, 1978a] [Lehman, 1978b] [Lehman, 1980a] [Lehman, 1980b] [Lehman, 1991] на основу анализе података које су првобитно прикупљене у току студије IBM процеса програмирања [Lehman, 1969]. Закони еволуције софтвера односе се на програме е-Типа, односно „софтверске системе који решавају проблеме примене рачунара у реалном свету“ [Lehman, 1996]. 1. закон- Рачунарски програми е-Типа који се користе морају се континуирано адаптирати, иначе постају прогресивно мање задовољавајући. Овај закон говори о потреби за констаном повратном информацијом о успешности употребе система и контролисаним одржавањем, како би се одржало задовољство корисника система на одговарајућем нивоу. 2. закон - Како програм еволуира, расте његова комплексност, осим уколико се не реализују активности одржавања и смањења комплексности 3. закон - Процес еволуције програма је саморегулишући, са дистрибуцијом мерења која су блиска нормалној дистрибуцији вредности мерења атрибута процеса и производа. 4. закон – Просечна ефективна глобална стопа активности које се односе на еволуирајући систем је непроменљива у току животног циклуса производа. 5. закон – У току активног живота еволуирајућег програма, садржај сукцесивних испорука је статистички непроменљив. 6. закон – Функционални садржај програма мора стално да расте како би се одржавало задовољство корисника у току животног циклуса програма. 7. закон – Програми е-Типа ће бити „доживљени од стране корисника“ као програми чији квалитет опада уколико се ригорозно не одржавају и адаптирају на променљиво операционо окружење. 8. закон – Процес програмирања у креирању програма е-Типа састоји се од више циклуса и вишенивовске повратне спреге и мора се тако третирати како би успешно били модификовани или унапређени.

Карактеристике агилног приступа развоју софтвера

Термин „агилност“ дефинисана је у [Wendler, 2013] на основу дефиниција из [Ganguly et al, 2009] и [Dove, 1999] као „ефективна интеграција способнисти одговора и управљање знањем у циљу да се брзо, ефикасно и прецизно прилагоди (у проактивном и реактивном смислу) било којој неочекиваној (или непредвиђеној) промени у пословању/потребама или могућностима клијента без компромиса који би се односио на трошкове или квалитет производа/процеса.“ Агилност је блиско повезана са флексибилношћу и сужавањем („leanness“), међутим треба ове термине сматрати концептима у оквиру агилности као ширег појма. У оквиру [Conboy&Fitzgerald, 2004] термин агилност разматран је са историјског аспекта, где је приказано да је овај термин уведен прво у области менаџмента, односно истраживања у области пословних система као термин агилне производње, а тек касније је уведен у софтверску индустрију. У оквиру [Conboy&Fitzgerald, 2004] термин агилности је упоређен са термином флексибилност („способност за прилагођавање на промене“), где разликује проактивну и реактивну флексибилност. Агилност као термин укључује флексибилност и временску димензију (брзину одговора на промене), а такође и одбацивање сувишног, „урадити више са мање ресурса“, економичност и једноставност – „leanness”. Коначно, дефиниција агилности према [Conboy&Fitzgerald, 2004] је: „континуална спремност ентитета да брзо и инхерентно, проактивно или реактивно, прихвати промену кроз високо квалитетне, једноставне, економичне компоненте и релације са окружењем“.

У оквиру истраживања [Wendler, 2013] извршена је систематизација 28 фрејмворка и модела који описују концепте који одређују појам агилности и концепте који припадају том ширем појму као елементе којима би се могла мерити агилност. Општи појам агилности је декомпозицијом на 33 концепата категорисан кроз четири домена: Агилну производњу, Агилни развој софтвера, Агилну организацију и Агилну радну снагу, односно кроз пет домена: организациона култура, технологија, радна снага, клијент, организационе способности.

Примена агилног приступа развоју софтвера формално је започела 2001. године, дефинисањем принципа агилног развоја од стране Agile Software Development Alliance [Agile SD Alliance] кроз тзв. Agile Manifesto [AgileManifesto, 2001]. Међународне организације које се баве стандардима препознале су агилни приступ као приступ који води ка успеху софтверског пројекта и дефинисале низ стандарда који укључује агилни приступ, као што је ISO/IEC/IEEE 26515:2012 Systems and Software Engineering — Developing User Documentation in an Agile Environment.

Агилни приступ развоју софтвера подразумева следеће четири основне вредности [AgileManifesto, 2001]:  Појединци и интеракције су важније од процеса и алата  Софтвер који функционише је важнији од детаљне документације  Сарадња са клијентом је важнија од преговора у односу на уговор  Одговарати на промене је важније него бити доследан плану

У складу са наведеним основним вредностима агилног приступа, дефинисано је 12 принципа агилног развоја софтвера [AgileManifesto, 2001]: 1. Наш највиши приоритет је задовољити клијента кроз ране и континуиране испоруке корисног софтвера.. 2. Радо прихватити („поздравити“) измене захтева, чак и касно у развоју. Агилни процеси користе промене као клијентову конкурентску предност. 3. Испоручити радни софтвер често, у фреквенцијама од неколико недеља до неколико месеци, са настојањем да интервали буду што краћи. 4. Људи из пословног окружења и људи у развоју морају радити заједно сваког дана у току пројекта. 5. Градити пројекте око мотивисаних појединаца. Дати им радно окружење и подршку која им је потребна и веровати им да ће завршити посао. 6. Најефикаснији и ефектнији метод прослеђивања информација у развојном тиму је конверзација „лицем у лице“. 7. Софтвер који функционише је примарна мера прогреса. 8. Агилни процеси промовишу одрживи развој. 9. Спонзори, девелопери и корисници би требали да одржавају константну комуникацију бесконачно. 10. Континуално обраћање пажње на техничку изврсност и добар дизајн унапређује агилност. 11. Једноставност, тј. уметност максимизирања посла који није урађен, је кључна. 12. Најбоље архитектуре, захтеви и дизајн долази од самоорганизујућих тимова. 13. У редовним интервалима, тим размишља о тиме како да постане ефективнији, затим подешава и усклађује понашање у складу са тиме.

Према [Alleman, 2002], агилне методе у развоју софтвера имају следеће карактеристике: 1. Инкременталне, еволутивне и адаптирају се на промене у екстерним и интерним догађајима 2. Модуларне и сажете („lean“) омогућавајући да се компоненте процеса (или решења) постављају или уклањају у зависности од специфичних потреба учесника и заинтересованих страна 3. Базиране на времену – укључују конкурентне и итеративне радне циклусе. 4. Самоорганизујуће - у нормативном смислу, не нуде много упутства у смислу структуре и контроле. Агилне методе се заснивају на хеуристикама и партиципативним процесима, пре него на нормативним и рационалним методама и упутствима.

У раду [Bose, 2008] представљене су основне карактеристике и предности агилних метода развоја софтвера, као што је приказано следећом табелом.

Табела 2.3.2.1. Карактеристике агилних метода развоја софтвера, према Boose [Bose, 2008] Особина Предности Континуално прикупљање захтева Клијенти одлажу одлуке о кључним елементима, софтвер остаје флексибилан Фреквентна „лицем у лице“ Превазилазе се неспоразуми, гради се интеракција поверење између чланова тима Програмирање у пару Лакши тимски рад, боље власништво над кодом Рефакторисање Постепено унапређење кода без креирања шок таласа Континуирана испорука и Детекција и поправка грешака раније интеграција у пројекту, већи квалитет софтвера Рани одговор од стране Избегавање скупих измена на крају, клијентског експерта мањи трошкови развоја Минимизације документације Мање време развоја, нижи трошкови документовања

У почетном периоду применa агилних метода (пре дефинисања Agile Manifesto) je понекад сматрана рискантна, јер је интерпретирана као супротна од модела који се заснивају на планирању и превиђању и зато је сматрано да примена агилних метода може довести до хаоса [Boehm, 2002].

У оквиру [Boehm, 2002] извршено је упоређивање карактеристика плански- заснованих и агилних метода. У раду [Nerur et al, 2005] [Leau et al, 2012] [Javanmard&Alian, 2015] дата је компарација традиционалних (waterfall) и агилних метода развоја софтвера. У раду [Boehm, 2002] утврђено је да свака од наведене две групе метода (традиционална/waterfall и агилна група метода) имају област одговарајуће примене и не може се тврдити да је нека група метода погоднија у општем смислу. Такође, разматрана је и могућности хибридног приступа у скалирању између наведена два екстрема [Ambler&Lines, 2013].

Компарација агилних и традиционалних метода развоја софтвера, према Javanmard&Alian [Javanmard&Alian, 2015]

Компарација фаза животног циклуса Waterfall приступа и корака у оквиру једног циклуса примене агилне методе у развоју софтвера [Huo et al, 2004]

Компарација агилних метода развоја софтвера

У раду [Dyba& Dingsøyr, 2008] [Abrahamsson et al, 2003] дат је преглед најчешће коришћених агилних метода развоја софтвера и описане су најважније карактеристике, као што је приказано у табели 2.3.3.1.

Табела 2.3.3.1. Приказ карактеристика најчешће коришћених агилних метода, према Abrahamsson et al , Dyba& Dingsøyr, Agile PrepCast [Abrahamsson et al, 2003] [Dyba& Dingsøyr, 2008] АГИЛНА ОПИС МЕТОДА „Crystal Фамилија метода за колокацијске тимове различитих величина methodolog и критичности: Clear, Yellow, Orange, Red, Blue. Једна од ies“ најагилнијих метода „Crystal Clear“ фокусирана је на Кристалне комуникацију у малим тимовима у развоју софтвера који није методoлог животно-критичан, а карактеристике су: фреквентна испорука, ије рефлективно унапређење, осмотска комуникација, лична безбедност, фокус, лак приступ експертским корисницима и захтеви за техничким окружењем. [Cockburn, 2004] Фамилија Crystal метода омогућава избор одговарајуће методе у складу са величином и критичности, а „боја“ методе одређује тежину методе. Већи пројекти захтевају више координације и теже методе. Crystal приступ омогућава прилагођавање метода како би одговарале различитим околоностима и конкретним пројектима. [Abrahamsson et al, 2003] Crystal Methods – колекција приступа агилном развоју софтвера, који се фокусира примарно на људе и интеракцију међу њима док раде на пројектима развоја софтвера. Такође, фокус је на критичности и приоритетима елемената система који се развија, у односу на значај и утицај на пословање. Људи и процеси, као и њихове интеракције представљају језгро развојног процеса. [Agile PrepCast, 2013] „Dynamic Дели пројекте на 3 фазе: пред-пројекат, пројектни животни software циклус, пост-пројекат. Девет основних принципа: укључивање developme корисника, оснаживање пројектног тима, фреквентна nt method испорука, фокусирање на тренутне пословне потребе, (DSDM)” итеративни и инкрементални развој, дозвољавање реверзних Метода промена, дефинисање обухвата високог нивоа пре почетка динамичко пројекта, тестирање у току животног циклуса, ефикасна и г развоја ефективна комуникација. [Stapleton, 2003] Основна идеја софтвера DSDM je прилагођавање времена и ресурса и тек након тога усаглашавање функционалности предлога решења у складу са расположивим временом и ресурсима. [Abrahamsson et al, 2003] DSDM првенствено представља развојни оквир за агилну испоруку у оквиру билоког пројекта, али првенствено коришћен као метод развоја софтвера. Настао 1994 у циљу увођења дисциплине у RAD (Rapid Application Development), од 2007 постаје генерички приступ пројектном менаџменту и испоруци решења. Основни принципи су итеративни и инкрементални приступ уз континуално укључивање корисника/клијента. У оквиру DSDM фиксирају се трошкови, квалитет и време према спољашњем договору, а интерно користи MoSCoW класификацију према приоритетима особина софтвера који треба да буду реализоване – “must”, “should”, “could”, “won’t have to”. DSDM се може користити и за не-ИТ решења. [Agile PrepCast, 2013] „Feature- Представља метод процес-орјентисаног развоја софтвера за driven развој пословно критичних система. Фокусира се на дизајн и developme фазе изградње. Наглашава аспекте квалитета кроз процес nt“ (FDD) развоја и укључује фреквентне и опипљиве испоруе, кроз Развој прецизан мониторинг прогреса на пројекту. [Abrahamsson et al, заснован 2003] Комбинује модел-базиран и агилни развој са нагласком на на иницијалном објектном моделу, подели рада на особине и особинама итеративном дизајну сваке особине софтвера. Тврди се да је софтвера овај приступ погодан за развој критичних система. Итерација особине састоји се од две фазе: дизајн и развој. [Palmer& Felsing, 2002] Итеративни и инкрементални процес развоја софтвера са нагласком на перспективу клијента и његовог вредновања потребне функционалности (особина софтвера). Главни циљ је доставити опипљиве резултате, софтвер који ради и то испоручити у предвиђеном времену. “Lean” Адаптација принципа из „lean” производње, а посебно из развој Toyota производног система за развој софтвера. Састоји се од 7 софтвера принципа: елиминација вишка (непотребнога), повећати учење, доносити одлуке што касније, испоручивати што пре, оснажити тим, градити интегритет и имати увид у целину. [Poppendieck&Poppendieck, 2003] Lean software development – покретн намењен редукцији грешака и губљења времена, уз максимизирање едукације и ефикасности. Његови принципи су оригинално коришћени у производњи и IT, a након тога прилагођени програмирању. Основни принцип је примарна посвећеност вредности која се ствара за крајњег корисника, уз интелигентно чување ресурса. [Agile PrepCast, 2013] SCRUM Фокусира се на пројектни менаџмент у ситуацијама где је тешко планирати унапред, уз механизме за „емпиријску процесну контролу“ уз вишеструке повратне спреге. Софтвер се развија од стране само-организујућих тимова у инкрементима (који се зову „спринтови“), почев од планирања до завршетка који укључује ревизију. Особине које треба да буду имплементиране у систему се региструју у оквиру „backlog”. Након регистрације, власник производа одлучује која ставка из backlog-a треба да буду развијене у следећем спринту. Чланови тима координирају свој рад у свакодневним састанцима. Један члан тима („scrum master”) je задужен за решавање проблема који су учинили да тим буде заустављен у ефективном раду. [Schwaber& Beedle, 2001] Самоорганизујући тимови се сматрају јединицом која треба да достигне заједнички циљ, подстиче колокацију чланова тим, вербалну комуникацију између чланова тима. Главни принцип SCRUM je омогућавање да клијент може да промени мишљење о томе шта жели или шта му је потребно (назива се „requirements churn”) и прихватање да проблем који се решава не може бити у потпуности разјашњен и дефинисан, али се зато фокусира на максимизирање способности тима да испоручује брзо и одговара на актуелне захтеве. [Agile PrepCast, 2013] Extreme Представља колекцију добро познатих практичних упутстава и Programmi искустава из софтверског инжењерства. [Abrahamsson et al, ng 2003] Састоји се од 12 принципа праксе: игра планирања, (XP, XP2) мале испоруке, метафора, једноставан дизајн, тестирање, Екстремно рефакторисање, програмирање у пару, колективно власништво програмир над артефактима, континуирана интеграција, 40-часовна радна ање недеља, стална комуникација са корисницима (on-site), стандарди кодирања. Ревизија путем XP2 предлаже принципе праксе: седети заједно, целина тима, информативни радни простор, енергизиран рад, програмирање у пару, корисникове приче („user stories”) као спецификација захтева, итерације на недељном нивоу и на 3-месечном нивоу, затишја (slack), изградња од 10 минута, континуирана интеграција, програмирање базирано на тестирању („test-first programming”), инкрементални дизајн. [Beck, 2004] Промовише фреквентне испоруке у малим развојним циклусима, у циљу унапређења продуктивности и увођења тачки контроле где нови захтеви корисника могу бити прилагођени. Остале особине: програмирање у пару или екстензивна ревизија кода, тестирање целог кода једног модула, избегавање програмирања особине софтвера све док заиста није потребна, равна структура менаџмента, једноставност и јасност кода, очекивање промена у захтевима корисника како време пролази и проблем је боље схваћен, фреквентна комуникација са клијентима и између програмера. [Agile PrepCast, 2013] Адаптивни Настао на основама Rapid Application Development. Укључује развој принципе континуалне адаптације процеса развоја, као софтвера понављајуће серије шпекулација, сарадње и учења. У овом (ASD) динамичком циклусу обезбеђује константно учење и адаптацију актуелном стању пројекта. Карактеристике ASD животног циклуса: фокусиран на мисију, базиран на карактеристикама софтвера које је потребно реализовати, итеративно, временски дефинисан(timeboxed), орјентисан на управљање ризицима и толерантан на промене.[Agile PrepCast, 2013] Kanban Представља систем временског планирања (scheduling) за lean и JIT (Just in time) производњу. Представља систем контроле логистичког ланца са производне тачке гледишта. Развијен је у Toyota,као систем за унапређење и одржавање високог нивоа производње. Kanban представља метод кроз који се постиже JIT и представља ефективни алат подршке извршавања производног система у целини, уз подршку промоцији унапређења. [Agile PrepCast, 2013]

Рад [Qumer&Henderson-Sellers, 2006] послужио је као основ за развој методе за компарацију карактеристика различитих метода агилног приступа развоју софтвера применом реализованог аналитичког алата 4-DAT, а примена у компарацији XP и SCRUM метода је представљена у раду [Fendandes&Almeida, 2010].

У оквиру рада [Abrahamsson et al, 2003] дат је преглед агилних метода и поред Историјски преглед агилних метода приказан у овом раду дат је на слици 2.3.3.1.:

Историјски преглед метода агилног приступа развоју софтвера према Abrahamsson et al [Abrahamsson et al, 2003]

У оквиру [Agile PrepCast, 2013] дата је детаљна компарација (представљена у Табели 2.3.3.2.) агилних метода у односу на различите критеријуме:  Скалабилност – ниво до ког агилна метода може бити коришћена за различите врсте развоја производа, различите типове пројеката и различите примене  Величина тима – идеалан број чланова развојног тима за максималну ефективност примене агилне методе  Дужина итерације – саветована дужина времена (периода итерације) за испоруку производног инкремента клијенту, према наведеног агилној методи  Улоге и одговорности – Ниво до ког су дефинисане специфичне улоге и одговорности у примени конкретне агилне методе  Процес центричне или човек-центричне – да ли је агилна метода орјентисана на процес или на људски фактор  Подршка виртуалним тимовима – ниво до ког агилна метода подржава комуникацију и координацију рада виртуалних тимова  Ниво смањења ризика – ниво до ког се ризик који је инхерентан пројекту може смањити применом наведеног агилног метода  Интеракција са клијентом – ниво интеракције са клијентом потребан за максималну ефективност примене наведене агилне методе  Предности – главни аспекти предности примене наведене методе  Недостаци – главни недостаци наведене методе, због којих наведена метода не треба да се користи

У раду [Stojanovic et al, 2003], [Agile PrepCast, 2013] и [Javanmard&Alian, 2015] дата је компарација агилних метода у односу на различите критерујуме, а посебно у оквиру [Stojanovic et al, 2003] извршена је анализа и компарација приступа моделовању у оквиру развоја софтвера применом различитих агилних метода.

Компарација Агилних метода, према различитим критеријумима [Agile PrepCast, 2013]

Компарација Агилних метода, према Javanmard&Alian [Javanmard&Alian, 2015]

Табела 2.3.3.4. Компарација агилних метода према Stojanovic et al [Stojanovic et al, 2003]

Табела 2.3.3.4. Компарација агилних метода према Stojanovic et al [Stojanovic et al, 2003] (наставак)

2.3.4. Истраживање улоге инжењерства захтева, моделовања, дизајна и документације у агилном развоју софтвера

У оквиру рада [Cao&Balasubramaniam, 2008] описана су претходна истраживања, као и практична искуства анализом индустријске праксе (16 компанија) у области инжењерства захтева (који се изједначава као термин са анализом захтева) применом агилног приступа. Основни резултати су: 1) преферирање личне комуникације у односу на комуникацијом путем документације; 2) итеративно инжењерство захтева, где захтеви нису унапред дефинисани, већ еволуирају у току развоја; 3) захтеви се рангирају константно у току развоја у складу са приоритетима, који се дефинишу у складу са доприносом пословним вредностима. Листе захтеваних особина софтвера се константно формирају и рангирају, на почетку сваког развојног циклуса; 4) управљање изменама захтева кроз константно планирање кроз 2 типа примена: додавање или брисање особина софтвера као и измене већ раније реализованих особина; 5) реализација прототипа, који се најчешће касније унапређује и поставља као решење, уместо да буде третирано као привремено решење које ће бити замењено правим решењем; 6) тест-базирани развој где се дефинишу тестови пре писања кода као форма прецизне спецификације шта и како апликација треба да функционише; 7) састанци ревизије.

У раду [Paetsch et al, 2003] описане су технике инжењерства захтева у контексту агилног развоја софтвера. Технике издвајања захтева корисника служе за разумевање апликационог домена, пословних потреба, ограничења система, заинтересованих страна и самог пословног проблема. Најчешће технике обухватају: интервју, креирање случајева коришћења и сценарија, посматрање и социјална анализа, дискусује фокусних група, Brainstorming, реализација прототипа. Након прикупљања захтева, следи њихова анализа уз технике: удружени развој апликације (Joint Application Development), одређивање приоритета захтева за развој (од стране клијента – издвајање захтеваних карактеристика софтвера које омогућавају највеће користи у пословању али и чланова развојног тима – разматрање могућности техничке реализације – ризика, трошкова, потешкоћа), моделовање система (најчешћи модели: модели тока података, модели семантике података, објектно- орјентисани модели). Након приоритизације, реализује се документовање, валидација и управљање захтевима. У овом раду су у свим сегментима инжењерства захтева описана искуства добре праксе у примени у оквиру агилних приступа.

У оквиру рада [Stojanovic et al, 2003] описано је истраживање улоге моделовања у агилном приступу развоја софтвера. Резултати истраживања представљени су у табели 2.3.4.1.

Табела 2.3.4.1. Улога моделовања у примени агилних метода развоја софтвера, према Stojanovic et al [Stojanovic et al, 2003]

У оквиру [Fox et al, 2008] разматран је аспект кориснички-орјентисаног дизајна у контексту примене агилних метода, кроз преглед постојећих истраживања и емпиријско истраживање реализације конкретних софтверских пројеката. Првенствени фокус истраживања овог рада је у итеративном дизајну корисничког интерфејса који се одвија паралелно са техничком имплементацијом решења.

У раду [Rubin&Rubin, 2010] описано је истраживање у области улоге документације у агилном развоју софтвера. Као један од главних доприноса агилног приступа у овом раду се сматра смањење бирократије традиционалних методологија развоја софтвера. Ипак, документација има важну улогу у размени знања. Суштинска идеја наведеног рада је у предлогу адаптивне документације која ће бити усклађена са агилним принципима развоја. Адаптивна документација се у овом раду уводи кроз имплементацију приступа активног документационо софтверског дизајна (Active Documentation Software Design) као активна документација која је блиско повезана са изорним кодом, где се измене и документацији рефлектују на измене изворног кода и обрнуто – измене изворног кода омогућавају измене релевантне документације.

Дисциплиновани агилни приступ развоју софтвера

У току процеса прилагођавања агилних метода реалној употреби, различита терминологија из разних метода и некомплетност појединих метода довела је до потребе да се наведене методе анализирају у смислу издвајања заједничких карактеристика и општег модела агилног приступа развоју софтвера [Janus, 2012], као и интегришу [Ambler, 2013]. Из наведених разлога, од 2006-2012. године [Ambler&Lines, 2012] у оквиру фирме IBM развијен је тзв. Disciplined Agile Delivery (DAD) фрејмворк, као процесни оквир орјентисан на испоруку решења применом интеграције различитих агилних метода. Основне карактеристике DAD су [Ambler&Lines, 2013]:  орјентисан на људе („people-first“),  хибридан у примени стратегија из више агилних метода: Scrum, Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), Kanban, Outside in Development (OID), and Agile Data (AD)  орјентисан на учење,  орјентисан на решења, тј. решавање проблема у ширем контексту– „од једноставног креирања софтвера до обезбеђивања употребљивих решења која обезбеђују стварну пословну вредност заинтересованим странама у оквиру економских, културних и технолошких ограничења. Софтвер јесте важан, али у циљу обезбеђивања подршке потребама заинтересованих страна, често се поред софтвера јавља потреба за унапређењем хардвера и променама у пословним и оперативним процесима, чак и организационим структурама у организацијама где раде заинтересоване стране.“ [Ambler&Lines, 2013]  орјентисан испоруку – орјентација на континуирану испоруку, кроз животни циклус  орјентисан на реализацију циљева („goal driven“) – тим мора да се адаптира на промене у захтевима и развојним приоритетима, мора да разуме контекст у ком раде...  вредновање ризика („risk- value delivery“),  усклађеност са организационим потребама („enterprise-aware“) – „дисциплиновани агилни тимови препознају да представљају део већег организационог екосистема и у складу са тиме реализују своје активности, сарађујући са другим тимовима у оквиру организације.“ [Ambler&Lines, 2013]  скалабилност.

На слици 2.3.2.1. приказан је животни циклус дисциплинованог агилног приступа испоруци IT решења: 1. DAD животни циклус започиње идентификацијом, приоритизацијом и селекцијом пројеката, где је иницијална визија и буџет (финансирање) дефинисано. 2. Фаза заснивања („inception phase“) пројекта пролази кроз једну или више итерација. Састоји се из иницијалног моделовања, планирања и организације, где су иницијални захтеви дефинисани и испоручен иницијални план испоруке и обезбеђена је сагласност заинтересоване стране. 3. Фаза конструкције се реализује кроз кратке итерације и свака итерација производи потенцијално употребљиво решење. Радне ставке („work items“) се дефинишу и радне ставке највишег приоритета су изабране да буду укључене у план следеће итерације („iteration backlog“). Задаци су дефинисани у оквиру плана итерације. Задаци се реализују и оквиру итерације у оквиру активности сваког дана и сваког дана се одржавају састанци координације. Након што је итерација завршена, потенцијално употревљиво решење се испоручује на преглед и ретроспективу итерације, креира се демо верзија за заинтересоване стране и она се њима презентује, дефинише се стратегија за следећу итерацију. У оквиру састанка планирања итерације („iteration planning session“) селектују се радне ставке и идентификују радни задаци за следећу итерацију. Фаза конструкције је завршена када је довољно функционалности реализовано. 4. Фаза транзиције почиње када се реализовано решење поставља у реалну радну средину где ће бити коришћено („released in production“). Ова фаза се такође састоји из неколико кратких итерација. 5. Коначно, решење се користи у реалном радном окружењу, уз подршку која треба да прихвати и реализује захтеве за унапређењем или извештаје о грешкама.

Слика 2.3.4.1. Животни циклус у оквиру дисциплиноване агилне испоруке (DAD) према Ambler&Lines [Ambler&Lines, 2013]

У складу са агилним приступом, адаптивност у смислу спремности и прилагођавању на промене представља једну од четири најважније вредности. У оквиру основних принципа агилног развоја, промене се односе на промене захтева корисника као и на омогућавање самоорганизованости тимова који интерно унапређују своју организацију и понашање ради унапређења ефикасности и ефективности рада. ARHITEKTURA INFORMACIONOG SISTEMA

DEFINICIJA

»Aрхитектура се дефинише као основна организација система садржана у његовим компонентама, њихова међусобна веза и веза са окружењем и принципи који владају развојем и еволуцијом система.« [ANSI/IEEE 1471-2000]

»Архитектура информационог система је део ширег скупа архитектура и модела који су релевантни за организацију. На различитим нивоима архитектуре можемо разликовати:  Архитектуру организације/предузећа (Enterprise Architecture),  Aрхитектуру информационог система (ISA – Information System Architecture),  Софтверску архитектуру (SWA – Software Architecture).« [Vasconcelos et al, 2007]

Zachman-ov framework [Zachman, 1987] je први одвојио концепт SWA и ISA, односно показао да SWA није једини који чини ISA.

Према [Vasconcelos et al, 2007], архитектуру информационог система чине подсистеми, односно архитектуре:  ИНФОРМАЦИОНА АРХИТЕКТУРА – архитектура података,  АПЛИКАЦИОНА АРХИТЕКТУРА – функционална архитектура,  ТЕХНОЛОШКА АРХИТЕКТУРА – инфраструктурно-платформска архитектура.

Нивои архитектуре информационих система према Whitworth&Zaic [Whitworth&Zaic, 2003]

Zachman-ov framework

Eлементи (компоненте) компјутерски заснованог информационог система су представљени наредном табелом.

Компоненте архитектуре информационог система КОМПОНЕНТА АРХИТЕКТУРЕ РЕФЕРЕНЦА ИНФОРМАЦИОНОГ СИСТЕМА ИНФОРМАЦИОНА АРХИТЕКТУРА [Vasconcelos et al, 2007] - Подаци („Data“) [Elmasri& Navathe, 2007][Krsmanović& Mandić, 1995] - Модели података [Lazarević et al, 1988] - Структуре података и системи [Vasconcelos et al, 2007] [Elmasri& за управљање базама Navathe, 2007] података АПЛИКАЦИОНА АРХИТЕКТУРА [Vasconcelos et al, 2007] - Модели функција [Lazarević et al, 1988] - Софтверска архитектура, [Dulović, 1991] [Stankić, 2005] софтвер („software“), [Vasconcelos et al, 2007] [Zachman, апликациони софтвер 1987] [Elmasri& Navathe, 2007] [Krsmanović& Mandić, 1995] АРХИТЕКТУРА РЕСУРСА [Lazarević et al, 1988]  ТЕХНОЛОШКА АРХИТЕКТУРА [Vasconcelos et al, 2007], [Dulović, 1991] - Медији за чување [Elmasri& Navathe, 2007] података - Рачунарска опрема [Stankić, 2005] [Elmasri& Navathe, 2007] (“Hardware”) [Krsmanović& Mandić, 1995] - Мрежна опрема [Stankić, 2005][Krsmanović& Mandić, (“Netware”) 1995]  КАДРОВИ (“Lifeware”) [Lazarević et al, 1988] [Elmasri& Navathe, 2007] [Krsmanović& Mandić, 1995] - Персонал који користи и [Elmasri& Navathe, 2007] управља подацима - Програмери апликација [Elmasri& Navathe, 2007]  ОРГАНИЗАЦИОНА [Lazarević et al, 1988] [Dulović, 1991] АРХИТЕКТУРА (“Orgware”) [Stankić, 2005] [Krsmanović& Mandić, 1995] - Принципи и концепти [Dulović, 1991] - Организациона правила [Dulović, 1991] коришћења система - Токови информисања [Dulović, 1991] - Методе и поступци [Dulović, 1991] коришћења система

SOFTVERSKA ARHITEKTURA (iz skripte Ivankovic/Lacmanovic)

ДЕФИНИЦИЈА СОФТВЕРСКЕ АРХИТЕКТУРЕ

Definisanje arhitekture softverske aplikacije predstavlja proces kreiranja softvera koji zadovoljava sve tehničke i funkcionalne zahteve, dok u isto vreme optimizuje kvalitativne osobine kao što su performanse, bezbednost i mogućnost jednostavnog održavanja.

 Arhitektura sistema predstavlja skelet datog sistema.  Za arhitekturu sistema su odgovorne arhitekte. Njihov posao je da prikupe zahteve, dizajniraju ceo sistem, osiguraju da implementacija odgovara očekivanju i na kraju omoguće da korisnici dobiju ono što im je potrebno (što ne mora uvek da bude ono što su na početku tražili).  Arhitekte takođe vrše komunikaciju sa timovima koji su zaduženi za razvoj sistema. Ova komunikacija se uglavnom vrši putem UML dijagrama.

Softverska arhitektura bi trebala da:  Prikaže strukturu sistema ali da sakrije detalje implementacije  Realizuje sve slučajeve korišćenja i scenarije  Odgovori i na funkcionalne i na kvalitativne zahteve

Primenom opštih principa softverskog inženjerstva, kao i principa objektno orjentisanog programiranja, arhitekte imaju za cilj da sistem podele u što je moguće manje celine. Arhitektura softvera ima određene preduslove - principi u dizajniranju sistema, i određene postuslove - implementirani sistem koji daje očekivane rezultate. Softverska arhitektura se fokusira na to kako se koriste najvažniji elementi i komponente u okviru aplikacije, ili kako oni komuniciraju i sarađuju sa ostalim elementima i komponentama u okviru aplikacije.

Odabir struktura podataka i algoritama kao i načina implementacije pojedinih komponenti predstavlja oblast softverskog dizajna. Softverska arhitektura i softverski dizajn se veoma često preklapaju. Ove dve oblasti se zajedno kombinuju u cilju kreiranja što kvalitetnijeg softvera. Dizajn se koristi kako bi se realizovala softverska arhitektura.

CILJEVI ARHITEKTURE

Softverska arhitektura ima za cilj da  kreira vezu između poslovnih zahteva i tehničkih zahteva razumevanjem slučajeva korišćenja, kao i pronalaženjem načina da se ti slučajevi korišćenja implementiraju u softver.  Cilj arhitekture je da identifikuje zahteve koji utiču na strukturu aplikacije.

Dobra arhitektura smanjuje poslovne rizike povezane sa kreiranjem tehničkog rešenja. Dobar dizajn je dovoljno fleksibilan da izdrži prirodne promene u softverskoj i hardverskoj tehnologiji, kao i u korisničkim zahtevima, koji će se dešavati tokom životnog veka aplikacije. Arhitektura mora uzeti u obzir ukupne efekte odluka o softverskom dizajnu, kompromis između kvalitativnih osobina (npr. performanse i sigurnost), kao i kompromise kako bi se zadovoljili zahtevi korisnika, sistema i poslovnih zahteva. Važno je razumeti korisničke zahteve, kao i poslovne zahteve za bržim odzivom, boljom podrškom u cilju izmene tokova rada, kao i lakšim izmenama. Ovo su faktori koji utiču na softversku arhitekturu, i koji će je oblikovati u budućnosti tokom životnog veka softvera.

Potrebno je razumeti sledeće zahteve:  Zadovoljstvo korisnika - dizajn koji je u skladu sa zadovoljstvom korisnika mora da bude fleksibilan i da se može prilagoditi potrebama i željama korisnika. Aplikaciju treba kreirati tako da je korisnik može prilagoditi sebi. Treba mu omogućiti da on sam definiše kako želi da vrši interakciju sa sistemom, umesto da mu se to nameće. Ovde treba voditi računa da se ne pretera sa nepotrebnim opcijama i podešavanjima koja mogu dovesti do konfuzije. Treba dizajnirati aplikaciju tako da budu jednostavne i da je lako pronaći informaciju i koristiti aplikaciju.  Treba iskorisiti već postojeće platforme i tehnologije. Korisititi framework-e visokog nivoa, gde to ima smisla, kako bi se mogli fokusirati na funkcionalne zahteve aplikacije, a ne da se ponovo kreira nešto što već postoji. Treba korisiti paterne koji predstavljaju izvor proverenih rešenja za uobičajene probleme.  Fleksibilan dizajn - koristi prednosti slabog povezivanja kako bi se isti kod mogao koristiti na više mesta i kako bi se olakšalo održavanje. Mogu se korisiti prednosti servisno orjentisanih tehnologija kao što je SOA kako bi se obezbedila saradnja sa drugim sistemima.  Kada se kreira aplikacija, treba razmišljati o budućim trendovima koji se mogu očekivati u dizajnu nakon postavljanja aplikacije. Npr. treba uzeti u obzir mogućnost korišćenja bogatijih UI alta, povećanje mrežnog protoka i dostupnosti, moguću upotrebu mobilnih uređaja, korišćenje jačeg hardvera, prelazak na cloud, itd. PRINCIPI SOFTVERSKE ARHITEKTURE

Treba razmotriti sledeće ključne principe kada se kreira arhitektura aplikacije:  Kreiraj da menjaš umesto da kreiraš da traje - traba razmotriti kako će se aplikacija vremenom menjati kako bi se što bezbolnije moglo odgovoriti na zahtevane promene.  Modeluj kako bi analizirao i smanjio rizik - treba koristiti alate za modelovanje kao što je UML (Unified Modeling Language), kako bi se bolje sagledali zahtevi, arhitektura i dizajn, i kako bi se analizirao njihov uticaj. Međutim, ne treba modelovati do nivoa koji smanjuje mogućnost da se dizajn lako prilagodi novim zahtevima.  Koristi modele i vizuelizaciju kao alate za komunikaciju i saradnju – efikasna komunikacija, kreiranje odluka i predviđanje izmena predstavljaju ključne faktore u cilju kreiranja dobre arhitekture. Treba koristiti modele, poglede i druga sredstva vizuelizacije kako bi se efikasno komuniciralo sa svim činiocima koji učestvuju u kreiranju softvera.  Identifikovanje ključnih inženjerskih odluka - treba koristiti sve dostupne informacije i znanja kako bi se razumele najčešće inženjerske odluke i uočile oblasti gde se greške najčešće prave. Treba investirati kako bi se na samom početku donele ispravne odluke i kako bi dizajn bio više fleksibilan i otporan na izmene.  Treba koristiti inkrementalan i iterativan pristup kako bi se arhitektura činila boljom. Treba krenuti sa opštom arhitekturom kako bi se kreirala opšta slika, a zatim razvijati samu arhitekturu kroz testiranje i poboljšavanje u skladu sa zahtevima. Ne treba pokušavati da se sve uradi ispravno iz prvog pokušaja. Treba kreirati dizajn taman toliko koliko je neophodno da bi se on mogu testirati u odnosu na zahteve i pretpostavke. Iterativno treba dodavati detalje u dizajn kroz više prolazaka kako bi se obezbedili da smo velike odluke doneli ispravno, a nakon toga se možemo fokusirati na detalje. Uobičajena greška je da se fokusiramo na detalje suviše brzo i da kreiramo opštu sliku pogrešno, koristeći se netačnim ineproverenim pretpostavkama.

КЉУЧНА ПИТАЊА Prilikom kreiranja arhitekture moramo pretpostaviti da će dizajn evoluirati tokom vremena i da ne možemo znati sve što je potrebno unapred kako bi u potpunosti kreirali arhitekturu sistema. Dizajn u opštem slučaju mora da se menja tokom implementiranja aplikacije, kako se aplikacija testira u odnosu na stvarne zahteve. Treba kreirati arhitekturu sa tim na umu, kako bi mogla da se prilagodi zahtevima koji nisu u potpunosti poznati na početku procesa dizajniranja. Ne treba pokušavati da se predvidi bukvalno sve što uključuje arhitektura novog softvera, kao što i ne treba praviti pretpostavke koje se ne mogu proveriti. Umesto toga, treba kreirati sistem koji je otvoren za nove promene. Postoje delovi u okviru dizajna koji se moraju ispraviti u ranim fazama, jer njihov redizajn sa sobom povlači visoku cenu. Ove oblasti treba dobro istražiti i njima posvetiti dodatno vreme kako bi se valjano kreirale.

Treba razmatrati sledeća pitanja kada se kreira arhitektura aplikacije:  Koji su osnovni delovi arhitekture koji predstavljaju najveći rizik ukoliko se ne predvide dovoljno dobro?  Koji su delovi arhitekture koji će se najverovatnije menjati, ili čiji se dizajn može odložiti a da to nema velike posledice na celokupan proces izrade aplikacije?  Koje su pretpostavke i kako ih testirati i proveriti?  Koji uslovi mogu dovesti do izmene dizajna?

Prilikom kreiranja softverske arhitekture, treba uzeti u obzir sledeće koncepte:  Kako će korisnici koristiti aplikaciju?  Kako će aplikacija biti postavljena na krajnje okruženje na kom će biti korišćena?  Koji su zahtevi sa stanovišta sigurnosti, performansi, konkurentnosti, internacionalizacije i konfiguracije?  Kako dizajnirati aplikaciju da bude fleksibilna i laka za održavanje tokom njenog životnog veka?

Kada testiramo arhitekturu, treba razmotriti sledeća pitanja:  Koje pretpostavke su učinjene u okviru arhitekture?  Koje eksplicitne ili izvedene zahteve ova arhitektura zadovoljava?  Koji su ključni rizici u okviru kreirane arhitekture i korišćenog pristupa?  Koje kontramere su primenjene kako bi se ublažili ključni rizici?  Na koje načine je nova arhitektura poboljšanje u odnosu na prethodnu arhitekturu?

TIPOVI SOFTVERSKE ARHITEKTURE

Архитектурни патерн је опште, поново-искористиво решење за уобичајене проблеме који се јављају у софтверској архитектури у оквиру одређеног контекста.

KLIJENT.SERVER ARHITEKTURE У трослојном моделу клијент-сервер система, основни елементи архитектуре су [Mogin et al, 2000]: 1. Сервер базе података – задужен је за подршку управљања обрадом података и логике обраде података 2. Апликациони сервер – задужен је за подршку логике презентације 3. Апликациони клијент – задужен је за подршку управљања презентацијом.

SERVISNO ORJENTISANE ARHITEKTURE Према [Alonso et al, 2004], коришћење web сервиса се заснива на претпоставци да је функционалност која је дата јавности на располагање обликована и изложена као сервис. Суштински, сервис представља поцедуру, метод или објекат са стабилним интерфејсом који може бити позван од стране клијента. Захтевање и извршавање сервиса подразумева да један рачунарски програм позива други (који реализује сервис). Према [Papazoglou&Georgakopoulos, 2003], сервис-орјентисано рачунарство представља примену сервиса као фундаментални елемент у развоју апликација. Сервисно-орјентисане архитектуре заснивају се на сервисима, њиховим описима и подршци основним операцијама (публикација сервиса, откривање сервиса, селекција и повезивање). Према [Papazoglou&Georgakopoulos, 2003], под сервисом подразумевамо самостално-описане отворене компоненте које подржавају брзу и јефтину композицију дистрибуираних апликација.

Архитектура савремених пословних апликација орјентисана је на издвајање података, пословних правила и пословних процеса у посебне модуле, при чему тим слојевима управљају посебни системи:  подацима управљају системи за управљање базама података  Пословним правилима управљају системи за управљање пословним правилима  Пословним процесима управљају системи за управљање пословним процесима.[Naab, 2012]

UML U PRIKAZU SOFTVERSKE ARHITEKTURE

2.2.1.1. PRIMER STRUKTURE MENIJA POSLOVNE APLIKACIJE

Uobičajena struktura poslovne softverske aplikacije sastoji se iz odeljka za rad sa šifarnicima (opšti podaci), podrške poslovnim procesima, rad sa pretragom izveštajima, kao i servisne opcije.

<> Sifarnici

Obrada

<> <> Prijava na sistem Meni aplikacije

Korisnik

Pretraga <>

Izvestaji <>

Korisnici

Servis <> <>

<> Bekap

2.2.1.2. PRIMER SOFTVERSKIH FUNKCIJA POSLOVNE APLIKACIJE

Uobičajene softverske funkcije poslovne aplikacije obuhvataju: CRUD operacije (unos (C - create), čitanje podataka (R- read), izmena (U – update), brisanje (D – delete); Predstavljanje učitanih podataka (tabelarni prikaz, pojedinačni prikaz, prikaz za štampu, grafički prikaz (grafikon)); Manipulaciju podacima (navigacija, pozicioniranje, selekcija, označavanje, filtriranje, sortiranje); Obrada podataka (statistike, razna sumiranja); Eksport podataka u različite formate tekstualnih datoteka ili dokumente.

Unos

Brisanje

Izmena

Azuriranje podataka

Tabelarni prikaz

Pojedinačni prikaz

Predstavljanje podataka Prikaz za štampu

Korisnik aplikacije Grafički prikaz Navigacija

Pozicioniranje

Selekcija

Manipulacija podacima

Označavanje Filtriranje

Sortiranje

Statistička sumiranja Obrada podataka

Eksport u tekstualne datoteke

Eksport podataka

Eksport u dokument

2.2.2. Primeri dijagrama komponenti

Komponente softverske aplikacije se razlikuju prema tipu aplikacije. Možemo razlikovati komponente aplikacije u dizajn režimu (u toku razvoja) i u izvršnom režimu, kao i skup elementa potrebnih za instalaciju. U nastavku će biti prikazani primeri poslovnih aplikacija koje obavezno sadrže i komponente za rad sa bazom podataka.

PRIMER DESKTOP APLIKACIJE

Primer desktop aplikacije u izvršnom režimu sastoji se od izvršne verzije programa i pratećih standardnih biblioteka klasa, kao I baze podataka I odgovarajućih biblioteka klasa jezgra sistema za upravljanje bazom podataka (DBMS).

Biblioteke klasa standardnog skupa iz razvojnog okruženja Izvršna verzija programa

DESKTOP APLIKACIJA - izvršni paket

Biblioteke klasa za rad sa bazom podataka iz jezgra DBMS Baza podataka

Dizajn režim desktop aplikacije predstavljen je narednim dijagramom komponenti:

Programsko razvojno okruženje Izvorni kod programa

DESKTOP APLIKACIJA - dizajn režim

DBMS jezgro i vizualni alat Baza podataka1

Konačno, instalaciona verzija programa sastoji se od fajlova izvršne verzije koja uključuje i setup program koji objedinjuje sve fajlove izvršnog paketa.

setup program

Biblioteke klasa standardnog skupa iz razvojnog okruženja2 Izvršna verzija programa2

DESKTOP APLIKACIJA - instalacioni paket

Baza podataka2 Biblioteke klasa za rad sa bazom podataka iz jezgra DBMS2

Izvršni režim desktop aplikacije može da sadrži i zasebnu biblioteku klasa ili više biblioteka klasa koje omogućavaju da se deo aplikativne logike podeli po slojevima. Tada govorimo o višeslojnoj desktop aplikaciji.

Izvršna verzija programa3 Biblioteke klasa standardnog skupa iz razvojnog okruženja3

Aplikacione biblioteke klasa

VIŠESLOJNA DESKTOP APLIKACIJA - izvršni paket

Biblioteke klasa za rad sa bazom podataka iz jezgra DBMS3 Baza podataka3

PRIMER VIŠESLOJNE WEB APLIKACIJE UZ PRIMENU WEB SERVISA

Danas je aktuelan razvoj web aplikacija, posebno zbog mogućnosti da se izvršavaju i na mobilnim uređajima. Svakako, u porastu je i razvoj zasebnih mobilnih aplikacija. Naredni dijagram komponenti prikazuje tipičan skup komponenti savremene web aplikacije.

Biblioteka klasa Web servis

Serverski ENGINE za web aplikaciju Serverski ENGINE za web servis

Web aplikacija

Viseslojna web aplikacija uz primenu web servisa - izvršni paket

Web browser Baza podataka 2 DBMS 2

Web browser klijentskog računara obraća se web aplikaciji koja se izvršava na osnovu posebnog programa “web servera” koji omogućava tumačenje i izvršavanje naredbi u web aplikaciji (“Serverski ENGINE”). Radi omogućavanja lakšeg održavanja,web aplikacije se razvijaju kao višeslojne, gde se pojedini delovi programskog koda smeštaju u okviru posebnih biblioteka klasa. Biblioteke klasa se kompajliraju I u izvršnom obliku uključuju u web aplikaciju, kako bi omogućile podršku pojedinim delovima funkcionalnosti. Same biblioteke klasa se nalaze najčešće na istom računaru kao I sama web aplikacija ili na posebnim računarima tzv. Aplikacionim serverima. Jedan deo funkcija se može koristiti od strane drugih proizvođača softvera uslužno, putem povezivanja sa udaljenim web servisima (ne mora se uvek “cela” aplikacija nalaziti na jednom mestu, već je neki deo funkcionalnosti uradila druga softverska kompanija i ponudila na javno korišćenje, kao servis koji je besplatan ili se plaća u određenom ugovornom periodu). Web servisi predstavljaju on-line biblioteke klasa kojima se pristupa putem URL-a. Svakako, poslovne web aplikacije zasnivaju svoj rad najčešće na bazama podataka i da bi se mogle koristiti, uključeni su sistemi za upravljanje bazom podataka, kao posebne komponente.

U okviru vežbi iz ovog predmeta neće se razvijati web aplikacije I ovaj deo je dat samo zbog ilustracije I upoznavanja studenata sa aktuelnim tehnologijama razvoja softvera.

2.2.3. Primer dijagrama razmeštaja

PRIMER VIŠESLOJNE DESKTOP APLIKACIJE Kod višeslojne desktop aplikacije, sve komponente se nalaze na jednom čvoru, tj. računaru.

Primer:

- Program: Ambulanta.exe - Standardne biblioteke za rad programa: .NET dll biblioteke - Aplikativne biblioteke klasa: KlasePodataka.dll - Biblioteke za DBMS jezgro: biblioteke koje omogucuju rad sa MS SQL Server - Baza podataka: Pacijenti.mdf

PRIMER KLIJENT-SERVER APLIKACIJE sa FAT KLIJENTOM Fat/rich/heavy/rich client je varijanta klijent-server arhitekture gde se aplikacija sa svim bibliotekama nalazi na klijentskom računaru, dok se baza podataka može nalaziti na drugom računaru. Ovaj concept je prisutan u lokalnim računarskim mrežama tipa banaka, šaltera na autobuskim stanicama i slično.

PRIMER KLIJENT-SERVER APLIKACIJE sa THIN KLIJENTOM Thin client je varijanta klijent-server arhitekture kada se na klijentskom računaru nalazi samo manji aplikativni deo, a cela programska logika i baza podataka se nalazi na drugim računarima - serverima. Tipična situacija je kada klijentski računar ima samo web browser, kojim se pristupa web serverskom računaru gde se izvršava web aplikacija.

Savremen pristup razvoju web aplikacija uključuje primenu Java Script-a koji omogućuje da se deo funkcionalnosti, posebno u smislu opsluživanja korisničkog interfejsa, ipak izvršava na klijentskom računaru. Savremeni web browseri imaju podršku za Java Script, tako da se u ovoj varijanti, korisnički web browser nije thin klijent u najstrožijem smislu.

TRECI CAS

ELEMENTI I TIPOVI SOFTVERSKE ARHITEKTURE

KLIJENT-SERVER ARHITEKTURA Klijent-server je model distribuirane strukture aplikacije, tako da se dele zadaci i aktivnosti između “obezbeđivača resursa ili servisa” (server) i “zahtevača servisa” (klijenti). Najčešće klijenti i server funkcionišu na različitom hardveru i povezani su računarskom mrežom, iako mogu biti i na fizički istom sistemu. Server izvršava jedan ili više serverskih programa kojima deli svoje resurse sa klijentima, dok klijent ne deli svoje resurse, već zahteva od server određene sadržaje ili servisne funkcije. Klijent-server predstavlja relaciju saradnje programa u aplikaciji. Serverska komponenta aplikacije obezbeđuje funkcije ili servise za jednog ili više klijenata, koji zahtevaju te servise. Serveri se mogu klasifikovati u odnosu na usluge-servise koje obezbeđuju. Npr. Web server obezbeđuje web stranice, file server služi za obradu računarskih fajlova, server baze podataka procesira rad sa bazama podataka. Deljeni resursi servera mogu biti računarski softver (program, podaci) ili hardverske komponente (npr. Uređaji za skladištenje podataka – storage devices). Deljenje resursa servera čini servis. Jedan računar može izvršavati više serverskih programa i pružati više servisa (npr. Može istovremeno biti i web server, server baze podataka, file server).

VIŠESLOJNA OBJEKTNO-ORJENTISANA ARHITEKTURA U softverskom inženjerstvu, višeslojna arhitektura (često nazvana i n-tier arhitektura) je klijent-server arhitektura gde su prezentacija, procesiranje aplikacije i funkcije upravljanja podacima fizički odvojene. Najčešće korišćena višeslojna arhitektura je troslojna arhitektura. N-tier aplikaciona arhitektura obezbeđuje model softvera gde developeri mogu da kreiraju fleksibilne aplikacije pogodne za održavanje i ponovno korišćenje komponenti (reusable). Razdvajanjem aplikacije na slojeve, dobija se mogućnost izmene ili dodavanja specifičnih slojeva, umesto da se celokupna aplikacija ponovo implementira zbog promena. U troslojnoj arhitekturi najčešće razlikjemo prezentacioni sloj (presentation tier), sloj domenske logike (domain logic tier) i sloj podataka (data storage tier).

U objetno-orjentisanom dizajnu višeslojne arhitekture softverske podrške informacionog sistema, najčešći su slojevi:  Prezentacioni sloj (Presentation layer) – korisnički interfejs(UI layer), sloj pogleda(view layer)  Aplikacioni sloj (Application layer) – Sloj servisa (service layer), Controller Layer  Poslovni sloj (Business layer) - Sloj poslovne logike(business logic layer - BLL), domenski sloj (domain layer)  Sloj pristupa podacima (Data access layer) (persistence layer, logging, networking i ostali servisi potrebni za poslovni sloj)

MVC pristup (Model View Controller) Model–view–controller (MVC) je softverski arhitekturni (dizajn) patern. Deli aplikaciju na tri međusobno povezane komponente kao bi se razdvojile interne prezentacije informacija od načina kako je informacija prezentovana i prihvaćena od strane korisnika. Na ovaj način, MVC dizajn patern omogućava paralelni razvoj komponenti i ponovnu iskoristivost koda (code reuse). Inicijano korišćena za desktop aplikacije, ova arhitektura je postala popularna za dizajn web i mobilnih aplikacija. Najčešće korišćeni programski jezici Java, C#, PHP i Ruby imaju svoje popularne MVC framework-e koji se koriste u razvoju aplikacija. Komponente su:  MODEL – centralna komponenta MVC paterna. Izražava ponašanje aplikacije u smislu problemskog domena, nezavisno od korisničkog interfejsa. Upravlja podacima, programskom logikom i pravilima koja su ugrađena u aplikaciju.  VIEW – može biti bilokoji prikaz informacija (output representation). Za iste informacije može biti više različitih prikaza – grafikoni, tabelarni prikazi I slično.  KONTROLER – preuzima ulaze i konvertuje ih u komande koje su upućene MODELU ili VIEW. Podela na 3 komponente definiše i njihovu međusobnu povezanost:  MODEL čuva podatke, KONTROLER zadaje komande modelu za preuzimanje podataka, kontroler zadaje komande kojima se podaci prikazuju u VIEW.  VIEW generiše novi izlaz (output) koji je predstavljen korisniku, na osnovu promena koje su se desile u modelu.  KONTROLER može da šalje komande MODELU da promeni stanje modela. Kontroler može da šalje komande na VIEW da se izmeni prikaz podataka na osnovu izmena modela ili da se prikaže druga vrsta ili način ponašanja VIEW.

PREZENTACIONI SLOJ TROSLOJNE SOFTVERSKE ARHITEKTURE Prezentacioni sloj troslojne softverske arhitekture zadužen je predstavljanje podataka korisniku, kao i za neposredni prijem komandi korisnika u toku korišćenja aplikacije. Osnovne funkcije obuhvataju formatiranje i predstavljanje podataka, kao i organizaciju dostupnosti funkcija kroz personalizaciju funkcija različitim tipovima korisnika. Strukture podataka služe za prijem i predstavljanje podataka i mogu se značajno razlikovati u odnosu na strukture podataka koje se nalaze u poslovnom sloju i sloju podataka. Posebne klase objektno-orjentisane implementacije obezbeđuju odgovarajuće strukture podataka, kao i funkcije prikaza i organizacije funkcija, odnosno prijema komandi sa korisničkog interfejsa. Te klase mogu biti univerzalne, pa se mogu koristiti u implementaciji različitih tipova korisničkih interfejsa (desktop, web, mobilne aplikacije). Takođe, ovom sloju pripadaju I standardne klase za grafičko uređenje korisničkog interfejsa.

MIDDLEWARE Middleware je računarski softver koji obezbeđuje servise softverskim aplikacijama van onih koje su na raspolaganju od strane operativnog sistema. Middleware olakšava softverskim developerima da implementiraju komunikaciju i ulaz-izlaz, kako bi se mogli fokusirati na specifične namene njihovih aplikacija. Termin je najčešće korišćen u značenju softvera koji omogućuje komunikaciju i upravljanje podacima u distribuiranim aplikacijama. Middleware je definisan i kao “servisi koji su iznad transportnog sloja OSI modela, ali ispod aplikacionog okruženja, odnosno aplikacionog API nivoa). U ovom specifičnom smislu, middleware povezuje klijent i server, odnosno dva peer-a u peer-to-peer vezi. Middleware uključuje web servere, aplikacione servere, content menadžment sisteme I slične alate koji podržavaju razvoj i funkcionisanje aplikacija. Middleware se takođe definiše i kao softverski sloj koji je između operativnog sistema I aplikacija na svakoj strain distribuiranog sistema u mreži. Servisi koji pripadaju middleware uključuju integraciju poslovnih aplikacija (Enterprise application integration), integraciju podataka, middleware orjentisan na poruke (Message oriented middleware), object request brokers (ORBs) i enterprise service bus (ESB). Pod pojmom middleware podrazumevaju se i servisi za rad sa bazom podataka, kao što su: ODBC, JDBC I drugi.

RADNI TOKOVI (WORKFLOW MANAGEMENT SYSTEMS) Sistem za upravljanje radnim tokovima obezbeđuje infrastrukturu za definisanje, funkcionisanje i monitoring definisanog niza zadataka, uređenih u aplikaciju koja prati i podržava radne tokove. Sistem za upravljanje radnim tokovima je zasnovan na modelu kojim se definišu zadaci kao čvorovi i njihova međusobna povezanost. Zadaci se aktiviraju ukoliko su uslovi njihove međusobne povezanosti sa drugim zadacima ispunjeni. Teorijska osnova upravljanja radnim tokovima je teorija grafova i petrijeve mreže. Upravljanje radnim tokovima implementira se kroz softversku podršku koja najčešće uključuje primenu web servisa. Aktuelni su standardi za definisanje načina povezivanja web servisa za primenu u podršci radnim tokovima. Posebno definisan jezik Web Services Business Process Execution Language (WS-BPEL) predstavlja standardni jezik za specifikaciju akcija u okviru poslovnih procesa koji se realizuju putem web servisa.

POSLOVNI ENTITETI Poslovni objekat je entitet u okviru višeslojne softverske aplikacije koji razmenjuje podatke sa slojem podataka i slojem poslovne logike. Opisuju entitete rečnika poslovnog domena I omogućavaju implementaciju poslovne logike.

SISTEM ZA UPRAVLJANJE POSLOVNIM PRAVILIMA Sistemi za upravljanje poslovnim pravilima (BRMS – business rule management system) je softverski sistem koji se koristi za definisanje, postavljanje, izvršavanje, monitoring i održavanje različitih elemenata logike odlučivanja koje se koriste u softverskim sistemima podrške organizacijama ili preduzećima. Logika odlučivanja uključuje poslovna pravila, politike, zahteve, uslovne rečenice koje se koriste kako bi se utvrdile taktičke akcije koje bi se primenile u aplikacijama i sistemima. Osnovna arhitektura BRMS sistema minimalno mora sadržavati:  Skladište (repozitorijum) gde će biti smešteni elementi logike odlučivanja, izdvojeni iz programskog koda jezgra softverske aplikacije  Alati kojima se definiše i održava logika održavanja  Izvršno okruženje, koje omogućava aplikaciji da pokreće logiku odlučivanja koja se nalazi u BRMS i izvršavanje koristeći Business Rule Engine Prednosti korišćenja BRMS sistema odnose se na smanjivanje zavisnosti organizacionih jedinica od IT odeljenja kada su u pitanju promene pravila poslovanja, povećan nivo kontrole nad logikom odlučivanja, unapređenje preciznosti odlučivanja i efikasnosti zbog automatizacije odlučivanja.

SLOJ PODATAKA Sloj za pristup podacima (Data Access Layer - DAL) je sloj računarskog programa koji obezbeđuje jednostavniji pristup podacima koji su smešteni u okviru nekog trajnog skladišta podataka (persistent storage), npr. u okviru relacione baze podataka ili fajl sistema. DAL čine klase koje obezbeđuju podatke iz npr. baze podataka, a koje mogu pristupati podacima pozivom stored procedura iz baze podataka. DAL sakriva kompleksnost skladištenja podataka, a može da sadrži upite i nad više različitih izvora podataka i više baza podataka. DAL može biti zavisan od konkretnog DBMS (sistema za upravljanje bazom podataka), odnosno servera baze podataka ili nezavisan. DAL koji podržava više različitih tipova DBMS (ili je univerzalan u tom smislu) je lakši za održavanje, jer se lako izvrši izmena podrške konkretnom DBMS, dok ostali elementi ostaju nepromenjeni. Alati ORM (Object- Relational Mapping) tipa omogućavaju active record model. Osnovna podrška DAL treba da bude za CRUD (Create, Read, Update, Delete) operacije nad podacima.

SERVISNO-ORJENTISANA ARHITEKTURA Servisno-orjentisana arhitektura (SOA) je stil softverskog dizajna gde su servisi obezbeđeni softverskim komponentama kojima se pristupa putem mrežnih komunikacionih protokola. Servis ima opšte karakteristike, nezavisne od tehnologije ili dobavljača: predstavlja logičku jedinicu posla, samostalan, implementacija je sakrivena za korisnike, može da se u svojoj implementaciji zasniva na primeni drugih servisa. Različiti servisi se mogu udružiti kako bi obezbedili funkcionalnost složenije softverske aplikacije. U okviru servisno-orjentisane arhitekture, aplikacija se kreira integracijom distribuiranih, nezavisno-održavanih i postavljenih softverskih komponenti. Servis predstavlja jednostavni interfejs koji je pozvan od strane korisnika usluge servisa I koji sakriva implementaciju samog servisa. U okviru SOA, servisi koriste protokole kojima se opisuje kako se prosleđuju I tumače poruke, koristeći metapodatke – opisuju funkcionalne karakteristike I karakteristike kvaliteta usluge-servisa. Osnovni elementi I učesnici SOA pristupa su: - Service Provider (Kreira web servis I registruje ga u okviru registra servisa) - Service Broker (registar servisa, skladište servisa) - Service Requester (pronalazi web servis u okviru servisnog brokera i povezuje se sa service provider-om kako bi koristio usluge web servisa. U razvoju SOA aplikacija razvijaju se web servisi i koriste se standardi za web servise, npr. SOAP, CORBA; REST.

TEHNOLOGIJE DISTRIBUIRANIH INFORMACIONIH SISTEMA

1. Osnovni pojmovi 2. Definicija i karakteristike distribuiranih sistema 3. Tipovi distribuiranih sistema 3.1. Distribuirani računarski sistemi 3.2. Distribuirani informacioni sistemi 3.3. Distribuirani integrisani ("embedded") sistemi 4. Arhitektura distribuiranog informacionog sistema 4.1. Arhitektura informacionog sistema 4.2. Klijent-server arhitektura 4.3. Višeslojne arhitekture 5. Sloj računarsko-komunikacione infrastrukture 5.1. Mobilni uređaji 5.2. Wireless 5.3. Bluetooth 5.4. GPS 6. Distribuirani operativni sistemi 7. Sloj podataka 7.1. Formati datoteka za razmenu podataka 7.2. Distribuirane baze podataka 7.3. "Big data" sistemi 8. Sloj aplikativne logike 8.1. Srednji sloj - Middleware 8.2. Web servisi 8.3. Algoritmi 8.4. Analiza podataka 9. Prezentacioni sloj 9.1. Web aplikacije 9.2. Mobilne aplikacije 9.3. Vizualizacija prostornih podataka 10. Performanse i bezbednost 11. Primene 11.1. Senzorske mreže i Internet of Things 11.2. Geografski informacioni sistemi 11.3. Smart home, smart city 11.4. Upravljanje vozilima 11.5. eHealth sistemi 11.6. Ostale primene

DISTRIBUIRANO, PARALELNO I KONKURENTNO RACUNARSTVO

Distribuirano računarstvo se odnosi na primenu distribuiranih sistema za rešavanje računarski rešivih problema. U ovom načinu procesiranja, problem je podeljen između više zadataka, gde se svaki rešava na jednom ili više računara povezanih računarskom mrežom, koji međusobno komuniciraju razmenom poruka. Računarski program koji se izvršava u distribuiranom sistemu naziva se distribuirani program. Postoji više načina za razmenu poruka između računara: HTTP, RPC (Remote Procedure Call) i redovi poruka (message queues). Paralelno računarstvo je tip obrade podataka gde se mnoga izračunavanja izvršavaju na procesima koji se izvršavaju simultano (istovremeno). Veliki problemi se dele na manje, koji se mogu rešavati u isto vreme. Ima nekoliko formi paralelnog računarstva: nivo bita, nivo instrukcije, nivo podataka i paralelizam zadataka. S obzirom na potrebu da se smanji zagrevanje I potrošnja energije računara, paralelno računarstvo je postalo danas dominantno u računarskoj arhitekturi, najčešće u formi procesora sa više jezgra. Paralelno računarstvo je blisko sa konkurentnim računarstvom. Moguće je imati paralelizam bez konkurentnosti (npr. Bit-nivo paralelizma) ili konkurentnost bez paralelizma (npr. Kod multitaskinga sa deljenjem vremena na procesoru sa jednim jezgrom). Kod paralelnog računarstva, zadatak obrade se podeli na nekoliko, čak i više sličnih podzadataka koji se mogu procesirati nezavisno i čiji rezultati se kombinuju kasnije, nakon njihovog završetka. Kod konkurentnog računarstvo, raznovrsni procesi često se ne odnose na međusobno povezane zadatke, već kada izvršavaju (slično kao i kod distribuiranog računarstva) svoje aktivnosti, potrebno je da postoji proces koji će ih povezati u toku izvršavanja.

DEFINICIJA I KARAKTERISTIKE DISTRIBUIRANIH SISTEMA

Prema [Tanenbaum&Steen, 2007], distribuirani sistem se može definisati kao kolekcija nezavisnih računara koji se javlja korisnicima kao jedan jedinstven (koherentan) sistem.

Važne karakteristike distribuiranih sistema:  „Skup autonomnih računarskih elemenata“ - Sastoji se od komponenti koje su autonomne. Autonomne komponente moraju da „sarađuju“, ali tako da je to sakriveno od korisnika.  „Višeslojna arhitektura“ - Da bi se obezbedilo povezivanje heterogenih računarskih komponenti i mreža, distribuirani sistem je organizovan kroz slojeve, čime se odvaja niži fizički nivo operativnih sistema i osnovnih komunikacionih funkcija od višeg nivoa aplikacija i korisnika. Između ta dva nivoa je srednji sloj – middleware. Aplikativni sloj dobija isti interfejs, koji se implementira na različite načine putem komponenti.  (Ne) „Transparentnost“ - Korisnici (ljudi ili programi) imaju „utisak“ da rade sa jednim sistemom. Implementacija sistema je sakrivena od korisnika - ne daje detalje o tipovima računara kao komponenti (mogu biti heterogeni) niti o načinu kako su povezani i kako sarađuju. Prema [Tanenbaum&Steen, 2007] i standardu ISO iz 1995, postoje različite  Forme transparentnosti distribuiranog sistema: Tip Opis Pristup Sakriva razlike u prezentacijip odataka i kako se pristupa resursima Lokacija Sakriva lokaciju resursa Migracija Sakriva mogućnost da resurs može da promeni lokaciju Relokacija Sakriva mogućnost da resurs može da promeni lokaciju u toku korišćenja Replikacija Sakriva da se resurs replicira (umnožava) Konkurentnost Sakriva da se resurs može deliti između više konkurentnih korisnika, tj. korisnika koji koriste resurs u isto vreme Greška (Failure) Sakriva greške i oporavak resursa

 „Skalabilnost“ - Distribuirani sistemi se lako mogu proširiti novim komponentama.  „Pouzdanost“ - Očekuje se da distribuirani sistem uvek bude raspoloživ i funkcionalan, ialo pojedini elementi privremeno mogu biti van funkcije. Korisnici i aplikacije ne bi trebali da primete delove koji su u procesu zamene ili popravke ili dodavanja novih elemenata koji se dodaju da bi obezbedili podršku za više korisnika ili aplikacija.  „Otvorenost“ – sistem nudi servise u skladu sa standardnim pravilima koje opisuju sintaksu i semantiku tih servisa. Pravila se odnose na format, sadržaj i značenje poruka koje se šalju ili primaju. Takva pravila formalizovana su u protokolima. U distribuiranim sistemima, servisi su definisani kroz interfejse, opisane najčešće kroz Interface Definition Language (IDL).  „Fleksibilnost“ –sistem se lako konfiguriše od različitih komponenti (čak i od različitih proizvođača). Sistem treba da omogući laku zamenu komponenti ili dodavanje novih komponenti bez uticaja na postojeće komponente koje već funkcionišu. Kako bi se postigla fleksibilnost, sistem treba da predstavlja kolekciju malih i lako zamenjivih i adaptibilnih komponenti. Odvajanje funkcionalnosti, ciljeva („policy“) i mehanizma implementacije.

Ciljevi i opravdanost kreiranja distribuiranog sistema:  Obezbeđuju lakšu dostupnost i deljenje udaljenih resursa – uređaja, datoteka, skladišta podataka.  Dostupnost i deljenje resursa je ekonomski opravdano – smanjuje opšte troškove  Povezivanje korisnika i resursa olakšava kolaboraciju i razmenu informacija.

Rizici i problemi distribuiranih sistema:  Bezbednost podataka  Privatnost podataka

TIPOVI DISTRIBUIRANIH SISTEMA

Tipovi distribuiranih sistema:  Distribuirani računarski sistemi (“Distributed Computing Systems”):  Distribuirani informacioni sistemi  Distribuirani integrisani (“embedded”) sistemi

DISTRIBUIRANI RAČUNARSKI SISTEMI

Mogu biti:

1. Klasterski sistemi – homogeni sistemi, više istih ili sličnih PC računara sa istim operativnim sistemom, povezanih homogenom računarskom mrežom, uz najčešće jedan master računar koji upravlja zadacima. Koristi se kod paralelnog programiranja, gde se jedan program izvršava na paralelnim računarima.

Slika 1. Prikaz arhitekture klasterskog sistema

2. “Grid” sistemi– heterogeni sistemi, raznovrsnost hardvera, operativnih sistema, mreža, administrativnih domena, bezbedonosnih sistema…Suština grid sistema je da se resursi različitih organizacija ujedinjuju da bi se obezbedila kolaboracija grupe ljudi ili institucija. Takva kolaboracija predstavlja formu virtualne organizacije. Ljudi, koji pripadaju istoj virtualnoj organizaciji, imaju prava pristupa resursima te virtualne organizacije. Ti resursi predstavljaju procesorske servere (“compute servers”), skladišta podataka (“storage facilities”) i bazepodataka. Takođe, posebni uređaji koji su dostupni u mreži takođe mogu biti na raspolaganju (senzori, teleskopi…).

Slika 2.Prikaz arhitekture grid sistema

Osnovni elementi arhitekture grid sistema predstavljeni su kroz slojeve:  Sloj aplikacija (“Application layer”) – aplikacije koje se koriste u virtualnoj organizaciji koje omogućavaju primenu celog sistema  Sloj kolekcije (“Collective layer”) – obrađuje upravljanje istovremenim pristupom ka više resursa i sastoji se od servisa za otkrivanje resursa, alokaciju i vremensko raspoređivanje (“scheduling”) zadataka nad višestrukim resursima, replikacijom podataka itd.  Sloj konekcije (“Connectivity layer”) – obezbeđuje servise i protokole za razmenu podataka između resursa, pristup resursima iz udaljenih lokacija.  Sadrži bezbedonosne servise autentikacije korisnika i resursa. Autentifikacija se odnosi prvenstveno na programe koje koriste korisnici.  Sloj resursa (“Resource layer”) –odgovoran je za upravljanje jednim resursom. Obezbeđuje funkcije za očitavanje konfiguracionih informacija o pojedinačnom resursu ili izvršavanje specifičnih operacija kreiranja procesa ili čitanja podataka. Zasniva se na prethodnoj kontroli pristupa, koja je realizovana kroz autentikaciju sloja konekcije.  Fabrički sloj („Fabric layer“) – odnosi se na interfejse lokalnih resursa konkretne lokacije. Obezbeđuju funkcije za deljenje resursa – upite nad stanjem i mogućnostima („capabilities“) resursa, kroz funkcije menadžmenta resursa (npr. zaključavanje).

3. CLOUD sistemi

Cloud računarstvo se bazira na metafori: Za korisnika, elementi implementacije sistema koji nudi razne servise su nevidljivi, kao da su u oblaku. Cloud računarstvo je tip Internet-baziranog računarstva koje omogućuje deljene resurse za računarsko procesiranje I skladištenje podataka, kako bi bili na raspolaganju računarima i drugim uređajima. Ovaj model omogućuje resurse po zahtevu iz deljenog skupa lako dostupnih i lako konfigurišućih resursa (računarskih mreža, servera, uređaja za smeštanje podataka – storage, aplikacija, servisa), koji se brzo mogu obezbediti i dati na korišćenje uz minimum potrebe za upravljanjem. Ovi resursi obezbeđuju pojedinačnim korisnicima ili firmama različite mogućnosti čuvanja I procesiranja podataka u data centrima koji mogu biti geografski veoma udaljeni i na taj način se obezbeđuje ušteda izbegavanjem investicija u infrastrukturu (kupovina i održavanje servera). Na ovaj način se organizacije mogu fokusirati na suštinu svog poslovanja, umesto da ulažu vreme I novac na računarsku infrastrukturu i njihovo održavanje. Firme koje nude “cloud” sisteme naplaćuju korišćenje cloud sistema u zavisnosti od mogućnosti koje klijent koristi ("pay as you go").

(DISTRIBUIRANI) INTEGRISANI (EMBEDDED) SISTEM

Integrisani sistem je računarski sistem posebne namene koji je povezan sa širim mehaničkim ili električnim sistemom, najčešće zasnovan na procesiranju podataka u realnom vremenu. Integrisan sistem je INTEGRISAN zato što predstalja deo kompletnog uređaja koji obično sadrži hardverske i mehaničke komponente. Integrisani sistemi kontrolišu mnoge uređaje u svakodnevnoj upotrebi. 98% svih proizvedenih mikroprocesora danas su zapravo realizovani da bi bili komponente integrisanih sistema. Osnovne karakteristike integrisanih računara, poredeći sa računarima opšte namene, su manji nivo potrošnje energije, manje dimenzije, manji troškovi, grublji skup operacija, zbog ograničenja procesnih resursa. Zbog ovoga je teže programirati i raditi sa tim resursima. Radi unapređenja rada integrisanih sistema, uključuju se inteligentni mehanizmi uz postojeći hardver, senzore i umrežavanje integrisanih elemenata. Takođe, posebno se unapređuju integrisani sistemi tako da imaju manje dimenzije i troškove proizvodnje, ali veću pouzdanost i bolje performanse. Na ovaj način unapređuje se npr. Potrošnja energije integrisanih sistema. Savremeni integrisani sistemi su najčešće bazirani na mikrokontrolerima (procesor s integrisanom memorijom i perifernim interfejsima) ili običnim mikroprocesorima sa eksternim čipovima za memoriju i periferne interfejse, koji se koriste u kompleksnijim sistemima. Procesori mogu biti opšte namene ili specijalizovani za određene vrste procesiranja. Standardna klasa namenskih procesora su „digital signal processor (DSP)”. Integrisani sistemi se nalaze u malim portabilnim uređajima (npr. Digitalni satovi, MP3 player), ali i u velikim stacionarnim instalacijama kao što su saobraćajna signalizacija, kontroleri u fabrikama, složena hibridna vozila I slično. Kompleksnost ide od jednog mikrokontrolerskog čipa do veoma velikih i višestrukih jedinica.

DISTRIBUIRANI INFORMACIONI SISTEMI

Prеma [Mogin et al, 2000], pоd pојmоm distribuirani infоrmaciоni sistem pоdrazumеva se infоrmaciоni sistem kојi pоdržava distribuiranu obradu pоdataka, nad distribuiranоm bazоm pоdataka.

DISTRIBUIRANE BAZE PODATAKA

Distribuirane baze podataka su baze podataka gde uređaji na kojima su uskladištene nisu povezani na zajednički procesor. Mogu biti čuvane na više računara, smeštenih na jednoj fizičkoj lokaciji ili mogu biti smeštene na računarima na širem prostoru i povezane računarskom mrežom. Administratori sistema mogu da distribuiraju bazu podataka, odnosno kolekcije podataka kroz više fizičkih lokacija. Distribuirana baza podataka može da se nalazi na organizovanoj mreži servera ili decentralizovana na nezavisnim računarima na internetu, na korporativnim intranet sistemima ili računarskim mrežama drugih organizacija. Distribuirane baze podataka unapređuju performance prema korisniku sistema, omogućujući da se transakcije izvršavaju na više mašina, umesto da se izvršavaju na jednoj mašini. Savremeni DBMS sistemi podržavaju osnovne operacije sa distribuiranim bazama podataka: replikacija, particionisanje, distribuirane transakcije, oporavak baze podataka, sinhronizacija. Postoje i posebni DBMS sistemi namenjeni distribuiranim bazama podataka.

DISTRIBUIRANO PROGRAMIRANJE Različite hardverske i softverske arhitekture se koriste kod distribuiranog računarstva. Na nižem nivou, potrebno je povezati veći broj procesora određenom vrstom mreže. Na višem nivou, potrebno je povezati procese da se izvršavaju na tim procesorima sa određenim komunikacionim sistemom.

Distribuirano programiranje (programiranje distribuiranih aplikacija) obuhvata najčešće sledeće osnovne arhitekture: klijent-server, troslojna, višeslojna, peer-to- peer ili kategorije: slabo ili jako povezanih sistema (loose coupling, or tight coupling).  Klijent-server arhitektura: klijent razmenjuje podatke sa serverom upućujući zahteve korisnika za podacima ili prosleđujući serveru podatke koje treba da ažurira. Klijent može biti “fat” ili “smart” tako da je programska logika u okviru klijentskog računara ili “thin” kada je programska logika u okviru serverskog računara.  Troslojna arhitektura: programska logika je izmeštena na srednji sloj tako da se pojednostavljuje razvoj i klijenti rasterećuju. Većina web aplikacija je troslojna.  Višeslojna arhitektura: uključuje servise, odnosno aplikacione servere, gde se poslovna logika posebno procesira.  Peer-to-peer arhitektura: ne postoje posebni server koji obezbeđuju servise ili upravljaju mrežnim resursima. Umesto toga, odgovornosti su uniformno razdeljene između svih računara, nazvanih peer. Peer računari (ravnopravni računari) mogu da imaju ravnopravno ulogu i kao klijenti i kao serveri.

PORUKE Poruka je diskretna jedinica komunikacije formulisana od strane izvora poruke radi korišćenja od strane primaoca poruke. Poruke su forma komunikacije korišćena u konkurentnom i paralelnom računarstrvu, objektno-orjentisanom programiranju ili interprocesnoj komunikaciji. U objektno-orjentisanom programiranju, poruka se šalje objektu klase, čime se specificira zahtev za izvršavanje konkretne akcije od strane metode te klase, uz konkretne vrednosti parametara poziva. Postoje različiti standardi-protokoli razmene poruka.

RAZMENA PORUKA (MESSAGE PASSING) U računarskim naukama, slanje poruke je obraćanje procesu-metodi objekta, koji treba da izvrši neki programski kod, odnosno izvrši neku akciju. U objektno- orjentisanom programiranju, na ovaj način se razlikuje funkcija od implementacije, koja je enkapsulirana. Enkaspulacijom softverski objekti pozivaju servise drugih objekata bez poznavanja ili uticaja na to kako su ti servisi implementirani. Distribuirana razmena poruka omogućuje developerima sloj arhitekture (nazvan “messaging layer”) sa mogućnošću izgradnje sistema sastavljenog od podsistema koji se izvršavaju na različitim računarima sa različitim lokacijama i u različito vreme. Messaging layer omogućava slanje poruka distribuiranih objekata drugim objektima kroz: - Pronalaženje adekvatnog objekta, pri čemu se objekti mogu nalaziti na različitim računarima, operativnim sistemima I biti implementirani na različitim programskim jezicima - Snimanje poruke u red (queue) ukoliko odgovarajući objekat nije trenutno aktivan i pokretanje poruke kada se odgovarajući objekat aktivira - Kontrolisanje distribuiranih transakcija, obezbeđujući ACID osobine nad podacima. Razlikujemo sinhrono i asinhrono slanje poruka. Sinhrono slanje poruka se javlja između objekata koji su aktivni u isto vreme. Asinhrono slanje poruka je moguće kada je objekat koji treba da primi poruku i izvrši akciju zauzet ili nije aktivan u trenutku kada objekat koji šalje poruku pošalje tu poruku. Ta obradu asinhrone razmene poruka koristi se poseban middleware, npr. Message-oriented middleware, gde se zahtevi šalju, čuvaju u “message bus”, a obrađuju kada je ciljni objekat aktivan. Sinhrona razmena poruka takođe može da koristi poseban middleware (npr. Synchonizer), gde sender ne šalje novu poruku dok ne dobije odgovor od prijemnika da je primio poruku. Potrebno je razlikovati slanje poruka i poziv procedure. U tradicionalnom pozivu procedure, argumenti (vrednosti parametara poziva procedure) se šalju korišćenjem registara opšte namene koji pamte samo adresu vrednosti argumenta, dok se kod slanja poruke šalje ceo argument-parametar sa svim svojim osobinama (tip podatka) kao i vrednost argumenta.

KOMUNIKACIONI PROTOKOL U telekomunikacijama, komunikacioni protocol je sistem pravila koja omogućavaju da dva entiteta komunikacionog sistema razmenjuju podatke pomoću varijacija fizičkih veličina. Ta pravila ili standardi opisuju sintaksu, semantiku I sinhronizaciju komunikacija I metode za oporavak od mogućih grešaka. Protokoli mogu biti implementirani u okviru hardvera i softvera. Komunikacioni sistemi koriste dobro definisane formate (protokole) za razmenu različitih poruka. Svaka poruka ima precizno značenje kojim se pokreće I očekuje odgovor iz skupa svih mogućih odgovora koji su unapred definisani za takvu situaciju.Očekivano ponašanje kao odgovor na poruku je nezavisno od načina implementacije. Komunikacioni protokoli treba da su rezultat dogovora-usaglašavanja između svih strana, a obično se oblikuju kao tehnički standardi. Protokoli definišu pravila koja se odnose na transmisiju poruka. Protokol mora da definiše: formate podataka za razmenu, adresne formate (pošiljaoca I primaoca) za razmenu podataka, adresno mapiranje (u druge oblike adresa), rutiranje (definisanje posrednika u komunikaciji), detekcija grešaka transmisije, odgovor o uspehu prijema paketa podataka, gubitak podataka (timeout i retry), usmerenje toka informacija, kontrola sekvenci, kontrola toka.

ASINHRONA KOMUNIKACIJA U telekomunikacijama, asinhrona komunikacija je razmena podataka bez primene eksternog satnog signala, gde se podaci razmenjuju povremeno, bez konstantnog protoka. Transmiter i receiver satni generatori nisu sinhronizovani.

SINHRONA KOMUNIKACIJA Sinhronizacija je koordinacija događaja u sistemu. Sistemi čiji svi elementi funkcionišu sinhrono, nazivaju se sinhroni sistemi. Sinhroni uređaji zahtevaju postojanje satnog signala (clock signal), čija je osnovna namena da signaliziraju početak i kraj nekog vremenskog perioda. Na ovaj način se događaji nad različitim elektronskim sistemima mogu sinhronizovati, tj. da se ponašaju tako da se izvršavaju simultano. Primer sinhronizacije je u GPS sistemima, gde rad satelita treba da se uskladi sa radom GPS uređaja na Zemlji, koristeći Network Time Protocol (NTP) kojima se obezbeđuje pristup u realnom vremenu I bliska aproksimacija za “UTC timescale”.

SOFTVERSKI SERVISI Servis je diskretna jedinica funkcionalnosti kojoj se može pristupiti udaljeno (remotely) i koristiti i menjati nezavisno. Software as a service (SaaS) je model za softversko licenciranje i isporuku gde se softver licencira na bazi pretplate I centralno je smešten (hostovan). SaaS se pristupa od strane korisnika koristeći tanki (“thin”) klijent koristeći web browser. SaaS je postao uobičajen model za isporuku poslovnih aplikacija. Pojam Saas se koristi kao deo nomenclature u okviru Cloud računarstva, zajedno sa infrastructure as a service (IaaS), platform as a service (PaaS), desktop as a service (DaaS), managed software as a service (MSaaS), mobile backend as a service (MBaaS), and information technology management as a service (ITMaaS). S obzirom da SaaS aplikacije ne mogu da pristupaju internim sistemima neke kompanije (npr. Bazama podataka ili internim servisima), integracija je omogućena koristeći protokole i API (application programming interfaces). Ovi protokoli su bazirani na HTTP, SOAP i REST.

DISTRIBUIRANI OBJEKTI U distribuiranom računarstvu, distribuirani objekti su objekti (u smislu objektno- orjentisanog programiranja) koji su distribuirani na različitim adresnim prostorima u okviru različitih procesa jednog računara ili na više računara u računarskoj mreži, ali funkcionišu zajedno deljenjem i razmenom podataka i pokretanjem metoda. To uključuje lokacijsku (ne)transparentnost, gde udaljeni objekti „izgledaju“ isto kao i lokalni objekti. Osnovni način komunikacije distribuiranih objekata je putem udaljenog poziva metoda putem slanja poruka: jedan objekat šalje poruku drugom objektu na udaljenoj mašini ili procesu da izvrši neki zadatak. Rezultati se šalju nazad objektu koji je pozvao taj objekat. Primeri podrške za distribuirane objekte: Java RMI, CORBA, DCOM (Microsoft platform), DDObjects(Delphi), JavaSpaces, Pyro (Python), DRb (DistributedRuby).

UDALJENO POZIVANJE PROCEDURA (REMOTE PROCEDURE CALL) U distribuiranom računarstvu, Remote Procedure Call (RPC) je proces pozivanja, od strane računarskog programa, procedure koja se izvršava u drugom adresnom prostoru, najčešće na drugom računaru deljene računarske mreže. Prilikom tog udaljenog pozivanja, u programu se pišu naredbe kao da se poziva lokalna procedura, bez potrebe za dodatnim programiranjem detalja u vezi udaljene interakcije. Implementacija odgovara request-response sistemu razmene poruka, slično kao kod klijent-server modela. Istorijat: Počev od objektno-orjentisanog programiranja I modela “Remote Method Invocation”, zatim CORBA (Common Object Request Broker Architecture), zatim Java RMI (Java Remote Method Invocation).

CETVRTI CAS

STANDARDNA DOKUMENTACIJA

Izvor: “Hans-Peter Halvorsen: Software documentation”

Pogledati iz materijala:

 SOFTWARE DEVELOPMENT STANDARDS  ONTARIO STANDARDI RAZVOJA SOFTVERA PREMA RAZLICITIM SDLC

TIPOVI ARHITEKTURE

There are four types of architecture from the viewpoint of an enterprise and collectively, these architectures are referred to as enterprise architecture.

 Business architecture − Defines the strategy of business, governance, organization, and key business processes within an enterprise and focuses on the analysis and design of business processes.

 Application software architecture − Serves as the blueprint for individual application systems, their interactions, and their relationships to the business processes of the organization.

 Information architecture − Defines the logical and physical data assets and data management resources.

 Information technology IT architecture − Defines the hardware and software building blocks that make up the overall information system of the organization.

IZVOR: http://www.tutorialspoint.com/software_architecture_design/key_principles.htm

ISTORIJAT RAZVOJA SOFTVERSKIH ARHITEKTURA

Izvor: David Garlan, Carnegie Mellon University, NASA Fault Management Workshop,New Orleans, April 2012

DEFINICIJA

 Software architecture is described as the organization of a system.  System represents a set of components that accomplish the defined functions.

ARHITEKTONSKI STIL

The architectural style, also called as architectural pattern, is a set of principles which shapes an application. It defines an abstract framework for a family of system in terms of the pattern of structural organization.

The architectural style is responsible to:  Provide a lexicon of components and connectors with rules on how they can be combined.  Improve partitioning and allow the reuse of design by giving solutions to frequently occurring  problems.  Describe a particular way to configure a collection of components a module with well – defined interfaces, reusable, and replaceable and connectors communication link between modules.

The software that is built for computer-based systems exhibit one of many architectural styles. Each style describes a system category that encompasses:  A set of component types which perform a required function by the system.  A set of connectors subroutine call, remote procedure call, data stream, and socket that enable communication, coordination, and cooperation among different components.  Semantic constraints which define how components can be integrated to form the system.  A topological layout of the components indicating their runtime interrelationships.

OSNOVNI PRINCIPI ARHITEKTURNOG DIZAJNA

Build to Change Instead of Building to Last Consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this.

Reduce Risk and Model to Analyze Use design tools, visualizations, modeling systems such as UML to capture requirements and design decisions. The impacts can also be analyzed. Do not formalize the model to the extent that it suppresses the capability to iterate and adapt the design easily.

Use Models and Visualizations as a Communication and Collaboration Tool Efficient communication of the design, the decisions, and ongoing changes to the design is critical to good architecture. Use models, views, and other visualizations of the architecture to communicate and share the design efficiently with all the stakeholders. This enables rapid communication of changes to the design. Identify and understand key engineering decisions and areas where mistakes are most often made. Invest in getting key decisions right the first time to make the design more flexible and less likely to be broken by changes.

Use an Incremental and Iterative Approach Start with baseline architecture and then evolve candidate architectures by iterative testing to improve the architecture. Iteratively add details to the design over multiple passes to get the big or right picture and then focus on the details.

Key Design Principles Following are the design principles to be considered for minimizing cost, maintenance requirements, and maximizing extendibility, usability of architecture.

Separation of Concerns Divide the components of system into specific features so that there is no overlapping among the components functionality. This will provide high cohesion and low coupling. This approach avoids the interdependency among components of system which helps in maintaining the system easy.

Single Responsibility Principle Each and every module of a system should have one specific responsibility, which helps the user to clearly understand the system. It should also help with integration of the component with other components.

Principle of Least Knowledge Any component or object should not have the knowledge about internal details of other components. This approach avoids interdependency and helps maintainability.

Minimize Large Design Upfront Minimize large design upfront if the requirements of an application are unclear. If there is a possibility of modifying requirements, then avoid making a large design for whole system.

Do not Repeat the Functionality It specifies that functionality of the components should not to be repeated and hence a piece of code should be implemented in one component only. Duplication of functionality within a single application can make it difficult to implement changes, decrease clarity, and introduce potential inconsistencies.

Prefer Composition over Inheritance while Reusing the Functionality Inheritance creates dependency between children and parent classes and hence it blocks the free use of the child classes. In contrast, the composition provides a great level of freedom and reduces the inheritance hierarchies.

Identify Components and Group them in Logical Layers Identity components and the area of concern that are needed in system to satisfy the requirements. Then group these related components in a logical layer, which will help the user to understand the structure of the system at a high level. Avoid mixing components of different type of concerns in same layer.

Define the Communication Protocol between Layers Understand how components will communicate with each other which requires a complete knowledge of deployment scenarios and the production environment.

Define Data Format for a Layer Various components will interact with each other through data format. Do not mix the data formats so that applications are easy to implement, extend, and maintain. Try to keep data format same for a layer, so that various components need not code/decode the data while communicating with each other. It reduces a processing overhead.

System Service Components should be Abstract Code related to security, communications, or system services like logging, profiling, and configuration should be abstracted in the separate components. Do not mix this code with business logic, as it is easy to extend design and maintain it.

Design Exceptions and Exception Handling Mechanism Defining exceptions in advance, helps the components to manage errors or unwanted situation in an elegant manner. The exception management will be same throughout the system.

Naming Conventions Naming conventions should be defined in advance. They provide a consistent model that helps the users to understand the system easily. It is easier for team members to validate code written by others, and hence will increase the maintainability.

OSNOVNE VRSTE ARHITEKTONSKIH STILOVA The following table lists architectural styles that can be organized by their key focus area

IZVOR: http://www.tutorialspoint.com/software_architecture_design/key_principles.htm

IZVOR: “Mark Richards, Neal Ford: Software Architecture Fundamentals Workshop, part 1: from developer to architect”.

ARHITEKTURE MOBILNIH APLIKACIJA

Izvor: “Ben Feigin: Mobile Application Development”.

POGLEDATI UDZBENIK: Microsoft Application Architecture Guide, patterns and practices, 2nd Edition

CAS 5

Teme:  Kvalitet softvera  Standardi kvaliteta softvera  Softverske metrike  Preporuke i konvencije za pisanje kvalitetnog koda  Refaktorisanje programskog koda

********************* POSEBAN ČAS: Testiranje softvera

KVALITET SOFTVERA - Tri aspekta: KVALITET PROCESA, STRUKTURNI KVALITET SOFTVERA, FUNKCIONALNI KVALITET SOFTVERA

KVALITET PROCESA - The quality of the development process significantly affects the value received by users - Meeting delivery dates. Was the software delivered on time? - Meeting budgets. Was the software delivered for the expected amount of money? - A repeatable development process that reliably delivers quality software. If a process has the first two attributes—software delivered on time and on budget—but so stresses the development team that its best members quit, it isn’t a quality process. True process quality means being consistent from one project to the next.

STRUKTURNI KVALITET - code itself is well structured - Code testability. Is the code organized in a way that makes testing easy? - Code maintainability. How easy is it to add new code or change existing code without introducing bugs? - Code understandability. Is the code readable? Is it more complex than it needs to be? These have a large impact on how quickly new developers can begin working with an existing code base. - Code efficiency. Especially in resource-constrained situations, writing efficient code can be critically important. - Code security. Does the software allow common attacks such as buffer overruns and SQL injection? Is it insecure in other ways?

FUNKCIONALNI KVALITET - Functional quality means that the software correctly performs the tasks it’s intended to do for its users. - Meeting the specified requirements. Whether they come from the project’s sponsors or the software’s intended users, meeting requirements is the sine qua non of functional quality. In some cases, this might even include compliance with applicable laws and regulations. And since requirements commonly change throughout the development process, achieving this goal requires the development team to understand and implement the correct requirements throughout, not just those initially defined for the project. - Creating software that has few defects. Among these are bugs that reduce the software’s reliability, compromise its security, or limit its functionality. Achieving zero defects is too much to ask for most projects, but users are rarely happy with software they perceive as buggy. - Good enough performance. From a user’s point of view, there’s no such thing as a good, slow application. - Ease of learning and ease of use. To its users, the software’s user interface is the application, and so these attributes of functional quality are most commonly provided by an effective interface and a well-thought-out user workflow. The aesthetics of the interface—how beautiful it is—can also be important, especially in consumer applications. - Software testing commonly focuses on functional quality

Izvor: David Chappel: The Three aspects of software quality – functional, structural and process. STANDARDI KVALITETA SOFTVERA

- Kvalitet softverskog proizvoda - Kvalitet procesa razvoja softvera

STANDARDI KVALITETA SOFTVERSKOG PROIZVODA ISO/IEC 9126 — Međunarodni standard za evaluaciju kvaliteta softvera kao proizvoda. Zamenjen je standardom ISO/IEC 25010:2011. The quality criteria according to ISO 9126

[w Desharnais]

 Functionality - "A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs."  Suitability  Accuracy  Interoperability  Security  Functionality compliance  Reliability - "A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time."  Maturity  Fault tolerance  Recoverability  Reliability compliance  Usability - "A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users."  Understandability  Learnability  Operability  Attractiveness  Usability compliance  Efficiency - "A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions."  Time behaviour  Resource utilization  Efficiency compliance  Maintainability - "A set of attributes that bear on the effort needed to make specified modifications."  Analyzability  Changeability  Stability  Testability  Maintainability compliance  Portability - "A set of attributes that bear on the ability of software to be transferred from one environment to another."  Adaptability  Installability  Co-existence  Replaceability  Portability compliance

ISO/IEC 25010:2011 (Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models) defines:

1. A quality in use model composed of five characteristics (some of which are further subdivided into subcharacteristics) that relate to the outcome of interaction when a product is used in a particular context of use. This system model is applicable to the complete human-computer system, including both computer systems in use and software products in use. 2. A product quality model composed of eight characteristics (which are further subdivided into subcharacteristics) that relate to static properties of software and dynamic properties of the computer system. The model is applicable to both computer systems and software products. 1. "Functionality" is renamed "functional suitability". "Functional completeness" is added as a subcharacteristic, and "interoperability" and "security" are moved elsewhere. "Accuracy" is renamed "functional correctness", and "suitability" is renamed "functional appropriateness". 2. "Efficiency" is renamed "performance efficiency". "Capacity" is added as a subcharactersitic. 3. "Compatibility" is a new characteristic, with "co-existence" moved from "portability" and "interoperability" moved from "functionality". 4. "Usability" has new subcharacteristics of "user error protection" and "accessibility" (use by people with a wide range of characteristics). "Understandability" is renamed "appropriateness recognizability", and "attractiveness" is renamed "user interface aesthetics". 5. "Reliability" has a new subcharacteristic of "availability" (when required for use). 6. "Security" is a new characteristic with subcharacteristics of "confidentiality" (data accessible only by those authorized), "integrity" (protection from unauthorized modification), "non-repudiation" (actions can be proven to have taken place), "accountability" (actions can be traced to who did them), and "authenticity" (identity can be proved to be the one claimed). 7. "Maintainability" has new subcharacteristics of "modularity" (changes in one component have a minimal impact on others) and "reusability"; "changeability" and "stability" are rolled up into "modifiability". 8. "Portability" has "co-existence" moved elsewhere. STANDARDI KVALITETA PROCESA RAZVOJA SOFTVERA

ISO/IEC 15504 Information technology – Process assessment, also termed Software Process Improvement and Capability Determination (SPICE), is a set of technical standards documents for the computer software development process and related business management functions.

ISO/IEC 15504 is the reference model for the maturity models (consisting of capability levels which in turn consist of the process attributes and further consist of generic practices) against which the assessors can place the evidence that they collect during their assessment, so that the assessors can give an overall determination of the organization's capabilities for delivering products (software, systems, and IT services ISO/IEC 15504 was initially derived from process lifecycle standard ISO/IEC 12207(Software lifecycle processes) ISO/IEC 15504 has been revised by: ISO/IEC 33001:2015 Information technology – Process assessment – Concepts and terminology as of March, 2015 and is no longer available at ISO.

 IZVOR: Hwang S.M: Process Quality Levels of ISO/IEC 15504, CMMI and K- model, International Journal of Software Engineering and Its Applications, Vol 3, No 1, January 2009. 

SOFTVERSKE METRIKE

DEFINICIJA: SOFTVERSKA METRIKA je standardna mera nivoa do kog sistem ili proces ima određene osobine. CILJ: obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments.

METRIČKI OKVIR ZA VREDNOVANJE KVALITETA MODELA U RAZVOJU SOFTVERA

Van Belle-ов оквир за евалуацију модела у области информационих система [Belle J-P, 2006] АСПЕКТ КРИТЕРИЈУМ (метрике) Синтаксни Величина (број концепата) аспект Коректност, непостојање грешака, интегритет, конзистентност, усклађеност са стандардима Модуларност (број група и нивоа дијаграма) Структура, хијерархија, степен поновне искористивости Комплексност, густина Архитектурни стил Семантички Генеричност (усклађеност са доменом) аспект Покривеност (покривеност домена и основних концепата) Комплетност (степен покривености речника -exicon) Ефикасност, концизност Експресивност Сличност и преклапање са другим сличним моделима Разумљивост, читљивост Документација (комплетност, проширивост, читљивост) Прагматички Валидност, прихваћеност од стране клијента и корисника аспект Флексибилност, проширивост, адаптибилност Зрелост, усклађеност са садашњим стањем (currency) Усклађеност са сврхом, циљем, релевантност, да одговара систему Доступност (availability)

MODEL POSLOVNIH PROCESA КРИТЕРИЈУМ ВРЕДНОВАЊА DTP BPM НАЗИВИ ЕЛЕМЕНАТА – правилни, прецизни + +  Процес + +  Ток података + +  Складиште података + +  Систем из окружења (entitet) +  Организациона јединица („swim lane“) + ОРГАНИЗАЦИЈА ЕЛЕМЕНАТА +  Стабло процеса – припадност, међузависност +  Стабло процеса – хронолошка уређеност +  Повезаност елемената - правило баланса +  Повезаност елемената – интерни токови +  Повезаност елемената – повезаност процеса са + + складиштима података  Повезаност елемената – повезаност са процеса са + системима из окружења  Хронолошки распоред процеса +  Распоред процеса, токова и складишта података + унутар одговарајуће „пливачке линије“ организационе јединице (учесника процеса) РЕЧНИК ПОДАТАКА + +  Потпуност скупа елементарних података + +  Правилни називи елементарних података + +  Правилан распоред елементарних података - у + + токовима података  Правилан распоред елементарних података – у + + складиштима података  Правилан синтаксни опис структуре тока података + +  Правилан синтаксни опис структуре складишта + + података

MODEL SOFTVERSKIH FUNKCIJA ОБЛАСТ КАРАКТЕРИСТИКА ТАБЕЛА Назив софтверске функције прецизан и технички коректан ПРЕСЛИКАВАЊА (назив као софтверска функција) Распоред – правилно одређен размештај софтверских функција по категоријама: 1. Приоритет, 2. Приоритет, Предуслов Потпуност- потпун скуп софтверских функција првог приоритета Правилно одређен профил корисника у односу на радно место примитивног пословног процеса и одговарајућих софтверских функција којима може да приступа ДИЈАГРАМ USE Правилна повезаност случаја коришћења са профилом CASE корисника Правилна међусобна повезаност случајева коришћења Правилно коришћење стереотипа код веза међузависности случајева коришћења СПЕЦИФИКАЦИЈА Правилно одређен предуслов СЛУЧАЈА Правилно описани кораци активности (action steps) КОРИШЋЕЊА Правилно одређене тачке проширења Правилно одређени изузеци Правилно одређен постуслов (резултат)

KONCEPTUALNI MODEL PODATAKA GRUPA GRUPA Potrebna osobina - METRIKA ELEMENATA OSOBINA Semantika Semantički u skladu sa problemom Pokrivenost opisa posla Usklađenost sa Pokrivenost importovanih datim elementarnih podataka CELINA materijalom Pokrivenost skladišta podataka sa MODELA DTP Kompletnost skupa entiteta Kompletnost Kompletnost skupa atributa Kompletnost skupa poveznika Jezička Nepostojanje sinonima u nazivima nedvosmislenost entiteta i atributa Nepostojanje homonima u nazivima entiteta i atributa Могућност креирања SQL упита Прагматика Једноставност ажурирања података у оквиру трансакција Imenica ili glagolska imenica Izražava sustinske objekte i Naziv dogadjaje Ne izražava nazive dokumenata Jednina u nazivu Ima identifikaciono obeležje ili je identifikaciono zavisan od drugih ENTITET entiteta Dodeljen atribut odgovarajućem Entitet i atributi entitetu (2NF) Ne postoje brojni odnosi atributa 1:M u entitetu (3NF) Ne postoje tranzitivne zavisnosti atributa u entitetu (1NF) Jednina u nazivu Naziv (1NF) Nema naziv kao struktura Odgovarajući tip podatka Atributi i tipovi Atribut nema za tip podatka domen /domeni (uzi skup vrednosti nego sto je podataka standardni tip podatka), vec je ATRIBUT izvucen kao sifarnik Atributi se sa istim nazivom ne ponavljaju (nema redundanse) Karakteristike Nema izračunljivih atributa, vec samo analitickih vrednosti medju atributima na osnovu kojih se vrše izracunavanja Poveznik ima naziv Naziv Naziv kao glagol Povezani direktno entiteti koji treba da budu povezani Entiteti su povezani hronoloskim Nacin sledom međuzavisnih događaja povezivanja Povezani su entiteti u gerund odnosu, entiteta ako je potrebno Ako poveznik ima važne atribute, pretvoren je u entitet POVEZNIK Pravilno podešen kardinalitet Pravilno podešena strana na vezi 1:M Pravilno određeno da li ima opravdanja za vezu 1:1 ili je jedan entitet Podesavanja Pravilno određeno u vezi 1:1 ko je osobina dominant Pravilno određeno u vezi M:M da li ima važnih atributa ili ostaje M:M Pravilno podesena identifikaciona zavisnost Pravilno podešena is-a hijerarhija (gde je nadredjeni, bar jedan podređeni, migrira samo ID)

METRIČKI MODEL ZA VREDNOVANJE KVALITETA SOFTVERA U OKVIRU INFORMACIONOG SISTEMA У наставку ће бити приказан метрички модел за евалуацију софтверске апликације као артефакта у процесу развоја софтвера информационог система. Метрички модел је описан кроз карактеристике из стандарда ISO 25010 и ISO 9126 (прва колона), истраживања [Jadhav&Sonar, 2009], [Whitworth&Zaic, 2003], [Irani, 2002] и имплементационе детаље реализације захтеване карактеристике, која омогућује конкретну проверу постојања одговарајуће карактеристике, односно имплементацију решења у складу са наведеним захтевом. ГРУПА ЗАХТЕВА / ЗАХТЕВ ИМПЛЕМЕНТАЦОНИ ДЕТАЉИ КВАЛИТЕТА РЕАЛИЗАЦИЈЕ ЗАХТЕВАНЕ КАРАКТЕРИСТИКЕ ФУНКЦИОНАЛНЕ КАРАКТЕРИСТИКЕ Функционалност софтвера Софтвер функционише Функционална усклађеност Усклађеност решења са захтевима (случајеви са потребама коришћења USE CASE или „user stories“), потребама и очекивањима корисника Подршка основним функцијама  Унос и аквизиција Унос података подршком за различите уређаје података  Ажурирање података брисање, измена  Верификација Контрола исправности података приликом података уноса/измене  Чување података База података, различити формати (XML), дистрибуиране базе података, бекап уређаји  Размена података Интероперабилност – експорт података, учитавање података других формата  Обрада података Сумарна и статистичка обрада података  Презентовање Графичко представљање, Визуализација података података, Графикони, Табеларни прикази  Претрага Филтрирање података, сортирање, навигација КВАЛИТЕТ ПОДАТАКА  Комплетност Усклађеност базе података, екранских форми и извештаја са базом података, захтевима корисника  Прецизност Одређени типови података, ограничења  Конзистентност Усклађеност података из различитих табела базе података (трансакције)  Доступност Поузданост апликације у LAN, развој web и мобилних апликација повећава доступност  Поузданост - Извор података – аквизиција, директни унос кредибилитет Профили корисника, Овлашћени приступ, НЕФУНКЦИОНАЛНЕ КАРАКТЕРИСТИКЕ  Погодност за Издвајање шифарника, довољан ниво одржавање апстракције дизајна базе података, модуларизација, вишеслојно програмирање  Модуларност Издвајање модула – Dynamic Link Libraries, Web Services  Конзистентност Усклађеност делова апликације  Поновна искористивост Модули са општим решењима, семантички независним, Генератори класа, Генератори корисничког интерфејса  Оптимално коришћење Брзина рада кода, минимизација процесорског ресурса времена и меморијских ресурса  Поузданост Верификација података, Коректност формула код израчунавања  Валидност Минимизација грешака функционисања  Стабилност Верификација података, Бекап података  Безбедност података Профили корисника, Овлашћени приступ, криптографија  Прецизност Тачност приликом обраде података (израчунавања, интеграција итд.)  Лакоћа коришћења Интуитивни кориснички интерфејс, Аутоматизми, Изглед корисничког интерфејса у складу са навикама (менталним моделима) корисника  Лакоћа учења Минимизација потребних корака у коришћењу коришћења апликације апликације за решавање неког пословног задатка  Прилагодљивост Технолошко решење које може бити различитим коришћено на различитим оперативним оперативним системима рачунара и мобилних уређаја, у окружењима оквиру различитих web browser-а  Интероперабилност са Могућност да коегзистира са другим другим апликацијама апликацијама Могућност да учитава податке из других апликација Могућност да доставља податке другим апликацијама Могућност да аутоматски интегрише свој рад са радом у оквиру других апликација разменом података  Могућност Измене структуре података, изгледа извештаја, прилагођавања изгледа корисничког интерфејса различитим захтевима – персонализација  Проширивост Могућност додавања нових функционалности уз интеграцију са постојећим  Ергономска погодност Усклађеност боја са потребама корисника, величина фонта, распоред контрола, подршка за различите уређаје за улаз (тастатура, миш, читачи картица) и излаз података (екран, штамшач...)  Подршка за Аутоматизми, Минимизација потребних корака продуктивност у коришћењу апликације за решавање неког пословног задатка  Управљивост Могућност да се врше измене у структури и начину функционисања апликације ради прилагођавања потребама пословања – кастомизација  Усклађеност са ИТ, семантички стандарди примене стандардима  Квалитет програмског Читљивост, рефакторисање, модуларност, кода коментари  Документовано Корисничка и техничка документација решење

METRIČKI MODEL KVALITETA PODATAKA KOJI SE KORISTE OD STRANE APLIKATIVNOG SOFTVERA

[w Desharnais]

Слика 2.2.4.1.10. McCall-ов модел са три нивоа погледа на карактеристике квалитета софтвера, према Sanz et al [Sanz et al, 2005] Табела 2.2.4.1.1. Функционалне карактеристике као критеријуми вредновања софтверског пакета [Jadhav&Sonar, 2009]

Табела 2.2.4.1.2. Карактеристике квалитета софтвера као критеријуми вредновања софтверског пакета [Jadhav&Sonar, 2009]

PREPORUKE I KONVENCIJE ZA PISANJE KVALITETNOG KODA

PREPORUKE ZA PISANJE KVALITETNOG KODA

Diomidis Spinellis, author of Code Quality: The Open Source Perspective Rule 1: Follow the Style Guide Every programming language has a style guide that tells you in great detail how to indent your code, where to put spaces and braces, how to name stuff, how to comment—all the good and bad practices. For example, the style guide tells you the 12 mistakes lurking in this code snippet: for(i=0 ;i<10 ;i++){

Read the guide carefully, learn the basics by heart, look up corner cases, apply the rules religiously, and your programs will be better than those written by the majority of university graduates. Many organizations customize style guides to reflect the organization's specific practices. For instance, Google has developed and released style guides for more than a dozen languages. These guides are well thought out, so check them out if you're looking for help programming for Google. Guides even include editor settings to help you apply a programming style, and custom tools can verify that your code adheres to that style. Use these tools. Rule 2: Create Descriptive Names Constrained by slow, clunky teletypes, programmers in the past used to contract the names of their variables and routines to save time, keystrokes, ink, and paper. This culture persists in some communities, in the name of backward compatibility; consider C's tongue-twisting wcscspn (wide character string complement span) function. But there's no excuse for this practice in modern code. Use long descriptive names, like complementSpanLength, to help yourself, now and in the future, as well as your colleagues to understand what the code does. The only exception to this rule concerns the few key variables used within a method's body, such as a loop index, a parameter, an intermediate result, or a return value. Even more importantly, think long and hard before you name something. Is the name accurate? Did you mean highestPrice, rather than bestPrice? Is the name specific enough to avoid taking more than its fair share of semantic space? Should you name your method getBestPrice, rather than getBest? Does its form match that of other similar names? If you have a method ReadEventLog, you shouldn't name another NetErrorLogRead. If you're naming a function, does the name describe what the function returns? Finally, there are some easy naming rules. Class and type names should be nouns. Methods names should contain a verb. In particular, if a method returns a value indicating whether something holds true for an object, the method name should start with is. Other methods that return an object's property should start with get, and those that set a property should start with set. Rule 3: Comment and Document Start every routine you write (function or method) with a comment outlining what the routine does, its parameters, and what it returns, as well as possible errors and exceptions. Summarize in a comment the role of each file and class, the contents of each class field, and the major steps of complex code. Write the comments as you develop the code; if you think you'll add them later, you're kidding yourself. In addition, ensure that your code as a whole (for example, an application or library) comes with at least a guide explaining what it does; indicating its dependencies; and providing instructions on building, testing, installation, and use. This document should be short and sweet; a single README file is often enough. Rule 4: Don't Repeat Yourself Never copy-and-paste code. Instead, abstract the common parts into a routine or class (or macro, if you must), and use it with appropriate parameters. More broadly, avoid duplicate instances of similar data or code. Keep a definitive version in one place, and let that version drive all other uses. Following are some good examples of this practice:  Creation of API reference guides from comments, using Javadoc or Doxygen  Automatic detection of unit tests through an annotation or a naming convention  Generation of both PDF and HTML documentation from a single markup source  Derivation of object classes from a database schema (or the opposite) Rule 5: Check for Errors and Respond to Them Routines can return with an error indication, or they can raise an exception. Deal with it. Don't assume that a disk will never fill up, your configuration file will always be there, your application will run with the required permissions, memory-allocation requests will always succeed, or that a connection will never time out. Yes, good error-handling is hard to write, and it makes the code longer and less readable. But ignoring errors and exceptions simply sweeps the problem under the carpet, where an unsuspecting end user will inevitably find it one day. Rule 6: Split Your Code into Short, Focused Units Every method, function, or logical code block should fit on a reasonably-sized screen window (25–50 lines long). If it's longer, split it into shorter pieces. An exception can be made for simple repetitive code sequences. However, in such cases, consider whether you could drive that code through a data table. Even within a routine, divide long code sequences into blocks whose function you can describe with a comment at the beginning of each block. Furthermore, each class, module, file, or process should concern one single thing. If a code unit undertakes diverse responsibilities, split it accordingly. Rule 7: Use Framework APIs and Third-Party Libraries Learn what functionality is available through an API in your programming framework, and also what's commonly available through mature, widely adopted third-party libraries. Libraries supported by your system's package manager are often a good bet. Use that code, resisting the temptation to reinvent the wheel (in a dysfunctional square shape). Rule 8: Don't Overdesign Keep your design focused on today's needs. Your code can be general to accommodate future evolution, but only if that doesn't make it more complex. Don't create parameterized classes, factory methods, deep inheritance hierarchies, and arcane interfaces to solve problems that don't yet exist—you can't guess what tomorrow will bring. On the other hand, when the code's structure no longer fits the task at hand, don't shy away from refactoring it to a more appropriate design. Rule 9: Be Consistent Do similar things in similar ways. If you're developing a routine whose functionality resembles that of an existing routine, use a similar name, the same parameter order, and a comparable structure for the code body. The same rule applies to classes: Give the new class similar fields and methods, make it adhere to the same interface, and match any new names with those already used in similar classes. Make the order and number of case statements or if else blocks follow the corresponding definition in the specifications you're using. Keep unrelated items in alphabetical or numerical order. Your code should adopt the conventions of the framework in which you're programming. For instance, it's common practice to represent ranges half-open: closed (inclusive) on the left (the range's beginning), but open (exclusive) on the right (the end). If there's no a convention for a particular choice, establish one and follow it religiously. Rule 10: Avoid Security Pitfalls Modern code rarely works in isolation. Therefore it will inevitably risk becoming the target of malicious attacks. They don't have to come from the Internet; the attack vector could be data fed into your application. Depending on your programming language and application domain, you might have to worry about buffer overflows, cross-site scripting, SQL injection, and similar problems. Learn what these problems are, and avoid them in your code. It's not difficult. Rule 11: Use Efficient Data Structures and Algorithms Simple code is often more maintainable than equivalent code hand-tuned for efficiency. Fortunately, you can combine maintainability with efficiency by utilizing the data structures and algorithms provided by your programming framework. Use maps, sets, vectors, and the algorithms that work on them, and your code will be clearer, more scalable, faster, and memory-frugal. For example, if you keep a thousand values in an ordered set, a set intersection will find the values common with another set in a similar number of operations, rather than performing a million comparisons. Rule 12: Include Unit Tests The complexity of modern software makes it expensive to deploy a system and difficult to test it as a black box. A more productive approach is to accompany every small part of your code with tests that verify its correct function. This approach simplifies debugging by allowing you to catch errors early, close to their source. Unit testing is indispensable when you program with dynamically typed languages such as Python and JavaScript, because they'll only catch at runtime any errors that that a statically typed language such as Java, C#, or C++ would catch at compile time. Unit testing also allows you to refactor the code with confidence. You can use an xUnit framework to simplify writing these tests and automate running them. Rule 13: Keep Your Code Portable Unless you have some compelling reason, avoid using functionality that's available only on a specific platform or framework. Don't assume that particular data types (such as integers, pointers, and time) are of a given width (for example, 32 bits), because this differs between various platforms. Store the program's messages separately from the code, and don't hardcode cultural conventions such as a decimal separator or date format. Conventions need to change when your code runs in other countries around the world, so keep this adaptation as painless as possible. Rule 14: Make Your Code Buildable A single command should build your code into a form that's ready for distribution. The command should allow you to perform fast incremental builds and run the required tests. To achieve this goal, use a build automation tool like Make, Apache Maven, or Ant. Ideally, you should set up a continuous integration system that will check, build, and test your code every time you make a change. Rule 15: Put Everything Under Version Control All elements of your system—code, documentation, tool sources, build scripts, test data—should be under version control. Git and GitHub make this task cheap and hassle-free, but many other similarly powerful tools and services are available. You should be able to build and test your program on a properly configured system, simply by checking out the code from the repository.

Code Conventions for the JavaScript Programming Language DOUGLAS CROCKFORD Douglas Crockford is an American computer programmer and entrepreneur who is best known for his ongoing involvement in the development of the JavaScript language, for having popularized the data format JSON (JavaScript Object Notation), http://www.crockford.com/index.html

This is a set of coding conventions and rules for use in JavaScript programming. The long-term value of software to an organization is in direct proportion to the quality of the codebase. Over its lifetime, a program will be handled by many pairs of hands and eyes. If a program is able to clearly communicate its structure and characteristics, it is less likely that it will break when modified in the never-too- distant future. Code conventions can help in reducing the brittleness of programs. All of our JavaScript code is sent directly to the public. It should always be of publication quality. Neatness counts. JavaScript Files JavaScript programs should be stored in and delivered as .js files. JavaScript code should not be embedded in HTML files unless the code is specific to a single session. Code in HTML adds significantly to pageweight with no opportunity for mitigation by caching and compression. Whitespace Where possible, these rules are consistent with centuries of good practice with literary style. Deviations from literary style should only be tolerated if there is strong evidence of a significant benefit. Blank lines improve readability by setting off sections of code that are logically related. Blank spaces should always be used in the following circumstances:  A keyword followed by ( left parenthesis should be separated by a space. Spaces are used to make things that are not invocations look less like invocations, so for example, there should be space after if or while. while (true) {  A blank space should not be used between a function value and its invoking ( left parenthesis. This helps to distinguish between keywords and function invocations.  The word function is always followed with one space.  No space should separate a unary operator and its operand except when the operator is a word such as typeof.  All binary operators should be separated from their operands by a space on each side except . period and ( left parenthesis and [ left bracket.  Every , comma should be followed by a space or a line break.  Each ; semicolon at the end of a statement should be followed with a line break.  Each ; semicolon in the control part of a for statement should be followed with a space. Every statement should begin aligned with the current indentation. The outermost level is at the left margin. The indentation increases by 4 spaces when the last token on the previous line is { left brace, [ left bracket, ( left paren. The matching closing token will be the first token on a line, restoring the previous indentation. The ternary operator can be visually confusing, so ? question mark always begins a line and increase the indentation by 4 spaces, and : colon always begins a line, aligned with the ? question mark. The condition should be wrapped in parens. var integer = function ( value, default_value ) { value = resolve(value); return (typeof value === "number") ? Math.floor(value) : (typeof value === "string") ? value.charCodeAt(0) : default_value; }; If . period is the first character on a line, the indentation is increased by 4 spaces. Avoid excessively long lines. When a statement will not fit nicely on a single line, it may be necessary to break it. It is best to break after a { left brace, [ left bracket, ( left paren, , comma, or before a . period, ? question mark, or : colon. Clauses (case, catch, default, else, finally) are not statements and so should not be indented like statements. Use of tabs invites confusion, argument,and crying, with little compensating value. Do not use tabs. Comments Be generous with comments. It is useful to leave information that will be read at a later time by people (possibly your future self) who will need to understand what you have done and why. The comments should be well-written and clear, just like the code they are annotating. An occasional nugget of humor might be appreciated. Frustrations and resentments will not. It is important that comments be kept up-to-date. Erroneous comments can make programs even harder to read and understand. Make comments meaningful. Focus on what is not immediately visible. Don't waste the reader's time with stuff like // Set i to zero.

i = 0; Use line comments, not block comments. The comments should start at the left margin. Variable Declarations All variables should be declared before used. JavaScript does not require this, but doing so makes the program easier to read and makes it easier to detect undeclared variables that may become implied. Implied global variables should never be used. Use of global variables should be minimized. It is preferred that each variable declarative statement and comment. They should be listed in alphabetical order if possible. var currentEntry; // currently selected table entry var level; // indentation level var size; // size of table A JavaScript var does not have block scope, so defining variables in blocks can confuse programmers who are experienced with other C family languages. Function Declarations All functions should be declared before they are used. Inner functions should follow the var statement. This helps make it clear what variables are included in its scope. There should be no space between the name of a function and the ( left parenthesis of its parameter list. There should be one space between the ) right parenthesis and the { left curly brace that begins the statement body. The body itself is indented four spaces. The } right curly brace is aligned with the line containing the beginning of the declaration of the function. function outer(c, d) { var e = c * d;

function inner(a, b) { return (e * a) + b; }

return inner(0, 1); } This convention works well with JavaScript because in JavaScript, functions and object literals can be placed anywhere that an expression is allowed. It provides the best readability with inline functions and complex structures. function getElementsByClassName(className) { var results = []; walkTheDOM(document.body, function (node) { var array; // array of class names var ncn = node.className; // the node's classname

// If the node has a class name, then split it into a list of simple names. // If any of them match the requested name, then append the node to the list of results.

if (ncn && ncn.split(" ").indexOf(className) >= 0) { results.push(node); } }); return results; } If a function literal is anonymous, there should be one space between the word function and the ( left parenthesis. If the space is omitted, then it can appear that the function's name is function, which is an incorrect reading. div.onclick = function (e) { return false; };

that = { method: function () { return this.datum; }, datum: 0 }; Use of global functions should be minimized. When a function is to be invoked immediately, the entire invocation expression should be wrapped in parens so that it is clear that the value being produced is the result of the function and not the function itself. var collection = (function () { var keys = []; var values = [];

return { get: function (key) { var at = keys.indexOf(key); if (at >= 0) { return values[at]; } }, set: function (key, value) { var at = keys.indexOf(key); if (at < 0) { at = keys.length; } keys[at] = key; values[at] = value; }, remove: function (key) { var at = keys.indexOf(key); if (at >= 0) { keys.splice(at, 1); values.splice(at, 1); } } }; }()); Names Names should be formed from the 26 upper and lower case letters (A .. Z, a .. z), the 10 digits (0 .. 9), and _ underbar. Avoid use of international characters because they may not read well or be understood everywhere. Do not use $ dollar sign or \ backslash in names. Do not use _ underbar as the first or last character of a name. It is sometimes intended to indicate privacy, but it does not actually provide privacy. If privacy is important, use closure. Avoid conventions that demonstrate a lack of competence. Most variables and functions should start with a lower case letter. Constructor functions that must be used with the new prefix should start with a capital letter. JavaScript issues neither a compile-time warning nor a run-time warning if a required new is omitted. Bad things can happen if new is not used, so the capitalization convention is the only defense we have. Global variables in browsers should be in all caps. Statements Simple Statements Each line should contain at most one statement. Put a ; semicolon at the end of every simple statement. Note that an assignment statement that is assigning a function literal or object literal is still an assignment statement and must end with a semicolon. JavaScript allows any expression to be used as a statement. This can mask some errors, particularly in the presence of semicolon insertion. The only expressions that should be used as statements are assignments, invocations, and delete. Compound Statements Compound statements are statements that contain lists of statements enclosed in { } curly braces.  The enclosed statements should be indented four more spaces.  The { left curly brace should be at the end of the line that begins the compound statement.  The } right curly brace should begin a line and be indented to align with the beginning of the line containing the matching { left curly brace.  Braces should be used around all statements, even single statements, when they are part of a control structure, such as an if or for statement. This makes it easier to add statements without accidentally introducing bugs. Labels Statement labels should be avoided. Only these statements should be labeled: while, do, for, switch. return Statement The return value expression must start on the same line as the return keyword in order to avoid semicolon insertion. if Statement The if class of statements should have the following form: if (condition) { statements }

if (condition) { statements } else { statements }

if (condition) { statements } else if (condition) { statements } else { statements } for Statement A for class of statements should have the following form: for (initialization; condition; update) { statements } while Statement A while statement should have the following form: while (condition) { statements } do Statement A do statement should have the following form: do { statements } while (condition); Unlike the other compound statements, the do statement always ends with a ; semicolon. switch Statement A switch statement should have the following form: switch (expression) { case expression: statements default: statements } Each case is aligned with the switch. This avoids over-indentation. A case label is not a statement, and should not be indented like one. Each group of statements (except the default) should end with break, return, or throw. Do not fall through. try Statement The try class of statements should have the following form: try { statements } catch (variable) { statements }

try { statements } catch (variable) { statements } finally { statements } continue Statement Avoid use of the continue statement. It tends to obscure the control flow of the function. with Statement The with statement should not be used. {} and [] Use {} instead of new Object(). Use [] instead of new Array(). Use arrays when the member names would be sequential integers. Use objects when the member names are arbitrary strings or names. , comma Operator Avoid the use of the comma operator. (This does not apply to the comma separator, which is used in object literals, array literals, var statements, and parameter lists.) Assignment Expressions Avoid doing assignments in the condition part of if and while statements. Is if (a = b) { a correct statement? Or was if (a == b) { intended? Avoid constructs that cannot easily be determined to be correct. === and !== Operators. Use the === and !== operators. The == and != operators do type coercion and should not be used. Confusing Pluses and Minuses Be careful to not follow a + with + or ++. This pattern can be confusing. Insert parens between them to make your intention clear. total = subtotal + +myInput.value; is better written as total = subtotal + (+myInput.value); so that the + + is not misread as ++. Avoid ++. eval is Evil The eval function is the most misused feature of JavaScript. Avoid it. eval has aliases. Do not use the Function constructor. Do not pass strings to setTimeout or setInterval.

ELEMENTI PROGRAMSKOG STILA

Brian W. Kernighan, P.J. Plauger:The Elements of Programming Style Računarski programi treba da budu napisani ne samo da zadovolje kompajlere ili da imaju personalni programerski stil, već da budu čitljivi od strane ljudi, prvenstveno zaposlenih na pozicijama održavanja softvera, drugih programera i zaposlenih na dokumentovanju (technical writers). 1. Write clearly -- don't be too clever. 2. Say what you mean, simply and directly. 3. Use library functions whenever feasible. 4. Avoid too many temporary variables. 5. Write clearly -- don't sacrifice clarity for efficiency. 6. Let the machine do the dirty work. 7. Replace repetitive expressions by calls to common functions. 8. Parenthesize to avoid ambiguity. 9. Choose variable names that won't be confused. 10.Avoid unnecessary branches. 11.If a logical expression is hard to understand, try transforming it. 12.Choose a data representation that makes the program simple. 13.Write first in easy-to-understand pseudo language; then translate into whatever language you have to use. 14.Modularize. Use procedures and functions. 15.Avoid gotos completely if you can keep the program readable. 16.Don't patch bad code -- rewrite it. 17.Write and test a big program in small pieces. 18.Use recursive procedures for recursively-defined data structures. 19.Test input for plausibility and validity. 20.Make sure input doesn't violate the limits of the program. 21.Terminate input by end-of-file marker, not by count. 22.Identify bad input; recover if possible. 23.Make input easy to prepare and output self-explanatory. 24.Use uniform input formats. 25.Make input easy to proofread. 26.Use self-identifying input. Allow defaults. Echo both on output. 27.Make sure all variables are initialized before use. 28.Don't stop at one bug. 29.Use debugging compilers. 30.Watch out for off-by-one errors. 31.Take care to branch the right way on equality. 32.Be careful if a loop exits to the same place from the middle and the bottom. 33.Make sure your code does "nothing" gracefully. 34.Test programs at their boundary values. 35.Check some answers by hand. 36.10.0 times 0.1 is hardly ever 1.0. 37.7/8 is zero while 7.0/8.0 is not zero. 38.Don't compare floating point numbers solely for equality. 39.Make it right before you make it faster. 40.Make it fail-safe before you make it faster. 41.Make it clear before you make it faster. 42.Don't sacrifice clarity for small gains in efficiency. 43.Let your compiler do the simple optimizations. 44.Don't strain to re-use code; reorganize instead. 45.Make sure special cases are truly special. 46.Keep it simple to make it faster. 47.Don't diddle code to make it faster -- find a better algorithm. 48.Instrument your programs. Measure before making efficiency changes. 49.Make sure comments and code agree. 50.Don't just echo the code with comments -- make every comment count. 51.Don't comment bad code -- rewrite it. 52.Use variable names that mean something. 53.Use statement labels that mean something. 54.Format a program to help the reader understand it. 55.Document your data layouts. 56.Don't over-comment

ČITLJIVOST KODA – STILOVI PROGRAMIRANJA Indentation if (hours < 24 && minutes < 60 && seconds < 60) { return true; } else { return false; } or if (hours < 24 && minutes < 60 && seconds < 60) { return true; } else { return false; } with something like if ( hours < 24 && minutes < 60 && seconds < 60 ) {return true ;} else {return false ;}

Vertical alignment

It is often helpful to align similar elements vertically, to make typo-generated bugs more obvious. Compare:

$search = array('a', 'b', 'c', 'd', 'e'); $replacement = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value = 0; $anothervalue = 1; $yetanothervalue = 2; with:

$search = array('a', 'b', 'c', 'd', 'e'); $replacement = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value = 0; $anothervalue = 1; $yetanothervalue = 2; $yetanothervalue = 2;

Spaces

For instance, compare the following syntactically equivalent examples of C code: int i; for(i=0;i<10;++i){ printf("%d",i*i+i); } versus int i; for (i=0; i<10; ++i) { printf("%d", i*i+i); } versus int i; for (i = 0; i < 10; ++i) { printf("%d", i * i + i); }

REFAKTORISANJE PROGRAMSKOG KODA

DEFINICIJA: unapređenje kvaliteta koda bez izmene funkcionalnosti

KNJIGA: Martin Fowler: “Refactoring: Improving the Design of Existing Code” SADRŽAJI sa dodatnog web sajta: https://refactoring.com/catalog/

DODATNI PRIMERI I TEKSTOVI:

 SOFTWARE DEVELOPMENT GUIDELINES http://webster.cs.ucr.edu/Page_softeng/softDevGuide_contents.html  Osvaldo Pinali Doederlein: Writing quality code with NetBeans  Hwang S.M: Process Quality Levels of ISO/IEC 15504, CMMI and K-model, International Journal of Software Engineering and Its Applications, Vol 3, No 1, January 2009.  INSPEKCIJA KODA I PRIMERI GRESAKA U KODU: “Graham Bolton, Stuart Johnston: IfSQ Level 2, a foundation-Level standard for computer program source code, Second Edition, November 2009”.  Smells to refactorings Quick Reference Guide, Industrial Logic, 2005 (http://industriallogic.com)

CAS 6

FAZE RAZVOJA SOFTVERA NAJVAŽNIJI ARTEFAKTI I RADNE POZICIJE

(IZVORI ZA PLANIRANJE I SPROVOĐENJE TESTIRANJA SOFTVERA)

FAZA ARTEFAKT RADNA PREDM GRUPA ULOGA ET ARTEFAKTA UPOZNAVANJE SA GRUBI MODEL Business IS 1 IDEJNI POSLOVNIM POSLOVNIH PROCESA – Process PROJEKAT – PROCESOM activity dijagram Analyst – KONCEPTUAL GRUBI KONCEPTUALNI analizira NI MODEL MODEL – poslovne poslovni entiteti procese kakve jesu i kakvi ce biti

Agile Product Owner, Business Systems Analyst

SNIMAK STANJA Tekst snimka stanja – Business IS 1 postojeća rešenja, consultant – planovi, strategije, analizira problemi poslovne ciljeve i zadatke i predlaže rešenja za poslovne problem

Agile Product Owner, Business Systems Analyst

SPECIFIKACIJA Client requirements Requirement IS 1 ZAHTEVA document s Analyst- SE 2 specifier dokumentuje zahteve poslovanja Agile Product Owner, Business Systems Analyst

Specifikacija poslovnih Management ciljeva i procesa, consultant – usklađenost za omogućava projektom razvoj poslovnih strateških ciljeva

Agile Product Owner, Business Systems Analyst

PLANIRANJE Project charter Business Upravlj PROJEKTA Project plan consultant – anje analizira projekti poslovne ma ciljeve i SE 2 zadatke i predlaže rešenja za poslovne problem

Project manager DIZAJN - Dokument opisa System SE1 ARHITEKTURA arhitekture sistema Analyst – SE2 SISTEMA UML model – dijagram prevodi IS1 komponenti zahteve UML model – dijagram poslovanja u razmeštaja sistemske- funkcionalne zahteve DETALJNO DETALJNI BUSINESS Business IS1 GLAVNI UPOZNAVANJE SA PROCESS MODEL sa Process PROJEKAT – POSLOVNIM rečnikom podataka Analyst – LOGIČKO PROCESOM GLOSSARY – rečnik analizira PROJEKTOVA poslovnih termina sa poslovne NJE objašnjenjima i procese sinonimima kakve jesu I kakvi ce biti

Business Architect – analizira ceo poslovni process, podatke I ciljeve DIZAJN UML model- use case sa Software IS1 SOFTVERSKIH specifikacijom architect SE1 FUNKCIJA SE 2 DIZAJN MODELA CDM model Data Analyst IS1 PODATAKA Data Modeler PLANIRANJE PDM model baze Software - IS1 DETALJNI IMPLEMENTACIJE podataka Solution PROJEKAT- UML model – dijagram architect FIZIČKO klasa PROJEKTOVA Razmatranje gotovih Software - SE2 NJE, tj. rešenja – framework, Solution planiranje arhitekturni šabloni, architect implementacij biblioteke klasa e IMPLEMENTACIJA - User story – kratki Scrum SE1 PRODUKCIJA IZRADA BAZE tekstovi zahteva master SE2 PODATAKA, korisnika za doradom u Agile Product IS2 PROGRAMIRANJE toku razvoja Owner, Business Systems Analyst

Shema baze podataka Programmer Izvorni kod Developer

TESTIRANJE Test plan Tester SE2 Test slučajevi Scrum Rezultati testiranja master Rezultati korekcija DOKUMENTOVANJE Korisničko uputstvo Technical SE1 Tehničko uputstvo writer SE2 Scrum IS2 master

ISPORUKA - Izvršni kod Product SE1 INSTALACIJA Instalaciona verzija owner SE2 programa Release IS2 Tehničko uputstvo za Manager instalaciju i održavanje Obuka Uputstvo za korišćenje Trainer SE1 POSTPRODUK SE2 CIJA IS2 ODRZAVANJE – Zahtev za izmenom Scrum SE2 IZMENE Izveštaj o realizovanoj master izmeni Developer Agile Product Owner, Business Systems Analyst

IZVOR: HTTP://JOBDESCRIPTIONS.NET/BUSINESS/BUSINESS-ANALYST/ MANY DIFFERENT INDUSTRIES EMPLOY BUSINESS ANALYSTS WITH VARIOUS ROLES AND TITLES. SOME OF THESE ARE:  A BUSINESS CONSULTANT ANALYZES THE BUSINESS OBJECTIVES OF THE STAKEHOLDER AND DEVELOPS SOLUTIONS TO THEIR BUSINESS ISSUES.  A DATA ANALYST DEVELOPS A LOGICAL DATA MODEL.  A BUSINESS PROCESS ANALYST ANALYZES AND DEFINES PROCESSES OF BUSINESS BOTH “TO BE” AND “AS IS.”  A REQUIREMENTS ANALYST/SPECIFIER IDENTIFIES, ANALYZES, AND DOCUMENTS BUSINESS REQUIREMENTS AND DELIVERS WORK PRODUCTS THROUGHOUT THE PROJECT LIFE CYCLE.  A BUSINESS ARCHITECT ANALYZES THE ENTIRE BUSINESS, INCLUDING DATA, GOALS, PROCESS, AND ORGANIZATION.  A MANAGEMENT CONSULTANT AIDS STAKEHOLDERS IN DEVELOPING THEIR STRATEGIC GOALS.  A SYSTEMS ANALYST TRANSLATES BUSINESS REQUIREMENTS TO SYSTEM/FUNCTIONAL REQUIREMENTS, AND THEN THESE ARE PASSED TO APPLICATION DEVELOPERS. BUSINESS ANALYSTS USUALLY TAKE ON SEVERAL OF THE LISTED ROLES, SO THIS JOB IS IDEAL FOR A PERSON HAVING A BROAD SKILL SET. OTHER JOB REQUIREMENTS INCLUDE:  ENSURING THAT THE RECOMMENDED SOLUTION IS BOTH COMMERCIAL AND COMPETITIVE  UNDERSTANDING BUSINESS REQUIREMENTS AND TRANSLATING THEM INTO SPECIFIC SOFTWARE REQUIREMENTS  UNDERSTANDING BOTH TECHNICAL DESIGNS AND SPECIFICATIONS  ANALYZING AND DOCUMENTING THE REQUIRED DATA AND INFORMATION  EVALUATING INFORMATION HARVESTED THROUGH SURVEYS AND WORKSHOPS, TASK ANALYSIS, AND BUSINESS PROCESS DESCRIPTION  HAVING STRONG TECHNICAL SKILLS, BUSINESS INTELLIGENCE, AND A FULL UNDERSTANDING OF THE NEEDS OF THE CUSTOMER  BEING ABLE TO EFFECTIVELY COMMUNICATE WITH EXTERNAL CLIENTS AND INTERNAL TEAMS TO DELIVER GUI, INTERFACE AND SCREEN DESIGNS  BEING AN INTERFACE BETWEEN TECHNOLOGY TEAMS, SUPPORT TEAMS, AND BUSINESS UNITS

Most of the time, a solutions architect can be considered a de facto leader of a company’s development team. This is a brief list of what is expected of solutions architects:

 Identifying the key issues and weaknesses of a set of problems the organization is dealing them;  Converting those problems into requirements for the technological side of activities;  Identifying technological or tech-related solutions to those issues; this is often achieved through a fair amount of research, sometimes the topics of that research may be so far from the initial problem that they may even seem out of place.  Building an architectural design of solutions based on the findings. By ‘architectural design’ we mean a structural build of how those solutions are meant to function together as a whole, we’re not referring to actual architecture (unless the organization’s activities specifically require it).  Conversion of those requirements into the designed solution architecture, in a way which will surpass the problem at hand: the structure of solutions created should outlive the initial task and become a template or a blueprint for tackling all similar issues in the future.  Translation of the architecture’s perks to the other development team members and leaders. This part is essential: all parties which are expected to implement the solutions prescribed must buy into the new way of solving them, understand why the change is necessary etc.

A computer systems analyst works in the grey area between IT and business management. They analyze existing computing solutions within an organization and help increase efficiency. They can ‘translate’ what the managers of a company wants in order to make that company more efficient to the IT department.

IZVOR: HTTPS://JOBS.WALGREENS.COM/JOB/-/-/1242/5194472?CODES=INDEED

Agile Product Owner (Business Systems Analyst) will need to be proficient in the following areas:

 Strong understanding of the complete software development life-cycle  Hands-on experience in product management and business analysis  Experience in coordinating with UI and UX teams  Practical knowledge of Agile/Scrum  Requirement gathering and heavy time management experience is critical

Responsible for conducting complex and thorough research of existing processes, systems, systems logic, hardware deployment and desired objectives to develop detailed systems specifications to meet the objectives of the assigned projects. This position examines, in detail, existing manual and automated processes, documentation and training requirements, and the capacities and limitations of existing, or proposed hardware in order to develop comprehensive specifications in a formal and structured way. Implements activities that generally impact discrete components / processes of the work of own unit / team / projects. Receives work in the form of short-term assignments that often require the application of independent judgment. Operates within the context of defined procedures.

Job Responsibilities

 Participates in gathering and analyzing of internal business requirements by means of interviews, workflow analyses and facilitated discussions with users.  Translates users' business requirements into detailed functional designs for development, testing and implementation.  Applies methodologies such as Unified Modeling Language ("UML") and Rational Unified Process ("RUP") and prepares detailed specifications using case statements and related documentation.  Identifies and communicates risks and issues impacting business rules, functional requirements and specifications.  Participates in managing the scope of applications and related changes.  Assists quality assurance with functional test case reviews.  Collaborates with stakeholders on the evaluation of the feasibility, effort and costs to implement requirements.  Participates in the creation of training materials and may assist with user orientation and training.  Interacts with internal and external peers and managers to exchange information related to areas of specialization. May serves as a liaison between engineering, quality assurance and non-technical stakeholders during the development and deployment process.  Effectively resolves problems and roadblocks before they occur.  Mentors less experienced members of the team.

IZVOR: https://jobs.walgreens.com/job/-/-/1242/5420012?codes=Indeed Business Analyst II/Agile Scrum Master

Job Responsibilities Participates in gathering and analyzing of internal business requirements by means of interviews, workflow analyses and facilitated discussions with users.

 Translates users' business requirements into detailed functional designs for development, testing and implementation.  Applies methodologies such as Unified Modeling Language ("UML") and Rational Unified Process ("RUP") and prepares detailed specifications using case statements and related documentation.  Identifies and communicates risks and issues impacting business rules, functional requirements and specifications.  Participates in managing the scope of applications and related changes.  Assists quality assurance with functional test case reviews.  Collaborates with stakeholders on the evaluation of the feasibility, effort and costs to implement requirements.  Participates in the creation of training materials and may assist with user orientation and training.  Interacts with internal and external peers and managers to exchange information related to areas of specialization. May serves as a liaison between engineering, quality assurance and non-technical stakeholders during the development and deployment process.  Effectively resolves problems and roadblocks before they occur.  Mentors less experienced members of the team.

MERENJE USPEHA PROJEKTA ILI PROCESA RAZVOJA

(u kontekstu stalnog procesa unapređenja, tj. CMM zrelosti)

“If You Can’t Measure It, You Can’t Manage It”, W. Edwards Deming, The New Economics, page 35. In Out of the Crisis, page 121, Dr. Deming wrote: “the most important figures that one needs for management are unknown or unknowable, but successful management must nevertheless take account of them.” IZVOR: https://management.curiouscatblog.net/2010/08/04/how-to-manage-what- you-cant-measure/

“To hire talented people and hobble them with bureaucracy is the height of stupidity and poor management to boot.” Nije preporučljivo raditi „MICROMANAGE“, nadgledati zaposlene previše detaljno, već treba imati poverenja i dozvoliti slobodu i kreativnost.

IZVOR: https://www.forbes.com/sites/lizryan/2014/02/10/if-you-cant-measure-it- you-cant-manage-it-is-bs/#356faccf7b8b

To begin, we'll define a few of the terms. We are using "measure" as a verb, not a noun and "benchmark" as a noun, not adverb.  Measure: The verb means "to ascertain the measurements of"  Measurement: The figure, extent, or amount obtained by measuring"  Metric: "A standard of measurement"  Benchmark: "A standard by which others may be measured" So we collect data (measurements), determine how those will be expressed as a standard (metric), and compare the measurement to the benchmark to evaluate progress. For example, we measure number of lines of code written by each programmer during a week. We measure (count) the number of bugs in that code. We establish "bugs per thousand lines of code" as the metric. We compare each programmer's metric against the benchmark of "fewer than 1 defect (bug) per thousand lines of code". What To Measure: Measure those activities or results that are important to successfully achieving your organization's goals. Key Performance Indicators, also known as KPIs or Key Success Indicators (KSIs), help an organization define and measure those activities that support making progress toward goals. KPIs differ depending on the organization. A business may have as one of its KPIs the percentage of its income that comes from returning or repeat customers. A Customer Service department may measure the percentage of customer calls answered in the first minute. A Key Performance Indicator for a development organization might be the number of defects in their code. You may need to measure several things to be able to calculate the metrics in your KPIs. To measure progress toward a Customer Service KPI, the department will need to measure (count) how many calls it receives. It must also measure how long it takes to answer each call and how many customers are satisfied with the service they received. The Customer Service Manager can use those various measures to calculate the percentage of customer calls answered in the first minute and to gauge overall effectiveness in answering calls. How To Measure: How you measure is as important as what you measure. In the previous example, we can measure the number of calls by having each Customer Service representative (CSR) count their own calls and tell their supervisor at the end of the day. We could have an operator counting the number of calls transferred to the department. The best option, although the most expensive, would be to purchase a software program that counts the number of incoming calls, measures how long it takes to answer each, records who answered the call, and measures how long the call took to complete. These measurements are current, accurate, complete, and unbiased. Collecting the measurements in this way enables the manager to calculate the percentage of customer calls answered in the first minute. In addition, it provides additional measurements that help him or her manage toward improving the percentage of calls answered quickly. Knowing the call durations lets the manager calculate if there is enough staff to reach the goal. Knowing which CSRs answer the most calls identifies for the manager expertise that can be shared with other representatives. How To Use Measurements: Most often, these measurements are used as part of a Continuous Improvement Plan. Similar plans are used by many companies in different industries and given different names, but the goal is the same - to measure the key factors and improve them.

Measure To Manage:  Measure what's important.  Publish your metrics and benchmarks.  Use the metrics to guide decisions.  Reward people for exceeding their goals.  And then keep tuning the metrics. IZVOR: HTTPS://WWW.THEBALANCE.COM/YOU-CAN-T-MANAGE-WHAT-YOU-DONT- MEASURE-2275996 TESTIRANJE SOFTVERA

IZVOR:

Ron Patton: Software testing, SAMS publishing, 2001.

STANDARD

ANSI/IEEE 829 – standard za software test documentation

SOFTWARE BUG - definicija

 Softver ne radi ono što je specifikacijom proizvoda navedeno da treba.  Softver radi nešto što je u specifikaciji naglašeno da ne treba.  Softver radi nešto što nije spomenuto u specifikaciji.  Sofver ne radi ono što u specifikaciji nije napomenuto, ali bi trebalo da je receno u specifikaciji.  Softver je tezak za razumevanje I koriscenje, spor ili prema stavu testera – jednostavno ne radi dobro.

POSAO TESTERA

Da pronađe greške i to što ranije i da se postara da budu ispravljene.

ARTEFAKTI TESTIRANJA

 Ulazni – veza ka drugim aktivnostima-artefaktima u razvoju softvera, V model  Izlazni – rezultati planiranja i realizacije testiranja

Izvor slike: John E. Bentley: Software Testing Fundamentals—Concepts, Roles, and Terminology

TEST DOKUMENTACIJA

 Test plan – opisuje metod provere da li je softver u skladu sa specifikacijom proizvoda I potrebama korisnika. Ukljucuje ciljeve kvaliteta, izvore, plan rada, zadatke, metode….  Test slučajevi – opisuje sta ce biti testirano (stavke), korake I podatke koji ce biti korisceni u testiranju.  Izvešaj o greškama (“Test incident report”) – problemi koji su pronadjeni  Metrike, statistike I sumarni izveštaji

OSNOVNI POJMOVI

 Precision and accuracy  Verification and validation  Quality and reliability  Testing and Quality assurance

METODE TESTIRANJA

 Black box (funkcionalno) - white box (strukturno - uzimanje u obzir programskog koda, strukture)  Static (bez pokretanja) – Dynamic (u toku izvršavanja)  Visokog nivoa (specifikacija) I niskog nivoa (implementacija)

NAJČEŠĆE VARIJANTE:

 Dynamic black box (behavioural testing)– test to pass I test to fail, equivalence partitioning, granicne vrednosti, default – null vrednosti, tehnike: repetition, stress (nedovoljno memorije), load (previse podataka)  Static white box (structural testing)- tehnike: formal reviews, walkthrough, inspections.  Dynamic white box – vs. debugging. Pokrivanje: podataka, toka podataka, formula, grananja, uslova, ciklusa, TEHNIKA: forsiranje gresaka.

OBLASTI

 Po delovima (unit, integration, szstem, bottom-up, incremental, user interface)  Configuration – instalacija  Karakteristike: foreign language, usability, compatibility, documentation  Specijalne vrste softvera: website, mobile app

KARAKTERISTIKE KVALITETA DOBROG KORISNIČKOG INTERFEJSA

 Prati standarde i konvencije  Intuitivan  Konzistentan  Fleksibilan  Udoban (comfortable)  Korektan  Koristan 

TIPOVI TESTIRANJA:

 AD HOC  PRIMENOM METODA (black box, white box, static, dynamic)  BETA TESTIRANJE – dati softver na koriscenje i proveru manjem broju potencijalnih korisnika  AUTOMATIZACIJA TESTIRANJA

Tipovi testiranja u skladu sa V modelom, pokrivaju sve faze:

Izvor: John E. Bentley: Software Testing Fundamentals—Concepts, Roles, and Terminology

STRUKTURA TEST SLUČAJA:

 ID – oznaka TS  Test item – šta se testira, koji deo  Input specification – koji ulazi, koji uslovi pod kojim se testira  Output specification – očekivani rezultat ako je sve u redu  Environmental needs – potrebni uslovi za izvršavanje testiranja – hardver, softver, alati za testiranje, kadrovi  Specijalni proceduralni zahtevi

AKTUELNO:

AGILNI RAZVOJ SOFTVERA I TESTIRANJE SOFTVERA, PRINCIPI

DODATNI MATERIJAL:

1. Standardni process i dokumentacija: Department of Defense USA: Software development and documentation, 1994. 2. Struktura dokumenata:  Software requirements document: o Ian Sommervile: “Software requirements”, CS2 Software engineering note 2, 2004. o USA Department of Agriculture, System requirements specification o Karl E. Wiegers: Software requirements specification for project iTEST, 2002.  Software architecture o F. Bachmann et all: “Software Architecture documentation in practice: Documenting architectural layers, Carnegie Mellon Software engineering institute, 2000. o Primena UML 2.0 za prikaz arhitekture po slojevima, “Documenting a software architecture”  Project charter primer: “Waftlz Towers Rehabilitation – project charter”  Project management plan: o BAHRI TUREL, CELAL CIGIR, MUCAHID KUTLU, OMER FARUK UZAR: Project management plan “Job application management system” o Project plan – Minesota geospatial commons – test implementation. o SPISAK AKTIVNOSTI u planiranju redosleda razvoja softvera IZ MICROSOFT PROJECT alata, primer  User story – o Craig Brown: User story template o Keith Braithwaite, Richard Emerson, Immo Huneke: “Agile requirements by example”. Zhulke, 2009  Test Plan Template IEEE 829-1998 Format  Primer test slucajeva : Kaavya Kuppa: Test plan – Airline reservation System, Master thesis, Kansas State university. 3. Principi agilnog razvoja softvera: Elisabeth Hendrickson, “Agile testing, 9 principles and 6 concrete practices for testing on agile teams”, Quality Tree Software, 2008. 4. PRIJEM ZAHTEVA, RAZVOJ, TESTIRANJE I DOKUMENTOVANJE U PRAKSI – Primer firme YU TEAM SOFTWARE

PRIMERI IZ YU TEAM SOFTWARE

POSLOVI

ADMINISTRACIJA BOLOVANJE GODIŠNJI ODMOR INSTALACIJA IZMENE – INTERVENCIJA NA PODACIMA PO ZAHTEVU KORISNIKA (POMOĆ KORISNIKU) IZMENE - KOREKCIJE PO ZAHTEVU KORISNIKA IZMENE - NOVE FUNKCIONALNOSTI PO ZAHTEVU IZMENE - NOVE FUNKCIONALNOSTI U PROGRAMIMA IZMENE - NOVE FUNKCIONALNOSTI ZBOG IZMENE ZAKONA/PROPISA IZMENE - RAZDVAJANJE GODINE, POČETNA STANJA NOVO - MODUL POSTOJEĆE APP NOVO - NOVA APP FOX NOVO - RAZVOJ NOVIH APP C# NOVO - RAZVOJ NOVIH APP SQL OBUKA - NOV KORISNIK OBUKA - ZAPOSLENI YUTEAM OBUKA -PO ZAHTEVU KORISNIKA OTKLANJANJE GREŠKE - GARANCIJA OTKLANJANJE GREŠKE - GREŠKA KORISNIKA OTKLANJANJE GREŠKE - OPORAVAK BAZA PODATAKA PREZENTACIJA RAZNO SASTANAK TESTIRANJE - ODRAĐENI ZAHTEVI TESTIRANJE - PO ZAHTEVU KORISNIKA TESTIRANJE - RAZVOJ NOVIH APP

PREUZIMANJE ZAHTEVA KORISNIKA – interna aplikacija za upravljanje projektom I pracenje radnih zadataka

PRACENJE ZAHTEVA KORISNIKA - interna aplikacija za upravljanje projektom i pracenje radnih zadataka

GRAFIČKI PRIKAZ NEDELJNOG PLANA AKTIVNOSTI

RAZVOJ - TEAM FOUNDATION SERVER – OTVORENI TASKOVI

TESTIRANJE – TEAM FOUNDATION SERVER (FEEDBACK)

SA SLIKOM PROBLEMA i komentarom o gresci

VEZANI TASKOVI U ODNOSU NA PROBLEM

Povezano SQL Server baza podataka iz TFS sa bazom podataka interne aplikacije za pracenje realizacije projekta.

IZVEŠTAJ O URAĐENIM AKTIVNOSTIMA, radi fakturisanja klijentu

CAS 7

SOFTVERSKO INŽENJERSTVO 2 – ČAS 7  RAZVOJ SOFTVERA U DISTRIBUIRANOM OKRUŽENJU – LEKCIJE I PRIMERI

Дистрибуирани развој софтвера

Под термином дистрибуираног развоја софтвера подразумева се развој софтвера који реализују тимови који су дистрибуирани, односно најчешће географски удаљени. “Дистрибуирани развој софтвера (ДСД) омогућава члановима тима да буду смештени на различитим удаљеним местима у току животног циклуса софтвера и на тај начин формирају мрежу виртуалних тимова који раде на истим пројектима. Ти тимови могу бити чланови исте организације или може бити потребна сарадња или outsourcing од стране других организација. Дистрибуирани развој најчешће подразумева коришћење електронских технологија за комуникацију, првенствено Internet-a.

Као супротност дистрибуираном развоју јавља се колокацијски (collocated) развој, где се сви учесници у развоју налазе на истој локацији уз могућност непосредне личне комуникације [Kocaguneli et al, 2013].

Таксономија дистрибуције презентована је у [Gumm, 2006] кроз:

 Објекте дистрибуције (шта је дистрибуирано – људи, артефакти, задаци,итд.)  Типови дистрибуције (како је дистрибуција организована, димензије дистрибуције): o Физичка или географска дистрибуција (названа и “глобални развој софтвера” (ГСД) [Herbsleb&Moitra, 2001] o Организациона дистрибуција, o Временска дистрибуција, o Дистрибуција између група заинтересованих страна.

Кључни елемент дистрибуираног развоја је сарадња тимова која може бити класификована као колаборација, кооперација итд. Неколико аутора разликује више нивоа колаборације. Она се састоји из (a) информисања, (b) координације, (c) сарадње и (d) кооперације.

Неки типови организације у дистрибуираном развоју софтвера су:  Виртуални тимови – “састоје се из географски дистрибуираних сарадника повезаних путем информационих технологија како би реализовале организациони задатак” [Zhang et al, 2008]. “Виртуални тим се може описато као суштинска јединица која изграђује виртуалну организацију. Традиционални тим је дефинисан као друштвена група појединаца који се налазе на истој локацији и међусобно су повезани задацима, група узима и координира њихове активности како би се остварили заледнички циљеви и делила орговорност за резултате. Виртуални тимови имају исте циљеве и задатке као и традиционални тимови и интерагују кроз међусобно зависне задатке, али функционишу преко географских, временских и организационих граница. Често функционишу у мултикултуралном и мултијезичком окружењу; комуникација између чланова виртуалних тимова је уобичајено електронска и често асинхрона.” [Noll et al, 2010]  IT Outsourcing – “ је акт делегирања и преношења неких или свих права одлучивања, пословних процеса, интерних активности и услуга, која се односе на IT, екстерним обезбеђивачима, који развијају, управљају и администрирају своје активности у складу са договореним резултатима који треба да буду испоручени, у складу са стандардима перформанси и излаза, као што је дефинисано у уговору” [Dhar& Balakrishnan, 2006]. Велике IT компаније [Kommeren& Parviainen, 2007], као и мала и средња предузећа [Boden et al, 2007] укључују дистрибуирани развој софтвера ангажујући outsourcing тимове из других земаља.  Open Source развој софтвера (ОССД) – са неформалношћу комуникације и кооперације, где појединци и групе доприносе унапређењу заледничког производа унапређивањем појединачних особина. Они који доприносе унапређењу решења су истовремено и корисници и развијају га; њихове сугестије за унапређење нису формално записане као захтеви. [Mockus& Herbsleb, 2002]

Када су у питању ДСД пројекти, “рани резултати [Spinellis, 2006] упозорили су да такви пројекти могу да пате од нижег квалитета због географске дисперзије” [Kocaguneli et al, 2013]. Истраживање [Kocaguneli et al, 2013] је извршило проверу тврђења да ДСД утиче на квалитет софтвера и доказало је да ДСД приступ је одговарајући за коришћење у индустрији.

Постоје многе “познате” предности ДСД, међу којима су [Ågerfalk et al, 2008]:

 Уштеда трошкова,  Приступ великом броју расположиве радне снаге која је обучена и има одговарајућа знања и способности,  Смањено време производње и бржи излаз производа на тржиште (користећи различите временске зоне и радно време [Herbsleb&Moitra, 2001],  Близина тржишту и купцима, укључујући локална тржишта Неке „непознате“ предности ДСД, према [Ågerfalk et al, 2008] су:

 Организационе предности – a) иновација и дељење најбоље праксе, b) унапређена алокација ресурса,  Предности на нивоу тима – a) унапређење модуларизације задатака, b) смањени трошкови координације, c) унапређење аутономије тима,  Предности на нивоу процеса – a) формални запис о комуникацији, b) унапређена документација, c) јасно дефинисани процес.

OPEN SOURCE РАЗВОЈ СОФТВЕРА

Појам „open-source“ софтвера (ОSS) може се дефинисати као „софтвер за који корисници имају приступа изворном коду. То га разликује од уобичајене праксе од стране комерцијалних издавача софтвера који само достављају бинарне извршиве верзије софтвера. Већина ‘open source’ софтвера се такође дистрибуира без икаквих трошкова са ограниченим рестрикцијама како може бити коришћен, тако да се под појмом слободан или бесплатан у односу на ‘open source’ односи на два значења: 1) ослобођен од трошкова б) слободан да се са тим софтвером може радити шта год се пожели (тј. оно што је најважније – слободно се може читати, тј. приступати изворном коду програма).“ [Madey et al, 2002].

„Пројекти развоја „open-source“ софтвера базирају се на Internet- заснованим заједницама програмера (софтвер девелопера) који волонтерски сарађују како би развили софтвер који је потребан њима или њиховим организацијама.“ [Hippel&Krogh, 2003] Најчешће су корисници „open-source“ софтвера истовремено и учесници у његовом развоју. Покретачи новог софтвера, мотивисани својим потребама, најчешће касније постају и руководиоци пројеката развоја тог софтвера [Hippel&Krogh, 2003] [Gasser&Ripoche, 2003].

Основне карактеристике „open-source“ развоја софтвера су [Mockus et al, 2000]:

 OSS системе развија потенцијално велик број (стотине, хиљаде) волонтера  Радни задаци нису додељени, већ људи сами узимају да раде оно што изаберу  Нема експлицитног дизајна система или чак детаљног дизајна  Не постоји пројектни план, распоред рада или листа резултата који треба да буду испоручени, Према [10] основне карактеристике „open-source“ развоја софтвера су:  Главни доприноси долазе од учесника који нису плаћени  Висок ниво дистрибуције учесника у развоју  Слаба формализација у дизајну, планирању пројекта и менаџменту  Отворен изворни код и контрола и ревизија пројекта од стране заједнице

ПРИМЕРИ РЕАЛИЗОВАНИХ РЕШЕЊА

Неки од најпознатијих „open-source“ софтвера, алата и језика су [Madey et al, 2002] [Gasser&Ripoche, 2003]:

 Web browser (Mozilla)  Web server (Apache, iPlanet/Netscape)  E-Mail server (Sendmail)  Оперативни систем (Linux, BSDUnix).  Алати за рад у канцеларији (OpenOffice - рад са текстуалним документима, унакрсним табелама, презентацијама)  Програмских Језици (Perl, Java, Python, GCC, Tk/TCL). У емпиријским истраживањима [Emanuel et al, 2011], успешним „open-source“ софвером сматра се софтвер који има више од 100.000,00 преузимања („download“) од стране корисника.

Неке од предности „open-source“ развоја софтвера [Wahyudin &Tjoa, 2007] [Raymond, 1999]:

 Брзи развој и масивни провера/ревизија (massive peer review)  Флексибилност у коришћењу и изменама изворног кода ради интереса корисника  Развој ниског нивоа трошкова и трансфера технологије  Наслеђивање развоја (Developer inheritance) и коришћење референци имплементације које помажу креирању стандарда.

ИСКУСТВА ДИСТРИБУИРАНОГ РАЗВОЈА ИЗ ИТ ИНДУСТРИЈЕ

Искуства „оutsourcing“ предузећа

Истраживања која су се вршила у IT индустрији превасходно су се вршила у оквиру великих IT компанија која раде „оutsourcing“ у оквиру других земаља, као што је фирма Alcatel [Ebert&De Neve, 2001], IBM [Sengupta et al, 2006], Siemens [Herbsleb et al, 2005] и Philips [Kommeren& Parviainen, 2007]. Мањи број истраживања односи се на емпиријска истраживања дистрибуираног развоја софтвера у оквиру малих и средњих предузећа [Jiménez et al, 2010], у појединачним земљама - у Финској [Paasivaara et al, 2009] [Komi-Sirvio&Tihinen, 2005] и у више других земаља [Herbsleb&Mockus, 2003] [Heeks et al, 2001].

У наставку ће бити детаљно приказана искуства из фирме Alcatel [Ebert&De Neve, 2001]. Иако је превасходно компанија која се бави телекомуникацијама, у укупном развојном буџету фирме Alcatel, чак 80-90% се односи на развој софтвера. Развој софтвера у овој фирми се одвија по тимовима у укупно 15 земаља. Ефикасност рада и квалитет комбинују се са трошковима локација на којима се одвија развој, тако да се део развоја одвија у источној Европи и Индији. Истовремено се реализује више пројеката на најчешће 2 или више локација истовремено. Ранија релативна независност појединачних развојних локација замењена је глобалним управљањем производним линијама. Нека од практичних искустава у овој фирми и савети како боље организовати посао у глобалном развоју софтвера су заснована на научним истраживањима у оквиру ове компаније. Резултати у виду закључака су дати у наставку:

 Креирати кохерентне колокацијске тимове који су потпуно радно алоцирани, а не виртуалне тимове. То значи да посао треба поделити у јасно одвојене модуле (кохезија) при чему сваки модул ради један тим. Тимови могу бити на различитим географским локацијама, али у оквиру истог тима људе организовати да на истом модулу раде тако што су физички смештени у истој згради (колокација) и да раде само посао на једном пројекту (радна алокација), а не на више пројеката истовремено.  Одлуке о архитектури целог система, ревизије кључних тачака и тестирање ради се на једној локацији (централно).  Радне улоге су: језгро компетенције (архитектура система, ревизицја, главне одлуке), инжењерство (развојни део функционалности), услуге (документовање, одржавање).  Јасно дефинисаним и договореним терминима почетка и завршетка посла, дефинисаним квалитетом и трошковима, садржај се развија итеративно, континуираном производњом резултата.  Треба разликовати као посебне пројекте развој нових функција од корекција грешака у постојећим решењима.  Јасна дефиниција одговорности сваког појединца за успех целог пројекта захтева детљан пројектни план са јасно дефинисаним потребним знањима, трајањем активности, функцијама које се развијају, дефинисањем тимова и итерација развоја.  Обука и менторство (coaching) над младим и неискусним кадровима унапређује квалитет будућег решења и потребно је да буде присутно и организовано.  Развој орјентисан на карактеристике, а не на архитектуру (feature-oriented development) - већа интеграција унутар тима и орјентација на испуњавање функционалних целина пројекта, као и орјентација на циљеве пројекта и допринос пројекту – дизајнер остаје укључен у пројекат и прати га до фазе тестирања, тестер учествује у дизајну, јер мора се и тестабилност решења уградити у сам дизајн...На овај начин су смањени време израде и трошкови.  Укључивање јасно дефинисаних глобалних производних линија, односно фамилија производа који могу да деле дизајн и имплементацију – дефинишу се основни производи, који се касније прилагођавају појединачним тржиштима. Разликују се: 1) независни модули који не подлежу кастомизацији, 2) језгро производа које ако се мења, утиче на све остале производе, 3) специфични модули за појединачне локалне потребе корисника. Настојање да варијанти основног производа буде што мање, како би се лакше управљало променама.  Потреба за алатима за представљање и синхронизацију промена у производним линијама. Реализовано је интранет решење, које даје свим учесницима увид у: фазе и успешност реализације пројекта, фазе развојног процеса, елементе и особине производа који се реализује.  Инкрементални развој – повезати захтеве са функционалностима, повезати модуле у шири контекст интерфејса ка другим модулима и проценити њихову међузависност, дефинисати пројектни план, доделити један инкремент једном тиму (често реализује и више узастопних инкремента), посебне линије тестирања,  Заједнички развојни процес, методологија и терминологија. Битна је размена свесности (информисаности о стању), комуникација и размена знања. Креиран је заједнички „on-line web“ базирани систем за представљање пројеката, документације и процеса.  Организациона култура запослених - спремност на промене. Ниво организационог квалитета CMM ниво 2 је минимум који омогућује успешну реализацију пројеката, уз настојање повећања CMM нивоа.

Конкретна упутства и савети из искустава фирме Alcatel у организацији пројекта [Ebert&De Neve, 2001]:

 Договором дефинисати и комуницирати на почетку пројекта у вези циљева пројекта, као што су квалитет, тачке провере („milestones“), садржај или алокација ресурса.  Постарати се да задужења појединаца и тимова постоје у писаној и контролисаној форми.  Одредити вођу пројекта који је потпуно одговоран а остваривање циљева пројекта и одредити његов тим за управљање пројектом, који представља носиоца културе у оквиру пројекта.  У оквиру сваког пројекта пратити континуирано 10 највећих ризика, који су најчешће у глобалним пројектима мање техничке, а више организационе природе.  На почетку пројекта одредити који су тимови укључени и шта ће они радити на свакој локацији.  Припремити web страницу пројекта која сумарно приказује садржај пројекта, метрике напретка, информације о планирању и информације специфичне за сваки тим.  Обезбедити интерактивни модел процеса базиран на прихваћеној најбољој пракси, која омогућава извршавање процеса за специфичне потребе пројекта или тима.  Строго подстицати реализацију производних линија, користећи усвојен стандардни процес развоја, који се односи на CMM ниво 3 организације.  Обезбедити довољно комуникационих начина, као што је видеоконференсинг или дељена радна окружења и гловалне софтверске библиотеке.  Строго подстицати управљање конфигурацијом и правила управљања изградњом решења (нпр. у гранању, спајању и синхронизацији, фреквенцији), обезбедити одговарајућу подршку алата.  Ротирати чланове менаџмента кроз разне локације и културе како би се креирала потребна свесност културних разлика и како да се усклађује са њима.  Креирати тимове људи из различитих држава како би се интегрисала индивидуална културна наслеђа и усмерило ка организационом и пројектно-орјентисаном духу.  Учинити да су тимови у потпуности одговорни за своје резултате.

Емпиријска истраживања „оpen source“ развоја софтвера

Проблеми „open-source“ развоја софтвера представљени су кроз низ емпиријских истраживања која се односе на појединачне аспекте:

1. Аспект друштвеног умрежавања учесника у „open-source“ развоју, описан кроз теорију друштвених мрежа, базирану на теорији графова [Madey et al, 2002] [Crowston&Howison, 2003]

2. Aспект дистрибуираности у колективној пракси и одговарајућих приступа и метода за успешну реализацију [Gasser&Ripoche, 2003]

3. Иновација у интеграцији приватно и јавно мотивисаних активности учесника у развоју „open-source“ софтвера [Hippel&Krogh, 2003]

4. Мотивација учесника „open-source“ развоја софтвера и њихова ефикасност у оквиру иновативних активности и доприноса [Kogut&Metiu, 2001]

5. Фактори успеха и метрике успеха „open-source“ пројеката развоја софтвера, а посебно које се односе на метрике, које се односе на модуларност „open- source“ софтвера [Emanuel et al, 2011]

6. Координација активности у оквиру „open-source“ развоја софтвера и предности у односу на традиционални развој софтвера [Mockus& Herbsleb, 2002]

7. Размена знања у оквиру „open-source“ развоја софтвера [Sowe et al, 2009]

Посебно је детаљно описан конкретан „open-source“ развој Apache Servera [Mockus et al, 2000], уз илустрацију процеса, проблема и решења проблема у развоју. Емпиријско истраживање засновано је на хипотезама које су потврђене у складу са подацима који се односе на процес развоја Apache Servera. Развој Apache Servera почела је 1995. године, када је група од 8 програмера удружила снаге како би унапредила раније започет пројекат NCSA организације. Даље укључивање нових чланова реализовано је гласањем постојећих чланова. Такође, гласање је коришћено и приликом укључивања измена у постојећем програмском коду. Да би се неки нови члан прикључио тиму, морао је најпре дати допринос у пробном периоду од најмање 6 месеци. „Активности у развоју укључивале су проналажење проблема, утврђивање да ли ће волонтер радити на решавању проблема, идентификација решења, развијање и тестирање кода локално, презентовање промена кода језгру тима AG ради ревизије, слање кода и документације у репозиторијум. Овај процес се некад одвија у више итерација, али се настоји да промене које су потребне да би се решио појединачни проблем буду извршене у једној итерацији“ [Mockus et al, 2000]. У оквиру рада AG групе и волонтера који су кандидати за чланове групе, коришћени су разни алати за координацију рада: BUGDB – за евидентирање проблема, USENET newsgroup – за размену новости. Искуства из развоја Apache Servera указују на следеће потврде почетних хипотеза, а које говоре о условима за успешност OSS пројеката:

1. У развоју ОSS софтвера, језгро од 10-15 људи развија око 80% процената софтвера.

2. Уколико је софтвер сложен и не може његов развој бити управљан и реализован од стране 10-15 људи, креирају се помоћни пројекти са одговарајућим језгром учесника.

3. Језгро тима развија нове функције софтвера, али нема довољно времена да се бави утврђивањем и поправком грешака. То треба да раде учесници из шире групе волонтера, који не припадају језгру.

4. У оквиру OSS развоја, програмери који учествују у развоју су најчешће и искусни корисници истих софтверских решења и доменски експерти, тако да лако могу да дефинишу захтеве и проблеме, а одмах и да их реше. Из тог разлога, број грешака (густина грешака) у OSS развоју софтвера је мања, у односу на комерцијалне софтвере. Такође, из тог разлога и поправке и нове верзије софтвера су много брже доступне корисницима.

PROBLEMI DISTRIBUIRANOG RAZVOJA SOFTVERA

РЕФEРЕНЦА ДСД ПРОБЛЕМИ

Организација виртуелног тима (кооперативни, [Gorton&Motwani, делегацијски и консултативни модел) 1996] комуникације у тиму, процес развоја софтвера, додељивање задатака

Расположивост ресурса, различита инфраструктура, различита експертиза у [Herbsleb&Moitra, различитим технологијама, стратешки 2001] проблеми (подела посла на локације, координација), отпор због страха (губитак посла, смањење контроле, потреба за пресељењем и честим путовањима), проблеми културе (однос према хијерархији, стил комуникације), неадекватна комуникација (формална – довољно прецизна и свеобухватна, неформална – да буде на располагању), управљање знањем, управљање информисањем (документовање, обавештавање, истицање рокова, проблема, потребног знања), недостатак синхронизације, пројектни и процес менаџмент, нестабилне спецификације и захтеви, недостатак добрих алата за комуникацију, контрола промена и верзија софтвера, технички проблеми (споре и непоуздане мреже, усклађеност верзија алата, компатибилност формата података)

Удаљеност, колаборација, координација, [Carmel&Agarwal, контрола, културне удаљености, језичке 2001] баријере, временска удаљеност

Језик, културне баријере, кохерентност, колокација, алокације, радне улоге (језгро [Ebert&De Neve, компетенције, инжењерство, услуге), обука, 2001] менторство, конкурентно инжењерство, развој орјентисан на особине, управљање променама, инкрементални развој, CMMI нивои

Ризици IT outsourcing - фактори: људи (различите способности, искуства), Знање (Функционално, технолошко, управљачко), Културни, Политички, Финансијски (Рачуноводствени стандарди, варијација курсне листе), Стандарди квалитета, Стандарди мерења перформанси, Обухват, трошкови, процена времена, Различите [Dhar&Balakrishnan, компаније из страних земаља имају различити начин 2006] управљања и суштинске компетенције, Правни уговори и стандарди интелектуалног власништва, Безбедност – заштита и контрола података, Опоравак од катастрофа, Управљање уговарањем (формулисање уговора, планирање распореда, планирање активности, слање и прихватање испорука, одјава).

Неадекватна комуникација, посебно [Sengupta et al, неформална, културне разлике, стратегијски 2006] проблеми, процес, технички проблеми, управљање знањем, погрешно разумевање захтева, договор око корисничког интерфејса, географска дисперзија, проблеми временских зона, културне и организационе разлике, кључни индикатори перформанси, CMM нивои

Мање фреквентна комуникација, мање ефективна комуникација, временске разлике, друштвено-језичке разлике, географска удаљеност, непознавање задужења и [Herbsleb, 2007] експертизе, некомпатибилност алата, знања, процеса, радних навика и културе, софтверска архитектура, дефинисање захтева, развојна окружења и алати, организација

Географска удаљеност: недостатак неформалне комуникације, погрешно разумевање, измене захтева; Временска удаљеност: временске зоне, [Ågerfalk et al, 2008] кашњење одговора (feedback), различито радно време; Социо-културне разлике: Природа процеса развоја софтвера, језик, недостатак фамилијарности, недостатак поверења

Људски ресурси, организационо управљање, комуникација чланова тима, инфраструктура, усклађеност са организацијом, управљање [Jiménez et al, 2009] пројектом, усклађеност са стандардима, управљање конфигурацијом, тестирање, управљање знањем, контрола процеса, групна свесност, координација, колаборација, подршка процесу, квалитет, мерење

Комуникација, управљање конфигурацијом, управљање знањем, Управљање квалитетом, [Jiménez et al, 2010] управљање ризиком, управљање пројектом, подршка процесу, координација, колаборација

Географска, временска, културна и језичка удаљеност, дељење знања, способности, [Noll et al, 2010] организација, процес, управљање, страх и поверење, инфраструктура, архитектура производа

[Kocaguneli et al, Квалитет софтверског производа, комуникација, 2013] координација, организација, стратегије развоја

KLASIFIKACIJA PROBLEMA

КЛАСА ПРОБЛЕМ ПРОБЛЕМА Управљање Дистрибуирано управљање софтверским пројектима софтверским Перформансе пројекта пројектима Управљање Стратешки приступи Делегација лидерства, ефикасност лидерства Управљање конфликтима Процена трошкова Управљање ризицима Артикулација рада Алокација задатака Koнтрола Управљање непрецизношћу (неизвесношћу) Eфикасност и ефективност Организациони Програмирање у пару облици Виртуални тимови Мала и средња предузећа Велике мултинационалне компаније Психолошки Групна свесност аспекти и Друштвене везе тимски рад Фамилијарност Компјутерски подржан тимски рад Ментални модели Когнитивна дивергенција

Поверење Прилагођавање тимском раду Колаборација Улога вође Различитост индивидуа Управљање Управљање знањем знањем Дељење знања Координација експертизе Ток размене знања Путујући тимови знања Оперативно и стратегијско учење Комуникације Комуникације Комуникационе везе Удаљеност Брзина Размена задатака Језик комуникације Координација Преговарање Временске зоне Координација развојног и тест тима Култура Конвергенција Култура и знање Kултурне разлике Утицај идеологије Квалитет Квалитет софтвера Перформансе успеха Метрике успеха Метрике комуникације Методологија Спецификација захтева развоја Агилни приступ софтвера SCRUM Агилни vs. структурни приступи Покривеност фаза развоја софтвера Правни Open source & free software аспекти Области Колаборативни дизајн примене Развој инф. система Објектно орјентисани развој

ANALIZA PROBLEMA U ODNOSU NA DIMENZIJE RAZVOJA SOFTVERA (SE) I UPRAVLJANJE PROJEKTIMA (PM)

Резултати примене SE-PM матрице сумарним приказом броја радова који разматрају одговајућу групу ДСД проблема

SE – PM Column Id

matrics

G D summar H

Row ID

der

Risk

Time

ment

Scope

ication

Human Human

Quality

Procure

Resourc

Stakehol

Commun Integrati 1 Requiremen 2 ts

2 Design 1 2

3 Constructio 1 n

4 Testing 1 2

5 Maintainanc 1 1 e

6 Configurati 1 1 1 5 2 on Managemen t

7 Engineering 7 5 3 2 10 10 8 2 2 Managemen t

8 Engineering 1 1 1 6 Process

9 Engineering Models and Methods

10 Quality 3 4 4

11 Engineering 1 1 Economics

АЛАТИ ЗА ПОДРШКУ ДИСТРИБУИРАНОМ РАЗВОЈУ СОФТВЕРА

Развојна окружења за софтверско инжењерство предмет су истраживања и стандардизације (нпр. стандард ISO/IEC 15940:2006 Information Technology—Software Engineering Environment Services). У оквиру дистрибуираног развоја софтвера, посебно су унапређена постојећа и креирана нова развојна окружења која треба да омогуће тимски рад у развоју софтвера у дистрибуираном окружењу.

Kолаборативна развојна окружења и алати за подршку тимском раду у дистрибуираном развоју софтвера

Проблеми дистрибуираности не морају да се односе само на географску дистрибуцију, већ и у оквиру исте локације могу наступити због тимског рада у условима смањених могућности непосредне комуникације. [Herbsleb&Moitra, 2001] Идеални услови за рад би омогућили „да локације максимално независно функционишу, уз једноставну, флексибилну и ефективну комуникацију између локација“ [Herbsleb&Moitra, 2001].

Решавање проблема дистрибуираног развоја софтвера од стране универзитетске заједнице и софтверских фирми резултовао је у креирању различитих софтверских алата који пружају подршку појединим аспектима у дистрибуираном развоју софтвера, a првенствено повећању квалитета комуникације у тимском раду. Такви алати припадају категорији Groupware и Task Manager софтвера. Специфичност алата за подршку колаборативном развоју софтвера огледа се у потребним карактеристикама. Ови специфични алати треба да омогуће [Sengupta et al, 2006]:

 Да учврсте колаборацију у дистрибуираном развоју,  Управљање апликационим знањем, како би се олакшала миграција, очување и размена знања у вези апликације  Омогућавање тестирање софтвера у дистрибуираном окружењу, нпр. тестирање јединица на удаљеним локацијама где тест подаци не могу бити директно доступни због приватности података и проблема са репликацијом  Олакшавање интеграције модула који су развијени на различитим локацијама и редукција грешака интеграције  Подршка проблемима процеса и метрика, која треба да омогући да се утврди које методологије развоја да се користе, који подаци и метрике да се прикупљају када је развој дистрибуиран,  Подршка свим фазама развоја софтвера (спецификација захтева корисника, дизајн, кодирање, тестирање)

„Kолаборативнo развојнo окружењe („Collaborative development environment“-CDE систем) је виртуални простор где учесници пројекта, често раздвојени временом и простором, могу да се сусретну, размењују и деле, дискутују, преговарају, меморишу и генерално раде заједно како би извели до краја неки задатак, најчешће да креирају неки користан артифакт и његове пратеће објекте.„ [Booch&Brown, 2002] Према [Booch&Brown, 2002], разлика између колаборативног рада у другим областима и у развоју софтвера се разликује првенствено по тиме што учесници колаборативног развоја софтвера морају манипулисати семантички дубоким артифактима који су веома семантички дубоко повезани, а такође и по томе што су учесници софтверског развоја природно везани за Internet технологије, чиме се лакше прелази са физичке на виртуалну колокацију. Према [Booch&Brown, 2002] разлика између IDE (Integrated Development Environment) и CDE (Collaborative development environment“) je што је IDE примарно орјентисан на девелопера и њему потребну подршку, док је CDE есенцијално орјентисан на подршку потребама тима: интеракција, комуникација, координација...

Кључне карактеристике које CDE систем треба да има и да омогући су, према [Booch&Brown, 2002], приказане на слици 2.1.3.1.

Карактеристике система за подршку колаборацији, према Booch&Brown [Booch&Brown, 2002]

Специфичне потребе у тимском раду у оквиру дистрибуираног развоја софтвера захтевају подршку више различитих софтверских алата или њиховој интеграцији за подршку размени и интеграцији развојних ресурса, подршку тимском раду и подршку управљању пројектима. Концептуални модел таквог интегралног система представљен је на слици 2.1.3.2.

Development resources

Team tools

Project workspaces

Слика 2.1.3.2. Кључни део концептуалног модела CDE (Collaborative development environment) система, према Booch&Brown [Booch&Brown, 2002]

Технолошка решења у области подршке колаборативном раду обухватају [Dustdar, 2004]:

 Groupware системе, тј. подршку тимском раду, а првенствено комуникацијама у тиму (instant messaging,… [Booch&Brown, 2002])  Системе за подршку управљању знањем  Документ менаџмент системе  Системе за подршку пројектном менаџменту (пројектни web сајтови [Booch&Brown, 2002])  Системе за подршку радним токовима (укључујући и тзв. Таsk manager, Event notification server и Issue Tracking тип софтверских алата [Booch&Brown, 2002]).

ПРИМЕРИ АЛАТА

У наставку ће бити дат приказ неких од софтверских алата који су креирани ради подршке тимском раду у дистрибуираном развоју софтвера, као и њихових карактеристика:

 Складишта и праћење промена изворног кода [Froehlich&Dourish, 2004], као што су нпр. системи: o CVS (Concurent Versions System) [Cederqvist, 2006] - софтверски алат који поред складиштења изворног кода омогућава управљање конфигурацијом и подршку тимском раду, где је могуће бележити ко је мењао програмски код o Subversion [Pilato et al, 2004] o Microsoft SourceSafe и Тeam Foundation Server  Software configuration management системи [Mahapatra& Das, 2012] [Booch&Brown, 2002]  Дељење екрана [Cheng, 2004] – софтверски алат, као што је VNC (Virtual Newtork Computing) омогућава увид у радни екран другог члана тима  Посебни правци развоја укључују проширења развојних окружења функцијама које омогућавају подршку тимском раду, као што је мoдул Jazz као проширење Eclipse IDE развојног окружења [Cheng, 2004] .  Подршка размени порука (е-Mail и IM – instant messanger) такође може бити интегрисана у оквиру развојног окружења [Cheng, 2004] .  Размена мултимедије у окружењу видео-конференција (аудио и видео синхронизација), систем CAIRO базиран на технологији агената [Pena-Mora et al, 2000]  Процесно-орјентисани (process aware) систем CARAMBA [Dustdar, 2004] је објектно орјентисани систем који подржава workflow management са елементима управљања знањем, заснован на Јава технологији и релационим базама података, вишеслојне архитектуре.  Aлати за подршку континуираној координацији [Redmiles et al, 2007] – базирани су на мониторингу рада у развојном окружењу (нпр. систем Palantir – nad Eclipse развојним окружењем), који користе Event Notification Server( нпр.систем YANCEES [Redmiles et al, 2007]) за размену података о утврђеним променама које је мониторинг софтвер утврдио. Такође, посебни алати визуално представљају и социо-технолошке везе између учесника у дистрибуираном развоју (нпр. систем Ariadne који се такође надовезује на Eclipse развојно окружење [Redmiles et al, 2007]).  Web базирани системи за размену података у оквиру једног пројекта који омогућава праћење дневних промена и испорука, mailing листе, праћење грешака, огласне табле за обавештења и форуме, архивирање фајлова, бекап фајлова и администрацију, нпр: [Google Code], [Git Hub], [Launch Pad]  Koмбинована развојна окружења, где се локално на рачунару инсталира софтверски алат за контролу изворног кода, а путем web апликације реализује се регистрација корисника, пројеката и централна комуникациона локација пројеката. Један од таквих комбинованих система користи се за развој open-source ”R (GNU-S) система” , а то је систем R- Forge [Theußl& Zeileis, 2009], базиран на Subversion клијентском систему.

Постоји много комерцијално доступних софтверских пакета, намењених подршци управљању пројектима. Овакви системи омогућавају [Jurison, 1999]:

 Планирање и моделовање („Front-end planning and modeling“) – омогућавају креирање иницијалног плана и прецизирање евалуацијом алтернативних планова. Већина програма укључује методе PERT, анализу критичног пута и обезбеђује преглед и планирање коришћења ресурса  Праћење трошкова и временског плана („Cost and schedule tracking“) – прикупљање података о трошковима и о статусу и праћење статуса у односу на план.  Креирање извештаја – припрема извештаја о напретку у различитим формама, укључујући и извештаје и изузецима, гантограме, коришћење ресурса, податке о добијеној вредности (earned value) и трендовима. Већина алата омогућава корисницима да креирају темплејте и подешавају извештаје.  Комуникација – додељивање задатака и добијање података о промени статуса, размена података о пројекту  Управљање вишепројектним радом – одређивање међузависности између различитих пројеката, креирање вишепројектних извештаја и омогућавање да менаџери одреде утицај појединачних пројеката на пословање.

Опис софтверских функција и карактеристика алата који су према анкети, најчешће коришћени у управљању софтверским пројектима у дистрибуираном окружењу дат је у наставку.

9.8.1. Општи алати за управљање пројектима

Алат „Active Collab“ [activecollab] - могућност инсталирања (Desktop апликација), чување података у cloud-у, могућност вођење евиденције за више пројеката у исто време, могућност проширења могућности (updates); функционалне могућности: филтрирање података, календар, дискусије са више учесника, колаборативно писање, израчунавање времена проведеног у раду на пројекту, наплате, процена трошкова.

Слика 9.8.1.1. Радно окружење алата „Аctive Collab“

Алат „Basecamp“ [basecamp]- web апликација која снима податке у cloud-у, подршка за мобилне уређаје, функционалне могућности: е-маил, комуникација учесника пројекта, опис пројекта, додавање фајлова, дискусије, календар, колаборативно писање, чување и приказ мултимедијалних фајлова

Слика 9.8.1.2. Радно окружење алата „Basecamp“

Алат „dotProject (или dP)“ [dotproject]– web апликација уз могућност инсталирања целе web апликације на серверу за хостинг, имплементиран користећи PHP/MYSQL, проширив (могућност додавања модула за језике и теме - графички стилови, измена икона, додатни модули за форум, гантограме), функције: аутоматско слање е-маила, управљање корисницима, управљање тикетима, управљање клијентима, листинг таскова, архива фајлова, листа контаката, календар, дискусиони форуми

Слика 9.8.1.3. Радно окружење алата „dotProject“

9.8.2. Алати за управљање софтверским пројектима

Алат „GForge Advanced Server“ [gforge] [gforge inria] [gforge group]– инсталира се као VMWare виртуална машина или као посебна инсталација, потребан је Linux оперативни систем, а може се и користити хостинг. Проширив ради омогућавања интероперабилности, тј. 1) комуницирање система са развојним окружењима: Visual Studio, Eclipse, Jenkins и Microsoft Project.; 2) експорт података у MS Excel i XML формат. Најновија верзија подржава агилну методологију, односно подврсте као што је Kanban. Функционалне могућности: праћење задатака, грешака, пројектни менаџмент, управљање документима, дискусиони форум, wiki, контролу изворног кода, анализу података и графички приказ, мониторинг процеса, управљање фајловима, вестима, задацима, форум, извештаји, chat, размену фајлова, праћење промена (tracker) и филтрирање података. Добијање обавештења и технике „спомињања“ („mentions“).

Слика 9.8.2.1. Радно окружење алата „GForge Advanced Server“

Алат „JIRA“ [jira] – фунционалне могућности: анализа података и приказ за одлучивање (dashboards), евиденција пројеката, евиденција проблема и грешака, подршка агилном приступу (SCRUM, Kanban), повезивање са тестирањем, графички приказ радног тока (workflow) са могућношћу дефинисања сопствених радних токова и активности, претрага података, интероперабилност, тј. повезаност са развојним окружењима и алатима (BitBucket, Bamboo), претрага и филтрирање података (JIRA query language JQL).

Слика 9.8.2.2. Радно окружење алата „JIRA“ – додавање активности и материјала

Слика 9.8.2.3. Радно окружење алата „JIRA“ – дефинисање радног тока, примена Jquery језика и подршка за Kanban

Алат „RedMine“ и „easyRedMine“ [redmine] [easyredmine]– креиран у технологији Ruby on Rails Framework, подржава инсталацију или хостинг, омогућава додатне модуле (plugins), измена графичког дизајна избором теме (боје и организација опција екрана). Функционалне могућности: рад са више пројеката истовремено, флексибилна контрола приступа у зависности од радних улога, садржи систем праћења проблема (issue tracking system), интегрише управљање вестима, документима и фајловима, омогућава нотификације о променама путем е-маила и web feed, за сваки појединачни пројекат омогућује wiki и форуме, праћење времена, прилагодљив дизајн и дефинисање потребних података за евиденцију проблема, временских података, пројеката и корисника, омогућава интеграцију са другим системима за развој, праћење промена софтвера и репозиторијуме кода (SVN, CVS,Git, Mercurial, Bazaar and Darcs), омогућава аутентификацију и саморегистрацију корисника, омогућава подршку за 34 говорна језика, даје могућност коришћења различитих база података. Додатни модули: – Управљање ресурсима, Управљање буџетом и финансијско извештавање, Наплата, Help desk, CRM, агилни прегледи. Управљање ресурсима – задавање радних задатака, планирање рада, евидентирање присуства на послу. Агилни приступи – Kanban, Scrum. Имплементиран је концепт базе знања (прикупљање знања из разних елемената управљања пројектима, сортирање, приказ). Реализована је подршка за гантограме, календар, временске листе (time sheets - дневне евиденције рада на пројектима). Реализован је систем за рано упозоравање о потенцијалном ризику неуспеха пројекта. Реализован је модул за подршку друштвеној мрежи (слично као Facebook). Омогућава дизајн радних токова дефинисањем низа активности. Омогућава креирање формула за израчунавање вредности на основу других вредности (слично као MS Excel). Омогућава интероперабилност, тј. повезивање са другим апликацијама и сервисима користећи REST API.

Слика 9.8.2.4. Радно окружење алата „easy Redmine“ – агилна табла

Слика 9.8.2.5. Радно окружење алата „easy Redmine“ –временски план и граф прогреса

Алат „Microsoft Team Foundation Server (или алтернативно Visual Studio Online)“ –[tfs vstudio] [fts overview] проширење уз MS Visual Studio, намењен за подршку комплетном животном циклусу развоја софтвера у оквиру MS Visual Studio. Функционалне могућности:контрола верзија изворног кода и извршних верзија централизовано (Team Foundation Version Control) или дистрибуирано (Git), подршка за агилне методологије и радне токове, омогућава преузимање готових темплејта који се односе на радне токове. Омогућава проналажење грешака раније у току развоја и интеграцију. Подржава web базирано тестирање. Омогућава креирање извештаја и графикона о напретку рада. Интегрисан је са другим алатима за развој – Eclipse, GIT. Повезивање са другим апликацијама и сервисима користећи REST API. Омогућава евидентирање и обавештавање о догађајима, евидентирање података о раду, креирање извештаја и анализу података, управљање захтевима. Омогућава телеметрију, тј. мерење перформанси, коришћења и доступности имплементиране апликације. Модул Монако омогућава директно програмирање апликација користећи Web browser или мобилни уређај. Омогућава експорт података и интеграцију са MS Office фајловима - MS Excel, MS PowerPoint, MS Project.

Слика 9.8.2.6. Радно окружење „Microsoft Team Foundation Server/VS Online“

9.8.3. Алат за комуникацију и подршку тимском раду

Алат „TeamViewer“ [teamviewer] – омогућава евиденцију корисника и група, управљање конекцијама и сесијама приступа и приступ удаљеном рачунару, размену података и састанке у дистрибуираном окружењу. Омогућава интеграцију са другим алатима помоћу REST API.

Слика 9.8.3.1. Радно окружење алата „Team Viewer“

9.8.4. Подаци из бенчмаркинг анализе

У наставку је дат приказ основних питања за анализу и алата који су вредновани на основу датих питања. Посебно су обележена питања где одговарајући алат има имплементирану подршку.

Табела 9.8.4.1. Анализа карактеристика издвојених алата путем анкете, применом бенчмаркинг модела

ОБ КАРАКТЕ Acti Basec dotPr GFo Ji RedM Micros TeamVi ЛА РИСТИКА ve amp oject rge ra ine oft ewer СТ Coll Team ab Found ation Server PMB Интеропер Да Да Д Да Да Да OK абилност а са другим алатима, посебно развојним окружењи ма и различити м форматим а фајлова? експорт Да Да Да Да података? PMB Приказ Д Да Да OK дефиниса а Да Да ног Д Да Да обухвата а потребних Д софтверск а их функција? Измене обухвата потребних софтверск их функција? Приказ реализова ног обухвата потребних софтверск их функција? PMB Процену и Да Да Да Да Д Да Да OK планирањ Да Да Да Да а Да Да е времена Д реализаци а је? Приказ временски х карактери стика тока реализаци је? PMB Мерење - - OK квалитета Да Да људи – Да Да учесника Да Да пројекта? Мерење квалитета тима у учешћу пројекта? Мерење квалитета резултата? Мерење квалитета тока резултата процеса? PMB Евиденциј Да Да Да Да Д Да Да OK у Да Да Да Да а Да Да учесника Да Да Да Да Д Да Да пројекта? а Евиденциј Д у а реализова ног рада? Персонали зацију функција за различите профиле корисника у односу на различите улоге у реализаци ји пројекта? PMB Размену Да Да Да Да Д Да Да Да OK фајлова Да Да Да Да а Да Да Да између Д учесника? а Комуници рање – размену порука, идеја, питања? PMB Евидентир Да OK ање Да ризика? Да Мерење ризика? Приказ ризика? PMB Унапређе Да Да Д Да Да OK ње а постојећег решења додатним модулима? PMB Комуникац Да Да Да Да Д Да Да Да OK ију са а заинтерес ованим странама? PMBOK: 8 9 9 11 13 20 17 5 Max=21 SW Евиденциј Да Д Да Да EBO у захтева? Да а Да Да K Евидентир Да Д Да Да ање а промене Д захтева? а Праћење и приказ промена захтева? Евидентир ање степена усклађено сти решења са захтевима ? SW Интеграци Да Д Да EBO ју са а K алатима за дизајн система? SW Интеграци Да Д Да Да EBO ју са а K алатима за развој? SW Интеграци Да Д Да EBO ју са а K алатима за тестирање ? SW Приказ Да Да Да Да Д Да Да EBO тока а Да Да K процеса реализаци је? Мерење успеха фазе или тока реализаци је? SW Примену Да Д Да Да EBO различити а Да Да K х приступа Д и а методолог ија управљањ а пројектим а? Примену различити х приступа и методолог ија развоја софтвера? SW Мерење Да Да EBO квалитета Да Да K резултата? Мерење квалитета тока резултата процеса? SWEBOK: 1 1 1 8 9 10 12 0 Max=13 BSC Финансијс Да Да ки Да показатељ и успеха фазе или процеса? Финансијс ки показатељ и успеха производа ? BSC Комуникац Да Да Да Да Д Да Да Да ију са Да Да а Да Да корисници Да ма? Да Креирање извештаја ? Мерење задовољст ва корисника ? Евидентир ање потреба и захтева корисника ? BSC Приказ Да Да Да Д Да Да тока а Да Да процеса? Д Да Да Планирањ а е тока Д процеса? а Мерење успеха тока процеса? BSC Евиденциј - - Да у и приказ Да Д Да искустава а ? Евидентир ање и приказ проблема и одговора? BSC: 3 2 2 4 5 9 7 1 max=10 УКУПНО: 12 12 12 23 2 39 36 6 max=44 7

CAS 8

ODRŽAVANJE SOFTVERA

DEFINICIJA “The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment” • 40-90% of the software life cycle cost

Osnovne faze razvoja softvera:

Uloga odrzavanja u celom zivotnom ciklusu softvera:

TIPOVI ODRZAVANJA:

Faze razvoja i elementi održavanja:

Grupe aktivnosti u odrŽavanju softvera (izvor: Alain April, Jane Huffman Hayes, Alain Abran, and Reiner Dumke: Software Maintenance Maturity Model (SMmm): The software maintenance process model)

(izvor: http://www.klariti.com/technical-writing/2011/08/26/software- maintenance-plan/) There are two sides to Software Maintenance Plans – management and technical. . Management issues include aligning with customer priorities, resources, setting up maintenance teams, and costs. . Technical issues include impact analysis, testing, maintainability measurement.

Software Maintenance planing includes ten activities: 1. Preparation – Describe software preparation and transition activities including the conception and creation of the maintenance plan; describe how to handle problems identified during development and configuration management. 2. Modification – After the application has become the responsibility of the maintenance team, explain how to analyze each request; confirm and check validity; investigate and propose solutions; document the proposal and get the required authorizations to apply the modifications. 3. Implementation – Describe the process for considering the implementationof the modification itself. 4. Acceptance – Describe how the modification is accepted by the maintenance team. 5. Migration – Describe any migration tasks that need to be executed. If the software needs to be moved to another system, outline the steps to do so without impacting its functionality. 6. Transition – Document the sequence of activities to transition the system from Development to Maintenance. 7. Service Level Agreements – Document SLAs and maintenance contracts negotiated by Maintenance. 8. Change Request – Outline the problem-handling process to prioritize, documents and route change and maintenance requests. 9. Modification Request acceptance/rejection – Describe the request including details of the size/effort/complexity. If this is too complex to resolve, outline the steps to route the issue back to the software team. 10.Retirement – This is the final stage in the lifecycle. Describe how to retire the software and the steps to archive any data that may be a by-product of the system.

MODELI ODRZAVANJA SOFTVERA:  QUICK – FIX – je ad-hoc pristup, čekanje da problem nastupi i korekcija  Boemov model 1983, GODINE– zasnovan na ekonomskim principima (cost- benefit analiza zahteva za izmenama, izmene su povezane sa resursima koji su potrebni za realizaciju)

 OZBORNOV MODEL – zasniva se na mogućnosti da sve nije idealno, tj. da nisu na raspolaganju svi potrebni podaci, dokumentacija i specifikacije, vec se iterativno realizuje odrzavanje, omogucavajuci pojedinim segmentima da budu izmenjeni.

 Iterativni model unapređenja softvera – iterativni razvoj softvera uz nedovoljno jasne specifikacije koje se novim iteracijama razjasnjavaju I detaljnije opisuju, svaka iteracije radi UPDATE svih dokumenata I svih artefakta (REQUIREMENTS, DESIGN, CODING, TESTING).

 Reuse-oriented model – u okviru održavanja naglasak je na korišćenju gotovih komponenti, tj. prerađivanje starog dela softvera radi ponovnog korišćenja.

SERVICE LEVEL AGREEMENT (SLA) (izvor: https://www.paloaltonetworks.com/cyberpedia/what-is-a-service-level- agreement-sla) A service level agreement (SLA) is a contract between a service provider (either internal or external) and the end user that defines the level of service expected from the service provider. SLAs are output-based in that their purpose is specifically to define what the customer will receive. SLAs do not define how the service itself is provided or delivered. The SLA an Internet Service Provider (ISP) will provide its customers is a basic example of an SLA from an external service provider. The metrics that define levels of service for an ISP should aim to guarantee:  A description of the service being provided– maintenance of areas such as network connectivity, domain name servers, dynamic host configuration protocol servers  Reliability – when the service is available (percentage uptime) and the limits outages can be expected to stay within  Responsiveness – the punctuality of services to be performed in response to requests and scheduled service dates  Procedure for reporting problems – who can be contacted, how problems will be reported, procedure for escalation, and what other steps are taken to resolve the problem efficiently  Monitoring and reporting service level – who will monitor performance, what data will be collected and how often as well as how much access the customer is given to performance statistics  Consequences for not meeting service obligations – may include credit or reimbursement to customers, or enabling the customer to terminate the relationship.  Escape clauses or constraints – circumstances under which the level of service promised does not apply. An example could be an exemption from meeting uptime requirements in circumstance that floods, fires or other hazardous situations damage the ISP’s equipment. Though the exact metrics for each SLA vary depending on the service provider, the areas covered are uniform: volume and quality of work (including precision and accuracy), speed, responsiveness, and efficiency. In covering these areas, the document aims to establish a mutual understanding of services, areas prioritized, responsibilities, guarantees, and warranties provided by the service provider. The level of service definitions should be specific and measureable in each area. This allows the quality of service to be benchmarked and, if stipulated by the agreement, rewarded or penalized accordingly. An SLA will commonly use technical definitions that quantify the level of service such as mean time between failures (MTBF) or mean time to recovery, response, or resolution (MTTR), which specifies a “target” (average) or “minimum” value for service level performance. SLAs are also very popular among internal departments in larger organizations. For example, the use of a SLA by an IT helpdesk with other departments (the customer) allows their performance to be defined and benchmarked. The use of SLAs is also common in outsourcing, cloud computing, and other areas where the responsibility of an organization is transferred out to another supplier.

REINŽENJERING SOFTVERA

Reinženjering – izmene softvera tako da ima drugačiju strukturu

(izvor: http://www.cs.toronto.edu/~yijun/ece450h/handouts/lecture2.pdf)

UPRAVLJANJE KONFIGURACIJOM SOFTVERA

DEFINICIJA (izvor: https://www.techopedia.com/definition/24583/software-configuration- management-scm)

Software configuration management (SCM) is a software engineering discipline consisting of standard processes and techniques often used by organizations to manage the changes introduced to its software products. SCM helps in identifying individual elements and configurations, tracking changes, and version selection, control, and baselining.

SCM is also known as software control management. SCM aims to control changes introduced to large complex software systems through reliable version selection and version control.

PRAĆENJE VERZIJA SOFTVERA (Version control softver)

ALATI ZA PRAĆENJE VERZIJA SOFTVERA POSTOJI NEKOLIKO MODELA:  Model sa lokalnim podacima - In the local-only approach, all developers must use the same file system.  Klijent-server model - In the client-server model, developers use a shared single repository.  DISTRIBUIRANI MODEL - each developer works directly with his or her own local repository, and changes are shared between repositories as a separate step.

PRIMERI ALATA: Local data model *********************** Open source ------ Revision Control System (RCS) – stores the latest version and backward deltas for fastest access to the trunk tip[1][2] compared to SCCS and an improved user interface,[3] at the cost of slow branch tip access and missing support for included/excluded deltas.  Source Code Control System (SCCS) – part of UNIX; based on interleaved deltas, can construct versions as arbitrary sets of revisions. Extracting an arbitrary version takes essentially the same time and is thus more useful in environments that rely heavily on branching and merging with multiple "current" and identical versions.

Client-server model *********************** Open source ------ Concurrent Versions System (CVS) – originally built on RCS, licensed under the GPL.  CVSNT – cross-platform port of CVS that allows case insensitive file names among other changes  OpenCVS – CVS clone under the BSD license, with emphasis put on security and source code correctness  Subversion (SVN) – versioning control system inspired by CVS[4]  Vesta – build system with a versioning file system and support for distributed repositories

Proprietary ------ Filesentral – GUI based version control aimed primarily at the non - programmers demographic  AccuRev – source configuration management tool with integrated issue tracking based on "Streams" that efficiently manages parallel and global development; replication server is also available  Autodesk Vault – Version control tool specifically designed for Autodesk applications managing the complex relationships between design files such as AutoCAD and Autodesk Inventor.  CADES - Designer productivity and version control system by International Computers Limited.  Dimensions CM - software change and configuration management system developed by Serena Software that includes revision control.  IBM Rational ClearCase – SCC compliant configuration management system by IBM Rational Software  IBM Configuration Management Version Control (CMVC) – version control system, no longer available.  IBM Rational Team Concert – Collaboration and application lifecycle management platform by IBM Rational Software  IC Manage Global Design Platform (GDP) – design data management for IC design and Perforce infrastructure support.  PTC Integrity (Formerly MKS Integrity).  Panvalet - Around since the 1970s, source and object control for IBM mainframe computers.  Perforce Helix – Free for up to 5 users.  PVCS – originally Polytron Version Control System, developed by Don Kinzer at Polytron, first released in 1985. Now owned by Serena.  Quma Version Control System  Razor (configuration management), integrated suite from Visible Systems  StarTeam – coordinates and manages software delivery process by Micro Focus, formerly Borland; centralized control of digital assets and activities  Surround SCM – version control tool by Seapine Software.  Team Foundation Server (TFS) - Development software by Microsoft which includes revision control.  Visual Studio Team Services (VSTS) - Services for teams to share code, track work, and ship software for any language by Microsoft  IBM Rational Synergy – SCC compliant integrated change management and task-based configuration management system, proprietary of IBM.  Vault – version control tool by SourceGear (First installation can be used for free)  Visual SourceSafe – version control tool by Microsoft; oriented toward small teams  TeamWork – version control tool by DBmaestro; oriented to DBMs

Distributed model ****************** Open source ------ ArX – written by Walter Landry, started as a fork of GNU arch, but has been completely rewritten  Bazaar – written in Python, originally by Martin Pool and sponsored by Canonical; decentralised, and aims to be fast and easy to use; can losslessly import Arch archives  BitKeeper – was used in Linux kernel development (2002 – April 2005) until it's license was revoked for breach of contract. It was open-sourced in 2016 in an attempt to broaden its appeal again.  Codeville – written in Python originally by Ross Cohen; uses an innovative merging algorithm  Darcs – written in Haskell and originally developed by David Roundy; can keep track of inter-patch dependencies and automatically rearrange and "cherry-pick" them using a "theory of patches"  DCVS – decentralized and CVS-based  Fossil – written by D. Richard Hipp for SQLite; distributed revision control, wiki, and bug-tracking (all-in-one solution) with console and web interfaces. Single portable executable and single repository file.  Git – written in a collection of Perl, C, and various shell scripts, designed by Linus Torvalds based on the needs of the Linux kernel project; decentralized, and aims to be fast, flexible, and robust  GNU arch  Mercurial – written in Python as an Open Source replacement to BitKeeper; decentralized and aims to be fast, lightweight, portable, and easy to use  Monotone – developed by the Monotone Team; decentralized in a peer-to- peer way  SVK – written in Perl by Kao Chia-liang; built on top of Subversion to allow distributed commits  Veracity - Is another distributed version control system which includes bug tracking and Agile software development tools integrated with the version control features.

Proprietary ------ Code Co-op – peer-to-peer version control system (can use e-mail for synchronization)  Sun WorkShop TeamWare – designed[citation needed] by Larry McVoy, creator of BitKeeper  Plastic SCM – by Codice Software, Inc  Visual Studio Team Services - Services for teams to share code, track work, and ship software for any language by Microsoft

DODATNI MATERIJAL IZ PDF – Basic concepts of software maintenance, CECAM Lyon February2008 – The Maintenance Process

2001.

Bureau of Standards, Special Publication 500-106, 1983. Alan W. Brown: A Case study in Software Maintenance, Technical report CMU/SEI-93-TR-8, Jun 1993. -Peter Halvorsen, Software Maintenance, slajdovi Maintenance Maturity Model: The software maintenance process model.

CAS 9

SOFTVERSKO INŽENJERSTVO 2 – predavanja, čas 9

SADRŽAJ:

• MODELOVANJE SOFTVERA PRIMENOM UML - PONAVLJANJE

• ISTORIJAT OBJEKTNO-ORJENTISANOG PRISTUPA

• OSNOVNI POJMOVI OBJEKTNO-ORJENTISANOG PROGRAMIRANJA

• OSNOVNI PRINCIPI OBJEKTNO-ORJENTISANOG PROGRAMIRANJA

• HEURISTIČKA UPUTSTVA PRAVILNOG DIZAJNA OBJEKTNO-

ORJENTISANOG SOFTVERA

• DIZAJN PRINCIPI OBJEKTNO-ORJENTISANOG PROGRAMIRANJA

• REUSABILITY PROGRAMSKOG KODA

IZVOR: Ivanković, Lacmanović: Udžbenik Softversko inženjerstvo 2, TFZR

PONAVLJANJE 1. MODELOVANJE SOFTVERA PRIMENOM UML – ponavljanje različiih vrsta dijagrama i vrsta veza na dijagramu klasa 2. Osnovni koncepti objektno-orjentisanog programiranja

ISTORIJAT OBJEKTNO-ORJENTISANOG PRISTUPA

Objektno-orjentisani pristup razvoju softvera proizašao je iz tzv. “softverske krize”, koja je posebno došla do izražaja kod velikih i složenih softverskih sistema realizovanih strukturnim pristupom (algoritamskim načinom razmišljanja). Termin “SOFTVERSKA KRIZA” prvi put se javio na Nato konferenciji 1968. godine “Software crisis” manifestuje se kroz: • troškovi veći od planiranih (“cost overruns”) • nezadovoljstvo korisnika finalnim proizvodom • pun grešaka (“buggy”) software • nepouzdan (lako puca, “brittle”) software. IZVOR: Carl Erickson: OBJECT-ORIENTED PROGRAMMING, Atomic Object LLC, 2009.

Alan Kay, dobitnik je Turing nagrade za kreiranje objektno-orjentisanog programiranja, On je postavio temelje današnjeg pristupa Object Orientation ranih 70-tih. Ideja je uključena u jezik Smalltalk koji je imao klase, višestruke instance klasa i razmenu poruka između objekata klasa. Dodavanje mogućnosti Smalltalk programa odnosio se na dodavanje novih klasa biblioteci klasa.

Osnovne ideje objektno-orjentisanog pristupa imaju korene u: - programskom jeziku Simula 67, koji omogućuje “multiple processes to talk to each other via message passing. Some people think that Simula 67 is the first Object Oriented language. Simula 67 didn't have Classes.” - pojavama realnog sveta- “children who would put together new things by combining existing objects”. - Alan Kay je studirao biologiju i uvideo da ćelije, kao samostalne jedinice, komuniciraju sa drugim ćelijama putem razmene hemijskih poruka. IZVOR: https://www.quora.com/Who-invented-Object-Oriented-Programming-OOP- and-what-was-the-motivation-and-inspiration - Kako čovek “izlazi na kraj” sa kompleksnošću : o koristi apstrakciju, tj. odbacivanje nebitnih detalja i fokusiranje na suštinu. o Hijerarhijsko uređenje koncepata o Dekompozicija – podela složenog sistema na manje delove, jer ako neki manji deo ne funkcioniše, to neće mnogo uticati na celinu i lakše se zameni ili koriguje, a takođe, lakše se podeli posao oko razvoja. o Odlaganje odluka – prerano odlučivanje može da dovede do grešaka. o Postepeno uvođenje detalja. IZVOR: Carl Erickson: OBJECT-ORIENTED PROGRAMMING, Atomic Object LLC, 2009.

Osnovni ciljevi OO pristupa • Smanjenje troškova • Povećanje kvaliteta Postiže se pomoću: • Bolje organizacije koda- modularizacija, bolje razumevanje (enkapsulacija) • Ponovna iskoristivost proverenog koda – reusability koda (pomoću nasleđivanja, polimorfizma) • Bolje organizacije procesa razvoja – timski rad (modularizacijom)

OSNOVNI POJMOVI

OBJEKTNO-ORJENTISANOG PROGRAMIRANJA

IZVOR: Carl Erickson: OBJECT-ORIENTED PROGRAMMING, Atomic Object LLC, 2009.

Osnovni pojam-klasa (Booch): “A class is a set of objects that share a common structure and a common behavior” • The responsibilities that an object has to its clients are key to defining the class that an object belongs to. • Classes are (mostly) static. They define the capabilities or behavior of an object. Classes in an OOD may be abstract representations of real things, or useful abstractions for solving our problem which don’t have a real-world analog. • Objects are living, breathing, dynamic entities. They get work done. We create them, often at runtime. A synonym for object is instance.

ELEMENTI KLASE: • Atribut • Property • Konstruktor • Metode MODIFIKATORI PRISTUPA: • PRIVATE • PUBLIC • PROTECTED

TIPOVI KLASA: • Osnovna klasa • Statička klasa – ne instancira se, ne nasleđuje se, ne sadrži konstruktor, sadrži samo statičke elemente • Sealed klasa – ne može biti nasleđena • Partial klasa – delovi klase mogu biti implementirani u više fajlova • Apstraktna klasa – ne može se instancirati, mora se naslediti I izvedene klase implementiraju ono što je dato u apstraktnoj klasi. Sadrži samo definicije. • Interfejs – Opisuje ugovor koji govori šta treba implementirati I sadrži samo prototipove metoda, propertija I događaja. Konkretne klase implementiraju sve elemente interfejsa. Omogućuje višestruko nasleđivanje tako što konkretna klasa može da implementira više interfejsa. • Generička klasa – opšta klasa kojoj nisu definisani tipovi podataka do trenutka dok se ne deklariše I instancira u okviru klijentskog koda.

Objects The active elements of an OO program. Objects are of a definite type (their class, and possibly some other interface) and have two parts: what they know (attributes) and what they can do (behavior). They occupy memory, they get work done, they have a unique id. Classes The templates from which objects can be instantiated. The definition of the class determines what objects of that class can know and do. Classes themselves are passive (compared to objects at least, and if you ignore class members). Encapsulation The idea that an object encapsulates knowledge and behavior. We control what outsiders may see with access control. Generally, the internal state of an object is hidden from other objects. The algorithms used in the definition of the class methods are hidden by the class. Includes the idea of containment as an essential relationship between classes. Inheritance Classes may be related to each other in an inheritance hierarchy. Top level, abstract classes tend not to be instantiated into active, living, breathing objects. They serve to gather together the common attributes and behavior which their concrete subclasses inherit. Messaging Messages are what gets work done in an OO system. There are four parts to a message: a receiver object, a method name, optional method arguments, and an optional return value. Identity Objects must have a unique identity which is required to send an object a message. Pointers give us aliases for the unique names of objects. Polymorphism The idea that the code that is executed as the result of a message being sent depends on the class of the object that receives the message. Objects of different classes can react differently to being sent the same method in a message. Type What determines the capabilities or behavior of a thing, such as an object. Distinct from, but often confused with, class. Type is equivalent to the interface of a class. Programming to types, not classes, maintains flexibility.

Osnovne aktivnosti: - Objektno-orjentisana analiza – predstavljanje problemskog domena putem klasa i objekata - Objektno-orjentisan dizajn – kreiranje logičkih-fizičkih i statičkih-dinamičkih modela na osnovu kojih se kreira softverski sistem - Objektno-orjentisano programiranje- kreiranje programa sa karakteristikama: „Programs are organized as collections of cooperative, dynamic objects, each of which is an instance of some class. The classes may be organized into a hierarchy formed from inheritance relationships.“

OSNOVNI PRINCIPI OBJEKTNO-ORJENTISANOG PROGRAMIRANJA

TRI NAJVAŽNIJA PRINCIPA OOP: - Enkapsulacija – skrivanje detalja implementacije, fokusiranje na mogućnosti koje pruža korisnicima - Nasleđivanje – hijerarhijsko uređenje klasa, postepenim dodavanjem detalja i mogućnosti, uz mogućnost redefinisanja načina implementacije i funkcionisanja - Polimorfizam – mogućnost da se metode ili svojstva ponašaju različito u zavisnosti od konkretnog objekta ili parametra ili okolnosti.

IZVOR slike i daljeg teksta: Carl Erickson: OBJECT-ORIENTED PROGRAMMING, Atomic Object LLC, 2009.

An abstraction is a simplified description of a system which captures the essential elements of that system (from the perspective of the needs of the modeler) while suppressing all other elements. The boundary of the abstraction must be well- defined so that other abstractions may rely on it. This cooperation between abstractions relies on the contract of responsibilities that an abstraction provides. This relationship is sometimes called client and server. The protocol of a server is the set of services it provides to clients and the order in which they may be invoked.

Apstrakcija se realizuje kroz izdvajanje: • INTERFACE- This is the outside view of the class. The part visible by everybody (or at least any object who has the name of an object from this class). • IMPLEMENTATION - This is the actual code that implements the behavior of the class. Objects are asked to do things in messages which include the name of one of the member functions.

Objekat - What an object knows (state) and what it can do (behavior) are determined by its classification (which class instantiates). Identity is required so that we may talk to an object without confusing it with another object, and so that we may have more than one object of a given class alive at the same time. • Identitet - Identity is the property of a thing which distinguishes it from all other objects. Humans have id numbers,fingerprints, DNA profiles. All these are representations of the fact that we are each unique and identifiable. • Stanje objekta - State is the set of values that an object encapsulates. It is a set of properties, or variables (usually static) which can take different values at different times in the objects life (dynamic). Since objects have state, their reaction to messages can vary depending on when the messages are sent, and what order they are sent in. • Ponašanje (BEHAVIOR) - This is the set of actions that an object knows how to take, named: member functions, better name is methods. In general, we can group the methods of a class into five categories: • Modifier - Change the state of the object • Selector - Accesses, but does not change the state • Iterator - Operates across all parts of an object • Constructor - Creates an object and initializes its state • Destructor - Frees the state and destroys the object cleanly

Poruke- Messaging is how work gets done in an OO system. A message has four parts: • identity of the recipient object • code to be executed by the recipient • arguments for the code • return value The code to be executed by an object when it is sent a message is known variously as a method, or a function. Method is preferable. Messaging an object may cause it to change state.

U zavisnosti od načina kako se razmenjuju poruke (aktivno ili pasivno) razlikujemo objekte: • Actor - poziva metode drugih objekata, ali njegove metode nisu nikad pozvane da on nešto izvrši (Operates on other objects, but is never operated upon). • Server – Njegove metode se pozivaju od strane drugih objekata da nešto izvrši, ali on nikad ne poziva druge objekte da nešto izvrše (Server is operated on by other objects, but never operates on other objects). • Agent – Istovremeno je actor i server.

Izvor – izmenjena verzija sa: IZVOR: Carl Erickson: OBJECT-ORIENTED PROGRAMMING, Atomic Object LLC, 2009.

Important to remember that the decisions concerning modularity are more physical issues, whereas the encapsulation of abstractions are logical issues of design.

ENKAPSULACIJA - We encapsulate the details of a class inside its private part so that it is impossible (and not just suggested) for any of the class’s clients to know about or depend upon these details. The ability to change the representation of an abstraction (data structures, algorithms) without disturbing any of its clients is the essential benefit of encapsulation.

MODULARIZACIJA - Modularity is closely tied with encapsulation; think of modularity as a way of mapping encapsulated abstractions into real, physical modules. Booch gives two goals for defining modules. Make a module cohesive (shared data structures, similar classes) with an interface that allows for minimal inter-module coupling. • INTERNA POVEZANOST - KOHEZIJA (High Cohesion) – Potrebno je da bude velika interna povezanost na nivou modula • EKSTERNA POVEZANOST (Low coupling) – Potrebno je da bude mala povezanost između modula, kako bi posebne komponente upravljale njihovim povezivanjem i na taj način se postiže fleksibilnost sistema.

HIJERARHIJSKO UREĐENJE KLASA – razlikujemo 2 tipa: • IS-A - As we form the class hierarchy we push the common state and behavior between lower level classes into the upper level classes. This allows for the lower level classes (which are usually “discovered” first in an OOA) to be built on top of the higher level classes, thus making them smaller and more readily understandable. This activity (pushing commonality up the inheritance hierarchy) makes for a generalization/specialization hierarchy. The classes at the top are more general (or abstract) and the classes at the bottom are more specific (or concrete). It is usually the concrete classes that we instantiate objects from. Abstract classes are simply that; abstract means of organizing shared information. Forming the hierarchy eliminates redundant code and organizes our abstractions into something easier to understand. The “isa” hierarchy is a compile-time hierarchy, in that it involves classes extending other classes. • Part-of - The other type of hierarchy is the “part of” hierarchy we find in our designs. This is hierarchy through aggregation. Objects would be overly large if it was not possible to aggregate them. The “has-a” hierarchy is another means of code organization. The “has-a” hierarchy is a run-time hierarchy, in that it involves objects containing other objects.

KONKURETNOST – istovremeno paralelno izvršavanje koda SINHRONIZACIJA – usklađivanje paralelnog izvršavanje koda, koja može biti: • Sequential – semantics of object are guaranteed only for one thread at a time (aka not thread safe) • Guarded – semantics of the object are guaranteed only if the threads coordinate with each other (i.e. synchronization is outside the object) • Synchronous – object guarantees its semantics by doing its own guarding.

CRC KARTE - ODGOVORNOST I POVEZANOST KLASA Class / Responsibilities / Collaborators (CRC) cards are a simple representation of the classes in an OO system. You write the name of the class at the top of the card. On the left half of the card you write the responsibilities (which cover the class attributes via “knowing…”) and on the rights side you write the collaborations (other classes) for this class.

NASLEĐIVANJE When we use inheritance, we have classes at the top of the hierarchy that are known variously as: Generalization Parent Superclass Base Abstract And classes at the bottom of the hierarchy (or those which inherit from some other class) known variously as: Specialization Child Subclass Derived Concrete

Prednosti nasleđivanja: • Avoid redundant code by sharing it (coupling?) between classes, Inheritance relationships let us avoid the redundancy of declaring the same instance variables and behavior in a group of related classes. • Enforcing standards at a design level (interfaces) • Programming-by-drag-and-drop (components) • Avoid redundant code by sharing it between projects (reuse)  Shared code allows for rapid prototyping via reuse.  Shared code produces greater reliability via greater use (and hence discovery of errors). • Substitution of code - When objects of class X can be substituted for objects of class Y with no observable effects, we say class Y is substitutable for class X.

Nedostaci nasleđivanja: • Increased class/abstraction coupling- What is more coupled than super/sub classes? Coupling is bad. So inheritance is bad? • Performance- The more general a body of code (class hierarchy) is, the less likely it is the optimal performance, solution for any given specific problem- Overblown, Experts versus novices, and class maturity. • Program size- Using large class hierarchies makes your project bigger, Dealing with the run-time dispatch of messages to objects related in an inheritance hierarchy has memory overhead. • Understanding a large system (the yo-yo problem, class documentation) - Inheritance means that it is not sufficient to study the header file (declaration) of a class to completely understand its behavior. You often must look up the hierarchy and consider the inherited behavior and state from its superclasses. On a practical note, this can be a pain for documentation, since you may not find he behavior you seek in the document for the class itself. Class browsers address this problem.

POLIMORFIZAM - When something (function argument, variable, etc) can be of more than one type. The goal of a language that supports polymorphism is to let us specify and reuse our algorithms or design. Polymorphism is necessary for the sort of higher level reuse which is the goal of design patterns and frameworks.

PREDNOST POLIMORFIZMA reusability of higher level abstractions. The higher we can push reuse, the better (more reliable) and cheaper (faster, greater reuse) our projects will be.

OBLICI POLIMORFIZMA; • BINDING - When is the method that is invoked by a message determined? If it is at compile-time (static binding) then you lose a lot of flexibility. If it is at run-time (dynamic binding) then you have polymorphism, or the ability for each object to react differently to the same message. • ČIST POLIMOFIZAM- “pure” polymorphism refers to a function which can take parameters of many types. This occurs as a natural result of the is a relationship. Subclasses which are subtypes are substitutable for their base classes. Clients can’t tell the difference and don’t care. A piece of code can be written in terms of what is common to all the objects (i.e. the interface of the base class). With polymorphism we can write out function abstractly and have it work with a variety of types, including those not yet dreamed of. Primer:

• Overriding - This sort of polymorphism supports the inheritance of specialization and extension. A subclass implements a different version, or extends the existing version, of a base class method. The method name is the same, but subtypes implement it differently. This is distinct from overloading because of the type relationship between the overriding classes. • Deferred methods - This sort of polymorphism supports the inheritance of specification. A method may have no implementation – it could be just an interface specification. Subclasses are required to implement such methods, but in the meantime, clients can be written in terms of the abstract method without worrying about how each subclass implements the method. • Generics - Container classes provide the best example of the use of generics, or parameterized classes. The behavior common to container classes representing common data structures (queues, stacks, lists, etc) is completely independent (at the high level) of the particular data type being stored in the container. One solution is to build a very generic container that will hold objects of any type. But what you lose with this approach is the safety of having the compiler type check your code. What you want are type-safe containers, where the container is code is written in terms of a generic type, but the container class can be created with a specific type and the compiler will check with this specific type. • Overloading - The name of the function (within the same class) is polymorphic. The compiler uses the type (and possibly the number) of parameters to distinguish between multiple functions with the same name.

HEURISTIČKA UPUTSTVA PRAVILNOG DIZAJNA OBJEKTNO-ORJENTISANOG SOFTVERA IZVOR: Carl Erickson: OBJECT-ORIENTED PROGRAMMING, Atomic Object LLC, 2009.

THE QUALITY OF CLASSES AND OO DESIGN

Class quality Object oriented analysis, design, and implementation are an iterative process. It is usually impossible to fully and correctly design the classes of an OO system at the outset of a project.

Booch proposes five metrics to measure the quality of classes: • Coupling • Cohesion • Sufficiency • Completeness • Primitiveness

Coupling How closely do classes rely on each other? Inheritance makes for strong coupling (generally a bad thing) but takes advantage of the re-use of an abstraction (generally a good thing). Cohesion How tied together are the state and behavior of a class? Does the abstraction model a cohesive, related, integrated thing in the problem space? Sufficiency Does the class capture enough of the details of the thing being modeled to be useful? Completeness Does the class capture all of the useful behavior of the thing being modeled to be re-usable? What about future users (reusers) of the class? How much more time does it take to provide completeness? Is it worth it? Primitive Do all the behaviors of the class satisfy the condition that they can only be implemented by accessing the state of the class directly? If a method can be written strictly in terms of other methods in the class, it isn’t primitive. Primitive classes are smaller, easier to understand, with less coupling between methods, and are more likely to be reused. If you try to do too much in the class, then you’re likely to make it difficult to use for other designers. Sometimes issues of efficiency or interface ease-of-use will suggest you violate the general recommendation of making a class primitive. For example, you might provide a general method with many arguments to cover all possible uses, and a simplified method without arguments for the common case. The truism “Make the common case fast” holds, but in this case “fast” means “easy”. Easy may violate primitive.

RELATIONSHIPS BETWEEN CLASSES The Law of Demeter provides a useful guideline: The methods of a class should not depend on the structure of other classes. A class should communicate with as few other classes as possible. Applying this law results in loosely coupled classes.

Class inheritance hierarchy shape The shape of the class hiearchy may be: Wide and shallow o Classes are loosely coupled; some commonality may be redundantly implemented.

Narrow and deep o Classes are smaller, but are more tightly coupled to their parent classes.

There is no single “right” shape. This is very problem dependent. Don’t expect to see one shape or another in your projects; you may be disappointed.

PITFALLS IN CLASS DESIGN These are adapted from Bruce Webster’s book.

Confusing class relationships Isa, Has-a, Association are all different and must be applied properly confusing interface inheritance with implementation inheritance As a base class, do you want your derived classes to inherit: An interface and implementation (normal class function) An interface and default implementation (virtual class function) An interface only (pure virtual function)

Mis-using inheritance Not everyone thinks inheritance is a necessary part of OO. Potential problem of coupling; lets a subclass get into the guts of a base class. Some specific things to watch out for: Using MI to turn the is-a hierarchy upside down by creating a general class out of two more specific classes. (e.g. Clock, Calendar, ClockCalendar) Using MI without restrictions, or a clear understanding of OO ideas Functionality of base classes – too much or too little Base classes which do to little may: o have no public or protected interface (i.e. they impose no protocol) o have no implementation (i.e. they are only a protocol) o have subclasses which do too much (duplicated code in subclasses) Base classes which do too much: o Offer an implementation that is mostly overridden by derived classes

Base class invariants Base classes have assumptions built into them about their state, pre and post conditions, relationships between ivars, timing, invocation of methods, etc. Since a derived class “is-a” base class, the same invariants must hold true. But these invariants aren’t necessarily visible from the header, or even sometimes from the implementation file, so it is easy for the designer of the derived class to mess up the invariants she inherits. Documentation and review are the keys.

Class bloat A class becomes unwieldy at some point: too many ivars, too much functionality. This can happen over time, and may indicate the need to split the class via inheritance or aggregation, or simply other classes. “Swiss Army Knife” classes are a special case of bloat. Too much functionality unrelated to the abstraction can creep into the class. When it does, people will rely on it, then you’re stuck.

Finding classes/objects All classes show up as nouns in a functional description of the project. This is too simple. Some classes are obvious, have corresponding physical entities in the problem domain. Others are less obvious and are “discovered” or invented during analysis/design. Gamma says these sort are key to making designs flexible. Many of the objects in the pattern catalog are of this type. This is why it’s important to know the catalog.

QUALITY OO DESIGN

Type versus class A type is an interface. An interface is a collection of methods which an object responds to. Different kinds of objects may share the same type. An object can have many types. An object’s implementation is defined by its class. The class tells you about the state an object maintains. It also tells you how an object implements the methods in its interface. Class inheritance is a means of sharing implementation (both state and behavior) between classes. Interface inheritance (subtyping) only specifies when one object can be used in place of another. The distinction is important because it is the type of an object that is important to flexible design. Interface is everything in good design; type is interface. Designing with an interface in mind (rather than an implementation) helps because: Clients remain unaware (hence decoupled) of the specific kinds of objects they use. Clients remain unaware of the classes of the objects they use. They just know the interfaces.

These points together describe what Gamma calls the first “principle of OO design”...  Program to an interface, not an implementation.

Variables should not be concrete classes. Rather, they should be to abstract classes that just specify an interface. There are creational patterns for instantiating objects of concrete classes (since you have to get work done somewhere) while remaining unaware of their class.

Inheritance and composition Class inheritance is great for implemenation re-use. But it goes against the general goal of decoupled classes. It’s also a static, compile-time relationship. This makes it easier to understand and program to, but less flexible. Composition (aka association) is another means of achieving re-use. Put an object inside another object and the first object can re-use the code behind the composed object. The difference is that the composed object can be determined at run-time. The only stipulation is that the composed object must be of the proper type (not class). If you view composition as an alternative to inheritance then you can in effect change the inheritance or class of an object at run-time. In C++ we can make a useful distinction between aggregation and composition (aka association). Aggregation is done by value (life times the same between whole/part). Composition is done by reference (reference or pointer, lifetimes de-coupled) so that the object being referred to can change at run-time.

Gamma’s second principle of good OOdesign is to: Favor object composition over class inheritance. Systems that follow this rule have fewer classes and more objects. Their power is in the ways that the objects can interact with each other. It would be important to have good dynamic models.

Delegation Delegation is an important design pattern itself. It’s used a lot in Objective C and NEXTSTEP programming as an alternative to mandatory inheritance from a complex framework and multiple inheritance. If B is a subclass of A then sending B a message for something in A’s interface means that B can re-use the implementation found in A. Delegation uses composition to put re-use the implementation from A. B’s interface can be extended to have some of the same functionality of A. But when a B object is sent a message corresponding to a method in A’s type, it forwards the message to an A object. The aggregation design we saw earlier for implementing a Set in terms of a List is an example of the use of delegation.

Static vs Dynamic Structure Some things are apparent from the static structure and models of a system (e.g. inheritance, aggregation). An executing OO program is a network of messaging objects. The objects come and go. The message patterns shift. The relationships vary over time. Little of this is apparent from the static models of the system. The dynamic models (object diagrams, etc.) are crucial for understanding this behavior. If the dynamic behavior relationships have been created in the form of well-known patterns then they will be that much easier to document and understand. For the distinction between the static and dynamic elements of a system, consider an aquarium. What would you know about how an aquarium looks, behaves, captivates, rots, etc, by examining a description of the separate parts (tank, filter, rocks, fish, food, etc)? Now imagine how rich and complicated the interactions of the various components of an aquarium are. Think of what the pieces give rise to.

Design for Change

Here’s how patterns address change that can otherwise force re-design: 1. Creating an object by specifying a class explicitly. 2. Specifying one particular operation. 3. Limit the spread of platform dependencies. Helps in porting and maintenance to isolate particulars of the GUI or OS. 4. Knowing how an object is represented, stored, located or implemented. Some of this is naturally avoided by encapsulation. But you can take this further to de-couple classes, as in a Distributed Objects NXProxy. (Graph, Node, List example) 5. Algorithmic dependencies. Encapsulate algorithms that are likely to change so that change can’t ripple. Could even be within the same class. 6. Avoid tight coupling. Classes that are tightly coupled can’t be separated or changed independently. Also less likely to re-use. 7. Limiting re-use to inheritance. Composition and delegation provide alternatives which can be simpler and lead to more flexible systems. 8. Classes you can’t alter. Patterns give you ways of using classes you can’t touch which keeps your design flexible. Use of delegation is good example of this. DIZAJN PRINCIPI

OBJEKTNO-ORJENTISANOG PROGRAMIRANJA

IZVOR: Ivanković, Lacmanović: Udžbenik Softversko inženjerstvo 2, TFZR

• Jedna stvar je napisati kod koji radi. Nešto sasvim drugo je napisati dobar kod koji radi. Usvajanjestanovišta "pisanje dobrog koda koji radi" Stav "pisanje dobrog koda koji radi" vodi ka vrednovanju mogućnosti lakog održavanja koda. • Nezadovoljavajući softver može proizaći iz loše komunikacije – rešava se agilnim metodologijama frekventne komunikacije sa korisnikom i iterativno- inkrementalnim razvojem.

UOBIČAJENI NEFORMALNI DIZAJN PRINCIPI Postoji veliki broj uobičajenih dizajn principa koji, kao i dizajn paterni, predstavljaju najbolju praksu i omogućavaju osnovu na kojoj se mogu kreirati profesionalni softveri koji su laki za održavanje.

Neki od najpoznatijih principa su: Keep It Simple Stupid (KISS) – veoma često softverska rešenja budu suviše komplikovana. Cilj KISS principa je da kod bude jednostavan i da se izbegne nepotrebna kompleksnost

Don’t Repeat Yourselt (DRY) – ovaj princip nalaže da se izbegne bilo kakvo ponavljanje delova sistema. Ovo se postiže apstrakcijom onih delova koji su zajednički i njihovim smeštanjem na jednu lokaciju. Ovaj princip se ne bavi samo kodom, već bilo kojom logikom koja je duplirana u sistemu.

Tell, Don’t Ask – ovaj princip je blisko povezan sa enkapsulacijom i dodelom odgovornosti odgovarajućim klasama. On govori da je potrebno reći objektima koja akcija treba da se izvrši, umesto da se postavlja pitanje o stanju objekta i da se onda pravi odluka koja akcija treba da se izvrši. Ovo pomaže da se uredi odgovornost i da se izbegne jaka veza između klasa.

You Ain’t Gonna Need It (YAGNI) – ovaj princip govori da je potrebno uključiti samo funkcionalnosti koje su neophodne aplikaciji, a izbaciti sve ostaje funkcionalnosti za koje se misli da bi mogle zatrebati.

Separation of Concerns (SoC) – predstavlja proces razdvajanja dela softvera na zasebne karakteristike koje sadrže jedinstveno ponašanje, kao i na podatke koje mogu koristiti i druge klase. Proces razdvajanja programa po diskretnim odgovornostima značajno pospešuje ponovnu upotrebu koda, održavanje i testiranje.

S.O.L.I.D. DIZAJN PRINCIPI S.O.L.I.D. dizajn principi predstavljaju kolekciju najbolje prakse za objektno- orjentisan dizajn.

Naziv S.O.L.I.D. dolazi iz prvih slova svakog principa:  Single Responsibility Principle (SRP) - Princip SRP (Single responsibility principle - princip o samo jednoj odgovornosti) je u bliskoj vezi sa SoC (Separation of Concerns - razdvajanje odgovornosti). On govori da svaki objekat treba da ima jedan fokus. Pridržavanjem ovog principa, izbegava se problem monolitnih klasa. Ako su objekti koncizni, povećava se čitljivost i omogućava lakše održavanje sistema.  Open-Close Principle (OCP) - Princip OCP (Open-close principle - otvoren- zatvoren princip) govori da klasa treba da bude otvorena za proširenja a zatvorena za izmene. Drugim rečima, treba omogućiti dodavanje novih karakteristika i proširenje klase bez promene unutrašnjeg ponašanja postojećih metoda. Princip teži da se izbegne menjanje postojeće klase i drugih klasa koje od nje zavise, jer će to dovesti do pojavljivanja velikog broja grešaka u samoj aplikaciji.  Liskov Substitution Principle (LSP) - Princip LSP (Liskov substitution principle - Liskov princip zamene) govori da bi trebalo omogućiti korišćenje bilo koje izvedene klase na mestu klase roditelja i da bi ta klasa trebala da se ponaša na isti način bez izmena. Ovaj princip je u skladu sa OCP principom jer osigurava da izvedena klasa ne utiče na ponašanje klase roditelja.  Interface Segregation Principle (ISP) - Cilj ovog principa je dodeljivanje novog interfejsa grupama metoda koje imaju isti fokus kako bi se izbeglo da klijent mora da implementira jedan veliki interfejs i veliki broj metoda koje mu nisu potrebne. Prednost ovog principa se ogleda u tome da klase koje žele da koriste iste interfejse, treba da implementiraju samo određen skup metoda.  Dependency Inversion Principle (DIP) - Princip DIP se bazira na izolovanju klasa od konkretne implementacije kako bi zavisile od apstraktnih klasa i interfejsa. On promoviše kodiranje bazirano na interfejsima, a ne na implementaciji. Ovo pospešuje fleksibilnost u okviru sistema, osiguravajući da kod nije čvrsto vezan za jednu implementaciju. DI predstavlja dobavljanje klase nižeg nivoa i zavisne klase kroz konstruktor, metodu ili properti. Zavisne klase se mogu zameniti interfejsima ili apstraktnim klasama koje će voditi ka slabo povezanimsistemima koji su vrlo dobri za testiranje i laki za izmenu. Dependency Inversion princip (DIP) pomaže u razdvajanju koda tako što osigurava da unutar koda imamo zavisnosti od apstrakcija, a ne od konkretnih implementacija. Ovaj princip je najvažniji u cilju razumevanja dizajn paterna. Dependency Injection (DI) predstavlja implementaciju DIP. Ovi termini se često prepliću a cilj im je da se postigne razdvajanje koda.

REUSABILITY PROGRAMSKOG KODA

IZVOR: B.JALENDER, A.GOVARDHAN, P.PREMCHAND: DESIGNING CODE LEVEL REUSABLE SOFTWARE COMPONENTS, International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.1, January 2012

In software engineering reuse is an important area where we can improve the productivity and quality of software [3].Software reuse is the use of existing software or software knowledge to construct new software [4]. Reusable software components are designed to apply the power and benefit of reusable, interchangeable parts from other industries to the field of software construction [5].Software reuse provides a basis for dramatic improvements in increased quality and reliability and in long-term decreased costs for software development and maintenance.

PRISTUPI KOJI OMOGUĆAVAJU REUSABILITY:

Application Frameworks: Collections of concrete and abstract classes that can be adapted and extended to create application systems. It is used to implement the standard structure of an for a specific development environment. A framework is a incomplete implementation plus conceptually complete design. Application frameworks became popular with the rise of, since these tended to promote a standard structure for applications. · Application Product Lines: Application product lines, or Application development, refers to methods, tools and techniques for creating a collection of similar product line systems from a shared set of software assets using a common . An application type is generalized around a common architecture so that it can be adapted in different ways for different customers. A type of application system reuse. Adaptation may involve component and system configuration; selecting from a library of existing components ;adding new components to the system; or modifying components to meet new requirements [14]. · Aspect-Oriented Software Development: Aspect-oriented software development (AOSD) is an emerging software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program's business logic. AOSD allows multiple concerns to be expressed separately and automatically unified into working systems [15]. · Component-Based Development: Systems are developed by integrating components (collections of classes) that conform to component-model standards. By adopting a component based development approach you will have the option of buying off-the- shelf components from third parties rather than developing the same functionality inhouse[16]. · Configurable Vertical Applications: Configurable vertical application is a generic system that is designed so that it can be configured to the needs of specific system customers[17]. An example of a vertical application is software that helps doctors manage patient records, insurance billing, etc · COTS Integration: By integrating existing application systems System is developed. A type of application system reuse. A commercial off–the-shelf (COTS) item is one that is sold, leased, or licensed to the general public.[18] · Design Patterns: A design pattern is a recurring solution for repeatable problem in software design. Design Pattern is a template for how to solve a problem that can be used in many different situations [19]. · Legacy System Wrapping: By wrapping a set of defining interfaces by legacy systems provides access to interfaces. By rewriting a legacy system from scratch can create a equivalent functionality information system based on modern software techniques and hardware [20]. · Program Generators: Program Generator is a program that enables an individual to easily create a program of their own with less effort and programming knowledge. With a program generator a user may only be required to specify the steps or rules required for his or her program and not need to write any code or very little code A generator system embeds knowledge of a particular type of application and can generate systems or system fragments in that domain. Program Generators Involves the reuse of standard patterns and algorithms [20]. · Program Libraries: Function and class libraries implementing commonly used abstractions are available for reuse. Libraries contain data and code that provides necessary services to independent programs. This idea encourages the exchanging and sharing of data and code . · Service-Oriented Systems: SOA is a set of methodologies and principles for developing and designing software in the form of component. These components are developed by linking shared services that may be externally provided. An enterprise system often has applications and a stack of infrastructure including databases, operating systems, and networks [21].

TEHNIKE KREIRANJA CODE-LEVEL REUSABLE KOMPONENTI A code level reusable software component is self-contained and has clearly defined boundaries with respect to what it does and does not do. At these boundaries it will present an equally and clearly defined set of interface points that will allow easy integration with the other components. For most of the users, the interface will be sufficient to allow reuse the code level components; that is, the implementation will be hidden through encapsulation .For those users who need to modify the internals/functionality of the component in some way, for example to add a feature, or fix a previously undiscovered defect, a clear, unambiguous, and understandable specification for the component will be required. The component will then conform to the specification and user reproducible tests will validate this conformance. This allows users to modify implementation details, assuming source code is available and to build code level reusable components [22]. We need to provide clear documentation when distributing a code level software component. That will provide the information about how to reuse it along with example applications and installation guides.. Finally, it is critical that the component is correctly licensed and full details are made available to the end user [23]

The following ways to build code level reusable components · Class libraries · Function libraries · Design patterns · Framework Classes

Class libraries Class libraries are the object-oriented version of function libraries. Classes provide better abstraction mechanisms, better ability and adaptability than functions do. Reusability has greatly from concepts like inheritance, polymorphism and dynamic binding. In many class libraries there are classes devoted to generic data structures like lists, trees and queues. The major problem with class libraries is that they consist of families of related components. Thus members of families have incompatible interfaces. Often several families implement the same basic abstraction but have interfaces. This makes libraries hard to use and makes interchanging components. Also, most class libraries are not scalable [24].

Function libraries Functions are the most common form of reusable components. For many programming languages, standard libraries have been, for example, for input/output or mathematical functions. A few decades ago languages had much functionality in the language itself, e.g., PL/I. Later on, the trend was towards lean languages with standard libraries for various functionalities, e.g., Modula-2. There are many example of function libraries, from collections of standard routines (e.g., the C standard libraries) to domain libraries (e.g., for statistics or numerical purposes) [25].

Design patterns The purpose of design patterns is to capture software design know-how and make it reusable. To save time and effort, it would be ideal if there was a repository which captured such common problem domains and proven solutions. In the simplest term, such a common solution is a design pattern. Design patterns can improve the structure of software, simplify maintenance, and help avoid architectural drift. Design patterns also improve communication among software developers and empower less experienced personnel to produce high-quality designs. you design and build different applications, you continually come across the same or very similar problem domains. This leads you to find a new solution for the similar problem each time. They standardize piecework to larger units. For example, many times there exists a special arrangement of classes and/or objects in order to avoid reuse errors. A subsystem is a set of classes with high cohesion among themselves and low coupling to classes outside the subsystem [26]. A software design pattern describes a family of solutions to a software design problem.By using available methods, functions, threads we can build the code level reusable components. Example design patterns are Model/View/Controller (MVC), Blackboard, Client/Server, and Process Control. Design patterns can correspond to subsystems, but often they have level of granularity. Design patterns have been to avoid dependence on classes when creating objects, on particular operations, representation or implementation, on particular algorithms, and on inheritance as the extension mechanism [27]. MVC is enforces the separation between the input, processing, and output of an application. To this end, an application is divided into three core components: the model, the view, and the controller. Each of these components handles a different set of tasks.. The architecture of MVC shown in below figure 1.

Framework Classes For large-scale reuse, isolated classes are small-scale primitives that are to boost productivity; systems have to be built out of largescale composites. Thus we have to focus on sets of classes that collaborate to carry out a common set of responsibilities, rather than on individual classes. Frameworks are flexible collections of abstract and concrete classes designed to be extended and for reuse. Components of class libraries can serve as discrete, stand-alone, context- independent parts of a solution to a large range of applications, e.g., collection classes. Components of frameworks are not intended to work alone; their correct operation requires the presence of and collaboration with other members of the framework components. Reusers of framework classes inherit the overall design of an application made by experienced software engineers and can concentrate on the application's functionality [28]. The major advantage of framework classes over library classes is that frameworks are concerned with conventions of communication between the components [29] .Today the combination of components from class libraries is the exception rather than the rule. This is because there is some implicit understanding of how components work together. High cohesion and low coupling increase the reusability of components. But unless the component does have extensive functionality, it is required to cooperate and communicate with many others. In a framework this interaction is built in and eases interaction of its components [30].

MacApp is a framework for Macintosh applications. An abstract MacApp application consists of one or more windows, one or more documents, and an application object. A window contains a set of views, each of which displays part of the state of a document. MacApp also contains commands, which automate the undo/redo mechanism, and printer handlers, which provide device independent printing. Most document classes do little besides define their window and how to read and write documents to disk. An average programmer rarely makes new window classes, but usually has to define a view class that renders an image of a document. MacApp makes it much easier to write interactive programs [31].

Framework is set of reusable software program that forms the basis for an application. Building Reusable Frameworks help the developers to build the application quickly. These are useful when reusing more than just code level component[32] .Frameworks are having well written class libraries. By reusing these class libraries we will build the code level reusable software components[33].

CAS 10

UVOD - kontekst primenljivosti teorijskih koncepata: - Iskustva iz firme LEVI 9 – continuous delivery process razvoja, primena agilne metodologije SCRUM, testiranje, timski rad i sinhronizacija, alati za podrsku timskom radu

TEORIJA: - Slojevi višeslojne arhitekture softvera - Softverski dizajn paterni o Po slojevima o Po oblastima - Antipaterni

ISKUSTVA IZ FIRMI

INFO: dodatno prezentacija 11.1. 2018. u terminu predavanja – Levi 9 I Consulteer

LEVI 9 – prezentacija 13.12.2017. na TFZR - Continuous delivery process razvoja: zahtev (story, ticket) – programiranje/testiranje(debugging), Team Foundation Server (build, automatsko testiranje, release to test, release to production), Manuelno testiranje (zahtev – test plan – test suit – test cases), Produkcioni server (korisnikov server) - Scrum (POGLEDATI: http://www.scrum- institute.org/The_Scrum_Product_Backlog.php)– sprint (2-3 nedelje), skupljanje zahteva u backlog, grupisanje zahteva prema funkcijama I odredjivanje prioriteta, daily meetings (dogovor ko sta radi, predlog resenja I boljih resenja), refinement (procena tezine zahteva – story points), sprint review (sa klijentom sta je uradjeno I da li je zadovoljan), sprint retrospective (interno na nivou tima – problemi razvoja, alata…generalno I mogucnosti unapredjenja za ubuduce). - Alati – Test Lodge (evidentiranje zahteva korisnika), razvojni alat Microsoft Visual studio, TFS Server (Team Foundation server), GIT (razmena koda u timu) - Sinhronizacija u okviru VS NET sa TFS I GIT – omogućavanje timskog rada na zajedničkom softveru - Tehnologija – Microsoft Visual Studio NET, ASP.NET, MVC

SLOJEVI višeslojne arhitekture poslovnih aplikacija.

Pomoću: - Modularizacije - Reusability - Razdvajanje nadležnosti - Interna kohezija - Slaba povezanost – sprega sa drugim modulima Ciljevi višeslojnog razvoja aplikacije: - Lakše održavanje (izmene), - Timski rad (podela posla), - brži razvoj (jednom kada se biblioteke klasa naprave i testiraju, u narednom softveru sličnog tipa se brže realizuje softver). - Bolji kvalitet softvera – ponavljanje radnih operacija uvodi rizik od ljudske greške, kada jedan modul dobro funkcioniše, može se ponovo koristiti.

IZVOR: Ivankovic, Lacmanovic: Softversko inzenjerstvo 2, TFZR

DETALJNI PRIKAZ SLOJEVI I PODSLOJEVI SA TEHNIČKOM IMPLEMENTACIJOM U MICROSOFT VISUAL STUDIO RAZVOJNOM OKRUŽENJU

GLAVNI SLOJ MVC PODSLOJ TEHNOLOŠKA dizajn IMPLEMENTACIJA patern PREZENTACIONI VIEW Korisnički interfejs ASPX SLOJ CONTROL Klase DLL biblioteka klasa prezentacione logike SERVISNI SLOJ Web servis Projekat tipa web servisa - online biblioteka klasa kojoj se pristupa radi udaljenog uslužnog izvršavanja programskog koda Klase za DLL biblioteka klasa mapiranje slojeva SLOJ POSLOVNE Radni tokovi - Engine za upravljanje LOGIKE radnim tokovima - DLL biblioteka klasa MODEL Poslovni objekti  DLL biblioteka klasa sa klasama koje predstavljaju poslovne objekte (entitete pojmova realnog sveta, dokumente) koji se po nazivu razlikuju od naziva tabela iz baze podataka  Master-detail odnosi podataka Poslovna pravila - Engine za izvrsavanje poslovnih pravila, eksterna poslovna pravila zapisana formalnim jezikom - DLL biblioteka Klasa sa algoritmima provere i automatske primene poslovnog pravila SLOJ ZA RAD Rad sa DLL biblioteka klasa SA PODACIMA relacionom bazom - Entity framework podataka - DLL BIBLIOTEKE KLASA - - Klase Odvajanje tehnoloskih modela i klasa (orjentacija na repository konkretnu DBMS podrsku) za rad sa i klasa podataka podacima iz (semantika bez tabela tehnologije) radi boljeg relacione odrzavanja baze DBMS sistem i baza podataka - podataka tabele, relacije, stored - DBMS sa procedure, pogledi, trigeri, bazom transakcije podataka Rad sa drugim DLL biblioteka klasa formatima podataka – XML, XLS, JSON

DIZAJN PATERNI OBJEKTNO-ORJENTISANOG PROGRAMIRANJA IZVOR: Ivankovic, Lacmanovic: Softversko inzenjerstvo 2, TFZR

• Kvalitetna rešenja koja su pokazala upotrebljivost i stabilnost prerastaju u komponente koje se mogu ponovo koristiti, a opšti šabloni koji su se dobro pokazali u praksi prerastaju u dizajn paterne. • Dizajn šabloni (design patterns) predstavljaju apstraktne primere rešenja na visokom nivou. Njih treba posmatrati kao plan u rešavanju problema, a ne kao samo rešenje. Gotovo je nemoguće pronaći okvir (framework) koji će biti primenjen kako bi se kreirala cela aplikacija. Umesto toga, inženjeri vrše generalizaciju (uopštavanje) problema kako bi prepoznali patterne koje treba da primene. Dizajn paterni imaju za cilj ponovnu upotrebu postojećih rešenja. Iako nisu svi problemi jednaki, ako je moguće posmatrani problem „razbiti“ i naći sličnosti sa problemima koji su ranije bili rešavani, onda je moguće primeniti uniformno rešenje nad njim. Većina problema na koje se nailazi tokom programiranja je već rešena nebrojeno puta, pa verovatno postoji i patern koji može pomoći u implementaciji rešenja. Paterni su nastali kao rezultat dobre prakse i iskustva programera.

ISTORIJAT: Software patterns first became popular with the wide acceptance of the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (frequently referred to as the Gang of Four or just GoF).

TIPOVI DIZAJN PATERNA 1. grupa – prema slojevima: - Dizajn paterni prezentacionog sloja - Dizajn paterni sloja servisa - Dizajn paterni poslovnog sloja - Dizajn paterni sloja za rad sa podacima 2. grupa – u odnosu na oblast: • Creational Patterns: odnose se na kreiranje objekata i referenciranje • Structural Patterns: odnose se na relacije između objekata i na to kako objekti međusobno deluju jedan na drugi u cilju kreiranja većih i kompleksnijih objekata • Behavioral Patterns: odnose se na komunikaciju između objekata, naročito u smislu odgovornosti i algoritama

DIZAJN PATERNI PO SLOJEVIMA

PREZENTACIONI SLOJ - PODSLOJEVI: Korisnički interfejs (UI – user interface), prezentaciona logika - CILJEVI: ista funkcionalnost može biti podržana različitim grafičkim elementima korisničkog interfejsa, ali prezentaciona logika ostaje ista. Treba omogućiti laku promenu korisničkog interfejsa bez uticaja na druge slojeve. Treba da je čak prezentaciona logika nezavisna od UI tehnologije. - NAMENA I ODGOVORNOSTI: koristan prikaz podataka, konforan ulaz podataka, opšti prikaz (dizajn) u odnosu na namenu - DIZAJN PATERNI – MVC se, istorijski gledano, smatra dizajn paternom za GUI (graficki korisnicki interfejs), razdvajajuci VIEW (cist HTML), MODEL (podatke I poslovnu logiku) I CONTROL (kontrolu komunikacije sa korisnikom I upravljanja celom aplikacijom).

MVC DIZAJN PATERN

IZVOR: ASP.NET MVC, TutorialsPoint

The MVC (Model-View-Controller) design pattern has actually been around for a few decades, and it's been used across many different technologies. Everything from Smalltalk to C++ to Java, and now C Sharp and .NET use this design pattern to build a user interface. Following are some salient features of the MVC pattern:  Originally it was named Thing-Model-View-Editor in 1979, and then it was later simplified to Model- View-Controller.

 It is a powerful and elegant means of separating concerns within an application (for example, separating data access logic from display logic) and applies itself extremely well to web applications.

 Its explicit separation of concerns does add a small amount of extra complexity to an application’s design, but the extraordinary benefits outweigh the extra effort.

 The Model: A set of classes that describes the data you are working with as well as the business logic.  The View: Defines how the application’s UI will be displayed. It is a pure HTML, which decides how the UI is going to look like.  The Controller: A set of classes that handles communication from the user, overall application flow, and application-specific logic.

PRINCIP FUNKCIONISANJA The idea is that you'll have a component called the view, which is solely responsible for rendering this user interface whether that be HTML or whether it actually be UI widgets on a desktop application. The view talks to a model, and that model contains all of the data that the view needs to display. Views generally don't have much logic inside of them at all. In a web application, the view might not have any code associated with it at all. It might just have HTML and then some expressions of where to take pieces of data from the model and plug them into the correct places inside the HTML template that you've built in the view. The controller that organizes is everything. When an HTTP request arrives for an MVC application, that request gets routed to a controller, and then it's up to the controller to talk to either the database, the file system, or the model.

IZVOR: Ivankovic, Lacmanovic: Softversko inzenjerstvo 2, TFZR

MVC concept u Microsoft tehnologiji:

ASP.NET MVC is basically a web development framework from Microsoft, which combines the features of MVC (Model-View-Controller) architecture, the most up- to-date ideas and techniques from Agile development, and the best parts of the existing ASP.NET platform. It is a complete alternative to traditional ASP.NET Web Forms. It is built on the top of ASP.NET.

PREDNOSTI:

 Makes it easier to manage complexity by dividing an application into the model, the view, and the controller.  Enables full control over the rendered HTML and provides a clean separation of concerns.  Direct control over HTML also means better accessibility for implementing compliance with evolving Web standards.  Facilitates adding more interactivity and responsiveness to existing apps.  Provides better support for test-driven development (TDD).  Works well for Web applications that are supported by large teams of developers and for Web designers who need a high degree of control over the application behavior.

SERVISNI SLOJ

IZVOR: Ivankovic, Lacmanovic: Softversko inzenjerstvo 2, TFZR

Prema definiciji za sloj servisa koju je dao Martin Fowler u svojoj knjizi "Patterns of Enterprise Application Architecture", sloj servisa je dodatni sloj koji postavlja granicu između dva susedna sloja.

ODNOS PREMA SLUCAJEVIMA KORISCENJA Sloj servisa definiše interfejs za prezentacioni sloj kako bi se pozvale predefinisane akcije sistema. On predstavlja vrstu granice koja označava gde se završava prezentacioni sloj a gde počinje sloj sa poslovnom logikom. Sloj servisa je dizajniran kako bi održao vezu između prezentacionog sloja i sloja sa poslovnom logikom na minimumu, bez obzira na to kako je poslovna logika organizovana. Sloj servisa se obično mapira na poslovne slučajeve korišćenja. On se nalazi između prezentacionog sloja i sloja poslovne logike i predstavlja interfejs koji definiše granice sistema i operacije koje su omogućene klijentu.

IMPLEMENTACIJA: U sloju servisa, kod se poziva direktno iz korisničkog interfejsa. Poziva se metoda koja uzima određene podatke u zadatom formatu a vraća neke druge podatke. Podaci se u sloj i iz sloja prenose pomoću objekata za prenos podataka (DTO - Data Transfer Objects). sloj servisa predstavlja skup klasa koje predstavljaju logički povezane metode koje drugi sloj, u opštem slučaju prezentacioni sloj, može pozvati kako bi ispunio određeni slučaj korišćenja.

OPŠTI POJAM SERVISA I SERVISNO ORJENTISAN RAZVOJ APLIKACIJA Nezavistan od bilo koji tehnologije, reč servis ukazuje na softverski kod koji servisira zahteve koje jedan sloj šalje ka drugom. Izraz sloj servisa se odnosi na kolekciju servisa koji zajednički kreiraju posrednički sloj između dva sloja koja međusobno komuniciraju.

Velikom broju ljudi reč servis označava više od dela koda koji servisira dolazne zahteve. Ovapromena u gledištu je nastala kao posledica prednosti koje su doneli orjentacija ka servisima (SO - Service Orientation) i arhitektura bazirana na servisima (SOA - Service Oriented Architecture). SO je način dizajniranja poslovnih procesa kao skupa međusobno povezanih servisa. Tu se ne govori o samoj tehnologiji, već je to prosto drugačiji pristup u načinu opisa rada datog poslovnog sistema. SOA se odnosi na IT arhitekturu koja posmatra svoje resurse kao servise i vrši njihovo povezivanje statički ili na zahtev. U SOA svetu, aplikacije nastaju kao rezultat kompozicije i integracije nezavisnih servisa. Servise izvršavaju klijenti, pri čemu klijent jedan servis može izvršiti više puta. Pod klijentima se podrazumevaju korisnici, drugi servisi u aplikaciji, kao i drugi delovi poslovne logike kao što su tokovi rada.

Prilikom kreiranja SOA aplikacija postoje četiri osnovna principa koja treba slediti: - Granice su jasne – interfejs servisa bi trebao da bude što jasniji i jednostavniji - Servisi su autonomni – metode servisa ne bi trebale da zavise od drugi metoda u cilju obavljanja poslovnih transakcija. Klijent ne bi trebao da poziva metode u određenoj sekvenci kako bi obavio poslovnu transakciju. On bi trebao da pozove jedan servis i da u okviru jedne akcije dobije odgovor o uspehu ili neuspehu te transakcije. - Servisi prikazuju ugovore a ne klase – servisi bi trebali da otkriju samo ugovore a ne I konkretne implementacije. - Kompatibilnost servisa se zasniva na politici – servis bi treba da otkrije politiku za čega se on može koristiti. Klijenti zatim koriste servis sa dobrim znanjem kako da ga koriste i šta da očekuju kao odgovor.

PATERNI U SERVISNOM SLOJU - REQUEST – RESPONSE - IDEMPOTENT PATERN – omogućava da će korisnik dobiti uvek isti odgovor ukoliko uputi isti zahtev.

POSLOVNI SLOJ - Komponente: o objekti poslovnog domena (pojave, događaji, dokumenti, učesnici u poslovnom procesu), o poslovna pravila (klijentska politika, zahtevi I ograničenja – implementiraju se kao skup IF THEN ELSE pravila), o servisi (implementiraju autonomne funkcionalnosti, tj. slučajeve korišćenja), o procesi rada (workflow – definiše kako se dokumenti I podaci prenose iz jednog modula ili funkcije u drugi ili između slojeva). - Paterni poslovnog sloja: o Proceduralni paterni . Transaction Script patern – poslovni sloj se smatra nizom povezanih transakcija, svaka jedinica funkcionalnosti se deli na pojedine zadatke do najsitnijih delova koji se nazivaju (logičke) transakcije (skupa naredbi koje završavaju jednu logičku operaciju). . Modul Tabele patern – operacije su grupisane prema podacima u tabelama. Definisani su objekti u odnosu na tabele u bazi podataka. Operacije sa podacima su metode tih objekata. o Objektno-bazirani paterni – organizovanje logike domena kao grafa povezanih objekata, pri čemu svaki objekat predstavlja entitet poslovnog domena ili tačku od interesa I poseduje podatke I ponašanje. . Patern aktivnog sloga – objekti su slični tabelama iz baze podataka . Domen model patern – objekti se značajno razlikuju u odnosu na tabele baze podataka, apstrakniji su. Bliskiji poslovnoj problematici.

SLOJ ZA RAD SA PODACIMA - Sloj za pristup podacima – DATA ACCESS LAYER (DAL) – biblioteka klasa koja omogućava pristup podacima u bazi podataka, odnosno čitanje I upis (kao I brisanje I izmenu) podataka. - NADLEŽNOSTI SLOJA: CRUD usluge (Create, Read, Update, Delete), odgovor na upite (izdvajanje podataka ili bilokoji upit upućen podacima), upravljanje transakcijama, obrada konkurentnosti - CILJEVI: postići nezavisnost u odnosu na DBMS, mora omogućiti čuvanje I rad sa podacima nezavisno od formata (da li je relaciona baza podataka, datoteke itd). - IMPLEMENTACIJA nezavisnosti: ADO.NET API, objektno-relaciono mapiranje - DIZAJN PATERNI: o Repository patern – opšte funkcije za rad sa podacima date su u formi interfejsa (metode add, save, remove, findall, find by). Repository predstavlja memorijsku kolekciju čime se izoluju poslovni entiteti od infrastrukture podataka. o Query object patern – kreira se objekat koji predstavlja upit nad bazom podataka, čime se apstrahuje jezik upita za bazu podataka. Za konkretni DBMS se mora koristiti Query Translator objekat koji uzima Query objekte I pretvara ih u konkretne SQL naredbe za konkretni DBMS. o Unit of work patern- objekat Jedinica rada služi da održava listu objekata koji su promenjeni transakcijom, bez obzira da li je to dodavanje, uklanjanje ili ažuriranje. On je zadužen da koordinira skladištenje izmena i rešavanje problema konkurentnosti. o Data concurrency control – usklađivanje istovremenih ažuriranja objekta od strane više korisnika. Kontrole konkurentnosti : optimistička (poslednja promena pobeđuje) I pesimistička (zaključavanje ili čuvanje poslednje vrednosti prilikom učitavanja I poređenje sa verzijom nakon izmene). o Identity map – kreiranje mape učitanih objekata i omogućavanje da se prikažu objekti kada se referencira na njih, s ciljem da se objekat učita samo jednom.

DIZAJN PATERNI PO OBLASTIMA

CREATIONAL PATTERNS • OPIS: odnose se na kreiranje objekata i referenciranje • DIZAJN PATERNI:  Singleton – omogućava da klasa bude instancirana jednom i da poseduje globalnu tačku pristupa  Factory – omogućava da klasa delegira odgovornost za kreiranje odgovarajućeg objekta.  Abstract Factory – obezbeđuje interfejs za kreiranje više povezanih objekata  Builder – omogućava da različite verzije nekog objekta budu kreirane tako što razdvaja kreiranje samog objekta  Prototype – omogućava da klase budu kopirane ili klonirane iz instance prototipa, a ne da se kreiraju nove instance

STRUCTURAL PATTERNS • OPIS: odnose se na relacije između objekata i na to kako objekti međusobno deluju jedan na drugi u cilju kreiranja većih i kompleksnijih objekata • DIZAJN PATERNI:  Adapter – omogućava klasama nekompatibilnih interfejsa da budu korišćene zajedno  Bridge – razdvaja abstrakciju od njene implementacije, što omogućava da se apstrakcija I implementacija menjaju nezavisno jedna od druge  Composite – omogućava grupama objekata koje predstavljaju hijerarhiju da budu tretirane na isti način kao jedna instanca objekta  Decorator – omogućava da se dinamički okruži klasa i da se proširi njeno ponašanje  Facade – omogućava jednostavan interfejs i kontroliše pristup nizu komplikovanih intefejsa I podsistema  Flyweight – omogućava da se na efikasan način dele podaci između više malih klasa  Proxy – obezbeđuje skladište za kompleksniju klasu čije instanciranje je skupo

BEHAVIORAL PATTERNS • OPIS: odnose se na komunikaciju između objekata, naročito u smislu odgovornosti i algoritama • DIZAJN PATERNI:  Chain of Responsibility – omogućava komandama da se zajedno dinamički menjaju kako bi odgovorile na zahtev  Command – enkapsulira metodu kao objekat i razdvaja izvršavanje komande od pozivaoca  Interpreter – određuje kako oceniti rečenice u jeziku  Iterator – omogućava kretanje kroz kolekciju na formalizovan način  Mediator – definiše objekat koji omogućava komunikaciju između druga dva objekta, pri čemu oni ne znaju jedan za drugi  Memento – omogućava vraćanje objekta u prethodno stanje  Observer – definiše način na koji jedna ili više klasa treba da budu upozerene na promene u drugoj klasi  State – omogućava da objekat promeni svoje ponašanje tako što delegira na posebna i promenljiva stanja objekta  Strategy – omogućava da određeni algoritam bude enkapsuliran unutar klase i da bude zamenjen tokom izvršavanja kako bi promenio ponašanje objekta  Template Method – definiše kontrolu toka algoritma ali omogućava podklasama da preklope ili da implementiraju tokove izvršavanja  Visitor – omogućava novoj funkcionalnosti da bude izvršena nad klasom bez uticaja na njenu strukturu

ANTIPATERNI

IZVOR: https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Architecture/A nti-Patterns

In software engineering, an anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice. The term was coined in 1995 by Andrew Koenig, inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field. The term was widely popularized three years later by the book AntiPatterns, which extended the use of the term beyond the field of software design and into general social interaction.

NEKI PRIMERI Anti-Patterna

Singleton Overuse We have talked about this one: the first pattern you understood immediately, and you used it heavily. But beware it violates information hiding. Therefore the simple rule: when in doubt don't use it. My experience is that the larger the project, the more Singletons show up. How do you detect Singletons? This is very easy: look at the class diagram. All classes that have references to themselves (or their base class) are potential Singletons. If you want to get rid of them, Kerievsky shows you the medicine that cures this disease.

Functional Decomposition Although very popular once, in a modern object-oriented language there is no more space for functional decomposition. It is a remanent of procedural languages such as C or Pascal. Usually it indicates old software that was integrated into a new project or migrated. This anti-pattern reveals itself in three ways: The names of classes sound like function names (e.g. CalculateInterest). Or the classes only have one action, i.e., they only do one thing. Or all class attributes are private (which is fine) but they are only used within the class. To detect this anti-pattern you can use a tool such as SourceMonitor.[6] It lists all class names, and also lists the functions.

Poltergeist People like this anti-pattern because of its name. What it is, are classes that briefly appear to only disappear into oblivion. Either nobody knows what they really do, or they have very limited functionality. Usually they are not needed or can be absorbed in other classes. Usually one recognizes this anti-pattern by class names that end in ’*controller’ or ’*manager’. Again a tool such as SourceMonitor can help to find this anti-pattern. Often a consequence of "agile" approaches where cogitating is preferred to Design.

Spaghetti Spaghetti code is like the noodles: it is very long. Although the noodles are delicious, code the longer it gets is not. SourceMonitor can help you find this pattern, you simply look for methods with many lines of code. Refactoring usually is the cure here.

Blob A blob is a class with a lot of attributes and methods. Quite often these are not even related. You can detect this smell with your favorite code analysis tool, by listing classes with lots of attributes and methods or many lines of code. Usually splitting this class into several smaller classes will help here.

Copy and Paste As the name implies, somebody copied some code from some place to another place. It is the simplest way to duplicate functionality, but it should be avoided for many reasons. The simplest solution is to turn the code into a method instead, or use inheritance. To detect almost identical code you can use a tool like PMD’s Tool Copy/Paste Detector.

Lava Flow What is lava flow? "A lava flow is a moving outpouring of lava, which is created during a non-explosive effusive eruption. When it has stopped moving, lava solidifies to form igneous rock." In software engineering it means that the code is ancient, nobody has touched it for eons, and nobody has the guts to touch it (never touch a working class...). You can find these classes by using your source control system. Simply list those classes that have not been checked out and modified for a long time.

Code Smells Code smells are similar to anti-patterns, but not quite as formal. If code smells, then that smell can be o.k. (like some cheese) or it can be bad, possibly indicating a deeper problem. Kent Beck introduced the idea in the late 1990s and Martin Fowler made it popular in his book “Refactoring. Improving the Design of Existing Code”. You can use tools, such as FindBugs, Checkstyle or PMD to find bad smells. Usually refactoring is used to remove the offending odor. Martin Fowler and Joshua Kerievsky, among others, provide the appropriate refactorings.

Duplicate Code This smell is very similar to the Copy and Paste anti-pattern. You can use the PMD Tool Copy/Paste Detector [7] to find the problematic areas.

Long Method Related to the Spaghetti anti-pattern, you can find it using SourceMonitor when sorting classes according to ’Avg Stmts/Meth’. Methods that have more then 50 lines are definitely suspicious.

Indecent Exposure In the current Victorian age of information hiding, naturally indecent exposure is a bad thing. If a class has too many methods, or, god forbid, any public attributes then we talk about indecent exposure. You find this smell by checking for public methods of classes. If a class has more than 50% public methods, this may not conform to the information hiding policy.

Lazy Class Reminds me of the Poltergeist anti-pattern: this is a class that does so little that it has no reason for existence. Try to absorb it into another class. To detect this smell use SourceMonitor: Sort 'Methods/Class' and look for classes that have fewer than two methods or look for classes with very few lines of code. They are suspect of being lazy.

Large Class A large class is the opposite of a lazy class. You find it similarily, look for classes with too many methods, or too many statements. Usually a class should not have more than 30 methods or more than 400 statements. Also class with too many attributes could be large classes. Kerievsky shows several possible ways of reducing this smell. Really means not coding to code conventions. Look up Meyer, MISRA etc.

PRECIZNIJI Anti-Pattern-i po grupama

Organizational anti-patterns  Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project  Cash cow: A profitable legacy product that often leads to complacency about new products  Design by committee: The result of having many contributors to a design, but no unifying vision  Escalation of commitment: Failing to revoke a decision when it proves wrong  Management by perkele: Authoritarian style of management with no tolerance of dissent  Matrix Management: Unfocused organizational structure that results in divided loyalties and lack of direction  Moral hazard: Insulating a decision-maker from the consequences of his or her decision  Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure)  Stovepipe or Silos: A structure that supports mostly up-down flow of data but inhibits cross organizational communication  Vendor lock-in: Making a system excessively dependent on an externally supplied component

Project management anti-patterns  Death march: Everyone knows that the project is going to be a disaster – except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang"). Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline.  Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking  Smoke and mirrors: Demonstrating how unimplemented functions will appear  Software bloat: Allowing successive versions of a system to demand ever more resources  Waterfall model: An older method of software development that inadequately deals with unanticipated change

Analysis anti-patterns  Bystander apathy: When a requirement or design decision is wrong, but the people who notice this do nothing because it affects a larger number of people

Software design anti-patterns  Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions  Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint  Big ball of mud: A system with no recognizable structure  Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable  Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value  Inner-platform effect: A system so customizable as to become a poor replica of the software development platform  Input kludge: Failing to specify and implement the handling of possibly invalid input  Interface bloat: Making an interface so powerful that it is extremely difficult to implement  Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction  Race hazard: Failing to see the consequence of different orders of events  Stovepipe system: A barely maintainable assemblage of ill-related components

Object-oriented design anti-patterns  Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).  BaseBean: Inheriting functionality from a utility class rather than delegating to it  Call super: Requiring subclasses to call a superclass's overridden method  Circle-ellipse problem: Subtyping variable-types on the basis of value- subtypes  Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules  Constant interface: Using interfaces to define constants  God object: Concentrating too many functions in a single part of the design (class)  Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use  Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals  Poltergeists: Objects whose sole purpose is to pass information to another object  Sequential coupling: A class that requires its methods to be called in a particular order  Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

Programming anti-patterns  Accidental complexity: Introducing unnecessary complexity into a solution  Action at a distance: Unexpected interaction between widely separated parts of a system  Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine  Boat anchor: Retaining a part of a system that no longer has any use  Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging  Caching failure: Forgetting to reset an error flag when an error has been corrected  Cargo cult programming: Using patterns and methods without understanding why  Coding by exception: Adding new code to handle each special case as it is recognized  Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message  Hard code: Embedding assumptions about the environment of a system in its implementation  Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences  Loop-switch sequence: Encoding a set of sequential steps using a switch within a loop statement  Magic numbers: Including unexplained numbers in algorithms  Magic strings: Including literal strings in code, for comparisons, as event types etc.  Soft code: Storing business logic in configuration files rather than source code  Spaghetti code: Programs whose structure is barely comprehensible, especially because of misuse of code structures

Methodological anti-patterns  Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions  Golden hammer: Assuming that a favorite solution is universally applicable (See: Silver Bullet)  Improbability factor: Assuming that it is improbable that a known error will occur  Not Invented Here (NIH) syndrome: The tendency towards reinventing the wheel (Failing to adopt an existing, adequate solution)  Premature optimization: Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency  Programming by permutation (or "programming by accident"): Trying to approach a solution by successively modifying the code to see if it works  Reinventing the wheel: Failing to adopt an existing, adequate solution  Reinventing the square wheel: Failing to adopt an existing solution and instead adopting a custom solution which performs much worse than the existing one  Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem  Tester Driven Development: Software projects in which new requirements are specified in bug reports

Configuration management anti-patterns  Dependency hell: Problems with versions of required products  DLL hell: Inadequate management of dynamic-link libraries (DLLs), specifically on Microsoft Windows  Extension conflict: Problems with different extensions to pre-Mac OS X versions of the Mac OS attempting to patch the same parts of the operating system  JAR hell: Overutilization of the multiple JAR files, usually causing versioning and location problems because of misunderstanding of the Java class loading model

PREGLED DODATNE LITERATURE:

DESIGN PATTERNS  Erich Gamma, Richard Helm, Ralph Jognson, Jogn Vlissides: Design Patterns: Abstraction and Reuse of Object-oriented design, ECOOP ‘93 Conference Proceedings  Brad Appleton: Patterns and Software: Essential Concepts and Terminology, Blackboard Academic Suite  Craig Larman: Applying UML and patterns, Book, Second Edition  Partha Kuchana: Software Architecture Design Patterns in Java, Book, 2004, CRC Press LLC MVC  ASP.NET MVC, Book, TutorialsPoint, 2016  Jess Chadwich, Todd Snyder, Hrusikesh Panda: Programming ASP.NET MVC 4, O’Reilly, 2012.  John Galloway, Brad Wilson, K.Scott Allen, Davic Matson, Professional ASP.NET MVC 5, WROX, 2014.  ASP.NET MVC 6 Documentation, Microsoft, March 02 2016.

LITERATURA ZA DALJE IZUCAVANJE PROBLEMATIKE:  Arthur J. Riel: “Heuristike objektno-orjentisanog dizajna”, CET, 2003.  Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: “Design Patterns”, Addison-Wesley, 1995.

CAS 11

SOFTWARE FRAMEWORK

IZVOR:

Njeru Mwendi Edwin: Software Frameworks, Architectural and Design Patterns, Journal of Software Engineering and Applications, 2014, 7, 670-678

DEFINICIJA

A software framework is a concrete or conceptual platform where common code with generic functionality can be selectively specialized or overridden by developers or users. Frameworks take the form of libraries, where a well-defined application program interface (API) is reusable anywhere within the software under development. [3].

KARAKTERISTIKE

Certain features make a framework different from other library forms, including the following:

 Default Behavior: Before customization, a framework behaves in a manner specific to the user’s action.  Inversion of Control: Unlike other libraries, the global flow of control within a framework is employed by the framework rather than the caller.  Extensibility: A user can extend the framework by selectively replacing default code with user code.  Non-modifiable Framework Code: A user can extend the framework but not modify the code.

CILJEVI

The purpose of software framework is to simplify the development environment, allowing developers to dedicate their efforts to the project requirements, rather than dealing with the framework’s mundane, repetitive functions and libraries [3].

PRIMENA

Software frameworks consist of frozen spots and hot spots. Frozen spots define the overall architecture of a software system, that is to say its basic components and the relationships between them. These remain unchanged (frozen) in any instantiation of the application framework. Hot spots represent those parts where the programmers using the framework add their own code to add the functionality specific to their own project. In an object-oriented environment, a framework consists of abstract and concrete classes. Instantiation of such a framework consists of composing and subclassing the existing classes.

IZVOR: Sameer Paradkar: The Anatomy of Software Frameworks, BP Trends, April 2011.

PREDNOSTI I NEDOSTACI

Advantages

 Reuse code that has been pre-built and pre-tested. Increase the reliability of the new application and reduce the programming and testing effort, and time to market.

 A framework can help establish better programming practices and appropriate use of design patterns and new programming tools.

 A framework can provide new functionality, improved performance, or improved quality without additional programming by the framework user.

 By definition, a framework provides you with the means to extend its behaviour.

Disadvantages

 Creating a framework is difficult and time-consuming (i.e. expensive).

 The learning curve for a new framework can be steep.

 Over time, a framework can become increasingly complex.

 Frameworks often add to the size of programs, a phenomenon termed “code bloat”.

KATEGORIZACIJA FRAMEWORKA

IZVOR: Sameer Paradkar: The Anatomy of Software Frameworks, BP Trends, April 2011.

I grupa – prema mogucnostima uvida u programski kod i izmene White Box Frameworks – Emphasis on Inheritance o Black Box Frameworks – Emphasis on Composition o Grey Box Frameworks – Framework is built using both the above approaches.

II grupa - how broad the Framework scope is: o Application Frameworks are horizontal frameworks applicability across domains. o Domain Frameworks are vertical frameworks with specific applicability to a particular domain. o Support Frameworks: Basic system level frameworks on which other frameworks or application would be built. NAJČEŠĆE KORIŠĆENI FREMVORCI I UPOREDNI PRIKAZ KARAKTERISTIKA

POJMOVI: ORM – Object-relational mapping AJAX -Asynchronous JavaScript and XML

IZVOR https://en.m.wikipedia.org/wiki/Comparison_of_web_frameworks

HTML, CSS

Current stable Release

Project License version date

Bootstrap (client-side 3.3.7 2016-06-25 MIT, Apache framework)

Java

Current stable Release

Project License version date

Google Web 2.8.1 2017-04-24 Apache 2.0

Toolkit JavaServer CDDL, GNU GPL 2, Apache 2.2.8 2016-05-30 Faces 2.0 3.1.0 final

JBoss Seam 2012-01-13 GNU LGPL (discontinued)

Spark 2.5 2016-05-03 Apache

Spring 4.3.5 2016-12-21 Apache 2.0

JavaScript

Project Current stable version Release date License

AngularJS 1.6x 2017-01-05 MIT License

React.js 15.6.1 2017-01-06 MIT License

Node.js 8.4.0 2017-08-15 MIT License

PHP

Current

Project Start date stable Release date License version CakePHP 2005-08 3.5.7[16] 2017-12-05[±] MIT

CodeIgniter 2006-02-28 3.1.6[17] 2017-09-25 MIT

Laravel 2011-06-11 5.5.0[23] 2017-08-30 MIT

Symfony 2005-10 3.3.9[35] 2017-09-11 MIT

Zend Framework 2006-03 3.0.0[39] 2016-06-28 New BSD

Python

Project Current stable version Release date License

Django 2.0 2017-12-02[43] BSD

Falcon 1.3.0 2017-09-06[44] Apache 2.0

Ruby

Project Current stable version Release date License

Padrino 0.13.2 2016-05-09[53] MIT

Ruby on Rails 5.1.1 2017-05-12[54] MIT

Comparison of features Java M For V i1 Cac m C 8 Testin DB Securit Templ hin vali MVC p Pro n g migrati y ate g dati Lang Aja fram u jec & ORM frame onfram frame frame fra on

uage x ewo s t L1 work( ework( work(s work(s me fra rk h- 0 s) s) ) ) wor me p

n? k(s) wor ul k(s)

l Ap Cac Built ach Page Hibern hed -in jQu Pu Ye pluggab Velocity e Java orien ate, Ca Yes tem valid

ery ll s le , JSP Clic ted yenne plat atio

k es n Entity Entity Freema Inte Serv Engine Engine Internal rker rnal er (Intern Tools, Securit (Recom Cac side Ap Pu Java, al kind Data y mended he valid ach sh Groo jQu Ye of File framew ), Main atio e Yes - JUnit

vy, ery s ORM, Tool, ork Velocity tena n, OF p XML, not CSV based (Suppor nce Clie

Biz ull really Parser, on t with nt ORM, Apache OWASP Availabl Distr Side notably POI e), JSP ibut Vali used (Suppor ed dati by t Cac on Atlassi Availabl he (JQu an Jira) e) Clea ery) ring for clust ers Ap Pu Uses ach sh JCR e Java Yes Yes - content Yes Yes Yes

Sli p reposit

ng ull ory Ap Pu ach sh Ye Unit e Java Yes Yes - Yes Yes Yes

s tests Str p

uts ull Nati Ap Prot ve ach JPA, Hi Seleniu with otyp Spring or B e Pu Ye bernat m, Tes exte Java e, Yes Securit Yes ean Tap ll s e, Caye tNG, J nsio jQu y, Shiro Vali est nne Unit ns ery dati ry on Mock Exte objects nsio No , unit Ap ns (Mod and ach for ular with Pu Ye integra e Java YUI, even extensi Yes Yes Yes Yes ll s tion Wic Ext t- ons tests ket JS, drive via mor n) extensi e on Ajax valid atio n on For serv own mE Ye er Java Yes connec ngi s and tor API ne form stat e upd ate Unit multiple Spring GORM, Gra Groo Pu Ye tests, i plugins: Securit Yes Yes Hibern Yes Yes Yes ils vy sh s ntegrat autobas y,[60]A ate ion e, pache test, fu dbmigr Shiro[6 nctiona ate, 1] l test more us in even g extern pure page nor Its t Pu pluggab Java Yes Ja al, HTML- cach mal

Nat drive sh le va built-in SVG ing Java n i1 8n Nati ve JPA, Hi valid bernat ator Jav eand s, aSe any inte rve Pu Ye other Facelets grati

Java Yes Yes JUnit Yes Yes r ll s Java , JSP on Fac EE with

es ORM Bea framew n ork Vali dati on M For V i1 Cac m C 8 Testin DB Securit Templ hin vali MVC p Pro n g migrati y ate g dati Lang Aja fram u jec & ORM frame onfram frame frame fra on

uage x ewo s t L1 work( ework( work(s work(s me fra rk h- 0 s) s) ) ) wor me p

n? k(s) wor ul k(s)

l JAASint egratio n, Drool JBos Hibe JBo s, s rnat JPA, ss Pu Ye JUnit, Hiberna Cac e Java Yes Yes Hibern Facelets Sea ll s TestNG te he, Vali ate m Filters, Ehca dato OpenID che r , CAPTC HA Yes, Inte rnal Jsp Page JAAS Master- Own UI x- Java Yes orien integrat content API valid bay ted ion pages atio n cont rols Mod Yes, JVx Yes, Single el Ye plug We Java Yes plugga JUnit Yes sourcin Drive s gabl bUI ble g n e Pu sh JW Ye Java Yes Yes - Yes Yes Yes t s p ull uses JPA, uses UI is port Op Mod Hibern JSR- automa al en el Ye Hiberna Java Yes ate, JUnit 168 tically and Yes Xav Drive s te tools EJB2 portal generat JPA a n CMP security ed cach ing Serv Pu via er- sh JPA, JUnit, Core Pla Java, Ye side Yes Yes - Hibern Seleniu Yes Securit Yes Yes y Scala s valid p ate m y atio ull module n Inte Pu grati Out of sh on RIF DW Ye contain Java Yes - Yes Yes Yes with Yes

E R s er p Terr testing ull acot

ta Com JSP, mon Commo s Spring Hibern Mock ns Ehca valid Securit Spr Pu Ye ate, objects Tiles, V che, ator,

Java Yes Yes y(forme ing sh s iBatis, , unit elocity, mor Bea rly more tests Thymel e n Acegi) eaf, Vali more dati on framew JPA, Stri Pu Ye ork Java Yes Yes Hibern Yes Yes Yes pes ll s extensi ate on Pu Va sh GW Ye adi Java - Yes Yes Yes Yes

T s n p ull Wa Java Doj Yes Pu D Hibern JUnit Hiberna Spring Dojo Dojo Reg ve Scrip o sh oj ate te Securit Toolkit Tool ular ma t(clie Tool o y kit expr

ker nt), kit To (former essi Java ol ly on, (serv kit Acegi), sche er) role- ma- based driv access en control valid atio n M For V i1 Cac m C 8 Testin DB Securit Templ hin vali MVC p Pro n g migrati y ate g dati Lang Aja fram u jec & ORM frame onfram frame frame fra on

uage x ewo s t L1 work( ework( work(s work(s me fra rk h- 0 s) s) ) ) wor me p

n? k(s) wor ul k(s)

l WOUni Pu t We in sh (JUnit), bO Ye Project

Java Yes Yes - EOF TestNG Yes Yes Yes bje s WONDE p , cts R ull Seleniu m Pu Ajax sh valid , inte atio m grat n on ul es Velocity serv Java ti st use YUI, , FreeM er zte JDK pl an any Goo annotat arker, and mp 1.5 e da J2EE Unit gle, Yes ion JSP, form lat or ac rd ORM tests etc., based others stat es newe ti Ja framew with pluggab e r on va ork ann le upd s otati ate pe ons (YUI r , JS U ON) RL JUnit Go (too ogl JPA Bea Java, early), e with n Java Ye jsUnit(t We Yes Reques via Java Yes Vali Scrip s oo b tFactor dati t difficult Too y on ), lkit Seleniu m (best) Pu any Macro Hiberna clien sh J2EE Spring compon Java, jQu Ye JUnit, teUtil, t,

ZK Yes - ORM Securit ents & Yes

ZUML ery s ZATS SpringU serv p framew y compos til er ull ork ition

JavaScript M V i1 Form Testin Securi Templ C 8n DB valida MVCfr O g ty ate Caching Proj Aj pu & migrationf tion amew R frame frame frame framew

ect ax sh L1 ramework frame

ork M work( work( work( ork(s) - 0n (s) work( s) s) s)

pu ? s)

ll Karma (unit Conte i1 testing XH nt Form 8n ), Ang R, Securit validat an Protra Templ ularJ JS Yes y Caching ion d ctor ates

S O Policy (client l1 (end- NP (CSP), -side) 0n to-end XSRF testing ) E m Emb Ye Ye be Handle Yes QUnit erJS s s r bars Da ta Form qoox Ye Data i1 Testru Validat doo s binding 8n nner ion Spro Ye utCo Yes s re Na tiv Comm Storage e onJS Data (applicati Pu Ob Unit Securit on.stora sh Wak Ye jec Testin y and ge, Yes & anda s t g YUI Access user.stor Pu No Test Contro age, ll SQ Servic l SessionS L e torage) DB

PHP M V i1 L Se Te C 8 a DB cur mpl Form MV p n Cachin Sc n migr ity ate valid Cfr u & Testing g af R Mo Proj g Aja ation fra fra ation

am s L ORM framew frame fo A bil

ect u x fram me me fram ew h 1 ork(s) work(s ldi D ity a ewor wo wor ewor

ork - 0 ) ng g k(s) rk( k(s k(s) p n e s) )

u ?

ll The mes Unit , ORM tests, Lay Valida , Dat object CR outs tion Y a mocking, UD , via Mo e Map fixtures, bas Cell Conte bil P s per code ed, s, xts C e H , Patte coverage AC Vie (Table Pl a Ag P P Memcac rn, , L- ws, (DAO) ug k ent Cake > u he, Redi An Ye SQL memory bas Ele , in e De PHP = Yes s Yes s, XCac y s Relat analysis ed, men Entity CR B tec

3 5. h he, APC ional with PHP Mul ts, (VO) U a tio 6[ & , File Alge Unit and tipl Plug & D k n, 6 C braA Xdebug a e ins Contr e La 2] e bstra nd Conti Plu for oller), yo ll ction nuous gin Twi CSRF uts s Laye Integrati s g, B Protec r on via Tr oots tion avis trap , etc. P H P M > P os Te Code Third Ready No Y = An u tl mp Ignit Yes party for next Yes Yes Yes Yes Yes [6 e 5. y s y[ lat er only release 5] s 6. h 6 es 0[ 4] 6 3] jQu ery Memcac , jQ Opti P N he, Drup uer PA Ye onal SimpleTe N Ye H / Yes Yes Yes APC, Va Yes No al y C s mod st o s P A rnish, UI, ule more mo re Fat- P An MV P Ye Data Built-in Yes Yes Yes APC, Yes No ? ? Free H y C, u s map Memcac Fram P RM s pers he, ewor R h for XCache,

k - SQL, WinCac p Mon he, and u goD Filesyst ll B, em Flat- File P Yes H , Yes, File, Re P MV P Plu Plug dis, Fuel > C, u Ye gin ins Ye Yes Yes PHPUnit Yes Memcac Yes ? ?

PHP = HM s s s avai s he, 5. VC h ava labl more 3. ilab e x le Mul via tipl N qform Not e P o, s or P ma plu Fuse u cu built Ye H Yes nda ? ? ? gin ? ? ? ? box s st in s P tor s h o PHP y ava m valida ilab tion le De dic ate d Impl mo eme bil ntati e on- an spec In d Built- ific; ter tab nan P in AC help P ac let o.js u Data Sche L- er H tiv lay , s M - ma bas func Gyro P APC, e Y out rep LC h os sour comp ed, tion scop > No Memcac Yes co e s,

lac HH - tl ce ariso rep s e = he de s lan eab p y agno n tool lac and 5. ge dsc le[ u stic and ea the 4 ne ap 66] ll UDF ble me rat e- editor tem or por plat trai es t avai tra labl nsf e or ma tio n Joo Plu ? Yes ? ? ? ? ? ? ? ? ? ? ? ? mla gin P H P Bo PHPUnit, APC, Y Kajo P An u Ye Ye ots Yes Yes Selenium Yes Yes Yes Databas Yes e na > y s s s tra , Jasmine e, File s

= h p 7 P H APC, P P Databas Y Lara > An u Ye e, Ye

Yes Yes PHPUnit Yes Yes Yes Yes e No vel = y s s File, Me s s 5. h mcache, 5. Redis 9 Unit Yes, P Yes tests, PHP with C H , builtin , Tw Memcac SRFPr P P Plu Li3 ( test igPl he, Redi otecti Y > An u Ye gin Lithi Yes Yes framewor No ugin s, XCac on No e ? = y s s s um) k or avai he, APC and s 5. h ava other labl , File Form 3. ilab independ e Signin 6 le ent g P Too H Nett lkit P P e - Third > MV u Ye Fram ind party Yes No Yes Yes Yes Yes No ? ?

= P s s ewor epe only 5. h k nde 3. nt 0 P H P P Y Phal An u Ye Ye > Yes Yes Yes Yes Yes Volt Yes Yes e ? con y s s s = s h 5. 5 P APC, H Databas P P AC e, Y Pop > An u Ye L-

Yes Yes PHPUnit Yes Yes File, Me Yes ? e ?

PHP = y s s bas mcache, s 5. h ed Redis, 6. Session 0 P Pro P Data PHPUnit, XML APC, Ye PRA Ye Yes[6 H tot No u acce SimpleTe No Yes - Databas s[ ? ?

DO s 9] P ype s ss st, Seleni bas e, eAcce 70 > , h obje um ed, lerator, ] = scri - cts(D simi Memcac 5. pt. p AO), lar hed, 3. acu u activ to A XCache 0 lo.u ll e SP. s, recor NET ow d s[68 n patte ] co rn, mp SQL one Map nts data [67 map ] per P P jQu u Activ Silve H incl ery s e rStri P Unit . Y , h Ye recor Auto The Ye Ye pe(S > Yes tests, Sel Op Yes Yes e jQu - s d matic mes s s apph = enium enI s ery p patte ire) 5. D UI u rn 2 ll P Plugi H Pl n P ug Y exist PHP > Ye Plugin in

Silex Yes Yes e s Yes No Yes , Tw Yes ? ? = s exists ex s (Doc ig 5. ist trine 3. s ) 9 Ye Yes s, (Post (jQ greS uer QL, Yes y P MyS (Ma mo H QL, rker Yes bil Sma P SQLi s, T (File, e, Y Y rt.Fr > Ye te, wig, Redis, Bo Yes Yes e Yes No Yes Yes No e ame = s Mon othe others ots s s work 5. goD rs via tra 4. B, via plugins) p, 9 Solr, plug oth other ins) ers s via via plugi plu ns) gin s) P Pro P Prop Plugin PHP Symf H tot u Ye el, D exists Plu Ye Yes Yes , Tw Yes Yes ? ? ony P ype s s octri (alph gin s ig 5 , h ne(Y a scri AML) code) pt. acu lo.u s, Un obt rusi ve Aja x wit h UJS and PJS plu gin s P H Prop P P Symf el, D PHP > An u Ye Plugin Ye ony Yes octri Yes Yes , Tw Yes Yes ? ? = y s s exists s

2 ne(Y ig 5. h AML) 3. 3 P H P P PHPUnit Twis > An u Ye Yes Yes via Travi No Yes Yes Yes Yes No ? ? tPHP = y s s s 5. h 3. 3 P l P u P u Pl g H s TYP ug i P TYP An h Ye Partia O3 in n > Yes Yes Yes Yes Yes Yes ?

O3 y - s l Flui ex e = p d ist x 5. u s i 5 ll s t s P jQu P Data AC PHP APC, Ye H ery u Acce L- - Databas Ye PHPUnit, s[

Yii P , Yes s ss Yes bas bas e, Yes ? ? s Selenium 71 > jQu h Obje ed, ed, eAcceler ] = ery - cts RB PRA ator, 5. UI, p (DA AC DO- File, 4 ow u O), - like, Memcac n ll Activ bas plug he, co e ed, ins Redis, mp Reco plu WinCac one rd gin he, nts Patte s XCache, , rn, Zend plu Plugi Platform gin ns s (incl. Doct rine 2.0) Tabl P e P Too APC, u and Unit Zend H lkit Databas s row tests, AC Fram P - e, File, h Ye data PHP Unit L- Ye ewor > ind Yes Yes Yes Memcac Yes ? ? - s gate or other bas s k[72 = epe he, Zen p way independ ed

] 5. nde d u or ent 3 nt Platform ll Doct rine Tabl e and row P P data Too APC, H u gate Unit lkit Databas Zend P s way tests, AC - e, File, Fram > h Ye and PHP Unit L- Ye ind Yes Yes Yes Memcac Yes ? ? ewor = - s Doct or other bas s epe he, Zen k 2 5. p rine independ ed nde d 3. u 2.0 ent nt Platform 3 ll for Zend Fram ewor k 2.0

Python M V i1 Form C Testi Secur Temp Cachi Py 8n DB valid Pr Lan A MVCfr p O ng ity late ng th & migration ation oj gua ja amew us R frame frame frame frame on L1 framewor frame ect ge x ork h- M work work work work 3. 0n k(s) work p (s) (s) (s) (s) *

? (s) ul

l Dj Pyth Y Yes Pu Ye Y Yes Yes Yes built- Yes Yes Ye an on e sh s e in, s

go s s Jinja2, Mako, Cheet ah

Ruby M i1 V 8 C Form n Testi Secu Tem Cachi Pr p DB valid MVCfra & ng rity plate ng oj u OR migratio ation

Ajax mewor L fram fram fram fram ec s M nframew fram k 1 ewor ewor ewor ewor t h- ork(s) ewor 0 k(s) k(s) k(s) k(s) p k(s) n ul

l Unit Tests, Ru Functi ActiveR by Prototype, s Activ onal ecord, Pu Ye Plug- on cript.aculo.u eRec Tests Yes Yes Yes Yes Action sh s in

Ra s, jQuery ord and Pack ils Integ ration Tests

CAS 12

WEB SERVISI (SOAP, REST)

Dve osnovne tehnologije savremenih web servisa su:

 SOAP (Simple Object Access Protocol) is a protocol specification for exchanging structured information in the implementation of web services in computer networks. Its purpose is to induce extensibility, neutrality and independence. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.  REST (Representational state transfer) or RESTful web services are a way of providing interoperability between computer systems on the Internet. REST- compliant Web services allow requesting systems to access and manipulate textual representations of Web resources using a uniform and predefined set of stateless operations.

KOMPARACIJA KARAKTERISTIKA

IZVOR: Marek Potociar: When To Use SOAP And When REST, jAZOON, International conference on the modern art of Software, 2011.

CAS 13

FORMATI ZA RAZMENU PODATAKA (XML, JSON)

IZVOR: Gofur Halmruatov, Elena Myazina: XML vs JSON, 2009.

U primeni web servisa koriste se 2 osnovna formata podataka:

 XML (EXtensible Markup Language) – koristi se u SOAP web servisima  JSON ((JavaScript Object Notation)– koristi se u REST web servisima.

KARAKTERISTIKE xml:

KARAKTERISTIKE JSON:

Komparacija:

PRIMER XML:

PRIMER JSON: https://www.sitepoint.com/10-example-json-files/ This is an example of a Google Maps JSON file which you might see used to store configuration settings to setup your system. It might also be used to contain Google Maps record information which can be easily shared across components using the simple JSON format.

{"markers": [ { "point":new GLatLng(40.266044,-74.718479), "homeTeam":"Lawrence Library", "awayTeam":"LUGip", "markerImage":"images/red.png", "information": "Linux users group meets second Wednesday of each month.", "fixture":"Wednesday 7pm", "capacity":"", "previousScore":"" }, { "point":new GLatLng(40.211600,-74.695702), "homeTeam":"Hamilton Library", "awayTeam":"LUGip HW SIG", "markerImage":"images/white.png", "information": "Linux users can meet the first Tuesday of the month to work out harward and configuration issues.", "fixture":"Tuesday 7pm", "capacity":"", "tv":"" }, { "point":new GLatLng(40.294535,-74.682012), "homeTeam":"Applebees", "awayTeam":"After LUPip Mtg Spot", "markerImage":"images/newcastle.png", "information": "Some of us go there after the main LUGip meeting, drink brews, and talk.", "fixture":"Wednesday whenever", "capacity":"2 to 4 pints", "tv":"" }, ] } This is an example of a Facebook JSON file which you might see when getting data from the Facebook API. It might also be used to contain profile information which can be easily shared across your system components using the simple JSON format.

{ "data": [ { "id": "X999_Y999", "from": { "name": "Tom Brady", "id": "X12" }, "message": "Looking forward to 2010!", "actions": [ { "name": "Comment", "link": "http://www.facebook.com/X999/posts/Y999" }, { "name": "Like", "link": "http://www.facebook.com/X999/posts/Y999" } ], "type": "status", "created_time": "2010-08-02T21:27:44+0000", "updated_time": "2010-08-02T21:27:44+0000" }, { "id": "X998_Y998", "from": { "name": "Peyton Manning", "id": "X18" }, "message": "Where's my contract?", "actions": [ { "name": "Comment", "link": "http://www.facebook.com/X998/posts/Y998" }, { "name": "Like", "link": "http://www.facebook.com/X998/posts/Y998" } ], "type": "status", "created_time": "2010-08-02T21:27:44+0000", "updated_time": "2010-08-02T21:27:44+0000" } ] }

OPŠTA LITERATURA ZA CEO UDŽBENIK

 Кази Љубица, Радуловић Биљана: »Проjeктовањe информационих систeма кроз примeрe и задаткe, практикум«, 2008, Тeхнички факултeт "Михаjло Пупин" Зрeњанин, ISBN 978-86-7672-105-4, Библиотека „Уџбеници“, број 134, 2007/08  Ivanković Z, Lacmanović D: Softversko inženjerstvo 2, skripta, Tehnički fakultet “Mihajlo Pupin”, Zrenjanin, 2016.  Кази Љубица, Биљана Радуловић: „Увод у дистрибуиране информационе системе – практикум за вежбе”, Технички факултет "Михајло Пупин" Зрењанин, Библиотека "Уџбеници" број 184, 2013/2014, ISBN 978-86-7672-227-3 (електронски уџбеник)  George Coulouris, Jean Dollimore, Tim Kindberg, Gordon Blair: "Distributed Systems: Concepts and Design", Addison Wesley, 2012.  Tanenbaum A, Van Steen M: “Distributed systems, Principles and Paradigms”, VrijeUniversiteit, Amsterdam, Pearson Prentice Hall, 2007.  Ajay D. Kshemkalyani, Mukesh Singhal: "Distributed Computing, Principles, Algorithms, and Systems", Cambridge University Press 2008  Arthur J. Riel: “Heuristike objektno-orjentisanog dizajna”, CET, 2003.  Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: “Design Patterns”, Addison-Wesley, 1995.  Martin Fowler: “Refactoring – Improving the Design of Existing Code”, Addison-Wesley, 1999.