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. So f t w ar e F ac t or y Def in i t i on 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=a0d36000002HEjdAAG&page=JobDetailPage&sessionId=&jobSite=default&p=Candidate)

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

methodologies“ Кристалне

методoлогије

Фамилија метода за колокацијске тимове различитих величина

и критичности: Clear, Yellow, Orange, Red, Blue. Једна од најагилнијих метода „Crystal Clear“ фокусирана је на комуникацију у малим тимовима у развоју софтвера који није

животно-критичан, а карактеристике су: фреквентна испорука, рефлективно унапређење, осмотска комуникација, лична

безбедност, фокус, лак приступ експертским корисницима и захтеви за техничким окружењем. [Cockburn, 2004] Фамилија

Crystal метода омогућава избор одговарајуће методе у складу са величином и критичности, а „боја“ методе одређује тежину методе. Већи пројекти захтевају више координације и теже

методе. Crystal приступ омогућава прилагођавање метода како би одговарале различитим околоностима и конкретним

пројектима. [Abrahamsson et al, 2003] Crystal Methods – колекција приступа агилном развоју софтвера, који се фокусира примарно на људе и интеракцију

међу њима док раде на пројектима развоја софтвера. Такође, фокус је на критичности и приоритетима елемената система

који се развија, у односу на значај и утицај на пословање. Људи и процеси, као и њихове интеракције представљају језгро развојног процеса. [Agile PrepCast, 2013]

„Dynamic software

development method

(DSDM)” Метода

динамичко

г развоја софтвера

Дели пројекте на 3 фазе: пред-пројекат, пројектни животни циклус, пост-пројекат. Девет основних принципа: укључивање

корисника, оснаживање пројектног тима, фреквентна испорука, фокусирање на тренутне пословне потребе,

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

