UVOD

Najvažnije karakteristike svakog sustava su njegova struktura i proces funkcioniranja. Struktura sustava shvaćena je kao vremenski stabilan skup odnosa između njegovih elemenata ili komponenti. Struktura je ta koja povezuje sve elemente i sprječava da se sustav raspadne na zasebne komponente. Struktura sustava može odražavati različite odnose, uključujući ugniježđenje elemenata jednog sustava u drugi. U tom je slučaju uobičajeno manji ili ugniježđeni sustav nazivati ​​podsustavom. Proces funkcioniranja sustava usko je povezan s promjenama njegovih svojstava ili ponašanja tijekom vremena. Istovremeno važna karakteristika sustava je njegovo stanje, koje se shvaća kao skup svojstava ili karakteristika koje u svakom trenutku odražavaju najznačajnije karakteristike ponašanja sustava. Zajedničko svojstvo svih modela je njihova sličnost izvorni sustav. Važnost izgradnje modela leži u mogućnosti njihove uporabe za dobivanje informacija o svojstvima ili ponašanju izvornog sustava. U tom se slučaju proces konstruiranja i naknadne primjene modela za dobivanje informacija o izvornom sustavu naziva modeliranjem. Opći model sustav sadrži neke važne informacije o funkcionalnim značajkama danog sustava, koje daju ideju o njegovom daljnjem ponašanju.

Proučavanje procesa modeliranja predmet je proučavanja ovog kolegija. Izgradnja specifičnog objektni model, proučavanje njezina ponašanja smatrat će se predmetom istraživanja. Za postizanje ovog cilja koristi se sljedeće metode: proučavanje potrebne literature, usporedba, primjeri iz životnog iskustva Budući da će se konstrukcija modela objekta provoditi na primjeru autoservisa, potrebno je proučiti princip rada ove organizacije. Da biste to učinili, dovoljno je posjetiti službene web stranice različitih auto servisa. Ali za proučavanje principa konstruiranja objektnog modela proučavao sam znanstvenu domaću i stranu literaturu. Pokazalo se da je to vrlo uzbudljiva aktivnost.

Na kraju, moj cilj predmetni rad postalo: izgraditi objektni model informacijskog sustava “Autoservis”, proučiti princip konstruiranja objektnog modela, opisati proces izgradnje, dokazati važnost posjedovanja ovih znanja i sposobnost njihove primjene u praksi.

Struktura kolegija je sljedeća: prvo se proučava teorija konstruiranja objektivnog modela, zatim se provjerava implementacija teorije na praktičnom primjeru.

1. Osnovni pojmovi objektno orijentiranog pristupa

Objektno orijentirani pristup temelji se na sustavnoj uporabi modela. Objekti i pojmovi uključeni su u formulaciju cilja stvarni svijet vezano uz programski sustav koji se razvija. S objektno orijentiranim pristupom, ti objekti i koncepti zamijenjeni su njihovim modelima, tj. određene formalne strukture koje ih predstavljaju u softverskom sustavu.

Model ne sadrži sve karakteristike i svojstva objekta ili koncepta koji predstavlja, već samo one koje su bitne za programski sustav koji se razvija. Dakle, model je jednostavniji od objekta (koncepta) koji predstavlja. Time se pojednostavljuje kako razvoj i proučavanje (analiza) modela tako i njihova implementacija na računalu. Konkretno, formalna priroda modela omogućuje nam da dobijemo formalni model softverskog sustava koji se razvija kao sastav formalnih modela njegovih komponenti.

Dakle, objektno orijentirani pristup pomaže u suočavanju sa složenim problemima kao što je smanjenje složenosti softvera; povećanje pouzdanosti softvera; što omogućuje izmjenu pojedinačne komponente softver bez mijenjanja ostalih komponenti; osiguravanje mogućnosti ponovne uporabe pojedinih programskih komponenti.

Sustavna primjena objektno orijentiranog pristupa omogućuje nam razvoj dobro strukturiranih, pouzdanih i prilično lako modificiranih softverskih sustava. Ovo objašnjava interes programera za objektno orijentirani pristup. Objektno orijentirani pristup jedno je od područja teorijskog i primijenjenog programiranja koje se najbrže razvija.

Objektno orijentirani razvoj softvera uključuje korištenje objektno orijentiranih modela u razvoju softverskih sustava i njihovih komponenti.

Objektno orijentirani razvoj može započeti već u prvoj fazi životni ciklus; nije povezan s programskim jezikom u kojem bi se softverski sustav koji se razvija trebao implementirati: ovaj jezik možda nije objektno orijentiran. U fazi razvoja, objekti su neke formalne strukture (na primjer, pravokutnici s zaobljeni kutovi, uz pomoć kojih su prikazani u dijagramima), još ni na koji način nisu povezani s njihovom budućom implementacijom u nekom od programskih jezika.

Objektno orijentirani razvoj softvera uključuje korištenje objektno orijentiranih metodologija (tehnologija). Obično su ove objektno orijentirane metodologije podržane softverskim alatima, no i bez takvih alata one su korisne jer omogućuju dobro razumijevanje različitih aspekata i svojstava softverskog sustava koji se razvija, što kasnije značajno olakšava njegovu implementaciju, testiranje, održavanje, razvoj novih verzija i značajnije izmjene.

