Bázisok UML - A diagramok (use-case)
Függetlenül attól, hogy a tervezési módszer, hogy használja, az első fejlődési szakaszban lesz a készítmény a termék követelmények (Graddi Booch leírja a Rational Unified Process [1], és Rosenberg - ICONIX [2]). Egy sor termék követelményeknek egy technikai feladat. A követelmények vannak osztva funkcionális (azaz, a rendszer lehetővé teszi, hogy a kívánt funkciók) és a nem-funkcionális (hardver követelmények, az operációs rendszer, stb.) Az UML hivatalossá használatát diagramok használt funkcionális követelményeknek.
Diagram használati esetek, érdemes építeni a technikai projekt tanulmány. áll egy grafikus diagram leírja a szereplők és a használati esetek. és a specifikáció egy szöveges leírást a specifikus szekvenciák intézkedések (Event Flow). a felhasználó végzi, amikor dolgozik a rendszer. A specifikáció majd az alapja a tesztelés és dokumentáció. és a következő szakaszában a tervezés van kiegészítve, és alakú formájában diagramok (belüli ICONIX használva szekvencia diagramot az UML, de erre is vannak aktivitás diagramok). Ezen túlmenően, használati eset diagram elég egyszerű, hogy képes megérteni az ügyfél, így használhatja úgy, hogy megfeleljen a feladatmeghatározás (mert diagram ismerteti funkcionális követelmények a rendszer).
A következő diagram mutatja:
Véleményem a legtöbb helyes eljárás az építőiparban az alábbi táblázat:
- kiválasztott csoportja a szereplők (dolgozik a rendszer különböző módon, gyakran a különböző hozzáférési jogok);
- azonosítani annyi lehetőség, mint lehetséges, hogy (a folyamatokat, amelyek a felhasználók végre). Nem szabad osztani a folyamatok túl kicsi, meg kell választani csak az is, hogy ad a felhasználónak jelentős eredmény. Például a pénztáros „árut” (ez lesz precedens), hanem „a termék vonalkódot bemenet az ár” nem önálló precedenst
- kiegészítik precedensek verbális leírása (script):
- Minden használat esetén a partíciókat: a „fő-szekvencia” és „alternatív szekvencia”;
- előkészítése során a forgatókönyvet kell állhatatosan kérni az ügyfelek kérdéseire „mi történik?”, „hogyan tovább?”, „mit tud történni?”, és rögzíti a válaszokat.
Tekintsük a fejlesztés a diagramok használni a példa a lehetőségek - akkor is, ha az ügyfél megadta nekünk a következő feladatmeghatározás:
A cél - a fejlesztési matematikai képességek a gyermekek körében.
Platform: Linux, Windows, Android.
funkciók:
Amikor először kezdi el a rendszer lehetővé teszi, hogy a tanár írja be a jelszót. Hozzárendelések matematikai problémák összeadás, kivonás, szorzás és osztás. A feladat egység lehet bármilyen típusú probléma (meghatározott összeg). Amellett, hogy a típusú bemeneti műveletet végrehajtottuk a példában meg kell határozni megengedett tartománya a számok (vagy akár az egyes számok, mint a tanulmány a szorzótábla gyakran először tanított szorzás 2, majd 5, és csak ezután az összes többi). Továbbá, a kivonási művelet képesnek kell lennie arra, hogy létrehozza a kivonandó kevesebb kisebbítendő (egyébként az eredmény negatív lesz, és a negatív számok az iskolában tesztelték jóval később).
Nyilvánvaló, hogy annak ellenére, hogy az ügyfél részletesen egyes részleteket, akkor nem csak, hogy folytassa a feladat, de még egy durva becslés a költségek és az időzítés. Mivel egy ilyen feladat nem világos például, hogy a jelentéseknek tartalmazniuk kell. Ugyanakkor tudjuk azonnal azonosítani két felhasználói csoportok, néhány tevékenységüket.
Példa a diagramok
A folytonos vonalak a diagramban a viszonyt ábrázolják egyesülési tükröző a lehetőségét, hogy a színész precedens. Miután egy meghatározott területén használati esetek, meg lehet kezdeni elkészítése forgatókönyveket. A forgatókönyvek kell leírni a szempontból a felhasználó, fontos, hogy leírja a felhasználói interakció a felületi elemek. Például forgatókönyv precedens hallgatói nyilvántartó következőképpen nézhetnek ki:
Név precedens: hallgatói nyilvántartó
Színész: tanár
Cél: hogy adjunk egy diák, hogy a rendszer, megkapta a jelszót
- Tanár kiválasztja a főmenü „add hallgató”;
- a rendszer megjelenít egy ablakot tanár hozzátéve tanuló tartalmazó mezők adható meg a bejelentkezési nevet és jelszót, és „next” gomb és a „vissza”;
- A tanár bemutatja a kívánt felhasználónév és jelszó tanuló megnyomja a „Tovább” gombra;
- A rendszer hozzáadja a hallgató;
- A tanárok meg a főmenüt, és 5 másodperc értesítést, hogy a hallgató sikeresen hozzáadva.
Alternatív szekvenciát (visszatérjen a főmenübe hozzáadása nélkül a hallgató):
- Tanár kiválasztja a főmenü „add hallgató”;
- a rendszer megjelenít egy ablakot tanár hozzátéve tanuló tartalmazó mezők adható meg a bejelentkezési nevet és jelszót, és „next” gomb és a „vissza”;
- a tanár megnyomja a „vissza” gombot;
- A tanárok meg a főmenüt (a bevitt adatok formájában hallgató hozzátéve ablakok nem mentjük el).
Alternatív szekvencia (hozzáadásával egy tanuló, már rendelkezésre a rendszerben):
- Tanár kiválasztja a főmenü „add hallgató”;
- a rendszer megjelenít egy ablakot tanár hozzátéve tanuló tartalmazó mezők adható meg a bejelentkezési nevet és jelszót, és „next” gomb és a „vissza”;
- A tanár bemutatja a kívánt felhasználónév és jelszó tanuló megnyomja a „Tovább” gombra;
- tanár értesítés jelenik meg 5 másodpercig, hogy a kért felhasználónév foglalt.
Hasonlóképpen, a precedensek is mondják ki, szemlélteti az ábra. Scripts kell lennie annyira, hogy tartalmazza az összes lehetséges felhasználói műveleteket a rendszer. Az ügyfél megteheti, nagy öröm, mint programozó rovására a korábbi találja lehetséges vevői követelményeket (mint a fenti forgatókönyv, talán megtudja, hogy a program megjelenít egy felugró értesítés).
Annak ellenére, hogy az egyszerűség a fenti forgatókönyv, saját szekvenciák megtalálhatók párhuzamos, ha zajlik a szkripteket - akkor vedd ki néhány töredéke leírás néhány precedens (ami lehet egyénileg és csak részét más felhasználásra). Ugyanakkor közötti használati esetek lesz vagy expanziós arány (kiterjeszteni), vagy kapcsolja be (közé). amelyek megjelennek a diagramok (UML általánosítás kapcsolat van, és OML - hívja és részesítendő).
A felvétel kapcsán a rajz használat
Az arány a tágulási a diagramon a használat
A leggyakoribb hibák az építési ilyen jellegű ábrák:
- visszaélés kapcsolatok bővítése és az integráció, beleértve megpróbálja használni a diagram egy funkcionális bomlása a rendszer. Ez abból ered, egy félreértés a különbség a két típusú kapcsolat, és hogy a use-case diagram kell kifejezni csak a rendszer követelményeinek, de nem a végrehajtásának részleteit;
- Fejlesztése a diagram egy programozó szemszögéből, nem a felhasználó. A forgatókönyvek kell használni nevét ellenőrzés (látható a felhasználó számára), de nem kívánt módon képviseli végrehajtásának részleteit (például az esemény kezelő) nem világos, hogy az ügyfél;
- Nem elég tanulmány a forgatókönyv:
- hiánya vagy elégtelen számú alternatív szekvenciák, amelyben kell figyelembe venni, beleértve, a hibás beviteli adatok a rendszerbe;
- Leírás Felhasználói művelet megadása nélkül az elemek a rendszer interfész és a hiányzó rendszer leírása reakció forgatókönyveket.
Fontos, hogy ICONIX folyamat iteratív, így ha hibázott a fejlődési szakaszában a használata diagramok - ezek megtalálhatók és korrigálni a következő stádiumban (különösen a hiányzó tárgyakat lehet kinyerni, ha dolgozik grafikonok robusztusság és forgatókönyvek kidolgozott építési rajzok szekvencia).
Ha követed a szabályokat adott használati eset diagramok, akkor lehet használni, hogy dolgozzanak ki a feladatmeghatározás kellő részletességgel megbecsülni az időt és a költségek a végrehajtás, az egyes konkrét eseteket kölcsönhatás a rendszer, amely alapját képezi majd a vizsgálatok és a dokumentációt. és koordinálja mindezt az ügyfél.
A cikk bemutatja a fő jellemzői a use-case diagramok. véleményem legyen elég a fejlesztés a legtöbb rendszerek, több információt, ha szükséges, és példák találhatók a következő dokumentumokban: