História UML

Vývoj UML sa začal v októbri 1994, keď Grady Booch a Jim Rumbaugh z Rational Software Corporation začali spolupracovať na zjednotení metód Booch a OMT (Object Modeling Technique). Obe metódy sa vyvíjali nezávisle od seba a boli právom označované za jednu z najlepších metód objektovo orientovaného prístupu pri vývoji softvérových systémov. Bolo rozhodnuté spojiť tieto dve metódy a v októbri 1995 bola vydaná beta verzia, ktorá sa volala Unified Method.

Koncom roku 1996 sa ukázalo, že množstvo veľkých spoločností je pripravených považovať UML za základnú obchodnú stratégiu. Vzniklo neziskové konzorcium OMG (Object Modeling Group), ktoré združovalo takých popredných výrobcov softvéru ako DEC, HP, IBM, Microsoft, Oracle, Rational Software atď. V januári 1997 vyšlo UML 1.0. Čoskoro sa k OMG pridali také spoločnosti ako IBM, Objectime, Platinum Technology a Softeam. V dôsledku tejto spolupráce sa objavil UML 1.1. V roku 2003 bola prijatá verzia 1.5. 2004 – prijatá verzia 2.0

Štruktúra UML

UML (skratka pre Unified Modeling Language) je grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvéru. UML je všeobecný jazyk, otvorený štandard, ktorý používa grafickú notáciu na vytvorenie abstraktného modelu systému, nazývaného model UML. UML bol vytvorený na definovanie, vizualizáciu, návrh a dokumentáciu väčšiny softvérových systémov.

UML zabezpečuje vývoj reprezentatívnych modelov na organizovanie interakcie medzi zákazníkom a vývojárom IS a rôznymi skupinami vývojárov IS.

V prvom rade UML zdedí techniky od Booch, OMT a OOSE.

Po druhé, pokrýva ich.

Po tretie, treba poznamenať, že UML je jazykový štandard, nie procesný štandard.

Jazyk UML obsahuje sadu grafických prvkov používaných v diagramoch. Ako jazyk UML obsahuje pravidlá na kombinovanie týchto prvkov. Diagramy sa používajú na zobrazenie rôznych pohľadov na systém. Tento súbor rôznych zobrazení sa nazýva model. Model UML popisuje, čo bude systém musieť urobiť. Zároveň sa nehovorí nič o tom, ako sa bude realizovať.

Z najvšeobecnejšieho hľadiska sa popis jazyka UML skladá z dvoch vzájomne sa ovplyvňujúcich častí, ako napríklad:

Sémantika jazyka UML. Predstavuje určitý metamodel, ktorý definuje abstraktnú syntax a sémantiku konceptov objektového modelovania v jazyku UML.

Notácia UML. Je to grafická notácia na vizuálne znázornenie sémantiky jazyka UML.

UML diagramy

Prejdime teraz k prehľadu grafickej notácie UML. Grafická notácia je mapovanie vizuálnej reprezentácie do sémantiky jazyka. Ako už bolo spomenuté, UML je kvintesenciou troch techník modelovania a v podstate zdedí ich grafický zápis, pričom sa zbavuje málo používaných a nevýrazných prvkov a pridáva sa nové, aby vyhovovali potrebám trhu moderných softvérových systémov. Pri tvorbe UML sme sa snažili zachovať rovnováhu medzi jednoduchosťou a zrozumiteľnosťou jazyka a jeho výrazovou silou a presnosťou. Model vyvíjaného systému je množina vzájomne prepojených podmodelov, z ktorých každý je opísaný množinou diagramov opísaných pomocou grafickej notácie definovanej v UML.

Projekt vytvorený pomocou UML 1.x môže obsahovať nasledujúce diagramy (zoskupené podľa účelu): Existujú také schémy osem:

Schéma prípadu použitia

· Diagram tried

· Diagramy správania

o Stavový diagram

o Diagram aktivity

o Interakčné diagramy

§ Sekvenčný diagram

§ Diagram spolupráce

· Implementačné diagramy

o Schéma komponentov

o Diagram nasadenia

3.1. Schéma prípadu použitia

Diagramy použitia popisujú funkčnosť IS, ktorá bude viditeľná pre používateľov systému. „Každá funkcia“ je znázornená ako „prípady použitia“ alebo jednoducho prípady použitia. Prípad použitia je typická interakcia používateľa so systémom, ktorá:

popisuje užívateľsky viditeľnú funkciu,

môže predstavovať rôzne úrovne detailov,

zabezpečuje dosiahnutie konkrétneho cieľa, ktorý je pre používateľa dôležitý.

Prípad použitia je na diagrame označený oválom spojeným s používateľmi, ktorí sa zvyčajne nazývajú aktéri. Aktéri používajú systém (alebo ich systém používa) v danom prípade použitia. Herec hrá v tomto prípade určitú úlohu. Diagram zobrazuje iba jedného aktéra, ale v tejto úlohe vo vzťahu k IS môže pôsobiť veľa skutočných používateľov. Zoznam všetkých precedensov vlastne určuje funkčné požiadavky na informačný systém, ktoré tvoria základ pre vypracovanie technických špecifikácií pre tvorbu systému.

V diagramoch prípadov použitia je okrem spojení medzi aktérmi a prípadmi použitia možné použiť ešte dva typy spojení medzi prípadmi použitia: „použitie“ a „rozšírenie“ (obr. 3.1.1). Pripojenie typu rozšírenia sa používa, keď je jeden prípad použitia podobný druhému, ale nesie o niečo väčšie funkčné zaťaženie. Mal by sa použiť na opis zmien v normálnom správaní systému. Pripojenie typu „použitie“ vám umožňuje izolovať určitý fragment správania systému a zahrnúť ho do rôznych prípadov použitia bez toho, aby ste ho znova opisovali.

Jadrom úlohy UML pri vývoji softvéru je rozmanitosť spôsobov použitia jazyka, rozdiely, ktoré sa preniesli z iných jazykov grafického modelovania. Tieto rozdiely vedú k dlhým a zložitým diskusiám o tom, ako by sa malo používať UML.

Na vyriešenie tejto ťažkej situácie Steve Mellor a Martin Fowler nezávisle prišli s definíciou tri spôsoby používania UML od vývojárov: režim skica, režim dizajn a režim programovací jazyk. Samozrejme, najdôležitejší z týchto troch je spôsob použitia. UML pre skicovanie. V tomto režime vývojári používajú UML na komunikáciu informácií o rôznych aspektoch systému. V režime návrhu môžete použiť náčrty na dopredné a spätné inžinierstvo. O priamy vývoj(predné inžinierstvo) diagramy sa kreslia pred kódovaním a kedy reverzné inžinierstvo(reverzné inžinierstvo) diagramy sú zostavené na základe zdrojového kódu, aby ste mu lepšie porozumeli.

Esencia skicovania alebo modelovanie skice, v selektivite. Pri priamom vývoji si načrtnete jednotlivé prvky programu, ktorý sa chystáte napísať, a zvyčajne o nich diskutujete s niektorými z vývojárov vo vašom tíme. Pomocou náčrtov si chcete uľahčiť zdieľanie nápadov a možností toho, čo budete robiť. Nerozoberáte celý program, na ktorom máte v úmysle pracovať, ale iba najdôležitejšie body, ktoré chcete najskôr sprostredkovať svojim kolegom, alebo časti projektu, ktoré si chcete vizualizovať pred začiatkom programovania. Tieto stretnutia môžu byť veľmi krátke: 10-minútové stretnutie na niekoľko hodín programovania alebo jednodňové stretnutie na prediskutovanie dvojtýždňovej iterácie.

V reverznom inžinierstve používate náčrty na vysvetlenie, ako funguje niektorá časť systému. Nezobrazujete všetky triedy, len tie, ktoré sú zaujímavé a stoja za prediskutovanie predtým, ako sa ponoríte do kódu. Keďže skicovanie je neformálne a dynamické a musíte ho robiť rýchlo a spoločne, najlepším zobrazovacím médiom je tabuľa. Náčrty sú tiež užitočné v dokumentácii, kde zohráva hlavnú úlohu skôr proces sprostredkovania informácií ako úplnosť. Nástroje na skicovanie sú ľahké nástroje na kreslenie a vývojári často v skutočnosti nedodržiavajú všetky prísne pravidlá UML. Sila náčrtov spočíva v selektivite prenosu informácií, a nie v úplnosti popisu.