Projektiranje aplikativnog softverskog sustava počinje analizom zahtjeva koje će on morati zadovoljiti. Takva se analiza provodi kako bi se dovoljno razumjela svrha i uvjeti rada sustava da bi se mogao izraditi njegov idejni projekt.

Objektno orijentiranim pristupom analiza zahtjeva sustava svodi se na izradu modela ovog sustava. Model sustava (ili bilo kojeg drugog objekta ili pojave) formalni je opis sustava koji identificira glavne objekte koji čine sustav i odnose između tih objekata. Izrada modela je široko rasprostranjen način proučavanja složenih objekata i pojava. Model izostavlja brojne detalje koji ga čine teškim za razumijevanje. Modeliranje je rašireno iu znanosti iu tehnologiji.

Modeli pomažu provjeriti performanse sustava u razvoju u ranim fazama njegovog razvoja, komunicirati s kupcem sustava, pojašnjavajući njegove zahtjeve za sustav i napraviti (ako je potrebno) promjene u dizajnu sustava (i na početku dizajna i u drugim fazama životnog ciklusa).

Modeli razvijeni i otklonjeni u prvoj fazi životnog ciklusa sustava nastavljaju se koristiti u svim sljedećim fazama, olakšavajući programiranje sustava, otklanjanje pogrešaka i testiranje, održavanje i daljnje modifikacije.

Objektni model opisuje strukturu objekata koji čine sustav, njihove atribute, operacije i odnose s drugim objektima. Objektni model treba odražavati one koncepte i objekte stvarnog svijeta koji su važni za sustav koji se razvija. Objektni model prvenstveno odražava pragmatiku sustava koji se razvija, što se izražava u korištenju terminologije područje primjene vezano uz korištenje sustava koji se razvija.

Razmotrimo osnovne koncepte koji se koriste u konstruiranju objektnog modela.

Objekt je apstrakcija ili bilo koja stvar s jasno definiranim granicama koja ima smisla u kontekstu problema primjene koji se razmatra. Uvođenje objekata ima dva cilja: razumijevanje primijenjenog zadatka (problema) i upoznavanje osnove za implementaciju na računalu.

Svrha razvoja objektnog modela je opisati objekte koji zajedno čine dizajnirani sustav, kao i identificirati i naznačiti različite ovisnosti između objekata.

Klasa je deskriptor za skup objekata koji imaju ista svojstva. Klasa opisuje svojstva određenog broja objekata. Svaki objekt je instanca samo jedne klase.

Sve objekte iste klase karakteriziraju isti skupovi atributa. Međutim, grupiranje objekata u klase nije određeno skupovima atributa, već semantikom. Tako npr. objekti štala i konj mogu imati iste atribute: cijenu i starost. Štoviše, mogu pripadati istoj klasi ako se u problemu razmatraju jednostavno kao proizvod ili kao različite klase, što je prirodnije.

Kombiniranje objekata u klase omogućuje uvođenje apstrakcije u problem i razmatranje u općenitijoj formulaciji. Klasa ima ime (kao što je konj) koje se odnosi na sve objekte te klase. Osim toga, klasa sadrži nazive atributa koji su definirani za objekte. U tom smislu, opis klase je sličan opisu tipa strukture (zapisa); Štoviše, svaki objekt ima isto značenje kao instanca strukture (varijabla ili konstanta odgovarajućeg tipa).

Atribut objekta je vrijednost koja karakterizira objekt u njegovoj klasi. Primjeri atributa: marka, godina proizvodnje, boja (atributi objekata klase automobila) itd.

Operacija je funkcija (ili transformacija) koja se može primijeniti na objekte dane klase. Primjeri operacija: provjeriti, ukloniti, ugraditi (za objekte klase rezervnih dijelova).

Svi objekti određene klase koriste istu instancu svake operacije (tj. povećanje broja objekata određene klase ne povećava količinu učitanih programski kod). Objekt iz kojeg je operacija pozvana prosljeđuje joj se kao implicitni argument (parametar).

Ista se operacija može primijeniti na objekte različitih klasa: takva se operacija naziva polimorfnom jer može imati različite oblike za različite klase.

Ovisnosti između klasa su dvosmjerne: sve klase u zavisnosti imaju jednaka prava. To vrijedi čak iu slučajevima kada se čini da naziv ovisnosti uvodi smjer u tu ovisnost. Ovisnosti između klasa odgovaraju ovisnostima između objekata tih klasa. Ovisnosti, poput klasa, mogu imati atribute.

Diskriminator je atribut tipa "nabrajanja" koji pokazuje od kojih je svojstava objekata napravljena data generalizacija.

Uloga definira jednu stranu ovisnosti. U binarnoj ovisnosti definirane su dvije uloge. Naziv uloge jedinstveno identificira jednu stranu ovisnosti. Uloge omogućuju promatranje binarne ovisnosti kao odnosa između objekta i skupa zavisnih objekata: svaka je uloga oznaka objekta ili skupa objekata koji su ovisnošću povezani s objektom na drugom kraju ovisnosti. Naziv uloge može se smatrati izvedenim atributom čiji je skup vrijednosti skup objekata povezanih s tom ulogom. U binarnoj ovisnosti, par naziva uloga može se koristiti za identifikaciju te ovisnosti.

