Objektově orientované technologie pro návrh aplikačních softwarových systémů. Vlastnost classList je objekt pro práci s třídami

Matematici jsou příliš líní na to, aby vysvětlili laickým jazykem co skutečné číslo. Pro průměrného člověka je obtížné číst symboly napsané matematikem, protože mu není jasný jejich význam. V důsledku toho existuje propast mezi teorií a praxí. Teoreticky matematici velmi dobře vědí, jaké typy objektů jsou a jaké jsou atributy, ale když přejdeme do praxe, vidíme, že jen málo praktikujících rozumí tomu, co to je. Existuje mnoho intuitivních konceptů, ale každý z nich připomíná spíše náboženské dogma než poznání. V tomto článku jsem se pokusil překlenout propast mezi matematiky a aplikovanými vědci vysvětlením základů teorie množin jednoduchým jazykem, žádné složité ikony. Znáte například definici atributu? Sám jsem tím trpěl, protože jsem nemohl najít jeho formální definici. A teprve potom mi Igor Katrichek poslal odkaz na knihu E. Kindlera „Modeling Languages“ (1979, přeloženo 1985), která dává definici atributu:

V tomto článku dám své, více obecná definice atribut, abyste si to mohli snadno představit.

V minulém článku jsem mluvil o tom, že několik objektů, o kterých uvažujeme jako o celku, existuje v naší mysli, ale nejsou námi výslovně rozpoznány. Matematici si to uvědomili a učinili to explicitní zavedením konceptu množiny. Také jsem si připomněl, že koncept mnoho a koncept objekt- axiomy, které nelze odvodit z jiných pojmů. Zároveň je nám pojem objektu známý a máme dostatečné zkušenosti s tím, abychom s ním pracovali, ale se souborem se seznamujeme v ústavu při studiu základů matematiky a představa o nich je není tak zřejmé. Pro ty, kteří hledají příležitost naučit se jasněji reprezentovat množinu, jsem vám řekl, kde ji můžeme najít dobrý obrázek– v prezentaci struktur. V tomto článku budu pokračovat v příběhu o sadách a řeknu vám co typ A atribut z pohledu teorie množin. A co je nejdůležitější, řeknu vám, jak se tyto koncepty odrážejí v modelech, které stavíme.

Množiny v matematice a fyzice

Svět vnímáme buď jako prostor, nebo jako čas, ale nedokážeme si představit obojí zároveň. To omezuje jazyk, který používáme, a modely, které vytváříme.

Například matematická množina neexistuje v čase, stejně jako operace na ní. To znamená, že se nedá říci, že by se složení sestavy v čase měnilo.

Zdá se mi to jako kontraintuitivní a nesamozřejmý požadavek, ale bez toho nebudeme schopni provádět operace s množinami a provádět srovnání. To znamená, že pokud chceme popsat množinu zrnek písku v hromadě písku, máme dva způsoby, jak to udělat: pro každé nové složení zrnek písku zavést novou množinu nebo uvažovat množinu časových částí zrnek písku na studované hromadě. Časová část zrnka písku se vztahuje k času A Jsem součástí zrnka písku, které má atribut: začátek a konec, modelující přítomnost tohoto zrnka písku v hromadě. Tato sada časových částí se také nazývá 4D reprezentace vytvořená ve 4D paradigmatu. Z této sady lze dočasně získat složení zrnek písku v konkrétním okamžiku Ó th slice: vyberte pouze ty dočasné části zrnek písku, které jsou „aktuální“. momentálněčas, tedy ty, které se objevily v hromadě dříve a opustily hromadu později než ve vybraném časovém okamžiku.

Takto je modelována skladba skutečných „fyzických“ sestav. Ale pro aktuální článek bude taková reprezentace poměrně složitá a vrátím se k obvyklé reprezentaci jednoduchých množin „zamrzlých“ v čase, tedy těch, které existují „mimo čas“.

Určení složení množiny

Sada je hodně, pojatá jako celek, kde hodně je složení sady. Zvažme způsoby, jak určit složení sady. Jak víme, složení množiny lze specifikovat dvěma způsoby:
  1. Přímý výčet objektů vybraných ze sady.
  2. Pravidla pro identifikaci objektů vybraných ze sady.
Předpokládejme například, že v místnosti jsou kromě jiných předmětů dva předměty: bílý talíř a zelená značka.
  1. Soubor A skládající se z těchto dvou prvků lze definovat výčtem: bílá deska je součástí sady A a zelená značka je součástí sady A. Součástí sady A není nic jiného v místnosti.
  2. Můžete to udělat jinak. Na talíř a fix můžete nalepit žlutou samolepku a ujistit se, že v místnosti nejsou žádné další samolepky. Pak můžeme říci, že do sady A jsou zahrnuty pouze ty a jen ty předměty v dané místnosti, které mají žlutou nálepku.
Prvním způsobem, jak určit složení, je výčet
Druhým způsobem je nastavení identifikační podmínky.

Při diskuzi k minulému článku jsem si uvědomil, že ne každý jasně chápe rozdíl mezi těmito dvěma způsoby určování složení množiny. Proto vám o nich řeknu více.

První metoda je založena na řadě prohlášení:

Talíř je součástí sady A
Značka je součástí sady A
Nikdo jiný není součástí sady A

Druhým způsobem je prohlášení v predikátech:

Ten a jen ten předmět v místnosti, který má žlutou nálepku, je součástí sady A.

První způsob popisu kompozice může zahrnovat jakékoli modely objektů. Ve druhém způsobu popisu musí mít objektové modely jeden společný atribut, jehož hodnota určuje, zda je objekt zahrnut do množiny či nikoli. Tedy pokud v modelech nejsou žádné předměty společné atributy není možné sestrojit identifikační podmínky.

V diskusi bylo navrženo, aby samotné zařazení do množiny pomocí výčtu bylo také provedeno jako atribut: „část množiny A“. Objekty, které jsou součástí množiny A, tedy mají hodnotu tohoto atributu „ano“. Poté bylo na základě tohoto atributu navrženo provést označení pro výběr do stejné množiny A: ty objekty, které mají hodnotu „ano“, jsou zahrnuty do množiny A. Autor této myšlenky si nevšiml, že v důsledku logického závěru z těchto dvou tvrzení dostáváme dvě tautologie:

Sada A obsahuje pouze ty objekty, které jsou součástí sady A A

Objekt je zahrnut do množiny A právě tehdy, je-li zahrnut do množiny A.

