UML modellezés - studopediya
UML Unified Modeling Language [18] (Unified Modeling Language) egy olyan nyelv meghatározására, jelentési és dokumentum tervező szoftver rendszerek, szervezeti és gazdasági rendszerek, a műszaki és egyéb rendszerek különböző jellegű. UML egy szabványos ábrák, jelölések a legkülönbözőbb fajok.
· Biztosítson a felhasználók számára azonnal használható kifejező nyelv vizuális modellezés, amely lehetővé teszi számukra, hogy értelmes minták és ossza meg őket;
· Adjon nyújtható, és a specializáció mechanizmusok kiterjeszteni az alapfogalmak;
· Függetlenségének biztosítása az adott programozási nyelvek és fejlesztési folyamatokat;
· Formai alapja a megértés a modellező nyelv (a nyelv legyen pontos és könnyen érthető, anélkül, hogy túlzott formalizmus);
· Serkentik a növekedést a piaci objektum-orientált eszközöket;
· Integrálja a legjobb élményt.
UML a szabványosítási folyamatban, birtokában OMG (Object Management Group) - Szabványügyi Szervezet területén az objektum-orientált módszerek és technológiák, amelyek jelenleg elfogadott standard modellező nyelv és széles körű támogatást kapott a szoftver-iparban. UML által elfogadott szinte az összes nagy cégek - szoftvergyártók (Microsoft, az IBM, a Hewlett-Packard, az Oracle, Sybase, stb.) Ezen kívül szinte a világ összes gyártó CASE-eszközöket, továbbá az IBM Rational
· A strukturális (szerkezeti) modell:
osztály diagram (osztály diagramok) - modellezésére statikus struktúráját a rendszer osztályok és viszonyok közöttük; komponens diagramja (Komponens diagramok) - modellezésére hierarchiáját komponensek (alrendszerek) a rendszer;
elhelyezés diagram (telepítési ábrák) - szimuláló fizikai rendszer architektúra.
· Viselkedésminták (viselkedési):
Használati eset diagramok (használati eset diagramok) - modellezésére az üzleti folyamatok és a funkcionális követelmények a rendszer létrehozása; interakció diagramok (interakció diagramok):
szekvencia diagram (szekvencia diagramok) és az együttműködési diagramok (együttműködési diagramokat) - szimulálására közötti üzenetváltás tárgyak folyamatban;
állami diagramok (statechart ábrák) - létesítmények modellezésére a rendszer viselkedését során az átmenet az egyik állapotból a másikba;
aktivitás diagramok (aktivitás diagramok) -, hogy szimulálja a rendszer viselkedését alapján különböző használati esetek, vagy kontroll folyamok.
ÁBRÁK opciók a
Az az elképzelés, amely leírja a funkcionális követelmények formájában használati esetek (használati eset) fogalmazták 1986 Ivar Jacobson. Ez a gondolat már elismert konstruktív és széles körben elfogadják. Ezt követően a legjelentősebb hozzájárulás a probléma megoldásának a jellegének meghatározására használata lehetőséget és hogyan írják le őket tenni Alister Kobern [19].
Használati eset egy műveletsor (tranzakciók) által végrehajtott rendszer válaszul egy esemény által kiváltott valamilyen külső tárgy (színész). Felhasználási eset bemutatja egy tipikus interakció a felhasználó és a rendszer, és tükrözi a megértése a rendszer viselkedését a felhasználó szemszögéből. A legegyszerűbb esetben a használati eset határozza meg a folyamat megbeszélés a felhasználónak a funkciókat, amit szeretnénk megvalósítani, vagy gól, hogy kereső vonatkozásában a rendszer fejlesztés alatt.
Színész (színész) - ez a szerepe, hogy a felhasználó játszik tekintetében a rendszer. Szereplők szerepeket, nem konkrét személyek vagy nevét munkák.
Annak ellenére, hogy az általuk használt eset diagramok formájában jelenik stilizált emberi alak, a színész is lehet egy külső rendszer, hogy szüksége van néhány információ a rendszerből.
Karakterek vannak osztva három fő típusa - a felhasználók a rendszer, más rendszerek, amelyek kölcsönhatásba lépnek ez, és az idő. Idő lesz egy színész, ha úgy dönt, a kezdete minden esetben a rendszerben.
Ennek képi ábrázolása használati esetek használt case diagramok használatát. Ábra. 2.47 ábra egy példa egy ilyen diagramot a bankrendszer.
Ábra. 2.47. Példa Esetdiagram
Esetdiagram közötti interakciót mutatja a használati esetek és színészek. Ez tükrözi a funkcionális követelmények a rendszer a felhasználó szemszögéből. Így a használati esetek - egy funkciója a rendszer által, és a szereplők - ez az érintettek (érdekeltek) tekintetében a létrehozott rendszer. Ezek ábrák mely szereplők kezdeményezi a használati eset. Köztük az is nyilvánvaló, amikor a színész információt kap a használati eset. Irányított használata esetén a színész nyíl jelzi, hogy használat esetén információt nyújt használt színész. Ebben az esetben a választási lehetőséget „Befizetés” információt nyújt a hitelrendszer a bankkártyás fizetés.
Színészek játszhat különböző szerepeket használatával kapcsolatos ügyben. Ők is részesülhetnek az eredmények önmagukban közvetlenül részt vesz benne. A jelentősége a különböző szerepeket színész attól függ, hogyan használjuk a kapcsolatokat.
A cél az épület használati eset diagramok - Dokumentációs funkcionális követelmények a rendszer legáltalánosabb formában, így kell, hogy rendkívül egyszerű. Amikor az épület használati eset diagramok kell betartani az alábbi szabályokat:
• Ne szimulálni közötti kommunikáció szereplői. A definíció szerint a karakterek hatálya nem terjed ki a rendszer. Ez azt jelenti, hogy a kommunikáció közöttük is nem tartozik a hatáskörébe.
· Ne csatlakoztassa a két felhasználási nyíl is. Ábrák az ilyen típusú leírni csak a használati esetek, hanem a sorrendben azok végrehajtását. Jelenítse meg a végrehajtási sorrendjét használata ehhez a tevékenységhez felhasznált diagramok.
· Minden használat kell elindítania egy színész. Ez azt jelenti, hogy mindig legyen egy shooter, kezdve az arcon, és befejezve a jelenlegi verzió használható.
Egy jó forrás azonosítására használati esetek szolgálnak külső eseményeket. Meg kell kezdeni egy listát az összes bekövetkezett események a külvilág, amelyre a rendszert kell valahogy reagálni. Bármely adott esemény eredményezheti a reakció rendszer, amely nem igényel felhasználói beavatkozást, vagy éppen ellenkezőleg, mert a letisztult felhasználói választ. Azoknak az eseményeknek, hogy válaszolniuk kell a PA, hogy segítsen azonosítani használati esetek.
Esetdiagram a leggyakoribb ábrázolása funkcionális követelmények a rendszer. Azonban használat esetén modellezés nem csak a diagram rajzoló. Az ezt követő rendszer kialakítása szükségessé teszi konkrét részleteket. Ezeket az adatokat egy dokumentumban úgynevezett „használati eset forgatókönyv” vagy „patak események» (események menetébe). A cél az áramlás az események részletes dokumentációt a kölcsönhatás a színész a rendszer keretében végrehajtott, a használati eset. Az események menetébe kell leírni mindent, ami arra szolgál, hogy megfelelnek a kéréseket a szereplők.
Bár az események menetébe, és részletesen leírtuk, ez szintén nem kell attól függ, a végrehajtás során. A cél -, hogy leírja chtobudet rendszer nem kakona fogja csinálni. Jellemzően az események láncolatába leírás a következő részekből áll:
· A legfontosabb események menetébe;
· Alternatív flow események;
Következetesen megnézi ezeket az összetevőket.
Rövid leírás. Minden használat esetén kell egy rövid leírást, hogy mi történik benne. Például a választási lehetőséget „Transfer pénz” is tartalmazza az alábbi leírást.
A lehetőség a „Transfer pénz” lehetővé teszi, hogy az ügyfél vagy alkalmazottja a bank pénzt az egyik fiókból a kereslet vagy a megtakarítási számla a másikra.
Előfeltételek. Előfeltétele a használatra - ezek a feltételek, amelyeket teljesíteni kell, mielőtt a használat esetén kerül végrehajtásra magát. Például ez a feltétel lehet a végrehajtását egy másik megvalósításában használatával vagy a felhasználó hozzáférési jogait, amelyek szükségesek az induláshoz. Nem minden esetben használat előfeltétele. Említettük korábban, hogy a használati eset diagramok nem tükrözik a sorrendben a végrehajtás. Az ilyen információ leírható előfeltételek. Például, egy előfeltétele az egyik megvalósítási mód szerint az lehet, hogy el kell végezni a másik alkalommal.
Fő és alternatív áramlás az események. Részleteket erre a célra általában le vannak írva az alternatív hírfolyamukat. Az események menetébe leírja a szakaszban, hogy ne lépjen fel a használat során a meghatározott lehetőségek alkalmassága. Az események menetébe odafigyel arra, amit a rendszer nem, de nem így fog csinálni, és leírja mindezt a szempontból a felhasználó. A fő események menetébe leírja a rendes körülmények között (hiba nélkül), és ha van több lehetséges változatai az események lehet elágazó, hogy a slave flow (részáramlásmérőn). Alternatív adatfolyamok leírják az eltérés a rendes körülmények (hiba körülmények között), és a feldolgozás. Például a variáns patakok események a „pénzt a számlára” így néz ki:
A fő áramlási események
1. A használati eset akkor kezdődik, amikor az ügyfél a kártyát behelyezi egy ATM gép.
2. ATM megjeleníti a szöveget, és arra szólítja fel a fogyasztót, hogy adja meg személyes PIN-kódot.
3. Az ügyfél belép a PIN-kódot.
4. ATM megerősíti a kódot.
5. Az ATM listáját jeleníti meg a rendelkezésre álló intézkedések: befizetéshez, pénzt, pénzt átutalni
6. Az ügyfél kiválasztja a „pénzt a számlájára.”
7. ATM kérdezi, hogy mennyi pénzt kell távolítani.
8. A vásárló belép a szükséges összeget.
9. ATM meghatározza, hogy van elég pénz a számlán.
10. ATM levonja a szükséges összeget az ügyfél számláján.
11. Az ATM biztosítja az ügyfél számára a szükséges mennyiségű pénzt.
12. ATM kártya visszaadja az ügyfélnek.
13. Az ATM nyomtat nyugtát a vevő számára.
14. A használati eset végződik.
Alternatív események menetébe 1. Belépés hibás PIN-kódot.
4a1. ATM tájékoztatja az ügyfelet, hogy a kódot helytelenül adta meg.
4a2. ATM visszaadja a kártyát az ügyfél.
4aZ. A használati eset végződik.
2. Egy alternatív események menetébe nem elég a pénz a számlán.
9A1. ATM tájékoztatja az ügyfelet, hogy a pénz a számláján nem elég.
9a2. ATM visszaadja a kártyát az ügyfél.
9AZ. A használati eset végződik.
Alternatív események menetébe 3. Hiba a visszaigazolást az igényelt összeget.
9b2. ATM belép hibainformációkat a hiba napló. Minden bejegyzés tartalmazza a dátumot és az időt a hibát, az ügyfél nevét, számlaszámát, és a hibakód.
9b3. ATM visszaadja a kártyát az ügyfél.
9b4. A használati eset végződik.
• egyszerű mondatokban;
· Egyértelműen jelzik az egyes tételek, aki végrehajtja a - a színész, vagy a rendszer;
· Ne mutatnak túl kevés akció;
· Ne mutassa részletes felhasználó intézkedéseket, miközben dolgozik a felhasználói felület;
· Nem megfontolja a hiba körülmények (használat akciók „megerősítés”, és nem „check”).
Azonosításakor alternatív hírfolyamukat kell először figyelni járó esetekben:
· Hibás felhasználói műveleteket (például hibás jelszó);
· Kihagyása a karaktert (például jelszó lejárati timeout);
· Belső hiba a rendszerben van kialakítva, amely ki kell mutatni és feldolgozni a szokásos módon (például blokkolt pénzautomata);
· Kritikus hiányosságok rendszer teljesítményét (például válaszidő nem fér el 5 másodperc).
Utófeltételek. Utófeltételek azok feltételeit, hogy mindig el kell végezni befejezése után használata esetén. Például, akkor jelölje be a jelölőnégyzetet minden kapcsoló végén a használati eset. Ez a fajta információ része a post-körülmények között. Előfeltételei a post-feltételek megadhatja információt a sorrendben a megvalósítási módok a rendszer. Ha például, miután az egyik használati esetek kell mindig más, akkor lehet leírni, mint egy utófeltétel. Ezek a körülmények nem minden használata esetén.
Extensions. Ez az elem jelen van, ha nagymértékben homo-ke események történnek viszonylag ritka B tuatsii (speciális esetek). A leírás az ilyen helyzetek kiszabott ezt a bekezdést.
A használati eset diagramok a jelenléte a tartályban többféle kapcsolatokat. Ez a kommunikációs kapcsolatokat (közlemény), engedélyezze (többek között), bővíteni (kiterjesztése) és az általánosítás (általánosítás).
Kommunikáció Kommunikáció - az összekötő kapocs a változatot használják, Bani és színész, ő képviseli OD-nonapravlennoy Association (nyíl vonal). A nyíl irányába lehetővé teszi, hogy megértsük, aki kezdeményezi a kommunikációt.
Kommunikációs váltás használható olyan esetekben, amikor van olyan rész a rendszer viselkedését (az áramlási Søby csapágy), ami ismétlődik több opcióval-vanija. Ilyen kapcsolatot általában modellezni mnogokrat használt, de a funkcionalitás. A példában a bankrendszer beállításokat a „pénzt egy számlára” és a „Fizess” kell hitelesíteni az ügyfél és a PIN-kódot, mielőtt lehetővé teszi a végrehajtását a tranzakció is. Ahelyett, hogy egy részletes leírást a hitelesítési folyamat minden egyes használati esetek, akkor tegye ezt a funkciót a saját használatra esetben az úgynevezett „hitelesíti az ügyfél.”
Kommunikációs expanziót alkalmazunk, ha változás áll be a normális viselkedés a rendszer (bekezdésben leírtak szerint „Extended-CIÓ”), amelyek szintén kiveszik a másik változat használ-vanija.
Közlemény és bővíteni mutatjuk függőséget híd ábrán látható. 2.48.
Ábra. 2.48. Közlemény és bővítése
Az általánosítás kommunikáció azt mutatja, hogy vannak hasonlóságok és különbségek között több szereplő. Például a szervezet alkalmazottai vannak, mint a közös tulajdon, és a különböző díjazási mód (ábra. 2,49).
Nem kell mindig a kapcsolat létrehozásához az ilyen típusú. Általában azok szükségesek, ha az eltérések a viselkedés a színész az azonos típusú viselkedést befolyásoló egyéb funkciók a rendszer. Ha mindkét altípusát ugyanazt használati esetek, bemutatva egy általánosítása a színész nem szükséges.
Használati esetek szükséges eszköz a kezdeti szakaszaiban a szoftverre vonatkozó követelményeknek. Minden használat esetén - ez potenciálok
Ábra. 2.49. Általánosítása a színész
társadalmi követelmény, hogy a rendszer, és bár nem látszik, lehetetlen tervezni annak végrehajtását.
Különböző fejlesztők alkalmasak a leírás a használati esetek különböző mértékű részletességgel. Például Ivar Jacobson azt állította, hogy a komplexitás a projekt 10 éves férfi számának használati esetek hozzávetőleg 20 (ide nem értve a csatlakozások „” és a „bővítés”). Előnyben kell részesíteni a kis- és részletes használati esetek, mivel az megkönnyíti előkészítése és végrehajtása során az elfogadott projekt tervet.
A használatának előnyei változatai a modell abban a tényben rejlik, hogy:
· Meghatározza a felhasználók és a rendszer határán;
· Meghatározza a rendszer interfész;
· Kényelmes felhasználók számára, hogy kommunikálni a fejlesztők;
· Használt írás tesztek;
· A alapjaként írásban felhasználói dokumentációt;
· Jól illeszkedik bármilyen tervezési technikák (mint az objektum-orientált és strukturált).