is250 arhitekturaitsistemaorganizacije is250 arhitekturaitsistemaorganizacije l10

Lekcija 10 - Izrada TOGAFmodela IS i tehnički sloj

| Contents | 2

Contents

LearningObject................................................................ 3Poslovna arhitektura: Katalozi, matrice i diagrami.......................................................... 3TOGAF: IS arhitektura...................................................................................................... 3TOGAF: IS arhitektura-Podaci o servisima....................................................................... 5TOGAF: IS arhitektura-System Use case..........................................................................7TOGAF: IS arhitektura-System Use case- Vežba.............................................................. 9TOGAF: IS arhitektura- Dijagrami koji se koriste na nivou aplikativne arhitekture......... 13TOGAF: IS arhitektura- Dijagrami koji se koriste na nivou aplikativne arhitekture-

vežba..........................................................................................................................16TOGAF: IS arhitektura- Arhitektura podataka................................................................ 17TOGAF: IS arhitektura- Arhitektura podataka................................................................ 19TOGAF: IS arhitektura- Ostali dijagrami za pretstavljanje arhitekture podataka............ 20TOGAF: IS arhitektura- Ostali dijagrami za pretstavljanje arhitekture podataka............ 23TOGAF: Tehnička arhitektura......................................................................................... 24TOGAF: Tehnička arhitektura......................................................................................... 27Poslovni sloj: Katalozi, matrice i diagrami..................................................................... 29

| LearningObject | 3

LearningObject

Poslovna arhitektura: Katalozi, matrice i diagrami

UvodPrateći pristup koga se treba pridržavati prilikom izrade arhitekture preduzeća, u ovompredavanju se govori o slojevima IS i tehničke arhitekture. Na nivou IS arhitekture sedefinišu Aplikativna arhitektura (Application architecture) i i Arhitektura podataka (Dataarchitecture).U daljem tekstu će biti detaljno opisan način na koji se definiše svaki od ovihslojeva.

TOGAF: IS arhitektura

Cilj• Objasniti pristup koji treba koristiti prilikom izrade TOGAF modela

TOGAF: IS arhitekturaAplikativna arhitektura se modelira u okviru Paketa <<application architecture>>. Glavnielementi modela su aplikativne komponenete sa odgovarajućim IS servisima koje obezbedjujuili traže od drugih aplikativnih komponenti.

Na nivou aplikativne arhitekture se koriste sledeće vrste dijagrama:

• Solution Concept diagrams: koji omogućava sagledavanje čitavog rešenja na globalnomnivou, koje se previ kako bi se opravdalo angažovanje arhitekata preduzeća

•• Application and User Location diagram koji prikazuje geografsku distribuciju aplikacija.•• Enterprise Manageability diagrams prikazuje u kakvoj su interakciji jedna ili više aplikacija

sa aplikativnim ili tehnološkim komponentama koje podržavaju upravljanje operativnimrešenjem.

•• Process/System Realization diagram jasno opisuje sekvencu događaja u slučaju kada je

više aplikacija obuhvaćeno prilikom izvršenja poslovnog procesa.•• Project Context diagrams - prikazuje područjejednog paketa kojeg treba implementirati kao

deo neke veće mape transformacije.•• Benefits diagrams - prikazuje mogućnosti koje su identifikovane prilikom definicije

arhitekture, a koje su klasifikovane prema svojoj relativnoj veličini, benefitima I složenošću.

Na sledećoj slicu je prikazana arhitektura Aplikativnog sloja.

Slika 1. Struktura domena Aplikativna arhitektura

TOGAF: IS arhitektura-Podaci o servisima

TOGAF: IS arhitektura-podaci o servisimaNalaze se u paketu <<application domain>>, <<service data>> i sadrže model poruka ilidelova (fragmenata) poruka. Spomenute poruke sačinjavaju informacije koje se razmenjujuizmeđu IS servisa. Iz ovog modela, Modelio može da generiše XSD šemu. Poruke se mogukoristiti kao jedna vrsta parametara servisa.