Tato zjevná prohlášení neobsahují žádné informace o konkrétní objekty, ani o množině A. Když vezmu talíř, tak na základě tohoto tvrzení nebude možné určit, zda do množiny A patří nebo ne.

Proto jsou výčet a pravidlo v zásadě dvě odlišně popisy složení množiny a v matematice se označují jako dva hlavní a zcela odlišné způsoby určování složení množiny.

Mimochodem, svého času se vedly dlouhé debaty o definici toho, co je funkce. Tento spor vznikl, protože se nemohli rozhodnout, která identifikační pravidla jsou považována za správná a která ne. V důsledku toho byla přijata Dirichletova myšlenka, že jakákoli pravidla budou považována za správná. Proto se nebudu pokoušet klasifikovat všechna pravidla, ale zvážím pouze některá, která budeme v této souvislosti potřebovat.

V učebnicích se pravidlu identifikace často říká výběrové pravidlo. Termín „pravidlo výběru“ je zavádějící, protože implikuje určitý druh operace výběru. A to je náznak, že sada může být doplněna. Ale to není pravda. Sada má pevné složení. Proto je lepší nemluvit o výběru, ale o identifikaci. Prvky do množiny nevybíráme, identifikujeme je jako prvky množiny.

Určení složení podmnožiny

Podívejme se, jak určujeme složení mnoha afrických slonů. Napočítal jsem čtyři různé způsoby, jak to udělat.
  1. Můžete je definovat výčtem.
  2. Můžete nalepit nálepku na slony a říci, že ti sloni, kteří na sobě mají nálepku, jsou považováni za africké. Jedná se o určení složení množiny pomocí atributu. Atribut bude považován za přítomnost nebo nepřítomnost nálepky.
  3. Kompozici můžete určit průnikem dvou množin: množiny slonů a množiny zvířat žijících v Africe.
  4. Můžete zavést koncept jako „afričtí sloni“.
Pomocí OWL v ​​naší práci máme možnost implementovat tři výše popsané metody pro specifikaci podmnožiny:
  1. Explicitně vyjmenujte objekty zahrnuté v podmnožině,
  2. Definujte identifikační pravidlo prostřednictvím jakýchkoli podmínek pro libovolné atributy, s různé operace: od samotného faktu, že vlastníte hodnotu atributu, dokud tato hodnota nespadne do určitého rozsahu
  3. Zadejte operace s jinými sadami: například sada A zahrnuje pouze ty objekty, které jsou zahrnuty v sadě B a nejsou zahrnuty v sadě C.
Abychom pochopili, zda můžeme implementovat čtvrtý způsob identifikace pomocí objektového typu, podívejme se na něj blíže.

Modelování podmnožiny pomocí typu

K určení typu „afrického slona“ potřebujeme:
  1. Skupina objektů, ze které vybíráme objekty pro podtyp. V v tomto případě Tato skupina má jméno - jedná se o skupinu slonů.
  2. Jedinečná vlastnost, ve které se objekty tohoto typu liší od ostatních objektů ve skupině: žijí v Africe.
  3. Jedinečný název pro objekty tohoto typu
Můžete to udělat jinak a vzít zvířata žijící v Africe jako skupinu. Jedinečnou vlastností, která odlišuje africké slony od jiných afrických zvířat, bude to, že tato zvířata jsou sloni.

Celkem k definování typu potřebujete:

  1. Určete nadmnožinu objektů.
  2. Upřesněte charakteristické rysy(diferenciální vlastnosti) objektů daného typu od objektů skupiny.
  3. Zadejte název objektů tohoto typu
