Dërgoni punën tuaj të mirë në bazën e njohurive është e thjeshtë. Përdorni formularin e mëposhtëm

Studentët, studentët e diplomuar, shkencëtarët e rinj që përdorin bazën e njohurive në studimet dhe punën e tyre do t'ju jenë shumë mirënjohës.

Postuar në http://www.allbest.ru/

Instituti Shtetëror i Shërbimit Omsk

Modelimi i sistemeve të informacionit duke përdorur gjuhën UML

Udhëzime metodike për zbatimin e punimit terminor

I.V. Chervenchuk

• Prezantimi
• 2 . Gjuha e unifikuar e modelimitUML
• 4. Zhvillimi i një modeli të sistemit softuerik me mjeteUML
• 5. Pyetje të zbatimit të sistemit të informacionit
• 6. Temat e lëndës
• Lista bibliografike

Prezantimi

Punimi trajton zhvillimin e sistemeve të informacionit duke përdorur gjuhën e unifikuar të modelimit UML, e cila është bazë për punën e kursit në disiplinën "Sistemet dhe proceset e informacionit. Modelimi dhe menaxhimi". Fazat kryesore të një procesi racional të unifikuar të zhvillimit të sistemeve të informacionit po përpunohen, jepen shembuj dhe ilustrime. Janë dhënë mundësitë për detyra për lëndët.

Udhëzimet metodike janë të destinuara për studentët e specialitetit "Informatikë e Aplikuar" dhe mund të përdoren në lëndët, përgatitjen për provim, si dhe në procesin e punës së pavarur.

1. Kërkesat e përgjithshme për zbatimin e punimit termik

Puna e kursit në disiplinën "Sistemet dhe proceset e informacionit. Modelimi dhe menaxhimi" është faza përfundimtare e studimit të këtij kursi dhe është projektuar për të konsoliduar në praktikë njohuritë bazë teorike të modelimit të sistemeve të informacionit. Puna konsiston në zhvillimin e një modeli të një sistemi informacioni me anë të gjuhës së unifikuar të modelimit UML me zbatimin e tij të mëvonshëm. Si një variant tipik i detyrës, propozohet të zhvillohet një sistem informacioni dhe referimi bazuar në një bazë të dhënash, por me kërkesë të studentit, në marrëveshje me mësuesin, zhvillimi i një aplikacioni WEB, sistemi testimi ose pajisje harduerike mund të të ofrohet si detyrë. Në të njëjtën kohë, parakushti kryesor është përdorimi i një qasjeje të orientuar nga objekti dhe ndërtimi i një modeli UML.

Titulli tipik i punimit termik duket si "Zhvillimi i një sistemi informacioni dhe referimi _ titullin _ "

Prezantimi

1. Pasqyrë thelbësore e fushës lëndore. Kërkesat bazë të sistemit

2. Një model i detajuar i sistemit të informacionit

2.1 Pamje nga këndvështrimi i rasteve të përdorimit

2.2 Pamja e projektimit

2.3 Pamja e zbatimit

2.4 Perspektiva e procesit (nëse është e aplikueshme)

2.5 Pamje nga pikëpamja e vendosjes (nëse është e nevojshme)

3. Zbatimi i sistemit të informacionit

konkluzioni

Lista e aplikacioneve të një programi ose moduli kreu

Në hyrje mund të theksohet përdorimi i teknologjisë së informacionit në fusha të ndryshme të veprimtarisë, duke përfshirë sektorin e shërbimeve, avantazhet e kontabilitetit elektronik, problemet e ndërtimit të sistemeve të specializuara të informacionit, etj.

Këto udhëzime përmbajnë rekomandime të detajuara për seksionet kryesore të shënimit shpjegues dhe shembujt e projektimit. Duhet të theksohet se lënda kryesore e kësaj pune të kursit është zhvillimi i një modeli UML të një sistemi informacioni, prandaj rekomandohet fuqimisht që diagramet UML të jepen në pjesën kryesore të një shënimi shpjegues, duke u dhënë atyre komente të hollësishme. , dhe tekstet e programeve duhet të vendosen në aplikacion.

Pamja e procesit duhet të jepet gjatë dizajnimit të sistemeve me shumë detyra. Pamja e vendosjes supozon një sistem informacioni të shpërndarë. Këto lloje, dhe pjesët përkatëse të shënimit shpjegues, nuk janë të detyrueshme për zbatimin e kësaj pune kursi, përdorimi i tyre supozohet kur kryhen vetëm disa variante të punës së kursit.

Kur nënvizoni çështjet e zbatimit të sistemit në një shënim, këshillohet të justifikoni zgjedhjen e një mjedisi programimi, të siguroni një manual përdorimi. Një element i detyrueshëm është përfshirja e formularëve të ekranit (screen-shorts) të programit të zbatuar në tekst, inkurajohet përdorimi i mjeteve të inxhinierisë së kundërt.

Në përfundim, rezultatet kryesore të punës përmblidhen shkurtimisht: është zhvilluar një model UML i sistemit, sistemi zbatohet duke përdorur një mjedis programimi të tillë që lejon sistemi i zhvilluar, avantazhet e qasjeve të përdorura (bazuar mbi modelimin) për projektimin e sistemeve.

modelimi i gjuhës së sistemit të informacionit

Puna e kursit duhet të përmbajë 20-30 faqe tekst të shtypur me ilustrime. Diagramet e rasteve të përdorimit, klasat, ndërveprimet duhet të sigurohen pa dështuar.

2. UML Gjuha e Unifikuar e Modelimit

Zhvillimi racional i një sistemi informacioni presupozon një studim të thellë paraprak analitik. Para së gjithash, është e nevojshme të përvijohet një gamë e detyrave të kryera nga sistemi që po zhvillohet, më pas, të zhvillohet një model i sistemit dhe së fundi, të përcaktohen metodat e zbatimit. Një studim i thellë i arkitekturës së sistemit të informacionit që po zhvillohet në fazat fillestare të projektimit, si rregull, shpërblehet më vonë, veçanërisht kur zhvillohen projekte në shkallë të gjerë me mbështetje afatgjatë.

Mjetet e gjuhës së modelimit UML (Unified Model Language, - një gjuhë programimi e unifikuar) lejojnë në mënyrë ekspresive dhe mjaft të lehtë të kryejnë një zhvillim konceptual paraprak të një sistemi informacioni, dhe në të njëjtën kohë, të shoqërojnë metodikisht të gjithë procesin e zhvillimit, duke përfshirë i gjithë cikli i mëtejshëm jetësor i sistemit të zhvilluar të informacionit si produkt softuer.

UML është një gjuhë e orientuar nga objekti për vizualizimin, specifikimin, ndërtimin dhe dokumentimin e objekteve të sistemeve softuerike.

UML, si çdo gjuhë tjetër, përbëhet nga një fjalor dhe rregulla që ju lejojnë të kombinoni fjalët e përfshira në të dhe të merrni ndërtime kuptimplote. Në një gjuhë modeluese, fjalori dhe rregullat përqendrohen në paraqitjen konceptuale dhe fizike të sistemeve të informacionit. Modelimi është thelbësor për të kuptuar sistemin. Thënë kjo, një model i vetëm nuk mjafton kurrë. Përkundrazi, për të kuptuar çdo sistem jo të parëndësishëm, duhet të zhvillohen një numër të madh modelesh të ndërlidhura. Siç zbatohet për sistemet softuerike, kjo do të thotë se nevojitet një gjuhë me të cilën është e mundur të përshkruhen nga këndvështrime të ndryshme përfaqësimet e arkitekturës së sistemit gjatë gjithë ciklit të zhvillimit të tij.

UML është një gjuhë vizualizimi dhe UML nuk është vetëm një koleksion simbolesh grafike. Secili prej tyre ka semantikë të mirëpërcaktuar (shih).Kështu, një model i shkruar nga një zhvillues mund të interpretohet pa mëdyshje nga një tjetër, apo edhe nga një paketë veglash.

UML është një gjuhë specifikimi. Në këtë kontekst, specifikim nënkupton ndërtimin e modeleve të sakta, të paqarta dhe të plota. UML lejon specifikimin e të gjitha vendimeve të rëndësishme të analizës, projektimit dhe zbatimit që duhet të merren gjatë zhvillimit dhe vendosjes së një sistemi softuerik.

UML është një gjuhë projektimi. Megjithëse UML nuk është një gjuhë programimi vizuale, modelet e krijuara me të mund të përkthehen drejtpërdrejt në gjuhë të ndryshme programimi specifike. Me fjalë të tjera, modeli UML mund të hartohet në gjuhë të tilla si Java, C ++, Visual Basic dhe madje edhe tabela të bazës së të dhënave relacionale ose objekte të vazhdueshme të bazës së të dhënave të orientuara nga objekti. Ato koncepte që preferohet të përcillen grafikisht janë të përfaqësuara në UML; ato që përshkruhen më mirë në formë teksti shprehen duke përdorur një gjuhë programimi.

Ky raportim i një modeli në një gjuhë programimi lejon dizajnimin e drejtpërdrejtë: gjenerimin e kodit nga një model UML në një gjuhë specifike. Ju gjithashtu mund të zgjidhni problemin e kundërt: rivendosni modelin nga zbatimi ekzistues. Natyrisht, modeli dhe zbatimi përfshin përdorimin e një numri entitetesh specifike. Prandaj, inxhinieria e kundërt kërkon instrumente dhe ndërhyrje njerëzore. Kombinimi i gjenerimit të kodit përpara dhe inxhinierisë së kundërt ju lejon të punoni në paraqitjet grafike dhe tekstuale për sa kohë që mjetet sigurojnë konsistencë midis të dy paraqitjeve.

Përveç hartës së drejtpërdrejtë në gjuhët e programimit, UML, për shkak të ekspresivitetit dhe paqartësisë së tij, ju lejon të ekzekutoni drejtpërdrejt modele, të simuloni sjelljen e sistemeve dhe të kontrolloni sistemet operative.

UML është një gjuhë dokumentimi

Një kompani softuerësh prodhon dokumente të tjera përveç kodit të ekzekutueshëm, duke përfshirë:

Kërkesat e sistemit;

arkitekturë;

projekti;

burimi;

planet e projekteve;

teste;

prototipe;

versionet, etj.

Në varësi të metodologjisë së miratuar të zhvillimit, disa punë kryhen më formalisht, të tjera më pak. Dokumentet e përmendura nuk janë vetëm pjesë të ofruara të projektit; ato janë të nevojshme për menaxhimin, për vlerësimin e rezultatit dhe gjithashtu si një mjet komunikimi midis anëtarëve të ekipit gjatë zhvillimit të sistemit dhe pas vendosjes së tij.

UML i siguron zhvilluesit dhe menaxhmentit mënyrën e tyre të zgjidhjes së problemit të dokumentimit të arkitekturës së sistemit dhe të gjitha detajeve të tij, siguron një gjuhë për formulimin e kërkesave të sistemit dhe përcaktimin e testeve, dhe në fund ofron një mjet për punën e modelimit gjatë planifikimit dhe versionit të projektit. faza e kontrollit.

Le të shqyrtojmë zhvillimin e një modeli të një sistemi informacioni me anë të gjuhës UML duke përdorur shembullin e zhvillimit të një stacioni pune të automatizuar për një sekretar departamenti (në tekstin e mëtejmë referuar si AWP e sekretarit të departamentit).

3. Përshkrimi i fushës lëndore

Koncepti i fushës lëndore të bazës së të dhënave është një nga konceptet bazë të shkencës kompjuterike dhe nuk ka përkufizim të saktë. Përdorimi i tij në kontekstin e IP-së presupozon ekzistencën e një korrelacioni të qëndrueshëm me kalimin e kohës midis emrave, koncepteve dhe realiteteve të caktuara të botës së jashtme, të pavarur nga vetë IP-ja dhe rrethi i saj i përdoruesve. Kështu, futja në konsideratë e konceptit të domenit të bazës së të dhënave kufizon dhe e bën hapësirën e marrjes së informacionit të dukshme në IS dhe bën të mundur ekzekutimin e pyetjeve në një kohë të kufizuar.

Nën përshkrimin e fushës lëndore nënkuptojmë përshkrimin e mjedisit të sistemit që zhvillohet, llojet e përdoruesve të sistemit, duke treguar edhe detyrat kryesore, zgjidhja e të cilave i është caktuar sistemit.

Në përshkrimin paraprak të fushës lëndore, futen termat bazë (fjalori i sistemit), përcaktohen llojet e përdoruesve dhe të drejtat e tyre, formulohen detyrat që sistemi i zhvilluar duhet të zgjidhë. Në këtë rast, përshkrimi supozohet të përdorë mjetet e gjuhës së zakonshme dhe grafikët standarde të biznesit (foto, diagrame, tabela).

Gjatë zhvillimit të një fjalori sistemi, është e nevojshme të përcaktohen emrat e subjekteve ("student", "mësues", "disiplinë"). Në këtë rast, termi esencë kuptohet nga ne si një përbërës i modelit të domenit, domethënë si një objekt i identifikuar tashmë në nivelin konceptual. Objektet e alokuara në fushën lëndore shndërrohen nga analisti në entitete.

