Metodika pre modelovanie domén. Implementačné nástroje pre technológiu objektovo orientovaného programovania

Objektovo orientované modelovanie

Všeobecne uznávanou filozofiou vo väčšine moderných grafických systémov pri vytváraní výkresov na počítači je používanie najjednoduchších geometrických primitív: bodov, segmentov a oblúkov. Pomocou rôznych kombinácií uvedených primitív, priradením určitých hodnôt ich geometrickým vlastnostiam (čo znamená súradnice charakteristických bodov, dĺžok, polomerov atď.), ako aj pomocou editačných príkazov zabudovaných v programe, používateľ môže vytvoriť ľubovoľne zložitý obrázok. Môžete namietať, že takmer v každom grafickom systéme je aj oveľa viac príkazov na kreslenie, povedzme, Bézierových kriviek alebo NURBS kriviek. Aby vás to však nevyviedlo z omylu: na hardvérovej úrovni sú všetky tieto krivky a splajny stále preložené do sekvenčnej sady segmentov, ktoré aproximujú skutočnú krivku (teda čo najbližšie k skutočnej polohe krivky). Približne rovnaký prístup sa používa aj pri 3D modelovaní telies: zložitý 3D objekt sa vytvára postupnými kombináciami rôznych základných 3D tvarov (kocka, guľa, kužeľ, anuloid atď.), ako aj pomocou základných tvarovacích operácií (extrúzia, rotácia, atď.). Booleovská operácia atď.) atď.).

Vo väčšine prípadov je tento prístup pre používateľov celkom uspokojivý, pretože umožňuje vytvárať obrázky a modely prakticky akéhokoľvek tvaru. Je to však za cenu času stráveného učením sa funkčnosti grafického systému, ako aj času stráveného tvorbou každého takéhoto výkresu alebo 3D modelu. Poplatok v skutočnosti nie je taký veľký, ale čoskoro tento prístup prestal používateľom vyhovovať. Za príčinu je potrebné v prvom rade považovať skutočnosť, že používateľ pri navrhovaní vytvára model alebo obraz skutočného (aj keď ešte neexistujúceho) hmotného objektu. Každý takýto objekt skutočného sveta je vybavený dobre definovanými vlastnosťami, ktoré nie je možné vždy sprostredkovať prostredníctvom obrazu konvenčného výkresu alebo 3D modelu. Je potrebné poznamenať, že takáto príležitosť s vývojom prostriedkov, a teda aj požiadaviek na dizajn, by nebola zbytočná. To bol impulz, ktorý prinútil jednotlivých vývojárov vydať sa trochu inou cestou, v dôsledku čoho bol vynájdený objektový prístup.

V objektovo orientovanom modelovaní používateľ nepracuje s najjednoduchšími geometrickými primitívami, ale so špecifickými objektmi. Napríklad pri konštrukcii pôdorysu budovy sa dnes namiesto bodov, segmentov a oblúkov používajú steny, okná, dvere, samostatné miestnosti atď.. Každý takýto objekt je obdarený určitým súborom vlastností, ktoré sú nastavené (resp. priradené štandardne) pri vytváraní objektu a sú uložené v súbore dokumentu spolu s obrázkom výkresu alebo geometriou 3D modelu. Pri oknách môžu tieto vlastnosti zahŕňať celkové rozmery a popis tvaru okna (obdĺžnikový, polkruhový, oblúkový alebo akýkoľvek iný tvar), optické vlastnosti zasklenia a materiál a štruktúru rámu. V prípade stien hrúbka, dĺžka a výška steny, materiál steny, štruktúra vonkajších a vnútorných povrchov, skutočnosť, že na tejto stene sú okná alebo dvere, ako aj odkazy na predmety zodpovedajúce týmto oknám alebo dvere.

V 3D modelovaní je 3D scéna tiež zostavená zo samostatných objektov, ktoré systém ponúka užívateľovi na výber. Napríklad, ak je určitý program určený na modelovanie dizajnu obytných miestností alebo obchodných priestorov, potom databázu takéhoto programu môže predstavovať súbor rôzneho čalúneného alebo kancelárskeho nábytku, skríň, stolov atď. interiérový objekt má tiež špecifické vlastnosti, ktoré umožňujú jeho úpravu v určitých limitoch (zmena farby, konfigurácie, výber materiálu a iné vlastnosti).

Použitie objektového prístupu má mnoho výhod.

Rýchlosť vytvárania plánov a výkresov sa rádovo zvyšuje.

Výkres alebo model sa stáva informatívnejším: pri výbere (alebo úprave) objektu môžete jednoducho definovať (nahradiť) jeho vlastnosti a väčšina týchto vlastností sa spravidla nedá zobraziť na bežnom výkrese alebo modeli.

Databáza objektov je niekedy zaplnená nie len ľubovoľnými, vopred pripravenými, ale celkom reálnymi predmetmi (napríklad kusy nábytku z praxe od rôznych firiem, materiály od konkrétnych výrobcov a pod.). V takýchto prípadoch musí program obsahovať adresy dodávateľov a výrobcov, kde môžete ihneď po dokončení projektu kontaktovať a objednať potrebné materiály a iné predmety.

Objekty sa ľahko menia a upravujú, pričom program sleduje správnosť nastavenia hodnôt určitých vlastností (napríklad nemôžete vytvoriť okno väčšie ako sú rozmery steny, na ktorej je umiestnené). To uľahčuje prácu a predchádza neúmyselným chybám.

Postavený model (výkres) je možné znázorniť ako hierarchický strom (obr. 1.1), čo uľahčuje navigáciu v projekte, vyhľadávanie a úpravu jeho jednotlivých častí.

Ryža. 1.1. Príklad hierarchickej reprezentácie stavebného plánu vytvoreného na základe objektového prístupu

Poznámka

Hierarchická reprezentácia nie je v počítačom podporovanom dizajne ani zďaleka nová. V tomto prípade však uzly stromu nie sú samostatnými časťami grafického obrazu, ktoré spravidla nie sú informatívne a nenesú žiadnu sémantickú záťaž, ale konkrétne objekty rozdelené podľa určitého atribútu.

Jednou z hlavných, ale v žiadnom prípade nie zrejmých výhod objektovo orientovaného prístupu pri vytváraní grafických obrázkov je schopnosť rýchlo a úplne automaticky prejsť na trojrozmerný obrázok (inými slovami, schopnosť automaticky generovať trojrozmerný obrázok). rozmerový model navrhovaného objektu). Berúc do úvahy skutočnosť, že množina objektov, ktoré môže používateľ obsluhovať, je v každom prípade obmedzená, a tiež s prihliadnutím na skutočnosť, že do vlastností každého objektu možno vložiť dostatok informácií na získanie úplného obrazu o jeho tvare, je možné realizovať „zdvihnutie“ grafického obrazu v 3D bez akejkoľvek námahy zo strany používateľa (toto je prístup implementovaný v systéme ArCon). Výsledkom je, že používateľ takmer okamžite dostane trojrozmernú reprezentáciu svojho projektu, pričom nevynaloží takmer žiadne úsilie. Výsledný trojrozmerný model je potom možné vizualizovať a získať realistický obraz alebo ho preniesť do iného systému na ďalšie úpravy alebo inžinierske výpočty. Navyše v tomto prípade používateľ nepotrebuje žiadne špeciálne zručnosti v oblasti 3D modelovania.

