slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ARHITEKTURE PROGRAMSKE POTPORE Objektno usmjerena arhitektura Protok podataka PowerPoint Presentation
Download Presentation
ARHITEKTURE PROGRAMSKE POTPORE Objektno usmjerena arhitektura Protok podataka

Loading in 2 Seconds...

play fullscreen
1 / 59

ARHITEKTURE PROGRAMSKE POTPORE Objektno usmjerena arhitektura Protok podataka - PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on

ARHITEKTURE PROGRAMSKE POTPORE Objektno usmjerena arhitektura Protok podataka Arhitektura zasnovana na događajima Arhitektura repozitorija podataka Slojevita arhitektura Virtualni strojevi Arhitektura programske potpore u upravljanju procesima. ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'ARHITEKTURE PROGRAMSKE POTPORE Objektno usmjerena arhitektura Protok podataka' - lynch


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

ARHITEKTURE PROGRAMSKE POTPORE

    • Objektno usmjerena arhitektura
    • Protok podataka
    • Arhitektura zasnovana na događajima
    • Arhitektura repozitorija podataka
    • Slojevita arhitektura
    • Virtualni strojevi
    • Arhitektura programske potpore u upravljanju procesima
slide3

ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA

  • (engl. event based architecture, implicit invocation)
  • (implicitno pozivanje)
  • Temeljne značajke:
  • Komponente se međusobno ne pozivaju eksplicitno.
  • Neke komponente generiraju signale = događaje.
  • Neke komponente su zainteresirane za pojedine događaje, te se prijavljuju na strukturu za povezivanje komponenata.
  • Komponente koje objavljuju događaj nemaju informaciju koje će sve komponente reagirati i kako na događaj.
  • Asinkrono rukovanje događajima.
  • Nedeterministički odziv na događaj.
  • Model izvođenja: Događaj se javno objavljuje te se pozivaju registrirane procedure.
slide5

ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA

Struktura za povezivanje

slide6

ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA

Primjenski program ne poziva rutinu za obardu događaja izravno niti neizravno. Prekidna rutina (odziv na iznimku) se aktivira preko vektora.

Generiranje iznimke (npr. skok preko vektora)

slide7

ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA

Login/autentifikacijskiscenarij:

Prijava generira događaj na koji se odazivaju brojni procesi.

slide8

ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA

  • Prednosti:
  • Omogućuje razdvajanje i autonomiju komponenata.
  • Snažno podupire evoluciju i ponovno korištenje.
  • Jednostavno se uključuju nove komponente bez utjecaja na postojeće.
  • Nedostaci:
  • Komponente koje objavljuju događaje nemaju garancije da će dobiti odziv.
  • Komponente koje objavljuju događaje nemaju utjecaja na redoslijed odziva.
  • Apstrakcija događaja ne vodi prirodno na postupak razmjene podataka (možda je potrebno uvođenje globalnih varijabli).
  • Teško rasuđivanje o ponašanju komponenata koje objavljuju događaje i pridruženim komponentama koje su registrirane uz te događaje (nedeterministički odziv)
slide9

ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA

Stilistička varijacija: MVC (engl. Model View Controller)

Struktura za povezivanje

mvc primjer prora unske tablice
MVC Primjer: Proračunske tablice
  • Sustav proračunskih tablica za upis i pregled podataka, Npr. Excel.
  • Bez značajnih promjena cjelokupnog sustava postoji potreba za:
    • Dodavanjem nove neinteraktivne vizualizacije podataka.
    • Dodavanjem nove interaktivne vizualizacije podataka.
mvc primjer prora unske tablice1
MVC primjer: proračunske tablice

Controller:Rukovanje ulaznim podacima korisnika

Model: Jezgrene funkcionalnosti i podaci

View. Prikaz informacija

mvc za w eb primjene
MVC zaweb primjene

(Controller)

Web

Server

(Tomcat)

Web

Service

Servlet

rukuje

URL-om

4

zahtjev za URL stranicom

šalje upit

2

1