Da bi bilo jasnije čemu ove poruke služe, ponovićemo još jednom način na koji se vrširazmena poruka između servisa na kojima se bazira SOA (Sevisno orijentisana arhitektura).

Svaki servis se sastoji od jedne ili više operacija. Svaka operacija upravlja obradom specifičnefunkcije koju je Web servis u stanju da izvršava. Obrada se sastoji od SOAP poruka koje sešalju i primaju što je prikazano na slici “Operacija koja obrađuje odlazece i dolazece SOAPporuke”.

Slika: Operacija koja obrađuje odlazece i dolazece SOAP poruke

Komponovanjem ovih delova, Web servisi formiraju aktivnosti kroz koje se automatizuje nekizadatak (slika „Scenario komunikacije između Web servisa“)

Slika: Scenario komunikacije između Web servisa

Service data diagram: Pretstavlja statički dijagram. Na sledećoj slici je pretstavljen Servisdata dijagram za kompaniju TripRezervation. Na dijagramu su prikazane prethodno definisaneporuke ili fragmeti poruka koje su smeštene ispod paketa <<application domain>>,<<service data>>

Slika: Service data diagram za kompaniju TripReservation

TOGAF: IS arhitektura-System Use case

TOGAF: IS arhitektura-System Use caseModeliraju se u okviru paketa <<application domain>>, <<system use case>>.

Za Use case-ove se mogu vezivati Akteri i njihove role. U njima se takođe mogu prikazatiaplikativne komponente koje realizuju prikazane Use case-ove, i svaka od njih je sarelevantnim Use case-ovima povezana vezom "component realization dependency".

Na sledećoj slici je prikazan jedan od Sistemskih Use case-ova za kompaniju TripRezervation.Na slici su pored sistemskih Use case-ova pretstavljene i aplikativne komponente kojima ćeovi Use case-ovi biti realizovani.

Slika: Sistemski Use case dijagram za kompaniju TripReservation

Za realizaciju ovih Use case-ova su korišćene sledeće komponente:

• Trip – koja pretstavlja Entity application komponentu• Order – koja takođe pretstavlja Entity application komponenta• Reserve Trip – koja pretstavlja Process application komponenta• Invoicing – koja takođe pretstavlja Process application komponenta

Na sledećem sistemskom Use case dijagramu se vidi upotreba još jedne aplikativnekomponente-TripReservationSite.

Slika: Slika: Sistemski Use case II dijagram za kompaniju TripReservation

Aplikativna komponenta TripReservationSite pretstavlja interface komponentu kojima seobično pretstavljaju Web site-ovi. Svaka interface komponenta pretstavlja jedan servis.

Tako se može reći da se Entity application komponente koriste u okviru razvojne strategijearhitekture i pretstavljaju trajno zapamćene podatke korišćene od strane aplikacija. Processapplication komponente pretstavljaju komponente kojima se izvršava neka obrada dokinterface component pretstavljaju komponente za interakciju kojima pristupaju različiti akteri irole.

Pored ovih najčešće korišćenih aplikativnih komponenti mogu se koristiti još utilitykomponente, komponente za posredovanje (intermediary component) nasleđene bazepodataka itd.

Aplikativne komponente se smeštaju u ispti paket kao i Use case na koga se odnose.

Na sledećoj slici je prikazana Matrica - Use cases-Components koja pokazuje koji su Use case-ovi realzovani jednom aplikativnom komponentom. Ovo može biti veoma koristan dijagramjer prikazuje funkcionalnost svake aplikativne komponente.

,Slika: Matrica - Use cases-Aplikativna komponenta za kompaniju TripRezervation

TOGAF: IS arhitektura-System Use case- Vežba

TOGAF: IS arhitektura- System Use case- Vežba:Opis sistema:

PRU je turistička kompanija sa više zaposlenih. U poslednje vreme, posao je naglo porastaoi vlasnik ove kompanije želi da uvede nov informacioni sistem za upravljanje procesimanaručivanja i kupovine. PRU ima skup od deset standardnih menija kojima se nude različitiaranžmani za odlazak na piknik. Kada potencijalni kupac pozove, Menadžer prodaje mu najpreopiše raspoložive menije. Ukoliko kupac odluči da rezerviše jedan od ponuđenih aranžmana,Menadžer prodaje zapisuje informacije o kupcu (npr. ime, adresa, broj telefona itd.) iinformacije o kupljenom aranžmanu (mesto, datum, vreme, meni kojem pripada, ukupnacena) u ugovor. Kupcu se zatim putem faksa šalje kopija ugovora koju mora da potpiše ipošalje je nazad zajedno sa depozitom (broj kreditne kartice ili ček) pre nego što se aranžmanzvanično rezerviše. Ostatak novca se čuva sve dok se aranžman ne završi. Ponekad, kupac

može da zaželi nešto posebno (npr. rođendansku tortu). U takvim situacijama, Menadžerprodaje uzima informacije i šalje ih vlasniku, koji određuje cenu; recepcionar tada ponovopoziva kupca i daje mu informacije o ceni.

Nekada, kupac može da prihvati cenu, dok u drugim situacijama može da traži izmene štočitav postupak vraća nazad na vlasnika koji treba da odredi novu cenu. Svakog vikenda,vlasnik proučava raspored putovanja za naredni viked i šalje porudžbine ka dobavljačima(npr. za tanjire, hleb, piletinu itd.) Vlasnik takođe želi da novi sistem koristi za potrebemarketiga, u okviru kojeg bi pratio način na koji su kupci došli do informacija o PRU,identifikovao kupce koji su više puta koristili njihove aranžmane kako bi im PRU ponudilaspecijalne ponude. Vlasnik takođe želi da prati aranžmane za koje je PRU poslala ugovore aliih kupci nisu potpisali.

Zadatak:

Za opisani sistem:

Uradite sistemski Use case/ Use case-ove, kojima se može podržati ovaj informacionisistem. Identifikujte aplikativne komponente za realizaciju ovog sistema. Prilikom unošenjaaplikativnih komponenti vodite računa o strukturi aplikativnog sloja i napravite je što slučnijenačinu koji je prikazan u predavanjima.

Rešenje zadataka:

Da bi se identifikovali sistemski Use case-ovi tj. funkcionalnost aplikacije koju aplikacija trebada obezbedi za buduće korisnike, pošlo se od aktera sistema koji su identifikovati prilikomdizajniranja poslovne arhitekture. To su Kupac, Administrator, Vlasnik i Menadžer prodaje.Za svaki od njih je napravljen jedan ili više Sistemskih Use case-ova koji opisuju funkcije kojesistem treba da za njih obezbedi.

Sistemski Use case za aktera administrator

Slika: Sistemski Use case za aktera administrator

Mada u opisu problema nisu eksplicitno opisane funkcije sistema koje treba obezbediti zaadministratora, na slici su prikazani Use case-ovi koje ovaj acter svakako mora da izvrši. Onise realzuju entity aplikativnom komponentom Aranžmani i meniji.

Sistemski Use case za aktera Kupac

Slika: Sistemski Use case za aktera Kupac

Na slici su prikazaci slučajevi korisšćenja koje sistem treba da izvrši za aktera kupac. Usecase-ovi su realizovani koriščenjem komponente za interakciju koja pretstavlja Web sitekompanije PRU i procesne komponente Obrada zahteva kupaca.

Sistemski Use case za aktera menadžer prodaje

Slika: Sistemski Use case za aktera menadžer prodaje

Menadžer prodaje Pregledavanja rezervisanih aranžmana izvršava preko interfejs aplikativnekomponente PRU Web site, dok se Use case sklapanje ugovora realizuje preko entitykomponente Ugovori.

Sistemski Use case za aktera vlasnik

Slika: Sistemski Use case 1 za aktera vlasnik

Slika: Sistemski Use case 2 za aktera vlasnikFunkcionalnost aplikacije koju je neophodno obezbediti za aktera Vlasnik se može realizovatipreko tri navedene aplikativne komponente:• Entity aplikativne komponente Specijalni zahtevi• Procesne aplikativne komponente Nabavka• Procesne aplikativne komponente Marketinška analiza

TOGAF: IS arhitektura- Dijagrami koji se koriste na nivouaplikativne arhitekture

TOGAF: IS arhitektura- Dijagrami koji se koriste na nivou aplikativne arhitektureOvde je prikazano nekoliko vrsti dijagrama koji se koriste za opis Aplikativne arhitekture i zakoje su dati odgpvarajući primeri za kompaniju TripReservation. To su:

Project context diagram, prikazan na slici “Project context diagram ya kompanijuTripReservation”. Prikazuje područje jednog paketa kojeg treba implementirati kao deo nekeveće mape transformacije.

Slika: Project context diagram za kompaniju TripReservation

Enterprise Manageability diagrams prikazuje u kakvoj su interakciji jedna ili više aplikacijasa aplikativnim ili tehnološkim komponentama koje podržavaju upravljanje operativnimrešenjem.

Slika: Enterprise Manageability diagram na primeru kompanije TripReservation

Process/System Realization diagram jasno opisuje sekvencu događaja u slučaju kada je višeaplikacija obuhvaćeno prilikom izvršenja poslovnog procesa.

Benefits diagrams - prikazuje mogućnosti koje su identifikovane prilikom definicijearhitekture, a koje su klasifikovane prema svojoj relativnoj veličini, benefitima i složenošću.

Slika: Benefit dijagram za kompaniju TripReservation

Application communication diagram

Slika: Application communication diagram na primeru kompanije TripReservation

TOGAF: IS arhitektura- Dijagrami koji se koriste na nivouaplikativne arhitekture-vežba

TOGAF: IS arhitektura- Dijagrami koji se koriste na nivou aplikativne arhitekture-vežbaOpis sistema:

PRU je turistička kompanija sa više zaposlenih. U poslednje vreme, posao je naglo porastaoi vlasnik ove kompanije želi da uvede nov informacioni sistem za upravljanje procesimanaručivanja i kupovine. PRU ima skup od deset standardnih menija kojima se nude različitiaranžmani za odlazak na piknik. Kada potencijalni kupac pozove, Menadžer prodaje mu najpreopiše raspoložive menije. Ukoliko kupac odluči da rezerviše jedan od ponuđenih aranžmana,Menadžer prodaje zapisuje informacije o kupcu (npr. ime, adresa, broj telefona itd.) iinformacije o kupljenom aranžmanu (mesto, datum, vreme, meni kojem pripada, ukupnacena) u ugovor. Kupcu se zatim putem faksa šalje kopija ugovora koju mora da potpiše ipošalje je nazad zajedno sa depozitom (broj kreditne kartice ili ček) pre nego što se aranžmanzvanično rezerviše. Ostatak novca se čuva sve dok se aranžman ne završi. Ponekad, kupacmože da zaželi nešto posebno (npr. rođendansku tortu). U takvim situacijama, Menadžer

prodaje uzima informacije i šalje ih vlasniku, koji određuje cenu; recepcionar tada ponovopoziva kupca i daje mu informacije o ceni.

Zadatak:

Za opisani sistem uraditeApplication communication diagram

Rešenje:

Slika: Application communication diagram za PRU kompaniju

Sve aplikativne komponenete na ovom dijagramu su prikazane na prethodno definisanimsistemskim Use case dijagramima, na kojima se vide i Use case-ovi koji su realzovani odstrane svake od ovih komponenti.

TOGAF: IS arhitektura- Arhitektura podataka

TOGAF: IS arhitektura- Arhitektura podatakaNa sledećoj slici je prikazana struktura sloja podataka koja je definisana na nivou Aplikativnearhitekture.

Slika: Struktura sloja arhitekture podataka

Business entities (poslovni entiteti): nalaze se ispod paketa <<DataModel>> U okviruovog domena, podaci se modeliraju na konceptualnom nivou. Fokus se ne stavlja naperzistentno modeliranje (modeliranja podataka koje treba trajno pamtiti). Da bi se u okviruaplikativne arhitekture dobio perzistentni model podataka, može se koristiti "Togaf" menuza automatsko generisanja perzistentnog modela na nivou aplikativne arhitekture i/iligenerisanje aplikativnih komponenti iz modela poslovnih entiteta.

