SVEUILITE

UI

ZAGREBUI NFORMATIKE

F AKULTET O RGANIZACIJE

Nikola Cika

OBLIKOVANJE SUSTAVA ZA VOENJE PROIZVODNOG PROCESA NA TEMELJU PROGRAMSKIH KOMPONENATA- Magistarski rad -

Varadin, 2000.

PODACI O MAGISTARSKOM RADUI. AutorIme i Prezime Datum i mjesto roenja Naziv fakulteta i datum diplomiranja Sadanje zaposlenje Nikola Cika 18. travnja 1975., Varadin Fakultet Organizacije i Informatike, 16. travanj 1998. Vindija d.d. - prehrambena industrija, Varadin

II. Magistarski radNaslov Broj stranica, slika, tabela, priloga, bibliografskih priloga Znanstveno podruje, smjer i disciplina iz koje je postignut akademski stupanj Mentor ili voditelj rada Fakultet na kojem je rad obranjen Oznaka i redni broj rada Oblikovanje sustava za voenje proizvodnog procesa na temelju programskih komponenata 134 stranice, 44 slike, 3 tabele, 1 prilog podruje: Informacijske znanosti smjer: Informacijsko i programsko inenjerstvo Prof. dr. sc. Josip Brumec Sveuilite u Zagrebu Fakultet Organizacije i Informatike Varadin

III. Ocjena i obranaDatum prihvaanja teme od Znanstveno-nastavnog vijea Datum predaje rada Datum sjednice ZNV-a na kojoj je prihvaena pozitivna ocjena rada Sastav povjerenstva koje je rad ocijenilo Datum obrane rada Sastav Povjerenstva pred kojim je rad obranjen Datum promocije

SVEUILITE

UI

ZAGREBUI NFORMATIKE

F AKULTET O RGANIZACIJE

Nikola Cika

OBLIKOVANJE SUSTAVA ZA VOENJE PROIZVODNOG PROCESA NA TEMELJU PROGRAMSKIH KOMPONENATA- Magistarski rad -

Varadin, 2000.

Bazina dokumentacijska kartica na hrvatskom jeziku MRIZ (FOI-Sveuilite Zagreb) Magistarski rad UDK: 658.5:681.3.06(043.2)

Oblikovanje sustava za voenje proizvodnog procesa na temelju programskih komponenataN. Cika Fakultet Organizacije i Informatike, Varadin, Hrvatska Kompleksni informacijski sustavi budunosti moi e se prikazati strukturom modularnog tipa. Modularnost IS-a moe se lako postii primjenom programskih komponenata u odreenim fazama izrade informacijskog sustava. Podruje u kojem su programske komponente posebno interesantne iz vie razloga je podruje informacijskih sustava proizvodnje. IS proizvodnje je specifian (gotovo unikatan) za svako pojedino proizvodno poduzee i nije mogue jedan sustav proizvodnje direktno preslikati i primijeniti u drugom proizvodnom poduzeu. Zbog toga i zbog dinaminosti promjena u proizvodnom procesu izmjene informacijskog sustava proizvodnje moraju biti brze. Detaljnije se opisuju sustavi izvravanja proizvodnje, njegove funkcije, metodike izrade i naini primjene. Primjena programskih komponenata pri izgradnji informacijskih sustava proizvodnje rezultira pozitivnim efektima koji su objanjeni u ovom radu. Osim opsene rasprave o sustavima izvravanja proizvodnje, panja je posveena i programskim komponenta, izvrena je njihova klasifikacija, izloeni su naini koritenja (predloci, vieslojne arhitekture, metodike razvoja). Na kraju rada je izraen primjer sustava izvravanja proizvodnje u metalo-preraivakom poduzeu. Voditelj rada: Prof. dr. sc. J. Brumec Povjerenstvo za ocjenu i obranu: Obrana: Promocija:

Rad je pohranjen u Biblioteci Fakulteta organizacije i informatike u Varadinu. (134 stranice, 44 slike, 3 tablice, 1 prilog, 41 bibliografski podatak, original na hrvatskom jeziku). N. Cika

MRIZ-2 1. Oblikovanje sustava za voenje proizvodnog procesa na temelju programskih komponenata I. Cika, N. II. Fakultet organizacije i informatike, Varadin, Hrvatska

UDK: 658.5:681.3.06(043.2) Proizvodnja Sustavi izvravanja proizvodnje Programske komponente Predloci Metodika

Bazina dokumentacijska kartica na engleskom jeziku MRIZ-2 (FOI-Univ. Zagreb) Master of Science Thesis UD 658.5:681.3.06(043.2)

Designing systems for execution of manufacturing process based on programming componentsN. Cika Faculty of Organization and Informatics, Varadin, Croatia Structure of complex information systems of the future is modular. Modularity of IS can be easily achieved by using software components in phases of information system development process. Manufacturing information systems are domain in which use of software components is especially interesting because of positive effects of their use. Manufacturing information system is specific (almost unique) for each manufacturing company and it is not possible to use manufacturing IS of one factory in another without some customization. Because of the previous reason and because of dynamic changes in manufacturing process development and customization of manufacturing information system must be fast. Manufacturing Execution Systems (MES) are more specific analyzed and its functions are described, development methodologies and examples of real-world use are shown. Using software components when developing manufacturing information systems results with positive effects that are analyzed in this text. Text does not describe only MES systems, attention was given also to software components, classification and guidelines for real-world work (frameworks, multi-tier architectures, development methodologies) were proposed to. At the end, there is also an example of MES system for metal-manufacturing company. Supervisor: Prof. dr. J. Brumec Examiners: Oral examination: The thesis deposited at the Library of the Faculty of Organization and Informatics, Varadin. ( 134 pages, 44 fig, 3 tables, 1 appendix, 41 references, original in Croatian). N. Cika

MRIZ-2 1. Designing systems for execution of manufacturing process based on programming components I. Cika, N. II. Faculty of Organization and Informatics, Varadin, Croatia

UD 658.5:681.3.06(043.2) Production Manufacturing execution systems Software components Frameworks Methodology

SADRAJ

1. Uvod...............................................................................................1 2. Programska komponenta .............................................................72.1. Podjela ...................................................................................................................9 2.2. Karakteristike programskih komponenata.................................................132.2.1 Izvrni oblik............................................................................................................... 13 2.2.2 Suelje ....................................................................................................................... 14 2.2.3 Zatita programskog koda ................................................................................... 15 2.2.4 Viestruko koritenje ............................................................................................. 16 2.2.4.1 Razvoj viestrukim koritenjem .............................................................16 2.2.4.2 Razvoj za viestruko koritenje .............................................................18 2.2.4.3 Viestruko koritenje programskih sustava .........................................20 2.2.5 Ostale karakteristike programskih komponenata ......................................... 24

2.3. Okolina komponente - programski meusloj ............................................25 2.4. Pravni aspekti upotrebe komponenata.......................................................30 2.5. Primjena...............................................................................................................32

3. Metodike komponentama usmjerenog programiranja .............353.1. Metodika "SELECT Perspective" .................................................................363.1.1 Razvoj komponenata ............................................................................................ 38 3.1.2 Razvoj gotovog rjeenja....................................................................................... 41

3.2. CSLA metodika..................................................................................................423.2.1 Komponente ope namjene ................................................................................ 43 3.2.2 Komponente specifine za pojedinu aplikaciju.............................................. 44 3.2.3 Komponente specifine za pojedinu industriju .............................................. 44 3.2.4 Modeli aplikacija ..................................................................................................... 45 3.2.4.1 Jednoslojne aplikacije .............................................................................45 3.2.4.2 Dvoslojni korisnik/posluitelj...................................................................47 3.2.4.3 Troslojni korisnik/posluitelj....................................................................49 3.2.4.4 Mreni pretraivai...................................................................................52

4. Sustavi izvravanja proizvodnje ................................................544.1. Proizvodni sustavi.............................................................................................54 4.2. Openito o SIP sustavima..............................................................................57 4.3. Osnovne funkcije ..............................................................................................614.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 Suelje prema sustavu planiranja ..................................................................... 62 Upravljanje radnim nalozima .............................................................................. 62 Upravljanje radnim mjestima .............................................................................. 63 Praenje opreme u upotrebi................................................................................ 65 Upravljanje kretanjem materijala ....................................................................... 65 Prikupljanje podataka u proizvodnji .................................................................. 66 Upravljanje iznimkama i neoekivanim dogaajima.................................... 66

ii 4.4. Sporedne funkcije .............................................................................................674.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.4.8 Nadzor odravanja................................................................................................. 67 Prisustvovanje radu ............................................................................................... 68 Statistika kontrola procesa ................................................................................ 69 Osiguranje kvalitete ............................................................................................... 69 Analiza performansi proizvodnih procesa....................................................... 69 Dokumentacija i specifikacije.............................................................................. 70 Sljedivost proizvoda............................................................................................... 71 Evidencija dobavljaa ........................................................................................... 71

4.5. Prednosti koritenja SIP sustava .................................................................74 4.6. Metodika razvoja SIP sustava.......................................................................75 4.7. Primjena programskih sustava u proizvodnji............................................75

5. Predloci......................................................................................775.1. Povijest predloaka ..........................................................................................79 5.2. Aktivni dokumenti..............................................................................................80 5.3. SemaTech CIM Framework...........................................................................825.3.1 5.3.2 5.3.3 5.3.4 Arhitektura ................................................................................................................ 83 Arhitektura zadataka ............................................................................................. 84 Notacija predloaka ............................................................................................... 87 Primjena .................................................................................................................... 93

6. Evaluacija komponenata ............................................................996.1. Stanja sustava baziranih na komponentama ...........................................996.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 Trite komponentama ....................................................................................... 100 Izbor komponenata .............................................................................................. 101 Adaptacija komponenata ................................................................................... 101 Povezivanje komponenata ................................................................................ 102 Nadograivanje..................................................................................................... 102 Formativna evaluacija......................................................................................... 103 Evaluacija cjelovitosti .......................................................................................... 104 Kontinuirana evaluacija ...................................................................................... 105 Poslovna evaluacija............................................................................................. 107 Istraivaka evaluacija........................................................................................ 108

6.2. Odluivanje u kontekstu odabira programskih komponenata ...........102

7. Prijedlog upotrebe programskih komponenata ......................1097.1. Metodika razvoja SIP sustava.....................................................................1097.1.1 Tehnika razvoja SIP sustava na temelju komponenata ........................... 110 7.1.2 Tehnika razvoja programske komponente ................................................... 112 7.1.3 Infrastruktura potrebna za razvoj SIP sustava ............................................ 114

7.2. Primjer ................................................................................................................1167.2.1 Povijest poduzea ................................................................................................ 117 7.2.2 Trenutno stanje ..................................................................................................... 117 7.2.2.1 Organizacijska struktura .......................................................................118 7.2.2.2 Opis Proizvodnog procesa ...................................................................119

iii7.2.3 Zahtjevi menadmenta ....................................................................................... 119 7.2.4 Rjeenje .................................................................................................................. 120

8. Zakljuak ...................................................................................126 9. Literatura ...................................................................................129 10. Prilog .........................................................................................13310.1. Programske kue proizvoai SIP sustava.............................................133

iv

Kratice i strane rijeiKratica/PrijevodADO (ActiveX Data Object) ASP (Active Server pages) BOM (Bill of Materials) Button CNC (Computer Numerical Control) COM (Component Object Model) COM+ ComboBox Component Connection Container COP (Component-Oriented Programming) COP (Component-Oriented Programming) CORBA (Common Object Request Broker Architecture) CPI-C CSLA (Component-Based Scalable Logical Architecture) DAO (Data Access Object) DataGrid DCE RPC (Distributed Computing Environment remote procedure call) DCOM (Distributed COM) DCS (Distributed control system) DHTML (Dynamic Hypertext Markup Language) DLL (Dynamic Linked Library) DNC (Distributed numerical control) DSOM (Distributed System Object Model) EJB (Enterprise Java Beans) ERP (Enterprise resource planning) Framework GUID (Global Unique Identifier) IDL (Interface definition language) IIS (Internet Information Server) In-Proc Server Interface ISP JAD (Joint Application Development) JAD (Joint Application Development) JavaBeans Library MES (Manufacturing Execution System) MFC (Microsoft Foundation Classes) MOM (Message-Oriented Middleware) MRP II MSMQ (Microsoft Message Queue) MTS (Microsoft Transaction Server) NDR

OpisProgramski modul za pristup podacima. Jezik za definiranje aktivnih mrenih stranica Sastavnica. Programska komponenta grafikog korisnikog suelja. Koncept vezan uz proizvodne sustave. Model komponenata i objekata. Zadnja verzija COM-a. Programska komponenta grafikog korisnikog suelja. Programska komponenta. Spojnica Spremnik programskih komponenata. Komponentama-orijentirano programiranje. Programiranje temeljeno na programskim komponentama. Opa arhitektura posrednika zahtjeva za objektima IBM-ov protokol za komunikaciju Metodika razvoja vieslojnih programskih sustava. Programski modul za pristup podacima. Programska komponenta grafikog korisnikog suelja. API za udaljeno pozivanje procedura organizacije Open Software Foundation (OSF) Distribuirani COM. Koncept vezan uz proizvodne sustave. Jezik za definiranje multimedijskog sadraja. Biblioteka sa izvrnim procedurama. Koncept vezan uz proizvodne sustave. Model komponenata i objekata koji je izradio IBM. Programske komponente poduzea SUN. Koncept vezan uz planiranje proizvodnje. Predloak. Jedinstveni identifikator; moe identificirati programsku komponentu, klasu, objekt, suelje, itd. Jezik za definiranje suelja. Mreni (web) posluitelj poduzea Microsoft. Programska komponenta koja se izvrava u memorijskom odjeljku matinog programa. Ugovor. Informacijski sustav proizvodnje Tehnika razvoja programskog sustava Tehnika razvoja programskih sustava. Programske komponente poduzea SUN. Programska biblioteka Sustav izvravanja proizvodnje Predloak sa razliitim pomonim klasama. Meusloj temeljen na porukama Koncept vezan uz planiranje proizvodnje. Microsoftov protokol za razmjenu programskih poruka Transakcijski posluitelj poduzea Microsoft Neutralno prosljeivanje argumenata i parametara

v Kratica/PrijevodOCX ODBC OLE (Object Linking and Embedding) OLEDB OMG (Object Management Group) OO RPC (Object-oriented remote procedure call) OpenDOC OSF (Open Software Foundation) Out-of-Proc Server Overhead P/PE (Product and process engineering) Pattern PLC (Programmable logic controllers) RAAD (Rapid Architected Application Development) Reusability RPC (Remote procedure call) SCADA (Supervisory control and data aquisition) SCM (Supply chain management) Script language Server SIP SPP SSM (Sales and service management) TCI (Total cost of investment) TCO (Total cost of ownership) TCP/IP TextBox TP (Transaction Processing) Monitor Transaction Server VB VBX VC++ WIP (Work-in-process)

OpisEkstenzija datoteke u kojoj se nalazi 32-bitna programska komponenta u izvrnom obliku. Programski modul za pristup podacima. Objektno-orijentirana tehnologija namjenjena razvoju viestruko upotrebljivih programskih komponenata. Programski modul za pristup podacima. Organizacija koja promovira objektne tehnologije Objektno orijentirani poziv udaljenih procedura Predloak namijenjen korisnikom suelju. Udruenje. Programska komponenta koja se izvrava izvan memorijskog odjeljka matinog programa. Dodatno iskoritavanje resursa iznad prvotno planiranih procjena potrebe za resursima. Koncept vezan uz proizvodne sustave. Uzorak Koncept vezan uz proizvodne sustave. Brzi razvoj aplikacije. Viestruko koritenje Udaljeno pozivanje procedure Koncept vezan uz proizvodne sustave. Koncept vezan uz poslovne sustave. Priruni programski jezik. Posluitelj. Sustav izvravanja proizvodnje. Sustav planiranja proizvodnje Koncept vezan uz poslovne sustave. Ukupna cijena ulaganja. Ukupna cijena posjedovanja. Mreni protokol Programska komponenta grafikog korisnikog suelja. Modul koji nadgleda rad transakcijskog sloja Transakcijski Posluitelj. Visual Basic; razvojno programsko okruenje. Ekstenzija datoteke u kojoj se nalazi 16-bitna programska komponenta u izvrnom obliku. Visual C++; razvojno programsko okruenje. Poslovi u toku.

Tabela 1 - Popis kratica i stranih rijei

Popis slikaSlika 1 - Pristupi izradi informacijskog sustava proizvodnje............................................................ 4 Slika 2 - Klasifikacija programskih komponenata ............................................................................. 10 Slika 3 - Microsoft-ov Visual Component Manager.......................................................................... 19 Slika 4 - Odnos izmeu napravi-sve i kupi-sve pristupa [Szyp98] ............................................. 22 Slika 5 Zavisnost korisnosti i robustnosti o outsourcing-u [Szyp98] ....................................... 22 Slika 6 - Komunikacija komponenata pomou redova ekanja [Edwa97] ................................ 24 Slika 7 - Spojne toke komponenata (DCOM)................................................................................... 25

viSlika 8 - Stroga vieslojna arhitektura [Szyp98]................................................................................ 26 Slika 9 - Proirena stroga vieslojna arhitektura [Szyp98] ............................................................ 26 Slika 10 - Slobodna vieslojna arhitektura[Szyp98]......................................................................... 27 Slika 11 - Povezanost procesa razvoja gotovog rjeenja i procesa razvoja programske komponente [AllFro98] ............................................................................................................. 37 Slika 12 - Uinak stupnja formalnosti na izradu programskog proizvoda [AllFro98] ............ 40 Slika 13 - Primjer uporabe programske komponente Mreni Pretraiva u Visual Basic-u43 Slika 14 - Primjena specifine procedure PMT (izraun rate kredita) u programskom paketu Microsoft Office 2000 ................................................................................................. 44 Slika 15 - Primjer upotrebe procedure iz prethodnog primjera u programskom jeziku Visual Basic .............................................................................................................................................. 45 Slika 16 - Raspored komponenata u aplikaciji sa jednoslojnom arhitekturom ....................... 45 Slika 17 - Raspored komponenata u aplikaciji sa dvoslojnom korisnik/posluitelj arhitekturom................................................................................................................................. 47 Slika 18 - Raspored komponenata u aplikaciji sa troslojnom korisnik/posluitelj arhitekturom................................................................................................................................. 50 Slika 19 - Raspored komponenata u aplikaciji tipa mreni pretraiva (engl. web browser) ......................................................................................................................................................... 52 Slika 20 - Hijerarhija informacijskih sustava vezanih uz proizvodnju ......................................... 57 Slika 21 - Prikaz tehnologija primijenjenih u postojeim SIP sustavima [MESA-97d]........... 60 Slika 22 - Prikaz tehnologija koje e se primjenjivati u SIP sustavima budunosti [MESA97d]................................................................................................................................................. 60 Slika 23 - Prikaz razmjene podataka izmeu MRPII i SIP sustava [MESA-97b].................... 72 Slika 24 - Prikaz razmjene podataka izmeu SIP sustava i sustava nadzora proizvodnje (kontrolori u pogonu) [MESA-95] .......................................................................................... 73 Slika 25 - Uloga SIP sustava unutar poduzea (dijagram razmjene podataka) [MESA-95] 73 Slika 26 - Hijerarhijski model resursa proizvodnog poduzea (po CIM Framework-u)......... 85 Slika 27 - Hijerarhija strukture zadatka [SEMA-99].......................................................................... 86 Slika 28 - Model odnosa komponenata ............................................................................................... 87 Slika 29 Informacijski model komponenata .................................................................................... 87 Slika 30 Dijagram interakcije komponenata.................................................................................... 88 Slika 31 - Koncepti kojima se prikazuje dinamika objekta ............................................................. 88 Slika 32 Primjer dijagrama koritenja (UML) .................................................................................. 90 Slika 33 - Primjer dijagrama klasa (UML)............................................................................................ 91 Slika 34 - Model odnosa komponenata u modulu FactoryLabor (CIM Framework) .............. 96 Slika 35 - Informacijski model komponente PersonManagement (CIM Framework) ........... 97 Slika 36 - Model dinamike objekta Person (CIM Framework) ...................................................... 97 Slika 37 - Faze razvoja sustava baziranog na programskim komponentama ......................... 99 Slika 38 - Elementi odluivanja u projektu ........................................................................................ 103 Slika 39 - Mogui redoslijed razvoja i evaluacije sustava baziranog na komponentama .. 106 Slika 40 - Faze razvoja SIP sustava na temelju programskih komponenata......................... 110 Slika 41 - Model infrastrukture potrebne za izgradnju SIP sustava .......................................... 114 Slika 42 - Organizacijska struktura poduzea OMEGA d.o.o..................................................... 118 Slika 43 - Logika arhitektura funkcioniranja sustava izvravanja proizvodnje..................... 121 Slika 44 - Izvedba SIP sustava po slojevima ................................................................................... 123

1

1. UvodProizvodni proces je proces koji stvara novu materijalnu vrijednost. Bez obzira na visok stupanj informatizacije i automatizacije koji e u budunosti biti prisutni u poslovnom svijetu, proizvodnja e kao proces uvijek postojati. Proces proizvodnje je kompleksan. U praktinoj se primjeni moe pronai velik broj razliitih vrsta informacijskih sustava vezanih uz proizvodnju i proizvodne procese (npr. MRP, MRP II, ERP, itd.) ija namjena je podrka i praenje proizvodnog procesa. Svaka vrsta informacijskog sustava, pa tako i onog vezanog uz proizvodnju, usmjerena je na odreenu poslovnu domenu i ima tono odreenu namjenu izvan koje teko moe posluiti svrsi. Neovisno o postojanju relativno velikog broja razliitih tipova informacijskih sustava proizvodnje (ISP), s vremenom se javila ideja da se postojea arhitektura ISP sustava doradi te da se pojedini dijelovi postojeih tipova sustava objedine u potpuno novu vrstu sustava pod nazivom sustav izvravanja proizvodnje (SIP). Zadatak sustava izvravanja proizvodnje je povezivanje operativnog dijela proizvodnje (tehnolokog procesa) i viih organizacijskih razina; gdje se teite ipak stavlja na podrku tehnolokog procesa. SIP sustave bi na prvi pogled trebalo svrstati u kategoriju sustava praenja proizvodnje ili u kategoriju sustava planiranja proizvodnje (MRP, MRP II, ERP) no postoje razlozi zbog ega takva klasifikacija ne bi bila dobra. SIP sustavi se ne mogu svrstati u sustave planiranja proizvodnje (SPP) jer SIP sustavi nisu namijenjeni planiranju ve izvravanju (podrci) proizvodnje; podatke o planu proizvodnje SIP sustavi pribavljaju od SPP sustava. Kod definiranja uloge SIP sustava posebnu pozornost treba posvetiti izvravanju. Uloga SIP sustava je aktivno praenje toka proizvodnje, a ne pasivno praenje ve dogoenog. Jedna od bitnih razlika izmeu SIP sustava i MRP sustava je i vremenska jedinica mjere koja se koristi za praenje proizvodnog procesa. Vremenska jedinica mjere u SIP sustavima je za red veliine manja od vremenske jedinice mjere u SPP sustavima. Dodatna vana razlika izmeu SIP sustava i SPP sustava je razina detalja do koje SIP sustavi idu na operativnoj razini. SIP sustavi za razliku od ostalih sustava mogu upravljati radom strojeva na temelju upravljakih programa. Vano je napomenuti da SIP sustavi nisu isto to i programski sustavi niske razine

2 (npr. SCADA, PLC, DCS, DNC, CNC, itd.) jer za razliku od navedenih sustava SIP sustavi objedinjuju raznolike sustave niske razine u jednu cjelinu i viim organizacijskim razinama ih predstavljaju kroz jedno suelje. Kategorizacija SIP sustava je izvrena na temelju genetike taksonomije izloene u [Brum97]. GTO vrijednost za SIP sustave je Rv,r,t = [2, 1, 2.5]. Razloga za takav odabir ima vie. Sustavi izvravanja proizvodnje po vrsti procesa spadaju u jasno specificirane procese sa neodreenim slijedom (engl. determined process with unexpected sequence) koji u taksonomiji poprimaju vrijednost v=2. Po razini procesa, SIP sustavi spadaju u kategoriju procesa operativne razine koji u taksonomiji imaju vrijednost r=1. Razina koritenja raunala u SIP sustavima je kombinacija dvije razine. Po karakteristikama SIP sustava se moe zakljuiti da se ne radi o neraunalnom tipu sustavu zbog toga jer rad SIP sustava nije mogu bez raunala. Obzirom na postojanje velikog broja procesa u kojima SIP sustavi sudjeluju i koriste podatke iz baza podataka, loginim se ini svrstavanje u kategoriju t=2 . S druge strane, dio procesa koji se odvijaju u SIP sustavima (npr. simuliranje toka proizvodnog procesa, optimalizacija toka proizvodnog procesa, analiza i izbjegavanje uskih grla u proizvodnji) nisu trivijalni ve se radi o kompleksnim procesima koji zahtijevaju baze znanja i koritenje umjetne inteligencije. Zbog navedenog razloga bi parametar t mogao poprimiti i vrijednost 3. Procjena autora ovog rada je da bi s obzirom na prisustvo obiju karakteristika (raunala koja koriste baze podataka i raunala koja koriste baze znanja), vrijednost parametra t trebala poprimiti vrijednost t=2.5 to taksonomija dozvoljava [Brum97]. Brumec u svojem radu ne navodi nijedan informacijski sustav sa GTO vrijednou [2, 1, 2.5] na temelju ega slijedi da SIP sustavi doista popunjavaju prazninu koja postoji u genetikoj taksonomiji informacijskih sustava. Negativni efekti koji se javljaju kod izgradnje ISP sustava, ali to je najvanije ne samo kod njih ve i kod veine drugih vrsta poslovnih informacijskih sustava) su: informacijski sustav u trenutku putanja u rad ne odgovara trenutnim (u odnosu na poetak projekta izmijenjenim) potrebama i zahtjevima poduzea, visoki trokovi razvoja, rada i odravanja (koji esto viestruko premauju poetni proraun), nefleksibilnost i glomaznost informacijskog sustava u primjeni i odravanju,

3 zatvorenost informacijskog sustava prema drugim informacijskim sustavima u okolini

Ima takvih pristupa izradi informacijskih sustava proizvodnje koji pokazuju da negativni efekti koji se javljaju kod izgradnje sustava izvravanja proizvodnje mogu dijelom biti umanjeni a neki ak i potpuno uklonjeni primjenom programskih komponenata u izgradnji takvih sustava. U radu su analizirani naini primjene, prednosti i nedostaci primjene programskih komponenata u izgradnji sustava izvravanja proizvodnje1. Programske komponente nemaju kratku povijest no jo uvijek postoje nepoznanice vezane uz primjenu programskih komponenata. Izgradnja programske komponente kao samostalne cjeline nije osobit problem. Problemi nastupaju kada vei broj programskih komponenata treba objediniti u informacijski sustav poslovno-proizvodnog sustava; sustav izvravanja proizvodnje. Problemi definiranja arhitekture informacijskog sustava, konceptualnog dizajna sustava, nadogradnje sustava i primjene novih programskih komponenata vrlo su izraeni i jo uvijek teko premostivi. U radu je prikazan postupak oblikovanja sustava izvravanja proizvodnje koritenjem programskih komponenata na takav nain da se: skrati vrijeme izrade informacijskog sustava smanji rizinost projekta izgradnje novog informacijskog sustava povea fleksibilnost sustava u smislu prilagoavanja informacijskog sustava buduim zahtjevima korisnika

ali da u isto vrijeme nije negativno utjecano na druge karakteristike (funkcionalne i nefunkcionalne) konanog informacijskog sustava i poslovnog sustava kao jedinstvene cjeline. U radu se objanjava i definira: to je to programska komponenta, koja joj je namjena, te koje su prednosti i nedostaci koritenja komponente, okolina programske komponente i naini primjene programske komponente,

1

Sustav izvravanja proizvodnje (krat. SIP) je vrsta informacijskog sustava. SIP se moe svrstati u informacijske sustave proizvodnje.

4 to je to sustav izvravanja proizvodnje (SIP), njegova funkcija, prednosti i naini primjene, po emu se SIP razlikuje od klasinih sustava planiranja proizvodnje (ERP, MRP/II, itd.), predloke (engl. frameworks) i njihovu ulogu u procesu razvoja programskih sustava, postupak procjene uspjenosti (engl. evaluation) izrade i primjene sustava izvravanja proizvodnje, i model sustava izvravanja proizvodnje za postojee metalo-preraivako poduzee u Hrvatskoj.

Slika 1 prikazuje tri mogua pristupa kojima proizvodno poduzee moe krenuti da bi pribavilo vlastiti informacijski sustav proizvodnje.

Programske komponente

ISP (SIP)

Referentni model

Realni sustav

Slika 1 - Pristupi izradi informacijskog sustava proizvodnje

Prvi pristup (prikazan punom linijom - Slika 1) je kupovina gotovog ISP sustava i primjena istog u proizvodnom poduzeu (vjerojatno uz preinake u organizacijskoj strukturi i proizvodnom procesu poduzea). Drugi pristup (prikazan crtkanom linijom - Slika 1) je koritenje modula (modul Proizvodnja, modul Transport, modul ObraunRada, itd.) koji ine informacijski sustav proizvodnje parametrizacijom i spajanjem u gotov informacijski sustav. Pri konfiguriranju modula i izradi realnog sustava preporua se koritenje referentnog modela kako bi postupak izrade novog sustava bio kvalitetan i brz. Hipoteza zastupljena u ovom radu je prikazana treim pristupom (tokasta

5 linija - Slika 1). Primjenom programskih komponenata i koritenjem referentnog modela mogue je izraditi sustav izvravanja proizvodnje sa odreenim karakteristikama2. Hipoteza glasi: Pravilnom primjenom programskih komponenata moe se izraditi sustav izvravanja proizvodnje metalo-preraivakog poduzea sa vie zemljopisno distribuiranih organizacijskih jedinica. Referentni modeli sustava izvravanja proizvodnje poznati iz literature mogu se konkretizirati upotrebom programskih komponenata.

U prvom dijelu rada predstavljen je uvod u problemsku domenu. U drugom dijelu rada su prikazane programske komponente kao element izgradnje programskih proizvoda. Izvrena je klasifikacija komponenata, pobrojane su karakteristike komponenata, prednosti i nedostaci koritenja. Dio poglavlja je posveen pravnoj problematici upotrebe komponenata u programskim proizvodima. U treem dijelu su prikazane dvije metodike izgradnje programskih sustava primjenom programskih komponenata: SELECT Perspective i CSLA. Razvoj sloenih programskih sustava primjenom komponenata ima niz problematinih faza koje budua istraivanja tek trebaju rijeiti. etvrti dio rada je uvod u informacijske sustave proizvodnje i posebno detaljno u sustave izvravanja proizvodnje (SIP, engl. Manufacturing Execution System; MES). Objanjene su funkcije SIP sustava, prednosti primjene i najei problemi izrade takvih sustava. U petom dijelu rada su obraeni predloci (engl. frameworks), povijest predloaka i naini primjene. Ukratko je prikazan predloak organizacije SEMATECH pod nazivom CIM Framework 2.0. CIM Framework je predloak namijenjen izgradnji informacijskih sustava proizvodnje sa naglaskom na sustavima izvravanja proizvodnje (SIP).

2

Karakteristike koje mora imati dobiveni informacijski sustav definirane su na poetku ovog poglavlja.

6 U procesu izrade programskih sustava baziranih na komponenata treba odabirati programske komponente za pojedine dijelove sustava. Analizom programskih komponenata odreene namjene moe se doi do zakljuka da postoje bre i sporije, vee i manje, sloenije i jednostavnije programske komponente i da je potrebno odabrati samo jednu od veeg broja komponenata sline namjene. Zbog navedenog razloga esti dio rada prikazuje imbenike bitne za odabir programskih komponenata. Zavrni dio rada (sedmi i osmi dio) je prikaz procesa izrade i mogunosti primjene sustava izvravanja proizvodnje baziranih na programskim komponentama u poduzeu OMEGA d.o.o. . Prikazana je snimka postojeeg stanja analizom kojeg je odreena organizacijska struktura poduzea, tok dokumenata i materijala kroz poduzee, budue potrebe poduzea i problemi vezani uz proizvodni proces koje je trebalo ukloniti. Cijeli primjer temelji se na znanjima iznesenim u prethodnim poglavljima i metodici razvoja SIP sustava pomou programskih komponenata. Metodika razvoja opisana je u sedmom poglavlju. Sintezom rjeenja pojedinanih problema izgradnje informacijskih sustava proizvodnje dobiven je model sustava izvravanja proizvodnje za poduzee Omega d.o.o. . Za izradu ovog rada koritene su slijedee metode i tehnike: analiza strunih i znanstvenih radova i lanaka analiza strunih lanaka iz asopisa vezanih uz podruja informatikih tehnologija, asopisa vezanih uz proizvodne sustave i asopisa za popularizaciju znanosti analiza sluaja izgradnje informacijskih sustava u velikim meunarodnim poduzeima usporedba karakteristika sustava iz (ranije navedene) analize sluajeva i sustava za izvravanje proizvodnje klasificiranje

7