Poznámka

Tejto vlastnosti by sa mala venovať väčšia pozornosť, pretože generovanie trojrozmerného modelu z výkresov bolo dlho kameňom úrazu pre všetkých vývojárov inžinierskych grafických systémov. V praxi sa totiž realizuje opačný princíp - generovanie výkresu (v podstate projekcia 3D modelu) z hotového modelu. Pokus o implementáciu reverznej akcie (prechod z dvojrozmerného obrazu na 3D) sa uskutočnil v niektorých známych CAD systémoch (najmä v SolidWorks), ale je ťažké ho nazvať úspešným. Na dvojrozmerný obraz sú kladené príliš prísne obmedzenia, ktoré nedovoľujú všade aplikovať deklarovanú funkcionalitu. Objektový prístup poskytuje možnosť získania kompletného trojrozmerného modelu, samozrejme s prihliadnutím na špecifiká konkrétnych objektov.

Napriek veľkému počtu výhod uvedených vyššie má objektovo orientovaný prístup aj nevýhody.

V prvom rade (a to je zrejmé) je obmedzená množina hotových predmetov, ako aj nemožnosť ich svojvoľnej zmeny. To odoberá flexibilitu programu, čo znamená, že princíp objektového dizajnu možno aplikovať iba v špecializovaný systémy (ako napr. ArCon, Professional Home Design Platinum atď.). Vývojári takýchto systémov musia brať do úvahy špecifiká odvetvia, pre ktoré je softvérový produkt určený na automatizáciu a riešenie problémov, ako aj na maximalizáciu schopnosti prispôsobiť vlastnosti navrhovaných objektov.

Tu vystupuje do popredia otázka ceny a funkčnosti systému. Ak ste si 100% istý, že konkrétny špecializovaný program je vhodný pre vaše účely, nemali by ste pri jeho kúpe pochybovať. V opačnom prípade si treba podrobnejšie naštudovať funkčnosť, či bude možné úlohy riešiť alebo v horšom prípade budete musieť minúť peniaze na „obyčajný“ a drahý CAD editor.

Druhou nevýhodou objektovo orientovaných systémov grafického inžinierstva je problém integrácie s inými grafickými systémami. Nehovoríme o žiadnych problémoch pri prenose dát – výmena dvojrozmerných aj trojrozmerných informácií sa už dlho považuje za štandard pre akékoľvek komerčné programy. Podstata problému spočíva práve v strate hodnôt vlastností objektov, ako aj všetkých hierarchických vzťahov budovaných medzi objektmi. Dôvod je jasný: systém, do ktorého plánujete exportovať projekt, nemusí podporovať objektový prístup alebo môže mať zoznam vlastností pre svoje vlastné objekty, ktorý je odlišný od tohto. Z tohto dôvodu sa pri ukladaní projektu z programu ArCon do iného formátu (nie objektu ArCon) exportuje iba grafický obrázok.

Poznámka

Pri pohľade do budúcnosti poviem, že projekty ArCon+ 2005 je možné exportovať do rôznych 2D a 3D formátov pomocou súboru? Exportujte vo formáte (obr. 1.2). Je dôležité poznamenať, že program podporuje také známe formáty výmeny údajov ako VRML, DXF, systémový formát 3ds Max, ako aj možnosť uložiť projekt do spustiteľného súboru EXE (viac o tom neskôr).

Ryža. 1.2. Podporované formáty pre export projektov z ArConu

Pri importe dát z iných systémov je situácia ešte horšia. Ak sa nedostanú do určitého formátu, nie je možné ich „prevziať“ do objektovo špecializovaného systému. Napríklad pri importe výkresu z AutoCADu do ArConu je možné načítať iba obrázok. ArCon zároveň nebude vedieť samostatne rozpoznať, kde sú na otvorenom obrázku okná, dvere, steny atď., ba čo viac, priradiť jednotlivým objektom celkom rozumné vlastnosti. To znamená, že ďalšia úprava výkresu v ArCone, ako aj jeho „prevýšenie“ do 3D, je nemožná. Import v podstate stráca zmysel, a preto drvivá väčšina objektovo orientovaných návrhových systémov nemá funkcie na čítanie grafických údajov zvonku.

Napriek takýmto výrazným nedostatkom však prevláda jednoduchosť práce a hlavne rýchlosť a prehľadnosť realizácie projektu. Výsledkom je, že systémy ako program ArCon, o ktorom sa hovorí v tejto knihe, nedávno našli široké uplatnenie pri riešení rôznych konštrukčných problémov.

Vo vývoji softvéru existuje niekoľko prístupov k modelovaniu. Najdôležitejšie z nich sú algoritmické (štrukturálne) a objektovo orientované.

Štrukturálna metóda predstavuje tradičný prístup k vývoju softvéru. Hlavným stavebným kameňom je procedúra alebo funkcia a pozornosť sa venuje predovšetkým prevodu riadenia a rozkladu veľkých algoritmov na menšie.

Najmodernejší prístup k vývoju softvéru je objektovo orientovaný. Objekt alebo trieda tu funguje ako hlavný stavebný blok. V najvšeobecnejšom zmysle je objekt entita, zvyčajne získaná zo slovnej zásoby domény alebo riešenia, a trieda je popis množiny objektov rovnakého typu. Každý objekt má identitu (možno ho pomenovať alebo inak odlíšiť od iných objektov), ​​stav (zvyčajne sú nejaké údaje spojené s objektom) a správanie (môže s ním niečo robiť alebo so sebou). iné predmety).

Ako príklad si predstavte trojvrstvovú architektúru fakturačného systému pozostávajúcu z používateľského rozhrania, middlewaru a databázy. Rozhranie obsahuje konkrétne objekty – tlačidlá, ponuky a dialógové okná. Databázu tvoria aj špecifické objekty, konkrétne tabuľky, reprezentujúce entity predmetnej oblasti: zákazníci, produkty a objednávky. Middleware zahŕňa objekty, ako sú transakcie a obchodné pravidlá, ako aj abstraktnejšie reprezentácie doménových entít (zákazníkov, produktov a objednávok).

Ak prijmeme objektovo orientovaný pohľad na svet, treba zodpovedať množstvo otázok. Akú štruktúru by mala mať dobrá objektovo orientovaná architektúra? Aké artefakty by mali byť vytvorené v procese práce na projekte? Kto by ich mal vytvoriť? A nakoniec, ako zhodnotiť výsledok?

Vizualizácia, špecifikácia, návrh a dokumentácia objektovo orientovaných systémov – to je účelom jazyka UML.

Objektovo orientované modelovacie jazyky sa objavili v období od polovice 70. do konca 80. rokov, keď výskumníci čelili potrebe zohľadniť nové vlastnosti objektovo orientovaných programovacích jazykov a požiadavky čoraz zložitejších aplikácií. boli nútení vyvinúť rôzne alternatívne prístupy k analýze a dizajnu.