Imena uloga moraju biti navedena u slučajevima kada je uspostavljena ovisnost između objekata iste klase. Nazivi uloga moraju biti jedinstveni jer se koriste za razlikovanje objekata uključenih u ovisnost.

Kvalifikator je atribut koji vam omogućuje smanjenje efektivne višestrukosti ovisnosti. Kvalifikatori se koriste u ovisnostima jedan-prema-više ili više-prema-više.

Agregacija je ovisnost između klase složenih objekata i klasa koje predstavljaju komponente tih objekata (odnos "cjelina"-"dio").

Generalizacija i nasljeđivanje omogućuju prepoznavanje analogija između različitih klasa objekata i određivanje višerazinske klasifikacije objekata. Tako u grafičkim sustavima mogu postojati klase koje određuju prikaz različitih geometrijskih oblika: točaka, linija (pravih linija, kružnih lukova i krivulja definiranih splineovima), poligona, krugova itd.

Diskriminator je atribut tipa "nabrajanja", koji pokazuje od kojih se svojstava objekata sastoji data generalizacija.

Treba napomenuti da treba izbjegavati opsežne višerazinske klasifikacije jer ponašanje potklasa nižih razina višerazinske klasifikacije može biti teško razumjeti: većina (a često i svi) atributa i operacija takvih klasa su definirani u svojim superklasama raznih razina. Ako je broj razina klasifikacije postao pretjerano velik, trebate malo promijeniti strukturu sustava.

Generalizacija i nasljeđivanje naširoko se koriste ne samo u analizi zahtjeva za softverske sustave i njihov preliminarni dizajn, već iu njihovoj implementaciji.

Ponekad je potrebno da potklasa nadjača operaciju definiranu u jednoj od svojih superklasa. Da bi se to postiglo, operacija koja se može izvesti iz superklase kao rezultat nasljeđivanja je također definirana u podklasi; ova redefinicija "zamagljuje" svoju definiciju u superklasi, tako da se primjenjuje operacija nadjačana u podklasi, a ne ona naslijeđena. Podsjetimo se da je svaka operacija definirana svojim potpisom; prema tome, potpis nadjačavanja operacije mora odgovarati potpisu operacije u superklasi koju je operacija nadjačala.

Nadjačavanje može poslužiti u jednu od sljedećih svrha:

proširenje: nova operacija proširuje naslijeđenu operaciju, uzimajući u obzir utjecaj atributa podklase;

ograničenje: nova operacija je ograničena na izvođenje samo dijela radnji naslijeđene operacije, koristeći specifičnosti objekata podklase;

optimizacija: korištenje specifičnosti objekata potklase omogućuje vam pojednostavljenje i ubrzavanje odgovarajuće metode;

pogodnost.

Preporučljivo je pridržavati se sljedećih semantičkih pravila nasljeđivanja:

sve operacije upita (operacije koje koriste vrijednosti atributa, ali ih ne mijenjaju) moraju naslijediti sve podklase;

sve operacije koje mijenjaju vrijednosti atributa moraju biti naslijeđene u svim svojim ekstenzijama;

sve operacije koje mijenjaju vrijednosti ograničenih atributa ili atributa koji definiraju ovisnosti moraju se blokirati u svim svojim proširenjima;

operacije ne bi trebalo temeljito redefinirati; sve metode koje implementiraju istu operaciju moraju izvršiti sličnu konverziju atributa;

Naslijeđene operacije mogu se poboljšati dodavanjem dodatnih radnji.

Slijedeći ova pravila, koja, nažalost, rijetko podržavaju objektno orijentirani programski jezici, možete učiniti program koji razvijate razumljivijim, lakšim za modificiranje i manje podložnim raznim pogreškama i propustima.

Apstraktna klasa ne može imati objekte jer ne definira operacije na objektima; objekti moraju pripadati konkretnim potklasama apstraktne klase. Apstraktne klase koriste se za određivanje sučelja za operacije (metode koje implementiraju te operacije naknadno se definiraju u podklasama apstraktne klase). Apstraktne klase prikladne su tijekom faze analize zahtjeva sustava, budući da nam omogućuju identificiranje analogija u naizgled različitim operacijama definiranim u sustavu koji se analizira.

Višestruko nasljeđivanje omogućuje klasi da ima više od jedne superklase, nasljeđujući svojstva (atribute i operacije) svih svojih superklasa. Klasa koja ima više superklasa naziva se unijska klasa. Svojstva klase pretka koja se pojavljuje više puta u grafu nasljeđivanja nasljeđuju se samo u jednoj kopiji. Sukobi između paralelnih definicija stvaraju dvosmislenosti koje se moraju riješiti tijekom implementacije. U praksi, takve dvosmislenosti ili loše razumijevanje treba izbjegavati čak i kada određeni programski jezik odabran za implementaciju sustava pruža mogućnost njihovog rješavanja korištenjem prioriteta ili nekim drugim sredstvima.