Navíc můžete specifikovat:
  • Důvody, proč se tento typ objektů stal žádaným (rozdílné funkční vlastnosti objektů tohoto typu
  • Výhody zavedení tohoto typu objektu
  • Historie termínu
Objekty stejného typu se liší od ostatních objektů nadmnožiny nějakou jedinečnou vlastností. Tuto jedinečnou vlastnost lze modelovat pomocí jakýchkoli podmínek na libovolných atributech. Není ale nutné, aby se všechny hodnoty všech atributů shodovaly, nebo aby složení atributů pro všechny objekty stejného typu byl stejný.

Když víte, co je typ, můžete si myslet, že čtvrtá metoda identifikace podmnožin se shoduje s druhou. Abychom však mohli definovat typ, budeme muset dodatečně uvést minimálně specializovaný název a případně uvést další atributy typu, například uvést důvody pro výběr tohoto typu objektu, historii termínu atd. To nelze provést pomocí druhé metody. Proto se čtvrtá metoda liší od druhé a ještě není implementována v modelovacích standardech, které znám.

Typ konceptu

Takže z pohledu teorie množin:

Typ je způsob výběru podmnožiny z nadmnožiny a přiřazení nového názvu objektům této podmnožiny.

Pokud neexistuje žádná nadmnožina, pak je typ považován za axiomatický, nederivovatelný. Jak jsem řekl dříve, koncept objektu a koncept množiny jsou neodvoditelné koncepty, protože jim nelze dát nadmnožinu objektů.

Rozdíl mezi typem objektu a sadou objektů

Z diskuzí k článku jsem si uvědomil, že existují lidé, kteří věří, že typ objektů a množina objektů jsou buď příbuzné pojmy, nebo jeden a tentýž. Pokusím se vysvětlit, proč tomu tak není. Typ je jak pravidlo pro identifikaci objektů, tak název pro tyto objekty. To znamená, že typ současně slouží ke specializaci (nebo výběru) podmnožiny ze sady a dává nový název specializovaným objektům.

Každý typ určuje složení množiny, ale ne každá množina odpovídá typu, který určuje její složení, například když mluvíme o množině, jejíž složení je dáno výčtem jejích prvků, nebo když mluvíme o množině, jejíž prvky dělají nemají svá vlastní jména.

Je jasné, že pravidlo definující množinu není množina samotná.

Zdá se mi, že ze všeho, co bylo řečeno, je jasné, jak se pojem „typ objektů“ liší od pojmu „soubor objektů“.

Modelování podobných objektů

V IS se často objekty stejného typu modelují pomocí modelů obsahujících stejnou sadu atributů. Nyní to můžete vidět toto omezení redundantní, protože objekty stejného typu mohou mít různé sady atributů. Toto omezení je způsobeno technické vlastnosti implementace, ale ne požadavky předmětová oblast.

V IS se rozrůstá seznam objektů stejného typu. To napovídá variabilní skladbě sestav, které modelujeme. To však není pravda. Seznam objektů, které byly evidovány v IP, není vyčerpávajícím výčtem sady. Tzn., že v IS nejsou uloženy modely všech prvků sestavy, ale pouze ty, které jsou aktuálně registrované. Když tedy podáváme žádost, její význam je tento: dejte mi všechny objekty tohoto typu, které jsou aktuálně evidovány v IS.

Životní cyklus objektu

Kromě toho, že objekt lze klasifikovat jako určitý typ objekty, jsou zde ještě dva body, na které by se nemělo zapomínat:
  1. Klasifikace (přiřazení objektu k určitá třída nebo typ objektů) je vždy subjektivní. Stejný objekt může vypadat různě z různých úhlů pohledu. Pokud budujeme model rozšiřitelné domény, jehož použití vyžaduje přítomnost různých zainteresovaných stran, pak musí být možné modelovat kontext a různé úhly pohledu. Navíc z různých úhlů pohledu lze stejný objekt klasifikovat jako různé typy.
  2. Účetnictví životní cyklus Objektu zahrnuje nejen zohlednění změn v objektu, ale také zohlednění změn v našem vnímání tohoto objektu, protože spolu s procesem syntézy a analýzy existuje proces objektivizace a de-objektivizace.
Proces objektivizace a deobjektivizace vypadá takto:

Objektivizace

Máme-li představu o typech, snažíme se najít předměty těchto typů ve světě kolem nás. Nalezené předměty bývají nejširšího typu. Například pokud mluvíme o o podniku, pak se v prvním kroku mohou nalezené objekty týkat operací, funkcí a objektů. Nebo pokud mluvíme o rostlinách, rozdělujeme je nejprve na stromy, trávu a keře. Dále je objasněn typ objektu testováním různých hypotéz. V procesu objasňování se snažíme najít typ, který nám o objektu napoví tolik, aby bylo možné tyto poznatky efektivně využít v praxi (snažíme se najít užší typ, kterému lze tento objekt přiřadit). V procesu zpřesňování získává objektový model nové detaily. Znalosti o tomto objektu přitom využíváme v praxi. Pokud je aplikace těchto znalostí úspěšná, je objekt považován za správně získaný a správně klasifikovaný (typ objektu je správně zvolen).

Deobjektivizace

Vše se však mění: mění se představy o světě kolem nás, objevují se nové poznatky atd. V důsledku toho se ukazuje, že model předmětu přestává uspokojovat požadavek užitku. A pak se příliš úzká specializace objektu stává jeho vlastním nepřítelem. Objekt podléhá reklasifikaci (aplikace se změnila v poptávku) a někdy je zcela zničen, stejně jako byl zničen éter nebo kalorie. A pak cyklus začíná znovu: vybírání předmětů, objasňování znalostí o nich atd.

Případové studie:

Objektivizace:

Nechte klienta přijít podat žádost. Dokud není příkaz proveden, můžeme znát jeho typ pouze s určitou mírou pravděpodobnosti. Proto je nejprve registrována aplikace nejširšího typu. Poté, jak se vyjasňují detaily a v procesu jeho realizace, aplikační model získává nové atributy. Po nějaké době je jasné, jaký typ aplikací zahrnout tuto aplikaci a dochází k jeho konečné klasifikaci.

Deobjektivizace:

Mějme typický scénář pro vyhledávání informací na internetu. Řekněme, že kdykoli potřebujete najít informace, které potřebujete, použijte takový a takový vyhledávač - vyhledávací program potřebné informace. Použijme tento program mnohokrát, pokaždé, když provádíme vyhledávací operaci. Během provozu tohoto programu bylo takových operací mnoho a všechny byly klasifikovány jako operace typu „vyhledávání informací“. Po nějaké době se ukázalo, že program vyhledávače provádí špionážní funkce a „uniká“ data o uživateli zájemcům o tyto informace. A pak se ukáže, že operace, které tento vyhledávač používal, budou nyní překlasifikovány z operací získávání informací na operace přenosu dat zainteresovaných stran. Může se ale klidně stát, že se o tomto programu dozvíme něco více a pak budeme muset přehodnotit další operace, na kterých se podílel.

Požadavky na modeláře modelování typů

Pojďme formulovat požadavky na modeláře, který je určen pro modelování typů:

  1. Je nutné umět modelovat objekty stejného typu, jejichž složení atributů neodpovídá
  2. Musíte být schopni modelovat pravidla, která rozlišují objekty do jednoho typu
  3. Potřeba modelovat další atributy typu: název objektů daného typu, historii tohoto názvu atd.
  4. Musí umět modelovat různé body pohled na stejný objekt
  5. Musíte být schopni modelovat životní cyklus objektu
  6. Je nutné umět modelovat změny v našem chápání objektu v průběhu času.

Jak může IT průmysl implementovat tyto požadavky bez použití databázové struktury? Jak bez odkazu na datovou strukturu vzít v úvahu různé úhly pohledu, přidat nové typy objektů, objasnit typ objektů, v případě potřeby překlasifikovat objekty?

Modelování objektů pomocí OWL

V OWL existuje jedno omezení: nerozlišuje mezi množinou a typem objektů. Z tohoto důvodu máme omezenou funkčnost pro modelování typů objektů. Tato funkčnost je však mnohem širší než to, co nám poskytují jiné metody modelování, protože máme následující možnosti:
  • Přidání nové sady objektů do OWL se neliší od přidání nového objektu.
  • Lze požadovat, že pokud je znám typ objektu, pak byl vytvořen model objektu s danými, dříve známými atributy. Navíc po vytvoření lze atributy buď přidat, nebo odstranit. Příklad: při vytváření aplikačního modelu můžeme požadovat zadání hodnot atributů (číslo aplikace, datum aplikace, žadatel, adresát). Jen si musíte pamatovat, že tyto atributy v OWL existují odděleně od typů objektů. A jeden atribut lze použít při modelování objektů různých sad. Tento zásadní rozdíl z běžných programovacích jazyků, kde atribut existuje pouze v rámci jednoho typu objektu. Jiný atribut v jiném typu, dokonce se stejným názvem, bude odlišný atribut.
  • Můžete požadovat opak: určit podmnožinu modelovaného objektu na základě atributů objektového modelu a jeho členství v nadmnožině. Za tímto účelem pravidlo napíše, že pokud model objektu patřícího do určité nadmnožiny obsahuje takové a takové atributy a jejich hodnoty splňují určitá pravidla, pak bude objekt automaticky přiřazen k určité podmnožině. Takže s pomocí pravidel bude implementována tzv. „kachní klasifikace“. Pokud má například model požadavku hodnotu atributu " Telefonní číslo“ a „Připojení“ je hodnota atributu „Typ vykonávané práce“, pak bude aplikace automaticky klasifikována jako aplikace pro připojení telefonního čísla.

Rozdělení množiny na podmnožiny

Nechť existuje množina objektů. Úkolem je rozdělit tuto množinu do sedmi podmnožin, z nichž každá má přiřazenu vlastní barvu: „červené objekty“, žluté objekty. Atd.

Rozdělení sady na podmnožiny lze provést různými způsoby.

  1. Sadu můžete rozdělit na nesouvislé podmnožiny rozdělením objektů do podmnožin jejich výčtem. Vytvořte sedm podmnožin a uveďte objekty, které patří do každé podmnožiny.
  2. Pro každou podmnožinu můžete přijít s vlastním podtypem. Poté lze celou sadu rozdělit do sedmi podmnožin zavedením sedmi podtypů: „Typ červených objektů“, „Typ žlutých objektů“ atd. Každý objekt lze přiřadit k jednomu z uvedených typů a říci například takto : objekt patří k typu červených objektů.
  3. Nadmnožinu můžete oddělit pomocí atributu a jeho hodnot. Můžete například zadat atribut „Color“ a jeho sedm hodnot: „Červená“, „Žlutá“ atd. Poté se název barvy stane přídavným jménem pro objekt a bude znít takto: červený objekt, žlutý objekt atd.
První metoda v OWL je implementována vytvořením sedmi různé třídy a označení objektů, které se jich týkají.

Druhá metoda může být implementována třemi různými způsoby:

  1. Vytvořením samostatných podmnožin sjednocených jedním typem, ale samotné typy, jak jsem řekl dříve, nejsou modelovány. Tato metoda se neliší od výčtové separační metody.
  2. Pomocí referenční knihy „Typy barevných objektů“, jejichž hodnotami budou objekty, které modelují typy: „Červené objekty“, „žluté objekty“ atd.
  3. Pomocí atributu nazvaného „typ objektu“, jehož hodnoty budou mít textová forma: „Typ červených objektů“, „Typ žlutých objektů“ atd.
Třetí způsob rozdělení množiny na podmnožiny v IS je modelován dvěma způsoby:
  1. Pomocí adresáře „Colors“, jehož hodnoty budou objekty, které modelují hodnoty atributů: červená, žlutá atd.
  2. Pomocí atributu s názvem „Color“, jehož hodnoty budou v textové podobě: „červená“, „žlutá“ atd.
Je vidět, že separace pomocí typů a atributů je modelována ve dvou případech stejně, ale má různá jména. Vlastnictví hodnoty atributu v OWL je modelováno následujícím tripletem:

#objekt #atribut #hodnota

Členství ve třídě je následující:

#object rdf:type #class

To znamená, že můžeme říci, že členství ve třídě je jednoduše vyjádřeno pomocí speciálního atributu služby definovaného ve standardu - rdf:type.

Atribut koncept

Formulujme prohlášení:

Atribut je způsob, jak rozdělit sadu objektů do podmnožin. V tomto případě každá hodnota atributu odpovídá určité podmnožině, jejíž objekty mají atribut s touto hodnotou.

Modelování podmnožin pomocí atributu

Každá ze tří výše uvedených metod modelování podmnožin má své výhody a nevýhody v závislosti na kontextu a zvolené metodě implementace.

Pokud je podmnožin málo, můžete zvolit kteroukoli z uvedených metod rozdělení na podmnožiny a libovolnou implementaci.

Pokud existuje mnoho podmnožin (například v limitě nekonečné, když každá z množin seskupuje objekty stejné délky), formálně zbývá:

  1. třetí způsob modelování typu a
  2. druhý způsob modelování atributu.
Již dříve jsem však psal, že každému typu je potřeba dát jméno. Pokud existuje mnoho podmnožin (nekonečno), pak je pojmenování každé z nich nereálné. Proto toto rozdělení nemodelujeme pomocí typů. Toto rozdělení modelujeme pouze pomocí atributu, jehož rozsah hodnot bude jednou z běžných množin: set reálná čísla, množina modelující časovou osu, množinu přirozená čísla, mnoho řetězců konečné délky atd. Poznáváte datové typy?

Můžete si přečíst o tom, jak zavést funkci na množině podmnožin a nejen o tom

2.1.2. Atributy objektu

Atribut je hodnota, která charakterizuje objekt ve své třídě. Příklady atributů: kategorie, zůstatek, kredit (atributy objektů účtové třídy); jméno, věk, váha (atributy objektů třídy osoby) atd.

Atributy se liší trvalé atributy(konstanty) a proměnné atributy. Konstantní atributy charakterizují objekt ve své třídě (například číslo účtu, kategorie, jméno osoby atd.). Aktuální hodnoty atributových proměnných charakterizují proud stát objekt (například zůstatek na účtu, věk osoby atd.); Změnou hodnot těchto atributů změníme stav objektu.

Atributy jsou uvedeny v druhé části obdélníku představujícího třídu (viz obrázek 2.1). Někdy je uveden typ atributů (ostatně každý atribut má určitou hodnotu) a počáteční hodnota proměnných atributů (množina počátečních hodnot těchto atributů určuje počáteční stav objektu).

Je třeba si uvědomit, že když mluvíme o objektech a jejich třídách, nemáme na mysli žádný objektově orientovaný programovací jazyk. To se projevuje zejména v tom, že v této fázi Při vývoji softwarového systému byste měli brát v úvahu pouze ty atributy, které dávají smysl ve skutečnosti (tuto vlastnost mají všechny atributy objektů třídy account - obrázek 2.1). Atributy jsou spojeny s vlastnostmi celkové implementace. Pokud například víte, že budete používat databázi, ve které má každý objekt jedinečný identifikátor, pak by tento identifikátor neměl být v této fázi zahrnut mezi atributy objektu. Faktem je, že zavedením takových atributů omezujeme možnosti implementace systému. Zavedením jedinečného identifikátoru objektu do databáze jako atributu tedy hned na začátku návrhu odmítáme používat DBMS, které takový identifikátor nepodporují.

MINISTERSTVO ŠKOLSTVÍ A VĚDY RUSKÉ FEDERACE

Stát vzdělávací instituce vyšší odborné vzdělání

Ruská ekonomická univerzita pojmenovaná po G.V. Plechanov

Ufa Institute (pobočka)

Fakulta ekonomiky a managementu

Kurz 2

Specialita 230700,62 Aplikovaná informatika

Gabbasov Timur Aidarovič

Práce v kurzu

Disciplína: "Softwarové inženýrství"

Na téma: „Koncept třídy a objektu. Co by mohlo být předmětem? Atribut a operace"

Vedoucí: Sadrtdinov F.A.

Ufa 2014

Úvod……………………………………………………………………………………………….. 3

1. Pojem objektu v programování …………………………………4

2. Definice třídy………………………………………………………………..6

2.1.Atributy tříd………………………………………………………..7

2.2. Provoz………………………………………………………………………..8

2.3 Závislosti mezi třídami a objekty …………………………..11

Závěr……………………………………………………………………………………….. 15

Seznam referencí……………………………………………………………….17

Zavedení

Relevantnost této prácespočívá v tom, že díky konceptům jako „Object“ a „Class“ se objektově orientované programování objevilo jako systematický přístup k algoritmické formalizaci komplexních oborů, což výrazně zjednodušilo řešení objemných problémů.

Předmět výzkumu -koncept třídy a objektu.

Předmět studia -objekt a třída a jejich vztah s atributem a operacemi.

Účel této práce:odhalit podstatu pojmů objekt a třída, naznačit jejich souvislost s pojmy atribut a operace, naznačit jejich roli v koncepci objektově orientovaného programování.

úkoly:


1.Naučte se pojmy objekt a třída.

2.Uveďte příklady
3.Nastudujte si pojmy atribut a operace.

4.Uveďte roli v objektově orientované programovací koncepty.

1. Pojem objektu v programování

V každém běžném normativním programovacím jazyce se rozlišují pojmy jako data a datové typy. Data jsou čísla, řetězce znaků, různé binární kódy, které lze uložit do paměti RAM počítače a provádět s nimi různé operace. Datové typy jsou názvy skupin dat, které jsou stejné velikosti, obsazené v paměti RAM a způsobu vnější reprezentace, například celá čísla nebo znaky.

Podobné rozdělení existuje v objektově orientovaných programovacích jazycích. Objekt je koncept nejblíže konceptu dat. To je něco, co musí v programu skutečně existovat a zabírat prostor určený jeho typem. BERAN. Zároveň je objekt více komplexní koncept než jen daný nebo soubor dat. Nejjednodušeji by se objekt dal nazvat nerozlučnou sbírkou dat se sadou funkcí (nebo tzv. metod), které postačují pro zpracování těchto dat nezbytných v programu.

Aby bylo možné začít skládat objektově orientovaný program, je nutné strávit poměrně dlouhou dobu identifikací a klasifikací objektů, které jsou nezbytné pro řešení problému softwarovým systémem.

Objekt lze nazvat nějakým nezávisle rozlišitelným softwarový model, jako systém modelů objektů, pojmů a vztahů mezi nimi s jejich charakteristickým chováním v čase a možné způsoby změny, které hrají důležitou funkční roli při řešení konkrétní úkol programování.

Pojďme dát obecné znaky objektů.

Objekt je rozpoznatelný, tzn. má nějaké, možná ne jasně definované, hranice.

Objekt je charakterizován souborem možných stavů, ve kterých se v určitých časových intervalech nachází. Stavy se navzájem nahrazují po celou dobu existence objektu.

Objekt projevuje své vlastnosti při interakci s jinými objekty. Tato vlastnost se někdy nazývá chování objektu.

Objekt je unikátní, tzn. má vlastnosti, které jej umožňují odlišit od ostatních objektů.

Objekt má určitý rámec životního cyklu. „Narodí se“, funguje, mění stav za stavem a „umírá“. Tato vlastnost je spojena s existencí v programu jasně definovaného rámce pro fungování objektu. Objekty místního programu mají nejmenší „život“, maximum - globální objekty, který se objeví ihned po spuštění programu a zmizí těsně před jeho dokončením.

Uvedené vlastnosti objektů přidělených při řešení konkrétního problému téměř zcela odpovídají budoucím funkcím objektů v programu. Fungování objektu obvykle začíná přidělením počítačové paměti RAM a vytvořením určitého počátečního stavu (počáteční hodnoty během inicializace). Během následné činnosti programu se paměťová oblast obsazená objektem mění, což charakterizuje nové stavy objektu, který interaguje s jinými objekty. A nakonec, když dokončí svou práci, objekt uvolní paměť, kterou zabíral.

Vlastnosti předmětu umožňují odlišit pojem „objekt“ od poněkud opačného pojmu „třída“.

2. Definice třídy

Objekty s identické vlastnosti a metody.

Jedna z prvních akcí, které člověk udělá, když se snaží porozumět svět kolem nás, je aplikovat některé strukturální forma. Když narazíme na neznámý předmět, snažíme se jej zařadit do naší stávající struktury: jinými slovy klasifikovat jej. Většina lidí zná alespoň několik klasifikačních struktur nebo hierarchií.

Použití hierarchie tříd zavádí potřebu abstrakce. Třídy se stávají abstraktnějšími, když se pohybujete v hierarchii výše.

Objektově orientované jazyky používají stejný přístup. Hierarchie obvykle začínají několika abstraktní třídy. Každý nová třída je reprezentována jako podtřída existující třídy (nazývaná její nadtřída). Dědí data a metody z tříd výše v hierarchii. Měla by být definována a implementována pouze data a metody, které jsou pro tuto třídu nové.

Třída je abstraktní pojem, srovnatelný s pojmem kategorie v jejím běžném smyslu.

Na základě určitých vlastností jakéhokoli prvku určité kategorie lze stanovit, že do ní patří. Je určena samotná kategorie obecné vlastnosti, kterou mají všechny instance této kategorie.

To lze ilustrovat na příkladu hudební nástroje. Hudební nástroje se dělí do těchto kategorií: dechové, bicí a smyčcové.

Všechny tyto kategorie patří do kategorie hudebních nástrojů. Do kategorie nástrojů je zase zařazena kategorie hudebních nástrojů. Na obr. 1 je tato struktura kategorií graficky znázorněna ve formě stromu.

Všechny objekty stejné třídy jsou charakterizovány stejnými sadami atributů. Seskupování objektů do tříd však není určeno sadami atributů, ale sémantikou. Takže například objekty stáj a kůň mohou mít stejné atributy: cenu a stáří. Kromě toho mohou patřit do stejné třídy, pokud jsou v problému považovány pouze za produkt nebo do různé třídy, což je přirozenější.

Obr. 2.1 Obr. 2.2

2.1.Atributy tříd

Atribut je hodnota, která charakterizuje objekt ve své třídě. Příklady atributů: kategorie, zůstatek, kredit (atributy objektů účtové třídy); jméno, věk, váha (atributy objektů třídy osoby) atd.

Mezi atributy se rozlišují trvalé atributy (konstanty) a proměnné atributy. Konstantní atributy charakterizují objekt ve své třídě (například číslo účtu, kategorie, jméno osoby atd.). Aktuální hodnoty proměnných atributů charakterizují aktuální stav objektu (například zůstatek na účtu, věk osoby atd.); Změnou hodnot těchto atributů změníme stav objektu.

Atributy jsou uvedeny v druhé části obdélníku představujícího třídu (viz obrázek 2.1). Někdy je uveden typ atributů (ostatně každý atribut má určitou hodnotu) a počáteční hodnota proměnných atributů (množina počátečních hodnot těchto atributů určuje počáteční stav objektu).

Je třeba si uvědomit, že když mluvíme o objektech a jejich třídách, nemáme na mysli žádný objektově orientovaný programovací jazyk. To je vyjádřeno zejména tím, že v této fázi vývoje softwarového systému by měly být brány v úvahu pouze ty atributy, které mají ve skutečnosti smysl (tuto vlastnost mají všechny atributy objektů třídy účtu - obrázek 2.1).

Atributy jsou spojeny s vlastnostmi celkové implementace. Pokud například víte, že budete používat databázi, ve které má každý objekt jedinečný identifikátor, neměli byste tento identifikátor v této fázi zahrnout mezi atributy objektu. Faktem je, že zavedením takových atributů omezujeme možnosti implementace systému. Zavedením jedinečného identifikátoru objektu do databáze jako atributu tedy hned na začátku návrhu odmítáme používat DBMS, které takový identifikátor nepodporují.

2.2.Provoz

Operace je funkce (nebo transformace), kterou lze aplikovat na objekty dané třídy. Příklady operací: kontrola, odstranění, umístění (pro objekty třídy účet), otevření, čtení, zavření (pro objekty třídy soubor - obrázek 3.1) atd.

Obr.3.1

Všechny objekty dané třídy používají stejnou instanci každé operace (tj. zvýšení počtu objektů určité třídy nezvýší množství načtených programový kód). Objekt, ze kterého je operace volána, je mu předán jako jeho implicitní argument (parametr).

Stejnou operaci lze obecně vzato použít na objekty různých tříd: taková operace se nazývá polymorfní, protože může mít různé tvary pro různé třídy. Například pro objekty tříd vector a complex_number můžete definovat operaci +; tato operace bude polymorfní, protože sčítání a přidávání vektorů komplexní čísla, obecně řečeno, různé operace.

Každá operace má odpovídající metodu - implementaci této operace pro objekty dané třídy. Operace je tedy specifikace metody, metoda je implementace operace. Například ve třídě souboru lze definovat operaci tisku. Tato operace může být provedena různé metody: (a) tisknout binární soubor; b) těsnění textový soubor atd. Tyto metody logicky provádějí stejnou operaci, i když jsou implementovány různými fragmenty kódu.