Naopak, jazyk UML Ako znamená dizajn zamerané na úplnosť. V procese priameho vývoja ide o to, že projekt vyvíja dizajnér, ktorého úlohou je zostaviť podrobný model pre programátora, ktorý bude robiť kódovanie. Takýto model by mal byť úplne úplný z hľadiska stanovených návrhových rozhodnutí a programátor by mal byť schopný ich sledovať priamo a bez veľkého premýšľania. Dizajnérom modelu môže byť ten istý programátor, ale spravidla je dizajnér starší programátor, ktorý vyvíja modely pre programátorský tím. Dôvod tohto prístupu spočíva v analógii s inými typmi inžinierskych prác, kde profesionálni inžinieri vytvárajú výkresy, ktoré sú následne odovzdané stavebným firmám.

Dizajn je možné použiť pre všetky časti systému, alebo môže dizajnér nakresliť model konkrétneho dielu. Bežným prístupom je, že dizajnér vyvíja modely na úrovni návrhu ako rozhrania podsystému a potom nechá vývojárov pracovať na detailoch implementácie.

V reverznom inžinierstve je účelom modelov reprezentovať podrobné informácie o programe buď ako papierové dokumenty, alebo vo forme vhodnej na interaktívne prezeranie pomocou grafického prehliadača. V takomto modeli môžete zobraziť všetky detaily triedy v grafickej forme, ktorá je pre vývojárov zrozumiteľnejšia.

Modelovanie vyžaduje sofistikovanejšie nástroje ako skicovanie, pretože je potrebné zachovať detail, ktorý spĺňa požiadavky danej úlohy. Špecializované CASE nástroje (počítačom podporované softvérové ​​inžinierstvo) patria do tejto kategórie, hoci samotný pojem sa stal takmer špinavým slovom a predajcovia sa mu snažia vyhýbať. Nástroje priameho vývoja podporujú kreslenie diagramov a ich kopírovanie do úložiska za účelom ukladania informácií. Nástroje reverzného inžinierstva čítajú zdrojový kód, zapisujú jeho interpretáciu do úložiska a generujú diagramy. Nazývajú sa nástroje, ktoré umožňujú dopredné aj spätné inžinierstvo obojstranný (spiatočný).

Niektoré nástroje používajú zdrojový kód ako úložisko a diagramy ho používajú na grafické znázornenie. Takéto nástroje užšie súvisia s programovaním a často sú zabudované priamo do nástrojov na úpravu zdrojového kódu.

Hranica medzi modelmi a náčrtmi je dosť nejasná, ale rozdiely sú v tom, že náčrty sú zámerne neúplné, pričom zdôrazňujú dôležité informácie, zatiaľ čo modely sa snažia o úplnosť, často s cieľom zredukovať programovanie na jednoduché a do istej miery mechanické činnosti. To znamená, že náčrty môžu byť definované ako skúšobné prvky a modely ako konečné.

Čím dlhšie pracujete s UML a programovanie sa stáva mechanickejším, tým je potreba prejsť na automatizovanú tvorbu programov zrejmejšia. Mnohé CASE nástroje skutočne generujú kód tak či onak, čo vám umožňuje automatizovať konštrukciu významnej časti systému. Nakoniec sa dostanete do bodu, kedy môžete opísať celý systém pomocou UML a budete v režime UML. ako programovací jazyk . V takomto prostredí vývojári kreslia diagramy, ktoré sú kompilované priamo do spustiteľného kódu a UML sa stáva zdrojovým kódom. Je zrejmé, že takáto aplikácia UML vyžaduje obzvlášť sofistikované nástroje. (Taktiež zápisy dopredného a spätného inžinierstva strácajú zmysel, pretože UML a zdrojový kód sa stávajú jedným a tým istým.)

Jednou zo zaujímavých otázok týkajúcich sa UML ako programovacieho jazyka je otázka modelovania behaviorálnej logiky. UML 2 ponúka tri spôsoby modelovania správania: interakčné diagramy, stavové diagramy a diagramy aktivít. Všetky majú svojich priaznivcov v oblasti programovania.

Ďalší vývojársky pohľad na UML spadá niekde medzi jeho použitie na koncepčné modelovanie a jeho použitie na modelovanie softvéru. Väčšina vývojárov používa UML na modelovanie softvéru. S softvérového hľadiska Prvky UML sa mapujú takmer priamo na prvky softvérového systému. Ako uvidíme neskôr, mapovanie nemusí nutne znamenať dodržiavanie pokynov, ale keď používame UML, hovoríme o softvérových prvkoch.

S koncepčné hľadisko UML predstavuje popis doménových konceptov. Tu nehovoríme ani tak o softvérových prvkoch, ako skôr o vytvorení slovnej zásoby na diskusiu o konkrétnej oblasti.

Neexistujú žiadne prísne pravidlá pre výber uhla pohľadu. Keďže sa na problém dá pozerať z rôznych uhlov pohľadu, existuje niekoľko spôsobov, ako ho aplikovať. Niektoré nástroje automaticky konvertujú zdrojový kód na diagramy, pričom UML považujú za alternatívnu formu zdrojového kódu. Toto je do značnej miery programová perspektíva. Ak sa diagramy UML používajú na testovanie a pochopenie rôznych významov pojmov „skupina aktív“ so skupinou účtovníkov, potom by sa mal prijať oveľa bližší koncepčný pohľad.

Dôsledkom rôznych použití UML je, že existuje veľa diskusií o tom, čo znamenajú diagramy UML a ako súvisia so zvyškom sveta. To ovplyvňuje najmä vzťah medzi UML a zdrojovým kódom. Niektorí vývojári sa domnievajú, že UML by sa malo použiť na vytvorenie modelu, ktorý je nezávislý od programovacieho jazyka použitého na implementáciu projektu. Iní sú presvedčení, že jazykovo nezávislý model je oxymoron.

Ďalší rozdiel v názoroch sa týka otázky charakteru UML. Myslím si, že väčšina používateľov UML, najmä skicárov, vidí podstatu UML v jeho diagramoch. Autori UML však považujú diagramy za sekundárne a metamodel UML je považovaný za primárny. Diagramy sú len reprezentáciou metamodelu. Tento pohľad má zmysel aj pre vývojárov, ktorí používajú UML v režime návrhu a v režime programovacieho jazyka.

Zhrnutie: Boli identifikované 3 spôsoby použitia UML.

1 - režim náčrtu. Nakreslí sa náčrt buď budúceho kódu (potom budete musieť napísať kód založený na modeli), alebo existujúceho kódu (aby ste mu lepšie porozumeli). Cieľom je rýchla výmena informácií. Vlastnosť - selektivita. Úplnosť nie je dôležitá, dôležitý je samotný proces výmeny.

2 - režim dizajnu. Cieľom je úplnosť. Vypracuje sa detailný model, ktorý sa následne zrealizuje (a programátor nemusí nad implementáciou veľmi premýšľať, jeho práca sa zredukuje na jednoduché mechanické úkony). Môžete vymodelovať celé, alebo len časť.

3 - režim programovacieho jazyka. Grafické diagramy sú kompilované do kódu, UML sa stáva zdrojovým kódom.

Odpoveď z predchádzajúcich rokov (Den)

Jazyk Unified Modeling Language (UML) možno považovať za výsledok pomerne dlhého a ešte neukončeného vývoja metodológií modelovania a dizajnu.

Toto zjednotenie sledovalo tri hlavné ciele:

· modelovanie systému od konceptu až po spustiteľný modul pomocou objektovo orientovaných techník;

· riešenie problémov s mierkou v zložitých systémoch;

· vytvorenie modelovacieho jazyka používaného ľuďmi aj počítačmi.

Na čo sa používa UML?

UML je v prvom rade jazyk a ako každý jazykový nástroj poskytuje slovnú zásobu a pravidlá na kombinovanie slov v tejto slovnej zásobe. Tu sa slovná zásoba a pravidlá zameriavajú na koncepčné a fyzické reprezentácie systému. Jazyk diktuje, ako vytvoriť a čítať model, ale neposkytuje žiadne usmernenie o tom, aký systémový model vytvoriť - to je mimo rámca UML a je doménou procesu vývoja softvéru.

UML je vizualizačný jazyk. Zápis modelov v UML má jeden jednoduchý cieľ – uľahčiť proces prenosu informácií o systéme. Každý symbol UML má presne definovanú sémantiku, čo vám umožňuje vyhnúť sa chybám pri interpretácii.

UML je jazyk špecifikácií a presných definícií. V tomto zmysle modelovanie UML znamená vytváranie modelov, ktoré sú presné, jednoznačné a úplné.

UML je dokumentačný jazyk.

UML diagramy

Vizualizácia návrhu systému z rôznych pohľadov v UML je realizovaná prostredníctvom diagramov – projekcií systému. Diagram je grafické znázornenie množiny prvkov, ktoré je znázornené ako súvislý graf s vrcholmi (entitami) a hranami (vzťahmi).

Nižšie sú uvedené definície grafov:

· Diagram triedy- štrukturálny diagram zobrazujúci mnohé triedy, rozhrania, spolupráce a vzťahy medzi nimi;