Technológia vývoja softvérových systémov založených na paradigme reprezentovania sveta vo forme objektov, ktoré sú inštanciami zodpovedajúcich tried, sa nazýva objektovo orientovaná analýza a dizajn (OOAP) – OOA&D (Object-Oriented Analysis/Design). V rámci tejto technológie je jazyk UML prostriedkom na grafické znázornenie výsledkov modelovania nielen softvéru, ale aj širších tried systémov a podnikových aplikácií, pomocou objektovo orientovaných konceptov. Zároveň je explicitne stanovený vzťah medzi základnými konceptmi pre modely koncepčnej a fyzickej úrovne a je dosiahnutá škálovateľnosť modelov, čo je dôležité najmä pre zložité viacúčelové systémy.

Samotní vývojári jazyka ho definujú ako „všeobecný vizuálny modelovací jazyk určený na špecifikáciu, vizualizáciu, návrh a dokumentáciu softvérových komponentov, obchodných procesov a iných systémov“.

V technológii OOP je vzťah medzi dátami a algoritmom pravidelnejší: po prvé, trieda (základný koncept tejto technológie) kombinuje dáta (štruktúrovaná premenná) a metódy (funkcie). Po druhé, schéma interakcie medzi funkciami a údajmi je zásadne odlišná. Metóda (funkcia) volaná na jeden objekt zvyčajne nevolá inú funkciu priamo. Najprv musí mať prístup k inému objektu (vytvoriť, získať ukazovateľ, použiť interný objekt v aktuálnom a pod.), potom už môže naň volať niektorú zo známych metód. Štruktúra programu je teda určená vzájomnou interakciou objektov rôznych tried. Spravidla existuje hierarchia tried a technológiu OOP možno nazvať aj programovaním „od triedy k triede“.

Akékoľvek programovanie sa vykonáva podľa jedného zo štyroch princípov:

Princíp modularity

Princíp „od všeobecného k konkrétnemu“

Princíp krok za krokom

Princíp štruktúrovania

Modulárne programovanie. Princíp modularity je formulovaný ako požiadavka na vývoj programu vo forme súboru modulov (funkcií). Zároveň by rozdelenie na moduly nemalo byť mechanické, ale malo by vychádzať z logiky programu:

1. veľkosť modulu by mala byť obmedzená;

2. modul musí vykonať logicky úplnú a úplnú akciu;

3. Modul musí byť univerzálny, t. j. čo najviac parametrizovaný: všetky meniteľné charakteristiky vykonávanej akcie musia byť prenesené cez parametre;

4. Vstupné parametre a výsledok modulu je žiaduce odovzdať nie cez globálne premenné, ale cez formálne parametre a výsledok funkcie.

Ďalšou, ale už fyzickou jednotkou programu je textový súbor obsahujúci množstvo funkcií a definícií dátových typov a premenných. Modulárne programovanie na úrovni súborov je schopnosť rozdeliť celý program do viacerých súborov. Princíp modularity platí nielen pre programy, ale aj pre dáta: každý súbor parametrov, ktoré charakterizujú logický alebo fyzický objekt, musí byť v programe reprezentovaný ako jedna dátová štruktúra (štruktúrovaná premenná).

Stelesnením princípu modularity je knižnica štandardných funkcií. Zvyčajne poskytuje kompletnú sadu parametrizovaných akcií pomocou bežných dátových štruktúr. Knižnice sú podobné programy nezávisle zostavené a umiestnené v adresári knižnice.

Programovanie zhora nadol. Dizajn programu zhora nadol spočíva v tom, že vývoj prechádza od všeobecnej neformálnej formulácie nejakej činnosti programu v prirodzenom jazyku, „od všeobecného k konkrétnemu“: k jeho nahradeniu jedným z troch formálnych konštrukcií programovacieho jazyka:

jednoduchá postupnosť akcií;

· konštrukcie podľa výberu alebo operátora, ak;

· konštrukcie opakovania alebo cyklu.

V zápise algoritmu to zodpovedá pohybu od vonkajšej (objímajúcej) štruktúry k vnútornej (vnorenej). Tieto konštrukcie môžu tiež obsahovať neformálne popisy akcií vo svojich častiach, to znamená, že dizajn zhora nadol je vo svojej podstate krok za krokom. Upozorňujeme na hlavné vlastnosti tohto prístupu:

Spočiatku je program formulovaný ako nejaká neformálna akcia v prirodzenom jazyku;

Najprv sa určia vstupné parametre a výsledok akcie;

· ďalší krok detailovania nemení štruktúru programu získanú v predchádzajúcich krokoch;

Ak sa počas procesu navrhovania získajú rovnaké akcie v rôznych odvetviach, znamená to potrebu navrhnúť túto akciu ako samostatnú funkciu;

· Potrebné dátové štruktúry sa navrhujú súčasne s detailovaním programu.

programovanie krok za krokom. Dizajn zhora nadol je vo svojej podstate prírastkový, pretože zahŕňa nahradenie jednej verbálnej formulácie vždy jediným jazykovým konštruktom. V procese vývoja programu však môžu existovať aj ďalšie kroky súvisiace s podrobným rozpracovaním samotnej verbálnej formulácie do detailnejšej podoby.

Skutočnosť, že tento princíp je vyčlenený, naznačuje potrebu vyhnúť sa pokušeniu podrobne program od začiatku do konca a rozvíjať schopnosť zvýrazniť a zamerať sa na hlavné, a nie vedľajšie detaily algoritmu.

Vo všeobecnosti platí, že postupný návrh programu zhora nadol nezaručuje „správny“ program, ale umožňuje vám vrátiť sa k jednému z vyšších krokov detailovania, keď sa zistí zablokovanie.

Štrukturálne programovanie. So zostupným podrobným popisovaním programu krok za krokom sa objavujú dátové štruktúry a premenné potrebné na prevádzku, keď prechádzame od neformálnych definícií k jazykovým konštruktom, to znamená, že procesy detailovania algoritmu a údajov idú paralelne. Týka sa to však predovšetkým jednotlivých lokálnych premenných a vnútorných parametrov. Z veľmi všeobecného hľadiska je subjekt (v našom prípade dáta) vždy primárny vo vzťahu k akciám, ktoré sa s ním vykonávajú (v našom prípade algoritmus). Preto v skutočnosti spôsob, akým sú dáta organizované v programe, ovplyvňuje jeho algoritmickú štruktúru výraznejšie ako čokoľvek iné a proces navrhovania dátových štruktúr by mal byť pred procesom navrhovania algoritmu na ich spracovanie.

Štruktúrované programovanie je modulárny návrh algoritmu a dátových štruktúr zhora nadol.

Objektovo orientovaný prístup k programovaniu zahŕňa 3 hlavné komponenty:

objektovo orientovaná analýza (OOA),

objektovo orientovaný dizajn (OOD),

· objektovo orientované programovanie (OOP).

V akejkoľvek inžinierskej disciplíne sa dizajn zvyčajne chápe ako jednotný prístup, pomocou ktorého hľadáme spôsoby, ako vyriešiť určitý problém a zabezpečiť splnenie úlohy. V kontexte inžinierskeho dizajnu je cieľ dizajnu definovaný ako vytvorenie systému, ktorý

Spĺňa dané (možno neformálne) funkčné špecifikácie;

v súlade s obmedzeniami danými zariadením;

· spĺňa explicitné a implicitné požiadavky na výkon a spotrebu zdrojov;

· spĺňa explicitné a implicitné kritériá dizajnu produktu;

· spĺňa požiadavky na samotný vývojový proces, ako je napríklad trvanie a náklady, ako aj zapojenie dodatočných nástrojov.

Dizajn zahŕňa zohľadnenie protichodných požiadaviek. Jej produkty sú modely, ktoré nám umožňujú pochopiť štruktúru budúceho systému, vyvážiť požiadavky a načrtnúť schému implementácie.

Program je numerickým modelom navrhnutého systému (obr. 1.3.1.)

Ryža. 1.3.1.

Dôležitosť zostavenia modelu. Modelovanie je všadeprítomné vo všetkých inžinierskych disciplínach, z veľkej časti preto, že implementuje princípy dekompozície, abstrakcie a hierarchie. Každý model popisuje určitú časť uvažovaného systému a my zasa staviame nové modely na základe starých, v ktorých sme si viac či menej istí. Modely nám umožňujú kontrolovať naše zlyhania. Vyhodnocujeme správanie každého modelu v bežných aj neobvyklých situáciách, a ak nás niečo neuspokojuje, robíme príslušné úpravy.

Prvky návrhu softvéru. Je zrejmé, že neexistuje univerzálna metóda, ktorá by previedla softvérového inžiniera od požiadaviek zložitého softvérového systému až po ich splnenie. Navrhovanie komplexného softvérového systému nie je o slepom dodržiavaní súboru receptov. Ide skôr o postupný a opakovaný proces. A napriek tomu použitie metodológie dizajnu zavádza určitú organizáciu do procesu vývoja. Softwaroví inžinieri vyvinuli desiatky rôznych metód, ktoré môžeme zaradiť do troch kategórií. Napriek rozdielom majú tieto metódy niečo spoločné. Spája ich najmä toto:

Konvencie - jazyk na popis každého modelu;

proces - pravidlá návrhu modelu;

· nástroje – nástroje, ktoré urýchľujú proces tvorby modelov, a v ktorých sú už zakotvené zákonitosti fungovania modelov. Nástroje pomáhajú identifikovať chyby v procese vývoja.

Dobrá metóda návrhu je založená na solídnom teoretickom základe a zároveň umožňuje programátorovi určitý stupeň slobody prejavu.

Objektovo orientované modely. Najužitočnejšie je vytvárať modely, ktoré zameriavajú pozornosť na objekty nachádzajúce sa v samotnej doméne a tvoria to, čo sa nazýva objektovo orientovaný rozklad.

Objektovo orientovaná analýza a návrh je technika, ktorá logicky vedie k objektovo orientovanej dekompozícii. Aplikovaním objektovo orientovaného dizajnu sú programy flexibilné a písané nákladovo efektívnym spôsobom. Rozumným rozdelením štátneho priestoru dosiahneme väčšiu dôveru v správnosť nášho programu. V dôsledku toho znižujeme riziko pri vývoji zložitých softvérových systémov.

Keďže budovanie modelov je nevyhnutné pri navrhovaní zložitých systémov, objektovo orientovaný dizajn ponúka bohatý výber modelov (zobrazené na obrázku 1.3.2) Objektovo orientované modely odrážajú hierarchiu tried a systémových objektov. Tieto modely pokrývajú celý rad kritických návrhových rozhodnutí, ktoré je potrebné zvážiť pri navrhovaní komplexného systému, a tak nás inšpirujú k vytváraniu návrhov, ktoré majú všetkých päť atribútov dobre organizovaných komplexných systémov.

Ryža. 1.3.2

OOP je programovacia ideológia založená na kombinácii údajov a procedúr, ktoré dokážu pracovať s týmito údajmi v súhrnoch, nazývaných triedy.

Podstatou OOP je použitie objektového modelu známeho v každodennom živote. Každý objekt má svoje vlastné vlastnosti a môžete vykonávať akcie, ktoré sú preň špecifické. Trieda je typ objektu. Trieda popisuje a implementuje práve tieto vlastnosti a akcie. Objekt v našom chápaní bude premenná, ktorej typom bude nejaká trieda. Polia triedy budeme nazývať jej vlastnosti a metódy - akcie, ktoré možno vykonať s inštanciou tejto triedy (objektu).

V príklade implementácie triedy zvážte implementáciu konceptu knihy pomocou triedy na definovanie reprezentácie knihy TBook a sady funkcií na prácu s premennými tohto typu:

PagesCount: integer;

function CompareWithBook(OtherBook: TBook): integer;

postup ShowTitle;