Entiteti është rezultat i abstraksionit të një objekti real. Ka dy probleme që lidhen me objektet: identifikimi dhe përshkrimi adekuat. Për identifikim, përdoret një emër, i cili duhet të jetë unik. Në këtë rast, supozohet se ka një refuzim të kuptimit të tij, i cili është i natyrshëm në gjuhën natyrore. Përdoret vetëm funksioni tregues i emrit. Emri është një mënyrë e drejtpërdrejtë për të identifikuar një objekt. Metodat indirekte të identifikimit të objektit përfshijnë përcaktimin e një objekti përmes vetive të tij (karakteristikave ose shenjave).

Objektet ndërveprojnë me njëri-tjetrin nëpërmjet vetive të tyre, gjë që krijon situata. Situatat janë marrëdhënie që shprehin marrëdhëniet ndërmjet objekteve. Situatat në fushën e lëndës përshkruhen me anë të deklaratave për fushën e lëndës. Në këtë fazë, ju mund të përdorni metodat e llogaritjes propozicionale dhe llogaritjes së kallëzuesit, domethënë logjikës formale, matematikore. Për shembull, deklarata "Programuesi dhe menaxheri janë punonjës të kompanisë" përshkruan një marrëdhënie gjithëpërfshirëse. Kështu, të gjitha informacionet rreth objekteve dhe entiteteve të domenit përshkruhen duke përdorur deklarata në gjuhën natyrore.

Ju mund të specifikoni lidhjet strukturore, të nënvizoni situatat statike dhe dinamike (duke futur kështu një parametër kohor në model), megjithatë, për një studim të hollësishëm të modelit, është më i përshtatshëm të përdorni mjete të avancuara të përshkrimit të domenit, për shembull, mjetet e gjuhën UML.

Pra, detyra është të zhvillojë një sistem "stacioni pune të sekretarit të departamentit" që do të lejojë llogaritjen e automatizuar të të dhënave për punonjësit dhe studentët e departamentit të TIK të OmSTU, të sigurojë mundësi fleksibël për zgjidhjen e detyrave specifike të planifikuara dhe të paplanifikuara të përpunimit. kredencialet.

Si pjesë e zgjidhjes së problemit të zhvillimit të një vendi pune të automatizuar për sekretarin e departamentit, ne do të veçojmë subjektet e mëposhtme:

mësuesit - mësuesit e departamentit;

nxënësit- studentë të universitetit të këtij specialiteti;

studentët studiojnë në grupe, grupështë një ent organizator (unifikues) për studentët;

studente te diplomuar, kanë veçorinë që, nga njëra anë, mund të zhvillojnë vetë mësimin, nga ana tjetër, janë vetë studentë dhe kanë një këshilltar shkencor;

disipline- disiplina e mësuar (lënda, kursi).

Subjektet e futura kanë një sërë atributesh, të cilat do t'i përcaktojmë më vonë.