U objektno orijentiranom dizajnu bavimo se skupovima međusobno povezanih objekata. Svaki objekt se može tretirati kao varijabla ili konstanta tipa strukture (na taj način se metode opisane u objektu tretiraju kao adrese funkcija koje se mogu primijeniti na ovaj objekt). Dakle, skup objekata je skup međusobno povezanih podataka, tj. nešto vrlo slično bazi podataka. Stoga je primjena koncepata baze podataka često korisna u objektno orijentiranoj analizi i objektno orijentiranom dizajnu aplikacijskih softverskih sustava.

Metapodaci su podaci koji opisuju druge podatke. Na primjer, definicija klase je metapodatak, budući da klasa opisuje druge podatke - objekte ove klase. Modeli su metapodaci jer opisuju objekte koji se modeliraju. Drugi primjer metapodataka je apstraktna klasa.

Glumci su uloge koje igraju entiteti koji su u izravnoj interakciji sa sustavom.

Glumac definira ulogu koju neki vanjski entitet igra u izravnoj interakciji s danim sustavom. Može predstavljati korisničku ulogu ili ulogu koju obavlja drugi sustav ili dio hardvera koji dodiruje granice sustava.

Jako mi se svidio opis pojma "glumac" u djelu Jima Arlowa i Islea Neustadta "UML 2 i Unificirani proces": "Da bismo razumjeli glumce, važno je razumjeti koncept uloga. Uloga se može zamisliti kao šešir koji se nosi u određenoj situaciji." (stranica 92).

Kada su osnovni pojmovi poznati, možemo razmotriti izgradnju samog modela

1. Izrada objektnog modela

1. Definiranje klasa

Analiza vanjskih zahtjeva za projektirani aplikacijski sustav omogućuje nam da odredimo objekte i klase objekata povezanih s aplikacijskim problemom koji ovaj sustav mora riješiti. Morate započeti identificiranjem mogućih klasa iz pisane izjave primijenjenog problema ( projektni zadatak i ostala dokumentacija koju dostavlja kupac). Ovo je vrlo teška i odgovorna faza razvoja, jer o tome uvelike ovisi buduća sudbina projekta.

Kada identificirate moguće klase, trebali biste pokušati identificirati što je moguće više klasa, zapisujući naziv svake klase koja vam padne na pamet. Konkretno, svaka imenica koja se pojavljuje u preliminarnoj izjavi problema može imati odgovarajuću klasu. Stoga, kada se identificiraju mogući razredi, svaka se takva imenica obično povezuje s mogućim razredom.

redundantne klase: ako dvije ili više klasa izražavaju istu informaciju, treba zadržati samo jednu od njih;

irelevantne (koje nisu izravno povezane s problemom) klase: za svaki naziv moguće klase procjenjuje se koliko je potrebna u budućem sustavu (često je to vrlo teško procijeniti); irelevantne klase su isključene;

nejasno definirane (sa stajališta problema koji se razmatra) klase;

atributi: neke imenice više odgovaraju atributima nego razredima; takve imenice, u pravilu, opisuju svojstva predmeta (na primjer, ime, dob, težinu, adresu itd.);

operacije: vjerojatnije je da će neke imenice biti imena operacija nego klasa (na primjer, telefon_poziv vjerojatno neće značiti bilo koju klasu);

uloge: neke imenice definiraju imena uloga u objektnom modelu (na primjer, vlasnik, vozač, šef, zaposlenik; sva ova imena povezana su s ulogama u različitim ovisnostima objekata klase osoba);

izvedbene konstrukcije: nazivi koji su više povezani s programiranjem i računalnim hardverom ne bi se trebali uspoređivati ​​s klasama u ovoj fazi, budući da ne odražavaju značajke dizajniranog aplikacijskog sustava; primjeri takvih naziva: potprogram, proces, algoritam, prekid itd.

Nakon eliminacije naziva svih nepotrebnih (suvišnih) mogućih klasa, dobit će se preliminarni popis klasa koje čine projektirani sustav.

1. Priprema rječnika podataka

Pojedine riječi imaju previše tumačenja. Stoga je potrebno na samom početku projektiranja pripremiti rječnik podataka koji sadrži jasne i nedvosmislene definicije svih objekata (klasa), atributa, operacija, uloga i ostalih entiteta koji se razmatraju u projektu. Bez takvog rječnika rasprava o projektu s kolegama programerima i korisnicima sustava je besmislena, jer svatko može interpretirati pojmove o kojima se govori na svoj način.

2.3. Definiranje ovisnosti

U sljedećoj fazi izgradnje objektnog modela utvrđuju se ovisnosti između klasa. Prije svega, atributi koji su eksplicitne veze s drugim klasama isključeni su iz klasa; takvi se atributi zamjenjuju ovisnostima. Poanta ove zamjene je da ovisnosti predstavljaju apstrakciju na istoj razini kao i klase, te stoga ne utječu izravno na buduću implementaciju (referenca na klasu samo je jedan od načina za implementaciju ovisnosti).

Baš kao što su nazivi mogućih klasa dobiveni iz imenica pronađenih u preliminarnoj izjavi problema aplikacije, nazivi mogućih ovisnosti mogu se dobiti iz glagola ili glagolskih izraza koji se nalaze u navedenom dokumentu. Ovako obično opisuju: fizički položaj (follows_after, is_part, is_contained), usmjerenu akciju (leads_to_movement), komunikaciju (talks_to), pripadnost (has, is_part), itd.

Zatim biste trebali ukloniti nepotrebne ili netočne ovisnosti prema sljedećim kriterijima:

ovisnosti između isključenih klasa moraju se eliminirati ili preformulirati u smislu preostalih klasa;

Treba eliminirati nebitne ovisnosti i ovisnosti vezane uz implementaciju;

radnje: ovisnost treba opisivati ​​strukturna svojstva domene primjene, a ne nevažne događaje;

trenarne ovisnosti: većina ovisnosti između tri ili velik broj klase se mogu rastaviti na nekoliko binarnih ovisnosti, koristeći kvalifikatore ako je potrebno; u nekim (vrlo rijetkim) slučajevima takva se razgradnja ne može provesti; na primjer, trenarna ovisnost “Profesor predaje kolegij u sobi 628” ne može se rastaviti na binarne bez gubitka informacija;

izvedene ovisnosti: potrebno je isključiti ovisnosti koje se mogu izraziti kroz druge ovisnosti, jer su suvišne; kada isključujete redundantne (izvedene) ovisnosti, morate biti posebno oprezni, jer nisu sve duplicirane zavisnosti između klasa redundantne; u nekim slučajevima, druge ovisnosti nam omogućuju da utvrdimo samo postojanje druge izvedene ovisnosti, ali nam ne dopuštaju da utvrdimo višestrukost ove ovisnosti.

Nakon što ste uklonili suvišne ovisnosti, trebate razjasniti semantiku preostalih ovisnosti na sljedeći način:

Netočno imenovane zavisnosti: treba ih preimenovati tako da njihovo značenje postane jasno;

imena uloga: trebate dodati imena uloga gdje je to potrebno; naziv uloge opisuje ulogu koju ima odgovarajuća klasa u danoj zavisnosti sa stajališta druge klase koja sudjeluje u toj zavisnosti; ako je naziv uloge jasan iz naziva klase, može se izostaviti;

kvalifikatori: dodavanjem kvalifikatora gdje je to potrebno uvodimo elemente konteksta, čime postižemo jednoznačnu identifikaciju objekata; kvalifikatori također omogućuju pojednostavljenje nekih ovisnosti smanjenjem njihove višestrukosti;

višestrukost: potrebno je dodati oznake za višestrukost ovisnosti; Treba imati na umu da se višestrukost ovisnosti može promijeniti u procesu daljnje analize zahtjeva sustava;

neobračunate ovisnosti moraju se identificirati i dodati u model.

2.4. Pročišćavanje atributa

U sljedećoj fazi pojašnjava se sustav atributa: prilagođavaju se atributi klase, po potrebi se uvode novi atributi. Atributi izražavaju svojstva objekata dotične klase ili određuju njihovo trenutno stanje.

Atributi obično odgovaraju imenicama; na primjer, car_color (svojstvo objekta), cursor_position (stanje objekta). Atributi, u pravilu, malo utječu na strukturu objektnog modela.

Uz atribute objekata potrebno je unijeti i atribute ovisnosti između klasa (odnosa između objekata).

Prilikom određivanja atributa vode se sljedećim kriterijima:

Zamjena atributa objektima. Ako je prisutnost nekog entiteta važnija od njegove vrijednosti, onda je to objekt ako značenje je važnije, onda je ovo atribut: na primjer, šef je objekt (nije važno tko je šef, glavno je da je netko), plaća je atribut (njegovo značenje je vrlo značajno); grad je uvijek objekt, iako se u nekim slučajevima može činiti da je atribut (na primjer, grad kao dio adrese tvrtke); u slučajevima kada želite da grad bude atribut, trebali biste definirati ovisnost (recimo, locirano) između klasa tvrtka i grad.

Kvalifikacije. Ako značenje atributa ovisi o specifičnom kontekstu, treba ga učiniti kvalifikatorom.

Imena. Imena se obično bolje podudaraju s kvalifikatorima nego s atributima objekta; u svim slučajevima gdje ime dopušta odabir iz objekata određenog skupa, treba ga učiniti kvalifikatorom.

Identifikatori. Identifikatori objekata povezani su s njihovom implementacijom. U ranim fazama dizajna ne bi se trebali smatrati atributima.

Atributi veza. Ako neko svojstvo ne karakterizira sam objekt, već njegovu vezu s drugim objektom (objektima), tada je to atribut veze, a ne atribut objekta.

Unutarnje vrijednosti. Atribute koji definiraju samo unutarnje stanje objekta, nevidljivo izvan objekta, treba isključiti iz razmatranja.

Nevažni detalji. Preporuča se izostaviti atribute koji ne utječu na izvođenje većine operacija.

2.5. Izolacija podsustava