2. Programska komponentaU teoriji i praksi moe se nai vei broj definicija programske komponente3. Evo ih nekoliko: "Programske komponente su programski moduli u izvrnom obliku. Izraene su, prikupljene i upotrijebljene neovisno o drugim dijelovima sustava koji zajedno ine skladnu cjelinu. Sustavi sastavljeni od programskih komponenata zovu se programski sustavi graeni na komponentama." [Szyp98] "Komponenta je u tvornici testiran programski podsustav." (Orfali, R., 1995., asopis Datamation) "Pod komponentama podrazumijevamo ranije izraene jedinice programskog koda koje koristimo kao proirenja koncepata programskog jezika. Koriste se za vrijeme programiranja i moemo ih usporediti sa komponentama u graevnoj industriji." (Jacobson, I., 1993. Object-Oriented Software Engineering) "Programske komponente se definiraju kao prethodno izraeni i testirani, cjeloviti, viestruko iskoristivi programski moduli - skupine podataka i procedura - koji izvravaju specifine zadatke." (Meta Group, 1994.) I objekti i komponente svoje usluge nude preko jasno definiranog suelja (engl. interface). Samo na taj nain mogue je da komponenta ima slijedea svojstva: Komponenta je element kompozicije vanjskog programera ili poduzea.4 Programeri intenzivno koriste tue komponente kako bi razvijali vlastite

programske proizvode. Komponenta mora biti relativno samostalna, sa jasnim specifikacijama koje sadre uvjete koritenja i rezultate (ako su uvjeti koritenja zadovoljeni) da bi bila primjenjiva u praksi. U komponentu su ugraene metode djelovanja i ponaanje. Komponenta komunicira sa okolinom putem jasno definiranog nedvosmislenog suelja.

3

U daljem tekstu se radi jednostavnosti umjesto pojma programska komponenta koristi samo pojam komponenta. Znaenje komponente u drugaijem kontekstu bit e posebno napomenuto.

4

esto je upotreba tuih komponenata vezana uz kupovinu uporabne dozvole (engl. use license).

8 Komponenta je zaokruena cjelina upotrebe. Za primjenu komponente u nekom programskom alatu nisu potrebne druge komponente. Komponenta (uz ponekad i programski jezik) je zaokruena cjelina koja je sposobna izvriti sueljem definirane zadatke. Komponenta ima jasnu granicu prema okolini u kojoj se nalazi i ne moe se koristiti samo dio programske komponente ve cijela komponenta. Komponenta nije perzistentna Kopije komponente se ne razlikuju jedna od druge pa zbog toga nema smisla drati5 u memoriji vie kopija (engl. instance) iste komponente . U svakodnevnim

situacijama sve je ei sluaj da su komponente vrlo velike i zahtijevaju jake raunalne resurse6.

Programska komponenta je nain razmjene programskog koda na nain da se algoritam i interni rad komponente sauvaju kao poslovna tajna. Komponenta osigurava zatitu vlastitog znanja i know-howa ugraenog u programsku komponentu. Suelje komponente osigurava njezinu standardiziranost i univerzalnost u smislu identinog ponaanja u razliitim radnim okolinama. Izmeu komponente i objekta postoje razlike koje su prikazane u tabeli (Tabela 2). Kada se spominje pojam programske komponente, veliki broj strunjaka odmah pomilja na IDL (engl. Interface Definition Language). IDL je jezik kojim se opisuje suelje (engl. interface) programske komponente. Za razliku od komponente, pri definiranju objekta se ne koristi IDL ve sintaksa definicije programskog jezika u kojem se objekt definira. Druga vana razlika izmeu objekata i komponenata je ponaanje u radnoj memoriji raunala. U radnoj memoriji se moe nai vei broj

5

U stvarnosti ova tvrdnja nije potpuno tona. Zato? Jedna programska komponenta moe u sebi sadravati vie razliitih suelja. Radi zatite konzistentnosti podataka (izmjena vrijednosti varijabli u vienitnim aplikacijama) smjetenih unutar programske komponente neki razvojni alati ne doputaju istovremeno izvravanje vie metoda. Dolazi do zaustavljanja (engl. blocking) poziva metoda i serijalizacije poziva u red ekanja. Kako bi se to izbjeglo, dozvoljava se kreiranje vie instanci klasa - suelja - komponenata (Instancing svojstvo programske komponente moe poprimati vrijednosti MultiUse, SingleUse, GlobalMultiUse, GlobalSingleUse, itd. u Visual Basic-u).

6

Primjer: DBMS moe biti komponenta. Cijeli Microsoft Internet Explorer je skup komponenata. U Windows operativnom sustavu Adobe Acrobat Reader je komponenta. Microsoft Office se sastoji od skupine ActiveX komponenata.

9 instanci objekta iste klase, dok isto ne vrijedi za komponente koje se u radnoj memoriji mogu pojaviti najvie jednom. Objekt ima stanje koje se moe pohraniti na trajnom nositelju podataka (engl. persistence) ne koristi se IDL u radnoj memoriji moe postojati vie instanci objekta svaka instanca ima jedinstveni identitet vezan uz programski jezik za izradu se koristi objektno orijentirane programske jezike definira se klasom Komponenta nema stanje suelje je definirano IDL-om u radnoj memoriji u pravilu postoji samo jedna instanca komponente ako ipak u radnoj memoriji postoji vie instanci sve imaju istu oznaku identiteta7 (vidi dno 8. stranice) direktno primjenjiva u razliitim programskim jezicima, arhitekturama i operativnim sustavima pri izradi se koristi proceduralne programske jezike, objektno orijentirane programske jezike, prirune jezike (engl. script language), strojne jezike, itd. moe sadravati procedure, klase, globalne varijable, itd.

Tabela 2 - Karakteristike objekta i komponente

Pojam komponente je opsegom iri od pojma objekta. Komponenta se moe sastojati od vie objekata. Da bi se definirala struktura komponente nisu nuno potrebni objekti i klase ve se moe koristiti adekvatni programski jezik. Svaki objekt ima svoj jedinstveni identitet po kojem se razlikuje od drugih objekata iste klase. U iznimnim sluajevima kada u radnoj memoriji postoji vie instanci komponente, instance se meusobno ne razlikuju i nemaju jedinstveni identitet.

2.1. PodjelaStrunjaci koji se bave problematikom programskih komponenata jo uvijek nisu jasno definirali kriterije klasifikacije programskih komponenata. Na temelju klasifikacija koje je autor rada uspio prikupiti i analizirati, definirana je relativno jednostavna viedimenzionalna klasifikacija koja programske komponente razlikuje7

GUID - engl. Global Unique Identification. Poduzee Microsoft ovaj identifikator koristi na vie podruja (kao jedinstveni identifikacijski broj objekata, suelja, komponenata, korisnika, itd.). GUID vrijednosti su velike 16 byteova i primjenom GUID generatora nije mogue na dva razliita raunala u svijetu generirati istu GUID vrijednost; barem ne unutar vremenskog razdoblja od 3000 godina.

10 po vie dimenzija (Slika 2). Dimenzija trina vrijednost komponente je jedna od vanijih. Najvei dio programskih komponenata izraen je sa ciljem stjecanja profita. Ciljano trite za koje se komponente izrauju najveim dijelom ine informatika poduzea (gospodarski sektor), dok se za vladine institucije (ministarstva) i za osobnu upotrebu izrauje manji broj programskih komponenata. U SAD-u koliina komponenata izraenih za vladine institucije ini relativno velik udio u ukupnom broju proizvedenih programskih komponenata (u odnosu na stanje u naoj zemljopisnoj regiji).

Po trinoj vrijednosti Po ciljnom tritu

1) komercijalne 2) nekomercijalne 1) vladine 2) za gospodarski sektor 3) privatne

Mogunost izmjena Po pouzdanosti rada

1) dozvoljene izmjene 2) izmjene zabranjene 1) potvrene 2) nepotvrene (engl. non-certified) 3) razvojne i testne

Slika 2 - Klasifikacija programskih komponenata

U nastavku slijede klasifikacije drugih autora. Na mrenom posluitelju udruenja SEI8 te u prezentacijama sa meunarodnih konferencija moe se nai klasifikacija programskih komponenata. Klasifikacija komponenata je izvrena po marketinko-ekonomskom principu obzirom da se kategorizacija uzima po naelu tko je proizveo komponentu i kome ju namjerava ponuditi na upotrebu. Po toj klasifikaciji, programske komponente se dijele na: Komercijalne komponente "iz kutije" (engl. Commercial-off-the-shelf; COTS) Drugi nama blii naziv bi moda bio komponente "s trgovake police" zbog toga jer se radi o proizvodima koji se mogu kupiti u poduzeima i trgovinama sa programskom i raunalnom opremom. Klasian primjer bi bio programski paket "Microsoft Office 2000 hrvatska verzija" koji se moe kupiti u robnoj kui na odjelu tehnike robe. Iako Office 2000 nije programska komponenta,

8

SEI - engl. Software Engineering Institute.

11 u sebi sadri niz programskih komponenata koje se mogu koristiti u programima (npr. komponente za provjeru gramatike ispravnosti reenice, rad sa Excel tabelama i grafovima, itd.). Komponente "iz kutije" (engl. Off-the-shelf; OTS) Ova kategorija u sebi ukljuuje COTS komponente i programske komponente koje se ne prodaju komercijalno ve su besplatno raspoloive (npr. demo primjerci programskih komponenata, prezentacije, itd.). Obuhvaa iri opseg programskih komponenata. Vladine komponente "iz kutije" (engl. Government-off-the-shelf; GOTS) Kod nas kategorija GOTS komponenata nije toliko zastupljena. U zapadno europskim zemljama i Sjevernoj Americi9 ova kategorija proizvoda je dobila na vanosti prije par godina kada su se i dravne institucije odluile za komercijalizaciju vlastitih informacijskih sustava; elja za smanjenjem trokova IT-a i vremena razvoja novih sustava. COTS-crna kutija Programska komponenta u kojoj nije dozvoljena izmjena internog programskog koda. COTS-bijela kutija Programska komponenta u kojoj su dozvoljene izmjene internog programskog koda. MOTS (engl. modified-off-the-shelf) NOTS (engl. not-off-the-shelf) ROTS (engl. research-off-the-shelf) od treih osoba (engl. 3rd party components) Komercijalno pribavljen softver (engl. Commercially acquired software; CAS) Nerazvojni proizvod (engl. Non-Developmental Item, Not Developed In-house; NDI) Programski proizvod koji je neka osoba ili poduzee razvijalo za svoje

9

Perry Memo, Kaminsky Memo, Clinger-Cohen Act, DoD 5000.1-R, DoD 5000.1, FASA/FARA, DoDD 8000.1, DII COE v3.1, JTA 1.0, Raines Rules