3

(Model)

generira

Browser

Java

Beans

odabire vizualizaciju

5

7

(Model)

JSP

HTML klijentu

6

Java Servlet Pages

JSP Tomcatu

(View)

mvc za web primjene
MVC za web primjene
  • Akcija klijenta generira zahtjev za određenom URL stranicom.
  • Tomcat otprema Java servlet koji rukuje s URL-om.
  • Servlet kao “Controller” interpretira akciju klijenta i šalje upit ili traži promjenu u Java Beans (“Model”).
  • Java Beans koristi vanjske resurse kao što je npr. Web usluga.
  • Ovisno o stanju modela servlet odabire prikladnu vizualizaciju i prosljeđuje Java Beans do Java Servlet Pages (JSP), t.j. do “View” komponente.
  • Tomcat konvertita JSP u HTML.
  • HTML se prosljeđuje klijentu.
slide14

ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA

  • Zaključak:
  • Vrlo značajna arhitektura programske potpore.
  • Očekuje se intenzivna primjena u procesorskim sustavima s više jezgara (engl. multicore).
  • Uključena u najnoviju specifikaciju UML-a (UML 2.x).
slide16

ARHITEKTURA REPOZITORIJA PODATAKA

Predstavlja veliku skupinu sustava uz mnoge varijacije upravljanja i dijeljenja podataka. Arhitektura obuhvaća načine prikupljanja, rukovanja i očuvanja velike količine podataka.

Prirodni primjer su baze podataka, ali ne i jedini (npr. oglasna ploča)

Pogled s najviše razine na ovu arhitekturu (dvije vrste komponenta):

slide17

ARHITEKTURA REPOZITORIJA PODATAKA

  • Dvije različite vrste komponenta:
      • Središnji repozitorij podataka (predstavlja trenutno stanje)
      • Kolekcija nezavisnihkomponenta koje operiraju nad središnjim repozitorijem (proizvođači i korisnici podataka).
  • Temeljna prednost ove arhitekture je jednostavno dodavanje i povlačenje proizvođača i korisnika (konzumenata) podataka.
  • Problemi su koncentrirani oko:
    • Sinkronizacije
    • Konfiguracije i upravljanje shemama struktura podataka
    • Atomičnosti
    • Konzistencije
    • Očuvanja (perzistencije)
    • Performanse
slide18

ARHITEKTURA REPOZITORIJA PODATAKA

Stil: Jednostavna transakcijski usmjerena BAZA PODATAKA

3 vrste komponenta

  • Komponente modificiraju ili čitaju podatke (preko transakcijskog upita, engl. query) iz baze - DB.
  • DB skladišti perzistentne podatke između različitih transakcija.
  • Nema fiksnog uređenja redoslijeda između transakcija.
  • Komponenta “Control” upravlja paralelnim pristupima u DB.
slide19

ARHITEKTURA REPOZITORIJA PODATAKA

Model ER (entiteti-odnosi) baze podataka:

ER: Entity – Relationship je koncepcijski model podataka koji opisuje podatkovne zahtjeve u informacijskom sustavu na jednostavan i razumljiv grafički način.

Podatkovni zahtjevi se opisuju simbolima ER sheme.

ER shema je komparabilna (ali nije identična) UML dijagramu razreda.

slide20

ARHITEKTURA REPOZITORIJA PODATAKA

ER model baze podataka

(odnosi, veze)

slide21

ARHITEKTURA REPOZITORIJA PODATAKA

ER model baze podataka

Svaka instancija odnosa SUPPLY predstavlja jednu određenu trojku (povezuje instancije iz tri entiteta).

slide22

ARHITEKTURA REPOZITORIJA PODATAKA

ER model baze podataka

(značajke)

Odnosi se npr. na “slot” s više polja.

slide23

ARHITEKTURA REPOZITORIJA PODATAKA

ER model baze podataka

Složeni (Composite) atribut

slide24

ARHITEKTURA REPOZITORIJA PODATAKA

ER model baze podataka

1 Employee min 1 max 5 assignments

1 Task up to 50 assignments

slide25

ARHITEKTURA REPOZITORIJA PODATAKA

ER model baze podataka

(identifikatori, ključevi)

slide26

ARHITEKTURA REPOZITORIJA PODATAKA

ER model baze podataka

= identifier

slide27

ARHITEKTURA REPOZITORIJA PODATAKA

  • ER model baze podataka
  • Razlike između ER modela i UML dijagrama razreda
  • ER dijagrami dozvoljavaju n-struku relaciju. U dijagramima razreda postoji samo relacija (asocijacija) između dva razreda.
  • ER dijagrami dozvoljavaju atribute s više vrijednosti. UML razredi ne.
  • ER dijagrami specificiraju identifikatore. Dijagrami razreda ne.
  • Dijagrami razreda omogućuju dinamičku klasifikaciju (tijekom izvođenja objekt može promijeniti razred). To je složen postupak, ali u ER modelu nije ni predviđen.
  • UML razredi imaju pridružene metode, ograničenja (engl. constraints) i pre/post uvjete.
slide28

ARHITEKTURA REPOZITORIJA PODATAKA

Stil: Oglasna ploča (engl. blackboard)

Temeljni koncept:

Mnogi eksperti promatraju rješavanje zajedničkog problem na ploči (npr. kriminalisti).

Svaki ekspert dodaje svoj dio u rješavanju cjelokupnog problema.

Osnovni dijelovi:

Izvori znanja– KS (engl. knowledge sources), odvojeni i nezavisnidijelovi primjenskog znanja (eksperti). Ne surađuju međusobno izravno već samo putem oglasne ploče.

Oglasna ploča, podaci o stanju problema, organizirani prema primjenskoj hijerarhiji. Izvori znanja, aktivirani promjenom sadržaja na oglasnoj ploči, mijenjaju pojedine sadržaje što inkrementalno dovodi do rješenja problema.

Upravljanje stanjem oglasne ploče. Izvori znanja se odazivaju oportunistički kada se promjene na oglasnoj ploči na njih odnose.

slide29

ARHITEKTURA REPOZITORIJA PODATAKA

Stil: Oglasna ploča (engl. blackboard)

KS: Ekspertize iz različitih domena

Oglasna ploča s hijerarhijskom strukturom

Upravljački dio

Važna distinkcija:

Baza podataka:vanjski procesi iniciraju promjenu sadržaja. Oglasna ploča: promjena sadržaja inicira vanjske procese (KS).

slide30

ARHITEKTURA REPOZITORIJA PODATAKA

Stil: Oglasna ploča (engl. blackboard)

slide31