Ne kryejmë dy lloje përdoruesish: privat përdorues(me tutje përdorues, dhe administratori... Supozohet se përdorues mund të hyjë në sistem me një kërkesë, të shfaqë raporte, administratori gjithashtu mund të modifikojë të dhënat. Për shembull, ndihmës sekretari i departamentit mund të veprojë si përdorues, vetë sekretari ose mësuesi përgjegjës mund të veprojë si administrator.

Duke marrë parasysh termat e paraqitura, sistemi që po zhvillohet duhet të sigurojë:

organizimi i kontabilitetit të plotë dhe të besueshëm të të gjithë punonjësve dhe studentëve të departamentit;

mbështetje informative e vendimeve të marra të menaxhimit, formimi i informacionit të plotë dhe të besueshëm në lidhje me proceset arsimore dhe rezultatet e aktiviteteve të departamentit;

uljen e kostove të punës për përgatitjen e dokumenteve dhe raporteve parësore;

eliminimi i dyfishimit gjatë futjes së informacionit dhe gabimeve mekanike që rezultojnë;

ndërfaqe miqësore për përdoruesit;

diferencimi i kompetencave të përdoruesve të zakonshëm dhe të administratorit.

Në këtë shembull, ne zgjidhim një problem të veçantë - ne zhvillojmë një AWP për sekretarin e departamentit, prandaj, departamenti merret si një njësi strukturore e nivelit më të lartë për ne, të cilën do ta kemi parasysh si parazgjedhje, d.m.th. supozohet se të gjithë elementët e modelit kanë të bëjnë vetëm me këtë departament, i cili nuk është specifikuar në mënyrë eksplicite ... Ne nuk do të konsiderojmë struktura të nivelit më të lartë, si fakultet, universitet.

4. Zhvillimi i një modeli të sistemit softuerik duke përdorur UML

UML është një gjuhë për specifikim dhe vizualizim, njësitë kryesore të saj janë diagramet.

Një diagram UML është një paraqitje grafike e një grupi shabllonesh, më së shpeshti të përshkruara si një grafik i lidhur me kulme (entitete) dhe skaje (marrëdhënie). Diagramet karakterizojnë sistemin nga këndvështrime të ndryshme. Një diagram është, në një farë kuptimi, një nga projeksionet e sistemit. Në mënyrë tipike, grafikët ofrojnë një pamje të kolapsuar të elementeve që përbëjnë një sistem. Një dhe i njëjti element mund të jetë i pranishëm në të gjitha diagramet, ose vetëm në disa (varianti më i zakonshëm), ose jo i pranishëm në asnjë (shumë rrallë). Në teori, diagramet mund të përmbajnë çdo kombinim të entiteteve dhe marrëdhënieve. Megjithatë, në praktikë, përdoret një numër relativisht i vogël kombinimesh tipike, që korrespondojnë me pesë llojet më të zakonshme që përbëjnë arkitekturën e një sistemi softuerësh (shih seksionin vijues). Kështu, në UML, dallohen nëntë lloje diagramesh:

diagramet e klasave

diagramet e objekteve;

përdorimi i diagrameve të rasteve;

diagramet e sekuencës;

diagramet e bashkëpunimit;

diagramet e gjendjes;

diagramet e veprimit (veprimtarisë);

diagramet e komponentëve;

diagramet e vendosjes.

Modeli konceptual UML

Diagrami i klasës tregon klasat, ndërfaqet, objektet dhe bashkëpunimet dhe marrëdhëniet e tyre. Gjatë modelimit të sistemeve të orientuara nga objekti, ky lloj diagrami përdoret më shpesh. Diagramet e klasave paraqesin një pamje statike të projektimit të një sistemi. Diagramet e klasave që përfshijnë klasa aktive korrespondojnë me pamjen statike të sistemit nga perspektiva e procesit.

Një diagram objekti paraqet objektet dhe marrëdhëniet ndërmjet tyre. Ato janë "fotografi" statike të rasteve të njësive të paraqitura në diagramet e klasave. Diagramet e objekteve, si diagramet e klasave, i referohen një pamjeje statike të një sistemi nga një perspektivë e projektimit ose procesit, por me një këndvështrim të një zbatimi real ose simulues.

Diagrami i rastit të përdorimit tregon rastet e përdorimit dhe aktorët (një rast i veçantë i klasave), si dhe marrëdhëniet midis tyre. Diagramet e rasteve të përdorimit i referohen një pamjeje statike të një sistemi për sa i përket rasteve të përdorimit. Ato janë veçanërisht të rëndësishme gjatë organizimit dhe modelimit të sjelljes së një sistemi.

Diagramet e sekuencës dhe diagramet e bashkëpunimit janë raste të veçanta të diagrameve të ndërveprimit. Diagramet e ndërveprimit paraqesin marrëdhëniet ndërmjet objekteve; tregon, në veçanti, mesazhet që objektet mund të shkëmbejnë. Diagramet e ndërveprimit i referohen pamjes dinamike të sistemit. Në këtë rast, diagramet e sekuencës pasqyrojnë renditjen e përkohshme të mesazheve, dhe diagramet e bashkëpunimit - organizimin strukturor të objekteve që shkëmbejnë mesazhe. Këto diagrame janë izomorfike, domethënë mund të shndërrohen në njëra-tjetrën.

Diagramet e grafikut të gjendjes përfaqësojnë një automat që përfshin gjendjet, tranzicionet, ngjarjet dhe llojet e veprimeve. Diagramet e gjendjes i referohen pamjes dinamike të sistemit; ato janë veçanërisht të rëndësishme kur modeloni sjelljen e një ndërfaqeje, klase ose bashkëpunimi. Ato fokusohen në sjelljen e një objekti, në varësi të sekuencës së ngjarjeve, gjë që është shumë e dobishme për simulimin e sistemeve reaktive.

Një diagram aktiviteti është një rast i veçantë i një diagrami të gjendjes; tregon kalimet e rrjedhës së kontrollit nga një aktivitet në tjetrin brenda sistemit. Diagramet e aktivitetit i referohen një pamjeje dinamike të një sistemi; ato janë më të rëndësishmet në modelimin e funksionimit të tij dhe pasqyrojnë rrjedhën e kontrollit ndërmjet objekteve.

Diagrami i komponentëve tregon organizimin e një grupi komponentësh dhe varësitë ndërmjet tyre. Diagramet e komponentëve i referohen një pamjeje statike të një sistemi nga pikëpamja e zbatimit. Ato mund të lidhen me diagramet e klasave, pasi një komponent zakonisht lidhet me një ose më shumë klasa, ndërfaqe ose bashkëpunime.

Diagrami i vendosjes tregon konfigurimin e nyjeve përpunuese të sistemit dhe komponentëve të vendosur në to. Diagramet e vendosjes i referohen një pamje statike të arkitekturës së një sistemi nga një perspektivë e vendosjes. Ato janë të lidhura me diagramet e komponentëve sepse një nënbashkim zakonisht përmban një ose më shumë komponentë.

Këtu është një listë e pjesshme e diagrameve të përdorura në UML. Mjetet ju lejojnë të gjeneroni edhe diagrame të tjera, të tilla si diagramet e profileve të bazës së të dhënave, diagramet e aplikacioneve në ueb, etj.

4.1 Dizajnimi i një pamjeje nga perspektiva e rastit të përdorimit

Modelimi fillon me përcaktimin e objektivave kryesore të sistemit që po zhvillohet dhe veprimeve që ai duhet të kryejë. Për këto qëllime përdoren diagramet e rasteve të përdorimit. Siç u diskutua më parë, diagramet e rasteve të përdorimit tregojnë rastet e përdorimit dhe aktorët dhe marrëdhëniet midis tyre.

Precedent (Rasti i përdorimit) është një përshkrim i një sekuence veprimesh të kryera nga sistemi që prodhon një rezultat të vëzhgueshëm që është domethënës për një Veproni e ra (Aktor). Rasti i përdorimit përdoret për të strukturuar entitetet e sjelljes së modelit. Rasti i përdorimit deklaron vetëm një përshkrim të disa veprimeve të sistemit, duke iu përgjigjur pyetjes "çfarë duhet bërë?", Por nuk tregon se me çfarë mjetesh. Zbatimi konkret i sjelljes së specifikuar nga rasti i përdorimit sigurohet nga një klasë, bashkëpunimi i klasës ose komponenti.

Një aktor është një grup koherent rolesh që përdorin përdoruesit e rasteve kur ndërveprojnë me ta. Në mënyrë tipike, një aktor përfaqëson rolin që luan një person, pajisje harduerike, apo edhe një sistem tjetër në një sistem të caktuar. Në sistemin e zhvilluar "Stacioni i punës së sekretarit të departamentit" aktorët janë administratori (admin) dhe përdorues.

Grafikisht, një precedent përshkruhet si një elips i kufizuar nga një vijë e vazhdueshme, që zakonisht përmban vetëm emrin e tij, aktori ka një ikonë "njeri i vogël".

Për të ndërtuar një diagram të rastit të përdorimit, është e nevojshme të identifikohen veprimet elementare të kryera nga sistemi dhe të krahasohen ato me rastet e përdorimit. Në të njëjtën kohë, është e dëshirueshme të jepen emrat e rasteve të përdorimit në mënyrë që ato të tregojnë sjelljen, shpesh emra të tillë përmbajnë folje, për shembull, "gjeneroni një raport", "gjeni të dhëna sipas kriterit", etj. Është e mundur të jepen emra për të përdorur raste me emra që sugjerojnë disa veprime, për shembull, "autorizim", "kërkim", "kontroll".

Duke iu rikthyer modelimit të vendit të automatizuar të punës së sekretarit të departamentit, le të veçojmë precedentët:

Redaktimitë dhëna,

Kërkostudenti,

Kërkomësuesi,

Lëshimilistëmësuardisiplinat,

Autorizimi.

Elementet e diagramit të rasteve të përdorimit (rastet e përdorimit dhe aktorët) duhet të lidhen me marrëdhënie.

Marrëdhënia më e zakonshme midis rasteve të përdorimit, rasteve të përdorimit dhe aktorëve është shoqërimi. Në disa raste, marrëdhëniet e përgjithësimit mund të përdoren. Këto marrëdhënie kanë të njëjtin kuptim si në diagramin e klasës.

Për më tepër, përcaktohen dy varësi specifike midis rasteve të përdorimit në UML - një marrëdhënie përfshirjeje dhe një marrëdhënie shtesë.

Një marrëdhënie përfshirjeje midis rasteve të përdorimit do të thotë që në një moment në rastin e përdorimit bazë, sjellja e një rasti tjetër përdorimi është përfshirë (përfshirë). Rasti i përdorimit të përfshirë nuk ekziston kurrë në mënyrë autonome, por instancohet vetëm si pjesë e rastit të përdorimit të bashkangjitur. Ju mund të mendoni për rastin e përdorimit bazë si huazim i sjelljes së përfshirjes. Për shkak të pranisë së marrëdhënieve të përfshirjes, është e mundur të shmangen përshkrimet e shumta të së njëjtës rrjedhë ngjarjesh, pasi sjellja e përgjithshme mund të përshkruhet si një rast përdorimi i pavarur i përfshirë në ato bazë. Një marrëdhënie përfshirjeje është një shembull i delegimit, në të cilin një sërë përgjegjësish të sistemit përshkruhen në një vend (në rastin e përdorimit të përfshirë), dhe pjesa tjetër e rasteve të përdorimit, kur është e nevojshme, i përfshin këto përgjegjësi në grupin e tyre.

Marrëdhëniet e përfshirjes përshkruhen si varësi me stereotipin "përfshi". Për të specifikuar një vend në rrjedhën e ngjarjeve ku një rast përdorimi bazë përfshin sjelljen e një tjetri, thjesht shkruani fjalën përfshin e ndjekur nga emri i rastit të përdorimit që duhet përfshirë.

Një lidhje shtesë përdoret për të modeluar pjesë të një rasti përdorimi që përdoruesi i percepton si sjellje opsionale të sistemit. Kjo ju lejon të ndani sjelljet e nevojshme dhe opsionale. Marrëdhëniet e zgjerimit përdoren gjithashtu për të modeluar nëngrupe individuale që funksionojnë vetëm në rrethana të caktuara. Së fundi, ato përdoren për të simuluar transmetime të shumta që mund të shkaktohen në një moment në skenar si rezultat i ndërveprimit të qartë me aktorin.

Marrëdhënia e shtrirjes përshkruhet si një varësi me stereotipin "zgjat". Pikat e zgjerimit të skriptit bazë janë renditur në një seksion shtesë. Ato janë thjesht etiketa që mund të shfaqen në rrjedhën e rastit themelor të përdorimit.

Një shembull i përdorimit të kësaj marrëdhënieje mund të jetë qasja në një bazë të dhënash me një pjesë operative dhe një arkiv. Në këtë rast, nëse kërkesa pajiset me të dhëna nga pjesa operative, kryhet qasja kryesore (themelore) në të dhënat, nëse të dhënat nga pjesa operative nuk janë të mjaftueshme, aksesohet në të dhënat e arkivit, pra qasja është kryhet sipas skenarit të avancuar.

Në rastin tonë, precedenti redaktimitë dhëna përfshin rastet e përdorimit: hyrjetë dhëna, fshirjetë dhëna, Ndryshimitë dhëna.

Diagrami i precedentëve të AWP-së së sekretarit të departamentit është paraqitur në figurën 1.

Oriz. 1. Diagrami i precedentëve të PVP të sekretarit të departamentit

Precedent Kërkostudenti përfshin kërkimin sipas mbiemrit dhe kërkimin sipas rezultateve të performancës akademike.

Kur hartoni një pamje për sa i përket rasteve të përdorimit, shpesh është e nevojshme të jepet një përshkrim i zgjeruar i rastit të përdorimit (vetëm emri jepet në versionin e shkurtuar). Në mënyrë tipike, rrjedha e ngjarjeve të një rasti përdorimi përshkruhet në formë teksti në fillim. Ndërsa përmirësoni kërkesat e sistemit tuaj, do të jetë më e përshtatshme të kaloni në një paraqitje grafike të flukseve në diagramet e aktivitetit dhe ndërveprimit.

Rrjedhat e ngjarjeve mund të përshkruhen me anë të tekstit të pastrukturuar, tekstit të strukturuar (që përmban fjalë shërbimi: NËSE,PARAATAPORDERISA etj.), një gjuhë zyrtare e specializuar (pseudokod).

Kur përshkruani një rast përdorimi si një rrjedhë ngjarjesh, është e rëndësishme të përcaktohen gjithashtu rrjedhat kryesore dhe alternative të sjelljes së sistemit.

Për shembull, merrni parasysh përshkrimin e rrjedhës së ngjarjeve të rastit të përdorimit autorizimi.

bazë rrjedhin ngjarjet. Rasti i përdorimit fillon kur sistemi i kërkon përdoruesit hyrjen dhe fjalëkalimin e tij. Përdoruesi mund ta futë atë nga tastiera. Hyrja përfundon me shtypjen e tastit. Hyni. Pas kësaj, sistemi kontrollon hyrjen dhe fjalëkalimin e futur, dhe nëse ato përputhen me administratorin, konfirmon autoritetin e administratorit. Kjo përfundon precedentin.

Të jashtëzakonshme rrjedhin ngjarjet. Klienti mund të përfundojë transaksionin në çdo kohë duke shtypur tastin Anulo. Ky veprim fillon përsëri precedentin. Nuk ka hyrje në sistem.

Të jashtëzakonshme rrjedhin ngjarjet. Klienti mund të fshijë hyrjen dhe fjalëkalimin e tij në çdo kohë përpara se të shtypë tastin Enter.

Të jashtëzakonshme rrjedhin ngjarjet. Nëse klienti ka futur hyrjen dhe fjalëkalimin që nuk korrespondojnë me administratorin, atij i ofrohet të rihyjë ose të hyjë në sistem si një përdorues i zakonshëm.

Natyrisht, përshkrimi i një rasti përdorimi nga një rrjedhë ngjarjesh presupozon një lloj algoritmi që mund të përfaqësohet në një diagram aktiviteti (Fig. 2).

Diagrami i algoritmit duhet të përmbajë kulmet e fillimit dhe të fundit, me vetëm një fillim dhe një fund. Diagrami përmban kulme të ekzekutueshme - aktivitete (të treguara nga drejtkëndësha të rrumbullakosura), kulme të kushtëzuara (vendim - përzgjedhje, njohje, e treguar me diamante) dhe lidhje.

Diagrame të ngjashme mund të shpjegojnë ekzekutimin e rasteve të tjera të përdorimit, duke plotësuar kështu pamjen e sistemit nga pikëpamja e rasteve të përdorimit.

Oriz. 2. Autorizimi i përdoruesit. Diagrami i aktivitetit.

4.2 Zhvillimi i një pamje të projektimit

Pamja e projektimit është faza kryesore në studimin konceptual të modelit. Në këtë fazë prezantohen abstraksionet bazë, përcaktohen klasat dhe ndërfaqet përmes të cilave realizohet zgjidhja e detyrave. Nëse rastet e përdorimit deklarojnë vetëm sjelljen e sistemit, atëherë në fazën e zhvillimit të pamjes nga pikëpamja e projektimit, përcaktohet se me çfarë mjetesh do të zbatohen këto raste përdorimi. Aspektet statike të këtij lloji zhvillohen përmes diagrameve të klasave, dinamike - përmes ndërveprimit dhe diagrameve të gjendjes (automati).

Diagramet e klasave përmbajnë klasa, ndërfaqe, bashkëpunime, si dhe lidhje ndërmjet tyre. Zhvillimi i një diagrami të klasës duhet të fillojë me përcaktimin e klasave që korrespondojnë me entitetet kryesore të sistemit, të cilat, si rregull, përcaktohen në fazat fillestare të zhvillimit kur përshkruajnë fushën e lëndës. Këtu është e nevojshme të vendoset se cilat entitete janë më të përshtatshme për t'u modeluar si klasa dhe cilat si atribute të tyre. Për shembull, nëse do të kërkohej brenda fakultetit të tregonte titullarin për secilin departament, do të ishte më mirë të specifikohej menaxherkarrige e bëjnë atë një atribut të klasës karrige duke treguar klasën mësuesit ( shoqata një me një ), në vend që të prezantohet një klasë e veçantë menaxherkarrige.

Gjatë modelimit, duhet të mbahet mend se çdo klasë duhet të korrespondojë me një entitet real ose abstraksion konceptual nga zona me të cilën merret përdoruesi ose zhvilluesi. Një klasë e strukturuar mirë ka karakteristikat e mëposhtme:

është një abstragim i mirëpërcaktuar i ndonjë koncepti nga fjalori i zonës së problemit ose zonës së zgjidhjes;

përmban një grup të vogël, të përcaktuar mirë përgjegjësish dhe kryen secilën prej tyre;

mban një ndarje të qartë ndërmjet specifikimeve të abstraksionit dhe zbatimit të tij;

i kuptueshëm dhe i thjeshtë, por në të njëjtën kohë lejon zgjerimin dhe përshtatjen ndaj detyrave të reja.

Si pjesë e zhvillimit të modelit të vendit të automatizuar të punës së sekretarit të departamentit, ne do të përcaktojmë klasat: mësuesit, nxënësit, studente te diplomuar, disiplinat, grup... Natyrisht, e para prej tyre ka shumë atribute të përbashkëta, kështu që le të prezantojmë një klasë abstrakte PEerson, i cili do të përmbledhë të gjitha vetitë e lidhura me njeriun në kontekstin e sistemit që po zhvillohet (mbiemri, emri, adresa, etj.). Në këtë rast një person do të jetë superklasa dhe do të komunikojë me marrëdhënie gjenerike me klasat mësuesit, nxënësit, studente te diplomuar.

atribut adresën ka strukturën e vet, për ta pasqyruar mund të prezantoni një klasë shtesë, le ta quajmë T_ ADR(siç është zakon në shumë sisteme programimi, emrat e klasave fillojnë me shkronjën T). Vini re se atributi adresën klasës një personështë një shembull i klasës T_ ADR, domethënë vendoset një marrëdhënie varësie midis këtyre klasave (e treguar nga një shigjetë e ndërprerë me një majë të hapur, shigjeta drejtohet nga e varura te e pavarura). Në rastin tonë, ndryshimi i strukturës së klasës T_ ADR sjell një ndryshim klase një person përmes strukturës së atributit përkatës ( adresën).

Kur modeloni një klasë T_ ADR atribut indeks vendosur me anë të një tipi primitiv T_ POSTIDX, i përcaktuar si një numër dhjetor gjashtëshifror. Llojet primitive janë stereotipe " lloji" , diapazoni i vlerave specifikohet përmes kufizimeve të mbyllura në mbajtëset kaçurrelë.

Në klasë mësuesi le të theksojmë atributet specifike që lidhen vetëm me mësuesin: pozicion, uch. shkallë(diplomë akademike), uch. gradë ( grada akademike), shkarkimi(kategoria e një shkalle tarifore të vetme). Atributet uch. shkallë dhe uch. gradëështë më mirë të përcaktohen llojet e specializuara me anë të numërimit. Numërimet janë modeluar nga një klasë me stereotipin " një numër" (numërimi - numërimi), vlerat e lejuara shkruhen si atribute, etiketat që përcaktojnë dukshmërinë e atributeve janë shtypur. Në këtë shembull, përmes numërimit, ne prezantojmë klasa të specializuara T_Duhet, T_UCHST, T_UchZv, përkatësisht duke përcaktuar pozitat e mundshme, titujt akademikë, titujt akademikë përmes transferimeve. Në këtë rast, si kudo në raste të ngjashme, kur krijohen klasa që specifikojnë atributet e klasës kryesore, vendosen marrëdhënie varësie.

Për klasën studenti prezantohet një atribut specifik dhomëlibrat e regjistrimeve... Atributet specifike janë përcaktuar për klasën pasuniversitare formëtë mësuarit dhe datëfaturat... Forma e studimit do të përcaktohet nga një klasë e veçantë me anë të një numërimi T_FormObuch(me kohë të plotë, me kohë të pjesshme).

Klasa grup ka atribute: titullin, forma të mësuarit, numrikurvar. ( numri i nxënësve ). Duke pasur parasysh që mësimdhënësit e departamentit në fjalë mund të japin mësim në grupe nga fakultete të tjera, është vendosur një orë shtesë. specialiteti, me atribute dhomë(specialitete), titullin(specialitete ), fakultetit llojet e të cilave nuk janë të specifikuara në këtë model, megjithëse ato mund të përcaktohen përmes numërimit.

Klasa disipline ka atribute: dhomë, titullin, ciklit. atribut ciklit me anë të një lloji të specializuar të futur përmes një numërimi T_Ciklet përcakton se cilit cikli i përket disiplina: ciklit të disiplinave humanitare dhe socio-ekonomike, disiplinave matematikore dhe natyrore, disiplinave të përgjithshme profesionale, disiplinave të veçanta.

Atributet numriorë, numrisemestrave nuk mund të specifikohet në klasë disipline, duke qenë se varen nga specialiteti, aq më shumë nuk mund t'i tregosh në klasë specialiteti... Këto atribute lidhen me çiftin specialitet-disiplinë dhe përcaktohen në klasë - shoqatë Disiplina-specialitete.

Oriz. 3. Diagrami i klasës së PVP të sekretarit të departamentit (opsioni 1)

Kur jepni një strukturë klase, kushtojini vëmendje dukshmërisë së atributeve. Të gjitha atributet e konsideruara duhet të jenë të disponueshme dhe të kenë dukshmërinë Publike (të shënuar me shenjën "+" ose një ikonë pa dry). Në klasat e konsideruara, ne u fokusuam në strukturë dhe jo në sjellje (operacionet nuk u përshkruan dhe nuk supozohet të përshkruhen), prandaj, për ta bërë diagramin më të lehtë për t'u lexuar, është e dëshirueshme që të shtypen operacionet.

Në grupin e prezantuar të klasave, është e nevojshme të ripërcaktohen lidhjet. Lidhjet e përgjithësimit dhe varësive tashmë janë përcaktuar, mbetet të përcaktohen asociacionet.

Studentët formuar në grup, në këtë rast shoqata do të jetë në formë agregimi. Agregimi supozon një marrëdhënie pjesë-tërësie, e shënuar me një vijë të fortë me një romb në fund nga e gjithë ana (në rastin tonë grup). Shumësia e marrëdhënieve shumë-për-një student-grup. Secili grup i referohet një specifike specialiteti, nga ana tjetër, disa grupe mund të korrespondojnë me një specialitet të caktuar, prandaj shoqata grup-specialitet ka edhe llojin e shumëfishimit "shumë për një".

Në këtë rast, si në shumicën e të tjerave, drejtimi i shoqatave është i dyanshëm, kështu që është më mirë të shtypni navigimin (zgjidhni fushën e lundrueshme të opsionit Detail Role)

Le të përcaktojmë një lidhje midis mësuesit dhe mësoi disiplinat si "shumë-për-shumë": një mësues mund të mësojë disa disiplina, disa disiplina mund të mësohen nga disa mësues. Ndërmjet disiplinat dhe specialitete krijohet edhe shoqata “shumë-për-shumë”: kurrikula e specialiteteve përmban shumë disiplina, shumica e disiplinave gjenden në planet e punës të disa specialiteteve. Klasa e shoqatës i bashkëngjitet kësaj shoqate. Disiplina-specialitete me atribute që tregojnë kursin, numrin e semestrave dhe numrin e orëve të një disipline të caktuar në një specialitet të caktuar.

Në mënyrë të ngjashme, ne prezantojmë një lidhje midis në grupe dhe mësuesit: Mësuesit japin mësim në grupe, të tipit shumë-për-shumë. Lidhja e drejtpërdrejtë ndërmjet në grupe dhe disciplinat ju nuk keni nevojë të përcaktoni, pasi kjo marrëdhënie gjurmohet përmes klasës binder specialiteti.

Për të shfaqur praninë e një mbikëqyrësi për një student të diplomuar, është e nevojshme të futet një lidhje midis një studenti të diplomuar dhe një mësuesi të llojit "shumë-për-një"; një mbikëqyrës mund të ketë disa studentë të diplomuar. Në këtë shoqatë nga ana e mësuesit, ju mund të tregoni qartë rolin: mbikëqyrës.

Oriz. 4. Diagrami i klasave të AWP të sekretarit të departamentit (opsioni 2)

Në secilin grupee ka një drejtues grupi, ky fakt mund të shfaqet nga një shoqatë shtesë (le t'i japim një emër kryetar) nga grupi te nxënësit me llojin e shumëzimit “një në një”. Në këtë rast, ju mund të specifikoni në mënyrë eksplicite navigimin.

Studentë pasuniversitarë gjithashtu mund t'u mësojë disiplina specifike grupeve të veçanta: shoqata shumë-për-shumë grupet pasuniversitare, disiplinat pasuniversitare. Disa studentë të diplomuar mund të mos japin mësim, kështu që lloji i shumëfishtë në skajet e lidhjes do të jetë 0. n.

Diagrami përfundimtar i klasës është paraqitur në Fig. 3.

Oriz. 5. Skema e thjeshtuar e klasës

Duke marrë parasysh që si studentët e diplomuar ashtu edhe mësuesit japin mësim, mund të futet një klasë shtesë abstrakte, për shembull, mësimdhënies që është pasardhës i klasës një person dhe një superklasë për klasat mësuesi dhe student i diplomuar, e cila do të zvogëlojë pak numrin e lidhjeve. (fig. 4.). Në këtë rast, nga klasat disipline dhe grup shoqatat do të shkojnë në klasë mësimdhënies, duke supozuar një lidhje me klasat mësuesi dhe student i diplomuar nëpërmjet trashëgimisë (marrëdhënie gjeneralizimi). Në klasë mësimdhënies ju mund të hiqni atributet oferta(0,5 norma, norma e plotë) dhe shkarkimi.

Diagrami që rezulton është mjaft kompleks dhe i ngarkuar me elementë, por modelimi i klasave nuk është ende i plotë: disa klasa të shërbimeve dhe ndërfaqe duhet ende të përcaktohen. Për të shkarkuar diagramin e klasës, do të ndërtojmë një pamje të re të saj (në një diagram të veçantë), duke lënë imazhin e klasave kryesore dhe duke shtypur shfaqjen e atyre ndihmëse që përcaktojnë llojet e atributeve (Fig. 5).

Në fig. 5, së bashku me klasat kryesore që korrespondojnë me elementët konceptualë të sistemit, paraqitet edhe klasa T_ ADR, duke zbuluar strukturën e adresës, kjo klasë është gjithashtu e rëndësishme, pasi përmban elementet e nevojshme të të dhënave për të mësuesit dhe studente te diplomuar- pasardhës të klasës një person.

Le të kalojmë në përcaktimin e ndërfaqeve. Klasat ndërveprojnë me botën e jashtme përmes ndërfaqeve.

Ndërfaqja (Interface) është një koleksion operacionesh që përcaktojnë një shërbim (bashkësi shërbimesh) të ofruar nga një klasë ose komponent. Kështu, një ndërfaqe përshkruan sjelljen e jashtme të dukshme të një elementi. Një ndërfaqe mund të përfaqësojë sjelljen e një klase ose komponenti tërësisht ose pjesërisht; ai përcakton vetëm specifikat e operacioneve (nënshkrimet), por asnjëherë zbatimin e tyre. Ndërfaqja grafike përshkruhet si një rreth, nën të cilin është shkruar emri i tij. Një ndërfaqe rrallë ekziston më vete - zakonisht i bashkëngjitet një klase ose komponenti zbatues. Ndërfaqja gjithmonë presupozon ekzistencën e një lloj "kontrate" midis palës që deklaron ekzekutimin e një sërë operacionesh dhe palës që i zbaton këto operacione.

Vendoseni klasën në diagram elektroniketabela, i cili përmbledh të gjitha vetitë dhe operacionet e tabelës që ju lejon të redaktoni të dhënat. Ne nuk do të zbulojmë strukturën e kësaj klase për shkak të kompleksitetit të saj të madh. Pra, në mjetet moderne të zhvillimit të aplikacioneve, përdoruesi përdor klasa dhe shabllone të gatshme, duke trashëguar aftësitë e tyre, për shembull, biblioteka VCL (Delphi) përmban një klasë TTable që përmbledh aftësitë e një spreadsheet. Pasardhësit e klasës elektroniketabela janë tabela specifike që përmbajnë të dhëna specifike për fakultet, studentë të diplomuar, studentë, grupe, disiplina dhe specialitete. Duke i bërë klasat përkatëse pasardhës të klasës elektroniketabela, ne deklarojmë për këto klasa të gjitha vetitë dhe operacionet e qenësishme në spreadsheets (regjistrimi në sistem, futja, fshirja, redaktimi i të dhënave, renditja, etj.).

Për klasën elektroniketabela, dhe, në përputhje me rrethanat, për të gjithë pasardhësit e tij, ne përcaktojmë ndërfaqen redaktimi, duke nënkuptuar të gjitha operacionet e mundshme të redaktimit të të dhënave (fusni, fshini, ndryshoni të dhënat). Në këtë rast supozohet se në klasë elektroniketabela këto mundësi zbatohen.

Përdorimi i një klase të personalizuar elektroniketabela dhe trashëgimia shmangi përcaktimin e veçorive të veçanta dhe ndërfaqet e redaktimit të të dhënave për secilën fletëllogaritëse.

Le të përcaktojmë ndërfaqet Kërkomësuesi, Kërkodisiplinat duke i bashkangjitur ato në klasat e tyre përkatëse me një marrëdhënie zbatimi. Ne nuk do të zbulojmë përbërjen e operacioneve të këtyre ndërfaqeve (është mjaft e parëndësishme), prandaj, ne do t'i shfaqim ndërfaqet në një formë të shkurtuar (në formën e një rrethi). Kujtoni që një marrëdhënie zbatimi e bashkangjitur në një ndërfaqe në formë të shkurtuar shfaqet si një vijë e thjeshtë e fortë (si një lidhje).

Ndërfaqja Kërkostudenti do të shfaqet me një tregues të listës së operacioneve përmes një klase të stereotipizuar, ndërsa lidhja e zbatimit tregohet me një shigjetë të ndërprerë me një majë të mbyllur.

Natyrisht, supozohet se ndërfaqet e prezantuara zbatohen me anë të klasave të cilave u janë bashkangjitur nga relacioni i zbatimit, domethënë, klasat përkatëse përmbajnë operacione dhe metoda që zbatojnë ndërfaqet e deklaruara. Për lehtësinë e perceptimit, këto mekanizma nuk vizualizohen.

Për të menaxhuar të drejtat e aksesit dhe autorizimin e përdoruesit, ne prezantojmë klasën menaxherakses... Menaxheri i aksesit ka një atribut të tipit të aksesit privat tabelafjalëkalimet që është një shembull i klasës Tabela e kodit(Tabela e koduar) që përmban fjalëkalime ( fjalëkalimin) dhe emrat e hyrjes ( identifikimi) të përdoruesve administratorë. Supozohet se aftësitë e klasës së shërbimit Tabela e kodit mos lejoni një përdorues të paautorizuar të lexojë fjalëkalimet e përdoruesit. Në këtë fazë të projektimit, ne thjesht deklarojmë aftësi të tilla, duke mos u ndalur në mekanizmin e zbatimit të tyre, por duke supozuar se ato janë të kapsuluara në një klasë Tabela e kodit.

Klasa menaxherakses përmban transaksione të hapura hyrjefjalëkalimin dhe dhënien e të drejtave të administratorit, me anë të të cilave realizohet autorizimi dhe menaxhimi i të drejtave të aksesit.

Le të tregojmë varësinë midis ndërfaqes së redaktimit të të dhënave ( redaktimi) dhe një menaxher aksesi, duke supozuar se vetëm përdoruesit me të drejta administratori kanë aftësi të plota të redaktimit të të dhënave.

Oriz. 6. Skema përfundimtare e klasave të PVP të sekretarit të departamentit

Diagrami përfundimtar është paraqitur në Fig. 6.

Pra, në këtë fazë, zhvillimi i një modeli të orientuar nga objekti i stacionit të punës të sekretarit të departamentit me anë të diagramit të klasës UML mund të konsiderohet i plotë. Natyrisht, është e mundur të ktheheni tek ai dhe të rishikohen disa elementë gjatë projektimit të sistemit, kur rregulloni detyrat, kur specifikoni detaje individuale. Procesi i projektimit të sistemeve të informacionit është përsëritës. Duhet të theksohet se diagrami i zhvilluar i klasës përmban elementë që zbatojnë në mënyrë eksplicite ose implicite të gjitha rastet e përdorimit të diagramit të rasteve të përdorimit. Çdo rast përdorimi i një diagrami të rastit të përdorimit duhet të korrespondojë ose me një ndërfaqe ose një operacion ndërfaqeje (zbatimi supozohet në klasat që korrespondojnë me ndërfaqen), ose një operacion publik të klasës, ose një grup operacionesh publike (në këtë rast, rasti i përdorimit zbatohet drejtpërdrejt nga klasa ose grupi i klasave përkatëse).

Le të shohim procesin e krijimit të një rekordi të ri studentor duke përdorur një diagram sekuence.

Krijimi i një rekordi të ri supozon të drejtat e administratorit, kështu që administratori do të jetë protagonisti i këtij ndërveprimi ( admin). Ky element është futur tashmë në diagramin e rastit të përdorimit, kështu që tërhiqeni atë në diagramin e sekuencës nga shfletuesi i pamjes së rastit të përdorimit.

Duhet të theksohet se objektet shfaqen në diagramet e ndërveprimit, domethënë, shembuj konkretë të klasave (emri i një objekti është gjithmonë i nënvizuar).

Ne menaxhojmë objektet: formëhyrje, menaxherrekorde, procesverbal i studentit Petrov(si një shembull konkret i një dosje studentore), menaxhertransaksionet... Ky grup objektesh është tipik kur modifikoni një rekord në një tabelë të bazës së të dhënave.

Formahyrje- një element i ndërfaqes së përdoruesit, i cili është një formë tipike për futjen e të dhënave për një student (mbiemri, emri, patronimi, adresa, etj.). Në rastin tonë, është një zbatim konkret disi i zgjeruar i ndërfaqes standarde redaktimi klasës elektroniketabela. Meqenëse nuk kemi prezantuar në mënyrë specifike ndërfaqen për redaktimin e të dhënave të studentëve në diagramin e klasës, prandaj, specifikoni në mënyrë eksplicite klasën për objektin formëhyrje ne nuk do të.

Menaxherirekorde- një objekt që ka një grup standard të aftësive të menaxhimit të të dhënave kur punon me një spreadsheet. Ky grup aftësish trashëgohet nga klasa nxënësit nga klasa elektroniketabela... Për objekt Menaxherirekorde klasa e së cilës është shembull tregohet në mënyrë eksplicite - nxënësit.

Petrov- një rekord specifik për studentin Petrov, një element i ri i tabelës për studentët. Këtu ne tregojmë në mënyrë eksplicite klasën e prezantuar regjistrimiOstudenti... Objekte të tilla zakonisht ekzistojnë përkohësisht për të dërguar informacionin përkatës në bazën e të dhënave gjatë transaksioneve. Pas përfundimit të transaksionit, ky objekt mund të shkatërrohet. Objekti që korrespondon me rekordin mund të krijohet përsëri nëse është e nevojshme të redaktoni informacionin.

Menaxheritransaksionet- një objekt që siguron ekzekutimin e një operacioni të përfunduar në bazën e të dhënave, në këtë rast, krijimin e një regjistrimi të ri për studentin Petrov. Ky objekt është gjithashtu përgjegjës për kryerjen e një numri funksionesh të sistemit që shoqërojnë transaksionin. Shembuj të menaxherëve të transaksioneve janë, për shembull, BDE (përdoret për të hyrë në bazat e të dhënave Paradox, Dbase, etj. nga aplikacionet Delphi), ADO (përdoret për të hyrë në bazat e të dhënave MS Access nga aplikacione të ndryshme).

Diagrami i sekuencës për futjen e një rekordi të ri për një student në AWS të sekretarit të departamentit është paraqitur në Fig. 7.

Oriz. 7. Futja e të dhënave të studentëve. Diagrami i sekuencës.

Në diagramin e sekuencës, ne përcaktojmë transferimin e mesazheve midis objekteve: krijojnëi riregjistrimi(transmetuar nga objekti në objekt deri në fund të zinxhirit si mesazh ruajregjistrimi); hapurformë(në formularin e hyrjes); për të prezantuarF.DHE RRETH.,adresën. ( futja e të dhënave të studentit), më pas këto të dhëna transmetohen me mesazhe ruajF.DHE RRETH.,adresën. Nga menaxhertransaksionet dërgo mesazh mbledh informacionOstudenti duke ofruar reagime për bazën e të dhënave, dhe në fund një mesazh refleksiv menaxhertransaksionet emërtuar si ruajregjistrimivDB, siguron përfundimin e transaksionit.

Nëse dëshironi, ky ndërveprim mund të përfaqësohet nga një diagram bashkëpunimi, i cili ilustron, para së gjithash, aspektin strukturor të ndërveprimit (Fig. 8). Ky diagram mund të ndërtohet nga ai i mëparshmi në modalitetin automatik (në Rational Rose duke shtypur tastin F5).

Oriz. 8. Futja e të dhënave të studentëve. Diagrami i bashkëpunimit.

Nëse është e nevojshme, projekti mund të plotësohet me diagrame të tjera ndërveprimi që zbulojnë punën e rasteve të përdorimit.

4.3 Zhvillimi i një profili relacional të bazës së të dhënave

Në rast se një DBMS e orientuar nga objekti (OODBMS) përdoret për zbatimin e sistemit, diagrami i objektit i ndërtuar në seksionin e mëparshëm është modeli përfundimtar dhe një udhëzues i drejtpërdrejtë për zbatimin e sistemit të informacionit. Në të njëjtin rast, kur një bazë të dhënash relacionale (RDB) supozohet të përdoret si bërthamë informacioni e një sistemi informacioni, është e nevojshme të zhvillohet një diagram tjetër, një diagram profili i një baze të dhënash relacionale.

Profili UML për një projekt të bazës së të dhënave është një shtesë UML që e mban të paprekur metamodelin UML. Profili për një projekt të bazës së të dhënave shton stereotipe dhe vlera të etiketuara të shtuara në këto stereotipa, por nuk ndryshon metamodelin themelor UML. Për të vizualizuar elementët e projektuar të bazës së të dhënave dhe rregullat e projektimit për bazat e të dhënave relacionale, ikonat përkatëse janë shtuar në profil (në tekstin e mëtejmë thjesht bazat e të dhënave). Baza e të dhënave përshkruhet duke përdorur tabela, kolona dhe marrëdhënie. Profili përmban elementë që zgjerojnë bazën e të dhënave, të tilla si nxitësit, procedurat e ruajtura, kufizimet, llojet e përcaktuara nga përdoruesi (domainët), pamjet dhe të tjera. Profili tregon se si dhe ku të përdoren të gjithë këta elementë në model. Subjektet e mëposhtme janë përcaktuar në profilin e bazës së të dhënave UML:

tabela ( Tabela) - një grup regjistrimesh në bazën e të dhënave për një objekt specifik, i përbërë nga kolona.

Kolona ( Kolona) është një komponent i tabelës që përmban një nga atributet e tabelës (fusha e tabelës).

fillore Celës (Çelësi primar) - një çelës i mundshëm i zgjedhur për të identifikuar rreshtat e tabelës.

E jashtme Celës (Çelësi i huaj) - një ose më shumë kolona të një tabele, të cilat janë çelësat kryesorë të një tabele tjetër.

Përfaqësimi ( View) është një tabelë virtuale që sillet nga këndvështrimi i përdoruesit tamam si një tabelë e rregullt, por nuk ekziston më vete.

Të ruajtura procedurë ( Procedura e ruajtur) është një funksion procedural i pavarur i ekzekutuar në server.

Domenet ( Domains) është një grup i vlefshëm vlerash për një atribut ose kolonë.

Përveç këtyre entiteteve, mund të futen disa entitete shtesë që pasqyrojnë aspekte specifike të modelit të bazës së të dhënave.

Dokumente të ngjashme

Metodologjitë e zhvillimit të sistemeve të informacionit në literaturën vendase dhe të huaj. Standardet shtetërore dhe ndërkombëtare në fushën e zhvillimit të softuerit. Zhvillimi i një fragmenti të sistemit të informacionit të burimeve arsimore-metodike.

punim afatshkurtër, shtuar 28.05.2009


Përkufizimi i konceptit të "sistemit". Historia e zhvillimit dhe tiparet e sistemeve moderne të informacionit. Fazat kryesore të zhvillimit të një sistemi të automatizuar informacioni. Përdorimi i standardeve vendase dhe ndërkombëtare në fushën e sistemeve të informacionit.

prezantimi u shtua më 14.10.2013


Ideja kryesore e metodologjisë dhe parimeve të RAD-zhvillimit të sistemeve të informacionit, avantazhet e saj kryesore. Arsyet e popullaritetit, veçoritë e aplikacionit të teknologjisë. Formulimi i parimeve bazë të zhvillimit. Mjediset e zhvillimit duke përdorur parimet RAD.

prezantimi u shtua më 04/02/2013


Roli i strukturës së menaxhimit në sistemin e informacionit. Shembuj të sistemeve të informacionit. Struktura dhe klasifikimi i sistemeve të informacionit. Teknologjia e Informacionit. Fazat e zhvillimit të teknologjisë së informacionit. Llojet e teknologjisë së informacionit.

punim termi shtuar 17.06.2003


Koncepti i CASE-tools si mjete softuerike që mbështesin krijimin dhe mirëmbajtjen e sistemeve të informacionit (IS). Karakteristikat e teknologjisë IDEF të zhvillimit të IS. Përshkrimi i shënimit IDEF0. Zhvillimi i modeleve funksionale të një procesi biznesi.

prezantimi u shtua më 04/07/2013


Thelbi i gjuhës së unifikuar të modelimit, modeli i saj konceptual dhe parimi i funksionimit, rregullat dhe mekanizmat e përgjithshëm. Modelimi i konceptit të "kompetencës". Diagrami i klasës që përshkruan procesin arsimor. Zbatimi i një sistemi informacioni të caktuar.

tezë, shtuar 17.02.2015


Zhvillimi i sistemeve të informacionit. Tregu modern i softuerit të aplikuar financiar dhe ekonomik. Avantazhet dhe disavantazhet e zbatimit të sistemeve të automatizuara të informacionit. Metodat për projektimin e sistemeve të automatizuara të informacionit.

tezë, shtuar 22.11.2015


Koncepti i një sistemi informacioni, llojet e sistemeve të informacionit. Analiza e mjeteve për zhvillimin e sistemeve të automatizuara të informacionit. Kërkesat për programin dhe produktin softuer. Zhvillimi i formave të ndërfaqes grafike dhe bazave të të dhënave.

tezë, shtuar 23.06.2015


Zgjidhja e sigurisë së informacionit. Sistemet për qendrat e të dhënave. Çfarë është pajisja e qendrës së të dhënave. Konceptet dhe parimet bazë të modelimit. Zgjedhja e një metode për zgjidhjen e problemeve. Metoda Zoitendijk e drejtimeve të pranueshme, algoritmi Frank-Wolfe.

punim termi shtuar 18.05.2017


Koncepti i sistemit të informacionit. Fazat e zhvillimit të sistemeve të informacionit. Proceset në sistemin e informacionit. Sistemi informativ për gjetjen e pikave të tregut, për uljen e kostove të prodhimit. Struktura e sistemit të informacionit. Mbeshtetje teknike.

Koncepti i një modeli është kyç në teorinë e përgjithshme të sistemeve. Modelimi si një metodë e fuqishme - dhe shpesh e vetme - kërkimore nënkupton zëvendësimin e një objekti real me një tjetër - material ose ideal.
Kërkesat më të rëndësishme për çdo model janë përshtatshmëria e tij me objektin në studim në kuadër të një detyre specifike dhe realizueshmëria e mjeteve të disponueshme.
Në teorinë e efikasitetit dhe shkencën kompjuterike, një model i një objekti (sistemi, operimi) është një sistem material ose ideal (i imagjinueshëm mendërisht) i krijuar dhe/ose i përdorur në zgjidhjen e një problemi specifik për të marrë njohuri të reja rreth objektit origjinal, të mjaftueshëm për të. ajo për sa i përket vetive të studiuara dhe më e thjeshtë se origjinali në aspekte të tjera.
Klasifikimi i metodave kryesore të modelimit (dhe modelet e tyre përkatëse) është paraqitur në Fig. 3.1.1.
Në studimin e sistemeve të informacionit ekonomik (EIS), përdoren të gjitha metodat e modelimit, megjithatë, ky seksion do të fokusohet në metodat semiotike (shenjë).
Le të kujtojmë se semiotika (nga greqishtja semeion - shenjë, shenjë) është shkenca e vetive të përgjithshme të sistemeve të shenjave, domethënë sistemeve të objekteve (shenjave) konkrete ose abstrakte, me secilën prej të cilave lidhet një kuptim i caktuar. Shembuj të sistemeve të tilla janë çdo gjuhë

Oriz. 3.1.1. Klasifikimi i metodave të modelimit

(natyrore ose artificiale, për shembull, përshkrimi i të dhënave ose gjuhët e modelimit), sistemet e sinjalizimit në shoqëri dhe botën e kafshëve, etj.
Semiotika përfshin tre seksione: sintaksore; semantika; pragmatike.
Sintaktika studion sintaksën e sistemeve të shenjave pa marrë parasysh ndonjë interpretim dhe problem që lidhet me perceptimin e sistemeve të shenjave si mjete komunikimi dhe komunikimi.
Semantika studion interpretimin e deklaratave të një sistemi shenjash dhe, nga pikëpamja e modelimit të objekteve, zë vendin kryesor në semiotikë.
Pragmatika shqyrton qëndrimin e personit që përdor sistemin e shenjave ndaj vetë sistemit të shenjave, në veçanti - perceptimin e shprehjeve kuptimplote të sistemit të shenjave.
Nga modelet e shumta semiotike, për shkak të shpërndarjes më të madhe, veçanërisht në kuadrin e informatizimit të shoqërisë moderne dhe futjes së metodave formale në të gjitha sferat e veprimtarisë njerëzore, do të veçojmë ato matematikore që pasqyrojnë sisteme reale duke përdorur simbole matematikore. Në të njëjtën kohë, duke marrë parasysh faktin se po shqyrtojmë metodat e modelimit në lidhje me studimin e sistemeve në operacione të ndryshme, do të përdorim metodologjinë e njohur të analizës së sistemeve, teorinë e efikasitetit dhe vendimmarrjen.

Më shumë për temën 3. TEKNOLOGJIA E SIMULIMIT TË SISTEMEVE INFORMATIVE Metodat e modelimit të sistemeve:

1. Modele simuluese të sistemeve të informacionit ekonomik Bazat metodologjike të aplikimit të metodës së simulimit
2. Seksioni III BAZAT PËR MODELIMIN E NJË SISTEM TË MARREQTINGUT TË SHËRBIMIT
3. KAPITULLI 1. SISTEMET DINAMIKE TË KONTROLLUARA SI OBJEKT IMULIMI KOMPJUTERIK
4. Bazat e modelimit strukturor të sistemit të marketingut të shërbimeve mjekësore
5. Seksioni IV SHEMBULL I PËRDORIMIT TË APLIKUAR TË MODELIT TË SISTEMIT MARKETING NË MODELIMIN E IMITIMIT
6. Koncepti i modelimit të sferës financiare të sistemeve të marketingut

Detyrat dhe funksionet e sistemit të informacionit.

IS mund të zgjidhë dy grupe problemesh. Grupi i parë shoqërohet me mbështetje thjesht informative të aktivitetit kryesor (përzgjedhja e mesazheve të nevojshme, përpunimi, ruajtja, kërkimi dhe shpërndarja e tyre te subjekti i aktivitetit kryesor me një plotësi, saktësi dhe efikasitet të paracaktuar në formën më të pranueshme). Grupi i dytë i detyrave shoqërohet me përpunimin e informacionit / të dhënave të marra në përputhje me algoritme të caktuara për të përgatitur zgjidhje për detyrat me të cilat përballet subjekti i aktivitetit kryesor. Për të zgjidhur probleme të tilla, IS duhet të ketë informacionin e nevojshëm për fushën e temës. Për të zgjidhur probleme të tilla, IS duhet të ketë një inteligjencë të caktuar artificiale ose natyrore. Sistemi i informacionit - një sistem për mbështetjen dhe automatizimin e punës intelektuale - kërkimin, administrimin, ekspertizën dhe vlerësimet ose gjykimet e ekspertëve, vendimmarrjen, menaxhimin, njohjen, grumbullimin e njohurive, trajnimin. Detyrat e grupit të parë janë detyrat e informatizimit të shoqërisë “në gjerësi”.

Detyrat e grupit të dytë - detyrat e informatizimit

shoqëria "e thellë".

Për të zgjidhur detyrat e caktuara, IS duhet të kryejë funksionet e mëposhtme:

 përzgjedhjen e mesazheve nga mjedisi i brendshëm dhe i jashtëm, të nevojshme për zbatimin e veprimtarisë kryesore;

 futja e informacionit në IS;

 ruajtjen e informacionit në kujtesën e IS, përditësimin e tij dhe ruajtjen e integritetit të tij;

 përpunimin, kërkimin dhe nxjerrjen e informacionit në përputhje me kërkesat e përcaktuara nga ODS. Përpunimi mund të përfshijë gjithashtu përgatitjen e opsioneve për zgjidhjen e problemeve të aplikuara nga përdoruesit.

Sistemi i informacionit (IS) është një grup i ndërlidhur mjetesh, metodash dhe personeli që përdoret për ruajtjen, përpunimin dhe lëshimin e informacionit me qëllim arritjen e qëllimit të caktuar. Kuptimi modern i sistemit të informacionit përfshin përdorimin e një kompjuteri personal si mjetin kryesor teknik të përpunimit të informacionit. Një IS është një mjedis, elementët përbërës të të cilit janë kompjuterët, rrjetet kompjuterike, produktet softuerike, bazat e të dhënave, njerëzit, llojet e ndryshme të komunikimeve teknike dhe softuerike, etj. Edhe pse vetë ideja e IP-së dhe disa parime të organizimit të tyre lindi shumë kohë përpara ardhjes së kompjuterëve, megjithatë, kompjuterizimi rriti efikasitetin e IP me dhjetëra e qindra herë dhe zgjeroi fushën e aplikimit të tyre.

Struktura funksionale e sistemit të informacionit.

Në IS, këshillohet të dallohen tre nënsisteme funksionale të pavarura.

Nënsistemi i përzgjedhjes së informacionit. Sistemi i informacionit mund të përpunojë / përpunojë vetëm informacionin që është futur në të. Cilësia e punës së IS përcaktohet jo vetëm nga aftësia e tij për të gjetur dhe përpunuar informacionin e nevojshëm në grupin e vet dhe për t'ia lëshuar atë përdoruesit, por edhe nga aftësia e tij për të zgjedhur informacionin përkatës nga mjedisi i jashtëm. Një përzgjedhje e tillë kryhet nga nënsistemi i përzgjedhjes së informacionit, i cili grumbullon të dhëna për nevojat e informacionit të përdoruesve të IS (të brendshëm dhe të jashtëm), analizon dhe organizon këto të dhëna, duke formuar një profil informacioni IS.

Nënsistemi për futjen, përpunimin/përpunimin dhe ruajtjen e informacionit transformon informacionin dhe kërkesat hyrëse, organizon ruajtjen dhe përpunimin e tyre në mënyrë që të plotësojë nevojat për informacion të abonentëve të IS.

Zbatimi i funksioneve të këtij nënsistemi presupozon praninë e një aparati për përshkrimin e informacionit (sistemet e kodimit, një gjuhë përshkrimi të të dhënave (DLS), etj.), Organizimin dhe ruajtjen e informacionit (organizimi logjik dhe fizik, procedurat për ruajtjen dhe mbrojtjen e informacionit, etj.). etj.), një aparat përpunimi dhe përpunimi i informacionit (algoritme, modele, etj.).

Nënsistemi për përgatitjen dhe dhënien e informacionit zbaton drejtpërdrejt plotësimin e nevojave informative të përdoruesve të SI (të brendshëm dhe të jashtëm). Për të përmbushur këtë detyrë, nënsistemi kryen një studim dhe analizë të nevojave për informacion, përcakton format dhe metodat e përmbushjes së tyre, përbërjen dhe strukturën optimale të produkteve të informacionit të prodhimit, organizon vetë procesin e mbështetjes dhe mirëmbajtjes së informacionit.

Zbatimi i këtyre funksioneve kërkon një aparat për përshkrimin dhe analizimin e nevojave për informacion dhe shprehjen e tyre në gjuhën IS (përfshirë LOD, IPL, gjuhën e indeksimit, etj.), si dhe një aparat për vetë mbështetjen e informacionit (procedurat për kërkimin dhe lëshimin e informacionit , gjuhët e manipulimit të të dhënave etj.). Shumë funksione të nënsistemeve IC janë të dyfishuara ose të mbivendosura, gjë që është objekt i optimizimit në dizajnimin e IC. Në këtë drejtim, automatizimi i IS shoqërohet me rishpërndarjen e elementeve të IS.

Automatizimi presupozon një përfaqësim (strukturim) të zyrtarizuar të funksioneve të IS dhe informacionit të përpunuar në vetë SI, i cili lejon hyrjen, përpunimin / përpunimin, ruajtjen dhe rikthimin e informacionit duke përdorur një kompjuter. Çdo zyrtarizim karakterizohet nga një ose një nivel tjetër i përshtatshmërisë së imazhit të krijuar të realitetit (modelit) të vetë realitetit. Për më tepër, përshtatshmëria e modelit të realitetit përcaktohet si nga vetitë e vetë realitetit ashtu edhe nga aftësitë e aparatit të përdorur për përfaqësimin e tij të zyrtarizuar.

Nga ky këndvështrim, "niveli i automatizimit" të IS është i lidhur ngushtë me "shkallën e strukturimit" të informacionit. Ekzistojnë tre nivele të strukturimit të informacionit: Informacioni i strukturuar në mënyrë të ngurtë (të dhëna) - informacioni, përfaqësimi i zyrtarizuar i të cilit me mjete moderne të strukturimit të tij (në veçanti, gjuhët e përshkrimit të të dhënave) nuk çon në humbjen e përshtatshmërisë së vetë modelit të informacionit.

informacion. Informacioni i strukturuar dobët është informacion, prezantimi i zyrtarizuar i të cilit çon në humbje të konsiderueshme në përshtatshmërinë e modelit të informacionit të vetë informacionit fillestar.

Informacioni i pastrukturuar është informacion për të cilin aktualisht nuk ka mjete për paraqitjen e tij të formalizuar me një nivel të pranueshëm përshtatshmërie në praktikë. Mjetet e paraqitjes së një informacioni të tillë duhet të kenë aftësi të larta semantike dhe shprehëse. Zhvillimi i mjeteve të tilla aktualisht po shkon përgjatë linjës së krijimit të gjuhëve për përshkrimin e njohurive dhe IPL me fuqi të lartë semantike.

Metodologjitë e ndërtimit të sistemeve të informacionit.

Industria për zhvillimin e sistemeve të automatizuara të menaxhimit të informacionit filloi në vitet 1950 - 1960 dhe deri në fund të shekullit fitoi forma plotësisht të përfunduara.

Në fazën e parë, qasja kryesore në hartimin e SI ishte metoda "nga poshtë-lart", kur sistemi u krijua si një grup aplikacionesh që janë më të rëndësishmet për momentin për të mbështetur aktivitetet e ndërmarrjes. Kjo qasje është ruajtur pjesërisht edhe sot. Në kuadrin e "automatizimit me lara-lara", mbështetja për funksionet individuale ofrohet mjaft mirë, por praktikisht nuk ka asnjë strategji për zhvillimin e një sistemi të integruar automatizimi.

Faza tjetër lidhet me realizimin e faktit se ka nevojë për mjete softuerike mjaft standarde për automatizimin e aktiviteteve të institucioneve dhe ndërmarrjeve të ndryshme. Nga i gjithë spektri i problemeve, zhvilluesit kanë identifikuar më të dukshmet: automatizimin e kontabilitetit, kontabilitetin analitik dhe proceset teknologjike. Sistemet filluan të projektohen “lart-poshtë”, d.m.th. me supozimin se një program duhet të plotësojë nevojat e shumë përdoruesve.

Vetë ideja e përdorimit të një programi universal imponon kufizime të rëndësishme në aftësinë e zhvilluesve për të formuar strukturën e bazës së të dhënave, format e ekranit dhe zgjedhjen e algoritmeve të llogaritjes. Kuadri i ngurtë i vendosur "nga lart" nuk bën të mundur përshtatjen fleksibël të sistemit me specifikat e veprimtarisë së një ndërmarrje të caktuar. Kështu, kostot materiale dhe kohore për zbatimin e sistemit dhe rregullimin e tij të imët me kërkesat e klientit. kërkesat zakonisht tejkalojnë ndjeshëm treguesit e planifikuar.

Sipas statistikave të përpiluara nga Standish Group (SSL), nga 8,380 projektet e anketuara nga SSL në 1994, më shumë se 30% e projekteve me një vlerë totale prej më shumë se 80 miliardë dollarë dështuan. Në të njëjtën kohë, vetëm 16% e numrit të përgjithshëm të projekteve u përfunduan në kohë, dhe tejkalimet e kostove arritën në 189% të buxhetit të planifikuar.

Në të njëjtën kohë, klientët IS filluan të parashtrojnë gjithnjë e më shumë kërkesa që synojnë të sigurojnë mundësinë e përdorimit kompleks të të dhënave të korporatës në menaxhimin dhe planifikimin e aktiviteteve të tyre. Kështu, lindi një nevojë urgjente për të formuar një metodologji të re për ndërtimin e sistemeve të informacionit.

Sipas metodologjisë moderne, procesi i krijimit të një SI është një proces i ndërtimit dhe transformimit sekuencial të një numri modelesh të dakorduara në të gjitha fazat e ciklit jetësor të IS (LC). Në secilën fazë të ciklit jetësor, krijohen modele specifike - organizata, kërkesa për

IP. Projekti IP. kërkesat e aplikimit etj. Zakonisht, dallohen fazat e mëposhtme të krijimit të një SI: formimi i kërkesave për sistemin, projektimi, zbatimi, testimi, vënia në punë, funksionimi dhe mirëmbajtja.

Faza fillestare e procesit të krijimit të një SI është modelimi i proceseve të biznesit që ndodhin në organizatë dhe realizimi i qëllimeve dhe objektivave të saj. Modeli i organizatës, i përshkruar në terma të proceseve të biznesit të funksioneve të biznesit, ju lejon të formuloni kërkesat themelore për IS.

Dizajni i IS bazohet në modelimin e domenit. Për të marrë një projekt IS adekuat për fushën e lëndës në formën e një sistemi programesh që funksionojnë siç duhet, është e nevojshme të kemi një përfaqësim integral, sistematik të modelit, i cili pasqyron të gjitha aspektet e funksionimit të sistemit të ardhshëm të informacionit. Në këtë rast, një model domeni kuptohet si një sistem i caktuar që imiton strukturën ose funksionimin e domenit të studiuar dhe plotëson kërkesën bazë - të jetë adekuat për këtë fushë.

Modelimi paraprak i fushës së temës ju lejon të zvogëloni kohën dhe kushtet e punës së projektimit dhe të merrni një projekt më efikas dhe me cilësi të lartë. Pa modeluar domenin, ekziston një probabilitet i lartë për të bërë një numër të madh gabimesh në zgjidhjen e çështjeve strategjike, duke çuar në humbje ekonomike dhe kosto të larta për ridizajnimin e mëvonshëm të sistemit. Si rezultat, të gjitha teknologjitë moderne të dizajnit të IS bazohen në përdorimin e metodologjisë së modelimit të domenit.

Kërkesat e mëposhtme vendosen në modelet e domenit:

Formalizimi, duke ofruar një përshkrim të qartë të strukturës së fushës lëndore;

Kuptueshmëria për klientët dhe zhvilluesit bazuar në përdorimin e mjeteve grafike të shfaqjes së modelit;

Realizueshmëria, që nënkupton disponueshmërinë e mjeteve të zbatimit fizik të modelit të domenit dhe IS;

Sigurimi i një vlerësimi të efektivitetit të zbatimit të modelit të domenit bazuar në metoda të caktuara dhe tregues të llogaritur.

Modelimi funksional IDEF0: përkufizimet dhe dispozitat bazë.

Programi i kompjuterizimit të integruar të prodhimit ICAM (ICAM - Integrated Computer Aided Manufacturing) ka për qëllim rritjen e efikasitetit të ndërmarrjeve industriale përmes futjes së gjerë të teknologjive kompjuterike (informative). Në Shtetet e Bashkuara, kjo rrethanë u realizua në fund të viteve '70, kur Forcat Ajrore të SHBA propozuan dhe zbatuan

Metodologjia IDEF (Përkufizimi ICAM) bën të mundur studimin e strukturës, parametrave dhe karakteristikave të sistemeve prodhuese-teknike dhe organizative-ekonomike (në të ardhmen, ku nuk shkakton konfuzion - sisteme). Metodologjia e përgjithshme IDEF përbëhet nga tre metodologji specifike modelimi të bazuara në paraqitjet grafike të sistemeve:

IDEF0 përdoret për të krijuar një model funksional që shfaq strukturën dhe funksionet e sistemit, si dhe flukset e informacionit dhe objekteve materiale që lidhin këto funksione.

IDEF1 përdoret për të ndërtuar një model informacioni që shfaq strukturën dhe përmbajtjen e rrjedhave të informacionit të kërkuara për të mbështetur funksionet e sistemit;

IDEF2 ju lejon të ndërtoni një model dinamik të sjelljes së funksioneve, informacionit dhe burimeve të sistemit që ndryshon në kohë.

Deri më tani, metodologjitë më të përhapura dhe të aplikuara janë IDEF0 dhe IDEF1 (IDEF1X), të cilat kanë marrë statusin e standardeve federale në Shtetet e Bashkuara. Metodologjia IDEF0, veçoritë dhe aplikimi i së cilës përshkruhen në këtë Dokument Udhëzues (GD), bazohet në qasjen e zhvilluar nga Douglas T. Ross në fillim të viteve 70 dhe të quajtur SADT (Structured Analysis & Design Technique - metoda e analizës strukturore dhe dizajn). Qasja dhe, si rrjedhojë, metodologjia IDEF0 bazohen në një gjuhë grafike për përshkrimin (modelimin) e sistemeve, e cila ka vetitë e mëposhtme.

Për shfaqjen e saktë të ndërveprimeve të komponentëve IS, është e rëndësishme të kryhet modelimi i përbashkët i përbërësve të tillë, veçanërisht nga pikëpamja e përmbajtjes së objekteve dhe funksioneve.

Metodologjia e analizës së sistemeve strukturore ndihmon shumë në zgjidhjen e problemeve të tilla.

Është zakon të quajmë një analizë strukturore një metodë për studimin e një sistemi, i cili fillon me pasqyrën e tij të përgjithshme, dhe më pas detajohet, duke marrë një strukturë hierarkike me një numër në rritje të niveleve. Metoda të tilla karakterizohen nga: ndarja në nivele të abstraksionit me një numër të kufizuar elementësh (nga 3 në 7); konteksti i kufizuar, duke përfshirë vetëm detajet thelbësore të secilit nivel; përdorimi i rregullave të rrepta formale të regjistrimit; përafrim konsistent me rezultatin.

Le të përcaktojmë konceptet kryesore të analizës strukturore të ndërmarrjes (organizatës).

Operacioni është një veprim elementar (i pandashëm) i kryer në një vend pune.

Funksioni - një grup operacionesh të grupuara sipas një veçorie specifike.

Një proces biznesi është një grup funksionesh të lidhura, gjatë ekzekutimit të të cilave konsumohen burime të caktuara dhe krijohet një produkt (objekt, shërbim, shkencor

zbulim, ide), që ka vlerë për konsumatorin.

Një nën-proces është një proces biznesi që është një element strukturor i disa proceseve të biznesit dhe është me vlerë për konsumatorin.

Një model biznesi është një përshkrim i strukturuar grafikisht i një rrjeti procesesh dhe operacionesh të lidhura me të dhëna, dokumente, njësi organizative dhe objekte të tjera që pasqyrojnë aktivitetet ekzistuese ose të synuara të ndërmarrjes. Ekzistojnë metodologji të ndryshme për modelimin e domenit strukturor, ndër të cilat duhet të dallohen metodologjitë e orientuara nga funksioni dhe ato të orientuara nga objekti.

Përshkrimi i një sistemi duke përdorur IDEF0 quhet model funksional. Modeli funksional synon të përshkruajë proceset ekzistuese të biznesit, i cili përdor gjuhë natyrore dhe grafike. Për të përcjellë informacion në lidhje me një sistem specifik, burimi i gjuhës grafike është vetë metodologjia IDEF0.

Metodologjia IDEF0 përshkruan ndërtimin e një sistemi hierarkik të diagrameve - përshkrime të vetme të fragmenteve të sistemit. Së pari, përshkruhet sistemi në tërësi dhe ndërveprimi i tij me botën e jashtme (diagrami i kontekstit), pas së cilës kryhet zbërthimi funksional - sistemi ndahet në nënsisteme dhe secili nënsistem përshkruhet veçmas (diagramet e dekompozimit). Më pas secili nënsistem ndahet në më të vegjël dhe kështu me radhë derisa të arrihet niveli i dëshiruar i detajeve.

Mjedisi i veglave BPwin.

Modelimi i procesit të biznesit zakonisht kryhet duke përdorur mjete rasti. Këto mjete përfshijnë BPwin (teknologji PLATINUM), Silverrun (teknologji Silverrun), Oracle Designer (Oracle), Rational Rose (Rational Software), etj. Funksionaliteti i mjeteve të modelimit strukturor për proceset e biznesit do të diskutohet duke përdorur shembullin e rastit BPwin mjet.

BPwin mbështet tre metodologji modelimi: modelimi funksional (IDEF0); përshkrimi i proceseve të biznesit (IDEF3); diagramet e rrjedhës së të dhënave (DFD). BPwin ka një ndërfaqe përdoruesi mjaft të thjeshtë dhe intuitive. Kur filloni BPwin, si parazgjedhje, shfaqet shiriti kryesor i veglave, paleta e mjeteve (pamja e së cilës varet nga shënimi i zgjedhur) dhe, në të majtë, naviguesi i modelit - Model Explorer).

Kur krijoni një model të ri, shfaqet një dialog në të cilin duhet të specifikoni nëse modeli do të krijohet përsëri ose do të hapet nga një skedar ose nga depoja ModelMart, më pas vendosni emrin e modelit dhe zgjidhni metodologjinë në të cilën modeli do të ndërtohet.

Siç u përmend më lart, BPwin mbështet tre metodologji - IDEF0, IDEF3 dhe DFD, secila prej të cilave zgjidh problemet e veta specifike. Në BPwin, është e mundur të ndërtohen modele të përziera, domethënë, një model mund të përmbajë të dy diagramet IDEF0 dhe IDEF3 dhe DFD në të njëjtën kohë. Përbërja e paletës së mjeteve ndryshon automatikisht kur kalon nga një shënim në tjetrin.

Një model BPwin shihet si një koleksion aktivitetesh, secila prej të cilave operon në një grup të dhënash. Puna përshkruhet si drejtkëndësha, të dhënat si shigjeta. Nëse klikoni në ndonjë objekt të modelit me butonin e majtë të miut, shfaqet një meny e kontekstit, çdo artikull i së cilës korrespondon me redaktuesin e një vetie të caktuar të objektit.

Në fazat fillestare të krijimit të një IP, është e nevojshme të kuptohet se si funksionon organizata që do të automatizojë. Menaxheri e njeh mirë punën në tërësi, por nuk është në gjendje të thellohet në detajet e punës së çdo punonjësi të zakonshëm. Një punonjës i zakonshëm e di mirë se çfarë po ndodh në vendin e tij të punës, por mund të mos dijë se si punojnë kolegët. Prandaj, për të përshkruar punën e një ndërmarrje, është e nevojshme të ndërtohet një model që do të jetë adekuat për fushën lëndore dhe të përmbajë njohuritë e të gjithë pjesëmarrësve në proceset e biznesit të organizatës.

Gjuha më e përshtatshme për modelimin e proceseve të biznesit është IDEF0, ku sistemi përfaqësohet si një grup aktivitetesh ose funksionesh ndërvepruese. Ky orientim thjesht funksional është themelor - funksionet e sistemit analizohen në mënyrë të pavarur nga objektet me të cilat funksionojnë. Kjo ju lejon të modeloni më qartë logjikën dhe ndërveprimin e proceseve të organizatës.

Procesi i modelimit të një sistemi në IDEF0 fillon me krijimin e një diagrami kontekstual - një diagram i nivelit më abstrakt të përshkrimit të sistemit në tërësi, që përmban përkufizimin e temës së modelimit, qëllimin dhe këndvështrimin mbi modelin.

Aktivitetet i referohen proceseve, funksioneve ose detyrave të emërtuara që ndodhin me kalimin e kohës dhe kanë rezultate të dallueshme.

Punimet përshkruhen si drejtkëndësha. Të gjitha punët duhet të emërtohen dhe të përcaktohen. Emri i punës duhet të shprehet me një emër foljor që tregon një veprim (për shembull, "Aktiviteti i kompanisë", "Marrja e një porosie", etj.). Puna "Aktivitetet e Kompanisë" mund të ketë, për shembull, përkufizimin e mëposhtëm: "Ky është një model mësimor që përshkruan aktivitetet e kompanisë". Kur krijoni një model të ri (menyja File / New), krijohet automatikisht një diagram konteksti me një vepër të vetme që përshkruan sistemin në tërësi.

Shigjetat përshkruajnë ndërveprimin e punëve dhe përfaqësojnë disa informacione të shprehura në emra. (Për shembull, "Thirrjet e klientëve", "Rregullat dhe Procedurat", "Sistemi i Kontabilitetit".)

“Modelimi matematikor kompjuterik” Objektivat e studimit të seksionit. Zotërimi i modelimit si një metodë e njohjes së realitetit përreth (natyra kërkimore shkencore e seksionit) - tregohet se modelimi në fusha të ndryshme të njohurive ka karakteristika të ngjashme, shpesh për procese të ndryshme është e mundur të merren modele shumë të ngjashme; - demonstron avantazhet dhe disavantazhet e një eksperimenti kompjuterik në krahasim me një eksperiment në shkallë të plotë; - tregohet se si modeli abstrakt ashtu edhe kompjuteri ofrojnë një mundësi për të njohur botën përreth, për ta kontrolluar atë në interes të njeriut. Zhvillimi i aftësive praktike në modelimin kompjuterik. Jepet metodologjia e përgjithshme e modelimit matematikor kompjuterik. Në shembullin e një numri modelesh nga fusha të ndryshme të shkencës dhe praktikës, praktikisht zbatohen të gjitha fazat e modelimit, nga formulimi i problemit deri te interpretimi i rezultateve të marra gjatë një eksperimenti kompjuterik. Promovimi i orientimit profesional për studentët. Shfaqja e aftësive të studentit për veprimtari kërkimore, zhvillimi i potencialit krijues, orientimi drejt zgjedhjes së një profesioni që lidhet me kërkimin shkencor. Tejkalimi i ndarjes së lëndëve, integrimi i njohurive. Lënda shqyrton modele nga fusha të ndryshme të shkencës duke përdorur matematikën. Zhvillimi dhe profesionalizimi i aftësive kompjuterike. Masterizimi i softuerëve për qëllime të përgjithshme dhe të specializuara, sisteme programimi.

Libër mësuesi për universitetet

Ed. 2, Rev. dhe shtoni.

2014 G.

Tirazhi 1000 kopje.

Formati 60x90 / 16 (145x215 mm)

Ekzekutimi: me kapak

ISBN 978-5-9912-0193-3

BBK 32.882

UDC 621.395

Grif UMO
Rekomanduar nga UMO për edukimin në fushën e telekomunikacionit si tekst shkollor për studentët e institucioneve të arsimit të lartë që studiojnë në specialitetet "Rrjetet dhe Sistemet Switching", "Sistemet Telekomunikuese Shumëkanale"

shënim

Janë marrë në konsideratë algoritmet për modelimin e variablave dhe proceseve të rastësishme diskrete dhe të vazhdueshme. Paraqiten parimet dhe algoritmet për modelimin e sinjaleve informative të përshkruara nga proceset Markov me kohë diskrete dhe të vazhdueshme.Shqyrtohen parimet e modelimit të sistemeve të radhës. Janë përshkruar veçoritë e përshkrimit dhe përdorimit të proceseve fraktale dhe multifraktale për modelimin e trafikut telekomunikues. Janë analizuar metodat dhe shembujt e modelimit të sistemeve të informacionit duke përdorur paketa softuerike të specializuara Matlab, Opnet, Network simulator.

