redseeds podręcznik użytko redseeds podręcznik użytkownika

Download ReDSeeDS Podręcznik Użytko ReDSeeDS Podręcznik Użytkownika

Post on 11-Jan-2017

224 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • ReDSeeDS

    Podrcznik Uytkownika

    Lucyna Skrzypek, Piotr abcki

    Redakcja: Micha miaek

    Politechnika

    Warszawska

    ReDSeeDS

    Podrcznik Uytkownika(dla wersji 0.6.2)

    Lucyna Skrzypek, Piotr abcki

    Redakcja: Micha miaek

    smog.iem.pw.edu.pl

    Podrcznik Uytkownika

    Lucyna Skrzypek, Piotr abcki

    smog.iem.pw.edu.pl

  • 1

    1 Wprowadzenie

    Gwn cech narzdzia ReDSeeDS jest moliwo tworzenia oprogramowania w oparciu o specyfi-kacj wymaga. Powoduje to zmian proporcji udziau analityka i programisty w procesie wytwarza-nia oprogramowania na korzy analityka. ReDSeeDS wykorzystuje wszystkim znan notacj przy-padkw uycia, scenariuszy i sownika poj. Przy poprawnej ich definicji wedug okrelonego wzor-ca, moliwe staje si automatyczne wygenerowanie znacznej iloci kodu aplikacji. Skutkuje to ograni-czeniem roli programisty tylko do odpowiedniego uzupenienia wygenerowanego przez narzdzie ReDSeeDS kodu.

    Rysunek 1: Gwny ekran narzdzia ReDSeeDS

    Wymagania wprowadzane do ReDSeeDSa formuowane s w intuicyjnym jzyku RSL (Requirements Specification Language) za pomoc wbudowanego w narzdzie edytora RSL. Jest to fundament dzia-ania tego narzdzia, a jego budow w duym uproszczeniu mona zobrazowa ponisz zalenoci:

    RSL = aktorzy + przypadki uycia + scenariusze + sownik poj

    RSL jest pierwszym jzykiem czcym ze sob cechy sownika i modelowania pojciowego, co znacznie uatwia zrozumienie wymaga. Jzyk ten umoliwia definiowanie relacji pomidzy elemen-tami dziedziny i zobrazowanie ich na diagramach, a take okrela, w jaki sposb naley formowa wyraenia i pojcia, aby potem moliwe byo poprawne wygenerowanie architektury aplikacji. Pod tym wzgldem jzyk RSL czerpie wiele schematw dziaa z jzyka UML. W scenariuszach zalecane jest budowanie zda jak najprostszych, najlepiej trzyma si schematu Podmiot-Orzeczenie-Dopenienie.

    Jzyk RSL zosta opisany przy uyciu tak zwanego metamodelu. Metamodel jest zbiorem modeli opi-sujcych w sposb abstrakcyjny inne modele. W praktyce, taki model jest reprezentowany przez zbir

  • 2

    odnoszcych si do siebie metaklas i tekstu. Odpowiednie zdefiniowanie relacji pomidzy metaklasa-mi pozwala jasno okreli gramatyk obowizujc w danym jzyku.

    Modele oraz metamodele opisujemy na 4 poziomach:

    M0 poziom instancji modelu (zawiera rzeczywiste obiekty klas zawartych w modelu), M1 poziom modelu (np. klasy w jzyku UML), M2 poziom metamodelu (metaklasy odpowiadajce elementom jzyka np. klasom), M3 poziom metametamodelu (meta klasy odpowiadajce elementom jzyka poziomu M2).

    Przykad metamodelu na poziomie M2, modelu na poziomie M1 i rzeczywistej skadni na poziomie M0 przedstawione zostay na Rysunku 2: [3]

    Rysunek 2: Metamodel [3]

    Charakterystyczne dla ReDSeeDSa jest generowanie kodu w jzyku programowania Java w architek-turze Model-View-Presenter. Na podstawie modelu wymaga automatycznie tworzona jest wikszo logiki aplikacji z wykorzystaniem frameworka dla aplikacji webowych Echo3, a take obiekty DAO (Data Access Objects) oraz DTO (Data Transfer Objects). Na Rysunku 3 przedstawiony jest schemat transformacji z przykadow specyfikacja w jzyku RSL przeksztacon do kodu.

  • 3

    Rysunek 3 Przykadowy schemat procesu transformacji [3]

    Aby wygenerowa kod, ReDSeeDS wykorzystuje narzdzia Enterprise Architect lub Modelio, w kt-rych po przeprowadzeniu odpowiedniej transformacji wymaga oprogramowania automatycznie gene-rowany jest szablon kodu aplikacji, ktry jest potem uzupeniany przez programist. Cay opisany powyej proces obrazuje Rysunek 4.

    Rysunek 4: Diagram procesu translacji [2]

  • 4

    2 Praca w ReDSeeDS W niniejszym rozdziale przedstawione zostan istotne aspekty zwizane z prac nad wymaganiami oprogramowania definiowanymi w narzdziu ReDSeeDS. Omwione zostan takie kwestie jak: two-rzenie nowego projektu, konwencja pisania scenariuszy przypadkw uycia, dodawanie i zarzdzanie pojciami oraz proces walidacji efektw pracy i generowania kodu. Wszystkie te elementy zostan zilustrowane przy pomocy przykadowej specyfikacji wymaga dla systemu obsugi Miejskiego Orodka Sportu i Rekreacji.

    2.1 Uruchamianie narzdzia i zarzdzanie projektem Narzdzie ReDSeeDS uruchamiamy poprzez uruchomienie odpowiedniego pliku wsadowego (redse-eds.bat). Plik ten uruchamia najpierw tzw. serwer terminologii JWGNL, a nastpnie zasadnicz apli-kacj (redseeds.exe). Serwer terminologii mona zminimalizowa w trakcie pracy z narzdziem, ale powinien on by zawsze uruchomiony. Serwer odpowiada za zarzdzanie terminologi uywan w specyfikacjach wymaga. Terminologia jest wykorzystywana w ramach ponownego wykorzystywania wymaga, ktre nie jest omawiane w niniejszym przewodniku.

    Po uruchomieniu aplikacji, naley wybra istniejc lub utworzy now przestrze robocz (works pace). Przestrze robocza to katalog, w ktrym ReDSeeDS przechowuje ca tworzon specyfikacj. W celu przeniesienia pracy na inny komputer, naley skopiowa cay katalog zawierajcy przestrze robocz. Wskazane jest uycie programu pakujcego (zip) i umieszczenie katalogu w pliku spakowa-nym. Oprcz przestrzeni roboczej, naley rwnie przenie plik wordnetgraph.tg zawarty w kata-logu JWGNL.

    W celu stworzenia nowego projektu uytkownik powinien wybra opcj File New Project, a w kolejnym kroku wybra opcj New Software Case Project i nada projektowi nazw. Po tej czynno-ci niezbdne jest utworzenie nowego pakietu wymaga poprzez wybranie opcji Requirement Speci-fication New Requirements Package. Moliwe jest utworzenie wielu paczek wymaga, w zalenoci od potrzeby. W omawianym projekcie specyfikacja wymaga zostaa podzielona logicznie na podpakiety: najpierw ze wzgldu na rodzaj uytkownika (klient lub manager) a nastpnie kady z nich na odpowiednie moduy funkcjonalne (klub fitness, pywalnia, promocje, zarzdzanie rezerwa-cjami itp.). Taki podzia wprowadza do projektu ad i porzdek, co znacznie uatwia pniejsz prac nad projektem. Efekt tego dziaania jest widoczny na Rysunku 5.

    Rysunek 5: Podzia projektu na pakiety

  • 5

    2.2 Tworzenie przypadkw uycia Po stworzeniu podpakietw przychodzi pora na dodawanie do nich przypadkw uycia. Aby doda taki element naley najpierw stworzy diagram przypadkw uycia uywajc opcji New Use Case Diagram. Dziki temu otworzy si nowa strona, na ktrej bdzie moliwe ukadanie przypadkw uycia oraz aktorw. Aby doda przypadek uycia, wystarczy przecign element Use Case lub Ac-tor z paska bocznego Palette lub uy menu kontekstowego Add Use Case lub Add Actor. W przypadku dodania nowego aktora na diagramie, automatycznie jest on rwnie dodawany w folderze Domain Specification Actors.[4][5]

    Po umieszczeniu na diagramie wszystkich wybranych aktorw i przypadkw uycia mona poczy relacj aktorw z przypadkami uycia poprzez przecignicie linii z jednego elementu do drugiego. Naley zauway, e powysze dziaanie nie znajduje zastosowania, jeeli uytkownik chce poczy ze sob relacjami przypadki uycia. Aby zobaczy na diagramie takie poczenie np. pomidzy dwo-ma przypadkami uycia, naley w scenariuszu jednego z przypadkw uycia doda zdanie typu invoke (wicej o pisaniu scenariuszy w dalszej czci rozdziau). Nastpnie z listy rozwijanej uyt-kownik powinien wybra, do ktrego elementu docelowego odnosi si ta relacja. Po tym wyborze i zapisaniu zmian, na diagramie pojawi si linia przerywana czca wybrane przypadki uycia. Istotny jest fakt, e w jzyku RSL nie wyrnia si typowych dla jzyka UML relacji extend i invoke, lecz relacje invoke, wprowadzone w jzyku RSL.

    Na rysunkach 6 i 7 pokazano przykadowe diagramy przypadkw uycia dla systemu zarzdzania MOSiR. Wiecej diagramw mona znale w przykadowym modelu systemu MOSiR dostpnym na stronie www.redseeds.eu.

    Rysunek 6: Korzystanie z fitness-klubu przez klienta

  • 6

    Rysunek 7: Zarzdzanie fitness-klubem przez managera

    2.3 Tworzenie scenariuszy i poj w sowniku Po zdefiniowaniu przypadkw uycia i zalenoci pomidzy nimi, kolejnym krokiem jest napisanie scenariuszy. W tym celu po otworzeniu szczegw danego przypadku uycia naley przej do za-kadki scenariusza (o tej samej nazwie co przypadek uycia). Uytkownik musi zainicjowa pisanie scenariusza wciskajc przycisk Create SVO Sentence. Nastpnie mona rozpocz wprowadzanie kolejnych zda w scenariuszu. Powyej pierwszego zdania znajduje si sekcja Precondition, w ktrej uytkownik moe wprowadzi warunki pocztkowe, jakie musz by spenione, aby dany przypadek uycia si rozpocz.

    Pisanie scenariuszy powinno odbywa si zgodnie ze specyficzn konwencj. Zdania powinny mie budow Podmiot Orzeczenie Dopenienie (rzeczownik czasownik rzeczownik) czyli np. System zapisuje dane ksiki. Moliwe jest rwnie dodawanie dopenienia dalszego, ale taka praktyka nie jest zalecana. Generaln zasad jest budowanie zda moliwie jak najkrtszych i najprostszych. Po-zwoli to unikn generowania niepotrzebnych elementw w kodzie aplikacji. Zdecydowanie odradza si uywania w zdaniach scenariusza polskich znakw, ktre wprawdzie s poprawnie obsugiwane przez narzdzie ReDSeeDS, ale w pniejszym etapie znaki te s przenoszone na kod. Moe to unie-moliwi jego skompilowanie.

    Uytkownik ma moliwo utworzenia scenariusza alternatywnego. Aby to zrobi, naley w trakcie pisania scenariusza gwnego wybra opcj Fork scenario. Efektem tego jest pojawienie si sekcji, w ktrej mona wpisa warunek, jaki musi zosta speniony, aby scenariusz gwny by kontynuowany. Jednoczenie zostanie utworzona nowa karta w szczegach danego przypadku uycia, zawierajca nowy scenariusz alternatywny. Warto zauway, e jeli uytkownik wybierze opcj Fork scenario w trakcie pisania scenariusza gwnego (np. po 4 zdaniach), w scenariuszu alternatywnym bd widocz-ne wszystkie zdania, znajdujce si w scenariuszu gwnym przed wywoaniem opcji Fork scenario. Pod nimi ponownie pojawia si sekcja, w kt

Recommended

View more >