ARHITEKTURA REPOZITORIJA PODATAKA

  • Stil: Oglasna ploča (engl. blackboard)
  • Obilježja problema prikladnih za arhitekturu oglasne ploče
      • Nema izravnog algoritamskog rješenja (višestruki pristup rješavanju, potrebna ekspertiza iz različitih domena).
      • Neizvjesnost (pogreške i varijabilnost u podacima, srednji ili niski omjer “signala prema šumu” u podacima).
      • Aproksimativno rješenje je dovoljno dobro (ne postoji jedan diskretan odgovor na problem ili ispravan odgovor može varirati.
  • Primjeri primjene:
      • Obradba signala
      • Planiranje, logistika, dijagnostika
      • Optimizacija prevodioca (kompilatora, engl. compiler)
slide32

ARHITEKTURA REPOZITORIJA PODATAKA

  • Stil: Oglasna ploča (engl. blackboard)
  • U ovoj arhitekturi nije unaprijed specificirano:
  • Struktura znanja (kako je predstavljeno znanje).
  • Kako izvori znanja (KS) dohvaćaju podatke s oglasne ploče ?
  • Kako izvori znanja (KS) zapisuju djelomične odgovore na oglasnu ploču ?
  • Kako izvori znanja (KS) koriste podatke sa oglasne ploče ?
  • Kako se određuje kvaliteta rješenja ?
  • Kako se ustvari upravlja ponašanjem izvora znanja (KS) ?
  • Znanjemože biti predstavljeno na različite načine (jednostavnim funkcijama, kolekcijom složenih logičkih izraza, pravilima i sl.). Predstavljeno znanje izaziva odgovarajuću akciju na oglasnoj ploči.
slide33

ARHITEKTURA REPOZITORIJA PODATAKA

Stil: Oglasna ploča (engl. blackboard)

  • Upravljanje oglasnom pločom
      • Upravljano događajima ili signalima (prekidima).
      • Upravljanje pozivanjem procedura.
      • Podatkovno inicirano (engl. Data driven). Slijedeći korak je definiran stanjem podataka, te se poziva odgovarajući KS.
      • Inicirano ciljem (engl. Goal driven). Upravljačka funkcija poziva KS koji najviše doprinosi pomaku prema cilju. Općenito je teško kodirati ciljeve.
      • U praksi se koristi kombinacija ovih postupaka.
slide34

ARHITEKTURA REPOZITORIJA PODATAKA

Stil: Oglasna ploča (engl. blackboard)

Prednosti i nedostaci oglasne ploče s temeljnih gledišta:

Intencijsko i reaktivno ponašanje – kako se napreduje prema rješenju

Prednost: jednostavno integriranje različitih autonomnih sustava.

Nedostatak: Oglasna ploča može biti vrlo složena arhitektura, posebice ako su komponente prirodno međuzavisne.

Predstavljanje i obradba neizvjesnog znanja

Prednost: Oglasna ploča je dobra arhitektura za ovaj tip problema.

Sigurnost i tolerancija na kvarove

Prednost: podsustavi mogu promatrati oglasnu ploču i obratiti pažnju na potencijalne poteškoće.

Nedostatak: Oglasna ploča je kritičan resurs.

Fleksibilnost

Prednost: oglasna ploča je inherentno fleksibilna

slide35

ARHITEKTURA REPOZITORIJA PODATAKA

  • Stil: Oglasna ploča (engl. blackboard)
  • Primjer: Hearsay– sustav za raspoznavanje govora s velikim vokabularom (CMU, 1976). Složena struktura problema motivirala je istraživanje organizacije i uporabe znanja u računalnim sustavima.
  • Oglasna ploča daje višestruko i hijerarhijski organizirano predstavljanje govora:
      • Valni oblici
      • Fonemi
      • Slogovi
      • Rečenice
  • Cjelokupni problem se razdvaja na akustičku, fonetski, leksičku, sintaktičku i semantičku razinu (aktiviranje različitih KS).
  • Sustav rangira verzije potencijalnih rečenica metrikom vjerodostojnosti i daje najvjerojatniji prijevod.
slide36

ARHITEKTURA REPOZITORIJA PODATAKA

Stil: Oglasna ploča (engl. blackboard)

hearsay ii organizacija oglasne plo e
Hearsay II: Organizacija oglasne ploče

Hijerarhijske razine

Izvori znanja

Phrasal

syntactic word

hypothesizer

Lexical

phoneme

hypothesizer

Syllabic

Surface-

phonemic

phone-phoneme

synchronizer

Phonetic

phone synthesizer

Segmental

segmenter-classifier

Parametric

slide38

ARHITEKTURA REPOZITORIJA PODATAKA

Primjer: Prevoditelj (engl. compiler)

Computer Aided Software Engineering (CASE)

Inicijalno: prevođenje izvornog u objektni kod (kompilator, knjižnica - library, povezivanje – linker, “make”).

Razvoj uključuje zapis verzije, dokumentaciju, analizu, upravljanje konfiguracijama, itd.

Traži se čvršća integracija pojedinačnih alata (u 20 godina još nije postignuta).

Tradicijski prevoditelj (1970, sekvencijski)

(arhitektura protoka podataka)

plus odvojena tablica simbola

slide39

ARHITEKTURA REPOZITORIJA PODATAKA

(Rudimentaran)

1985, “attribute” gramatika, stablo parsiranja

slide40

ARHITEKTURA REPOZITORIJA PODATAKA

Prevoditelj predstavljen arhitekturom repozitorija podataka.

Informacija u repozitoriju nije perzistentna od jedne uporabe (prevođenja) do druge.

slide41

ARHITEKTURA REPOZITORIJA PODATAKA

Poželjno generičko CASE okruženje predstavljeno arhitekturom repozitorija podataka:

slide42

ARHITEKTURE PROGRAMSKE POTPORE

    • Objektno usmjerena arhitektura
    • Protok podataka
    • Arhitektura zasnovana na događajima
    • Arhitektura repozitorija podataka
    • Slojevita arhitektura
    • Virtualni strojevi
    • Arhitektura programske potpore u upravljanju procesima
slide44

SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE

  • Primjenski program ili operacijski sustav se strukturira tako da se dekomponira u podskupove modula koji čine različite razine apstrakcije.
  • Dekompozicija je na razini statičkog izvornog koda.
  • Ako je dekompozicija na razini logičkog izvođenja (engl. Run-time) radi se o razinama ili naslagama (engl. Tiers).
  • Temeljni elementi:
      • Komponente = slojevi
      • Konektori = protokoli koji definiraju
      • interakciju između slojeva
  • Hijerarhijska organizacija:
      • Samo susjedni slojevi komuniciraju
      • Svaki sloj daje uslugu sloju iznad i postaje klijent sloju ispod.
      • Svaki sloj skriva slojeve ispod.
slide45

SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE

Tipični primjeri: OSI, TCP/IP

OSI slojeviti model je danas zastario.

Zamijenjen je popularnim Internet Protocol Stack–om.

slide46

SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE

Primjer: Organizacija programskih cjelina u računalu

Primjeri:

UNIX (Linux) jezgra,

X Window sustav (Xlib, Xt, Motif), API

slide47

SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE

Primjer: Predstavljanje znanja na Web-u (Semantički Web)

(znanje predstavljeno kategorijama i hijerarhijom pojmova, uz mogućnost zaključivanja)

Primjena "Opisne logike"

OWL

Razredi i odnosi

Uvodi jednostavnu izjavu (objekt, atribut, vrijednost)

slide48

SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE

  • Prednosti slojevite arhitekture:
    • Sloj djeluje kao koherentna cjelina.
    • Vrlo jednostavna zamjena sloja novijom inačicom.
    • Jednostavno održavanje jer svaki sloj ima dobro definiranu ulogu.
    • Minimizirana je međuovisnost komponenata.
    • Podupire oblikovanje programske potpore na visokoj apstraktnoj razini.
    • Podupire ponovno korištenje (engl, reuse).
  • Nedostaci slojevite arhitekture:
      • Smanjene performanse jer gornji slojevi samo indirektno dohvaćaju donje slojeve.
      • Teško se pronalazi ispravna apstrakcija (posebice u sustavima s većim brojem slojeva).
      • Svi sustavi se ne preslikavaju izravno u slojevitu arhitekturu (djelokrug programske jedinice može zahvaćati više slojeva).
slide50

VIRTUALNI STROJEVI (VM)

  • Virtualni stroj (VM) je računalno okruženje čiji skup resursa i funkcionalnost je izgrađeno (kroz programski sloj) iznad nekog drugog programskog okruženja (apstrakcija računalnih resursa).
  • Npr.: Java primjenski program se izvodi u okviru Java virtualnog stroja (JVM), koji se pak izvodi u okviru nekog operacijskog sustava.
  • Temeljna prednost je u odvajanju primjenskog programa od ostatka sustava (nedostatak je slabljenje performansi).
  • VM može simulirati funkcionalnost (još) nepostojeće sklopovske platforme (pomaže u razvoju prog. potpore za nove naprave).
  • Konfiguracija više ne slijedi tradicijsku organizaciju (sklopovlje – OS – primjenski program) već jednu od nekoliko mogućnosti pod zajedničkim nazivom Virtualni stroj (VM).
  • Te su konfiguracije: Hipervizorski VM, Udomaćen VM (engl. hosted), Primjenski VM i Paralelni VM.
slide51

VIRTUALNI STROJEVI (VM)

Hipervizor VM(engl. hypervisor) – (hipernadzorni ?)

Dodani sloj je odmah iznad sklopovlja. Na njega se oslanjaju jedan ili više OS gdje svaki smatra da je jedini OS u računalu

(npr. VMware ESX server).

Primjenski program 1 Primjenski program 2 Primjenski program 3

OS 1 OS 2 OS 3

Hipervizorski program (VM)

Sklopovlje

slide52

VIRTUALNI STROJEVI (VM)

Udomaćen VM (engl. hosted VM)

VM, kao i svaki drugi primjenski program izvodi se iznad OS-a. Shema je manje efikasna od Hypervisorskog VM, ali osnovna prednost odvajanja ostaje (primjer VMware GSX server, Microsoft Virtual PC).

Primjenski program 3

Primjenski program 1 Primjenski program 2 Udomaćen OS_1

OS

Sklopovlje

Cygwin nije udomaćen virtualni stro (OS) j jer se svi programi za UNIX moraju prevesti iz izvornog (engl. source ) oblika.

To je VM na primjenskoj razini – vidi slijedeću sliku.

slide53

VIRTUALNI STROJEVI (VM)

Virtualni stroj primjenske razine (specifičan)

Slično udomaćenu VM, ali na primjenskoj razini. Npr. Java VM je primjenski program (izvodi se na izvornom OS-u), a Java primjene se izvode na Java VM. Prednost: Java primjenski program izvodit će se bez prevođenja na svakom Java VM (koji je različit za svaki operacijski sustav).

Primjenski program 3

Primjenski program 1 Primjenski program 2 Java VM

OS

Sklopovlje

Paralelni virtualni stroj

Pretpostavlja se postojanje programskog međusloja.

Međusloj egzistira kao programski (zlo)duh (UNIX “demon”) ili uslužni program, zajedno sa pozivima u skup rutina (“library calls”). Pozivi rutina su uključeni (prevoditeljem) u primjenski program. Međusloj omogućuje da su rutine raspodijeljene u mreži računala.

slide55

ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA

Automatsko upravljanje grijanjem u zatvorenoj petlji.

slide56

ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA

Opći dijagram sustava automatskog upravljanja:

Upravljanje bez povratne veze

Upravljane izlazne varijable

Varijable koje mijenjamo

Željene vrijednosti

Senzori - osjetila

Upravljanje s povratnom vezom

cruise control system

ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA

Cruise Control System

Active/inactive

toggle

Engine

Controller

Desired

speed

throttle

setting

Wheel

rotation

Podešavanje “gasa”

pulses from wheel

The set point consists of the desired speed and the active/inactive toggle. Desired speed can only be calculated when the system is active, and is based on the system on and increase/decrease speed inputs. Active/inactive status is calculated based on the engine on, system on, accelerator, brake, current speed, and resume inputs.

slide58

ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA

Tehnička shema fizikalnog procesa je razumljiva, ali nejasno koje programske jedinice uporabiti.

Potrebna općenitija analiza programskih i sklopovskih dijelova te okoline (engl. HW + SW + environment).

Software

Hardware

Devices (peripherals)

Interakcija sokolinom.

Sensors

Actuators

Environment

slide59

ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA

  • Realizacija
  • Budući da u ovoj arhitekturi pojedine programske komponente nisu specificirane, najčešće se koristi neka od temeljnih programskih arhitektura kao npr.:
      • Cjevovodi i filtri
      • Arhitektura zasnovana na događajima
      • Oglasna ploča
  • Programske komponente se ugrađuju u fizički sustav (nužno je razmatranje ograničenja okoline te intenzivna uporaba ekspertnog znanja iz domene primjene).