Aplikacijski sustav je skup međusobno ovisnih objekata. Svaki objekt karakterizira skup atributa čije vrijednosti određuju stanje objekta i skup operacija koje se mogu primijeniti na ovaj objekt. Tijekom razvoja aplikacijski sustavi zgodno je pretpostaviti da su svi atributi objekata privatni (tj. nisu im dostupni izvan objekta, a da bi se saznala vrijednost atributa drugog objekta u objektu, odnosno promijenila ga, potrebno je koristiti jednu od javnih operacija ovog objekta, osim ako, naravno, takva operacija nije definirana). Objektne operacije mogu biti javne ili privatne.

Dakle, svaki objekt ima strogo definirano sučelje, tj. skup javnih operacija koje se mogu primijeniti na ovaj objekt. Svi objekti iste klase imaju isto sučelje. Sučelje klase (i, posljedično, svakog objekta ove klase) navedeno je popisom potpisa njegovih otvorenih (javnih) operacija (i metoda koje ih implementiraju); potpisi zatvorenih operacija nisu uključeni u sučelje objekata odgovarajuće klase.

itd.............

Sustav primjene predstavlja skup međusobno ovisnih objekata. Svaki objekt karakterizira skup svojstava, čije vrijednosti određuju stanje objekta, te skup operacija koje se mogu primijeniti na ovaj objekt.

Pri razvoju aplikacijskih sustava prikladno je pretpostaviti da su sva svojstva objekata privatna (to jest, nisu im dostupna izvan objekta). Objektne operacije mogu biti javne ili privatne.

Dakle, svaki objekt ima strogo definirano sučelje, tj. skup javnih operacija koje se mogu primijeniti na ovaj objekt. Svi objekti iste klase imaju isto sučelje.

Objektni model predstavlja statističku strukturu projektiranog sustava (podsustava). Međutim, znanje statična struktura nedovoljno za razumijevanje i procjenu podsustava robota. Potrebno je imati sredstva za opisivanje promjena koje se događaju s objektima i njihovim vezama tijekom rada podsustava.

Jedno od tih sredstava je dinamički model podsustava. Izrađuje se nakon što je objektni model podsustava izgrađen i prethodno dogovoren i otklonjen. Dinamički model podsustava sastoji se od dijagrama stanja njegovih objekata podsustava.

Trenutno stanje objekta karakterizira skup trenutnih vrijednosti njegovih atributa i odnosa. Tijekom rada sustava, njegovi sastavni objekti međusobno djeluju, uslijed čega se njihova stanja mijenjaju. Jedinica uticaja je događaj: svaki događaj dovodi do promjene stanja jednog ili više objekata u sustavu, odnosno do pojave novih događaja. Rad sustava karakterizira slijed događaja koji se u njemu događaju.

Događaj se događa u nekom trenutku u vremenu. Primjeri događaja: lansiranje rakete, start utrke na 100 m, početak postavljanja žica, izdavanje novca itd. Događaj nema trajanje (točnije, traje zanemarivo malo vremena).

Ako događaji nemaju uzročnu vezu (tj. logički su neovisni), nazivaju se nezavisna(istodobno). Takvi događaji ne utječu jedni na druge. Nema smisla poredati neovisne događaje, budući da se mogu pojaviti bilo kojim redoslijedom. Model distribuirani sustav mora nužno sadržavati nezavisne događaje i aktivnosti.

Slijed događaja naziva se scenarij. Nakon što su scenariji razvijeni i analizirani, određuju se objekti koji generiraju i primaju svaki događaj scenarija.

Kada se dogodi događaj, ne samo da objekt prelazi u novo stanje, već se također izvodi radnja povezana s tim događajem. Radnja je trenutna operacija povezana s događajem.

Proces izgradnje objektnog modela uključuje sljedeće korake:

Definicija objekata i klasa;

Priprema rječnika podataka:

Određivanje ovisnosti između objekata;

Određivanje svojstava objekata i veza;

Organiziranje i pojednostavljenje klasa pri korištenju nasljeđivanja;

Daljnja istraživanja i usavršavanje modela.

Objektni model postojeći posao pokazuje kako i zbog čega se provode presedani. Ovaj model otkriva unutarnja struktura posao, naime: koje se vrste resursa koriste za implementaciju presedana i kako oni međusobno djeluju. Opis objektnog modela temelji se na konceptu "objekta". Objekti predstavljaju sudionike procesa i razne vrste entiteta (gotovi proizvodi, narudžbe itd.).

Objekti sučelja poslovnog procesa koji se proučava:

• 1. Voditelj službe za korisnike. Atributi: puno ime, pozicija, plaća. Odgovornosti: komunicira s kupcima, postavlja narudžbe, prihvaća plaćanja od kupaca za narudžbe.
• 2. Financijski odgovoran skladištar. Atributi: puno ime, pozicija, plaća. Odgovornosti: komunicirati s dobavljačima, prihvaćati materijale i potpisivati ​​fakture.
• 3. Vozač dostavljač. Atributi: puno ime, pozicija, plaća. Odgovornosti: Isporuka gotovog proizvoda naručitelju.

Kontrolni objekti poslovnog procesa koji se proučava:

• 1. Dizajner. Atributi: puno ime, pozicija, plaća. Odgovornosti: dizajn proizvoda, upravljanje projektima, kontrola.
• 2. Operater automatizirano računovodstvo. Atributi: puno ime, pozicija, plaća. Odgovornosti: vođenje automatizirane evidencije, rad s bazom podataka.
• 3. Majstor namještaja (montažer). Atributi: puno ime, pozicija, plaća. Odgovornosti: Izrada proizvoda prema projektu.

Objekti entiteta poslovnog procesa koji se proučava:

• 1. Ček - dokument koji se izdaje prilikom plaćanja narudžbe.
• 2. Katalog - dokument koji odražava asortiman proizvoda.
• 3. Narudžbenica - dokument koji sadrži broj narudžbe, datum narudžbe, podatke o kupcu, odabranu vrstu, skicu proizvoda, želje kupca.
• 4. Dizajn proizvoda - dizajn naručenog namještaja.
• 5. Zahtjev za materijale - karakterističan dokument potrebne materijale i njihove zapremine.
• 6. Baza podataka - program koji omogućuje vođenje materijalne evidencije u poduzeću.
• 7. Materijali - potrebni za izradu proizvoda po narudžbi.
• 8. Faktura - dokument koji se potpisuje prilikom otpreme materijala.
• 9. Gotov proizvod je rezultat proizvodnje, karakteriziran pripadanjem bilo kojem redu.

Tablica 5.1 daje opis međusobnog odnosa objekata.

Tablica 5.1 Opis načina na koji objekti međusobno djeluju

	Komunikacijski objekti	Vrsta komunikacije
	Klijent - Account Manager	komunikacijski stav	Klijent kontaktira upravitelja radi narudžbe za proizvodnju namještaja
	Menadžer – Klijent	komunikacijski stav	Voditelj daje klijentu katalog mogućih skica proizvoda
	Klijent - Katalog	omjer korištenja	Klijent odabire odgovarajuću skicu
	Klijent - Voditelj	komunikacijski stav	Klijent izražava svoj izbor i želje
	Menadžer – Klijent	komunikacijski stav	Voditelj objašnjava uvjete i termine
	Klijent - Voditelj	komunikacijski stav	Klijent plaća narudžbu
	Upravitelj - Provjerite	omjer korištenja	Upravitelj ispisuje ček
	Menadžer – Klijent	komunikacijski stav	Menadžer daje ček klijentu
	Voditelj - Narudžbenica	omjer korištenja	Voditelj kreira narudžbenicu
	Voditelj - Dizajner	komunikacijski stav	Voditelj nosi narudžbenicu dizajneru u odjelu dizajna
	Dizajner - Narudžbenica	omjer korištenja	Dizajner prihvaća narudžbenicu
		omjer korištenja	Dizajner razvija projekt
	Dizajner - Dizajn proizvoda	omjer korištenja	Projektant ocjenjuje projekt
	Dizajner - zahtjev za materijal	omjer korištenja	Dizajner kreira zahtjev za materijale
	Dizajner - Automatizirani računovodstveni operater	komunikacijski stav	Projektant podnosi zahtjev za materijale operateru automatiziranog računovodstva
	Automatizirani računovodstveni operater - Zahtjev za materijale	omjer korištenja	Automatizirani računovodstveni operater prihvaća prijave materijala
	Automatizirani računovodstveni operater - Baza podataka	omjer korištenja	Automatizirani računovodstveni operater provjerava raspoloživost potrebnog materijala s raspoloživim materijalom
	Financijski odgovoran skladištar - Dobavljači	komunikacijski stav	Materijalno odgovoran skladištar naručuje potrebne materijale od dobavljača
	Dobavljači - Financijski odgovoran skladištar	komunikacijski stav	Isporuka materijala
	Financijski odgovoran skladištar - Materijali	omjer korištenja	Prijem materijala
	Financijski odgovoran skladištar - Faktura	omjer korištenja	Potpisuje fakturu
	Financijski odgovoran skladištar - Inkasator	komunikacijski stav	Poruka o raspoloživosti materijala na skladištu
	Dizajner - Monter	komunikacijski stav	Prijenos dizajna proizvoda asembleru
	Asembler - Dizajn proizvoda	omjer korištenja	Sastavljač namještaja prima i proučava dizajn proizvoda
	Asembler - Gotov proizvod	omjer korištenja	Monter izrađuje proizvod
	Asembler - Dizajner	komunikacijski stav	Monter poziva dizajnera da kontrolira kvalitetu proizvoda
	Dizajner - Gotov proizvod	omjer korištenja	Kontrola kvalitete proizvoda
	Dizajner - Monter	komunikacijski stav	Dizajner daje ocjenu kvalitete proizvoda
	Asembler - Gotov proizvod	omjer korištenja	Ispravljanje nedostataka u gotovom proizvodu
	Inkasator - Vozač otpremnik	komunikacijski stav	Predaja narudžbenice i gotovog proizvoda vozaču otpremniku
	Vozač dostavljač - Klijent	komunikacijski stav	Prijenos gotovog proizvoda

