ࡱ>            f q : bjbjt+t+ bAA+2]  R*R*R*R*+.R*΀&7*nb8c8cNcgrUkl8 ggigigigigigig$lgA_ggg rr8cNc7   %rR8cNcgg# rrgg   b S"SgNcr5D@&R*R*}fSVEU ILI`TE U ZAGREBU FAKULTET STROJARSTVA I BRODOGRADNJE OBJEKTNO ORIJENTIRANI PRISTUP MODELIRANJU PROCESA KONSTRUIRANJA Disertacija Mr. sc. Neven Pavkovi, dipl. in~. Mentor: Prof. dr. Dorian Marjanovi, dipl. in~. Zagreb, 2000. PODACI ZA BIBLIOGRAFSKU KARTICU UDK: 658.512.2:681.3:621 Klju ne rije i: teorija konstruiranja, proces konstruiranja, konstruiranje pomou ra unala, objektno orijentirano modeliranje, objektno orijentirano programiranje, planiranje, prikazivanje procesa, objektne baze podataka Znanstveno podru je: Tehni ke znanosti Znanstveno polje: Strojarstvo Institucija u kojoj je rad izraen Sveu iliate u Zagrebu Fakultet strojarstva i brodogradnje Mentor: Prof. dr. sc. Dorian Marjanovi Broj stranica: 147 Broj slika 63 Broj tablica: 11 Broj koriatenih bibliografskih jedinica: 142 Datum obrane: Povjerenstvo: Prof. dr. sc. Bojan Jerbi Prof. dr. sc. Dorian Marjanovi Prof. dr. sc. Jo~e Duhovnik Prof. dr. sc. Dragutin ` ap Prof. dr. sc. Izvor Grubiai Institucije na kojima je rad pohranjen: Fakultet strojarstva i brodogradnje Zagreb Nacionalna i sveu iliana knji~nica Zagreb Zahvaljujem mentoru, prof. dr. Dorianu Marjanoviu na savjetima, korisnim raspravama i podraci u tijeku izrade ovog rada. Primjedbe i savjeti lanova povjerenstva takoer su puno pomogli da kona na verzija rada bude kvalitetnija. Djelatnici Laboratorija za osnove konstruiranja doprinijeli su ovom radu kroz brojne analize i rasprave tijekom zajedni kih istra~ivanja na projektu kojeg je dio i ova disertacija. Ministarstvo znanosti i tehnologije Republike Hrvatske takoer je potpomoglo izradu ovog rada financiranjem projekta 120-015 "Razvoj modela ICAD sustava". Na kraju, posebno se zahvaljujem svojoj supruzi i roditeljima na velikom strpljenju i podraci. SADR}AJ POPIS SLIKA IV POPIS TABLICA V PREDGOVOR VI SA}ETAK VII SUMMARY VIII  TOC \o "1-3" 1. Uvod  PAGEREF _Toc409163438 \h 1 1.1 Opis zadatka (definicija problema)  PAGEREF _Toc409163439 \h 2 1.2 Cilj istra~ivanja i hipoteza  PAGEREF _Toc409163440 \h 3 1.3 Znanstveni doprinos  PAGEREF _Toc409163441 \h 4 1.4 Polaziata  PAGEREF _Toc409163442 \h 5 1.5 Metodologija istra~ivanja  PAGEREF _Toc409163443 \h 6 2. Pregled stanja i smjerova istra~ivanja  PAGEREF _Toc409163444 \h 7 2.1 Stanje i smjerovi istra~ivanja u Znanosti o konstruiranju  PAGEREF _Toc409163445 \h 7 2.2 Situacija u razvoju CAD i CAE sustava  PAGEREF _Toc409163446 \h 10 2.2.1 Istra~ivanja unapreenja CAD i CAE sustava  PAGEREF _Toc409163447 \h 11 3. Analiza procesa konstruiranja  PAGEREF _Toc409163448 \h 14 3.1 Zna ajke procesa konstruiranja  PAGEREF _Toc409163449 \h 14 3.2 Konstruiranje kao rjeaavanje zadatka  PAGEREF _Toc409163450 \h 15 3.2.1 Struktura operacija u procesu konstruiranja  PAGEREF _Toc409163451 \h 17 3.2.2 Ograni enja i odluke u procesu konstruiranja  PAGEREF _Toc409163452 \h 19 3.2.3 Vrste zadataka, odnosno konstrukcija  PAGEREF _Toc409163453 \h 20 3.2.4 Metode konstruiranja  PAGEREF _Toc409163454 \h 21 3.2.5 Napredovanje u procesu rjeaavanja zadatka  PAGEREF _Toc409163455 \h 21 3.3 Zaklju ci provedene analize procesa konstruiranja  PAGEREF _Toc409163456 \h 22 4. Pristupi i polaziata modeliranja procesa konstruiranja  PAGEREF _Toc409163457 \h 24 4.1 Pregled zna ajnijih "teoretskih" modela procesa konstruiranja  PAGEREF _Toc409163458 \h 24 4.1.1 Proceduralni model procesa konstruiranja prema VDI 2221  PAGEREF _Toc409163459 \h 24 4.1.2 Opi model procesa konstruiranja (Hubka, Eder)  PAGEREF _Toc409163460 \h 26 4.1.3 Opa teorija konstruiranja (Yoshikawa, Tomiyama)  PAGEREF _Toc409163461 \h 28 4.1.4 Aksiomatska teorija konstruiranja (Suh)  PAGEREF _Toc409163462 \h 29 4.1.5 Osvrt na prikaz teorija o konstruiranju  PAGEREF _Toc409163463 \h 31 4.2 Problematika modeliranja  PAGEREF _Toc409163464 \h 33 4.2.1 Informacijski modeli (sustavi)  PAGEREF _Toc409163465 \h 33 4.3 Proces konstruiranja i metode planiranja u umjetnoj inteligenciji  PAGEREF _Toc409163466 \h 34 4.3.1 Pristupi planiranju  PAGEREF _Toc409163467 \h 35 4.3.2 Pretra~ivanje i problem interakcije podproblema  PAGEREF _Toc409163468 \h 36 4.3.3 Okolina (prostor) izvoenja plana  PAGEREF _Toc409163469 \h 37 4.4 Topologija prikaza akcija u procesu konstruiranja  PAGEREF _Toc409163470 \h 38 4.4.1 Matri ni prikaz grafova  PAGEREF _Toc409163471 \h 41 4.5 Metode prikaza procesa  PAGEREF _Toc409163472 \h 43 5. Objektno orijentirani pristup modeliranju i programiranju  PAGEREF _Toc409163473 \h 45 5.1 Modeliranje objektima  PAGEREF _Toc409163474 \h 45 5.2 Osnovna terminologija  PAGEREF _Toc409163475 \h 46 5.3 Razvoj metoda modeliranja objektno orijentiranih programskih sustava  PAGEREF _Toc409163476 \h 48 5.4 Unified Modeling Language (UML)  PAGEREF _Toc409163477 \h 48 5.5 Usporedba UML-a i EXPRESS-a  PAGEREF _Toc409163478 \h 49 5.6 Objektne baze podataka  PAGEREF _Toc409163479 \h 50 6. Koncipiranje objektno orijentiranog modela procesa konstruiranja  PAGEREF _Toc409163480 \h 52 6.1 Preslikavanje pojmova realnog svijeta u konceptualni i objektni model  PAGEREF _Toc409163481 \h 52 6.2 Problematika formiranja modela procesa konstruiranja u konceptualnoj domeni  PAGEREF _Toc409163482 \h 53 6.3 Proces razvoja objektnog modela  PAGEREF _Toc409163483 \h 56 6.4 Koncepcija osnovne strukture (arhitekture) sustava  PAGEREF _Toc409163484 \h 57 7. Prijedlog entiteta objektnog modela procesa konstruiranja  PAGEREF _Toc409163485 \h 60 7.1 Strukturalni (gradbeni) elementi  PAGEREF _Toc409163486 \h 61 7.1.1 Parametar konstrukcije  PAGEREF _Toc409163487 \h 61 7.1.2 Baza parametara  PAGEREF _Toc409163488 \h 65 7.1.3 Prikaz proizvoda (skup informacija o proizvodu)  PAGEREF _Toc409163489 \h 72 7.1.4 Struktura proizvoda (objekt iz fizi ke domene)  PAGEREF _Toc409163490 \h 78 7.1.5 Akcija  PAGEREF _Toc409163491 \h 79 7.1.6 Su elje programskog alata  PAGEREF _Toc409163492 \h 82 7.1.7 Zadatak  PAGEREF _Toc409163493 \h 84 7.1.8 Konstruktor  PAGEREF _Toc409163494 \h 85 7.2 Relacije u objektnom modelu procesa konstruiranja  PAGEREF _Toc409163495 \h 86 7.2.1 Matri ni prikaz relacija  PAGEREF _Toc409163496 \h 87 7.2.2 Mre~a relacija izmeu entiteta modela procesa konstruiranja  PAGEREF _Toc409163497 \h 89 7.2.3 Matrica informacijske zavisnosti konstrukcijskih zadataka  PAGEREF _Toc409163498 \h 90 7.2.4 Relacije zavisnosti parametara konstrukcije  PAGEREF _Toc409163499 \h 93 7.2.5 Relacije "pripadnosti" izmeu razli itih klasa objekata  PAGEREF _Toc409163500 \h 94 7.2.6 Izrazi kao elementi zapisa ograni enja i pravila  PAGEREF _Toc409163501 \h 96 7.2.7 Ograni enja  PAGEREF _Toc409163502 \h 97 7.2.8 Pravila odlu ivanja  PAGEREF _Toc409163503 \h 98 7.2.9 Generiranje i a~uriranje zapisa ograni enja i pravila odlu ivanja  PAGEREF _Toc409163504 \h 99 7.3 Elementi prikaza i kontrole izvoenja procesa konstruiranja  PAGEREF _Toc409163505 \h 100 7.3.1 Nacrt plana konstruiranja  PAGEREF _Toc409163506 \h 101 7.3.2 Elementi plana konstruiranja (dekompozicija i prikaz procesa konstruiranja planom)  PAGEREF _Toc409163507 \h 103 7.3.3 vor plana konstruiranja  PAGEREF _Toc409163508 \h 104 7.3.4 Su elje za prikaz plana konstruiranja  PAGEREF _Toc409163509 \h 116 7.3.5 Kreiranje plana konstruiranja  PAGEREF _Toc409163510 \h 117 7.3.6 Izvoenje plana konstruiranja  PAGEREF _Toc409163511 \h 119 7.4 Komponente realizacije sustava ra unalne podrake konstruiranju  PAGEREF _Toc409163512 \h 120 7.4.1 Programske komponente objektnog modela procesa konstruiranja  PAGEREF _Toc409163513 \h 121 7.4.2 Baze znanja i baze podataka  PAGEREF _Toc409163514 \h 122 7.4.3 Baza programskih alata  PAGEREF _Toc409163515 \h 123 8. Realizacija predlo~enog objektnog modela  PAGEREF _Toc409163516 \h 124 8.1 Modeliranje relacija  PAGEREF _Toc409163517 \h 124 8.1.1 Pokaziva i na objekte  PAGEREF _Toc409163518 \h 125 8.1.2 Ugraeni objekti  PAGEREF _Toc409163519 \h 125 8.1.3 Skup  PAGEREF _Toc409163520 \h 125 8.1.4 Reference prema zahtjevu  PAGEREF _Toc409163521 \h 126 8.1.5 Zavisni objekti  PAGEREF _Toc409163522 \h 126 8.1.6 Primjer zapisa razli itih vrsta relacija u POET bazi  PAGEREF _Toc409163523 \h 126 8.2 Specifikacija predlo~enog objektnog modela koriatenjem UML-a  PAGEREF _Toc409163524 \h 128 8.2.1 Gradbeni elementi modela procesa konstruiranja  PAGEREF _Toc409163525 \h 129 8.2.2 Relacije u modelu procesa konstruiranja  PAGEREF _Toc409163526 \h 130 8.2.3 Izrazi, ograni enja i pravila odlu ivanja  PAGEREF _Toc409163527 \h 133 8.2.4 Elementi prikaza i kontrole izvoenja procesa konstruiranja  PAGEREF _Toc409163528 \h 135 8.3 Primjer plana konstruiranja  PAGEREF _Toc409163529 \h 138 9. Zaklju ak  PAGEREF _Toc409163530 \h 145  LITERATURA 148 BIBLIOGRAFIJA 155 DODATAK 1: RJE NIK POJMOVA 161 }IVOTOPIS 162 POPIS SLIKA:  TOC \c "Slika" Slika 1: Preslikavanja od realnosti do ra unalnog modela  PAGEREF _Toc409163591 \h 6 Slika 2: Taksonomija podru ja istra~ivanja u znanosti o konstruiranju, prema [17]  PAGEREF _Toc409163592 \h 9 Slika 3: Podru ja istra~ivanja primjene ra unala u znanosti o konstruiranju prema [55]  PAGEREF _Toc409163593 \h 13 Slika 4: Model procesa konstruiranja prema [59]  PAGEREF _Toc409163594 \h 16 Slika 5: Struktura aktivnosti u konstrukcijskom procesu prema [60]  PAGEREF _Toc409163595 \h 17 Slika 6: Metoda to no usmjerenih koraka  PAGEREF _Toc409163596 \h 22 Slika 7: Faze procesa konstruiranja prema [21]  PAGEREF _Toc409163597 \h 25 Slika 8: Dijagram toka procesa konstruiranja prema [68]  PAGEREF _Toc409163598 \h 26 Slika 9: Opi model procesa konstruiranja prema [22]  PAGEREF _Toc409163599 \h 27 Slika 10: Shema preslikavanja unutar prostora GDT prema [70]  PAGEREF _Toc409163600 \h 28 Slika 11: Koncept metamodela [70]  PAGEREF _Toc409163601 \h 29 Slika 12: Domene procesa konstruiranja po aksiomatskoj teoriji [74]  PAGEREF _Toc409163602 \h 30 Slika 13: Tri topologije prikaza akcija u procesu konstruiranja  PAGEREF _Toc409163603 \h 39 Slika 14: Izvoenje po predvienim i nepredvienim putanjama  PAGEREF _Toc409163604 \h 40 Slika 15: Redundantni zapisi u hijerarhijskom stablu  PAGEREF _Toc409163605 \h 41 Slika 16: Usmjereni graf i dio njegove matrice susjedstva  PAGEREF _Toc409163606 \h 42 Slika 17: Primjer usmjerenog grafa i pripadajue matrice incidencije  PAGEREF _Toc409163607 \h 42 Slika 18: Dijagram objekta prema [97] 46 Slika 19: Zone pristupa objektu (prema [97])  PAGEREF _Toc409163608 \h 46 Slika 20: }ivotni ciklus klase i njenih objekata prema [98]  PAGEREF _Toc409163609 \h 47 Slika 21: Proces aktiviranja i deaktiviranja objekata, prema [99]  PAGEREF _Toc409163610 \h 51 Slika 22: Apstrahiranje entiteta i njihovo preslikavanje u objektni model  PAGEREF _Toc409163611 \h 53 Slika 23: Gubitak informacija pri formiranju prikaza konkretnog procesa konstruiranja [5]  PAGEREF _Toc409163612 \h 54 Slika 24: Izrada dokumentacije o proizvodu u odnosu na ugovaranje i izradu proizvoda  PAGEREF _Toc409163613 \h 55 Slika 25: Shema osnovnih elemenata strukture objektnog modela procesa konstruiranja  PAGEREF _Toc409163614 \h 58 Slika 26: Primjer parametara koji moraju dijeliti istu vrijednost  PAGEREF _Toc409163615 \h 63 Slika 27: Povezivanje "zajedni kih" atributa objekata referenciranjem istog parametra  PAGEREF _Toc409163616 \h 64 Slika 28: Organizacijska struktura baze parametara  PAGEREF _Toc409163617 \h 67 Slika 29: Prijedlog realizacije baze parametara u relacijskoj bazi  PAGEREF _Toc409163618 \h 69 Slika 30: Skup referenci na parametre u bazi parametara kao podskup objekta prikaza proizvoda  PAGEREF _Toc409163619 \h 74 Slika 31: Dijagram prijedloga klasifikacije prikaza proizvodu  PAGEREF _Toc409163620 \h 76 Slika 32: Preslikavanje informacija o proizvodu u logi ki i objektni model  PAGEREF _Toc409163621 \h 77 Slika 33: Izvraavanje akcije u tijeku izvoenja procesa konstruiranja  PAGEREF _Toc409163622 \h 80 Slika 34: Prijedlog klasifikacije akcija  PAGEREF _Toc409163623 \h 81 Slika 35: Transfer vrijednosti parametara preko su elja programskog alata  PAGEREF _Toc409163624 \h 82 Slika 36: Klasifikcija su elja programskih alata  PAGEREF _Toc409163625 \h 84 Slika 37: Grafi ki prikaz binarne relacije  PAGEREF _Toc409163626 \h 86 Slika 38: Osnovna matrica i jedna varijanta submatrice  PAGEREF _Toc409163627 \h 88 Slika 39: Preslikavanje matrice u listu  PAGEREF _Toc409163628 \h 88 Slika 40: Matrica prikaza informacijskih zavisnosti konstrukcijskih zadataka  PAGEREF _Toc409163629 \h 90 Slika 41:"Neorganizirana matrica" 91 Slika 42:Ista matrica nakon reorganizacije  PAGEREF _Toc409163630 \h 91 Slika 43: Tri mogua redoslijeda izvraavanja dva konstrukcijska zadatka  PAGEREF _Toc409163631 \h 92 Slika 44: Reference vora na druge objekte i proces izvoenja vora  PAGEREF _Toc409163632 \h 108 Slika 45: Vrste veza vorova plana konstruiranja  PAGEREF _Toc409163633 \h 112 Slika 46: Povezivanje razli itih vrsta vorova plana  PAGEREF _Toc409163634 \h 114 Slika 47: Komponente ra unalne podrake u procesima kreiranja i izvoenja plana konstruiranja  PAGEREF _Toc409163635 \h 121 Slika 48: Skup referenci na objekte ("lset")  PAGEREF _Toc409163636 \h 128 Slika 49: Pokaziva  na objekt druge klase 128 Slika 50: Ugraeni objekt  PAGEREF _Toc409163637 \h 128 Slika 51: Struktura zapisa objektnog modela procesa konstruiranja  PAGEREF _Toc409163638 \h 129 Slika 52: Klase i asocijacije u paketu "relacije"  PAGEREF _Toc409163639 \h 130 Slika 53: Matrice zavisnosti parametara i zadataka  PAGEREF _Toc409163640 \h 131 Slika 54: Pregled referenci jedne instance klase "zavisnost parametara"  PAGEREF _Toc409163641 \h 132 Slika 55: Relacije pripadnosti izmeu razli itih klasa  PAGEREF _Toc409163642 \h 133 Slika 56: Reference izraza na operande  PAGEREF _Toc409163643 \h 134 Slika 57: Asocijacije klase "izraz"  PAGEREF _Toc409163644 \h 135 Slika 58: Klase i asocijacije u paketu "prikaz i kontrola procesa"  PAGEREF _Toc409163645 \h 135 Slika 59: Klase vorova i njihovih veza  PAGEREF _Toc409163646 \h 136 Slika 60: Matrice zapisa veza izmeu vorova plana  PAGEREF _Toc409163647 \h 137 Slika 61: Asocijacije (relacije) vora plana konstruiranja  PAGEREF _Toc409163648 \h 138 Slika 62: Skica konstrukcije rotora asinhronog elektromotora  PAGEREF _Toc409163649 \h 140 Slika 63: Grafi ki prikaz razmatranog primjera plana  PAGEREF _Toc409163650 \h 140  POPIS TABLICA:  TOC \c "Tablica" Tablica 1: Liste vorova i bridova primjera grafa sa slike 17  PAGEREF _Toc409163653 \h 43 Tablica 2: Entiteti i komponente objektnog modela procesa konstruiranja  PAGEREF _Toc409163654 \h 60 Tablica 3: Povezivanje strukturalnih elemenata modela procesa konstruiranja  PAGEREF _Toc409163655 \h 89 Tablica 4: Matrica zavisnosti parametara konstrukcije  PAGEREF _Toc409163656 \h 93 Tablica 5: Shema zapisa zavisnosti parametara konstrukcije  PAGEREF _Toc409163657 \h 94 Tablica 6: Prikaz relacije "pripadnosti" izmu objekata dviju klasa  PAGEREF _Toc409163658 \h 95 Tablica 7: Matrica "aktivnost-tema" prema [130]  PAGEREF _Toc409163659 \h 103 Tablica 8: Primjer zapisa redoslijeda obrade skupa referenci vora  PAGEREF _Toc409163660 \h 105 Tablica 9: Zapis redoslijeda obrade unutar dva skupa referenci vora  PAGEREF _Toc409163661 \h 106 Tablica 10: Zapis skupa realcija zavisnosti izmeu instanci iste klase, sveden na listu  PAGEREF _Toc409163662 \h 131 Tablica 11: Shema referenci vorova razmatranog primjera plana  PAGEREF _Toc409163663 \h 144  PREDGOVOR Izrada ovog rada potaknuta je viaegodianjim istra~iva kim radom u podru ju unapreenja ra unalne podrake procesu konstruiranja strojarskih proizvoda, te iskustvom autora u primjeni i razvoju elemenata CAD sustava. Postojeim CAD sustavima nedostaje podraka odvijanju (modeliranju) konstrukcijskog procesa. Razvijeni teoretski modeli procesa konstruiranja veinom nisu pogodni za direktnu ra unalnu implementaciju. Promatrajui postojee ra unalne alate koji se koriste u procesu konstruiranja, takoer je potrebno istra~iti principe i metode njihove integracije u cjeloviti (samim time i efikasniji) sustav za ra unalnu podraku razvoju proizvoda. Unapreenje mogunosti i efikasnosti primjene CAD sustava treba pridonijeti poveanju produktivnosti i boljoj organizaciji procesa konstruiranja, a time i poveanju profitabilnosti cjelokupnog proizvodnog sustava. Istra~iva kim projektom broj 120-015  Model inteligentnog CAE sustava predvieno je istra~ivanje modeliranja ra unalne podrake tijeku i kontroli odvijanja konstrukcijskog procesa, te je ova disertacija dio cjelokupnih istra~ivanja unutar navedenoga projekta. O ekuje se da objektno orijentirani pristup modeliranju procesa konstruiranja doprinese fleksibilnosti i otvori mogunosti implementacije viae parcijalnih modela i metoda unutar istog okvira. SA}ETAK Tema ove disertacije razvoj je osnovne strukture objektno orijentiranog modela procesa konstruiranja. Predlo~ena struktura trebala bi se upotrijebiti kao sustav "otvorene kutije s alatima". Pri tome je sustav koncipiran tako da njegova primjena ne ovisi o vrsti konstrukcije, niti je vezana za odreenu fazu procesa konstruiranja. U takvom pristupu, svaki pojam, relacija i druge "realne stvari" iz domene procesa konstruiranja pokuaale su se modelirati kao objekti. Pretpostavljeno je da objektno orijentirana metodologija nudi pogodnije i fleksibilnije na ine modeliranja programskih sustava od drugih raspolo~ivih tehnika. Proces konstruiranja promatran je kao niz transformacija od inicijalnog stanja skupa podataka, ograni enja i ciljeva do kona nog stanja koje predstavlja potpuni opis proizvoda koji se konstruira. Takve transformacije obavljaju pojedine osobe ili timovi, te izdvojeni ili integrirani programski alati. Glavni rezultat istra~ivanja u ovom radu je prijedlog i definicija skupa osnovnih entiteta konceptualnog modela procesa konstruiranja. Osnovni strukturalni entiteti definirani su kao: konstrukcijski parametar, objekt prikaza proizvoda, objekt prikaza strukture proizvoda, su elje programskog alata, akcija, konstruktor (kao aktivni djelatnik procesa), te konstrukcijski zadatak. Navedeni entiteti preslikani su u osnovne klase objektno orijentiranog ra unalnog modela procesa konstruiranja. Kao sredianja tema istra~ivanja, analizirana je kompleksna mre~a relacija izmeu entiteta predlo~enog modela procesa konstruiranja. Pokazalo se da je takvu mre~u relacija mogue efikasno modelirati (i njome manipulirati) u okru~enju objektne baze podataka. Model procesa konstruiranja graen je "bottom up" pristupom - osnovni strukturalni entiteti i mre~a relacija koriste se kao gradbeni elementi slo~enih entiteta koji modeliraju tijek i kontrolu odvijanja procesa konstruiranja. Proces konstruiranja prikazan je planom - skupom vorova i njihovih veza u usmjerenom grafu. Veze izmeu vorova prikazuju tokove podataka i/ili unaprijed planirane redoslijede izvraavanja vorova. Analizirane su mogue topologije prikaza plana, te procesi kreiranja i izvoenja plana, uz naznake mogunosti implementacije tzv. "dinami kog planiranja" - mijenjanja plana u tijeku njegova izvoenja. vor plana konstruiranja modelira jednu etapu procesa konstruiranja koja uklju uje provjeru preduvjeta, listu akcija, provjeru postuvjeta, te odlu ivanje o daljnjem tijeku procesa. Preduvjeti i postuvjeti sadr~e skupove ograni enja i pravila u kojima se referenciraju parametri konstrukcije i atributi svih klasa objekata predlo~enog modela. Struktura predlo~enog modela dokumentirana je u UML jeziku, koriatenjem programskog paketa "Rational Rose 2000". Primjer implementacije modela realiziran je u "POET" objektnoj bazi. Klju ne rije i : in~enjersko konstruiranje, teorija konstruiranja, proces konstruiranja, konstruiranje pomou ra unala, modeliranje procesa konstruiranja, objektno orijentirano modeliranje, UML, objektne baze podataka, planiranje, prikazivanje procesa UDK 658.512.2:681.3:621 OBJECT-ORIENTED APPROACH TO DESIGN PROCESS MODELLING SUMMARY The subject of this thesis is the development of the object-oriented design process model framework. The proposed framework should be used as an open toolbox, independently of the design task class and the design process phase. In such an approach, every occurrence, relation and other real-world 'things' from the domain of the design process are attempted to be modelled as objects. It is assumed that the object-oriented methodologies can provide more appropriate and flexible ways of software system modelling than the other techniques. The design process is here viewed as a sequence of transitions from an initial state of data, constraints and goals to a final state: a complete description of the mechanical artefact being designed. These transitions are allocated to individual participants or teams, and individual or integrated computational tools or models. The main results of this research are identification and description of the basic structural, relational and behavioural entities of the design process model. The proposed model is built upon following basic structural entities: design parameter, product description object (any type of document), product structure object (part), interface to external software tool, action, designer (as an actor in the process) and the design task. These entities are modelled as the basic classes of the object-oriented design process model. The complex network of relations between design process model entities is analysed as a central issue of the presented research. It turned out that a very large and complex object network could be efficiently modelled and managed in an object database environment. Thus, a design process model is built using a "bottom up" approach in which the basic structural entities and the network of relations are used as a building blocks for more complex entities which model and control the design process flow. A design process is represented with design plan - a collection of nodes and their connections in a directed graph. The connections between nodes represent the information flow and/or the preplanned execution paths. Possible design plan topologies, the plan generation and exploitation issues are discussed, as well as the possibilities of implementing dynamic changes while the plan is being executed. A design plan node models one step of the design process, including: checking of preconditions, list of actions, checking the postconditions and deciding about the next step. Preconditions and postconditions include sets of constraints and rules. Constraints and rules include references to design parameters and attributes of all classes of objects that constitute the design process model. The structure of the proposed model is documented in the UML language, using "Rational Rose 2000" software tool. An example of "real world" implementation is realised in POET object database. Keywords : engineering design, design theory, design process, computer-based design support, design process, design process modelling, object-oriented technology, UML, object databases, planning, process representations UDC 658.512.2:681.3:621 Uvod Zadatak in~enjera je primjeniti svoje znanje u rjeaavanju tehni kih problema i optimirati to rjeaenje u danim ograni enjima materijala, tehnologije i ekonomije. Radom na razvoju proizvoda - kreiranjem materijalnog svijeta, in~enjeri doprinose unapreenju ope kvalitete ~ivota. Razvoj proizvoda, kao temelj in~enjerskog djelovanja, mo~e se podijeliti na konstruiranje, ili idejno stvaralaatvo, te samu izradu, odnosno proizvodno stvaralaatvo. Znanje, ideje i sposobnosti konstruktora imaju fundamentalni utjecaj na prirodu izraenog proizvoda, njegov status na tr~iatu i njegovu ukupnu profitabilnost  REF _Ref409167827 \r \h [1]. Konstruiranje je intelektualno nastojanje da se zadovolje odreeni zahtjevi na najbolji mogui na in. To je in~enjerska aktivnost koja djeluje na gotovo svaku sferu ljudskog ~ivota, temelji se na otkriima i zakonima znanosti i kreira uvjete za primjenu tih zakona na proizvodnju korisnih proizvoda  REF _Ref409171766 \r \h [2]. Va~nost konstruiranja (i s ekonomskog aspekta, i za opi razvoj civilizacije) dovodi do razvoja nove znanstvene discipline - Znanosti o konstruiranju. Unato  velikom napretku istra~ivanja, naae razumijevanje konstruiranja ipak joa nije doseglo potpunu zrelost  REF _Ref409173045 \r \h [3]. Istra~iva i vjeruju da je mogue dublje i fundamentalnije razumijevanje konstruiranja bez ~rtvovanja kreativnosti koja generira nove proizvode, strojeve i sustave  REF _Ref409173045 \r \h [3]. U dosadaanjem razvoju Znanosti o konstruiranju razvijeno je nekoliko zna ajnijih openitih teorija konstruiranja, kao i veliki broj parcijalnih modela koji opisuju pojedine aspekte ili domene konstruiranja. Svejedno, mo~e se rei da niti jedna od razvijenih teorija nije sama za sebe dovoljna za potpuni opis i formalizaciju procesa konstruiranja na na in koji bi omoguio razvoj integrirane ra unalne podrake  REF _Ref409238939 \r \h [4]. Pri modeliranju ra unalne podrake, proces konstruiranja mo~e se tretirati kao niz transformacija informacija i generiranja informacija, od po etnog stanja (zahtjeva) do krajnjeg stanja - potpunog opisa proizvoda. Proces konstruiranja ne bi trebalo promatrati kao stati ku institucionaliziranu strukturu, nego kao dinami ku mre~u koja se stvara u realnom vremenu kako ciljevi, potrebe, prioriteti i resursi evoluiraju  REF _Ref409239013 \r \h [5]. U okru~enju integriranog sustava ra unalne podrake, konstruktor bi trebao raditi sa "skupom alata" koji mu omoguuju da kreira parcijalne modele procesa konstruiranja prema svojim potrebama. Takav sustav trebao bi biti neovisan o vrstama konstrukcijskih zadataka, a ne bi ga trebalo vezati niti uz faze procesa konstruiranja. Prednosti koje pru~a objektna tehnologija (u odnosu na druge metode) trebala bi omoguiti razvoj ~eljene strukture programskog sustava za kompletnu ra unalnu podraku procesu konstruiranja. Objektno orijentirana analiza zapo inje ispitivanjem "stvari iz realnog svijeta", odnosno domene problema koji se rjeaava. Te "stvari" (objekti ili entiteti) karakterizirane su atributima i ponaaanjem. U analizi se formiraju i opisuju "klase" iz domene problema i paralelno se modeliraju veze i "suradnja" meu objektima. Nakon toga, prelazi se sa modeliranja domene problema na modeliranje domene implementacije. Jedna od najveih prednosti objektne tehnologije je u tome ato su objekti isti i u domeni problema i u domeni implementacije, ato uvelike olakaava razvoj i odr~avanje sustava. Objektno orijentirana metodologija modeliranja programskih sustava intenzivno se razvija posljednjih desetak godina i dovoljno je sazrela da bi krenula prema standardizaciji. Opis zadatka (definicija problema) Razvoj ra unalne opreme i novih metoda programiranja otvorio je i nove mogunosti za podizanje ra unalne podrake konstruiranju na viau razinu. Postojeim CAD sustavima nedostaje model procesa konstruiranja i alati za povezivanje akcija, tj. planiranje i podraku prirodnom toku promialjanja konstruktora u tijeku rjeaavanja konstrukcijskog zadatka. Razvijene metode prikaza konstrukcijskog procesa koje se koriste u danaanjim CAD sustavima ograni enih su mogunosti, te efikasno funkcioniraju samo kod dobro definiranih problema uske domene. Programski sustavi ope namjene redovito su koncipirani kao skup zasebnih programskih cjelina za podraku odreenim podru jima aktivnosti konstruiranja (geometrijsko modeliranje, generiranje NC programa, analiza mehani kih svojstava, itd.), ali bez integriranog modela procesa konstruiranja. Konstrukcijski ured esto je usko grlo u procesu proizvodnje, a ujedno i mjesto gdje se koncentrira i obrauje najvei dio informacija o proizvodu. Konstruktor i/ili projektant trebao bi stoga imati na trenutnom raspolaganju prakti ki sve informacije vezane uz proizvod, od ugovaranja do povratnih informacija iz eksploatacije. Upravo tu se o ituje nu~nost integracije informacijskih tokova, pogotovo kod velikih proizvodnih sustava. Stoga se sve viae ukazuje potreba za integracijom raznorodnih postojeih aplikacija, kao i za razvojem openitog postupka prijenosa podataka izmeu njih. Ra unalni model procesa konstruiranja trebao bi podr~ati prirodni tok promialjanja, ali u isto vrijeme poslu~iti i kao platforma za integraciju CAD programskih alata te baza podataka i znanja o proizvodu i procesu proizvodnje u konzistentno okru~enje. U dosadaanjim istra~ivanjima  REF _Ref409244619 \r \h [6], pokazalo se da realizacija ovakvih kompleksnih zahtjeva u relativno jednostavnijim programskim okru~enjima (npr. relacijska baza podataka) zahtijeva velik utroaak programerskih resursa uz neizvjesne kona ne rezultate. Ra unalni pristupi tretiranju procesa konstruiranja neovisno o domeni i stupnju ponovljivosti konstrukcije relativno su rijetki u literaturi. Iterativnost i intuitivnost ine modeliranje procesa konstruiranja vrlo zahtjevnim i kompleksnim pa se openiti pristupi prete~no svode na teorijske modele, dok se ra unalni modeli procesa konstruiranja uglavnom svode na primjenu odreene metode konstruiranja ili su ograni eni unutar odreene domene. Modeliranjem ra unalne podrake planiranju i izvoenju konstrukcijskog procesa mo~e se ostvariti samo pribli~an model realnog procesa konstruiranja. Jedan od moguih pristupa unapreenju ra unalne podrake konstrukcijskog procesa je koncipiranje skupa programskih alata koji ine okru~enje za modeliranje prikaza tijeka procesa konstruiranja, neovisno o domeni i vrsti konstrukcijskog zadatka. Stupanj pribli~enja ra unalnog modela realnosti ovisi o: spoznajama teorije konstruiranja - razumijevanju procesa konstruiranja mogunostima danaanjih informati kih tehnologija (viae programskih nego hardverskih) i metodologiji njihove primjene. Objektno orijentiranom tehnikom programiranja mogue je koncipirati strukturalno vrlo kompleksne modele uz relativno razuman utroaak programerskih resursa. Proces konstruiranja mo~e se raa laniti na strukturu operacija i aktivnosti koje se mogu promatrati kao procesi transformacije informacija unutar skupa informacija o proizvodu koji se konstruira. Tako poopeni proces mo~e se opisati kao djelatnost koja se sastoji od niza akcija i njihovih meusobnih relacija. Svaka od akcija vrai pretvorbu informacija, tj. na temelju skupa ulaznih informacija generira skup izlaznih informacija. Akcije su etape unutar procesa, a grani na stanja etapa (odnosno meustanja) mo~emo zamisliti kao prostor stanja procesa. Svaki proces sastoji se od slijeda aktivnosti koji se mo~e formulirati planom. Rad se osniva na pretpostavci da jezgru modela tijeka procesa konstruiranja treba initi ra unalni zapis plana modeliranog mre~om vorova koji predstavljaju izvoenje akcija. Svaka akcija odnosno operator kao i njihove meusobne relacije u procesu konstruiranja mogu se prikazati kao objekti sa pripadajuim svojstvima. Prednosti na ela objektne tehnike programiranja prvenstveno trebaju omoguiti realizaciju mre~nog modela prostora stanja procesa, ali i koncipiranje kompleksne i fleksibilne strukture modela procesa konstruiranja, kao i implementaciju metoda umjetne inteligencije. Strukture in~enjerskih podataka daleko su raznorodnije i slo~enije od podataka u npr. poslovnim aplikacijama. Veze meu strukturama su mnogobrojne, a iste strukture mogu imati razli ite uloge. Topologija procesa konstruiranja mo~e se promatrati kao dvije kompleksne mre~e relacija: slo~ene viaerazinske veze izmeu struktura in~enjerskih podataka mre~a relacija redoslijeda izvoenja etapa procesa, koja redovito uklju uje i iterativne podprocese Istra~ivanja ovog rada usmjeriti e se na mogunosti ra unalnog modeliranja navedenih mre~a relacija. Te dvije mre~e relacija ne mogu se promatrati odvojeno, nego se i one meusobno pro~imaju, tj. relacije jedne grupe mogu uklju ivati relacije druge grupe, kroz viae razina referenciranja. Pod pojmom "mre~na topologija procesa konstruiranja", u daljnjem tekstu podrazumijevati e se topologija spomenutih mre~a relacija. Cilj istra~ivanja i hipoteza Naprednije metode upravljanja kompleksnim strukturama koje pru~a objektna tehnologija trebaju omoguiti realizaciju modela procesa konstruiranja koji je realniji i transparentniji od modela realiziranih drugim metodama programiranja. Pri tome se pod realnijim modelom podrazumijeva da su semanti ke razlike u odnosu na stvarni svijet ato manje. Transparentniji model zna i da je konstruktoru prirodniji, razumljiviji i jednostavniji za u enje i uporabu. Pored toga prednosti primjene objektne tehnologije ogledaju se u sustavima koji su fleksibilniji za primjenu, dogradnju i odr~avanje. Osnovni cilj ovog rada je koncipiranje i kreiranje strukture ra unalnog modela procesa konstruiranja koriatenjem objektno orijentirane metodologije modeliranja. Za tako odreeni cilj postavlja se hipoteza u tri meusobno spregnute to ke: Mre~na topologija procesa konstruiranja modelira se objektno orijentiranim metodama. Pretpostavlja se da je objektnim metodama mogue realizirati, zapisati i dograivati kompleksnu viaerazinsku mre~u relacija izmeu skupova i struktura podataka na efikasniji na in nego drugim raspolo~ivim metodama. Ova hipoteza verificirati e se realizacijom modela mre~e relacija u objektnoj bazi podataka. Entiteti prostora fenomenoloakog modela procesa konstruiranja preslikavaju se u prostor objektnog modela. Nu~an preduvjet u razradi prve to ke hipoteze je teoretsko uopivanje i definiranje svih pojava i pojmova koji odreuju konstrukcijski proces kao entiteta fenomenoloakog modela. Pri verifikaciji hipoteze nastojati e se ostvariti preslikavanje "jedan za jedan", tj. da svakom entitetu fenomenoloakog modela odgovara jedna klasa objektnog modela. Temeljem osnovnih klasa objektnog modela grade se slo~eni objekti koji modeliraju prikaz procesa i dinamiku izvoenja procesa konstruiranja. Pretpostavlja se da je mogue koncipirati model procesa konstruiranja "bottom-up" pristupom, tako da se slo~eniji elementi prikaza procesa grade kombiniranjem, referenciranjem i agregacijom osnovnih elemenata strukture modela. Takva koncepcija treba osigurati i veu fleksibilnost modela pri uvoenju u eksploataciju. Pri razradi i dokazivanju prve to ke hipoteze, nu~no je prvo provjeriti i dokazati preduvjete postavljene u druge dvije to ke. Primarni cilj razvoja "teoretskih" modela procesa konstruiranja je produbiti razumijevanje i spoznaje o procesu konstruiranja, te razviti egzaktne formalizacije pri opisivanju procesa. Spoznaje "teoretskih" modela u ovom istra~ivanju nastojati e se preslikati i primjeniti pri koncipiranju "ra unalnog modela". Pri tome e se u svakoj situaciji koncepcija modela prilagoavati mogunostima ra unalne implementacije. Koncipirani "ra unalni model" predlo~iti e se kao osnova kreiranja ra unalne podrake tijeku odvijanja procesa konstruiranja. Tako formulirano istra~ivanje implicira zadovoljenje skupa zahtjeva, koji se mogu promatrati kao parcijalni ciljevi: Ra unalni model procesa konstruiranja treba biti openito primjenjiv, tj. ne smije ovisiti o fazi procesa konstruiranja niti o vrsti konstrukcijskog zadataka. Proces konstruiranja promatran kao proces obrade i generiranja informacija na isti na in se mo~e tretirati u svim fazama i za sve vrste zadataka. Stoga e se struktura i elementi modela definirati prema kriterijima procesa obrade i generiranja informacija. Entiteti i struktura modela trebaju poslu~iti kao platforma za integraciju raznorodnih programskih alata koji se koriste u procesu konstruiranja. Sustav treba biti koncipiran tako da slu~i kao "pomonik" i "savjetnik" konstruktora, za razliku od te~nji prema "automatskom konstruiranju" Treba postii ato vei mogui stupanj fleksibilnosti modela, odnosno primjenjivosti za razli ite uvjete i okoline izvoenja procesa konstruiranja. Jezgru modela i organizaciju strukture modela treba koncipirati tako da se cijeli sustav modela mo~e prilagoavati i dograivati prema specifi nim potrebama i postojeim modelima i pravilima izvoenja procesa konstruiranja u odreenoj konkretnoj okolini (konstrukcijskom uredu). Znanstveni doprinos Razvijeni ra unalni model procesa konstruiranja treba biti osnova integracije postojeih CAD alata i istovremeno slu~iti kao ra unalna podraka odvijanju procesa konstruiranja na viaoj razini apstrakcije zadatka nego sa sadaanjim programskim alatima. Integrirani programski sustav koji bi uz standardne mogunosti CAD (CAE) paketa sadr~avao i model procesa konstruiranja trebao bi omoguiti konstruktoru da u kraem vremenu i s manje rutinskih aktivnosti mo~e ponoviti procese analize i sinteze skupova informacija o proizvodu uz potrebne korekcije, a isto tako i da paralelno obrauje viae varijanti prije odabira kona ne. Pri tome model procesa konstruiranja treba sadr~avati podraku planiranju i kontroli tijeka izvoenja procesa. O ekuje se da se objektnim tehnologijama mo~e realizirati implementacija tzv. "dinami kog planiranja". Realizacija zapisa mre~ne topologije procesa konstruiranja trebala bi ra unalni model viae pribli~iti realnosti. Zna ajne mogunosti unapreenja procesa konstruiranja mogu se ostvariti u uvjetima timskog rada na jednoj konstrukciji (ato je danas vjerojatno prevladavajua situacija). Ra unalni model procesa konstruiranja treba omoguiti i unapreenje organizacije procesa i ubrzati komunikaciju izmeu lanova tima. Takoer je va~no koncipirati i entitete koji modeliraju procese "istovremenog in~enjerstva" (concurrent engineering). Osnovna struktura objektnog modela trebala bi u daljnjim istra~ivanjima poslu~iti kao skup prijedloga i polaznih to aka, te poticaj za aire usaglaaavanje koncepcije i definicija entiteta ra unalnog modela procesa konstruiranja, koji bi te~io k standardizaciji. Na takvoj platformi mogli bi se u slijedeim fazama istra~ivanja efikasnije nadograivati slo~eni programski alati koji e sustav viae pribli~iti ideji  inteligentnog , odnosno zamisli "modela radne okoline", tj. "radnog stola" ("designer's workbench-a"). Polaziata Kako je Znanost o konstruiranju multidisciplinarna, kao polaziata za istra~ivanja definirana zadatkom ovog rada potrebno je prije svega izvraiti kompilaciju literature iz nekoliko podru ja. Problem definiran zadatkom rada obuhvaa podru je Znanosti o konstruiranju, te odreena podru ja ra unalskih znanosti, umjetne inteligencije i teorije grafova. Kao dio znanosti o konstruiranju nedostaje dobro utemeljena i detaljno razraena teorija CAD-a koja bi trebala biti "agregat" prije navedenih znanosti, ime bi postala polaziate za daljnji razvoj CAD sustava. Ova disertacija dio je ukupnih istra~ivanja na projektu razvoja modela CAD sustava ije karakteristike se trebaju pribli~iti ideji  inteligentnog CAD sustava. Rad se jednim dijelom nastavlja na istra~ivanja prikazana u  REF _Ref409244619 \r \h [6] i  REF _Ref409257371 \r \h [7]. U nedostatku boljeg ili prikladnijeg termina za karakterizaciju CAD ili CAE sustava koji bi sadr~avao okru~enje za modeliranje procesa konstruiranja, koristiti e se pridjev  inteligentni . U literaturi se taj pridjev esto koristi  REF _Ref409246831 \r \h [8],  REF _Ref409246833 \r \h [9], ali inteligentni sustav prije je cilj (limes) kojem treba te~iti nego prakti no ostvariva mogunost. U novijoj literaturi koristi se i naziv "designer's workbench"  REF _Ref409247530 \r \h  \* MERGEFORMAT [10],  REF _Ref409247532 \r \h  \* MERGEFORMAT [11]. Detaljniji pregled literature dan je u drugom poglavlju. Treba naglasiti da do sada (za airu prakti nu primjenu) nije razvijen CAD sustav ope namjene s implementiranim modelom procesa konstruiranja. U znanosti o konstruiranju ne postoji detaljno razraena i usaglaaena metoda prikaza i zapisa tijeka odvijanja konstrukcijskog procesa. Takvo stanje ne treba iznenaditi jer do sada je razvijeno (za razli ite domene i namjene) nekoliko desetaka metoda prikaza procesa, i tek se odnedavno pokuaava krenuti prema standardizaciji u tom podru ju  REF _Ref409142339 \r \h [12]. Da bi se moglo prii kona noj sintezi modela procesa konstruiranja potrebno je provesti po etne analize i istra~ivanja u viae razli itih podru ja. Pri tome se mogu razlu iti sljedee polaziane to ke: analiza procesa konstruiranja, na ina razmialjanja i organizacije rada konstruktora postojei opi modeli procesa konstruiranja i ope teorije konstruiranja analiza postojeih informacijskih modela i njihove primjene u konstruiranju analiza strukture in~enjerskih podataka i dokumenata (kao nosilaca informacija) openite metode prikaza procesa, teorija grafova metode planiranja u umjetnoj inteligenciji opi principi i mehanizmi modeliranja principi objektno orijentirane metodologije modeliranja i razvoja programskih sustava Metodologija istra~ivanja U uvodnom dijelu rada analizirati e se zna ajke procesa konstruiranja i biti e sagledano sadaanje stanje istra~ivanja u teoretskom kao i u ra unalnom modeliranju procesa konstruiranja. Iz razmatranja zna ajki procesa konstruiranja trebaju proizai zahtjevi na koncepciju modela procesa konstruiranja, ali i ograni enja - ne mo~e se o ekivati da je mogue u potpunosti modelirati proces konstruiranja (ne postoji usaglaaen model niti u Znanosti o konstruiranju). Glavni dio istra~ivanja sa injavati e slijedea razmatranja: promatranje modela procesa konstruiranja kao integriranog dijela cjelokupne informati ke podrake razvoju proizvoda, a pri tome se konstruiranje tretira kao proces obrade i generiranja informacija apstrahiranje (teoretsko izlu ivanje) svih pojava, stvari, dogaaja, informacija kao entiteta procesa konstruiranja preslikavanje entiteta u objekte, definiranje atributa, operacija i relacija objekata Analizirati e se metode i principi objektnog modeliranja, na temelju kojih e se predlo~iti koncepcija osnovne strukture sustava. Pri definiranju entiteta modela, odnosno objekata krenuti e se od najjednostavnijih, koji e poslu~iti kao gradbeni elementi za slo~ene (kompozitne) objekte koji e modelirati kompleksne pojmove i relacije. Dakle osnovna metoda gradnje sustava biti e  bottom-up , dok e se po potrebi kombinirati i  top-down i  bottom-up pristup. Principi gradnje sustava biti e voeni idejom  otvorene kutije s alatima (open toolbox). Koriatenjem kombinacija i agregacija osnovnih entiteta, predlo~iti e se na ini implementacije u model nekih od metoda prikaza i reorganizacije procesa konstruiranja. Zaklju na razmatranja usporediti e razraeni model sa drugim poznatim modelima, te analizirati mogunosti primjene i predlo~iti pravce daljnjih istra~ivanja. Sa stanoviata modeliranja, metodologija istra~ivanja mo~e se prikazati kao niz preslikavanja prema slici 1 (autori Andreasen i Duffy  REF _Ref409258193 \r \h [13]).  INCLUDEPICTURE "linkane slike\\andreasen duffy preslikavanje.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 1: Preslikavanja od realnosti do ra unalnog modela Realnost se modelira teorijama znanosti o konstruiranju, temeljem kojih se preslikava u fenomenoloake modele. Informacijski modeli temelje se na informacijskim teorijama, npr. "entity - relationship" modeliranju ili objektno orijentiranom modeliranju. Ra unalni model temelji se na programskom jeziku, odn. odabranom programskom okru~enju realizacije. Preslikavanja s lijeva u desno prikazuju proces istra~ivanja u kojem se fenomenoloaki model postepeno formalizira sredstvima informacijskih i ra unalnih modela. Putanja s desna u lijevo ozna ava proces verifikacije u kojem se model usporeuje s realnosti. Pregled stanja i smjerova istra~ivanja Iako je Znanost o konstruiranju relativno mlada disciplina, detaljniji pregled i klasifikacija svih smjerova istra~ivanja, zahtjevna je i vrlo opairna zadaa koja bi odvela previae u airinu. Stoga e biti istaknute samo one teme i smjerovi koji su relevantni za temu rada. Veliki zna aj konstruiranja za profitabilnost proizvodnje dovodi do stalnog rasta interesa za ovu disciplinu, tako da danas ve postoje i multidisciplinarni timovi istra~iva a. Dosadaanji tijek razvoja Znanosti o konstruiranju karakterizira: velik broj razvijenih parcijalnih modela i teorija, neusklaenost metodologije, nekoliko razli itih "akola konstruiranja" (Njema ka i Engleska, USA, Japan), posljednjih desetak godina vrlo brz razvoj ra unalnih tehnologija bitno uti e i na razvoj i otvaranje novih smjerova istra~ivanja. ini se kao da razvoj komercijalnih CAD i CAE sustava ne ide paralelno sa razvojem Znanosti o konstruiranju, odnosno do implementacije novih metoda i spoznaja u komercijalne CAD sustave ili ne dolazi ili ona prili no kasni. Nekoliko je moguih razloga za takvo stanje: tvrtke koje proizvode vrhunske CAD sustave nastoje da im podru je primjene bude ato aire, a novorazvijene metode esto su samo parcijalni modeli za u~e domene primjena novih spoznaja i metoda iz Znanosti o konstruiranju i ina e se teako prihvaa u praksi  REF _Ref409151822 \r \h  \* MERGEFORMAT [14],  REF _Ref409151825 \r \h  \* MERGEFORMAT [15] nove metode trebaju proi vrijeme "dokazivanja" i prilagodbe konstruktora koji su navikli na ustaljeni na in rada i pru~aju otpor promjenama Pregled stanja istra~ivanja stoga je u nastavku (sa glediata procesa konstruiranja) podijeljen na dva dijela - "teoretski" - Znanost o konstruiranju i "prakti ni" - razvoj CAD i CAE sustava. Dakako, razvoj CAD sustava temelji se na zna ajnim znanstvenim doprinosima iz podru ja geometrijskog modeliranja, ali najvei nedostatak je upravo to da se radi najveim dijelom samo o geometrijskom modeliranju. Stanje i smjerovi istra~ivanja u Znanosti o konstruiranju Mo~e se rei da u podru ju znanosti o konstruiranju ne postoje zajedni ki usaglaaeni stavovi meu istra~iva ima o prikladnim metodologijama i prioritetnim smjerovima istra~ivanja. Takvo stanje uzrokuje odreenu kaoti nost, ali je i poticajno za daljnja istra~ivanja. Takoer se mo~e uo iti da nedostaje jedinstvena teorija CAD-a - ne postoji potpuna reprezentacija proizvoda, niti usaglaaen model procesa konstruiranja proizvoda. Jedan od moguih razloga za takvo stanje je u injenici da je znanost o konstruiranju relativno mlada znanstvena disciplina. S druge strane mora se napomenuti da je proces konstruiranja izuzetno kompleksan proces, te je stoga neke njegove zna ajke teako razumjeti do te mjere da bi se mogle teoretski formalizirati. Nekoliko autora nastojalo je sistematizirati dostignua i dati pregled trenutnog stanja. Kao zna ajnije ovdje e se izdvojiti Hubku i Edera (1996)  REF _Ref409151916 \r \h [16], te Finger i Dixona (1989)  REF _Ref409149372 \r \h [17],  REF _Ref409149374 \r \h [18]. Koliko je poznato autoru ovog rada, noviji pregledi stanja takvih opsega i takve razine detalja klasifikacije nisu napravljeni. Noviji pristupi sistematizaciji i vizije razvoja u budunosti mogu se nai u  REF _Ref409152505 \r \h [19] i  REF _Ref409152507 \r \h [20]. VDI 2221  REF _Ref409233023 \r \h [21] daje detaljan pregled i klasifikaciju metoda konstruiranja, uz naznake njihove uporabe u pojedinim fazama procesa konstruiranja. Hubka i Eder  REF _Ref409151916 \r \h [16] daju detaljnu sistematizaciju Znanosti o konstruiranju, i to sa viae razli itih aspekata. Takoer daju i kronoloaki prikaz razvoja Znanosti o konstruiranju. Ovdje emo izdvojiti dio njihovih razmatranja o trenutnom stanju znanja o konstruiranju. Velika koli ina znanja je akumulirana, ali veinom kao "otoci znanja", jer nije bilo dovoljno sinteza. Raspolo~ivo znanje unutar znanja o konstruiranju nije jednoliko (uravnote~eno) pripremljeno, odnosno pojedina podru ja nisu jednakovrijedno tretirana. Pri razvoju metodologije konstruiranja neki problemi su se iskristalizirali ili u parcijalne zadatke ili u principe metodologije, npr.: zadatak razvoja jasnog prikaza postupaka konstruiranja zadatak najfinijeg mogueg strukturiranja procesa, sa jasnom separacijom individualnih aktivnosti, poglavito onih sa posebnim zna ajkama (npr. tra~enje rjeaenja problema) princip razrade ato je mogue viae alternativa i njihove optimizacije u ranim fazama procesa konstruiranja zadatak prilagodbe opih postupaka razli itim situacijama: za timski rad za primjenu ra unala Kvaliteta znanja nije jednolika i varira od iskustvenog znanja do preciznih izreka Put prema in~enjerskoj praksi, odnosno airoj primjeni joa nije pronaen. Dok su Hubka i Eder orijentirani na vrlo airoku i detaljnu sistematizaciju i organizaciju Znanosti o konstruiranju, Finger i Dixon daju samo pregled stanja i klasifikaciju pravaca istra~ivanja u radovima  REF _Ref409149372 \r \h [17] i  REF _Ref409149374 \r \h [18]. Prema  REF _Ref409149372 \r \h [17], podru ja istra~ivanja u znanosti o konstruiranju mogu se sistematizirati na slijedei na in (slika 2): Deskriptivni modeli procesa konstruiranja Preskriptivni modeli procesa konstruiranja Ra unalni modeli procesa konstruiranja Jezici, prikazi i okru~enja za podraku konstruiranju Analiti ke metode kao podraka donoaenju odluka Konstruiranje temeljem zahtjeva iz ~ivotnog vijeka proizvoda Navedene kategorije nisu meusobno isklju ive, odnosno neka istra~ivanja mogu obuhvaati dva ili viae podru ja.  INCLUDEPICTURE "linkane slike\\taksonomija istrazivanja.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 2: Taksonomija podru ja istra~ivanja u znanosti o konstruiranju, prema  REF _Ref409149372 \r \h [17] Tema ovog rada obuhvaa istra~ivanja iz podru ja navedenih pod r. br. 1, 3 i 4 pa emo izdvojiti neke od otvorenih tema istra~ivanja u tim podru jima prema  REF _Ref409149374 \r \h [18]. Premda je prikaz dan 1989. godine, veina tema aktualna je i danas. Deskriptivni modeli: Potrebno je dalje razvijati spoznajne (kognitivne) modele strategija konstruiranja da bi se bolje razumjelo kako konstruktori rade Joa uvijek se premalo zna o dekompoziciji zadataka koji se rjeaavaju timskim radom, makar je to situacija pri konstruiranju veine proizvoda. Ra unalni modeli procesa konstruiranja: Modeli i metode parametarskog konstruiranja su visoko zavisni o podru ju. Potrebno je istra~iti mogunosti unifikacije parametara konstrukcije, ato uklju uje i numeri ke i nenumeri ke podatke. Istra~ivanje mogunosti promjene konfiguracija sklopova bez redefiniranja po etnih projektnih parametriziranih informacija Definiranje funkcija strategijskih alata za rjeaavanje distribuirane problemske eksplozije pri razvoju ekspertnih sustava za podraku konstruiranju. Uloga fizikalnih principa u povezivanju forme i funkcije joa nije u potpunosti razmotrena (shvaena). Jezici, prikazi i okru~enja za podraku konstruiranju: Podru je istra~ivanja zajedni ko za sve konstrukcijske probleme je prikaz mehani ke konstrukcije. Neke od tema istra~ivanja su : prikaz nedovraene konstrukcije prikaz procesa razvoja konstrukcije (uklju ivai kontrolu konfiguracije i kontrolu razli itih verzija) prikaz atributa konstrukcije koji nisu geometrijske prirode veze i zavisnosti izmeu prikaza razli itih atributa konstrukcije implementacija svojstava i drugih apstraktnih pojmova u prikaz konstrukcije Potrebno je istra~iti mogunosti primjene formalnih gramatika i jezika za prikaz konstrukcije. Va~no podru je kojem nije posveeno dosta pa~nje je kreiranje okru~enja za konstruiranje (design environments) koje integrira raspolo~ive programske alate u konzistentan sistem za podraku konstruktoru. Analiti ke metode za podraku donoaenju odluka: Kreirati CAD sustave koji podr~avaju faze koncipiranja omoguujui konstruktoru da kreira, modificira i analizira na viaestrukim razinama apstrakcije i sa razli itih glediata. Situacija u razvoju CAD i CAE sustava Nagli razvoj ra unalne opreme omoguio je i razvoj vrlo zahtjevnih i kompleksnih programskih paketa. CAE (Computer Aided Engineering) jedno je od podru ja primjene ra unala s vrlo velikim zahtjevima na sve resurse i performanse ra unala. Integracija CAD, CAM (i ostalih popularnih kratica koje po inju sa  CA ) u cjelovit i efikasan CIM sustav izuzetno je kompleksan proces i na teoretskom nivou, dok implementacija u praksi otvara joa i niz novih problema. Modeliranje strukture i problemi prakti ne realizacije takovog integriranog sustava i/ili njegovih podsustava tema je velikog dijela danaanjih istra~ivanja u podru ju primjene ra unala u cjelokupnom procesu proizvodnje. Pri tome postoji vrlo velik broj razli itih pristupa u kojima se veinom zbog opse~nosti problema interes su~ava na odreen podsustav onoga ato ini  ideju CIM sustava. Osnovna svrha svih tih istra~ivanja je daljnje poveanje produktivnosti u svim aktivnostima koje prate proces proizvodnje. Proces konstruiranja ima najvei utjecaj na troakove i rokove u procesu proizvodnje,  REF _Ref409261642 \r \h  \* MERGEFORMAT [22],  REF _Ref409152939 \r \h  \* MERGEFORMAT [23], dakle i na kompletno poslovanje i profit pa je razumljivo da je veina istra~ivanja posveena upravo podru ju CAD-a. Vrlo esto upravo je konstrukcijski ured  usko grlo u procesu proizvodnje. Na tr~iatu danas postoji velik broj CAx programskih paketa s velikim rasponom ponude mogunosti i cijena. Veina tih paketa je ope namjene, a postoje i specijalizirani za npr. domene elektronike, strojarstva ili arhitekture. Najvei broj komercijalnih programskih sustava mo~e se svrstati u CAD sustave (2D ili 3D). Takoer se na tr~iatu nudi i velik broj CAM paketa, kao i paketa za numeri ke analize konstrukcija (naj eae metoda kona nih elemenata - FEM). Samo najskuplji programski sustavi nekoliko vodeih proizvoa a sadr~e CAD, CAM, FEM, EDM/PDM i ostale komponente potrebne u in~enjerskom radu. Meutim i tada su to joa uvijek samo zasebne programske cjeline, a nema modela procesa konstruiranja u kojem bi se integrirale te zasebne funkcije. Koriatenje takvog skupa programskih paketa ne podr~ava u cjelini proces konstruiranja, a za ovladavanje svim segmentima sustava potrebno je utroaiti dosta rada i vremena. Gotovo se mo~e rei da se jedna osoba nije u stanju jednako kvalitetno (produktivno) koristiti svim elementima sustava, nego i tu dolazi do specijalizacije. Dodatne mogunosti unapreenja produktivnosti pru~aju tzv.  makro jezici kojima se mo~e automatizirati i povezati niz radnji u koriatenju sustava, ali to ne mo~e kvalitativno doprinijeti rjeaavanju osnovnih nedostataka postojeih CAD sustava u koje mo~emo ubrojiti: manipuliranje prete~no samo geometrijskim (numeri kim) informacijama nedostatak modela procesa konstruiranja, odnosno podrake prirodnom toku promialjanja nedostaju programski alati i su elja za povezivanje pojedinih elemenata sustava vrlo je teako realizirati paralelno koriatenje CAD sustava i drugih vrsta aplikacija, npr. aktiviranjem viae procesa istovremeno - nedostaju su elja, modeli na ina povezivanja i prijenosa podataka te kontrole redoslijeda izvoenja Zna ajan dio istra~ivanja mogunosti unapreenja CAD (CAE sustava) temelji se na ideji da se primjenom metoda umjetne inteligencije omogui modeliranje podrake prirodnom toku promialjanja i postupaka obrade informacija u tijeku procesa konstruiranja. To uklju uje modeliranje prikaza tijeka procesa konstruiranja na na in koji omoguuje obradu i numeri kih i simboli kih informacija na razli itim razinama apstrakcije. Cilj je istra~ivanja takav model ato viae pribli~iti zna ajkama procesa konstruiranja. S informacijskog stanoviata mo~emo proces konstruiranja promatrati i kao iterativni proces izmeu obrade podataka i donoaenja odluka. Dobar dio razli itih procesa obrade informacija nije mogue ili nije pogodno podr~ati CAD sustavom ope namjene - npr. baza podataka sa stanjem skladiata ili npr. programi za numeri ke prora une parametara dijelova ili sklopova. Za takve svrhe uglavnom treba razvijati aplikacije ija je domena usko vezana uz specifi ne zahtjeve okru~enja u kojima se koriste. Podraka donoaenju odluka mo~e se realizirati implementiranjem metoda umjetne inteligencije. Po etke razvoja umjetne inteligencije karakterizira veliki entuzijazam i o ekivanja. Vremenom se doalo do spoznaja da razvijene metode imaju ograni enja i da efikasno funkcioniraju kod primjene na dobro definirane probleme unutar uske domene. Po sadaanjim spoznajama ne mo~e se o ekivati da je mogue razviti ekspertni sustav koji bi bio u stanju  sam konstruirati, niti da je mogue formalizirati sveukupno znanje struke i postupke koje konstruktor koristi u radu. Primjena ekspertnih sustava, odnosno metoda umjetne inteligencije u CAD sustavima mo~e rijeaiti neke njihove nedostatke - prvenstveno nedostatak obrade simboli kih i topoloakih informacija. U obliku baze znanja mogu se pohraniti skupovi pravila i postupaka koji vrijede za odreenu proizvodnu okolinu, odnosno vrstu proizvoda. Meutim primjena metoda umjetne inteligencije ne rjeaava nedostatak modela procesa konstruiranja, odnosno nedostatak programske podrake za prikaz, planiranje i kontrolu tijeka odvijanja procesa konstruiranja. Istra~ivanja unapreenja CAD i CAE sustava Istra~ivanja u podru ju znanosti o in~enjerskom konstruiranju dala su skup apstraktnih i openitih teorija sa svrhom organiziranja procesa i poveavanja efikasnosti. Jedan dio tih napora usmjeren je na prou avanje na ina prikaza procesa konstruiranja, a mogu se grubo svrstati u dvije kategorije: istra~ivanja opih i apstraktnih prikaza procesa konstruiranja, uglavnom temeljena na tehnikama scenarija istra~ivanja modela procesa konstruiranja za odreene klase konstrukcijskih zadataka, temeljena na grafi kim prikazima Tipi an proces razvoja proizvoda realizira se u malim koracima doraivanja postojeih proizvoda za razliku od razvoja potpuno novih  REF _Ref409263740 \r \h [24]. Informacije (podaci) o proizvodu koji se konstruira spremaju se u baze podataka. Spremljeni skupovi podataka su prete~no geometrijski i strukturalni, te podaci o materijalu i tehnologiji izrade. Veinom se ne spremaju informacije o tome kako i zaato se doalo do odreenog rjeaenja. Taj vrlo va~an segment znanja u procesu konstruiranja ostaje skriven i nezapisan, dakle bez mogunosti ponovnog koriatenja i nije na raspolaganju svima u konstrukcijskom uredu. To su znanja o procesu konstruiranja i proizvodnje specifi na za radnu okolinu u kojoj se proces odvija. Takva znanja esto su i specifi na za pojedinu osobu (konstruktora) - npr. individualne metode rada i ste eno iskustvo. Rezultati istra~ivanja, kao i iskustva iz industrije naglaaavaju potrebu integracije informacijskih tokova u procesu proizvodnje, iji je dio proces konstruiranja. Poduzea koja su krenula tim smjerom, znatno su unaprijedila produktivnost i smanjila troakove. Ako promatramo informacijske tokove cijelog procesa proizvodnje, sigurno je da je proces konstruiranja najkompleksniji njegov dio. U procesu konstruiranja obrauje se i stvara najvei dio informacija o proizvodu, i to s najveim udjelom heuristike. Ve je prije napomenuto i da proces konstruiranja ima najvei utjecaj na troakove proizvodnje. Sve nabrojene injenice poticaj su velikog broja istra~ivanja procesa konstruiranja, pogotovo metoda i modela ra unalom podr~anog konstruiranja. Jedan dio istra~ivanja u podru ju CAD-a, bavi se integracijom CAD alata i implementacijom CAD alata u sve faze procesa konstruiranja. Razvijen je zna ajan broj razli itih pristupa i pravaca istra~ivanja. Za ilustraciju sadaanjih trendova istra~ivanja dan je kratak pregled zna ajnijih radova, uz grubu klasifikaciju. Teoretske podloge za "inteligentne CAD sustave": Akman, Hagen i Tomiyama  REF _Ref409263479 \r \h [25] predlo~ili su "jezik za opis konstruiranja" sagraen na principima logi kog i objektno orijentiranog programiranja. Jezik se temelji na opoj teoriji konstruiranja po Yoshikawi, mo~da najboljoj do sada prezentiranoj teoriji konstruiranja. Chandrasekaran  REF _Ref409263517 \r \h [26] je razvio strukturu zadataka u procesu rjeaavanja konstrukcijskih problema, prou avajui razli ite metode i znanje i klasificirajui podzadatke neovisno o pridru~enom znanju. Colton i Dascanio  REF _Ref409263538 \r \h [27] koncipirali su i implementirali integriranu, "inteligentnu" okolinu koja daje konstruktoru mogunost izbora iz kataloga i konstruiranja uobi ajenih dijelova. Veina takvih istra~iva kih projekata bavi se "prijateljskim" korisni kim su eljima, integriranim sa modulima za kontrolu informacija. Ekspertni sustavi razvijeni za te svrhe, obi no su efikasni samo u ograni enim domenama. Neki od pristupi u podru ju modeliranja modela podataka proizvoda ("product data models"): semantika modela  REF _Ref409265645 \r \h [28], integracija viae ra unalnih procesa  REF _Ref409265701 \r \h [29], minimizacija troakova razvoja proizvoda  REF _Ref409135683 \r \h [30], procesiranje baza podataka  REF _Ref409265763 \r \h [31]. injenica da konvencionalni CAD sustavi nisu koncipirani da bi asistirali konstruktoru u rjeaavanju kompleksnih problema poti e istra~ivanja integriranih programskih okolina  REF _Ref409266006 \r \h [32]. Gauseimer i Vajna bave se aspektima kvalitete i efikasnosti razvoja proizvoda  REF _Ref409266015 \r \h [33],  REF _Ref409135683 \r \h [30]. Modeli "radnih okolina" ("designers workbench") razvijaju se sa viae razli itih pristupa, i tu tek predstoji usaglaaavanje ciljeva i metoda  REF _Ref409266591 \r \h [34],  REF _Ref409266596 \r \h [35]. Razvoj modela konstruiranja temeljen na paradigmi umjetne inteligencije dao je sna~an poticaj istra~ivanjima  REF _Ref409266601 \r \h [36]. Blount i Clarke tretiraju konstruiranje kao aktivnost rjeaavanja problema koja se mo~e automatizirati  REF _Ref409266607 \r \h [37]. Mostow  REF _Ref409266609 \r \h [38] istra~uje tehniku "kompilacije znanja" kao transformaciju eksplicitno prikazanog znanja iz domene u efikasni algoritam za izvoenje odreenih zadataka u domeni. Uloge ekspertnih sustava i sustava za upravljanje bazama podataka u okolini "konstruiranja za izradu" razmotrene su u radu  REF _Ref409266612 \r \h [39]. Metode rjeaavanja problema analogijom, primjenjene na in~enjersko konstruiranje, esto se upotrebljavaju u razvoju "inteligentnih agenata"  REF _Ref409269148 \r \h  \* MERGEFORMAT [40]. Istra~ivanja koja kombiniraju umjetnu inteligenciju i metode optimizacije pokazala su zna ajan utjecaj na formalizaciju i rjeaenja ra unalnih metoda u in~enjerskom konstruiranju  REF _Ref409269154 \r \h  \* MERGEFORMAT [41]. Istra~ivanja primjene ekspertnih sustava sugeriraju da standardni pristupi nisu pogodni za konstruiranje i planiranje. Stoga u ovom podru ju treba razviti nove pristupe  REF _Ref409269156 \r \h  \* MERGEFORMAT [42]. Ullman i D'Ambrosio predlo~ili su taksonomiju ra unalne podrake konstruiranju  REF _Ref409269158 \r \h  \* MERGEFORMAT [43]. Openitiji pristupi bave se razvojem "okvira" znanja (knowledge frameworks). Forde i koautori uvode strategiju koncipiranja objektno orijentiranog "okvira"  REF _Ref409269161 \r \h  \* MERGEFORMAT [44]. Smithers  REF _Ref409269853 \r \h [45] predla~e teoriju konstruiranja u obliku "razina znanja". Svoju teoriju upotrebljava kao prakti nu alternativu spoznajnoj teoriji konstruiranja. Ra unalni modeli ovisni o domeni, dovedeni su gotovo do savraenstva u su~enim prostorima interesa. Takvi slu ajevi upravo naglaaavaju razliku izmeu modeliranja procesa konstruiranja  REF _Ref409269858 \r \h [46] i modeliranja odreenog zadatka. Razmatrajui konstruiranje kao proces, ta istra~ivanja usredoto uju se na pronala~enje odgovarajue metode za rjeaavanje problema. Ra unalni modeli zadataka konstruiranja openito su specifi ni za dobro definiranu klasu problema kao u  REF _Ref409269862 \r \h [47],  REF _Ref409269865 \r \h [48] i u mnogim drugim radovima. Openitiji pristupi modeliranju procesa konstruiranja pokuaaji su koji podr~avaju izvoenje i ozna avanje alternativnih koncepata upotrebljavajui negeometrijske entitete za podraku kompleksnim konstrukcijskim projektima. Spremljeni koncepti omoguuju implicitno zapisivanje konstrukcijskog znanja (design rationale)  REF _Ref409269868 \r \h [49],  REF _Ref409269871 \r \h [50]. Raste interes za modele procesa konstruiranja zasnovane na teoriji grafova. Eppinger modelira iteraciju u procesu konstruiranja pomou grafova toka signala  REF _Ref409270389 \r \h [51]. Schmidt  REF _Ref409270391 \r \h [52] upotrebljava algoritme temeljene na gramatici grafova pri generiranju rjeaenja blizu optimalnih. Zadnja dva spomenuta modela mogu se kategorizirati i kao optimizacijski modeli. Planiranje i tehnike scenarija  REF _Ref409270393 \r \h [53] predstavljaju daljnje iskoritenje paradigme umjetne inteligencije. Planovi konstruiranja i potreba za automatiziranim sustavima objanjavanja, kao i njihova interakcija s konstruktorom, predmet su kontinuiranih istra~ivanja  REF _Ref409270395 \r \h [54]. Pristupi koji se bave planiranjem procesa konstruiranja proizvoda relativno su rijetki u odnosu na istra~ivanja u koncipiranju procesa planiranja proizvodnje. Weber i Werner predla~u pregled i sistematizaciju podru ja istra~ivanja primjene ra unala u konstruiranju prema shemi na slici 3.  INCLUDEPICTURE "linkane slike\\RESEARCH AREAS.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 3: Podru ja istra~ivanja primjene ra unala u znanosti o konstruiranju prema  REF _Ref409183564 \r \h [55] Istra~ivanja u ovom radu usmjerena su modeliranje upravljanja procesom i na unapreenje organizacije toka i razmjene informacija u procesu konstruiranja. Pri tome e se koristiti spoznaje i metodologije teorije konstruiranja. Analiza procesa konstruiranja Prije svega trebamo biti svjesni da se modeliranjem ra unalne podrake planiranju i izvoenju konstrukcijskog procesa mo~e ostvariti samo pribli~an model realnog procesa konstruiranja. Svrha ove analize je iznala~enje smjernica za koncipiranje modela, te odreivanje mogunosti i na ina pribli~enja zna ajkama realnog procesa. Kako je ve navedeno, pribli~enje ra unalnog modela realnosti, ovisi prije svega o spoznajama i razumijevanju procesa konstruiranja, a zatim i o mogunostima i metodologiji primjene danaanjih informati kih tehnologija. Kao prvi korak analize, i najviae, razumijevanja procesa konstruiranja potrebno je razmotriti zna ajke procesa konstruiranja. Konstruktor u tijeku procesa konstruiranja svoje aktivnosti usmjerava ka cilju - rjeaenju postavljenog zadatka, pa analiza procesa konstruiranja s aspekta rjeaavanja zadatka daje smjernice za modeliranje prikaza tijeka procesa konstruiranja. Zna ajke procesa konstruiranja Kao jedno od polaziata za razmatranje, navesti e se zna ajke procesa konstruiranja i konstruktorskog rada prema  REF _Ref409261642 \r \h [22]. Konstrukcijski proces je u prvom redu proces prerade i generiranja informacija, gdje se na temelju ulaznih zahtjeva generira skup informacija koje opisuju proizvod. Konstrukcijski proces je sinteza relativno dobro poznatih elemenata u jednu jedinstvenu, otprije nepoznatu cjelinu sa zahtjevanim odreenim svojstvima. Ta sinteza iziskuje kreativan, stvarala ki rad. Iz toga proizlazi va~na zna ajka procesa konstruiranja - ovjek mora kontrolirati proces, odnosno imati prete~an udio u obavljanju potrebnih radnji. S filozofskog glediata proces konstruiranja je takoer i spoznajni proces: sustav na po etku nepoznat - spoznaje se, odnosno postaje poznat. Na temelju toga mo~e se rei da je spoznajna teorija takoer jedan izvor opih zakonitosti za proces konstruiranja. Konstruiranje se mo~e promatrati i kao proces u enja. Svaki konstrukcijski zadatak mo~e se rijeaiti na mnogo razli itih na ina, odnosno mo~e rezultirati sa razli itim strojnim sustavima ili sklopovima. Ta karakteristi na mnogostrukost moguih rjeaenja uvjetovana je koli inom svojstava proizvoda koje se trebaju odrediti u postupku konstruiranja. Svaki proces konstruiranja mo~e se razlo~iti u manje cjeline (faze, dijelove procesa, etape, operacije) koje ine strukturu procesa. Velika kompleksnost meusobno proturje nih zahtjeva dovodi do potrebe za viaestrukim ponavljanjem odreenih faza nakon po etnog apstrahiranja i postavljanja pretpostavki - dok se ne odrede potrebne vrijednosti. Iterativni postupak je jedna od tipi nih zna ajki konstruiranja. Do sada prete~no samostalna djelatnost (u okviru zadatka), sve viae se pretvara u timski rad u kojem se koriste prednosti veeg informacijskog kapaciteta i meusobne razmjene ideja i postupaka. Proces konstruiranja je vrlo zahtjevan kreativni rad, ali ne smije se promatrati kao umjetnost, nego kao znanstveni rad. Odreeni misaoni postupci (intuicija, nastajanje ideje) koji se ne mogu racionalno objasniti imaju obilje~ja umjetni ke kreativnosti. Ti postupci ne mogu se formalizirati u svrhu stvaranja cjelovitog teoretskog prikaza konstrukcijskog procesa. Sa stanoviata teorije proizvoda,  REF _Ref409171901 \r \h [56] mogu se navesti slijedee zna ajke procesa konstruiranja: nagli porast potreba uvjetovan tr~ianim zakonitostima period razvoja proizvoda je sve krai vijek trajanja proizvoda je sve krai javlja se pojam kriti ne brzine konstruiranja raste koli ina proizvoda u serijskoj i masovnoj proizvodnji zahtjevi za kvalitetom takoer rastu troakovi proizvodnje i poslovanja se moraju svoditi na minimum najvei utjecaj na strukturu troakova proizvodnje ima konstrukcijsko rjeaenje proizvoda produktivnost tehnologije izrade proizvoda raste daleko br~e od produktivnosti konstruiranja Iz navedenih zna ajki mo~e se uo iti mnogostrukost upliva na proces konstruiranja, kompleksnost procesa, a i airina potrebnih znanja. Detaljnija razmatranja upliva okoliaa na proizvodni sustav s implikacijama na CIM, odnosno na proces konstruiranja i CAD mogu se nai u  REF _Ref409171903 \r \h  \* MERGEFORMAT [57]. Kompleksnost procesa konstruiranja i mnogostrukost upliva okoline ine zadatak modeliranja procesa konstruiranja vrlo zahtjevnim. To se o ituje i u velikom broju razli itih stavova o konstruiranju i u nizu razli itih pristupa modeliranju procesa konstruiranja. Konstruiranje kao rjeaavanje zadatka Drugi dio zahtjeva na koncepciju ra unalnog modela procesa konstruiranja trebalo bi definirati analiziranje i razvrstavanje postupaka koje konstruktor koristi u tijeku rjeaavanja konstrukcijskog zadatka. Prema  REF _Ref409261642 \r \h  \* MERGEFORMAT [22] zadatak procesa konstruiranja je pretvorba postavljenih zahtjeva u opis ~eljenog strojnog sustava. Drugim rije ima potrebno je definirati i opisati strojni sustav (proizvod) koji e proizvoditi ~eljene u inke i pri tome ispunjavati zahtjevana svojstva. Osim postavljenih zahtjeva potrebno je voditi ra una i o ostalim aspektima tehni ke i ekonomske naravi - npr. tehnologi nost, troakovi, itd. - ato vrijedi i za sam proizvod, i za njegovo funkcioniranje u ~ivotnom vijeku. Kao okosnicu ovog poglavlja (ujedno i cijelog rada) trebalo bi razmotriti slijedei niz principjelnih pitanja : Kako konstruktor rjeaava zadatak, kako razmialja, koje postupke koristi, kako organizira proces, kako se u i konstruirati ? Razmatrajui kako pristupiti obrazovanju konstruktora, Ullman  REF _Ref409152939 \r \h  \* MERGEFORMAT [23] dolazi do zaklju ka da ne postoji univerzalni  recept rjeaavanja konstrukcijskog zadatka (i/ili problema). U uvodnim razmatranjima navodi slijedee: Jedini na in da se nau i konstruiranje - je konstruirati. U tijeku rjeaavanja zadatka konstruktor upotrebljava tri vrste znanja: znanje za generiranje ideja znanje za procjenu, prosuivanje ideja znanje za strukturiranje procesa konstruiranja Sposobnost generiranja ideja dolazi s iskustvom, ali je potreban i talent. Za prosuivanje ideja koristi se iskustveno znanje i znanje ste eno obrazovanjem. Znanje potrebno za generiranje i prosuivanje (razmatranje) ideja ovisno je o domeni konstrukcijskog zadatka, dok je znanje o strukturiranju procesa konstruiranja veinom neovisno o domeni zadatka. Mo~e se nau iti konstruirati kvalitetne proizvode, pod uvjetom da postoje odreene predispozicije, te dovoljno iskustvo za generiranje i prosudbu ideja. Konstruiranje treba u iti paralelno u akademskoj i industrijskoj okolini. Lindemann  REF _Ref409493420 \r \h [58] razmatra model napredovanja kroz proces konstruiranja promatrajui individualne na ine rada razli itih konstruktora. Premda su promatrali rad konstruktora kroz niz godina, joa uvijek nema kompletne slike i jasnog i detaljnog razumijevanja kako konstruktori napreduju kroz proces. Interesantan je Giaopulis-ov  REF _Ref409496503 \r \h [59] prijedlog modela u kojem se promatraju tri razine - strateaka, operativna i rezultati. Konstruktor pri odlu ivanju i planiranju svog procesa zapravo neprekidno "aee" izmeu tih razina (slika 4).  INCLUDEPICTURE "linkane slike\\lindemann.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 4: Model procesa konstruiranja prema  REF _Ref409496503 \r \h [59] Akcije od stratekog prema operativnom planiranju promatraju se kao konkretizacija stratekog planiranja ("top-down" pristup). Akcije od razine rezultata prema operativnom planiranju promatraju se kao spontana analiza meurezultata ("bottom-up" pristup). Analiza rezultata mo~e uzrokovati i modifikacije strateakog planiranja. Konstruktori prelaze sa razine strateakog planiranja na razinu operativnog planiranja u trenutku mijenjanja ~ariata interesa. Na operativnoj razini razmatraju detaljnije i konkretnije planove. Akcije (kao rezultat takvih planova) vode do rezultata, koji mogu aktivirati slijedei operativni plan sa daljnjim rezultatima. Povratak na strateaku razinu pojavljuje se u situacijama vanjskih interakcija ili teakoa na operativnoj razini. Model Giaopulisa  REF _Ref409496503 \r \h [59] opisuje dijelom i promatranja Lindemanna  REF _Ref409493420 \r \h [58] koji razvija "fenomenoloaki model" procesa konstruiranja u kojem promatra prelaze i "skokove" izmeu razli itih akcija, strategija i pogleda u tijeku konstruiranja. Navesti emo neke od primjera takvih alternacija izmeu: apstraktnijih i konkretnijih razina cijelog sustava i detalja oblikovanja forme i prora una sinteze i analize planiranih i oportunisti kih koraka "bottom-up" i "top-down" pristupa poznatog i nepoznatog Prema  REF _Ref409493420 \r \h [58] joa uvijek su nejasni detalji procesa pronala~enja i izbora slijedeeg koraka. Klju na pitanja koje postavlja Lindemann: Koji skupovi va~nih uvjeta e dovesti do koje vrste akcije? Koja od alternativnih strategija i akcija je upotrebljiva i efikasna? Fenomenoloaki model procesa konstruiranja joa nije dovraen, a autor se pita da li ga je uope i mogue kompletirati. Struktura operacija u procesu konstruiranja Svaki konstrukcijski proces mo~e se raa laniti na nekoliko kompleksnih faza, odnosno na operacije i korake. Struktura konstrukcijskog procesa mo~e se prikazati kao niz strukturnih elemenata koji le~e na razli itim hijerarhijskim razinama. Pravila strukturiranja mogu poslu~iti kao polaziata za upravljanje i voenje, kao i planiranje konstrukcijskog procesa. Obzirom na temu i cilj ovog rada, posebno je interesantno razmotriti operacije koje konstruktor provodi u tijeku rjeaavanja zadatka. Prikaz strukture procesa konstruiranja u kojem su raa lanjene operacije i aktivnosti dan je prema  REF _Ref409173935 \r \h  \* MERGEFORMAT [60].  INCLUDEPICTURE "linkane slike\\HUEN5_4new.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 5: Struktura aktivnosti u konstrukcijskom procesu prema  REF _Ref409173935 \r \h [60] Prikaz strukture konstrukcijskog procesa mo~e se promatrati na dva na ina: kao hijerarhija kompleksnosti u aktivnostima konstrukcijskog procesa - gledano po vertikalnoj osi, svi elementi (operacije) iz ni~ih razina sadr~ani su u svakom od elemenata iz viaim razina kao grupe (blokovi) aktivnosti (gledano po horizontalnoj osi) koji se cikli ki ponavljaju do postizanja ciljeva Razmatranjem prikaza strukture operacija namee se ideja o razvoju skupa programskih alata za podraku obavljanju onih operacija (izmeu navedenih) koje se mogu algoritmizirati, a nisu (kao cjelina) podr~ane danaanjim CAD sustavima. Naravno, takovi programski alati trebali bi omoguiti obavljanje operacija na poopenom nivou apstrakcije, tj. neovisno o vrsti proizvoda i konstrukcijskog zadatka, uz mogunost prilagodbe uvjetima okru~enja u kojem se koriste. Razvoju takvih vrlo slo~enih programskih alata treba prethoditi razvoj integrirane programske okoline za modeliranje planiranja, praenja i kontrole tijeka odvijanja akcija, odnosno skupa procedura koje obavljaju operacije. Pri tome se mo~e pretpostaviti da se poopeni ra unalni model odreene operacije mo~e sastojati od niza programskih procedura - odnosno da se mo~e graditi od elemenata sustava za podraku planiranju konstrukcijskog procesa. Sa stanoviata ra unalnog modeliranja, elementi od kojih se gradi model odreene operacije mogu biti bilo kakvi programi koji na bilo koji na in vrae pretvorbu informacija unutar skupa informacija o proizvodu. Na temelju prethodnih postavki mo~e se zaklju iti da pojam programske procedure (uz njenu funkciju i atribute) treba biti jedan od osnovnih elemenata odnosno entiteta sustava za podraku planiranju i izvoenju konstrukcijskog procesa. Pri tome osnovna obilje~ja (svojstva kao objekta-entiteta) svake programske procedure trebaju biti njena funkcija, odnosno namjena, te skup ulaznih i izlaznih atributa. U daljnjem tekstu uvesti emo naziv "akcijska funkcija" za programsku proceduru kao entitet modela procesa konstruiranja. Modeliranje poopenih operacija mo~e se realizirati uzastopnim pozivanjem niza akcijskih funkcija. Upotrebom postojeih programskih procedura (kao akcijskih funkcija) ili razvojem novih, uz osiguranje integralnog su elja za prijenos podataka izmeu procedura, mo~e se modelirati ra unalska podraka izvoenju odreene konkretne operacije, koja vrijedi za odreeni zadatak ili klasu zadatka, odnosno konstrukciju, i to u uvjetima okru~enja u kojem se odvija konkretan konstrukcijski proces. Konstrukcijske operacije (na razini 2 prema slici 5) openito sadr~e u sebi sve temeljne operacije sa razine 3 i ni~ih razina 4 i 5. One operacije i aktivnosti sa ni~ih razina koje se mogu algoritmizirati odnosno podr~ati ra unalom na bilo koji na in, mogu se ra unalno modelirati izvoenjem jedne ili niza od nekoliko akcijskih funkcija. Kao akcijske funkcije mogle bi se dakle koristiti sve vrste komercijalnih ili aplikativnih programa koji se koriste u okru~enju izvoenja konstrukcijskog procesa. Naravno, uvijek je potrebno odrediti i redoslijed izvoenja akcijskih funkcija - ato je zapravo definicija plana. Cilj procesa rjeaavanja zadatka (konstruiranja) je definiranje kompletne konstrukcije odnosno skupa svih informacija o proizvodu. Svaki slo~eniji zadatak mo~e se razlo~iti na viae podzadataka, od koji e svaki imati svoj parcijalni cilj. To zna i da se za svaki podzadatak mo~e postaviti redoslijed, odnosno plan izvoenja akcijskih funkcija ije e izvoenje rezultirati pretvorbom po etnog stanja odreenog podskupa informacija o proizvodu u ~eljeno (ciljno) stanje. Drugim rije ima mo~e se postaviti hijerarhija planova i podplanova koji ine ukupnu strukturu konstrukcijskog zadatka. Za modeliranje ra unalne podrake procesu konstruiranja nije nu~no uvijek postavljati kompletan plan rjeaavanja zadatka na najviaem nivou apstrakcije, jer tu razinu kontrole mo~e preuzeti sam konstruktor na na in da odreuje redoslijed izvoenja planova (odn. podplanova) koji mu slu~e kao podraka u procesu rjeaavanja podzadataka. Na in strukturiranja hijerarhije planova i podplanova bitno ovisi o slo~enosti konstrukcijskog zadatka, znanju i iskustvu konstruktora kao i o raspolo~ivim programskim alatima (u konkretnom okru~enju) koji se mogu koristiti kao akcijske funkcije. Ovdje se pretpostavlja da konstruktor sam treba modelirati podraku (planove) za rjeaavanje nekog zadatka ili klase zadataka iz svog djelokruga. Da bi to mogao efikasno napraviti mora imati na raspolaganju integriranu programsku okolinu koja treba sadr~avati slijedee elemente: Organizirano znanje o skupu akcijskih funkcija odnosno programa koje e koristiti u tijeku rjeaavanja zadatka. Takova baza znanja prvenstveno treba sadr~avati opise modela, namjene i ograni enja svakog programa, te detaljne opise skupova ulaznih i izlaznih podataka, te na ina njihova transfera (u i iz programa). Bazu znanja o proizvodu, pravilima izvoenja procesa konstruiranja i tehnologiji proizvodnje Ra unalni model procesa konstruiranja koji je koncepcijski dovoljno fleksibilan da se mo~e prilagoavati i nadograivati - pretpostavlja se da takove zahtjeve mo~e ispuniti objektni model. Objektni model trebao bi sadr~avati sve pojave i entitete iz "stvarnog svijeta" modelirane kao objekte. Potpuno definiranu sintaksu svakog strukturalnog elementa modela i elemenata koji implementiraju kontrolu i voenje procesa. Osim modeliranja akcija i operacija potrebno je razmotriti koje joa entitete treba uklju iti u ra unalni model procesa, obzirom na zna ajke procesa konstruiranja. Ograni enja i odluke u procesu konstruiranja Proces napredovanja od po etne specifikacije (definicije zadatka ili problema) do rjeaenja, odnosno kompletnog skupa informacija o ~eljenom proizvodu mo~e se promatrati kao niz koraka u kojima se izmjenjuju procesi obrade informacija i donoaenja odluka. Svaki od koraka mo~e se nazna iti nekom odlukom koja na bilo koji na in mijenja stanje unutar skupa informacija o proizvodu. Skup informacija o proizvodu ine svi generirani crte~i, modeli, analize, prora uni, tehni ke upute, biljeake i prikupljeno znanje tijekom procesa konstruiranja. Prema  REF _Ref409152939 \r \h  \* MERGEFORMAT [23] mogu se razlu iti dva razli ita glediata o tome kako proces konstruiranja napreduje po koracima, odnosno od jednog stanja do slijedeeg. Po jednom pristupu, opis proizvoda (konstrukcija) evoluira tijekom kontinuiranog (cikli kog) procesa usporedbe izmeu trenutnog stanja definiranosti skupa informacija o proizvodu i cilja, tj. skupa zahtjeva na konstrukciju definiranih konstrukcijskim zadatkom. Takav pristup implicira to no poznavanje svih zahtjeva na po etku rjeaavanja zadatka kako bi se jasno mogla definirati razlika u odnosu na trenutno stanje definiranosti konstrukcije. Razlika tih dvaju stanja tada kontrolira proces konstruiranja. Meutim, za veinu konstrukcijskih zadataka i/ili problema, takav pristup je previae jednostavan, jer u po etku procesa nisu svi zahtjevi precizno definirani, odnosno mogu se u tijeku procesa modificirati, pa ciljno stanje konstrukcije ne mo~e na po etku biti potpuno poznato. Po drugom pristupu, na po etku rjeaavanja zahtjevi na konstrukciju ograni avaju skup moguih rjeaenja na podskup svih moguih rjeaenja. Kako proces konstruiranja napreduje, nova ograni enja se dodaju da bi dalje reducirala mogua rjeaenja, koja se kontinuirano eliminiraju do jednog kona nog rjeaenja. Drugim rije ima, konstruiranje je sukcesivno razvijanje i primjena ograni enja dok ne preostane samo jedno rjeaenje. Ograni enja koja se dodaju u tijeku procesa konstruiranja proizlaze iz dva izvora. Jedan od izvora je ope stru no znanje konstruktora kao i znanje iz domene rjeaavanja zadatka. Kako svaki konstruktor raspola~e razli itim znanjem, primjenjivati e i razli ita ograni enja, pa e svaki rijeaiti zadatak na svoj, jedinstveni na in. Drugi tip ograni enja koja se primjenjuju u tijeku konstrukcijskog procesa proizlazi iz odluka koje se donose u procesu konstruiranja. Odluke definiraju ograni enja i na taj na in mogu utjecati na slijedee odluke u daljnjem tijeku procesa. Mo~e se rei da se veina ograni enja temelji na rezultatima konstrukcijskih odluka. Zbog toga je jedna od esencijalnih osobina konstruktora sposobnost donoaenja odluka, ali na temelju dobro razraenih kriterija, i u trenutku kad raspola~e s dovoljnom koli inom informacija. Na osnovu prethodnih razmatranja mo~e se uo iti nekoliko osnovnih entiteta (objekata) u promatranju proceduralne prirode konstrukcijskog procesa: operacije, odnosno akcije, ograni enja, odluke i ciljevi. Jedan od moguih na ina modeliranja tijeka odvijanja procesa je u obliku niza akcija (operacija) koje se izvode planiranim redoslijedom, uz definiranu strukturu plana. Izvoenje svake operacije u pravilu mijenja stanje unutar skupa informacija o proizvodu koji se konstruira, pa nakon izvoenja akcije treba provjeriti definirana ograni enja i donijeti odluke o daljnjem tijeku procesa. Pri tome se redoslijed izvoenja treba usmjeravati ka postizanju unaprijed definiranog cilja koji mo~e biti krajnje rjeaenje zadatka ili jedno od parcijalnih rjeaenja. Vrste zadataka, odnosno konstrukcija Elementi strukture konstrukcijskog procesa - objekti (mehani ki sustav odn. proizvod), operacije i koraci te redoslijed njihova izvraavanja znatno variraju ovisno o zadatku. Zna ajke, odnosno vrsta i slo~enost zadatka imaju bitan upliv na tijek i metode rjeaavanja. Prema stupnju odreenosti proizvoda zadatke, odnosno vrste konstrukcija mo~emo prema  REF _Ref409171901 \r \h [56] razvrstati kao: ponovljene - izrada po ve gotovoj dokumentaciji uz eventualno prilagoavanje novoj tehnologiji (to je zapravo ponovljena izrada proizvoda) kvantitativno usklaene - kvalitativno ista konstrukcija, ali kvantitativno ponovljena na na in da odreeni parametri dobivaju nove vrijednosti ( esto se u literaturi ovaj slu aj naziva parametarska konstrukcija) varijantne - osnovna funkcija i struktura proizvoda ostaju iste, ali se eventualno mijenjaju principi rada pojedinih parcijalnih funkcija prilagodne - osnovna funkcija ostaje ista, ali se uz izmjenu parcijalnih funkcija mo~e mijenjati i struktura nove konstrukcije - izrada na osnovu novih principa rjeaenja kod istog, promijenjenog ili novog zadatka Sustav za ra unalnu podraku izvoenju procesa konstruiranja treba modelirati tako da ne ovisi o vrsti konstrukcijskog zadatka, ali da se mo~e prilagoditi i koristiti u procesu rjeaavanja svake vrste zadatka ili unutar nekih slo~enijih vrsta zadataka barem za rjeaavanje parcijalnih zadataka. Naime, za nove ili vrlo slo~ene konstrukcije teako je o ekivati da ima smisla postavljati model procesa (plan izvoenja) na najviaoj razini apstrakcije zadatka - npr. plan za konstruiranje lokomotive ili npr. plan za razvoj potpuno nove konstrukcije nekog stroja specijalne namjene. Isto tako, za relativno jednostavne zadatke esto nema smisla postavljati plan, ako se za isti utroaak vremena zadatak mo~e i rijeaiti. Metode konstruiranja Prema  REF _Ref409180953 \r \h  \* MERGEFORMAT [61] metodi kim se konstruiranjem nastoji pomou znanstvenih metoda razviti proces konstruiranja kao metodu koja omoguuje da se problematika konstruiranja rjeaava openito, a ne kao problematika konstruiranja sasvim odreenog stroja ili ureaja. Rije  je, zapravo o tome da se konstruiranje shvati kao proces u kojem se jednakim postupcima mogu rjeaavati razli iti zadaci. U literaturi iz podru ja znanosti o konstruiranju mo~e se nai airoki spektar prikaza i opisa razvijenih metoda konstruiranja, kao i metoda i principa tra~enja rjeaenja za pojedine parcijalne funkcije. Kao ilustraciju te injenice navedimo neke od autora:  REF _Ref409182852 \r \h  \* MERGEFORMAT [1],  REF _Ref409151916 \r \h  \* MERGEFORMAT [16],  REF _Ref409152939 \r \h  \* MERGEFORMAT [23],  REF _Ref409183300 \r \h  \* MERGEFORMAT [62],  REF _Ref409183302 \r \h  \* MERGEFORMAT [63],  REF _Ref409183304 \r \h  \* MERGEFORMAT [64],  REF _Ref409183306 \r \h  \* MERGEFORMAT [65],  REF _Ref409183310 \r \h  \* MERGEFORMAT [66],  REF _Ref409183311 \r \h  \* MERGEFORMAT [67]. Implementacija postupaka i principa veine razvijenih metoda metodi kog konstruiranja u sustav za podraku konstrukcijskom procesu mogla bi biti tema razmatranja posebnog rada (za svaku od metoda). Prikaz svih metoda konstruiranja bio bi preopairan, pa e se ovdje samo izdvojiti Roth-ov  REF _Ref409183304 \r \h  \* MERGEFORMAT [64] algoritamski postupak konstruiranja pomou kataloga. Po ovom postupku u prvoj fazi provodi se analiza proizvoda iji rezultat ini precizno formulirani zadatak. Tako formulirani zadatak sadr~i potrebnu funkciju, tehni ke zahtjeve i potrebne troakove. Zahtjevi tvore kriterije pomou kojih se u kasnijoj fazi mo~e izvraiti izbor iz kataloga. Katalozi predstavljaju zbirku rjeaenja koja su se pokazala dobra za odreene konstrukcijske zadatke ili parcijalne funkcije. Katalozi mogu sadr~avati informacije razli itog sadr~aja i rjeaenja razli itog stupnja konkretizacije. U katalozima mogu biti : principi rjeaenja, fizikalni efekti, koncepcijska rjeaenja za kompletne zadatke, elementi strojeva, standardni dijelovi, materijali, gotovi dijelovi, itd. Mialjenje je autora, da se ovakva koncepcija kataloga mo~e ra unalno modelirati u obliku baze znanja, koja bi trebala biti koncipirana tako da se mo~e koristiti u tijeku generiranja plana procesa konstruiranja. Navedeno mialjenje je i osnovni razlog za izdvajanje i navoenje ove metode konstruiranja. Napredovanje u procesu rjeaavanja zadatka Metode i principi tra~enja rjeaenja temeljene na heuristi kim principima (odn. metodi kim postupcima) predstavljaju alat za metodi ki tok i upute za na in promialjanja u tijeku konstruiranja. Stoga se namee pretpostavka da ove metode mogu poslu~iti i kao smjernice modeliranja napredovanja u procesu rjeaavanja zadatka. Ovdje e se kao relevantna metoda (iz grupe metoda temeljenih na heuristi kim principima) izdvojiti prikaz "metode to no usmjerenih koraka". Metoda to no usmjerenih koraka sastoji se u postavljanju  pitanja samom sebi na na in koji usmjerava k rjeaenju. Predlo~eni na in mialjenja odvija se u etiri stupnja (slika 6): razumijevanje zadatka, zamialjanje plana, izvoenje plana i pogled unatrag.  INCLUDEPICTURE "linkane slike\\MEUSMKOR.WMF" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 6: Metoda to no usmjerenih koraka Prije zaklju nih razmatranja ovog poglavlja u kojem je analiziran proces konstruiranja, navesti emo neke izvatke iz sustava postavki (izreka) navedenih u zadnjem poglavlju knjige  REF _Ref409261642 \r \h  \* MERGEFORMAT [22] koje se (prema autoru) mogu interpretirati s jedne strane kao teze, a s druge strane kao kona ni zaklju ci. Postoji struktura relativno konkretnih operacija i njihovog redoslijeda, koja predstavlja idealan model napredovanja (u procesu konstruiranja), koji vrijedi za sve vrste konstrukcijskih zadataka. Model napredovanja za proces konstruiranja tehni kih sustava sadr~i logi an i probita an redoslijed faza (operacija), koji je usklaen sa zna ajkama sustava koji se konstruira, te pretpostavlja idealno stanje (polo~aj) operatora. Za odreeni projekt postoji jedan optimalan plan napredovanja koji odgovara konkretnoj definiciji zadatka i konkretnim operatorima procesa konstruiranja. Zaklju ci provedene analize procesa konstruiranja Rezimirajui razmatranja u ovom poglavlju mo~e se postaviti pitanje kako treba koncipirati model ra unalne podrake konstrukcijskom procesu, obzirom na navedene zna ajke konstrukcijskog procesa i promatranje konstruiranja kao rjeaavanja zadatka. Cilj istra~ivanja u projektu razvoja objektnog modela procesa konstruiranja nije razvoj  automata , ve fleksibilnog modela koji omoguuje manipulaciju informacijama u razli itim oblicima i na razli itim razinama apstrakcije, sukladno prirodnom toku promialjanja, odnosno razvoja konstrukcije. Takav sustav treba djelovati kao  pomonik konstruktora, na taj na in da konstruktor mo~e modelirati ra unalnu podraku kakva mu za odreeni zadatak odgovara, koristei raspolo~ive programske alate. Pri tome sustav treba biti primjenjiv neovisno o vrsti i domeni zadatka kao i o fazi procesa konstruiranja u kojoj se koristi. Iz ovako postavljenih zahtjeva proizlazi da razvoju sustava treba pristupiti tako da se prvo razvija opa okosnica ili okolina (okru~enje) koja podr~ava (i integrira) budue dijelove sustava. Na temelju takve integrirane okoline mogu se dalje graditi viae ili manje  inteligentni podsustavi. Napredovanje u procesu konstruiranja mo~e se prikazati planom, tako da operacije u procesu konstruiranja predstavljaju operatore plana. U ra unalnom modelu plana pojam operatora mo~e se modelirati izvoenjem neke programske procedure koja na bilo koji na in vrai odreenu pretvorbu informacija na nekom podskupu skupa informacija o proizvodu koji se konstruira. Iz razmatranja tijeka rjeaavanja konstrukcijskog zadatka slijedi da proces napreduje kroz donoaenje odluka, te postavljanje i provjeru ograni enja, ato zna i da odluke i ograni enja takoer treba kao objekte implementirati u strukturu plana. Pretpostavlja se da sam plan, odnosno zapis plana mo~e biti temelj prikaza tijeka izvoenja procesa u objektnom modelu procesa konstruiranja. Da bi konstruktor mogao efikasno modelirati podraku rjeaavanju konkretnog zadatka iz svog djelokruga, mora imati na raspolaganju integriranu programsku okolinu u kojoj e na temelju definirane sintakse generirati i nakon toga eksploatirati plan rjeaavanja zadatka. Pri tome nije nu~no da postavlja plan rjeaavanja na najviaoj razini apstrakcije jer iz razmatranja metoda i principa rjeaavanja konstrukcijskih zadataka slijedi da se svaki konstrukcijski zadatak dade razlo~iti na skup jednostavnijih podzataka za koje su poznate metode rjeaavanja. Poato sustav ne bi trebao biti koncipiran kao  automat , potrebna je ljudska kontrola procesa konstruiranja, ali uz uvjet da sam ra unalni model procesa u tome ima odgovarajuu ulogu (podraku), koliko god i gdje god je to mogue. Pristupi i polaziata modeliranja procesa konstruiranja Ve je ranije napomenuto da je do danas u Znanosti o konstruiranju predlo~en velik broj modela procesa konstruiranja razli itih autora. Nekoliko modela svojim zna ajem se isti e, i obi no se u literaturi za njih koristi naziv "ope teorije konstruiranja". Pregled i osvrt na etiri takva modela dan je u slijedeem dijelu ovog poglavlja. Ipak, analiza tih modela nije sama po sebi dovoljna kao polaziate za koncipiranje objektnog modela procesa konstruiranja. Potrebno je osim toga razmotriti joa nekoliko podru ja i razli itih pristupa unutar njih. Prije svega to se odnosi na razvijene informacijske sustave (modele) i njihovu primjenu u konstruiranju, te na pristupe planiranju u podru ju umjetne inteligencije. Kvaliteta modela (openito) ovisiti e najviae o primjenjenim principima modeliranja, pa je kao dio ovog poglavlja dan i kratki osvrt na problematiku modeliranja. Od posebne va~nosti za cilj ovog rada je i razmatranje metoda prikaza procesa i topologije prikaza akcija u procesu konstruiranja. Sve navedene teme, odnosno podru ja, obraena su u ovom poglavlju kao uvodna razmatranja pristupa i polaziata koncipiranja entiteta objektnog modela procesa konstruiranja. Prikaz objektno orijentirane tehnologije modeliranja i programiranja izdvojen je kao slijedee poglavlje. Pregled zna ajnijih "teoretskih" modela procesa konstruiranja Zakonitosti koje vladaju u procesu konstruiranja kao kreativnoj ljudskoj djelatnosti, nastoje se opisati teorijama ija su polaziata uvjetovana okolinom i svim njenim uplivima (filozofskim, povijesnim, socioloakim, gospodarskim, itd.). Do sada razvijene teorije mogu se razvrstati po okru~enjima u kojima su nastale na njema ke (evropske), ameri ke i japanske. U ovoj je glavi dan pregled jednog proceduralnog modela i tri (po mialjenju autora) najzna ajnije teorije. Proceduralni model procesa konstruiranja prema VDI 2221 U njema kom okru~enju te~nje za sistematizacijom i sustavnim metodi kim pristupom konstruiranju najranije su zapo ele i najviae su bile izra~avane. Velik broj autora predlagao je svoje metode i principe. Prirodno je da je u takvom okru~enju razvijen i proceduralni model procesa konstruiranja u obliku "preporuka" odn. "vodi a" (richtlinie, guideline). Model je rezultat rada skupine autora i objavljen je u obliku preporuka  REF _Ref409233023 \r \h [21],  REF _Ref409233026 \r \h [68]. Namjena modela je openita, te su dani i primjeri upotrebe za razli ite industrijske grane. Ipak, razmatrane ideje ini se da su najviae vezane uz strojarsko konstruiranje  REF _Ref409183306 \r \h [65]. U modelu su nazna eni glavni koraci procesa od apstraktne razine raa iaavanja zadatka do detaljiranja konstrukcije. Prisutnost iterativnih petlji zna i da ovaj model nije vremenski orijentiran, kako se esto shvaa  REF _Ref409493420 \r \h [58]. Slika 7 prikazuje opi pristup procesu konstruiranja, odnosno korake i faze procesa. Nakon svakog koraka treba donijeti odluku da li se mo~e prijei na slijedei ili treba ponoviti prethodni. Faze procesa mogu se promatrati i kao razine apstrakcije  REF _Ref409493420 \r \h [58]. Oatre granice izmeu faza ne mogu se postaviti, a isto tako ne treba kruto promatrati niti redoslijed faza. Ovakav model ne prikazuje proces rjeaavanja problema, odnosno kako se dolazi do rjeaenja  REF _Ref409183306 \r \h [65]. U procesu rjeaavanja problema rjeaenja se generiraju i testiraju unutar svake faze. To zna i da zapravo u svakoj fazi konstruktor prolazi kroz temeljni ciklus procesa konstruiranja, esto i nekoliko puta.  INCLUDEPICTURE "linkane slike\\VDI 2221 - NOVI.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 7: Faze procesa konstruiranja prema  REF _Ref409233023 \r \h [21] U svakoj fazi treba misliti na viae alternativa rjeaenja. Razrada svih varijanti rjeaenja kroz sve faze dovela bi do kombinatori ke eksplozije. S druge strane usredoto enje na samo jednu putanju unutar mre~e mogunosti zna i da se mogu previdjeti bolja ili najbolja rjeaenja. Stoga konstruktor mora divergirati i konvergirati u svakoj fazi. Taj va~ni metodi ki princip ilustriran je slikom 8. Napomenimo ovdje da je ovakav na in promatranja procesa (divergencija i konvergencija) izuzetno va~an i za prikaz tijeka procesa u ra unalnom modelu.  INCLUDEPICTURE "linkane slike\\VDI2222.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 8: Dijagram toka procesa konstruiranja prema  REF _Ref409233026 \r \h [68] Opi model procesa konstruiranja (Hubka, Eder) Opi model konstruiranja koji je postavio Hubka 1973. godine  REF _Ref409261642 \r \h [22], daje pregled skupa aktivnosti, vrsta procesa i upliva na proces konstruiranja. Razvojem opeg modela konstruiranja autor je tijekom vremena postavio teoriju tehni kih sustava, te unutar nje noviji  opi proceduralni model konstruiranja  REF _Ref409173935 \r \h [60]. Autor prve verzije teorije je Hubka, ali novija engleska izdanja  REF _Ref409151916 \r \h [16],  REF _Ref409173935 \r \h [60] potpisuje i Eder.  INCLUDEPICTURE "linkane slike\\hub model1.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 9: Opi model procesa konstruiranja prema  REF _Ref409261642 \r \h [22] Opi model procesa konstruiranja mo~e se interpretirati na slijedei na in: konstruiranje je proces transformiranja informacija od zahtjeva kupaca do potpunog opisa predlo~enog tehni kog sustava prikazuje se osnovna struktura procesa, uklju ujui regulacijske, kontrolne i pomone procese kao direktni operatori, konstruktori i njihova sredstva za rad izvode akcije (efekte) na skupu informacija (operanada konstrukcijskog procesa) prikazuje se utjecaj ostalih razli itih faktora na proces konstruiranja (metode rada, radna okolina, upravljanje) S ciljem da se predlo~eni model procesa konstruiranja osuvremeni, te omogui primjena ra unala, teorija je tijekom godina evoluirala do "opeg proceduralnog modela procesa konstruiranja"  REF _Ref409173935 \r \h  \* MERGEFORMAT [60],  REF _Ref409151916 \r \h  \* MERGEFORMAT [16]. U tom modelu proces konstruiranja dijeli se na etiri osnovna dijela: Elaboriranje, odnosno pojaanjavanje zadane specifikacije Koncipiranje - postavljanje funkcionalne strukture i strukture osnovnih fizi kih komponenti sustava Definiranje dispozicije sustava - preliminarno i kona no dimenzionalno rjeaenje Detaljna razrada rjeaenja, izrada dokumentacije Svaka od navedenih osnovnih faza raa lanjuje se dalje na korake. Svaka faza sadr~i operacije ispitivanja mogunosti unapreenja, vrednovanja, izbora, odlu ivanja, provjere i potvrivanja. Faze se povezuju i odvijaju unutar procesa rekurzije, iteracije, dekompozicije i analize povratnih informacija. Za ovako koncipiranu teoriju karakteristi no je da je veina pojmova sistematizirana i opisana, te je teorija lako razumljiva, edukativna i pregledna. Neki autori navode da je osnovni nedostatak ato se teorija osniva na fenomenoloakom opisu, bez egzaktnog aparata, ato ote~ava formalizaciju teorije kao polaziata za razvoj ra unalnog modela procesa konstruiranja. Opa teorija konstruiranja (Yoshikawa, Tomiyama) Opa teorija konstruiranja (Yoshikawa, General Design Theory - GDT) po iva na tri abdukcione hipoteze iz kojih autor izvodi tri aksioma. Definicije pojmova i teoremi teorije grade se na formalnom aparatu aksiomatske teorije skupova  REF _Ref409182189 \r \h [69],  REF _Ref409182190 \r \h [70],  REF _Ref409160783 \r \h [71]. Od prvog objavljivanja pred gotovo 20 godina proirena su razmatranja unutar GDT, te se sada u literaturi navodi i kao Extended General Design Theory. Proklamirani ciljevi ove teorije su: znanstveno utemeljenje procesa konstruiranja formaliziranje prakti no upotrebljivog znanja o metodologiji konstruiranja formalan na in prezentiranja znanja o konstruiranju, s ciljem ra unalne implementacije. Razmatranja "Ope teorije konstruiranja" izvode se u kontekstu poimanja tri razli ita svijeta (i preslikavanjima izmeu njih - slika 10) : realnog R - gdje egzistiraju konkretni entiteti konceptualnog C - gdje zamialjamo entitete iz realnog svijeta, svaki pojedinac posjeduje svoj vlastiti konceptualni svijet. logi kog L - kao svijet simbola, logike, matematike itd. Tako su npr. fizika, epistemologija, kognitivne znanosti, logika, tehnologija i znanost o konstruiranju definirane kao neka od preslikavanja izmeu tih svjetova (slika 10). Stoga, (po shvaanju autora teorije) konstruiranje je niz preslikavanja iz konceptualnog svijeta u realni svijet, preko logi kog svijeta. U ovom se dijelu sla~u gotovo svi pristupi fenomenu konstruiranja, s malo razli itom terminologijom, naime eai je termin  transformacija od  preslikavanja . Konstruiranje se shvaa kao aktivnost kod koje se kreira entitet u realnom svijetu, od prve ideje koja se stvara u konceptualnom svijetu (na osnovu utjecaja iz realnog svijeta), kroz logi ki svijet (u kojem egzistiraju samo simboli, npr. crte~i).  Slika  SEQ Slika \* ARABIC 10: Shema preslikavanja unutar prostora GDT prema  REF _Ref409182190 \r \h [70] Fizika je prikazana kao preslikavanje R SYMBOL 174 \f "Symbol" C SYMBOL 174 \f "Symbol" L, gdje je prvi dio preslikavanja promatranje fenomena koje je pokrivano epistemologijom, a druga polovina preslikavanja je primjena matematike ili logi kih operacija koje slu~e da bi se fizikalni fenomeni opisali na objektivan (znanstveni) na in. Konstruiranje se definira kao preslikavanje neke to ke iz funkcionalnog prostora u to ku u prostoru atributa (uz idealno znanje). Budui je metrika prostora funkcije i prostora atributa obi no nekompatibilna, uveden je koncept metamodela (M), kao meuprostora u tom preslikavanju (slika 11).  Slika  SEQ Slika \* ARABIC 11: Koncept metamodela  REF _Ref409182190 \r \h [70] Mo~e se prigovoriti da GDT preidealisti ki prikazuje konstruiranje, ali je ona okvir koji omoguuje ra unalnu implementaciju. Naime teorija razmatra tri segmenta znanosti o konstruiranju: teoriju konstruiranja, teoriju objekata konstruiranja, i teoriju znanja. Temeljem toga realiziran je i sustav IDDL  REF _Ref409163449 \r \h [72] koji eksploatira ideju opisa atributa entiteta funkcijama. Problem nesigurnih i neto nih specifikacija rjeaavaju autori kombinacijom nodalne logike i matematike predikata prvoga reda. Zaklju iti emo s mialju da GDT ne mo~e adekvatno predstavljati realno konstruiranje. Uvoenjem prihvatljivih ograni enja i relaksirajui prestroge zahtjeve formalnog modela zastupljenog pogotovo u  idealnom dijelu GDT teorija mo~e poslu~iti (i ve je) kao smjernica za gradnju boljih CAD sustava. Aksiomatska teorija konstruiranja (Suh) Aksiomatska teorija konstruiranja  REF _Ref409182183 \r \h [73] nudi sustavni pristup konstruiranju proizvoda i planiranju proizvodnje. Argumentacija i motivacija razvoja ove teorije sli ne su kao i u prethodnim primjerima. Pri tome Suh naglaauje  REF _Ref409166254 \r \h [74] da teorija  osigurava istovremeno formalni opis konstrukcijskog procesa i skup osnovnih principa odlu ivanja . Proces konstruiranja podijeljen je na slijedee korake: odreivanje ciljeva konstruiranja koji zadovoljavaju zadani skup potreba naru itelja, generiranje ideja za kreiranje vjerojatnih rjeaenja, analiza predlo~enih rjeaenja, izbor rjeaenja koje najpovoljnije zadovoljava ciljeve, primjena (razrada ) odabranog rjeaenja Aksiomatski pristup opisanog konstrukcijskog procesa temelji se na slijedeim konceptima. Konstruiranje uklju uje kontinuiranu obradu informacija izmeu i unutar etiri razli ite domene (slika 12). Alternativna rjeaenja kreiraju se pridru~ivanjem zahtjeva specificiranih u jednoj domeni, skupu zna ajki druge domene. Izlaz svake domene upotpunjuje se u hijerarhijskom na inu od apstraktnog koncepta do potpuno odreenih informacija. Hijerarhijska dekompozicija u jednoj domeni ne mo~e se provesti nezavisno od hijerarhijom susjednih domena, odnosno dekompozicija slijedi  cik-cak preslikavanja unutar morfologija susjednih domena (Ovime Suh inzistira na morfoloakoj sli nosti struktura dekompozicija susjednih, a time i svih domena. Formalno to nije nigdje dokazano). Dva aksioma tvore racionalnu bazu za vrednovanje predlo~enih alternativa rjeaenja i nakon toga izbor najbolje alternative. Potrebe se korisnika pojavljuju u domeni korisnika (domena potroaa a), a formaliziraju u funkcionalnoj domeni kao skup koji iji su lanovi funkcionalni zahtjevi (FR) kojima je odreeno nala~enje rjeaenja. Pri tome je svaki funkcionalni zahtjev (FR) po definiciji nezavisan od ostalih funkcionalnih zahtjeva. Kako se kompleksnost opisa poveava s brojem funkcionalnih zahtjeva za primjenu je teorije va~no da se potrebe opisuju s minimalnim skupom nezavisnih zahtjeva. Kreativna faza konstruiranja ili sinteza uklju uje pridru~ivanje FR parametrima konstrukcije (DP) u fizikalnoj domeni. Broj moguih rjeaenja za svaki dani skup FR ovisi o imaginaciji, i iskustvu konstruktora. Stoga aksiomi slu~e za odreivanje prihvatljivih rjeaenja.  Slika  SEQ Slika \* ARABIC 12: Domene procesa konstruiranja po aksiomatskoj teoriji  REF _Ref409166254 \r \h [74] Aksiom 1 (aksiom nezavisnosti): Osigurati nezavisnost funkcionalnih zahtjeva. Aksiom 2 (informacijski aksiom): Minimizirati informacijski sadr~aj konstrukcije. Prvi aksiom odreuje prirodu pridru~ivanja izmeu  onoga ato se tra~i (FR-a) i  kako se to posti~e parametara konstrukcije (DP-a). Suh smatra da  dobro konstrukcijsko rjeaenje osigurava nezavisnost funkcionalnih zahtjeva. U drugom se, informacijskom, aksiomu odreuje sadr~aj informacija konstrukcije kao mjera za odreivanje relativne vrijednosti i usporedbu alternativnih rjeaenja koja zadovoljavaju prvi aksiom. Zna enje aksioma nezavisnosti Pridru~ivanje izmeu m-komponentnog vektora FR (vektor funkcionalnih zahtjeva) i odgovarajueg vektora parametara konstrukcije DP s n komponenata odreeno je izrazom:  EMBED Equation.2  4.1.4.1 gdje je A matrica konstrukcije kojom se odreuje priroda i odnos izmeu svakog funkcionalnog zahtjeva FRi u FR i svakog parametra konstrukcije DPj u DP. Openito se onda lanovi matrice mogu prikazati kao:  EMBED Equation.2  4.1.4.2 i povezuju komponente vektora FR s komponentama vektora DP. Matrica A ima slijedei oblik:  EMBED Equation.2  4.1.4.3 Vrednovanje Aij provodi se u fizikalnoj domeni tijekom konstruiranja, osim u slu aju kada je Aij=konst. Izraz 3.3.1 Suh naziva  jednad~bom konstrukcije u kojem lijeva strana prikazuje ~elje formulirane u obliku zahtjeva koje treba ispuniti, a desna strana  kako mislimo zadovoljiti zahtjeve . Osvrt na prikaz teorija o konstruiranju U prethodnim poglavljima dan je sa~eti prikaz istra~ivanja u podru ju znanosti o konstruiranju, te odabranih relevantnih teorija, od do sada razvijenih unutar znanosti. Iz dosadaanjih razmatranja proizlazi da ne postoji jedinstvena teorija koja objaanjava fenomen konstruiranja. Pri izvoenju teorija, izra~ajni aparat koji se koristi za objaanjavanje zakonitosti podru ja nije od najvee va~nosti. Teorija se mo~e formulirati formalnim i neformalnim aparatom, bitno je da opisuje odnose i pojave podru ja promatranja dosljedno. Iz prikaza danih u ovoj glavi rada mo~e se zaklju iti. Sve prikazane teorije nastoje utvrditi zakonitosti koje vladaju u va~noj djelatnosti ljudi - stvaranju proizvoda. Sve teorije inzistiraju na sistemati nosti u konstruiranju. Polazne osnove teorija (na kojima se ove osnivaju) veoma su sli ne, odnosno preklapaju se. Niti jedna (autoru ovoga rada poznata) teorija ne obuhvaa sve aspekte procesa konstruiranja. U svim se pristupima odvojeno promatraju konstrukcija, proces konstruiranja, te na in provoenja procesa. Povezivanje funkcije i forme nastoji se formalno povezati, bez (do sada) rjeaenja na opoj razini. Postoji koncenzus u prikazu procesa konstruiranja. Iako autori druga ije opisuju proces i razgrani enja faza u procesu, razlike nisu suatinske, ve terminoloake. Sli nosti izmeu teorija vee su od razlika. Teorije se meusobno razlikuju u: primjenjenoj metodologiji i terminologiji, razini primjene egzaktnog (formalnog) aparata, naglascima pojedinih segmenata razvoja proizvoda, preporu enoj metodologiji (i tehnologiji). Navedene razlike (veim dijelom) proizlaze iz razli itosti osobnih iskustava autora. Mo~emo zaklju iti da unutar znanosti o konstruiranju postoje razli ite akole koje opisuju fenomen konstruiranja razli itim metodama. Primjena ra unala nesumnjivo predstavlja sna~an impuls primjeni formalnog matemati kog aparata u osnivanju teorija. Poseban zna aj razvoja teorija ogleda se u sustavnom pristupu izu avanja konstruiranja. Meutim na sadaanjoj razini razvoja teorija, treba podr~ati samo ona htijenja koja omoguuju konstruktorima napredovanje od problema do rjeaenja, uz ekstenzivno i objektivno pretra~ivanje prostora rjeaenja, ne ograni avajui pri tome kreativnost konstruktora. Mo~e se zaklju iti da ni jedna teorija nije sveobuhvatna, niti pogodna kao osnova (polaziate) za razradu objektnog modela procesa konstruiranja. Svaku teoriju mo~emo promatrati kao zaseban pristup i doprinos, ije spoznaje trebaju biti "ideje vodilje" pri koncipiranju modela. Odreene dijelove, odnosno razmialjanja vjerojatno je mogue i implementirati u objektni model. `to se danas o ekuje od teorije konstruiranja? Izmeu ostalih autora koji nude odgovore na takvo pitanje izdvojiti emo Vajnu,  REF _Ref409238939 \r \h [4] i  REF _Ref409233354 \r \h [75]: da uklju i sve zna ajke cijelog ~ivotnog vijeka proizvoda (razmatranje svih aspekata termina "design for x") da uklju i i podr~i vremenski paralelne procese (istovremeno (paralelno) in~enjerstvo) formalizacija strukture i sadr~aja procesa konstruiranja u modelu procesa za deriviranje i realizaciju funkcija za cjelokupnu ra unalnu podraku Jedan od prvih koraka u razvoju teorije konstruiranja koja bi opisala cjelokupni proces konstruiranja prema  REF _Ref409233354 \r \h [75] je korektno ujedinjavanje razli itih parcijalnih modela uz koriatenje postojeih mogunosti matemati kog modeliranja. Problematika modeliranja U kontekstu teme ovog rada, va~no je postaviti pitanje kako treba modelirati? Kojih se principa treba dr~ati pri koncipiranju modela? Kako kreiramo modele i kojim se tehnikama koristimo za prikaz modela? Vrlo interesantna razmatranja o atribuciji modela, a mo~da i dio odgovora na ova pitanja daje Schregenberger u  REF _Ref409257741 \r \h [76]. Schregenberger citira Stachowiak-a, koji je u  REF _Ref409264175 \r \h [77] predlo~io integralnu koncepciju modela. Prema  REF _Ref409264175 \r \h [77] izjave o ne emu (o "originalima") uvijek se odnose na odreenu svrhu, prikazuju original sa razli itih aspekata, potje u od nekoga, usmjerene su nekome, i dio su specifi nog konteksta. Takva opa koncepcija omoguuje nam sistematizaciju i razmatranje bilo koje vrste ljudskog izraza. Modele upotrebljavamo za spremanje, procesiranje i razmjenu znanja. Optimalno upravljanje modelima odlu ujue je za uspjeanost intelektualnog in~enjerskog rada. Froese  REF _Ref409266202 \r \h [78],  REF _Ref409266205 \r \h [79] razmatra problematiku modeliranja informacijskih sustava u domeni projektiranja u graevinarstvu. U lanku  REF _Ref409266202 \r \h [78] dan je pregled i komparativna analiza konceptualnih modela ("core models") procesiranja informacija konstruiranja u podru ju arhitekture i graevinarstva. Kao najvei, i vjerojatno najzna ajniji projekt u danom pregledu naveden je dio standarda ISO 10303 (STEP). Prema autoru nisu joa razvijene komponente STEP-a za konceptualno modeliranje projektnih procesa (stanje 1994). Informacijski modeli (sustavi) Primjena baza podataka kao sustava za praenje proizvodnje (financijsko, organizacijsko i logisti ko) svakako ima veliki upliv i na modeliranje ra unalne podrake konstruiranju. Kao informacijske sustave mo~emo promatrati i tzv. "EDM" sustave (engineering data management). EDM sustavi zapravo su jedna komponenta ra unalne podrake procesu konstruiranja, koju treba su eljima povezati sa modelom procesa konstruiranja. Prema  REF _Ref409178545 \r \h [80]: Informacijski model je formalni opis ideja, injenica i procesa koji zajedno ine model dijela stvarnog svijeta, i osiguravaju eksplicitni skup interpretacijskih pravila. U idealnom slu aju informacijski model bi trebao osigurati potpunu, to nu i jednozna nu sliku pojave koja se modelira. Razvoj informacijskih sustava s pripadajuim aplikacijama prvenstveno je vezan uz netehni ku problematiku, dok primjena ovakvih tehnologija u in~enjerstvu zahtijeva, zbog druga ije prirode informacija s kojima se operira, u mnogo emu druga iji pristup  REF _Ref409251518 \r \h [81]. Stoga e se razmotriti zna ajke in~enjerskih podataka, da bi se nazna ili mogui problemi informacijskog modeliranja procesa konstruiranja. Priroda in~enjerskih podataka Priroda in~enjerskih podataka vrlo je razli ita od podataka u poslovnim aplikacijama, otkuda sti~e veina razvoja u podru ju tehnologije baza podataka. Uz potencijalno veliku koli inu, podatke u in~enjerskim aplikacijama karakterizira raznorodnost i vrlo slo~ena povezanost izmeu struktura. Prema  REF _Ref409251518 \r \h [81] podaci u in~enjerstvu mogu se opisati na slijedei na in: Struktura in~enjerskih podataka je neuniformna i nepredvidiva. Instance jedne konceptualne strukture mogu varirati u veli ini, a skup podataka koji prikazuje cijeli proizvod mo~e sadr~avati veliki broj razli itih struktura podataka, s relativno malim brojem instanci svake strukture. Mnogi od koncepata zahtijevaju prikaz koji je mre~a struktura i odnosa. Npr. za prikaz ~i anog modela potrebne su geometrijske informacije koje odreuju to ke/vrhove modela. Topoloake informacije odreuju bridove koje povezuju to ke. Za vizualizaciju ~i anog modela potrebne su i geometrijske i topoloake informacije. Veze meu strukturama su mnogobrojne, a iste strukture mogu imati razli ite uloge. Npr. strojni dio je u jednom slu aju proizvod, a u drugom komponenta u sklopu slo~enijeg proizvoda. Zna ajan udio podataka ovisi o postojanju drugih podataka. Cjelovitost skupa podataka relativna je u odnosu na stadij ~ivotnog vijeka proizvoda. Razina to nosti numeri kih podataka varira ovisno o zna enju podataka i aplikaciji koja ih koristi. Npr., aplikacija koja provjera mogu li se komponente slo~iti u sklop zahtjeva bitno veu to nost od aplikacije koja se koristi pri pakiranju. Postoje slo~ena pravila za instanciranje podataka. Npr., ako je proizvod definiran kao sklop, mora imati viae od jedne komponente, a svaka od komponenti mora imati barem jedan uvjet spajanja koji odgovara uvjetu spajanja druge komponente. Nu~no je osigurati cjelovitost podataka odgovarajuim algoritmima. Npr., ako se obriae jedna od komponenti sklopa, struktura sklopa se mora prilagoditi. Jedna koncepcija prikaza mo~e se na detaljiziranoj razini prikazati na viae na ina. Npr., prikaz oblika mo~e biti ~i ani model, rasterska slika ili solid model. Proces konstruiranja i metode planiranja u umjetnoj inteligenciji Istra~ivanja primjene spoznaja i metoda Umjetne inteligencije u konstruiranju po ela su otprilike prije dvadesetak godina. Nakon po etnih rezultata istra~ivanja su se po ela razvijati u tri meusobno zavisna smjera  REF _Ref409252999 \r \h  \* MERGEFORMAT [82]: Razvoj tehnika prikaza in~enjerskog znanja: "blackboard sustavi" "production rule" sustavi (ekspertni sustavi) strukturirani objektni prikazi Razvoj "boljih" modela procesa konstruiranja. Razvoj arhitektura za integraciju razli itih sustava za podraku konstruiranju. Prema  REF _Ref409252999 \r \h [82] modeliranje procesa konstruiranja joa je uvijek nedovoljno rasvijetljeno podru je. Nije joa dovoljno dobro spoznato kako treba upotrijebiti ra unalne sustave u podraci svim aktivnostima konstruktora (a ne samo geometrijskom modeliranju). Rad na modelima procesa konstruiranja razmatra spoznajne procese konstruktora dok radi, te vrste, izvore i manipulaciju znanjem. Ova istra~ivanja otvorila su trei pravac - kako integrirati razli ite vrste sustava rezoniranja i kako ih automatski kontrolirati i omoguiti efikasnu komunikaciju sa "ljudskim" korisnicima. Svrha je tih istra~ivanja spoznati (razumjeti) kako postii efikasno povezivanje ljudske i umjetne inteligencije u procesu konstruiranja. Postavimo pitanje kako konstruktor organizira svoj rad, odnosno redoslijed izvoenja pojedina nih aktivnosti? Ovom temom danas se bave i multidisciplinarni timovi, u koje su uklju eni i psiholozi  REF _Ref409254725 \r \h [83],  REF _Ref409254727 \r \h [84],  REF _Ref409254728 \r \h [85],  REF _Ref409254730 \r \h [86]. Rezultati jedne od takvih studija prikazani su u  REF _Ref409254996 \r \h [87]. Rana istra~ivanja zaklju uju da se aktivnost konstruiranja hijerarhijski organizira, odnosno slijedi unaprijed postavljeni plan. Konstruktori svoje aktivnosti opisuju planovima, ali pokazalo se da je njihova stvarna aktivnost organizirana viae oportunisti ki. Pretpostavlja se da primjena razvijenih metoda planiranja (u podru ju umjetne inteligencije) mo~e pridonijeti pribli~enju ra unalnog modela realnom procesu konstruiranja. Stoga je u ovom poglavlju dan sa~eti prikaz dosadaanjih istra~ivanja i dostignua u dijelu podru ja Umjetne inteligencije koje se bavi razvojem metoda i algoritama za ra unalsku podraku planiranju. Prikaz je dan prema kompilacijskom priru niku  REF _Ref409258111 \r \h  \* MERGEFORMAT [88]. Trebalo bi napomenuti da se te metode uglavnom primjenjuju u robotici, te u planiranju i voenju tehnoloakih procesa. Svrha je ovog prikaza i razmatranja iznai smjernice za eventualnu implementaciju razvijenih metoda i spoznaja u modelu ra unalne podrake planiranju i izvoenju konstrukcijskog procesa. U svakodnevnoj terminologiji planiranje zna i odlu ivanje o tijeku djelovanja, prije samog djelovanja (akcije). Za postavljeni (kompletirani) plan mo~e se rei da je to ureena linearna lista operatora koji vode k rjeaenju problema, meutim ciljevi koji se dosti~u primjenom operatora esto imaju hijerarhijsku strukturu. Taj aspekt strukture planova potakao je jednu od najranijih definicija plana prema  REF _Ref409268568 \r \h  \* MERGEFORMAT [89]: Plan je svaki hijerarhijski proces u organizmu koji mo~e kontrolirati redoslijed po kojem treba izvoditi operacije. Pristupi planiranju Pregled dostignua i diskusija prema  REF _Ref409258111 \r \h  \* MERGEFORMAT [88] orijentirani su na temu  planiranje i rjeaavanje problema , s osvrtom na koristi koje donosi primjena planiranja. Kako su ta istra~ivanja ope prirode (neovisna o domeni problema), mo~e se o ekivati da se odreene spoznaje i metode mogu primjeniti i u domeni planiranja rjeaavanja zadatka (i/ili problema) u procesu konstruiranja. Prema  REF _Ref409258111 \r \h  \* MERGEFORMAT [88] mogu se razlu iti etiri razli ita pristupa planiranju: Nehijerarhijski: generira slijed akcija kojima se posti~u ciljevi. Ciljevi se mogu reducirati na jednostavnije ili se mo~e upotrijebiti postupak analize u svrhu reduciranja razlike trenutnog i ~eljenog (ciljnog) stanja prostora planiranja Hijerarhijski: prvo se "skicira" kompletan, ali djelomi no neodreen plan, koji se zatim razrauje do kompletnog slijeda detaljiziranih operatora rjeaavanja problema. Hijerarhijsko planiranje uklju uje definiranje i planiranje u jednom ili viae prostora apstrakcije. Plan se prvo generira u najviaem prostoru apstrakcije. Dobiveni  kostur plana detaljizira se dalje na ni~im nivoima apstrakcije "Script based": koriste se ve postojee skice plana koje se pozivaju iz baze. Apstraktni koraci u planu popunjavaju se operatorima rjeaavanja za konkretni problem. Ovakav pristup zahtijeva velike koli ine specijalisti kog znanja koje treba koristiti na raznim razinama openitosti (apstrakcije), dok se ne nau odgovarajui operatori za svaki korak odabrane skice plana. Oportunisti ki pristup razvili su supru~nici Hayes-Roth  REF _Ref409268797 \r \h  \* MERGEFORMAT [90] da bi modelirali ljudske sposobnosti planiranja. U tu svrhu upotrijebili su adaptiranu "blackboard" kontrolnu strukturu. "Blackboard" je "mjesto za raa iaavanje" ("clearinghouse") sugestija o koracima (dijelovima) plana, koje daju programi - "specijalisti" za odreene vrste odlu ivanja i postupaka u planiranju. Kontrola procesa u "blackboard" modelu je asinhrona i oportunisti ka: programi, odnosno komponente sustava postavljaju hipoteze bez odreenog redoslijeda, i upotrebljavaju hipoteze ostavljene od drugih programa ako im je to od koristi. Na na in sli an oportunisti kom pristupu, zapravo ovjek planira u "svakodnevnom ~ivotu" - plan ne nastaje odjednom, "iz jednog komada", nego se formiraju "otoci" akcija koji se meusobno povezuju kad se za to uka~e prilika. Oportunisti ki pristup sadr~i i "bottom up" komponentu, zbog mogunosti implementiranja detaljiziranih akcija u plan koji se razvija. To je u suprotnosti sa "top-down" procesom razrade koji karakterizira hijerarhijsko planiranje, gdje se odluke na ni~im (detaljnim) nivoima ne donose do zadnjeg mogueg trenutka u tijeku razvoja plana. Slijedea bitna razlika ovog i ostala tri pristupa je u tome da mo~e razviti "otoke" - dijelove plana nezavisno, dok hijerarhijski pristupi nastoje razviti cijeli plan na svakom od nivoa apstrakcije. U svakom slu aju, ljudske sposobnosti planiranja daleko su sofisticiranije od bilo kojeg od navedenih pristupa planiranju u podru ju Umjetne inteligencije, ali im se oportunisti ki pristup kao model najviae pribli~ava. Pretra~ivanje i problem interakcije podproblema Potrebno je joa razmotriti dva problema koja su usko vezana uz temu poglavlja o metodama i tehnikama planiranja. To je problem ograni avanja pretra~ivanja i problem interakcije podproblema. Problemi s ograni enjem pretra~ivanja nastaju kad treba pronai ispravan redoslijed i korake koji dovode do rjeaenja, a postoji ogroman broj moguih putanja od kojih veina ne vodi k cilju. Tada nastaje tzv. kombinatori ka eksplozija jer broj kombinacija operatora raste eksponencijalno s brojem operatora. Problem interakcije podproblema javlja se uvijek kad problem ima "spregnute (vezane) ciljeve", tj. vie od jednog uvjeta koji mora biti zadovoljen. Poredak u kojem spregnuti ciljevi trebaju biti postignuti obi no nije definiran problemom, ali mo~e biti kriti an za pronala~enje rjeaenja. Mo~e se rei da je to vrlo esto ili gotovo uvijek vrijedi u rjeaavanju konstrukcijskih problema, ako ne za nala~enje jednog od moguih rjeaenja, ali onda svakako za pronala~enje rjeaenja ato bli~e optimalnom. Ponekad je zbog interakcije podproblema i nemogue doi do rjeaenja, npr. ukoliko se spregnuti ciljevi u odreenom redoslijedu meusobno isklju uju. Na~alost kod kompleksnijih problema ta vrsta informacija se na po etku rjeaavanja ne mora odmah nazirati, nego se do njih dolazi zaklju ivanjem tek u tijeku procesa rjeaavanja. Problemi pretra~ivanja i interakcije podproblema su povezani jer dodatno pretra~ivanje u prostoru rjeaenja rezultira iz preuranjenog postavljanja proizvoljnog redoslijeda podciljeva. Ako je redoslijed operatora neispravan (to se zaklju uje tek kad doe do interakcije podproblema), potrebno se vratiti nazad do to ke u planu koja je uzrokovala greaku i promijeniti plan - ato je zapravo daljnje pretra~ivanje u prostoru rjeaavanja. Ukoliko je plan inicijalno loae postavljen i kao takav zahtijeva dosta vraanja i korekcija, to mo~e uzrokovati dodatne troakove. Za interakcije podproblema u podru ju planiranja koristi se i naziv odnosno pojam ograni enja. O ograni enjima mo~emo izvesti zaklju ke i iz po etnih uvjeta problema ako su dani eksplicitno. Okolina (prostor) izvoenja plana U literaturi je objavljen veliki broj radova o kreiranju planova, dok se relativno malo pa~nje posveuje okolini u kojoj se planovi koriste. Naj eae su to za (odreeni) plan standardne okoline. Ovdje pojam standardne okoline treba prvenstveno shvatiti kao stati ne, u smislu nepromjenjivosti situacije u kojoj se plan eksploatira. Ve je re eno da se plan sastoji od niza akcija. Ciljevi su odreeni za svaku akciju, i to svaku zasebno, jednu po jednu. Eksploatacija tako odreenog plana podrazumijeva da se iz stanja zadovoljenih inicijalnih uvjeta, za zadani cilj izvodi plan koji e rezultirati stanjem zadovoljenog cilja. Pri tome okolina ne djeluje na izvoenje plana. Samo u planu unaprijed predviene situacije odreuju na in izvoenja odabranog plana. Plan se mijenja (bira ili odreuje alternativni) samo u situacijama kada postoje smetnje koje onemoguuju izvoenje trenutnog plana. Smetnje su planom nepredviene situacije, tj.  vanjski poremeaji . Smetnje koje tako nastaju tretiraju se u upravlja kim modulima za izvoenje plana kao neo ekivane situacije, tj. slu ajevi kada situacije nisu onakve kakve bi trebale biti. Pri tome upravlja ki moduli realiziranih sustava za izvoenje plana ne razmatraju logi ki karakter smetnji, nego samo konstatiraju da stanje okoline ne odgovara predvienom. Ovakva vrsta plana koji se eksploatira u gotovo stati kim uvjetima ne odgovara osnovnim zahtjevima procesa konstruiranja. Realni proces konstruiranja se mora tretirati kao dinami ka pojava. Situacije se tijekom odvijanja procesa mogu mijenjati. Pri tome uzrok promjene ne mora biti izazvan isklju ivo odvijanjem neke od akcija plana. Takoer razlozi za promjenu plana (pa i prekid izvoenja) mogu biti uzrokovani nekom od akcija. Dinami ke promjene u procesu konstruiranja mogu se svrstati u interne i eksterne. Pod internim promjenama podrazumijevamo promjene koje su uzrokovane akcijama plana konstruiranja. Eksternim promjenama nazivamo promjene bilo kojih parametara procesa konstruiranja koje nisu uzrokovane planom. Redoslijed izvoenja planiranih akcija odnosno promjena plana uzrokovani su dakle promjenama situacije. Dinami ke promjene okoline (u skladu s prijaanjim izlaganjima to su promjene o ekivane situacije pri izvoenju plana) tijekom konstruiranja stalno su prisutne. Naime, konvencionalne akcije procesa konstruiranja su tako strukturirane da efekti pojedine akcije vrlo rijetko imaju utjecaj na samo jednu, slijednu akciju. eae efekti pojedine akcije uti u na vei broj parametara konstrukcije, koji su preduvjeti ostalih akcija pa tako u opem slu aju mogu utjecati i na promjenu situacije. Kao poseban problem prikaza konstrukcijskog procesa planom predstavlja se recepcija (, a potom i zadovoljenje) razli itih spregnutih ciljeva (zahtjeva u konstrukcijskoj terminologiji) koji mogu proizai tijekom rada. Drugim rije ima radi se o interakciji podproblema (razmatranoj u prethodnom poglavlju). Takovi se ciljevi ne moraju pojavljivati u  lijepom sekvencijalnom na inu, ato uzrokuje potrebu za odreivanjem redoslijeda i prioriteta rjeaavanja ciljeva. Takvi slu ajevi predstavljaju dinami ku promjenu situacije koja nije izazvana vanjskom smetnjom. Meutim, (kao da i do sada navedeno nije dovoljno !) realne okoline mogu se mijenjati i na taj na in da ne  ruae izvoeni plan, nego da naprotiv,  REF _Ref409270393 \r \h  \* MERGEFORMAT [53] nude nove mogunosti izvoenja akcija, odnosno rjeaavanja. Ako se osvrnemo na sve navedene probleme, mo~e se postaviti pitanje da li postavljanje i koriatenje plana u djelatnosti kao ato je konstruiranje uope ima smisla. Mialjenje je autora ovog rada da koriatenje plana u svakom slu aju mo~e prvenstveno poslu~iti kao temelj integracije toka podataka izmeu raznorodnih aplikacija i kao temelj unapreenja organizacije procesa konstruiranja. Efekti primjene bili bi zna ajniji u okolinama gdje prevladava timski rad i gdje se uvodi paralelno in~enjerstvo (concurrent engineering). Pri tome se "plan" tretira kao metoda prikaza tijeka procesa koja ima samo ograni ene mogunosti rjeaavanja nepredvienih situacija. Takva upotreba plana trebala bi za odreene klase zadataka konstruktora osloboditi jednog dijela rutinskih aktivnosti, odnosno omoguiti mu da efikasnije i sistemati nije koristi raspolo~ive programske alate (uklju ujui i konvencionalne CAD sustave). Na temelju programskog okru~enja za eksploataciju definiranih  prototipnih planova mogli bi se dalje graditi  inteligentniji alati kojima bi se barem djelomi no (za odreene klase i domene zadataka) rjeaavali problemi razmatrani u ovom poglavlju. Uz prije navedeno joa e se naglasiti da koncepcija sustava nee biti postavljena tako da se planovi kreiraju ra unalnim modelima (odnosno  automatski ), nego je zamialjanje i kontrola procesa generiranja plana u potpunosti prepuatena ovjeku ije su sposobnosti planiranja daleko sofisticiranije. To zna i da bi tako generirani planovi (ovisno o iskustvu i umjeanosti konstruktora) trebali djelomi no izbjei ili barem ubla~iti navedene probleme dinami kog prostora izvoenja. Pri tome alat za generiranje plana konstruktoru treba poslu~iti kao sredstvo za efikasnu obradu velikih koli ina podataka i kao sredstvo koje e u tijeku procesa generiranja u najveoj moguoj mjeri otklanjati, odnosno spre avati mogue greake. Topologija prikaza akcija u procesu konstruiranja U prethodnim izlaganjima razmotrene su zna ajke procesa konstruiranja i navedene neke smjernice modeliranja ra unalne podrake procesu konstruiranja. Ovdje emo ponovo naglasiti da u podru ju Znanosti o konstruiranju ne postoji usaglaaena metoda prikaza tijeka procesa konstruiranja. Proces konstruiranja promatran kao rjeaavanje zadatka i/ili problema mo~e se prikazati prostorom stanja,  REF _Ref409269858 \r \h [46],  REF _Ref409269114 \r \h [91], gdje svako od moguih stanja odgovara ili parcijalnom ili kona nom rjeaenju. Na taj na in konstruiranje mo~emo promatrati kao niz akcija koje vode od inicijalnog stanja (definicije zadatka) do kona nog stanja (rjeaenja). U prethodnim razmatranjima zaklju eno je da sustav za ra unalnu podraku planiranju i izvoenju procesa konstruiranja treba modelirati tako da ne ovisi o vrsti konstrukcijskog zadatka, a isto tako niti o fazi procesa konstruiranja u kojoj se primjenjuje. Ponovo emo napomenuti da nije nu~no koncipirati model sustava s o ekivanjima da bi se trebao koristiti na viaim razinama apstrakcije zadatka, odnosno prostor stanja u kojem se izvode akcije mo~e biti neki od moguih podskupova cjelokupnog skupa informacija o proizvodu. Tako poopeni proces mo~e se opisati kao djelatnost koja se sastoji od niza akcija i njihovih meusobnih relacija. Svaka od akcija vrai pretvorbu informacija, tj. na temelju skupa ulaznih informacija generira skup izlaznih informacija. Akcije su etape unutar procesa, a grani na stanja etapa (odnosno meustanja) mo~emo zamisliti kao prostor stanja procesa. Topologiju tog prostora (odnosno topologiju akcija) mo~emo prikazati na najmanje tri na ina: linearnim prostorom (tj. etape su meusobno linearno povezane), ato zna i da je tijek procesa isklju ivo linearan (slika 13a) hijerarhijskim stablom, ato zna i da u procesu konstruiranja postoje grananja, ali da promjene u jednom voru ne uti u na stanje vorova drugih grana (slika 13b) mre~om - koja je openitiji prikaz od stabla, a u stvari omoguuje bolji opis strukture i tijeka procesa konstruiranja jer pojedini vor mo~e biti referenciran iz viae prethodnika, a mogu se i definirati meurelacije izmeu vorova razli itih grana (slika 13c).  INCLUDEPICTURE "linkane slike\\des proc topologije.wmf" \* MERGEFORMAT \d  a (linearna) b (hijerar. stablo) c (mre~a) Slika  SEQ Slika \* ARABIC 13: Tri topologije prikaza akcija u procesu konstruiranja Sve tri razmatrane topologije akcija prikazane su usmjerenim grafovima. Definicija grafa prema  REF _Ref409400416 \r \h  \* MERGEFORMAT [92]: Graf G sadr~i dva kona na skupa: skup to aka V, koje nazivamo vorovima, i skup linija povezivanja E, koje nazivamo bridovima. Pri tome svaki brid povezuje dva vora. G = (V, E) Definicija usmjerenog grafa prema  REF _Ref409400416 \r \h  \* MERGEFORMAT [92]: Usmjereni graf G = (V, E) je graf u kojem svaki brid e = (i,j) ima smjer od "inicijalne to ke" ( vora) do "terminalne to ke" ( vora). Pod uvjetom da su suprotnih smjerova, u usmjerenom grafu mogu postojati dva brida koja povezuju iste vorove. Ako koristimo usmjereni graf kao prikaz topologije akcija u procesu konstruiranja, treba razjasniti interpretaciju takvog prikaza. Za sada emo pretpostaviti da prikaz procesa konstruiranja uvijek treba imati samo jedan "po etni" vor kojeg stavljamo na vrh grafa. (Opi usmjereni graf ne mora imati jedan "po etni" vor.) Linearna lista, hijerarhijsko stablo i mre~a sa jednim po etnim vorom samo su specijalne vrste opeg usmjerenog grafa. Hijerarhijsku mre~u promatramo kao prikaz koji se najviae mo~e pribli~iti realnim zna ajkama procesa konstruiranja. Na vrhu te mre~e su zahtjevi (specifikacije koje ine definiciju zadatka), a krajnji vorovi predstavljaju akcije nakon ijeg izvraavanja stanje u prostoru procesa odgovara nekom od moguih stanja rjeaenja. Meu vorovi predstavljaju meustanja u tijeku odvijanja procesa. Bridovi grafa prikazuju mogue putanje redoslijeda izvraavanja akcija i tokove podataka kroz proces. Bridovi se mogu interpretirati i kao prikaz meusobnog utjecaja podskupova informacija, naime promjena jednog meustanja (u jednom voru) mo~e utjecati na podskupove informacija (atributa) drugih vorova. Sustav za podraku procesu konstruiranja treba koncipirati na slijedei na in: konstruktoru treba omoguiti lagano manevriranje izmeu vorova mre~e u tijeku izvoenja procesa treba omoguiti dodatnu obradu (od strane konstruktora) skupova informacija u svakom voru treba osigurati uvid u trenutno stanje unutar prostora stanja rjeaavanja zadatka Prethodna istra~ivanja unutar projekta "Model inteligentnog CAE sustava"  REF _Ref409269474 \r \h  \* MERGEFORMAT [7],  REF _Ref409257866 \r \h  \* MERGEFORMAT [5],  REF _Ref409403626 \r \h  \* MERGEFORMAT [93], oslanjala su se na prikaz procesa konstruiranja u obliku hijerarhijskog stabla. Meutim, iako je topologija prostora stanja konstrukcijskog procesa zapisana u obliku stabla, u tijeku izvoenja programskog sustava omogueno je da se takav zapis eksploatira u obliku hijerarhijske mre~e (slika 14), jer konstruktor mo~e aktivirati vorove i nepredvienim redoslijedom (ne poatujui relacije sljednik-prethodnik). U tom slu aju program za kontrolu izvoenja plana procesa konstruiranja ne obrauje informacije temeljem meurelacija izmeu vorova, pa konstruktor mora sam obaviti takovu eventualnu dodatnu obradu. Ovakav na in modeliranja procesa konstruiranja odabran je jer je u po etnoj fazi razvoja sustava zaklju eno da su algoritmi kontrole hijerarhijske mre~e isuviae slo~eni da bi se mogli odmah implementirati. Stoga je nastavak istra~ivanja u ovom radu usmjeren na objektno orijentiranu metodologiju modeliranja, jer se pretpostavlja da e njene prednosti omoguiti realizaciju, nadogradnju i odr~avanje mre~nog modela.  INCLUDEPICTURE "linkane slike\\sekvenc prekidano .wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 14: Izvoenje po predvienim i nepredvienim putanjama Razmotrimo joa mogunosti prikaza iterativnosti procesa konstruiranja i uplive na ina odlu ivanja na modeliranje prikaza procesa. Iterativnost i strategiju odlu ivanja mo~emo nazna iti kao zna ajke procesa rjeaavanja konstruktorskog zadatka koje u velikoj mjeri ovise o odabranoj metodi rjeaavanja zadatka, kao i o znanju, iskustvu i individualnim sposobnostima konstruktora. Proces iteracije nema smisla prikazivati stablom, jer se ne mo~e unaprijed odrediti broj ponavljanja. Iteracija se mo~e simulirati prekidanim na inom rada, ali tada treba pri kreiranju plana voditi ra una o skupovima ulaznih i izlaznih atributa vorova, odnosno treba ih strukturirati prema o ekivanoj putanji kretanja kroz vorove u tijeku iteracije. Ukoliko se u tijeku izvoenja poka~e potreba za kretanjem nepredvienim putanjama, vrlo je vjerojatno da e se pojavljivati situacije u kojima nisu odreene vrijednosti svih potrebnih ulaznih atributa vorova, ato e dodatno usporavati proces izvoenja. Odluke koje se donose u vorovima s viae od jednog sljedbenika imaju najvei upliv na strukturu prikaza procesa. Odluke mogu biti npr. tipa  uvjet zadovoljen ili  uvjet nije zadovoljen - koje bi generirale strukturu binarnog stabla. Odluke tipa izbora izmeu viae mogunosti mogu uzrokovati divergiranje stabla plana u airinu. Naime, nakon izbora izmeu npr. moguih varijanti nekog dijela ili sklopa, daljnji proces mo~e biti potpuno jednak, neovisno o odabranoj varijanti. To zna i da bi se isti skupovi vorova ponavljali u svakoj grani, a ako bi bilo viae vorova s takovim odlukama, prikaz (plan procesa) bi divergirao u airinu i postao bi glomazan, s velikom redundancijom podataka (slika 15). To odmah implicira i viae mogunosti za pravljenje semanti kih greaaka, nepreglednost i te~e odr~avanje plana, du~i proces prevoenja i vee zahtjeve za memorijom u tijeku izvoenja, te prostorom za spremanje zapisa plana na disku. S druge pak strane, ako se veina ili sva "grananja" i odlu ivanja obavljaju unutar operacija odreenog vora, prikaz procesa tada poprima strukturu linearne liste.  INCLUDEPICTURE "linkane slike\\widen.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 15: Redundantni zapisi u hijerarhijskom stablu Prethodna razmatranja doprinose zaklju ku da je nu~no razviti model prikaza procesa u obliku mre~ne topologije  REF _Ref409407742 \r \h [94],  REF _Ref409269300 \r \h [95]. Koriatenjem objektne metodologije svaki vor i svaki brid grafa bi trebalo modelirati kao objekte. Enkapsulacija svojstava i ponaaanja (operacija), te klasifikacija vorova i bridova trebala bi omoguiti realizaciju algoritama za kontrolu procesa prikazanog mre~nom topologijom. Matri ni prikaz grafova vorovi grafa obi no se ozna avaju s v1, v2, & . ili jednostavno brojevima, a bridovi s e1, e2, & . ili s njihove dvije krajnje to ke ( vora) npr: e1= (1,4), e2=(1,2) Brid (vi, vj) je svojstven (upadan, zavisan, eng. "incident") voru vi (vrhu); isto vrijedi za vj. Broj bridova svojstvenih voru v naziva se stupanj vora v. Dva vora nazivamo susjednim (eng. "adjacent") vorovima grafa ako su povezani bridom, odnosno ako ine dvije krajnje to ke brida. Za ra unalni prikaz grafova najpogodnije je koristiti matrice, pa slijedi prikaz nekoliko oblika matri nih prikaza grafova. Definicija matrice susjedstva (adjacency matrix) grafa G:  EMBED Equation.3  Matrica susjedstva opeg grafa je simetri na. Za prikaz procesa konstruiranja svakako je prikladnije koristiti usmjereni graf. Element matrice susjedstva usmjerenog grafa, aij = 1, onda kad postoji usmjereni brid (od vora i prema voru j). Matrica susjedstva usmjerenog grafa nije simetri na. Na slici 16 prikazan je primjer usmjerenog grafa i po etni dio pripadajue matrice susjedstva. Radi bolje preglednosti nule su izostavljene. prema voru:R112345678& odR1111 vora:112131141151611718& . Slika  SEQ Slika \* ARABIC 16: Usmjereni graf i dio njegove matrice susjedstva Definicija matrice incidencije grafa G:  EMBED Equation.3   GRANA:12345678 VOR:111-12-1113-11-114-115-1-116-1& . Slika  SEQ Slika \* ARABIC 17: Primjer usmjerenog grafa i pripadajue matrice incidencije Matrica susjedstva openito je mnogo manja od matrice incidencije, pa se stoga prete~no upotrebljava za ra unalni prikaz i spremanje grafa. Maksimalni mogui broj bridova u grafu iznosi: n(n-1)/2, gdje je n broj vorova grafa. Matri ni prikazi nisu efikasni za grafove koji imaju mali broj bridova u odnosu na maksimalni mogui broj bridova. U takvim slu ajevima obi no se koriste liste vorova i liste bridova s kojima se lakae i br~e manupilira nego s matricama. Primjer takvih listi prikazan je u tablici 1. vorvezani bridovibridkrajnje to ke11, 2, 811, 221, 3, 421, 332, 5, 6, 732, 443, 842, 554, 5, 653, 56765, 373, 684, 1Tablica  SEQ Tablica \* ARABIC 1: Liste vorova i bridova primjera grafa sa slike 17 Metode prikaza procesa U prethodnim razmatranjima topologije prikaza akcija u procesu konstruiranja, za sam prikaz procesa koriaten je graf, odnosno vorovi i njihove veze (bridovi). Openiti graf ima mre~nu strukturu, dok su linearna lista i hijerarhijsko stablo samo specijalni oblici (slu ajevi). Opi grafovi koriste se kao metode prikaza u raznim podru jima - ekonomiji, za prikaz elektri nih mre~a, molekularnih struktura, organizacijskih struktura, itd. Osim grafova, razvijeno je joa mnogo metoda prikaza procesa (od kojih se neke temelje na grafovima). Metode prikaza procesa (openite i specifi ne namjene) predmet su mnogih istra~ivanja. Ameri ki nacionalni institut za standarde i tehnologiju (NIST) nastoji razviti openiti jezik za prikaz procesa (Unified process specification language) koji bi trebao postati standardom. U tom projektu krenuli su s analizom prednosti i nedostataka postojeih metoda prikaza procesa. Zaklju eno je da niti jedna od postojeih metoda ne mo~e ispuniti sve zahtjeve openitog prikaza. Stoga nastoje analizirati prednosti pojedinih metoda u odreenim domenama, te kombiniranjem karakteristika i elemenata viae metoda doi do osnovnih koncepata openitog jezika za prikaz procesa. Prema  REF _Ref409142339 \r \h [12] analizirano je 26 metoda prikaza procesa, odnosno njihova primjenjivost za odreeni skup zahtjeva. Analiza je takoer pokazala da se neke osnovne metode i elementi prikaza koriste u svim analiziranim prikazima procesa. U dosta slu ajeva analiziranih 26 metoda koriste se kombinacije pet osnovnih metoda prikaza: AND/OR grafovi dijagrami toka podataka (data flow diagrams) usmjereni grafovi (directed graphs) dijagrami tranzicije stanja (state transition diagrams) strukture stabla Druga faza analize u projektu prema  REF _Ref409142339 \r \h [12] uklju uje odreivanje koje metode su pogodne za odreene vrste zahtjeva pri prikazu procesa. Razraena je klasifikacija na temelju zna ajki koje opisuju prikaze. Navesti emo neke od tih zna ajki metoda prikaza procesa: - temeljene na ograni enjima, temeljene na "EXPRESS-u", fokusirane na cilj, grafi ke, temeljene na grafovima, hijerarhijske, usredoto ene na znanje, logi ki orijentirane, objektno orijentirane, proceduralne, usredoto ene na proces, usredoto ene na stanja. Na primjer za opis metode AP213 vrijede zna ajke da je temeljena na "EXPRESS-u", usredoto ena na proces, objektno orijentirana i tekstualna. U slijedeoj fazi istra~ivanja prema  REF _Ref409142339 \r \h [12] nastojati e se kombiniranjem i spajanjem karaketristika i elemenata analiziranih postojeih metoda prikaza procesa doi do openitog modela koji bi se mogao standardizirati. Iz razmatranja o metodama prikaza procesa mo~e se zaklju iti da objektni model procesa konstruiranja treba koncipirati tako da u po etnoj fazi sadr~i jednu od metoda prikaza procesa, ali da treba ostati otvoren i za daljnje modifikacije te metode kao i za implementaciju drugih metoda. Objektno orijentirani pristup modeliranju i programiranju Temeljna je ideja (princip) objektno orijentiranog programiranja: modelirati aplikaciju kao skup objekata koji komuniciraju da bi postigli zajedni ki cilj. Va~no je naglasiti da se objektno orijentirano programiranje ne bavi programiranjem u smislu razvoja algoritama i struktura podataka, nego ga treba promatrati kao skup sredstava za organiziranje programa, odnosno openitije kao tehnike za koncipiranje programa  REF _Ref409231419 \r \h [96]. Osnovna sredstva strukturiranja programa su objekti. Objekti modeliraju entitete iz stvarnog svijeta, mogu obuhvaati apstrakcije kompleksnih fenomena ili mogu reprezentirati elemente programskog sustava (npr. stogove ili upravljanje grafi kim prikazom). Operacijski gledano, objekti kontroliraju ra unalni proces. Iz perspektive razvoja programa, najva~nija karakteristika objekata nije njihovo ponaaanje kao takvo, nego injenica da se ponaaanje objekta mo~e opisati apstraktnom karakterizacijom njegova su elja. Takva apstraktna karakterizacija dovoljna je za po etno koncipiranje sustava. Stvarno ponaaanje objekta mo~e se implementirati i doraditi kasnije, prema potrebama. Vjerojatno najva~niji doprinos objektne orijentacije programerskoj praksi je upotreba nasljeivanja pri odreivanju relacija izmeu objekata, odnosno klasa objekata. Nasljeivanje omoguuje inkrementalno dodavanje funkcionalnosti (specifikaciji). Na taj na in osigurano je bolje konceptualno modeliranje - mogu se izvui zajedni ki dijelovi specifikacije i omoguena je ponovna upotrebljivost specifikacije. Ako se (disciplinirano) primjenjuje na odgovarajui na in, nasljeivanje omoguuje postupan razvoj specifikacije tipa klase objekata. Razli iti objekti razli itih tipova mogu se promatrati kao elementi zajedni kog "super" tipa. Modeliranje objektima Objektna orijentacija promatra ra unalni program kao skup objekata, gdje svaki objekt modelira entitet ili dogaaj iz aplikacijskog problema (domene). Svi objekti rade (funkcioniraju) zajedno da bi postigli cilj zadatka postavljenog cjelokupnom sustavu. Sredianji programski (softverski) koncept je "objekt". Objekt obuhvaa identitet, strukturu i ponaaanje aplikacijskih entiteta koje reprezentira (modelira, prikazuje). U stvarnom svijetu mnogi objekti su sli ni - imaju zajedni ka svojstva i ponaaanje. Ipak, svaki objekt ima svoj identitet i svoje jednistvene vrijednosti (unutar) zajedni kih svojstava. Unato  jednistvenosti identiteta i vrijednosti svakog objekta, smislenije je opisivati objekte u grupama. Objektno orijentirani program opisuje objekte koji se pojavljuju u aplikaciji - to ini sa klasama ije instance su objekti. Dakle "objekt" je programski (softverski) koncept koji modelira aplikacijski entitet. "Klasa" je programski (softverski) koncept koji opisuje skup objekata. Objekti se mogu usporediti sa varijablama u tradicionalnim programskim jezicima. Ipak, postoji zna ajna razlika izmeu objekta i varijable. Varijabla obuhvaa samo "podatkovni" (informacijski) aspekt objekta (vrijednost), ali ne i ponaaanje. Kombinacija strukture podataka i deklaracije funkcija, zajedno sa sposobnoau da iz sebe kreira instance razli itih identiteta, naziva se klasom u objektno orijentiranim programskim jezicima. Klasa usko povezuje strukture podataka i njima pridru~ene procedure koje ih obrauju. U objektno orijentiranom pristupu naglasak je na modeliranju stvarnosti u domeni problema umjesto stvaranja arhitekture modela sustava koja vodi k implementaciji. Objektna tehnologija razvoja sustava koristi isti model kroz cijeli proces razvoja sustava: zapo eti sa objektno orijentiranom analizom konvertirati rezultate analize u objektne koncepte napisati objektno orijentirane programe Dakle, mo~da najvea prednost objektne tehnologije je u konzistentnosti modela tijekom cijelog procesa razvoja programskog sustava. `to je sustav kompleksniji i vei, ta prednost viae dolazi do izra~aja. Osnovna terminologija Osnovni elementi objekata su atributi i operacije. Prema  REF _Ref409192567 \r \h  \* MERGEFORMAT [97] atribut je informacijski detalj svojstven objektu. Ovisno o konkretnom programskom jeziku, atributi se nazivaju i varijablama ili svojstvenim poljima (member fields). Operacija je funkcionalni detalj svojstven objektu i spremljen kao dio objekta. Za operacije se koriste i nazivi svojstvena funkcija (member function) ili metoda. Pri modeliranju sustava korisno je prikazivati objekte i klase pomou dijagrama. Dijagram objekta naglaaava objekt kao neato ato ograni ava svoju "unutraanjost" i komunicira sa "vanjskim svijetom" (slika 18).  INCLUDEPICTURE "linkane slike\\Ege 1_1.wmf" \* MERGEFORMAT \d   INCLUDEPICTURE "linkane slike\\enkapsulacija.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 18: Dijagram objekta prema  REF _Ref409192567 \r \h  \* MERGEFORMAT [97] Slika  SEQ Slika \* ARABIC 19: Zone pristupa objektu (prema  REF _Ref409192567 \r \h  \* MERGEFORMAT [97]) Svi atributi i operacije koji su potpuno unutar objekta, skriveni su od vanjskog svijeta, odnosno oni su "u ahureni" (eng. encapsulated). Ostali objekti nemaju pristup do njih. Atributi i operacije koji djelomi no izlaze iz okvira objekta pristupa ni su "vanjskom svijetu" i oni ine su elje objekta. Razlikujemo dva na ina pristupa (slika 19) - pristup od strane klijenata (objekata koji nisu hijerarhijski povezani s objektom kojem se pristupa) i pristup od strane podklasa iz hijerarhije klasa kojoj pripada objekt. Prema  REF _Ref409231419 \r \h [96] enkapsulacija promovira modularnost, tj. objekti se moraju promatrati kao blokovi za gradnju kompleksnog sustava. Kad se jednom dostigne odgovarajua modularizacija, mogue je odgoditi kona ne odluke o implementaciji. To svojstvo omoguuje brzu izradu prototipa modela. Enkapsulacija omoguuje separaciju procesa kreiranja klase na faze specifikacije i implementacije. Specifikaciju mo~e izraditi specijalist za koncipiranje programskih sustava ("software designer"), a implementaciju programer. Klasa opisuje skup entiteta koji imaju zajedni ke temelje koncepta. Objekt je instanca klase, a klase slu~e kao predloaci za kreiranje objekata. Klase imaju ~ivotni ciklus koji dijele sa svojim objektima (slika 20).  INCLUDEPICTURE "linkane slike\\zivotni cilkus klase.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 20: }ivotni ciklus klase i njenih objekata prema  REF _Ref409236024 \r \h [98] Usporedba klasa sa konvencionalnim na inima kategorizacije dovodi do izra~aja pojam hijerarhije klasa (nasljeivanje). "Podklase" su zapravo proairenja i/ili specijalizacije postojeih klasa i nasljeuju njihova svojstva. Objektno orijentirani programski jezici upotrebljavaju klase za kategorizaciju entiteta koji se pojavljuju u aplikacijama. Kad je hijerarhija jednom postavljena, jednostavno se proairuje. Da bi se opisao novi koncept (entitet), nije nu~no opisati sva njegova svojstva. Dovoljno je opisati samo razlike u odnosu na koncept unutar postojee hijerarhije. Klasa opisuje strukture podataka i funkcionalnost svojih instanci. Nema uvijek potrebe da klasa ima instance. Klasa mo~e poslu~iti i kao osnovna klasa hijerarhije koja apstrahira zajedni ka svojstva nekoliko deriviranih klasa. Apstraktna klasa je dakle klasa koja slu~i kao zajedni ka osnovna klasa i nee imati instance. Polimorfizam (viaevrsnost) zna i imati sposobnost preuzeti mnogo varijanti oblika. U objektno orijentiranoj tehnologiji to se odnosi na mogunost entiteta da se u tijeku izvoenja pove~e sa instancama razli itih klasa. U objektno orijentiranim jezicima mogu se razlu iti dva oblika polimorfizma - inkluzijski i operacijski. Polimorfizam, u kombinaciji sa dinami kim povezivanjem (dynamic binding) omoguava gradnju fleksibilnih sustava koje je lakae proairivati. Dinami ko povezivanje je mogunost da se objekt pove~e sa akcijom (operacijom) tek u tijeku izvoenja programa. Drugim rije ima dinami ko povezivanje odla~e povezivanje poziva funkcije i ciljnog bloka programskog koda do trenutka izvoenja programa. Kompozitni objekt je agregacija drugih objekata, odnosno sadr~i kompoziciju ili agregaciju drugih objekata kao podobjekata u svojoj implementaciji. Takvi podobjekti mogu biti instance klasa koje predstavljaju entitete, ili mogu i sami biti kompozitni objekti. Na taj na in mo~e se kreirati viaerazinska hijerarhija sadr~avanja (uklju ivanja) objekata. Kompozitni objekt upravlja postojanjem i meuzavisnostima svojih podobjekata, odnosno upravlja skupovima instanci podobjekata. Razvoj metoda modeliranja objektno orijentiranih programskih sustava Prvi problem s kojim se suo avaju programeri koji razvijaju sustave koriatenjem objektnih tehnologija jest izbor odgovarajue metodologije za proces razvoja. Od po etaka razvoja objektnih jezika do devedesetih godina razvijeno je i koriateno mnogo razli itih metodologija, svaka sa svojom varijantom notacije. Od po etnih desetak doalo se do oko 50 metoda koje su koriatene izmeu 1989. i 1994. Te metode neki autori  REF _Ref409236024 \r \h [98] nazivaju metodama prve generacije. Takvo stanje bilo je na neki na in kaoti no, jer niti jedna metoda nije prevladavala niti je mogla zadovoljiti sve zahtjeve iz prakse. Sve su te metode imale neke zajedni ke koncepte, ali izra~ene na razli ite na ine. Takvo stanje ak je i odvraalo od upotrebe objektne tehnologije. Put prema spajanju i unifikaciji metoda po eo je sredinom devedesetih godina, kada se javljaju metode druge generacije. U tom periodu razvija se nekoliko pravaca standardizacije, npr. CORBA, OPEN i UML. U isto vrijeme tri metode se izdvajaju kao najprominentnije: Booch-ova, OMT (Rumbaugh) i OOSE (Jacobson). Spomenuta tri autora spajaju svoje metode i zapo inju razvoj UML-a (Unified Modeling Language), iju prvu verziju prikazuju 1995. OMG (Object Management Group) konzorcij za razvoj programskih sustava preuzima ulogu katalizatora za spajanje svih nastojanja u razvoju i standardizaciji UML-a. Okuplja se veliki broj tvrtki i iskusnih metodi ara, te u srpnju 1997. nastaje prvi prijedlog standarda. Nakon slijedeeg koraka dorade, u studenom 1997. OMG grupa prihvaa UML kao standardni jezik modeliranja. Tako UML postaje temelj za de facto standard u domeni objektno orijentirane analize i koncipiranja  REF _Ref409661447 \r \h [100]. To ne zna i da su sve ostale metode odmah istisnute, ali primjetan je trend sve vee upotrebe UML-a  REF _Ref409236024 \r \h [98]. Unified Modeling Language (UML) UML je, prema definiciji njegovih autora  REF _Ref409667260 \r \h [101], jezik za vizualiziranje, specificiranje, konstruiranje i dokumentiranje rezultata procesa razvoja softvera kao i za modeliranje poslovnog sustava. UML takoer omoguuje pohranu, razmjenu i primjenu znanja u procesima rjeaavanja problema. UML ne propisuje nikakav odreeni pristup rjeaavanju problema, nego se mo~e prilagoditi svakom pristupu. Autori UML-a jasno razdvajaju jezik za modeliranje od razvojnog procesa. Iako e se UML koristiti u sklopu definiranih procesa, pokazuje se da razli ite organizacije, razli iti tipovi projekata i razli ite problemske domene, tra~e i razli ite odgovarajue razvojne procese. Primjerice, razvojni proces prikladan za tvrtku koja proizvodi programe za obradbu teksta za airoko tr~iate ne mo~e biti istovjetan razvojnom procesu za poznatog naru itelja, recimo, u zrakoplovnoj industriji. Meutim, jezik za objektno modeliranje mo~e biti jedinstven. Treba naglasiti i da UML nije samo notacija (na in crtanja pojedinih dijagrama). To je skup koncepata u objektnom modeliranju. Kao i svaki jezik, UML ima definiranu sintaksu (ovdje je to grafi ka notacija i niz pravila vezanih uz dijagrame) i semantiku. Razvoj semantike jezika iziskivao je najviae napora, posebno u usklaivanju postojeih i uvoenju novih koncepata. Trebalo je definirati jezik koji je dovoljno bogat, a istodobno potpuno precizan. Semantika UML-a opisana je i metamodelom u samome UML-u. UML je pogodan za modeliranje irokog spektra programskih sustava, npr. velikih poslovnih informacijskih sustava, distribuiranih Web aplikacija, pa i vrlo kompleksnih sustava realnog vremena. Usporedba UML-a i EXPRESS-a Da bi razjasnili neke mogue nedoumice, u ovoj glavi razmotriti emo neke aspekte primjene UML-a i EXPRESS-a. EXPRESS, kao dio STEP standarda danas je jedan od prevladavajuih jezika modeliranja u podru ju informacijskih sustava za podraku proizvodnji. Moglo bi se stoga postaviti pitanje koji od ta dva jezika pogodnije koristiti pri izradi modela procesa konstruiranja? Koje su prednosti jednog ili drugog u odreenim situacijama i zaato? EXPRESS  REF _Ref409695135 \r \h [102] je dio kompleksnog sustava razvijenog za modeliranje i razmjenu podataka meu razli itim sustavima. STEP (STandard for the Exchange of Product Model Data) neformalno je ime koje se koristi za ISO 10303 Industrial automation systems - Product data representation and exchange standard kojim je opisana problematika oblikovanja i razmjene informacija  REF _Ref409695137 \r \h [103]. Meutim, kako je STEP razvijan prvenstveno kao standard za razmjenu podataka o proizvodu, ne sadr~i nikakve oblike modela procesa konstruiranja  REF _Ref409695139 \r \h [104],  REF _Ref409695140 \r \h [105]. Model procesa konstruiranja trebao bi moi implementirati razvijene informacijske strukture opisa proizvoda iz STEP standarda. Samo je po sebi jasno da informacijske strukture opisa proizvoda trebaju biti jedan od gradbenih elemenata modela procesa konstruiranja, jer su informacije o proizvodu zapravo produkt procesa konstruiranja. Postavlja se sada pitanje na koji na in ostvariti takovu implementaciju (odnosno povezivanje), jer je sasvim vjerojatno da e elementi STEP standarda ui u airoku upotrebu u veini proizvodnih sustava. Vjerojatno najjednostavniji i najprirodniji na in rjeaavanja tog problema je da se informacijske strukture iz STEP standarda tretiraju u modelu procesa konstruiranja kao objekti, odnosno komponente. Navedimo i usporedimo neke zna ajke EXPRESS-a i UML-a bitne za trenutne aspekte razmatranja. EXPRESS je shema konceptualnog jezika, razvijen kao dio PDES/STEP projekta. Njime se specificiraju informacijski zahtjevi gotovo svih dijelova standarda. Slu~i odreivanju objekata koji pripadaju prostoru promatranja, informacijskih jedinica i pravila koja se odnose na te objekte. EXPRESS je u osnovi "Entity-Relationship" orijentiran, no uklju uje i neke elemente objektnih modela. Model entiteti-veze i relacijski model podataka uspjeano se primjenjuju u poslovnim informacijskim sustavima u kojima su podaci razmjerno jednostavnijih tipova. U aplikacijama kao ato je konstruiranje podr~ano ra unalom javlja se potreba za (semanti ki) "bogatijim" tipovima podataka kojih u spomenutim modelima nema. Za razliku od objekata entiteti nemaju opis ponaaanja u samom modelu entiteti-veze. Dakle objekt openito odgovara pojavi entiteta modela entiteti-veze, osim ato dodatno sadr~i i opis svog ponaaanja. Klasa odgovara tipu entiteta, osim ato sadr~i i opis ponaaanja objekata klase. I UML i EXPRESS su samo deklarativni, ali ne i izvrani jezici, pa se prema tome mogu koristiti samo za modeliranje. Izvrani kod se mo~e dobiti generatorima koda, meutim UML sadr~i gotovo sve potrebne specifikacije za izvrani kod ve u samom modelu. Pored toga struktura UML-a odgovara jezicima u koje se prevodi, dok struktura EXPRESS-a nema puno zajedni kog s npr. C programskim jezikom. Dakle pri transformaciji EXPRESS-a dolazi do semanti ke razlike i dobiveni programski kod je teako povezati sa izvornim modelom. UML je semanti ki daleko bogatiji jezik od EXPRESS-a. EXPRESS-G je grafi ka varijanta jezika i sadr~i dijagrame, ali samo strukturalne, a ne i interakcijske i dinami ke. UML je semanti ki bogatiji i od bilo kojeg postojeeg objektno orijentiranog jezika  REF _Ref409667260 \r \h [101]. Iz iznesenog mo~emo zaklju iti da je UML svakako pogodniji i kompletniji jezik za modeliranje ra unalnog sustava podrake procesu konstruiranja. Osnovna razlika ova dva jezika o ituje se u metodologijama. Kompleksnost procesa konstruiranja zahtijeva semanti ki bogatiji jezik i prednosti objektne metodologije. Meutim prednosti razvijenog standarda modeliranja informacija o proizvodu treba svakako iskoristiti u gradnji modela procesa konstruiranja. To zna i da se modeli informacijskih struktura razvijeni u EXPRESS-u trebaju implementirati u strukturu objektnog modela procesa konstruiranja. Zaklju imo dakle, da je mogue i potrebno kombinirati modeliranje pomou oba jezika, s time da se strukture modelirane EXPRESS-om koriste kao podsustavi, odnosno parcijalni modeli (komponente ili podpaketi). Odreeni dijelovi strukture STEP-a (aplikacijskih protokola i integriranih generi kih resursa  REF _Ref409695139 \r \h [104],  REF _Ref409695140 \r \h [105]) mogu poslu~iti i kao polaziata i uzorci za definiranje i koncipiranje gradbenih elemenata modela procesa konstruiranja. Objektne baze podataka Realno je pretpostaviti da e neke od klasa objektnog modela procesa konstruiranja imati veliki broj instanci, odnosno objekata. Vjerojatno je takoer da e u tijeku izvoenja ra unalne podrake procesu konstruiranja prevladavati situacije u kojima veina tih objekata nee biti aktivna, odnosno nee biti potrebe da budu stalno u memoriji. To pogotovo vrijedi za objekte koji nemaju nit kontrole ("thread") u aplikaciji. Veina takvih pasivnih objekata mogla bi se ponovno iskoristiti i u slijedeim varijantama konstrukcije, odnosno novim zadacima. Permanentno spremanje objekata, odnosno koriatenje objektne baze stoga se namee kao osnovna programska platforma implementacije objektnog modela procesa konstruiranja. Objektna baza podataka kombinira semantiku objektno orijentiranog programskog jezika i mehanizme upravljanja i pretra~ivanja podataka konvencionalnih sustava baza podataka. Ako je objektna baza integrirana sa objektnim programskim jezikom, tada treba podr~avati semantiku tog jezika - relacije postavljene u programu trebaju automatski biti prikazane u bazi kada se objekti spreme. Objekti kojima se pristupa u transakcijama kopiraju se ili briu iz memorijskog prostora aplikacije koja vri transakciju. Te operacije nazivaju se aktiviranje i deaktiviranje objekata  REF _Ref409299733 \r \h [99]. Slika 21 prikazuje proces aktiviranja i deaktiviranja objekta u tijeku njegova ~ivotnog ciklusa. Prva aplikacija kreira novi stalni (perzistentni) objekt. Kada aplikacija predaje nit kontrole, objekt se deaktivira i sprema u bazu. Druga aplikacija u itava objekt, odnosno aktivira ga u memoriji. Na kraju transakcije objekt se opet deaktivira i zapisuje u bazu ako je bio modificiran. Trea aplikacija pristupa objektu, aktivira ga i briae. Pri tome se objekt ne deaktivira, niti zapisuje, nego se uklanja iz baze.  INCLUDEPICTURE "linkane slike\\objektna baza 1.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 21: Proces aktiviranja i deaktiviranja objekata, prema  REF _Ref409299733 \r \h [99] Ako se objekt spremi (zapiae) u bazu i nakon toga pro ita, treba se ponaaati kao da nikad nije niti bio spremljen. To zna i da objekt pro itan iz baze mora imati isti identitet, enkapsulaciju, strukturu nasljeivanja, polimorfizam i reference kao originalni objekt  REF _Ref409260045 \r \h [106]. Neki proizvoa i objektnih baza (npr. "POET") tvrde da ispunjavaju takve uvjete. Za verifikaciju mogunosti implementacije predlo~enog objektnog modela procesa konstruiranja odabrana je komercijalna objektna baza "POET". Spomenuti proizvoa  jedan je od nekoliko vrhunskih, a ujedno je i evaluacijska verzija baze i dokumentacije lako dostupna. U osmom poglavlju biti e detaljnije obrazlo~ene neke od metoda i modela implementacije objektne baze koje vrijede konkretno za POET, a ne za objektne baze openito. Tehnologija i metode implementacije objektnih baza joa uvijek se razvijaju i sazrijevaju, tako da se komercijalne implementacije prili no razlikuju u metodici i mogunostima. ODMG organizacija (object data management group) razvija openiti model koji te~i prema standardizaciji, ali joa uvijek postoje velike razlike izmeu razli itih proizvoa a objektnih baza. Npr. prema  REF _Ref409299733 \r \h [99], ODMG standard ne podr~ava spremanje C++ pokaziva a (pointera) kao dijelova objekta, dok POET objektna baza ima razvijen mehanizam njihovog spremanja i ponovnog aktiviranja nakon u itavanja spremljenog objekta. Koncipiranje objektno orijentiranog modela procesa konstruiranja Preslikavanje pojmova realnog svijeta u konceptualni i objektni model U obrazlaganju hipoteze rada, i u prethodnom poglavlju, ve je bilo govora o temeljnim principima u pristupu koncipiranju objektnog modela. Meyer  REF _Ref409262200 \r \h [107] formalno definira objektno orijentirano koncipiranje kao "konstrukciju programskih sustava u obliku strukturiranih skupova (kolekcija) implementacija apstraktnih tipova podataka. Neformalno, definira ga kao "metodu koja vodi do programskih arhitektura temeljenih na objektima kojima manipulira svaki sustav ili podsustav. Objekt se mo~e promatrati kao smislena povezanost odreenog znanja i odreenih operacija. Izgraditi sustav sa objektno orijentiranim pristupom, zna i analizirati problem i pronai objekte uklju ene u sustav. Ope zna ajke i ponaaanje tih objekata modeliraju se i implementiraju kao klase u objektno orijentiranom programskom jeziku. Kada se jednom objekti domene problema modeliraju i kreiraju kao klase, te klase se spajaju zajedno u modeliranju sustava u ra unalnom okviru. Takav "bottom-up" pristup, temeljen na podacima, koristi prijaanje napore kao polugu za kreiranje sustava izgraenih od "gotovih dijelova". Dakle, prvenstveno e se nastojati apstrahirati i definirati pojave i pojmovi koji odreuju konstrukcijski proces, da bi ih se zatim preslikalo u osnovne klase i objekte modela. Koncipiranje objektnog modela procesa konstruiranja mo~e se promatrati kao preslikavanje pojava i pojmova iz domene stvarnog svijeta u entitete u domeni konceptulanog i logi kog svijeta (slika 22). Entiteti konceptualnog i logi kog svijeta preslikavaju se u klase u domeni objektnog modela. Jedna od glavnih prednosti objektnog modeliranja je mogunost poklapanja entiteta i objekata. Prema  REF _Ref409256364 \r \h [108], cilj objektnog modeliranja je "jedan prema jedan" podudaranje izmeu entiteta u konceptualnom i logi kom svijetu i objekata u ra unalnom programu.  INCLUDEPICTURE "linkane slike\\shema preslikavanja.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 22: Apstrahiranje entiteta i njihovo preslikavanje u objektni model Analogna razmatranja modeliranja kao preslikavanja iz domene realnog svijeta u domene fenomenoloakog , informacijskog i ra unalnog modela prikazana su slikom 1. Problematika formiranja modela procesa konstruiranja u konceptualnoj domeni Razmatrajui ope teorije konstruiranja kao mogua polaziata koncipiranja modela, zaklju eno je da niti jedna opa teorija nije dovoljna sama za sebe, niti je pogodna kao osnovno polaziate razvoja modela. Niti jedna od tih teorija ne promatra proces konstruiranja sa svih aspekata i nisu (u potpunosti) orijentirane informati kom modeliranju. Opa teorija konstruiranja (Yoshikawa, Tomiyama) i aksiomatska teorija (Suh) veinom se zadr~avaju na viaim razinama apstrakcije i modeliranja, ne razmatrajui aspekte organizacije timskog rada, odn. suradnje i koordinacije lanova tima (u novije vrijeme time se bave Duffy i Andreasen  REF _Ref409236648 \r \h [109]), na ine dekompozicije i organizacije izvraavanja zadataka, praenje i voenje procesa. Opi model procesa konstruiranja (Hubka) airi je i sveobuhvatniji, ali se osniva na fenomenoloakom opisu, bez egzaktnog aparata. Takvi pristupi prvenstveno nastoje produbiti razumijevanje procesa konstruiranja, ali s druge strane ne daju bitne doprinose unapreenju organizacije procesa i skraivanju rokova u danas prevladavajuim okru~enjima timskog rada. Sve navedeno ne zna i da ope teorije treba u ovom pristupu zanemariti, nego naprotiv treba nastojati kombinirati i koristiti njihove spoznaje kao principe koncipiranja strukture i pojedinih entiteta modela. Cilj pristupa predlo~enog u ovom radu je interpretativni ra unalni model koji bi trebao obuhvatiti ato je mogue viae pojava i pojmova realnih procesa konstruiranja promatranog sa svim su eljima prema cjelokupnom okru~enju proizvodnog procesa. Ponovimo stoga citat Vajne  REF _Ref409238939 \r \h  \* MERGEFORMAT [4] i  REF _Ref409233354 \r \h  \* MERGEFORMAT [75] - ato se danas o ekuje od teorije konstruiranja: da uklju i sve zna ajke cijelog ~ivotnog vijeka proizvoda (razmatranje svih aspekata termina "design for x") da uklju i i podr~i vremenski paralelne procese (istovremeno (paralelno) in~enjerstvo) formalizacija strukture i sadr~aja procesa konstruiranja u modelu procesa za deriviranje i realizaciju funkcija za cjelokupnu ra unalnu podraku Razmotrimo joa neke teme zna ajne za koncipiranje i implementaciju modela procesa konstruiranja. Posljednjih dvadesetak godina nekoliko istra~iva kih timova u USA veliku je pa~nju posvetilo metodama vizualizacije mre~e interakcija konstrukcijskih zadataka i parametara.  REF _Ref409180678 \r \h [110],  REF _Ref409180871 \r \h [111],  REF _Ref409180873 \r \h [112],  REF _Ref409173569 \r \h [113],  REF _Ref409173839 \r \h [114],  REF _Ref409173842 \r \h [115]. Razvijene metode mo~emo promatrati i kao parcijalne modele procesa konstruiranja (parcijalne jer promatraju samo dio informacija i samo odreene aspekte). Nedostatak je navedenih istra~ivanja ato promatraju stati ne prikaze procesa, na kojima nastoje reorganizacijom unaprijediti proces. Meutim stanje u okolini procesa konstruiranja nije stati no - stvaraju se novi resursi, dolazi do organizacijskih promjena i promjena u raspodjeli zadataka. Struktura procesa konstruiranja mo~e se mijenjati ak i u vrijeme trajanja konstruiranja jednog proizvoda, usporedo sa napredovanjem kroz faze procesa  REF _Ref409239013 \r \h [5]. U veini konstrukcijskih ureda postoje propisane procedure "kako se radi", meutim uvijek treba o ekivati da e "ono ato se stvarno dogaa" biti redovito za nijansu druga ije. Prema  REF _Ref409239013 \r \h [5] u tijeku formiranja konkretnog modela mo~e doi do gubitka informacija, tj. u procesu prikazivanja realnog stanja ("kako se ina e radi") (slika23). Ovi problemi e postojati u slu ajevima kada je "snimanje stanja" pri formiranju modela odvojeni proces od stvarne svakodnevne konstruktorske prakse.  INCLUDEPICTURE "linkane slike\\slika 4 iz 230.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 23: Gubitak informacija pri formiranju prikaza konkretnog procesa konstruiranja  REF _Ref409239013 \r \h [5] Jednom formirani ra unalni model procesa konstruiranja biti e kasnije podlo~an stalnom doraivanju i odr~avanju, bilo zbog unapreivanja ili zbog praenja promjena u okolini procesa. Odr~avanje implementiranog modela zahtijevati e i dodatni anga~man konstruktora u odnosu na dotadaanji na in rada. Proces konstruiranja pri modeliranju ne bi trebalo promatrati kao stati nu institucionaliziranu strukturu, nego kao dinami nu mre~u koja nastaje u realnom vremenu usporedo s evoluiranjem konstrukcijskih ciljeva, potreba i prioriteta  REF _Ref409239013 \r \h [5]. Stoga se predla~e koncipirati strukturu modela kao "otvorenu kutiju s objektima". To zna i da treba omoguiti jednostavno dodavanje novih entiteta (klasa) i njihovo semanti ko povezivanje sa postojeima. Pri formiranju modela procesa konstruiranja u konkretnom sustavu koriste se raspolo~ivi entiteti, uz eventualnu prilagodbu i dodavanje novih. Pri tome nije nu~no da se koriste svi entiteti iz modela. Ovakva koncepcija predla~e se stoga jer nije realno za o ekivati da model mo~e biti dovoljno openit da bi obuhvatio sve varijacije situacija u razli itim realnim okru~enjima. Stoga ga treba koncipirati na na in koji bi omoguio implementaciju barem dijela do sada razvijenih metoda za unapreivanje i/ili modeliranje procesa. Realni sustav ije konceptualno modeliranje se razmatra je proces konstruiranja zamialjen u uredu koji koristi ra unalnu opremu u mre~nom okru~enju i u kojem ve postoji iskustvo u koriatenju programskih alata za podraku konstruiranju. Pretpostavlja se da se u procesu koriste CAD paketi, programi za prora une, baze podataka i druge vrste programskih alata. Ulazne informacije u proces konstruiranja su zahtjevi tr~iata, odnosno naru itelja, a skup izlaznih informacija je dokumentacija o konstruiranom proizvodu. Pri modeliranju tako definiranog realnog sustava treba uzeti u obzir i vremenske odnose procesa izrade dokumentacije o proizvodu u odnosu na ugovaranje s naru iocem i po etak izrade proizvoda. U modernim procesima istovremenog in~enjerstva vremenski intervali navedenih procesa esto se preklapaju (slika 24).  INCLUDEPICTURE "linkane slike\\inf model pr konst.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 24: Izrada dokumentacije o proizvodu u odnosu na ugovaranje i izradu proizvoda To zna i da proces izrade dokumentacije zapo inje i prije kona nog potpisa ugovora, a izrada nekih komponenti proizvoda zapo inje i prije nego je dovraena kompletna dokumentacija. Takve situacije nameu dodatne zahtjeve i kompliciraju proces konstruiranja, ali su nu~nost koju diktira tr~iate stalnim skraivanjem rokova izrade proizvoda. esto se po etni zahtjevi promijene (ili se postavljaju dodatni) i nakon zavranog definiranja ugovora. Takve situacije javljaju se ipak samo kod nekih vrsta proizvoda (slo~ena postrojenja i njihove komponente). Ovdje to napominjemo da bi se naglasilo da se proces konstruiranja ne mo~e uvijek promatrati kao proces obrade stati kog skupa inicijalnih zahtjeva, ato je prevladavajui model u Znanosti o konstruiranju. Utjecaj na proces konstruiranja imati e i povratne informacije iz eksploatacije isporu enih varijanti proizvoda. Konceptualni model procesa konstruiranja nastojati e se postaviti tako da ne bi trebao biti ni preskriptivni ni deskriptivni (u smislu klasifikacije prema  REF _Ref409149372 \r \h [17]), nego e se prvenstveno nastojati da bude prilagoen ra unalnoj primjeni. Konstruiranje e se promatrati kao proces transformiranja i generiranja informacija, pretpostavljajui da je velik dio tih informacija zapisan u ra unalnom obliku. Drugim rije ima konstruiranje se promatra kao proces kojem treba modelirati informati ku podraku, preslikavajui uobi ajeni na in rada u domenu objektnog programskog sustava. Na temelju izlo~enog pristupa promatranju i modeliranju realnog sustava predlo~iti e se entiteti koncepualnog i logi kog modela. Pri koncipiranju strukture nastojati e se da model bude dovoljno openit da bude airoko primjenjiv, ali da istovremeno sadr~i dovoljno mogunosti specijalizacije da bi se mogao efikasno prilagoditi specifi nostima konkretne okoline. Najvei dio softverskog tr~iata (pa i objektnih sustava) usmjeren je na razvoj podrake poslovnim procesima. Usporedimo li konceptualno modeliranje poslovnih procesa sa modeliranjem procesa konstruiranja, mo~e se zaklju iti da su poslovni procesi ipak znatno jednostavnije strukture nego proces konstruiranja, za koje je lakae apstrahirati konceptualni model. Pored toga dobar dio transakcija i operacija u poslovnim sustavima strogo je definiran i odreen zakonima i propisima. Za razliku od toga velik dio transakcija u procesu konstruiranja ne mo~e se niti predvidjeti, niti propisati. Konceptualno modeliranje procesa konstruiranja dodatno ote~ava i okolnost da takav model nije u potpunosti sazrio niti usaglaaen niti na razini Znanosti o konstruiranju - odnosno ne postoji jednistven i usaglaaen fenomenoloaki model. Koliko je poznato autoru ovog rada, takva sistematizacija, orijentirana na ra unalnu primjenu, joa nije provedena u Znanosti o konstruiranju. U Znanosti o konstruiranju nedostaje "teorija CAD-a", ato naglaaavaju i Akman, Hagen i Tomiyama  REF _Ref409263479 \r \h  \* MERGEFORMAT [25]. Proces razvoja objektnog modela U ovom poglavlju razmotriti emo proces razvoja modela u objektnoj domeni sa informati kog (programskog) aspekta. Treba napomenuti da konceptualno i informacijsko (objektno) modeliranje ne treba promatrati odvojeno, jer postoji velik broj meusobnih upliva i interakcija. Zapravo se ta dva procesa odvijaju paralelno, u iterativnim ciklusima. Realno je o ekivati da e pristup u kojem e se pojave i pojmovi koji odreuju konstrukcijski proces nastojati apstrahirati i preslikati u objekte, kao rezultat dati opse~an i kompleksan model, odnosno programski sustav. Idealno bi bilo kad bi se preslikavanje iz konceptualne u objektnu domenu realiziralo "jedan za jedan", tj. da svakom entitetu odgovara jedna klasa. Da bi se to ostvarilo, pri formiranju entiteta u konceptualnom modelu treba uzeti u obzir i zahtjeve ra unalne implementacije, tj. voditi ra una o: organizaciji programskog sustava izboru strukturalnih elemenata i njihovih su elja kojima se spajaju u cjelovit sustav ponaaanju elemenata, specificiranom u njihovim interakcijama i kolaboracijama kompoziciji elemenata strukture i ponaaanja u progresivno vee podsustave Ovdje treba naglasiti da je razvoj svih metodologija (pa i objektne) uvijek bio potican najveim dijelom problemima iz domene upravljanja poslovnim sustavima, ato je i razumljivo, jer je taj segment softverskog tr~iata daleko najvei. Makar se smatra da su razvijeni objektni programski jezici ope namjene, ipak bi se moglo rei da izvoriata razvoja imaju svoje uplive na primjenjivost u razli itim domenama. Kvaliteta i primjenjivost (upotrebljivost) informacijskog modela djelomi no proizlazi i iz principa modeliranja, odnosno stilova koriatenih pri kreiranju konceptualnog modela. Jedan od primjera skupa principa modeliranja prema  REF _Ref409266202 \r \h  \* MERGEFORMAT [78], postavio je West  REF _Ref409267515 \r \h  \* MERGEFORMAT [116]. Navedimo neke principe: Entitete je bolje prikazati i nazvati prema njihovoj "prirodi" ("underlaying nature") nego prema ulozi koji imaju u odreenom kontekstu. Sve asocijacije izmeu fizi kih i logi kih objekata trebalo bi prikazati kao entitete radije nego samo kao relacije izmeu objekata. Joa neki interesantni principi modeliranja razmatrani su u "Primitive-Composite" pristupu prema  REF _Ref409267655 \r \h  \* MERGEFORMAT [117]. Entiteti se mogu temeljiti na nekoliko razli itih konceptualnih dekompozicija ("conceptual breakdowns"). Na primjer "konstruktor" se mo~e definirati u smislu svoje uloge kao osobe, zaposlenika, resursa u aktivnosti, fizi kog objekta sa jedinstvenom lokacijom, lana tima, entiteta koji egzistira u nekom stanju, itd. Svaka od tih razli itih klasifikacija mo~e se prikazati upotrebom "primitivnog" objekta. Cjelokupni entitet koji kombinira sve karakteristike primitiva naziva se "kompozitni objekt". Iz te perspektive, nastaje veliki problem za konceptualne modele da unaprijed definiraju sve mogue kombinacije i permutacije svih primitivnih dekompozicija. Proces razvoja slo~enih i sofisticiranih programskih sustava karakteriziran je iterativnoau. Sukcesivna poboljaanja i inkrementalni rast efikasnosti rjeaenja problema odvijaju se kroz nekoliko ciklusa  REF _Ref409667260 \r \h [101]. Kako je ve navedeno, realno je o ekivati da e predlo~eni pristup rezultirati sa vrlo slo~enim i opse~nim modelom programskog sustava. Stoga e se opseg ovog rada ograni iti samo na definiranje i razradu entiteta konceptualnog modela, te na ina njihovog preslikavanja u klase objektnog modela. U objektnom modelu definirati e se struktura klasa, njihovi atributi, operacije i relacije, do razine na kojoj mo~e zapo eti razvoj programskog koda i detalja implementacije. Objektno orijentirani pristup podr~ava apstrakciju na razini objekta. Razvoj sustava mo~e se stoga odvijati na razini objekata ignorirajui ostatak sustava tako dugo dok god je to potrebno, pa nije nu~no obraati pa~nju na razinu implementacije. Cilj tako postavljenog istra~ivanja je stvoriti temelj ("kostur modela") koji e biti dovoljno opisan i dovoljno precizan da bi omoguio daljnji razvoj - eventualno kao polazna to ka ili poticaj za aire usaglaaavanje koncepcije i definicija entiteta ra unalnog modela procesa konstruiranja. Definicije klasa i svi ostali elementi "kostura" objektnog modela zapisati e se u obliku UML modela, koriatenjem programskog paketa "Rational Rose". Implementacija tako zapisanog modela realizirati e se u programskom okru~enju objektne baze. Koncepcija osnovne strukture (arhitekture) sustava Temeljem svih dosadaanjih razmatranja i istra~ivanja predla~e se osnovna shema arhitekture sustava prikazana na slici 25. Prema  REF _Ref409170775 \r \h  \* MERGEFORMAT [118] u dobro koncipiranom modelu, klase trebaju biti uredno biti grupirane u podsustave koji su slabo spregnuti. Veze izmeu klasa iz razli itih podsustava trebaju biti minimizirane. Arhitektura sustava treba sadr~avati ato je mogue viae stablinih apstrakcija, koje treba izolirati od onih za koje je vjerojatnije da e biti podlo~ne promjenama. Vodei se tim principima, predlo~ena arhitektura sustava podijeljena je u etiri osnovne grupe (podsustava) klasa: osnovni gradbeni (strukturalni) elementi elementi prikaza relacija elementi prikaza i kontrole izvoenja procesa konstruiranja "servisne" klase koje realiziraju "ponaaanje" modela, i skup programskih komponenti realizacije sustava  INCLUDEPICTURE "linkane slike\\osnovna struktura sustava.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 25: Shema osnovnih elemenata strukture objektnog modela procesa konstruiranja Predlo~ena arhitektura nastoji implementirati "bottom up" pristup gradnji modela, stoga se prvo polazi od najjednostavnijih entiteta (elemenata) koji e se koristiti kao gradbeni elementi slo~enijih entiteta. Strukturalni (gradbeni) elementi modeliraju osnovne pojmove realnog svijeta odvijanja procesa konstruiranja. Ovdje se predla~e slijedea gruba kategorizacija strukturalnih elemenata na: objekte na kojima se izvodi proces konstruiranja (koji "trpe" sve akcije i operacije): zapisi informacija o proizvodu i logi ki modeli "fizi kih" komponenti proizvoda objekte koji "djeluju" u procesu: konstruktori, programski alati, akcije - kao dalje nedjeljive etape procesa Relacije izmeu entiteta u procesu konstruiranja daleko su slo~enije nego one u npr. poslovnim sustavima. Stoga se pretpostavlja da e neke od slo~enijih zavisnosti biti pogodnije modelirati kao zasebne entitete, jer mehanizmi objektne tehnologije za modeliranje relacija u veini slu ajeva nee biti dovoljni ili pogodni. Elementi prikaza i modeliranja relacija ine stoga posebnu grupu (podsustav) klasa, iji objekti takoer sudjeluju i u gradnji slo~enih entiteta (objekata). Objekti prikaza relacija na razli ite na ine prikazuju relacije izmeu skupova gradbenih elemenata iste klase ili izmeu skupova gradbenih elemenata razli itih klasa. Pri tome objekti prikaza relacija sadr~e skupove referenci na gradbene elemente ije relacije prikazuju. Elementi prikaza i kontrole odvijanja procesa konstruiranja apstrakcije su koje e proizai iz dekompozicije procesa konstruiranja promatranog kao niza akcija pretvorbe informacija. Dakle to e biti prikazi etapa, stanja i situacija u procesu, te mre~e njihovih veza. Elementi prikaza i kontrole procesa koncipirati e se kao slo~eni objekti u koje e se uklju ivati objekti osnovnih gradbenih elemenata na slijedee na ine: referenciranjem, ugraivanjem (kompozitni objekti) i modeliranjem "suradnje" izmeu objekata. Na temelju slo~enih objekata prikaza procesa mogu se dalje graditi modeli odreenih situacija, postupaka i metoda konstruiranja, prilagoeni potrebama konkretnog okru~enja primjene. U navedenom pristupu ogleda se fleksibilnost koncepcije "otvorene kutije s alatima". Prve tri razmatrane grupe klasa modeliraju osnovnu "stati ku" strukturu sustava. Sve klase iz tih grupa imati e skupove instanci koji e svi zajedno tvoriti model procesa konstruiranja. Realno je pretpostaviti da e klase iz prve tri grupe imati veliki broj instanci, stoga je predvieno da se sve njihove instance spremaju u objektnu bazu. Objektna baza predstavlja onda zapis stati ke strukture modela procesa konstruiranja. Takvoj "stati koj" strukturi etvrta grupa ("servisnih" klasa) dodaje "dinami ki" aspekt. Servisne klase sadr~e skupove operacija koje modeliraju ponaaanje sustava u eksploataciji. Primjeri takvih operacija su npr. generiranje plana procesa konstruiranja i izvoenje plana. U etvrtu grupu svrstane su i programske komponente realizacije sustava - skup su elja za komunikaciju s korisnicima sustava, su elja prema postojeim bazama znanja, programsko okru~enje objektne baze, modeli organizacije zapisa i arhiviranja planova, itd. Predvieno je da u etvrtoj grupi klasa budu klase koje sadr~e samo operacije, bez modela struktura podataka. Takve klase nee imati viae instanci, pa se ne spremaju u objektnu bazu. Razrada predlo~ene arhitekture sustava kombinirati e dalje analizu i koncipiranje. Analizom e se nastojati modelirati proces konstruiranja otkrivanjem klasa i objekata koje ine rje nik (vokabular) domene problema. Pri koncipiranju izmialjati e se apstrakcije i mehanizmi koji realiziraju (omoguavaju) ponaaanje koje taj model zahtijeva. Prijedlog entiteta objektnog modela procesa konstruiranja Kako je u prethodnom poglavlju obrazlo~eno, u razradi objektnog modela procesa konstruiranja entiteti su svrstani u etiri grupe (tablica 2): osnovni gradbeni (strukturalni) elementi elementi prikaza relacija elementi prikaza i kontrole izvoenja procesa konstruiranja programske komponente realizacije sustava i "servisne" klase koje realiziraju "ponaaanje" modela GRADBENI ELEMENTIZAPISI RELACIJA IZMEU OBJEKATA ILI ATRIBUTAPRIKAZ I IZVOENJE PROCESAKOMPONENTE REALIZACIJE parametar baza parametara objekt prikaza proizvoda objekt strukture proizvoda akcija su elje programskog alata zadatak konstruktorzavisnosti parametara zavisnosti konstrukcijskih zadataka relacije pripadnosti izmeu razli itih klasa objekata izrazi - relacije izmeu atributa objekata ograni enja - relacije parametara i funkcionalnih zahtjeva pravila odlu ivanja - relacije izmeu uvjeta i akcijaplan konstruiranja vor plana konstruiranja matrica prikaza veza izmeu vorova plana zapis tijeka izvoenja procesa konstruiranja zapis stanja procesa u izvoenju postupak kreiranja plana postupak izvoenja plana nacrt plana konstruiranja"servisne" klase - kreiranje i izvoenje plana rje nik objektne baze objektna baza sa strukturom plana konstruiranja arhiva kreiranih planova arhiva izvedenih planova su elja prema bazama znanja i bazama podataka baza znanja o programskim alatima sustavaTablica  SEQ Tablica \* ARABIC 2: Entiteti i komponente objektnog modela procesa konstruiranja U ovom poglavlju dane su definicije i prikazi predlo~enih entiteta unutar svake od navedenih grupa, ato mo~emo promatrati kao detaljnu razradu konceptualnog modela sustava. U danim prikazima razmatrano je i preslikavanje predlo~enih entiteta u klase objektnog modela. Sve klase objektnog modela imaju iste nazive kao i entiteti konceptualnog modela. Detaljnija razrada implementacije i realizacije entiteta kao strukture klasa i relacija u konkretnom objektnom modelu (programskom sustavu) razraena je u osmom poglavlju. Strukturalni (gradbeni) elementi Parametar konstrukcije Promatrajui proces konstruiranja kao proces transformacije i generiranja informacija mo~e se smatrati da je podatak, odnosno u ra unalnom modelu varijabla, temeljna i nedjeljiva jedinica informacije. Varijabla dakle predstavlja najjednostavniji entitet u modelu procesa konstruiranja. Varijable e se u predlo~enom modelu nazivati "parametri konstrukcije", ato je naj eai naziv u literaturi (npr.  REF _Ref409180678 \r \h [110],  REF _Ref409158676 \r \h [119],  REF _Ref409241353 \r \h [120] ). Parametri konstrukcije promatrati e se kao osnovne jedinice zapisa informacija o proizvodu koji se konstruira. Vrijednosti parametara odreuju se u tijeku procesa konstruiranja, ali vrijednost parametra mo~e biti poznata ve i na po etku procesa konstruiranja ako se radi o podacima iz liste zahtjeva ili o nekom podatku varijantne konstrukcije. U objektnom modelu parametri se mogu modelirati kao atributi objekata ili kao zasebni objekti. Razmatrajui zna ajke procesa konstruiranja, posebno u timskom okru~enju, mo~e se uo iti potreba za joa nekim elementima u sintaksi parametra osim samog zapisa vrijednosti podatka - kao npr. "status vrijednosti", fizikalna jedinica i hiperveza na zapis relevantnog znanja o parametru. U takvom pristupu parametar se ne mo~e modelirati kao jedan atribut objekta, nego eventualno kao skup (struktura) povezanih atributa. Odmah se namee zaklju ak da je, slijedei principe objektnog modeliranja, pogodnije onda parametre modelirati kao objekte koji e enkapsulirati takve skupove atributa. Entitet "parametar konstrukcije", preslikan na objekt u modelu procesa konstruiranja enkapsulira: zapis vrijednosti podatka o proizvodu, status vrijednosti (koji se mijenja u izvoenju procesa konstruiranja), reference na dodatne opise - znanja o procesu konstruiranja i proizvodu, zapise "namjera" konstruktora - prijedloge, argumente i pretpostavke. Mo~e se rei i da objekt "parametar konstrukcije" modelira "~ivotni ciklus" i zapis znanja o podatku konstrukcije. Parametri kao objekti sadr~e slijedei skup atributa: P = {n, a, v, s, f, h}, pri emu je: n ::= naziv a ::= adresa u bazi parametara v ::= vrijednost s ::= status vrijednosti f ::= fizikalna jedinica h ::= hiperveza na opis parametra i zapis relevantnog znanja Pri tome v poprima to no jednu vrijednost iz skupa moguih stanja V: v ( V, gdje je V = {v1, v2, v3} v1 ::= zapisana je jedna vrijednost v2 ::= zapisana je donja i gornja granica kontinuiranog intervala unutar kojeg je vrijednost v3 ::= zapisan je niz (polje) diskretnih vrijednosti Isto tako s poprima to no jednu vrijednost iz skupa moguih stanja S: s ( S, gdje je S = {s1, s2, s3, s4, s5} s1 ::= vrijednost je odreena, ali joa se mo~e mijenjati s2 ::= vrijednost odreena, i ne mo~e se viae mijenjati s3 ::= pretpostavljena jedna vrijednost s4 ::= vrijednost je pretpostavljena unutar kontinuiranog intervala s5 ::= vrijednost je pretpostavljena kao jedna od vrijednosti iz niza diskretnih vrijednosti Dozvoljene kombinacije vrijednosti s i v podskup su kartezijevog produkta skupova njihovih moguih stanja: K = {(v1,s1), (v1,s2), (v1,s3), (v2,s1), (v2,s4), (v3,s5)}, K ( V x S Implementacija kontrole razli itih kombinacija s i v mo~e se rijeaiti sa razli itim klasama parametra ili sa kontrolnom procedurom implementiranom u generiranje nove instance parametra. Pojam "statusa vrijednosti" mo~e biti osobito zna ajan u iterativnim procesima i informacijski spregnutim konstrukcijskim zadacima. Ozna avanje da je vrijednost parametra privremena, pretpostavljena, unutar odreenih granica i sli no mo~e omoguiti modeliranje algoritama rjeaavanja iterativnih, odnosno spregnutih zadataka i unaprijediti komunikaciju unutar tima koji ih rjeaava. Uz status vrijednosti trebalo bi vezati i prijedloge i argumente, ato bi bilo posebno interesantno u okru~enjima timskog rada, gdje viae konstruktora "dijeli" vrijednosti klju nih parametara, odnosno surauje na odreivanju njihovih vrijednosti. Pri tome svaki konstruktor, u okviru svog parcijalnog zadatka ima i svoje zahtjeve (prijedloge) na vrijednost parametara koje potkrepljuje svojim argumentima, te treba nai kompromisna rjeaenja. Zapisivanje prijedloga i argumenata uz status vrijednosti parametra olakaalo bi komunikaciju izmeu lanova tima, a ujedno bi se na taj na in zapisala i "povijest" razvoja konstrukcije, odnosno razlozi donoaenja pojedinih odluka. Prijedlog modela takvog zapisa podataka razvijen je u radu  REF _Ref409233669 \r \h [121]. Implementacija zapisa prijedloga i argumenata zahtijeva razvoj odgovarajuih su elja i operacija koje trebaju biti dio modela ponaaanja sustava. Parametre mo~emo nazivati i konstrukcijske varijable ili atributi konstrukcije. U daljnjem razvoju, odnosno pri programskoj realizaciji modela mo~e se razmotriti slijedee pitanje: Da li svi podaci konstrukcije trebaju biti modelirani kao parametri koji su zasebni objekti? Potvrdni odgovor zna io bi manipuliranje sa vrlo velikim brojem objekata u sustavu, ato bi ipak trebalo nastojati izbjei. Stoga bi trebalo one konstrukcijske podatke za koje se sigurno mo~e ustanoviti da ih je dovoljno modelirati kao atribute objekata, takvima i zadr~ati. Koji parametri konstrukcije bi onda nu~no trebali biti modelirani kao zasebni objekti, a koji mogu biti "samo" atributi drugih objekata ? In~enjerske strukture podataka redovito su znatno kompleksnije od onih u poslovnim sustavima. Razmotrimo situaciju u kojoj su pojedini dijelovi i sklopovi konstrukcije modelirani kao posebni objekti, a svi podaci odnosno parametri konstrukcije modelirani su isklju ivo kao atributi takvih objekata. Lako je pokazati da e u navedenom pristupu, doi do situacija u kojima e, s konstrukcijskog aspekta, isti parametar biti modeliran kao atribut razli itih objekata (slika 26). Takvi objekti, openito gledano ne moraju pripadati istoj hijerarhiji klasa. Primjeri takvih parametara naj eae e biti geometrijski podaci (kote dosjeda) koje moraju imati istu osnovnu vrijednost (zanemarujui tolerancije) na razli itim objektima, odnosno dijelovima i sklopovima proizvoda. Ukoliko se vrijednost parametara modeliranih kao atributa ne mo~e "prenijeti" mehanizmom nasljeivanja, nu~no je da se njihovim vrijednostima upravlja na jednom mjestu do kojeg e svi objekti imati pristup. Dakle, u takvim situacijama parametri nu~no moraju biti modelirani kao zasebni objekti. Modeliranje konstrukcijskih parametara kao zasebnih objekata Ovdje emo detaljnije razmotriti jedan primjer situacije u kojoj je nu~no parametre konstrukcije modelirati kao zasebne objekte. Pri razmatranju problematike modeliranja parametara konstrukcije ve je spomenuto da u jednom od moguih pristupa modeliranju oni mogu pripadati (kao atributi) odreenim objektima. Ovdje se radi o objektima koji sadr~e bilo koji oblik prikaza informacija o konstrukciji ili su to objekti koji predstavljaju su elje prema skupu informacija o konstrukciji. U daljnjem tekstu zvati emo ih objektima "prikaza proizvoda", a detaljnije e biti razmotreni u slijedeem poglavlju, kao slo~eniji gradbeni elementi modela procesa konstruiranja.  INCLUDEPICTURE "linkane slike\\assem 1 wmf vsd.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 26: Primjer parametara koji moraju dijeliti istu vrijednost Razmotrimo primjer jednostavnog sklopa sa slike 26. Neka su zapisi informacija o dijelovima sklopa modelirani kao hijerarhijski nezavisni objekti "prikaza proizvoda". Razmatrani objekti nisu dakle 3D CAD modeli dijelova i sklopa, nego takve objekte promatramo kao objekte koji sadr~e su elja prema CAD modelima i njihovim skupovima geometrijskih parametra. Drugim rije ima objekti "prikaza proizvoda" trebaju zapisati osnovne informacije iz CAD modela u obliku svojih atributa, odnosno oni su su elja transfera informacija izmeu CAD modela i modela procesa konstruiranja. Premda je na slici 26 vrlo jednostavna konstrukcija, pretpostavimo da dijelove ne radi isti konstruktor i da nisu modelirani unutar istog parametarskog 3D CAD modela (prikazani dijelovi mogu npr. biti elementi slo~enih sklopova). Neka je svaki od dijelova modeliran "svojim" objektom prikaza proizvoda, koji "zapisuje" geometrijske parametre kao svoje atribute. Razmotrimo kote dosjeda u sklopu. Kote "A1" i "A2", te "B1" i B3" moraju imati istu vrijednost nazivne mjere, isto tako i promjeri provrta i promjer osovine. Kako osigurati da zapisi ovih parametara konstrukcije kao atributa razli itih objekata imaju istu vrijednost? Ako u tijeku razvoja konstrukcije dolazi do estih promjena vrijednosti konstrukcijskih parametara, kako osigurati pravovremenu komunikaciju izmeu konstruktora, ako je odreivanje svakog od povezanih parametara dio razli itih zadataka razli itih konstruktora? To zna i da svakim od objekata prikaza proizvoda manipulira drugi konstruktor, i to u razli itim vremenskim razdobljima. Ovdje se predla~e rjeaenje u kojem objekti prikaza proizvoda ne sadr~e u atributima zapise vrijednosti konstrukcijskih parametara nego pokaziva e ("pointere") na objekte, odn. instance klase "parametar" koji enkapsuliraju zapis vrijednosti konstrukcijskih parametara. Manipuliranje svojstvima i zapisom vrijednosti konstrukcijskog parametra na samo jednom mjestu (unutar objekta "parametar"), osigurava ispravnost konstrukcije, ali i otvara mogunosti sofisticiranije kontrole pristupa zapisu vrijednosti parametra. Isto tako otvara se i mogunost modeliranja komunikacije izmeu konstruktora koji manipuliraju sa zajedni kim parametrima u obliku razmjene prijedloga i argumenata. Na slici 27 prikazana je shema referenciranja konstrukcijskih parametara ija vrijednost je zajedni ka za viae dijelova modeliranih kao "objekata prikaza proizvoda". Atributi objekata sadr~e pokaziva e na objekte klase "parametar". Atributi mogu imati razli ite nazive u razli itim objektima (npr. "kota A1", "kota A2"), ali moraju pokazivati na zajedni ki parametar, iji zapis vrijednosti dijele. U ovom primjeru objekt klase parametar, "dosjed dio1-dio2", sadr~avati e dakle zajedni ku vrijednost nazivne mjere. Tolerancije mogu biti zapisane kao dodatni atributi objekata klase "parametar" ili u svakom od objekata prikaza proizvoda posebno.  INCLUDEPICTURE "linkane slike\\veza atributa i parametara 3.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 27: Povezivanje "zajedni kih" atributa objekata referenciranjem istog parametra Objekti prikaza konstrukcije mogu sadr~avati atribute koji su svojstveni samo jednom objektu, ali takoer referenciraju objekt klase "parametar" - npr. atribut "materijal" dijela 1 (slika 27). Isto tako atributi objekata modela procesa konstruiranja za koje to nije nu~no, ne trebaju biti modelirani kao zasebni objekti, odn. objekti klase "parametar". To e naj eae biti atributi koji "ne sudjeluju" ni u kakvim interakcijama sa drugim objektima, odnosno nema potrebe za njihovim eksponiranjem izvan dosega samog objekta. Slika 26 vrlo je jednostavan primjer "dijeljenja" iste vrijednosti, odnosno relacije jednakosti izmeu konstrukcijskih parametara koji su geometrijski podaci. Openito gledano, nije nu~no da samo geometrijski podaci razli itih objekta konstrukcije budu povezani i modelirani na ovaj na in, nego se predlo~ena koncepcija mo~e primjeniti i na ostale vrste podataka. Treba naglasiti da u ovom primjeru promatramo vrlo jednostavnu konstrukciju odnosno sklop. Pri spajanju viae slo~enih dijelova i podsklopova u kona ni proizvod razmatrani problem mo~e biti i te kako zna ajan. Realne situacije (u slo~enim konstrukcijama) sadr~avati e daleko vei broj povezanih parametara i slo~enije relacije izmeu njih, gdje npr. promjena jednog parametra utje e na nekoliko drugih. U takvim slu ajevima potrebno je zapisati i sve relacije izmeu parametara, ato e biti razmotreno u poglavlju  REF _Ref409436808 \r \h 7.2.4. Iz razmatranog primjera mo~e se zaklju iti: U tijeku formiranja objekata prikaza konstrukcije treba voditi ra una o svim atributima koji su na bilo koji na in povezani s atributima drugih objekata (direktno ili indirektno), te takve atribute nu~no treba modelirati kao objekte, odn. instance klase "parametar" Mo~e se o ekivati da (pogotovo za slo~ene konstrukcije) nije mogue odmah na po etku uo iti i definirati sve meuzavisnosti unutar skupa objekata prikaza konstrukcije. To zna i da se parametri kao objekti i njihove relacije trebaju moi definirati i a~urirati u cijelom tijeku procesa konstruiranja. Struktura hijerarhije, odnosno dekompozicije objekata prikaza konstrukcije, od bitnog je utjecaja na modeliranje i izbor parametara. Npr. u razmatranom primjeru dijelovi su mogli biti modelirani kao jedan objekt (sklop), u kojem su mjere dosjeda "interni atributi". Osim navedenih situacija, kao zasebni objekti trebaju biti modelirani i oni parametri za koje nije pogodno ili mogue modelirati ih kao atribute drugih objekata iz raznih drugih razloga - npr. zbog implementacije "statusa vrijednosti", hiperveze, zapisa znanja, omoguavanja pristupa raznim programskim alatima, itd. Svakako bi kao zasebne objekte trebalo modelirati skup klju nih parametara konstrukcije (gabariti, performanse i sli no) da bi se omoguio br~i i jednostavniji pristup i pregled statusa i vrijednosti takvih podataka. Realno je pretpostaviti da e postojati i zna ajan skup parametara (tj. podataka) konstrukcije kojima nu~no nije potrebna oznaka statusa vrijednosti i hiperveza, pa se mogu modelirati kao "obi ni" atributi objekata kojima pripadaju. Baza parametara Kompletan skup informacija o proizvodu redovito sadr~i vrlo velik broj podataka. Informacije se grubo mogu klasificirati kao geometrijske, strukturalne (topoloake) i tehnoloake. Svaka slo~enija konstrukcija biti e tako opisana sa nekoliko tisua ili desetaka tisua podataka. Ta injenica odmah namee potrebu da se parametri (kao modeli konstrukcijskih podataka) moraju strukturalno organizirati radi lakaeg manipuliranja sa tako brojnim skupom podataka. Za tu svrhu u predlo~enom modelu predviena je "baza parametara". Termin "baza" u ovom se kontekstu koristi u nedostatku prikladnijeg, makar predlo~eni entitet ne mora imati sva svojstva baze podataka i nije nu~no da se realizira u programskoj okolini baze podataka. (Mo~da jednako ili viae neprikladni termini mogli bi biti npr. "skup", "kontejner" ili "pregled" parametara). Baza parametara modelira logi ku organizaciju skupa parametara konstrukcije modeliranih kao objekata, uz kontrolu jedinstvenosti naziva parametra i pristupa atributima parametra, te sadr~i i operacije pretra~ivanja i pregledavanja. Baza organizira (sadr~i) sve parametre konstrukcije koje je iz bilo kojeg razloga pogodno ili nu~no modelirati kao zasebne objekte. Glavne operacije koje treba sadr~avati baza parametara: manipuliranje strukturom parametara kontrola pristupa parametrima i transfera vrijednosti parametara prema ostalim entitetima sustava Osim osiguranja jedinstvenih vrijednosti "zajedni kih" parametra, treba izdvojiti joa jednu va~nu funkciju baze parametara - da slu~i kao univerzalno su elje, odnosno izdvojeni "servis" transfera vrijednosti parametara. esto e se u konstrukcijskim uredima naii na skup raznorodnih aplikacija koje su nastajale kroz dugi niz godina, ije ulazno-izlazne procedure nisu povezane. Ovdje se "programskim alatima" (procedurama) smatraju programi (naj eae prora uni) pisani u proceduralnim jezicima koji u velikom broju slu ajeva nisu integrirani meusobno, niti sa CAD modelima. Vrlo je vjerojatno da e u veini slu ajeva biti isplativije takve alate ne mijenjati i pokuaati ih implementirati u objektni model, nego razvijati nove operacije unutar objektnog modela koje bi zamijenile takve alate. Jedan od na ina implementacije je izrada posebnih dodatnih procedura za svaki program koje e brinuti o transferu podataka prema bazi parametara. Dakle za svaki pojedini programski alat treba razviti su elje koje ga pokree i obavlja transfer podataka. Su elja moraju poznavati strukturu baze parametara kao i strukturu ulazno/izlaznih operacija programskog alata kojem pripadaju. U takvom pristupu baza parametara osigurava jedinstvenost zapisa vrijednosti i jednostavniju dostupnost konstrukcijskih parametara (jer se "izdvajaju" iz svojih objekata). Meutim dodatni problem ovakvog pristupa je potreba za "dvostrukim" a~uriranjem su elja - sa strane eventualne promjene konfiguracije baze parametara i sa strane dorada i promjena programskih alata. Preko "su elja programskih alata" i baze parametara osigurava se dakle transfer vrijednosti: izmeu atributa objekata "prikaza proizvoda" (koji referenciraju objekte klase "parametar") i "vanjskih" programskih alata izmeu viae "vanjskih" programskih alata (procedura), koje koriste odreene konstrukcijske parametre u slijedu Organizacija baze parametara Realno je pretpostaviti da e baza parametara sadr~avati vrlo velik broj parametara u modelima slo~enijih konstrukcija. Konstruktori bazu popunjavaju postupno, a potrebno je osigurati i jednostavne postupke a~uriranja, pregledavanja i pretra~ivanja. Stoga je svakako potrebno bazu parametara strukturirati na na in koji olakaava navedene operacije. Kategorizacija parametara svakako mo~e olakaati snala~enje (pronala~enje i manipuliranje) u velikom skupu parametara, pa se u ovom radu predla~e bazu parametara strukturirati u obliku hijerarhijskog stabla (slika 28), tj. na isti na in kako je organizirano "stablo" direktorija i datoteka. U slu aju npr. nekoliko tisua parametara koji su svi smjeateni na istoj razini hijerarhije snala~enje konstruktora u takvoj linearnoj strukturi bi bilo vrlo teako.  INCLUDEPICTURE "linkane slike\\strukt baze param.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 28: Organizacijska struktura baze parametara Na slici 28 osnovne kategorije su prikazane kao grupe. Svaka grupa mo~e se dalje granati na podgrupe, a parametri se mogu pohranjivati u svim razinama, po evai od osnovnih grupa. Izuzetno je va~no da svaki parametar ima svoju jedinstvenu adresu u predlo~enoj strukturi. Adresa parametra podatak je s kojim e manipulirati veina klasa (entiteta) objektnog modela procesa konstruiranja. Dakle, osim ato mora biti jedinstvena, adresa parametra ne smije se mijenjati nakon po etnog definiranja, ili svi objekti koji referenciraju parametar moraju koristiti pokaziva e ("pointere") na adresu parametra u strukturi baze parametara. Da li parametar treba imati i jedinstveni naziv? Mialjenje je autora da nije prakti no inzistirati na tome da naziv bude jedinstven u bazi, nego samo unutar pojedine kategorije, odnosno grupe. Naime ako se postavi zahtjev na jedinstvenost unutar cijele baze, to mo~e stvoriti probleme u odreivanju ("izmialjanju") naziva parametara koji ve imaju uvrije~ene sli ne ili iste termine u praksi odreenog okru~enja. Ako se nazivu parametra pridoda i naziv kategorije kojoj pripada, tada takva oznaka mora biti jedinstvena. Takva oznaka parametra vie govori o parametru nego sam naziv. Operacije u bazi parametara U procesu razvoja nove konstrukcije baza parametara nastaje i "puni" se usporedo s razradom funkcionalne strukture i razradom komponenti, odnosno s kreiranjem objekata prikaza konstrukcije. Pri konstruiranju varijantne i ponovljene konstrukcije mo~e se koristiti postojea struktura (prethodno zavraene varijante) koja se eventualno prilagoava i dograuje. Bez obzira na vrstu konstrukcije iji proces se modelira, baza parametara trebala bi sadr~avati slijedee osnovne operacije: dodavanje i brisanje grupe i pojedina nog parametra, promjena hijerarhije grupa, agregacija grupa, rastavljanje grupa (dekompozicija), premjeatanje parametra i/ili grupe unutar hijerarhije, promjena naziva parametra i/ili grupe, operacije promjene vrijednosti parametra i ostalih uz njega vezanih zapisa, pregledavanje i pretra~ivanje po razli tim kriterijima - upitima Ovdje smo naveli samo skup osnovnih operacija koje modeliraju strukturu i organizaciju baze parametara, no pored njih potrebno je realizirati i operacije kontrole pristupa bazi i transfera podataka prema su eljima programskih alata, o emu e biti rije i neato kasnije. Pristup realizaciji modela baze parametara Model baze parametara mogue je realizirati na viae na ina: u okru~enju objektne baze podataka u okru~enju relacijske baze podataka kao skup ASCII datoteka i potrebnih aplikacija za realizaciju svih operacija Svaki od navedenih pristupa ima svoje prednosti i mane. Treba naglasiti da sva tri pristupa moraju osigurati siguran rad u okru~enju ra unalne mre~e. Objektna baza svakako je "najprirodniji" pristup, obzirom na realizaciju cijelog objektnog modela procesa konstruiranja. Svaki parametar modelira se kao objekt, pa je logi no da se sprema u objektnu bazu. U istoj bazi bili bi spremljeni i objekti klasa koje sadr~e sve potrebne operacije modeliranja i implementacije baze parametara. Relacijska baza pogodna je zbog lakae implementacije mehanizama manipuliranja strukturom i pogotovo pretra~ivanja, te ispisa izvjeaa. Meutim, relacijsku bazu te~e je implementirati u objektno orijentirano okru~enje, a kompliciranije je realizirati i postupke transfera podataka prema objektima sustava. Osnovna prednost pristupa u kojem se baza parametara realizira kao skup ASCII datoteka i pripadajuih aplikacija je u daleko jednostavnijem transferu podataka prema programskim alatima. Ulazno - izlazne procedure programskih paketa specifi ne namjene veinom su realizirane tako da itaju i piau po ASCII datotekama. Meutim kod ovakvog pristupa ostaje puno viae posla pri realizaciji potrebnih aplikacija za modeliranje strukture baze, osiguranje jedinstvenosti adrese parametra i kontrolu pristupa. Ako se nazivi i adrese parametara (misli se na adrese u logi koj strukturi baze) zapisuju u ASCII datoteke te~e je realizirati i mehanizme zaatite od nehoti nih greaaka pri upisivanju vrijednosti. Kao ilustracija prethodnih razmatranja, na slici 29 prikazan je prijedlog osnovne strukture tablica i relacija kao implementacije strukture baze parametara u okru~enju relacijske baze.  INCLUDEPICTURE "linkane slike\\relac baza param.gif" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 29: Prijedlog realizacije baze parametara u relacijskoj bazi Predlo~enu strukturu u relacijskoj bazi podataka mogue je realizirati na na in da su svi podaci parametara zapisani u jednoj tablici, ato olakaava manipulaciju s adresom parametra i operacije pretra~ivanja. Pri realizaciji predlo~enog modela pokazalo se ipak da objektna baza ima najviae prednosti, pogotovu u modeliranju vrlo slo~enih struktura relacija izmeu parametara i drugih klasa objektnog modela. Pored toga objektna baza efikasno rjeaava i probleme viaestrukog referenciranja i kontrole pristupa parametrima. Detaljnije su ove teme razmotrene u osmom poglavlju. Kontrola pristupa bazi parametara i zapisivanje vrijednosti Baza parametra struktura je podataka i pripadajuih operacija koje moraju osigurati siguran rad i kontrolu pristupa u mre~nom okru~enju. Ovdje emo nabrojati neke od situacija za koje treba realizirati mehanizme kontrole pristupa. U jednom trenutku samo jedan korisnik (aktivni objekt) mo~e mijenjati strukturu (hijerarhiju grupa) unutar baze, ostali objekti sustava za to vrijeme ne mogu imati pristup niti za pisanje niti za itanje. Istovremeno viae objekata mo~e imati pristup za pisanje, ako pri tome ne mijenjaju strukturu, i pri tome upisuju vrijednosti razli itih parametara. Pristup za itanje mo~e imati viae objekata istovremeno. Poseban je problem kontrola pristupa i mijenjanje vrijednosti parametara koji se obrauju u viae konstrukcijskih zadataka koji se izvode paralelno i koji su "informacijski spregnuti", ato zna i da se vrijednost jednog te istog parametra mo~e mijenjati u svakom od tih zadataka. Ako bilo koji od spregnutih zadataka treba promijeniti vrijednost parametra, potrebno je da o tome obavijesti i ostale. Pored toga, za takve je slu ajeve potrebno realizirati mehanizme komunikacije izmeu zadataka u smislu tra~enja suglasnosti za takve promjene - da li ostali zadaci mogu prihvatiti novu vrijednost parametra? Za takve je situacije predvien zapis prijedloga i argumenata kao dio strukture parametra. Ova problematika detaljnije je razraena i modelirana u  REF _Ref409233669 \r \h [121]. Noviji pristup ovoj problematici razraen je u  REF _Ref409158676 \r \h [119]. Navedena situacija takoer se razmatra i u poglavlju o matrici prikaza informacijske zavisnosti konstrukcijskih zadataka. Informacijski spregnuti konstrukcijski zadaci izvode se u iterativnim ciklusima, a takve situacije karakteristi ne su za procese istovremenog in~enjerstva (eng. concurrent engineering). Potrebno je razmotriti joa jedan dodatni problem vezan za su elja prema bazi parametara, sadr~aj baze i kontrolu pristupa parametrima. Tradicionalni proceduralni programski alati (npr. numeri ki prora uni) u tijeku izvoenja procesa konstruiranja obavljati e u veini situacija transfer vrijednosti skupova parametara samo povremeno, u diskontinuiranim iterativnim ciklusima. Transfer vrijednosti parametara prema CAD modelima daleko je slo~eniji proces. Konstruktor u pravilu radi na jednom CAD modelu u kontinuiranom procesu kroz du~e vrijeme. Pri tome mo~e primjenom naredbi CAD paketa promijeniti vrijednosti nekih geometrijskih parametara mnogo puta. Postavlja se pitanje da li je nu~no svaku takvu promjenu odmah zapisati u bazu parametara? Vjerojatno takav pristup ne bi bio isplativ, a bilo bi ga i vrlo teako realizirati. Dodatan problem za takve situacije je praenje dinamike promjena vrijednosti parametara. Promjena vrijednosti jednog geometrijskog podatka u parametriziranom CAD modelu uzrokuje promjene vrijednosti svih ostalih podataka koji su s njime povezani geometrijskim relacijama i ograni enjima. Kako u navedenim situacijama realizirati zapis, tj. transfer vrijednosti parametara u bazu? Aplikacija (su elje) koja povezuje CAD model i bazu parametara svakako treba obaviti transfer vrijednosti prilikom svakog otvaranja i zatvaranja (spremanja) CAD modela. Ovdje pretpostavljamo da se koriste parametarski CAD sustavi koji koriste interne varijable za geometrijske parametre modela. Neki vrhunski CAD paketi danas ve imaju module koji omoguavaju kontrolu pristupa i "vlasniatva" nad komponentama slo~enih sklopova u okolinama timskog rada. Za po etnu fazu razvoja baze parametara dovoljno je realizirati upisivanje u status vrijednosti parametra da je "aktivan u otvorenom CAD modelu". To zna i da je pristup do vrijednosti takvog parametra onemoguen sve dok se doti ni CAD model ne zatvori, odnosno obavi transfer vrijednosti svih parametara iz baze koje je koristio. Ovdje ostaje otvoreno pitanje kako rijeaiti situaciju istovremenog rada na viae CAD modela koji sadr~e nekoliko zajedni kih (istih) parametara. Da bi predlo~eni mehanizam funkcionirao, svako su elje CAD modela mora imati to nu evidenciju o pripadajuim parametrima. Meutim, tu se javlja novi problem: novogenerirane parametre CAD modela (koji nastaju u tijeku rada s modelom) treba definirati u bazi i u su elju CAD modela i baze. To zna i da konstruktor paralelno sa radom na CAD modelu, mora koristiti i su elje modela prema bazi parametara, ili "pamtiti" sve nove parametre, pa ih naknadno upisivati u bazu preko su elja baze, i pored toga a~urirati listu parametara u su elju modela. U oba slu aja za ispravan transfer vrijednosti odgovoran je konstruktor koji radi na CAD modelu. Na in rjeaavanja razmatranih problema bitno ovisi i o faktorima konkretnog okru~enja procesa konstruiranja: mogunostima konkretnog CAD sustava koji se koristi u odreenom okru~enju na inu kreiranja CAD modela, odnosno koriatenja CAD sustava (rijetko koji konstrukcijski ured koristi CAD sustav na "pravi" na in, odnosno ne izvla i maksimum mogunosti sustava) dekompoziciji konstrukcije u CAD modele sklopova i podsklopova, raspodjeli zadataka unutar tima Uloga baze parametara (rezime) Rezimirajui, joa jednom emo naglasiti osnovne zadae baze parametara: da osigura nadzor nad vrijednostima zajedni kih atributa raznorodnih objekata, odnosno parametara konstrukcije koji se koriste u viae razli itih prikaza konstrukcije, da omogui realizaciju mehanizma transfera podataka izmeu raznorodnih i neintegriranih aplikacija bez velikih zahvata u programski kod takvih aplikacija, da omogui pregled "stanja razvoja" konstrukcije "na jednom mjestu", odnosno da nije potrebno pregledavati viae raznorodnih dokumenata i modela da bi se vidjele trenutne vrijednosti i status klju nih parametara konstrukcije. Unapreenje organizacije manipulacije podacima konstrukcije i kontrole pristupa podacima konstrukcije jedan od prvih preduvjeta unapreenja organizacije i kvalitete izvoenja cjelokupnog procesa konstruiranja. To pogotovo vrijedi u okolinama timskog rada i istovremenog in~enjerstva. Komponenta vremena u takvim situacijama vrlo je va~na - im je informacija definitivno definirana, treba ju odmah proslijediti dalje. esto je informacije va~no staviti na raspolaganje ve i kad su u statusu "prijedloga". U prethodnim razmatranjima navedeno je i nekoliko problema koje pri realizaciji modela baze parametara nije jednostavno rijeaiti. Mo~e se onda postaviti pitanje da li baza parametara treba biti entitet modela procesa konstruiranja ili je bolje manipulaciju s atributima objekata rijeaiti na druge na ine? Mialjenje je autora da i pored navedenih problema treba izdvojiti manipulaciju s klju nim podacima konstrukcije na jednom mjestu, jer takav pristup mo~e zna ajno unaprijediti organizaciju zapisa i tokova razmjene informacija u tijeku procesa konstruiranja. Daljnja detaljnija istra~ivanja trebala bi dati rjeaenja razmatranih problema. Realizacija baze parametara kao entiteta objektno orijentiranog modela procesa konstruiranja zahtijevati e itav skup klasa i operacija, a treba se i odlu iti za jedan od ranije predlo~enih pristupa. Na kraju treba napomenuti da se predlo~ena struktura baze parametara ne bi trebala smatrati nadomjestkom sustava za upravljanje informacijama o proizvodu, tzv. EDM/PDM sustava (engineering / product data management). Ve je prije naglaaavano da baza parametara ne treba sadr~avati sve podatke o proizvodu, nego ona sadr~i samo klju ne podatke za povezivanje razli itih objekata prikaza konstrukcije, podatke koje dijele informacijski spregnuti zadaci i podatke koji kolaju izmeu raznorodnih programskih alata. Bazu parametara najbolje bi mogli opisati kao univerzalno su elje za sve podatke koji trebaju biti izvan dosega objekata prikaza konstrukcije kojima pripadaju. Takvi podaci mogu se promatrati i kao "izdvojena proairenja" atributa objekata prikaza konstrukcije, ili "atributi modelirani kao objekti". Dakle baza parametara nije repozitorij svih informacija proizvodnog sustava, nego samo zajedni ko su elje objekata modela procesa konstruiranja. Prikaz proizvoda (skup informacija o proizvodu) Proizvod procesa konstruiranja je skup svih informacija potrebnih da se proizvod izradi i pravilno eksploatira. Svaka slo~enija konstrukcija sadr~i u tom skupu informacija veliki broj raznorodnih dokumenata, odnosno zapisa informacija, npr.: projektni dokumenti (preliminarne sheme i dispozicije, elaborati), monta~ni i radioni ki crte~i, prora uni, sastavnice, tehnoloake upute i postupci, podaci za narud~bu standardnih dijelova, upute za rukovanje i odr~avanje, itd. Skup svih informacija o proizvodu sa injen je dakle od raznorodnih oblika zapisa i organizacije informacija, koji nastaju u razli itim fazama procesa konstruiranja. Pri tome se mnoge informacije pojavljuju u viae dokumenata (zapisa). Svaki konstrukcijski ured ima organizirani sustav identifikacije i pohrane dokumentacije. U takvim sustavima obi no postoje i interni propisi na ina kreiranja i tokova kolanja dokumenata. Ovisno o zna ajkama proizvoda i tehnologije proizvodnje takvi sustavi znatno variraju jer su prilagoeni konkretnim potrebama. Najvei raspon razlika naaao bi se izmeu nezavisnih projektnih ureda i konstrukcijskih ureda unutar proizvodnih sustava. Openito gledano, skup informacija o proizvodu sastoji se od niza podskupova raznorodnih oblika zapisa, unutar kojih se neke informacije preklapaju, tj. pojavljuju se u viae dokumenata, zapisane u razli itim oblicima. Sustavi organizacije takvih skupova informacija variraju i specifi ni su za odreeno okru~enje odvijanja procesa konstruiranja. Zapisi informacija o proizvodu temeljni su entiteti u "realnom svijetu" procesa konstruiranja kojeg razmatramo i modeliramo, jer su oni proizvod, odnosno cilj procesa konstruiranja. Stoga ih treba apstrahirati i modelirati kao objekte, ali prije toga treba razmotriti to takvi objekti predstavljaju i koja je njihova uloga u modelu procesa konstruiranja. Kako nazvati takve objekte? Npr. pogodan naziv u engleskom jeziku bio bi "product information object". Ovaj naziv nema prikladnog doslovnog prijevoda, pa emo koristiti naziv "prikaz proizvoda" ("objekt prikaza proizvoda") ili "skup informacija o proizvodu". Pri tome se podrazumijeva da je "prikaz proizvoda" odreeni podskup cjelokupnog skupa informacija o proizvodu. Entitet "prikaz proizvoda" modelira odreenu vrstu zapisa informacija o proizvodu. Modelira postojanje, odnosno enkapsulira sve pojmove i dogaaje iz "~ivotnog ciklusa" odreenog nosioca zapisa informacija o proizvodu. Objekt "prikaz proizvoda" sadr~i operacije su elja za transfer i generiranje podataka iz skupa informacija koji modelira. Takav objekt model je konkretnog dokumenta ili skupa podataka, odnosno nosioca informacija o proizvodu. Pod "modelom" dokumenta ovdje se podrazumijeva: identifikacija dokumenta unutar modela procesa konstruiranja skup operacija koje ine su elje "stvarnog dokumenta" (tj. zapisa skupa informacija) i objektnog modela procesa konstruiranja skup referenci na parametre u bazi parametara i skup atributa objekta, odnosno svi podaci koji ine doti ni podskup informacija o proizvodu dogaaji (stanja) koji ine "~ivotni ciklus" dokumenta - definiranje (otvaranje), izrada, zavraetak, kontrola, odobravanje, pohrana u arhivi, prosljeivanje na tehnoloaku razradu ili u proces proizvodnje Primarna uloga objekta prikaza proizvoda je da "enkapsulira" sve navedene informacijske aspekte i aspekte ponaaanja odreene klase dokumenta odnosno zapisa informacija o proizvodu. Pri modeliranju objekata prikaza proizvoda potrebno je klasificirati sve vrste zapisa informacija o proizvodu, izdvojiti zajedni ke atribute i operacije, te definirati hijerarhiju klasa na vrhu koje bi bila generi ka klasa. U veini slu ajeva informacije o proizvodu biti e zapisane na ra unalu, ali ovaj entitet treba moi modelirati i druge oblike zapisa informacija. Ako objekt predstavlja ra unalni zapis informacija, tada mo~e i sadr~avati taj zapis (djelomi no ili u potpunosti), ali mo~e funkcionirati i kao su elje prema aplikaciji koja sadr~i i obrauje ra unalni zapis (npr. CAD paket). Ako objekt predstavlja skup informacija koji nije zapisan na ra unalu, tada e funkcija takvog objekta naj eae biti samo "administrativne" prirode - da modelira "postojanje" i cirkulaciju takvog dokumenta u procesu konstruiranja. Objekt prikaza proizvoda mo~e sadr~avati, (ali ne i nu~no) informacije i o procesu konstruiranja proizvoda. Ovi objekti su slo~ene strukture (kompozitni objekti) i mogu sadr~avati i druge objekte iz skupa entiteta modela procesa konstruiranja. Kriteriji klasifikacije i na ini realizacije konkretnih podklasa prikaza proizvoda bitno e ovisiti o vrsti i razini koriatenja postojee programske podrake procesu konstruiranja u odreenom realnom okru~enju. Na primjer ako se u konkretnom okru~enju koristi CAD programski paket koji sadr~i podraku za kreiranje strukturne sastavnice proizvoda, onda nee biti potrebno kreirati sastavnicu kao posebnu klasu prikaza proizvoda. Na objektima prikaza proizvoda izvodi se najvei dio operacija u procesu konstruiranja. Na kraju procesa skup ovih objekata sa injava dokumentaciju o konstruiranom proizvodu, odnosno skup svih potrebnih informacija za proizvodnju i eksploataciju proizvoda. Klasifikacija objekata prikaza proizvoda tema je slijedeeg poglavlja. Ovdje emo navesti zajedni ke atribute i operacije koje treba imati svaka klasa, a koje nasljeuje od generi ke klase na vrhu hijerarhije klasifikacije. Atributi klase "prikaz proizvoda" Skup osnovnih atributa objekata prikaza proizvoda: D = {i, o, k, p, u, s, R} pri emu je: i::= identifikator u sustavu klasifikacije i pohrane dokumenata o::= opis k::= odgovorna osoba - referenca (pokaziva ) na konstruktora p::= putanja do datoteke (ili direktorija, ako prikaz sadr~i skup datoteka) - koristi se za ra unalni zapis informacija o proizvodu u::= dostupnost, odnosno ograni enja upotrebe, (skup referenci na konstruktore) - zapisuje se tko ga smije mijenjati, a tko samo itati s::= status objekta odnosno dokumenta (ili stanje u ~ivotnom ciklusu) R::= skup referenci ("pointera") na parametre u bazi parametara (slika 30) Pri tome s poprima to no jednu vrijednost iz skupa moguih stanja S: s ( S, gdje je S = {s1, s2, s3, s4} s1::= aktivna je obrada dokumenta s2::= dokument zavraen, eka odobrenje s3::= dokument zavraen i odobren s4::= dokument zatvoren (izmjene mogue samo uz posebno odobrenje ili dogovor) Operacije klase "prikaz proizvoda" Skup operacija koje trebaju biti dio procesa generiranja nove instance objekta: dodjeljivanje identifikatora, inicijalizacija statusa, referenciranje parametara, generiranje i inicijalizacija parametara, referenciranje odgovorne osobe. Upravljanje referencama na parametre. Skup operacija su elja prema nosiocu informacija kojeg modelira (za transfer vrijednosti prema parametrima iz baze, slika 32). Relacije (asocijacije) klase "prikaz proizvoda" Objekt prikaza proizvoda sadr~i skup referenci na parametre u bazi parametara (slika 30, analogno slici 27). Na taj na in se operacijama unutar objekta prikaza proizvoda omoguuje pristup do parametara koji su modelirani kao zasebni objekti. Ovakav skup referenci mo~e se promatrati kao relacija izmeu instance prikaza proizvoda i skupa instanci parametara, logi ki organiziranih u bazi parametara. Detaljna razrada relacija izmeu razli itih klasa objekata prezentirana je u poglavlju  REF _Ref409177624 \r \h 7.2, a realizacija ovako postavljenih relacija u objektnoj bazi prezentirana je u osmom poglavlju. Stoga se shema na slici 30 ovdje daje samo kao uvod u daljnja razmatranja, bez detaljnije razrade.  INCLUDEPICTURE "linkane slike\\REFERENCE NA BAZU PARAMETARA.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 30: Skup referenci na parametre u bazi parametara kao podskup objekta prikaza proizvoda Primjeri objekata prikaza proizvoda i klasifikacija Za ilustraciju prethodnih razmatranja, odnosno koncepta objekta prikaza proizvoda, navesti emo i razmotriti primjere takvih objekata. Ponoviti emo da takvi objekti nisu sami ra unalni zapisi (kao npr. CAD model), nego u veini slu ajeva njihova su elja. Npr. 2D crte~ postoji kao datoteka i kao iscrtani dokument na papiru. Radi se zapravo o istom skupu informacija, zapisanom na razli ite na ine, odnosno na razli itim medijima. U oba slu aja zapisa treba identificirati i "administrirati" postojanje takvog zapisa, a u slu aju ra unalnog zapisa, potrebno je realizirati operacije su elja prema bazi parametara i drugim objektima modela procesa konstruiranja. Ako se radi o parametarskom 2D crte~u tada e se u odreenoj fazi procesa konstruiranja pokrenuti operacije su elja (sadr~ane u objektu prikaza proizvoda) koje e izvraiti transfer vrijednosti parametara iz baze parametara prema internim varijablama crte~a i na taj na in nastati e nova varijanta crte~a. Takav novi crte~ treba dobiti svoj broj (kao novi dokument), treba biti iscrtan (isplotan), pohranjen u arhivi i proslijeen dalje u tehnoloaki odjel. Uloga objekta prikaza proizvoda koji modelira takav dokument je dakle da "administrativno" prati njegov "~ivotni ciklus" i da mu osigura potrebne operacije su elja prema bazi parametara i prema drugim objektima modela procesa konstruiranja. Razjasnimo joa ato se podrazumijeva pod "administrativnim praenjem ~ivotnog ciklusa". Da bi se efikasno unaprijedila organizacija procesa konstruiranja i da bi se konstruktora oslobodilo najveeg dijela rutinskih aktivnosti, potrebno je razviti aplikacije koje e automatizirati operacije manipulacije s dokumentima. Jedan primjer takve aplikacije je automatsko dodjeljivanje jedinstvene oznake svakom novokreiranom dokumentu, te evidencija svih dokumenata u zajedni koj bazi podataka cijelog proizvodnog sustava. Postoji itav niz programskih sustava koji pokrivaju takve namjene (EDM/PDM sustavi), meutim to su openite "ljuske" ili "toolbox-ovi", realizirane veinom u relacijskim bazama podataka, te je potrebno ulo~iti dosta dodatnog rada pri njihovom prilagoavanju i implementaciji u konkretno okru~enje. Va~niji nedostatak takvih sustava u razmatranom kontekstu je injenica da nisu primarno orijentirani na proces konstruiranja nego prete~no na poslovne (financijske i informacijske) aspekte proizvodnog ciklusa. Stoga je u nekim slu ajevima isplativije razvijati takve sustave pojedina no, prema pravilima organizacije dokumentacije konkretnog okru~enja. Primjer takvog sustava realiziran je kao dio projekta  REF _Ref409171671 \r \h [122],  REF _Ref409237958 \r \h [123]. Navedeni projekt je sustav baza podataka konstrukcijskog ureda koje sadr~e sve podatke o dokumentaciji proizvoda (oznake, stanje dokumenata, rokovi) i podatke o raspodjeli zadataka izmeu konstruktora. Sustav je realiziran u mre~nom okru~enju, koriatenjem "intranet" tehnologije. Navedimo sada primjere dokumenata, odnosno zapisa informacija koji se mogu modelirati kao objekti prikaza konstrukcije: zahtjevi naru itelja, (podaci ugovora) projektni podaci, preliminarni dispozicijski crte~i i sheme tehni ki prora uni (ulazno-izlazne liste), kalkulacije troakova, elaborati 3D CAD model - dio i/ili sklop, 2D crte~, sastavnica (osnovni dokumenti za proizvodnju) podaci za narud~bu standardnih i kataloakih dijelova i materijala graevinska dokumentacija, studije utjecaja na okolia (za procesna postrojenja) tehnoloake upute za proizvodnju tehni ke upute za eksploataciju i odr~avanje interni standardi proizvodnog sustava, katalozi internih standardiziranih dijelova katalozi dobavlja a, katalozi standardnih dijelova Zadnja dva navedena primjera nisu kao skupovi informacija direktni proizvodi procesa konstruiranja, ali se njihove komponente koriste u cjelokupnom prikazu proizvoda. Razrada klasifikacije objekata prikaza proizvoda dovela bi do upotrebe konkretnijih naziva objekata (klasa) kao npr. dokument, crte~, prora un vrstoe, itd. Takve klasifikacije pogodnije je napraviti prema specifi nim potrebama konkretnog okru~enja. U svakom slu aju, "objekt prikaza proizvoda" mo~emo promatrati kao generi ku (apstraktnu) klasu na vrhu klasifikacijske hijerarhije. Jedan primjer prijedloga klasifikacije zapisa informacija o proizvodu prikazan je na slici 31. Jednostavni primjeri objekata prikaza proizvoda i njihovo povezivanje sa bazom parametara prikazani su na slici 32.  INCLUDEPICTURE "linkane slike\\UML klasifikacija prikaza proizvoda.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 31: Dijagram prijedloga klasifikacije prikaza proizvodu Kreiranje objekata prikaza proizvoda Objekti prikaza proizvoda kreiraju se u svim fazama procesa konstruiranja. Ako se radi o potpuno novoj konstrukciji, objekti se mogu kreirati usporedo s razradom funkcionalne strukture proizvoda. Objekt prikaza proizvoda nastaje zapravo s kreiranjem nove instance odreene klase zapisa informacija o proizvodu. Vjerojatno nije uvijek nu~no nakon kreiranja novog dokumenta (odn. zapisa informacija) kreirati i objekt koji ga "predstavlja" unutar objektnog modela procesa konstruiranja. Kreiranje objekta prikaza proizvoda nu~no e biti u situacijama gdje je potrebno koristiti operacije su elja prema bazi parametara i prema drugim objektima modela procesa konstruiranja. Kod ponovljenih i varijantnih konstrukcija zapisi informacija (odnosno dokumenti) mogu se kreirati na temelju postojeih uzoraka i predlo~aka koji se dograuju i mijenjaju (npr. "skeleton, layout, template") ili se kao osnova mogu koristiti pohranjeni zapisi ve izvedenih konstrukcija. U takvim situacijama klase objekata prikaza proizvoda mogle bi se realizirati kao parametarske, ato bi olakaalo kreiranje, odnosno instanciranje objekata. Modeliranje prikaza proizvoda Razmatranje objekta prikaza proizvoda zaklju iti e se primjerom principa modeliranja pojmova iz realnog svijeta preslikavanjem entiteta iz "realnog svijeta" u logi ki i objektni model (shema na slici 22). U ovom primjeru izdvojeno je modeliranje skupa informacija o proizvodu i modeliranje "fizi ke komponente" proizvoda, uz naglaaavanje semanti ke razlike izmeu ta dva pojma. Ujedno su prikazane i interakcije i reference objekta prikaza proizvoda sa ostalim objektima modela procesa konstruiranja.  INCLUDEPICTURE "linkane slike\\objekt prikaza proizvoda.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 32: Preslikavanje informacija o proizvodu u logi ki i objektni model Skupovi informacija o proizvodu preslikavaju se u objekte prikaza proizvoda. Jedna od primarnih funkcija objekta prikaza proizvoda je osigurati transfer vrijednosti podataka iz zapisa informacija o proizvodu prema bazi parametara (i obrnuto). U konkretnom primjeru odreeni skup parametara CAD modela treba modelirati kao parametre (odnosno objekte) u bazi parametara. Objekt prikaza proizvoda koji modelira konkretni CAD model sadr~avati e skup (niz) pokaziva a (pointera) na adrese objekata (parametara) u bazi parametara. Sam transfer vrijednosti navedenih parametara bitno e ovisiti o vrsti zapisa informacija o proizvodu, odnosno o moguim na inima u itavanja i eksportiranja podataka. Stoga za svaku vrstu zapisa informacija o proizvodu treba postojati posebna podklasa objekta prikaza proizvoda koja e sadr~avati odgovarajue operacije transfera podataka prema bazi parametara. Ostali objekti prikaza proizvoda, kao i druge klase objekata mogu pristupati parametrima u bazi koji pripadaju trenutno aktivnom objektu prikaza proizvoda, pri emu atributi stanja svakog parametra odreuju kontrolu pristupa. Slika 32 isti e razliku u modeliranju skupova informacija o proizvodu i modeliranju "fizi kih" komponenti proizvoda (ato se u svakodnevnoj praksi esto poistovjeuje). Skup informacija o proizvodu mo~e sadr~avati informacije o jednom ili viae fizi kih objekata. Isto tako jedan fizi ki objekt (ili skup fizi kih objekata) mogu biti opisani sa viae raznorodnih skupova informacija. Fizi ke komponente proizvoda kao objekte modela procesa konstruiranja potrebno je modelirati u situacijama koje su navedene u slijedeem poglavlju. Struktura proizvoda (objekt iz fizi ke domene) Dokumenti, odnosno sve vrste zapisa informacija ine skup podataka o proizvodu. Pored informacija o proizvodu, u proizvodnom sustavu kao entiteti egzistiraju i dijelovi i sklopovi proizvoda kao stvari, "fizi ki" objekti. Npr. razlikujemo "vratilo" i "crte~ vratila". Neki objektni pristupi (npr. REF _Ref409238242 \r \h [124],  REF _Ref409141828 \r \h [125]) konstruiranju razlikuju "fizi ke" i "nefizi ke" entitete i tretiraju ih ravnopravno. Postoje i pristupi u kojima se ne razmatra modeliranje zapisa informacija kao objekata nego se orijentiraju samo na modeliranje i odnose "fizi kih" objekata konstrukcije  REF _Ref409169407 \r \h [126],  REF _Ref409238301 \r \h [127]. Po mialjenju autora nu~no je promatrati i modelirati oba aspekta i pri tome omoguiti jednostavne mehanizme preslikavanja iz fizi ke u "informacijsku" domenu i obratno. Ako se u ovim razmatranjima oslonimo na Suh-ovu aksiomatsku teoriju konstruiranja, tada mo~emo objekte promatrati u etiri domene: domena potroaa a, funkcionalna domena, fizikalna domena i domena procesa (slika 12). Suh tretira proces konstruiranja kao cik-cak preslikavanja izmeu navedenih domena. Objekte prikaza proizvoda mo~emo pridru~iti Suh-ovoj domeni procesa, a objekti koji modeliraju komponente proizvoda pripadali bi u fizikalnu domenu. Razmotrimo u kojim situacijama u procesu konstruiranja e trebati koristiti objekte prikaza iz fizi ke domene, odnosno kada se javlja potreba za takvim objektima? Prete~no e to biti situacije u kojima treba vezati odnosno skupiti ("enkapsulirati"), zapise informacija i operacije uz pojam konkretnog fizi kog objekta. Primjeri takovih situacija mogu biti npr: zapis referenci na parametre koji sudjeluju u interakcijama (meuzavisnostima) s drugim objektima fizi ke domene zapisi informacija testiranja i ispitivanja podsklopova ili cijelog gotovog proizvoda, zapisi povratnih informacija iz proizvodnje i eksploatacije skup informacija za dijelove koje rade subliferanti zapisi tehnoloakih procesa izrade i sklapanja formiranje objekta ija je uloga modeliranje i praenje "~ivotnog ciklusa" dijela u proizvodnom sustavu - takvi objekti definiraju se u odjelu konstrukcije, ali se koriste dalje u cijelom proizvodnom ciklusu podaci o internim standardnim i katalokim dijelovima - sve situacije koritenja standardnih dijelova Druga mogunost koriatenja objekata prikaza fizi ke domene je modeliranje skupova kompleksnih relacija koje se ne odnose na hijerarhiju sklopova i podsklopova. Ovdje se prvenstveno misli na funkcionalne relacije - odnose dijelova i sklopova u ispunjavanju parcijalnih funkcija tehni kog sustava. Primjer takvog pristupa predlo~en je u radu  REF _Ref409238351 \r \h [128]. Modeliranje svakog pojedinog dijela slo~ene konstrukcije samo u svrhu jedinstvene identifikacije, generiralo bi vrlo veliki broj objekata. Stoga je mialjenje autora da objekte fizi ke domene treba koristiti samo u ranije predlo~enim situacijama. Identifikaciju svakog pojedinog strojnog dijela jednostavnije je rjeaavati bazama podataka, odnosno komponentama EDM/PDM sustava. Kriteriji klasifikacije objekata strukture proizvoda specifi ni su za svako konkretno okru~enje izvoenja procesa konstruiranja. Stoga se ovdje predla~e samo jednostavna klasifikacija na dio, podsklop i sklop sa generi kom klasom na vrhu hijerarhije. Modeli klasifikacije i relacija izmeu elemenata strukture proizvoda mogu se preuzeti i iz STEP standarda  REF _Ref409695137 \r \h [103],  REF _Ref409695139 \r \h [104],  REF _Ref409695140 \r \h [105]. Kao osnovni atributi objekta strukture proizvoda predla~u se: identifikator, naziv, opis i status (u ~ivotnom vijeku). Objekti strukture proizvoda mogu se povezati relacijama sa objektima prikaza proizvoda, i to relacijama "jedan prema viae" u oba smjera, tj. jedan objekt prikaza proizvoda prikazuje viae objekata strukture proizvoda, i s druge strane, jedan objekt strukture proizvoda je prikazan u viae objekata prikaza proizvoda. Detaljnije e ova relacija biti razraena u poglavlju 7.2 i u osmom poglavlju. Akcija Do sada prikazani entiteti objektnog modela procesa konstruiranja ine osnovu stati ke (informacijske) strukture modela, odnosno mo~emo ih promatrati kao osnovne informacijske gradbene elemente. Jedan od ciljeva ovog istra~ivanja je modelirati prikaz dinamike (tijeka) odvijanja procesa. Stoga se uvodi entitet "akcija" kao jedan od osnovnih gradbenih elemenata prikaza procesa. Entitet "akcija" modelira pozive operacija objekata modela procesa konstruiranja. Akcije se kreiraju i planiraju prije izvoenja procesa, a realiziraju se u tijeku izvoenja procesa konstruiranja. Akcija se ovdje promatra u kontekstu generiranja, transformiranja i prikaza informacija (samo u informati kom kontekstu), a ne i u kontekstu metodologije i postupaka konstruiranja, kao ato je npr. Hubkina klasifikacija aktivnosti i operacija u procesu konstruiranja (slika 5). Meutim tako koncipirani entitet "akcije" mo~e poslu~iti kao gradbeni element, tj. skup akcija mo~e modelirati elementarne operacije s razine 5 na slici 5. Slo~eniji kompozitni entiteti prikaza procesa konstruiranja, te njihove agregacije i asocijacije trebaju poslu~iti kao osnova za modeliranje aktivnosti i operacija sa viaih razina kompleksnosti (slika 5). Akciju mo~emo promatrati kao element upravljanja izvoenjem procesa konstruiranja koji se ugrauje u proces u tijeku njegova izvoenja. Drugim rije ima akcije su elementi upravljanja procesom koji se unaprijed planiraju prije izvoenja procesa da bi se realizirale (ovisno o uvjetima i situacijama) za vrijeme izvoenja procesa konstruiranja. Izvraavanje akcije u procesu konstruiranja Postavlja se pitanje na koji na in se mo~e rijeaiti izvraavanje (realizacija) planirane akcije u tijeku izvoenja procesa konstruiranja. Ve je re eno da e akcija biti jedan od gradbenih elemenata slo~enijih entiteta prikaza procesa konstruiranja - vora plana konstruiranja - koji je detaljno razraen u poglavlju 7.3. Instanca akcije sadr~i zapis akcije koji se openito sastoji od naziva objekta i procedure koju treba pozvati, te liste argumenata poziva. U tijeku izvoenja procesa konstruiranja treba takav zapis "dekodirati" u poziv odgovarajue operacije to no odreenog objekta, ato se mo~e realizirati postupkom tzv. "parsiranja". Pojedine klase akcija mogu sadr~avati joa i neke dodatne specifi ne elemente sintakse zapisa akcije. Stoga, da bi se pojednostavnila procedura dekodiranja svaka klasa akcije treba imati svoju operaciju dekodiranja koja "zna" kako se "obrauje" samo njena varijanta sintakse zapisa. Izvoenjem procesa konstruiranja treba upravljati procedura koja ima glavnu "nit kontrole" ("thread of control") nad cijelim sustavom, pa upravlja i procesom izvoenja vora plana konstruiranja. Procesiranje vora plana uklju uje obradu elemenata vora predvienim redoslijedom. vor pristupa svojim elementima preko referenci na njihove adrese. Dakle, kad procesiranje vora naie na element "akciju", nit kontrole predaje se tom objektu tako da se poziva njegova operacija dekodiranja, tj. obrade zapisa akcije. Rezultat takve obrade zapisa akcije su parametri potrebni za poziv operacije u itani u memoriju. Ovisno o klasi aktivirane akcije proces se mo~e nastaviti na dva na ina: aktivirana instanca akcije poziva svoju operaciju (sa "inicijaliziranim" argumentima) - takva operacija specifi na je za tu klasu akcije, tj. ona je njen "zadatak" - npr. u itavanje objekta iz baze aktivirana instanca akcije poziva operaciju nekog drugog objekta modela procesa konstruiranja i njoj predaje nit kontrole, koju ova po izvraavanju vraa akciji. U oba slu aja aktivirana instanca akcije nakon izvraavanja vraa nit kontrole procesu obrade vora (procesiranju vora).  INCLUDEPICTURE "linkane slike\\izvrsavanje akcije.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 33: Izvraavanje akcije u tijeku izvoenja procesa konstruiranja Konstruktoru se na ovaj na in omoguava da planira pozive operacija entiteta modela procesa konstruiranja, bez nu~nog znanja programiranja, ali uz uvjet poznavanja argumenata i naziva operacija objekata predlo~enog modela. Kako su objekti modeli entiteta iz realnog svijeta procesa konstruiranja, u enje koriatenje predlo~enog sustava ne bi trebalo predstavljati problem, jer konstruktor ne mora poznavati detaljnu strukturu operacija koje koristi kao akcije u procesu, odnosno zapis akcije slu~i mu kao su elje prema pozivima operacija. Ovako modeliran entitet "akciju" mo~emo promatrati i kao su elje izmeu operacija objekata i kontrole izvoenja procesa konstruiranja. Drugim rije ima, preko takvog su elja proces izvodi planirane operacije na objektima. Klasifikacija akcija Kako je ve navedeno akcija se ovdje modelira u kontekstu generiranja, transformiranja i prikaza informacija, pa se na tome temelji i predlo~ena klasifikacija akcija. Dakle primarni kriterij klasifikacije je na in djelovanja akcije na objekte modela procesa konstruiranja. Predla~u se slijedee vrste djelovanja akcija: mijenjanje stanja jednog ili viae objekata pridru~ivanjem novih vrijednosti atributima u itavanje objekta iz baze, spremanje objekta u bazu poziv operacije objekta poziv "vanjskih" programskih alata (npr. CAD modela) kreiranje novih instanci klasa ili brisanje iz memorije nepotrebnih (poziv konstruktora i destruktora odreene klase) slanje poruka konstruktoru i obrada odgovora prikaz stanja procesa (stanja jednog ili viae objekata) pregled skupova informacija u situacijama kad na temelju toga treba donositi odluke ili npr. provjeriti, kontrolirati, odobriti, sintetizirati, itd Hijerarhija klasa prikazana je na slici 34. Kao posebna grupa izdvojene su klase koje pozivaju operacije drugih klasa objektnog modela, te klase operacija su elja prema objektnoj bazi. Promjena vrijednosti atributa drugih objekata vrijedi samo za one atribute kojima je dozvoljen pristup izvan njihove klase (deklarirani kao "public").  INCLUDEPICTURE "linkane slike\\UML klasifikacija akcija.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 34: Prijedlog klasifikacije akcija Osnovni atributi akcije su: zapis akcije (operacije koju treba pozvati) prema specifi noj sintaksi svake klase akcije, te status zahtjeva za izvoenjem akcije i status izvraavanja akcije. Osnovna operacija akcije koja se nasljeuje od generi ke klase je obrada (dekodiranje) zapisa, meutim svaka klasa akcije ima svoju implementaciju operacije obrade zapisa. Su elje programskog alata U poglavlju o bazi parametara ve je razmatran transfer podataka iz objekata modela procesa konstruiranja prema "vanjskim programskim alatima". "Vanjskim" alatima smatraju se svi oblici ra unalne podrake koja se koristi u procesu konstruiranja. Naj eae e to biti razni numeri ki prora uni pisani u proceduralnim jezicima, no mo~e biti i npr. tabli ni kalkulator, ekspertni sustav, baza podataka, itd. Da bi se takvi oblici programske podrake integrirali sa objektnim modelom potrebno je koncipirati su elja programskih alata prema objektima modela. Entitet "su elje programskog alata" enkapsulira skup operacija za transfer podataka izmeu objekata modela procesa konstruiranja i programskih alata koji nisu dio objektnog modela procesa konstruiranja. Svaki pojedini "vanjski" programski alat treba imati svoju instancu su elja koje ga pokree i obavlja transfer podataka. Transfer podataka te e u oba smjera (slika 35). Su elja moraju poznavati strukturu baze parametara kao i strukturu ulazno/izlaznih podataka i na ine dobave podataka programskog alata kojem pripadaju. Pri konkretnoj implementaciji treba posebno voditi ra una o a~uriranju su elja pri eventualnim doradama programskih alata.  INCLUDEPICTURE "linkane slike\\poziv programskog alata.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 35: Transfer vrijednosti parametara preko su elja programskog alata Atributi su elja programskog alata: naziv programskog alata, putanja do izvrane datoteke, putanje do ulaznih i izlaznih datoteka, status programskog alata (obzirom na dostupnost i pokretanje). Osnovne operacije su elja programskih alata su operacije transfera podataka u oba smjera. Vanjski programski alati pozivaju se koriatenjem posebne klase akcije koja aktivira su elje alata i predaje mu nit kontrole procesa. Instance takve klase akcija sadr~e reference na pripadajue instance su elja. Klasifikacija su elja programskih alata Klasifikaciju su elja programskih alata treba provesti primarno prema kriteriju razli itih na ina komuniciranja (pokretanja i transfera) sa vanjskim alatima koji nisu direktni dijelovi sustava modela procesa konstruiranja. Meutim treba uzeti u obzir i kriterije klasifikacije samih programskih alata. Prema oba navedena kriterija vrlo je teako precizno definirati klasifikaciju jer ona bitno ovisi o specifi nostima konkretnog okru~enja izvoenja procesa konstruiranja - koji programski alati se koriste, kojim metodama su razvijeni, te na kojem stupnju razvoja je koriatenje ra unalne podrake. Stoga e se ovdje predlo~iti nekoliko kriterija (aspekata) klasifikacije programskih alata koji se ne smatraju kona no definiranim niti potpunim: prema vrsti operacije koju programski alat obavlja, odnosno podr~ava : preliminarni ili kontrolni prora un dimenzija i/ili vrstoe strojnog dijela ili sklopa kalkulacija troakova (materijala, izrade i sl.) izbor izmeu razli itih varijanti rjeaenja na temelju skupa pravila generiranje crte~a strojnog dijela ili sklopa prema fazi procesa konstruiranja u kojoj se primjenjuje : u fazi koncipiranja vjerojatno e se esto koristiti ekspertni sustavi za izbor nosioca parcijalnih funkcija mogu poslu~iti baze znanja i katalozi principa rjeaenja u fazi projektiranja prete~no e se koristiti programi za tehni ke prora une i kalkulacije troakova u tijeku konstrukcijske razrade prete~no se koristi komercijalni CAD paket i procedure razvijene u njegovom makro jeziku prema vrsti programskog jezika ili programske platforme: program pisan u proceduralnom jeziku (npr. C, Fortran, Pascal); makro jezik komercijalnog CAD paketa; ljuska (shell) za ekspertni sustav; baza podataka; tabli ni kalkulator, itd. prema na inu zadavanja ulaznih i ispisa izlaznih podataka : koriste se datoteke, su elja za transfer koja su dio aplikacije ili kombinacije oba pristupa prema na inu izvoenja i slo~enosti programskog alata : samo jedna izvrana ( exe ) datoteka, ili viae komponenti (dodatne dinami ke biblioteke) posebni zahtjevi za okolinom izvoenja (to vrijedi za npr. makro procedure CAD sustava - mora biti aktivan i CAD sustav)  INCLUDEPICTURE "linkane slike\\UML klasifikacija SPA.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 36: Klasifikcija su elja programskih alata Slika 36 dijagram je klasifikacije su elja programskih alata po kriteriju vrste, odnosno namjene programskog alata. Predlo~ena klasifikacija samo je primjer za ilustraciju prethodnih razmatranja. Preciznija klasifikacija mo~e se odrediti tek pri implementaciji sustava u konkretno okru~enje, prema njegovim specifi nostima. Zadatak Nastojanja za unapreivanjem organizacije rada konstrukcijskog ureda promatraju i konstrukcijski zadatak u informati kom kontekstu. U takvom pristupu promatra se tok informacija izmeu zadataka, rokovi, resursi i odgovornosti. Entitet "zadatak" modelira informacijske tokove i organizacijske aspekte realnog konstruktorskog zadatka u okru~enju timskog rada. Prema VDI  REF _Ref409233023 \r \h [21] zadatak integrira slijedee informacije: ulazne podatke (zahtjeve), izlazne podatke - cilj (funkcije i karakteristike), rokove, troakove, i organizacijske podatke. Objekt "zadatak" treba dakle enkapsulirati sve navedene skupove informacija kao skupove svojih atributa ili kao skupove referenci na druge objekte modela procesa konstruiranja. Zadatak se mo~e promatrati i kao dio dekompozicije procesa konstruiranja u okru~enju timskog rada. Potreba za definiranjem zadatka kao objekta javljati e se kod vrlo slo~enih konstrukcija, gdje na pojedinim sklopovima rade grupe konstruktora, te postoji i hijerarhija odgovornosti i rukovoenja unutar i izmeu grupa. U takvim slu ajevima zadatak modelira i enkapsulira i sve potrebne organizacijske informacije. Pri tome jedan zadatak mo~e rjeaavati jedan ili viae konstruktora. Sadr~aj zadatka Informacije koje zadatak treba integrirati (enkapsulirati) mogu se podijeliti na dvije osnovne grupe: zahtjevi i ciljevi zadatka - mogu biti zapisani u nekoliko oblika: zahtijevane funkcije i karakteristike dijela konstrukcije koji je predmet zadatka Za varijantne i ponovljene konstrukcije: reference na parametre iju vrijednost i/ili statuse treba odrediti (ti parametri ve postoje kao instance) lista parametara koje treba generirati (kreirati) i odrediti im vrijednost reference na ve postojee objekte prikaza proizvoda koje treba razraditi i lista objekata prikaza koje treba kreirati - sa ~eljenim vrijednostima statusa takvih objekata organizacijski podaci: atributi zadatka: naziv, po etak, planirani zavraetak, odgovorna osoba, status: nije po et, u izradi, zavraen zapisi informacijske zavisnosti o drugim zadacima u procesu - reference na druge zadatke koji su informacijski spregnuti sa odreenim zadatkom Svi navedeni oblici zapisa zahtjeva i ciljeva zadatka ne mogu se za sve vrste konstrukcija unaprijed isplanirati, nego se oni formiraju u tijeku izvraavanja zadatka (parametri i objekti prikaza proizvoda). Razrada relacija zadatka s drugim objektima modela procesa konstruiranja dana je u poglavlju 7.2, a implementacija je razraena u osmom poglavlju. Konstruktor Entitet "konstruktor" enkapsulira informacije i operacije vezane uz osobe iz konstrukcijskog tima, organizaciju i podjelu rada i odgovornosti, te hijerarhiju kontrole pristupa dokumentima koji su proizvod procesa konstruiranja. Skup instanci "konstruktora" modelira dogaaje i pojmove vezane za osobe i njihove interakcije kao "izvoa e" procesa konstruiranja. Ovaj objekt sadr~i slijedee osnovne skupove referenci: - na dodijeljene zadatke - na objekte prikaza proizvoda i objekte strukture proizvoda za koje je odgovoran Ovi skupovi referenci omoguavaju koncipiranje i kreiranje operacija za podraku planiranju i praenju rokova i optereenja u okru~enju timskog rada. Takve operacije mogu dati pregled stanja (dovraenosti) zadataka i objekata prikaza proizvoda na kojima radi jedan konstruktor ili grupa konstruktora. Osnovni atributi objekta "konstruktor": ime i prezime, funkcija, odnosno polo~aj u hijerarhiji rukovoenja. Eventualna klasifikacija mo~e se provesti pri implementaciji sustava prema specifi nostima konkretnog ureda i njegovoj organizaciji rada. Prava pristupa pojedinog konstruktora odreenoj klasi objekata modela procesa konstruiranja mogu se zapisivati u obliku atributa svake klase. Asocijacije u obrnutom smjeru - zapisivanje u svakoj instanci konstruktora emu sve ima pristup bilo bi kompliciranije realizirati, a i rezultirale bi velikim brojem referenci. Model organizacije prava pristupa dokumentima specifi an je za svako konkretno okru~enje, stoga se ova problematika detaljnije ne razmatra, odnosno treba ju rjeaavati pri implementaciji sustava. Objekt "konstruktor" mo~e sadr~avati i atribute i operacije za modeliranje komunikacije (slanje poruka) meu lanovima tima. Takve poruke generiraju se direktno iz operacija, u tijeku izvoenja procesa konstruiranja (ovdje se ne misli na poruke koje aalje "konkretni" konstruktor izvan konteksta operacija objektnog modela procesa konstruiranja). Primjer takvih poruka je razmjena prijedloga i argumenata u situacijama izvoenja informacijski spregnutih zadataka. U voru plana mogu se unaprijed isplanirati akcije koje e poslati poruke drugom konstruktoru, ovisno o nastaloj situaciji. Relacije u objektnom modelu procesa konstruiranja Prema  REF _Ref409236024 \r \h [98] relacije su konceptualne ili konkretne tvorbe koje povezuju dva ili viae drugih entiteta. Zna enje veze mo~e se definirati na razli ite na ine unutar razli itih semanti kih modela  REF _Ref409251031 \r \h [129]. Osnovni strukturalni elementi modela procesa konstruiranja meusobno su zavisni i povezani na mnogo razli itih na ina, tj. topologija prostora relacija izmeu elemenata ima oblik mre~e u kojoj je svaki vor (koji prikazuje element) povezan sa veinom drugih vorova. Stoga model procesa treba sadr~avati posebne klase objekata za prikaz i manipulaciju sa relacijama izmeu entiteta modela. Takve relacije mogu biti izmeu gradbenih elemenata modela meusobno, kao i izmeu gradbenih i kompozitnih elemenata. Openito, model treba imati mogunost zapisa relacija izmeu bilo koje dvije vrste elemenata.  INCLUDEPICTURE "linkane slike\\graf relacije.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 37: Grafi ki prikaz binarne relacije U teoriji skupova relacija se definira kao podskup Kartezijevog produkta dva skupa AxB: R ( AxB = { (a,b) ( R | a ( A, b ( B } Primjer grafi kog prikaza relacije prikazan je na slici 37. Kako klasificirati relacije, odnosno koje su mogue vrste relacija? Analizirajui postojee informacijske modele, nailazi se na razli ite klasifikacije relacija. Relacija je openiti pojam kojim se ozna ava povezivanje entiteta, istog ili razli itog tipa. Broj entiteta povezanih jednom relacijom odreuje dimenzionalnost, te se stoga mogu razlikovati binarne i viaestruke relacije. Relacije, takoer, mogu biti usmjerene, od jednog objekta ka drugom, a neki informacijski modeli podr~avaju i viaesmjerne relacije (multidirectional). U predlo~enom modelu osloniti emo se na klasifikaciju relacija prema autorima UML-a  REF _Ref409667260 \r \h [101] koji modeliraju (koriste) etiri vrste relacija: generalizacija (specijalizacija) asocijacija relacija zavisnosti realizacija Relacije generalizacije u objektom modelu implementiraju se postavljanjem hijerarhije klasa. U daljnjim razmatranjima veinom emo se baviti asocijacijama izmeu elemenata modela procesa konstruiranja. Va~no je uzeti u obzir da tijekom izvoenja procesa konstruiranja dolazi do generiranja novih veza izmeu objekata u modelu procesa, ato zna i da elementi za prikaz relacija ne bi trebali biti stati ne strukture, jer se njihov sadr~aj stalno mijenja. Matri ni prikaz relacija Od posebnog su interesa za predlo~eni model procesa konstruiranja relacije zavisnosti i asocijacija izmeu entiteta modela. Neki pristupi modeliranju procesa konstruiranja, npr.  REF _Ref409180606 \r \h [130],  REF _Ref409180678 \r \h [110] koriste matri ne prikaze relacija izmeu objekata u procesu konstruiranja. U matri nom obliku relacija se prikazuje kao "oznaka" u eliji matrice koja indicira postojanje zavisnosti izmeu elementa stupca i retka kojima elija pripada. Takav prikaz zapravo je analogan grafu relacije prikazanom na slici 37. Naj eaa upotreba matri nog prikaza relacija u istra~ivanjima metoda unapreenja procesa konstruiranja je matri ni prikaz informacijske zavisnosti konstrukcijkih zadataka, tzv. "design structure matrix", koji je predlo~io Steward  REF _Ref409180871 \r \h [111],  REF _Ref409180873 \r \h [112]. Zapis relacija u matri nom obliku pogodan je zbog toga ato se u relativno kompaktnom obliku mo~e dobiti pregled meusobnih zavisnosti unutar veih skupova objekata ato mo~e biti zna ajno za planiranje redoslijeda izvoenja zadataka u procesu konstruiranja. Osim informacijske zavisnosti u matri nom obliku mogu se zapisati i drugi oblici veza izmeu objekata (npr. relacije pripadnosti, referenciranja, "odgovornosti za" i sli no). Jedan od nedostataka matri nog prikaza je u injenici da zapis "oznake" u eliji matrice samo indicira postojanje relacije (veze), dok niata ne govori o svojstvima (semantici) instance relacije. Taj problem mo~e se djelomi no rijeaiti na viae na ina: klasifikacijom oznaka, pri emu svaka oznaka ima odreeno zna enje zapisom relacije u eliju matrice (koji mo~e biti djelomi no skriven pri prikazu matrice (npr. kao zapis komentara u eliju u programskom paketu MS Excel) tako da se u eliju matrice zapisuje pokaziva  na puni zapis i opis relacije Matri ni prikaz relacija izmeu skupova objekata mo~e biti prili no nepregledan ako broj stupaca i redaka (odnosno elemenata) bude puno vei od deset do dvadeset. Za takve situacije potrebno je razraditi procedure koje prikazuju samo odreeno relevantno podru je matrice, kao ato je npr. rijeaeno u  REF _Ref409239013 \r \h [5]. Druga mogunost je razbijanje osnovne matrice na submatrice (podmatrice) da bi se manipuliralo samo sa onim podru jem matrice koje je za danu situaciju relevantno. Na ovaj na in mogu se pojednostavniti operacije pregledavanja i a~uriranja sadr~aja velikih matrica. Primjer submatrice prikazan je na slici 38. Submatrica je reducirani prikaz matrice dobiven brisanjem stupaca 1, 4, 6 i 7, te brisanjem redaka 1, 3, 4, i 7. Ovakav pristup podrazumijeva razradu svih potrebnih operacija za dinami ka definiranja i manipulaciju sa submatricama. U ovakvom pristupu samo jedan redak ili stupac matrice takoer se mogu promatrati kao submatrice. 123456781xx2xx23583xxx2x4xx(5xx5xxx6x6xx8x7x8xxSlika  SEQ Slika \* ARABIC 38: Osnovna matrica i jedna varijanta submatrice Razmotrimo joa graf relacije izmeu dva skupa (slika 37). Neka su elementi skupova A i B instance klasa (skupovi objekata) koje implementiraju entitete modela procesa konstruiranja. Matri ni prikaz sa "ozna enom elijom" analogan je takvom grafu relacije. Realno je pretpostaviti da e veina grafova relacija izmeu dva skupa objekata imati malen broj "ozna enih" elija u odnosu na ukupni broja elija, odnosno da e relacija biti "malen" podskup kartezijevog produkta skupova A i B. U takvim slu ajevima matri ni prikaz (graf relacije) mo~e se u prikazu svesti na listu sa dva stupca (slika 39). U lijevom stupcu liste svi su elementi skupa A, a u desnom stupcu liste zapisuju se (u jednoj eliji) oznake (redni brojevi) svih elemenata skupa B koji su u relaciji sa elementom skupa A. Na taj na in svi stupci matrice svode se na jedan. Ovakav na in prikaza matrice ima smisla u slu ajevima kad je broj "ozna enih" elija matrice u recima znatno manji od broja stupaca matrice. Trei stupac takvog prikaza mo~e sadr~avati zapis semantike relacije, ako je element skupa A povezan na semanti ki isti na in sa svim elementima skupa B. Primjer takvog zapisa je npr. algebarska jednad~ba ai = f ( bj ). b1b2b3b4b5b6& .bnelementi skupa Bsemantika relacijea1xa1b4a1= (b4)2a2xxa2b3,b6a2=b3+b6a3xxa3b4,b5..a4x(a4b2a5xxxa5b2,b4,bn..anxxanb5,b6Slika  SEQ Slika \* ARABIC 39: Preslikavanje matrice u listu U osmom poglavlju biti e pokazano kako se matri ni prikaz relacije sveden na listu mo~e realizirati pri implementaciji sustava. Potrebno je postaviti dvije asocijacije izmeu klasa A i B koje predstavljaju skupove svojih instanci, odnosno elemente skupova A i B. Pri tome se asocijacije realiziraju skupovima pokaziva a ("pointera"). Mre~a relacija izmeu entiteta modela procesa konstruiranja Razmotrimo sada koje vrste entiteta i na koji na in treba povezivati u modelu procesa konstruiranja. Za tu svrhu formirana je matrica u kojoj su elementi redaka i stupaca osnovni gradbeni (strukturalni) entiteti modela procesa konstruiranja (tablica 3). Openito gledano, u logi kom modelu procesa konstruiranja mogle bi se postavljati relacije izmeu svih definiranih entiteta, odnosno mogli bi promatrati mre~u veza u kojoj je svaki entitet povezan sa svim ostalim entitetima. Ova razmatranja klju na su za hipotezu rada, jer e pri razradi implementacije sustava biti pokazano da je objektni model pogodan za modeliranje i realizaciju takve mre~e relacija, odnosno mre~ne topologije procesa konstruiranja. Drugim rije ima ovako postavljeni logi ki model mre~e relacija mogue je preslikati u objektni model, realiziran u objektnoj bazi, ato e biti pokazano u osmom poglavlju. Jasno je da e neke od relacija (iz mre~e svih moguih relacija) biti za modeliranje procesa konstruiranja bitno zna ajnije od drugih, i isto tako je jasno da neke relacije nee imati smisla postavljati u kontekstu modelu procesa konstruiranja. Matrica prikazana tablicom 3 prikazuje mre~u relacija izmeu entiteta koji se u objektnom modelu preslikavaju u klase. Klase u konkretnom modelu sadr~e skupove instanci, tj. skupove objekata. Tako svaku eliju ove matrice mo~emo promatrati kao jednu relaciju izmeu skupova instanci dviju klasa, a itavu matricu kao skup takvih relacija. Oznaka "x" matrice stavljena je u one elije matrice, za koje se smatra da ima smisla modelirati relacije izmeu takvih objekata, a oznake "?" teme su za razmatranje. Predlo~ena shema razmatra samo binarne veze (izmeu dva elementa). Sve oznake su ispod dijagonale matrice - razmatra se samo povezivanje elemenata (bez uzimanja u obzir smjera veze). Razli iti smjerovi asocijacija biti e razmotreni kasnije (npr. "P-A" i "A-P"). U daljnjem tekstu razmotrene su predlo~ene varijante relacija uz osvrt na mogunosti primjene. Vrijedno bi bilo razmotriti i mogue slo~enije veze izmeu viae elemenata (viaestruke relacije), meutim za te slu ajeve vjerojatno bi se prikaz takvih veza u matri nom obliku pokazao nepogodnim. PBPPPOSPSPAAZKOPPparametri Pxbaza parametaraBP??prikaz proizvodaPPx?xobjekt strukture proizvodaOSPx?xxsu elje programskog alataSPAx?xx?akcijaA????x?zadatakZx?xx??xkonstruktoriK??xx??x?objekti prikaza procesaOPPx?xxxxx?xTablica  SEQ Tablica \* ARABIC 3: Povezivanje strukturalnih elemenata modela procesa konstruiranja Relacije izmeu strukturalnih elemenata modela procesa konstruiranja naj eae e biti informacijske zavisnosti ili relacije pripadnosti. U daljnjem tekstu razraditi e se prikazi onih relacija izmeu skupova objekata modela procesa konstruiranja koji po mialjenju autora trebaju biti elementi modela. Pri tome e se kao metoda zapisa relacije koristiti matrica ili matrica svedena na listu. U ovim razmatranjima ograni iti emo se samo na binarne relacije. Izlo~eni matri ni prikaz (poglavlje 7.2.1 i tablica 3) dan je stoga primarno kao teorijski model za razmatranje skupa (mre~e) relacija izmeu entiteta modela. Entiteti se preslikavaju u klase, tj. relacije se postavljaju izmeu skupova instanci dviju klasa ili unutar skupa instanci iste klase. Matrica informacijske zavisnosti konstrukcijskih zadataka Najzna ajnija relacija unutar predlo~enog skupa entiteta modela procesa konstruiranja svakako je prikaz informacijske zavisnosti izmeu konstrukcijskih zadataka. Ovo je relacija na skupu instanci konstrukcijskih zadataka koju emo razmatrati u matri nom zapisu. Istra~ivanja mogunosti unapreenja organizacije procesa konstruiranja, temeljena na analizi ovakvog matri nog prikaza po inju osamdesetih godina  REF _Ref409180871 \r \h [111],  REF _Ref409180873 \r \h [112]. Kako je ve navedeno, uobi ajen naziv ovakvog prikaza u literaturi je "Design Structure Matrix". Zna ajna istra~ivanja organizacije konstrukcijskih zadataka u procesima istovremenog in~enjerstva provode Eppinger  REF _Ref409180678 \r \h [110],  REF _Ref409173569 \r \h [113], i Rogers  REF _Ref409173839 \r \h [114],  REF _Ref409173842 \r \h [115]. Wallace  REF _Ref409239013 \r \h [5] koristi ovu matricu kao jedan od elemenata za prikaz toka informacija u sustavu integracije programskih alata za podrku konstruiranju. Slika 40 prikazuje matricu u njenoj originalnoj binarnoj formi prema  REF _Ref409180871 \r \h [111],  REF _Ref409180873 \r \h [112]. Konstrukcijski zadaci prikazani su identi nim oznakama u stupcu i retku matrice. Ozna ene elije pokazuju koji zadaci moraju osigurati informacije da bi se odreeni zadatak mogao izvraiti. ovisi o:12345678910zadatak 11zadatak 22xzadatak 33xzadatak 44xxzadatak 55xxzadatak 66xxzadatak 77xzadatak 88xxzadatak 99zadatak 1010xx Slika  SEQ Slika \* ARABIC 40: Matrica prikaza informacijskih zavisnosti konstrukcijskih zadataka  Slika  SEQ Slika \* ARABIC 41:"Neorganizirana matrica" Slika  SEQ Slika \* ARABIC 42:Ista matrica nakon reorganizacije Razmotrimo primjer matrice sa slike 41. Oznake u retku D postoje u stupcima E, F i L, to zna i da izvoenje zadatka D zahtijeva transfer informacija iz zadataka E, F i L. Iz toga slijedi da bi se tri spomenuta zadatka trebala izvraiti prije zadatka D. Dijagonalni elementi ove matrice nemaju nikakvog zna enja. Prvi korak analize strukture ove matrice (procesa konstruiranja) je iznala~enje redoslijeda izvoenja konstrukcijskih zadataka u kojem bi sve oznake u matrici bile ispod glavne dijagonale. U tom slu aju svi zadaci bi se izvodili tek nakon ato prime sve potrebne informacije od svojih prethodnika. Na~alost takve situacije se rijetko mogu postii u praksi, pogotovo ako se u proces proizvodnje (i konstruiranja) nastoji uvesti istovremeno in~enjerstvo ("concurrent engineering"). Slika 42 prikazuje matricu sa slike 41 nakon ato je zamjenom redaka i stupaca promijenjen redoslijed izvraavanja zadataka s ciljem da ato manje relacija bude iznad glavne dijagonale. Postupci reorganizacije redoslijeda izvraavanja zadataka redovito kao rezultat daju matricu u kojoj se mogu uo iti blokovi veza oko glavne dijagonale. Blokovi na dijagonali pokazuju informacijske sprege zadataka uzrokovane povratnim vezama. Preostale veze ispod glavne dijagonale prikazuju "isporuku" informacija zadacima koji slijede. Reorganizirana matrica (slika 42) pokazuje da zadatak C ovisi o zadatku B, dakle redoslijed izvraavanja je B-C. Zadaci A i K ovise oba o zadatku C, ali se mogu izvoditi paralelno (jer A i K ne ovise meusobno). "Blokovi" koji sadr~e zadatke L-J-F-I i E-D-H prikazuju dva skupa spregnutih zadataka. Problem izvoenja skupova spregnutih zadataka predstavlja veliki izazov pri uvoenju metoda istovremenog in~enjerstva, makar se takva situacija mo~e pojaviti i u druga ije organiziranim procesima konstruiranja. Slika 43, prema  REF _Ref409180678 \r \h [110] prikazuje tri navedene situacije iz matrice na primjeru izvoenja dva konstrukcijska zadatka.  Slika  SEQ Slika \* ARABIC 43: Tri mogua redoslijeda izvraavanja dva konstrukcijska zadatka Za spregnute zadatke teako je odrediti redoslijed njihova izvraavanja, esto e to biti nekoliko iterativnih ciklusa. Skup spregnutih zadataka trebao bi se izvoditi simultano, a transfer informacija koje uzrokuju spregnutost mogao bi poprimiti oblik pregovaranja izmeu "izvoa a" zadataka. U takvim situacijama od zna ajne koristi trebao bi biti atribut "status vrijednosti" u objektu "parametar konstrukcije". Naime, pri simultanom izvoenju skupa spregnutih zadataka, odreene informacije ije vrijednosti joa zadatku nisu poznate morati e biti pretpostavljene. Pretpostavke e kasnije morati biti korigirane, ato zna i da e se zadaci izvoditi u nekoliko iterativnih ciklusa. Parametri koji uzrokuju spregnutost skupa zadataka svakako trebaju biti spremljeni u bazu parametara jer se na taj na in mo~e realizirati koordinacija odnosno "pregovaranje" o trenutnoj vrijednosti i statusu zajedni kih informacija, odnosno podataka (parametara). U dosadaanjim istra~ivanjima primjene prikazane matrice razvijeno je nekoliko metoda reorganizacije redoslijeda izvraavanja zadataka: metoda temeljena na binarnoj matri noj algebri  REF _Ref409180249 \r \h [131] metode temeljene na ekspertnim sustavima i geneti kim algoritmima  REF _Ref409173839 \r \h [114],  REF _Ref409173842 \r \h [115] postupci prema  REF _Ref409180371 \r \h [132] Proairenja i mogunosti primjene matrice zavisnosti konstrukcijskih zadataka U binarnom obliku zapisa matrica zavisnosti konstrukcijskih zadataka prikazuje samo da li neki zadatak informacijski ovisi o drugome ili ne. Binarni podatak niata ne govori o "ja ini", odnosno zna aju te povezanosti. Eppinger  REF _Ref409270389 \r \h [51] stoga uvodi u matricu "te~inski faktor" zavisnosti zadataka, a u glavnu dijagonalu zapisuje pretpostavljeno vrijeme trajanja zadatka. U takvom pristupu algoritmi reorganizacije redoslijeda nastoje bli~e glavnoj dijagonali smjestiti oznake s veom vrijednosti te~inskog faktora. U dosta slu ajeva spregnutost zadataka teako je izraziti numeri ki. Nadalje, svaki element matrice mogao bi biti vektor, odnosno niz vrijednosti koje na razli it na in izra~avaju zavisnost zadataka. Umjesto "te~inskog faktora" mo~e se uvesti i klasifikacija povezanosti zadataka. Eppinger predla~e razlikovanje "ulaza", "kontrole" i "povratne veze". Svaki od takvih razli itih pristupa zahtijeva i druga ije analiti ke postupke reorganizacije redoslijeda izvoenja zadataka. Ovisno o potrebama i slo~enosti procesa konstruiranja u odreenoj situaciji (okolini) mogu se modelirati razli ite podklase matrice zavisnosti konstrukcijskih zadataka, sa razli itim prikazima i postupcima reorganizacije redoslijeda zadataka. Zapis zavisnosti konstrukcijskih zadataka u matri nom obliku svoju primjenu u procesu konstruiranja treba nai prvenstveno kao podloga planiranju i praenju redoslijeda izvoenja zadataka u procesu konstruiranja. U okru~enjima gdje je proces konstruiranja vrlo slo~en, sa veim timovima ljudi i vrlo slo~enim proizvodima, ova metoda mo~e dati zna ajni doprinos, pogotovo ako se nastoji uvesti paralelno (istovremeno) in~enjerstvo. U takvim slu ajevima primjene, mogu se ustanoviti blokovi informacijski spregnutih zadataka. Takav zapis mo~e slu~iti kao podloga za unapreenje rjeaavanja iteracijskih procesa, kao i za eventualno redefiniranje strukture konstrukcijskih zadataka. Relacije zavisnosti parametara konstrukcije Relacije zavisnosti izmeu parametara konstrukcije najbrojnije su i najslo~enije u procesu konstruiranja. Veina tih zavisnosti algebarske su jednad~be, ali mogu se javljati i drugi oblici zavisnosti. Proces rjeaavanja sustava jednad~bi s parametrima konstrukcije jedna je od klju nih aktivnosti (podprocesa) u procesu konstruiranja. Strukture sustava jednad~bi u procesu konstruiranja razmatraju se u  REF _Ref409241353 \r \h [120]. Autori daju i prijedloge reformulacija strukture kojima se mo~e smanjiti razina kompleksnosti sustava i unaprijediti proces odlu ivanja. Slo~ene konstrukcije na kojima radi tim konstruktora sadr~e veliki broj (prete~no geometrijskih) parametara ije meuzavisnosti je potrebno sistematizirati i organizirati u zajedni kom obliku zapisa. Prijedlog takvog zapisa u izlo~enom modelu procesa konstruiranja je matrica relacija zavisnosti izmeu parametara konstrukcije. Matri ni zapis meuzavisnosti parametara konstrukcije analogan je zapisu zavisnosti zadataka konstrukcije. Oznaka "x" u eliji matrice zna i da odreeni parametar ovisi o drugom parametru (tablica 4). Zapis u jednom retku pokazuje o kojim sve parametrima ovisi odreeni parametar: pi = f ( p j ). p1p2p3p4p5& .pnparametar 1p1xxparametar 2p2xxparametar 3p3parametar 4p4xparametar 5p5x . . . . .. . . .parametar npnxTablica  SEQ Tablica \* ARABIC 4: Matrica zavisnosti parametara konstrukcije Realno je o ekivati da e svaka malo slo~enija konstrukcija sadr~avati veliki broj parametara. Postavlja se pitanje ato u initi s matri nim prikazom u takvim slu ajevima, jer postaje velik i nepregledan, s malim brojem ozna enih elija. Pri manipulaciji sa prikazom zavisnosti parametara mogu se koristiti podmatrice, (prema shemi iz poglavlja  REF _Ref409184075 \r \h 7.2.1, odnosno prikazivati samo ona podru ja matrice koja su trenutno interesantna. Drugo je pitanje kako zapisati matricu reda veli ine npr. pribli~no 1000 parametara, dakle ukupno 106 elija. Svakako da nema smisla zapisivati sve vrijednosti elija, jer e vrlo vjerojatno samo mali postotak imati "oznaku" postojanja zavisnosti. Dovoljno je uz svaki parametar zapisati samo adrese, odnosno redne brojeve stupaca drugih parametara o kojima on ovisi. Iz takvog se zapisa jednostavnim algoritmom mo~e generirati i matri ni prikaz (odnosno podmatrica odreenog podru ja) u situacijama kada je to potrebno. Postupak preslikavanja matrice u listu ve je razmatran i prikazan na slici 39. Tablica 5 prikaz je matrice zavisnosti parametara konstrukcije svedene na listu sa tri stupca. Drugi stupac matrice sadr~i adrese parametara o kojima ovisi odreeni parametar, a trei stupac sadr~i zapis semantike zavisnosti: pj = f ( pi, i ( {1, & . n}, i ( j ), gdje je n broj svih definiranih parametara u bazi parametara. redni br. parametra:ovisi o:zapis jednad~bi zavisnostip1p2, p4, p78p1 = f (p2, p4); p1 = f (p2, p78)p2p1, p5, p36p2 = f (p1, p5, p36)p3p24, p78. . . . .p4p2, p20, p35p5p4, p153. . . . .. . . . .pjpi, i ( {1, & n}, i ( jpj = f ( pi, i ( {1, & . n}, i ( j ). . . . .. . . . .. . . . .pnTablica  SEQ Tablica \* ARABIC 5: Shema zapisa zavisnosti parametara konstrukcije Funkcija f zavisnosti parametara naj eae e biti jedna ili viae algebarskih jednad~bi, no mo~e biti i druga vrsta funkcije, ovisno o vrsti parametra (npr. funkcija mo~e biti u obliku "if-then" pravila). Zapis zavisnosti parametara konstrukcije mo~e nam dati joa jednu vrlo korisnu informaciju. esto je posebno va~no znati kako promjena jednog parametra utje e na ostale parametre u konstrukciji, odnosno koji sve parametri ovise o odreenom parametru? Takva informacija mo~e se dobiti kao rezultat upita ("query-a") u kojem se prikazuju svi reci liste u kojima se tra~eni parametar pojavljuje u drugom stupcu liste. Matrica zavisnosti parametara konstrukcije mo~e poslu~iti kao podloga za izradu matrice zavisnosti konstrukcijskih zadataka. Ukoliko se u matri nom obliku zapiau relacije pripadnosti svakog od parametra konstrukcijskim zadacima, interesantno bi bilo istra~iti da li je mogue realizirati algoritam koji bi na temelju zapisa u obje matrice automatski generirao matricu zavisnosti konstrukcijskih zadataka. Relacije "pripadnosti" izmeu razli itih klasa objekata U prethodna dva poglavlja razmatrane su relacije zavisnosti i mogunosti zapisa njihove semantike. Relacije "pripadnosti" jednostavnije su strukture jer nije potrebno posebno zapisivati semantiku relacije, nego samo nazna iti "ato emu pripada". Relacije pripadnosti u pravilu postoje izmeu skupova objekata dviju razli itih klasa. Zapis ovih relacija takoer se sa matri nog oblika mo~e svesti na listu sa dva stupca. Tablica 6 prikazuje primjer zapisa relacije pripadnosti objekata klase B objektima klase A. Desni stupac tablice sadr~i reference na neprazni podskup objekata klase B koji "pripadaju" odreenom objektu klase A. Pri tome je n broj objekata klase A, a k je broj objekata klase B. Objekti klase Aobjekti klase B koji pripadaju objektu klase A a1b2, b3, b12a2b3, b4a3b2, b10& & .& & & .aibi, i ( {1, & k}& & .& & & .an& & Tablica  SEQ Tablica \* ARABIC 6: Prikaz relacije "pripadnosti" izmu objekata dviju klasa Dalje slijede razmatranja nekoliko primjera relacija "pripadnosti". Sve takve relacije mogu se zapisati prema shemi prikazanoj u tablici 6. Koristei mogunosti objektne baze, ovakve skupove relacija relativno je jednostavno realizirati, kao i manipulirati s njima, ato e detaljnije biti prikazano u osmom poglavlju. Relacija objekt prikaza proizvoda - parametar Ova relacija odreuje (pokazuje) koji parametar "pripada" kojem objektu prikaza proizvoda, prema shemi iz tablice 6. Svaki objekt prikaza proizvoda sadr~i dakle svoj skup referenci na parametre ije vrijednosti su dio zapisa informacija o proizvodu kojeg taj objekt modelira. Gotovo redovito se vrijednosti nekih parametara zapisuju u viae prikaza proizvoda, odnosno ti parametri e biti referencirani u viae objekata prikaza proizvoda. Upravo ta injenica je i razlog modeliranja parametara kao objekata, ato je detaljnije ve razmotreno u poglavlju 7.1.2. Pri generiranje svake nove instance objekta prikaza proizvoda potrebno je upisati reference na parametre, odnosno zapisati novi redak u listu koja prikazuje relaciju. Iz predlo~ene sheme zapisa mogue je i dobiti pregled koji objekti "dijele", tj. koriste odreeni parametar. Takvi pregledi mogu biti zna ajni za situacije u procesu konstruiranja u kojima se objekti koji dijele isti parametar obrauju istovremeno. Osim referenci na parametre koji mu pripadaju, objekt prikaza proizvoda sadr~i i operacije su elja za transfer vrijednosti parametara prema zapisu informacija o proizvodu kojeg modelira. Ostale relacije "pripadnosti" Ovdje e se navesti primjeri joa nekoliko relacija "pripadnosti" izmeu razli itih klasa objekata koje se prema mialjenju autora mogu koristiti u modelu procesa konstruiranja: Relacija konstruktor - zadatak evidencija je dodjele zadataka konstruktorima. Relacija konstruktor - objekt prikaza proizvoda evidentira za koje je prikaze proizvoda pojedini konstruktor odgovoran. Relacija akcija - su elje programskog alata povezuje instance klase akcije za poziv programskog alata i su elje poziva programskog alata koje se koristi. Izrazi kao elementi zapisa ograni enja i pravila U poglavlju  REF _Ref409178290 \r \h 3.2.2 razmatrano je napredovanje kroz proces konstruiranja provjerom ograni enja i odlu ivanjem. Entiteti koji modeliraju etape procesa konstruiranja trebaju dakle uklju iti procese provjere i dodavanja ograni enja, kao i procese odlu ivanja temeljem analize skupova pravila. Provjera ograni enja i pravila odlu ivanja trebaju dakle biti dio strukture zapisa plana procesa konstruiranja. Konstruktor kreira plan konstruiranja u kojem treba predvidjeti i zapisati provjere ograni enja i skupove pravila na temelju kojih se donose odluke. Ograni enja i pravila detaljno se razrauju u slijedea dva poglavlja. Kao osnovni element zapisa ograni enja i pravila mo~e se izdvojiti "izraz". Pojam izraz (expression), analogan je u razmatranom kontekstu "izrazu" kao dijelu naredbe, kako se definira u gotovo svim programskim jezicima - kao niz sintakti kih elemenata koji se sastoji od operanada i operatora. Ako se izraz interpretira kao ograni enje ili kao uvjet u pravilu, tada se odreuje njegova vrijednost kao istina ili la~. Izraz je dakle leksi ka struktura kojom se formiraju zapisi provjere ograni enja i pravila odlu ivanja. Izraz se mo~e definirati i kao "predikatna formula" nad datim jezikom. Izraz se sastoji od operanada i operatora, gdje su operandi atributi objekata modela procesa konstruiranja ili numeri ke ili znakovne konstante. Pri tome izraz mora sadr~avati barem dva operanda (od kojih bar jedan treba biti atribut objekta) i barem jedan operator. izraz ::= <operand> | <operator> | <operand> { <operator> | <operand> } operand ::= <varijabla> | <konstanta> operator ::= <aritmeti ki operator> | <relacijski operator> | <logi ki operator> | <zagrada> varijabla ::= #naziv_objekta.naziv_atributa konstanta ::= <numeri ka konstanta> | <znakovna konstanta> logi ki operator ::= <&&> | <||> | <and> | <or> aritmeti ki operator ::= <+> | <-> | <*> | </> | relacijski operator ::= <=> | <(> |<<=> | <>=> | <<> | <>> zagrada ::= <(> | <)> Slijedi nekoliko primjera izraza. U primjerima nazivi objekata su skraeni na oblik "p i", a atributi na "v" (vrijednost) i "s" (status). #p1.v = #p3.v - #p5.v / 2.81 #p20.v = ' 4732' or #p20.v = ' 1531' #p4.s = 'prijedlog' or #p4.s = 'neodredjen' #p1.v + #p3.v > #p8.v / 10.5 #p1.v > 10 and #p2.s = 'odredjen' #p5.v > #p3.v or (#p2.v +10) < #p4.v Osnovni operandi izraza su varijable koje su atributi objekata. Varijabla se sastoji od naziva objekta i naziva atributa tog objekta. Na ovaj na in u izrazima se mogu koristiti svi atributi svih objekata modela procesa konstruiranja. Ovdje pretpostavljamo da se domene varijabli i domene operatora u izrazu uvijek poklapaju, tj. da su izrazi semanti ki ispravni. Izraz se zapisuje kao niz znakova u tijeku kreiranja plana konstruiranja. Vrijednost izraza odreuje se "parsiranjem" u tijeku izvoenja plana konstruiranja. Postupkom parsiranja varijablama se dodjeljuju trenutne vrijednosti atributa objekata, primjenuju se operatori i odreuje se da li je izraz istinit ili ne. Osim samog zapisa izraza kao niza znakova, instanca klase "izraz" sadr~i i skup pokaziva a (pointera) na objekte iji atributi se pojavljuju kao elementi (varijable). Implementacija tako postavljene strukture biti e detaljnije razraena u osmom poglavlju. Prethodna razmatranja promatraju "izraz" samo kao leksi ku strukturu, bez obzira na njegovo zna enje u kontekstu izvoenja procesa konstruiranja. Izrazi se mogu koristiti kao elementi provjere ograni enja ili kao uvjeti u skupovima pravila odlu ivanja. Izrazi trebaju dakle biti elementi klase "ograni enje" i klase "pravilo". Za oba slu aja operacija parsiranja, odnosno sintaksa izraza je ista, samo je razli it kontekst uporabe izraza. Klase "ograni enje" i "pravilo", dijele dakle istu formu zapisa izraza i operaciju parsiranja izraza. Izraz se onda mo~e modelirati kao klasa sadr~ana u spomenutim klasama ili ograni enja i pravila trebaju sadr~avati pokaziva e na pripadajue instance izraza. Ograni enja Proizvod koji se konstruira mora zadovoljiti skup funkcionalnih zahtjeva. Funkcionalni zahtjevi ispunjavaju se indirektno mijenjanjem jednog ili viae parametara konstrukcije, fizi kog oblika i operativnih uvjeta  REF _Ref409241353 \r \h [120]. Uobi ajeno je da se funkcionalni zahtjevi izra~avaju kao funkcije parametara konstrukcije, drugih funkcionalnih zahtjeva i razli itih "internih varijabli" ("prijelaznih ili pomonih" varijabli)  REF _Ref409241353 \r \h [120]. Interne varijable i parametri konstrukcije ine vektor nepoznanica konstrukcije P = [p1, p2, p3, & , pn]. Funkcionalni zahtjevi ine vektor F = [F1, F2, F3, & , Fn]. Relacije izmeu zahtjeva i nepoznanica mogu se izraziti kao: fi ( F, P ) = 0 i = 1, k gj ( F, P ) ( Gj j = 1, s Navedene jednad~be i nejednad~be u terminologiji znanosti o konstruiranju nazivaju se "ograni enja". Pri tome neke od navedenih relacija ne moraju sadr~avati funkcionalne zahtjeve, nego samo parametre i "interne varijable". Treba napomenuti da relacije ograni enja nisu relacije zavisnosti izmeu parametara, (razmatrane u poglavlju  REF _Ref409436808 \r \h 7.2.4) makar se u nekim slu ajevima mogu i poklapati. Proces konstruiranja napreduje kroz postavljanje i zadovoljavanje ograni enja. Stoga model procesa konstruiranja mora sadr~avati postupke kreiranja i provjere ograni enja. U predlo~enom modelu procesa konstruiranja nepoznanice konstrukcije i funkcionalni zahtjevi modelirani su kao atributi razli itih klasa objekata. Dakle mo~emo rei da ograni enja definiraju prostor prihvatljivih vrijednosti atributa objekata  REF _Ref409269474 \r \h [7]. Promatrajui tijek (napredovanje) procesa konstruiranja, ograni enja se provjeravaju kao preduvjeti i postuvjeti koji moraju biti ispunjeni u odreenim situacijama, odnosno etapama procesa. Rezultat provjere ograni enja samo je informacija da li je ono ispunjeno ili ne. Proces provjere ograni enja nema nikakvog utjecaja na atribute objekata koji su sadr~ani u relaciji ograni enja. Entitet "ograni enje" modelira zapis i proces provjere ograni enja, te sadr~i slijedee atribute: pokaziva  (pointer) na zapis izraza koji sadr~i jednad~bu ili nejednad~bu ograni enja opis - dodatni komentari i pojaanjenja vrsta upozorenja ako ograni enje nije ispunjeno - nema upozorenja, ispis poruke, ispis poruke i prekid procesa status ograni enja kod zadnje provjere: ispunjeno, nije ispunjeno status provjeravanja: aktivno - provjerava se, pasivno - joa se ne provjerava zapis stanja svih provjera u tijeku procesa Ograni enje sadr~i pokaziva  na izraz ija se istinitost provjerava. Izraz je leksi ka struktura prema sintaksi predo enoj u poglavlju  REF _Ref409437152 \r \h 7.2.6. Operacija parsiranja izraza odreuje da li je izraz istinit (ograni enje zadovoljeno) ili nije. Veina provjera ograni enja biti e zapravo grani ni uvjeti iterativnih procesa. Zapis stanja atributa u trenutku provjere ograni enja mo~e biti korisna informacija za donoaenje odluka u slijedeim koracima iteracije. Isto tako konstruktor mo~e zapisati i obrazlo~iti (u obliku teksta) ato je poduzeo u svakom koraku iteracije u kojem ograni enje nije bilo ispunjeno. Na taj na in zapisuju se informacije o procesu razvoja konstrukcije koje mogu biti izuzetno korisne za razvoj slijedeih varijanti konstrukcije. Takve vrijedne informacije naj eae ostaju nezabilje~ene i neiskoriatene. Jedan od pravaca istra~ivanja unapreenja ra unalne podrake konstruiranju upravo je orijentiran na spomenute probleme ("design intent and rationale capturing"). Operacije za generiranje i zapis ograni enja potrebno je koncipirati tako da se provjeravaju tipovi atributa, odnosno treba osigurati da operandi i operatori budu iz iste domene. Pravila odlu ivanja Do sada razmatrani entiteti objektnog modela procesa konstruiranja modeliraju osnovne strukture podataka i skupove relacija izmeu takovih objekata. Time je modelirana stati ka struktura domene procesa konstruiranja, ali ne i struktura dinamike izvoenja procesa. Modeliranje prikaza i kontrole izvoenja procesa tema je slijedeeg poglavlja ( REF _Ref409155949 \r \h 7.3). Kao osnovni elementi usmjeravanja tijeka izvoenja procesa konstruiranja u predlo~enom modelu koncipirana su "pravila odlu ivanja". Pravila odlu ivanja mogu se razmatrati i kao relacije izmeu akcija koje se izvode u procesu i stanja i vrijednosti atributa objekata. Pravila odlu ivanja dakle su i relacije i elementi kontrole izvoenja procesa. Prikaz pravila odlu ivanja uklju en je u poglavlje o relacijama i stoga ato je "izraz" jedan od osnovnih elemenata pravila, pa se izlaganja nadovezuju na prethodna dva podnaslova o izrazima i ograni enjima. Pravila odlu ivanja elementi su prikaza tijeka procesa konstruiranja koja se generiraju i zapisuju prije izvoenja procesa, odnosno kontrolne strukture koje su objekti projektiranja procesa  REF _Ref409269474 \r \h [7]. Dodatne kontrolne strukture na viaoj razini koje upravljaju procesom konstruiranja predmet su razmatranja u poglavlju  REF _Ref409155949 \r \h 7.3. Pravila odlu ivanja koncipirana su u obliku "IF uvjet THEN akcija" (ili premisa - akcija), pri emu zadovoljenje uvjeta pokree akciju. Struktura pravila mo~e sadr~avati jedan uvjet i viae akcija. Kao uvjet pravila koristi se leksi ki izraz, odnosno entitet "izraz", kako je definiran u poglavlju  REF _Ref409437152 \r \h 7.2.6. Sintaksa pravila: pravilo ::= if '(' <izraz> ')' then <niz_akcija> [ else <niz_akcija> ] end if niz_akcija ::= <akcija> { ';' <akcija> } akcija ::= naziv_objekta.naziv_operacije // ovo je samo openita naznaka, jer pojedine klase akcija imaju razli ite sinatkse zapisa akcije izraz ::= <operand> | <operator> | <operand> { <operator> | <operand> } // prema sinatksi danoj u  REF _Ref409437152 \r \h  \* MERGEFORMAT 7.2.6 Pri evaluaciji pravila odreuje se vrijednost izraza (uvjet) kao istina ili la~ i na temelju toga odlu uje se koji niz akcija e se izvraiti . Akcije koje pravilo pokree mogu biti bilo koje od klasa akcija koje su razmatrane u  REF _Ref409166554 \r \h 7.1.5. Na taj na in, ovisno o vrijednostima, statusima i meusobnim odnosima atributa objekata, "odlu uje" se koja e se operacija kojeg objekta pokrenuti. Pri tome akcija ne mora biti samo operacija objekta, nego mo~e biti i promjena vrijednosti atributa nekog od objekata. Predlo~enim konceptom mogue je modelirati vrlo slo~ena pravila odlu ivanja, sa vrlo bogatom semantikom na raspolaganju. Pod semanti kim elementima pravila odlu ivanja podrazumijevaju se: atributi svih klasa koje ine model procesa konstruiranja, mogunost pozivanja neke od operacija bilo koje klase iz modela procesa konstruiranja, klasifikacija semantike akcija (slika 34) - promjena vrijednosti atributa, operacije s objektnom bazom, itd. Na taj na in pravila odlu ivanja mogu se promatrati i kao implementacija znanja u model procesa konstruiranja. Npr. ako je akcija promjena vrijednosti parametra - tada dakle pravilo slu~i kao znanje za odreivanje vrijednosti parametra. Svaka instanca pravila odlu ivanja sadr~i zapis pravila u obliku niza znakova, koji se u tijeku izvoenja procesa konstruiranja parsira. Entitet "pravilo odlu ivanja" modelira dakle zapis i proces obrade (evaluacije) pravila odlu ivanja, te sadr~i slijedee atribute i operacije: pokaziva  (pointer) na zapis cijelog pravila opis - dodatni komentari i pojaanjenja status pravila kod zadnjeg izvoenja - koji su uvjeti bili ispunjeni, odnosno koje su akcije izvedene zapis stanja svih izvoenja u tijeku procesa operaciju parsiranja pravila, koja predaje kontrolu odabranoj akciji Veina pravila odlu ivanja mo~da e se u tijeku procesa konstruiranja izvesti i nekoliko puta, kao dijelovi iterativnih procesa. Stoga je korisno zapisati koji su uvjeti bili ispunjeni u svakom od izvoenja, iz istih razloga kao i kod provjera ograni enja (razmatranja na kraju poglavlja  REF _Ref409172047 \r \h 7.2.7). U daljnjem razvoju mo~e se tako predvidjeti i zapis primjedbi i obrazlo~enja konstruktora uz svako izvoenje pravila. Generiranje i a~uriranje zapisa ograni enja i pravila odlu ivanja Kao i operacije generiranja zapisa ograni enja i operacije generiranja zapisa pravila odlu ivanja trebaju sadr~avati mehanizme kontrole ispravnosti sintakse i semantike pravila. Zapisi ograni enja i pravila odlu ivanja u pravilu bi se trebali generirati prije izvoenja procesa konstruiranja, no nema nikakve zapreke da se oni mijenjaju i dodaju i u tijeku izvoenja procesa. Na taj na in mogu se donekle ubla~iti posljedice nepredvienih situacija u planu procesa, odnosno mo~emo govoriti o jednoj vrsti dinami kog prilagoavanja plana procesa u tijeku izvoenja! Time bi se mogunosti kontrolnih struktura izvoenja procesa konstruiranja za jedan mali korak pribli~ile ljudskim mogunostima dinami kog planiranja. Predlo~ena koncepcija mo~e se realizirati na na in da kontrolne operacije izvoenja procesa omoguavaju interakcije s kontruktorom prije i nakon procesa obrade ograni enja i pravila odlu ivanja. U takvim interakcijama omoguavala bi se promjena zapisa postojeih ograni enja i pravila odlu ivanja, kao i dodavanje novih. `toviae, takve operacije interakcija s konstruktorom mogu biti i akcije u samim pravilima odlu ivanja! Pokretanje interakcije s konstruktorom mo~e se i unaprijed planirati koriatenjem npr. atributa ograni enja i pravila, ija vrijednost bi odreivala da li prije ili poslije obrade treba pokrenuti operaciju dorade ili dodavanja ograni enja ili pravila. Relacije ograni enja i pravila odlu ivanja mogu se u "pseudo" formi zapisivati u bazu znanja procesa konstruiranja. Pri tome "pseudo" forma zna i da izrazi ne sadr~e reference na konkretne objekte, nego su napisani u simboli kom obliku. Jedan prototip takvog sustava u relacijskoj bazi podataka realiziran je u  REF _Ref409244619 \r \h [6]. Elementi prikaza i kontrole izvoenja procesa konstruiranja Sredianja tema ovog istra~ivanja je koncipiranje prikaza, odnosno modela procesa konstruiranja temeljeno na principima razvoja objektno orijentiranog modeliranja programskih sustava. U dosadaanjim izlaganjima predlo~eni su osnovni strukturalni elementi (entiteti) modela ija je funkcija modeliranje in~enjerskih struktura podataka i kompleksne mre~e relacija izmeu njih. Do sada razmotreni entiteti modeliraju prete~no samo stati ke aspekte procesa konstruiranja. Modeliranje entiteta koji opisuju dinami ke aspekte znatno je zahtjevnija zadaa. Izlaganja u drugom i treem poglavlju rada daju pregled procesa konstruiranja kao izuzetno kompleksne ljudske djelatnosti. Stoga se i prikazani teoretski modeli procesa konstruiranja dosta razlikuju u pristupima i aspektima koje razmatraju. Niti jedna od razvijenih openitih metoda prikaza tijeka procesa (razmatranih u poglavlju  REF _Ref492090505 \r \h 4.5) ne mo~e u potpunosti modelirati proces konstruiranja. Kratki pregledi i kritike uporabe nekoliko metoda prikaza procesa konstruiranja mogu se nai u radovima  REF _Ref409248257 \r \h [133] i  REF _Ref409178840 \r \h [134]. Fokus istra~ivanja ovog rada je koncipiranje dovoljno fleksibilnog okvira (okru~enja) unutar kojeg se model procesa konstruiranja mo~e adaptirati i nadograivati prema specifi nim potrebama pojedinih korisnika. Kako je ve navedeno, u Znanosti o konstruiranju joa ne postoji jedinstveni (usaglaaeni) model procesa konstruiranja, pa je stoga i terminologija koja se koristi u istra~ivanjima iz te teme prili no razli ita. esta je situacija da su nazivi semanti ki istih pojmova razli iti u radovima razli itih autora, no takva situacija ne treba iznenaditi, jer je o ito da i metodologija istra~ivanja vjerojatno joa nije dovoljno sazrela i nije usaglaaena. U ovom radu za prikaz dinami kog aspekta procesa konstruiranja koristiti e se naziv "plan konstruiranja". Pri tome taj termin obuhvaa i strukture podataka i operacije koje zajedno ine model odvijanja procesa u realnom vremenu, kao i model toka informacija izmeu stati kih objekata sustava. Prema  REF _Ref409258111 \r \h [88] plan je svaki hijerarhijski proces u organizmu koji mo~e kontrolirati redoslijed po kojem treba izvoditi operacije. Plan konstruiranja u predlo~enom modelu procesa konstruiranja definira se kao model dekompozicije i tijeka izvoenja procesa konstruiranja u kojem se organiziraju i predviaju tokovi informacija i redoslijed izvraavanja akcija, te postavljaju kontrolni uvjeti. Plan konstruiranja upravlja akcijama koje se izvode na objektima koji modeliraju strukture podataka i mre~u relacija izmeu njih. Elemente plana konstruiranja mo~emo podijeliti na prikaz tijeka odvijanja procesa i na upravljanje izvoenjem procesa. Stati ki prikaz procesa ne zadovoljava zahtjeve rjeaavanja situacija koje se javljaju u izvoenju procesa konstruiranja (razmatranja u poglavljima  REF _Ref409248357 \r \h 4.3.2 i  REF _Ref409248359 \r \h 4.3.3). Stoga elementi plana koji upravljaju izvoenjem procesa trebaju u tijeku procesa omoguiti promjene elemenata prikaza procesa i kontrolnih uvjeta, o emu je ve bilo govora u poglavlju  REF _Ref409157237 \r \h 7.2.9. U poglavlju  REF _Ref409248534 \r \h 4.3 razmotreni su pristupi planiranju rjeaavanja problema. Proces konstruiranja mo~e se promatrati kao proces rjeaavanja problema, stoga se mo~e pretpostaviti da se tehnike planiranja rjeaavanja problema mogu primjeniti (preslikati) na proces konstruiranja. Pri tome su od posebnog interesa metode oportunisti kog planiranja i metoda temeljena na nacrtima uzoraka planova ("script based planning"). Kako implementirati te dvije metode u objektni model procesa konstruiranja? Jedna od mogunosti je razdvojiti izradu plana konstruiranja na viae razina (i/ili faza): izrada "nacrta" (skice) plana rjeaavanje konfliktnih situacija (spregnuti zadaci i ciljevi, algoritmi iteracije) generiranje kona nog zapisa plana po kojem e se izvoditi proces konstruiranja Nacrt plana ne mora sadr~avati strogo formalni zapis plana, niti mora biti definitivno odreen redoslijed izvoenja operacija. Na temelju takve po etne skice plana treba uo iti, odnosno pokuaati predvidjeti sve mogue konfliktne situacije i na ine njihova rjeaavanja. Kona ni zapis plana skup je entiteta i procedura koje ine ra unalni model dinami kog aspekta procesa konstruiranja, odnosno slu~i kao alat za ra unalnu podraku organizaciji i kontroli izvoenja procesa konstruiranja. Nacrt plana konstruiranja Kako je ve napomenuto, nacrt (skica) plana zamialjen je kao zapis informacija koji ne bi trebao slijediti unaprijed zadani skup formalnih pravila zapisivanja. Promatran kao entitet objektnog modela procesa konstruiranja, nacrt plana treba sadr~avati sva potrebna su elja prema osnovnim strukturalnim elementima modela i elementima za prikaz relacija. Dakle, konstruktor treba imati mogunost pristupa do svih relevantnih informacija za izradu nacrta plana konstruiranja odreene varijantne, ponovljene ili nove konstrukcije. Na temelju nacrta plana raa iaavaju se konfliktne situacije i prilazi se izradi "formalnog, kona nog" plana konstruiranja. Ideja ovakvog koncepta je ne prisiljavati konstruktora da ve u po etnoj fazi kreiranja plana konstruiranja mora prilagoavati svoja promialjanja, organizaciju rada i toka informacija, propisanim pravilima i sintaksi elemenata "formalnog" plana. Nacrt plana tako postaje mjesto za diskusiju i raa iaavanje, a sam zapis nacrta plana mo~e sadr~avati prikaze i podatke iz strukturalnih i relacijskih entiteta modela. Takav prikaz takoer nu~no ne mora sadr~avati kona ni redoslijed izvoenja akcija i operacija. Postavlja se pitanje kako programski realizirati takvu koncepciju? Potrebno je realizirati skup programskih alata za pretra~ivanje, dohvaanje i kopiranje informacija iz ostalih entiteta modela, a pri tome najveu pa~nju treba posvetiti organizaciji i pristupu bazi znanja o konstruiranju proizvoda. Spomenuta baza znanja treba sadr~avati prvenstveno znanje o procesu konstruiranja, dakle iskustva i procese promialjanja i odlu ivanja iz prethodnih konstrukcija. Struktura baze znanja kao dijela modela procesa konstruiranja predlo~ena je u  REF _Ref409159332 \r \h [135]. U strukturu nacrta plana treba implementirati i su elja prema alatima koji sadr~e implementacije metoda za odreivanje redoslijeda izvraavanja akcija i zadataka, kao npr. operacije "preslagivanja" matrice informacijske zavisnosti konstrukcijskih zadataka. Jezgru nacrta plana mo~e initi lista aktivnosti gdje nije nu~no odreen redoslijed aktivnosti, nego se samo navode potrebne aktivnosti, odnosno koraci ka postizanju cilja. Takva lista mo~e se zapisivati u tekstualnom obliku, ili u obliku matrice, gdje se aktivnost povezuje sa temom ili objektom na kojeg djeluje. Elementi zapisa mogu biti i reference na strukturalne i relacijske objekte pohranjene u objektnim bazama podataka. Takvi objekti koriste se kao gotovi uzorci pri izradi nacrta plana kao i pri izradi kona nog formalnog plana. Korak dalje u razvoju predlo~enog koncepta mogla bi biti implementacija metoda generiranja formalnog zapisa plana na temelju nacrta plana, ali do tog stupnja razvoja predstoji joa mnogo istra~iva kog rada. U ovoj fazi istra~ivanja va~nije je razmotriti kako (i da li je mogue) koncipirati proces izrade nacrta plana na kojem radi viae konstruktora istovremeno. Za takav slu aj mogla bi se koristiti "blackboard" kontrolna struktura, ali svakako ostaje otvoreno pitanje kako koordinirati rad viae "planera" i na kraju spojiti plan u jednu cjelinu? Kao zaklju ak razmatranja o nacrtu plana navedimo njegove osnovne funkcije: da bude po etna faza u procesu generiranja plana procesa konstruiranja, u kojoj se na "labaviji" na in mo~e prikazati proces, ali sa referencama na "prave" (postojee) objekte da poslu~i kao mjesto za diskusiju i raa iaavanje, te postupno odreivanje redoslijeda izvoenja akcija ranije otkrivanje moguih konfliktnih situacija, zbog neoptereenosti formalizmom zapisa plana Matrica "aktivnost - tema" Kao jedan od elemenata nacrta plana (ili njegova jezgra), mo~e se usvojiti matrica "aktivnost-tema", prema  REF _Ref409180606 \r \h [130],  REF _Ref409269868 \r \h [49] . Prema prijedlogu autorice, "oznaka" u eliji matrice bilje~i da je obavljena odreena aktivnost na temi (tablica 7). U sustavu koji Blessing predla~e, matrica se koristi za bilje~enje procesa konstruiranja sa svrhom ponovne uporabe takvog zapisa u slijedeoj varijanti konstrukcije. Predlo~eni na in zapisa mo~e modelirati nacrt plana konstruiranja, ako se umjesto u tijeku procesa, matrica popunjava prije izvoenja procesa. Pri tome oznake u elijama matrice mogu biti i redni brojevi koji ozna avaju preliminarni redoslijed aktivnosti. Prema  REF _Ref409180606 \r \h [130] popis tema i aktivnosti mo~e se prilagoditi potrebama specifi nog okru~enja, odnosno procesa konstruiranja. Teme se rjeaavaju u tri koraka: generiranje, procjena (odreivanje) i izbor. Generiranje rezultira prijedlozima koji se odnose na zadanu temu. Taj stupac mo~e sadr~avati i druge informacije relevantne za prijedlog. Procjena i izbor mogu oboje rezultirati sa argumentima i odlukama. Argumenti podr~avaju ili pobijaju prijedlog, te slu~e kao temelj za donoaenje odluka. Argumenti mogu takoer dovesti i do novih prijedloga. Odluke opisuju status prijedloga. AKTIVNOSTITEMEgenerirajprocijeni izaberiproblemzahtjevfunkcijekonceptgeometrijamaterijalodr~avanjetrokoviTablica  SEQ Tablica \* ARABIC 7: Matrica "aktivnost-tema" prema  REF _Ref409180606 \r \h [130] Blessing povezuje ovu matricu sa objektima konceptualne strukture proizvoda. Kao element objektnog modela procesa konstruiranja ova matrica mo~e se vezati uz objekte strukture proizvoda, objekte prikaza proizvoda i zadatke. Pri tome se ove matrice mogu i klasificirati prema popisu tema i aktivnosti koje bi sadr~avale. Teme i aktivnosti nisu predvieni kao entiteti objektnog modela procesa konstruiranja, stoga se ova matrica nee modelirati na isti na in kao i npr. matrice zavisnosti izmeu objekata. Matricu "aktivnost-tema" pogodnije je modelirati skupovima atributa i operacijom, jer nije nu~no da svaki redak, stupac ili elija matrice matrice budu zasebni objekti. Tako definirana klasa mo~e onda biti dio procesa podrake kreiranju plana konstruiranja. Elementi plana konstruiranja (dekompozicija i prikaz procesa konstruiranja planom) Osnovu prikaza procesa konstruiranja u predlo~enom modelu initi e dekompozicija procesa na "etape" koje ine zaokru~ene cjeline generiranja i transformacija informacija. Etapa procesa je proces obrade informacija koji je dio jednog konstruktorskog zadatka. Kao metoda prikaza tijeka odvijanja procesa koristiti e se usmjereni graf, prema razmatranjima u  REF _Ref409176535 \r \h 4.4. Prema  REF _Ref409176645 \r \h [12], niti jedna od postojeih metoda prikaza procesa ne mo~e ispuniti sve zahtjeve openitog prikaza, ato je detaljnije obrazlo~eno u poglavlju  REF _Ref492090505 \r \h 4.5. Stoga e se uo eni nedostaci odabrane metode prikaza procesa nastojati nadoknaditi implementacijom dodatnih semanti kih elemenata i eventualnim kombiniranjem elemenata postojeih metoda prikaza procesa. U predlo~enom pristupu vor usmjerenog grafa modelirati e "etapu" procesa konstruiranja. Bridovi usmjerenog grafa modeliraju mogue putanje redoslijeda izvoenja etapa i mogue putanje tokova informacija. Pri tome usmjereni graf ima strukturu mre~e sa jednim po etnim vorom - prema razmatranjima izlo~enim u poglavlju  REF _Ref409176535 \r \h 4.4. vor plana i veze izmeu vorova ine stati ke elemente zapisa prikaza procesa. Skup operacija koje upravljaju izvoenjem procesa konstruiranja na temelju zapisa stati kih elemenata i interakcija sa konstruktorom modeliraju dinami ki aspekt izvoenja procesa konstruiranja. U nastavku izlaganja definirati e se i opisati vorovi plana, veze vorova i njihov zapis. vor plana konstruiranja U predlo~enom modelu, etapa ( vor plana) procesa konstruiranja definira se kao kombinacija nepraznog skupa akcija (naredbi) Aj koje transformiraju objekt O, koji se nalazi u stanju SOi , u slijedee (novo stanje) SOi+1 : E ={ An : Sj ( Aj ( SOi ) = SOi+1 } Definicija se mo~e proairiti i na skup objekata, odnosno skup akcija transformira stanje svakog od objekata u slijedee novo stanje. Pri tome akcije mogu i generirati nove objekte i nakon toga im mijenjati stanje. U predlo~enoj definiciji "objekti" su: parametri, objekti prikaza proizvoda, objekti strukture proizvoda, konstrukcijski zadaci, te objekti prikaza relacija izmeu skupova instanci istih ili razli itih klasa. Predlo~ena definicija etape procesa, odnosno vora plana, analogna je definiciji "radnog prostora konstruiranja", prema  REF _Ref409184969 \r \h [136]. Autori modeliraju proces konstruiranja pomou "radnih prostora konstruiranja (design-working-space)" - skupova objekata koji ine okolinu za rjeaavanje konstrukcijskog problema. Radni prostor grupira objekte iz svih faza procesa konstruiranja i strukturira znanje o procesu konstruiranja da bi se odredilo (fiksiralo) stanje konstrukcije. Nova stanja izvode se iz definiranog stanja primjenom "uzoraka procesa". Osnovna razlika modela predlo~enog u ovom radu u odnosu na model predlo~en u  REF _Ref409184969 \r \h [136] i  REF _Ref409148253 \r \h [137], je u injenici da se "radni prostor konstruiranja" temelji primarno na geometrijskom modeliranju konstrukcije. Model procesa konstruiranja predlo~en u ovom radu orijentiran je primarno na unapreenje organizacije i integracije ra unalne podrake. Pri tome se entiteti realnog svijeta procesa konstruiranja nastoje preslikati u entitete objektnog modela koji e initi sustav dovoljno fleksibilan da se pri implementaciji mo~e prilagoditi razli itim okru~enjima izvoenja procesa konstruiranja. Istra~ivanja u ovom radu usmjerena su primarno na informacijsko modeliranje procesa konstruiranja. Akcije u etapi procesa konstruiranja, prema definiciji etape, mijenjaju stanje objekata. Osnovni uvjet za izvoenje odreene akcije treba biti dakle postojanje samog objekta. Pored toga objekt mora biti u odreenom stanju koje akcija zahtijeva da bi se mogla izvraiti, odnosno da bi njeno izvraavanje imalo smisla. vor plana kao model etape procesa konstruiranja treba dakle sadr~avati operacije provjere preduvjeta izvraavanja akcija. Planirati proces zna i odreivati ato se u odreenoj etapi procesa treba postii, odnosno odrediti ciljeve svake etape. Ciljeve etape mo~emo promatrati i kao skup uvjeta koji moraju biti zadovoljeni, dakle vor plana treba sadr~avati operacije provjere zadovoljenja ciljeva. U predlo~enom modelu preduvjeti i ciljevi modelirati e se kao zahtijevano po etno (ulazno) stanje objekata i zahtijevano kona no (izlazno) stanje objekata koji se obrauju u etapi procesa, tj. u voru plana konstruiranja. Tako modelirana etapa procesa ( vor plana) sadr~i skup akcija koje obavljaju transformacije od ulaznog stanja k izlaznom. Pod transformacijama se podrazumijevaju: promjene vrijednosti atributa objekata postavljanje ili mijenjanje relacija izmeu objekata pozivanje operacija objekata koji mijenjaju vlastito stanje ili stanje drugih objekata pozivanje "vanjskih" programskih alata koji mijenjaju stanje objekata prikaza proizvoda i objekata strukture proizvoda generiranje novih objekata, postavljanje i mijenjanje njihovih inicijalnih stanja pregledi i analize stanja (skupova atributa i objekata), te odlu ivanje o daljnjem tijeku procesa konstruiranja vor plana entitet je koji kontrolira procese obrade informacija na skupovima razli itih klasa objekata. Postavlja se pitanje kako (pri kreiranju plana) u voru zapisati ato treba raditi, na emu, i kojim redoslijedom. Pri tome treba nastojati da takav zapis nema krutu sintaksu. Stoga je ovdje odabrana koncepcija da se redoslijed obrade elemenata vora implementira u skup operacija koje vode proces obrade vora, a da zapis "na emu" se obrada radi i zapis liste akcija koje rade obrade budu u obliku skupova referenci na objekte (slika 44). Objekte koje vor referencira treba dakle kreirati nezavisno od samog vora, tj. oni ne ine zapis vora, pa se na taj na in dobija na fleksibilnosti zapisa. Druga prednost takve koncepcije je u tome da se isti objekti mogu referencirati i iz viae vorova. Takva koncepcija otvara i mogunost promjene referenci vorova u tijeku izvoenja plana, odnosno prilagoavanja plana nepredvienim situacijama koje nastaju u tijeku izvoenja, ato je zapravo implementacija dinami kog planiranja. Na predlo~eni na in ak i sam plan konstruiranja (u tijeku izvoenja, bez interakcije sa konstruktorom) mo~e mijenjati i prilagoavati "sam sebe", tj. akcije jednog vora mogu na temelju uvjeta u pravilima odlu ivanja promijeniti reference tog vora ili reference drugih vorova! Jedan od pristupa razradi inkrementalnog dinami kog planiranja prezentiran je u radu  REF _Ref409148286 \r \h [138]. vor sadr~i dakle skupove referenci na objekte modela procesa konstruiranja. Pri tome neki skupovi referenci mogu sadr~avati objekte jedne i samo jedne klase, dok neki mogu sadr~avati objekte razli itih klasa. Nu~no je to no definirati ato koji skup referenci mo~e sadr~avati radi algoritma procesa obrade vora. Takve skupove referenci promatramo kao elemente vora. Redoslijed obrade elemenata vora (skupova referenci) implementiran je u operaciju procesa obrade vora. vorovi plana mogu se klasificirati prema tome koje elemente sadr~e i prema eventualno razli itim algoritmima procesa obrade. Jedan element obrade vora skup je referenci na objekte modela procesa konstruiranja, pa treba odrediti i redoslijed obrade pojedinih referenci unutar samog skupa referenci. Redoslijed obrade referenci unutar skupa mo~e se zapisati u obliku tablice, gdje svaka referenca ima svoj "redni broj" obrade (tablica 8). Na predlo~eni na in nije nu~no zapisivati odmah reference onim redom kojim ih treba obraivati, nego se taj redoslijed mo~e odrediti i zapisati naknadno. Pri tome se pretpostavlja da je skup referenci implementiran kao polje pokaziva a (pointera). Svakom lanu polja pokaziva a odgovara jedan lan polja redoslijeda obrade. Ovakav na in zapisa takoer omoguuje i jednostavne promjene redoslijeda obrade referenci u tijeku izvoenja plana konstruiranja. Tablica mo~e sadr~avati i naziv objekta koji se referencira, radi preglednosti pri kreiranju plana konstruiranja. Primjer predlo~enog na ina zapisa redoslijeda obrade unutar skupa referenci vora koji sadr~i pet elemenata prikazan je tablicom 8. polje pokaziva a na objekteredni broj obradep [1]3p [2]2p [3]1p [4]5p [5]4Tablica  SEQ Tablica \* ARABIC 8: Primjer zapisa redoslijeda obrade skupa referenci vora Na analogan na in mo~e se rijeaiti zapis redoslijeda obrade ako skup referenci sadr~i pokaziva e na instance dviju razli itih klasa. Shema takvog zapisa prikazana je tablicom 9. Svaka klasa ima "svoje" polje pokaziva a na objekte, pa je i zapis rednog broja obrade podijeljen na dva odgovarajua polja. Ako je broj instanci klase A jednak n, a broj instanci klase B jednak k, tada redni brojevi imaju vrijednosti od 1 do n+k, i mora biti ispunjen uvjet da je Ra ( Rb = (. Analogno se zapis redoslijeda mo~e proairiti i na viae od dvije klase objekata. Skup referenci potrebno je razdvojiti na zasebna polja pokaziva a za svaku klasu stoga ato objektna baza mo~e implementirati polje (skup) pokaziva a samo na skup instanci iste klase. polje pokaziva a na objekte klase Apolje pokaziva a na objekte klase Bredni broj obrade objekta klase Aredni broj obrade objekta klase Bpa [1]pb [1]ia ( Ra, Ra={1, ..n+k}ib ( Rb Rb={1, ..n+k}pa [2]pb [2]. . .. . .. . .. . . . . .pb [k-1]pa [n-1]pb [k]ibkpa [n]ianTablica  SEQ Tablica \* ARABIC 9: Zapis redoslijeda obrade unutar dva skupa referenci vora U slijedeem poglavlju razmotriti e se proces izvoenja vora, a nakon toga rezimirati e se ato sve vor kao slo~eni objekt treba sadr~avati. Proces izvoenja (obrade) vora Pri razmatranju procesa izvoenja vora pretpostavlja se da se istovremeno izvraava samo jedan vor plana konstruiranja. U trenutku "aktiviranja" vora pokree se operacija koja upravlja izvoenjem vora, tj. procesom obrade elemenata vora. Shema procesa obrade elemenata vora i reference vora na skupove objekata modela procesa konstruiranja prikazani su na slici 44. Osnovni koraci (etape) procesa obrade vora mogu se nazna iti kao: Provjera preduvjeta (zahtjevanog ulaznog stanja) - obrauje se skup referenci na ograni enja i pravila odlu ivanja. Zahtijevano (planirano) ulazno stanje skup je uvjeta i ograni enja koji moraju biti ispunjeni da bi imalo smisla izvoditi predviene akcije vora. Izvoenje liste akcija - procesira se skup referenci na akcije, no lista akcija mo~e sadr~avati i reference na ograni enja ili pravila - kao provjere "meuuvjeta". Provjera "postuvjeta", tj. da li je postignuto planirano izlazno stanje - obrauje se skup referenci na pravila i ograni enja. Ako nije postignuto planirano izlazno stanje, mogu je povratak na neku od akcija (iz liste akcija) ili se proces obrade prekida. Povratak na odreenu akciju realizira se kroz interakciju s konstruktorom koji bira redni broj akcije koja e se izvraiti. Proces obrade se u tom slu aju vraa na odabrani korak i nastavlja se dalje prema istim koracima kao i u prethodnom koraku iteracije. Odlu ivanje o daljnjem tijeku procesa - izbor i aktiviranje slijedeeg vora, interakcija s konstruktorom ili prekid procesa. Slijedei vor bira se na temelju zapisa veza izmeu vorova u matricama susjedstva i incidencije Bilje~enje tijeka obrade u "stanje procesa" tokom obrade, u trenutku eventualnog prekida procesa i po zavraetku obrade vora. Dijagram toka redoslijeda obrade elemenata vora prikazan je na slici 44. Ujedno su shematski prikazane i direktne i indirektne reference vora. vor sadr~i reference na akcije, koje referenciraju operacije svih klasa objekata, te reference na ograni enja i pravila koja referenciraju atribute svih klasa objekata modela procesa konstruiranja. Preko direktnih i indirektnih referenci vor zapravo grupira sve skupove informacija (objekte) koji se obrauju u jednoj etapi procesa konstruiranja. Na taj na in modeliran je "radni prostor" koji sadr~i i model izvoenja procesa konstruiranja. Obrada, provjera informacija i odlu ivanje izvode se po unaprijed planiranom redoslijedu koji se u tijeku izvoenja mo~e prilagoavati novonastalim (nepredvienim) situacijama. Osim elemenata (skupova referenci) koji se u voru procesiraju, vor mo~e sadr~avati i skup "ulaznih" i skup "izlaznih" referenci koje nisu uklju ene u proces obrade. Ti skupovi referenci predvieni su kao "pregled" stanja objekata koji konstruktor mo~e aktivirati na po etku i na kraju izvoenja vora ili u trenutku prekida procesa obrade. Na taj na in konstruktor mo~e u ~eljenom trenutku dobiti uvid u stanje razvoja konstrukcije. U navedenim skupovima mogu biti referencirani i objekti koji se ne obrauju u voru koji ih referencira, ali su relevantni za analize i usporedbe, odnosno za usmjeravanje tijeka procesa i odlu ivanje.  INCLUDEPICTURE "linkane slike\\SHEMA REFERENCI CVORA.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 44: Reference vora na druge objekte i proces izvoenja vora Predlo~eni na in izvoenja (obrade) vora ( vorova), odnosno plana sadr~i i neke elemente "oportunisti kog" i dinami kog planiranja. Zapravo svaki vor funkcionira kao svojevrstan "otok" planiranja koji sam rjeaava svoj dio posla u etapi procesa konstruiranja. Provjera preduvjeta i postuvjeta koji provodi vor mo~e se promatrati kao usporedba unaprijed planirane i stvarne dinami ke situacije u tijeku izvoenja plana. Pregled stanja referenciranih objekata koristi konstruktor u situacijama kad se proces obrade vora prekida i tra~i intervencija konstruktora. vor kao "otok planiranja" modeliran je svojom operacijom obrade elemenata vora, odnosno ugraenim znanjem "ato treba initi" u odnosu na situacije koje mogu nastupiti u tijeku izvoenja procesa. Algoritam procesa obrade elemenata vora odvija se po slijedeim fazama (dijagram toka prikazan je na slici 44): Provjera preduvjeta: ako su sva ograni enja zadovoljena, i uvjeti pravila tako odreuju, prelazi se na izvoenje liste akcija ako neko od ograni enja nije zadovoljeno ili se u nekom od pravila tako odredi, mogue su dvije putanje nastavka: tra~enje intervencije konstruktora, nakon koje on bira to ku nastavka procesa skok na odlu ivanje o daljnjem tijeku procesa (to ka 4) Lista akcija: redom se izvode akcije, izmeu kojih se mogu pojavljivati i provjere meuuvjeta, koje mogu rezultirati sa istim putanjama nastavka kao i nakon provjere preduvjeta Provjera postuvjeta: ako su sva ograni enja zadovoljena, i ako uvjeti pravila tako odreuju, prelazi se na odlu ivanje o daljnjem tijeku procesa, odnosno izbor slijedeeg vora plana konstruiranja ako neko od ograni enja nije zadovoljeno ili se u nekom od pravila tako odredi, mogue su dvije putanje nastavka: tra~enje intervencije konstruktora, nakon koje on bira to ku nastavka procesa povratak na odreenu akciju u listi akcija, dalje se izvode akcije koje slijede Odlu ivanje o daljnjem tijeku procesa: na temelju zapisa veza izmeu vorova plana u matricama incidencije i susjedstva, te na temelju skupa pravila, bira se slijedei vor plana i pokree proces njegove obrade ako nastupe nepredviene situacije, ili uvjeti pravila tako odreuju, tra~i se intervencija od konstruktora, koji odreuje slijedei vor ili prekida proces Plan konstruiranja, odnosno mre~a veza izmeu vorova prikaz je tokova podataka, moguih (unaprijed planiranih) putanja i redoslijeda izvraavanja, kao i situacija izvoenja. Na temelju znanja zapisanog u skupu pravila, vor mo~e odlu ivati koje e dalje vorove aktivirati i kojim redoslijedom - odnosno da li se mo~e realizirati planirani redoslijed ili se treba prilagoditi trenutnoj situaciji, odnosno tra~iti odluku od konstruktora ato treba dalje raditi. Prilagodba novoj situaciji mo~e se realizirati promjenom zapisa elemenata vora, ali i dograivanjem plana u tijeku izvoenja - dodavanjem novih veza i vorova. Reference, operacije i atributi vora Nakon prikaza procesa izvoenja vora, ovdje e se rezimirati ato sve objekt " vor plana konstruiranja" treba sadr~avati. vor plana najkompleksniji je entitet modela procesa konstruiranja koji "grupira" sve potrebne objekte za modeliranje "radnog prostora" izvoenja etape procesa konstruiranja. Model radnog prostora ine skupovi referenci na razli ite klase objekata i skup operacija koje upravljaju procesom izvoenja vora. vor plana sadr~i slijedee skupove referenci: Za pregled i analizu stanja obrade - reference na parametre, objekte prikaza proizvoda, objekte strukture proizvoda, i objekte zapisa relacija zavisnosti i pripadnosti. Ovi skupovi referenci nisu uklju eni u proces obrade vora. Na elemente procesa obrade: ograni enja i pravila navedena u provjeri preduvjeta akcije koje su navedene u listi akcija ograni enja i pravila provjere "postuvjeta" skup pravila odlu ivanja o daljnjem tijeku procesa konstruiranja Svaki od navedenih skupova referenci mora imati i svoje liste redoslijeda obrade (prema tablicama 8 i 9). Navedeni skupovi referenci mogu se promatrati kao "direktne" reference vora. Ograni enja i pravila sadr~e reference na izraze i akcije, izrazi sadr~e reference na atribute objekata, a akcije sadr~e reference na operacije objekata - pa sve ove reference mo~emo promatrati kao "indirektne" reference vora. Openito gledano, na taj na in vor plana mo~e u procesu obrade "dohvatiti" neki od atributa ili pozvati neku od operacija bilo kojeg objekta modela procesa konstruiranja. Implementacija ovakve koncepcije razraditi e se u osmom poglavlju. vor, kao najkompleksniji entitet predlo~enog modela procesa konstruiranja sadr~i i najvei dio modela dinamike izvoenja procesa koji se realizira skupom operacija. Osnovna operacija koja kontrolira proces obrade vora poziva se u trenutku aktiviranja vora. Osnovne to ke algoritma procesa obrade vora navedene su u prethodnom poglavlju. Pored implementacije opisanog algoritma obrade, operacije vora trebaju modelirati i podr~avati i slijedee funkcije: Dekodiranje (parsiranje) zapisa elemenata obrade vora i zapisa redoslijeda obrade unutar pojedinog skupa referenci. Zapis tijeka izvoenja procesa, koji bi se trebao realizirati tako da je, izmeu skupa opcija, mogue birati ato e se, i u kojim fazama obrade procesa zapisivati. Svakako bi trebalo zapisivati kroz koje grane prolazi proces obrade, odnosno koji uvjeti su bili ispunjeni. Implementaciju su elja za interakcije s konstruktorom: Su elje odlu ivanja o daljnjem tijeku procesa - konstruktor treba imati pregled redoslijeda obrade referenciranih elemenata vora, i mogunost analize stanja skupova objekata. Su elje za formiranje upita za pregled i analizu stanja obrade. Su elje za pregled zapisa izvoenja procesa i za dodavanje primjedbi (u zapis izvoenja procesa konstruktor mo~e upisivati i svoja objaanjenja - koja je situacija nastupila, kako ju je rijeaio, ato je eventualno promijenio u planu. Implementaciju "poatanskog sandu ia" za slanje i primanje poruka od drugih vorova. Spomenute poruke predla~u se kao "podsjetnici" na situacije koje nastupaju u izvoenju plana, koji ine dio zapisa vora. Poruke mo~e zapisivati operacija izvoenja vora i konstruktor u tijeku prekida procesa obrade. U iterativnim procesima neki vorovi e se izvoditi viae puta, pa zapisi primjedbi u svakom izvoenju vora mogu biti od koristi za usmjeravanja procesa iteracije. Analogno, vor mo~e "poslati" (zapisati) poruku drugom voru, koja mo~e biti korisna informacija pri izvoenju, odnosno analizi stanja obrade drugog vora. "Poatanski sandu i" treba odvojiti od "zapisa izvoenja procesa", jer poruke ovdje promatramo kao informacije koje su od koristi za usmjeravanje tijeka izvoenja plana procesa konstruiranja. Takav na in zapisa "poruka" bio bi od zna ajne koristi u slu aju da se viae vorova izvodi istovremeno, kao razli iti ra unalni procesi. Kako takva pretpostavka zahtijeva daleko slo~enije koncepcije implementacije procesa obrade vora (i izvoenja cijelog plana procesa konstruiranja), u opsegu ovog rada ona se nee razmatrati. Kako vor sadr~i skup operacija i skupove referenci (a ne zapise elemenata), zna i da na odreenoj razini ima relativno stati nu strukturu. Implementacija razli itih varijanti strukture vora i procesa obrade vora mo~e se stoga rijeaiti klasifikacijom. Pri generiranju plana treba dakle kreirati instance odreene klase vorova i inicijalizirati njihove skupove referenci (pointera), s time da se redoslijed obrade unutar skupova referenci mo~e odrediti i mijenjati naknadno. Predla~u se slijedei atributi vora: naziv vora u planu procesa konstruiranja oznaka vora u zapisu plana konstruiranja - matrici incidencije i matrici susjedstva opis vora - opis etape procesa konstruiranja, uloge i zadatka vora u kontekstu plana procesa konstruiranja redni broj ponavljanja izvoenja vora zapis promjena stanja vorova koja su nastupila u tijeku izvoenja plana u odnosu na originalno (po etno planirano i zapisano stanje) Veze vorova u planu konstruiranja vor plana modelira jednu etapu procesa konstruiranja, a skup vorova i veza izmeu njih modeliraju cjelokupni proces konstruiranja. U poglavlju  REF _Ref409176535 \r \h 4.4 razmatrana je topologija prikaza akcija u procesu konstruiranja i matri ni prikazi usmjerenog grafa. Usmjereni graf odabran je kao metoda prikaza tijeka odvijanja procesa konstruiranja. Takav graf ima jedan "po etni vor", a ostali vorovi mogu biti povezani u obliku mre~e (tj. svaki vor mo~e biti vezan sa bilo kojim drugim vorom). Po etni vor razlikuje se od ostalih vorova po tome ato nema niti jedan "ulazni brid" (vezu). Krajnji vorovi takvog grafa su oni koji nemaju niti jedan izlazni brid (vezu). Osnovna pretpostavka razmatranja koja slijede jest da se istovremeno mo~e izvoditi samo jedan vor plana konstruiranja. U poglavlju  REF _Ref492090505 \r \h 4.5 naglaaeno je da (prema  REF _Ref409176645 \r \h [12]) niti jedna do sada razvijena metoda prikaza procesa (i openite i specifi ne namjene) ne mo~e ispuniti sve zahtjeve za prikazom procesa konstruiranja. Stoga e se u predlo~enom modelu razmotriti mogunosti i pretpostavke dodavanja nekih semanti kih elemenata u prikaz procesa pomou usmjerenog grafa. Jedna od takvih mogunosti je razlikovanje viae vrsta (klasa) veza izmeu vorova grafa. U matri nom prikazu grafa svaka vrsta veze mo~e imati svoju oznaku koja se zapisuje u eliju matrice. U ovoj fazi istra~ivanja predla~u se dvije vrste veza: veze dozvoljenih putanja (redoslijeda) izvraavanja vorova u planu veze "prijenosa" informacija i "a~uriranja" zapisa elemenata vora Pri tome svaka dva vora u planu mogu biti povezana sa obje vrste veza ili samo jednom od njih. Obje vrste veza mogu biti i ulazne i izlazne iz vora. Veze dozvoljenih putanja izvraavanja ozna avaju koji se slijedei vorovi mogu aktivirati nakon zavraetka obrade odreenog vora. Takve veze predstavljaju "planirani" redoslijed izvraavanja plana koji se zapisuje u matri ni prikaz grafa. Ukoliko na temelju pravila odlu ivanja o nastavku procesa (na kraju obrade vora) nije mogue odrediti slijedei vor, proces obrade vora tra~iti e odluku od konstruktora. Konstruktor tada ne mora poativati predviene veze izmeu vorova, nego mo~e odabrati bilo koji vor za nastavak procesa. U daljnjem tekstu ova vrsta veza ozna avati e se kao "izvrane" veze. Ponovno izvraavanje vora u iterativnom ciklusu mo~e u nekim situacijama zahtijevati druga ije algoritme procesa obrade vora od algoritma obrade pri prvom aktiviranju. Stoga je va~no "povratnu" vezu takoer izdvojiti kao posebnu vrstu (klasu) veze. Po etni vor plana mo~e imati "povratnu ulaznu vezu", ali ne i druge izvrane veze kao ulazne. Veze prijenosa informacija ozna avaju dozvoljene utjecaje vora koji se obrauje na druge vorove plana. Pri tome "utjecaj" ovdje zna i da aktivni vor mo~e mijenjati neki dio zapisa neaktivnog vora, ato je zapravo implementacija dinami kog planiranja, tj. prilagoavanja plana novonastalim situacijama u tijeku izvoenja. Aktivni vor dakle mo~e promijeniti popis referenci, redoslijed izvoenja referenci, te zapise izraza, pravila i akcija. Zapis ove vrste veza nema bitnog utjecaja na tijek izvoenja plana, ali u cjelini zapisa plana daje sliku o tome koji dijelovi plana i "sa kojih mjesta" se mogu mijenjati u tijeku izvoenja. Za ovu vrstu veza u daljnjem tekstu koristiti e se naziv "informacijske" veze. Zapis, odnosno slanje poruka izmeu vorova nije vezano uz informacijske veze, tj. aktivni vor mo~e poslati (zapisati) poruku bilo kojem drugom voru plana. Primjer razmatranih vrsta veza izmeu vorova prikazan je na slici 45.  INCLUDEPICTURE "linkane slike\\cvor plana.wmf" \* MERGEFORMAT \d   INCLUDEPICTURE "linkane slike\\vrste veza cvorova.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 45: Vrste veza vorova plana konstruiranja Izlo~ena razmatranja veza izmeu vorova u usmjerenom grafu oslanjaju se na pretpostavku da se istovremeno izvraava samo jedan vor. Pretpostavka izvoenja viae vorova plana istovremeno zahtijeva razvoj daleko slo~enijih procesa obrade vorova, sinhronizacije i komunikacije izmeu vorova. Takoer bi tada trebalo rijeaiti to ke "dijeljenja" jednog procesa na viae njih i to ke "spajanja" viae procesa u jedan, eventualno sve pod kontrolom jednog zajedni kog procesa na viaoj razini. Detaljna razmatranja ovih otvorenih tema izvan su opsega ovog rada, ali ovdje e se ipak razmotriti kakvi su mogui utjecaji pretpostavke izvoenja viae vorova istovremeno na metodu zapisa plana pomou usmjerenog grafa. Postavlja se stoga pitanje da li metoda usmjerenog grafa mo~e (uz eventualne semanti ke dodatke) biti osnova prikaza odvijanja procesa konstruiranja i pod pretpostavkom izvraavanja viae vorova istovremeno. S takvom pretpostavkom informacijske veze vorova imaju daleko vei zna aj u procesu izvoenja plana. Ako se viae vorova izvraava paralelno, mo~e biti va~no da neki vor proslijedi informaciju im ju odredi (definira), da bi odmah postala raspolo~iva drugim aktivnim vorovima. U takvoj situaciji "informacijske veze" mogu se promatrati i kao "feedforward" veze, tj. im neki od vorova odredi vrijednost nekog klju nog parametra (ili atributa objekta) mo~e o tome obavijestiti druge vorove s kojima je povezan informacijskim vezama i kojima je taj podatak nu~an. Na taj na in mo~e se modelirati proces paralelnog izvoenja informacijski spregnutih zadataka (ta tema razmatrana je u poglavlju  REF _Ref409193216 \r \h 7.2.3). Prva mogunost semanti kog proairenja usmjerenog grafa koja se namee pod pretpostavkom izvoenja viae vorova istovremeno je postavljanje "AND" i "OR" uvjeta na mjestima viae izlaznih ili viae ulaznih grana u vorove. Tako postavljeni uvjeti odreivali bi zapravo to ke dijeljenja ("AND" izlaz) jednog procesa na viae paralelnih podprocesa i to ke spajanja ("AND" ulaz) viae paralelnih podprocesa u jedan proces. Na slici 46 prikazan je primjer usmjerenog grafa kao prikaza plana uz dodatak "AND" i "OR" uvjeta na mjestima gdje postoji viae ulaznih ili izlaznih veza vorova. Promatrajui ulazne i izlazne veze vorova mogu se razlu iti etiri razli ite situacije: nakon izvraavanja odreenog vora slijedi mogunost izvraavanja samo jednog vora kao slijedeeg u procesu jedan vor ima jednu ulaznu vezu, tj. aktivirati e se pozivom to no odreenog vora koji mu prethodi postoji viae izlaznih veza, tj. nakon odreenog vora slijedi mogunost izbora nastavka izvraavanja procesa izmeu viae drugih vorova jedan vor ima viae ulaznih veza, tj. taj vor aktivirati e se pozivom nekog od nekoliko moguih prethodnika Prve dvije navedene situacije za razmatranu temu nisu interesantne. Za druge dvije situacije kao po etnu pretpostavku uzmimo slijedee vrste (kombinacije) postavljanja uvjeta izvoenja slijednika i prethodnika odreenog vora: Svi slijednici vora (viae izlaznih veza) izvraavaju se paralelno ("AND " izlaz) - nit kontrole procesa dijeli se na viae istovremenih podprocesa. Izvraava se samo jedan izmeu viae moguih slijednika vora ("OR" izlaz). Izvraava se nekoliko od, ali ne svi slijednici vora (kombinacija "AND" i "OR" operatora). Preduvjet izvraavanja vora je da su svi prethodnici bili izvraeni ("AND" ulaz). Preduvjet izvraavanja vora je izvraavanje bilo kojeg od prethodnika ("OR" ulaz). Preduvjet je izvraavanje nekoliko od prethodnika (ali ne nu~no svi) (kombinacija "AND" i "OR" operatora). Lako je pokazati da sve kombinacije ovakvih postavki nije uvijek mogue u planu realizirati za jedan vor nezavisno od ostalih vorova i strukture cijelog grafa. Naime, dolaziti e do preklapanja (pobijanja) postavljenih izlaznih (za slijednike) i ulaznih (za prethodnike) uvjeta izvraavanja. Na slici 46 to se uo ava na primjerima vorova 13 i 15. Ako se kao preduvjet izvraavanja vora 13 zahtijeva da i vor 5 i vor 6 budu izvraeni, onda izlaz iz vora 2 ne bi trebao biti "OR" nego "AND". Isto tako izlaz iz vora 5 u tom slu aju trebao bi biti "AND". Ako vor 15 "spaja" sve procese iz vorova 13, 9, 10 i 11 tada na voru 4 ne bi trebao biti "OR" izlaz nego "AND". Ili se npr. mo~e postaviti da vor 15 zahtijeva izvoenje vorova 13 i 9 ili 10 ili 11. Meutim uvjeti izvoenja vora 13 odreeni su i uvjetima izvoenja vorova 5 i 6.  INCLUDEPICTURE "linkane slike\\and cvor plana.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 46: Povezivanje razli itih vrsta vorova plana Postavlja se dakle pitanje ima li onda smisla implementirati ovakav na in odreivanja uvjeta paralelnog izvraavanja viae vorova plana. Svakako da bi opisani problem postao daleko izra~eniji i te~e rjeaiv na slo~enijem primjeru plana. Da bi se osigurala konzistentnost razmatranih uvjeta, u proces kreiranja plana trebalo bi implementirati algoritam kontrole mogunosti postavljanja uvjeta. U svakoj situaciji postavljanja novog "AND" uvjeta, kontrolna procedura trebala bi analizirati itav do tada kreirani plan i odrediti da li je novi uvjet mogue postaviti ili ne. Takva kontrolna procedura trebala bi simulirati izvoenje plana i pri tome "ozna avati" izvraene vorove. Svakom voru plana pripadala bi jedna logi ka varijabla kojoj bi se mijenjalo stanje nakon "prolaza kroz vor", odn. izvraavanja vora. Nakon simulacije izvraavanja plana, na temelju analize stanja "oznaka" neposrednih prethodnika vora na kojem se postavlja uvjet, moglo bi se odrediti da li je uvjet mogue postaviti bez kolizije s drugim prethodno postavljenim uvjetima. Meutim, za tako postavljenu koncepciju kontrolnog algoritma treba joa istra~iti kako bi se rijeaile povratne veze, tj. petlje. Detaljnom analizom i razradom predlo~enog algoritma kontrole ovaj rad se nee dalje baviti. Stoga e se joa samo razmotriti jedno od jednostavnijh rjeaenja razmatranog problema - da se uvjeti paralelnog izvoenja viae vorova postavljaju ili samo za dijelove grafa sa viae slijednika vora (na izlazu iz vora) ili samo za viae prethodnika (na ulazu u vor). Pri tome se "OR" ilzaz i "OR" ulaz smatraju "normalnim" na inom izvoenja plana koji se u grafu ne moraju posebno ozna avati. Mo~e se pretpostaviti da je zna ajnije u planu unaprijed odrediti ato treba u initi na izlazu iz vora. Preduvjeti ulaza, odnosno izvraavanja vora viae su stati ke prirode. Ovdje se pretpostavlja da je lakae rjeaavati mogue neplanirane situacije na ulazu u vor, (u tijeku izvoenja plana), a unaprijed u planu predvidjeti na ine izvoenja izlaznih grana. Meutim ostaje i dalje otvoreno pitanje na ina spajanja viae podijeljenih procesa. Npr. ako vor 1 ima "AND" izlaz, nastavlja se sa tri paralelna procesa. Ako se nakon vora 5 pree na vor 13, i ako vorovi 2, 4, i 5 imaju "OR" izlaze onda bi se sva tri procesa mogla spojiti opet u voru 15. U takvoj situaciji trebalo bi odrediti da li onda vor 15 treba ekati zavraetak svih od vorova 13, 9, 10 ili 11, ili bi mogao krenuti im jedan od njih zavrai? Druga mogunost je da se nakon vora 5 pree na vor 12. Tada bi se procesi koji su krenuli iz vorova 3 i 4 spojili u voru 15, ali bi ostao aktivan i proces sa vora 12, pa ako se dalje dodaju novi uvjeti, veze i grananja u grafu koji dodatno kompliciraju situaciju & Na temelju izlo~ene analize mo~e se zaklju iti da prikaz procesa usmjerenim grafom mo~e prikazati proces izvoenja plana i uz pretpostavku izvoenja viae vorova istovremeno, ali uz odreena ograni enja i mogue komplikacije. Stoga bi trebalo istra~iti koji su nu~ni uvjeti i ograni enja implementacije tako postavljene koncepcije prikaza i kontrole izvoenja procesa konstruiranja. Metoda prikaza matrice incidencije usmjerenog grafa svoenjem na dvije liste, (tablica 1) omoguuje relativno jednostavnu implementaciju zapisa uvjeta izvoenja slijednika odreenog vora. Zapis stanja vorova ("stanje procesa") Pretpostavka istovremenog izvraavanja viae vorova plana zahtijeva dopune zapisa plana i atributa vorova, na temelju kojih bi aktivni vorovi mogli  komunicirati u tijeku izvoenja plana. Stoga e se ovdje razmotriti  stanje vora kao dodatni atribut vora i  zapis stanja vorova kao podloga za razvoj algoritama usklaivanja izvoenja viae paralelnih procesa obrade vorova. Proces konstruiranja u velikoj veini slu ajeva timski je rad, dakle odvija se na viae radnih mjesta paralelno, a svi rade na istom proizvodu. Plan procesa konstruiranja mo~e se onda postaviti za svakog lana grupe posebno, s time da bi trebao postojati i zajedni ki plan koji modelira koordiniranje pojedina nih aktivnosti i upravlja tokovima razmjene podataka izmeu lanova tima. Druga mogunost (koja se ini jednostavnijom za realizaciju) jest da se model procesa konstruiranja fokusira na skup zadataka koje treba rijeaiti, bez obzira da li na njima radi jedna ili viae osoba. U takvom pristupu, jedan plan procesa konstruiranja imao bi u trenutku izvoenja jedan ili viae aktivnih podprocesa koji bi se odvijali na razli itim vorovima ra unalne mre~e. Sustav distribuirane obrade dijelova konstrukcije razvijaju u  REF _Ref409146578 \r \h [139], na temelju internet tehnologije. Za usklaivanje izvoenja viae podprocesa plana, nu~no je da aktivni vorovi imaju  uvid u stanje svih ostalih vorova u mre~i, posebno u trenucima odlu ivanja o nastavku procesa. To zna i da u toku izvoenja plana treba postojati  zapis stanja procesa koji je na raspolaganju svim aktivnim vorovima. Svaki vor plana u jednom trenutku nalazi se u jednom od moguih stanja, i to stanje zapisano je u  stanju procesa . Svaka promjena stanja nekog vora odmah se bilje~i u  stanju procesa . Pri tome treba osigurati da, u trenutku dok neki od vorova analizira stanje procesa, drugi vorovi ne smiju mijenjati svoja stanja. Osnovna stanja vora su  aktivan i  nije aktivan . Predla~u se slijedee varijante aktivnog stanja vorova: obavlja operacije provjere preduvjeta - za to vrijeme ne smije se mijenjati stanje drugih vorova izvodi svoj niz akcija ili provjera postuvjeta u tijeku je odlu ivanje o nastavku procesa  za to vrijeme ne smije se mijenjati stanje drugih vorova u interakciji s konstruktorom, i eka njegov odgovor vor je aktivan, ali proces obrade stoji i eka: odgovor poruke koju je poslao drugom voru, ili na informacije od drugih vorova, ili da neki drugi vor zavrai svoj proces obrade vor  analizira stanje procesa  za to vrijeme drugi vorovi ne smiju mijenjati svoja stanja Pored stanja vora, u zapisu stanja procesa trebalo bi za svaki vor voditi i evidenciju aktiviranja, te za svako aktiviranje zapisati i koji ga je prethodnik "pozvao", odnosno pokrenuo. Iz izlo~enog mo~e se zaklju iti da pretpostavka izvoenja viae vorova plana istovremeno otvara itavih niz novih pitanja i problema koje treba rijeaiti. Pri tome treba istra~iti ograni enja mogunosti implementacije, razviti koncepte usklaivanja viae razli itih procesa obrade vorova, tj. "sustav semafora" za komunikaciju preko "stanja procesa". Stoga e se daljnjim razmatranjima zadr~ati pretpostavka izvoenja samo jednog vora istovremeno. Istra~ivanjima sustava sli ne koncepcije bave se Clarkson i Hamilton  REF _Ref409158676 \r \h [119]. Uz svaki konstrukcijski zadatak oni ve~u status zadatka i razinu "pouzdanosti" vrijednosti parametara zadatka, kojima se odreuje da li izvoenje zadatka mo~e zapo eti ili ne. Su elje za prikaz plana konstruiranja Predlo~ena koncepcija plana konstruiranja mo~e se promatrati kao skup osnovnih objekata - ( vorova i matrice zapisa veza vorova) i skup svih ostalih objekata koje vorovi referenciraju direktno ili indirektno. Svi ti objekti spremljeni su u objektnoj bazi. Dakle plan nema "formalnog" zapisa u obliku npr. nizova (slogova) leksi kih elemenata. Odreen oblik takvog zapisa mogao bi se formirati, no on zasigurno ne bi mogao obuhvatiti sve razine referenciranja izmeu objekata. Bilo da se radi o "formalnom" zapisu plana, bilo o skupu objekata u objektnoj bazi, iz takvih zapisa teako je (gotovo nemogue) stei pregled cijelog plana, odnosno tijeka izvoenja. Stoga je potrebno koncipirati skup operacija su elja koje e formirati pregledne prikaze plana konstruiranja na temelju zapisa svih referenci izmeu objekata u objektnoj bazi. Takav pregled plana nu~an je za kontrolu plana prije izvoenja i u tijeku izvoenja, ali prije svega je konstruktoru potreban u procesu kreiranja novog plana. Su elje prikaza plana konstruiranja prete~no e sadr~avati razne varijante upita (query-a) koje trebaju realizirati prikaze referenciranih objekata kroz viae razina referenciranja. Npr. vor ima skup referenci na pravila i listu redoslijeda njihovog izvoenja, svako pravilo ima reference na izraze i akcije, izrazi na atribute objekata, a akcije na operacije objekata. Su elje prikaza plana treba podr~avati prikaze plana za razli ite situacije koje nastupaju u procesima kreiranja, kontrole i izvoenja plana. Operacije su elja prikaza plana nisu dio samog plana konstruiranja, jer su to dijelovi programske realizacije sustava koji se ne spremaju u objektnu bazu. Kreiranje plana konstruiranja Objektna baza sastoji se od dviju komponenti - "rje nika baze" (database dictionary) i same baze u koju se spremaju objekti. Rje nik baze zapis je svih definicija klasa, njihovih relacija i hijerarhijske strukture. Na jednom rje niku mo~e se temeljiti viae baza koje e sve imati istu strukturu klasa, ali razli ite skupove instanci. Stoga svaki plan konstruiranja mo~e biti zapisan u posebnu objektnu bazu. Tako svaku bazu kreiranu na temelju rje nika koji sadr~i sve definicije klasa modela procesa konstruiranja mo~emo promatrati kao "prazni" plan. U procesu kreiranja plana treba generirati sve potrebne instance klasa (objekte) i inicijalizirati reference izmeu njih (pointere), te takve objekte spremiti u bazu. Na kraju procesa kreiranja plana baza e sadr~avati zapis "gotovog" plana koji se mo~e koristiti. Procesom kreiranja plana treba upravljati skup operacija koje trebaju osigurati slijedee osnovne funkcije: Prikaz plana - su elje koje u svakom koraku kreiranja plana treba omoguiti: prikaz svih kreiranih elemenata plana, do najni~e razine referenciranja (prema prethodnom poglavlju), razli ite varijante parcijalnih prikaza strukture - upite i pretra~ivanja, unakrsne preglede, prikaze raspolo~ivih varijanti izbora u razli itim situacijama (posebice pri referenciranju). Mehanizme kontrole osiguranja sintakti ke ispravnosti i potpunosti plana i referenciranih elementa. Mehanizme a~uriranja strukture plana uz osiguranje referencijalnog integriteta, (npr. brisanje ili promjena strukture instanci koje referenciraju ili su referencirane). Povezivanje sa bazama znanja i podataka o proizvodu i procesu konstruiranja. Jedan dio postupaka kontrole ispravnosti elemenata plana i njihovih referenci trebao bi se implementirati u operacije kreiranja nove instance svake od klasa. Svaka klasa mora sadr~avati posebnu vrstu operacije za kreiranje svojih instanci, tj. objekata. Takva operacija u objektnoj terminologiji naziva se "konstruktor". Dakle svaka klasa mora u svojoj operaciji kreiranja instanci sadr~avati implementaciju postupka kontrole ispravnosti u odnosu na proces kreiranja plana. Na taj na in neke od moguih greaaka mogle bi se eliminirati ve na za etku. Operacije za podraku procesu kreiranja plana trebalo bi koncipirati tako da se u svakom koraku (situaciji) kreiranja plana provjerava sintakti ka ispravnost svakog elementa koji se u tom trenutku obrauje. U ovoj fazi istra~ivanja ne mo~e se sa sigurnoau tvrditi da je mogue osigurati potpunu kontrolu, tj. da e uvijek biti kreiran sintakti ki potpuno ispravan plan. Bez obzira na potvrdu ili pobijanje ovakve teze, svaki od entiteta modela procesa konstruiranja treba i u svojim operacijama sadr~avati kontrolne mehanizme. Ovdje se misli na operacije koje se aktiviraju u tijeku izvoenja procesa konstruiranja - npr. dekodiranje (parsiranje) izraza, proces obrade vora, itd. Kontrolni mehanizmi u operacijama entiteta modela procesa pri obradama greaaka u najviae slu ajeva tra~iti e intervenciju od konstruktora. Druga vrsta problema je semanti ka ispravnost i "kvaliteta" plana. Operacije podrake kreiranju plana ni na koji na in ne mogu osigurati izradu "kvalitetnog", tj. "dobrog" plana, ije e izvoenje sigurno (i mo~da optimalno) dovesti do ~eljenog cilja. Koliko je plan "dobar" ili nije, mo~e se provjeriti tek u procesu izvoenja plana. Skup operacija kreiranja plana mo~e se takoer uvrstiti u entitete modela procesa konstruiranja. Takav skup operacija mo~e se implementirati kao jedna tzv. "servisna" klasa, koja nee imati instance. Takva klasa ne sprema se u objektnu bazu, jer nije dio odreenog plana, nego je zajedni ka za sve planove konstruiranja koji se kreiraju u odreenom okru~enju. Kao podloga za nastavak istra~ivanja, predlo~iti e se neke operacije i koraci procesa kreiranja plana: kreiranje parametara, odreivanje i upis u bazu po etnih vrijednosti parametra (koje su npr. poznate iz liste zahtjeva) popunjavanje matrice meuzavisnosti parametara (za novu konstrukciju popunjavanje, a za varijantnu samo doraivanje ve postojee matrice) definiranje funkcionalnih zavisnosti izmeu parametara - zapisivanje matrice meuzavisnosti parametara definiranje objekata prikaza konstrukcije definiranje zadataka, odreivanje ciljeva zadataka, popunjavanje matrice zavisnosti konstrukcijskih zadataka "preslagivanje" matrice zavisnosti konstrukcijskih zadataka, odreivanje sekvencijalnih, paralelnih i spregnutih zadataka definiranje vorova plana (u odnosu na zadatke): odreivanje po etnih uvjeta izvraavanja, lista akcija, postuvjeta kreiranje izraza, akcija i pravila odlu ivanja odreivanje skupova referenci i njihovog redoslijeda izvraavanja u procesu obrade vora definiranje i zapisivanje veza izmeu vorova definiranje pravila odlu ivanja o redoslijedu izvraavanja vorova Proces kreiranja plana trebalo bi koncipirati tako da konstruktor mo~e "preskakati", odnosno naizmjence koristiti operacije, u onom redoslijedu kako mu u odreenoj situaciji odgovara, a da se u svakom trenutku mo~e vratiti na prethodne korake i izvraiti preinake. Detaljna razrada i implementacija postupka kreiranja plana, uz sve prije navedene zahtjeve i funkcije, izvan je opsega ovog rada i mo~e biti tema posebnog istra~ivanja. Uzorci planova Za proces kreiranja plana va~no je i koncipirati organizaciju spremanja kreiranih planova, kao i koncipirati proces kreiranja na temelju uzoraka djelomi no dovraenih planova. Ako se svi objekti svih planova spreme u istu bazu, jednostavnije bi bilo rijeaiti upotrebu istih elemenata u viae razli itih planova. U takvoj koncepciji, u bazi bi bilo spremljeno viae instanci matrica prikaza veza izmeu vorova koje bi pripadale pojedinim planovima. Meutim, ovdje se javlja problem inicijalizacije vrijednosti atributa, jer objekt koji mo~e biti rerefenciran u viae planova, ne mora imati iste vrijednosti atributa u tim planovima. Stoga je kao pogodnija odabrana koncepcija u kojoj se svaki kreirani plan sprema u posebnu objektnu bazu. Planovi konstruiranja za razli ite izvedbe varijantnih konstrukcija sadr~avati e veliki broj objekata koji su zajedni ki za sve izvedbe ili za pojedine varijante izvedbe. Za takve slu ajeve mogu se kreirati i spremiti kao posebne baze "uzorci" planova koji sadr~e sve zajedni ke objekte. Na taj na in proces kreiranja treba "poludovraeni" plan samo razraditi do kraja - tj. inicijalizirati atribute, neke od referenci i eventualno dodati ili obrisati neke objekte i reference. Prvi korak pri kreiranju novog plana bilo bi stvaranje nove kopije uzorka plana, da bi "original" uzorka ostao nepromijenjen. Prema predlo~enoj koncepciji mogu se razraditi uzorci planova za skupove varijanti konstrukcije, ali i za razli ite situacije i metode konstruiranja. Izvoenje plana konstruiranja Razmatrati e se proces izvoenja plana pod pretpostavkom izvoenja samo jednog vora istovremeno. Novokreirani plan spremljen je kao posebna objektna baza koja se temelji na definicijama klasa u "rje niku baze". Operacija izvoenja plana treba otvoriti bazu plana, u itati po etni vor iz baze u memoriju i pokrenuti proces obrade po etnog vora. Svaki vor na zavraetku svog procesa obrade poziva proces obrade slijedeeg vora. Proces obrade mo~e se prekidati interakcijama sa konstruktorom, nakon ega on odreuje to ku nastavka procesa. U takvim slu ajevima konstruktor mo~e odrediti redoslijed izvraavanja vorova koji nije predvien u planu, tj. zapisan u matrici veza izmeu vorova. Sa stanoviata procesa izvoenja plana treba razlikovati tri podklase vorova: po etni vor (svaki plan ima samo jedan po etni vor) meu vor - po zavraetku svoje obrade bira slijedei vor krajnji vor - njegov zavraetak obrade ujedno je i kraj procesa izvoenja plana Svaki plan ( mora sadr~avati jedan i samo jedan po etni vor P i najmanje jedan krajnji vor K, uz proizvoljni broj meu vorova M: ( = { P, ( Mi , ( Kj } i ( {0, & n} ; j ( {1, & m} Iterativni procesi modeliraju se u predlo~enoj koncepciji plana povratnim izvranim vezama (slika 45). To zna i da se mo~e ponavljati izvoenje odreenih nizova vorova, analogno pojmu "petlje" u programskim jezicima. U tijeku izvoenja iterativnih procesa mogu se promijeniti po etni uvjeti ili mogu posati raspolo~ive informacije koje to prije nisu bile. Primarno za takve slu ajeve predviene su mogunosti doraivanja plana u tijeku njegovog izvoenja, prema razmatranjima u poglavlju  REF _Ref409191431 \r \h 7.3.3. Procesi iteracije mogu biti unaprijed planirani, ali mogu biti i neplanirani - uzrokovani i greakama i propustima konstruktora ili dodatnim ili promijenjenim zahtjevima naru itelja proizvoda (slika 24, poglavlje 6). Operacija procesa izvoenja plana trebala bi biti koncipirana tako da omogui prekid izvoenja plana, i nakon toga nastavak na istoj to ci i sa istim stanjem plana kao da prekida nije niti bilo. Koncepcija plana koji je u cijelosti spremljen u objektnoj bazi omoguuje jednostavnu realizaciju takvih zahtjeva. itav tijek procesa obrade svakog vora i interakcije sa konstruktorom bilje~e se u "zapis tijeka izvoenja procesa" koji se mo~e koncipirati kao ASCII datoteka. Plan konstruiranja, nakon ato se izvede, zajedno sa svim svojim referenciranim objektima, zapravo ini organizirani skup zapisa informacija o proizvodu. Stoga bi trebalo razlikovati dva stanja odreenog plana: "neizvedeno" - inicijalno stanje, i "izvedeno" - zavrano stanje. Za svaki pojedini plan trebalo bi sa uvati "neizvedeno" inicijalno stanje kao posebnu bazu, a pored toga mogu se arhivirati i sva izvedena stanja plana. Stoga prije izvoenja novokreiranog plana treba prvo arhivirati kopiju inicijalnog stanja. Uz svako izvedeno stanje plana takoer treba arhivirati i datoteku sa zapisom tijeka izvoenja procesa. Jedno okru~enje izvoenja procesa konstruiranja (konstrukcijski ured) vjerojatno e s vremenom kreirati i koristiti dosta razli itih varijanti planova, pa e se ovdje predlo~iti koncepcija organizacije manipuliranja sa zapisima planova. Da bi se organizirao zapis izvedenih kopija planova, u model procesa konstruiranja uvodi se objekt "plan", koji treba sadr~avati listu svih svojih izvoenja, tj. popis naziva i putanja do datoteka s objektnim bazama koje sadr~e zapise izvedenih varijanti plana. Objekt "plan" sadr~i slijedee atribute: naziv plana, opis plana referencu na konstruktora koji je kreirao plan i koji je za njega odgovoran putanju do datoteke koja sadr~i rje nik baze putanju do datoteke koja sadr~i inicijalno stanje plana popis izvoenja kopija inicijalnog stanja plana koji sadr~i slijedee elemente: referencu na konstruktora koji je "izveo" kopiju plana naziv datoteke sa zapisom izvedene kopije plana i naziv datoteke sa odgovarajuim zapisom tijeka izvoenja plana Skup operacija izvoenja plana, kao i operacije kreiranja plana mogu se implementirati kao jedna "servisna klasa" koja nema instance i ne sprema se u objektnu bazu. Operacije izvoenja plana trebaju uklju iti i su elja prikaza plana. U tijeku izvoenja plana takva su elja prikazuju stanja bitnih elemenata odvijanja procesa. Su elja prikaza plana trebaju u trenucima prekida procesa omoguiti konstruktoru pregled i mijenjanje bilo kojeg elementa plana. Komponente realizacije sustava ra unalne podrake konstruiranju Predlo~eni model ra unalne podrake procesu konstruiranja temelji se na objektno orijentiranom pristupu modeliranju i razvoju programskih sustava. Jezgru takvog sustava ini skup klasa koje modeliraju entitete definirane u sedmom poglavlju rada. Operacije kreiranja i izvoenja plana realiziraju se kao "servisne" klase, dok sve ostale klase ine "rje nik" objektne baze na temelju kojeg se kreiraju baze sa "strukturalnim kosturom" plana procesa konstruiranja. Koncepcija predlo~enog objektnog modela razvijana je s ciljem da se implementira kao nadogradnja, a ne kao zamjena postojee strukture ra unalne podrake. Stoga e se u ovom poglavlju ukratko razmotriti odnos programskih komponenti objektnog modela procesa konstruiranja i ostalih programskih alata ra unalne podrake konstruiranju i procesu proizvodnje. Pri tome se pretpostavlja situacija implementacije predlo~enog modela u okru~enje koje ve koristi sve oblike ra unalne podrake konstruiranju.  INCLUDEPICTURE "linkane slike\\PROGRAMSKE KOMPONENETE SUSTAVA.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 47: Komponente ra unalne podrake u procesima kreiranja i izvoenja plana konstruiranja U ovom poglavlju objektni model procesa konstruiranja promatra se kao dio cjelokupnog sustava ra unalne podrake procesu konstruiranja (slika 47). Pri ovom razmatranju izdvojiti e se baze podataka i baze znanja, a ostale komponente sustava ra unalne podrake promatrati e se kao skup programskih alata. Proces obrade vora plana konstruiranja koristi i poziva "vanjske" programske alate preko instanci klase "su elja programskog alata". U procesu kreiranja i izvoenja plana konstruktor mora imati na raspolaganju organizirane zapise znanja o na inu koriatenja i implementiranim metodama programskih alata, pogotovo za alate specifi ne domene. Stoga se predla~e koncepcija "baze programskih alata". Isto tako konstruktor pri kreiranju i izvoenju plana treba imati i su elja prema bazama znanja i bazama podataka. Koriatenje takvih su elja treba implementirati u operacije kreiranja i izvoenja plana (slika 47). Programske komponente objektnog modela procesa konstruiranja Na slici 47 prikazane su osnovne komponente realizacije objektnog modela procesa konstruiranja. Skup svih klasa modela procesa razmatranih u poglavljima 7.1, 7.2 i 7.3 temelj je za kreiranje rje nika objektne baze plana konstruiranja. Sve spomenute klase trebaju biti dio aplikacije ijim preprocesiranjem nastaje rje nik baze. Operacije kreiranja i izvoenja plana zasebne su aplikacije, ali i one trebaju sadr~avati sve klase objektnog modela, pa su dio osnovnog skupa klasa, ali ne i rje nika objektne baze. Operacije kreiranja i izvoenja plana trebaju kreirati instance svih drugih klasa, spremati ih u bazu i u itavati iz baze. Na temelju rje nika baze kreira se objektna baza koja sadr~i samo definicije klasa, bez instanci, odnosno objekata. Takva baza (prazni plan) podloga je za kreiranje "uzorka plana" - djelomi no dovraenog plana koji sadr~i sve ato je zajedni ko svim izvedbama varijantnih konstrukcija. Plan konstruiranja kreira se na kopiji "praznog plana" ili na kopiji "uzorka plana". Prije izvoenja kreirani plan arhivira se za slijedeu upotrebu. Nakon procesa izvoenja plan konstruiranja sadr~i sve vrijednosti parametara konstrukcije i skupove referenci na zapise informacija o konstrukciji. Izvedeni plan zapravo je zapis konstrukcije i tijeka izvoenja procesa konstruiranja i kao takav se ne mo~e ponovo izvesti, nego se arhivira. Operacije kreiranja i izvoenja plana koriste su elja prema bazama podataka, bazi znanja i bazi programskih alata. Sve navedene komponente trebale bi biti kontrolirane jednom "glavnom" aplikacijom koja upravlja sa viae objektnih baza. Arhiva kreiranih planova i arhiva izvedenih planova mogu se realizirati kao posebne aplikacije iji je zadatak voenje evidencije o datotekama sa zapisima planova i implementacija su elja za pretra~ivanja takvih skupova baza. Spomenute arhive mogu se realizirati kao objektne baze u kojima su spremljene instance objekta "plan". Atributi objekta "plan" navedeni su u poglavlju  REF _Ref409171730 \r \h 7.3.6. Baze znanja i baze podataka U procesu konstruiranja koristi se gotovo cjelokupno znanje kojim raspola~e okru~enje u kojem se proces konstruiranja odvija (proizvodno poduzee ili projektni ured). To je samo jedan od razloga da koncipiranje baze znanja predstavlja vrlo zahtjevan zadatak (i kvalitativno i kvantitativno). Istra~ivanjima na ina zapisa i eksploatacije znanja, i primjeni metoda umjetne inteligencije u CAE sustavima posveeno je viae pa~nje nego ra unalnoj podraci voenju i odvijanju samog konstrukcijskog procesa. U ovom radu predla~e se koncipiranje baze znanja kao sustava  otvorene kutije s alatima . Drugim rije ima to bi trebao biti skup raznorodnih metoda, implementiranih raznorodnim programskim alatima koji bi bili povezani zajedni kom kontrolnom strukturom i mehanizmom izmjene informacija. Pri tome bi se za odreene vrste znanja i zahtjeva na prikaz znanja koristile za njih pogodne metode ili kombinacije metoda. Mehanizam povezivanja raznorodnih alata, odnosno dijelova baze znanja mogao bi se ostvariti u obliku  meta - baze  REF _Ref409186113 \r \h [140]. Takva  meta-baza sadr~avala bi znanje o svim pojedinim dijelovima baze znanja, odnosno o vrstama i domenama znanja, te implementiranim metodama prikaza i pristupa znanju, tj. na inima koriatenja znanja. Domene znanja mogu se razvrstati na proizvode i njihove dijelove, parametre sredstava i okru~enja za proizvodnju, tehnoloake postupke, metode projektiranja i prora una, propise i preporuke, standarde, kao i cjelokupnu dokumentaciju, odnosno nosioce zapisa informacija koji kolaju u proizvodnom sustavu. Kao dio  meta - baze moglo bi se realizirati i su elje povezivanja sa komponentama objektnog modela procesa konstruiranja. Prijedlog strukturiranja baze znanja kao dijela sustava ra unalne podrake procesu konstruiranja razvijen je u  REF _Ref409159332 \r \h [135]. Povezivanje procesa kreiranja plana s bazom znanja trebalo bi realizirati na takav na in da konstruktor u svakom trenutku procesa kreiranja plana mo~e pretra~ivati bazu znanja (bez prekida procesa kreiranja) i eventualno i prenositi podatke iz baze znanja. U situacijama kad proces obrade plana zatra~i intervenciju od konstruktora, takoer se treba omoguiti pristup bazi znanja. Operacije procesa kreiranja i izvoenja plana konstruiranja trebaju takoer omoguiti i pristupanje bazama podataka. U procesu konstruiranja koriste se razli ite baze podataka: katalozi standardnih dijelova, EDM / PDM sustavi, a konstruktoru mogu trebati i neki podaci iz poslovnih sustava. U objektnom modelu procesa konstruiranja trebalo bi stoga implementirati zajedni ko su elje za pozive i pristup pojedinim bazama podataka. Baza programskih alata "Programskim alatima" smatraju se svi oblici ra unalne podrake koja se koristi u procesu konstruiranja, a nisu implementirani kao komponente objektnog modela procesa konstruiranja Naj eae e to biti razni numeri ki prora uni pisani u proceduralnim jezicima, no mo~e biti i npr. tabli ni kalkulator, ekspertni sustav, baza podataka, itd. Pri tome se mogu koristiti i vlastite razvijene aplikacije (za odreenu usku domenu) kao i komercijalne aplikacije ope namjene. Predlo~eni model procesa konstruiranja integrira takve raznorodne oblike ra unalne podrake koriatenjem su elja programskih alata. Su elja moraju poznavati strukturu ulazno/izlaznih podataka i na ine dobave podataka programskog alata kojem pripadaju. U procesu kreiranja i izvoenja plana konstruktor mora imati na raspolaganju pregled mogunosti i implementiranih metoda pojedinih programskih alata. Pogotovo to vrijedi za domenom zavisne alate, gdje e npr. jedan prora un esto imati i nekoliko razli itih verzija. Stoga se ovdje predla~e "baza vanjskih programskih alata" kao pomona komponenta kreiranja i izvoenja plana procesa konstruiranja. Takva baza sadr~avala bi kategorizaciju i detaljne opise svakog programskog alata. Skup zapisa znanja o programskim alatima mo~e se realizirati kao objektna ili kao relacijska baza podataka. Primjer prototipa takve baze realiziran je u  REF _Ref409257866 \r \h  \* MERGEFORMAT [5]. smjestiti par re enica o svim radovima koji neato pokuaavaju s objektnim pristupom u konstruiranju pregled pristupa definiranju, tretiranju i modeliranju objekata - mo~da bolji naslov za poglavlje - radovi : 28, 37, 47, 48, 49, 67, 76, 149, 152, 156, 187, 193, 254, ???? Realizacija predlo~enog objektnog modela Prethodna (sedma) glava rada opisuje konceptualni i informacijski model procesa konstruiranja, prema slici 1 i slici 22. U ovoj glavi razraditi e se prijedlog preslikavanja (implementacije) entiteta fenomenoloakog modela u ra unalni model, tj. u programski sustav implementiran u objektno orijentiranom jeziku. UML jezik odabran je za specificiranje, dokumentiranje i vizualizaciju elemenata i strukture predlo~enog objektnog programskog sustava. Odreeni aspekti implementacije predlo~enih entiteta ve su razmatrani u prethodnom poglavlju - npr. koncepcija zapisa plana konstruiranja kao skupa objekata spremljenih u objektnu bazu. Mogunosti modeliranja relacija u objektnoj bazi diktiraju smjernice modeliranja nekih od entiteta predlo~enih u sedmom poglavlju rada. Stoga e se na po etku dati primjer jednostavne objektne baze koja ilustrira razli ite na ine modeliranja relacija. Primjer je dan kao uvod u predlo~enu koncepciju implementacije svih do sada razmatranih relacija izmeu skupova objekata istih ili razli itih klasa. Relacije modelirane kao skupovi referenci jednog objekta, ili skupovi objekata iste klase koji sadr~e skupove referenci, ine osnovu koncepcije realizacije predlo~enog objektnog modela. Realizacijom takve koncepcije potvruje se teza "da je objektnim metodama mogue efikasno modelirati mre~nu topologiju procesa konstruiranja". U ovom poglavlju biti e pokazano da je u objektnoj bazi mogue modelirati i zapisati kompleksnu mre~u relacija izmeu entiteta modela, prema razmatranjima u poglavlju  REF _Ref409174182 \r \h 7.2.2, tablica 3. Modelirana mre~a relacija mo~e biti vrlo slo~ena, sa viae razina referenciranja. Objektna baza posjeduje efikasne mehanizme manipulacije sa velikim brojem objekata i njihovih referenci pri u itavanju, spremanju i brisanju objekata iz baze. Modeliranje relacija Objektna baza ne sprema samo objekte, nego i sve relacije izmeu objekata koje su definirane u aplikaciji. Kad se spremljeni objekt u ita, sve njegove reference se reaktiviraju, tj. u itavaju se i svi referencirani objekti i podaci, a pokaziva i se inicijaliziraju na prave memorijske adrese. Definiciji klase iji se objekti ~ele spremiti u bazu, treba prethoditi klju na rije  "persistent". Ovdje e se dati kratki primjeri moguih na ina definiranja i spremanja relacija izmeu objekata u objektnoj bazi "POET". Postupkom "preprocesiranja", programski kod svih klasa definiranih kao stalne ("presistent") prevodi se u tzv. "rje nik baze" (database dictionary). Rje nik baze posebna je datoteka koja sadr~i definicije svih klasa i njihovih relacija. Jedan rje nik mo~e biti osnova za viae baza koje imaju istu strukturu, ali razli ite podatke. Relacije se mogu se kategorizirati prema na inu implementacije: pokaziva  ("pointer") na jedan objekt skup pokaziva a na niz objekata ("set") reference prema zahtjevu ("on demand references") ugraeni (sadr~ani) objekti, ("embedded objects") Pokaziva i na objekte Referenciranje objekta koriatenjem pokaziva a (pointera) u C++ jeziku, zapravo je modeliranje relacije. U objektnoj bazi takva relacija se mo~e spremiti, ali i referencirani objekt mora takoer biti ozna en kao "persistent". Na ovaj na in mogu se modelirati relacije "jedan prema jedan". Pokaziva  mo~e referencirati objekt iste klase ili neke druge klase. persistent class Osoba { . . . . Osoba * VaznaOsoba; // referencirani objekt je takoer instanca klase "Osoba" }; Ugraeni objekti Ugraeni objekti ("embedded objects") spremljeni su direktno unutar stalnog objekta. Ugraeni objekt nema identiteta, pa ne mo~e postojati (biti spremljen) kao takav u objektnoj bazi. Ugraeni objekti mogu biti stalni i tranzijentni, u oba slu aja spremaju se unutar objekta koji ih sadr~i, bez objektnog identiteta. class Adresa //ovo nije stalna ("persistent") klasa { . . . . }; persistent class Osoba { PtString Ime; PtString Prezime; Adresa Domicil; // ugraeni objekt . . . . }; Skup Pri definiranju modela baze podataka relacije "jedan prema viae" mogu se modelirati pomou skupova. Objekti u skupu mogu biti pokaziva i na stalne objekte, "on demand" reference, tranzijentni ("non-persistent") objekti ili literali osnovnih tipova podataka jezika C++. POET sadr~i tri na ina implementacije skupova koji na razli ite na ine upravljaju memorijom. Skupovi ne smiju sadr~avati stalne (persistent) klase direktno jer bi to moglo rezultirati viaestrukim kopijama istog objekta u memoriji, ato naruaava identitet objekta. Isto tako skup ne smije sadr~avati pokaziva e na osnovne tipove podataka i pokaziva e na tranzijentne objekte. persistent class Osoba { PtString Ime; PtString Prezime; lset<Dijete*> Djeca; //skup pokaziva a na instance klase //"Dijete" }; Reference prema zahtjevu POET objektna baza rjeaava reference na stalne objekte u itavanjem referenciranog objekta u memoriju i smjeatanjem njegove memorijske adrese u pokaziva  (pointer). Na taj na in uvelike se pojednostavljuje programiranje translatiranjem referenci iz baze direktno u C++ reference. Meutim takav pristup mo~e zauzeti zna ajne koli ine memorije ako objekti sadr~e mnogo referenci, a mo~e i usporiti proces kada treba u itati sve referencirane objekte. Klju na rije  "ondemand" deklarira reference na stalne objekte koje ne treba automatski u itavati, nego se u itavaju po potrebi, tek na poseban zahtjev aplikacije. Na taj na in mogue je kontrolirati koji e se referencirani objekti u itati, i kada. Mogue je deklarirati skupove "ondemand" referenci koji su posebno korisni u situacijama kada skup sadr~i veliki broj referenci. Stoga koriatenje skupova "on demand" referenci omoguuje modeliranje i manipuliranje velikim i kompleksnim mre~ama relacija, kakve postoje izmeu objekata modela procesa konstruiranja. Ovakvo svojstvo POET objektne baze va~no je za dokazivanje hipoteze rada - da je u objektnoj bazi mogue modelirati mre~nu topologiju procesa konstruiranja. persistent class Prikaz proizvoda { PtString Naziv; PtString Identifikator; . . . . ondemand<Sucelje programskog alata> Proracun vratila; // referenca "prema zahtjevu" na objekt druge klase cset<ondemand<Parametar>> Parametri; // skup "on demand" referenci na pripadajue parametre }; Referenca "na zahtjev" je referenca na stalni objekt, ona upotrebljava identitet objekta da uspostavi referencu (relaciju). Stoga ova vrsta reference mo~e pokazivati samo na stalne objekte. Zavisni objekti Zavisni objekti (dependent objects) omoguuju kreiranje relacija izmeu objekata uz referencijalni integritet. Zavisni objekt ne mo~e postojati bez objekta koji ga posjeduje. Kada se objekt "vlasnik" briae, briae se takoer i zavisni objekt. persistent class Tvrtka : public Osoba { . . . . PtString Naziv tvrtke; depend cset<Osoba*> zaposlenici; // ako se obriae "Tvrtka" obrisati e se i svi // referencirani zaposlenici }; Primjer zapisa razli itih vrsta relacija u POET bazi U ovom poglavlju razraen je jednostavni primjer modeliranja relacija izmeu objekata, kao ilustracija prethodno iznesenog, i kao uvod u prikaz implementacije predlo~enog objektnog modela procesa konstruiranja u POET objektnoj bazi. U primjeru je definirano pet klasa - "Zadatak", "Konstruktor",  Parametar ",  Sadr~aj i Adresa". Slike 48, 49, i 50 su razli ite varijante prikaza strukture jedne instance klase "Zadatak" i  Konstruktor . Manji (unutarnji) prozor prikaz je strukture odabranog objekta iz baze, a vei prozor pregled je svih objekata u bazi. U lijevoj polovici prozora objekta prikaz je strukture relacija odabranog objekta (pokaziva i i ugraeni objekti). Na slikama je u desnoj polovici manjeg prozora "otvoren" prikaz objekata koji su u relaciji s objektom. Klasa "Zadatak" sadr~i tri vrste relacija: Objekt "sadr~aj zadatka" je ugraeni objekt klase "Sadr~aj" (slika 49). Pokaziva  (pointer) na objekt klase  Konstruktor . Na slici 49 "otvoren" je prikaz objekta "konstruktor" iju adresu sadr~i pokaziva . Na ovaj na in modelirana je relacija "jedan prema jedan". Skup (set) pokaziva a na objekte klase "Parametar", koji modelira relaciju "jedan prema viae", tj. koji su klju ni parametri zadatka. Na slici 48 "otvoren" je prikaz popisa parametara, odnosno popis instanci na koje pokazuje skup pokaziva a (pointera). Klasa  Konstruktor sadr~i ugraeni objekt klase  Adresa (slika 50). Programski kod primjera: persistent class Zadatak { Konstruktor* p_konstruktor; PtString Naziv; PtString Cilj; sadrzaj sadrzaj_zadatka; lset parametri_zadatka; }; persistent class Parametar { PtString Naziv; PtString Vrijednost; }; persistent class Konstruktor { PtString Ime; PtString Prezime; Adresa Domicil; }; persistent class Adresa { PtString Grad; PtString Ulica; PtString Broj; }; persistent class sadrzaj { PtString opis_sadrzaja; };  INCLUDEPICTURE "linkane slike\\POET primjer rel zad 1visio.gif" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 48: Skup referenci na objekte ("lset")  INCLUDEPICTURE "linkane slike\\POET primjer rel zad 2.gif" \* MERGEFORMAT \d   INCLUDEPICTURE "linkane slike\\POET primjer rel zad 3.gif" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 49: Pokaziva  na objekt druge klase Slika  SEQ Slika \* ARABIC 50: Ugraeni objekt Specifikacija predlo~enog objektnog modela koriatenjem UML-a Premda su dijagrami najuo ljiviji dio UML-a, postoji niz informacija koje nastaju u procesu modeliranja, a koje se bolje prikazuju kao tekstualni opis ili tablice. Zadatak je alata za modeliranje da omogui lak prijelaz izmeu razli itih vidova opisa modela, uz o uvanje konzistentnosti cijelog modela. Autori UML-a razvili su i takav alat za modeliranje - "Rational Rose", koji je zapravo svojevrsna baza podataka o modelu - svim definiranim dijagramima, klasama, njihovim relacijama, atributima i operacijama. Spomenuti programski alat, ato je joa va~nije, osigurava konzistentnost i sintakti ku ispravnost modela. Slika 51 u dva dijela prikazuje osnovnu strukturu zapisa definicija klasa i njihovih relacija, kako izgledaju u su elju programskog paketa "Rational Rose". Na lijevoj polovici slike ekspandirana je lista elemenata u paketu "gradbeni elementi", a u desnoj polovici ekspandirani su paketi "relacije" i paket "prikaz i kontrola procesa". Pojam paket (package) element je UML-a koji omoguuje kategorizaciju i organizaciju elemenata modela u obliku hijerarhijskog stabla. Paket mo~e sadr~avati klase, relacije izmeu klasa i dijagrame. Relacije zavisnosti i pripadnosti izmeu instanci klasa u UML-u modeliraju se kao asocijacije (associations).  INCLUDEPICTURE "linkane slike\\ROSE model1.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 51: Struktura zapisa objektnog modela procesa konstruiranja Dijagrami klasifikacije prikaza proizvoda, akcija i su elja programskih alata dani su u sedmoj glavi, pa se ovdje nee posebno navoditi. U nastavku ovog poglavlja nastojati e se predo iti na ini implementacije elemenata (entiteta) modela procesa konstruiranja istim redoslijedom kako su razraeni u sedmoj glavi. Gradbeni elementi modela procesa konstruiranja Entiteti razraeni u poglavlju  REF _Ref409143054 \r \h 7.1, preslikani su skup klasa organiziranih u paketu "gradbeni elementi" (lijevi dio slike 51). Relacije izmeu ovih klasa razmatrati e se izdvojeno, na nekoliko dijagrama koji su dio paketa "relacije". Klase "akcija", "prikaz proizvoda", "struktura proizvoda" i "su elje programskog alata" apstraktne su klase. Takve klase slu~e kao "nosioci" hijerarhije klasifikacije, tj. one nee imati instance. Instance e imati njihove podklase kao specijalizacije apstraktne klase. Podklase nasljeuju sve atribute i operacije nadreene klase, ali i sve definirane asocijacije (relacije) nadreenih klasa, ato je posebno va~no za predlo~enu koncepciju realizacije mre~e relacija izmeu klasa u modelu. Klasa "baza parametara" takoer nee imati viae instanci, ona se implementira kao "servisna klasa" sa skupom operacija. Operacije "baze parametara" implementiraju hijerarhijsku klasifikaciju skupa svih instanci parametara koritenjem atributa parametra "naziv grupe". Svaki parametar ima oznaku grupe kojoj pripada (slika 28 u  REF _Ref409195927 \r \h 7.1.2.1), a strukturom grupa upravlja baza parametara. Na ovaj na in izbjegava se klasifikacija parametara koja bi dodatno zakomplicirala asocijacije (relacije) u kojima sudjeluje parametar, kao i kreiranje novih grupa parametara u tijeku generiranja plana (jer bi trebalo dodati novu podklasu u model baze za svaku novu grupu parametara). Dodavanje nove podklase zna i i definiranje nove varijante rje nika baze, ato zna i i kreiranje plana ispo etka. Relacije u modelu procesa konstruiranja Entiteti predlo~enog modela procesa konstruiranja razraeni u poglavlju  REF _Ref409147518 \r \h 7.2 preslikani su u klase i asocijacije paketa "relacije" (slika 51 i 52). UML jezik razlikuje etiri vrste relacija: zavisnost - promjena specifikacije jednog elementa uti e na drugi element koji ga upotrebljava, generalizacija - relacija izmeu klase i podklase koja se iz nje derivira, realizacija - semanti ki je kombinacija zavisnosti i generalizacije, asocijacija - strukturalna relacija koja specificira veze izmeu objekata istih ili razli itih klasa. Sve relacije razmatrane u poglavlju  REF _Ref409147518 \r \h 7.2 semanti ki odgovaraju asocijacijama. Pojam asocijacije u UML-u, odgovara pojmu relacije u relacijskim bazama. Jedna klasa tako mo~e imati relacije "jedan prema jedan" i "jedan prema viae" sa drugim klasama. Relacija "jedan prema viae" zna i da je svaka instanca npr. "klase A" povezana sa viae instanci npr. "klase B", tj. svaka instanca "klase A" sadr~i skup (polje) pokaziva a na skup instanci "klase B". Asocijacija "jedan prema jedan" modelira se tako da objekt "klase A" sadr~i pokaziva  (pointer) na adresu objekta "klase B". Prikaz modeliranja i zapisa asocijacija "jedan prema viae" i "jedan prema jedan" u objektnoj bazi dan je u poglavlju  REF _Ref409151481 \r \h 8.1. Slika 52 sadr~i listu svih asocijacija definiranih u paketu "relacije". Grafi ki prikazi ovih asocijacija kombinirani su na nekoliko dijagrama ija razmatranja slijede.  INCLUDEPICTURE "linkane slike\\ROSE asocijacije.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 52: Klase i asocijacije u paketu "relacije" Relacije "pripadnosti" razmatrane u poglavlju  REF _Ref409152166 \r \h 7.2.5 preslikane su u asocijacije "jedan prema viae" izmeu dviju razli itih klasa. Relacije zavisnosti Relacije zavisnosti razmatrane u  REF _Ref409193216 \r \h 7.2.3 i  REF _Ref409436808 \r \h 7.2.4 preslikane su u klase, ija jedna instanca predstavlja jedan redak matrice prikaza zavisnosti. Na slici 52 to su klase "zavisnost parametara" i "zavisnost konstrukcijskih zadataka". Klasa "zavisnost parametara" povezana je sa dvije asocijacije sa klasom "parametar", i analogno je klasa "zavisnost konstrukcijskih zadataka" povezana sa dvije asocijacije sa klasom "zadatak". Navedene asocijacije nazvane su "lijevi stupac liste" i "desni stupac liste" (slika 52). Predlo~ena koncepcija temelji se na postupku svoenja matrice na listu (slika 39), prikazanom u poglavlju  REF _Ref409184075 \r \h 7.2.1. Modelirane relacije zavisnosti postavljene su izmeu skupova instanci iste klase (tablica 10). Matri ni prikaz takve relacije mo~e se promatrati kao niz redaka u kojem svaki redak predstavlja jednu relaciju "jedan prema viae", tj. jedna instanca klase ovisi o skupu drugih instanci klase: ai = f ( aj ), j ( {1, & , n}, j ( i. a1a2a3a4a5a6.aninstance povezane sa instancom retkasemantika relacijea1xa1a4a1= (a4)2a2xxa2a3,a6a2=a3+a6a3xxxa3a1,a4,a5..a4x(a4a2..anxxana5,a6Tablica  SEQ Tablica \* ARABIC 10: Zapis skupa realcija zavisnosti izmeu instanci iste klase, sveden na listu Matri ni zapis takve relacije mo~e se na predlo~eni na in modelirati kao klasa u kojoj svaka instanca klase predstavlja jedan redak matrice, a skup svih instanci klase ini prikaz cijele matrice. Kako se onda modelira jedna instanca takve klase, tj. jedan redak matrice? Neka je klasa koja modelira matricu "klasa M", a "klasa A" neka je klasa zavisnost ijih instanci je prikazana matricom. Svaka instanca klase M sadr~i dvije asocijacije prema klasi A: jedan prema jedan - pokaziva  na instancu klase A, " iji je redak " matrice jedan prema viae - skup pokaziva a na instance klase A o kojima ovisi instanca klase A iji je to redak Pored toga, svaka instanca klase "M" mo~e sadr~avati i tekstualni zapis semantike relacije. Na slici 53 je UML prikaz razmatranih asocijacija izmeu klasa.  INCLUDEPICTURE "linkane slike\\UML PP i DSM matrice.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 53: Matrice zavisnosti parametara i zadataka Objektni model matri nog zapisa relacija zavisnosti unutar skupa svih parametara sastoji se dakle od: skupa instanci klase "zavisnost parametara", dvije asocijacije izmeu klasa "zavisnost parametara" i "parametar". Analogno je modeliran i matri ni zapis zavisnosti unutar skupa konstrukcijskih zadataka. Realizacija predlo~ene koncepcije u objektnoj bazi prikazana je na primjeru matrice zavisnosti parametara. Svaka instanca klase "zavisnost parametara" sadr~i: pokaziva  na objekt "parametar" koji je u lijevom stupcu matrice svedene na listu, neka se taj parametar zove pl skup pokaziva a ("lset") na objekte klase "parametar" o kojima ovisi parametar pl tekstualni zapis jednad~bi zavisnosti parametara Na slici 54, u tri manja prozora dane su razli ite varijante prikaza jedne instance klase "zavisnost parametara". Prvi manji prozor s gornje strane prikaz je atributa, gdje se vidi zapis jednad~be zavisnosti parametara. Dalje slijedi prozor u kojem je "otvoren" prikaz parametra na kojeg pokazuje pokaziva  - to je parametar " iji je redak matrice". U treem prozoru "otvoren" je prikaz skupa pokaziva a na sve parametre o kojima ovisi promatrani parametar ( iji je redak matrice").  INCLUDEPICTURE "linkane slike\\POET matrica zavisnosti parametara.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 54: Pregled referenci jedne instance klase "zavisnost parametara" Relacije pripadnosti Relacije "pripadnosti" razmatrane u poglavlju  REF _Ref409152166 \r \h 7.2.5, modelirane su jednostavnije nego relacije zavisnosti, kao asocijacije "jedan prema viae" izmeu dviju razli itih klasa. Ako promatramo relaciju "instance klase B pripadaju instancama klase A", tada svaka instanca klase "A" sadr~i skup pokaziva a na instance klase "B" koje joj pripadaju. Pri tome se matri ni prikaz relacije svodi na listu, prema tablici 6. Na slici 55 je UML prikaz razmatranih asocijacija izmeu klasa.  INCLUDEPICTURE "linkane slike\\UML relacije pripadnosti.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 55: Relacije pripadnosti izmeu razli itih klasa Izrazi, ograni enja i pravila odlu ivanja Prema sintaksi izlo~enoj u  REF _Ref409437152 \r \h 7.2.6, izraz se sastoji od operanada i operatora, gdje su operandi atributi objekata modela procesa konstruiranja ili numeri ke ili znakovne konstante: izraz :: <operand> | <operator> | <operand> { <operator> | <operand> } operand ::= <varijabla> | <konstanta> operator ::= <aritmeti ki operator> | <relacijski operator> | <logi ki operator> | <zagrada> varijabla ::= #naziv_objekta.naziv_atributa Osim samog zapisa izraza kao niza znakova, instanca klase "izraz" mora sadr~avati i skup pokaziva a (pointera) na objekte iji atributi se pojavljuju kao varijable izraza. Meutim, openito gledano, ti objekti mogu biti razli itih klasa, koje nisu derivirane iz jedne zajedni ke klase. Skup pokaziva a mo~e sadr~avati pokaziva e samo na objekte jedne klase i njenih podklasa. Dakle, ako bi instanca klase "izraz" imala skup pokaziva a na objekte koji se u izrazu pojavljuju kao varijable, svi ti objekti morali bi biti instance iste klase ili njenih podklasa. Stoga se ovdje predla~e rjeaenje u kojem izraz mo~e referencirati i razli ite klase objekata. Uvodi se klasa "operand", kao apstraktna klasa sa skupom podklasa, gdje svaka podklasa odgovara jednoj od klasa objekata modela procesa konstruiranja. Tako npr. klasi "parametar" odgovara klasa "op_parametar", koja je podklasa klase "operand". Svaka podklasa klase "operand" sadr~i pokaziva  na objekt odgovarajue klase. Instanca klase "izraz" sadr~i skup pokaziva a na klasu "operand", a time i na njene podklase. Na taj na in klasa "operand" slu~i kao "posrednik" koji preko svojih podklasa realizira skup pokaziva a na razli ite klase. Primjer zapisa referenci izraza u objektnoj bazi dan je na slici 56. Tri manja prozora na razli ite na ine prikazuju elemente zapisa jedne instance klase "izraz". U gornjem manjem prozoru vidi se zapis izraza, a u dva prozora ispod njega "otvoreni" su prikazi svih referenci izraza. Prva razina referenciranja je skup pokaziva a (lset) na instance podklasa klase "operand". U drugoj razini referenciranja, svaka instanca podklasa klase "operand" sadr~i pokaziva  na objekt iji je atribut operand u izrazu. Primjer zapisanog izraza sadr~i etiri operanda (p1.v, p3.v, p5.v i OPP6.s), pa analogno instanca klase "izraz" sadr~i etiri pokaziva a na instance klase "operand". Od toga, prva tri pokazuju na instance klase "op_parametar", a etvrti pokazuje na instancu klase "op_prikaz proizvoda". Obje navedene klase su podklase klase "operand". Instance klase "op_parametar" sadr~e pokaziva e na objekte klase "parametar" iji su nazivi "p1", "p3" i "p5". U dva donja prozora "otvoreni" su prikazi pokaziva a na objekte "p1" i "p3". Instanca klase "op_prikaz proizvoda" sadr~i pokaziva  na objekt klase "prikaz proizvoda", iji je naziv "OPP6".  INCLUDEPICTURE "linkane slike\\POET operandi izraza.gif" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 56: Reference izraza na operande Prema predlo~enoj koncepciji zapisa referenci izraza, operacija "parsiranja" izraza mo~e dohvatiti sve vrijednosti atributa objekata koji su operandi u izrazu, a ujedno operandi izraza mogu biti atributi objekata razli itih klasa. Izrazi se referenciraju u ograni enjima i pravilima odlu ivanja. Jedna instanca ograni enja sadr~i jedan izraz, dok jedna instanca pravila odlu ivanja mo~e sadr~avati viae izraza. Pravila odlu ivanja osim skupa referenci na izraze sadr~e i skup referenci na akcije. UML dijagram svih razmatranih asocijacija klase "izraz" dan je na slici 57. Pune strelice ozna avaju relacije generalizacije (nasljeivanja), a "obi ne" strelice ozna avaju asocijacije (relacije "jedan prema viae" ili "jedan prema jedan"). Na slici 57, radi preglednosti prikazane su samo tri podklase klase "operand".  INCLUDEPICTURE "linkane slike\\UML reference izraza.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 57: Asocijacije klase "izraz" Elementi prikaza i kontrole izvoenja procesa konstruiranja Entiteti predlo~enog modela procesa konstruiranja razraeni u poglavlju  REF _Ref409155949 \r \h 7.3 preslikani su u klase i asocijacije paketa "prikaz i kontrola procesa" (slika 58). Klase " vor plana" i "veza vorova" apstraktne su klase, ije su podklase prikazane na slici 59.  INCLUDEPICTURE "linkane slike\\ROSE prikaz procesa.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 58: Klase i asocijacije u paketu "prikaz i kontrola procesa" Matrica susjedstva i matrica incidencije sadr~e zapis veza izmeu vorova plana konstruiranja. Klase "generiranje plana" i "izvoenje plana" sadr~e skupove operacija, nemaju viae instanci i ne spremaju se u objektnu bazu. Prve etiri asocijacije u paketu "prikaz i kontrola procesa" realiziraju matrice incidencije i susjedstva, a preostale su reference vora plana na elemente koje obrauje u tijeku izvoenja. Klase vorova i veza izmeu njih Klasa " vor plana" ima tri podklase - "ulazni vor", "meu vor" i "zavrani vor", prema razmatranjima u  REF _Ref409171730 \r \h 7.3.6. Sve tri podklase nasljeuju sve skupove referenci od klase " vor plana", prema slici 59. Razlike izmeu ove tri vrste vora su u operaciji procesa obrade vora, npr. "zavrani vor" nema odlu ivanja o daljnjem tijeku, on prekida proces i zatvara bazu i datoteku sa zapisom tijeka izvoenja.  INCLUDEPICTURE "linkane slike\\UML klase cvorova i bridova.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 59: Klase vorova i njihovih veza Klasa "brid - veza vorova" ima podklase "izvrana veza" i "informacijska veza" prema iznesenom u poglavlju  REF _Ref409144297 \r \h 7.3.3.3. Podklase veze vorova referenciraju se u zapisu matrice incidencije (slika 60). Veze izmeu vorova plana zapisuju se u matri nom obliku, u matricu susjedstva i matricu incidencije, prema prikazanom u  REF _Ref409145340 \r \h 4.4.1. Matrica susjedstva implementirana je na isti na in kao i matrice prikaza relacija zavisnosti parametara i zavisnosti zadataka. Svaka instanca matrice susjedstva implementira jedan redak matrice. Pri tome svaka instanca ima jedan pokaziva  na jedan vor plana ( iji je to redak matrice) i skup pokaziva a na vorove koji su s njim povezani. Dakle, klase "matrica susjedstva" i " vor plana" povezane su asocijacijom "jedan prema jedan" i "jedan prema viae" (slika 60).  INCLUDEPICTURE "linkane slike\\UML matrice plana.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 60: Matrice zapisa veza izmeu vorova plana Matrica incidencije modelirana je takoer sa dvije asocijacije. Pri tome se matrica svodi na dvije liste, prema tablici 1. U prvoj listi zapisano je za svaki vor koji su bridovi vezani na njega. Takva lista modelirana je asocijacijom "jedan prema viae" izmeu vora plana i veza vorova. Pri tome e svaka instanca vora plana sadr~avati skup pokaziva a na instance podklasa veze vorova. U drugoj listi na koju se svodi matrica incidencije zapisano je za svaki brid (vezu vorova) koje su krajnje to ke ( vorovi) tog brida. Takva lista modelirana je relacijom "jedan prema dva", tj. svaka instanca veze vorova sadr~i polje od dva pokaziva a na instance vora plana. Reference vora plana konstruiranja vor plana konstruiranja sadr~i skupove referenci na entitete modela procesa konstruiranja koje obrauje. Proces obrade i reference vora detaljno su razmotreni u poglavljima  REF _Ref409191406 \r \h 7.3.3.1 i  REF _Ref409152108 \r \h 7.3.3.2. Sve reference vora modelirane su kao asocijacije "jedan prema viae", odnosno kao skupovi pokaziva a (pointera). Na slici 61, s lijeve strane su reference na akcije, ograni enja i pravila, koji su "objekti" procesa obrade vora, a s desne strane su reference na objekte "pregleda stanja konstrukcije". Reference vora na njemu susjedne vorove u planu (matrica susjedstva) i reference na bridove grafa (matrica incidencije), radi preglednosti izdvojene su na slici 60.  INCLUDEPICTURE "linkane slike\\UML asocijacije cvora.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 61: Asocijacije (relacije) vora plana konstruiranja Specifikacijama i realizacijom predlo~enog skupa entiteta odreena je osnovna struktura objektnog modela procesa konstruiranja koji zadovoljava zahtjeve i ciljeve postavljene u uvodnom dijelu rada, a potvrena je i postavljena hipoteza. Predlo~eni model orijenitran je primarno na unapreenje organizacije i integracije ra unalne podrake. Zamialjeno je da ovako koncipirani model bude jezgra cjelokupnog sustava ra unalne podrake konstruiranju, koja bi ispunjavala slijedee zadae: unapreenje organizacije procesa, planiranjem redoslijeda akcija i tokova informacija unificiranje i standardiziranje na ina zapisivanja informacija o proizvodu u okru~enju timskog rada zapisivanje tijeka izvoenja procesa, a ato je posebno va~no, klju nih odluka i njihovih objaanjenja integriranje postojeih raznorodnih alata ra unalne podrake Primjer plana konstruiranja U ovom poglavlju razraen je primjer plana procesa konstruiranja na postupku konstrukcije rotora elektromotora srednjih snaga. Radi se o varijantnoj konstrukciji u kojoj se koristi velik broj standardnih dijelova i dijelova kojima se samo prilagoavaju dimenzije. Ovaj primjer odabran je zbog poznavanja problematike iz konkretnog proizvodnog okru~enja - autor ovog rada tijekom nekoliko godina razvijao je programsku podraku za konstruiranje navedenog sklopa. Karakteristike elektromotora srednjih snaga iz standardnog programa esto ne odgovaraju u potpunosti zahtjevima naru ioca, pa se u takvim situacijama razvija nova varijanta izvedbe. Pri tome se polazi od elektromagnetskog projektnog prora una, kojim se generiraju osnovni parametri nove varijante izvedbe sklopova koji odreuju karakteristike elektromotora. Izlazni podaci elektromagnetskog prora una osnova su za konstrukciju nove "nestandardne" izvedbe. Takva nova izvedba, mora naravno koristiti standardno kuiate, valjne le~aje, ventilator i ostale dijelove koji nisu direktno vezani na postizanje zahtjevanih karakteristika elektromotora. Ostali dijelovi - rotorski i statorski paket limova, bakreni dijelovi, izolacija, vratilo, tla ne plo e i balansni prsten moraju se konstruirati prema podacima elektromagnetskog projektnog prora una. Ovaj primjer ograni iti e se samo na konstrukciju "nove varijante" sklopa rotora. Rotor elektromotora mo~e se dakle promatrati kao parametarska i adaptivna konstrukcija. Parametri koji se naj eae mijenjaju su du~ina i promjer paketa limova, a o njima ovise dimenzije vratila, bakrenih atapova u paketu, izolacije i joa nekih dijelova. Kod elektromotora srednjih snaga kriti an parametar konstrukcije naj eae je progib vratila ispod rotorskog paketa limova. Progib je to vei, ato je vea du~ina paketa za odreeni razmak le~aja, odnosno du~inu kuiata. Pri ugradnji rotor nije mogue idealno centrirati u odnosu na stator, tako da uvijek postoji odreeni ugradbeni ekscentricitet. Ekscentri nost uzrokuje nesimetri nost magnetskog polja u toku rada motora, tako da uvijek postoji odreena rezultantna magnetska sila koja privla i rotor k statoru. U tijeku perioda zaleta motora vrijednosti privla ne magnetske sile su najvee (istog ili viaeg reda veli ine od te~ine rotora). Tada mo~e doi do vrlo skupe havarije - struganja rotora po statoru. Isto tako, u normalnom radnom re~imu ekscentricitet ne bi trebao biti vei od 20 postotaka zra nog raspora izmeu rotora i statora. Zbog svih navedenih razloga svakako se mora izvraiti kontrolni prora un za svaku novu varijantu izvedbe sklopa rotora. Ovisno o vrsti elektromotora iz proizvodnog asortimana, izvedbe vratila konstrukcijski su dosta raznorodne. Stoga je za prora un progiba, nagiba, momenta i popre ne sile u presjecima vratila odabrana metoda tzv. prijenosnih matrica koja se mo~e poopiti na bilo kakav oblik i polo~aj vratila (horizontalno ili vertikalno). Programski alat za navedenu metodu prora una realiziran je u Fortranu 77. Meutim primjena navedene metode zahtijeva dosta rutinskog posla na pripremi i upisu ulaznih podataka za prora un. Vratilo treba podijeliti na manje segmente (polja) za koje treba na temelju radioni kih crte~a izra unati i odrediti u prosjeku oko stotinu podataka, ato traje po nekoliko sati. U razmatranom primjeru pretpostaviti emo da je razvijen poseban programski alat koji automatski priprema sve potrebne ulazne podatke za kontrolni prora un sklopa vratilo-le~aji-rotorski paket. Na temelju analize rezultata kontrolnog prora una, treba odlu iti da li svi parametri konstrukcije nove izvedbe zadovoljavaju predviena ograni enja. Osim ve navedene provjere progiba i ekscentriciteta rotora u radu, potrebno je provjeriti naprezanje u kriti nom presjeku rukavca vratila, te vijek trajanja i nagib u le~aju s pogonske strane u slu ajevima kada se na rukavac montira remenica. U tom slu aju potrebno je u pripremljeni skup podataka za prora un dodati i podatke o sili zatezanja remena. Ako neka od ograni enja nisu zadovoljena, treba odlu iti da li se problem mo~e rijeaiti promjenama konstrukcije, ili je potrebno promijeniti i osnovne parametre paketa limova, tj. ponoviti elektromagnetski projektni prora un. U oba slu aja potrebno je ponoviti kontrolni prora un sklopa vratilo-le~aji-rotorski paket. Ako svi parametri zadovoljavaju ograni enja, mogu se razraditi radioni ki crte~i svih dijelova sklopa rotora. Opisani se konstrukcijski zadatak esto (svakodnevno) ponavlja, a sastoji se gotovo samo od rutinskih aktivnosti - dohvaanja i obrade podataka, prilagodnog konstruiranja, te kontrolnog prora una. Postepenim razvojem programskih alata, baza podataka o dijelovima sklopa, i parametarskih CAD modela, te njihovim integriranjem mo~e se zna ajno skratiti vrijeme potrebno za rjeaavanje zadatka. Povezivanje programskih alata, te kontrola redoslijeda njihovog izvoenja i toka podataka izmeu njih mo~e se ostvariti koriatenjem zamialjenog primjera plana koji e biti iznesen. Na slici 62 prikazana je skica parametarske konstrukcije sklopa vratilo-le~aji-rotorski paket limova, asinhronog kliznokolutnog elektromotora.  INCLUDEPICTURE "linkane slike\\ROTOR EM vsd.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 62: Skica konstrukcije rotora asinhronog elektromotora  INCLUDEPICTURE "linkane slike\\primjer plana.wmf" \* MERGEFORMAT \d  Slika  SEQ Slika \* ARABIC 63: Grafi ki prikaz razmatranog primjera plana Tijek opisanog procesa konstruiranja modeliran je planom prikazanim na slici 62. U ovom prikazu navesti e se namjena i opisati proces obrade svakog vora. Plan konstruiranja prema predlo~enoj koncepciji skup je objekata i mre~e njihovih referenci zapisanih u objektnoj bazi. Stoga e se dalje navoditi koji objekti se u odreenom voru obrauju. vor 1: Zadatak zapo inje elektromagnetskim projektnim prora unom, koji odreuje sve potrebne podatke za konstrukciju i kontrolni prora un rotora. Prva akcija vora poziva program za elektromagnetski projektni prora un. Su elje ovog programskog alata obavlja transfer izra unatih podataka prema parametrima koji su modelirani kao objekti. U ovom voru odreuje se cijeli niz parametara, tzv. "podaci namota i paketa limova". Izdvojiti emo samo parametre potrebne za definiranje opisane konstrukciju i kontrolni prora un progiba (u tabli nom prikazu plana (na kraju poglavlja) ozna eni su kao "grupa1"): Lp: du~ina rotorskog paketa limova D2p: vanjski promjer rotorskog paketa, D1p: unutarnji promjer rotorskog paketa delta: zra ni raspor B1: indukcija u zra nom rasporu, P1: koeficijent polariteta, Cf: Carterov faktor (za prora un magnetske sile izmeu rotora i statora) Pn: snaga, T: moment n: broj okretaja, Objekti prikaza proizvoda koji se obrauju u voru 1 su lista zahtjeva naru ioca i ra unski podaci elektromagnetskog prora una. vor 2: U ovom voru pokree se su elje prema bazi podataka svih izvedenih varijanti. Baza se pretra~uje po vrijednostima klju nih parametara elektromagnetskih karakteristika motora. Ako se pronae odgovarajue dovoljno sli no ili identi no rjeaenje, poziva se vor 3. Ako niti jedno od postojeih rjeaenja iz arhive ne odgovara (ato je naj eai slu aj), treba pripremiti podatke za konstruiranje nove varijante rotora, te se u tom slu aju poziva vor 4. vor 3: Ako je pri pretra~ivanju baze pronaeno rjeaenje koje odgovara projektnim podacima proizaalim iz zahtjeva naru itelja, potrebno je samo lansirati radne naloge pripremi proizvodnje. U tom slu aju su elje baze treba  prepisati identifikacijske brojeve dokumentacije ve izvedenog rjeaenja. Objekti prikaza proizvoda koji se obrauju u voru 3 su baza izvedenih rjeaenja i radni nalozi pripremi proizvodnje. vor 4: Zadatak ovog vora je pripremiti sve potrebne podatke za konstruiranje sklopa vratilo-le~aji-rotorski paket. Elektromotor mo~e imati prijenos momenta na jednu ili obje strane vratila, a razli ite su i konstrukcije horizontalne i vertikalne izvedbe, stoga je svakoj od ovih vrsta konstrukcije dodijeljen poseban vor (5, 6 i 7). Prva akcija u voru 4 ustanovljava o kojoj vrsti izvedbe elektromotora se radi. Slijedea akcija poziva su elje odgovarajueg CAD modela izvedbe elektromotora. Ovdje je pretpostavljeno da za svaku vrstu izvedbe postoji parametarski CAD model u kojem je ve definiran oblik, tj.  layout konstrukcije. Zadatak su elja CAD modela je transfer vrijednosti parametara koje su odreene u voru 1 prema vrijednostima parametara CAD modela. Na in izvedbe su elja ovisi najviae o mogunostima konkretnog CAD programa koji se koristi. U procesu odlu ivanja, ovisno o naru enoj vrsti izvedbe elektromotora, poziva se jedan od vorova 5, 6 ili 7. vorovi 5,6,7: vorovi 5, 6 ili 7 "otvaraju" parametarski CAD model sklopa rotora.. Kad konstruktor zavrai konstrukciju nove varijante sklopa rotora, "zatvara" CAD model, a su elje CAD modela treba "prepisati" sve novoodreene vrijednosti u odgovarajue parametre modelirane kao objekte. Ovdje izdvajamo samo parametre koji su ulazni podaci u kontrolni prora un sklopa rotora (u tabli nom prikazu plana ozna eni su kao "grupa2"): Is: broj segmenata vratila dsi, lsi : promjeri i du~ine segmenata vratila oli: oznake odabranih kugli nih le~ajeva Gi: te~ine tla nih plo a, balansnih prstena, ventilatora e: pretpostavljeni ugradbeni ekscentricitet U procesu konstruiranja rotora potrebno je provjeriti i skup razli itih ograni enja koja se postavljaju pri provjeri postuvjeta preliminarne izvedbe konstrukcije (u vorovima 5, 6 i 7). Ako CAD program koji se koristi ima takve mogunosti, ograni enja se mogu postaviti unutar modela, u suprotnom nakon zatvaranja CAD modela u procesu obrade vorova 5, 6 ili 7 pokree se provjera postuvjeta. Postuvjeti sadr~e izraze u kojima su referencirani parametri odreeni u voru 1 i u voru 5, 6 ili 7. Ako neka od ograni enja nisu ispunjena, potrebno je mijenjati dimenzije dijelova sklopa rotora, dakle u procesu obrade vora vratiti se na otvaranje CAD modela. Ograni enja u prikazanom primjeru plana uglavnom se odnose na izbor parametara izolacijskih dijelova i razmake dijelova unutar sklopa kojih se konstruktor mora pridr~avati obzirom na meudjelovanja magnetskih polja. vor 8: vor 8 treba "prikupiti" sve potrebne podatke za kontrolni prora un rotora. To su parametari generirani elektromagnetskim prora unom u voru 1 i geometrijski parametri, te te~ine dijelova, odreeni u jednom od vorova 5, 6 ili 7. vor 8 poziva programski alat koji treba kreirati ulaznu ASCII datoteku kontrolnog prora una rotora. Na temelju dimenzija segmenata vratila (odreenih u prethodnom voru) treba podijeliti svaki segment na viae polja i izra unati i upisati sve potrebne podatke u ulaznu datoteku kontrolnog prora una. Ovaj postupak detaljnije je opisan u  REF _Ref409229770 \r \h [141] i  REF _Ref409181248 \r \h [142]. Programski alat za kreiarnje ulazne datoteke koristi i bazu podataka o standardnim kugli nim le~ajevima. vor 9: vor 9 poziva programski alat za kontrolni prora un, a su elje programskog alata obavlja transfer vrijednosti iz izlazne datoteke prora una prema parametrima ije granice vrijednosti treba provjeriti nakon prora una (u tabli nom prikazu plana ozna eni su kao "grupa3"): lh: vijek trajanja le~ajeva, nl: nagib elasti ne linije vratila na mjestu le~aja rmax: maksimalni progib vratila ispod rotorskog paketa limova nk: prvi kriti ni broj okretaja sigmax: maksimalno naprezanje vratila Pravila odlu ivanja u voru 9: Ako je prora un pokazao "struganje" rotora po statoru - povratak na elektromagnetski projektni prora un - potrebno je skratiti paket, ili uzeti drugu visinu osovine (slijedeu veu), dakle proces se vraa na vor 1. Ako je progib vei od 20 % zra nog raspora - konzultirati konstruktora koji odlu uje da li se prelazi na promjenu konstrukcije ( vor 4) ili promjenu projekta ( vor 1). Ako je kriti na brzine vrtnje blizu nominalne (+/- 10%) - konzultirati konstruktora koji odlu uje o daljnjem tijeku procesa Ako je vijek trajanja le~aja manji od zahtijevanog, ili je nagib elasti ne linije u le~aju vei od dvije kutne minute, povratak na vor 4, izbor drugog le~aja i ponavljanje kontrolnog prora una Ako svi prethodni uvjeti nisu ispunjeni, zna i da konstrukcija zadovoljava - mo~e se nastaviti na voru 10 vor 10: Ovaj vor pokree se ako su svi uvjeti kontrolnog prora una zadovoljeni, a zadatak vora je razrada radioni ke dokumentacije. Ako se koristi CAD program koji na temelju 3D modela mo~e generirati crte~e, ovaj vor otvara opet isti CAD model kao i u vorovim 5, 6 ili 7. Nakon zatvaranja CAD modela slijedea akcija vora treba generirati identifikacijske brojeve crte~a. Na kraju treba upisati vrijednosti klju nih parametara u bazu gotovih rjeaenja. Slijedi pregled svih objekata plana po klasama. Objektima su dodijeljene oznake koje se koriste u tabli nom prikazu plana danom na kraju ovog poglavlja. Objekti prikaza proizvoda: lista zahtjeva naru ioca (OPP1) ra unski podaci elektromagnetskog prora una (OPP2) baza izvedenih varijanti (podaci elektromagnetskog prora una relevantni za pretra~ivanje) (OPP3) parametarski CAD modeli sklopa rotora razli itih varijanti izvedbi elektromotora (OPP4, OPP5, OPP6) baza podataka o standardnim kugli nim le~ajevima koji se ugrauju u sve izvedbe elektromotora (OPP7) podaci kontrolnog prora una sklopa rotora (OPP8) radioni ki crte~i dijelova sklopa rotora (OPP9) Programski alati: elektromagnetski projektni prora un rotorskog paketa limova i bakra (PA1) baza podataka o izvedenim varijantama (PA2) 3D parametarski CAD sustav (PA3) priprema i izrada ulazne datoteke kontrolnog prora una rotora (PA4) kontrolni prora un sklopa rotora (PA5) Su elja programskih alata: su elje elektromagnetskog projektnog prora una: transfer ulaznih podataka iz liste zahtjeva i transfer izlaznih podataka elektromagnetskog prora una u skup parametara navedenih u slijedeoj to ci (SPA1) su elje parametarskog CAD modela: transfer podataka iz skupa parametara s geometrijskim podacima rotorskog paketa limova (ulazni podaci za prilagodnu konstrukciju) i transfer podataka prema skupu parametara s geometrijskim podacima vratila (preliminarna konstrukcija na kojoj treba provesti kontrolni prora un) (SPA2) su elje kontrolnog prora una rotora: transfer podataka prema skupu parametara koji su klju ni rezultati prora una i koji se referenciraju u provjerama ograni enja i pravilima odlu ivanja (SPA3) Kao rezime prethodnih izlaganja primjera plana dan je tabli ni prikaz iz kojeg se vidi shema direktnih i indirektnih referenciranja prije navedenih grupa objekata u pojedinom voru plana. Pritom su koriatene oznake objekata navedene u ranijem tekstu u zagradama. vorobjekt prikaza proizvoda koji se obraujeakcijesu elje programskog alatapozvani programski alatparametri koji se odreujupravila odlu ivanja1OPP1, OPP2 poziv PA1, preko SPA1SPA 1PA1grupa 12OPP3postavljanje upita u baziPA2ako je varijanta ve izvedena, pozovi vor 33nalog pripremi proizvodnjeobrada naloga4OPP4, OPP5, OPP6poziv SPA2SPA2izbor naru ene varijante izvedbe elektormotora5OPP4, OPP5, OPP6otvaranje i rad na CAD modeluPA3grupa 26OPP4, OPP5, OPP6otvaranje i rad na CAD modeluPA3grupa 27OPP4, OPP5, OPP6otvaranje i rad na CAD modeluPA3grupa28OPP2, OPP7,: OPP4, 5 ili 6poziv PA4PA49OPP8poziv PA5SPA3PA5grupa 35 pravila navedenih u opisu vora 910OPP9otvaranje i rad na CAD modeluPA3Tablica  SEQ Tablica \* ARABIC 11: Shema referenci vorova razmatranog primjera plana Zaklju ak U skladu s postavljenim ciljem u radu je koncipirana osnovna struktura objektnog modela procesa konstruiranja. Realni sustav ije modeliranje je razmatrano jest proces konstruiranja zamialjen u uredu koji koristi ra unalnu opremu u mre~nom okru~enju i u kojem je ve "uhodano" koriatenje programskih alata za podraku konstruiranju. U uvodnom dijelu analizirane su zna ajke procesa konstruiranja, uz promatranje konstruiranja kao procesa rjeaavanja zadatka. Dan je pregled polaziata koncipiranja modela, pri emu su razmatrani teorijski modeli konstruiranja, primjena metoda planiranja (iz podru ja umjetne inteligencije), openite metode prikaza procesa i topologija prikaza redoslijeda izvraavanja akcija u procesu konstruiranja. Analizirane su metode modeliranja i projektiranja objektnih sustava, uz osvrt na problematiku modeliranja informacijskih sustava u in~enjerstvu. Postavljen je koncept metodologije istra~ivanja u kojem se pojave i koncepti realnog svijeta procesa konstruiranja apstrahiraju i preslikavaju u entitete konceptualne domene. U drugoj stavci hipoteze pretpostavljeno je da se tako definirani entiteti mogu potom preslikati u klase objektnog modela procesa konstruiranja. Ovakva metodologija istra~ivanja odabrana je da bi se kreirao objektni model procesa konstruiranja koji je "prirodniji" i razumljiviji, odnosno ni deskriptivan ni preskriptivan, nego usmjeren ra unalnoj primjeni. U objektno orijentiranom pristupu naglasak je na modeliranju stvarnosti u domeni problema umjesto stvaranja arhitekture modela sustava koja vodi k implementaciji. Stoga se nastojalo preslikati entitete u objekte principom "jedan za jedan", tj. da jednom entitetu konceptualne domene odgovara to no jedan entitet objektne domene. Predlo~eni entiteti konceptualnog modela detaljno su razraeni u sedmom poglavlju rada, u kojem su razraena i njihova preslikavanja u klase objektnog modela. Time je potvrena trea stavka hipoteze. Struktura i definicije predlo~enih entiteta, te realizacija njihovog preslikavanja u klase objektnog modela originalan su znanstveni doprinos. }eljelo se razviti sustav koji bi se mogao primjenjivati neovisno o fazi procesa konstruiranja i vrsti konstrukcijskog zadataka. Ovako postavljeni zahtjev nastojalo se ispuniti tretiranjem procesa konstruiranja primarno kao procesa obrade i generiranja informacija - ne gledajui obradu informacija s konstrukcijskog, nego s informati kog aspekta. Pri tome se pretpostavlja da (s informati kog aspekta) openite zna ajke procesa obrade i generiranja informacija ne ovise o fazi procesa i vrsti konstrukcije. U takvom (informati kom) pristupu promatrane su slo~ene mre~e relacija izmeu struktura in~enjerskih podataka, te je postavljena prva stavka hipoteze - da je takvu mre~nu topologiju mogue efikasno modelirati objektno orijentiranim metodama. U poglavlju 7.2 (tablica 3) razmatrane su mogunosti povezivanja entiteta definiranih kao osnovnih "gradbenih" elemenata modela. Zaklju eno je da je u objektnom modelu mogue postaviti i zapisati kompletnu mre~u relacija (svaki entitet sa svakim), ali da jedan dio tih relacija nema zna enja u kontekstu procesa konstruiranja. Stoga su dalje razraene samo one relacije zavisnosti i relacije "pripadnosti" izmeu gradbenih entiteta modela koje imaju svoj semanti ki smisao u procesu konstruiranja. Predlo~en je zapis relacija izmeu skupova instanci klasa u matri nom obliku, gdje se matrice svode na liste sa nekoliko stupaca. Prikazi relacija, definirani u poglavlju 7.2, realizirani su u okru~enju objektne baze podataka. Pokazalo se da je predlo~enim pristupom mogue zapisati vrlo slo~ene mre~e relacija, sa viaestrukim razinama referenciranja (povezivanja). Mehanizmi upravljanja relacijama izmeu objekata u objektnoj bazi daju daleko sofisticiranije i efikasnije mogunosti modeliranja slo~enih mre~a relacija, nego drugi pristupi (npr. relacijske baze podataka). Druga iji pristupi zahtijevali bi realizaciju isuviae slo~enih algoritama i struktura podataka i procedura koji bi bili izuzetno zahtjevni za implementaciju i odr~avanje. Uz to, osnovna je prednost objektnog pristupa ato se relacije ne postavljaju izmeu "stupaca tablica", nego izmeu objekata, koji su modeli pojmova i in~enjerskih struktura podataka preslikanih iz konceptualnog modela procesa konstruiranja. Preslikavanjem slo~enih in~enjerskih struktura podataka u skup tablica gubi se jedan dio semantike modela. Realiziranjem zapisa mre~e relacija (izmeu objekata u koje su preslikani entiteti konceptualnog modela) u okru~enju objektne baze, dokazana je prva stavka postavljene hipoteze. Razmatranja strukture i na in realizacije mre~e relacija u predlo~enom objektnom modelu procesa konstruiranja, originalan su znanstveni doprinos ovog rada. Mehanizmi nasljeivanja u objektnoj tehnologiji daju joa jednu zna ajnu prednost predlo~enoj koncepciji. Podklase nasljeuju sve definicije relacija svojih "nadreenih klasa", pa se sustav mo~e vrlo jednostavno dograivati uvoenjem novih podklasa kao daljnjih specijalizacija ve definiranih klasa. Time se omoguava inkrementalno unapreivanje i daljnji razvoj modela, pri emu ne treba raditi nikakve promjene osnovne strukture zapisa relacija u ve definiranim klasama. Fleksibilnost predlo~enog modela pri uvoenju u eksploataciju nastojala se ostvariti "bottom up" pristupom pri gradnji elemenata modela. Entiteti konceptualnog modela i klase objektnog modela u koje su entiteti preslikani koncipirani su tako da cijeli sustav djeluje u odnosu na korisnika kao "otvorena kutija s alatima". Tako koncipiran model trebao bi biti otvoren za dogradnje i prilagoavanja specifi nim uvjetima odreene realne okoline. Stoga je postavljena trea stavka hipoteze - da se temeljem osnovnih klasa modela grade slo~eni objekti koji modeliraju prikaz i dinamiku izvoenja procesa. Na vrhu hijerarhije, kao najslo~eniji objekt je "plan konstruiranja" definiran kao model dekompozicije i tijeka izvoenja procesa konstruiranja. Osnovni element plana je " vor plana" definiran kao model etape procesa konstruiranja u kojem se odvija proces izvoenja akcija na objektima zapisa informacija o proizvodu. Osim liste akcija, vor plana enkapsulira provjere preduvjeta i postuvjeta izvoenja akcija, te zapis znanja o planiranom tijeku izvoenja procesa konstruiranja u obliku pravila odlu ivanja. Osnovni entiteti modela (definirani u poglavlju 7.1) i entiteti prikaza relacija (definirani u poglavlju 7.2) koriateni su kao gradbeni elementi slo~enog entiteta " vor plana". Plan je realiziran i zapisan u objektnoj bazi kao skup " vorova plana", veza vorova, i svih objekata koje vorovi referenciraju. U radu su usporeene pretpostavke istovremenog izvoenja samo jednog vora i istovremenog izvoenja viae razli itih vorova. Pri tome su analizirane implikacije na mogunosti prikazivanja veza vorova plana metodom usmjerenog grafa, uz dodatak klasifikacije veza i njihovog meusobnog uvjetovanja. Temeljem navedene analize predlo~ene su smjernice daljnjih istra~ivanja u kojima bi trebalo koncipirati joa slo~enije entitete koji bi efikasnije mogli modelirati dinamiku izvoenja procesa. U izlo~enim razmatranjima pokazalo se da je koriatenjem "bottom up" pristupa mogue graditi model procesa konstruiranja tako da se slo~eniji entiteti grade koriatenjem osnovnih, ime je dokazana trea stavka postavljene hipoteze. Predlo~eni pristup realizira sa fleksibilnijim sustavom, u kojem su definirani entiteti stabilniji u odnosu na promjene okoline (domene) koju modeliraju, nego entiteti koji bi proizaali iz "top-down" pristupa. Sustav u kojem su klase "slabo" meusobno zavisne lakae je i programski odr~avati. Definicije i struktura plana konstruiranja i vora plana konstruiranja nastavak su i proairenja istra~ivanja u  REF _Ref409244619 \r \h [6] i  REF _Ref409269474 \r \h [7]. Razmatranja mogunosti modeliranja dinamike procesa izvoenja plana u okru~enju predlo~enog objektnog modela originalan su znanstveni doprinos ovog rada. Na osnovu mogunosti koje pru~a objektna tehnologija predlo~ena su rjeaenja koja mogu implementirati tzv. "dinami ko planiranje", odnosno mijenjanje i prilagoavanje plana u tijeku izvoenja, sukladno novonastalim, u planu nepredvienim situacijama. U ovoj fazi istra~ivanja predvieno je da takve promjene plana radi primarno konstruktor, meutim predlo~ena struktura i algoritam izvoenja plana omoguuju da se u plan ugrade i operacije i algoritmi kojima bi plan mogao mijenjati "sam sebe", odnosno elemente (atribute objekata i reference) svog zapisa u objektnoj bazi. Sazrijevanje UML-a rjeaava barem jedan od dosadaanjih problema primjene objektno orijentirane tehnologije - postojanje velikog skupa razli itih metodologija razvoja. UML objedinjava najbolje iz nekoliko vodeih metoda i donosi unifikaciju. Na taj na in mo~e postati podloga za komunikaciju i suradnju viae istra~iva kih timova koji mogu razvijati i razmjenjivati parcijalne modele koristei istu notaciju i metodologiju. U takvom pristupu mogao bi se pokrenuti razvoj usaglaaenog ra unalnog modela procesa konstruiranja. Proces razvoja mogao bi se odvijati kroz cikluse: prijedlozi, rasprava, poboljaanja i kretanje k standardizaciji. Sli an proces ve se du~e odvija u razvoju STEP standarda, ali koliko je autoru poznato, nema nastojanja da se u STEP uklju i model procesa konstruiranja. Pri eventualnom implementiranju ra unalnog modela procesa konstruiranja u konstrukcijski ured svakako bi trebalo razmotriti koliki je odnos ulo~enog rada pri formiranju i odr~avanju modela u odnosu na unapreenje procesa koje bi se moglo postii. Realno je pretpostaviti da e taj odnos znatno varirati ovisno o vrsti proizvoda koja se konstruira, i o slo~enosti i zna ajkama procesa konstruiranja u razli itim sustavima. Autor smatra da bi predlo~eni model bio efikasan za slo~ene varijantne konstrukcije gdje prevladava timski rad, tj. openito u situacijama gdje su naglaaeni problemi organizacije i kontrole izvoenja procesa konstruiranja. LITERATURA Pahl G., Beitz W., Engineering Design, The Design Council, London, 1988. Martyrer E., Der Ingenieur und das Konstruieren, Konstruktion, Vol. 12, pp. 1-4, 1960. Dixon J. R., Finger S., Uvodna rije  (editorial), Research in Engineering Design, Vol. 1 No. 1, 1989. Vajna S., Wegner B., Optimization of the Product Development Process with Evolution Algorithms and Simultaneous Enginerring, Proceedings of International Conference on Engineering Design ICED 97, Vol. 3, pp. 3/67-3/70, WDK, Heurista, 1997. Wallace D. R., Abrahamson S. M., Borland N. P., Design Process Elicitation Through the Evaluation of Integrated Model Structures, Proceedings of ASME Design Engineering Technical Conference, DETC 99, Las Vegas, 1999. Pavkovi N., Kreiranje baze scenarija ekspertnog CAD sustava, magistarski rad, Zagreb, FSB, 1996. Marjanovi D., Implementacija ekspertnih alata u proces konstruiranja, Disertacija, FSB Zagreb, 1995. Proceedings of the IFIP TC 5/WG 5.2 Workshop on Intelligent CAD, Boston, listopad 1987, Amsterdam, North-Holland, 1987. Proceedings of the IFIP TC 5/WG 5.2 Second Workshop on Intelligent CAD, Cambridge, rujan 1988, Amsterdam, North-Holland, 1990. Mortensen N. H., Design modelling in a Designer's Workbench, disertacija, Lyngby, Technical University of Denmark, 1999. Blankenburg D., Dhainaut M., Designer's Advanced IT Workbench, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1873-1876, WDK, 1999 Schlenoff C., Knutilla A., Ray S., An Approach to Analyzing Existing Process Representations, Internet stranica: http://www.mel.nist.gov/psl/pubs/spain/paper.htm, 1997. Andreasen M. M., Duffy A. H. B., Mortensen N. H., Relations in Machine Systems, Proceedings of WDK Workshop "Product Structuring", Delft University, 1995. Eder W. E., Design Modeling-A design Science Approach (and Why Does Industry Not Use It?), Journal of Engineering Design, Vol. 9, No. 4, pp. 354-371, 1998. Maffin D., Engineering Design Models: context, theory and practice, Journal of Engineering Design, Vol. 9, No. 4, pp. 315-327, 1998. Hubka V., Eder W. E., Design Science, London, Springer, 1996. Finger S., Dixon J.R., A Review of Research in Mechanical Engineering Design. Part I: Descriptive, Prescriptive and Computer-Based Models of Design Process, Research in Engineering Design, Vol1, No1, 1989, 51-67 Finger S., Dixon J.R., A Review of Research in Mechanical Engineering Design. Part II: Representations, Analysis, and Design for the Life Cycle, Research in Engineering Design, Vol1, No2, 1989, 121-137 Wallace K., Developing a Vision of Engineering Design in the Future, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1665-1670, WDK, 1999. Horvath I., Vergeest J. S. M., Engineering Design Research: Anno 2000, Proceedings of the 6th International Design Conference DESIGN 2000, pp. 23-29, Zagreb, FSB, WDK, 2000. VDI 2221: Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte, Berlin, Beuth Verlag, 1993. Hubka V., Theorie der Konstruktionsprozesse, Springer, 1976 Ullman D. G., The Mechanical Design Process, McGraw - Hill, 1992 Hollins B., Design processes to develop the product generation after the product generation after next, Proceedings of the 5th International Design Conference DESIGN '98, pp. 17-22, Zagreb, FSB, WDK, 1998. Akman V., ten Hagen P.J.W., Tomiyama T., A fundamental and theoretical framework for an intelligent CAD system, CAD, Vol. 22, No. 6, pp. 352-367., 1990. Chandrasekaran B., A Framework for Design Problem-Solving, Research in Engineering Design, Vol. 1, No. 2, pp. 75-86., 1989. Colton J. S., Dascanio J. L., An Integrated, Intelligent Design Environment, Engineering with Computers, Vol. 7, No. 3, pp. 11-22., 1991. Shaw N. K., Bloor M. S., de Pennington A., Product Data Models, Research in Engineering Design, Vol. 1, No. 1, pp. 43-50., 1989. McMahon A. C., Xianyi M., A Network Approach to Parametric Design Integration, Research in Engineering Design, Vol. 8, No. 1, pp. 14-32., 1996. Vajna S., Burchardt C., Dynamic Development Structures of Integrated Product Development, Journal of Engineering Design, Vol. 9, No. 1, pp. 3-16., 1998. Hbel C., Sutter B., Supporting Engineering Applications by New Data Base Processing Concepts - An Experience Report, Engineering with Computers, Vol. 8, No. 1, pp. 31-49., 1992. Meerkamm H., Engineering Workbench - ein Schlssel zur Lsung komplexer Konstruktionsprobleme, Proceedings of International Conference on Engineering Design ICED 95, pp. 1261-1268, WDK, Heurista, 1995. Gauseimer J., Frank T., Hahn A., Integrated product development: An Integral Approach to Computer Aided Development of Advanced Mechanical Engineering Products, Proceedings of International Conference on Engineering Design ICED 95, pp. 1276-1289, WDK, Heurista, 1995. Jensen T., An Empirical Study of Variant Design with a Designer's Workbench, Proceedings of International Conference on Engineering Design ICED 97, Vol. 3, pp. 3/277-282, WDK, Heurista, 1997. Bei Y., MacCallum K. J., A Virtual Configuration Workbench for Product Development, Proceedings of International Conference on Engineering Design ICED 97, Vol. 3, pp. 3/337-342, WDK, Heurista, 1997. Gero J. S., Proceedings of fifth international conference on artificial intelligence in design - AID'98, pp. ix-x, Kluwer Academic Publishers, 1998. Blount G. N., Clarke S., Artificial Intelligence and Design Automation Systems, Journal of engineering Design, Vol. 5, No. 4, pp. 299-314., 1994. Mostow J., Towards Automated Development of Speialized Algorithms for Design Synthesis: Knowledge Compilation as an Approach to Computer-Aided Design, Research in Engineering Design, Vol. 1, No. 3, pp. 167-186., 1990. Miller G. S., Colton J. S., The Complementary Roles of Expert Systems and Database Management Systems in a Design for Manufacture Environment, Engineering with Computers, Vol. 8, No. 3, pp. 139-149., 1992. Bardasz T., Zeid I., Applying analogical problem solving to mechanical Design, CAD, Vol. 23, No. 3, pp. 202-211., 1991. Cagan J., Grossman I. E., Hooker J., A Conceptual Framework for Combining Artificial Intelligence and Optimization in Engineering Design, Research in Engineering Design, Vol. 9, No. 1, pp. 20-34, 1997 Mann T., Expert systems for Design and Planning: Requirements and Expectations, Proceedings of International Conference on Engineering Design ICED 95, pp. 1565-1566, WDK, Heurista, 1995. Ullman D. G. , D Ambrosio B., A Proposed Taxonomy for Engineering Decision Support, International Conference on Engineering Design, ICED 95, WDK, Heurista, 1995 Forde B. W. R., Russell A. D., Stiemer S. F., Object-Oriented Knowledge Frameworks, Engineering with Computers, Vol. 5, No. 4, pp. 79-89., 1989. Smithers T., Towards a knowledge level theory of design process, Proceedings of fifth international conference on artificial intelligence in design - AID '98, pp. 3-21, Kluwer Academic Publishers, 1998. Banares-Alcantara R., Representing the engineering design process: two hypotheses, CAD, Vol. 23, No. 9, pp. 595-603., 1991. Hoeltzel D. A., Chieung W. H., Factors that Affect Planning in a Knowledge-Based System for Mechanical Engineering Design Optimization with Application to the Design of Mechanical Power Transmissions, Engineering with Computers, Vol. 5, No. 2, pp. 47-62., 1989. }avbi R., Duhovnik J., Design environment for the design of mechanical drive units, CAD, Vol. 27, No. 10, pp. 769-781., 1995. Blessing L.T.M., Ball N.R., Implementation and Initial Evaluation of a Process-Based Approach to Design, Proceedings of International Conference on Engineering Design ICED 97, pp. 2/271-2/276, WDK, Heurista, 1997. Ball N., Matthews P., Wallace K., Managing Conceptual Design Objects-an Alternative to Geometry, Proceedings of fifth international conference on artificial intelligence in design - AID '98, pp. 67-86, Kluwer Academic Publishers, 1988. Eppinger S. D., Nukala M. V., Whitney D. E., Generalised Models of Design Iteration Using Signal Flow Graphs, Research in Engineering Design, Vol. 9, No. 3, pp. 112-123., 1997. Schmidt L. C., Cagan J., GGREADA: A Graph Grammar-Based Machine Design Algorithm, Research in Engineering Design, Vol. 9, No. 3, pp. 195-213., 1997. Pollack M. E., The uses of plans, Artificial Intelligence, Vol. 57, No. 1, pp. 43-68., 1992. Ndumu D.T., Izzudin B.A., Lloy Smith D., Explaining Design Plans, Knowledge Based Systems, Vol. 9, No. 1, pp. 23-29., 1996. Werner H., Weber C., State of the Art in Computer Based Design Tools (CBDT), European PhD-Seminar Engineering Design Research 2000, Baden-Baden, 2000. Kosteli A, Znanost o konstruiranju, rukopis knjige, Zagreb, 1996. Kosteli A., CAD kao podsustav CIM, Predavanje HAZU, Zagreb, 1994. Lindemann U., A Model of Design Processes of Individual Designers, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 757-762, WDK, 1999 Giaopulis A., Modell fr effektive Konstruktionsprozesse, Aachen, Shaker, 1998. Hubka V., Eder W.E., Engineering Design - General Procedural Model of Engineering Design, Heurista, Zrich, 1992. Obermit E., Nauka o konstruiranju, metodi ko konstruiranje i konstruiranje pomou ra unala, SNL Liber, Zagreb, 1985. Koller R., Konstruktionsmethode fr den Maschine, Gerte, und Apparatebau, Springer, 1976. Rodenacker, W, Methodisches Konstruieren, Springer, 1979. Roth K., Konstruieren mit Konstruktionskatalogen, Springer, 1980. Eekels J., Roozenburg N.F.M, Product design: Fundamentals and Methods, Wiley, 1995. Hollins B., Pugh S., Successful Product Design, London, Butterworths, 1990. Cross N., Engineering Design Methods - Strategies for Pruduct Design, Chichester, Wiley, 1994. VDI Richtlinie 2222, Sheet 1, Konzipieren technischer Produkte, Dsseldorf, VDI Verlag, 1973. Yoshikawa H, General Design Theory as a Formal Theory of Design, in Intelligent CAD I ed. Yoshikawa, Gossard, Procc. of IFIP TC5/WG5.2, pp. 51-63, North Holland, Boston, 1987 Tomiyama T., Yoshikawa H., Extended General Design Theory, Design Theory for CAD, ed. Yoshikawa, Warman, Procc. Of IFIP TC5/WG5.2, Tokyo, North Holland, 1987 Tomiyama T., Kiriyama T., Takeda H., Xue D., Yoshikawa H., Metamodel: A Key to Intelligent CAD Systems, Research in Engineering Design, Vol. 1, No. 1, pp. 19-34, 1989 Veerkamp P., Akman V., Bernus P., ten Hagen P. J. W., IDDL: A Language for Intelligent Interactive Integrated CAD Systems, Intelligent CAD Systems II, pp. 59-74, Springer, 1989 Suh N. P, Principles of Design, UP, Oxford, 1990 Albano L. D., Suh N. P., Axiomatic design and concurrent engineering, CAD, Vol. 26, No. 7, pp. 499-504, 1994 Bercsey T., Vajna S., Ein autogenetischer Ansatz fr die Konstruktionstheorie als Beitrag zur Vollstndigen Beschreibung des konstruktionsprozesses, Teil 1 und 2, CAD-CAM Report, Vol. 14, No. 2, No. 3, 1994. Schregenberger J. W., Attribution of Models, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 1191-1194, WDK, 1999 Stachowiak H., Allgemeine Modeltheorie, Wien, Springer, 1973. Froese T., Models of Construction Process Information, Journal of Computing in Civil Engineering, ASCE, 1995 Froese T., Rankin J., Representation of Construction Methods in Total Project Systems, 5 th Congress On Computing On Civil Engineering, Boston, ASCE, 1988 Schenck D., Wilson P., Information Modeling the EXPRESS Way, New York, Oxford University Press, 1994 Morris K. C., Mitchell M., Dabrowski C., Fong E., Database Managemnet Systems in Engineering, National Institute of Technology, Gaithersburg, 1992 Smithers T., AI-based design versus geometry-based design or Why design cannot be supported by geometry alone, CAD, Vol. 21, No. 3, pp. 141-150, 1989 Drner D., Thought and Design - Research Strategies, Single-case Approach and Methods of Validation, Designers, the key to successful product development, Berlin, Springer, 1998. Blessing L.T.M., Chakrabarti A., Wallace K. M., An Overview of Descriptive Studies in Relation to a General Design Research Methodology, Designers, the key to successful product development, Berlin, Springer, 1998 Ehrlenspiel K.,Gnther J., How Do Designers from Practice Design?, Designers, the key to successful product development, Berlin, Springer, 1998 Von der Weth R., Having a Nose for Good Solutions - The Development of Individual Strategies for the Design Process, Designers, the key to successful product development, Berlin, Springer, 1998 Visser W., Designers' activities examined at three levels: organization, strategies and problem-solving processes, Knowledge Based Systems, Vol. 5, No. 1, pp. 92-104, 1992. Cohen P .R., Feigenbaum E. A., The Handbook of Artificial Intelligence, Vol. I,II,III, Addison-Wesley, 1986. Miller G. A., Galanter E., Pribram K.H., Plans and the structure of behavior, New York, Holt, 1960. Hayes-Roth, B. Human planning processes, Rep. No. R-2670-ONR, Rand Corp., Santa Monica, Calif., 1980 Banares-Alcantara R., Design Support Systems for Process Engineering: I. Requirements and Proposed Solutions for a Design Process Representation, University of Edinburgh, Department of Chemical Engineering, Technical Report 1994-07, 1994 Kreyszig E., Advanced Engineering Mathematics, New York, J. Wiley, 1993. Boj eti N., Korisni ko su elje sustava za konstruiranje mehani kih sklopova, magistarski rad, FSB Zagreb, 1996. Pavkovi N., `torga M., Marjanovi D., Generating Design Plans in Relational Database Environment - Problems and Improving Possibilities, Proceedings of the 5th International Design Conference DESIGN '98, pp. 93-98, Zagreb, FSB, WDK, 1998. Pavkovi N., Marjanovi D., Structuring a Designers Workbench with Object Oriented Design Plans, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1401-1406, WDK, 1999. Elins A., Principles of Object-Oriented Software Development, Reading, Addison -Wesley, 1995. Ege R. K., Object-Oriented Programming with C++, Academic Press, 1994. Alhir S. S., UML in a Nutshell, O'Reilly, Sebastopol, 1988. Jordan D., C++ Object Databases, Programming with ODMG Standard, Reading, Addison Wesley, 1998 Quatrani T., Visual Modeling with Rational Rose and UML, Reading, Addison Wesley, 1999. Booch G., Rumbaugh J., Jacobson I., Unified Modeling Language User Guide, Addison Wesley, 1999. ISO 10303 -11, Description methods: The EXPRESS language reference manual, Geneve, ISO, 1994. ISO 10303, Industrial automation systems and integration - Product data representation and exchange - Part 1: Overview and fundamental principles, Geneve, ISO, 1994. ISO 10303 - 41, Integrated generic resources: Fundamentals of product description and support, Geneve, ISO, 1994. ISO 10303 - 43, Integrated generic resources: Representation structures, Geneve, ISO, 1994. POET 5.0 Programmer's Guide, San Mateo, POET Software Corporation, 1997. Meyer B., Object-Oriented Software Construction Eckel B., C++ Inside & Out, Berkeley, Osborne McGraw-Hill, 1993. Duffy A. H. B., Andreasen M. M., O' Donell F. J., Design Co-ordination, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 113-118, WDK, 1999 Eppinger S. D., Whitney D. E., Smith R. P., Gebala D. A., A Model-Based Method for Organizing Tasks in Product Development, Research in Engineering Design, Vol. 6, No. 1, pp. 1-13, 1994. Steward D. V., The Design Structure System: A Method for Managing the Design of Complex Systems, IEEE Tansactions on Engineering Management, Vol. EM-28, No. 3, pp. 71-74, 1981. Steward D. V., Systems Analysis and Management, New York, Petrocelli Books, 1981. Eppinger S. D., Model-base Approaches to Managing Concurrent Engineering, Journal of Engineering Design, Vol. 2, No. 4, pp. 283-290, 1991. Rogers J. L., McCulley C. M., Bloebaum C. L., Integrating a Genetic Algotithm into a Knowledge-Based System for Ordering Complex Design Processes, NASA Technical Memorandum 110247, 1996. Rogers J. L., Reducing Design Cycle Time and Cost Through Process Resequencing, Proceedings of International Conference on Engineering Design ICED 97, WDK, Heurista, 1997. West M., Developing High Quality Data Models, Shell Int. Petroleum, Report IC 91-077 T4, The Hague, 1993 Howard H. C., Abdalla J. A., Phan D. H., A Primitive-Composite Approach for Structural Data Modelling, Journal of Computing in Civil Engineering, Vol. 6, No. 1, pp. 19-40, 1992 King G. W., Object-Oriented really is better than Structured, Internet stranica: www.cs.uwa.edu.au/Why OOP.htm, 1995. Clarkson P. J., Hamilton J. R., 'Signposting', A Parameter-driven Task-based Model of the Design Process, Research in Engineering Design, Vol. 12, No. 1, pp. 18-38, 2000. Watton J. D., Rinderle J. R., Improving Mechanical Design Decisions with Alternative Formulations of Constraints, Journal of Engineering Design, Vol. 2, No. 1, pp. 55-68, 1991. Nagy R. L., Ullman D. G., Dietterich T. G., A Data Representation for Collaborative Mechanical Design, Research in Engineering Design, Vol. 3, No. 4, pp. 233-242, 1992. Pavli D., Marjanovi D., `torga M., The Implementation of Web-Based Technologies in Engineering Data Management, Proceedings of the 6th International Design Conference DESIGN 2000, pp. 23-29, Zagreb, FSB, WDK, 2000. Marjanovi D., Boj eti N., Dekovi D., Pavkovi N., Pavli D., `torga M., }e~elj D., Design Department Data Flow Integration, Proceedings of 3rd International Workshop "Integrated Product Development", Magdeburg, rujan 2000, Otto-von-Guericke University Magdeburg. Gorti S. R., Gupta A., Kim G. J., Sriram R. D., Wong A., An object-oriented representation for product and design processes, CAD, Vol. 30, No. 7, pp. 489-501., 1988. Liang W.Y., O'Grady P., Design With Objects: an Approach to Object-Oriented Design, CAD, Vol. 30, No. 12, pp. 943-956, 1998 Werner H., Muth M., Weber C., Functional Modeling Using an Object-Oriented Design System, Proceedings of International Conference on Engineering Design ICED 97, Vol. 3, pp. 3/234-3/238, WDK, Heurista, 1997. Korpela T., The Role of Object-Oriented Analysis in Modelling of Technical Processes, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 853-856, WDK, 1999. Jovi M., Razvoj modela za opisivanje i sprezanje sklopova mehani kih konstrukcija, magistaski rad, FSB Zagreb, 1997. Varga M., Baze podataka, Zagreb, ZEUS, 1994. Blessing L., A Process-Based Approach to Computer Supported Engineering Design, Proceedings of International Conference on Engineering Design ICED 93, Vol. 3., pp. 1393-1400, WDK, Heurista, 1993. Ledet W. P., Himmelblau D. M., Decomposition Procedures for the Solving of Large Scale Systems, Advances in Chemical Engineering, Vol. 8, pp. 185-254, 1970 Gebala D. A., Eppinger S. D., Methods for Analyzing Design Procedures, ASME Conference on Design Theory and Methodology, pp. 227-233, Miami, 1991. Park H., Cutkosky M. R., Framework for Modeling Dependencies in Collaborative Engineering Processes, Research in Engineering Design, Vol. 11, No. 2, pp. 84-102, 1999. Smith R. P., Morrow J. A., Product development process modeling, Design Studies, Vol. 20, No. 3, pp. 237-261, 1999. Herold Z., Strukturiranje baze znanja u procesu konstruiranja, disertacija, Zagreb, FSB, 1997. Grabowski H., Lossack R.-S., Weis C., A Design Process Model based on Design Working Spaces, Proceedings of the IFIP TC5 WG5.2 International Conference on Knowledge Intensive CAD, Vol. 1, pp. 245-262, Helsinki, Chapman & Hall, 1995. Grabowski H., Lossack R.-S., Knowledge based design of complex products by the concept of design working spaces, Proceedings of the IFIP TC5 WG5.2 International Conference on Knowledge Intensive CAD, Vol. 2, pp. 79-98, Pittsburgh, Chapman & Hall, 1996. Sutton R. A., Planning by Incremental Dynamic Programming, Proceedings of Ninth Conference on Machine Learning, pp. 353-357, Morgan-Kaufmann, 1991. Abrahamson S., Wallace D., Senin N., Sferro P., Integrated Design in a Service Marketplace, MIT CADlab, 1999. Stanek J., Aufbau von Wissenbasen in Ingenieurdatenbanksystemen zur Integralen Produktentwicklung, International Conference on Engineering Design, ICED 95, WDK, Heurista, 1995 Pavkovi, N, Programi za prora un vratila i le~aja, te crtanje vratila - tehni ke upute za koriatenje, elaborat br. 3.020928, Kon ar - Srednji elektri ni strojevi, 1991. Pavkovi, N, Programi za prora un vratila i le~aja, te crtanje vratila - upute za odr~avanje programa, elaborat br. 3.020930, Kon ar - Srednji elektri ni strojevi, 1991. BIBLIOGRAFIJA Abeln O., Meerkamm H., Storath E., Weber U., The CAD Reference Model - On Its First Approach to Praxis, International Conference on Engineering Design, ICED 95, WDK, Heurista, 1995 Abramovici M., Gerhard D., Use of PDM in Improving Design Processes - State of the Art, Potentials and User Perspectives, Proceedings of International Conference on Engineering Design ICED 97, Vol. 3, pp. 3/317-3/322, WDK, Heurista, 1997. Al-Salka M. A., Cartmell M. P., Hardy S. J., A Framework for a Generalized Computer-based Support Environment for Conceptual Engineering Design, Journal of Engineering Design, Vol. 9, No. 1, pp. 57-88, 1998 Andreasen M. M., Design Methodology, Journal of Engineering Design, Vol. 2, No. 4, pp. 321-335, 1991 Andreasen M. M., Pulkkinen A., Modular Engineering at ICED '99, 17. WDK Workshop, Rigi, WDK, 2000. Andreasen M. M., Wognum N., Considerations on a design typology, Proceedings of the 3rd International Workshop "Integrated Product Development", IPD 2000, Magdeburg, Otto-von-Guericke Univeristy Magdeburg, 2000. Arbab F., Design Object Modeling, Proceedings of the IFIP TC 5/WG 5.2 Workshop on Intelligent CAD, Boston, listopad 1987, Amsterdam, North-Holland, 1987. Austin S., Baldwin A., Baizhan L., Waskett P., Analytical Design Planning Technique: a Model of the detailed building design process, Design Studies, Vol. 20, No. 3, pp. 279-296, 1999. Bashir H. A., Thomson V., Metrics for design projects: a review, Design Studies, Vol. 20, No. 3, pp. 263-277, 1999. Bashir H. A:, Thomson V., Estimating Design Complexity, Journal of Engineering Design, Vol. 10, No. 3, pp. 247-257, 1999. Bauert F., Ball N. R., The integrated design framework: blackboards as a communication medium between designers and software modules, Proceedings of International Conference on Engineering Design ICED 93, Vol. 3., pp. 1351-1357, WDK, Heurista, 1993. Beitz W., Feldhusen J., Management Systems and Program Concepts for an Integrated CAD Process, Research in Engineering Design, Vol. 3, No. 2, pp. 61-74, 1991. Beitz W., Helbig D., Entwicklung Produkt - und unternehmensorientierter Konstruktionsleitsysteme, International Conference on Engineering Design, ICED 95, WDK, Heurista, 1995 Birmingham R. W., Information as the Raw Material of Design: an Educational Perspective, Proceedings of International Conference on Engineering Design ICED 97, Vol. 3, pp. 3/439-3/444, WDK, 1999. Blum A. L., Furst M. L., Fast Planning Through Planning Graph Analysis, Artificial Intelligence, No. 90, pp. 281-300, 1997 Boj eti N., Jovi M., The model of user interface in design process, Proceedings of International Conference on Engineering Design ICED 95, pp. 1563-1564, WDK, Heurista, 1995. Boudouh T., Noyes D., Aldamondo M., Modeling Reactive Design Processes in Concurrent Engineering, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 333-336, WDK, 1999 Bruce M., Cooper R., Vazquez D., Effective design management for small businesses, Design Studies, Vol. 20, No. 3, pp. 297-315, 1999. Cannon D. M., Leifer L. J., The Place of Design Research in the World of Contemporary Philosophical Thought, and Vice-Versa: an Illustrative example, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1635-1640, WDK, 1999 Cao Q., Protzen J.P., Managing design information: Issue-Based Information Systems and Fuzzy Reasoning System, Design Studies, Vol. 20, No. 4, pp. 343-362, 1999. Chen K. Z., Identifying the Relationship among Design Methods: Key to Successful Applications and Developments of Design Methods, Journal of Engineering Design, Vol. 10, No. 2, pp. 125-141, 1999. Chen, P., The entity-relationship model: towards a unified view of data, ACM Trans. Database System, Vol. 1, No. 1, pp. 9-36, 1976. Christiaans H.H.C.M., van Andel J., Information Processing and Storage during the Design Process: The Use of a Flexible Information System, Designers, the key to successful product development, Berlin, Springer, 1998 Clarkson P. J., Hamilton J. R., "Signposting the Design Process", Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 107-112, WDK, 1999 Cronemyr P., Ronnback A., Eppinger S. D., Process Improvement Simulations Using the Work Transformation Model, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 349-352, WDK, 1999 Cross N., Natural intelligence in design, Design Studies, Vol. 20, No. 1, pp. 25-39, 1999. Date C. J., An Introduction to Database Systems, Raeding, Addison Wesley, 1991. Dekovi D., Boj eti N., Structure of Design Domain Knowledge Base, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1921-1924, WDK, 1999 Deng Y.-M., Britton G. A., Tor S. B., A Design Perspective of Mechanical Function and its Object-Oriented Represtentation Scheme, Engineering with Computers, Vol. 14, No. 4, pp. 309-320, 1998. Dixon L. A., Colton J. S., An Anchoring Adjustment Process Model for Redesign, Journal of Engineering Design, Vol. 9, No. 4, pp. 297-313, 1998. Domajnko T., Juri  M. B., Rozman I., Selecting correct object storage system, Proceedings of the 22nd International Convention MIPRO '99, Vol. 1, pp. 99-102, Zagreb, MIPRO, 1999 Dong Y., Goh A., An Intelligent Database for Engineering Applications, Artificial Intelligence in Engineering, Vol. 12, No. 1-2, pp. 1-14, 1997 Drabble B., EXCALIBUR: a program for planning and reasoning with processes, Artificial Intelligence, Vol. 62, No. 1, pp. 1-40, 1993 Drisis L., What Do Our Designers Really Want? A Survey, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 567-570, WDK, 1999 Duffy A. H. B., Legler S., Rationalising Past Designs for Reuse, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 377-380, WDK, 1999 Eastman C. M., Bond A. H., Chase S. C., A Formal Approach for Product Model Information, Research in Engineering Design, Vol. 2, No. 2, pp. 65-80, 1991. Eastman C. M., Fereshetian N., Information models for use in product design: a comparison, CAD, Vol. 26, No. 7, pp. 551-572, 1994. Eastman C., Parker D. S., Jeng T-S., Managing the Integrity of Design Data Generated by Multiple Applications: The Principle of Patching, Research in Engineering Design, Vol. 9, No. 2, pp. 125-145, 1997. Eastman, C. M., Bond, A. H., Chase, S. C., A data model for design databases, Artificial Intelligence in Design 91, pp. 339-366, Butterworth-Heineman Ltd, Oxford, 1991. Ehrlenspiel K., Practicians - How they are Designing? And Why?, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 721-726, WDK, 1999 Endebrock K., Welp E. G., Object-Oriented Product and Process Modeling for Transparent Cost Estimation, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 493-496, WDK, 1999 Eversheim W., Graessler R., Schulten I., Parallel Processes Managed by an Integrated CAD-CAPP System, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 381-384, WDK, 1999 Fertalj K., Kalpi D., An Object Based Software Development Technique, Proceedings of the 21st International Conference on Information Technology Interfaces, ITI '99, pp. 469-474, Zagreb, SRCE, University of Zagreb, 1999 Fowler J., STEP for Data Management, Exchange & Sharing, Twickenham, Technology Appraisals, 1995. Fricke G., Succesful Individual Approaches in Engineering Design, Research in Engineering Design, Vol. 8, No. 3, pp. 151-165, 1996 Fuh J. Y. H., Chang C-H., Melkanoff M. A., The development of an integrated and intelligent CAD/CAPP/CAFP environment using logic-based reasoning, CAD, Vol. 28, No. 3, pp.217-232, 1996. Fulcher A. J., Hills P., A Taxonomy of Design Research Topics by Multivariate Agglomerative Clustering, Journal of Engineering Design, Vol. 9, No. 4, pp. 342-353, 1998. Gabbert U., Wehner P., The Product Data Model as a Pool for CAD-FEA Data, Engineering with Computers, Vol. 14, No. 2, pp. 115-122, 1998 Gao Y., Zeid I., Bardasz T., DEPSY: A Design plan System Supporting Case-based Mechanical Design, International Conference on Engineering Design, ICED 95, WDK, Heurista, 1995. Gauseimer J., Lewandowski S., Kespohl H. D., Pusch R., Seifert L., Gateway Integration of Global Engineering Networking (GEN) and Product Data Management (PDM), Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 703-708, WDK, 1999 Gero J. S., Mc Neill T., An approach to the analysis of design protocols, Design Studies, Vol. 19, No. 1, pp. 21-61, 1998. Gershenson J. K., Stauffer L. A., A Taxonomy for Design Requirements form Corporate Customers, Research in Engineering Design, Vol. 11, No. 2, pp. 103-115, 1999. Giaopulis A., Schlter A., Ehrlenspiel K., Gnther J., Effizientes Konstruieren durch Generierendes und Korrigierendes Vorgehen, Proceedings of International Conference on Engineering Design ICED 95, pp. 477-483, WDK, Heurista, 1995. Girard P., Eynard B., Rimmer D., Hein L., Re-engineering of Design Processes in a Design Co-ordination Envirinment, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 337-340, WDK, 1999 Goker M. H., Retrieving Adaptable Solutions from a Design Repository, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1389-1394, WDK, 1999 Grabowski H., Rude S., Pocsai Zs., Ontology Technology the Key for Intelligent Migration and Retrieval of Information in Engineering Networks, Proceedings of International Conference on Engineering Design ICED 97, Vol. 2, pp. 2/231-2/236, WDK, Heurista, 1997. Halpin, T. A., Nijssen, G. M., Conceptual Schema and Relational Database Design, Prentice-Hall, USA, 1989. Hansen C. T., Identification of Design Work Patterns by Retrospective Analysis of Work Sheets, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 775-780, WDK, 1999 Hhn B.-R., Steingrver K., Dyla A., Computer Aided Product Development, Proceedings of the 5th International Design Conference DESIGN 2000, Zagreb, FSB, WDK, 2000. Huang G. Q., Mak K. L., Developing a Generic Design for X Shell, Journal of engineering Design, Vol. 8, No. 3, pp. 251-260, 1997 Hubka V., Eder W. E., Theoretical Approach in Design Methodology, Designers, the key to successful product development, Berlin, Springer, 1998 IDEF1X Manual, USAF Integrated Computer-Aided Manufacturing Program. D Appleton Company, USA, 1986. Jonas W., Design as problem-solving? Or: here is the solution-what was the problem?, Design Studies, Vol. 14, No. 2, pp. 157-170, 1993. Kalpi  B., Polajnar A., Model of the Holistic Information Integration of an Enterprise, Strojarstvo, Vol. 39, No. 6, pp. 275-280, 1997 Kimura F., Architecture of Intelligent CAD Systems, Proceedings of the IFIP TC 5/WG 5.2 Workshop on Intelligent CAD, Boston, listopad 1987, Amsterdam, North-Holland, 1987. Krishnamurthy M. V., Smith F. J., Integration of scientific data and formulae in an object-oriented knowledge-based system, Knowledge Based Systems, Vol. 7, No. 2, pp. 135-141, 1994 Langdon P., Chakrabarti A., Browsing a Large Solution Space in Breadth and Depth, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1865-1868, WDK, 1999 Lau H., The New Role of Intranet/Internet Technology for Manufacturing, Engineering with Computers, Vol. 14, No. 2, pp. 150-155, 1998 Lee H. H., Arora J. S., Object-Oriented Programming for Engineering Applications, Engineering with Computers, Vol. 7, No. 3, pp. 225-235, 1991 Lemay L., Perkins C. L., Teach Yourself JAVA in 21 days, Indianapolis, Sams.net Publishing, 1996. Liang J., Chang T. Y. P., Chan C. M., An Object-Oriented Database Management System for Computer-Aided Design of Tall Buildings, Engineering with Computers, Vol. 14, No. 4, pp. 275-286, 1998 Liddament T., The computationalist paradigm in design research, Design Studies, Vol. 20, No. 1, pp. 41-56, 1999. Lippold C., Welp E. G., Multi-Domain Configuration System for Analysis and Synthesis of Mechatronic Conceptual Designs, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 829-834, WDK, 1999 Lockledge J. C., Salustri F. A., Defining the Engine Design Process, Journal of Engineering Design, Vol. 10, No. 2, pp. 109-123, 1999. Maher M. L., Rutherford J. H., A Model for Synchronous Collaborative Design Using CAD and Database Management, Research in Engineering Design, Vol. 9, No. 2, pp. 85-98, 1997 Marjanovi D., Design Process Representation in the Developmnet of Design Support Environment, Proceedings of International Conference on Engineering Design ICED 97, Vol. 2, pp. 2/705-2/708, WDK, Heurista, 1997. Marjanovi D., Pavkovi N., The Structure of an ICAE System, Proceedings of International Conference on Engineering Design ICED 95, pp. 1363-1368, WDK, Heurista, 1995. Marples M.L., The Decisions of Engineering Design, IRE Transactions on Engineering Managment, EM, 8, 55-70, 1961 Martin J., Principles of Object-Oriented Analysis and Design, New Yersey, Prentice Hall, 1993 Martin J., Principles of Object-Oriented Analysis and Design, New jersey, Prentice-Hall, 1993. McCullough, Issues in Intelligent CAD, Proceedings of the IFIP TC 5/WG 5.2 Second Workshop on Intelligent CAD, Cambridge, rujan 1988, Amsterdam, North-Holland, 1990. McMahon C. A., Lowe A., Culley S. J., An Information-Connection Model for Design, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1651-1656, WDK, 1999. Meerkamm H., Information Management in the Design Process - Problems, Approaches and Solutions, Designers, the key to successful product development, Berlin, Springer, 1998. Mills J. J., A Taxonomy of the Product Realization Process Environment, Research in Engineering Design, Vol. 4, No. 4, pp. 203-213, 1993. Moore J., Stader J., Chung P., Jarvis P., Macintosh A., Ontologies to Support the Management of New Product Development in the Chemical Process Industries, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 159-164, WDK, 1999 Myopolous J., Cohen P., Borgida A., Sugar L., Semantic networks and the generation of context, IJCAI 4, 134-142, 1975. Object Management Group, Unified Modeling Language Specification, version 1.3, Framingham, OMG, 1999. Ohsuga S., A Consideration to Intelligent CAD Systems, Proceedings of the IFIP TC 5/WG 5.2 Workshop on Intelligent CAD, Boston, listopad 1987, Amsterdam, North-Holland, 1987. Onosato M., Yoshikawa H., A Framework on Formalization of Design Object for Intelligent CAD, Proceedings of the IFIP TC 5/WG 5.2 Workshop on Intelligent CAD, Boston, listopad 1987, Amsterdam, North-Holland, 1987. Oosterman B. J., Gaalman G. J. C., Kuijpers F. P. J., Finding Structures in Product Development, University of Groningen, Research Report 99A06, 1998. Pavkovi N., Defining and Generating Design Plans - an Approach to the First Phase in Exploitation of an ICAD System, Proceedings of International Conference on Engineering Design ICED 97, Vol. 2, pp. 2/297-2/300, WDK, Heurista, 1997. Peak R. S., Fulton R. E., Nishigaki I., Okamoto N., Integrating Engineering Design Analysis Using a Multi-representation Approach, Engineering with Computers, Vol. 14, No. 2, pp. 93-114, 1998 Peckham J., Maryanski F., Semantic Data Models, ACM Comput. Surv., Vol. 20, No. 3, pp. 153-189, 1988. Pejtersen A. M., Sonnenwald D. H., Buur J., Govindaraj T., Vicente K., The Design Explorer Project: Using a Cognitive Framework to Support Knowledge Exploration, Journal of engineering Design, Vol. 8, No. 3, pp. 289-301, 1997 Peters T. J., Demurijan S. A., McCartney R., Needham D. M., Object Modeling to Localize Knowledge for Feature Interrelationships, Proceedings of the IFIP TC5 WG5.2 International Conference on Knowledge Intensive CAD, Vol. 2, pp. 199-207, Pittsburgh, Chapman & Hall, 1996. POET Software Corporation, POET Internet homepage, A Comparison Between Relational and Object Oriented Databases for Object Oriented Application Development, www.poet.com., 1997. Randall R. L., Bristow D. J., Drake R., Front-End Process Definition for Projects Engaged in Significant Technology Transition, Internet stranica: http://source.asset.com/stars/loral/pubs/stc96/fep96/fep.htm, 1996 Reich Y., A Critical Review of General Design Theory, Research in Engineering Design, Vol.7, No. 1, pp. 1-18, 1995 Reinders, H, Design Information Deployment in Design Assistants, International Conference on Engineering Design, ICED 95, WDK, Heurista, 1995 Reymen I., Domain Independent Description of Design Situations, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 1215-1218, WDK, 1999 Rigopoulus D. R., Oppenheim I. J., Design Objects and their Representation: Buildings and Structures, Proceedings of the IFIP TC 5/WG 5.2 Second Workshop on Intelligent CAD, Cambridge, rujan 1988, Amsterdam, North-Holland, 1990. Rodgers P. A., Huxor A. P., Caldwell H. M., Design Support Using Distributed Web-Based AI Tools, Research in Engineering Design, Vol. 11, No. 1, pp. 31-44, 1999 Rodgers P. A., The role of artificial intelligence as 'text' within design, Design Studies, Vol. 19, No. 2, pp. 143-160, 1998. Roozenburg N. F. M., Eekels J., Product Design: Fundamentals and Methods, Chichester, Wiley, 1995. Roozenburg N.F.M., Dorst K., Describing Design as a Reflective Practice: Observations on Schn's Theory of Practice, Designers, the key to successful product development, Berlin, Springer, 1998 Rosen D. W., Peters T. J, The Role of Topology in Engineering Design Research, Research in Engineering Design, Vol. 8, No. 2, pp. 81-98, 1996 Rosenman M. A., Gero J. S., Modeling Multiple Views of Design Objects in a Collaborative CAD Environment, CAD, Vol. 28, No. 3, pp. 193-205, 1996. Rugelj J., Intelligent Agent for Construction and Maintenance of Knowledge Trees, Proceedings of the 22nd International Convention MIPRO '99, Vol. 1, pp. 156-158, Zagreb, MIPRO, 1999 Salustri F. A., Venter R. D., An Axiomatic Theory of Engineering Design Information, Engineering with Computers, Vol. 8, No. 4, pp.197-212, 1992 Salustri F. A., Venter R. D., Towards a new computational model for engineering software systems, Proceedings of International Conference on Engineering Design ICED 93, Vol. 3., pp. 1359-1368, WDK, Heurista, 1993. Savage J. C. D., Miles C., Moore C. J., Miles J. C., The interaction of time and cost constraints on the design process, Design Studies, Vol. 19, No. 2, pp. 217-233, 1998. Saynisch M., Advanced Product Configuration Change Management, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 317-320, WDK, 1999 Schon A., Meerkamm H., Components for a Mechatronic Design Workbench, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 817-822, WDK, 1999 Schregenberger J. W., The Further Development of Design Methodologies, Designers, the key to successful product development, Berlin, Springer, 1998 Schulz J., Keutgen I., Birkhofer H., User-Oriented Presentation of Available Categorised Knowledge Providing On-Demand a Flexible, Relevant Knowledge-base Access, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 171-176, WDK, 1999 Shahin T. M. M., Sivaloganathan S., Development of a Computer-Based Design Reuse System, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1383-1388, WDK, 1999 Shen W., Barthes J.-P., An object-oriented approach for engineering design product modeling, Proceedings of the IFIP TC5 WG5.2 International Conference on Knowledge Intensive CAD, Vol. 1, pp. 171-187, Helsinki, Chapman & Hall, 1995. Shin Y., Han S., Data Enhancement for Sharing of Ship Design Models, CAD, Vol. 30, No. 12, pp. 931-941, 1998 Smith R. P., Tjandra P., Experimental Observation of Iteration in Engineering Design, Research in Engineering Design, Vol. 10, No. 2, pp. 107-117, 1998 Suh N. P., A Theory of Complexity, Periodicity and the Design Axioms, Research in Engineering Design, Vol. 11, No. 2, pp. 116-131, 1999. Suh N. P., Axiomatic Design Theory for Systems, Research in Engineering Design, Vol. 10, No. 4, pp. 189-209, 1998. `torga M., Pavkovi N., Marjanovi D., Execution of Design Plans in Relational Database Environment, Proceedings of the 5th International Design Conference DESIGN '98, pp. 221-226, Zagreb, FSB, WDK, 1998. Takeda H., Tomiyama T., Yoshikawa H., Logical Formalization of Design Processes for Intelligent CAD Systems, Proceedings of the IFIP TC 5/WG 5.2 Second Workshop on Intelligent CAD, Cambridge, rujan 1988, Amsterdam, North-Holland, 1990. Taura T., Kubota A., A Study on Engineering History Base, Research in Engineering Design, Vol. 11, No. 1, pp. 45-54, 1999 Troussier N., Pourroy F., Tollenaere M., Trebucq B., A Model to Reperesnt Mechanical Calculation Process in an Integrated Design Context, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 1235-1238, WDK, 1999 Tsichritizis, D., Hierarchical database managament, ACM Computer Surveys, Vol. 8, No. 1, pp. 105-124, 1976. Ullman D. G., A Taxonomy for Mechanical Design, Research in Engineering Design, Vol. 3, No. 3, pp. 179-189., 1992. Ullman D. G., D'Ambrosio B., A Proposed Taxonomy for Engineering Decision Support, Proceedings of International Conference on Engineering Design ICED 95, pp. 611-616, WDK, Heurista, 1995. Upton N., Blessing L., Methods for Evaluating Engineering Information Technology, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 253-256, WDK, 1999 Vajna S., An Introduction to Virtual Product Development, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 257-260, WDK, 1999 Vajna S., Burchardt C., Richter A., Organizing Integrated Product Development With Network Structures, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 393-396, WDK, 1999 Vajna S., Schabacker M., Evaluating Benefits of Investments into Engineering Processes, Procedures, Methods and Tools, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 249-252, WDK, 1999 Vajna S., Schabacker M., Schmidt R., Freisleben D., Methodical and Systematical Parametrisation in Product Modeling, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 531-534, WDK, 1999 Van Handenhoven E., Trassaert P., Design Knowledge and Design Skills, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 153-158, WDK, 1999 Varga M., Conversion of Relational into Multidimensional Database Schema, Proceedings of the 21st International Conference on Information Technology Interfaces, ITI '99, pp. 331-338, Zagreb, SRCE, University of Zagreb, 1999 Waldron M. B., Modeling of the Design Process, Proceedings of the IFIP TC 5/WG 5.2 Workshop on Intelligent CAD, Boston, listopad 1987, Amsterdam, North-Holland, 1987. Wartzack S., Meerkamm H., Shortening the Process Chain by Early Consideration of the Interaction Between Product and Process, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp.1007-1010, WDK, 1999 Welp E. G., Braun P., Integration Processors as Intelligent System Coupling in Process of Engineering, Proceedings of International Conference on Engineering Design ICED 97, Vol. 3, pp. 3/329-3/336, WDK, 1997. Welp E. G., Braun P., Knowledge Processing as a Solution and Decision-Making Aid in Early Phases of Embodiment Design, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 3, pp. 1965-1968, WDK, 1999 Werner H., Ahmed S., Design Capturing with a Model System Using Event Triggered Procedures, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 1011-1014, WDK, 1999 Wood W. H., A Methodology for Transforming Information into Design Knowledge, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 1, pp. 131-136, WDK, 1999 Woyak S. A., Myklebust A., Functionality and Data Integration of Software Modlules Through Dynamic Integration, Journal of Engineering Design, Vol. 9, No. 2, pp. 137-158, 1988. Yabuki N., Law K. H., An Object-Logic Model for the Representation and Processing of Design Standards, Engineering with Computers, Vol. 9, No. 3, pp. 133-159, 1993 Yan X. T., MacCallum K., An Integrated Novel Approach to Enhancing Interdisciplinary Product Design, Proceedings of International Conference on Engineering Design ICED 97, Vol. 1, pp. 1/266-1/270, WDK, 1999. Yassine A. A., Falkenburg D. R., A Framework for Design Process Specifications Management, Journal of Engineering Design, Vol. 10, No. 3, pp. 223-234, 1999. Yazdani B., Holmes C., Four Models of Design Definition: Sequential, Design Centered, Concurrent and Dynamic, Journal of Engineering Design, Vol. 10, No. 1, pp. 25-37, 1999. Zeid I., Bardasz T., Bhaskara S., Gao Y., Design plan systems for cas-based mechanical design: a survey and open issues, Proceedings of International Conference on Engineering Design ICED 93, Vol. 3., pp. 1369-1376, WDK, Heurista, 1993. Zeng Y., Gu P., A Set-Theoretic Model of Design Process, Proceedings of the 12th International Conference on Engineering Design ICED 99, Vol. 2, pp. 1179-1182, WDK, 1999 }avbi R., Razvoj izdelka s povezavo funkcije in delovnih principov, disertacija, Fakultet za strojniatvo, Ljubljana, 1998 DODATAK1: RJE NIK POJMOVA Entitet "parametar konstrukcije", preslikan na objekt u modelu procesa konstruiranja enkapsulira: zapis vrijednosti podatka o proizvodu, status vrijednosti (koji se mijenja u izvoenju procesa konstruiranja), reference na dodatne opise - znanja o procesu konstruiranja i proizvodu, zapise "namjera" konstruktora - prijedloge, argumente i pretpostavke. Baza parametara modelira logi ku organizaciju skupa parametara konstrukcije modeliranih kao objekata, uz kontrolu jedinstvenosti naziva parametra i pristupa atributima parametra, te sadr~i i operacije pretra~ivanja i pregledavanja. Entitet "prikaz proizvoda" modelira odreenu vrstu zapisa informacija o proizvodu. Modelira postojanje, odnosno enkapsulira sve pojmove i dogaaje iz "~ivotnog ciklusa" odreenog nosioca zapisa informacija o proizvodu. Objekt "prikaz proizvoda" sadr~i operacije su elja za transfer i generiranje podataka iz skupa informacija koji modelira. Entitet "akcija" modelira pozive operacija objekata modela procesa konstruiranja. Akcije se kreiraju i planiraju prije izvoenja procesa, a realiziraju se u tijeku izvoenja procesa konstruiranja. Entitet "su elje programskog alata" enkapsulira skup operacija za transfer podataka izmeu objekata modela procesa konstruiranja i programskih alata koji nisu dio objektnog modela procesa konstruiranja. Entitet "zadatak" modelira informacijske tokove i organizacijske aspekte realnog konstruktorskog zadatka u okru~enju timskog rada. Entitet "konstruktor" enkapsulira informacije i operacije vezane uz osobe iz konstrukcijskog tima, organizaciju i podjelu rada i odgovornosti, te hijerarhiju kontrole pristupa dokumentima koji su proizvod procesa konstruiranja. Skup instanci "konstruktora" modelira dogaaje i pojmove vezane za osobe i njihove interakcije kao "izvoa e" procesa konstruiranja. Plan konstruiranja u predlo~enom modelu procesa konstruiranja definira se kao model dekompozicije i tijeka izvoenja procesa konstruiranja u kojem se organiziraju i predviaju tokovi informacija i redoslijed izvraavanja akcija, te postavljaju kontrolni uvjeti. U predlo~enom modelu, etapa ( vor plana) procesa konstruiranja definira se kao kombinacija nepraznog skupa akcija (naredbi) Aj koje transformiraju objekt O, koji se nalazi u stanju SOi , u slijedee (novo stanje) SOi+1 : E ={ An : Sj ( Aj ( SOi ) = SOi+1 } Definicija se mo~e proairiti i na skup objekata, odnosno skup akcija transformira stanje svakog od objekata u slijedee novo stanje. Pri tome akcije mogu i generirati nove objekte i nakon toga im mijenjati stanje. }IVOTOPIS Neven Pavkovi roen je 05. 07. 1962. u Zagrebu gdje je zavraio osnovnu i srednju akolu (Matemati ko-informati ki obrazovni centar). Fakultet strojarstva i brodogradnje upisao je 1981. godine. Diplomirao je 1987. godine, na usmjerenju  Strojarske konstrukcije . Za uspjeh u studiju nagraen je Medaljom FSB-a. Od rujna 1987. do sije nja 1988. radio je u poduzeu "Kon ar - Transformatori" kao konstruktor u odjelu za konstrukciju alata i naprava. Od sije nja 1988. do o~ujka 1991. bio je zaposlen u poduzeu "Kon ar - Srednji elektri ni strojevi", u odjelu za razvoj konstrukcije. Radio je na poslovima razvoja programske podrake, primjene ra unala u odjelu konstrukcije i prora una vrstoe dijelova elektromotora. U tom razdoblju objavio je dva stru na elaborata. 01. 03. 1991. zasnovao je radni odnos na FSB-u, kao asistent za znanstvenu disciplinu "Elementi strojeva i konstruiranje", znanstveno podru je strojarstvo, u Zavodu za mehani ke konstrukcije, Katedra za elemente strojeva i konstruiranje. Kao asistent dr~ao je nastavu iz predmeta "Primjena elektroni kih ra unala", "Uvod u ra unala", "Informatika", "Konstruiranje pomou ra unala", "Primjena ra unala" i "Metodi ko konstruiranje". Magistarski rad pod naslovom "Kreiranje baze scenarija ekspertnog CAD sustava" obranio je 17. 10. 1996. Osim u nastavi, aktivno je sudjelovao i u organizaciji meunarodnih znanstvenih skupova DESIGN '98 i DESIGN 2000 odr~anih u svibnju 1998. i svibnju 2000. u Dubrovniku. Govori i piae engleski, a slu~i se i njema kim jezikom. Kao koautor objavio je jedan znanstveni rad u asopisu, a kao autor ili koautor 20 znanstvenih radova u zbornicima, od toga 8 na meunarodnim znanstvenim skupovima odr~anim u inozemstvu. BIOGRAPHY Neven Pavkovi was born on July 5th 1962 in Zagreb, where he completed his primary and secondary education (mathematics highschool). In 1987 he graduated in mechanical design from the Faculty of Mechanical Engineering and Naval Architecture of the University of Zagreb. For the excellent success in study, he was awarded the Faculty Medal. From September 1987 until January 1988 he worked in the "Kon ar - Transformers" factory, as a designer in tools design department. From January 1988 until March 1991 he was employed in the "Kon ar - Medium Size Electrical Machines" factory, as a research engineer in the design department. His line of work was the development of computer based design support tools and the mechanical stress calculations of electromotor parts. In that period he published two project report studies. Since March 1st 1991 he has been an assistant at the Design Department of the Faculty of Mechanical Engineering and Naval Architecture of Zagreb University. In 1996 Neven Pavkovi acquired the M. Sc. degree at the Faculty of Mechanical Engineering and Naval Architecture of Zagreb University with the thesis "Creating Database of Scenarios for Expert CAD System". He has a good command of English and can read German fairly well. Besides teaching activities, he took part in the organisation of the international design conferences DESIGN '98 and DESIGN 2000, held in Dubrovnik. As a co-author he has published one paper in a scientific journal. As a first author or a co-author he has published 20 scientific papers in conference proceedings, 8 of which were international conferences being held abroad.  Ovdje, i dalje u radu se rije  "apstrahirati" upotrebljava u zna enju izlu ivanja, idealizacije, a ne u zna enju isklju ivanja, tj. "ne uzimanja u obzir"  Suh navodi  implementacija , naime projektiranjem (ili konceptualizacijom) je konstrukcija odreena, treba je realizirati razradom i izradbom.  ovdje se  konstrukcija odnosi na konstrukcijsko rjeaenje, koncepciju, logi ki model, a ne na fizi ku izvedbu. Ova primjedba vrijedi svuda u ovom poglavlju, osim gdje to nije izri ito navedeno.  Dovoljno je npr. usporediti polaziata, namjenu i obrazlo~enje razloga razvoja teorija u radovima Kesselringa (koji je na neki na in duhovni otac srednje-europske akole) i Suha, ili Suha i Yoshikawe.  PAGE VIII  REF _Ref409265815 \h  \* MERGEFORMAT Uvod  PAGE 136  REF _Ref409265961 \h  \* MERGEFORMAT Pregled stanja i smjerova istra~ivanja  REF _Ref409269971 \h  \* MERGEFORMAT Analiza procesa konstruiranja  REF _Ref409270235 \h  \* MERGEFORMAT Pristupi i polaziata modeliranja procesa konstruiranja  REF _Ref409270337 \h  \* MERGEFORMAT Objektno orijentirani pristup modeliranju i programiranju  REF _Ref409687133 \h  \* MERGEFORMAT Koncipiranje objektno orijentiranog modela procesa konstruiranja  REF _Ref409687239 \* MERGEFORMAT Prijedlog entiteta objektnog modela procesa konstruiranja  REF _Ref409192688 \* MERGEFORMAT Realizacija predlo~enog objektnog modela  REF _Ref409875234 \h  \* MERGEFORMAT Zaklju ak Literatura Bibliografija Rje nik pojmova  EMBED Excel.Sheet.8  t,<Zv *jF x8:JLZ\&(\ƿjwUmHjUmHj}UmHjUmH jUmHmH jUmH OJQJmH6mH 5CJmH 5CJmHCJmH@(CJOJQJmH@CJ OJQJmHmHCJmH4,tvxz|~,.02468:<@&$$@&,tvxz|~,.02468:<  (jlnp\X  ¿泰9  (jlnp\   c  @& $@&X  4 V " d         " $ & d$   4 V " d         " $ & ( * , . 0 2 4 6 8 : < > @ B D F <xz| fv2lx Zj p6 P!!F""y Q& ( * , . 0 2 4 6 8 : < > @ B D F <xz|@&d fv2lx Zj p "  "  "  $ U"\^`bd68lnprt(*,.0*,`bdhj68lnptv pjUmHj_UmHjUmHjeUmHjUmHjkUmHjUmHjqUmHmH jUmHjUmH=prNPRVX(*^`bfh xz.0dfhln*,.24jA UmHj UmHjG UmHjUmHjMUmHjUmHjSUmHjUmHjYUmHmH jUmH=p6 P!!F"""1#l#$4%%0&l&&'@'''0(l((<)))J* "  "  " ^ ` !!D!F!H!L!N!!!!!!!!%"&"@"A"B"D"E"c"d"~""""""""""""##+#,#-#/#0#K#L#f#g#h#j#k#`$b$$$jUmHj)UmHj UmHj/ UmHj UmHj5 UmHj UmHj; UmHj UmHmH jUmH=""1#l#r#$4%%0&l&&'@'''0(l((<)))J***,+c++,---N..|/B011h23~3345677"88:9::V;;p<<b==.>> ??@NAABZCC'?'''''''''''jUmHjUmHjUmHjUmHjUmHjUmHjUmHj#UmHmH jUmH>'''''((*(+(,(.(/(K(L(f(g(h(j(k(((((((())6)7)8):);))))))))))))))))***D*E*F*H*I*********jUmHjvUmHjUmHj|UmHjUmHjUmHjUmHjUmHmH jUmHj UmH=J***,+c++,---N..|/B011h23~3345677"88:9 "  "  " ******* + +&+'+(+*+++B+C+]+^+_+a+b++++++++j,l,,,,,,,,,,---H-J-~------------ ..B.D.F.J.jXUmHjUmHj^UmHjUmHjdUmHjUmHjjUmHjUmHjpUmHmH jUmH=J.L........:/0@00000011h1j111111&2(2\2^2`2d2f222 33333<3>3r3t3v3z3|33333jUmHj@UmHjUmHjFUmHjUmHjLUmHjUmHjRUmHjUmHmH jUmH=33334444444F5H5|5~555555666 6 66666677B7D7x7z7|777778888 8j8l88888888,9.9096989999j#UmHj(#UmHj"UmHj."UmHj!UmHj4!UmHj UmHj: UmHmH jUmH>999:::::::::;;H;J;L;R;T;;;;;;;;,<.<b<d<f<l<n<<<<<<<<= =T=V=X=^=`========== >">$>*>,>l>j (UmHj'UmHj'UmHj&UmHj&UmHj%UmHj%UmHj$UmHmH jUmHj"$UmH=:9::V;;p<<b==.>> ??@NAABZCCn>>>>>>>>????????????\@^@@@@@@ A A@ABADAJALAAAAAAAANBPBBBBBBCCLCNCPCVCXCCCCCCCjo,UmHj+UmHju+UmHj*UmHj{*UmHj)UmHj)UmHj)UmHj(UmHmH jUmH=CCCC.D0D2D8D:DD@DDDDDDEEEEEEEEEtFvFFFFFFbGdGGGGGGHH:HHBHDHHHIII I I^I`IIIIIj/UmHj]/UmHj.UmHjc.UmHj-UmHji-UmHB*OJQJmH OJQJmHmH jUmHj,UmHmH jUmH;DDDEFGFHII@JJK-LpLL6MNXOPP.QQBRRSSTT$ ; " $ " @&IIIJ4J6J8JJJJJJJJJ\K^KKKKKK L L'L(L)L+L,LOLPLjLkLlLnLoLLLLLLLLMM0M1M2M4M5MjNlNNNNNNOOLONOj?4UmHj3UmHjE3UmHj2UmHjK2UmHj1UmHjQ1UmHj0UmHjW0UmHmH jUmH=L6M>MNXOPP.QQBRRSSTTUPVVWWWXrYZZ[ \d\\]J]]]^_4``a~bbhcdldd+e3ef4gghiij@kkkkllmRnnoop\q&rrsttttttttttttv{ 2$UNOPOTOVOOOPPP P PPPPPPPPQQQQQQQ!R"RR@RARRRRRRRRRR S S SSSjSkSSSSSSSSSSSSTTTTj'8UmHj7UmHj-7UmHj6UmHj36UmHj5UmHj95UmHj4UmHmH jUmH>TTTTTpUrUUUUUU/V0VJVKVLVNVOVVVVVVVVVVWWWWWfWgWWWWWWWWWWWWWbXdXXXXXX0Y2YfYhYjYnYpYYj<UmHj<UmHj;UmHj;UmHj:UmHj:UmHj9UmHj!9UmHmH jUmHj8UmH=TUPVVWWWXrYZZ[ \d\\]J]]^_4``a~bbhcdld$ " $  " $ " YYYYYZZZZZZZZZ>[@[t[v[x[|[~[[[\\\ \ \C\D\^\_\`\b\c\\\\\\\\\\]]]]]u]v]]]]]]^^^^^^j@UmHjt@UmHj?UmHjz?UmHj>UmHj>UmHj>UmHj=UmHj =UmHmH jUmH=^^J_L________&`(`*`0`2````````aaaaaaa:bj@jtjvjxj~jjjj2kj>IUmHjHUmHjDHUmHjGUmHjJGUmHjFUmHjPFUmHjEUmHmH jUmH>ldd+ef4gghiij@kkkkllmRnnop\q&rrsttt@&$ " 2k4k6kkkkkkkkkkkll8l:llllllllmmmmmmm1n2nLnMnNnPnQnnnnnnnnnnnoooovpxppppppqqj&MUmHjLUmHj,LUmHjKUmHj2KUmHjJUmHmH jUmHj8JUmHmH jUmHjIUmH=qNqPqRqXqZqqqrrr"r$rrrrrrrrssssssshtjttttttttDdDtvJVLN>@rOJQJ CJOJQJ5CJOJQJ5 OJQJmHCJOJQJmH5CJOJQJmHmH jUmHjOUmHjOUmHjNUmHj NUmH jUmHjMUmHmH3ttttttttttv{ 2p֓BDhjBDtv$@&@&dxdx@&2p֓BDhjBDtvaIJVNPr> ~ 2p8V4J# #  #S # L   !   !   !   ! ; L  L  /aIJVNPr> ~ 2p!x<@&@&rtv|~ثګ &(Z\^df,.`bdjlnp "2J B*mHB*mH6mHjSUmHjRUmHB*mHjRUmHjQUmHjQUmHjPUmHmH jUmHjPUmH>p8V4Jjlln   PZn & FZ & FZex#$ & Fh#$ & Fex<!jlln   PZn$&)*<++f,-h-- ...234z5&6,7:;=b>??zD{tmk" !   !  !  L   !  !  !  !   !   !   !   !  L  L   Z   Z   Z  Z # #  *P*       !!!!"""" "$"&"X"Z"\"b"d"2#####$$$$$$J$L$l$n$v$x$H&J&(((((((jmVUmHB*mHjUUmHjsUUmHjTB*UmHjyTB*UmHjB*UmHjSUmHjSUmH jUmHB*mHmH=n$&)*<++f,-h-- ...234z5&6,7:;=b>??"(<P@!x(44>>N>P>R>Z>\>b>d>????"?$?N?P?R?T?zDD.O0ObOdOOOOOOOOOOOOO[[[[[[[\\,\-\.\2\3\5\6\O\P\Q\U\V\J^L^~^jZUmHjZUmHjYUmHjYUmHjXUmHmH jgWUmHjVUmH jUmHj0J&UmHmH??zD|DDFPHH:ItIJK0MnNOQ:TT XZ0`zbJcxdeeLg$ qx<!!xxzD|DDFPHH:ItIJK0MnNOQ:TT XZ\]`0`zbJcxdeeLg"hhhhij@lbmm nZn{voh  X    X   X                  L  !   !   !   !  !  !  !  L   L &~^^^^^^^^^^^^^^_ _"_*_,_J`L`~`````kkkkkkkkk,l.l0l8l:lLlNllllllpp"q$q&q(q8q:qdqfqhqjqqq*rmH jm^UmHj]UmHjs]UmHj\UmHjy\UmHj[UmHj[UmHmH jUmHj[UmH=Lg"hhhhij@lbmm nZnn"oo~pp*q,q:r@tjtruvv ! & F8-"@& & FXx? $ qZnn"oo~pp*q,q:r@tjtruvv`xVy~zJ{{||}>~~Z jL0ؘb Ľ嶯~urkd] #   #   #  L   !   !  !  !  !  !  !   !   !   !   !   !   !   !  ! -"  X    X    X  #*r,r.r6r8rrstssssss@tjtvvJ{{ 02RT\^bdŒČTV  "TVX`b (jbUmHjpbUmHjaUmHjvaUmHj`UmHj|`UmH OJQJmHj_UmHmH jUmHj_UmH>v`xVy~zJ{{||}>~~Z jL0ؘb z|p# & F # & F x ! & F- ! & F8z|p~R8^LJLh(`v#^v<>|R |              M  L @L   L " 0   0   0   0   !  !   L  #  0p~R8^LJLh(`v x h h h h & F0 h!x(*468@B$&XZ\df&'@ABFG LNjRgUmHjfUmHjXfUmHjeUmHj^eUmHjdUmHjddUmHjcUmHjjcUmHmH jUmH=NPXZ:<nprz|LNPRT\^xzBDvx.0PRZ\02RT\^j:kUmHjjUmHj@jUmHjiUmHjFiUmHjhUmHjLhUmHjgUmHmH jUmHAFHJRT$&@Btvx>?XYZ^_ab{|}@BtvxjoUmHj"oUmHjnUmHj(nUmHjmUmHj.mUmHjlUmHj4lUmH jUmHjkUmHmH==>WXY]^:<nprz|VXZ\jl24fhjrt<|       xz02:jtUmHjsUmHjsUmHjrUmHj rUmHmH jqUmHjpUmHjpUmHmH jUmHA^v<>|R ||V P   T  ! & F8x & F h" $ h||V P   T  * t   \4L`!"J#L#''4((ž{skf_\" #  # #  #  #  #  # L   !  ! !  !   !   !   !   !   !   !                      #T  * t   \4L`!"J# #$ & F 77 # & Fn # & F7 # & F7x<<x ! & F8:<FHz|`#b######&&B&D&F&N&P&''0(1(2(3(:(;(P(Q(R(S(w(x(((((($/&/X/Z/\/d/f////////Z3\333jTxUmHjwUmHjZwUmHjvUmHmH juUmHjxuUmHjtUmHj~tUmH 56mHmH jUmH>J#L#''4((++/1262r222"3N3>44 5566;;l<!x! & Fd!x"@&$()++/1262r222"3N3>44 5566;;l<\==n?N@jG*MPTfZacDdfghƿ~{tjc\ !i   i  qi   !i !  #!=  ""RS L  !   !   !d   !d   !d   !d   !d  !d  !  $3333v;x;;;;;;;;;d<f<h<j<x<z<<<<<==L=N=P=X=Z=&M(MnmpmmmmmmmNpXp (*Гғ8:@BFj'|UmHj{UmHj-{UmH6mHjzUmHB*mHj3zUmHmH jNyUmHjxUmHmH jUmHBl<\==n?N@jG*MPTfZacDdfgh(ibmnuLxz~x! & Fi & Fi ! & Fiexx ! & F8 ! & F8xx"@&h(ibmnuLxz~ބ(Lh*ԍd>d@f 2  .Jž{qhebL  #  &#  %#m  $"L  L   !   !   !   !   !  L  L  &~ބ(Lh*ԍd>@f 2 #$ & F "@&$<!!xxFHz|  #$459:<=VWghlmop͚ΚҚӚ՚֚ "#3489jUmHjUmHjUmHj~UmHj~UmHj}UmHj!}UmHj|UmHmH jUmHA(*JLTV DFHJ*,LNVX fh^`j_UmHjUmHjeUmHjUmHjkUmHjUmHmH j UmH>*mH jUmHjUmHmH@  .J0p0FHtN"@&$$0p0FHtN'F0<xиypmL   !  # !  " !  ! !  !  * !  ) !  ( !  'L  {|"L   L uL   L *fhHJ fhlnpr  >@BJL&(Z\^fh$%>?@DEj)UmHjUmHj/UmHjUmH jІUmHjSUmHmH jYUmHj܄UmHmH jUmHB#$%&-.CDERTRTHJ|~ jUmHjUmHjUmHjUmHjUmHjUmHmH j#UmHjUmHmH jUmHA'0<x8:P & FA!x ! & F"@&$  23LMNRSz{|}(*8:dfjl<>prt|~mnjUmHjUmHjUmHCJmHjUmH j2UmH5mHjUmHmH jUmHmH jUmHB8:P  z  T9&(,#K"  8!t!!2""#$%6(,),../(000,12p44¼ݍ L " A  : A  9 A  8 A  7 A  6 A  5 A  4 A  3 A  2 A  1L  " A  0 A  / A  . A  - A  +3  z  T&(,#K"  8!t!!2"xx"@&$x & FA""..//,/./2/4//////////00&1(14455555555$6&6(6*6L6N6 7777`7b7j7n77788 8 8Z8^88888Ĺj0p4 EHUmHj0p4 CJUVmHH*mHj0p4 EHUmHj0p4 CJUVmH6mH5mHjUmHmH jUmHj0J&UmHmH jUmH>2""#$%6(,),../(000,12p445<6r77888 n n"@&" & FAx45<6r7788899d;;=?F@*AA\BCCDEPFFFHGGHHIJXMDPPQRXSŽ}wurh^!  %!:  $ A  HA  GA  F=A  EhA  DA  CA  BYA  AA  @&A  ?A  >A  =A  <A  ;.L  :$88899.929p9r99999VBXBDPPDQFQxQzQ|QQQQQQQQQQRUTUUUUUU.Y0YbYdYfYnYpYYYZZZZZrZtZZZZj#UmHjUmHj)UmHjUmHj/UmHjUmH 56mHj0J&UmH6mHH*mH jUmHj|EHUmHjic8 CJUVmHmH8899d;;=?F@*AA\BCCDEPFFFHGGHHIJXMDP & FA & FA n DPPQRXSzTVVPX*\4^bcZfhFllnoqFtu,vvxz{}!!xxx@&XSzTVVPX*\4^bcZfhFllnoqFtu,vvxz{}},ƀ"֌üxqjc\U p   p   !  2 !  1 !  0 p L   !  / !  . !  - !  , !  + !  * !  ) !  (![  ' L  L L  !v  &!ZZZZZ"[>[n[[[[[[[$\B^D^v^x^z^^^^^^^^^^_______ffhffffffjjkk k(k*knn oooooo pqVrFttvwx yz{BD5mHj!UmHj UmHj UmHjUmHjUmHjUmH6mH jUmHmHF}},ƀ"֌ڒjRzjP!<!xxx & Fp!   & FpexDvx́΁   >@BJLPRʉ̉Ή։؉܉މĊƊHJjltv8:Zjv%UmHj$UmHj|$UmHj#UmHj#UmHj#UmHj"UmHj "UmH jUmHj!UmHmH=֌ڒjRzjP.J|v0p>*6nl&"frjBP^:<~" #  K #  J #  IL  L  L   !  6 !  5 !  4 !  3 L 1Z\dfjRėƗ$&̚Κ"$,.(*JLTVBDvx@Btvxrt   j(UmHjd(UmHj'UmHjj'UmHj&UmH5mHjp&UmHj%UmH6mHmH jUmHC.J|v0p>*6nl&"frj"@& x Sf" # & F Sxjvx24<>LN  @BJLnjl$&,.24fh68:<JLvx jX,UmHj+UmHj^+UmHj*UmHjd*UmH6mHj)UmHmH jUmHCJOJQJmHmHDBP^:<  H 4^>!(.*0*"@&x # & F S # & F SPx@&xx$<  H 4^>!(.*0**N+.//h0.112334N4777777777777777777777788 888888 8(8.8084888 @L "#.  N#  M#  L8@x|~0*2***********,,.,`,b,d,l,n,r,t,,,,,,b/d/f/l/n//////>0@0B0T0V0X0t0v0x0~00000&1(1*1n1p111444 4F4H4J4L4555777¹j1/EHUmHjrc8 CJUVmH 6H*mH6mHj.UmHj7.UmH j[-UmHmH jUmHmHI0**N+.//h0.112334N4777777777777 $d($d$xd"@&$7777777 8"8(8.8X8\8t8v8z8888888888888999.90949J9L9R9h9v9x99999X:Z:^:`::::::::::::::ʼʰjCJOJQJUmHjL2EHUmHjuc8 CJUVmH6mHmH jUmHmHjCJOJQJUmH OJQJmHCJOJQJmH5OJQJmHCJmHCJOJQJmH<7777777e<__=`"$$0S-d$$$  S ! %)- $d($7777788 888888$d$d$ 8 8(8.8084888<8>8@8B8oTi________ $d($d$$$  S ! %)-               88<8>8@8B8D8F8H8J8X8\8^8`8b8d8f8h8j8l8p8r8t8v8z8~88888888888888888888888888888888888888888888888888888888999 9 99999999 9"9$9&9(9*9,9.9 cB8D8F8H8J8X8\8^8`8b8d8eT_d$$$  S ! %)-    $d($ d8f8h8j8l8p8r8t8v8z8~8e<_d$$$  S ! %)-    $d($ ~88888888888e@$$  S ! %)-    $d($ 8888888888888 $d($d$ 88888888888o@i________ $d($d$$$  S ! %)-    88888888888e<_d$$$  S ! %)-    $d($ 88888888888e@_d$$$  S ! %)-    $d($ 8888999 9 999e<$$  S ! %)-    $d($ 999999 9"9$9&9(9*9,9 $d($d$ ,9.909496989:9<9>9@9B9o8i________ $d($d$$$  S ! %)-    .909496989:9<9>9@9B9D9F9H9J9L9R9T9V9X9Z9\9^9`9b9d9f9h9j9:^:::::::::::::::::::::::::::;;; ;;;;;;; ;";$;&;*;,;2;4;6;:;@;D;F;H;J;N;P;R;X;Z;\;^;`;d;f;h;l;n;p;r;x;~;;" bB9D9F9H9J9L9R9T9V9X9Z9e<_d$$$  S ! %)-    $d($ Z9\9^9`9b9d9f9h9j9:^:ea^\"@&x$$  S ! %)-               $d($ ^:::::::::::::::::P$d$"$$~0 d$:::::::::::;T}sssssssss $d($$d$z$$ ae i m            :::;; ;$;&;*;H;J;N;f;h;l;;;;;;;;;;;;<<=>>>AABBBB"L$LVLXLZLbLdLpPrPPPPPPUUVVVVVY&Zh]j]]]]]]rnj7UmHj7UmHj6UmHj 6UmH6mHmH jUmHmH OJQJmHCJOJQJmHCJOJQJmHD;;; ;;;;;;; ;";$;&;@uuuuuuuuuH $d($d$z$$ ae i m   &;*;,;2;4;6;:;@;D;F;H;J;N;P;{<ud$z$$ ae i m   $d($ P;R;X;Z;\;^;`;d;f;h;l;n;p;r;{Dud$z$$ ae i m   $d($ r;x;~;;;;;;;;;;;;{8ud$z$$ ae i m   $d($ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;|<B>z@|@@@@@@@@@@@@@@A AAAAA4A6A:ADAFAJATAVAZAdAfAjAzA|AAAAAAAAAAAAAAAAAAAAAABBFLNL  "" Z;;;;;;;;;;;;;;{4ud$z$$ ae i m   $d($ ;;;;;|<B>z@|@@@@@{yyvyyyojjo<$$<$"@&z$$ ae i m            $d($ @@@@@@@@@@LRLN$$lr     $$$P$$lr             <$ @A AAAAA4A6A:ADAFAJATAVAZAdAfAjAzAX@LN$$lr     $$$zA|AAAAAAAAAA4Y,N$$lr       N$$lr     $$$ AAAAAAAAAAAA,N$$lr   $$$ AABBFLNNNOOP(PlTUrWYY&Z^["N$$lr     NNNOOP(PlTUrWYY&Z^[]cg$htkoqttuXvvwxxzT{8}:}=~TЇ& `2RüL  ?L  P""L   !  9 !  84 L L   L              4^[]cg$htkoqttuXvvwxx8}:}=~Ї&"$@& $<!$x4xrnnttDyFyxyzyyyyyyy{zz:}<}}}}}}}9~:~;~<~C~D~Y~Z~\~]~v~w~~~~~~~~~~~~~~~ jL;UmHj:UmHjR:UmHmH j^9UmHj|8B*UmHB*mHjB*UmH 56mHj7UmH jUmHmH6mH@ Їڇ "$24^`dfĊƊ֋Ll $֕ė.0bdfnp~BDFPR)*+/0{|.0jl5mHj>UmHjI>UmHj=UmH6mHjO=UmHj<UmHmH j;UmH jUmH 56mHmHB& `2R4׶XZd&$x"@&4׶XZd&T.l:~>nnp    ``J$˿⧙ !  :\L   ghZh-L  L   L Z"L  L  50Խjl(8ҿԿ NPR\^ ",.24fhjtvjBUmHj1BUmHjAUmHj7AUmHj@UmHj=@UmHj?UmH6mH5mHmH jUmHjC?UmH>T.l:~>nnp   xx$"@&x:<nprz|z~  >$&(24246@BDFpr      H J N P  jFUmH jFUmHjFUmHjEUmHjEUmHB*mHjDUmHj%DUmHmH j+CUmHmH jUmHB  ``J$ "Y((3)X,n.&4,8:8;<BGrJ O<"@&$x!!xP  RTtv|~DFHRTXZ *,02dfhrtxzjKUmHjJUmHjJUmHjIUmHj IUmHjHUmHjHUmHjGUmH jUmHmH=$ "Y((3)X,n.&4,8:8;<BGrJ O"SdSV ZbZ[[>\r_*bZbnczdjmDrtvvvz{(|^||}}T~,BnpRT !  F !  E !  D !  C !  B !  AL   !  @ !  ? !  > !  =L  " !  < !  ;6j$l$$$$$$&&N&P&R&X&Z&Y(Z((((((((((()),)-).)1)2)*.,.^.`.b.h.j.::0;2;4;6;D;F;p;r;v;x;DDJDLDNDVDXD벫jOUmH jNUmH jUUmHjiNUmHjMUmHmH jLUmHjxLUmHjKUmHmH jUmHj~KUmH?XDRRRRSSSS8a:alanaaaaaaaaabb"b$b:ex@x}}L~N~P~R~`~b~~~~~@br6mHmH jZSUmHjRUmHj`RUmHjQUmHjfQUmHjPUmHjlPUmH jUmHmHB O"SdSV ZbZ[[>\r_*bZbnczdjmDrtvvvz{(|^||}}<<!x}T~,BnpRTf|~l6pr & FU<x!"@&$Tf|~l6pr(XZn8H`ԡ@ xУ$~¤&ZDvXZ 6xZxȹμ !  GL  L "          7  L   L >r(XZn8H`ԡ@ x$x$C$$l    \Fy"    3     $ & Fxx$xУ$~¤&ZDvXZ 6 & F"G$$l4    \Fy" 3 $x$rZjlįƯ @BDNPTVx̼Ҽּ24ptĽν"$&,.46`bdbdf 6H*mH jmH6mHjlUUmHjTUmHjrTUmHmH jUmHmHCJmHJ6xZxȹXx̼2pĽp`bXxx!x<ȹXx̼2pĽp`bXd bvxHJz*~D <d    ."vL   !  M !  L !  K"" L EF !  J !  I !  HBfhRTXZ\^`bvx dfhjfhnp  (*.0:<@BLNRT^`dfhnprtvx|J^ jmH 6H*mH jmH6mHmHH*mHYXd bvxHJzx  & FT@& & Fx & Fx^dzz|   JLPR<>@BPR|~  N P R \ ^ x.606666666777 7XX~YYYYYYYYYYjjFj jZUmH jYUmHjXUmH j`WUmHmH jfVUmHB*mHjUUmH jUmH6mHmHGz*~D <d    ."vx8  !<x<! & F!xx"@&$x"vx8  "4*--.//,6.66`7k@@ADBE|EEXFF>GGI2JJJ:KKKMORzWXYGGI2JJJ:KUx"@&$!xxx:KKKMORzWXYx5HJRx02Z\txz|~ TVX,.`bdjlz{j[UmH 6H*mH jmH6mHB*mHj~[UmHmH jUmHj[UmHM2 Ɔڋ܋ЏԏؔlnnȜL65Ͱ x$x!x!ָĻ~|0Zz!$ & FS ! & FS S! & F ! & Fxxx!|0ZzT=+Q^8yzI}VZ$^ƽ~w !  i !  h !  g !  f !  e !  d !  c !  bL  "L  !  ` ! !  _L  !! L ,T=+Q^8yzI}VZ$!<x"$!! & FW !x{"$(*\^`jl01|}$&(248:lnpz|~jaUmHjUaUmHj`UmH j_UmH j^UmHj^UmHj]UmHmH jx\UmH jUmHmHD$^j0 X {|hD.!""$x<!^j0 X {|hD.!"#$,%%&&'**-~1n2558:x=?ABDRILN6P !  r L L   !  q !  p !  o !  n !  m !  lL  L  L  " !  k !  j2 *******000000000"1$1&101216181j1l1n1x1z18:nRpRSSS SSSDSFSJSLSz]|]jclc dddd d"dLdNdRdTdkmq jeUmHB*mHmH jdUmH6mHjCdUmHjcUmHjIcUmHjbUmHjObUmHmH jUmHC"#$,%%&&**-~1n2558:x=?ABDRILN6PxQlR!<!<xxx!!x6PxQlRnR SSWYY\d\]~]]^_^__|`ahcjcdddhggkmqqqnrstLvvF{l|||yvl!  OL  a}"34L   !  { !  z !  y !  x !  w !  v !  u !  tL  " !  s'lRnR SSWYY\d\]~]]^_^__|`hcjcdddhggkmq"x!xx"$qqqnrstLvvF{l||} ~~~bt5nBt! & FP! & FR ! & FS! & Fxx<"qqqqqqqqqqqq$&(*8:dfjl (<>prt|~^0ְذ  IJƲ&(RTXZVXvx jmH jmH jajUmHjiUmHjgiUmHjhUmH6mH jgUmHmH jfUmHmH jUmHE|} ~~~bt5nBt,FHZ (ȏ,ڕ`X0Ș»~wtnjc\          L L  " !  _ !  ^ !  ] !  \ !  [ !  Y !  X !  W !  V !  U !  T !  S !  R!Q  Q!  P#,FHZ (ȏ,ڕ`X0Ș N & F7x & F & Fexxxx"$! & FRȘ NbD^02Ԣxzҥԥ§ȫbdʰʲP(nV,F lD          L             "opL  4L             3NbD^02Ԣxzҥԥ§ȫbdʰʲ"$<4x & F$ & FP(nV,F lD$$x 8 < 8<468BDhj,.`bdnptvijFHJZ^dh 6H*mH6mHmH jB*OJQJhmHB*OJQJhmHjmUmHjImUmHjlUmHjOlUmHjkUmHjUkUmHmH jUmH:   !"$%&()*+,-./0234678:;<=>@BDFGIJKLNPQSTUWXZ[\]_`bcdefhikmopqstvwyz|}~ c  $$  !"$%&NLIIIIIII$$$$Ntk a WNx[  { | { { { { | {  grqrq&()*+,-./$$/0234678:N\IIIIIII$$$$Ntk a WNx[ {|{{{{|{ grqrq:;<=>@BDF$$FGIJKLNPQNXIIIIIII$$$$Ntk a WNx[ {|{{{{|{ g  r q r q  QSTUWXZ[\$$\]_`bcdefN\IIIIIII$$$$Ntk a WNx[ {|{{{{|{ g rqrq fhikmopqs$$stvwyz|}~NXIIIIIII$$$$Ntk a WNx[ {|{{{{|{ g rqrq ~$$NTIIIIIII$$$$Ntk a WNx[ {|{{{{|{ g rqrq fhjpv|  !"%+,569:;<>@" b$$NHIIIIIII$$$$Ntk a WNx[ {|{{{{|{ g  r q r q  $$NLIIIIIII$$$$Ntk a WNx[ {|{{{{|{ grqrq$$fhjpvNLJJE>>$x$$$"$$Ntk a WNx[  { | { { { { | {  grqrqhjlnrtxz~  "#$&')*-.013456789DEFHIKLMSTUV_`abcefgjkl jB*hmH B*H*hmH6B*H*hmHB*CJhmH6B*H*hmH 6B*hmH B*hmHOv|$$$x$ Y|TTTTTTTT$$$$8tk a WN&]U"  { | { { { { | {  7  n   n    T$$8tk a WN&]U" {|{{{{|{ 7 n  n $$  !"%+,5$$ 569:;<>@ABYtTTTTTTTT$$$$8tk a WN&]U" {|{{{{|{ 7 n  n  @ABCDGMNRSVWYZ[\]^_adghijmnpqstuvxy|z "&,2:BFJNVL  " ]BCDGMNRSVWT\$$8tk a WN&]U" {|{{{{|{ 7 n  n $$ WYZ[\]^_adghi$$ ijmnpqstuvYxTTTTTTTT$$$$8tk a WN&]U" {|{{{{|{ 7 n  n  lmyz{}~   L N P Z \ ` b      P R         j=oUmHjnUmHjCnUmHB*CJOJQJhmH6mHmH jUmHmH6B*H*hmH B*hmH 6B*hmHDvxy|TL$$8tk a WN&]U" {|{{{{|{ 7 n  n $$ $$ YhTTTTTTTT$$$$8tk a WN&]U" {|{{{{|{ 7 n  n  TR"$$8tk a WN&]U"  { | { { { { | {  7  n   n  $$z "&,2:BFJNV$$$$$$<$$x<xVXnrvxz|~>FJNRVXZ\^`b  "$>BFJNRVZ^bdf cVXnrvxz|~l`gd_______$$$$$$$  p L(_!1 ]777777777 g|b_$$$$$  p L(_!1 ]777777777$$ gb_$$$$$  p L(_!1 ]777777777$$ >FJgb_$$$$$  p L(_!1 ]777777777$$ JNRVXZ\^`bgb$$$$  p L(_!1 ]777777777$$ dd$$  p L(_!1 ]777777777$$$ $$$$$  llgd_______$$$$$$$  p L(_!1 ]777777777  "$>BFJNRVgb_$$$$$  p L(_!1 ]777777777$$ VZ^bdfgb_$$$$$  p L(_!1 ]777777777$$ $t   <>PRVZ^bfjnrv|~)+,L  " X$gdbb"@&$$  p L(_!1 ]777777777$$ $t  <>PRVZ^bfjnrv|$<<$$<<$<              7 8 9 > ? J K d e f i j 8 9 R S T Y Z \ ] v w x } ~ >$%:;=>hi~mHB*OJQJhmHj+rUmHjqUmHj1qUmHjpUmHj7pUmHmH jUmHjoUmH@|~a\^YTTTTTT$$$$$$$  ' 0|]?usKKLKKKKLKK X`UP$$$$$  ' 0|]?usKKLKKKKLKK $$ W`$$  ' 0|]?usKKLKKKKLKK $$ $$$$$ [dXSNNNNN$$$$$$$  ' 0|]?usKKLKKKKLKK )+UdRM$$$$$  ' 0|]?usKKLKKKKLKK $$+,-/0123457$$ ,-/01234578BDEFHIJKMNOPQ[]^_`abcdfghisuvxyz|}~   "" Y78BDEFHIJYdVQLLLLL$$$$$$$  ' 0|]?usKKLKKKKLKK JKMNOPQ[]S`PK$$$$$  ' 0|]?usKKLKKKKLKK $$]^_`abcdfgh$$ hisuvxyz|WdTOJJJJJ$$$$$$$  ' 0|]?usKKLKKKKLKK |}~Q\NI$$$$$  ' 0|]?usKKLKKKKLKK $$$$ UlRMHHHHH$$$$$$$  ' 0|]?usKKLKKKKLKK OMJ"@&$$  ' 0|]?usKKLKKKKLKK $$   l!()*++,Z23l6;<$CxEzE!"@&x"$ S$        :*<*n*p*r*|*~*++:+<+>+H+J+N+P++++++++++++++Z.\......8?:?l?n?p?z?|?XEZE\EnE띗 6H*mH6mHjRUmHjՅUmHjXUmHB*mHjۄUmHj^UmHjUmHmH j%sUmHmH jUmHjrUmH; l!()*++,Z23l6;<$CxEzE|E~EEEEEEEEEEEEEEEEEEEEEEFFFF F FF&F,F.F0F2F4F6F8F:FdDdRdTdZdjdldtd~ddddL  " _FFFFFFFFFFFztwrmmmmmmm$$$$$$$  jR:" us  FFFFFFFFGGGz`wrmmmmmmm$$$$$$$  jR:" us  GGGIT@TDTFTNTPThTjTrTtTTTTTTTTTUUUDUFUHUJUUU,c.cbcdcd d"d&d(d.d0d6d:d@dBdFdHdNdPdVdXd\d^dddhdddddddddddd e eeessRvTvvB*mHmH jUmHmH j6mH j6mH6mH 6H*mHSTTTTTTTUUUUFWHWZZ|}}}}"8$$lF7$9!h ($$($8$$lF7$9!h Z]]&^cccdd$ddDdRdTdZd@,0-$$l04 h $$$/$$l04 h <$$<$Zdjdldtd~dddddddddddehbhlnpvqq(P(x"$$-$$l04 h $ddddddddehbhlnpvqqsstuu:vL{} tԄ<2~ևT|nVlnp40 !  !  L  EL   !  !  !1  L   L " ;qsstuu:vL{} tԄ<2~x3<<<x!!xvvvvv z|$&@BTXjl&,:<`brv.0bdfpr.02<>ɿɿɿɿɿɿɿɿɿɿɿɿɿɿɿɿɿɿ5mHjFUmHjɇUmH5CJOJQJmHCJOJQJmH6mH jCJOJQJmHCJOJQJmHmH jUmHjLUmHB~ևT|nVlnp40.tܲ! & F!<x XZbdflntv .TXZ\prtvx~@Btvx&(Z\^dfȪʪ̪֪تȻʻjUmHj:UmHjUmHj@UmHjÈUmH jUmH jmH5mHmH 6H*mH6mHH*mHC0.tܲL>@Hfv~HJtdRnTN<4bƿ{xL  KG L   !   !   !  !  !  !   !  !  HL   !  !  !  !  /ܲL>@Hfv~HJtd! & F!xS< <  <<  ,.068½ƿȿʿԿֿFHT8:DFHFHJTV@Btvx~j"UmHjUmHj(UmHjUmHj.UmH5OJQJmH OJQJmHjUmH6mHj4UmHmH jUmH=RnTN<4bz  t0 n  <x! & F!!<~  >@BLN  &(Z\^hjpr,.`bdnp  6 8 : D F j# l# # j UmHjUmHjUmHjUmHjUmH6mHjUmHjUmHjUmHmH jUmH>z  t0 n      J L    $   j ! \" " 2( , , , - - - (- >- N- P- `- b- d- f- h- x- z- |- ~- - - - - - - - - - - - - - - - - - - - - - . . . . ƿ  L  !  !  !  [ L  !  !  !  H     J L  $   j ! \" " 2( , , , - $$!<x!# # # # # # # # # # # # >( @( r( t( v( ( ( , . . . 2. 3. 4. 5. V. W. p. q. r. w. x. Z8 \8 8 8 8 8 8 8 8 8 8 8 8 8 : : :: <: >: D: F: b> d> > > > > > B jUmHjuUmHjUmHj{UmHjUmHmHCJmHjUmHjUmHmH jUmHjUmH>- - - (- >- N- P- `- b- d- f- Ό0C$$l    \n, +&    n $$$1$$l4    0n,   h f- h- x- z- |- ~- - - - - - - - 0o4o0C$$l    \n, +& n$$$C$$l    \n, +& n - - - - - - - - - - - - - - - . . . . . . <8<4$C$$l    \n, +& n$$. . . . . . . y. / r1 4 4 5 7 ; > @ A A rC C G |K JQ V X Y 0Z Z H[ 6\ \ ] _ d h m n u u u u u u u v v v v v "v $v 0v 4v 6v Bv Fv Hv w | | } R} } } } } } (~ 8~ T~ !  !  !  !  !   !  L  L  " F. . . . . y. r1 4 4 5 7 ; > @ A A rC C G |K <x"C$$l    \n, +&  n$$B B B B B C "C $C &C (C `C bC dC jC rC ~C C C C C C C C C C C C C G G ,H .H 0H :H E @E E xF F G H ! & F!!<<x"@&$| ~    $ ( + .1 5 5 8 ? XA D E @E E xF F G H vI 2J K ^Q Q vY ^ ^ Pe *f f g Lh Ƽxurkd] !  !  !  L  L   !  !  !  !i  !  !  456k(ZL  0"#H vI 2J K ^Q Q vY ^ ^ Pe *f f g Lh i i j j p vv y { | } ~   !x<! xx!Lh i i j j k p p vv y { | } ~     f ʍ ^ К p ž}zpf\!q  !  !  L   L  !  !  !  !  !  !   !  !  !  !  !  !   !  !  !  !  $   f ʍ ^ К p v xx ! & F h ! & F ! ! & F!p r v x ̠ Π     V X Z \ j l    " ( * , 6 8 R T jiUmHjUmHjoUmHjUmHmH j˟UmHjNUmH jUmH j6mH 6H*mH j6mH jP6mHmH6mH

> > > /> 0> ~> > > > > > > > > > > > > > > > `@ b@ @ @ @ @ K K K K K K K K jUmH jUmH j{UmHmH jcUmH6mHCJOJQJmHjUmH <B*mH jUmHmHI\ 0  j  4   P   F  > B T          " P T t        B F d  , 2 d L' ( ( ɿ|yVL  L  L  L  !  !   !5  ![   L L  [ / P   F  > B T          " P T t        x!! & F B F d  , 2 d L' ( ( ( ( &) 8) :) ) * l* * * * n, , v. . . pp`$x( ( ( &) 8) :) ) * l* * * * n, , v. . . . / X/ / / / d0 2 5 x6 6 `7 8 : j; ; ; ; < < (< B< g< j< k< < < < < < < < < < < = = = != #= ƽ!  !  !  )L  =[L   248. . / X/ / / / d0 2 5 x6 6 `7 8 : j; ; ; ; < < (< B< g< j< k< < xx@&! & F<<@&p< < < < < < < < < < = = = != #= 3= D= T= W= X= q= s= = = = = = .> /> "$#= 3= D= T= W= X= q= s= = = = = = .> /> > ? @ 2A F K K K PL N $O 4Q V W \[ [ ] h] (^ ^ H_ ` ` Jg Lg g zh i i j l m ro r r r r r r r r r r r r !r Fr Gr Zr [r ^r _r `r ž L  !  !  !  !  &L   L L  "C/> > @ 2A F K K K PL N $O 4Q \[ [ ] h] (^ ^ H_ ` ` Jg Lg g zh i i "!<"x"$$K K K K K bO dO O O O O O V V V V V V V <\ >\ p\ r\ t\ z\ |\ \` ^` ` ` ` ` ` e e e e e e e Lg Ng g g g g g g h h $h &h h h i i i i i $j &j Xj Zj \j fj hj j`UmHjUmH jUmHjoUmHjUmHjuUmHjUmHj{UmHmH jUmHmHAhj nj pj j j j j j (o *o \o ^o `o jo lo q q q q q q q r r r r r r r r r r r r r r r r r r r r !r Zr [r \r ]r ^r _r hr ir jr lr mr pr qr ur vr wr xr ĽĬĽĽ6B*H*hmH *hmHB*CJhmH6B*H*hmH 6B*hmH B*hmH j6mH j6mH 6H*mH6mHjZUmHjݫUmH jUmHmH;i ro r r r r r r r r r r r r !r Fr Gr Zr $x$$$Zr [r ^r _r `r ar cr dr er fr Y|TTTTTTTT$$$$8tk a WN BU"  { | { { { { | {  7     n   `r ar cr dr er fr gr hr kr nr or yr zr }r ~r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r s s Bs ft v w x ^y !  !   ]fr gr hr kr nr or yr zr }r ~r P$$8tk a WN BU" {|{{{{|{ 7   n  $$ xr yr zr {r |r }r ~r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r s s s !s "s $s %s v w z z 0{ 2{ @mHmH jUmHmH jB*hmH *hmH6B*H*hmH 6B*hmH B*hmH B*H*hmHL~r r r r r r r r r r r r r $$ r r r r r r r r r r TOOOOOOOO$$$$8tk a WN BU" {|{{{{|{ 7   n   r r r r r r r r r N\$$8tk a WN BU" {|{{{{|{ 7   n  $$r r r r r r r r r r r r r r $$ r r r r r r r r r RLMMMMMMM$$$$8tk a WN BU" {|{{{{|{ 7   n  r r r r r r r r r Jh$$8tk a WN BU" {|{{{{|{ 7   n  $$r r r r r r r r r r r r r r s $$s s ft v w x ^y z NLJJHHDx!"$$8tk a WN BU"  { | { { { { | {  7     n   ^y z 8{ { | | ~} 0~ 2~ p R X  " P Q f L > n : z ԏ 6 *   < @ 0 l ® > L ̶ r "'0^L  ^"VL  L  L   !   !  !  !  !  "52{ 4{ 6{ D{ F{ p{ r{ v{ x{ L N P  " $ ؅ څ ܅ ޅ   D F H J X Z t v ԏ   ʢ ̢ j4UmHCJOJQJmHjUmH jUmHjUmH jUmH 6H*mH6mHmHmH jUmH j׬UmHEz 8{ { | | ~} 0~ 2~ p R X  " P Q f L > n "x"x! & F!"$ : z ԏ 6 *   < @ 0 l ® > L ̶ "x"$"<x 8 : < > L N x z ~ « l n      D F J L   B D F P R D F H J X Z ַ ط ڷ Ĺ ƹ r t    jdUmHjUmHjjUmH jFUmHjɴUmH jɳUmHjLUmHmH j7UmH jUmHmHE r  ( p    T  B L f H x!x$$"$ nr  ( p    T  B L f H \    &   d   Z   < > N Z        <   ^   ! ! l' |' ) <* * * D+ Ļ"vL   !  !  !  !  "Y+L  "FF  F H L N    h j l n | ~ D E F G H N O d e g h     &     d j      $ Z ^  6mH 6>*mH jaUmH jU jjUmH jXUmHj۸UmHj^UmHmHmH jUmHIH \    &   d   Z   < > N Z   xxxx$"      > N       < @ B J L N       ^ ` ! ! & & <& >& @& J& L& R& T& & & & & & l' |' ) ) ) ) <* D* * * * + D+ + 1 1 6 6 : : < < D J J J J J J J ZK \K ^K tK mHCJmHjҼUmHjUUmH jUmH 6H*mH 6>*mHmH6mHO      <   ^   ! ! l' |' ) <* * * D+ + 4- . ~/ 1 1  & FxxxxxD+ + 4- . ~/ 1 1 1 p5 r5 6 6 6 7 7 D8 9 9 8: : : : R; ; ; t< < < < > A B B B D D D E E JE zE E E E E E E {xxxxxxxvxxx !  !  !  !  !  !  !  !  !  !  !  !  !  !  !              .1 1 p5 r5 6 6 6 7 7 D8 9 9 8: : : : R; ; ; t< < < < > A B B B D !xxxD D D E E JE zE E E E E E E "F .F 6F FF HF JF NF XF F F T$(($$$*+bmMU"$(($$x($E "F .F 6F FF HF JF NF XF F F F F F F F .G JG LG NG PG RG TG XG zG G G G G G G H H 1H 2H 6H >H ?H @H BH SH rH sH wH H H H H H H H H H H H H H H H H H H H H H I I I I HJ JJ PJ ZJ J J J J J J ZK \K ^K `K tK N NR [ _ ~e L   " XF F F F F F .G JG LG NG PG RG TG XG zG G G G G G G H H 1H 2H T$(($$$*+bmMU"$(($2H 6H >H ?H @H BH SH rH sH wH H H H H H H H H H H H H H H H ׼$(($$$*+bmMU"$(($H H H H H H H I I I I HJ JJ PJ ZJ J J J J J J ZK \K ^K ׼"$(($$$*+bmMU"$(($^K `K tK N NR [ _ ~e Fg n p Zt \t y l~ D Z r t ę ƙ X  @&((x~e Fg n p Zt \t y l~ D Z r t ę ƙ X  қ ٜ Ğ B à = 1 Σ T f 0 ƿyrkd                                      R               %tK 8 : l n p v x ~ G H w  ! j ,k lk m n o o lr r s   =   ;   :   9   8   7   6   5   4   3   2   1   0   /   . $ t p 4 4 A : k F  $ & F$ & F: k F  3  s  4  u zsqjc\UNG   b   a   `   _   ^   ]   [   Z   Y   X   W   V   U   T   S   R   Q   P   O   N   M   L   K   J   I   H 3  s  4  u - 1 H x p +  & F & F$$ & Fu - 1 H x p + . t ; ]  n @ zsle^WPI   |   {   z   y   x   w   v   u   t   s   r   q   p   o   n   m   l   k   j   i   h   g   f   e   d   c . t ; ]  n @ R F g  =  $ & F & F & F & F & F$ & F R F g  =  P I  ž~tj`VL5  53  5  5g  5W   5                                   ~   } P I  s a [   m 5 & F5 & F@& & F & F$ & F$$ & F s a [   m  b     v b j v   V ĺzsle^WPI 5   5   5   5   5   5   5   5   5   5   5   5   5  5  5p  5  5  5  52  5  5_  5  m  b     v b j v  V ;  f   2   Y 0  5 & F5 & FV ;  f   2   Y 0    1  n  O! _" " |# f$ I% & ' o' xqjc\UN 5  8 5  7 5  6 5  5 5  4 5  3 5  2 5  1 5  0 5  / 5  . 5  - 5  , 5  + 5  ) 5  ( 5  ' 5  & 5  % 5  $ 5  # 5  " 5  ! 5  5    1  n  O! _" " |# f$ I% & ' o' =( ( c) ) * + e, - - . / / 0 5 & F5 & Fo' =( ( c) ) * + e, - - . / / 0 0 31 2 2 O3 5 |6 6 K7 7 R8 9 9 N: xqjc\UNG 5  S 5  R 5  Q 5  P 5  O 5  N 5  M 5  L 5  J 5  I 5  H 5  G 5  F 5  E 5  D 5  C 5  B 5  A 5  @ 5  ? 5  > 5  = 5  < 5  ; 5  : 5  90 0 31 2 2 O3 5 |6 6 K7 7 R8 9 9 N: Y; ; 7< < = > A@ A gA IB YC D D UE 5 & F5 & FN: Y; ; 7< < = > A@ A gA IB YC D D UE E F }G H H I I PJ J K *L M zsle^WPI 5  m 5  l 5  k 5  j 5  i 5  h 5  g 5  f 5  e 5  d 5  c 5  b 5  a 5  ` 5  _ 5  ^ 5  ] 5  \ 5  [ 5  Z 5  Y 5  X 5  W 5  V 5  U 5  TUE E F }G H H I I PJ J K *L M M ZN O O P Q iR R nS S T 8V &W W X Y 5 & FM M ZN O O P Q iR R nS S T 8V &W W X Y zY 6Z Z [ v\ ^] B^ ^ _ ` zsle^WPI 5  5  5  5  5  5  5  5  5   5  ~ 5  } 5  | 5  { 5  z 5  y 5  x 5  w 5  v 5  u 5  t 5  s 5  r 5  q 5  p 5  o 5  nY zY 6Z Z [ v\ ^] B^ ^ _ ` pa Bb *c c d ee f f vg &h i i j j j ,k k <<5 & F5 & F` pa Bb *c c d ee f f vg &h i i j j j ,k k Bl l dm m o lr s u v hy r{ .} v} $ & : b ƈ X Ό Ќ Ҍ Ȏ K  z { 4 !  !  !  !    5  5  5  5  5  5  5  5  5  5  5  5  3k Bl l dm m o lr s u v hy r{ .} v} $ & : b ƈ X Ό Ќ Ҍ xx<4<<<<! Ȏ K  z { 2 N P R T p r Н ҝ " $ X $$d&d'*<@&{ | }  2 4 P R T V b d l n r t  ĝ ̝ Ν Н ҝ ԝ   > @ ž  " $ & R T t v jCJUmHjCCJUmHjƾCJUmHCJjICJUmHjCJUmH0JmH0J j0JUCJmHOJQJ j0J&U= 2 N P R T p r Н ҝ " $ X Y Ġ Š % & 2 4 Ң Ԣ 2 4 6 8 : '*   V W X Y Z p q   à Ġ Š Ơ # $ % & ' J K . 0 2 4 6 b d Ң Ԣ * , . 0 8 : CJmH jUj*< CJUVmH jUj7CJUmHjCJUmHCJjCJUmHCJmHj=CJUmH6X Y Ġ Š % & 2 4 Ң Ԣ 2 4 6 8 : <@&&d&d200&P P. A!"#4$4%SS200&P P. A!"#4$4%SS/0&P P. A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS(&P . A!"#4$4%SS`!IbqȓmV5Q_ x{tEǫ*]M /3;nj2 Ka0BX/ F"O BD0.ȨD^:f?]}۷009oWunu}(/DLvmROCyUIUPP`"KV kJp6OocYP9f4Wӝ'ț9AMϾ^p%Q.f-4h(AY!)ߌ[ {]BT0u5qw*TtTQQf 㴅{IeQy7{l Ãj^6^Q2CFiQ~2J{5 F j)()_g$"eQ:"%(=G5J\,*[ULkiGv>j*45|W#.^ㇲ.q}{1Jնb _ZbV2ĕ |{XyµJe%dIx%^"^%tLD(U{%Xxm+XY11rD'*e_T,"U{F.UUbW>U-gW1QWe]TCU x}H5]gb5٣Z@jWXU{/j~ZjYZZ"eYן-ݻO)-֟- )?W~_ly6&]Cv}]Z?k;Ī:"zm!=+WW~}fR*cSdO9Tƞ'?S廥2nyCnKel~.ƪ4nF2ZVoY+5S-{&VmSVY*c7 bF}MΉOJe_Pںt랲M=ONSR{ܡȍ2R1%yTnZٍ}vSjp3Ւ[[tl-u]ǚ.V⽨kpLU8~-<}g!fuxδQ.E':X٧:՝Y}!`Eu/*91~nĕu .2eWfYui$?YZ:?8_[%㭀DZ Ɯ׈sWከkjKNɫC<^5ҧYiQ5'O'QjwT4>S#jr@4uz}B vlbum.v%WPBe%CTbBO;v^Wtu|]C^յBW]_@CyCcI7vr`k'*hYN-di챴d%{,oڞi2~祴_d̗̄Yo2JyMor W6oN!ôYAtCQy^#>~1eu>ɼۙ?:n6UbdfΆҲI۞J-&*Ajdϱg30NSe!~ `Aӗtg$jӔe{~zԧ59 k"|g"|7jUA#lxD\ :+pR1n+>З/z xI#!<}?8AT|`2L!>N LCF+C&, _/%^ӿX &؈Mr`l'ߎxFM|8 ?~%3}  <p*7F^ULW"W 7 o>~A =͡z3k =y{v zO@~0N>}?x FM|A:|3 a ka  [CѷxۉAzp~q8~0\g\.hITvk0ގ/bW.3y%Q!C8 %Qn밂|!@xo$,sg2K| CDC8 8tD9dC8 (uI %Qv(ykC8 xBwI-:4'of|gqh/^~\tygY/ A ;,?.OuG$".r^AvXĿ%]62C8˅xf4찈?%]N,C8Ǡx2찈K|Cw A ;,.;uhEC874%$:ܝuV q .rWu8K!DROSx5Cjǿ%O밙C8x]:o/3Cjǿ%O-0|!DR= t<5ó !␚AwS: &dT%O=ס;qH;NxZ"st< CS !␺Uҷ1I8~|}DyK _Toc409163438}DyK _Toc409163439}DyK _Toc409163440}DyK _Toc409163441}DyK _Toc409163442}DyK _Toc409163443}DyK _Toc409163444}DyK _Toc409163445}DyK _Toc409163446}DyK _Toc409163447}DyK _Toc409163448}DyK _Toc409163449}DyK _Toc409163450}DyK _Toc409163451}DyK _Toc409163452}DyK _Toc409163453}DyK _Toc409163454}DyK _Toc409163455}DyK _Toc409163456}DyK _Toc409163457}DyK _Toc409163458}DyK _Toc409163459}DyK _Toc409163460}DyK _Toc409163461}DyK _Toc409163462}DyK _Toc409163463}DyK _Toc409163464}DyK _Toc409163465}DyK _Toc409163466}DyK _Toc409163467}DyK _Toc409163468}DyK _Toc409163469}DyK _Toc409163470}DyK _Toc409163471}DyK _Toc409163472}DyK _Toc409163473}DyK _Toc409163474}DyK _Toc409163475}DyK _Toc409163476}DyK _Toc409163477}DyK _Toc409163478}DyK _Toc409163479}DyK _Toc409163480}DyK _Toc409163481}DyK _Toc409163482}DyK _Toc409163483}DyK _Toc409163484}DyK _Toc409163485}DyK _Toc409163486}DyK _Toc409163487}DyK _Toc409163488}DyK _Toc409163489}DyK _Toc409163490}DyK _Toc409163491}DyK _Toc409163492}DyK _Toc409163493}DyK _Toc409163494}DyK _Toc409163495}DyK _Toc409163496}DyK _Toc409163497}DyK _Toc409163498}DyK _Toc409163499}DyK _Toc409163500}DyK _Toc409163501}DyK _Toc409163502}DyK _Toc409163503}DyK _Toc409163504}DyK _Toc409163505}DyK _Toc409163506}DyK _Toc409163507}DyK _Toc409163508}DyK _Toc409163509}DyK _Toc409163510}DyK _Toc409163511}DyK _Toc409163512}DyK _Toc409163513}DyK _Toc409163514}DyK _Toc409163515}DyK _Toc409163516}DyK _Toc409163517}DyK _Toc409163518}DyK _Toc409163519}DyK _Toc409163520}DyK _Toc409163521}DyK _Toc409163522}DyK _Toc409163523}DyK _Toc409163524}DyK _Toc409163525}DyK _Toc409163526}DyK _Toc409163527}DyK _Toc409163528}DyK _Toc409163529}DyK _Toc409163530}DyK _Toc409163591}DyK _Toc409163592}DyK _Toc409163593}DyK _Toc409163594}DyK _Toc409163595}DyK _Toc409163596}DyK _Toc409163597}DyK _Toc409163598}DyK _Toc409163599}DyK _Toc409163600}DyK _Toc409163601}DyK _Toc409163602}DyK _Toc409163603}DyK _Toc409163604}DyK _Toc409163605}DyK _Toc409163606}DyK _Toc409163607}DyK _Toc409163608}DyK _Toc409163609}DyK _Toc409163610}DyK _Toc409163611}DyK _Toc409163612}DyK _Toc409163613}DyK _Toc409163614}DyK _Toc409163615}DyK _Toc409163616}DyK _Toc409163617}DyK _Toc409163618}DyK _Toc409163619}DyK _Toc409163620}DyK _Toc409163621}DyK _Toc409163622}DyK _Toc409163623}DyK _Toc409163624}DyK _Toc409163625}DyK _Toc409163626}DyK _Toc409163627}DyK _Toc409163628}DyK _Toc409163629}DyK _Toc409163630}DyK _Toc409163631}DyK _Toc409163632}DyK _Toc409163633}DyK _Toc409163634}DyK _Toc409163635}DyK _Toc409163636}DyK _Toc409163637}DyK _Toc409163638}DyK _Toc409163639}DyK _Toc409163640}DyK _Toc409163641}DyK _Toc409163642}DyK _Toc409163643}DyK _Toc409163644}DyK _Toc409163645}DyK _Toc409163646}DyK _Toc409163647}DyK _Toc409163648}DyK _Toc409163649}DyK _Toc409163650}DyK _Toc409163653}DyK _Toc409163654}DyK _Toc409163655}DyK _Toc409163656}DyK _Toc409163657}DyK _Toc409163658}DyK _Toc409163659}DyK _Toc409163660}DyK _Toc409163661}DyK _Toc409163662}DyK _Toc409163663}DyK _Ref409167827}DyK _Ref409171766}DyK _Ref409173045}DyK _Ref409173045}DyK _Ref409238939}DyK _Ref409239013}DyK _Ref409244619}DyK _Ref409244619}DyK _Ref409257371}DyK _Ref409246831}DyK _Ref409246833}DyK _Ref409247530}DyK _Ref409247532}DyK _Ref409142339}DyK _Ref409258193*Df@/linkane slike\andreasen duffy preslikavanje.wmf  s `? linkane slike\andreasen duffy preslikavanje.wmf}DyK _Ref409151822}DyK _Ref409151825}DyK _Ref409151916}DyK _Ref409149372}DyK _Ref409149374}DyK _Ref409152505}DyK _Ref409152507}DyK _Ref409233023}DyK _Ref409151916}DyK _Ref409149372}DyK _Ref409149374}DyK _Ref409149372Df?*linkane slike\taksonomija istrazivanja.wmf   c zV? linkane slike\taksonomija istrazivanja.wmf}DyK _Ref409149372}DyK _Ref409149374}DyK _Ref409261642}DyK _Ref409152939}DyK _Ref409263740}DyK _Ref409263479}DyK _Ref409263517}DyK _Ref409263538}DyK _Ref409265645}DyK _Ref409265701}DyK _Ref409135683}DyK _Ref409265763}DyK _Ref409266006}DyK _Ref409266015}DyK _Ref409135683}DyK _Ref409266591}DyK _Ref409266596}DyK _Ref409266601}DyK _Ref409266607}DyK _Ref409266609}DyK _Ref409266612}DyK _Ref409269148}DyK _Ref409269154}DyK _Ref409269156}DyK _Ref409269158}DyK _Ref409269161}DyK _Ref409269853}DyK _Ref409269858}DyK _Ref409269862}DyK _Ref409269865}DyK _Ref409269868}DyK _Ref409269871}DyK _Ref409270389}DyK _Ref409270391}DyK _Ref409270393}DyK _Ref409270395DfA2& linkane slike\RESEARCH AREAS.wmf ! c fB? linkane slike\RESEARCH AREAS.wmf}DyK _Ref409183564}DyK _Ref409261642}DyK _Ref409171901}DyK _Ref409171903}DyK _Ref409261642}DyK _Ref409152939}DyK _Ref409493420}DyK _Ref409496503DfP.9:linkane slike\lindemann.wmf " c \8? linkane slike\lindemann.wmf}DyK _Ref409496503}DyK _Ref409496503}DyK _Ref409493420}DyK _Ref409493420}DyK _Ref409173935Df'c$linkane slike\HUEN5_4new.wmf| # S X:linkane slike\HUEN5_4new.wmf}DyK _Ref409173935}DyK _Ref409152939}DyK _Ref409171901}DyK _Ref409180953}DyK _Ref409182852}DyK _Ref409151916}DyK _Ref409152939}DyK _Ref409183300}DyK _Ref409183302}DyK _Ref409183304}DyK _Ref409183306}DyK _Ref409183310}DyK _Ref409183311}DyK _Ref409183304Df,#linkane slike\MEUSMKOR.WMF~ $ c Z6? linkane slike\MEUSMKOR.WMF}DyK _Ref409261642}DyK _Ref409233023}DyK _Ref409233026}DyK _Ref409183306}DyK _Ref409493420}DyK _Ref409493420}DyK _Ref409183306DfE/8ZY!linkane slike\VDI 2221 - NOVI.wmf % c hD? linkane slike\VDI 2221 - NOVI.wmf}DyK _Ref409233023Df@ ,  linkane slike\VDI2222.wmf| & c X4? linkane slike\VDI2222.wmf}DyK _Ref409233026}DyK _Ref409261642}DyK _Ref409173935}DyK _Ref409151916}DyK _Ref409173935Df!mlinkane slike\hub model1.wmf ' c ^:? linkane slike\hub model1.wmf}DyK _Ref409261642}DyK _Ref409173935}DyK _Ref409151916}DyK _Ref409182189}DyK _Ref409182190}DyK _Ref409160783Dd #EQQ<  C A 2)Lp~k >@`!Lp~k >VV BVPZ(xmlSUs=/7ea&6$"4-e3GX N8>HC'8&f &$D1DE@RCL@H}-ݐK ss{{f;񀮟 dv315ZXpMӸR7Ҙdmd }D6?y=ɭSB3]b6äHhtP QGԂe7? R5R1f\ 8 u!Їs:t!( ymtLF18^qd)d_ b_ s>~CM7kJ頙K;l _d 0q>nL2\p3LL VpFη=WU^e*YjӦ:jsKENq:ӺGznrܿ@W,=I_R)5Iw<ݦj^œgk6ZyƛüY\^<2uT2`<.i #GW}xT<=FGm8)U}M OsO܏ Fvy}`*AtHuH@^hg9<>GRJVk,4 fI:[yg(Epˆ(>npCO e"l Pņi u/PYX!ಡQ!$gCkCȣ]nL!† lX#ಡE!Ćm ~6n @3 4 6n!OeʅٰJa%\6)`%i?n7 ըee!_φR*6lnp$v8 5l(np0G!Ć A6blxV ¿_apC 7ln8Ɇo*p= Q - 5l% lnA{k%"mA!̆ׄl#dW +cYᆕlna\lCn2 pCCt  7l8.b A6nJZ{cHyT~:6D3$PctQa!PNrl)?ùĹĽ1=g8y3 -Gv*1z)ϓR,B_+Ktԅ V7KWΒS]4$YD3~pk4&\)>* NXw8")©A'!fgP(Q!gltvtrd{ew8rK&8{d"?~< _FٍvlAkld=dP{e U2I2YFerT$29(eH'*yTD|@:Q**Y"ehoC}ܚQ{);ƔC h7ֺ uhFTh[F 5RFn~?+S\}7)uyũ=n<6w~ib>WyAe6*ù*3tunSÔ(YrՅ V7R R*\#ʠrFT5ګ蠊*NUpkQ[SwK u߫p ޙX0b,D.W3h{uE '4CD?]F"M@8kڪZ&:Br_q~D{j^JŦf .˩y''j0}$7>TS-MwE>'rc#3óB)766Y1gf9 ]AYTM/=1~7区SbD%mGq~Ngҷ釼 P 90uSC~z_tA~ZyvjvmE_6@_<>h"PxLD ai%v3 7q #7bRz%-+{Oި>L3*TBKy}Ļa3#cQD7^3JM>)~C(;Y[C!C@09V/ |n7y}90`;n;oܗ#XO׉}  =-\țX ;e\>^+3$ƵCds1d|ٽ8b2>E'G>DKf״LhδթV&vh'_Ǿll'Ȉ~dVU)bϢ¬+gL*z,Pxb9DZg9C 3\Ar0~C >0$[p-gC `n04Zΐ V hT,v3a `h9 [^t.AnhnC 0Xΐ jym9C>,g =3{ir/.XΠO,g(jzڵ /Zΐ,g 0DE͠si LYΐI[`赜 oXΐ 3 ,gXh%}-gwYΌ_'V~$z J*0s` ?Kٽ`x ȗW< oS2}!C\w}YaBE9^FS=lyXpeic}DyK _Ref409182190}DyK _Ref409163449}DyK _Ref409182183}DyK _Ref409166254wDd <   C A 2_w/@ e1~E;wןv`!3w/@ e1~E3nIЍwxնh Arڵ$g$* 9IFs%*bBTLH9|O::Y{};]+*jΑpwÑF:{_d_eO?'%}'~O!%Nvt1}j dksb3G*sͱ;`sɜ43W*ϔ2揊aUrtҩIIz=z6z,/=ϤI??&QO &I53}VۚG1~M#v%Lڮ뤺bSSOrikik+Y+:ɩ}W'R7%mUJZnMG._I գIϩr'O:d7!ϕrrs|_iRFfocLHn:ܽMUW\Jλh]IwW]mKצhkkZWWg\U%+VuRZO '-kZ4)լJ!]%5V3LDPSUrY`5Jic f([˔%l)gki=TҹrNW E˵P}:uL]򨟺j\մݮ -ɵ[ hݹEvwM=Aںlgs5snvjjbts3FJ\++"q={]gINyZ$eLn"K˜l2a]ԥ{& FAgDN"{Fbv%=Mu%se)^5Y[[2sn^ԝKRq7'^=Q>rɮ<.7W֍]eYW#cѨau5߻[[=߈3'"yc="L}+{}O{;22i"y{ɂwdĻEvüd%yc+o.cq[py72Qxh uF{E@xmk63x_0~V4g7+_5eQ:|&yZSjrGzZ}}g>3ByEyNœ^$jxr9՚ޑMq(%wӲ&+k#Gh9RwE;*7_*kulDem{)>h7%UwޱʟIYR2T7wKyV}ե/|]|cMwJ+ZqMVɿOwi#]1;Aں)dL[̓'C\>?@SK w;[9iڕLߊsb?&VYR_ e9߂xHT9пFv$ɗe-,N Fq8kkM7r,yo6I@ |*sP@=Nԍz\p^7xSoL/ 7u`G48RnΒ7noM|]ɒ@ 17K> ԦVkX31%Kp3GԹ-h[eU]UfU*CV)J],}|ڣ {j$TH Qk³.p:;][m /N׮oi _x m|4Rxr_1Fp16™E\%__Oy>,Kw|~F^ݑ>e*zK>&7 WxJbv%S>YS>9S<)~?E k*ȟIϓ_ϙr_ϚUfHyNFÍS&ߖ7Ky(G_߅pzoL 7F=FpkFpw#~>l]&+Dߓ2Gf6Hy3]XCt}a>5@)hR"E&H^4T*E(o*F*tld/V)EOeu27rGyQGJ}# n.j8ed<8rLmIV_^Tv0N{1Rk١5њG#UӴ+y!RCԈ# Zj4kJ4>Fri#.rZ#E6$^{M5RDɪx#ّʊ^YLU.GstUhW\0ڎMnΉw65;bd?[DkGUЊky>5}^-UVǺ cec!!vOi;RwJ:Ŋ.QFg(;+_1LmO2QjjD*ף`t#@)ZV=JeB̭̍eV ?jbm˱jrl!Y?'ٵF ZZhmh|6>6-~KVWZx^I4y"c FxQ`\13u,~K=!OA-Q/ċUg]}C|YSTbmX,ǧ$iWyM3C)ąk~co%I)_!~_&U~Nn7"^O _"ߋo{dE),_'FxqCW1 7y3oa7y*fu`uS&RjuS616f$p_Zk܋#.es?=rW]ս6u:UG}szVm)\WҮ6)e)kzKYh U޵+^JkbWiWzElP&[mVg\&(~#%kRWU12Qf'fW?&֪5Z^+.q5sڻj[a 8CLr3-Q s\\53 Wq#3F~wLqeEeY}P&[.{,rחoKʉrgs_Ђ\wV}ȽSLv'&iW1X^)Vw5[b;5Ysȹ2rSuO ɽC>-_tߗݏdQ֍҆U͸ov55~v46\SyRoON-E*uڞ[撿8V~}_mіh+i9~K?ZV;Qߋ}_ //|黡,Q&~ST:V) }󔲾)$y+ފ]]NoK強vP2+}꾑ʫ^Yx}lPN)G}> 5ZZ?>T;7շՙL )s+ڏanB'vǟQ$ˉM="FUm_/`6&s>]~?*o;.o2!~#\WԣzH򿛘]E?^<"{"lzއ|[(gxZЧgxGFd\}m{To{vyߒruL4F=5FFs6F>'#򔟂⡎J  vH)RtMyMشK))^Iq))[)s)C)ʹt)%5o8v#|S=ޭoT?TW3-1jT[3ÖR"|NޭD8 Tx/iʆenh2!_ꩴuQj:)vv%uB֡ʠkvPWeKhWhr14I'KxR0M>4 _Up.uZ"UToE5cJD͗RP+@G{!eHoWWƥ0QCsʏzgM?o^i+ JpH-Sy\vR*JnD+hS%O5X;^.6@LMRz6B]UϥV_R{߻JuF|2~QxV|o"SZ&GQThf |/W1ğ7+}⥌Ɣx>c!gu:~_?+kUA|ŇH-: \ 2㮮9sc^1r]B/ȠkBq*8lQIUr %EvQqETvӫ*k *96Rz1GfYQ\2|1\fKo|./ďC u0/^ ^mt74^73[ryZOADW39Z ΊY՞oF-{Qֆf iM [t 75c QϰeO7JxS0sc̈b& [?"= bYM 8>ʬ0+ >,2aY[kb%byS|g?wOfnůCl'??O2.31ai:;fL\3KfX7 N^q'MSdtڼ8gY_kpp]lSqn *(Ss,cFм$W>|^#G!քD't]3n!ғ̼3~TЩmS7M]Wgџ1iOr@v,dO 3~pq?g~3'y1"9 v:܁$ȽC5! ы} G(Jba"uet8/!}2ѻmKOdPbUh[K;XBu ="z/*cJR@lCBgR0Nބ0` qMm&N+/a{5<tk;N.vi-kG >=9888תcO.%2lc+RŰȪ Jĩ U[MOdLdL)T8> L s<|Xgb[fKCbG,vbEL>'X،vNn+ X{YWl&$&f2k'c'Sa1>`:3In;aYs6x&L"2pfYjr˹j6W5o /gA9l7BLw+;a;6?aY.+!*_Kl6_Х/nP ϑ-Go$$aUqYHb7t;lK_@_j+fEWH䐶 CxHARD61OV=7}n>r_!zS T R%LUȨ*U#jdZ }0\y(`( 6 oh͆0`L~kMfdLNTL;=?m$6TzYVCё ߅.t^TתɰC*:rjƩŴFc?f(Ehɲ!6m̚YTtZub!V;@NՙAOtE&tz0# Ùޛ0Qo-lb8oul}? `| %)x?0z1<S z3A{COtݱF]Xә5[%q_, gfp{  BΟA-zU*G@Y<* Jhh=ߴc1OSCg,d>]0]0jKW29til:6aj!\A ̆ytz!]_V2YM`ݧ>M`+؂7-?#$Lh'S'E/j `J)m*{؊݆mmfuEVR5yŎ6ou'ح&j%}[IVU䴊ck`- 1=V>x> tΑy2@f"^ҋTz .0 Ts*< '$p2L\y%E +o&"90=_\ |u wy+g}ޮxm{޾&op p.E/BON  PMQmb"ԅ0!>f:EĚ!R 7ly"dt 3dg] DvBõ:B^WvE\EQ׀Q52c CT B0aL𦨕` 5*6"~41J\EWQTqĶyW5W]UEl&(F(7Rj q C.WT^?_hJKxjcSo.|U@M`>7Z]DVt&dxhj*ZCCxQ$VtukCvЕn]/lPQ_ve=SYubUŮB5\E{h ZC x蛸t%|6WCj SW3*-XӒ^'6kGߑxo@O+CSczsz1éky `j^t'fw񚫛x^qu͡}h1߈\}n a0 Hb()!~9d((E?GыQ1|sz46q0> 6wq.3xL=F0 r?ΞO {r;^Gzo#/Ñۺ9g^wMm|3| t[.U{3cmǼ i-ߍ֥-ݝKh{NfHt˖_I3Yl&X"gf˽l]j:Q B =b1OY͖Kե-B3<ӱe.uū-K[;h{E-vlyTӝK:*-ݤMHE] M ]jU$oGYo1f <e. ë-֥-ݝn{=OJt˖L=ݹ,lo\Nu [K[M$G01;IRuiL<mϏ<3xn.md"wۣY[K[;+m_{'eW\W㿉D団x}.{b]FGKo@ta2_C}/,OŽAYm<{iyğ +tݳueU? eP.9&#C-#ui7CwCtۣdh~9@Sui=t9j"ui`wgmP-[>,UtIWicpf׋!5-֥AU,h{n,lT]"nԄG@Y lY.mkm-\Vi6i&X"͖/DfVӛ!U{;T(?TL{3TVSuiIg61m!ui`wAGs~jeӧ\ DP\ $q$–FnVS074& NYB-ϝK[xh{$[>r[vw /DlTӝKOt ťMIe8(ly_.m55 -cmϵD$a_Mե-o b/3=ڞ2L֥ۖ-ݝ)ۣ{-?{s5\.Q`>Mժ-K[MCBF£ya:TJSui0V'(u) ^my~d.m%wۣEje˧\7}F^ l 7ԍ?%7o:Q5H{-ϿykY?N ]VLJe,\%K$xeҖoAfҶofӗĦG }Vln<Ӭ ^ l]"ݑn{=W[@龓*FWi%ME\/dtf+#ui)WTDP£h1-WfT]"|)- ڪH!͖OCnǑ5 "ݲkRuOw.cMQE\/h!r[ TLP£Y jT.m3h{^lbڶ|)r[vwfOmϻcvl;3Q8 N;Aa!ui0gtL£ctk 2[vw܉ZnSuOw.y>%3c6I\'X,(ly~.m5bD46&|?6Ab-K[!x'_I\OՖBfDr=ڞ|nɩ;jFVf>ժ-֥Wc1#0VX}5VJmSuiWz4?|4ZJ=5T[ K[;mϮDlTݿ˿l׊o9рXme?%zG7:ye="{?.D7ejZ*ge͙T:NzS p.e yջR^y׻N~*g}d6npMY 3< .mlM}|gr?Q J@1(/YDoS[59|G}E; sPY)!Y ;.Ns&<&C O] vnKjMl`5XgAzzAA>#Bާ,|>PeL*Ez>/zAoC` ؽOǦЩr﬜$˅;pkSe3T>z&p= f%7YcPQay |+PӷR/SM"OnЕ:%~r&,往Z֭=wS]F~^K s~D|{c|5,?9%u~.ׇ71qVқa9P9ַWRjj~ԿI}!7!_ v vM/ =;1;qBN]kE-ɡjA-|_)_'6:&~$]txUqsL }+'B_ȉO( r̅E/G16C&dݷϡmrG7+S C1y$tZ CW y2t`"sˣ!/v~PH +Ez$o+7#PP~z(7n>CdoZ/`J#wdhMBrq'k w1m"r!,yW Bqy8#<Út|u|Yf* NBkvS.~;C_B_ʭ n&Oamh-^+W²[C^k9Z?K'fL)8S9&3Af 9!?r=|R¾X7m,&+oJr ^,Y8Hkr-j8 a?~U' S<%s]w#Ebe'5qdFL*į(vF8.넣A#MȺV ʊ,})IEG0uCR| $LzpO~KmjL)KP"Sz_ll7?S!Aա]1cd!zl;-.ȎpVr,5I! >c 1+2х2bd)Bf},2kw5w )A)KsP2fP,L,ܲ'>돏^}cgd =vSllG_^/QI7ԏJZP*~!/L)x.SIMTjTbKaԨ[-b d(Oڦ.1.6[(eb2w;Lm:2΍;o1zX BX1\v:;b̊ðvʙtmf"g6Otw#v3a {𹇉c}x /!`7삝H&+pKpcsβ )|Q"}6=?M?;>n&,n&_msm*ᵤ#ca]'%&ےw?%?7-Y9| a-| +a9,͇93 S`"#;Oܱ-tOz+y+y6mkw~<,H3ߵEɿjK֖&-K j˓V$ k+? ڪu  n*L{&,q"H PI>Owz$KkIʇ~m%8ԏǂWpN?< c8= } [X%|Oc"r.%"I>Owz.mw`32M0*GG-}L>6zO 7ke=w']~u{|-)w-?֟t{?]$lrmsw`s3p35q;pE \8)8(~#n~_g[[؂ݗ9> YO`g)w'<޽Z}3UkI~|3j)Q8xTm<՗{զ,6na+|_×|[n5R-KěA܏?U}Ͽ??1/9ESpY<,ns>ͣPjp_݋ؼdt61O;5󂳕yڼlkr7:;d>sA`fQڛٕfnOie*kP,44 +̢JmR,T2K(e8CW,"+z8#ssk+yJb&V.|nTAVb>d (&3K+RJ3-Xӆ|:OgnJ*}K`> 4QHq2΁|kvg ,};lC-ȹ9546CPg|a^`rGךffeUYD7;]0̤|Ȏdl'Sͽ9>b@~@tiycz!ϠLt|eg-1s/̦|N-?a6L-9ߗ!m]gA;O `7{.O0#P锽fz/EŽϤ )pna9p+诡Iw> ,Hދ܏>]0RX7IheQ2[*ZٔVv%CN bSzF)jSYg1+gᔳŻ: GasP JCY(3;:'<A~:SQ[NiA %/2wFϨdgVz%=zv1vUČ82(23s/3%8cvޅ {W*nֻ̎K]Nf给sN]}nM\E}p.b=rgswr>K;K\sp.E WZ{=)pu9ܺb]p82^tuى9[Ask/:bz59g 뢳un8YȃŜuZ}+҄ ;5;]ؙ=Jvk?&ܟAV9z!z>x1ZW۔ pY/郾?voH^o@g]F7b>& dq+o_GlӚ[«Ќ&oȮl@ݎ)={Bt}7t}#5' UqK^l6͡si1=vv-얫p.rβΠ?Nau)&vg$;$Y=G G0G}<y$qϲk/{mx  7 g^cN8CBh*1wlN:ӻ;ӹ"; Xz/xw }gqO_E8vV4 ~ ҫ)DB̢3)D ӫS rNA鉍>Pлb >G7a>iVv1qR*Nv,M!n26SJifu o.dF3tzj_ߛv3_q4 pJ+Hȋq2{Y9NfU8rne[ ov]׃<{9G2~gc>;jٔsT~ks_yy+|c*o!m]}ʕd1U% f_Nf9 rn692G:6p9Ŧ 6{,[FW~w?+q]YqE-šœ  y"UĹƚOY)\:֑'~'8cdy}esN)8ENGN68,O68S|7Q88t ;_=Wv/{C{ y[e"IBF/чCaì B ;?ɗ<$ {I<f?n5X3\Ve8ӕr UY*9(gK8+MUPry+gg78svu; Z=:ՍseΘӎsg+ 85 #/b=HtV΃q e[ ov]׃<{9 [׋=ɣ78㋾%_M9}46UG_ VǼm琶fI>xJ^-U*8Ze8ccKbSK!j+H ug!(Dœ ;`:ס%66|[X7} Z9Ni3vgVZs%^J勨|>ca7agḁyVYt9r.f- a%cXn6eeqRJvEt9Z34vTvd|N$LfSiSnŶk^$oJ 6cQ@P^PQl1=b,&1bnLL * ҫ4 :gH^_f^k~l}#` wPb 8A {2g&G#kqLr P `$59PY<"a`F5_g1y_?,93 ;7Ө428A ?F '8s'}ORϓ${4?שљJ¹Jmx%ֿу <5>KNS(8AQ8D~㜵/7}+B]F71]F&@tO<9H2<`GDSL5&*ݿ_BT6OR4KU e#2 gL3SF薉?PJ' S%y~19_Lx'bc?rb6=$nYsfv{F]Ti~G]3 ȿF-Q <;R%y / fDz҃jG|ww]td!o^8gM߿x#-:A1?.MRO,\3tWUNJWwV:)WWڂZ[e^z;|wTTa{?~*pP\s!!?@} qٛo;s3Jn6E!^'p&$S􏰙d|$+Y@$bIg;IoR!0 FHj?zs%;v!33pZ98p,pLDAA}~Ah7#߈|5W![_ B,KyXXѕ`@"Yؽg;r&b[;`!νA9HL9܏}vk"r~"֚eFeQMnA,Mw.%HL s8\X{>{ )8}!0)I#Lr=Fȋ:)gicN5S)'TjԲqXDb;79CWtH^* t#GA[ɸ>[i x ^&T)z 7TZ*MTG5h:) J#h@L4-Zuj]S{^۰G7, Pt:Pͫ1{P^WIU x"m(Cya?64@&i05F{BSkcai_ z@ 76JbO[98N;&~;CYx:h{oNK~P/z|KVr<.UBUzHc=3I^pL p?QMb?]ӉtCX>Uu2O-V 6uj dStm: ReЁ{t.ݻ-tcDOSH"aսt/|3;s{}`b"ca!K Tcs|Xxy[bw!BO÷5WJuanPpLB=qo8! QpA C&YN9|.v=dH#C46KSq1@ k w0#t.zC7= F/՗XSpNrH.a qX: Ⱥ߃~3^* t#Gwgc|L=O<x wGύ\ us~ѕ\-Z'xٰe' e|a+0[b]Ma.ote-"~JΠ 3=*l֟3Qq|EwDfGC>k8(tzpQ@P7&an*Fs&b>)<:1Ä|n("b.L1yq {5r"{ېF R 2H&a2DD0t'?aLplN")y 3YgȗJά*l"UsXE}+հ}[ZXWz6N?Ѓzjޫa%_`)ŰBB=|n{tۂ-X xC{xCe*8* Nl-6+?Vva~MTj) 3U99;?'!xNi8 k/ K`Okp7&QE]4QF3KQ4|y\`6.6^t $YL %p!s^LdY<˃|(@)gD e&9xj4|YJT-'J$#}LJY=6̸zf)O ώy.r!2YC*$#CJV -%RDbJCHGLHtɰaǫ|z{ҡxƊGiޔץYiZz.y{g(iQz < YGt:.gN*Dw_/*ު[AqkAް4CY[uS7OL KRzhS,^q< 2ki4Y1C1qs<8_D^Q9F R Ҥ&IcPyt>gf=Ys;ỄZPԉ~{Cg`"V%75SI_WI|S2 z0}Ao }O?־;z朵/gsk#a.M}e_{H} 7!2=D,A@ @O#ѷOpcݔ}A^[_Cc |` CRGy0C g8k/aގ8mNv|{}Ci]]lͺt"z? [߇\b/6`>zhdc/0 ӏ#؟@Na"gDdH~DTtKֿ :C_Sށ. ݪ2&,:_STk_x@%VAۋl?: 䐾14"2 UL~-S*dJ ݥLF2ZGfp><|7/-b݉ ^qMt>k8,gmޝ7X u@I0IۘUTLO Uz*ZɌFi =!{{9?lcVYb+`w=*$RD&Qґg"ˡ:"/Y2q9tPQ jjT{KSJP f\qS{Ciw{> >k5a"Lz|VAOcybFpXg/Le"vWsgCP0| ydZC%s6<@S}T}/9!]Ľw66?ȿGo=qVkZ귎:#uX6x~a>/b~_m%PQ"O b S@vTs~j/GH&l'Cy"܇cǨU%o`:cMbQm9q#&wi6k]G~!(`3!\ȁl_3f? !010P΅eJd[|r"/ ICl$H#l&c;JD,,{;qГ:B0@ojz6_}< >1/Q2xA*d@ِN.1Of6S >7_ȹBWRc,3>FS ijV\ga9+_2Us52io,0Q*`1,e FdWr~%)Z-gfi,O6dAtHC^*)Ky9b"Yyٖ؛T1R8@U䨔Fu9XTSj8R CMe1U}G=w3eJ SÔ-MWc Z[%b*Q(~ m4ibN3҅x=!>ԩS@g%҆xwx-7ݪ$TPq8щpsǤ!~_mXgUYLyIDO4cM7e麌4]p .IeG"GvL֓a*MF3ʙq|EwD&! 2փ0T/6`v~~4tUn͙b%;؋#_BÄ`Rfb39SMEPLŜ)&"W!q`1AdA:QHg 3=0Ĕ$o`zG~ g##|b:| LwXGgç a3z~F->D0}Y\W|X+d`=O҃9sς#C]grW˱+a5]^a-/r=7Y^Ylu֚5O{XnV*X S kr=﷍6>l+gwxv. ^ָ_acx9'E44ѝ&i4|y<\D1'oףpF>+@VNa3SxɌə+u" w1 !2F/y'?Bb/"brSrSmW@"$xp6x*6SdG;"@,I<ב_C qInR_>UpnB ܲaǫ|úײ{Ҥ4*@Y.)5ʮK+\v.Vv3NI(Svº1):NK?'~;H􎈔! JMp푗󆵐?Rϩ77C t9CLs{qqKTb>b,"b.L1yq {5r !@2>ũ8Bղ$`Ǻ7ɳTXnkLi'Ze:|PRB:qgr/bh[-c;َDI{H;UTwqJ|Xw+5L:RЖ{Akhܑ@ }WY{p 6vn2m֟[gOnAF{q3 ",F✧=x oc nձQMCkỶTQh0 g8k/hGvضǏFonl(͌FW>[(na# @>[}}ћv' &0zB5‰}"9L䬕b*Ídq1%oC}+Jƚ2`Or F'tHr{7ҵ{ؙ;t9`t ~]5sL |x'Y(8 9h<3zL/d{h/_=6]+^PῨ5pjl4UE.{PȓB:da?y>zqO42fѷ7W1pԃ7tPKSup'5#Gn]Asb~<:rKuėTGps%հY M56t.y#/z`{M8\ J2U: :%ЧLdÁ:Zq$HQ ݌J29,&.< b3s>J ēDl =C~x@,h !7&~n&~DC ܂Xw 댾ʿ-05)׸4fT[QunDNxpqc'!`;败{m螗wڤ@iej|秈#zݹs?.]7ܜp-@n܌GMݸuN׊65ߐ;~=7;P`o4E>pD||;כ0° :7{>M.z/ڗȽڮۅح>^͝a&UI߃G1'jjl3;gh6Mijxf'D|@ރ6^ t tgYHwrf1-CoȾ5ҹu|66v +쥒{^:cz~r8@.Epgێv ~B3g`c ݂-Ty3o"wZXYij RBj-~"bZŰs| a%aǫTf4%Ԋ;7nj.Xqsi-14fWo"D~>xH@GdLR9W{rD ?sǧ7$;e֗_4U dgu;xESS]Wθ;^kΏX,{Cqp&:Rb~ c~$eTyn͜#bTiՔrs-E3S*efEb0+EfW屹mvWJqpu,Bcv%sќp r̷4%s|x/ (͔:<qJpZ#6( 'fOEe3inJURMk+J]R_4F2!k-Woe%Z2,vGX nIݖ E6#C..e 냴J?YUWzR|vc hNJ'&:mˤXjGhc'pJ.Z4r.} *J;wVK j㯖2D8O$L"4U&kE|N T}9$7 [ N1,fŻ^?V>,2݇(3{`|+kʇ> 3m8vR>S ϥ B2V _l Y{`#lf3ېoGo'8<ǐD4g9w."Mf>s$BĒc,ƒpZ܅8F|?<\g/U;6{ft s&p#CWM/{>|-lz~ #lDwS%?q'lmf6Sĸ"M܈ ='-o`5WrXRfd1bg!/$EYERXaaWoe+,y͒!by$ , R'5-#h "< 2'MK,I归{)(=R+e3vZRR]mqRZ*,JK4hL7kER"a:7q{<5ߠ.i{Bp!hm>^͝•.ZbxЙVrG<-wrOڐmK"< ٷS,'Kp{ȜqVZ),5.t68(d^ ^B7t 7a8fozpbH%'td"ݙĄM"rL.Sa:m#Zۈ0 AgG`sΤ Xб#eq8#:{U%z?r?|;NݺS?CL>OD<6xVft婬dHY d|eɕ!ٖlܒn>g x`8WW ϡ\~ӉuLȷ<0-+a9,c1q Es :gr>>syV9L9|z6B> Y0%x*fc3b].czWZ& F 9;wPbhO%J~lܗC҃`5;a;??& +erRn=csp;~w /2w.k@z C%<{ǠʹNYMo ~Gep\萹Y18n*'̎rNPMNk@m#c8΍N(Bm%l7QΘ'qĝ#;d7d"4'W8w3B~yx Lr[L %>>҆q/~'z2Qs bxo'1a^v2܂߰^AKYD x+ >(~77dv}{1t1*ɬEj#(>B5Ax^ֿV.bfwRN~V o=tWsn%6WhsɷLz 'f~+v_GfҥcZWwQj֝[A'n)t%хGtܡ+7Y_+s(#‹Dw,k=ޏ!荖T*U#wL"J3̥CTj!.bOSYS+6C\uXGK&4{{ɧy1z%ħ'>kW+2 ^  A/0nicGpowINmGUbx.c{n+zngօUXm][ܸqWsnBfVb6:9ްxۍ3> lGo|{K8:П,5,S7N#iqo&{ZMo7nqZZq{2 XΌlM$O={dZQY t[¨M(ѬGdJorf0gߞ)6؝[aW Y{ wbt#rkNɷ9y`Ӆ8\=ؕ{u 8ѱb﫻-d^ &:L|0SЋB,myI_?5,z8D6L8h<*x_qt嬋 ~TCO~}L6卝nT;1RuK "^{d G[o1J鱖pdLe 3 C`0 d2}f2B\TXFR0 ø@iv ^;؆0#w8daΙIؙF-Qi9Uُ@>s--xVɝSޡF3+yޫ}6Yْ=wdnr.j2"XOp C<=M_?}DyK _Ref4091662546Dd B  S A?  2mDu뤛bk|v`!tmDu뤛bk  h BxkA&mM(XXCrT0Jj H."h=ԃrѿ@ T=fg֝mCgc_a-V"B0,9yTN }":+!  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmopqrstuvwxyz{|}~%                 ! " # e $ & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d h i j k l m n o p q r s t u v w x y z { | } ~  Root Entry+ F0DO25' 'Data nWordDocument*bObjectPool-*Y&25'_879767682 F*Y& Z&Ole PIC LMETA (  !"#%(+-./0123456789:;<=>?@ABCEHIJKNQRSTWZ[\]^_`adghiklmnoprstuvwxz{|}~L  Q  .1   &` + & MathTypepSymbol-2 *{Symbol-2 }Symbol-2 [Symbol-2 ]Symbol-2 {Symbol-2  }Times New Roman+- 2 FR 2 A 2 DPSymbol- 2 = & "System-CompObj ZObjInfo Equation Native |_879767681 FP&& FMicrosoft Equation 2.0 DS Equation Equation.2`VWUd WU FR{}=A[]DP{}LgOle PIC  LMETA CompObj$ZgP U .1  @&` & MathType-XTimes New RomanD- 2 @dA 2 {FR 2  DP Times New Roman- 2 @Nij>> 2 {i>`Times New RomanD- 2  j,Symbol- 2 @3=Symbol- 2 { 2  & "System- FMicrosoft Equation 2.0 DS Equation Equation.2`gX'Sd 'S  A ij =ObjInfo&Equation Native '|_946039258Fp#&p#&Ole )FR i DP j2 L  R  .1   @& & MathTypeSymbol-2 /[Symbol-2 /PIC      *L META$%&'()*+,-./0 56789,@CompObjFGHIJKLMNOPUVWXYDf`ObjInfofghijklmnopuvwxyF]Times New RomanTA- 2 ASymbol- 2 = 2  2  2 1 2  2  2  2 m 2 m 2 1m 2 m 2 m 2 mTimes New RomanTA- 2 A 2 8A 2 A 2 A 2 1A 2 pA 2 iA 2 iA 2 ibA Times New Roman- 2 np 2 np 2 im 2 i m 2 iLmnp Times New RomanTA- 2 11pp 2  12pp 2 c1p 2 21pp 2  22pp 2 _2p 2 i1p 2 i 2pMT Extra- 2 j K 2 j K 2 )5M~ 2 )M~ 2 ) M~ 2 ij K & "System- FMicrosoft Equation 3.0 DS Equation Equation.39q̓ A[]=Equation Native G _946041544FpX&pX&Ole LCompObjMfA 11 A 12 & A 1n A 21 A 22 & A 2n """A m1 A m2 & A mn [] FMicrosoft Equation 3.0 DS Equation Equation.39qObjInfo     O Equation Native)*+,-./0 56789P<@_946042288GHIJKLMNOP# F&0&^_`Oledefghijklmnop uvwxyU  A=a ij []a ij =1akoGimabridi,j()0ako nema brida{} FMicrosoft Equation 3.0 DS Equation Equation.39qCompObj!VfObjInfo"XEquation Native Y_1019292310% F&PV&} x A=a jk []a jk =+1ako grana k izlazi iz  vora j"1 ako grana k ulazi u  vor j0ako grana k ne dira  vor j{} FMicrosoft Excel WorksheetBiff8Excel.Sheet.89qOh+'0@HT` x  ʂ"50FLB^wo7E.'|eʵnpeU;ՙkp{&gDyN^qz }\I?UF?,|>3y2yG57o,/}fekg#vG|qC >E_7{q/$~w(h-o91f'yh*!H_q%k5*| L ,CkhrsE*?kur欧{}7OO埝{'N2{Dsz.`w~OهyZ[5ߴ%{c2ߋ|͗e~oq!~=|ˁ6t)Qw~JֺflωM=d?ި;Cg3ٯS;m#ō\~F~isRT=׻ѻkA^, 7L:~!w]ѿ YH|JyTa= "oWޖu[Ш. =ozhQ^`+3iJߜs92  Wc"FZ' 2g$q8MG$ EJG/]/۽аl ~@UHYn>`r 2 :MLl>Ooɑ4JPyWOaύֆ\{ns8X'Un$}(rs -Wz|p|q%3i6|܏/2 jO΍>[sV&[. NG|f\ɩ_NjP3j`&q5dc@ 8}Y틮HoC %$linkane slike\izvrsavanje akcije.wmf : c nJ? linkane slike\izvrsavanje akcije.wmfDfK:M$PP*linkane slike\UML klasifikacija akcija.wmf ; S tVlinkane slike\UML klasifikacija akcija.wmfDf2/hh)linkane slike\poziv programskog alata.wmf < c xT? linkane slike\poziv programskog alata.wmfDf@2"'linkane slike\UML klasifikacija SPA.wmf = S nPlinkane slike\UML klasifikacija SPA.wmf}DyK _Ref409233023}DyK _Ref409236024}DyK _Ref409251031DfA@linkane slike\graf relacije.wmf > c d@? linkane slike\graf relacije.wmf}DyK _Ref409667260}DyK _Ref409180606}DyK _Ref409180678}DyK _Ref409180871}DyK _Ref409180873}DyK _Ref409239013}DyK _Ref409180871}DyK _Ref409180873}DyK _Ref409180678}DyK _Ref409173569}DyK _Ref409173839}DyK _Ref409173842}DyK _Ref409239013}DyK _Ref409180871}DyK _Ref409180873}DyK _Ref409180678Dd#k \[x ? c TA 0slike\coupled tasks.wmf 2\V˵/?vlVisv`!\V˵/?vlV & $Xx tT73ߏ@YL/1wCbYa kϐNYe8CJ%KF8O t70x6 ! a~ mpODC b8H`K'BHV:3u rG݁ts۵ɹ: 9Oֹ@sg]]t'.]Hr.]̥Rrwݍ{\{poݓ2{qݛaÃt_Sg?߭^!zaPp# a 5<{'dxs< OӘxϚ #%2b{1 Me4k{ k5 "sy|jr9\\.FN K2/rr JJ**݇bO+Ju%{_(B <81i%jl%jmjnjo9jp9j/eͥѥ%ŨEP Q PQEA/FOޘy 2=3&z c蹗{/ГSћ3է)LFOOGG`Y?,!R7]7hFqD,k@?(b ;.~wýb FM4Ll .%=$ү`+#XƉj/v&]􈨡߈C4I~, V'a8BOZQzFqzV4Es,i煓_.pE[hX OēD~L򣢈#QE)O]yDw+zѓG2%zDo~F><\ я?| wp?N1(PA)@1-P9!r0퐅ge³3C:![[*bLdl"XCr3֔cXcvEriE"W.9 C.[!mK%r#^{x7-Gbc{HKžn{ƞn|B!1npsp5AyP{^Ԡ AmDDf[vPtkv$j j-j> =pz!=!xJzfNz=zDO%Rcp+z. DofCCtFOB1K9Ҝg'qYUk%۷P?X; tj#9!Hm"L K Q[%RUpZAQj'S(ZP¾=RGj?ݬP:HIWI#dZduRT=ݢS:'Vu:8Ci,ݦA#`prrr[[h6km6RlCV. @CpHsUqr\pNrnn8iJ'linkane slike\SHEMA REFERENCI CVORA.wmf @ s z%P? linkane slike\SHEMA REFERENCI CVORA.wmf!}DyK _Ref409176535}DOle      b CompObj&'()*+,-./0$'56789cf@ObjInfoFGHIJKLMNOPUVWXYe`Workbookfghijklmnop&(uvwxyg /:    Ba==$,8X1Arial1Arial1Arial1Arial1Arial1Arial"Kn"\ #,##0;\-"Kn"\ #,##0#"Kn"\ #,##0;[Red]\-"Kn"\ #,##0$"Kn"\ #,##0.00;\-"Kn"\ #,##0.00)$"Kn"\ #,##0.00;[Red]\-"Kn"\ #,##0.00>*9_-"Kn"\ * #,##0_-;\-"Kn"\ * #,##0_-;_-"Kn"\ * "-"_-;_-@_-,)'_-* #,##0_-;\-* #,##0_-;_-* "-"_-;_-@_-F,A_-"Kn"\ * #,##0.00_-;\-"Kn"\ * #,##0.00_-;_-"Kn"\ * "-"??_-;_-@_-4+/_-* #,##0.00_-;\-* #,##0.00_-;_-* "-"??_-;_-@_-                + ) , *  " "   "8 "8@@ "8@ "8  @ "8@ "8 "8 @ "8 "8 "8""@ @  Sheet1]8Sheet2F9Sheet3ZR-13  @@ <l ABCDEFGHIJKLX  st,yle:&Color:&Weight:Sha&dow&Round cornersFillA&utomaticNon&eC]|p0 &Styor:ght:adSe:Wi&dt(Н0Font:F&:Effectri&kethroughSup&erstSu&bscriptBtlinBazp0ground:Au&to scalePreview Text ament&HoS04t003w  /AEI M P V V e kwy@       !N] *`%TL +  BCDELF$ @> /AEI M P V V e kwy@      !] +`4'TL ,  BCDELF$ @> /AEI M P V V e kwy@       z ] ,`d)rjB - 0D@ C]-`9rjB . 0D@].`LrjB / 0D@z]/``rjB 0 0D@  z]0`l>@   dMbP?_*+%"??U>@   dMbP?_*+%"??U>@ SummaryInformation   ()f DocumentSummaryInformation/0856789j@1TableEFGHIJKLMNOPUVWXY T`SummaryInformationklmnop(,uvwxyqnpnpMicrosoft Excel@o{ @?4՜.+,D՜.+, PXd lt| fsbj Sheet1Sheet2Sheet3  Worksheets 6> _PID_GUIDAN{75581BF0-1FFB-11D4-94DE-0000F8D072F5}Oh+'0 ( D P \ ht| PREDGOVOR RED Maja i Nevenoajaaja Normal.dotn Maja i Neveno65aMicrosoft Word 8.0@,H@Nv@{=@# EyK _Ref492090505}DyK _Ref409176645Dfrlinkane slike\cvor plana.wmf A c ^:? linkane slike\cvor plana.wmf" Df&{%$linkane slike\vrste veza cvorova.wmf B s t|J? linkane slike\vrste veza cvorova.wmf#}DyK _Ref409193216Df$* linkane slike\and cvor plana.wmf C c fB? linkane slike\and cvor plana.wmf$}DyK _Ref409146578}DyK _Ref409158676}DyK _Ref409191431'Df 060linkane slike\PROGRAMSKE KOMPONENETE SUSTAVA.wmf D c b? linkane slike\PROGRAMSKE KOMPONENETE SUSTAVA.wmf%}DyK _Ref409171730}DyK _Ref409186113}DyK _Ref409159332}DyK _Ref409257866}DyK _Ref409174182Df+0-linkane slike\POET primjer rel zad 1visio.gif  S z\linkane slike\POET primjer rel zad 1visio.gif& DfbJR(linkane slike\POET primjer rel zad 2.gif  S pRlinkane slike\POET primjer rel zad 2.gif' DfcIO(linkane slike\POET primjer rel zad 3.gif  S pRlinkane slike\POET primjer rel zad 3.gif(Df linkane slike\ROSE model1.wmf  c `q<linkane slike\ROSE model1.wmf)}DyK _Ref409143054}DyK _Ref409195927}DyK _Ref409147518}DyK _Ref409147518}DyK _Ref409151481Df2f"linkane slike\ROSE asocijacije.wmf  S dFlinkane slike\ROSE asocijacije.wmf*}DyK _Ref409152166}DyK _Ref409193216}DyK _Ref409436808}DyK _Ref409184075Df1N&linkane slike\UML PP i DSM matrice.wmf  s x Nlinkane slike\UML PP i DSM matrice.wmf+-Df/m%4linkane slike\POET matrica zavisnosti parametara.wmf E S jlinkane slike\POET matrica zavisnosti parametara.wmf,}DyK _Ref409152166'Df8j!^*linkane slike\UML relacije pripadnosti.wmf F   Vlinkane slike\UML relacije pripadnosti.wmf-}DyK _Ref409437152Dfx.&linkane slike\POET operandi izraza.gif G S lNlinkane slike\POET operandi izraza.gif.Df25*k#&linkane slike\UML reference izraza.wmf H ~n  Nlinkane slike\UML reference izraza.wmf/}DyK _Ref409155949Dfs%linkane slike\ROSE prikaz procesa.wmf d S jLlinkane slike\ROSE prikaz procesa.wmf0}DyK _Ref409171730$Dfk,h("-linkane slike\UML klase cvorova i bridova.wmf J s ^\linkane slike\UML klase cvorova i bridova.wmf0}DyK _Ref409144297}DyK _Ref409145340Df+M'#linkane slike\UML matrice plana.wmf K S fHlinkane slike\UML matrice plana.wmf2}DyK _Ref409191406}DyK _Ref409152108Dfm.j$'linkane slike\UML asocijacije cvora.wmf L s zPlinkane slike\UML asocijacije cvora.wmf3Df* 7Mlinkane slike\ROTOR EM vsd.wmf M s h1>linkane slike\ROTOR EM vsd.wmf4DfFjslinkane slike\primjer plana.wmf N c d@linkane slike\primjer plana.wmf5}DyK _Ref409229770}DyK _Ref409181248}DyK _Ref409244619}DyK _Ref409269474}DyK _Ref409265815}DyK _Ref409265961}DyK _Ref409269971}DyK _Ref409270235}DyK _Ref409270337}DyK _Ref409687133}DyK _Ref409875234DD8 [:@: Normal$a$CJ_HmH sH tH n@n Heading 10$$$ & FLQ@&^`Qa$5CJ$OJQJmHsHu\@\ Heading 2'$ & FLBXh@&^B`5CJOJQJR@R Heading 3$$ & FL@&a$5CJOJQJH@1H Heading 4 & FL^@&^^`6CJDD Heading 5 & FL<@& CJOJQJjj Heading 6#$$ & FLdP @&a$!5;CJKHOJQJmHnHuDD Heading 7 & FL<@& CJOJQJHH Heading 8 & FL<@&6CJOJQJH H Heading 9 & FL<@&6CJOJQJ<A@< Default Paragraph Font0@0 TOC 1$xxa$5*@* TOC 2 ^CJ.@. TOC 3 ^6CJ.O". natuknice  & F8O28 literatura  & F<CJ4ZB4 Plain Text CJOJQJ,@R, Header  9r , @b, Footer  9r &)@q& Page Number$O$ body ``O` MASTER NASLOVI (BEZ OBROJ,) $ha$ CJ OJQJ&& TOC 4 ^&& TOC 5 ^&& TOC 6 ^&& TOC 7 ^&& TOC 8 ^&& TOC 9 ^O natuk,s brojevimat & F:x>T)^`:DOD obicne natuknice! & F 8"@8 Caption"$xxa$5CJO2 nabrojiv#$ & FS>T^S`a$H#@H Table of Figures$ ^` CJ(U@Q( Hyperlink>*B*8&@a8 Footnote ReferenceH*&Or& fusnota'CJBBB Body Text (7`7OJQJmH sH uDD Slika)$a$CJOJQJmH sH uP@P Footnote Text *d$CJOJQJmH sH uL Date+@@ D2000Text,$a$CJ_HmH sH tH hOh naslov koji nije heading-7<<^7` 6OJQJRR podnaslov koji nije heading .^>> Body /dCJOJQJmH sH u8Y8 Document Map0-D OJ QJ J"J Definition Term1$a$hmHsHtH uRR Definition List2$h^ha$hmHsHtH uv2v Preformatted.3$ # ~= z9!v%a$CJOJQJhmHsHtH u:P@B: Body Text 24x 6mHsHDORD bibliografija5$a$CJmHsHu>V@a> FollowedHyperlink >*B* ph&r&double7dhc11      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~1  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~1  \o:8gJ.8U_4K14hAk=g !! !!!!!!!! !!!!!!!!! ! ! ! ! !!!!!!!!!!!!!!!!!!! !!!"!#!$!%!&!'!(!)!*!+!,!-!.!/!0!1!2!3!4!5!6!7!8!9!:!;!<!=!>!?!@!A!B!C!D!E!F!G!H!I!J!K!L!M!N!O!P!Q!R!S!T!U!V!W!X!Y!Z![!\!]!^!_!`!a!b!c!d!e!f!g!h!i!j!k!l!m!n!o!p!q!r!s!t!u!v!w!x!y!z!{!|!}!~!!!        !  !!!!!!!!!!!!!!!?aJ#i3>CP\jyCq [#,)^8FS#aho9zƒДzؤ3$7 <'+5:8YC6MW#eq%gAs\;eJWL %,8AOQ[-imt\~yّV7H%Bu!/h!,9BK@Xeq}}řֱ `cn%3k@MYfhpvvA{ =I[ A)L2.8=E TU_8kwfAFP u4K1 Af5 # d > fU/]5w$KE1 !"#G$%&'(\)*x+),-"./c0C123456789:;<=P>m?@\AByCDE!FFGH=IJKLMN5OP1QR#ST`UVWXKYZ[\R]^_`abAcdef3gh2ijBkl mnto pqprstRuv0wx]y9z{g|9}~i*[ nXf?NR]6 <Ud_{AAOOOOLLLLLL~~~~~~//////111114\p$'*J.39l>CINOTY^d2kqr(~^*r(N:3F 8ZDZx7:rn P XDrf^Fj{qhl nESv~# B z p K hj xr 2{   tK { :     !"&)-.1247:>@BDGI]lmprtvw}$%*47:<G`b& pJ*:9DTldtpn?LgvpT J#l<~2"8DP}0*778B8d8~8888889,9B9Z9^::;&;P;r;;;@@zAAA^[&  O}rx6Xz :K2$"lRqN&/:FQ\fs~v5BWivVJV$|+7J]h|zEEF8FjFFFGRSTZZdq~ܲ - f- - . |K u } ~ Χ L  H    . < /> i Zr fr ~r r r r r r r s z H  1 D F 2H H ^K   m  0 UE Y k X :   #%'*,/368;<?CEHJKLNOPQRSTUVWYZ[\^_`acdefghiknqsxy{|~    !#&')+,-./012568;=?@BCDEHJLNPRTVXZ\^_c "L2zDZn|(h4XS֌<88.9;N$Tȹv0_^6P|Ș@V, Fd0. T~ Χ | Lh p \ ( #= `r ^y r D+ E ~e : u  V o' N: M ` : $(+059=AFMXbjouz  "(39>AFIKMOQSUWY[]a -IKe 7 9 y  1 4 W s v   8 T W  0 3 e  3 6 z /KN%ADc,/Kgj B^a7:Vru@\_">AC_b?[^} '*a}2NQ,HK?[^!$n-17;a} (,qB^b}  ! = A b ~ !!Z!v!z!!!!""!"S"o"s"""""##(#D#H#J####$$f$$$$$$.%J%M%%%%%%%+&G&J&&&&&&&8'T'W'{''''''A(](`((((())P)l)o)))).*J*M***** + +Y+u+x++++J,f,i,,,,"->-A----- . .Q.m.p....//K/N////00!0L0h0k0000 1%1(1U1q1t1111122d222222H3d3g333344 4W4s4w4444%5A5E5555566R6n6r66667-717j777777788^8z8~8888899Z9v9z9999:,:0:2:D:W:::::;;l;;;;;;<;<><<<<<<<:=V=Z====>8><>}>>>>^__5`P`T`\awa{a!bC9>[v{~nٹ޹n!<AE`eoD_d"Grwzs+0[v{o#f 49Wrw05GrwAFRmr ',i!798SX :?7<sZ"+"0"["v"{"+$F$K$9(d(i(m(((((( )%)*)5A`AeArNNNLTwT|TVWW!WLWQWTWWWWWWWWWWXX XKXPXSX~XXXXXYZ Z#adafanaaa]bbb#y>yCyFyayfyz0z5z{,{1{-|H|M|}0}5}~N~P~Y~o~q~~~~؀"8:g!&jƒ%'QlqQ|̌ -2&)Zuz֓,GLΙÚȚ2MR_suPdf˧ߧ"&AF %*Idiź2MR-2Gbg $),GLOjokcCns[-2    2 5       AEHswzy      w!!!!!!p%%%(2(5((((H)^)a)R,j,l,r111333I6d6i6:0:5:H.H3HRJJJJJJJKK+KVK[KdKzK}KKKKMMMPQQ"Q8Q;QkQQQ[[[```a3a8aaaaiii>kYk_kk lll1l7lUvpvvvyzz"z=zCzMOWmpƂ҃nAWrxCGKv{,25PVYtz}›ś>Y]15bɠ̠6:Qlpԩ֩ީGbgĵɵؼGMپ l*U[bdl  9?B]cf,2y      s''''''899%9;9>9eAAAAAA:xUxYxysyuy}yyy9TZ]x~yՋ׋ߋŒ 69A\beǜۧ͜˸͸ոgiq24<RU%su}$jlt069TZw+AD/EH!$?E7=@[am8NQ| !!p!!!1&L&R&&&&&&&& ''A(\(a(000444@6[6a6;;;CCC=LXL^L\\\]]]4`O`U`'bBbFb^fyffkl lnoooooppprrrssszzze4OS4:'BHLgm*EKZuy06ɢ 3NT.FHjA\`i26E`d+1:@D_ei@XZACKadw7;Tot" e g n      QlrS0008 99zaaahpppppp|||$)/*EKC DZ]޷Ź߽2MQB]a  #&&AGKfl58BDLbe %(q2C^bego 14OW$?Efhp&AIMhpIbHJRhkp%%%%%%777VVVVVV1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%tttttttC tC tC ttC C C tC C C  99  :::C C C : :  tCC t tC C Ct C C C  ttCt Ct tC C tttC C C Ct tC Ct tC ttCt t  t     t tt  ttttt tttttt  C CC C tttC tttCt CtCt t tCt tCt  C tCt Ct Ct tCt tCt ttCt tttCt tttCt C Ct ttt tt 9>AHLOwILtA{~4!!tt :O2$(d_z*|(B2$Ibqȓm2$,^wϸiNee2$,^wϸiNee@(  \   S  A ?m"   3 N<linkane slike\plan mreza .wmf6"bB   c $jJ?/"  c l==>Hlinkane slike\incidence digraph.wmf"bB  c $jJ?"B S  ?<'q'((/1 :10 T O0t q T)67t  4  _Hlt409234025 _Hlt409163651 _Ref409265815 _Toc409163438 _Hlt409171773 _Toc409163439 _Toc409163440 _Toc409163441 _Toc409163442 _Hlt409247558 _Hlt409247880 _Hlt409149234 _Toc409163443 _Toc409163591 _Ref409265961 _Toc409163444 _Toc409163445 _Hlt409169479 _Toc409163592 _Toc409163446 _Toc409163447 _Hlt409263747 _Hlt409171138 _Hlt409270115 _Hlt409169525 _Toc409163593 _Ref409269971 _Toc409163448 _Toc350860864 _Toc350936785 _Toc351888039 _Toc353094962 _Toc353776296 _Toc354831310 _Toc355649867 _Toc356414594 _Toc356494173 _Toc357365288 _Toc359471740 _Toc360355996 _Toc365362466 _Toc366999875 _Toc367509686 _Toc368474923 _Toc409163449 _Toc353094963 _Toc353776297 _Toc354831312 _Toc355649869 _Toc356414596 _Toc356494175 _Toc357365290 _Toc359471742 _Toc360355998 _Toc365362468 _Toc366999877 _Toc367509688 _Toc368474925 _Toc409163450 _Hlt409265070 _Hlt409265925 _Toc409163594 _Toc354831314 _Toc355649871 _Toc356414598 _Toc356494177 _Toc357365292 _Toc359471744 _Toc360356000 _Toc365362470 _Toc366999879 _Toc367509690 _Toc368474927 _Toc409163451 _Toc409163595 _Toc354831317 _Toc355649872 _Toc356414599 _Toc356494178 _Toc357365293 _Toc359471745 _Toc360356001 _Toc365362471 _Toc366999880 _Toc367509691 _Toc368474928 _Ref409178290 _Toc409163452 _Toc354831316 _Toc355649873 _Toc356414600 _Toc356494179 _Toc357365294 _Toc359471746 _Toc360356002 _Toc365362472 _Toc366999881 _Toc367509692 _Toc368474929 _Toc409163453 _Toc354831318 _Toc355649874 _Toc356414601 _Toc356494180 _Toc357365295 _Toc359471747 _Toc360356003 _Toc365362473 _Toc366999882 _Toc367509693 _Toc368474930 _Toc409163454 _Hlt409268768 _Toc409163455 _Toc409163596 _Toc409163456 _Ref409270235 _Toc409163457 _Toc409163458 _Toc409163459 _Toc409163597 _Toc409163598 _Toc354831311 _Toc355649868 _Toc356414595 _Toc356494174 _Toc357365289 _Toc359471741 _Toc360355997 _Toc365362467 _Toc366999876 _Toc367509687 _Toc368474924 _Toc409163460 _Toc409163599 _Hlt409859666 _Toc409163461 _Hlt409160789 _Hlt409859814 _Ref341367868 _Toc341848364 _Toc409163600 _Toc409163601 _Toc409163462 _Ref330632891 _Toc341848366 _Ref342072000 _Toc409163602 _Toc341848195 _Toc342897959 _Toc343169328 _Toc341848197 _Toc342897961 _Toc343169330 _Toc409163463 _Toc409163464 _Toc392488649 _Toc409163465 _Hlt409250413 _Hlt409169907 _Toc392488650 _Ref409248534 _Hlt409271586 _Toc409163466 _Hlt409254741 _Toc347138999 _Toc351888041 _Toc353094965 _Toc353776299 _Toc354831321 _Toc355649877 _Toc356414604 _Toc356494183 _Toc357365301 _Toc359471753 _Toc360356009 _Toc365362479 _Toc366999888 _Toc367509699 _Toc368474936 _Toc409163467 _Toc347139000 _Toc351888042 _Toc353094966 _Toc353776300 _Toc354831322 _Toc355649878 _Toc356414609 _Toc356494188 _Toc357365306 _Toc359471758 _Toc360356014 _Toc365362484 _Toc366999893 _Toc367509704 _Toc368474941 _Ref409248357 _Toc409163468 _Toc357365307 _Toc359471759 _Toc360356015 _Toc365362485 _Toc366999894 _Toc367509705 _Toc368474942 _Ref409248359 _Toc409163469 _Ref409176535 _Hlt409250572 _Toc409163470 _Hlt409867883 _Toc409163603 _Toc409163604 _Toc409163605 _Ref409145340 _Toc409163471 _Toc409163606 _Toc409163607 _Ref409186342 _Ref409186352 _Toc409163653 _Ref492090505 _Toc409163472 _Ref409270337 _Toc409163473 _Toc409163474 _Toc409163475 _Toc409163608 _Hlt409190170 _Toc409163609 _Toc409163476 _Toc409163477 _Hlt409667215 _Toc409163478 _Hlt409694978 _Toc409163479 _Toc409163610 _Ref409687133 _Toc409163480 _Toc409163481 _Toc409163611 _Toc409163482 _Hlt409236964 _Toc409163612 _Toc409163613 _Toc409163483 _Hlt409183683 _Toc409163484 _Toc409163614 _Ref409687239 _Toc409163485 _Toc409163654 _Ref409143054 _Toc409163486 _Toc409163487 _Toc409163615 _Toc409163616 _Toc409163488 _Hlt409187898 _Ref409195927 _Hlt409195941 _Toc409163617 _Toc409163618 _Toc409163489 _Toc409163619 _Toc409163620 _Toc409163621 _Toc409163490 _Hlt409240593 _Ref409166554 _Toc409163491 _Toc409163622 _Toc409163623 _Toc409163492 _Toc409163624 _Toc409163625 _Toc409163493 _Toc409163494 _Ref409177624 _Hlt409191323 _Ref409147518 _Toc409163495 _Toc409163626 _Ref409184075 _Hlt409241984 _Toc409163496 _Toc409163627 _Toc409163628 _Ref409174182 _Hlt409191682 _Toc409163497 _Toc409163655 _Ref409193216 _Toc409163498 _Toc409163629 _Toc409163630 _Toc409163631 _Ref409436808 _Hlt409243043 _Toc409163499 _Toc409163656 _Toc409163657 _Ref409152166 _Toc409163500 _Ref409144035 _Ref409144061 _Hlt409144094 _Toc409163658 _Ref409437152 _Toc409163501 _Ref409172047 _Hlt409247383 _Toc409163502 _Toc409163503 _Ref409157237 _Hlt409248260 _Toc409163504 _Hlt409247438 _Ref409155949 _Hlt409243299 _Toc409163505 _Hlt409247595 _Hlt409271585 _Toc409163506 _Toc409163659 _Toc409163507 _Ref409191431 _Hlt409253626 _Toc409163508 _Toc409163660 _Toc409163661 _Ref409191406 _Hlt409191451 _Toc409163632 _Ref409152108 _Ref409144297 _Hlt409250569 _Toc409163633 _Toc409163634 _Toc409163509 _Toc409163510 _Ref409171730 _Toc409163511 _Toc409163512 _Toc409163635 _Toc409163513 _Toc409163514 _Toc409163515 _Ref409192688 _Toc409163516 _Ref409151481 _Toc409163517 _Toc409163518 _Toc409163519 _Toc409163520 _Toc409163521 _Toc409163522 _Toc409163523 _Toc409163636 _Hlt409163652 _Toc409163637 _Toc409163524 _Toc409163638 _Toc409163525 _Toc409163526 _Toc409163639 _Toc409163662 _Toc409163640 _Toc409163641 _Toc409163642 _Toc409163527 _Toc409163643 _Toc409163644 _Ref409147524 _Toc409163528 _Toc409163645 _Toc409163646 _Toc409163647 _Toc409163648 _Toc409163529 _Toc409163649 _Toc409163650 _Toc409163663 _Ref409875234 _Toc409163530 _Ref409167827 _Hlt409168039 _Ref409182852 _Ref409171766 _Hlt409171779 _Hlt409171742 _Ref409173045 _Hlt409247940 _Hlt409170046 _Hlt409172954 _Ref409136948 _Ref409238939 _Hlt409238985 _Ref409239013 _Hlt409239058 _Ref409257866 _Hlt409247443 _Ref409244619 _Hlt409247883 _Ref409257371 _Ref409269474 _Hlt409247561 _Ref409246831 _Hlt409247825 _Ref409246833 _Ref409247530 _Hlt409247556 _Ref409247532 _Hlt409247833 _Hlt409169437 _Ref409142339 _Hlt409151860 _Ref409176645 _Hlt409169420 _Ref409258193 _Hlt409258164 _Ref409149369 _Ref409151822 _Hlt409151897 _Hlt409243084 _Hlt409151796 _Ref409151825 _Hlt409169492 _Ref409151916 _Hlt409183415 _Ref409149372 _Hlt409261462 _Ref409149374 _Hlt409149328 _Ref409152505 _Ref409152507 _Hlt409261451 _Hlt409152486 _Ref409152937 _Ref409233023 _Hlt409261434 _Ref409261642 _Ref409152939 _Hlt409152968 _Hlt409152748 _Ref409263740 _Hlt409142386 _Ref409263479 _Hlt409263582 _Ref409263517 _Hlt409172998 _Ref409263538 _Ref409265645 _Ref409265701 _Ref409135683 _Hlt409266127 _Ref409265763 _Ref409266006 _Hlt409266117 _Ref409266015 _Hlt409266123 _Ref409266591 _Hlt409266648 _Ref409266596 _Hlt409266762 _Ref409266601 _Hlt409266813 _Ref409266607 _Ref409266609 _Hlt409266826 _Ref409266612 _Hlt409266836 _Hlt409266559 _Ref409269148 _Hlt409172861 _Ref409269154 _Hlt409269308 _Ref409269156 _Hlt409269327 _Ref409269158 _Hlt409269345 _Ref409269161 _Hlt409269357 _Hlt409267137 _Ref409269853 _Ref409269858 _Hlt409270022 _Ref409269862 _Hlt409270055 _Ref409269865 _Hlt409169517 _Ref409269868 _Hlt409270118 _Ref409269871 _Hlt409269829 _Ref409270389 _Ref409270391 _Hlt409270469 _Ref409270393 _Hlt409270479 _Ref409270395 _Hlt409270484 _Ref409183564 _Hlt409263517 _Hlt409270354 _Ref409171901 _Ref409171903 _Hlt409265324 _Hlt409265723 _Hlt409171880 _Ref409493420 _Hlt409859446 _Ref409496503 _Hlt409266053 _Ref409173935 _Hlt409236839 _Hlt409173920 _Hlt409268410 _Ref409181231 _Ref409172895 _Hlt409180929 _Ref409180953 _Hlt409265894 _Hlt409265889 _Hlt409182171 _Ref409183300 _Ref409183302 _Ref409183304 _Hlt409169709 _Ref409183306 _Hlt409272689 _Ref409183310 _Ref409183311 _Hlt409169703 _Hlt409858837 _Hlt409183208 _Ref409233026 _Ref409182189 _Hlt409273564 _Ref409182190 _Hlt409160794 _Ref409160783 _Hlt409160799 _Ref409163449 _Hlt409860051 _Ref409182183 _Hlt409273733 _Ref409166254 _Hlt409273666 _Hlt409273659 _Hlt409860902 _Ref409251025 _Hlt409254521 _Ref409233354 _Hlt409233331 _Hlt409273419 _Hlt409176626 _Hlt409251485 _Ref409257741 _Hlt409862785 _Ref409264175 _Ref409266202 _Hlt409266260 _Ref409266205 _Hlt409183817 _Hlt409266180 _Ref409178545 _Hlt409183708 _Hlt409250255 _Hlt409251011 _Ref409251518 _Hlt409267627 _Ref409268442 _Ref409252999 _Ref409254725 _Hlt409254739 _Ref409254727 _Ref409254728 _Ref409254730 _Hlt409254743 _Ref409254996 _Hlt409169935 _Hlt409254982 _Ref409258111 _Hlt409268399 _Ref409268568 _Hlt409253074 _Hlt409169682 _Ref409268797 _Hlt409867815 _Ref409269114 _Hlt409260355 _Ref409269297 _Hlt409260277 _Hlt409400387 _Ref409400416 _Ref409403626 _Hlt409407697 _Ref409407742 _Hlt409226807 _Ref409269300 _Hlt409269596 _Ref409231419 _Hlt409170008 _Ref409269582 _Hlt409192531 _Ref409192567 _Hlt409192578 _Ref409236024 _Hlt485704953 _Ref409299733 _Hlt409171989 _Hlt409170061 _Hlt409264161 _Ref409661447 _Ref409667260 _Hlt409693703 _Hlt409667246 _Hlt409238902 _Ref409695135 _Hlt409695180 _Ref409695137 _Hlt409695186 _Ref409695139 _Hlt409239021 _Ref409695140 _Hlt409259580 _Hlt409695103 _Hlt409260044 _Ref409260045 _Hlt409260047 _Ref409262200 _Hlt409262511 _Ref409256364 _Hlt409256377 _Ref409236648 _Hlt409240512 _Ref409180678 _Hlt409240514 _Hlt409180660 _Ref409180871 _Ref409180873 _Hlt409172147 _Ref409173569 _Hlt409229892 _Ref409173839 _Hlt409240676 _Ref409173842 _Hlt409174165 _Hlt409237327 _Ref409267515 _Hlt409262303 _Ref409267655 _Hlt409252971 _Hlt409247669 _Ref409171647 _Hlt409229707 _Hlt409299690 _Ref409299952 _Ref485709556 _Ref409170775 _Hlt409168917 _Hlt409169980 _Hlt409256890 _Ref409151210 _Hlt409236581 _Ref409158676 _Ref409241353 _Hlt409185462 _Ref409233669 _Hlt409233679 _Ref409171671 _Hlt409240558 _Hlt409237111 _Ref409237958 _Hlt409237967 _Hlt409238182 _Hlt409237937 _Ref409180575 _Hlt409240622 _Ref409238242 _Ref409141828 _Hlt409172094 _Hlt409230177 _Ref409169407 _Hlt409172102 _Ref409226405 _Hlt409240597 _Ref409238301 _Hlt409158649 _Hlt409237209 _Ref409238351 _Ref409251031 _Hlt409241239 _Hlt409240572 _Hlt409226379 _Ref409180606 _Hlt409227285 _Hlt409173431 _Ref409180249 _Ref409180371 _Hlt409240694 _Hlt409171744 _Hlt409173393 _Hlt409180352 _Ref409248257 _Hlt409667013 _Hlt409661432 _Ref409178840 _Ref409159332 _Hlt409248549 _Ref409184969 _Hlt409249310 _Hlt409152469 _Ref409148253 _Hlt409268464 _Ref409148286 _Hlt409148313 _Hlt409148192 _Ref409146578 _Ref409186113 _Hlt409253660 _Ref409229770 _Hlt409148461 _Ref409181248 _Hlt409181214 _Hlt409859810 _Hlt409277167 _Hlt409178751 _Hlt409186705 _Hlt409170763 _Hlt409181293 _Hlt409184515 _Hlt409229908 _Hlt409229915 _Hlt409299628 _Hlt409255653 _Hlt409236993 _Hlt409170089 _Hlt485709542 _Hlt409693825 _Hlt409862066 _Ref409254421 _Ref409251027 _Ref409171651 _Hlt409230173 _Hlt409299947 _Ref409255513 _Hlt409255385 _Ref409254426 _Hlt409254405 _Hlt409149312 _Hlt409266427 _Ref409251029 _Hlt409269729 _Hlt409149281 _Hlt409266366 _Ref409858970 _Hlt409859439 _Ref409254422 _Hlt409266527 _Hlt409266486 _Hlt409270340 _Ref409254424 _Hlt409270314 _Ref409229777 _Ref409229768 _Hlt409229905 _Hlt409256556 _Hlt409270292 _Hlt409269655 _Hlt409152738 _Hlt409269756 _Hlt409250518 _Hlt409151686 _Hlt409151766 _Ref409254419 _Ref409858817 _Hlt409152445 _Hlt409180646 _Ref4092297725\\^j ԩfoo=================%%%%%%%%%%%%(>>>>>>>>>>>>>LLLLLLLLLLLL0T0T0T0T0T0T0T0T0T0T0T0TW)^ha@eoo0uBwS~ Q ٢٢٢ۢͼͼM                  ""(B)J,J,J,,,:8:8]?GJ+KQY;aag>kzQggة͵ؼwfJJWWx ]0$0$'9Q[wyً  ϸk6wnJJJ%)..2j!...4;??yCyCyCyCKK[[[jy{y{y{eZT&ֱֱֱ8Ew 9k@ZZhlpt|]IIKpw¿F Xij.L7.8.8a_a_a____``1`f`g`g`g`WaWa0b0b2b2bbbbbbtcccododeeeeee6fcfcfcffgg(ggggghbibijjjjj8k8ktktkkkkllmmm"nn3o3ooppIqIqUrUrssssrtuuuuvvv$w$wwwxxJyJyyyzz"{"{(|(||||}h~h~  aaVV$$fffffąąssllֈ    Ӊىډډډډx#####LLՎee''ԐԐ AA  CCwwwՕՕ֕֕YYppppΗΗttABBBnnqqNcc͞͞~~~~~~~QQҢӢӢ                   !    " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g ݣݣݣϥϥϥ  8888*++ҩҩҩFF==GG{||>>>:??EF ?{KKnnwMTY=`1  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcefghijklmnodpqrstuvwxyz{|}~     ! "#$%&'(*)+,-./2103547689;:<=?>@ABCDEGFHIJLKMNOPQRSTUVWXYZ[\]_^`abcdefghijklmnopqrstuvwxyz{|}~      "!%#$&+')(*,-/.0214357689:;G<>=?@BADCEHFJIKMLONVPTQSRWUXY[Z^\_]a`cbdefhgijlknmporqstvuxwzy|{~}    5\\_j,OȞ$d#[[[[[[[[[[[[[[[[[ @%%%%%%%%%%%%*)?????????????MMMMMMMMMMMMDTETETETETETETETETETETETWR^aqe%p%pmuyw~qr3  zLۢۢۢR::::)*pm T!""g()m,,,,,s8s8r?G\KKQYZaag>kzƂH:D JwwK l0$L$ (y9[y.|,. Jbbsh;gg-!.//4;&@&@yCCCC/L0L[[[jy{{{ĂĂzmֱ۫ 9@ [ [l7qu|s++]^ŠZEAo;P<WI*87878a______`1`f`f`g`VaWa0b0b0b2bbbbbbbscccmdodeeeeee6fbfcfffg(gggggghaibijjjj7k8ksksktkkkkllmmm!nn2o3oo~ppHqIqTrUrssssqtuuuuvvv#w$wwwxxIyJyyyzz!{"{'|(|||{}g~h~  `aUV"$dfeffÅąrsklֈ   Ӊىىډډډډw"#"##KLԎde&'ӐԐ @@A  BCuwwՕՕ֕XYoppp͗ΗstAABBmnpqNbc̞͞}~~~PQҢӢܣܣݣݣͥϥ   7888**+ѩҩҩEF<=GG{||>>>vG >?KtmnnwMTtY=18; SUde{~~????kAnAAAMBPBFFJJJJJJ+L5L]MgMMMMMdNgNNNNNOOOOrX|XYY ZZ [[7\:\q\t\\\\\^^aa|cce&ekkllmmooqqYqeqSr`rrrs$suuJwWwSy]yN|Z|||G}S}}}~$eoL[s `or}͎ڎΐѐӐ֐ȔԔהܖ 2*#&wzÙƙ  fo]fKSisަ!"${DMPU}֪ܪߪSVͫګޭJ\CF=J'| DJMSafimм(4\adhɿϿҿ׿$1 [eWZ!#&VXqt6<jm69^a O\GQ4>SVor 3?@IJSuu3= &IQFPu{|!+4P^LQTZnqv=JfoprIWtx !""P"Z"""k#w#####$$$$J%W%E+T+~++00b1k111*24233;4D4S4[4.5756#6j6t666q7{7888888'91999%;.;<<<=v??wBBCCFFZJfJYM\MNNOO PPPPYYYYZZ7\E\\\^^nn$s0sssvwBwNwqwtwvxxxxxxxxzz,:VcGLkw %2 ӈ  ŊϊҊۊ"0[hϋ؋ڋ  #&6@ōƍ̍ !/M[]gPS!0!+gjkzz~&-ux14wzz@M+-mo)ţѣ?AuwΥڥ68HQ   )1;#+{KNVZѽԽ߽6AGX+5gsZfhp+3OX3@AHmvcmx:E(Q_cm1@PUVZ3@8<kvHVAN &1=HT`blmx]h{!8B' 3 ` l       < F   / 0     C F V ` t ~ ' 1  "?I  2:w.=4=FP#,l!v! "-"""####F#H#J#L#{#~###########$$S$V$Y$a$U%^%_%e%4&7&u&v&[']'u'w'{(())))S+]+,,d/h/////////=1F122222222233#3$3*3I3N3O3Y3Z3b34444Y5e5555566<*<M<\<=#===P?U?AAAABBBBDDFF G/GzGGHHHHbIhIiIqI;LDLGLJLLLXLMMNNNNOO'O1OOOOO?PGPR RT T0T8TU UUUU(UUU)V5V8VCVTV`VVVVVWWWW*X4XIXTXtX~XXXXXXY:YDY{YYYYYY]]]]]] ^^^^^"^&^*^,^4^t^w^{^^^^^^^^^^^^^^S_V___` `2`5`H`J`K`P`aa;aBaCaKaLaTaVaYa[a^aaa;b>bbbc cTcWc8e;eeeeeffffggggg"gggggggWhZh_hfhjhqh{hhiiEjIjTjWjXj[j\jdjejgjhjojvjzjjjjjjjjjjjjjjjjjjjskwkllmmnnnn@oGoLoOoyooooooppppppRsUsXs_sss_tbtttttWuZuuuuuuuvvvvvvvv{xx.y߷)cdnoho ՜.+,D՜.+,8 hp  ZOO Co. C1  PREDGOVOR Titlex(RZ _PID_GUID _PID_HLINKSAN{519841C2-8AA7-11D1DocumentSummaryInformation8y CompObj&'()*+,-./056789j@ABCDEFGHIJKLMNOPUVWXYZ[\]^_`abcdefghijklmnopuvwxyz{|}~-9ED1-0040F658AEEF}ANbH ?slike\coupled tasks.wmf{= .linkane slike\POET primjer rel zad 1visio.gifU>> )linkane slike\POET primjer rel zad 2.gifU?> )linkane slike\POET primjer rel zad 3.gif;K linkane slike\ROSE model1.wmfhg #linkane slike\ROSE asocijacije.wmfpN2{ 'linkane slike\UML PP i DSM matrice.wmfJ-څ E5linkane slike\POET matrica zavisnosti parametara.wmfiOF F+linkane slike\UML relacije pripadnosti.wmfoX G'linkane slike\POET operandi izraza.gif/: H'linkane slike\UML reference izraza.wmfWd d&linkane slike\ROSE prikaz procesa.wmf4F J.linkane slike\UML klase cvorova i bridova.wmf  FMicrosoft Word Document MSWordDocWord.Document.89qXZbcFHOPpJKLiqrRl%%%%%%77VVVVVV%!%*%++-,M.O.O.P.Q.^._........7/8/////j0k00011P1Q1\1]1k1l1|1}1~111111߷)hopRl77++-,M.O.O.Q.^._._.`.........7/9////0j0l00011P1m1|1}1~1111 Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doc Maja i NevenD:\doktorat\npdok new.doch`Rfx#IģQl TK0 ;,:Y%r4+6*QurkP (aVmtèP! wruWBW!0f<!Bìm,b!n8e51$Y!il%PH4%ģ'Ve`) .()tlZ*ģsq*B~n. F.Vr,/ n/⫰b1&Qs3Ԃ.i?y5Ԃ.iC5P*Y6 N7)^1M7rld9 F/.:h; <~(M<; := #.O>6`V>Ԃ.iU|>f>0J^$4?~ %D6K@f@4dUA!D[B:]BģWZE>cF %IVm KPI Iҋn%K|HYKR5Ln7nM F0=NVCNtg OV4FOVPZ<^GQ  IR W6SJ튪;dTj`YvZpYDZK83 :aGa, NbJH@5cVp,`crUd&+H$H3djϔkdVKdeDej/Lg6--:iVJkԂ.i9\l"eEnrpnpWoSIo \gqģj9qn &1!#t "d>]uԂ.ipvhuS =>}u}Gr]w6B|]~  ^`OJQJo(@.@.@..@...@ ....@ .....@ ......@ .......@ ........*hh^h`.77^7`..7^7`...xp^`x....  ^` .....  X ^ `X ......  ^ `....... 8^`8........ `H^``.........T^T`o(-T^T`o(-T^T`o(-@^`.T^T`o(- hh^h`OJQJo(-hh^h`. ;^`;OJ QJ o(- :^`:OJ QJ o(- ^`OJ QJ o(- 2a ^2`OJ QJ o(-pp^p`()  ^ `.@ @ ^@ `.  ^ `.T^T`o(-T^T`o(-Th^T`o(-@^`.hh^h`. hh^h`OJQJo(-T^T`o(-T^T`o(- hh^h`OJ QJ o( ^`OJ QJ o(- ^`OJ QJ o(- ^`OJQJo( ^`OJQJo( pp^p`OJ QJ o(   ^ `OJ QJ o( @ @ ^@ `OJQJo(   ^ `OJQJo(@]s^]`s. ^`OJ QJ o(-T^T`o(-T^T`o(-hh^h`. s^`sOJ QJ o(- :^`:OJ QJ o(- ^`OJ QJ o(- 2a ^2`OJ QJ o(-pp^p`()  ^ `.@ @ ^@ `.  ^ `.T^T`o(-T^T`o(-T^T`o(-hh^h`.77^7`..7^7`...xp^`x....  ^` .....  X ^ `X ......  ^ `....... 8^`8........ `H^``.........@<^`<)@ <^`]uV>extexfdUAdUAdUAdUAdUAdUAdUAdUAdUAdUAdUAdUAWZEQl W6Srkbil%N7uB|#I`Yexh;%I(a.()BW!dUAdUACNpvhudUAD6K@<f>#.O>;dTUdC5H3dx/.:R5L]BdUAgx IdUApndUA IKde :adUA|HYK I I4+'dUAdUA I I IdUAdUAdUAdUA I Ip,`cY%En1M7w:i I I I Ig O.0=NH@5c IkdZpY I IdUA I I I I I I IdUAdUAPdUAdUAgxdUAdUAdUAgxdUAdUAhxdUAdUA hxe51$ IR>}u[B hxj9qGQe51$]~dUAe51$FHdx @ 7^7`OJQJo(-dx .@ R^R`OJQJo(ex T@ R^R`OJQJo(ex @ 7^7`OJQJo(-ex B@h h^h`OJQJo(Hfx @ ^`OJQJo(fx @^`.gx @ 7^7`OJQJo(-gx @ 7^7`OJQJo(- @,hx @ R^R`OJQJo(h  @$}< rr,,,,,,,,, ,#,%,&,'j(j)j*j,j-j/j0j13456;7;8;:;;I<I=I?IGINIPI\I^I`IaIeIfIjIvIwIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIllllllllll~~#~(~<~=~B~F~N~P~WXYdinsxy{|((((((((aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa a aaa a%a'a(a)a*a+a,a.a1a3a6a8a?aEaFaHIJ L N Q U ` a b g h k l o r z          <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< < < <\\\\\\!\#\'\,\-\/\1\5\9\;\>\A\D\H\K\N\O\Q\Z\[\aIcIeSfSgSoSqSsStuvxIzIIIIIIIIIIIIIIIIIIIIIaaaaaaaaaaaaaaaaaaattttt tt,/467:;@CEHKRU^`bejoqrvy 56@DFGIRUijnu|}VVVVVVccccccccccclll5l6~7~8~>~_~`2b2c2{2|22222CCCCCC}}%&')*+,./11 D@$L@,.0268:<>DHJ@NP@T@XZ@^`b@fhl@prv0@  "$&,.246>JTXZ@^`bhlnrz~@@@ &P@*2<dfpx4@@@  @8@"(02468HPXZbflptvzh@*48:<>@BFLPVZh@v@|@T @l @ @$P @*.48<DRVblx|~ @ @ *.6 @BFJRZ^djpx~T @` @ @ @ @ @$L@(8:BL\^@bd~@@@@ @4@6<FJLRT^dhnt   0@  ( \@0 : B H J Z \ d n v z ~     H J ^ f @l p @     * 6 x@@ F L @X ^ ` h j @n @t v | ~ @ @  F @J L X 8@ @@ t@ @ @ @ @ @ @ @ @ (@ <@* X@4 l@> @T @j l n r | @ $@ ,@ @@ GzTimes New Roman5Symbol3& zArialS&Arial Rounded MT Bold?5 zCourier New71CourierEDutch801 Rm BTA"GenevaArial7& Verdana5& zTahoma7Dw"q 8m0Tahoma5&  Impact9MT Extra;WingdingsWTms RmnTimes New Roman7Georgia9Garamond"1 h3]!]!+DFA  E `=D\0dCj%W PREDGOVOR Maja i Neven Maja i Neven