Každá operace má jeden implicitní argument – ​​objekt, na který je aplikována. Operace může mít navíc další argumenty (parametry). Tyto další argumenty parametrizují operaci, ale nejsou spojeny s výběrem metody. Metoda je spojena pouze s třídou a objektem (některé objektově orientované jazyky, jako je C++, umožňují stejnou operaci s různá čísla argumenty a pomocí toho či onoho počtu argumentů prakticky volíme jednu z metod spojených s takovou operací; ve fázi předběžného návrhu systému je vhodnější považovat tyto operace za odlišné a dávat je různá jména, aby to nekomplikovalo design).

Operace (a metody, které ji implementují) je definována svým podpisem, který zahrnuje kromě názvu operace i typy (třídy) všech jejích argumentů a typ (třídu) výsledku (návratovou hodnotu). Všechny metody, které implementují operaci, musí mít stejný podpis jako operace, kterou implementují.

Operace jsou uvedeny ve spodní části obdélníku (obrázek 3.1), který popisuje třídu. Každá operace musí být reprezentována svým vlastním podpisem, nicméně v raných fázích návrhu se můžete omezit na zadání názvu operace a odložit úplná definice podpisy pro konec uvažované fáze životního cyklu (nebo i pro následující fáze). V grafický jazyk Technologie OMT, typ libovolného datového objektu je uveden za názvem tohoto objektu za dvojtečkou (jako v Pascalu).

Při modelování systému je užitečné rozlišovat mezi operacemi, které mají vedlejší účinky (tyto účinky jsou vyjádřeny změnou hodnot atributů objektu, tj. změnou jeho stavu), a operacemi, které produkují požadovanou hodnotu beze změny. stav objektu. Tyto nedávné transakce se nazývají žádosti.

K hodnotám některých atributů objektu lze přistupovat pouze operacemi s tímto objektem. Takové atributy se nazývají soukromé. Obrázek 2.3 ukazuje soukromé atributy pro objekty třídy účtu. Hodnoty soukromých atributů objektu lze nalézt mimo objekt, pouze pokud jsou mezi operacemi daného objektu definovány vhodné dotazy. Podobně je možné definovat uzavřené (pomocné) operace v objektu, ale v raných fázích návrhu se to obvykle nedělá, protože identifikace uzavřených operací je spojena především s implementací systému.

Obrázek 3.2 Veřejné a soukromé atributy a operace

Dotazy bez argumentů (kromě implicitního argumentu - objektu, na který je operace aplikována) lze považovat za odvozené atributy. Hodnoty odvozených atributů závisí na hodnotách primárních atributů. To je jejich rozdíl od hlavních atributů, jejichž hodnoty jsou nezávislé. V důsledku toho hodnoty primárních atributů objektu určují jak jeho stav, tak hodnoty jeho odvozených atributů. Takže například délka, šířka a výška místnosti jsou jejími hlavními atributy a plocha a kubatura jsou odvozené atributy; atribut, jako je kubatura, je nutný, aby se nepočítala kubatura místnosti pokaždé, když je potřeba její hodnota.

Výběr hlavních atributů objektů je libovolný, ale hlavní atributy by neměly zahrnovat ty atributy, jejichž hodnoty jsou určeny hodnotami jiných atributů, takže jsou ve skutečnosti odvozeny.

Chcete-li tedy definovat třídu, musíte zadat název této třídy a poté vypsat její atributy a operace (nebo metody). Celý popis objekt v grafickém jazyce OMT má podobu znázorněnou na obrázku 3.3. Někdy je však vhodné použít zkrácený popis třídy, kdy je v obdélníku znázorňujícím tuto třídu uveden pouze název třídy. Obrázek 2.5 tedy ukazuje zkratky pro označení tříd pro náš hlavní příklad – systém služeb zákazníkům bankovního konsorcia.

Rýže. 3.3. Plná reprezentace objektů v OMT

Rýže. 2.5. Možné třídy pro AMT (bankovní) systém

2.3 Závislosti mezi třídami a objekty

Každý objekt je spojen s datovou strukturou, jejíž pole jsou atributy tohoto objektu a ukazatele na funkce (fragmenty kódu), které implementují operace tohoto objektu (všimněte si, že ukazatele funkcí jsou v důsledku optimalizace kódu obvykle nahrazeny voláním těchto funkcí). Objekt je tedy nějaká datová struktura, jejíž typ odpovídá třídě tohoto objektu.

Mezi objekty lze vytvořit datové závislosti. Tyto závislosti vyjadřují spojení nebo vztahy mezi třídami zadaných objektů. Příklady takových závislostí jsou znázorněny na obrázku 3.6 (první dvě závislosti jsou binární, třetí závislost je trojčlenná). Závislost je znázorněna čárou spojující třídy, nad kterou je napsán název této závislosti, případně jsou uvedeny role objektů (tříd) v této závislosti (označení rolí je nejvíce pohodlný způsob identifikace závislosti).

Rýže. 3.6. Závislosti mezi třídami

Závislosti mezi třídami jsou obousměrné: všechny třídy v závislosti mají stejná práva. To platí i v případech, kdy se zdá, že název závislosti zavádí směr do této závislosti. Takže v prvním příkladu na obrázku 3.6 název závislosti „má kapitál“ naznačuje, že závislost směřuje z třídy venkova do třídy města (zdá se, že obousměrná povaha závislosti zmizela); ale je třeba mít na paměti, že tato závislost je obousměrná v tom smyslu, že zároveň existuje inverzní závislost, která je kapitálem. Úplně stejným způsobem, ve druhém příkladu na obrázku 3.6, lze uvažovat o vlastním páru závislostí. Takovým nedorozuměním se lze vyhnout, pokud jsou závislosti identifikovány nikoli jmény, ale jmény rolí tříd, které tvoří závislost.

V programovacích jazycích jsou závislosti mezi třídami (objekty) obvykle implementovány pomocí odkazů (ukazatelů) z jedné třídy (objektu) na druhou. Reprezentace závislostí pomocí odkazů odhaluje skutečnost, že závislost je vlastností dvojice tříd a nikoli žádné z nich, tzn. závislost je vztah. Všimněte si, že i když jsou závislosti mezi objekty obousměrné, není nutné je implementovat jako obousměrné v programech a ponechat odkazy pouze v těch třídách, kde je to pro program nezbytné.

Další příklady závislostí mezi třídami jsou uvedeny na obrázku 3.7. První příklad ukazuje vztah mezi klientem banky a jeho účty. Klient banky může mít v této bance několik účtů současně, nebo nemusí mít účet vůbec (když se poprvé stane klientem banky). Je tedy nutné znázornit vztah mezi klientem a několika účty, což je provedeno na obrázku 3.7. Druhý příklad ukazuje vztah mezi protínajícími se zakřivenými (konkrétně přímými) čarami. Můžete zvážit 2, 3 nebo více takových čar a mohou mít několik průsečíků. Konečně třetí příklad ukazuje volitelnou závislost: počítač může nebo nemusí mít myš.

Závislosti mezi třídami odpovídají závislostem mezi objekty těchto tříd. Obrázek 3.8 ukazuje závislosti mezi objekty pro první příklad z obrázku 2.6; Obrázek 3.9 ukazuje závislosti mezi objekty pro příklady zobrazené na obrázku 3.7.

Rýže. 3.7. Další příklady závislostí. Označení

Rýže. 3.8. Závislosti mezi objekty

Všimněte si, že při zobrazování závislostí mezi objekty zpravidla známe počet objektů a nepotřebujeme taková označení jako „několik“, „dva nebo více“, „ne nutně“.

Při navrhování systému je výhodnější pracovat nikoli s objekty, ale s třídami.

Rýže. 3.9. Složitější závislosti mezi objekty

Koncept závislosti byl přenesen do technologie objektově orientovaného návrhu softwarové systémy z technologie návrhu (a modelování) databází, kde se závislosti používají již dlouhou dobu. Programovací jazyky zpravidla nepodporují explicitní popis závislostí. Popis závislostí je však velmi užitečný při vývoji softwarových systémů. Technologie OMT používá závislosti k interpretaci diagramů, které popisují systém.

Závěr

Objekty v programu fungují jako sehraný tým docela nezávislé programy, kteří sami vědí, kdy v závislosti na aktuální situaci potřebují začít s prací, kdy ji dočasně pozastavit a nakonec, kdy zcela opustit programový tým, aniž by na sebe zanechali vzpomínku kromě nezbytných užitečných výsledků práce. Zpravidla každý objekt, který začíná svou práci, objednává operační systém RAM pro svá data a po dokončení práce vrátí tuto paměť zpět do systému. Tím se optimalizuje množství paměti zabrané celým programem během jeho činnosti.

Aby objekty jasně znaly své místo a pravomoci v jednom týmu a neprováděly stejnou práci, podléhají zvláštní klasifikaci, jejímž výsledkem je identifikace tříd objektů. Pokud mají dvě třídy společné vlastnosti, pak pro ně musí existovat obecnější třída, která má pouze ty vlastnosti, které jsou společné těmto dvěma objektům. V tomto případě se objekty tříd se společnými vlastnostmi musí starat pouze o provádění funkcí spojených s jejich odlišnými vlastnostmi. Obecnou část lze provést objektem obecnější třídy.

Podívali jsme se na definice třídy, objektu, atributů, operací, hlavních součástí objektově orientovaného přístupu.
Dá se rozdělit do čtyř fází.