ефективна комуникација. [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

development“ (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

ng (XP, XP2)

Екстремно програмир

ање

Представља колекцију добро познатих практичних упутстава и искустава из софтверског инжењерства. [Abrahamsson et al,

2003] Састоји се од 12 принципа праксе: игра планирања, мале испоруке, метафора, једноставан дизајн, тестирање,

рефакторисање, програмирање у пару, колективно власништво над артефактима, континуирана интеграција, 40-часовна радна недеља, стална комуникација са корисницима (on-site),

стандарди кодирања. Ревизија путем XP2 предлаже принципе праксе: седети заједно, целина тима, информативни радни

простор, енергизиран рад, програмирање у пару, корисникове приче („user stories”) као спецификација захтева, итерације на недељном нивоу и на 3-месечном нивоу, затишја (slack),

изградња од 10 минута, континуирана интеграција, програмирање базирано на тестирању („test-first

programming”), инкрементални дизајн. [Beck, 2004] Промовише фреквентне испоруке у малим развојним циклусима, у циљу унапређења продуктивности и увођења тачки контроле где

нови захтеви корисника могу бити прилагођени. Остале особине: програмирање у пару или екстензивна ревизија кода,

тестирање целог кода једног модула, избегавање програмирања особине софтвера све док заиста није потребна, равна структура менаџмента, једноставност и јасност кода,

очекивање промена у захтевима корисника како време пролази и проблем је боље схваћен, фреквентна комуникација са клијентима и између програмера. [Agile PrepCast, 2013]

Адаптивни развој

софтвера (ASD)

Настао на основама Rapid Application Development. Укључује принципе континуалне адаптације процеса развоја, као

понављајуће серије шпекулација, сарадње и учења. У овом динамичком циклусу обезбеђује константно учење и

адаптацију актуелном стању пројекта. Карактеристике 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]

- Софтверска архитектура, софтвер („software“),

апликациони софтвер

[Dulović, 1991] [Stankić, 2005] [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]

- Рачунарска опрема (“Hardware”)

[Stankić, 2005] [Elmasri& Navathe, 2007] [Krsmanović& Mandić, 1995]

- Мрежна опрема (“Netware”)

[Stankić, 2005][Krsmanović& Mandić, 1995]

КАДРОВИ (“Lifeware”) [Lazarević et al, 1988] [Elmasri& Navathe, 2007] [Krsmanović& Mandić,

1995]

- Персонал који користи и

управља подацима

[Elmasri& Navathe, 2007]

- Програмери апликација [Elmasri& Navathe, 2007]

ОРГАНИЗАЦИОНА АРХИТЕКТУРА (“Orgware”)

[Lazarević et al, 1988] [Dulović, 1991] [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.

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.

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

Korisnik

Meni aplikacijePrijava na sistem

Sifarnici

Obrada

Pretraga

Izvestaji

Servis

Korisnici

Bekap

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

Korisnik aplikacije

Azuriranje podataka

Predstavljanje podataka

Manipulacija podacima

Obrada podataka

Eksport podataka

Unos

Brisanje

Izmena

Tabelarni prikaz

Pojedinačni prikaz

Prikaz za štampu

Grafički prikaz

Statistička sumiranja

Eksport u tekstualne datoteke

Eksport u dokument

Navigacija

Pozicioniranje

Selekcija

Označavanje

Filtriranje

Sortiranje

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

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

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.

DESKTOP APLIKACIJA - izvršni paket

Baza podataka

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

Biblioteke klasa za rad sa bazom podataka iz jezgra DBMS

DESKTOP APLIKACIJA - dizajn režim

Baza podataka1

Izvorni kod programaProgramsko razvojno okruženje

DBMS jezgro i vizualni alat

DESKTOP APLIKACIJA - instalacioni paket

Baza podataka2

Izvršna verzija programa2

Biblioteke klasa standardnog skupa iz razvojnog okruženja2

Biblioteke klasa za rad sa bazom podataka iz jezgra DBMS2

setup program

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.

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.

VIŠESLOJNA DESKTOP APLIKACIJA - izvršni paket

Baza podataka3

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

Biblioteke klasa za rad sa bazom podataka iz jezgra DBMS3

Aplikacione biblioteke klasa

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

Web browser

Web servis

Serverski ENGINE za web servisServerski ENGINE za web aplikaciju

Web aplikacija

DBMS 2Baza podataka 2

Biblioteka klasa

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 ELEMENATA

GRUPA OSOBINA

Potrebna osobina - METRIKA

CELINA MODELA

Semantika Semantički u skladu sa problemom

Usklađenost sa datim

materijalom

Pokrivenost opisa posla

Pokrivenost importovanih elementarnih podataka

Pokrivenost skladišta podataka sa DTP

Kompletnost

Kompletnost skupa entiteta

Kompletnost skupa atributa

Kompletnost skupa poveznika

Jezička Nepostojanje sinonima u nazivima

nedvosmislenost entiteta i atributa

Nepostojanje homonima u nazivima

entiteta i atributa

Прагматика

Могућност креирања SQL упита

Једноставност ажурирања података у оквиру трансакција

ENTITET

Naziv

Imenica ili glagolska imenica

Izražava sustinske objekte i

dogadjaje

Ne izražava nazive dokumenata

Jednina u nazivu

Entitet i atributi

Ima identifikaciono obeležje ili je

identifikaciono zavisan od drugih entiteta

Dodeljen atribut odgovarajućem entitetu

(2NF) Ne postoje brojni odnosi atributa 1:M u entitetu

(3NF) Ne postoje tranzitivne zavisnosti atributa u entitetu

ATRIBUT

Naziv (1NF) Jednina u nazivu

(1NF) Nema naziv kao struktura

Atributi i tipovi

/domeni podataka

Odgovarajući tip podatka

Atribut nema za tip podatka domen

(uzi skup vrednosti nego sto je standardni tip podatka), vec je

izvucen kao sifarnik

Karakteristike

Atributi se sa istim nazivom ne

ponavljaju (nema redundanse)

Nema izračunljivih atributa, vec samo

analitickih vrednosti medju atributima na osnovu kojih se vrše izracunavanja

POVEZNIK

Naziv Poveznik ima naziv

Naziv kao glagol

Nacin

povezivanja entiteta

Povezani direktno entiteti koji treba da budu povezani

Entiteti su povezani hronoloskim sledom međuzavisnih događaja

Povezani su entiteti u gerund odnosu, ako je potrebno

Ako poveznik ima važne atribute, pretvoren je u entitet

Podesavanja

osobina

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

Pravilno određeno u vezi 1:1 ko je

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

ULOGA

PREDM

ET

GRUPA

ARTEFAKTA

UPOZNAVANJE SA

POSLOVNIM PROCESOM

GRUBI MODEL

POSLOVNIH PROCESA – activity dijagram

GRUBI KONCEPTUALNI MODEL – poslovni entiteti

Business

Process Analyst –

analizira poslovne procese

kakve jesu i kakvi ce biti

Agile Product Owner,

Business Systems

Analyst

IS 1 IDEJNI

PROJEKAT – KONCEPTUAL

NI MODEL

SNIMAK STANJA Tekst snimka stanja –

postojeća rešenja, planovi, strategije,

problemi

Business

consultant – analizira

poslovne ciljeve i zadatke i

predlaže rešenja za

poslovne problem

Agile Product Owner,

Business Systems

Analyst

IS 1

SPECIFIKACIJA

ZAHTEVA

Client requirements

document

Requirement

s Analyst-specifier dokumentuje

zahteve poslovanja

Agile Product Owner, Business

Systems

IS 1

SE 2

Analyst

Specifikacija poslovnih

ciljeva i procesa, usklađenost za

projektom

Management

consultant – omogućava

razvoj poslovnih strateških

ciljeva

Agile Product Owner, Business

Systems Analyst

PLANIRANJE PROJEKTA

Project charter Project plan

Business consultant –

analizira poslovne

ciljeve i zadatke i predlaže

rešenja za poslovne

problem Project

manager

Upravljanje

projektima

SE 2

DIZAJN -

ARHITEKTURA SISTEMA

Dokument opisa

arhitekture sistema UML model – dijagram

komponenti UML model – dijagram razmeštaja

System

Analyst – prevodi

zahteve poslovanja u sistemske-

funkcionalne zahteve

SE1

SE2 IS1

DETALJNO UPOZNAVANJE SA

POSLOVNIM PROCESOM

DETALJNI BUSINESS PROCESS MODEL sa

rečnikom podataka GLOSSARY – rečnik poslovnih termina sa

objašnjenjima i sinonimima

Business Process

Analyst – analizira poslovne

procese kakve jesu I

kakvi ce biti Business

Architect – analizira ceo

poslovni process, podatke I

ciljeve

IS1 GLAVNI PROJEKAT –

LOGIČKO PROJEKTOVANJE

DIZAJN SOFTVERSKIH FUNKCIJA

UML model- use case sa specifikacijom

Software architect

IS1 SE1 SE 2

DIZAJN MODELA PODATAKA

CDM model

Data Analyst Data Modeler

IS1

PLANIRANJE IMPLEMENTACIJE

PDM model baze podataka

UML model – dijagram klasa

Software - Solution

architect

IS1 DETALJNI PROJEKAT-

FIZIČKO PROJEKTOVA

NJE, tj. planiranje implementacij

e

Razmatranje gotovih rešenja – framework,

arhitekturni šabloni, biblioteke klasa

Software - Solution

architect

SE2

IMPLEMENTACIJA - IZRADA BAZE PODATAKA,

PROGRAMIRANJE

User story – kratki tekstovi zahteva korisnika za doradom u

toku razvoja

Scrum master Agile Product

Owner, Business

Systems Analyst

SE1 SE2 IS2

PRODUKCIJA

Shema baze podataka Izvorni kod

Programmer Developer

TESTIRANJE Test plan Test slučajevi

Rezultati testiranja Rezultati korekcija

Tester Scrum

master

SE2

DOKUMENTOVANJE Korisničko uputstvo Tehničko uputstvo

Technical writer

Scrum master

SE1 SE2

IS2

ISPORUKA - INSTALACIJA

Izvršni kod Instalaciona verzija

programa Tehničko uputstvo za

instalaciju i održavanje

Product owner

Release Manager

SE1 SE2

IS2

Obuka Uputstvo za korišćenje Trainer SE1

SE2 IS2

POSTPRODUK

CIJA

ODRZAVANJE – IZMENE

Zahtev za izmenom Izveštaj o realizovanoj izmeni

Scrum master Developer

Agile Product Owner,

Business Systems Analyst

SE2

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 нивои

[Dhar&Balakrishnan,

2006]

Ризици IT outsourcing - фактори: људи

(различите способности, искуства), Знање

(Функционално, технолошко, управљачко),

Културни, Политички, Финансијски (Рачуноводствени

стандарди, варијација курсне листе), Стандарди

квалитета, Стандарди мерења перформанси,

Обухват, трошкови, процена времена, Различите

компаније из страних земаља имају различити начин

управљања и суштинске компетенције, Правни

уговори и стандарди интелектуалног власништва,

Безбедност – заштита и контрола података,

Опоравак од катастрофа, Управљање уговарањем

(формулисање уговора, планирање распореда,

планирање активности, слање и прихватање

испорука, одјава).

[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

matrics

summar

y

Column Id

A

B

C

D

E

F

G

H

I

Row ID

In

teg

rati

on

Sco

pe

Tim

e

Qu

ality

Hu

man

Resou

rc

e

Co

mm

un

icati

on

Ris

k

Pro

cu

re

men

t

Sta

keh

ol

der

1 Requiremen

ts

2

2 Design 1 2

3 Constructio

n

1

4 Testing 1 2

5 Maintainanc

e

1 1

6 Configurati

on

Managemen

t

1 1 1 5 2

7 Engineering

Managemen

7 5 3 2 10 10 8 2 2

t

8 Engineering

Process

1 1 1 6

9 Engineering

Models and

Methods

10 Quality 3 4 4

11 Engineering

Economics

1 1

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

Развојна окружења за софтверско инжењерство предмет су истраживања и

стандардизације (нпр. стандард 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

ve Collab

Basec

amp

dotPr

oject

GFo

rge

Ji

ra

RedM

ine

Micros

oft Team Found

ation Server

TeamVi

ewer

PMBOK

Интероперабилност

са другим алатима, посебно

развојним окружењи

ма и различитим

форматима

фајлова?

Да Да Да

Да

Да Да

експорт

података?

Да Да Да Да

PMB

OK

Приказ

дефинисаног обухвата

потребних софтверск

их функција? Измене

обухвата потребних

софтверских функција?

Приказ реализова

ног обухвата потребних

софтверских

функција?

Д

а Да

Да

Да

Да Да

Да

Да Да

PMB

OK

Процену и

планирање времена реализаци

је? Приказ временски

х карактери

Да

Да

Да

Да

Да

Да

Да

Да

Д

а Да

Да

Да

Да

Да

стика тока реализације?

PMBOK

Мерење квалитета

људи – учесника

пројекта? Мерење квалитета

тима у учешћу

пројекта? Мерење квалитета

резултата? Мерење

квалитета тока резултата

процеса?

- Да

Да Да

- Да

Да Да

PMB

OK

Евиденциј

у учесника

пројекта? Евиденцију

реализованог рада?

Персонализацију функција

за различите

профиле корисника

у односу на различите

улоге у реализаци

ји пројекта?

Да

Да Да

Да

Да Да

Да

Да Да

Да

Да Да

Д

а Д

а Да

Да

Да Да

Да

Да Да

PMBOK

Размену фајлова између

учесника? Комуници

рање – размену порука,

идеја, питања?

Да Да

Да Да

Да Да

Да Да

Да Д

а

Да Да

Да Да

Да Да

PMB Евидентир Да

OK ање ризика? Мерење

ризика? Приказ

ризика?

Да Да

PMB

OK

Унапређе

ње постојећег решења

додатним модулима?

Да Да Д

а

Да Да

PMBOK

Комуникацију са

заинтересованим странама?

Да Да Да Да Да

Да

Да

Да

PMBOK: Max=21

8 9 9 11 13 20 17 5

SWEBO

K

Евиденцију захтева?

Евидентирање

промене захтева? Праћење

и приказ промена

захтева? Евидентирање

степена усклађено

сти решења са захтевима

?

Да Да

Да

Да

Да

Да

Да Да

Да

Да Да

Да

SW

EBOK

Интеграци

ју са алатима

за дизајн система?

Да Д

а

Да

SWEBOK

Интеграцију са алатима

за развој?

Да Да

Да Да

SW

EBOK

Интеграци

ју са алатима

за тестирање?

Да Д

а

Да

SWEBO

Приказ тока

Да Да Да Да Да

Да Да

Да Да

K процеса реализације?

Мерење успеха

фазе или тока реализаци

је?

SW

EBOK

Примену

различитих приступа

и методологија

управљања

пројектима? Примену

различитих приступа

и методологија

развоја софтвера?

Да Д

а Д

а

Да

Да

Да

Да

SWEBO

K

Мерење квалитета

резултата? Мерење квалитета

тока резултата

процеса?

Да Да

Да Да

SWEBOK:

Max=13

1 1 1 8 9 10 12 0

BSC Финансијс

ки показатељи успеха

фазе или процеса?

Финансијски показатељ

и успеха производа

?

Да Да

Да

BSC Комуникац

ију са корисницима?

Креирање

Да

Да

Да Да Да

Да

Д

а

Да

Да

Да

Да Да Да

Да

извештаја? Мерење

задовољства

корисника? Евидентир

ање потреба и

захтева корисника?

BSC Приказ тока

процеса? Планирањ

е тока процеса? Мерење

успеха тока

процеса?

Да Да Да Да

Да

Да

Да Да

Да

Да Да

Да

BSC Евиденциј

у и приказ искустава?

Евидентирање и

приказ проблема и

одговора?

-

Да

-

Да

Да

Да

BSC:

max=10

3 2 2 4 5 9 7 1

УКУПНО:

max=44

12 12 12 23 2

7

39 36 6

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 dizajn

patern

PODSLOJ TEHNOLOŠKA IMPLEMENTACIJA

PREZENTACIONI

SLOJ

VIEW Korisnički interfejs ASPX

CONTROL Klase prezentacione

logike

DLL biblioteka klasa

SERVISNI SLOJ Web servis Projekat tipa web servisa - on-

line biblioteka klasa kojoj se pristupa radi udaljenog uslužnog izvršavanja programskog koda

Klase za mapiranje slojeva

DLL biblioteka klasa

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 SA PODACIMA

Rad sa relacionom bazom

podataka - Klase

modela i

repository za rad sa

podacima iz tabela relacione

baze podataka

- DBMS sa bazom podataka

DLL biblioteka klasa - Entity framework

- DLL BIBLIOTEKE KLASA - Odvajanje tehnoloskih klasa (orjentacija na

konkretnu DBMS podrsku) i klasa podataka

(semantika bez tehnologije) radi boljeg odrzavanja

DBMS sistem i baza podataka - tabele, relacije, stored

procedure, pogledi, trigeri, transakcije

Rad sa drugim formatima

podataka – XML, XLS, JSON

DLL biblioteka klasa

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/Anti-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

Project Current stable

version Release

date License

Bootstrap (client-side

framework)

3.3.7 2016-06-25 MIT, Apache

Java

Project Current stable

version Release

date License

Google Web

Toolkit

2.8.1 2017-04-24 Apache 2.0

JavaServer

Faces 2.2.8 2016-05-30

CDDL, GNU GPL 2, Apache

2.0

JBoss Seam

3.1.0 final (discontinued)

2012-01-13 GNU LGPL

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

Project Start date

Current

stable version

Release date License

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

Pro

ject

Language

Ajax

MVC

framewo

rk

M

VC p

us

h-pul

l

i1

8n

& L10

n?

ORM

Testing

framework(

s)

DB migrati

onframework(

s)

Security

framework(s

)

Template

framework(s

)

Cac

hing

framewor

k(s)

Form

validati

on frame

work(s)

Ap

ache

Click

Java jQu

ery

Page orien

ted

Pu

ll

Ye

s

Hibernate, Ca

yenne

Yes

pluggab

le

Velocity

, JSP

Cac

hed tem

plates

Built

-in valid

ation

Apach

e OFBiz

Java, Groovy,

XML,

jQuery

Yes

Push

-pull

Yes

Entity

Engine (Intern

al kind of

ORM,

not really

ORM, notably

JUnit

Entity

Engine Tools,

Data File

Tool,

CSV Parser,

Apache POI

Internal Securit

y framew

ork

based on

OWASP

Freema

rker (Recom

mended),

Velocity

(Support

Available), JSP

Inte

rnal Cac

he Maintena

nce with

Distribut

Serv

er side

validation,

Client

Side Vali

used

by Atlassi

an Jira)

(Suppor

t Availabl

e)

ed

Cache

Clearing for

clusters

dati

on (JQu

ery)

Apache

Sling

Java Yes Yes

Push-

pull

Uses JCR content

repository

Yes Yes Yes

Apache

Struts

Java Yes Yes

Push-

pull

Yes

Yes Unit tests

Yes

Yes

Ap

ache

Tapestry

Java

Prot

otype,

jQu

ery

Yes Pu

ll

Ye

s

JPA, Hibernat

e, Cayenne

Selenium, Tes

tNG, JUnit

Spring Security, Shiro

Yes

with exte

nsions

Native

or Bean Vali

dation

Apach

e Wic

ket

Java

Exte

nsions for

YUI, Ext

JS, mor

e

No (Modular

event-

driven)

Pu

ll

Ye

s

with

extensions

Mock objects, unit

and integra

tion tests via

extension

Yes Yes Yes Yes

For

mEngine

Java Yes

Yes

own connec

tor API

Ajax validatio

n on serv

er and form

state

update

Grails

Groovy

Yes Yes Push

Yes

GORM,

Hibernate

Unit

tests, integrat

ion

multiple

plugins: autobas

e,

Spring

Security,[60]A

pache

Yes Yes Yes

test, fu

nctional test

dbmigr

ate, more

Shiro[6

1]

Its

Nat

Java Yes

event

driven

Pu

sh

using

Java

i18n

extern

al, built-in

pluggab

le

pure

HTML-SVG

page

caching

nor

mal Java

JavaSe

rver

Faces

Java Yes Yes Pull

Yes

JPA, Hi

bernateand any

other Java

EE ORM

framework

JUnit

Yes

Facelets, JSP

Yes

Nati

ve valid

ators,

inte

gration

with Bea

n Validati

on

Projec

t

Language

Ajax

MVC

framewo

rk

M

VC p

us

h-pul

l

i1

8n &

L10

n?

ORM

Testing

frame

work(s)

DB migrationfram

ework(s)

Security

frame

work(s)

Template

frame

work(s)

Cac

hing

fra

mewor

k(s)

Form

validation

frame

work(s)

JBo

ss Sea

m

Java Yes Yes Pull

Yes

JPA,

Hibernate

JUnit, TestNG

JAASint

egration, Drool

s,

Hibernate

Filters, OpenID, CAPTC

HA

Facelets

JBoss

Cache,

Ehcache

Hibernat

e Vali

dator

Jspx-

bay

Java Yes Page orien

ted

Own

API

JAAS integrat

ion

Master-content

pages

Yes,

Internal UI

validatio

n cont

rols

JVx WebUI

Java Yes

Model

Driven

Ye

s

Yes, plugga

ble JUnit

Yes

Single sourcing

Yes, plug

gable

JWt

Java Yes Yes

Pu

sh-

pull

Yes

Yes Yes

Yes

OpenXav

a

Java Yes

Model

Drive

n

Yes

JPA, Hibern

ate, EJB2 CMP

JUnit Hibernate tools

uses JSR-

168 portal

security

UI is automa

tically generated

uses

portal

and JPA cach

ing

Yes

Pla

y

Java,

Scala Yes Yes

Push

-p

ull

Ye

s

JPA,

Hibernate

JUnit,

Selenium

Yes

via Core

Security

module

Yes Yes

Serv

er-side

validation

RIF

E

Java DW

R

Yes

Pu

sh-p

ull

Ye

s Yes

Out of contain

er testing

Yes Yes

Integrati

on with Terr

acotta

Yes

Spr

ing

Java Yes Yes Pu

sh

Ye

s

Hibernate,

iBatis, more

Mock objects

, unit tests

Spring Securit

y(formerly

Acegi)

JSP, Commo

ns Tiles, V

elocity, Thymel

eaf,

more

Ehcache,

more

Common

s

validator,

Bean

Vali

dation

Stripes

Java Yes Yes Pull

Yes

JPA,

Hibernate

Yes

framework

extensi

on

Yes

Yes

Vaadin

Java GW

T

Pu

sh-p

ull

Ye

s Yes Yes

Yes

Yes

Wa Java Doj Yes Pu D Hibern JUnit Hiberna Spring Dojo Dojo Reg

ve

maker

Scrip

t(client),

Java (server)

o

Toolkit

sh oj

o To

olkit

ate te Securit

y (former

ly Acegi),

role-

based access

control

Toolkit Tool

kit

ular

expressi

on, schema-

driven

validation

Projec

t

Lang

uage

Aja

x

MVCfram

ework

MV

C pu

sh-

pul

l

i18

n &

L10n?

ORM

Testin

g frame

work(s)

DB

migrationfram

ework(s)

Securit

y frame

work(s)

Templ

ate frame

work(s)

Cachin

g fra

mework(s)

Form

vali

dation

framewor

k(s)

WebO

bjects

Java Yes Yes

Pu

sh-

pull

Ye

s EOF

WOUnit

(JUnit), TestNG

, Seleniu

m

in Project

WONDER

Yes Yes Yes

zte

mplates

Java JDK

1.5 or newe

r

inte

grates

YUI,

Google,

etc., with

annotations

Yes

Push

, mul

tipl

e acti

ons

per U

RL

stan

dard Ja

va

use any

J2EE ORM

framew

ork

Unit tests

annotation

based

Velocity, FreeM

arker, JSP,

others pluggab

le

Ajax

validatio

n on server

and form

state

update (YUI

, JSON)

Googl

e We

b Toolkit

Java, Java

Script

Yes

Ye

s

JPA

with Reques

tFactory

JUnit

(too early), jsUnit(t

oo difficult

), Seleniu

via Java Yes

Bea

n Vali

dation

m

(best)

ZK

Java,

ZUML

jQu

ery

Yes

Pu

sh-p

ull

Ye

s

any

J2EE ORM

framew

ork

JUnit,

ZATS

HibernateUtil,

SpringUtil

Spring Securit

y

Macro

components & compos

ition

Yes

client,

server

JavaScript

Proj

ect

Aj

ax

MVCframew

ork

MV

C pu

sh-

pu

ll

i1

8n &

L10n?

ORM

Testin

g framework(

s)

DB migrationf

ramework(s)

Securi

ty framework(

s)

Templ

ate framework(

s)

Caching framework(s)

Form

validation

framework(

s)

Ang

ularJS

XHR,

JSONP

Yes

i1

8n and

l10n

Karma

(unit testing

), Protractor

(end-to-end

testing)

Conte

nt Securit

y Policy (CSP),

XSRF

Templates

Caching

Form validat

ion (client-side)

Emb

erJS

Ye

s Yes

Ye

s

E

mbe

r Data

QUnit

Handle

bars

qoox

doo

Ye

s

Data

binding

i1

8n

Testru

nner

Form Validat

ion

SproutCo

re

Yes

Yes

Wakanda

Yes

Yes

Push

& Pull

Na

tive

Ob

ject

NoSQL

DB

CommonJS Unit

Testing YUI

Test Servic

e

Data Securit

y and Access

Control

Storage (application.stora

ge, user.stor

age, SessionStorage)

PHP

Project

Lan

gu

age

Ajax

MVCfram

ework

M

VC

pus

h-

pull

i18

n & L

10

n?

ORM

Testing framew

ork(s)

DB migr

ationfram

ework(s)

Security

frame

work(s)

Template

frame

work(s)

Caching

frame

work(s)

Form valid

ation fram

ework(s)

Scaffo

lding

RA

D

Mobil

ity

Cake

PHP 3

PH

P >

= 5.6[

62]

Any

Yes

Y

es,

Pu

sh &

Ce

lls

Yes

ORM, Dat

a Map

per Patte

rn, SQL Relat

ional Alge

braAbstraction

Layer

Unit tests, object

mocking, fixtures,

code coverage

, memory analysis

with PHPUnit and

Xdebug and Continuous

Integration via Tr

avis

Yes

CR

UD bas

ed, AC

L-based,

Multipl

e Plugin

s

Themes

, Layouts

, Cell

s, Vie

ws, Elemen

ts, Plug

ins for Twi

g, Boots

trap,

etc.

Memcache, Redi

s, XCache, APC

, File

Validation

via Conte

xts (Table

(DAO),

Entity

(VO) &

Controller), CSRF

Protection

Pl

ugin CR

UD

Ca

ke B

ak

e

Mobil

e Ag

ent Detec

tion,

Layouts

CodeIgnit

er

PH

P >=

5.6.

0[63]

An

y Yes

Pu

sh

Mostl

y[6

4]

Third party

only

Ready for next

release

Yes Yes Yes Yes Yes No[6

5]

Ye

s

Temp

lates

Drupal

P

HP

jQuery

, jQuery

UI, mo

re

PAC

N

/A

Yes

Optional mod

ule

SimpleTest

Yes Yes Yes

Memcache,

APC, Varnish,

more

Yes No No

Yes

Fat- P An MV P Ye Data Built-in Yes Yes Yes APC, Yes No ? ?

Free

Framewor

k

H

P

y C,

RMR

u

sh

-pu

ll

s map

pers for

SQL, MongoD

B, Flat-

File

Memcac

he, XCache,

WinCache, and Filesyst

em

Fuel

PHP

PH

P >

= 5.3.

x

Yes

MVC,

HMVC

Pu

sh

Ye

s Yes PHPUnit Yes

Yes,

Plugin

s availab

le

Yes,

Plugins

available

File, Re

dis, Memcac

he,

more

Yes Ye

s ? ?

Fuse

box

PHP

Yes

Not

mandator

y

Pu

sh

N

o, cu

stom

? ? ?

Mul

tiple

plugins

availab

le

? ?

via qform

s or built

in PHP

valida

tion

Ye

s ? ?

Gyroscop

e

PH

P >

=5.4

nan

o.js,

replaceab

le[66]

LCHH

P

us

h-p

ull

M

ostly

Data-

source

agno

stic

No

Built-in

Schema

comparison tool

and UDF

editor

AC

L-bas

ed, replac

eable

Impleme

ntation-spec

ific; help

er func

tions

and

theme

templates

availabl

e

APC, Memcac

he

Yes

In

teractiv

e co

de gene

rator

Ye

s

Dedic

ated

mobile

and

tablet lay

outs,

landscap

e-por

trait

tra

nsfor

mation

Joo

mla

? Yes Plu

gin ? ? ? ? ? ? ? ? ? ? ? ?

Kajona

P

HP >

= 7

Any

Yes

Pus

h

Yes

Yes

PHPUnit,

Selenium, Jasmine

Yes Yes Yes

APC,

Database, File

Yes Yes

Y

es

Bootstra

p

Laravel

PHP

>=

5.5.9

Any

Yes

P

us

h

Yes

Yes PHPUnit Yes Yes Yes

APC, Databas

e, File, Me

mcache, Redis

Yes Yes

Y

es

No

Li3 (

Lithium)

PHP

>=

5.3.6

Any

Yes

P

us

h

Yes

Yes

Unit tests,

builtin test

framework or other

independent

No

Yes,

Plu

gins

available

PHP

, TwigPl

ugin availabl

e

Memcache, Redi

s, XCache, APC

, File

Yes, with C

SRFProtecti

on and

Form

Signing

No

Y

es

?

Nette Fram

ework

PHP

>=

5.3.0

Too

lkit-

ind

epende

nt

MVP

P

us

h

Yes

Third party

only

Yes No Yes Yes Yes Yes No ? ?

Phal

con

PH

P >=

5.5

An

y Yes

Pu

sh

Ye

s Yes Yes Yes Yes Volt Yes Yes

Ye

s

Yes

?

Pop PHP

PHP

>=

5.6.0

Any

Yes

P

us

h

Yes

Yes PHPUnit Yes

AC

L-bas

ed

Yes

APC,

Database,

File, Memcache, Redis,

Session

Yes ?

Y

es

?

PRADO

PH

P

Protot

ype

No Pu

s

Yes

Data acce

ss

PHPUnit, SimpleTe

st, Seleni

No Yes XML

-

bas

APC, Databas

e, eAcce

Yes[69]

Yes[

70

? ?

>

= 5.

3.0

,

script.

aculo.us,

own

compone

nts[67

]

h

-p

ull

obje

cts(DAO),

active

recor

d patte

rn, SQLMap

data map

per

um ed,

similar

to ASP.NET

s[68]

lerator,

Memcached,

XCache

]

Silve

rStripe(Sapph

ire)

PH

P >=

5.2

jQu

ery,

jQuery

UI

Yes

Pu

sh

-p

ull

Ye

s

Activ

e recor

d patte

rn

Unit tests, Sel

enium

Auto

matic

incl

. OpenI

D

The

mes Yes Yes

Ye

s

Yes

Ye

s

Silex

P

HP

>= 5.

3.9

Yes Yes Ye

s

Yes

Plugin

exists

(Doctrine

)

Yes No Yes PHP, Tw

ig

Plugin exists

Yes

Plug

in exist

s

? ?

Sma

rt.Frame

work

PHP

>=

5.4.9

Yes Yes

Y

es

Yes

Yes (Post

greSQL,

MySQL, SQLi

te, Mon

goDB,

Solr,

others via

plugins)

Yes No Yes

Yes

(Markers, T

wig, othe

rs via plug

ins)

Yes (File,

Redis, others

via plugins)

Yes No

Y

es

Yes, (jQ

uery

mobile,

Boots

trap, oth

ers via

plugins)

Symf

ony

PH

P 5

Protot

ype,

Yes

Pu

sh

Ye

s

Propel, D

octrine(Y

Yes

Plugin exists

(alpha

Plu

gin

PHP, Twig

Yes Yes Ye

s ? ?

scri

pt.acu

lo.us, Un

obtrusi

ve Ajax

with

UJS and PJS

plugin

s

AML) code)

Symfony 2

P

HP >

= 5.

3.3

An

y Yes

Pu

sh

Ye

s

Prop

el, Doctrine(Y

AML)

Yes Plugin

exists Yes

PHP, Twig

Yes Yes Ye

s ? ?

TwistPHP

P

HP

>= 5.

3.3

Any

Yes

P

ush

Yes

Yes PHPUnit via Travi

s

No Yes Yes Yes Yes No ? ?

TYPO3

P

HP >

= 5.

5

Any

Yes

P

us

h-p

ull

Yes

Yes Yes Partia

l Yes

TYP

O3 Fluid

Yes Yes

Plug

in exist

s

Plu

gi

n ex

is

ts

?

Yii

P

HP

>=

jQu

ery,

jQuery

Yes

P

us

h-

Yes

Data

Access

Objects

PHPUnit, Selenium

Yes

AC

L-bas

ed, RB

PHP

-bas

ed, PRA

APC,

Database,

eAccelerator,

Yes

Ye

s[71]

? ?

5.

4

UI,

own

compone

nts,

plugins

p

ull

(DA

O), Activ

e Record

Pattern,

Plugins

(incl.

Doctrine

2.0)

AC

-bas

ed, plugin

s

DO-

like, plug

ins

File,

Memcache,

Redis, WinCac

he,

XCache, Zend

Platform

Zend Framewor

k[72]

P

HP >

= 5.

3

Too

lkit-

ind

epende

nt

Yes

P

us

h-

pull

Yes

Table

and row

data gate

way or

Doct

rine

Unit tests,

PHP Unit or other

independent

Yes

AC

L-bas

ed

Yes

APC,

Database, File, Memcac

he, Zend

Platform

Yes Yes

? ?

Zend Framewor

k 2

PH

P >=

5.3.

3

Too

lkit-

independe

nt

Yes

Pu

sh-

pu

ll

Yes

Tabl

e and row

data gate

way and Doct

rine 2.0

for Zend Fram

ework 2.0

Unit

tests, PHP Unit or other

independent

Yes

ACL-

bas

ed

Yes

APC,

Database, File,

Memcache, Zen

d

Platform

Yes Yes

? ?

Python

Project

Language

Ajax

MVCframew

ork

M

VC

push-

pul

l

i18n &

L10n

?

ORM

Testi

ng framework

(s)

DB migration

framework(s)

Secur

ity framework

(s)

Temp

late framework

(s)

Cachi

ng framework

(s)

Form validation

framework

(s)

Py

thon 3.

*

Dj Pyth Y Yes Pu Ye Y Yes Yes Yes built- Yes Yes Ye

an

go

on e

s

sh s e

s

in,

Jinja2, Mako,

Cheetah

s

Ruby

Proj

ect

Ajax

MVCframewor

k

MVC

pu

sh-p

ull

i1

8n

& L1

0n

?

OR

M

Testi

ng framewor

k(s)

DB migratio

nframework(s)

Secu

rity framewor

k(s)

Tem

plate framewor

k(s)

Cachi

ng framewor

k(s)

Form

validation

framework(s)

Ruby on

Rails

Prototype, script.aculo.u

s, jQuery

ActiveR

ecord, Action Pack

Push

Yes

ActiveRec

ord

Unit Tests,

Functional Tests

and Integ

ration Tests

Yes Plug-

in Yes Yes Yes

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.