12 osobne (interne) potrebe. Prvotna namjena programa-komponente nije bila za komercijalnu uporabu. Stjecajem prilika komponenta se poela koristiti i u druge svrhe. Javno dostupan Tzv. shareware komponenta. Svaki programski proizvod koji se ovako deklarira dozvoljeno je upotrebljavati bez naknade autoru programske komponente. Vlastite komponente Komponente razvijene unutar poduzea ili organizacije i jedino se u njima upotrebljavaju. Drugu klasifikaciju programskih komponenata nudi Edwards [Edwa97]. Ova podjela nije toliko detaljna kao prethodna ali ju podravaju i drugi autori: Servisi Radi se o komponentama koje se sastoje od samo jedne metode i nemaju interno stanje. Ta metoda ima svrhu obavljanja neke poslovne transakcije (engl. business service) poput npr. UmanjiSaldoNaZiroRacunu. Kod poziva metode se specificiraju vrijednosti svih parametara, metoda sama pronae podatke koje treba izmijeniti, promijeni podatke i pozivatelju vrati zavrni status operacije. Objekti Sastoje se od dvije ili vie metoda i vezane su uz pojedine entitete problemske domene (npr. PoslovniPartner, IzlazniUreaj, VideoTraka, itd.). Metode su zaduene za dodavanje, brisanje, mijenjanje i druge operacije nad matinim entitetom. Infrastruktura potrebna za rad objekata skraeno se zove ORB (engl. Object Request Broker). Svrha ORB-a je podrka komunikacije objekata izmeu razliitih programskih jezika, operativnih sustava i mrea. Objekti se dalje dijele na:Objekti bez stanja (engl. stateless objects) Kod poziva ovakvog tipa objekta, on mora sam procijeniti gdje se nalaze podaci sa kojima mora raditi. Isto tako, mora ih zahvatiti s mjesta gdje su smjeteni i nakon promjene ih ponovno spremiti na mjesto. Primjer arhitekture koja spada u ovaj tip je DCOM (engl. Distributed Component Object Model). Objekti sa stanjem (engl. stateful objects) Ovi objekti imaju unutranje stanje. Putem jedinstvenog identifikatora objekta, programski meusloj (u kojem se nalazi objekt sa stanjem) zahvaa prethodno stanje

13objekta i stavlja objekt u to stanje. Nakon toga objekt vri zatraene operacije. Na kraju se operacija ili potvrdi (engl. commit) ili poniti (engl. rollback). Nakon to je operacija zavrena, stanje objekta se moe snimiti na trajni nositelj podataka. Primjer arhitekture koja podrava objekte ovakvog tipa je CORBA.

Programske komponente se mogu i komercijalno klasificirati u tri glavne kategorije i to po kriteriju programske grupacije koja promovira standard. Tako se programske komponente mogu podijeliti na programske komponente izraene u CORBA, DCOM10 i JavaBeans standardu. Udruenje OMG promovira i unapreuje CORBA standard, poduzee Microsoft promovira DCOM standard a poduzee Sun promovira JavaBeans standard.

2.2. Karakteristike programskih komponenataKomponente su specifina tehnologija sa velikim brojem karakteristika koje ih razlikuju od drugih programskih tehnologija. 2.2.1 Izvrni oblik U definicijama komponente na poetku poglavlja moe se uoiti da je programska komponenta zapravo programski modul u izvrnom obliku. Postoji manji broj strunjaka koji se bave informacijskim tehnologijama i koji zagovaraju definiciju komponente bez pojma "izvrnog oblika". S obzirom na veliku koliinu autora koji misle suprotno a i niza karakteristika koje otpadaju ako se krene od neizvrnog oblika definicije, autor ovog rada se odluio za definiciju programske komponente kao programskog modula u izvrnom obliku. Razlozi za takav odabir su: Programski kd postaje komponenta tek nakon prevoenja u strojni jezik. Primjer: programski kd programskog jezika C ili Pascal ne moe biti programska komponenta. Postoje standardi koji definiraju kako komponenta izgleda u memoriji za vrijeme izvravanja, kako izgledaju paketi za razmjenu poruka izmeu komponenata, kako se komponente ponaaju u tono odreenim sluajevima. Protokol pod nazivom Distributed Component Object Model Protocol (DCOM Protocol) je protokol koji je definirao Microsoft a sada tei tome da se standardizira10

DCOM je u vrijeme pisanja rada polako poeo gubiti znaaj zbog toga jer ga Microsoft zamjenjuje COM+ standardom.

14 kao javno dostupan Internet protokol koji bi bio usuglaen u suradnji sa IETF organizacijom (engl. Internet Engineering Task Force). DCOM Protocol se jo naziva i Objektni RPC. DCOM protokol je definiran na aplikacijskoj razini sa svrhom objektno-orijentiranog pozivanja udaljenih procedura (OO RPC; engl. Object-Oriented Remote Procedure Call) to bi podravalo distribuirane, na komponentama bazirane sustave svih tipova. To je protokol zasnovan na DCE RPC specifikaciji i svojstvima sa ciljem izrade zadatku specifinih komunikacijskih protokola pomou mogunosti kao to su: o arhitekturi (platformi) neutralno prosljeivanje argumenata (NDR), objekti istovremeno podravaju vie suelja (engl. interface) koja se neovisno mogu razvijati od strane vie partnera (podrka verzijama suelja i komponenata), podrka ovlatenja korisnika, odabir razine sigurnosti kanala, neutralnost zapisa podataka u paketu (neovisno o mrenoj arhitekturi). Objektni RPC protokol definira: nain generiranja poziva na objektu nain memoriranja, razmjene rada sa pokazivaima na objekte Primarna zadaa DCOM-a je podrka izgradnji programske infrastrukture distribuiranih aplikacija bilo kojeg tipa. Drugim rijeima, DCOM je temelj na kojem se grade komunikacijski putovi izmeu distribuiranih aplikacija. 2.2.2 Suelje Suelje (engl. interface)11 ini vaan dio komponente. Bez suelja se ne bi znalo to komponenta mora raditi, na koji nain mora komunicirati sa okolinom, kako brzo se mora izvravati, parametre putem kojih vrijednosti ulaze i izlaze iz komponente, itd. . Suelje predstavlja vanjski izgled komponente, ne definira ve indirektno odreuje interni rad komponente. Openito, neki strunjaci o suelju

11

U radu se esto uz rije suelje navodi i engleski prijevod interface. Razlog tome je elja autora da naglasi kontekst suelja kao openitog koncepta (korisniko suelje, programsko suelje, razvojno suelje, itd.) na jednoj strani i konkretnog suelja (engl. interface) programske komponente koje je definirano IDL-om na drugoj strani.

15 govore kao o "ugovoru" izmeu projektanta komponente i korisnika komponente; komponenta mora zadovoljavati sve uvjete pobrojane u "ugovoru". 2.2.3 Zatita programskog koda Programski kod nije direktno dostupan korisniku komponente. Neitljivost programskog koda ima vie prednosti: Korisnik ne moe modificirati programski kod komponente i tako napraviti neispravnu komponentu. Zatiuje se vlastito znanje ugraeno u programsku komponentu. Znanje ugraeno u komponentu esto je specifine prirode i teko dostupno u javnosti. Osim toga, nain na koji je neto napravljeno (mora se uzeti u obzir i funkcionalna svojstva komponente; brzina rada, potronja memorije) moe biti stroga poslovna tajna i moe predstavljati dragocjeno poslovno znanje. Samim time to korisnik programske komponente nema dostupan programski kod javljaju se i negativni efekti istog svojstva: Korisnik ne moe samostalno ispraviti pogreke ugraene u komponentu (pogreke ugraene od strane proizvoaa komponente). Korisnik mora ekati da proizvoa komponente ispravi pogreku (to moe potrajati neko vrijeme). Teko je vriti potpuno kvalitetno testiranje rada komponente; komponenta je crna kutija i najee korisnik ne moe vidjeti strukturu i sadraj komponente. Jedino to korisnik moe znati je kakav smije biti ulaz i kakav bi morao biti izlaz (rezultat rada komponente). Programska dokumentacija mijenja svrhu i razlog postojanja. Teko se moe provjeriti da je ono to je napisano kao uvjet u ugovoru o izradi komponente stvarno na taj nain izvedeno u komponenti. Ako proizvoa komponente (poduzee) ode u steaj ili se dogodi neki drugi dogaaj tetan za daljnje poslovanje korisnika, postavlja se pitanje tko e odravati i nadograivati komponentu ako korisnik nema programski kod komponente.

16 2.2.4 Viestruko koritenje Izrada programskih proizvoda se temelji na ponovnoj uporabi (engl. reusability) komponenata. Komponente mogu biti relativno male (jednostavne) ali mogu biti i vrlo velike (kompleksne). Kod razvoja novih programskih proizvoda trebamo teiti tome da se koristi sve to je napravljeno u ranijim projektima a ne da se u svakom projektu sve razvija od poetka. Razvoj programskih proizvoda orijentiran na viestruko koritenje se moe podijeliti u vie kategorija [Somm95]: 2.2.4.1 RAZVOJ VIESTRUKIM KORITENJEM U poslovnom svijetu informatike tei se tome da se ukupni trokovi razvoja sustava smanje na to je manju moguu mjeru. Jedno od realnih rjeenja je ponovno koritenje ranije razvijenih komponenata. Efekt takvog pristupa je manje novih specifikacija, dizajna, izrade i provjere valjanosti. Ostali efekti navedenog pristupa su: Poveanje pouzdanosti rada sustava. Komponente su ve ranije viestruko testirane. Smanjenje rizika neuspjenog zavretka projekta. Ne treba ponovno razvijati komponente ve se koriste ranije izraene i testirane programske komponente. Razvoj potpuno nove komponente je skuplji od dorade (koritenja) ranije izraene komponente. Efikasnije koritenje ekspertnih znanja. Umjesto da projektni tim primjenjuje svoja znanja na razliitim projektima, specijalisti tima se mogu usredotoiti na razvoj specifinih komponenata. Organizacijska pravila se mogu ugraditi u viestruko iskoristive programske komponente. Primjer je komponenta za rad sa programskim izbornicima koja moe u sebi sadravati svu logiku rada i karakteristike programskih izbornika. Takva komponenta se moe koristiti u svim programima koji se koriste u poduzeu pa se tako korisnici bre snau u novim aplikacijama zbog konceptualno i vizualno identinog suelja i navigacije kroz cjelokupni sustav. Drugi primjer

17 je programska komponenta za identifikaciju korisnika kod prijavljivanja sustavu i provjeru identiteta korisnika sustava. Vrijeme razvoja programskog proizvoda se smanjuje. U dananje vrijeme intenzivnih promjena pravovremeni izlazak na trite sa novim proizvodima ini razliku izmeu profita i gubitka. Nedostatak razvoja viestrukim koritenjem je da se specifikacije budueg programskog proizvoda moraju prilagoavati raspoloivim komponentama. To uvjetuje kompromise u fazi specificiranja novog sustava i manju efikasnost rada novog sustava nego da se koristi specijalni dizajn bez standardnih komponenata. Uvjeti da bi se moglo krenuti sa ovim pristupom su: 1) pronai viestruko upotrebljive komponente, 2) vjerovati da e se komponente ponaati kako je u dokumentaciji specificirano i da e pouzdano raditi i 3) posjedovanje valjane dokumentacije. Da bi se moglo krenuti sa ovim pristupom ipak su potrebne poetne investicije tako da viestruko koritenje jo uvijek nije pobudilo vei interes u poslovnom svijetu [Somm95]. Nedostaci ovakvog pristupa su: Teka procjena financijskih efekata (smanjenje trokova) viestruke primjene komponenata - postoje i trokovi viestrukog koritenja (traenje eljene komponente, prouavanje dokumentacije, testiranje rada komponente, adaptacija komponente za rad u novoj okolini, konfiguriranje komponente, sklapanje ugovora o koritenju, itd.). Postojei CASE alati ne podravaju razvoj viestrukim koritenjem komponenata. Programski inenjeri vie "vole" ponovno napisati komponentu jer vjeruju da e tako optimizirati rad komponente i imati veu kontrolu nad samom komponentom. Programski inenjeri ne vjeruju drugim programskim inenjerima. Tehnike klasificiranja, katalogiziranja i pohrane programskih komponenata su relativno nezrele.