První fází je identifikace abstrakcí. Izolování abstrakcí znamená analýzu předmětné oblasti, pro kterou je program sestaven, za účelem určení hlavních objektů předmětné oblasti, jejich vlastností, vztahů mezi objekty a také možných operací s objekty a jejich komponentami.

Druhá fáze se skládá z typování objektů a syntézy abstraktních datových typů. Fáze zahrnuje definování nových odvozených datových typů a sad specifických funkcí nebo operací aplikovaných na tyto datové typy takovým způsobem, aby se vyloučila možnost míchání nebo záměny různých typů.

Třetí fází je objektdekompozice jako výběr podtypů nebo podobjektů a jejich komponent pro každý typ objektu.

Čtvrtá etapa představuje kompoziční hierarchizaci objektů jako identifikaci generických a kompozičních vztahů nad objekty.

V důsledku objektově orientovaného přístupu k návrhu programu se proces vývoje programu mění v evoluční proces.programování, ve kterém provádění jakýchkoli změn a doplňků programu nevyžaduje radikální revizi jeho základních algoritmů. Evoluční metoda programování je založena na zachování integrity programových objektů, tzn. změny programu by neměly mít vliv vnitřní organizace objekty v něm existující.

Důležitá vlastnost objektově orientované jazyky je schopnost vyvíjet v nich programy, které fungují v systémech se složitými paralelními výpočetními procesy, které jsou vlastní technické prostředky výpočetní technika. Tato vlastnost je založena na konceptu aktivních a neaktivních objektů během provozu programu. Současná činnost různých objektů je možná díky jejich přísnému typování a uzavřenosti pro změny jinými objekty.

Reference:

1. M. Waite, S. Prata, D. Martin C Jazyk: Přeloženo z angličtiny-M.: Mir, 2007.-463 s., ill.

2. Winer R. Turbo C Jazyk: Přeloženo z angličtiny-M.: Mir, 2010.-384 s., ill.

3. Berry R., Meekins B. Jazyk C: úvod pro programátory: Přel. z angličtiny-M.: Finance and Statistics, 2007.-s., ill.

4. TURBO C++. Borland International. Inc. 2010.

Popisný atributy představují fakta vlastní každému popisu objektu. Příklad - logická funkce prvek digitálního obvodu.

Pokud se změní hodnota popisného atributu, znamená to, že se tento aspekt instance objektu změnil, ale objekt zůstává stejný.

Ukazování atributy se používají k určení názvu nebo označení instance.

Ukazovací atributy se používají jako identifikátory objektů.

Pomocný atributy se používají k přidružení instance jednoho objektu k instanci jiného objektu. Například instance objektu „Microcircuit“ s instancí „Electrical circuit diagram“.

Pokud se změní hodnota pomocného atributu, znamená to, že ostatní instance objektu nyní souvisí.

Popis atributů

U popisných atributů popis specifikuje skutečnou charakteristiku, která je abstrahována jako atribut.

V tomto případě je popis uveden takto:

    Výpis všech možné hodnoty, který atribut může přijmout;

    Formulování pravidla, které určuje, jaké hodnoty jsou povoleny;

    Určení rozsahu možných hodnot.

Popis hodnot indikačního atributu určuje formu indikace a rozsah, v jakém lze atribut použít jako identifikátor.

Popis pomocného atributu musí obsahovat popis skutečného vztahu definovaného atributem.

Pravidla atributů

Od jakékoli informační model, námi generované, by neměly obsahovat informační chyby (chyby). K tomu se musí snažit být relačním modelem, tzn. všechny vztahy mezi daty informačního modelu musí odpovídat pravidlům relační algebry.

Pravidlo 1. atributu

Jedna instance objektu má vždy jednu hodnotu pro každý atribut.

Pravidlo 2. atributu

Atribut nesmí mít žádnou vnitřní strukturu. Všechny atributy jsou jednoduché.

Pravidlo 3. atributu

Pokud má objekt složený identifikátor, tzn. identifikátor sestávající z více než jednoho atributu, pak každý atribut nezahrnutý ve složeném identifikátoru musí charakterizovat celý objekt, nikoli jeho část.

Vztahy mezi objekty

Spojení je abstrakce souboru vztahů, které systematicky vznikají mezi různými druhy objektů v reálném světě.

Každý vztah v informačním modelu je specifikován dvojicí názvů, které popisují vztah z pohledu každého zúčastněného objektu.

Příklad: diagram obsahuje prvky – prvky jsou součástí diagramu.

Vztah je graficky znázorněn čárou mezi souvisejícími prvky.

Příklad: vezměme ekonomický objekt:

Přímé vztahy se dělí na:

    Bezpodmínečná spojení

    Podmíněné spoje

Mezi nepodmíněnými spojeními existují 3 základní typy spojení. Toto jsou spojení:

    One-to-one je vztah, ve kterém je jedna instance jednoho objektu spojena s jednou instancí jiného objektu.

    One-to-many je vztah, ve kterém je jedna instance objektu spojena s jednou nebo více instancemi jiného objektu a každá instance druhého objektu je spojena pouze s jednou instancí prvního objektu.

    Many-to-many je vztah, ve kterém je jedna instance objektu spojena s jednou nebo více instancemi jiného objektu a každá instance jiného objektu je spojena s jednou nebo více instancemi prvního objektu.

2. typ vztahové vazby – podmíněná spojení.

Podmíněné připojení může mít instance objektu, které se neúčastní připojení.

N například:

Všechna připojení vyžadují popis. Popis obsahuje:

    ID komunikace

    Formulace názvů vztahů z hlediska zúčastněných objektů

    Typ připojení (jeho pluralita a podmíněnost)

    Prohlášení o tom, jak bylo spojení formalizováno (proč toto spojení zavádíme)

Formalizace spojení (jeho definice) spočívá v navázání spojení mezi instancemi objektu. To se provádí pomocí pomocných prostředků.

Pokud má objekt pomocné atributy, říká se, že vztah je formalizovaný.

Pro formalizaci vztahu one-to-many je pomocný atribut nastaven na straně mnoha.

Pokud máme vztah many-to-many, abychom neporušili pravidlo 3. atributu, vytvoříme pomocný (asociativní) objekt, který obsahuje odkazy na identifikátor každé zúčastněné instance.

Vztahy, které vznikají díky přítomnosti dalších spojení mezi objekty, se nazývají kompoziční spojení.

Pokud v informačních modelech existuje dědičnost, pak existují podtypy a nadtypy.

Nadtyp je nadřazený objekt.

Podtyp je podřízený objekt.




Nahoru