konštruktor Create(NewTitle, New

Ľudské kognitívne schopnosti sú obmedzené; ich rozsah môžeme rozširovať pomocou dekompozície, extrakcie abstrakcie a vytvárania hierarchií.

Komplexné systémy možno skúmať zameraním sa buď na objekty alebo procesy; Existujú dobré dôvody na použitie objektovo orientovaného rozkladu, v ktorom je svet vnímaný ako usporiadaná kolekcia objektov, ktoré v procese vzájomnej interakcie určujú správanie systému.

Objektovo orientovaná analýza a návrh – metóda, ktorá využíva rozklad objektov; objektovo orientovaný prístup má svoj vlastný zápis a ponúka bohatú sadu logických a fyzikálnych modelov, pomocou ktorých môžeme získať predstavu o rôznych aspektoch posudzovaného systému.

Michail Vasiliev, Igor Khomkov, Sergej Shapovalenko

Prakticky vo všetkých fázach životného cyklu informačných systémov (IS) - ako pri návrhu, keď sú stanovené hlavné charakteristiky systému, tak aj pri údržbe a správe už vybudovaného IS - existuje množstvo otázok prvoradej závažnosti. Bude táto architektúra IS spĺňať rastúce potreby? Aké úzke miesta si vyžadujú najväčšiu pozornosť? Aké investície sú potrebné na udržanie prevádzkyschopnosti IS o rok?.. tri roky?.. päť rokov? Aká je efektívnosť používaného IS?

V žiadnom prípade nie je ľahké odpovedať na všetky tieto otázky. Ešte ťažšie je na ne správne odpovedať. Analýza podnikového informačného systému v ktorejkoľvek fáze jeho existencie je komplexná záležitosť.

Dá sa povedať, že komplexnosť podnikových informačných systémov nie je náhodná, ale skôr nevyhnutná vlastnosť. Je určená niekoľkými dôvodmi, medzi ktoré patria:

Zložitosť riešeného problému;

Zložitosť rozvoja IS;

Zložitosť zabezpečenia takých parametrov, ako je primeranosť, škálovateľnosť, spoľahlivosť, nákladová efektívnosť a bezpečnosť;

Zložitosť popisu jednotlivých subsystémov IS.

Objektívne hodnotenia možno poskytnúť pomocou modelovacích technológií. Zostavenie modelu, jeho analýza a získanie odpovedí na otázky „čo sa stane, ak...?“ umožňujú predpovedať správanie IS v rôznych situáciách. Najčastejšie sa používa bench prototyping a konštrukcia počítačových modelov IP.

V súčasnosti sú na trhu nástrojov na modelovanie informačných systémov traja lídri. Ide o americké spoločnosti MIL3 (simulačný systém OPNET), Make Systems (systém NetMaker XA) a CACI Products Company (systém COMNET). Na obr. 1 je zobrazené hlavné okno systému OPNET. (V PC Week / RE, č. 34/98, s. 36 je na obrázku 2 zobrazené okno pre grafické znázornenie výsledkov v systéme OPNET.) Zastavme sa pri jednom z týchto systémov a v ňom implementovanom prístupe podrobnejšie. .

Technológia modelovania IC pomocou COMNET III

Samozrejmým spôsobom modelovania zložitých systémov je ich rozloženie podľa starovekého princípu Divide et impera (Rozdeľuj a panuj. – lat.). Hierarchické znázornenie zložitých IS ako súboru prepojených subsystémov je kľúčom k odhaleniu situácie. Subsystémy získané v dôsledku takéhoto rozkladu môžu byť zase rozdelené do podsystémov ďalšej úrovne hierarchie atď. do nekonečna. Práve schopnosť rozkladať zložité systémy nám umožňuje vytvárať ich modely. Na tejto ceste je však mimoriadne dôležité vedieť sa včas zastaviť.

Konečná fáza procesu rozkladu je určená najnižšou úrovňou abstrakcie aplikovanej v každom konkrétnom modeli. Príliš detailná fragmentácia môže viesť k výsledku, ktorý je v priamom rozpore s tým, čo sa očakáva: namiesto zjednodušenia modelovaného systému ho možno skomplikovať až k tomu, čo sa nazýva „pre stromy nevidíte les“. Pre úspešné modelovanie je teda nevyhnutná správna úroveň abstrakcie.

Ďalším krokom pri uľahčovaní modelovania zložitých systémov je objavenie a extrakcia bežných abstrakcií. Predpokladajme, že sme už vykonali dekompozíciu modelovaného IS a získali určitú hierarchiu entít. Napríklad smerovač Cisco 7500 a počítač NS7000 vybavený viacerými sieťovými kartami a vykonávajúci softvérové ​​smerovanie možno považovať za dve úplne odlišné entity alebo ako dve entity patriace do rovnakej triedy smerovačov. Dekompozícia systému pomocou metafory triedy v kombinácii so správne zvolenou úrovňou abstrakcie umožňuje radikálne zjednodušiť konštrukciu modelu IS.

Ryža. 1. Hlavné okno systému OPNET

Zvyčajne sa berú do úvahy dva hlavné typy rozkladu: algoritmický, ktorý rozdeľuje skúmaný systém podľa jeho aktívnych princípov, tj procesov, ktoré sa v ňom vyskytujú v určitom poradí, a objektovo orientovaný, ktorý umožňuje rozdelenie skúmaného systému do tried abstrakcie rovnakého typu. Oba typy rozkladu si našli cestu do COMNET III.

Prístup k budovaniu modelov v COMNET III môže byť reprezentovaný ako štandardná postupnosť krokov:

Popis topológie IC a určenie parametrov zariadenia;

Popis zdrojov návštevnosti a ich správania, popis zaťaženia siete;

Definícia simulačného scenára.

Definícia topológie IS a prepojenia dopravných zdrojov s uzlami topológie je ideálnou oblasťou pre aplikáciu objektovo orientovanej dekompozície. Algoritmická dekompozícia je potrebná na opísanie správania sa zdrojov prevádzky a zmien zaťaženia siete v priebehu času.

Ako už bolo uvedené, okrajové podmienky pre rozklad IS závisia od požadovanej úrovne abstrakcie. Abstrakcia umožňuje vývojárovi, ktorý vytvára projekt IS, alebo správcovi systému, ktorý ho udržiava, oddeliť najvýznamnejšie črty jeho správania od spôsobu ich implementácie. „Dobrá abstrakcia je taká, ktorá zdôrazňuje detaily, ktoré sú nevyhnutné na zváženie a použitie, a vynecháva tie, ktoré sú v súčasnosti irelevantné alebo rušivé“ * 1. V jednej situácii teda pri popise počítača stačí definovať ho ako zdroj návštevnosti bez toho, aby sme zachádzali do podrobného opisu architektúry, zatiaľ čo v inej situácii stačí podrobné zváženie jeho charakteristík, ako je napríklad počet procesory a parametre diskového subsystému, môžu byť potrebné.

*jeden. Shaw M. Abstrakce technika v moderných programovacích jazykoch. - IEEE softvér, okt. 1984, v. 1(4), str.10.

V systéme COMNET je plne aplikovateľná objektovo orientovaná metóda dekompozície, ktorá môže výrazne skrátiť čas modelovania a urobiť jeho proces intuitívnym a jasne korelujúcim s reálnym systémom. Model je vytvorený z objektov, akýchsi „stavebných blokov“, ktoré používateľ pozná z reálnych životných skúseností. Systém COMNET prichádza s veľkou knižnicou takýchto objektov - modelov reálnych sieťových zariadení a spôsobov prístupu do prostredia. Pozrime sa bližšie na objektový model COMNET (obr. 2).

Ryža. 2. Knižnica základných tried COMNET III

Objekty v tomto systéme možno rozdeliť do dvoch tried: po prvé sa používajú na opis topológie a po druhé na opis charakteristík prevádzky a zaťaženia siete. Základná obrazovka COMNET III so sadou tried knižníc je na obr. 3.

Ryža. 3. Hlavná obrazovka systému COMNET

Popis topológie v COMNET III

Takéto základné koncepty topológie v systéme COMNET III ako uzly, spojenia, oblúky boli popísané v PC Week / RE, č. 34/98, s. 34.

Okrem uzlov, spojení a oblúkov na popis hierarchických topológií a modelovanie nezávislých smerovateľných domén obsahuje systém COMNET ešte jednu doplnkovú triedu, ktorej objekty môžu byť umiestnené aj vo vrcholoch grafu, a to podsieť.

Použitie mechanizmu dedenia vrátane viacnásobného dedenia rozširuje rozsah používaných tried.

Trieda uzla zdedí štyri nové triedy.

Trieda „Počítačový a komunikačný uzol“ (C&C uzol, Počítačový a komunikačný uzol)

Tieto objekty môžu slúžiť ako zdroje alebo prijímače prevádzky a tiež sa používajú na modelovanie zložitých softvérových systémov, ktoré zohľadňujú zaťaženie procesora a diskových subsystémov. IS uzly opísané pomocou C&C Node možno použiť aj na modelovanie softvérových smerovačov.

Skupina počítačov Trieda uzlov

Objekt je možné použiť len na modelovanie počítačových systémov, keďže ich funkčnosť zahŕňa len zdroj a prijímač prevádzky. Spravidla popisuje skupiny počítačov, ktoré majú rovnaké správanie.

Trieda uzla smerovača

Objekty tohto typu sa používajú na modelovanie hardvérových smerovačov. Rovnako ako uzol C&C, aj uzol smerovača môže pôsobiť ako zdroj aj ako prijímač prevádzky a spúšťať aplikácie, ktoré využívajú hardvérové ​​prostriedky uzla (procesory, diskové podsystémy). Pre podrobnejší popis hardvérovej implementácie simulovaných objektov bol zavedený rad ďalších vlastností, ako je prítomnosť a parametre internej zbernice, ktorá umožňuje simulovať vnútorný tok prevádzky medzi vstupom a výstupom. porty objektu.

Trieda „Switch“ (Uzol prepínača)

Objekty typu Switch Node, ktoré majú schopnosť smerovať, sa používajú na modelovanie prepínačov, ktoré trávia zanedbateľný čas prenosom prevádzky medzi internými portami. Tieto objekty však na rozdiel od troch predchádzajúcich nemožno použiť ani ako zdroj, ani ako prijímač premávky.

Objekty tried C&C Node, Computer Group Node a Router node pre modelovanie zložitých softvérových systémov obsahujú úložisko príkazov, ktoré využívajú takéto už spomínané vlastnosti objektov ako charakteristiky diskového subsystému. Neustále aktualizovaná knižnica objektov rôznych tried, ktoré sú súčasťou COMNET, zahŕňa širokú škálu modelov skutočných hardvérových zariadení.

Objekt odkazu zdedí dva nové objekty.

Trieda Point-to-Point Link

Táto trieda sa používa na popis kanálov medzi dvoma uzlami. Príkladom takýchto spojení môžu byť prenajaté linky spájajúce smerovače v rozsiahlych sieťach alebo spojenia v sieťach s prepínaním okruhov.

Trieda „Multiaccess“ (odkaz na viacnásobný prístup)

Oblasťou pre aplikáciu tejto triedy sú situácie, keď niekoľko uzlov má prístup k rovnakému dátovému prenosovému médiu. Na druhej strane je tento objekt zdedený množstvom nových objektov, ktoré popisujú špecifické implementačné skutočnosti metódy prístupu k médiám, ako je detekcia nosiča, odovzdávanie tokenov, SONET atď. (pozri obrázok 2).

Doteraz sme zvažovali prípady, keď nadradený objekt zdedí jeden podriadený objekt. Objektovo orientovaný prístup však poskytuje aj zložitejšie situácie s viacnásobným dedením. Táto forma dedenia je použiteľná aj v systéme COMNET. Viacnásobné dedičstvo sa tu používa na vytváranie objektov takých dôležitých tried, ako sú tranzitná sieť a WAN cloud.

Obe triedy sú potomkami dvoch rodičovských tried – Subnet a Link. Forma dedenia je znázornená na obr. 2. Zvážte túto možnosť podrobnejšie.

Trieda podsiete

Mimoriadne dôležitá trieda. Používa sa na vytváranie hierarchických topológií IS, umožňuje správne opísať podsiete s rôznymi smerovacími algoritmami, nezávisle od algoritmu použitého na chrbtici. Okrem toho sa podsiete používajú na skrytie nepotrebných detailov pri modelovaní zložitých integrovaných obvodov. V COMNET sa používajú na popis systémov s ľubovoľnou hĺbkou vnorenia. Spojenie medzi vnútornou topológiou podsiete a topológiou chrbtice sa uskutočňuje pomocou prístupových bodov, ktorých počet môže byť ľubovoľný (pozri obrázok 3).

Trieda Transit Net

Potomok podsietí a pripojení je objekt, ktorý kombinuje vlastnosti rodičovských objektov. Tranzitnú sieť možno považovať za pripojenie aj ako podsieť súčasne. Ako spojenie preposiela pakety z výstupnej vyrovnávacej pamäte jedného uzla do vstupnej vyrovnávacej pamäte iného uzla. Ako podsieť vytvára tranzitná sieť v rámci svojich hraníc oblasť s vlastným smerovacím algoritmom.

Cloudová trieda (WAN Cloud)

Objekty tejto triedy, ktoré umožňujú vytvárať abstraktné reprezentácie pre globálne siete, tiež zdedia vlastnosti rodičovských objektov – Subnet a Link. Z topologického hľadiska objekt WAN Cloud funguje ako objekt „spojenie“, jeho ikona sa pripája priamo k uzlom. Z hľadiska vnútornej štruktúry je cloud tvorený súborom virtuálnych spojení (virtuálny okruh) a prístupových kanálov (access links), čo je typ spojenia point-to-point pre modelovanie globálnych sietí.

Popis prevádzky a zaťaženia siete v COMNET III

Ako sme už povedali, model IS v COMNET obsahuje dve časti: popis topológie systému a popis zdrojov prevádzky a zaťaženia siete. Pokryli sme základnú škálu objektov súvisiacich s topológiou. Teraz prejdime k objektom, ktoré popisujú premávku.

COMNET poskytuje širokú škálu nástrojov na popis prevádzky.

Trieda „Správa“ (Správa)

Objekty patriace do tejto triedy vám umožňujú poslať jednu správu buď jednému cieľovému objektu alebo viacerým objektom. Preposielanie takýchto správ sa spracováva ako postupnosť datagramov, pričom každý paket je smerovaný nezávisle od ostatných.

Trieda odozvy

Objekty tejto triedy možno použiť iba na odosielanie správ s odpoveďou. Sú riadené príchodom správ vytvorených objektmi tried Message alebo Response. Príjemcom správ triedy Response bude vždy objekt triedy Node, ku ktorému je pripojený zdroj riadiacej správy (triedy Response alebo Message).

Zavolajte triedu

Objekty triedy Call sa používajú na vytváranie modelov sietí s prepojovaním okruhov. Zdroj hovoru je opísaný súborom parametrov, ako je distribučný zákon, trvanie a, berúc do úvahy triedu smerovania, požiadavky na šírku pásma.

Trieda „Session“ (relácia)

Tieto objekty sa používajú na modelovanie relácií zahŕňajúcich množiny správ alebo správ smerovaných cez virtuálne linky. Relácia je iniciovaná odoslaním paketu nastavenia relácie a prijatím potvrdzovacieho paketu. Neskôr v rámci relácie možno odoslať ľubovoľný počet správ, ktoré sú tiež popísané v objekte triedy Session. Takéto správy sú smerované buď ako datagramy, alebo ako virtuálne linky, v závislosti od smerovacieho algoritmu na chrbtici alebo podsieti obsahujúcej objekt.

Všimnite si tiež, že COMNET III používa takzvané externé súbory návštevnosti, ktoré je možné získať pomocou rôznych analyzátorov návštevnosti.

Obzvlášť zaujímavé sú objekty triedy Application, ktorá je výsledkom viacnásobného dedenia tried Message, Response, Call a Session (pozri obrázok 2). Jeho objekty umožňujú najflexibilnejší popis zaťaženia siete a správania sa zdrojov návštevnosti v rámci modelu. Navyše pri ich použití je možné jednoducho modelovať takmer akýkoľvek druh softvérových systémov, vrátane distribuovaných, ako sú DBMS, poštové systémy atď.

Skutočná aplikácia, popísaná objektmi tejto triedy, obsahuje tri komponenty. Najprv sú to parametre uzla, ku ktorému je pripojený objekt triedy Application. Pomocou týchto parametrov sa špecifikujú charakteristiky a počet požadovaných procesorov a diskových podsystémov. Po druhé, ide o takzvané úložiská príkazov, ktoré využívajú vyššie uvedené charakteristiky uzla. A do tretice je to samotný objekt Application, ktorý riadi postupnosť vykonávania týchto príkazov.

Úložisko príkazov hostiteľa, a teda aj objekt triedy Application, môže obsahovať nasledujúce príkazy:

Transport Message (prenos správy). Tento príkaz je výsledkom dedenia nadradeného objektu triedy Message triedou Application.

Setup (install) - výsledok dedenia triedy Session.

Odpoveď Message je podtriedou triedy Response.

Filter Message (filtrovať správy). Tento príkaz vám umožňuje pozastaviť všetky operácie opísané v objekte triedy Application, kým sa neprijme správa, ktorá spĺňa podmienky filtrovania.

Proces (spracovanie). Tento príkaz simuluje spracovanie, ktoré spôsobuje využitie CPU.

Čítať a písať (čítanie a písanie). Tieto dva príkazy tiež umožňujú simulovať vyťaženosť hostiteľského procesora, avšak v kontexte interakcie s diskovým podsystémom na čítanie a zápis súborov.

Pomocou tried Application, Message, Response, Session a Call je teda možné flexibilné modelovanie aktuálneho zaťaženia siete a detailný popis správania softvérových systémov zaradených do IS. Je mimoriadne dôležité, aby vám tieto triedy umožnili modelovať komplexné distribuované softvérové ​​systémy a ich vplyv na existujúcu sieťovú infraštruktúru siete.

Objekty COMNET III: Parametrická abstrakcia

Keď už hovoríme o základnej sade tried COMNET III, je mimoriadne dôležité spomenúť na ne použiteľnosť takzvanej parametrickej abstrakcie. Tento prístup vám umožňuje vytvárať nové objekty – inštancie tried s rôznymi vlastnosťami. Také dôležité technologické riešenia, ako je povedzme gigabitový Ethernet, je možné modelovať veľmi jednoducho zmenou parametrov uvažovanej abstrakcie – vlastností vybranej triedy.

Zvážte príklad. Predpokladajme, že modelujeme lokálnu sieť, ktorá používa metódu náhodného prístupu s rozpoznávaním nosiča a detekciou kolízií (CSMA / CD, trieda spojení s viacnásobným prístupom) na podvrstve MAC, ale štandard spojovej vrstvy navrhnutý výrobcom sieťového zariadenia je trochu odlišný od „natívneho“ IEEE 802.3. Táto situácia pri použití produktu, ktorý neimplementuje objektovo orientovaný prístup, môže spôsobiť určité nepresnosti. Vývojár by bol nútený použiť štandard ponúkaný výrobcom produktu, s najväčšou pravdepodobnosťou klasický 802.3. Na obr. Obrázok 4 zobrazuje okno rozhrania COMNET III, pomocou ktorého môže užívateľ upravovať parametre tohto štandardu - počet opakovaných prenosov v prípade kolízií, dĺžku hlavičky rámca atď. Inými slovami, užívateľ sám vykonáva parametrizáciu objekt.

Ryža. 4. Parametrizácia pripojenia 10BaseT štandardu IEEE 802.3

Riešime teda otázku zhody medzi referenčnou normou a normou výrobcu. Naše ďalšie kroky smerujú k doplneniu knižnice objektov triedy CSMA / CD novým štandardom, ktorý si užívateľ definoval. Ak to chcete urobiť, stačí pridať nové parametre. To isté môžeme urobiť s hardvérovými uzlami, zdrojmi návštevnosti, nastaveniami WAN Cloud atď.

Z toho je vidieť, že parametrizácia poskytuje dostatok príležitostí na rozšírenie základnej knižnice objektov, čo umožňuje vývojárovi modelu robiť flexibilnejšie rozhodnutia.

Základnú množinu tried môžete rozšíriť ďalším použitím mechanizmu dedičnosti.

Režim „Kopírovať-prilepiť externý model“ (Intermodel copy-paste)

Predpokladajme, že budujeme veľký model, ktorý má veľmi zložitý topologický popis. Tu môžeme ísť dvoma spôsobmi: skombinovať celú topológiu systému do jedného súboru alebo vytvoriť niekoľko fragmentov a následne ich zlúčiť. Druhá možnosť je pre vývojára výhodnejšia z viacerých dôvodov. Ide o jednoduchosť ladenia každého jednotlivého fragmentu a dobrú viditeľnosť a v konečnom dôsledku aj väčšiu spoľahlivosť.

V budúcnosti je celý problém prenášať objekty z jedného modelu do druhého. Pre riešenie je vhodné použiť režim copy-paste COMNET III Intermodel (kopírovanie - vloženie externého modelu), ktorý zabezpečuje prenos z modelu do modelu novovytvorených objektov so všetkými vlastnosťami okrem tých, ktoré sú lokálne pre zdrojový model.

Vezmime si príklad. Predpokladajme, že prenášame z jedného modelu do druhého sieťový fragment, ktorý má nejaké zaťaženie. Prevádzka je popísaná objektmi triedy Message. Vlastnosť takýchto objektov, ktorá je lokálna pre zdrojový model, je jeho cieľom. Zostávajúce vlastnosti sa prenesú bez zmien z objektov, ktoré zdedia triedy uzlov (uzol C&C, skupina počítačov, smerovač, prepínač), prepojenie atď., ktoré nie sú viazané na zdrojový model.

Postup parametrizácie je v tomto prípade veľmi jednoduchý. Najmä pre správu môžete určiť jej smer v súlade so zoznamom mien z nového modelu, ktorý sa automaticky pripojí k objektu.

Aplikácia opísanej metódy otvára široké možnosti pri stavaní akýchkoľvek modelov z flexibilne rozšíriteľnej sady objektov - stavebných blokov, čo umožňuje výrazne znížiť náklady na modelovanie.

Modulárna konštrukcia uzlov

Zvážte postup na vytvorenie objektu novej triedy na základe viacnásobnej dedičnosti.

Predpokladajme, že vývojár má za úlohu zostaviť podrobný model hardvérového zariadenia (napríklad smerovača, ktorého niekoľko modulov rozhrania je prepojených zbernicou rozhrania). Účelom zostavenia modelu je určiť oneskorenie na zbernici rozhrania. V štandardnom popise COMNET III je zbernica opísaná dvoma parametrami: šírkou pásma a frekvenciou. Je jasné, že takýto popis nám nestačí. Máme však k dispozícii objekt, ktorý nám umožňuje opísať zbernicu ako samostatné zariadenie – spoj. Vo všeobecnosti nejde o úplne štandardné riešenie, ale vykonaním potrebnej parametrizácie objektu triedy Link získame model zbernice ako plnohodnotné zariadenie, ktoré implementuje napríklad arbitrážnu funkciu. Znázornené na obr. 5 je objekt MPRouter modelovaný týmto spôsobom. Zbernica rozhrania tu funguje podľa algoritmu Token Bus.

Ryža. 5. Parametrizácia zdroja dopravy počas presunu

fragment modelu na iný model (zdroj relácie)

Zároveň by sa malo povedať, že vývojár by nemal zneužívať takéto techniky, pretože, ako už bolo spomenuté, príliš presný popis každého objektu v niektorých situáciách môže mať opačný účinok, ktorý sa prejavuje znížením spoľahlivosti model ako celok. Táto technika je použiteľná v prípadoch, keď je potrebný podrobný popis charakteristík objektov.

Schopnosť nastaviť stavy objektu

Každý objekt v COMNET môže byť v niekoľkých stavoch. Napríklad pre objekty tried Link a Node sú možné stavy hore, dole, zlyhanie (zapnuté, vypnuté, chyba). Môžete tiež simulovať prechody medzi týmito stavmi a analyzovať vplyv prechodu na simulovaný IC (obr. 6).

Ryža. 6. Určenie parametrov aktuálneho stavu objektu (Vlastnosti uzla)

To dáva vývojárom dostatok príležitostí na vytváranie dynamických scenárov, ako napríklad „čo sa stane, ak...?“ a tým výrazne zvyšuje flexibilitu vytvoreného modelu.

Takže sme zvážili hlavné nástroje a najbežnejšie techniky na vytváranie modelov v COMNET III. Ďalšie články plánujú autori venovať modelovaniu rôznych riešení široko používaných v moderných IS.

Zásadný rozdiel medzi funkčným a objektovým prístupom spočíva v spôsobe rozkladu systému. Objektovo orientovaný prístup využíva dekompozíciu objektov, pričom statická štruktúra je opísaná v termínoch objekty a odkazy medzi nimi a správanie systému je popísané z hľadiska posielanie správ medzi objektmi. Účelom metodiky je vybudovať obchodný model organizácie, ktorý vám umožní prejsť od modelu prípady použitia na model, ktorý definuje jednotlivé objekty podieľajúce sa na implementácii podnikových funkcií.

Koncepčným základom je objektový model, ktorý je zostavený s prihliadnutím na tieto princípy:

• abstrakcia;
• zapuzdrenie;
• modularita;
• hierarchia;
• písanie na stroji;
• paralelizmus;
• udržateľnosť.

Základné pojmy objektovo orientovaný prístup sú objektom a triedou.

Objekt je objekt alebo jav, ktorý má presne definované správanie a má stav, správanie a osobnosť. Štruktúra a správanie podobných objektov im definuje spoločnú triedu. Trieda je súbor objektov spojených spoločnou štruktúrou a správaním. Ďalšou skupinou dôležitých pojmov objektového prístupu sú dedičnosť a polymorfizmus. koncepcia polymorfizmus možno interpretovať ako schopnosť triedy byť viac ako jedného typu. Dedičnosť znamená vytváranie nových tried založených na existujúcich triedach s možnosťou pridávať alebo prepisovať údaje a metódy.

Dôležitou kvalitou objektového prístupu je konzistentnosť modelov činnosti organizácie a modelov navrhovaného informačného systému od fázy tvorby požiadaviek až po fázu implementácie. Objektové modely možno použiť na sledovanie mapovania reálnych entít modelovanej predmetnej oblasti (organizácie) do objektov a tried informačného systému.

Väčšina existujúcich metód objektovo orientovaný prístup zahŕňajú modelovací jazyk a opis procesu modelovania. Proces je popis krokov, ktoré treba dodržať pri vývoji projektu. Ako modelovací jazyk objektový prístup využíva jednotný modelovací jazyk UML, ktorý obsahuje štandardnú sadu diagramov pre modelovanie.

Diagram je grafické znázornenie množiny prvkov. Najčastejšie sa zobrazuje ako spojený graf s vrcholmi (entitami) a hranami (reláciami) a predstavuje nejakú projekciu systému.

Objektovo orientovaný prístup má nasledujúce výhody:

• Dekompozícia objektov umožňuje vytvárať menšie modely s využitím bežných mechanizmov, ktoré poskytujú potrebnú hospodárnosť výrazových prostriedkov. Využitím objektového prístupu sa výrazne zvyšuje úroveň zjednotenia a znovupoužiteľnosti vývoja, čo vedie k vytvoreniu vývojového prostredia a prechodu na tvorbu montážneho modelu.
• Dekompozícia objektov zabraňuje vytváraniu zložitých modelov, pretože zahŕňa evolučnú cestu pre vývoj modelu založeného na relatívne malých subsystémoch.
• Objektový model je prirodzený, pretože je zameraný na ľudské vnímanie sveta.

Do nevýhod objektovo orientovaný prístup zahŕňajú vysoké počiatočné náklady. Tento prístup neprináša okamžité výnosy. Účinok jeho aplikácie sa prejaví po vypracovaní dvoch alebo troch projektov a nahromadení opätovne použiteľných komponentov. Menej prehľadné sú diagramy odrážajúce špecifiká objektového prístupu.

Porovnanie existujúcich metód

V funkčné modely(DFD- diagramy toku údajov, SADT-diagramy), hlavnými štrukturálnymi komponentmi sú funkcie (operácie, akcie, práce), ktoré sú vzájomne prepojené na diagramoch objektové prúdy.

Nepochybná výhoda funkčné modely je realizácia štrukturálny prístup na návrh integrovaných obvodov podľa princípu „zhora nadol“, keď každý funkčný blok možno rozložiť na mnoho podfunkcií atď., čím sa vykonáva modulárny IC dizajn. Pre funkčné modely charakteristická je procesná prísnosť rozkladu IS a viditeľnosť prezentácie.

o funkčný prístup objektové dátové modely vo forme ER-diagramov "objekt - vlastnosť - vzťah" sú vyvinuté samostatne. Na kontrolu správnosti modelovania predmetnej oblasti sa medzi funkčnými a objektovými modelmi vytvárajú vzájomné vzťahy.

Hlavná nevýhoda funkčné modely je, že procesy a dáta existujú oddelene od seba – okrem funkčného rozkladu existuje dátová štruktúra, ktorá je v pozadí. Okrem toho nie sú jasné podmienky vykonávania procesov spracovania informácií, ktoré sa môžu dynamicky meniť.

Uvedené nevýhody funkčné modely nakrútené v objektovo orientované modely, v ktorom je hlavnou štruktúrotvornou zložkou trieda objektov so súborom funkcií, ktoré môžu pristupovať k atribútom tejto triedy.

Triedy objektov sa vyznačujú hierarchiou zovšeobecnenia, čo umožňuje vykonávať dedičstvo nielen atribúty (vlastnosti) objektov z vyššej triedy objektov do nižšej triedy, ale aj funkcie (metódy).

V prípade dedenia funkcií možno abstrahovať od konkrétnej implementácie procedúr ( abstraktné dátové typy), ktoré sa líšia pre určité podtriedy situácií. To umožňuje odkazovať na podobné programové moduly bežnými názvami ( polymorfizmus) a pri úprave softvéru znova použite kód programu. Teda prispôsobivosť objektovo orientovaných systémov na zmenu predmetnej oblasti oproti funkčný prístup výrazne vyššia.

Pri objektovo orientovanom prístupe sa mení aj princíp IC dizajn. Najprv sa rozlišujú triedy objektov a následne sa v závislosti od možných stavov objektov (životný cyklus objektov) určia metódy spracovania (funkčné postupy), čím sa zabezpečí najlepšia implementácia dynamického správania informačného systému.

Pre objektovo orientovaný prístup vyvinul grafické metódy modelovania predmetnej oblasti, zovšeobecnené v jednotnom modelovacom jazyku UML. Z hľadiska viditeľnosti prezentácie modelu pre užívateľa-zákazníka sú však objektovo orientované modely jednoznačne horšie ako funkčné modely.

Pri výbere metodiky modelovania predmetnej oblasti zvyčajne kritériom je miera jej dynamiky. Pre viac regulované úlohy sú vhodnejšie funkčné modely, pre adaptívnejšie obchodné procesy(riadenie pracovného toku, implementácia dynamických dotazov na informačné úložiská) - objektovo orientované modely. Avšak v rámci toho istého IS pre rôzne triedy problémov môžu byť potrebné rôzne typy modelov popisujúcich rovnakú problémovú oblasť. V tomto prípade kombinované doménové modely.