Napomena: Ako su potrebni materijali na zalihi, tada se paragrafi 18, 19, 20, 21 ove tablice preskaču.

Dinamički model interakcije između odjela i kupca u presedanu "Prodaja proizvoda po narudžbi" prikazan je na slici 5.1. Dinamički model interakcije između odjela, zaposlenika i kupca u presedanu "Naručivanje" prikazan je na slici 5.2 Dinamički model interakcije između odjela, zaposlenika i kupca u presedanu “Design” prikazan je na slici 5.3. Dinamički model interakcije zaposlenika, u presedanu “Manufacturing” prikazan je na slici 5.4.

Slika 5.1 Dijagram slijeda slučaja upotrebe prodaje prilagođenog proizvoda

Slika 5.2 Dijagram redoslijeda slučaja upotrebe "Narudžba".

Slika 5.3 Dijagram slijeda slučaja upotrebe dizajna

Slika 5.4 Dijagram redoslijeda slučaja uporabe u proizvodnji

Konceptualna osnova objektno orijentiranog pristupa je objektni model. Glavni principi njegove izgradnje su:

· apstrakcija;

· kapsuliranje;

· modularnost;

· hijerarhija.

Apstrakcija je izdvajanje najvažnijih, bitnih karakteristika nekog predmeta, koje ga izdvajaju od svih drugih vrsta objekata i time jasno određuju njegove pojmovne granice sa stajališta daljnjeg razmatranja i analize, a zanemarivanje manje bitnih ili beznačajnih pojedinosti.

Apstrakcija vam omogućuje upravljanje složenošću sustava fokusiranjem na bitna svojstva objekta. Apstrakcija usmjerava pažnju na vanjske značajke objekt i omogućuje vam da odvojite najbitnije značajke njegovog ponašanja od detalja njihove implementacije. Izbor ispravan set apstrakcije za dano predmetno područje predstavlja glavni zadatak objektno orijentirani dizajn. Apstrakcija ovisi o domeni i gledištu - ono što je važno u jednom kontekstu ne mora biti važno u drugom. Objekti i klase su osnovne apstrakcije domene.

Enkapsulacija je fizička lokalizacija svojstava i ponašanja unutar jedne apstrakcije (koja se smatra "crnom kutijom"), skrivajući njihovu implementaciju iza javnog sučelja.

Enkapsulacija je proces međusobnog odvajanja pojedinačni elementi objekt koji određuje njegovu strukturu i ponašanje. Enkapsulacija služi za izoliranje sučelja objekta, koje odražava njegovo vanjsko ponašanje, od unutarnje implementacije objekta. Objektni pristup pretpostavlja da su izvorni resursi, kojima se može manipulirati samo operacijama samog objekta, skriveni od vanjsko okruženje. Apstrakcija i enkapsulacija su komplementarne: apstrakcija usmjerava pozornost na vanjske značajke objekta, dok enkapsulacija (ili drugačije ograničavanje pristupa) sprječava korisničke objekte da razaznaju unutarnju strukturu objekta.

Enkapsulacija je slična konceptu skrivanja informacija. To je sposobnost skrivanja brojnih detalja predmeta od vanjskog svijeta. Vanjski svijet objekt je sve što je izvan njega, uključujući ostatak sustava. Skrivanje informacija pruža istu prednost kao i enkapsulacija: fleksibilnost.

Modularnost je svojstvo sustava povezano s mogućnošću njegove dekompozicije na više unutarnje jako spregnutih, ali međusobno slabo povezanih podsustava (modula).

Modularnost smanjuje složenost sustava dopuštajući neovisan razvoj pojedinačnih modula. Enkapsulacija i modularnost stvaraju prepreke između apstrakcija.

Hijerarhija je rangirani ili uređeni sustav apstrakcija, njihov raspored po razinama.

Glavne vrste hijerarhijskih struktura u odnosu na složeni sustavi su struktura klasa (hijerarhija po nomenklaturi) i struktura objekata (hijerarhija po sastavu). Primjeri hijerarhije klasa su jednostavni i višestruko nasljeđivanje(jedna klasa koristi strukturni ili funkcionalni dio, odnosno, jedne ili više drugih klasa), a hijerarhije objekata su agregacija.

Nastava se može organizirati kao hijerarhijska struktura, koji prema izgled nalikuje klasifikacijskoj shemi u pojmovnoj logici. Hijerarhija pojmova konstruirana je na sljedeći način. Najopćenitijim pojmom ili kategorijom smatra se onaj pojam koji ima najveći obujam i prema tome najmanji sadržaj. Ovo je najviše visoka razina apstrakcije za datu hijerarhiju. Zatim dano opći koncept specificira se, odnosno smanjuje mu se volumen, a povećava sadržaj. Pojavljuje se manje općeniti koncept koji će u hijerarhijskom dijagramu biti smješten jednu razinu ispod izvornog. Ovaj proces konkretiziranja pojmova može se nastaviti sve do niža razina neće se dobiti koncept čija je daljnja specifikacija u ovom kontekstu ili nemoguća ili nepraktična.