· Schéma objektu- štrukturálny diagram, ktorý zobrazuje veľa predmetov a vzťahy medzi nimi. Možno to považovať za špeciálny prípad diagramu tried. Modelovacie nástroje nemusia podporovať samostatný formát pre diagramy prvkov. Zobrazujú objekty, takže diagram tried, ktorý nemá triedy, ale má objekty, ktoré k nim patria, možno považovať za diagram objektov;

· Schéma prípadu použitia- diagram správania, ktorý ukazuje mnohé precedensy a aktérov, ako aj vzťahy medzi nimi;

· Interakčný diagram:

o Sekvenčný diagram- diagram správania, ktorý ukazuje interakciu a zvýrazňuje časový sled udalostí;

o Diagram spolupráce- diagram správania, ktorý ukazuje interakciu a zdôrazňuje štrukturálnu organizáciu objektov odosielajúcich a prijímajúcich správy;

· Stavový diagram- diagram správania, ktorý zobrazuje stroj a zvýrazňuje správanie objektov z hľadiska poradia, v ktorom sú udalosti prijaté;

· Diagram aktivity- diagram správania, ktorý zobrazuje stroj a zvýrazňuje prechody riadiaceho toku z jednej činnosti do druhej;

· Schéma komponentov- diagram, ktorý znázorňuje organizáciu určitého súboru komponentov a závislosti medzi nimi - vzťahuje sa na štatistický typ systému;

· diagram topológie systému (diagram nasadenia)- štruktúrny diagram zobrazujúci uzly a vzťahy medzi nimi.

Odpoveď z predchádzajúcich rokov (Madina)

možnosť 1

Metodológia objektovo orientovaného dizajnu v UML (UML diagramy)

Unified Modeling Language (UML) je jazyk na špecifikovanie, vizualizáciu, konštruovanie a dokumentovanie rôznych typov systémov založených na objektovo orientovanom prístupe: softvér, hardvér, softvér-hardvér, zmiešané, výslovne zahŕňajúce ľudské aktivity atď.

Jazyk UML sa okrem iného používa na návrh relačných databáz. Na tento účel sa používa malá časť jazyka (diagramy tried), a to aj vtedy nie úplne. Z hľadiska navrhovania relačných databáz sa možnosti modelu príliš nelíšia od možností ER diagramov

Diagram triedy v terminológii UML sa nazýva diagram, ktorý zobrazuje množinu tried (a niektoré ďalšie entity), ktoré nesúvisia výslovne s návrhom databázy), ako aj vzťahy medzi týmito triedami. Obmedzenia môžu byť neformálne špecifikované v prirodzenom jazyku alebo formulované v OCL (Object Constraints Language).

Trieda sa volá pomenovaný popis kolekcie objektov so spoločnými atribútmi, operáciami, vzťahmi a sémantikou. Graficky je trieda znázornená ako obdĺžnik. Názov (textový reťazec) používaný na identifikáciu triedy.

Atribút triedy je pomenovaná vlastnosť triedy, ktorá popisuje množinu hodnôt, ktoré môžu mať inštancie tejto vlastnosti. Trieda môže mať ľubovoľný počet atribútov (najmä nemôže mať žiadny atribút).

Prevádzka triedy je pomenovaná služba, ktorú je možné vyžiadať z akéhokoľvek objektu tejto triedy. Operácia je abstrakcia toho, čo sa dá urobiť s objektom. Trieda môže obsahovať ľubovoľný počet operácií (najmä nesmie obsahovať žiadne operácie). Sada operácií triedy je spoločná pre všetky objekty tejto triedy.

Diagram tried môže zahŕňať tri rôzne kategórie vzťahov: závislosť, zovšeobecnenie a asociáciu.

Závislosť nazývaná aplikačná väzba, keď zmena v špecifikácii jednej triedy môže ovplyvniť správanie inej triedy, ktorá používa prvú triedu. Ak sa zmení rozhranie druhej triedy, ovplyvní to správanie objektov prvej triedy. Závislosť je znázornená ako bodkovaná čiara so šípkou smerujúcou k triede, na ktorej závislosť existuje.

Spojenie-zovšeobecnenie sa nazýva spojenie medzi spoločnou entitou tzv supertrieda, alebo rodič, a špecializovanejšia verzia tejto entity tzv podtrieda, alebo potomok. Zovšeobecnenia sa niekedy nazývajú spojenia "je", čo znamená, že trieda potomka je špeciálnym prípadom triedy predkov. Potomok trieda zdedí všetky atribúty a operácie triedy predkov, no možno v nej definovať ďalšie atribúty a operácie.

Vo väčšine prípadov, keď sa používa generický vzťah, postačuje jednoduché dedičstvo (keď každá podtrieda má iba jednu nadtriedu). UML však umožňuje aj viacnásobné dedenie, keď je jedna podtrieda definovaná na základe niekoľkých nadtried.

V tomto diagrame sú triedy Študent A Výskumník odvodené z rovnakej nadtriedy Muž z univerzity. Do triedy Študent odkazovať na tieto objekty triedy Muž z univerzity, ktoré zodpovedajú žiakom a triede Výskumník- predmety triedy Muž z univerzity, čo zodpovedá výskumníkom. Často sa stáva, že mnohí študenti sa už počas študentských rokov začínajú podieľať na výskumných projektoch, takže môžu existovať také dva triedne objekty Študent A Výskumník, ktoré zodpovedajú jednému objektu triedy Muž z univerzity. Teda medzi objekty triedy Študent môžu byť výskumníci a niektorí výskumníci môžu byť študenti. Potom môžeme definovať triedu Študent Výskumník prostredníctvom viacnásobného dedenia zo supertried Študent A Výskumník. Objekt triedy Študent Výskumník má všetky vlastnosti a operácie tried Študent A Výskumník a dá sa použiť všade tam, kde sa dajú použiť objekty týchto tried. Polymorfizmus inklúzie teda naďalej funguje. To však so sebou nesie množstvo problémov. Napríklad pri vytváraní podtried Študent A Výskumník oba môžu mať definovaný atribút IP_adresa počítača. Pre objekty triedy Študent hodnoty tohto atribútu budú IP adresa počítača triedy terminálu a pre objekty triedy Výskumník- IP adresa počítača výskumného laboratória. Navyše pre objekt triedy Študent Výskumník Oba atribúty s rovnakým názvom môžu byť významné (študent výskumu môže mať IP adresu počítača terminálovej triedy aj IP adresu počítača výskumného laboratória). V praxi sa používa jedno z nasledujúcich riešení:

• zakázať vytváranie podtriedy Študent Výskumník kým sa atribút nepremenuje v jednej z nadtried IP_adresa počítača;
• dediť túto vlastnosť len z jednej z nadtried, takže napríklad hodnota atribútu IP_adresa počítača pre objekty triedy Študent Výskumník bude vždy IP adresa počítača výskumného laboratória;
• Zdediť obe vlastnosti v podtriede, ale automaticky premenovať oba atribúty, aby sa objasnil ich význam; vymenuj ich napr. IP_adresa študentského počítača A IP_adresa počítača výskumníka.

Každé z týchto riešení má nevýhody, takže pri používaní UML na návrh relačných databáz musíte byť veľmi opatrní pri používaní dedenia tried vo všeobecnosti a snažiť sa vyhnúť viacnásobnému dedeniu.

asociácie nazývaný štrukturálny vzťah, ktorý ukazuje, že objekty jednej triedy nejakým spôsobom súvisia s objektmi inej alebo tej istej triedy. Je povolené, aby oba konce združenia patrili do rovnakej triedy. Asociácia môže zahŕňať dve triedy a potom sa nazýva binárna. Je možné vytvárať asociácie, ktoré spájajú n tried naraz (nazývajú sa n-árne asociácie) 1) Graficky je asociácia znázornená ako čiara spájajúca triedu so sebou samým alebo s inými triedami.

S konceptom asociácie sú spojené štyri dôležité dodatočné pojmy: meno, rola, multiplicita a agregácia. Asociácii možno dať názov, ktorý charakterizuje povahu vzťahu. Ďalším spôsobom, ako pomenovať asociáciu, je uviesť rolu každej triedy zúčastňujúcej sa asociácie. Rola triedy, podobne ako názov konca spojenia v modeli ER, je určená názvom umiestneným pod asociačným riadkom bližšie k danej triede.

Vo všeobecnosti môže mať asociácia svoj vlastný názov aj názvy triednych rolí. Je to preto, že trieda môže hrať rovnakú úlohu v rôznych asociáciách, takže vo všeobecnosti dvojica názvov rolí triedy neidentifikuje asociáciu. V jednoduchých prípadoch, kde je definovaná iba jedna asociácia medzi dvoma triedami, je možné k nej vôbec nepriraďovať ďalšie mená.

