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.