dr inż. Jacek Szedel

Studia dzienne GLIWICE

 SDS
  s e r w i s   d l a   s t u d e n t ó w

   Inżynieria Programowania II    

    Opis przedmiotu  |  Regulamin  |  Materiały  |  Wyniki  |  Przesyłanie  |  O serwisie
Opisy ćwiczeń i zadania

Ćwiczenie 1 [IP2-WYM]

Ćwiczenie 2 [IP2-MDB]

Ćwiczenie 3 [IP2-MDS]

Ćwiczenie 4 [IP2-MDZ]

Ćwiczenie 5 [IP2-GEN]

Ćwiczenie 6 [IP2-IMP]

 

Zadania 2005

 

Linki

IBM-Rational Software

Object Management Group

Unified Modeling Language

Borland UML Tutorial

 

Aktualności
SDS - system dla słuchaczy

20-02-2005

Uruchomienie pierwszej roboczej kopii serwisu SDS w wersji greendream dla przedmiotu Inżynieria programowania II.

20-02-2005
Rozpoczynają się WPROWADZENIA. Informacje dla prowadzących są dostępne >>tutaj.

SDS - system dla słuchaczy

Ćwiczenie 2 - Model procesów biznesowych (4 godz.)

Cel ćwiczenia
Ćwiczenie umiejętności opisywania dziedziny problemowej i funkcjonalności systemu za pomocą notacji diagramów przypadków użycia (Use-Case). Wyrobienie umiejętności spojrzenia na system w kontekście czynności wykonywanych przez potencjalnych użytkowników (perspektywa użytkowników).

 

Zadania do wykonania

-zapoznanie się z treścią opisu zadania projektowego, dokumentu wymagań oraz słownikiem projektu,

-zapoznanie się z edytorem diagramów Use-Case programu Rational Rose,

-wskazanie użytkowników oraz operacji jakie będą wykonywać,

-opracowanie diagramu Use-Case na podstawie dokumentu wymagań i zbioru ustalonych operacji,

-kontrola spójności diagramu z dokumentem wymagań, ewentualne rozszerzenie dokumentu wymagań.

Wyniki pracy podlegające ocenie

Model: Diagram Przypadków Użycia.

Ocena w skali 2-5 co pół stopnia.

* Przesłać pliki: zadanie.mdl (plik programu Rational Rose).

 

è Przejdź do >> Warsztaty przypadków użycia

 

Wskazówki     

Do stworzenia diagramu należy zebrać wszystkie zdobyte wcześniej informacje (wymagania, słownik projektu). Należy "wyobrażać sobie" potencjalnych użytkowników, oraz to, jakie czynności owi użytkownicy będą realizować korzystając z powstającego systemu. Diagram może być, podobnie jak dokument wymagań, wielopoziomowy. Przykład takiego diagramu znajduje się na rysunku poniżej (przykład dotyczy rozliczania wspólnot mieszkaniowych). Notację diagramów przypadków użycia omawiano na wykładzie.

 

Mini warsztaty przypadków użycia (mini Use-Case Workshop)
 

Istota warsztatów

Warsztaty przypadków użycia to spotkanie osób uczestniczących w projekcie mające na celu opracowanie modelu biznesowego opisanego notacją diagramów przypadków użycia.
Opisany tutaj przebieg warsztatu jest nieco uproszczony w stosunku do wytycznych podanych w Rational Unified Process. Uproszczenia wynikają z ograniczeń dotyczących wyposażenia i czasu jakim dysponują studenci na laboratorium.
W tej uproszczonej wersji do realizacji warsztatu konieczne będą:
-co najmniej kilka kartek formatu A4,
-kilkanaście formatu A5 (lub również A4),
-pisaki w dwóch kolorach (np. niebieski, i czerwony),
-bardzo pomoże duży stół lub tablica do rozłożenia lub rozwieszenia kartek.
Ponadto konieczne jest posiadania opracowanego wcześniej dokumentu wymagań;.

Identyfikujemy aktorów


Na środku jednej z kartek formatu A4 rysujemy kształt przypominający chmurkę (korzystamy teraz z niebieskiego pisaka). Teraz zastanawiamy się jakie osoby (lub jakiego rodzaju użytkownicy) będą korzystały z systemu - to nasi Aktorzy. Zakładamy, że interesują nas tylko te osoby, które pracują bezpośrednio przy komputerze. Staramy się określić rolę takiej osoby (np. Magazynier, Administrator, Księgowy, Sprzedawca, itp.). Należy zwrócić uwagę na to, aby zbytnio nie generalizować i nie wskazywać aktorów typu „Użytkownik Systemu”. Dla każdego aktora rysujemy postać „chłopka” na kartce z narysowaną „chmurką” i opisujemy ją nazwą określającą rolę.
Rysunek powinien przedstawiać się następująco:



Identyfikujemy przypadki użycia

Teraz wyciągamy nową kartkę formatu A4 i przerysowujemy na nią aktorów jednego po drugim zastanawiając się za każdym razem gdy na kartce pojawia się nowy aktor, jakie czynności w systemie będzie on realizować. Dla każdej czynności dorysowujemy na kartce czerwonym pisakiem przypadek użycia. Nazywamy go skrótem myślowym dobrze określającym ową czynność.
Łączymy przypadek użycia strzałką z aktorem. Na kartce powstanie następujący rysunek:



Na koniec sprawdzamy, czy przypadki użycia się nie powielają lub, czy nie występują przypadki użycia podobne do siebie i w razie zaistnienia takiej sytuacji skreślamy powielające się przypadki użycia i pozostawiamy tylko jeden z nich.

Opisujemy przypadki użycia

Następnie bierzemy mniejsze kartki. Przenosimy na nie każdy przypadek użycia wraz z aktorem, który go realizuje (jeden przypadek użycia na jednej kartce). Opisujemy w trzech zadaniach czynność realizowaną w ramach danego przypadku użycia. Możemy też wypisać kolejne kroki wykonywane w ramach realizacji określonej funkcji. Zawartość kartki jest następująca:



Kojarzymy przypadki użycia z wymaganiami


Teraz musimy skonfrontować ze sobą dwie wizje systemu: tę zarysowaną w dokumencie wymagań oraz tę, którą opracowano w ramach warsztatu przypadków użycia. Do każdej z kartek zawierających opis przypadku użycia dopisujemy czerwonym pisakiem numer wymagania (numery wymagań) najniższego poziomu, które jest odpowiedzialne za realizację danej czynności. Nasza kartka wygląda teraz następująco:



Jeśli wykryjemy rozbieżności, a takie na pewno się pojawią, uzupełniamy, lub redukujemy specyfikację wymagań względnie usuwamy przypadek użycia.

Na zakończenie należy jeszcze zastanowić się, czy przypadki użycia są jednakowo szczegółowe (operują na jednakowym poziomie abstrakcji) i czy się nie powielają.
Teraz możemy wprowadzić nasze ustalenia do modelu w programie Rational Rose.
 


kontakt: Jacek Szedel