Për studentët e regjistruar në specialitetet “Rrjetet dhe Sistemet komutuese”, “Sistemet e telekomunikacionit shumëkanalësh”, “Sistemet dhe teknologjitë e informacionit”.

Prezantimi

1 Parimet e përgjithshme të modelimit të sistemit
1.1. Konceptet e përgjithshme të modelit dhe modelimit
1.2. Klasifikimi i modelit
1.3. Struktura e modelit
1.4. Bazat metodologjike të formalizimit të funksionimit të një sistemi kompleks
1.5. Modelimi i komponentëve
1.6. Fazat e formimit të një modeli matematikor
1.7. Modelimi simulues
Pyetje kontrolli

2 Parimet e përgjithshme të ndërtimit të sistemeve dhe rrjeteve të komunikimit
2.1. Koncepti i ndërtimit të sistemeve dhe rrjeteve të komunikimit
2.2. Modelet e rrjetit me shtresa
2.2.1. Modeli me tre nivele
2.2.2. Arkitektura e protokollit TCP / IP
2.2.3. Modeli i referencës OSI
2.3. Struktura e rrjetit të komunikimit
2.3.1. Rrjetet globale
2.3.2. Rrjetet lokale
2.3.3. Topologjitë e rrjeteve kompjuterike
2.3.4. Rrjetet lokale Ethernet
2.4. Rrjetet Frame Relay
2.5. Telefonia IP
Pyetje kontrolli

3 Simulimi i numrave të rastit
3.1. Kuptimi i numrave të rastit
3.2. Metodat programatike për gjenerimin e numrave të rastit të shpërndarë në mënyrë uniforme
3.3. Formimi i variablave të rastësishëm me një ligj të caktuar shpërndarjeje
3.3.1. Metoda e funksionit të anasjelltë
3.3.2. Metodat e përafërta për konvertimin e numrave të rastit
3.3.3. Metoda e shqyrtimit (Metoda e gjenerimit të Neumann)
3.4. Metodat e bazuara në teoremën e kufirit qendror
3.5. Algoritme për modelimin e variablave të rastësishëm të përdorura shpesh
3.6. Algoritme për modelimin e variablave të rastësishëm të ndërlidhura
3.7. Formimi i realizimeve të vektorëve dhe funksioneve të rastit
3.7.1. Modelimi i një pike të rastësishme n-dimensionale me koordinata të pavarura
3.7.2. Formimi i një vektori të rastësishëm (në kuadër të teorisë së korrelacionit)
3.7.3. Formimi i zbatimeve të funksioneve të rastit

4 Modelimi i shpërndarjeve diskrete
4.1. Shpërndarja e Bernoulli
4.2. Shpërndarja binomiale
4.3. Shpërndarja Poisson
4.4. Simulimi i provave në një skemë të ngjarjeve të rastësishme
4.4.1. Simulimi i ngjarjeve të rastësishme
4.4.2. Modelimi i ngjarjeve të kundërta
4.4.3. Modelimi i një ndryshoreje të rastësishme diskrete
4.4.4. Modelimi i një grupi të plotë ngjarjesh
4.5. Rrjedhat e ngjarjeve
4.6. Përpunimi i rezultateve të simulimit
4.6.1. Saktësia dhe numri i realizimeve
4.6.2. Përpunimi parësor i të dhënave statistikore
Pyetje kontrolli

5 Algoritme për modelimin e sinjaleve stokastike dhe ndërhyrjet në sistemet e komunikimit
5.1. Algoritmi për modelimin e proceseve stokastike jo stacionare
5.2. Algoritme për modelimin e proceseve të rastësishme stacionare
5.3. Metodat për modelimin e sinjaleve dhe zhurmës në formën e ekuacioneve diferenciale stokastike
5.4. Shembuj të modeleve të proceseve stokastike në sistemet e komunikimit
5.4.1. Modelet e procesit të informacionit
5.4.2. Modelet e ndërhyrjeve
5.4.3. Karakteristikat e llojeve kryesore të ndërhyrjeve
Pyetje kontrolli

6 Proceset stokastike Markov dhe modelimi i tyre
6.1. Konceptet themelore të një procesi stokastik Markov
6.2. Vetitë themelore të zinxhirëve diskrete Markov
6.3. Zinxhirët e vazhdueshëm Markov
6.3.1. Konceptet bazë
6.3.2. Proceset gjysmë-Markov
6.3.3. Vdekja dhe proceset e riprodhimit
6.4. Modele të proceseve të rastësishme Markov me vlerë të vazhdueshme bazuar në ekuacione diferenciale stokastike
6.5. Modelimi i proceseve stokastike Markov
6.5.1. Modelimi i proceseve diskrete
6.5.2. Modelimi i proceseve skalare me vlerë të vazhdueshme
6.5.3. Modelimi i proceseve vektoriale me vlerë të vazhdueshme
6.5.4. Modelimi i një procesi Gaussian me dendësi spektrale fraksionale-racionale
6.5.5. Modelimi i sekuencave të lidhura të shumëzuara
6.5.6. Modelimi i proceseve Markov duke përdorur filtrat e formësimit
6.5.7. Algoritmi për modelimin statistikor të zinxhirëve Markov
Pyetje kontrolli

7 Shembuj të modeleve Markov
7.1. Modelet Markov të dialogut të të folurit të pajtimtarëve
7.1.1. Gjendjet e të folurit
7.1.2. Modelet e dialogut
7.2. Modelet e Markovit të monologut të të folurit
7.3. Procesi Poisson i drejtuar nga Markovi në modelet e të folurit
7.4. Markov modelet e sekuencave dixhitale në daljen e kodekut G.728
7.5. Multipleksimi statistikor i burimit të paketave të të folurit duke marrë parasysh modelin Markov të dialogut telefonik
7.6. Modeli Markov i një kanali pa tel me mekanizëm ARQ / FEC
7.7. Gabimet e grumbullimit
7.8. Llogaritja e karakteristikave të rrjedhës së gabimit sipas parametrave të modelit
7.8.1. Vlerësimi i parametrave të rrjedhës së gabimit
7.8.2. Vlerësimi i përshtatshmërisë së modelit të rrjedhës së gabimit
7.9. Modelet Markov për vlerësimin e QoS të shërbimeve multimediale në kohë reale në internet
7.9.1. Koncepti i shërbimeve multimediale në kohë reale
7.9.2. Analiza dhe modelimi i vonesave dhe humbjeve
7.10. Modelet e rrymave të trafikut multimedial
Pyetje kontrolli

8 Sistemet e radhës dhe modelimi i tyre
8.1. Karakteristikat e përgjithshme të sistemeve të radhës
8.2. Struktura e sistemit të radhës
8.3. Sistemet e radhës me pritje
8.3.1. Sistemi i shërbimit M / M / 1
8.3.2. Sistemi i shërbimit M / G / 1
8.3.3. Rrjetet me një numër të madh nyjesh të lidhura me kanale komunikimi
8.3.4. Shërbimi me prioritet
8.3.5. Sistemi i shërbimit M / M / N / m
8.4. Sistemet e radhës së dështimit
8.5. Parimet e përgjithshme të modelimit të sistemeve të radhës
8.5.1. Metoda e testimit statistikor
8.5.2. Blloko modelet e proceseve të funksionimit të sistemeve
8.5.3. Karakteristikat e modelimit duke përdorur qarqet Q
Pyetje kontrolli

9 Modelimi i sistemeve të informacionit duke përdorur mjete tipike teknike
9.1. Gjuhët e modelimit të sistemit dhe programimit
9.2. Kuptimi i gjuhës GPSS
9.2.1. Objektet dinamike GPSS. Blloqe të orientuara nga transaksionet (operatorët)
9.2.2. Blloqe të orientuara drejt harduerit (operatorë)
9.2.3. Shërbim shumëkanalësh
9.2.4. Blloqet statistikore GPSS
9.2.5. Njësitë operative GPSS
9.2.6. Blloqe të tjera GPSS
9.3. Simulimi i rrjetit ETHERNET në mjedisin GPSS
Pyetje kontrolli

10 Modelimi i sistemeve të transmetimit të informacionit
10.1. Sistemi tipik i transmetimit të të dhënave
10.2. Imuniteti i transmetimit të sinjaleve diskrete. Pritje optimale
10.3. Vlerësimi i probabilitetit të marrjes së gabuar të sinjaleve diskrete me parametra plotësisht të njohur
10.4. Imuniteti i sinjaleve diskrete me parametra të rastësishëm
10.5. Imuniteti i sinjaleve diskrete me marrjen jokoherente
10.6. Imuniteti i sinjaleve diskrete me parametra thelbësorë të rastësishëm
10.7. Algoritme për formimin e sinjaleve diskrete
10.8. Algoritmi për gjenerimin e interferencave
10.9. Algoritmi për demodulimin e sinjaleve diskrete
10.10. Struktura e kompleksit të imitimit dhe nënprogramet e tij
10.11. Mjedisi i softuerit Mathworks Matlab dhe paketa e modelimit vizual Simulink
10.11.1. Përshkrimi teknik dhe ndërfaqja
10.11.2. Paketa e Simulimit Vizual Simulink
10.11.3. Krijimi dhe maskimi i nënsistemit
10.11.4. Paketa shtesë e kutisë së veglave të komunikimit
10.12. Modelimi i blloqeve të sistemit të transmetimit të të dhënave WiMAX
10.12.1. Simulimi i transmetuesit
10.12.2. Modelimi i një kanali transmetimi
10.12.3. Simulimi i marrësit
10.12.4. Zbatimi i modelit në sistemin Mathlab
10.13. Rezultatet e Simulimit të Sistemit WiMAX
Pyetje kontrolli

11 Procese të ngjashme dhe aplikimi i tyre në telekomunikacion
11.1. Bazat e teorisë së proceseve fraktale
11.2. Proceset multifraktale
11.3. Vlerësimi i eksponentit Hurst
11.4. Analiza multifraktale duke përdorur softuer
11.4.1. Përshkrimi i softuerit
11.4.2. Shembuj të vlerësimit të shkallës së vetëngjashmërisë
11.5. Algoritme dhe softuer për analiza multifraktale
11.6. Ndikimi i vetëngjashmërisë së trafikut në karakteristikat e sistemit të shërbimit
11.7. Metodat për modelimin e proceseve të ngjashme në trafikun televiziv
11.8. Eksplorimi i strukturës së ngjashme të trafikut Ethernet
11.9. Kontroll i vetëngjashëm i bllokimit të trafikut
11.10. Lëvizja Fraktal Brownian
11.10.1. Algoritmi RMD për gjenerimin e FBD
11.10.2. Algoritmi i gjenerimit të SRA FWA
11.12. Zhurma Fraktal Gaussian
11.12.1. Algoritmi FFT për sintezën FGS
11.12.2. Vlerësimi i rezultateve të simulimit
Pyetje kontrolli

12 Modelimi i një nyje të rrjetit të telekomunikacionit
12.1. Bazat e Protokollit Frame Rele
12.2. Dizajni i hostit të stafetës së kornizës
12.3. Rezultatet e simulimit të një ruteri FR me kodek G.728 në hyrje
12.4. Ndikimi i vetë-ngjashmërisë së trafikut në QoS
Pyetje kontrolli

13 Sisteme të specializuara për simulimin e rrjeteve kompjuterike
13.1. Karakteristikat e përgjithshme të paketave softuerike të specializuara për modelimin e rrjetit
13.2. Parimet e përgjithshme të modelimit në mjedisin OPNET Modeler
13.3. Shembuj të aplikacionit OPNET
13.3.1. Model për vlerësimin e cilësisë së shërbimit
13.3.2. Zbatimi i modelit të rrjetit lokal
Pyetje kontrolli

14 Simulimi me simulatorin e rrjetit 2
14.1. Historia dhe arkitektura e paketës NS2
14.2. Krijo një objekt simulator
14.3. Krijimi i një topologjie rrjeti
14.4. Vendosja e parametrave të gjeneratorit
14.4.1. Ndezja/Fikur eksponenciale
14.4.2. Pareto Ndez/Fikur
14.5. Dy algoritme kryesore të radhës
14.6. Drejtimi adaptiv në NS2
14.6.1. API e nivelit të përdoruesit
14.6.2. Arkitektura e brendshme
14.6.3. Zgjerime në klasa të tjera
14.6.4. disavantazhet
14.6.5. Lista e komandave të përdorura për të simuluar skriptimin dinamik në NS2
14.6.6. Një shembull i rrugëzimit dinamik në NS2
14.7. Ekzekutimi i një programi skripti në NS2
14.8. Procedura e përpunimit të rezultateve të simulimit
14.9. Një shembull i modelimit të një rrjeti pa tel
14.10. Një shembull i simulimit të cilësisë së transmetimit të videos duke përdorur paketën NS 2
14.10.1. Struktura e kompleksit të harduerit dhe softuerit për vlerësimin e cilësisë së transmetimit të videos
14.10.2. Modulet funksionale të AKP-së
14.10.3. Vlerësimi i cilësisë së videos