Zajęcia laboratoryjne z przedmiotu IOP

Zajęcia laboratoryjne z przedmiotu IOP
Warszawa, październik 2013
dr inż. Marcin Szlenk
dr inż. Andrzej Zalewski
Cel zajęć ............................................................................................................................. 1
Model analityczny .............................................................................................................. 1
Organizacja prac ........................................................... Błąd! Nie zdefiniowano zakładki.
3.1. Zespoły ................................................................. Błąd! Nie zdefiniowano zakładki.
3.2. Terminy ................................................................ Błąd! Nie zdefiniowano zakładki.
3.3. Zmiana tematu zadania ......................................... Błąd! Nie zdefiniowano zakładki.
4. Zasady oceny ...................................................................................................................... 2
4.1. Ocena zadania ...................................................... Błąd! Nie zdefiniowano zakładki.
4.2. Ocena końcowa .................................................... Błąd! Nie zdefiniowano zakładki.
5. Sposób przygotowania dokumentów ................................................................................. 2
6. Zadania ............................................................................................................................... 2
6.1. Modelowanie przypadków użycia środowiska .......................................................... 2
6.2. Modelowanie przypadków użycia systemu ................................................................ 3
6.3. Modelowanie pojęć systemu ...................................................................................... 3
7. Wskazówki ......................................................................................................................... 4
8. Pytania i odpowiedzi .......................................................................................................... 4
8.1. Rozpoznanie dziedziny .............................................................................................. 4
1.
2.
3.
1. Cel zajęć
Zajęcia mają na celu zapoznanie studentów z problematyką przygotowywania dokumentacji
analitycznej w projekcie budowy systemu informatycznego. Poprawne wykonanie stawianych
w trakcie laboratorium zadań wymaga zarówno opanowania wybranych technik i notacji, jak
i zapoznania się ze wskazanymi w ramach poszczególnych zadań dziedzinami wiedzy
i obszarami zastosowań systemów informatycznych.
2. Model analityczny
Dokumentacja analityczna powstająca w ramach projektu informatycznego stanowi środek
komunikacji i efekt porozumienia pomiędzy przyszłym użytkownikiem tego systemu
a zespołem informatycznym: projektantami i programistami. Dokumentacja powinna zostać
przygotowana w taki sposób, aby:
1. Użytkownicy posiadający wiedzę specyficzną dla dziedziny zastosowań byli w stanie
potwierdzić, że dokumentacja ta prawidłowo opisuje procesy, których realizację będzie wspomagał system informatyczny oraz właściwie określa funkcje tego systemu.
2. Projektanci i programiści byli w stanie, jedynie na podstawie tej dokumentacji, zaproponować zgodną z oczekiwaniami użytkownika implementację opisanych w dokumentacji analitycznej funkcji systemu.
1/5
3. Zasady oceny
4. Sposób przygotowania dokumentów
Rozwiązanie każdego zadania musi zostać przygotowane i przekazane w postaci jednolitego
dokumentu. Dokumenty muszą zostać przekazane w postaci wydruku. Strony wydruku powinny zostać połączone zszywaczem, ew. spinaczem. Należy unikać oprawiania dokumentów, w tym ich bindowania, a ponadto oszczędzać papier stosując druk dwustronny.
Dokument musi zostać napisany czcionką szeryfową o rozmiarze od 10 do 12 punktów przy
rozmiarze interlinii 1.0. Tekst powinien zostać wyrównany do lewego i prawego marginesu.
Na dole strony tytułowej dokumentu musi zostać umieszczona tabelka (metryka dokumentu)
zgodna z następującym wzorcem:
Przedmiot:
Semestr:
Zadanie (nr/nazwa):
Temat (nr/treść):
Zespół (członkowie):
IOP
Zima 2013
1. Rozpoznanie środowiska
1. Moduł kontrolingowy systemu FK
Stefan Abacki, Jan Kowalski
Wszystkie strony dokumentu powinny mieć jednolitą numerację. Numery strony powinien
znajdować się w prawym dolnym rogu. Na drugiej stronie dokumentu powinien znajdować
się spis treści. Zamieszczone w dokumentach diagramy mogą zostać opracowane za pomocą
dowolnego narzędzia wspomagającego notację UML, np. Rational Rose, MS Visio.
Dokumenty muszą zostać opracowane samodzielnie – cytaty z innych opracowań nie mogą
stanowić więcej niż 20% treści przekazywanych do oceny dokumentów i muszą zostać wskazane ich źródła. W przypadku stwierdzenia kopiowania cudzych rozwiązań, w szczególności opracowanych przez studentów lat poprzednich, zespół automatycznie otrzymuje
za zadanie ocenę 2.
5. Zadania
5.1. Modelowanie przypadków użycia środowiska
Cel
Dokument powinien opisywać specyfikację interakcji (dialogu) użytkowników zewnętrznych
(np. klientów, innych organizacji lub istniejących systemów informatycznych) z daną organizacją (w tym jej pracownikami). Dana organizacja pełni rolę środowiska, w którym działał
będzie projektowany system informatyczny.
Wyniki prac
Lista aktorów – lista użytkowników i systemów informatycznych podejmujących interakcję
ze środowiskiem wraz z ich zwięzłym i precyzyjnym opisem.
Diagramy przypadków użycia środowiska – diagramy ilustrujące przypadki użycia środowiska (nazywane też biznesowymi przypadkami użycia) i związki z odpowiednimi aktorami,
sporządzone zgodnie z notacją UML. Przyjęty poziom abstrakcji („szczegółowość” przypadków użycia, a zatem i ich liczba) powinien być na tyle niewielki, by nie wymagał definiowania związków pomiędzy przypadkami użycia.
2/5
Specyfikacje przypadków użycia środowiska – zwięzły opis przypadków użycia oraz specyfikacje czynności wykonywanych w ramach poszczególnych przypadków zapisane jako
diagramy czynności (activity diagram) w notacji UML. Na diagramach należy w szczególny
sposób oznaczyć czynności (węzły diagramów), które wspierać będzie projektowany system
informatyczny, np. opatrując je stereotypem <<system>>.
Uwaga:
Dla każdego przypadku użycia na diagramie należy opracować jego specyfikację (diagram
czynności).
5.2. Modelowanie przypadków użycia systemu
Cel
Dokument powinien opisywać specyfikację interakcji (dialogu) użytkowników z projektowanym systemem informatycznym, umożliwiając zaprojektowanie jego interfejsu i sporządzenie
makiety tego systemu.
Wyniki prac
Lista aktorów – lista użytkowników i systemów informatycznych podejmujących interakcję
z projektowanym systemem.
Diagramy przypadków użycia systemu – sporządzone zgodnie z notacją UML diagramy
ilustrujące przypadki użycia systemu i ich związki z odpowiednimi aktorami, oraz zależności
pomiędzy przypadkami użycia (<<include>>, <<extend>>, generalizacja/specjalizacja).
Specyfikacje przypadków użycia systemu – specyfikacje przebiegu interakcji w obrębie
poszczególnych przypadków użycia w postaci opisu warunku początkowego, scenariusza
podstawowego, scenariuszy alternatywnych, punktów rozszerzeń i warunku końcowego.
Projekty ekranów – graficzny szkic lub zrzut z ekranu komputera, ekranu/formularza służącego do wprowadzania danych lub wybierania opcji przez użytkownika w ramach danego
przypadku użycia.
Uwaga:
Dla każdego przypadku użycia na diagramie należy opracować jego specyfikację oraz projekt
ekranu (jeśli z przypadkiem użycia wiąże się wprowadzanie danych, wybieranie opcji).
5.3. Modelowanie pojęć systemu
Cel
Dokument powinien opisywać specyfikację pojęć związanych z projektowanym systemem.
Wyniki prac
Diagram klas – diagram klas przedstawiający pojęcia dotyczące projektowanego systemu
informatycznego, sporządzony zgodnie z notacją UML. Specyfikacje klas (pojęć) powinny
obejmować specyfikacje atrybutów, dla których należy wyspecyfikować odpowiedni typ niezwiązany jednak z określoną platformą implementacji, np. LiczbaCałkowita, LiczbaRzeczywista, Napis itp. Należy wyspecyfikować związki pomiędzy klasami: związek asocjacji (i jej
szczególne przypadki – agregację, kompozycję) wraz z licznością końców, oraz związek genralizacji/specjalizacji.
Specyfikacja klas – zwięzły opis znaczenia poszczególnych klas i ich atrybutów.
3/5
Uwaga:
Nie podajemy operacji dla klas.
6. Wskazówki
Modelowanie środowiska a modelowanie wymagań systemowych
Przypadki użycia na poziomie środowiska (p. 5.1) reprezentują interakcję aktorów z opisywanym środowiskiem, natomiast przypadki użycia na poziomie systemu (p. 5.2) opisują interakcję aktorów z systemem informatycznym. W obu przypadkach aktorzy mogą być inni, np.
aktorem dla dziekanatu będzie wykładowca, który składa arkusz z ocenami, a aktorem dla
systemu informatycznego wspierającego pracę dziekanatu będzie pracownik dziekanatu, który
wpisuje oceny do systemu. Przypadki użycia systemu wynikają naturalnie z procesów opisanych przypadkami użycia środowiska.
Podobna zależność dotyczy pojęć używanych przy opisie środowiska (p. 5.1) i pojęć na poziomie systemu (p. 5.3). Cześć pojęć pojawiających się przy opisie środowiska, pojawi się
również przy opisie systemu. W drugim przypadku mogą pojawić się jednak nowe pojęcia
związane z korzystaniem z projektowanego systemu (wprowadzaniem/wyświetlaniem określonych danych, konfiguracją).
Weryfikacja jakości tworzonych dokumentów
Skutecznym techniką weryfikacji przydatności dokumentu analitycznego opracowanego
w ramach realizacji kolejnego zadania jest przekazanie go z prośbą o ocenę osobie zarówno
nie będącej specjalistą z zakresu analizowanego procesu jak i nie zaangażowanej w prace analityczne.
7. Pytania i odpowiedzi
Poniżej zamieszczone zostały odpowiedzi na pytania studentów. Lista ta będzie sukcesywnie
uzupełniana.
7.1. Rozpoznanie dziedziny
Pytanie: Czy ma to być cos w rodzaju propozycji kształtu programu obsługującego dane zagadnienie, czy raczej czysta analiza?
Odpowiedź: Powinien Pan przeprowadzić analizę procesu prowadzenia działań kontrolnych
przez NIK – czyli tego jak taka kontrola przebiega – kto podejmuje decyzje o przeprowadzeniu kontroli (w jakim trybie zapada decyzja o przeprowadzeniu kontroli), kto przeprowadza,
jakie informacje są gromadzone w toku kontroli, jakie dokumenty (zbiory informacji) towarzyszą poszczególnym fazom kontroli, jaki jest wynik kontroli.
Pytanie: Jakich głównych wytycznych należy się trzymać (z wykładu, któregoś podręcznika
czy może innych źródeł)?
Odpowiedź: Nie ma żadnych głównych wytycznych poza czytelnością, zwięzłością i zrozumiałością. Proszę zwięźle przedstawić sposób prowadzenia działań kontrolnych przez NIK.
Zadanie nie jest algorytmiczne, lecz twórcze.
Pytanie: Czy wystarczy ze strony NIKu pozyskać dokumenty dotyczące kontroli i na podstawie tego pisać, czy raczej szukać materiałów na stronach jakichś firm (jeśli tak, to jakich?)
zajmujących się tworzeniem programów do obsługi tego typu organizacji?
4/5
Odpowiedź: Odwołanie do odpowiednich źródeł informacji – to niestety leży po Pana stronie
i podlega ocenie.
Pytanie: Jaka ma być objętość stronicowa spisanego projektu, żeby nie został uznany za niewystarczający?
Odpowiedź: Objętość – adekwatna do zagadnienia – por. odp. na pyt. dot. głównych wytycznych.
Pytanie: Czy trzeba użyć jakiegoś specjalnego oprogramowania do tworzenia dokumentacji?
Odpowiedź: Nie.
5/5