Vytvoření objektového modelu softwarového systému. Vytvoření objektového modelu

Systém aplikace je soubor vzájemně závislých objektů. Každý objekt je charakterizován sadou vlastností, jejichž hodnoty určují stav objektu, a sadou operací, které lze na tento objekt aplikovat.

Při vývoji aplikačních systémů je vhodné vzít v úvahu, že všechny vlastnosti objektů jsou soukromé (to znamená, že nejsou dostupné mimo objekt). Objektové operace mohou být veřejné nebo soukromé.

Každý objekt má tedy striktně definované rozhraní, tzn. sada veřejných operací, které lze na tento objekt použít. Všechny objekty stejné třídy mají stejné rozhraní.

Objektový model představuje statistickou strukturu navrženého systému (subsystému). K pochopení a vyhodnocení práce subsystému však znalost statické struktury nestačí. Je nutné mít prostředky k popisu změn, ke kterým dochází u objektů a jejich vztahů během provozu subsystému.

Jedním z těchto prostředků je dynamický model subsystémy. Je sestaven poté, co je sestaven a předběžně odsouhlasen a odladěn objektový model subsystému. Dynamický model subsystém se skládá ze stavových diagramů jeho objektů subsystému.

Aktuální stav objektu je charakterizován souborem aktuálních hodnot jeho atributů a vazeb. Během provozu systému se jeho jednotlivé objekty vzájemně ovlivňují, v důsledku čehož se mění jejich stavy. Jednotkou vlivu je událost: každá událost vede ke změně stavu jednoho nebo více objektů v systému nebo ke vzniku nových událostí. Provoz systému je charakterizován sledem událostí, které se v něm odehrávají.

V určitém okamžiku nastane událost. Příklady událostí: start rakety, start závodu na 100 m, zahájení vysílání, vydání peněz atd. Událost nemá žádné trvání (přesněji řečeno trvá zanedbatelné množství času).

Pokud události nemají žádnou kauzalitu (tj. jsou logicky nezávislé), jsou volány nezávislý(souběžně). Tyto události se navzájem neovlivňují. Nemá smysl řadit nezávislé události, protože se mohou vyskytovat v libovolném pořadí. Modelka distribuovaný systém musí obsahovat nezávislé události a aktivity.

Sled událostí se nazývá scénář. Jakmile jsou scénáře vyvinuty a analyzovány, jsou definovány objekty, které generují a přijímají každou událost scénáře.

Když dojde k události, nejen že objekt přejde do nového stavu, ale také se provede akce spojená s touto událostí. Akce je okamžitá operace spojená s událostí.

Proces vytváření objektového modelu zahrnuje následující kroky:

Definice objektů a tříd;

Příprava datového slovníku:

Určení závislostí mezi objekty;

Stanovení vlastností objektů a vazeb;

Organizace a zjednodušení tříd při použití dědičnosti;

Další výzkum a vylepšování modelu.

Vytvoření objektového modelu problému pomocí modelovacího jazyka UML.

PRÁCE SE DĚLÁ ve StarUML

Dodací lhůta:

2 - 3 lekce

Pro ochranu díla je nutné poskytnout projekt vytvořený v balíku Rational Rose, včetně tří typů diagramů: případy použití, třídy (rozhraní, data) a sekvence pro každou funkci.

PŘÍKLAD ÚLOHY:

V databázi musí být uloženy následující informace:

- informace o studentech

Ó CELÉ JMÉNO.,

Ó adresa,

Ó pasové údaje,

Ó číslo účtu,

Ó Datum narození,

Ó skupina);

- informace o specialitách

Ó název speciality,

Ó šifra;

- informace o skupině

Ó specialita,

Ó rok přijetí

Ó číslo skupiny.

Zajistěte vydání dokumentu „Seznam skupin“ obsahujícího pole:

· sériové číslo,

· CELÉ JMÉNO.,

· číslo účtu.

Zakázka

Objektový model je zabudován v balíčku Rational Rose. K tomu vytvoříme prázdný projekt. Začněte svou práci s diagramem případu použití. Je postaven v hlavní oblasti části Use Case View, jak je znázorněno na obrázku 9.

Před zahájením tvorby diagramu je nutné definovat role uživatelů systému (aktérů) a jejich funkce (případy užití). V našem případě se systémem pracují dva aktéři - jedná se o „Zaměstnanec vzdělávacího oddělení“ a „Zaměstnanec děkanátu“. Mezi funkce zaměstnance vzdělávacího oddělení patří vedení seznamu odborností (pod údržba seznamu budeme rozumět přidávání záznamů, jejich úpravám a mazání). Mezi funkce pracovníka děkanátu patří vedení seznamu studentů a vedení seznamu skupin.

Zkonstruované schéma je znázorněno na Obr. 10.

Dále v části Logický pohled vytvořte dva diagramy tříd. K tomu můžete vytvořit dva balíčky. První diagram by měl obsahovat třídy rozhraní navrhované aplikace (viz obrázek 11). Na tomto obrázku jsou u tříd Seznam skupin a Seznam studentů vynechány operace Přidat, Upravit a Odstranit, aby nedošlo k přeplnění obrázku. Výstupním dokumentem je seznam skupin (nižší třída) (předchází mu třída "Výběr skupiny", protože je nutné získat seznam studentů určité skupiny). Druhým diagramem jsou databázové entity (viz obrázek 12).

Vytvořený diagram tříd zobrazuje všechny formy budoucí aplikace a jejich vztah.

Měli byste položit klíčová pole a vytvořit odkaz (z kontextové nabídky šipky - Násobnost).

Další fáze budování objektového modelu - vytváření sekvenčních diagramů. Sekvenční diagramy jsou vytvořeny pro každý případ užití v diagramu případu užití. Chcete-li do případu užití přidat sekvenční diagram, musíte jej vybrat ve stromu a zavolat na něj kontextová nabídka(NewàSequence Diagram), jak je znázorněno na obr. 13.

Příklad sekvenčního diagramu pro případ užití "Vedení seznamu specialit" je znázorněn na Obr. 14.

Je třeba poznamenat, že při konstrukci tohoto typu diagramu pro výstupní dokument „Seznam skupin“ v našem případě musíte nejprve vybrat skupinu ve formuláři „Vyberte skupinu“ (ta by naopak měla získat data z „ Skupina") a poté zobrazte formu výstupního dokumentu, do kterého již data pocházejí z entity "Student".

Databáze. Studenti korespondence

Laboratoř #1

Vytvoření objektového modelu problému pomocí modelovacího jazyka UML.

Pro ochranu díla je nutné poskytnout projekt vytvořený v balíku Rational Rose, včetně tří typů diagramů: případy použití, třídy (rozhraní, data) a sekvence pro každou funkci.

obecná informace

Vytvoření modelu je nezbytné pro lepší pochopení vyvíjeného systému.

Modelování umožňuje řešit následující problémy:

Vizualizujte nám systém v jeho aktuálním nebo požadovaném stavu;

Určete strukturu nebo chování systému;

Získejte šablonu, která vám umožní navrhnout systém;

Zdokumentujte učiněná rozhodnutí pomocí výsledných modelů.

Třída(Class) je popis kolekce objektů se společnými atributy, operacemi a vztahy. Graficky je třída znázorněna jako obdélník, který obvykle obsahuje její název, atributy a operace, jak je znázorněno na obrázku 1. 1. Jednou z variant třídy entity je herec(Herec). Typicky herec představuje roli, kterou člověk hraje v daném systému, hardwarové zařízení nebo dokonce jiný systém. Jak je znázorněno na Obr. 2 jsou herci vyobrazeni jako lidské postavy.

Precedens(Use Case) je popis posloupnosti akcí prováděných systémem, které vytvářejí pozorovatelný výsledek, který je smysluplný pro konkrétního aktéra (Actor). Případ užití se používá ke strukturování entit chování modelu. Graficky je případ užití znázorněn jako elipsa ohraničená souvislou čarou, která obvykle obsahuje pouze její název, jak je znázorněno na obrázku 2. 3.

Entity chování jsou dynamické součásti modelu UML. Toto jsou slovesa jazyka: popisují chování modelu v čase a prostoru. Existují dva typy entit chování:

Interakce;

Automaticky (státní automat).

Interakce(Interaction) je chování, jehož podstatou je výměna zpráv (Messages) mezi objekty v rámci specifického kontextu za účelem dosažení konkrétního cíle. Graficky jsou zprávy znázorněny jako šipka, nad kterou je téměř vždy napsán název odpovídající operace, jak je znázorněno na Obr. 4.

Seskupování entit jsou organizační části UML. To jsou bloky, na které lze model rozložit. Existuje pouze jedna entita seskupení, a to balíček.

Balíčky(Balíčky) jsou univerzálním mechanismem pro organizování prvků do skupin. Strukturální, behaviorální a dokonce i další seskupovací entity můžete vložit do balíčku. Na rozdíl od komponent, které existují, když systém běží, jsou balíčky čistě koncepční povahy, to znamená, že existují pouze během vývoje. Balíček se zobrazí jako složka se záložkou obsahující zpravidla pouze název (viz obr. 5).

Entity anotace- vysvětlující části modelu UML. Toto jsou komentáře pro dodatečný popis, vysvětlení nebo poznámky k jakémukoli prvku modelu. Existuje pouze jeden typ prvku poznámky, poznámka.

Poznámka je jednoduše symbol pro zobrazení komentářů nebo omezení připojených k prvku nebo skupině prvků. Graficky je poznámka zobrazena jako obdélník se zakřiveným okrajem obsahující text nebo grafický komentář, jak je znázorněno na Obr. 6.

V jazyk UML jsou definovány čtyři typy vztahů:

Závislost;

Sdružení;

zobecnění;

Implementace.

Tyto vztahy jsou základními stavebními kameny v UML a používají se k vytváření správných modelů.

Závislost(Závislost) je sémantický vztah mezi dvěma entitami, ve kterém změna jedné z nich, nezávislé, může ovlivnit sémantiku druhé, závislé. Graficky je závislost znázorněna jako přímá tečkovaná čára, často se šipkou (viz obr. 7).

Sdružení(Asociace) – strukturální vztah, který popisuje množinu spojení; Vztah je spojení mezi objekty. Graficky je přidružení znázorněno jako přímka (někdy končící šipkou nebo obsahující štítek), vedle které mohou být další symboly, jako je multiplicita a názvy rolí. Na Obr. 8 ukazuje příklad tohoto typu vztahu.

UML diagram je grafické znázornění množiny prvků, nejčastěji zobrazované jako souvislý graf s vrcholy (entitami) a hranami (relacemi). Pro vizualizaci systému jsou nakresleny diagramy různé body vidění. V UML existuje devět typů diagramů:

diagramy tříd;

Diagramy objektů;

Schémata případů;

Sekvenční diagramy;

Schémata spolupráce;

Stavové diagramy;

Akční diagramy;

Schémata součástí;

Schémata nasazení.

Na diagram tříd zobrazit třídy, rozhraní, objekty a spolupráce, stejně jako jejich vztahy. Při modelování objektově orientovaných systémů se tento typ diagramu používá nejčastěji. Diagramy tříd odpovídají statickému pohledu na systém z hlediska návrhu.

Na schéma případu použití jsou prezentovány precedenty a aktéři ( speciální případ třídy) a vztahy mezi nimi. Diagramy případů užití odkazují na statický pohled na systém z hlediska případů užití. Jsou zvláště důležité při organizování a modelování chování systému.

Sekvenční diagramy jsou speciálním případem interakčních diagramů. Na interakční diagramy jsou prezentovány vazby mezi objekty; ukazuje zejména zprávy, které si objekty mohou vyměňovat. Interakční diagramy odkazují na dynamický pohled systémy. Sekvenční diagramy zároveň odrážejí časové řazení zpráv.

Pořadí práce bude uvažováno na příkladu následující úlohy:

V databázi musí být uloženy následující informace:

- informace o studentech (včetně celého jména, domovní adresa, údaje o pasu, číslo záznamu, datum narození, skupina);

- informace o odbornosti (název odbornosti, kód);

- informace o skupinách (odbornost, rok přijetí, číslo skupiny).

Zajistěte vystavení dokladu „Seznam skupiny“, obsahující pole: pořadové číslo, celé jméno, číslo záznamu.

Objektový model je zabudován v balíčku Rational Rose. K tomu vytvoříme prázdný projekt. Začněte svou práci s diagramem případu použití. Je postaven v hlavní oblasti části Use Case View, jak je znázorněno na obrázku 9.

Před zahájením tvorby diagramu je nutné definovat role uživatelů systému (aktérů) a jejich funkce (případy užití). V našem případě se systémem pracují dva aktéři - jedná se o „Zaměstnanec vzdělávacího oddělení“ a „Zaměstnanec děkanátu“. Mezi funkce zaměstnance vzdělávacího oddělení patří vedení seznamu odborností (pod údržba seznamu budeme rozumět přidávání záznamů, jejich úpravám a mazání). Mezi funkce pracovníka děkanátu patří vedení seznamu studentů a vedení seznamu skupin.

Zkonstruované schéma je znázorněno na Obr. 10.

Dále v části Logický pohled vytvořte dva diagramy tříd. K tomu můžete vytvořit dva balíčky. První diagram by měl obsahovat třídy rozhraní navrhované aplikace (viz obrázek 11). Druhým diagramem jsou databázové entity (viz obrázek 12).

Vytvořený diagram tříd zobrazuje všechny formy budoucí aplikace a jejich vztah.

Dalším krokem při vytváření objektového modelu je vytvoření sekvenčních diagramů. Sekvenční diagramy jsou vytvořeny pro každý případ užití v diagramu případu užití. Chcete-li přidat sekvenční diagram do precedentu, musíte jej vybrat ve stromu a vyvolat na něm kontextovou nabídku (NewàSequence Diagram), jak je znázorněno na Obr. 13.

Příklad sekvenčního diagramu pro případ užití "Vedení seznamu specialit" je znázorněn na Obr. 14.

Objektový model stávající podnikání ukazuje, jak a jakými precedenty jsou implementovány. Tento model odhaluje vnitřní strukturu podniku, konkrétně: jaké typy zdrojů se používají k implementaci případů užití a jak se vzájemně ovlivňují. Popis objektového modelu je založen na konceptu "objekt". Objekty představují účastníky procesu a různé druhy entit (hotové výrobky, zakázky atd.).

Objekty rozhraní studovaného obchodního procesu:

• 1. Správce účtu. Atributy: celé jméno, funkce, plat. Zodpovědnost: Komunikuje se zákazníky, zadává objednávky, přijímá platby od zákazníků za objednávky.
• 2. Odpovědný skladník. Atributy: celé jméno, funkce, plat. Zodpovědnost: interakce s dodavateli, přijímání materiálů a podepisování faktur.
• 3. Řidič spedice. Atributy: celé jméno, funkce, plat. Zodpovědnost: Dodání hotového výrobku klientovi.

Kontrolní objekty studovaného podnikového procesu:

• 1. Návrhář. Atributy: celé jméno, funkce, plat. Zodpovědnost: produktový design, projektové řízení, kontrola.
• 2. Provozovatel automatizovaného účetnictví. Atributy: celé jméno, funkce, plat. Náplň práce: vedení automatizovaného účetnictví, práce s databází.
• 3. Nábytkář (Assembler). Atributy: celé jméno, funkce, plat. Zodpovědnost: Výroba produktu v souladu s projektem.

Objekty entity studovaného obchodního procesu:

• 1. Šek - doklad vystavený při platbě objednávky.
• 2. Katalog - dokument odrážející sortiment.
• 3. Objednávkový formulář - dokument, který obsahuje číslo objednávky, datum objednávky, informace o zákazníkovi, vybraný typ, náčrt produktu, přání zákazníka.
• 4. Produktový design - design objednaného nábytku.
• 5. Aplikace pro materiály - dokument charakterizující potřebné materiály a jejich objemy.
• 6. Databáze - program, který umožňuje vést evidenci materiálu ve firmě.
• 7. Materiály - nutné pro výrobu zakázkového předmětu.
• 8. Faktura - dokument podepsaný při expedici materiálu.
• 9. Hotový výrobek - výsledek výroby, vyznačující se příslušností k libovolné zakázce.

Tabulka 5.1 popisuje vzájemný vztah objektů.

Tabulka 5.1 Popis vzájemného působení objektů

Poznámka: Pokud jsou potřebné materiály skladem, pak položky 18, 19, 20, 21 této tabulky jsou přeskočeny.

Dynamický model interakce mezi odděleními a zákazníkem, v případě "Prodej zakázkového produktu" je znázorněn na obrázku 5.1 " je znázorněn na obrázku 5.3 Dynamický model interakce zaměstnanců, v případě "Výroba" je znázorněn na obrázku Obr. 5.4.

Obrázek 5.1 Sekvenční diagram případu použití „Prodej produktu na zakázku“.

Obrázek 5.2 Sekvenční diagram případu použití Checkout

Obrázek 5.3 Sekvenční diagram případu použití "Design".

Obrázek 5.4 Sekvenční diagram případu použití "Make".

Konstrukce objektového modelu předmětu "organizace procesů sportovního klubu" pomocí modelovacího jazyka UML

1. HLAVNÍ TEORETICKÁ USTANOVENÍ OBJEKTIVNĚ ORIENTOVANÉ METODIKY

1.1 Základní pojmy objektově orientovaného přístupu

model programování předmětového jazyka

Programování po dlouhou dobu používá strukturovaný procedurální model. Volba cílů projektu se provádí jedním ze dvou přístupů, nazývaných „shora dolů“ a podle toho „zdola nahoru“

1. Přístup shora dolů znamená, že úkol je rozdělen na dílčí úkoly, které zase na dílčí úkoly další úrovně atd. Tento proces, nazývaný dekompozice, pokračuje, dokud se zjednodušování dílčích úkolů nezredukuje na elementární funkce, které lze formalizovat.

2. Přístup zdola nahoru znamená, že procedury jsou psány pro řešení jednoduchých problémů, pak jsou postupně kombinovány do složitějších procedur, dokud není dosaženo požadovaného efektu.

Důležitými koncepty programování jsou procedurálně orientované programování a objektově orientované programování.

Programování orientované na procedury je programování v imperativním jazyce, ve kterém lze sekvenčně prováděné příkazy sestavit do podprogramů, tedy větších celistvých jednotek kódu, pomocí mechanismů samotného jazyka.

Objektově orientované programování (OOP) je styl programování, který zachycuje chování reálného světa způsobem, který skrývá detaily jeho implementace.

Objekt je druh samostatné entity, která vyniká mezi ostatními entitami svými vlastnostmi, chováním a interakcí s jinými objekty aplikace.

Použití této technologie umožňuje reprezentovat strukturu programu jako soubor objektů, které se vzájemně ovlivňují. V důsledku takové interakce, prováděné předáváním zpráv mezi objekty, jsou implementovány specifikované funkce programu. Po přijetí zprávy může objekt provést specifickou akci, která se nazývá metoda.

Mezi OOP a procedurálním programováním jsou dva důležité rozdíly:

1. V OOP programátor nejprve extrahuje třídy z popisu předmětová oblast, následně se sestaví objektový model pro řešení problému a teprve poté se přistoupí k analýze jejich metod a vlastností.

2. Metody a vlastnosti jsou spojeny s třídou navrženou k provádění odpovídajících operací.

Pokud budeme analyzovat, jak člověk řeší různé praktické problémy ve světě kolem sebe, pak pochopíme, že tento svět je také objektově orientovaný. Například, aby se člověk dostal do práce, obvykle interaguje s předmětem, jako je vozidlo. Vozidlo se zase skládá z předmětů, které ho vzájemnou interakcí uvádějí do pohybu, díky čemuž si člověk uvědomí svůj úkol – dostane se do požadovaného bodu. Řidič ani spolujezdec přitom nemusí vědět, jak spolupůsobí předměty, které tvoří vozidlo.

V objektově orientovaném programování, stejně jako v reálném světě, jsou uživatelé programu izolováni logické schéma potřebné k dokončení úkolů. Chcete-li například vytisknout stránku textový editor uživatel vyvolá určitou funkci stisknutím tlačítka na panelu nástrojů, ale nevidí probíhající vnitřní procesy. Při tisku stránky za běhu programu dochází ke složité interakci objektů, které zase interagují s tiskárnou.

Při vytváření objektově orientovaného programu je předmětná oblast reprezentována jako kolekce objektů, které jsou sloučeny do tříd. Provádění programu spočívá v tom, že si objekty vyměňují zprávy (vzájemně interagují). Při reprezentaci skutečného objektu patřícího do předmětné oblasti pomocí třída programu, je nutné vyčlenit jeho podstatné rysy u reálného objektu a mnohé další vlastnosti ignorovat, omezovat se pouze na ty, které jsou potřeba k řešení praktického problému. Tato technika se nazývá abstrakce.

Abstrakce je výběr základních charakteristik předmětu, které jej odlišují od jiných předmětů. Kromě toho seznam základních vlastností závisí na cílech modelování a pro různé úkoly může být úplně jiný. Například objekt „krysa“ z pohledu migračního biologa, veterináře nebo kuchaře bude mít zcela jiné vlastnosti.

Třída je kolekce objektů, které mají obecné vlastnosti a chování. Třídu lze tedy definovat jako druh obecnosti konkrétní objekty jako popis - jaké by měly být a co by měly dělat. Pokud objekty v aplikacích skutečně existují, pak je třída abstrakcí, která spojuje objekty do jedné skupiny podle jejich vlastností a chování v prostředí, ve kterém existují a interagují. Například Button1 na formuláři se všemi svými specifickými vlastnostmi a akcí je objektem třídy Button.

Chování je charakteristikou toho, jak jeden objekt ovlivňuje jiné objekty nebo se pod jejich vlivem mění. Chování ovlivňuje, jak se mění stavy objektu.

Srdcem technologie objektově orientovaného programování jsou „tři velryby“: zapouzdření, dědičnost a polymorfismus.

Encapsulation (encapsulation) – vlastnost, která kombinuje stav a chování a skrývá se v rámci jedné struktury vnitřní zařízení detaily objektu a implementace (od slova "kapsle"). Důležitou vlastností každého objektu je jeho izolace. Realizační detaily objektu, tzn. vnitřní datové struktury a algoritmy pro jejich zpracování jsou uživateli objektu skryty a nejsou k dispozici pro neúmyslné změny. Objekt se používá prostřednictvím rozhraní – sady přístupových pravidel. Například přepnout televizní program, na dálkovém máme dost dálkové ovládání vytočí její číslo, což spustí složitý mechanismus, který nakonec povede k požadovanému výsledku. Nepotřebujeme vědět, co se děje v ovladači a TV, stačí nám vědět, že TV tuto schopnost (způsob) má a jak ji lze aktivovat. Zapouzdření neboli skrytí implementace je základní vlastností OOP. Umožňuje vám vytvářet vlastní objekty, které mají požadované metody, a poté s nimi pracovat, aniž byste museli přecházet do struktury těchto objektů. Zapouzdření je tedy mechanismus, který kombinuje metody zpracování dat a dat (manipulace) a chrání je před vnějšími zásahy nebo zneužitím. Zapouzdření kódu v rámci třídy zajišťuje, že tento kód nelze „rozbít“ žádnou změnou v detailech implementace jednotlivých tříd. Proto můžete použít objekt v jiném prostředí a ujistěte se, že nepoškozuje oblasti paměti, které do něj nepatří. Pokud stále potřebujete něco změnit nebo přidat ve třídě, pak se používají mechanismy dědičnosti a polymorfismu.

Dědičnost je schopnost tříd na základě hierarchie zahrnovat vlastnosti a chování předchůdců a přidávat k nim své vlastní chování a vlastnosti. Každý rok se ve světě napíše spousta programů a je důležité používat již napsaný kód. Výhodou objektově orientovaného programování je, že pro objekt můžete definovat děti, které upravují nebo rozšiřují jeho chování. V tomto případě není potřeba pouze opakovat zdroj nadřazený objekt, ale dokonce k němu mají přístup. Tímto způsobem se zjednoduší úprava programu a tvorba nových programů vycházejících ze stávajícího. Pouze prostřednictvím dědičnosti je možné používat objekty, jejichž zdrojový kód není k dispozici, ale je třeba je upravit. Při dědění tak můžete nejen přidat novou funkcionalitu, ale také změnit tu stávající. A v mnoha ohledech je poskytován díky polymorfismu.

Polymorfismus („mnoho forem“) - schopnost používat stejné výrazy k označení různých operací, schopnost tříd potomků implementovat metodu popsanou pro třídu předka různými způsoby, tzn. schopnost provádět různé akce nebo přistupovat k objektům pomocí stejného jména během provádění programu jiný typ. Polymorfismus je implementován prostřednictvím přepisování metod v potomkových třídách (metoda má stejný název a stejné parametry, ale funguje jinak) - jedná se o mechanismus virtuálních metod prostřednictvím dynamické vazby. Také polymorfismus je implementován jako „overloading“ metody (metoda má stejný název a jiné parametry) – jedná se např. o použití znaménka + pro označení sčítání ve třídě reálných nebo celočíselných čísel a třídě řetězců. : podobné zprávy dávají zcela odlišné výsledky. Polymorfismus poskytuje schopnost abstrahovat společné vlastnosti.

Modularita je vlastnost systému, který byl rozložen na vnitřně koherentní, ale volně propojené moduly.
V procesu rozdělování systému na moduly mohou být užitečná dvě pravidla. Za prvé, protože moduly slouží jako elementární a nedělitelné jednotky programu, které lze znovu použít v celém systému, musí to při přidělování tříd a objektů modulům brát v úvahu. Za druhé, mnoho kompilátorů vytváří samostatný segment kódu pro každý modul. Proto může existovat omezení velikosti modulu. Dynamika volání podprogramů a uspořádání popisů v rámci modulů může výrazně ovlivnit umístění odkazu a správu stránek. virtuální paměť. Pokud jsou procedury špatně rozděleny do modulů, častější jsou vzájemná volání mezi segmenty, což vede ke ztrátě efektivity vyrovnávací paměti a častým změnám stránek.

Spojení takových protichůdných požadavků je poměrně obtížné, ale hlavní věcí je pochopit, že izolace tříd a objektů v projektu a organizace modulární struktury jsou nezávislé akce. Proces izolace tříd a objektů je součástí procesu logického návrhu systému a rozdělení do modulů je fází fyzického návrhu. Samozřejmě někdy není možné dokončit logický návrh systému bez dokončení fyzického návrhu a naopak. Tyto dva procesy se provádějí iterativně.

Psaní je způsob, jak chránit nebo alespoň kontrolovat používání objektů jedné třídy místo jiných.

Souběžnost je vlastnost, která odlišuje aktivní objekty od pasivních.

Perzistence - schopnost objektu existovat v čase, přežít proces, který jej dal vzniknout, a (nebo) v prostoru, pohybovat se ze svého původního adresního prostoru.

V programování se základní pojmy OOP posunuly z jiných oblastí poznání, jako je filozofie, logika, matematika a sémiotika, a aniž by prošly nějakými zvláštními změnami, alespoň co se podstaty těchto pojmů týče. Objektový způsob rozkladu (reprezentace) je přirozený a používá se po mnoho staletí. Proto není divu, že v procesu evoluce programovací technologie zaujala své právoplatné místo.

V procesu vývoje objektově orientovaných programů je tedy nutné:

1. určit množinu tříd objektů, které ji tvoří (rozklad);

2. pro každou třídu objektů specifikujte sadu požadovaných dat (polí);

3. pro každou třídu objektů specifikujte sadu akcí (metod) prováděných objekty;

4. Pro každou třídu objektů označte události, na které budou objekty reagovat, a napište příslušné procedury obsluhy.

Originál programový kód musí obsahovat popisy tříd pro všechny objekty programu. Kromě toho musí být proměnné deklarovány s názvy odpovídajících tříd specifikovaných jako typy. Instance tříd (objekty) se vytvářejí během provádění programu.

Po svém vytvoření musí instance třídy obdržet hodnoty pro všechna svá pole. Různé instance stejné třídy mohou mít různé hodnoty polí, ale mají stejné metody. Pole třídy nejsou k dispozici pro přímý přístup, včetně přiřazení. To se provádí za účelem zvýšení spolehlivosti programů. Namísto přímého přiřazení hodnoty poli objektu by mělo být provedeno volání speciální metody odpovídající třídy, která takové přiřazení provádí a kontroluje správnost zadané hodnoty. Podobně lze ke čtení hodnoty pole použít také speciální metody tříd. Pro přidružení polí k metodám pro čtení/zápis jejich hodnot se používají členy třídy zvané vlastnosti. Uživatel, který zadává data pro jejich zápis do polí objektu nebo čte hodnoty polí, se zabývá vlastnostmi, které tato pole reprezentují. Proto se běžně používá termín „hodnoty vlastností“ místo termínu „hodnoty pole“.

Členy třídy mohou být:

1. pole používaná k ukládání dat;

2. vlastnosti jako prostředek přístupu k soukromým polím;

3. metody, které definují funkčnost objektů;

4. události a jejich obsluhy jako nástroje pro řízení programu.

Automatizace řešení problémů řízení činnosti Mir Computerov sro

Vybudování koncepčního modelu informačního systému MUP "RPKHB"

Balíček Rational Rose je schopen vyřešit téměř jakýkoli konstrukční problém informační systémy: od analýzy obchodních procesů po generování kódu ve specifickém programovacím jazyce. Umožňuje vám rozvíjet jak vysokou úroveň...

Konstrukce objektového modelu předmětu "organizace procesů sportovního klubu" pomocí modelovacího jazyka UML

V technologii OOP je vztah mezi daty a algoritmem pravidelnější: za prvé, třída ( základní koncept tato technologie) kombinuje data (strukturovaná proměnná) a metody (funkce). Za druhé...

Programování v matematických procesech Delphi

Projekt systému pro účtování objednávek na nákladní přepravu autodopravy "TransAvto"

Hlavním komunikačním kanálem ve společnosti jsou písemné zprávy ve formě zpráv, bulletinů, které jsou zpracovány tradičním (papírovým) způsobem, což výrazně snižuje rychlost práce. Většina práce se dělá ručně...

Navrhování informačních systémů pomocí BPwin

Vývoj informačního systému pro automatizaci pracoviště knihovníka

Vývoj objektově orientovaného modelu informačního subsystému pro děkanát univerzity (účtování postupu studentů)

Efektivní správa studentské databáze není možná bez automatizačního systému. Informační systém "děkanát" je určen pro správu osobních spisů studentů a může pracovat samostatně nebo jako součást IS "Elektronické znalosti"...

Vývoj objektově orientovaného modelu informačního systému vzdělávací knihovna

Trendy ve vývoji modern informační technologie vedou k neustálému zvyšování složitosti informačních systémů (IS) vytvářených v různých oblastech lidské činnosti ...

Vývoj OOMD je vyvinout datový model pomocí objektově orientovaného přístupu k modelování...

Vývoj databázového schématu pro úkol "Účtování knihovního fondu" pro Charkovskou vysokou školu textilu a designu

Při výběru DBMS pro implementaci konkrétního systému je nutné vzít v úvahu všechny vlastnosti dnes dostupných technologií. Takže vzhledem k tomu, že modely OO a ER lze považovat za nejrozvinutější ...