Plug-in pro správu požadavků a sledování postupu vývoje

Transkript

1 Plug-in pro správu požadavků a sledování postupu vývoje Autor: Tomáš Vahalík vahalik@komix.cz Každý, kdo musí spravovat požadavky na vývoj informačního systému, řešil problém, jaký nástroj k tomu použít. V KOMIXu jsme zvolili cestu vývoje vlastního pluginu do UML nástroje MagicDraw. V tomto článku se seznámíte s UML extension mechanismem (tj. s možnostmi rozšíření UML modelu) a s pluginem ExtendIX, který těchto možností využívá. Plugin najde uplatnění nejen při správě požadavků, ale i při plánování a sledování postupu vývoje, odhadování pracnosti a při přípravě testů. V závěru najdete informace o tom, jak plugin získat. Problém V KOMIXu jsme hledali náhradu specializovaného nástroje pro správu požadavků DOORS firmy Telelogic. Hlavním důvodem byly licenční poplatky. Druhým důvodem byla možnost přímé integrace s UML nástrojem (v našem případě MagicDraw od firmy NoMagic), ve kterém jsou vytvářeny modely používané v průběhu vývoje softwaru již od fáze specifikace požadavků. Naší snahou je vždy dělat věci jen jednou a co nejjednodušeji, bez nutnosti ručního kopírování a propojování. Obecně se při správě požadavků nabízí tyto možnosti: Word processor (Word) Snadné formátování, výsledek je přímo součást dokumentace projednávané se zákazníkem, možnost zaznamenávat změny pomocí revizí. Nevýhodou je nemožnost požadavky třídit, filtrovat, obtížné je zajistit trasovatelnost do dalších fázích vývoje. Spreadsheet (Excel) Požadavky je možné třídit a filtrovat. Můžete si zobrazit např. všechny požadavky plánované pro etapu 2 setříděné podle priority s uvedením autora a stupně složitosti. Spreadsheet je také možné kombinovat s word procesorem (např. pomocí html odkazů). Nehodí se pro větší projekty, vyžaduje poměrně komplikovanou ruční práci. Vlastní nástroj Tato kategorie bývá někdy označována jako homegrown tool. Jedná se o vlastní aplikaci založenou zpravidla na databázi. Umožňuje třídit, filtrovat, provazovat požadavky. Nevýhodou může být obtížná adaptovatelnost na nový projekt, protože podobné aplikace bývají vytvořeny často na míru konkrétnímu projektu a rychle zastarávají. Problémem zůstává provázanost s UML nástrojem, pokud integrace není přímo součást řešení takovéhoto nástroje. Specializovaný komerční nástroj Nástroj kategorie RM tool (Requirements management tool). Hlavním problémem bývá vyšší cena a licenční poplatky. Specializovaný nástroj se určitě uplatní na skutečně

2 velkých projektech, u menších projektů ale zbytečně zvyšuje náklady. Dalším problémem může být integrace s konkrétním UML nástrojem, který používáte pro vývoj. Možná jste řešili podobný problém a dokázali by jste popsat i další varianty. Řešení: plug-in Zvažovali jsme různé možnosti, především vývoj vlastního nástroje s parametry blízkými komerčním specializovaným nástrojům. Nakonec jsme se rozhodli využít možností UML nástroje MagicDraw a s pomocí jeho Open API vytvořit plug-in splňující naše požadavky (přesněji naše metapožadavky = požadavky na správu požadavků). Výhodou tohoto řešení z hlediska pracnosti vlastního vývoje je především využití infrastruktury poskytované UML nástrojem: nemusíme řešit autentizaci a autorizaci, bezpečné ukládání dat ve standardním formátu XMI, práci v týmu a zamykání komponent, možnost undo atd. a můžeme se soustředit na požadovanou funkcionalitu. Další velkou výhodou je integrace správy požadavků přímo do UML nástroje používaného při vývoji. Díky tomu není nutné řešit synchronizaci s jinými specializovanými nástroji. Snadno můžeme uplatnit use case driven přístup při vývoji softwaru, kdy funkční požadavky jsou zaznamenány formou use case modelu a use case jsou potom sjednocujícím pohledem na vyvíjený systém pro všechny zúčastněné strany a profese tj. pro zákazníka, analytika, designera, testera i vedoucího projektu. Nevýhodou se může zdát závislost na konkrétním UML nástroji. MagicDraw jako svůj formát uložení modelu používá standardní XMI. Ani plugin nezavádí žádný vlastní formát uložení dat. Veškeré informace se kterými pracuje plugin jsou popisovány standardně v UML (nemusí se však vždy jednat o grafické zobrazení, zvláště u požadavků je primární text) a jsou ukládány ve standardním formátu XMI v rámci projektu, takže s těmito daty je možné pracovat i v jiných UML nástrojích podporujících XMI (což jsou snad všechny). Jedná se o plugin, nikoli o samostatnou aplikaci ukládající data ve formátu XMI, MagicDraw je proto nutná součást tohoto řešení. Nevýhodu závislosti na MagicDraw lze proměnit ve výhodu: plugin nabízíme i ostatním uživatelům MagicDraw. Plugin dostal jméno ExtendIX podle UML extension mechanism. Na vysvětlení tohoto pojmu se blíže podíváme v následující kapitole. Teorie: UML extension mechanism UML (Unified Modeling Language) je nejvíce rozšířený standard pro modelování informačních systémů. Je poměrně obecný, umožňuje však taková rozšíření a přizpůsobení, že dokáže popsat i specifickou problémovou oblast, kde s obecnými elementy UML nevystačíme. OMG (Object Managament Group) definuje dvě možnosti jak definovat jazyk specifický pro určitou problémovou oblast: 1) Definovat nový jazyk jako alternativu k UML a to za použití MOF (Meta Object Facility) což je meta jazyk pro definici objektově orientovaných modelovacích jazyků. Pomocí MOF je definován například UML, CWM (Common Warehouse Model), ale i MOF sám. 2) Poněkud šetrnější možností je specializace elementů a doplnění různých omezení při zachování původního významu UML elementů. Pro tyto případy poskytuje UML

3 extension mechanismus: stereotypy, tagged values, constraints. Všechna tato přizpůsobení jsou seskupena do UML Profilů. Obě varianty mají své výhody a nevýhody. Velkou výhodou druhé varianty, tedy použití Profilů, je ale skutečnost, že narozdíl od první varianty, lze využít komerční UML nástroje pro modelování. Profily je možno využít nejen pro specifické problémové oblasti, ale i pro přizpůsobení UML modelu různým implementačním platformám (J2EE,.NET) tedy podle přístupu MDA (Model Driven Architecture) při transformacích mezi modely a při transformaci modelu do kódu. Profily byly definovány již ve verzi UML 1.1. Ve verzi UML 2.0 je několik vylepšení a vyjasnění. Dále uvedené specifikace se týkají UML 2.0. Profile Profil obsahuje sadu extension mechanismů (stereotypes, tagged values, constraints), které jsou seskupeny do package se stereotypem <<profile>>. Existuje několik profilů standardizovaných OMG, další byly definovány organizacemi a softwarovými firmami (např. UML/EJB Mapping Specification). Další profily jsou součástí UML nástrojů (RUP Extensions Profile, UseCase Description Profile). Stereotype Stereotyp je druh meta-třídy, která rozšiřuje jiné meta- třídy (definuje se tedy nikoli rozšíření např. pro modelovanou třídu Osoba, ale definuje možná rozšíření například pro Class, UseCase, Association,...). Na diagramech se zobrazuje ve dvojitých lomených závorkách nad názvem elementu. Stereotyp může změnit grafické znázornění modelovaných elementů. Například v robustness diagramech třídy stereotypu <<boundary>> mají jiné znázornění než třídy stereotypu <<entity>>. Můžete například definovat stereotyp <<externí systém>> pro meta-třídu Actor, instance s tímto stereotypem budou zobrazovány nikoli jako panáček, ale např. jako počítač. Constraint Constraints neboli Omezení mohou být asociovány se stereotypy a tím přesněji definovat pravidla pro modelované elementy rozšířené stereotypem. Constraint může být vyjádřen v přirozeném jazyce nebo v OCL (Object Constraint Language), což je součást UML. Pojmenování Constraint v názvu jazyka pochází z jeho první verze, OCL 2.0 se vyvinul do bohatého jazyka, jehož vyjadřovací možnosti jsou srovnávány s SQL. Constraint se znázorňuje ve složených závorkách. Tagged value Tagged value (někdy překládané jako Označené hodnoty nebo Příznaky) jsou přidané meta-atributy k meta-třídě. Tagged value je vždy dvojice jméno a typ a jsou přidruženy k určitému stereotypu. Typem může být i Enumeration, což je druh datového typu, který definuje výčet přípustných hodnot nazvaný Enumeration literals.