MnohonásobnosťÚloha asociácie je charakteristika, ktorá udáva, koľko objektov triedy s danou rolou sa môže alebo musí zúčastniť na každej inštancii asociácie.

Najbežnejším spôsobom, ako určiť početnosť pridruženej role, je zadať konkrétne číslo alebo rozsah. "1" označuje, že každý objekt triedy s danou rolou sa musí zúčastniť na niektorej inštancii tohto priradenia a iba jeden objekt triedy s danou rolou sa môže zúčastniť každej inštancie priradenia. Zadanie rozsahu "0..1" znamená, že nie všetky objekty triedy s danou rolou sa musia zúčastňovať na akejkoľvek inštancii daného priradenia, ale iba jeden objekt sa môže zúčastniť na každej inštancii priradenia. Podobne, zadanie rozsahu "1..*" znamená, že všetky objekty triedy s danou rolou sa musia zúčastniť na niektorej inštancii tohto priradenia a aspoň jeden objekt sa musí zúčastniť každej inštancie priradenia (nie je určená horná hranica ). V zložitejších prípadoch určovania násobnosti možno použiť zoznamy rozsahov.

Obvyklá asociácia medzi dvoma triedami charakterizuje vzťah medzi rovnakými entitami: obe triedy sú na rovnakej koncepčnej úrovni. Niekedy však musí diagram tried odrážať skutočnosť, že spojenie medzi dvoma triedami má špeciálnu formu časť-celok. V tomto prípade má trieda „celok“ vyššiu koncepčnú úroveň ako trieda „časť“. Združenie tohto druhu sa nazýva agregát.

V každej triede terminálov musia byť nainštalované počítače. Preto trieda Počítač je „súčasťou“ triedy TerminalClass. Úloha triedy Počítač je voliteľné, pretože v princípe môžu terminálové triedy existovať bez počítačov. Navyše, aj keď triedy terminálov, ktoré nie sú vybavené počítačmi, neplnia svoju funkciu, objekty triedy TerminalClass A Počítač existovať nezávisle.

Existujú prípady, keď je spojenie medzi „časťou“ a „celkom“ také silné, že zničenie „celku“ vedie k zničeniu všetkých jeho „častí“. Súhrnné asociácie s touto vlastnosťou sú tzv zložený alebo len kompozície.

Akákoľvek fakulta je súčasťou jednej univerzity a likvidáciou vysokej školy dochádza k likvidácii všetkých existujúcich fakúlt na nej, hoci počas existencie univerzity môžu byť jednotlivé fakulty likvidované a vznikajú.

Diagramy tried môžu špecifikovať obmedzenia integrity, ktoré musia byť podporované v navrhnutej databáze. UML umožňuje dva spôsoby definovania obmedzení: v prirodzenom jazyku a v OCL (Object Constraints Language).

Z hľadiska definovania obmedzení integrity databázy sú dôležitejšie prostriedky na definovanie invariantov tried.

Pod nemenný triedy v OCL sa chápe ako podmienka, ktorú musia spĺňať všetky objekty danej triedy. Presnejšie povedané, invariant triedy je logický výraz, ktorého vyhodnotenie musí dať pravdivosť, keď sa vytvorí akýkoľvek objekt danej triedy a zachovať skutočnú hodnotu počas celej existencie tohto objektu. Pri definovaní invariantu musíte zadať názov triedy a výraz, ktorý definuje invariant zadanej triedy. Syntakticky to vyzerá takto:

Nižšie sú uvedené príklady invariantov na špecifikovanie obmedzení v OCL.

1. Vyjadrite v OCL obmedzenie, podľa ktorého zamestnanci starší ako 30 rokov musia pracovať na oddeleniach s počtom väčším ako 5

2. Definujte obmedzenie, že každé oddelenie musí mať manažéra a žiadne oddelenie nesmie byť založené pred príslušnou spoločnosťou

3. Podmienka štvrtého invariantu obmedzuje maximálny možný počet zamestnancov spoločnosti na 1000

Možnosť 2

1. Model RUP. Základné schémy modelu RUP.

Rational Unified Process (RUP) je jednou zo špirálových metodík vývoja softvéru. Metodika je podporovaná spoločnosťou Rational Software a produkt sa aktualizuje približne dvakrát ročne. Unified Modeling Language (UML) sa používa ako modelovací jazyk vo všeobecnej znalostnej báze.

Iteračný vývoj softvéru v RUP zahŕňa rozdelenie projektu na niekoľko malých projektov, ktoré sa vykonávajú postupne, pričom každá iterácia vývoja je jasne definovaná súborom cieľov, ktoré sa musia dosiahnuť na konci iterácie. Finálna iterácia predpokladá, že množina cieľov iterácie sa musí presne zhodovať so množinou cieľov špecifikovaných zákazníkom produktu, to znamená, že musia byť splnené všetky požiadavky. RUP poskytuje štruktúrovaný prístup k iteratívnemu vývoju softvéru, ktorý rozdeľuje proces na štyri míľniky v priebehu času: Začiatok, Vypracovanie, Konštrukcia a Prechod. RUP odporúča dodržiavať šesť postupov na úspešný rozvoj projektu:

Iteračný vývoj;

Riadenie požiadaviek;

Použitie modulárnych architektúr;

Vizuálne modelovanie;

Kontrola kvality;

Sledovanie zmien.

Grafické znázornenia modelov systémov v UML sú tzv diagramy. Z hľadiska jazyka UML sú definované tieto typy:

· prípad použitia alebo diagram prípadu použitia(diagram prípadu použitia)

· diagram tried(diagram triedy)

· grafy správania(diagramy správania)

· stavový diagram(stavový diagram)

· diagram činnosti(diagram aktivity)

· interakčné diagramy(interakčné diagramy)

· sekvenčný diagram(sekvenčný diagram)

· diagram spolupráce(diagram spolupráce)

· implementačné diagramy(implementačné diagramy)

· diagram komponentov(schéma komponentov)

· diagram nasadenia(diagram nasadenia)

Každý z týchto diagramov špecifikuje iný pohľad na model systému. Diagram prípadov použitia zároveň predstavuje konceptuálny model systému, ktorý je východiskom pre konštrukciu všetkých ostatných diagramov. Diagram tried je logický model, ktorý odráža statické aspekty štrukturálneho návrhu systému a diagramy správania, ktoré sú tiež typmi logického modelu, odrážajú dynamické aspekty jeho fungovania. Implementačné diagramy slúžia na znázornenie komponentov systému a odkazujú na jeho fyzický model.

Z vyššie uvedených diagramov niektoré slúžia na označenie dvoch alebo viacerých poddruhov. Nasledujúce diagramy sa používajú ako nezávislé znázornenia: prípady použitia, triedy, štátov, činnosti, sekvencie, spolupráce, komponentov A nasadenie.

Pre UML diagramy existujú tri typy vizuálnych symbolov, ktoré sú dôležité z hľadiska informácií, ktoré obsahujú:

· komunikácie, ktoré sú v rovine znázornené rôznymi čiarami;

· text, obsiahnuté v hraniciach jednotlivých geometrických útvarov;

· grafické symboly, zobrazené v blízkosti vizuálnych prvkov diagramov.

· každý diagram musí byť úplnou reprezentáciou nejakého fragmentu modelovanej predmetnej oblasti;

· modelové entity prezentované na diagrame musia mať rovnakú koncepčnú úroveň;

· všetky informácie o subjektoch musia byť jasne uvedené na diagrame;

· diagramy by nemali obsahovať protichodné informácie;

· diagramy by nemali byť preplnené textovými informáciami;

· každý diagram musí byť sebestačný na správnu interpretáciu všetkých jeho prvkov;

· počet typov diagramov potrebných na popis konkrétneho systému nie je presne stanovený a určuje ho vývojár;

Systémové modely by mali obsahovať iba tie prvky, ktoré sú definované

22. Dizajn integrovaného obvodu [J]

Tonyho pripravená odpoveď

Odpovede Denisa Kovalevicha boli aktualizované

Fáza implementácie

Jednou z hlavných príčin neúspešných implementácií je slabý vývoj projektu IS v štádiu manažérskeho poradenstva. V dôsledku toho sa informačný systém ukazuje ako nedostatočne integrovaný do celkového systému riadenia spoločnosti.

· nedostatok podpory zo strany kľúčových zamestnancov, najmä ak je potrebné venovať kritickým fázam dostatok času a energie;

· príliš ambiciózne plány namiesto múdreho prístupu krok za krokom;

· nezískanie dostatočného poradenstva od odborníkov so skutočnými skúsenosťami s používaním podobných systémov v podobných podnikoch.

Fáza prevádzky

o každodenné používanie;

Dispozícia

