Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A Visual Studióban modell segítségével megértheti és módosíthatja a rendszert, alkalmazást vagy összetevőt. A modell segítségével megjelenítheti a rendszer működését, tisztázhatja a felhasználók igényeit, meghatározhatja a rendszer architektúráját, elemezheti a kódot, és meggyőződhet arról, hogy a kód megfelel a követelményeknek.
Annak megtekintéséhez, hogy a Visual Studio mely verziói támogatják az egyes modelleket, tekintse meg az architektúra és a modellezési eszközök verziótámogatását.
A modellek többféleképpen segíthetnek:
A rajzmodellezési diagramok segítenek tisztázni a követelményekkel, az architektúrával és a magas szintű tervezéssel kapcsolatos fogalmakat. További információkért lásd a modell felhasználói követelményeit.
A modellek használata segíthet az inkonzisztenciák feltárásában a követelményekben.
A modellekkel való kommunikáció segít abban, hogy kevésbé egyértelmű módon kommunikáljon a fontos fogalmakkal, mint a természetes nyelvvel. További információ: Az alkalmazás architektúrájának modellezése.
Néha modellek használatával is létrehozhat kódot vagy más összetevőket, például adatbázissémákat vagy dokumentumokat. A Visual Studio modellezési összetevői például egy modellből jönnek létre. További információ: Az alkalmazás létrehozása és konfigurálása modellekből.
Modelleket sokféle folyamathoz használhat, az extrém agilistól a magas ceremónián át.
Modellek használata a kétértelműség csökkentésére
A modellezési nyelv kevésbé egyértelmű, mint a természetes nyelv, és úgy lett kialakítva, hogy kifejezze a szoftverfejlesztés során általában szükséges ötleteket.
Ha a projektben egy kis csapat követi az agilis eljárásokat, modellek segítségével tisztázhatja a felhasználói történeteket. Az ügyféllel az igényeikről folytatott megbeszélések során a modell létrehozása sokkal gyorsabban és a termék szélesebb területén is hasznos kérdéseket generálhat, mint a kiugró érték vagy a prototípuskód írása.
Ha a projekt nagy méretű, és a világ különböző részein található csapatokat is tartalmaz, modellek használatával sokkal hatékonyabban kommunikálhatja a követelményeket és az architektúrát, mint egyszerű szöveges formában.
A modell létrehozása mindkét esetben szinte mindig jelentősen csökkenti az inkonzisztenciákat és a kétértelműségeket. A különböző érdekelt felek gyakran különböző ismeretekkel rendelkeznek arról az üzleti világról, amelyben a rendszer működik, és a különböző fejlesztők gyakran eltérően ismerik a rendszer működését. Amikor egy modellt használnak egy vita középpontjában, általában feltárja ezeket a különbségeket. Az inkonzisztenciák csökkentésére szolgáló modell használatával kapcsolatos további információkért lásd a modell felhasználói követelményeit.
Modellek használata más artefaktumokkal
A modell önmagában nem követelményspecifikáció vagy architektúra. Ez egy eszköz ezeknek a dolgoknak bizonyos aspektusainak egyértelműbb kifejezésére, de a szoftvertervezés során szükséges fogalmak nem fejezhetők ki. A modelleket ezért más kommunikációs eszközökkel együtt kell használni, például OneNote-oldalakat vagy bekezdéseket, Microsoft Office-dokumentumokat, a Team Foundation munkaelemeit vagy a projektszoba falán lévő öntapadós jegyzeteket. Az utolsó elemen kívül az összes ilyen objektumtípus csatolható a modell elemeihez.
A specifikáció egyéb, a modellekkel együtt használt aspektusai közé tartoznak a következők. A projekt méretétől és stílusától függően több szempontot is használhat, vagy egyáltalán nem használhatja:
Felhasználói történetek. A felhasználói történet egy rövid leírás, amely a felhasználókkal és más érdekelt felekkel együtt a rendszer viselkedésének egy olyan aspektusát ismerteti, amelyet a projekt iterációinak egyikében fognak kézbesíteni. Egy tipikus felhasználói történet a következővel kezdődik: "Az ügyfél képes lesz rá...." A felhasználói történetek használati esetek egy csoportját vezethetik be, vagy meghatározhatják a korábban kifejlesztett használati esetek bővítményeit. A használati esetek definiálása vagy kiterjesztése megkönnyíti a felhasználói történet egyértelműsítését.
Kérések módosítása. A formálisabb projektekben a változáskérések nagyon hasonlítanak egy agilis projekt felhasználói történetéhez. Az agilis megközelítés az összes követelményt a korábbi iterációkban kifejlesztett változásokként kezeli.
Használati eset leírása. A használati eset egy olyan módszert jelöl, amelyben a felhasználó egy adott cél elérése érdekében interakcióba lép a rendszerrel. A teljes leírás tartalmazza az események célját, fő és alternatív sorozatait, valamint a kivételes kimeneteket. A használati esetek diagramja segít a használati esetek összegzésében és áttekintésében.
Forgatókönyvek. A forgatókönyv az események sorozatának meglehetősen részletes leírása, amely bemutatja, hogyan működnek együtt a rendszer, a felhasználók és más rendszerek az érdekelt felek számára. Ez lehet a felhasználói felület diavetítése vagy a felhasználói felület prototípusa. Leírhat egy használati esetet vagy egy használati esetsort.
Glosszárium. A projekt követelményeinek szószedete leírja azokat a szavakat, amelyekkel az ügyfelek beszélnek a világukról. A felhasználói felület és a követelmények modelljeinek is ezeket a feltételeket kell használniuk. Az osztálydiagramok segíthetnek tisztázni a legtöbb kifejezés közötti kapcsolatokat. A diagramok és szószedetek létrehozása nem csupán csökkenti a felhasználók és a fejlesztők közötti félreértéseket, hanem szinte mindig feltárja a különböző üzleti szereplők közötti félreértéseket.
Üzleti szabályok. Számos üzleti szabály kifejezhető invariáns megkötésként a követelményosztály-modell összekapcsolásai és attribútumai, valamint a szekvenciadiagramok megkötései esetén.
Magas szintű kialakítás. A főbb részeket és azok illeszkedési módját ismerteti. Az összetevő-, a sorozat- és az interfészdiagramok a magas szintű tervezés fő részét képezik.
Tervezési minták. Ismertesse a rendszer különböző részei között megosztott tervezési szabályokat.
Tesztelési specifikációk. A tesztszkriptek és a tesztkód-tervek jól használhatók a tevékenység- és szekvenciadiagramok használatára a tesztelési lépések sorozatainak leírásához. A rendszerteszteket a követelmények modellje alapján kell kifejezni, hogy könnyen módosíthatók legyenek a követelmények változásakor.
Projektterv. A projektterv vagy a hátralék határozza meg, hogy az egyes funkciók mikor lesznek kézbesítve. Az egyes funkciókat úgy határozhatja meg, hogy megadja, milyen használati eseteket és üzleti szabályokat valósít meg vagy terjeszt ki. Közvetlenül a tervben hivatkozhat az üzleti szabályokra és a használati esetekre, vagy definiálhat egy funkciókészletet egy külön dokumentumban, és használhatja a funkciócímeket a tervben.
Modellek használata az iterációs tervezésben
Bár minden projekt különböző a méretükben és a szervezetükben, egy tipikus projektet két és hat hét közötti iterációk sorozataként terveznek. Fontos, hogy elegendő iterációt tervezze meg ahhoz, hogy a korai iterációk visszajelzései felhasználhatók legyenek a későbbi iterációk hatókörének és terveinek módosításához.
Az alábbi javaslatok hasznosak lehetnek az iteratív projektek modellezésének előnyeinek kihasználásához.
A fókusz élesítése az egyes iterációk közeledtével
Az egyes iterációk közeledtével modellek segítségével határozhatja meg, hogy mit kell az iteráció végén kézbesíteni.
A korai iterációkban ne modellelje részletesen a részleteket. Az első iterációban hozzon létre egy osztálydiagramot a felhasználói szószedet fő elemeihez, rajzoljon egy diagramot a főbb használati esetekről, és rajzoljon egy diagramot a fő összetevőkről. Ezeket ne írja le részletesen, mert a részletek a projekt későbbi részében módosulnak. Az ebben a modellben definiált kifejezések használatával létrehozhatja a szolgáltatások vagy a főbb felhasználói történetek listáját. Rendelje hozzá a funkciókat az iterációkhoz úgy, hogy a becsült munka nagyjából egyensúlyban legyen a projekt során. Ezek a hozzárendelések a projekt későbbi részében módosulnak.
Próbálja meg az összes legfontosabb használati eset egyszerűsített verzióit implementálni egy korai iterációban. A későbbi iterációkban kiterjesztheti ezeket a használati eseteket. Ez a megközelítés segít csökkenteni annak a kockázatát, hogy a projekt későbbi szakaszában fedezzenek fel hibát a követelményekben vagy az architektúrában, amikor már túl késő bármit is tenni ellene.
Az egyes iterációk végén tartson egy követelményműhelyt, amely részletesen meghatározza a következő iterációban fejlesztendő követelményeket vagy felhasználói történeteket. Hívja meg a prioritásokat eldöntő felhasználókat és üzleti érdekelt feleket, valamint a fejlesztőket és a rendszertesztelőket. 2 hetes iteráció követelményeinek meghatározása három óra alatt.
A workshop célja, hogy mindenki egyetértsen abban, hogy mit érünk el a következő iteráció végére. A követelmények tisztázásához használjon modelleket az egyik eszközként. A workshop kimenete egy iterációs teendőlista, azaz a Team Foundation fejlesztési feladatainak listája és a Microsoft Test Manager tesztcsomagjai.
A követelmények workshopon csak annyiban beszélje meg a tervet, hogy meg kell határoznia a fejlesztési feladatok becsléseit. Ellenkező esetben a felhasználók által közvetlenül tapasztalt rendszerszintű viselkedésről tartson vitafórumot. Tartsa távol a követelménymodellt az architekturális modelltől.
A nem műszaki érdekelt feleknek általában nem okoz problémát az UML-diagramok megértése, némi útmutatással.
Modell csatolása munkaelemekhez
A követelmények workshopja után dolgozza ki a követelménymodell részleteit, és kapcsolja össze a modellt a fejlesztési feladatokkal. Ezt úgy teheti meg, hogy összekapcsolja a Team Foundation munkaelemeit a modell elemeivel.
Bármely elemet csatolhat munkaelemekhez, de a leg hasznosabb elemek a következők:
- Az üzleti szabályokat vagy a szolgáltatásminőségi követelményeket leíró megjegyzések. További információkért lásd a modell felhasználói követelményeit.
Modell csatolása tesztekhez
Az elfogadási tesztek tervezéséhez használja a követelmények modelljét. Ezeket a teszteket a fejlesztési munkával egyidejűleg hozza létre.
Ha többet szeretne megtudni erről a technikáról, tekintse meg a modellek tesztjeinek fejlesztése című témakört.
Hátralévő munka becslése
A követelmények modellje segíthet megbecsülni a projekt teljes méretét az egyes iterációk méretéhez viszonyítva. A használati esetek és osztályok számának és összetettségének felmérése segíthet megbecsülni a szükséges fejlesztési munkát. Amikor elvégezte az első néhány iterációt, a lefedett követelmények és a még fedezendő követelmények összehasonlítása hozzávetőleges mértéket adhat a projekt többi részének költségeiről és hatóköréről.
Az egyes iterációk végén tekintse át a követelmények jövőbeli iterációkhoz való hozzárendelését. Hasznos lehet a szoftver állapotát az egyes iterációk végén alrendszerként ábrázolni egy használati esetdiagramon. A megbeszélések során áthelyezheti a használati eseteket és az esetkiterjesztéseket ezen alrendszerek egyikéről a másikra.
Absztrakció szintjei
A modellek számos absztrakcióval rendelkeznek a szoftverhez képest. A legbetonozottabb modellek közvetlenül a program kódját jelölik, a leg absztraktabb modellek pedig olyan üzleti fogalmakat jelölnek, amelyek esetleg nem jelenhetnek meg a kódban.
A modellek többféle diagramon keresztül tekinthetők meg. A modellekről és diagramokról további információt az alkalmazás modelljeinek létrehozása című témakörben talál.
A különböző típusú diagramok az absztrakció különböző szintjein történő tervezéshez hasznosak. Számos diagramtípus több szinten is hasznos. Ez a táblázat az egyes diagramtípusok használatát mutatja be.
| Tervezési szint | Diagramtípusok |
|---|---|
| Üzleti folyamat A rendszer felhasználási környezetének megértése segít megérteni, hogy mire van szükségük a felhasználóknak. |
- A fogalmi osztálydiagramok az üzleti folyamat során használt üzleti fogalmakat írják le. |
| Felhasználói követelmények A felhasználók igényeinek meghatározása a rendszerből. |
- Az üzleti szabályok és a szolgáltatásminőségi követelmények külön dokumentumokban írhatók le. |
| Magas szintű kialakítás A rendszer általános felépítése: a fő összetevők és azok összekapcsolása. |
– A függőségi diagramok azt írják le, hogy a rendszer hogyan épül fel egymástól függő részekre. A programkódot a függőségi diagramok alapján ellenőrizheti, hogy az megfelel-e az architektúrának. |
| Kódelemzés A kódból diagramok hozhatók létre. |
– A függőségi diagramok az osztályok közötti függőségeket mutatják. A frissített kód egy függőségi diagramon érvényesíthető. - Az osztálydiagramok a kódban szereplő osztályokat mutatják. |
Külső erőforrások
Kapcsolódó tartalom
- Modellek használata az Agilis fejlesztésben
- Modellek létrehozása az alkalmazáshoz
- Modell felhasználói követelményei
- Az alkalmazás architektúrájának modellezése
- Tesztek fejlesztése modellből
- A modellezési megoldás felépítése
Megjegyzés:
A Text Template Transformation összetevő automatikusan telepítve van a Visual Studio bővítményfejlesztési számítási feladatainak részeként. A Visual Studio Installer Egyes összetevők lapján, az SDK-k, kódtárak és keretrendszerek kategóriában is telepítheti. Telepítse a Modellezés SDK-összetevőt az Egyes összetevők lapon.