Perzistentni model se prikazuje Logical data diagramom.

Slika: Logical data diagram za kompaniju TripReservation

TOGAF: IS arhitektura- Arhitektura podataka

TOGAF: IS arhitektura- Arhitektura podatakaOpis sistema:

PRU je turistička kompanija sa više zaposlenih. U poslednje vreme, posao je naglo porastaoi vlasnik ove kompanije želi da uvede nov informacioni sistem za upravljanje procesimanaručivanja i kupovine. PRU ima skup od deset standardnih menija kojima se nude različitiaranžmani za odlazak na piknik. Kada potencijalni kupac pozove, Menadžer prodaje mu najpreopiše raspoložive menije. Ukoliko kupac odluči da rezerviše jedan od ponuđenih aranžmana,Menadžer prodaje zapisuje informacije o kupcu (npr. ime, adresa, broj telefona itd.) iinformacije o kupljenom aranžmanu (mesto, datum, vreme, meni kojem pripada, ukupnacena) u ugovor. Kupcu se zatim putem faksa šalje kopija ugovora koju mora da potpiše ipošalje je nazad zajedno sa depozitom (broj kreditne kartice ili ček) pre nego što se aranžmanzvanično rezerviše. Ostatak novca se čuva sve dok se aranžman ne završi. Ponekad, kupacmože da zaželi nešto posebno (npr. rođendansku tortu). U takvim situacijama, Menadžerprodaje uzima informacije i šalje ih vlasniku, koji određuje cenu; recepcionar tada ponovopoziva kupca i daje mu informacije o ceni.

Zadatak:

Za opisani sistem uradite Logical Data dijagram

Rešenje zadataka:

Slika: Logical data dijagram

TOGAF: IS arhitektura- Ostali dijagrami za pretstavljanjearhitekture podataka

TOGAF: IS arhitektura- Arhitektura podatakaTu spadaju:

Data security diagram

Slika: Data security diagram za kompaniju TripReservation

Data migration diagram

Slika: Data migration diagram za kompaniju TripReservation

Data dissemination diagram

Slika: Data dissemination diagram za kompaniju TripReservation

TOGAF: IS arhitektura- Ostali dijagrami za pretstavljanjearhitekture podataka

TOGAF: IS arhitektura- Arhitektura podatakaOpis sistema:

PRU je turistička kompanija sa više zaposlenih. U poslednje vreme, posao je naglo porastaoi vlasnik ove kompanije želi da uvede nov informacioni sistem za upravljanje procesima

naručivanja i kupovine. PRU ima skup od deset standardnih menija kojima se nude različitiaranžmani za odlazak na piknik. Kada potencijalni kupac pozove, Menadžer prodaje mu najpreopiše raspoložive menije. Ukoliko kupac odluči da rezerviše jedan od ponuđenih aranžmana,Menadžer prodaje zapisuje informacije o kupcu (npr. ime, adresa, broj telefona itd.) iinformacije o kupljenom aranžmanu (mesto, datum, vreme, meni kojem pripada, ukupnacena) u ugovor. Kupcu se zatim putem faksa šalje kopija ugovora koju mora da potpiše ipošalje je nazad zajedno sa depozitom (broj kreditne kartice ili ček) pre nego što se aranžmanzvanično rezerviše. Ostatak novca se čuva sve dok se aranžman ne završi. Ponekad, kupacmože da zaželi nešto posebno (npr. rođendansku tortu). U takvim situacijama, Menadžerprodaje uzima informacije i šalje ih vlasniku, koji određuje cenu; recepcionar tada ponovopoziva kupca i daje mu informacije o ceni.

Zadatak:

Za opisani sistem uradite Data dissemination diagram

Rešenje zadataka:

Slika: Data dissemination diagram za PRU kompaniju

TOGAF: Tehnička arhitektura

TOGAF: Tehnička arhitekturaNalazi se u paketu <<technology architecture>>. Pod tehničkom arhitekturom sepodrazumeva kreiranje dokumentacije koja se odnosi na korišćenje uređaja ili tehnologija. Podefinisanim uređajima (najčešće serverima i radnim stanicama) treba razmestiti prethodnoizdvojene elemente Aplikativne arhitekture.

Za definisanje tehničke arhitekture koriste se kao što je rečeno sledeće vrste dijagrama:

Environments and Locations diagrams: opisuje koje se aplikacije hostuju na kojim lokacijama,identifikuju koje se tehnologije i/ili aplikacije koriste na kojim lokacijama i na kraju identifikujulokacije sa kojih su poslovni korisnici najčešće u interakciji sa aplikacijama.

Slika: Environments and Locations diagrams za kompaniju TripReservation

Software Distribution diagrams: prikazuje na koji su način softverske aplikacije struktuirane idistribuirane.

Platform Decomposition diagrams: opisuje tehnološku platform koja podržava operativni radarhitekture informacionog sistema.

Network computing hardware diagrams: prikazuje kako su aplikativne komponenteraspoređene u distribuiranom mrežnom okruženju

Slika: Network computing hardware diagrams za kompaniju TripReservation

Processing diagrams: fokusiran je na prikaz načina na koji su jedinice koda razmeštene natehnološkoj platform.

Slika: Processing diagrams za kompaniju TripReservation

TOGAF: Tehnička arhitektura

TOGAF: Tehnička arhitekturaOpis sistema:

PRU je turistička kompanija sa više zaposlenih. U poslednje vreme, posao je naglo porastaoi vlasnik ove kompanije želi da uvede nov informacioni sistem za upravljanje procesimanaručivanja i kupovine. PRU ima skup od deset standardnih menija kojima se nude različitiaranžmani za odlazak na piknik. Kada potencijalni kupac pozove, Menadžer prodaje mu najpreopiše raspoložive menije. Ukoliko kupac odluči da rezerviše jedan od ponuđenih aranžmana,Menadžer prodaje zapisuje informacije o kupcu (npr. ime, adresa, broj telefona itd.) iinformacije o kupljenom aranžmanu (mesto, datum, vreme, meni kojem pripada, ukupna

cena) u ugovor. Kupcu se zatim putem faksa šalje kopija ugovora koju mora da potpiše ipošalje je nazad zajedno sa depozitom (broj kreditne kartice ili ček) pre nego što se aranžmanzvanično rezerviše. Ostatak novca se čuva sve dok se aranžman ne završi. Ponekad, kupacmože da zaželi nešto posebno (npr. rođendansku tortu). U takvim situacijama, Menadžerprodaje uzima informacije i šalje ih vlasniku, koji određuje cenu; recepcionar tada ponovopoziva kupca i daje mu informacije o ceni.

Pod pretpostavkom da se ovaj sistem prostire na tri lokacije: Njujork, Čikago i Vašington ida se kao što je to opisano u poslovnoj arhitekturi na lokaciji Njujorka gde se nalazi sedištekompanije izvršavaju svi poslovni procesi, dok se na lokacima Čikago i Vašington obavljajusamo poslovi prodaje, nacrtajte sledeće vrste dijagrama:

Environments and Locations diagramsNetwork computing hardware diagrams

Rešenje zadatka:

Slika: Environments and Locations diagrams2.

Slika: Network computing hardware diagrams

Poslovni sloj: Katalozi, matrice i diagrami

ZaključakU predavanju se govorilo o TOGAF modelima kojima se može pretstaviti IS i Tehnološki slojbuduće arhitekture preduzeća.

is250 arhitekturaitsistemaorganizacije is250 arhitekturaitsistemaorganizacije l10

koriste sledee vrste

system use case

nivou aplikativne arhitekture

Documents

new lexus is250 - carnaviplayer.com

l10, l11, l11/9, l15 · l10/1, l10/2, l10/3, l10/4, l10/5,...

sl for is250 6 8 10

sl for is250 6 7 10

l10, l11, l11/9,...

l10, l11, l11/9, l15 - 3b scientific · 2020-01-15 · 4...