Odpoveď z predchádzajúcich rokov (Madina)

Implementácia.

2.1. Vypracovanie technických projektov (TP).

konzultanti zhotoviteľa a IT špecialisti objednávateľa tvoria TP;

Zákazník schvaľuje TP.

Upresňuje sa rozsah prác, načasovanie a cena.

Materiály TP sa používajú pri plánovaní a dokumentovaní prác.

Zloženie TP:

štruktúra uložených údajov;

algoritmy;

použité systémové prostriedky, ich štruktúra a prepojenia;

používateľské rozhranie.

2.2. Plánovanie práce.

V súlade so schválenými predpismi

projektoví manažéri zhotoviteľa a objednávateľa vypracúvajú pracovné programy (WP);

objednávateľ a zhotoviteľ schvaľujú RP.

Pre členov pracovného tímu sú vypracované individuálne plány.

Zloženie RP:

zoznam prác: konfigurácia, testovanie, akceptácia (zoznam prác môže obsahovať technické špecifikácie a technické špecifikácie);

doba obratu;

zodpovedný za každú položku RP.

2.3. Vyplnenie základných referenčných kníh.

Vlastnosti javiska:

môže vyžadovať 1 až 18 mesiacov;

vyžaduje centralizáciu vstupov informácií;

je nevyhnutnou podmienkou pre fungovanie systému.

Spôsoby implementácie:

konverzia údajov;

manuálne zadávanie údajov užívateľmi (operátormi).

2.4. Nastavenie, testovanie, akceptácia.

Vlastnosti javiska:

najnáročnejšie a najzodpovednejšie;

výrazne závisí od predbežnej prípravy (predpisy, technické špecifikácie, technické špecifikácie, RP);

vyžaduje prísnu disciplínu zo strany umelca aj zo strany objednávateľa;

sprevádzané objavením sa ďalších úloh od zákazníka;

vyžaduje flexibilitu zo strany objednávateľa a dodávateľa pri prekonávaní konfliktných situácií.

2.5. Skúšobná prevádzka.

Vlastnosti javiska:

vyžaduje rýchlu a spoľahlivú reakciu výkonného umelca;

môže vyžadovať značné úsilie od zákazníka (dvojitá práca);

má významné trvanie (1-3 mesiace);

sprevádzané vytvorením konečného zoznamu pripomienok (návrhov), plánovaním a realizáciou záverečných prác na konfigurácii, testovaní a akceptácii.

2.6. Dokumentácia.

príprava pokynov pre používateľov;

vypracovanie predpisov pre interakciu oddelení v rámci systému;

finalizácia technickej dokumentácie;

tvorba ďalších (vopred dohodnutých) dokumentov.

2.7. Dokončenie projektu.

právne uzatváranie zmluvných vzťahov;

konečné finančné vysporiadanie;

rozhodovanie o ďalšej spolupráci: uzatváranie zmlúv o technickej podpore a pozáručnej podpore, realizácia nových projektov.

IP recyklácia– vykoná sa tlačidlom DELETE.

Odpoveď z predchádzajúcich rokov (Den)

Fáza implementácie

Fáza vývoja a implementácie je zvyčajne vždy dokončená v plnom rozsahu. Nebrzdí ju slabý rozvoj technológií, nedostatočná kompetentnosť personálu či používateľov, ani nedostatok dobrých konzultantov.

Ak sa v tejto fáze vyskytnú problémy, sú spojené s týmito tromi hlavnými dôvodmi:

nedostatok podpory zo strany kľúčových zamestnancov, najmä ak sa kritickým fázam musí venovať dostatok času a energie;

príliš ambiciózne plány namiesto múdreho prístupu krok za krokom;

neschopnosť získať dostatok rád od odborníkov so skutočnými skúsenosťami s používaním podobných systémov v podobných podnikoch.

Fáza prevádzky

· Uvedenie informačného systému do prevádzky

o uvádzanie technických zariadení do skúšobnej prevádzky;

o uvedenie softvéru do skúšobnej prevádzky;

o školenie a certifikácia personálu;

o vykonávanie skúšobnej prevádzky komponentov a systému ako celku;

o uvedenie do prevádzky a podpisovanie potvrdení o prevzatí prác.

· Prevádzka informačného systému

o každodenné používanie;

o podpora softvéru, hardvéru a celého projektu.

Fáza podpory (údržby).

Služby technickej podpory zohrávajú veľmi významnú úlohu v živote každého podnikového informačného systému. Prítomnosť kvalifikovanej technickej služby v štádiu prevádzky informačného systému je nevyhnutnou podmienkou riešenia úloh, ktoré sú jej zverené, a chyby personálu údržby môžu viesť k zjavným alebo skrytým finančným stratám porovnateľným s nákladmi na samotný informačný systém.

Hlavné predbežné opatrenia pri príprave organizácie údržby informačného systému sú:

· identifikovať najkritickejšie komponenty systému a určiť pre ne kritickosť prestojov (umožní to identifikovať najkritickejšie komponenty informačného systému a optimalizovať alokáciu zdrojov na údržbu);

· identifikácia úloh údržby a ich rozdelenie na interné, riešené servisným úsekom a externé, riešené špecializovanými servisnými organizáciami (čím sa jasne definuje okruh vykonávaných funkcií a rozdelenie zodpovedností);

· analýza dostupných interných a externých zdrojov potrebných na organizáciu údržby v rámci popísaných úloh a rozdelenia kompetencií (hlavné kritériá analýzy: dostupnosť záruky na zariadenie, stav fondu opráv, kvalifikácia personálu);

· príprava plánu organizácie údržby, v ktorom je potrebné určiť etapy činností, ktoré sa majú vykonať, načasovanie ich vykonania, náklady na etapy a zodpovednosť vykonávateľov.

Zabezpečenie kvalitnej technickej údržby informačného systému si vyžaduje zapojenie vysokokvalifikovaných odborníkov, ktorí sú schopní riešiť nielen každodenné administratívne úkony, ale aj rýchlu obnovu systému v prípade porúch.

Dispozícia

Likvidácia produktu s premenou jeho zložiek na druhotné suroviny (v súlade s environmentálnymi požiadavkami) spojená s vylúčením všetkých informácií súvisiacich s likvidovaným produktom z informačného systému.

Táto téma je podrobne spracovaná na http://www.piter.com/attachment.php?barcode=978546900641&at=exc&n=0 a na http://www.rus-lib.ru/book/38/men/21 /2.3 .html

23. Dizajn integrovaného obvodu [J]

Súvisiace informácie.

definícia podobná tej nižšie.

Jazyk- systém znakov, ktorý slúži:

• prostriedok ľudskej komunikácie a duševnej činnosti;
• spôsob vyjadrenia sebauvedomenia človeka;
• prostriedok na ukladanie a prenos informácií.

Jazyk zahŕňa súbor znakov (slovná zásoba) a pravidlá ich používania a interpretácie (gramatika).

K tejto pomerne komplexnej definícii musíme dodať, že jazyky môžu byť prirodzené a umelé, formálne a neformálne. UML je formálny a umelý jazyk, aj keď, ako uvidíme neskôr, toto označenie mu celkom nesedí. Je umelý, pretože má autorov, ktorých v budúcnosti ešte viackrát spomenieme (zároveň vývoj UML kontinuálne pokračuje, čím sa vyrovná prirodzeným jazykom). Možno ho nazvať formálnym, pretože existujú pravidlá na jeho použitie (popis UML však obsahuje aj jednoznačne neformálne prvky, ako opäť uvidíme neskôr). Ešte jedna nuansa: UML je grafický jazyk, čo tiež trochu zamotáva situáciu!

Pri popise formálneho umelého jazyka, ktorý sme už videli v príkladoch popisovania programovacích jazykov, sú spravidla také prvky opísané ako:

1. syntax, teda určovanie pravidiel konštrukcie jazykových konštruktov;
2. sémantika, teda definovanie pravidiel, v súlade s ktorými jazykové štruktúry nadobúdajú sémantický význam;
3. pragmatika, teda určenie pravidiel používania jazykových konštruktov na dosiahnutie cieľov, ktoré potrebujeme.

Okrem toho približne v rovnakom čase (začiatkom 80. rokov) začala „objektovo orientovaná éra“. Všetko to začalo príchodom rodiny programovacích jazykov SmallTalk, ktorá aplikovala niektoré koncepty jazyka Simula-67 používaného v 60. rokoch. Vznik objektovo orientovaného prístupu bol primárne spôsobený narastajúcou zložitosťou problémov. Objektovo orientovaný prístup urobil pomerne radikálne zmeny v samotných princípoch tvorby a fungovania programov, ale zároveň umožnil výrazne zvýšiť výkon prácu programátorov, inak sa pozrieť na problémy a spôsoby ich riešenia, urobiť programy kompaktnejšími a ľahko rozšíriteľnými. V dôsledku toho jazyky, ktoré boli pôvodne orientované na tradičný prístup k programovaniu, dostali množstvo objektovo orientovaných rozšírení. Jedným z prvých, v polovici 80. rokov, bol Apple so svojím projektom Object Pascal. okrem toho objektovo orientovaný prístup vygeneroval silnú vlnu úplne nových softvérových technológií, ktorých vrcholom boli také všeobecne uznávané platformy ako Microsoft. NET Framework a Sun Java.

Najdôležitejšie však je, že vznik OOP si vyžadoval pohodlný nástroj na modelovanie, jednotnú notáciu na popis zložitých softvérových systémov. A tak sa „traja kamaráti“, traja hlavní špecialisti, traja autori najpopulárnejších metód, rozhodli spojiť svoj vývoj. V roku 1991 každý z „troch priateľov“ začal napísaním knihy, v ktorej načrtol svoju metódu OOAP. Každá metodika bola

UML je jednotný grafický modelovací jazyk na popis, vizualizáciu, navrhovanie a dokumentovanie OO systémov. UML je navrhnuté tak, aby podporovalo proces modelovania softvéru založeného na prístupe OO, organizovalo vzťah koncepčných a programových konceptov a odrážalo problémy škálovania zložitých systémov. Modely UML sa používajú vo všetkých fázach životného cyklu softvéru, od obchodnej analýzy až po údržbu systému. Rôzne organizácie môžu používať UML, ako uznajú za vhodné, v závislosti od ich problémových oblastí a technológií, ktoré používajú.

Stručná história UML

Do polovice 90. rokov navrhli rôzni autori niekoľko desiatok metód OO modelovania, z ktorých každá používala svoj vlastný grafický zápis. Každá z týchto metód mala zároveň svoje silné stránky, ale neumožňovala vybudovať dostatočne úplný model PS, ktorý by ho ukazoval „zo všetkých strán“, teda všetky potrebné projekcie (pozri článok 1). Okrem toho nedostatok štandardu modelovania OO sťažoval vývojárom výber najvhodnejšej metódy, čo bránilo širokému prijatiu prístupu OO k vývoju softvéru.

Na žiadosť Object Management Group (OMG), organizácie zodpovednej za prijímanie štandardov v oblasti objektových technológií a databáz, naliehavý problém zjednotenia a štandardizácie vyriešili autori troch najpopulárnejších metód OO - G Butch, D. Rambo a A. Jacobson, ktorí spoločnými silami vytvorili verziu UML 1.1, schválenú OMG v roku 1997 ako štandard.

UML je jazyk

Akýkoľvek jazyk pozostáva zo slovnej zásoby a pravidiel spájania slov, aby sa vytvorili zmysluplné konštrukcie. Takto sú štruktúrované najmä programovacie jazyky, ako napríklad UML. Jeho charakteristickým znakom je, že jazykový slovník tvoria grafické prvky. Každý grafický symbol má priradenú špecifickú sémantiku, takže model vytvorený jedným vývojárom môže byť jasne pochopený iným, ako aj softvérovým nástrojom, ktorý interpretuje UML. Z tohto konkrétne vyplýva, že softvérový model prezentovaný v UML možno automaticky preložiť do programovacieho jazyka OO (ako je Java, C++, VisualBasic), teda ak existuje dobrý nástroj na vizuálne modelovanie, ktorý podporuje UML, postavili model, dostaneme aj vzorový programový kód zodpovedajúci tomuto modelu.

Treba zdôrazniť, že UML je jazyk, nie metóda. Vysvetľuje, z akých prvkov vytvárať modely a ako ich čítať, ale nehovorí nič o tom, ktoré modely by sa mali vyvíjať a v akých prípadoch. Pre vytvorenie metódy založenej na UML je potrebné doplniť ju o popis procesu vývoja softvéru. Príkladom takéhoto procesu je Rational Unified Process, o ktorom sa bude diskutovať v nasledujúcich článkoch.

Slovník UML

Model je znázornený vo forme entít a vzťahov medzi nimi, ktoré sú znázornené v diagramoch.

entity sú abstrakcie, ktoré sú hlavnými prvkami modelov. Existujú štyri typy entít – štrukturálne (trieda, rozhranie, komponent, prípad použitia, spolupráca, uzol), behaviorálne (interakcia, stav), zoskupovanie (balíky) a anotácia (komentáre). Každý typ entity má svoje vlastné grafické znázornenie. Entity budú podrobne prediskutované pri štúdiu diagramov.

Vzťah ukazujú rôzne prepojenia medzi entitami. UML definuje nasledujúce typy vzťahov:

• Závislosť ukazuje také prepojenie dvoch entít, keď zmena jednej z nich – nezávislej – môže ovplyvniť sémantiku druhej – závislej. Závislosť je znázornená bodkovanou šípkou smerujúcou zo závislej entity na nezávislú entitu.
• asociácie je štrukturálny vzťah ukazujúci, že objekty jednej entity súvisia s objektmi inej entity. Graficky je asociácia znázornená ako čiara spájajúca pridružené entity. Asociácie slúžia na navigáciu medzi objektmi. Napríklad spojenie medzi triedami „Objednávka“ a „Produkt“ môže byť použité na nájdenie všetkých produktov špecifikovaných v konkrétnej objednávke na jednej strane alebo na nájdenie všetkých objednávok, ktoré obsahujú tento produkt, na strane druhej. Je jasné, že príslušné programy musia implementovať mechanizmus, ktorý takúto navigáciu zabezpečí. Ak je potrebná navigácia iba jedným smerom, je to označené šípkou na konci priradenia. Špeciálnym prípadom asociácie je agregácia – vzťah tvaru „celok“ – „časť“. Graficky je zvýraznený diamantom na konci blízko esencie-celku.
• Zovšeobecnenie je vzťah medzi nadradenou entitou a podriadenou entitou. Tento vzťah v podstate odráža vlastnosť dedičnosti pre triedy a objekty. Zovšeobecnenie je znázornené ako čiara končiaca trojuholníkom smerujúcim k rodičovskej entite. Dieťa zdedí štruktúru (atribúty) a správanie (metódy) rodiča, no zároveň môže mať nové prvky štruktúry a nové metódy. UML umožňuje viacnásobné dedičstvo, keď entita súvisí s viac ako jednou nadradenou entitou.
• Implementácia– vzťah medzi entitou, ktorá definuje špecifikáciu správania (interface) s entitou, ktorá definuje implementáciu tohto správania (trieda, komponent). Tento vzťah sa bežne používa pri modelovaní komponentov a bude podrobnejšie popísaný v nasledujúcich článkoch.

Diagramy. UML poskytuje nasledujúce diagramy:

• Diagramy popisujúce správanie systému:
• Stavové diagramy
• diagramy aktivít,
• Diagramy objektov,
• sekvenčné diagramy,
• Diagramy spolupráce;
• Diagramy popisujúce fyzickú implementáciu systému:
• Schémy komponentov;
• Schémy nasadenia.

Zobrazenie ovládania modelu. Balíčky.

Už sme povedali, že na to, aby bol model pre ľudí dobre pochopený, je potrebné ho hierarchicky usporiadať, pričom na každej úrovni hierarchie zostane malý počet entít. UML obsahuje prostriedky na organizáciu hierarchickej reprezentácie modelu – balíkov. Každý model pozostáva zo sady balíkov, ktoré môžu obsahovať triedy, prípady použitia a iné entity a diagramy. Balík môže obsahovať ďalšie balíky, čo umožňuje vytváranie hierarchií. UML neposkytuje samostatné diagramy balíkov, ale môžu sa objaviť v iných diagramoch. Balíček je vyobrazený ako obdĺžnik so záložkou.

Čo poskytuje UML.

• hierarchický popis komplexného systému identifikáciou balíkov;
• formalizácia funkčných požiadaviek na systém pomocou aparátu prípadov použitia;
• spresnenie systémových požiadaviek vytvorením diagramov činností a scenárov;
• identifikácia dátových tried a zostavenie koncepčného dátového modelu vo forme diagramov tried;
• identifikácia tried, ktoré popisujú používateľské rozhranie a vytvorenie schémy navigácie na obrazovke;
• opis procesov interakcie objektov pri vykonávaní systémových funkcií;
• popis správania sa objektu vo forme diagramov aktivít a stavov;
• popis softvérových komponentov a ich interakcia prostredníctvom rozhraní;
• popis fyzickej architektúry systému.

A posledná vec...

Napriek všetkej atraktivite UML by bolo ťažké ho použiť v reálnom softvérovom modelovaní bez nástrojov vizuálneho modelovania. Takéto nástroje vám umožňujú rýchlo prezentovať diagramy na obrazovke, dokumentovať ich, vytvárať šablóny programového kódu v rôznych programovacích jazykoch OO a vytvárať databázové schémy. Väčšina z nich zahŕňa možnosť reengineeringu programových kódov - obnovenie určitých projekcií softvérového modelu automatickou analýzou zdrojových kódov programov, čo je veľmi dôležité pre zabezpečenie súladu medzi modelom a kódmi a pri navrhovaní systémov, ktoré dedia funkčnosť predchádzajúcich systémov.

Unified Modeling Language (UML) je štandardný nástroj na vytváranie „plánov“ informačných systémov (IS). Pomocou UML môžete vizualizovať, špecifikovať, navrhovať a dokumentovať prvky týchto systémov.

UML je vhodné na modelovanie akéhokoľvek systému: od podnikových informačných systémov až po distribuované webové aplikácie a dokonca aj vstavané systémy v reálnom čase. Je to veľmi expresívny jazyk, ktorý vám umožňuje nazerať na systém zo všetkých hľadísk relevantných pre jeho vývoj a následné nasadenie. Napriek množstvu výrazových možností je tento jazyk ľahko zrozumiteľný a použiteľný. Najlepším miestom na začatie výučby UML je jeho koncepčný model, ktorý obsahuje tri základné prvky: základné stavebné bloky, pravidlá, ktoré definujú, ako možno tieto bloky kombinovať, a niektoré zo všeobecných mechanizmov jazyka.

UML je jednou zo súčastí procesu vývoja IS. Aj keď je UML nezávislé od modelovanej reality, najlepšie sa používa, keď je proces modelovania založený na zvažovaní prípadov použitia, je iteratívny a prírastkový a samotný systém má jasne definovanú architektúru.

UML je jazyk na vizualizáciu, špecifikáciu, konštrukciu a dokumentáciu prvkov softvérových systémov. Jazyk sa skladá zo slovníka a pravidiel, ktoré vám umožňujú kombinovať slová, ktoré obsahuje, a vytvárať zmysluplné konštrukcie. V modelovacom jazyku sa slovná zásoba a pravidlá zameriavajú na koncepčnú a fyzickú reprezentáciu systému. Modelovací jazyk ako UML je štandardným nástrojom na zostavovanie „návrhov“ IC.

Pri vytváraní IS akejkoľvek zložitosti sa vykonáva modelovanie budúceho systému, ale v mnohých prípadoch sa to robí neformálne, bez vypracovania akéhokoľvek dokumentu. Tento prístup je však plný problémov. Po prvé, výmena názorov na koncepčný model je možná len vtedy, keď všetci účastníci diskusie hovoria rovnakým jazykom. Po druhé, nie je možné získať prehľad o určitých aspektoch informačných systémov bez modelu, ktorý presahuje hranice textového programovacieho jazyka. Po tretie, ak autor kódu nikdy výslovne neimplementoval modely, ktoré zamýšľal, tieto informácie budú navždy stratené, ak zmení zamestnanie. V najlepšom prípade sa dá na základe implementácie iba čiastočne obnoviť.

Použitie UML rieši tretí problém: explicitný model uľahčuje komunikáciu.

Niektoré funkcie systému je najlepšie modelovať textovo, iné graficky. V skutočnosti vo všetkých zaujímavých systémoch existujú štruktúry, ktoré nemožno reprezentovať iba pomocou programovacieho jazyka. UML je grafický jazyk, ktorý nám umožňuje riešiť druhý z identifikovaných problémov.

UML je viac než len súbor grafických symbolov. Za každým z nich je dobre definovaná sémantika. To znamená, že model napísaný jedným vývojárom môže byť jednoznačne interpretovaný iným – alebo dokonca programom nástroja. Toto rieši prvý z vyššie uvedených problémov.

V tomto kontexte špecifikácia znamená stavať presné, jednoznačné a úplné modely. UML vám umožňuje špecifikovať všetky dôležité rozhodnutia o analýze, návrhu a implementácii, ktoré je potrebné urobiť počas vývoja a nasadenia informačného systému.

UML je jazyk vizuálneho dizajnu a modely vytvorené pomocou neho možno priamo preložiť do rôznych programovacích jazykov IS.

Pri vývoji IS sa berú do úvahy prvky ako:

• Požiadavky na systém;
• popis architektúry;
• projekt;
• zdroj;
• projektové plány;
• testy;
• prototypy;
• verzie atď.

V závislosti od prijatej metodiky vývoja sa niektoré práce vykonávajú formálnejšie ako iné. Uvedené položky nie sú len dodávanými súčasťami projektu; sú potrebné pre riadenie, pre vyhodnocovanie výsledku a tiež ako prostriedok komunikácie medzi členmi tímu pri vývoji systému a po jeho nasadení.

UML rieši problém dokumentácie architektúry systému a všetkých jeho detailov, poskytuje jazyk na formulovanie systémových požiadaviek a definovanie testov a napokon poskytuje nástroje na modelovanie práce počas fáz plánovania projektu a riadenia verzií.

Kde sa používa UML

Jazyk UML je určený predovšetkým pre vývoj informačných systémov. Jeho použitie je obzvlášť účinné v nasledujúcich oblastiach:

• podnikové informačné systémy;
• bankové a finančné služby;
• telekomunikácie;
• doprava;
• obranný priemysel, letectvo a astronautika;
• maloobchod;
• lekárska elektronika;
• veda;
• distribuované webové systémy.

Rozsah UML nie je obmedzený na softvérové ​​modelovanie. Jeho expresivita umožňuje modelovať povedzme tok dokumentov v právnych systémoch, štruktúru a fungovanie systému služieb pacientom v nemocniciach a navrhovať hardvér.

Koncepčný model UML

Aby ste pochopili UML, musíte pochopiť jeho konceptuálny model, ktorý zahŕňa tri komponenty: základné stavebné kamene jazyka, pravidlá ich kombinovania a niektoré mechanizmy spoločné pre celý jazyk. Po zvládnutí týchto prvkov budete môcť čítať modely UML a vytvárať ich sami - samozrejme, nie príliš zložité. Keď získate skúsenosti s jazykom, naučíte sa využívať jeho pokročilejšie možnosti.

Stavebné bloky UML

Slovník UML obsahuje tri typy stavebných blokov:

• esencie;
• vzťah;
• diagramy.

Entity sú abstrakcie, ktoré sú hlavnými prvkami modelu. Vzťahy spájajú rôzne entity; diagramy zoskupujú kolekcie objektov záujmu.

V UML existujú štyri typy entít:

• štrukturálne;
• behaviorálne;
• zoskupovanie;
• anotačný.

Entity sú základnými objektovo orientovanými blokmi jazyka. S ich pomocou môžete vytvoriť správne modely. Existuje sedem typov štrukturálnych entít:

• Trieda
• Rozhranie
• Spolupráca
• Prípad použitia
• Aktívna trieda
• Komponent
• Uzol

Týchto sedem základných prvkov – triedy, rozhrania, spolupráce, prípady použitia, aktívne triedy, komponenty a uzly – sú základnými štrukturálnymi entitami, ktoré môžu byť zahrnuté do modelu UML. Existujú aj rôzne druhy týchto entít: aktéri, signály, utility (typy tried), procesy a vlákna (typy aktívnych tried), aplikácie, dokumenty, súbory, knižnice, stránky a tabuľky (typy komponentov).

Behaviorálne veci sú dynamickými komponentmi modelu UML. Sú to slovesá jazyka: opisujú správanie modelu v čase a priestore. Existujú iba dva hlavné typy subjektov správania:

• Interakcia
• Štátny stroj

Tieto dva prvky interakcie a automaty sú hlavné entity správania zahrnuté v modeli UML. Sémanticky sú často spojené s rôznymi štrukturálnymi prvkami, predovšetkým triedami, kolaboráciami a objektmi.

Zoskupovacie entity sú organizačnými časťami modelu UML. Sú to bloky, na ktoré je možné model rozložiť. Existuje len jedna entita primárneho zoskupenia, a to plastový sáčok.

Balíky sú základné zoskupovacie entity, ktoré možno použiť na usporiadanie modelu UML.Existujú aj variácie balíkov, ako sú rámce, modely a podsystémy.

Entity anotácie— vysvetľujúce časti modelu UML. Toto sú komentáre, ktoré poskytujú dodatočný popis, objasnenie alebo komentár k akémukoľvek prvku modelu. Existuje len jeden základný typ prvku anotácie: Poznámka. Poznámka je jednoducho symbol reprezentujúci komentáre alebo obmedzenia pripojené k prvku alebo skupine prvkov. Graficky je poznámka znázornená ako obdĺžnik so zakriveným okrajom, ktorý obsahuje text alebo grafický komentár.

UML definuje štyri typy vzťahov:

• závislosť;
• združenie;
• zovšeobecňovanie;
• implementáciu.

Tieto vzťahy sú základnými spojovacími stavebnými kameňmi v UML a používajú sa na vytváranie platných modelov.
Štyri opísané prvky sú hlavné typy vzťahov, ktoré môžu byť zahrnuté v modeloch UML.Existujú aj variácie, ako napríklad Spresnenie, Sledovanie, Začlenenie a Rozšírenie (pre závislosti).

Diagram v UML je grafická reprezentácia množiny prvkov, najčastejšie zobrazovaná ako súvislý graf s vrcholmi (entitami) a hranami (vzťahmi). Diagramy sú nakreslené na vizualizáciu systému z rôznych perspektív. Diagram je v istom zmysle jednou z projekcií systému. Spravidla, s výnimkou najtriviálnejších prípadov, diagramy poskytujú zhustený pohľad na prvky, ktoré tvoria systém. Rovnaký prvok môže byť prítomný vo všetkých diagramoch alebo len v niekoľkých (najbežnejšia možnosť), alebo nie je prítomný v žiadnom (veľmi zriedkavé). Teoreticky môžu diagramy obsahovať akúkoľvek kombináciu entít a vzťahov. V praxi sa však používa pomerne malý počet štandardných kombinácií zodpovedajúcich piatim najbežnejším typom, ktoré tvoria architektúru informačného systému. V UML teda existuje deväť typov diagramov:

• diagramy tried;
• diagramy objektov;
• diagramy prípadov použitia;
• sekvenčné diagramy;
• diagramy spolupráce;
• stavové diagramy;
• diagramy aktivít;
• diagramy komponentov;
• diagramy nasadenia.

Tu je čiastočný zoznam diagramov používaných v UML. Nástroje umožňujú generovať ďalšie diagramy, no uvedených deväť je tých, ktoré v praxi vidíte najčastejšie.

Pravidlá jazyka UML

Stavebné bloky UML nie je možné navzájom ľubovoľne kombinovať. Ako každý iný jazyk, aj UML je charakteristický súborom pravidiel, ktoré definujú, ako má vyzerať dobre naformátovaný model, teda sémanticky sebestačný a v súlade so všetkými modelmi, ktoré sú s ním spojené.

Jazyk UML má sémantické pravidlá, ktoré vám umožňujú správne a jednoznačne definovať:

• mená, ktoré možno priradiť entitám, vzťahom a diagramom;
• rozsah(kontext, v ktorom má meno nejaký význam);
• viditeľnosť(keď sú mená viditeľné a môžu byť použité inými prvkami);
• bezúhonnosť(ako by mali prvky správne a dôsledne navzájom súvisieť);
• výkon(čo znamená spustiť alebo simulovať nejaký dynamický model).

Modely vytvorené počas vývoja informačných systémov sa časom vyvíjajú a rôzni účastníci projektu ich môžu v rôznych časoch vnímať rôzne. Z tohto dôvodu vznikajú nielen dobre navrhnuté modely, ale aj také, ktoré:

• obsahovať skryté prvky (niekoľko prvkov nie je znázornených na zjednodušenie vnímania);
• neúplné (chýbajú jednotlivé prvky);
• nekonzistentné (integrita modelu nie je zaručená).

Vzhľad nie príliš dobre navrhnutých modelov je nevyhnutný počas procesu vývoja, kým nie sú úplne objasnené všetky detaily systému. Pravidlá UML vás povzbudzujú, ale nevyžadujú, aby ste sa pri práci na svojom modeli zaoberali kritickými problémami analýzy, návrhu a implementácie, výsledkom čoho je časom dobre formulovaný model.

Všeobecné mechanizmy UML

Stavba je jednoduchšia a efektívnejšia, ak sa dodržia určité konvencie. Dodržiavaním určitých architektonických vzorov môžete navrhnúť budovu vo viktoriánskom alebo francúzskom štýle. Rovnaký princíp platí pre UML. Práca s týmto jazykom je značne uľahčená dôsledným používaním všeobecných mechanizmov uvedených nižšie:

• špecifikácie (Specifications);
• doplnky (ozdoby);
• spoločné delenia;
• Mechanizmy rozšíriteľnosti.

Architektúra

Pre vizualizáciu, špecifikáciu, konštrukciu a dokumentáciu informačných systémov je potrebné ich posudzovať z rôznych hľadísk. Každý, kto sa podieľa na projekte – koncoví používatelia, analytici, vývojári, systémoví integrátori, testeri, technickí autori a projektoví manažéri – majú svoje vlastné záujmy a každý sa na budovaný systém pozerá inak v rôznych obdobiach jeho života. Architektúra systému je snáď najdôležitejším prvkom, ktorý slúži na riadenie všetkých možných uhlov pohľadu a uľahčuje tak iteračný a inkrementálny vývoj systému počas jeho životného cyklu.

Architektúra je súbor dôležitých rozhodnutí týkajúcich sa:

• organizácia softvérového systému;
• výber konštrukčných prvkov, ktoré tvoria systém a ich rozhrania;
• správanie týchto prvkov špecifikované v spolupráci s inými prvkami;
• skladanie týchto štrukturálnych a behaviorálnych prvkov do väčších a väčších subsystémov;
• architektonický štýl, ktorý riadi a určuje celú organizáciu systému: statické a dynamické prvky, ich rozhrania, spoluprácu a spôsob ich kombinovania.

Architektúra softvérového systému pokrýva nielen všetky štrukturálne a behaviorálne aspekty, ale aj použitie, funkčnosť, výkon, flexibilitu, opätovnú použiteľnosť, úplnosť, ekonomické a technologické obmedzenia a kompromisy a estetické otázky.

Pohľad z pohľadu precedensov Zobrazenie prípadov použitia zahŕňa prípady použitia, ktoré opisujú správanie systému, ako ho pozorovali koncoví používatelia, analytici a testeri. Tento typ nešpecifikuje skutočnú organizáciu softvérového systému, ale tie hnacie sily, od ktorých závisí tvorba architektúry systému. V UML sú statické aspekty tohto typu prenášané pomocou diagramov prípadov použitia a dynamické aspekty prostredníctvom diagramov interakcií, stavov a akcií.

Dizajnový pohľad(Návrhové zobrazenie) pokrýva triedy, rozhrania a spolupráce, ktoré tvoria slovnú zásobu problému a jeho riešení. Tento pohľad podporuje predovšetkým funkčné požiadavky systému, teda služby, ktoré musí poskytovať koncovým používateľom. Pomocou UML možno statické aspekty tohto typu sprostredkovať pomocou diagramov tried a objektov a dynamické aspekty pomocou diagramov interakcií, stavov a akcií.

Procesný pohľad(Procesný pohľad) pokrýva vlákna a procesy, ktoré tvoria súbežné a synchronizačné mechanizmy v systéme. Tento pohľad popisuje najmä výkon, škálovateľnosť a priepustnosť systému. V UML sú jeho statické a dynamické aspekty vizualizované rovnakými diagramami ako pri pohľade na návrh, ale s osobitnou pozornosťou venovanou aktívnym triedam, ktoré predstavujú príslušné vlákna a procesy.

Pohľad na implementáciu Implementačný pohľad pokrýva komponenty a súbory použité na zostavenie a vydanie finálneho softvérového produktu. Toto zobrazenie je určené predovšetkým na správu konfigurácie verzií systému tvorených (do určitej miery) nezávislými komponentmi a súbormi, ktoré je možné navzájom kombinovať rôznymi spôsobmi. V UML sa statické aspekty tohto typu prenášajú pomocou diagramov komponentov a dynamické aspekty sa prenášajú pomocou diagramov interakcií, stavov a akcií.

Pohľad na nasadenie Zobrazenie nasadenia pokrýva uzly, ktoré tvoria hardvérovú topológiu systému, na ktorom beží. Ide predovšetkým o distribúciu, dodávku a inštaláciu častí, ktoré tvoria fyzický systém. Jeho statické aspekty sú opísané v diagramoch nasadenia a jeho dynamické aspekty pomocou diagramov interakcií, stavu a akcií.

Každý z uvedených typov možno považovať za úplne nezávislý, takže tí, ktorí sa podieľajú na vývoji systému, sa môžu sústrediť na štúdium iba tých aspektov architektúry, ktoré sa ich priamo týkajú. Nesmieme však zabúdať, že tieto druhy sa navzájom ovplyvňujú. Napríklad uzly pohľadu nasadenia obsahujú komponenty opísané pre pohľad implementácie, ktoré zas reprezentujú fyzické stelesnenie tried, rozhraní, spolupráce a aktívnych tried v zobrazení návrhu a procesu. UML vám umožňuje zobraziť každý z piatich uvedených pohľadov a ich interakcie.