4 Graficky jsou tagged values znázorněny jako atributy třídy, která definuje stereotyp, u modelovaného elementu jsou zobrazeny ve složených závorkách. Ve verzi UML 1.3 mohly tagged values rozšířit element modelu bez toho, aby byly součástí stereotypu. V UML 1.4 byla tato možnost podporována pouze kvůli zpětné kompatibilitě. Ve verzi UML 2.0 může být tagged value reprezentována pouze jako atribut definovaný na stereotypu. V těchto případech ale může UML nástroj automaticky definovat stereotyp pro samostatné tagged values, aby byla zachována zpětná kompatibilita. Příklad Následující obrázek ukazuje definici profilu. Use case může být označen stereotypem <<Functional Requirement>>, v tom případě je možné k takovému use case definovat hodnoty k tagged values Author, Priority, Status. Jsou předdefinovány přípustné hodnoty pro Prioritu a Status. Tento profil může být použit v libovolném projektu. Poznámka: Zde v příkladu výše uvedený Requirements Profile není totožný s profilem, který využívá ExtendIX, to by bylo moc jednoduché. V projektu, který používá takovýto profil, mohou být potom konkrétní use case označeny stereotypem <<Functional Requirement>> a mohou být definovány jejich Tagged Values. Následující obrázek ukazuje příklad dvou use case. Zobrazení stereotypu i zobrazení tagged values lze potlačit, aby diagram zůstal přehledným.

5 Produkt: ExtendIX UML nástroje včetně MagicDraw umožňují definovat a upravovat profily - to nebylo cílem pluginu ExtendIX. Nevýhodou UML nástrojů je omezený pohled na tagged values pouze přes jeden vybraný element viz následující příklad pro use case Send Credit. Pří vývoji softwaru je však vhodné mít celkový přehled. Například při plánování a sledování postupu vývoje chceme zobrazit tabulku kde je název use case, jejich autora, prioritu a stupeň složitosti, stav realizace, setřídit podle priority a filtrovat jen use case plánované do druhé etapy projektu. Následující obrázek ukazuje náš dříve použitý jednoduchý příklad, tak jak je zobrazen v ExtendIXu. Výhodou je nejen přehledné zobrazení, ale i možnost při tomto tabulkovém zobrazení nastavovat hodnoty sloupců odpovídající tagged values. V příkladu

6 není uveden textový popis use case, který odpovídá formulaci funkčního požadavku. Můžete si však nechat zobrazit další sloupec Documentation, potom text požadavku uvidíte. ExtendIX plugin umožňuje práci s extension elementy (stereotypy, tagged values, constraints) v tabulkové formě. Klíčové místo zde mají především tagged values, které fungují jako uživatelsky definované atributy. Tyto atributy nemusíte vždy definovat znovu - můžete využít tagged values definované v profilech, které jsou součástí MagicDraw (např. UseCase Description Profile) nebo využít Requirements Profile, který je součástí instalace pluginu. Nebo můžete vyrobit profil sobě na míru. ExtendIX najde uplatnění nejen při správě požadavků, ale i při plánování a sledování postupu vývoje, odhadování pracnosti, přípravě testů vždy když potřebujete filtrovat a třídit informace spojené s modelovanými elementy, vytvářet různé pohledy, definovat vlastní atributy. A to vše bez nutnosti exportování a importování do jiného nástroje. Následující obrázek ukazuje okno pluginu a naznačuje hlavní funkcionalitu. Náhled na data (view) lze ukládat a vytvářet reporty v různých formátech včetně možnosti exportu do Excelu. Tímto způsobem je možné exportovat data například do Mercury TestDirector pokud přece jen dáte přednost specializovaným nástrojům.

7 Download Plugin je k dispozici ke stažení na našich internetových stránkách Reference: Jim Heumann: Writing good requirements is a lot like writing good code Lidia Fuentes and Antonio Vallecillo : An Introduction to UML Profiles se2c.uni.lu/tiki/se2c-bib_download.php?id=1421