18 2.2.4.2 RAZVOJ ZA VIESTRUKO KORITENJE Razvoj za viestruko koritenje zahtijeva valjano katalogiziranje i dokumentiranje komponenata. Komponente moraju zadovoljavati poopene zahtjeve (iroke domene) kako bi se mogle primjenjivati u irokom spektru problema. Prilagoavanje komponente viestrukoj uporabi moe zahtijevati razliite promjene poput [Somm95]: Poopivanja naziva Naziv viestruko upotrebljive komponente mora biti neutralan tj. ne smije odraavati primjenu u specifinoj aplikaciji. Poopivanja metoda Dodavanje opih metoda ili izbacivanje specifinih metoda kako bi se zadovoljile specifikacije viestruko upotrebljive komponente. Poopivanja dogaaja (engl. event) Postoje naini da se neke metode komponente mogu izraditi koritenjem niza drugih metoda iste te komponente. To je mogue ali nije preporuljivo jer dobivene metode mogu biti neefikasne i spore. Pretvaranje komponente u viestruko iskoristivu komponentu rezultira dodatnim trokovima. Kako menaderi tee to niim trokovima, dogaa se da ne vide indirektnu korist u viestrukom koritenju ve vide samo direktne trokove to rezultira odbijanjem bilo kakve mogunosti ulaganja u viestruko koritenje. Razvoj viestruko upotrebljivih komponenata zbog toga zahtijeva posebnu politiku poduzea koja mora biti definirana u organizacijskim dokumentima. Objektno-orijentirani programski jezici za sobom su donijeli nasljeivanje (engl. inheritance). Meu manje educiranim informatiarima postoji miljenje da je nasljeivanje kao oblik viestrukog koritenja dobro. Meutim, u stvarnim sluajevima se pokazalo da nasljeivanje ima vie negativnih nego pozitivnih efekata. Negativni efekti su: programski kod nije na jednom mjestu ve je ratrkan na vie mjesta - buduem korisniku tee je razumjeti logiku rada komponente ako elemente mora traiti na vie mjesta.

19 neeljena ekstra funkcionalnost programske komponente koja rezultira neefikasnim kodom i sporim izvravanjem. teko odravanje - potrebne povremene reorganizacije programskog koda. Specifikacije budueg programskog proizvoda i aplikacije definiraju na apstraktan nain koje komponente e se koristiti, kako e se meusobno povezivati i nain konfiguriranja programskih komponenata. Koritenjem tih informacija generira se programski kod novog sustava. Problem je da su generatori programskog koda esto vezani uz odreenu programsku domenu i nisu u mogunosti koristiti programske komponente koje spadaju u domenu koja nije direktno vezana na domenu generatora programskog koda. Slika 3 prikazuje korisniko suelje Microsoftovog programskog alata pod nazivom Visual Component Manager. Radi se o alatu koju nudi mogunost pohrane, klasificiranja, opisivanja i praenja verzija programskih komponenata i drugih standardnih postupaka nad programskim komponentama.

Slika 3 - Microsoft-ov Visual Component Manager

20

2.2.4.3 VIESTRUKO KORITENJE PROGRAMSKIH SUSTAVA Ovaj oblik viestrukog koritenja rezultira programskim kodom finalnog sustava koji je dizajniran tako da se lako prenosi na druge platforme i kao takav se koristi uz relativno male preinake (manji trokovi). Mogue tehnike su: emuliranje platforme na drugoj platformi (koritenjem mikrokoda) prevoenje programa u apstraktni strojni jezik, izrada interpretera apstraktnog strojnog jezika na razliitim platformama koritenje predprocesora za prevoenje iz jednog dijalekta u drugi dijalekt programskog jezika Problemi koji se mogu javiti kod ovakvog pristupa viestrukom koritenju programskog koda se dijele na: problemi sa bibliotekama (engl. library) - nedostupnost programskih biblioteka na drugim platformama (npr. grafika ljuska OpenGL nije dostupna na VAX-VMS sustavima, MFC nije dostupan na UNIX sustavima, itd.). problemi sa izvrnim rutinama sustava (engl. run-time procedures) primjena specifinih (neuniverzalnih) svojstava sustava koje nisu globalno dostupne na ostalim platformama (npr. grafiki akcelerator sa hardverskim rutinama za sjenanje i lijepljenje uzoraka, zvuna kartica sa specijalnim efektima) problemi sa operativnim sustavom problemi sa hardverskom arhitekturom raunala (npr. poredak bitova u memoriji, itd.) Problemi sa izvrnim rutinama sustava i problemi sa bibliotekama se relativno teko rjeavaju. Problemi sa operativnim sustavom i arhitekturom raunala se rjeavaju izradom prijelaznog suelja (engl. portability interface) putem kojega se pristupa problematinim resursima. Da bi rad prijelaznih suelja bio kvalitetan i brz u raunalni sustav je potrebno ugraditi dopunske resurse (npr. vie radne memorije, vie procesora, itd.); engl. overhead.

21 Trend je da se u ovo podruje uvede vie reda definiranjem standarda: standarda programskih jezika, standarda operativnih sustava, mrenih standarda, standarda korisnikog suelja i drugih standarda to bi pozitivno utjecalo na mogunosti primjene ove vrste viestrukog koritenja. Meyer [Meyer97] tvrdi da ulaganje u razvoj viestruko primjenjivih komponenta rezultira poboljanjima kao to su: bri razvoj novog programskog proizvoda smanjenje trokova odravanja poveanje pouzdanosti gotovog proizvoda poveanje efikasnosti proizvoda poveanje konzistentnosti proizvoda zatita investicije, organizacijskog i ekspertnog znanja Direktna korist ponovnog koritenja ranije razvijenih komponenata je poveana pouzdanost novog programskog proizvoda. Komponente koje se koriste iznova i iznova imaju prednost jer su koritene u razliitim okruenjima i testirane u razliitim uvjetima. Viestruko koritene komponente zbog prethodno navedenog razloga sadre manje greaka u programskom kodu. Viestruka primjena komponenata ne znai samo opetovano koritenje programskog koda ve i opetovano koritenje specifikacija, dizajna, arhitekture, itd. . Viestruko koritenje programskog koda moe ii od najnie razine viestrukog koritenja funkcija (npr. matematike funkcije) preko viestrukog koritenja objekata i modula (npr. objekt koji predstavlja binarno stablo), viestrukog koritenja podsustava da bi u krajnjem obliku dobilo oblik viestrukog koritenja cijelih programskih sustava (npr. jedan program koji se izvrava na vie razliitih platformi). Svrha razvoja programskih komponenata nije jednokratna upotreba. Glavni cilj koji se eli postii pri razvoju komponenata je pronai idealni omjer izmeu to vee funkcionalnosti koju komponenta podrava i brzine (trokova) razvoja. Komponenta se mora moi primijeniti vie puta u razliitim projektima da bi ispunila svoju temeljnu zadau: smanjenje vremena razvoja uz odranje ostalih karakteristika na istom nivou.

22 Slika 4 prikazuje zavisnost trokova za koritenje tuih programskih komponenata o udjelu kupljenog (tueg) softvera i zavisnost fleksibilnosti programskog proizvoda o udjelu kupljenog softvera.

Trokovi 0% kupljeno

Fleksibilnost, kompetitivna prednost 100 %

Slika 4 - Odnos izmeu napravi-sve i kupi-sve pristupa [Szyp98]

Ako neko poduzee uope ne kupuje tui softver (komponente) ve sve proizvodi unutar drutva, trokovi koritenja tuih programskih komponenata bit e relativno mali u odnosu na sluaj da sve komponente kupuje od drugih osoba. Trokovi koritenja tuih programskih komponenata sve vie rastu kako se poveava omjer kupljenog stranog softvera. Istovremeno sa trokovima se mijenja i fleksibilnost programskog proizvoda. Ako netko sam izrauje programske komponente onda on moe u potpunosti zadovoljiti sve svoje potrebe i zahtjeve. Ako ta ista osoba komponente kupuje od drugih poduzea, dobivene komponente nee (u najveem broju sluajeva) u potpunosti zadovoljiti njegove zahtjeve i on e se morati prilagoditi ponudi na tritu. Kakva je ovisnost korisnosti (robustnosti) komponenata o omjeru outsourcinga moe se vidjeti na slici koja slijedi (Slika 5).

Korisnost 0%

Robustnost 100 %

viestruko koritenje (outsourcing)

Slika 5 Zavisnost korisnosti i robustnosti o outsourcing-u [Szyp98]

23

Ako najvei dio programskog proizvoda izrauju vanjska poduzea (tzv. engl. outsourcing) projektni tim e imati korist u smislu da e se velik dio rutinskog posla odvijati izvan poduzea dok e se projektni tim moi posvetiti nekim drugim i vanijim problemima. No meutim, to je vei broj komponenata (dio programskog proizvoda) izraen izvan razvojnog tima, robustnost dobivenog programskog proizvoda biti e manja. Naime, razvojni tim e imati malu kontrolu nad pojedinim fazama izgradnje programskog proizvoda.

24 2.2.5 Ostale karakteristike programskih komponenata Komponente meusobno moraju komunicirati kako bi razmjenjivale podatke. Mogui naini komunikacije su: Komunikacija preko spojnica Omoguava dijalog izmeu velikog broja korisnikih komponenata i komponenata na posluitelju. Primjer su TCP/IP spojnice (engl. sockets) i IBM-ov CPI-C. Komunikacija tipa zahtjev-odgovor (engl. request-response) Jednokratna komunikacija izmeu komponente na posluitelju i korisnike komponente. Primjer je udaljeni poziv procedure (engl. RPC-Remote Procedure Call). Komunikacija putem redova ekanja (engl. queues) Nain komunikacije kod kojeg komponente na posluitelju i kod korisnika (engl. client) ne moraju meusobno komunicirati u istom vremenskom trenutku. Ponekad je ovo jedini nain komunikacije izmeu distribuiranih dijelova sustava (npr. ako ne postoji pouzdana komunikacijska veza). Zahtjevi korisnike komponente (engl. client component) pohranjuju se u redu ekanja.

Korisnik Komponenta Komponenta Komponenta Komponenta Komponenta Komponenta

Red (queue)

Posluitelj Servis A Servis A Servis A Servis A Servis B Servis B Servis B Servis B Servis C Servis C Servis C Servis C Servis D Servis D Servis D Servis D

Red (queue)

Slika 6 - Komunikacija komponenata pomou redova ekanja [Edwa97]

Kada je posluitelj spreman prihvatiti nove poruke (engl. messages) jednostavno ih dohvaa iz reda ekanja. Primjeri programskih alata koji podravaju redove

25ekanja su Microsoft Message Queue (MSMQ) i Message-Oriented Middleware (MOM) sa TP Monitorom. Komunikacija moe biti i dvosmjerna. Registrirana pretplata (engl. publish-and-subscribe) Da bi komponente mogle komunicirati na ovaj nain potrebno je da u sustavu postoji MENADER DOGAAJA. Menader prima od komponenata upute o tome koji dogaaji i od kojih komponenata ih interesiraju. Komponente koje ele emitirati dogaaje jednostavno ih prosljeuju menaderu koji onda po zahtjevima primatelja obavjetava pretplaene komponente da se dogodio odreeni dogaaj (engl. event). Primjer su spojne toke u DCOM-u (engl. connection points) - Slika 7.

IConnectionPoint Izvor (Source)

ISomeSink Pretplatnik 1 (Sink) ISomeSink Pretplatnik 2 (Sink)

Slika 7 - Spojne toke komponenata (DCOM)

emitiranja i datagrami (engl. broadcasts and datagrams) Jednosmjerna komunikacija u smjeru korisnikih komponenata (engl. client components).

2.3. Okolina komponente - programski meuslojIdeja rasporeivanja (klasificiranja) programskih komponenata u vie jasno razgranienih slojeva ima dugu povijest. Razgraniavanje programskih komponenata u slojeve utjee na niz faktora od kojih su neki: prisiljavanje na modularni pristup izradi sustava, lake odravanje kompleksnih sustava, laka vizualna predodba arhitekture sustava, lake poimanje logike rada sustava, fleksibilnost sustava u kontekstu promjena, itd. .

26 U nastavku se prikazane (Slika 8, Slika 9, Slika 10) mogue arhitekture razraene na temelju meusobnog odnosa pojedinih slojeva. U strogoj vieslojnoj arhitekturi programske komponente koje pripadaju odreenom sloju mogu koristiti samo programske komponenteAplikacije Biblioteke Jezgra operativnog sustava Upravljaki programi ureaja Hardver Slika 8 - Stroga vieslojna arhitektura [Szyp98]

prvog podreenog sloja; preskakanje slojeva nije dozvoljeno. Opseg poslova pojedinog sloja mora u potpunosti pokrivati opseg poslova prvog podreenog sloja.

Nedostaci stroge vieslojne arhitekture su smanjena mogunost nadogradnje sustava novim mogunostima i ponekad smanjene radne performanse sustava. Proirivost novog sustava je smanjena na nain da programske komponente vieg sloja mogu koristiti funkcionalnost programskih komponenata samo prvog nieg sloja. Iako najnii sloj moda i podrava traenu funkcionalnost, neki od viih slojeva tu funkcionalnost vjerojatno ne podrava jer u inicijalnim zahtjevima ta funkcionalnost nije bila traena. Da bi najvii sloj mogao koristiti novu funkcionalnost potrebno je svaki sloj dograditi sa novim programskim komponentama koje dopunjuju traenu funkcionalnost. Zahtjevi se tada prosljeuju od najvieg sloja, sloj po sloj, prema niim slojevima to moe negativno utjecati na performanse sustava. Problem ograniene funkcionalnosti se moe rijeiti proirenjem svih slojeva (Slika 9). Pri tome treba teiti da se sloene operacije koje se sastoje od opetovanog pozivanja iste procedure na niem slojuAplikacije Biblioteke Ljuska operativnog sustava Upravljaki programi ureaja Hardver Slika 9 - Proirena stroga vieslojna arhitektura [Szyp98]

27 "spuste" to nie u arhitekturi kako ne bi dolo do smanjenja performansi sustava. Ako "sputanje" sloenih operacija na niske slojeve nije mogue potrebno je smanjiti broj slojeva. Trei tip arhitekture jeAplikacije Biblioteke Jezgra operativnog sustava Upravljaki programi ureaja Hardver Slika 10 - Slobodna vieslojna arhitektura[Szyp98]

slobodna vieslojna arhitektura. Ovaj tip arhitekture rjeava oba problema: proirivost i performanse. Novi problem koji se javlja je taj da nije mogue lako razgraniiti

pojedine slojeve a s vremenom odravanje i nadogradnja sustava sa ovakvom arhitekturom postaje sve tea. Nestaje glavna karakteristika stroge vieslojne arhitekture: sloj se bazira samo na dostupnim operacijama prvog nieg sloja. Neovisno o arhitekturi i broju slojeva, vei broj autora (Brodie, 1984.; Anderson, 1993.; Szyperski, 1997.) preporua postojanje minimalno 3 do najvie 7 programskih komponenata po jednom sloju arhitekture. Ovisno o tome koja je namjena komponente i kakva je arhitektura sustava (vieslojna ili jednoslojna) drugaija e biti i okolina programske komponente. Programski meusloj (engl. middleware) ima posebnu ulogu u distribuiranim sustavima. On ini sloj izmeu korisnikog suelja i baze podataka12. Proizvoai koji proizvode programsku podrku za velike poslovne sustave (npr. SAP, Baan, PeopleSoft, itd.) sloni su u razmiljanju da je otvorenost njihovih sustava prema vanjskim sustavima imperativ13. Otvorenost sustava se postie dijeljenjem vlastitih aplikacija na dijelove (programske module) koji onda imaju jasno definirana suelja (engl. interface, ugovor) prema okolini. Razmjena podataka izmeu dva programska modula razliitih proizvoaa u takvoj

12 13

Nije nuno da su poetna i zavrna razina korisniko suelje i baza podataka. Autoru ovog rada se na temelju povijesnih injenica ini da to prije nije bilo tako. Mnoga poduzea na podruju informatike su u prolosti imala stav da je najbolje izolirati se od suparnika visokim "zidom" nekompatibilnosti. Kao rezultat tog pristupa na kraju su neka velika poduzea pala na vrlo loe trine pozicije. Otvorenost sustava je osnovni zahtjev dananjice i budunosti.

28 okolini predstavlja manji problem nego to je to bio sluaj u prolosti kada su sustavi bili glomazni i u cijelosti izraeni od strane jedne programske kue. Bilo je nemogue kupiti dio programskog sustava jednog proizvoaa, dio programskog sustava drugog proizvoaa i od kupljenog softvera sklopiti radni sustav. Veliki korisnici nisu bili zadovoljni jer je odluka za izbor jednog dobavljaa bila riskantna. To je prisililo (istina, dugo je trajalo) proizvoae softvera da ponu dizajnirati otvorene sustave. Poeli su se javljati gotovi modularni sustavi (ili dijelovi sustava) koje se moglo kupovati po dijelovima. Moglo se odabrati samo one module koji su vrhunski uspjeh ba tog proizvoaa dok su se ostali moduli bolje kvalitete kupovali kod drugih proizvoaa. Na kraju se moglo sklopiti sustav koji se sastojao od samo najboljih modula. Naalost navedeni pristup dobro zvui na papiru ali u praksi jo nije u potpunosti zaivio. Suelja za povezivanje modula nisu do kraja definirana i to je najvanije, proizvoai nisu meusobno usuglasili svoje definicije modula tako da esto moduli nisu kompatibilni - ne postoji standardizacija protokola razmjene podataka, suelja, itd. . Programski meusloj ne mora biti samo poslovnog tipa. Meusloj moe biti i sistemskog tipa, pa tako postoje komponente (kontrole) koje nadziru komunikaciju, korisnika ovlatenja, razmjenu poruka, grafiku, zvuk, animaciju, itd. . Osim toga, programski meusloj omoguuje viedimenzionalnu neovisnost platformi. Korisnici (engl. clients) i posluitelj (engl. server) mogu biti na razliitim fizikim lokacijama (distribuirani sustav). Korisnici i posluitelj ne moraju koristiti iste komunikacijske protokole. Operativni sustavi korisnika i posluitelja ne moraju biti isti. Korisnici i posluitelj ak ne moraju komunicirati u isto vrijeme (npr. primjenom redova poruka, engl. message queue). U praksi je est sluaj da mali proizvoai specijalnog softvera koji izrauju specifine aplikacije (npr. data-warehouse korisnike) prilagouju svoje proizvode velikim sustavima (npr. SAP, Oracle, itd.) kako bi mogli podatke iz takvih sustava direktno prenositi u svoje aplikacije i onda na tim podacima vriti obrade. Postoji vie razloga zbog ega neki sustavi trebaju imati vieslojnu arhitekturu. Prvi i jedan od najvanijih razloga je taj da vieslojna arhitektura uvjetuje modularni pristup dizajnu i programiranju (openito gledano, posljedica toga je lake

29 odravanje manjih modula). Drugi razlog je taj to se poslovna logika, logika pristupa podacima i logika korisnikog suelja meusobno razdvajaju ime se odravanje i nadogradnja pojednostavljuje. Testiranje gotovog sustava i pronalaenje greaka u sustavu je olakano. Osim toga, ovisno o problemskoj domeni ne treba se zaustaviti na tri sloja (npr. ISO OSI mreni model sa sedam slojeva). U praksi postoje sustavi sa etiri sloja; korisniko suelje, korisniki poslovni objekt (engl. client business object), poslovni objekt na posluitelju (engl. server business object), pristup podacima. Po broju slojeva, najjednostavnija je dvoslojna arhitektura tzv. posluitelj/korisnik (engl. client/server) arhitektura14. Dvoslojna arhitektura se sastoji od dva dijela: korisnika (engl. client) koji trai usluge od posluitelja i posluitelja (engl. server) koji nudi usluge korisnicima. Karakteristike korisnika su: izvrava se na softverskim i hardverskim resursima koji su korisniki orijentirani da nadzire korisniko suelje (sve ee je to grafiko korisniko suelje; GUI) da prikazuje podatke da prihvaa unesene podatke i u odreenim sluajevima provjerava njihovu ispravnost se izvrava u razliitom adresnom prostoru od posluitelja da alje zahtjeve posluitelju da trai usluge jednog ili vie posluitelja da nadzire lokalne resurse (tastaturu, ekran) Karakteristike posluitelja su: da opsluuje jednog ili vie korisnika (UNIX, Windows NT, Mainframe, itd.) da upravlja zajednikim resursima (RDBMS, tampa, poslovna logika, datoteke, itd.) da omoguuje podjelu istih resursa izmeu vie korisnika14

Iako korisnik/posluitelj arhitektura ne oznaava samo dvoslojnu arhitekturu (Thin Client/Fat Server i Thick Client/Slim Server) esta je praksa da se podrazumijeva dvoslojna arhitektura. U radu se podrazumijeva isto.

30 da prihvaa akcije koje je zatraio korisnik da je neovisan o korisnicima da su horizontalno15 i vertikalno proirivi16 da su programski kod i podaci centralizirani pa je odravanje i zatita laka Dvoslojna arhitektura je primjenjiva u sustavima sa do najvie pedesetak korisnika17. Korisnici komuniciraju direktno sa posluiteljem. Vieslojne arhitekture zahtijevaju dodatne resurse (engl. overhead). Zahtjevi korisnika se opsluuju putem agenata. Agenti u praksi obino predstavljaju servise za transformaciju (npr. spoj na mainframe raunalo), inteligentne servise za rukovanje zahtjevima, mjesta za lokalizaciju poslovnih pravila, itd. . Koja je uloga komponenata u vieslojnim arhitekturama. Za valjanu primjenu komponenata potrebno je slijedee: modularni pristup izgradnji dijeljenje resursa dijeljenje opih akcija, procesa, procedura, poslova i metoda sakrivanje podataka Zanimljiv je pristup Allena i Frosta [AllFro98] koji vie ne govore o slojevima (engl. tier, layer) ve o skupinama servisa to je po osobinama najblie slobodnoj vieslojnoj arhitekturi (Slika 10) od tri ranije navedene arhitekture (vidi str. 26-27).

2.4. Pravni aspekti upotrebe komponenataUpotreba komponenata postavlja s pravnog gledita promatrano niz pitanja i nejasnih odgovora. Postoje problemi koji jo uvijek nisu razrijeeni u zapadnim zemljama a o hrvatskom pravu ne treba ni govoriti. Jedini zakon u Republici Hrvatskoj koji definira problematiku vezanu uz raunalne programe je Zakon o autorskim pravima [NN99]. Zakon je nadopuna starijih zakona15

Horizontalna proirivost (engl. horizontal scalability) - poveanje broja istovremenih korisnika linearno usporava odziv sustava.

16

Vertikalna proirivost (engl. vertical scalability) - nadogradnja breg hardvera, softvera i komunikacijskih ureaja linearno poboljava performanse sustava.

17

Naravno da maksimalni broj klijenata ovisi o velikom broju razliitih faktora pa brojku od 50 korisnika po jednom posluitelju u dvoslojnoj arhitekturi treba uzeti sa rezervom.

31 o autorskim pravima iz 1993. i 1991. godine. Zakon openito govori o raunalnim programima, pravima na raunalne programe i vremenu zastarijevanja autorskog prava na raunalne programe. Po nainu na koji je zakon napisan vidi se da autori nisu u vidu imali informatiku problematiku specijalno vezanu uz programske komponente. esta pitanja koja se u praksi postavljaju su: Ako neiji sustav koristi tuu komponentu i sustav "pukne" zbog tue komponente, tko snosi materijalnu i moralnu odgovornost za nastalu tetu? Ako se koriste tue komponente koliki dio profita od prodanog gotovog proizvoda ide proizvoau komponente? Kako vriti naplatu koritenja (engl. licensing) proizvoda? Mogunosti su:jedna dozvola (engl. license) za kupljenu komponentu i pravo da se sa njom radi (npr. dalja distribucija) to god se eli. jedna ili vie razvojnih dozvola i jedna izvrna dozvola (engl. runtime license) sa kojima se dobiva pravo da se komponenta distribuira krajnjim korisnicima u sklopu finalnog programskog proizvoda. jedna ili vie razvojnih dozvola i po jedna izvrna dozvola za svakog krajnjeg korisnika finalnog programskog proizvoda. jedna ili vie razvojnih dozvola i po jedna izvrna dozvola za spoj na resurs vezan uz komponentu. Npr. dozvola za pristup bazi podataka.

Kako se gleda na komponentu-crnu kutiju smjetenu u vladinom sustavu sa povjerljivim podacima; nema 100% sigurnosti da komponenta ne radi i neke nedoputene akcije nad podacima, prosljeuje povjerljive podatke izvan sustava prema drugim sustavima, itd. . Do sada je sudska praksa donosila i pozitivne i negativne presude u sluajevima vezanim uz programske komponente. Bilo je sluajeva da je u relativno slinim parnicama konana odluka sudaca bila razliita. Proizvoai komponenata obiavaju na ambalau u kojoj se nalazi medij sa programskom komponentom staviti holografske etikete koje je teko falsificirati i na istu stave natpis slian slijedeem18:

18

engl. Shrink Wrap Licenses

32 "Prije koritenja proizvoda morate prihvatiti priloeni ugovor o najmu. Proizvod je licenciran ... ... .

Proizvoa ne snosi nikakvu odgovornost za tetu (gubitak profita, prekid rada, gubitak poslovnih podataka, ) nastalu koritenjem proizvoda. Koritenjem proizvoda prihvaate ugovor.". Otvaranje ambalae nije mogue bez lomljenja zatitne etikete pa se pokuava nametnuti tumaenje da lomljenje etikete pravno gledano predstavlja potpisivanje ugovora o koritenju i prihvaanju uvjeta proizvoaa. Drugi problem je kako se zatiti od programskih komponenata koje u sebi sadre potencijalno tetne dijelove programskog koda koji mogu bez znanja korisnika izvriti nelegalne akcije (npr. transfer osobnih podataka pohranjenih na raunala). Jedan pristup relativno rairen je tzv. potvrivanje programskih komponenata digitalnim potpisivanjem. Potvrivanje (engl. certification) moe biti provedeno od strane posebno ovlatenih organizacija (npr. VeriSign) vlastitim potpisivanjem ili jednostavnim pozivanjem na prethodne sigurne komponente iz vlastite proizvodnje. U praksi se esto primjenjuje potvrivanje od strane ovlatenih organizacija (engl. 3rd party certificate) koja programsku komponentu prije izdavanja na komercijalnom tritu alje organizaciji koja vri testiranje komponente na kritine, opasne i protuzakonite akcije te u sluaju da komponenta zadovolji kriterije provjere, organizacija digitalno potpisuje komponentu i daje odreenu garanciju da komponenta nije tetna tj. ne sadri sakrivene dijelove programskog koda.

2.5. PrimjenaPrimjena komponenata u programskim sustavima dovodi do zanimljivih efekata koje ima smisla iskoristiti jer daje pozitivan uinak na neke aspekte razvoja, izrade i koritenja programskih sustava [IDEM98]: u sustavima koji pohranjuju velike koliine podataka primjena komponenata rezultira manjom koliinom transferiranih podataka u vanjske sustave kojima su podaci potrebni. Umjesto transfera cjelokupnih tabela, putem komponenata na razini pristupa podacima sustav se propitkuje o tono odreenim podacima (manja optereenost mrenih resursa).

33 postie se vea aurnost podataka na sustav se moe "prikljuiti" vie aktivnih korisnika koji propitkuju sustav (nego kad se koristi klasini transfer podataka) korisnici mogu odabrati najbolje komponente sa nekog podruja krajnji korisnik aplikacije praktiki nema pojma da radi sa podacima iz starog sustava jer korisniko suelje i par slojeva poslovne logike i pristupa podacima sakriva stari sustav (engl. legacy system). U svijetu ali i kod nas jo uvijek ima naslijeenih starih sustava pisanih u Cobol-u i ostalim programskim jezicima starijih generacija. Kako je zbog dugotrajnog razvoja, koliine znanja ugraenog u sustav, neaurne dokumentacije i niza drugih okolnosti nemogue u kratkom vremenu prijei na informacijski sustav nove generacije, izrauju se hibridna rjeenja gdje se u odreenom vremenskom razdoblju poslovanje izvodi na oba sustava koji meusobno surauju (razmjenjuju podatke). Komponente mogu sluiti kao most za relativno transparentan pristup podacima u starim sustavima; komponente s navedenom ulogom se jo nazivaju omotai (engl. wrapper). Jedan od moguih pristupa bio bi da se prvo vri provjera da li traeni podaci postoje u novom sustavu, ako ne postoje ide se u potragu u stari naslijeeni sustav i tek onda ako se nita ne pronae generira se poruka da podatak ne postoji. Kako cijela logika moe biti sakrivena iza komponente, krajnji korisnik pa ak i programer aplikacije novog sustava uope ne mora znati da je najnoviji 32 procesorski PC posluitelj na 1 GHz sa najnovijim DBMS sustavom verzije 9.0 putem TCPIP protokola povezan na stari gotovo potpuno nekompatibilni VAX/VMS, Unix, CTOS ili neki trei sustav i da se podaci itaju i piu ak i na to staro raunalo. Paralelno korisnici rade i na starom i na novom sustavu. S vremenom se sve vei dio poslova prenosi na novo raunalo. Sustavi izraeni pomou komponenata vrlo su fleksibilni kada se vre izmjene u programskim modulima dijelova sustava. Mogua je dinamika zamjena dijelova sustava za vrijeme punog radnog optereenja; praktiki nije potrebno "sputanje" sustava radi zamjene i nakon toga ponovno pokretanje sustava i inicijalizacija. Naravno, za neto takvo potreban je drugaiji pristup izgradnji sustava ali dinamike izmjene u sustavu su mogue. Ovime se bitno olakava nadogradnja sustava

34 pogotovo u okolinama koje zahtijevaju sustave koji moraju biti raspoloivi 24 sata dnevno 365 dana u godini. Komponente su idealan nain distribuiranja podataka i potreba za procesorskim resursima putem Internet-a. CORBA, JavaBeans i DCOM u svojim temeljima rade sa TCPIP i ostalim mrenim komunikacijskim protokolima. Komponente za razliku od klasinih EXE modula imaju manju veliinu (ovo svojstvo moramo promatrati u kontekstu granularnosti komponenata kao jedinica programskih cjelina), lako se instaliraju na distribuiranim raunalima, podravaju kontrolu pristupa, izvravanja i zatitu, laku kontrolu greaka i kritinih dogaaja, itd. . Ako koristimo komponente kao osnovni gradivi element novog programskog sustava, mogue su naknadne izmjene u internom ponaanju komponenata bez utjecaja na okolinu. Jedan od glavnih nedostataka primjene komponenata je sluaj kada se naknadno pojavi zahtjev za izmjenama u suelju komponente nakon to je ve vei broj elemenata sustava poeo koristiti usluge komponente te je potrebno odrediti komponente koje e izmjenama biti zahvaene te ih treba prilagoditi izmijenjenoj komponenti. Primjer: Autor ovog rada je imao sreu da je na radnom mjestu poduzea u kojem trenutno radi dobio zadatak povezati Windows NT sustav sa Unisys CTOS sustavom. Unisys CTOS sustav je bio (i jo uvijek jest) sustav na kojem se vri cjelokupno poslovanje poduzea. Programska podrka je pisana u COBOL-u, podaci se pohranjuju pomou sistemskih ISAM API poziva i ini se da je dolo vrijeme da se uvede neto novo. Podaci na starom sustavu su jo uvijek vrlo aktualni i nije mogu trenutni rez od prolosti. Autor rada je dobio zadatak izvriti povezivanje NT i CTOS raunala radi efikasne razmjene podataka. Napravljen je modul na CTOS strani koji je oslukivao pakete koji su dolazili preko TCP/IP mree, interpretirao ih i vraao natrag traene podatke iz ISAM baze. Na NT strani je stajala TELNET aplikacija u kojoj je korisnik jednostavnim komandama mogao vriti upite na CTOS ISAM bazu. Zamisao je bila da se u krajnjoj fazi na WinNT strani napravi komponenta (sistemski servis) koja bi opsluivala DCOM kompatibilne aplikacije (VB, VC++, itd.).

35

3. Metodike komponentama usmjerenog programiranjaProgramiranje koritenjem komponenata i objekata je kompleksno. Razvoj sustava baziranih na komponentama ima svoje prednosti i nedostatke. Da bi se izbjegao mogui lo proizvod dobro je primijeniti valjan pristup razvoju komponenata, arhitekturi sustava i samom sustavu, jednostavno reeno - treba metodika razvoja. U stranoj literaturi se uz pojam komponentama usmjerenog programiranja19 spominju nie navedene karakteristike pristupa razvoju sustava. Komponentamaorijentirano programiranje mora podravati [Szyp98]: vieoblinost (engl. polymorphism) sa