(DI1708) Projektowanie oprogramowania
Aktualizacja dla semestru 2011Z
Wykład
Prowadzący: Michał Śmiałek
Cel i treść przedmiotu
Celem przedmiotu jest nauczenie właściwej organizacji procesu inżynierii oprogramowania w zakresie projektowania oprogramowania. Studenci poznają notacje oraz techniki specyfikowania architektur oraz projektów szczegółowych oprogramowania. Przedstawiony jest sposób zastosowania języka UML do projektowania systemów. Pokazano, w jaki sposób usprawnić tworzenie oprogramowania poprzez budowę modeli projektowych, zgodnych z wymaganiami, a jednocześnie ułatwiających zrozumienie złożonej struktury i dynamiki kodu. Studenci otrzymują wiedzę na temat podziału systemu na podsystemy oraz warstwowej struktury systemów. Dowiadują się też, w jaki sposób projektować logikę aplikacji, logikę dziedziny oraz komponenty odpowiedzialne za interakcję z użytkownikiem. W ramach zajęć projektowych uzyskują praktykę w zakresie organizacji zespołów projektantów oraz zespołowego tworzenia nietrywialnych projektów dla systemów oprogramowania.
Zasady zaliczenia
Wykład. Sprawdzian końcowy, za który można otrzymać 55 pkt. Aby zaliczyć sprawdzian należy uzyskać co najmniej 28 pkt. Podczas wykładów można również uzyskać dodatkowe punkty za wykonane ćwiczenia. Punkty te są doliczane do sumy punktów za cały przedmiot i ułatwiają uzyskanie lepszej oceny. Podczas wykładu odbędzie się konkurs na najlepsze notatki.
Projekt. Projekt jest ściśle powiązany z wykładem. Wykonywany jest w dużych grupach, których zadaniem jest zaprojektowanie systemu na podstawie zadanej specyfikacji wymagań. Za wykonanie projektu można w sumie otrzymać 45 pkt. Aby zaliczyć projekt należy otrzymać co najmniej 23 pkt. Na ocenę z projektu składa się ocena grupy (25 pkt.) oraz ocena indywidualna (20 pkt.).
Ocena końcowa. Należy zaliczyć zarówno sprawdzian końcowy, jak i projekt. Do oceny końcowej punkty ze sprawdzianu i projektu sumują się. Od 51 pkt, co 10 pkt. kolejna ocena od 3,0 do 5,0.
Literatura
- R. S. Pressman, „Praktyczne podejście do inżynierii oprogramowania”, Wydawnictwa Naukowo-Techniczne, 2004
- I. Sommerville, „Inżynieria oprogramowania”, Wydawnictwa Naukowo-Techniczne, 2003
- Michał Śmiałek, „Zrozumieć UML 2.0”, Helion, 2005
Plan wykładu
Wykład 1 |
Wprowadzenie i przypomnienie. Regulamin przedmiotu. Przypomnienie podstawowych modeli języka UML. Przypomnienie modeli i struktury specyfikacji wymagań. Omówienie treści przedmiotu. |
Wykład 2 |
Miejsce projektowania oprogramowania w cyklu wytwórczym. Przypomnienie faz cyklu kaskadowego i iteracyjnego. Po co projektujemy oprogramowanie? Projekt systemu jako realizacja wymagań. Modelowanie wizualne jako podstawa projektowania. Rodzaje modeli i ich zastosowanie podczas projektowania. Podział na projektowanie architektoniczne i projektowanie podsystemów. Ogólna struktura projektu systemu. |
Wykład 3 |
Wprowadzenie do projektowania architektonicznego. Co to jest architektura oprogramowania? Mnogość definicji architektury. Architektura logiczna: podział na komponenty i warstwy; modelowanie wymiany komunikatów między komponentami. Architektura fizyczna: podział na maszyny; przydział komponentów do maszyn; "cienki" i "gruby" klient. |
Wykład 4 |
Statyczne modele architektoniczne. Komponenty i diagramy komponentów. Definiowanie interfejsów oraz obiektów transferu danych. Diagramy montażu. Mapowanie wymagań na statyczne modele architektoniczne. |
Wykład 5 |
Dynamiczne modele architektoniczne. Dynamika działania komponentów. Diagramy sekwencji na poziomie architektonicznym. Linie życia i komunikaty. Mapowanie wymagań na dynamiczne modele architektoniczne. |
Wykład 6 |
Metodyka modelowania architektonicznego. Architektura a technologie programistyczne. Dostosowanie architektury do konkretnej technologii. Dokumentowanie architektury - struktura specyfikacji architektonicznej. Techniki tworzenia specyfikacji - jednoczesna budowa modelu statycznego (interfejsy) i dynamicznego (interakcje). |
Wykład 7 |
Wprowadzenie do projektowania podsystemów. Złożoność systemów oprogramowania. Idea podziału systemu na podsystemy. Modelowanie "wnętrza" komponentów. Zależność struktury podsystemu od struktury całego systemu. |
Wykład 8 |
Projektowanie podsystemów warstwy prezentacji. Realizacja interfejsów programowych przez klasy projektowe. Korzystanie z interfejsów programowych innych komponentów. Reakcja na interakcje od użytkownika (obsługa zdarzeń). Reakcja na interakcje z warstwy logiki aplikacji (obsługa poleceń wyświetlania okienek). |
Wykład 9 |
Projektowanie podsystemów warstwy logiki aplikacji. Realizacja przypadków użycia. Struktura komponentów logiki aplikacji - realizacja interfejsów realizujących przypadki użycia. Sterowanie działaniem systemu przez komponenty logiki aplikacji. Interakcje na poziomie architektonicznym i na poziomie szczegółowym. |
Wykład 10 |
Projektowanie podsystemów warstwy logiki dziedzinowej. Realizacja słownika dziedzinowego - struktura komponentu logiki dziedzinowej. Projektowanie operacji przetwarzania danych. Projektowanie interakcji z bazą danych. |
Wykład 11 |
Metodyka modelowania podsystemów. Dokumentowanie projektu podsystemów - struktura specyfikacji podsystemów. Projekt systemu jako suma projektów podsystemów. |
Wykład 12 |
Organizacja wytwarzania oprogramowaniu w oparciu o projekt. Podział na zespoły projektowo-implementacyjne. Współpraca między zespołami - interfejsy. Implementacja i testowanie systemu w oparciu o wymagania i projekt. |
Wykład 13 |
Wprowadzenie do wzorców projektowych. Po co nam wzorce projektowe? Sposoby zapisu wzorców. Przykładowe wzorce projektowe: Obserwator, Fasada, DTO. Wzorzec architektoniczny: MVC. Wzorce a przejrzystość kodu systemu. |
Wykład 14 |
Ćwiczenia z projektowania oprogramowania. Podsumowanie treści i wykładu. Rozwiązywanie typowych zadań projektowych. |
Projekt
Prowadzący: Szymon Drejewicz
Grupy projektowe składają się z ok. 10 osób (po ok. 3 grupy projektowe na grupę dziekańską). Grupy projektowe oraz indywidualni studenci otrzymują punkty za przygotowanie do spotkań projektowych. Na każdym spotkaniu można zdobyć 2-3 pkt. grupowe lub 5 pkt. indywidualnych. Spotkania typu "konsultacje" są oceniane indywidualnie (konsultacje prowadzą kolejno 2 lub 3 wybrane osoby z grupy). Pozostałe spotkania oceniane są grupowo. Na spotkaniu podsumowującym wystawiana jest ocena indywidualna za indywidualnie wykonywane elementy projektu systemu.
Każda grupa składa się z 1 głównego architekta, 1 administratora oraz ok. 8 projektantów.
Rolą głównego architekta jest zapewnianie terminowego aktualizowania modelu projektowego przez projektantów i dokonywanie prezentacji modelu całej grupy podczas spotkań - konieczna jest dobra znajomość aktualnego stanu modelu. Główny architekt ściśle współpracuje z administratorem w celu przygotowania prezentacji na kolejne spotkania. Główny architekt zapewnia spójność całego modelu projektowego i koordynuje działania projektantów. Kierownik jest odpowiedzialny za model architektoniczny systemu. Kierownikiem może zostać tylko osoba, która posiada wysoką średnią ocen z poprzednich semestrów (w razie wątpliwości sprawdzana jest ocena z przedmiotu Modelowanie oprogramowania w języku UML).
Rolą projektanta jest wykonanie powierzonego sobie fragmentu modelu projektowego. Bardzo ważne jest utrzymanie spójności całej specyfikacji - zgodność z modelami pozostałych projektantów.
Rolą administratora jest utrzymywanie działania narzędzi EA oraz SVN. Zadaniem administratora jest również: 1) bieżące generowanie z modeli wymagań diagramów dla celów prezentacji - konieczna jest dobra orientacja w aktualnej strukturze modeli, 2) generowanie na bieżąco dokumentacji (dokument na bazie modelu wymagań, do wglądu na każdych zajęciach typu "omówienie" i "prezentacja", 3) przygotowanie testów systemu. Bardzo istotne jest prawidłowy podział dokumentacji na rozdziały i odpowiednie formatowanie rozdziałów.
Projekt wykonywany jest w narzędziu Enterprise Architect, przy wykorzystaniu systemu SVN zintegrowanego z e-Dziekanatem. Każda grupa projektowa ma przydzielone w systemie SVN repozytorium. Repozytorium należy zintegrować z narzędziem Enterprise Architect, zgodnie z instrukcją (help) zawartą w narzędziu. Model należy podzielić na pakiety. Za każdy pakiet odpowiada jeden projektant. Za pakiet architektoniczny odpowiada przede wszystkim główny architekt i wszyscy projektanci. Pakiety powinny być wersjonowane w systemie SVN zgodnie z instrukcją EA. UWAGA: prowadzący ma w każdej chwili wgląd do repozytorium.
Spotkanie 1 |
Przedstawienie regulaminu projektu. Ustalenie składu zespołów. Przydzielenie i wymiana specyfikacji wymagań z przedmiotu IWO między zespołami. Ustalenie harmonogramu spotkań. Omówienie pierwszego zadania - przygotowania prezentacji wymagań. |
Spotkanie 2 |
Prezentacja i przekazanie specyfikacji wymagań. Każdy zespół omawia (prezentuje na ekranie) otrzymaną od innego zespołu specyfikację wymagań. Uzgadnianie wymagań między zespołami. (1 pkt. grup) |
Spotkanie 3 |
Omówienie wstępnych założeń architektonicznych systemu. Omówienie przez głównego architekta wstępnego modelu komponentów (ok. 8 komponentów w podziale na 3 warstwy) wraz ze wstępną specyfikacją interfejsów. Omówienie planu implementacji systemu - wybór przypadków użycia do iteracji 1 i 2. (2 pkt. grup.) |
Spotkanie 4 |
Prezentacja wstępnych założeń architektonicznych systemu. Prezentacja przez głównego architekta wstępnego modelu komponentów (ok. 8 komponentów w podziale na 3 warstwy) wraz z rozszerzoną wstępną specyfikacją interfejsów. Prezentacja planu implementacji systemu - wybór przypadków użycia do iteracji 1 i 2. (2 pkt. grup.) |
Spotkanie 5 |
Konsultacje modelu statycznego i dynamicznego systemu. Ustalenie szczegółowych rozwiązań modelu architektonicznego - modelu komponentów (w tym interfejsy) oraz modelu interakcji (diagramy sekwencji). (5 pkt. ind.) |
Spotkanie 6 |
Omówienie modelu architektonicznego systemu. Omówienie przez głównego architekta kompletnego modelu komponentów systemu wraz ze specyfikacją interfejsów. Omówienie przez projektantów modeli interakcji (diagramów sekwencji) dla poszczególnych przypadków użycia systemu. (2 pkt. grup.) |
Spotkanie 7 |
Prezentacja modelu architektonicznego systemu. Prezentacja przez głównego architekta ostatecznego modelu komponentów systemu wraz ze specyfikacją interfejsów. Prezentacja przez projektantów modeli interakcji (diagramów sekwencji) dla poszczególnych przypadków użycia systemu. Omówienie przydziału komponentów do projektantów (każdy projektant dostaje do zaprojektowania co najmniej jeden komponent). (3 pkt. grup.) |
Spotkanie 8 |
Konsultacje projektów warstwy prezentacji. Ustalenie szczegółowych rozwiązań dla komponentów warstwy prezentacji - modelu klas (w tym realizacja interfejsów) oraz modelu interakcji (diagramy sekwencji dla realizacji operacji interfejsów). (5 pkt. ind.) |
Spotkanie 9 |
Omówienie projektu dla pierwszej iteracji. Omówienie przez głównego architekta postępów prac i uzgodnień/zmian w zakresie definicji interfejsów. Omówienie przez projektantów stanu prac nad projektami komponentów. (2 pkt. grup.) |
Spotkanie 10 |
Konsultacje projektów warstwy logiki aplikacji. Ustalenie szczegółowych rozwiązań dla komponentów warstwy logiki aplikacji - modelu klas (w tym realizacja interfejsów) oraz modelu interakcji (diagramy sekwencji dla realizacji operacji interfejsów). (5 pkt. ind.) |
Spotkanie 11 |
Konsultacje projektów warstwy logiki dziedzinowej. Ustalenie szczegółowych rozwiązań dla komponentów warstwy logiki dziedzinowej - modelu klas (w tym realizacja interfejsów) oraz modelu interakcji (diagramy sekwencji dla realizacji operacji interfejsów). (5 pkt. ind.) |
Spotkanie 12 |
Testowanie systemu dla pierwszej iteracji. Testy są wykonywane dla pierwszego zestawu przypadków użycia ustalonego podczas Spotkania 3. Testy polegają na odczytaniu scenariuszy przypadków użycia i jednoczesnym przejściu przez diagramy sekwencji na poziomie architektury systemu i na poziomie poszczególnych komponentów wszystkich warstw. Test przechodzi pomyślnie jedynie jeśli istnieją wszystkie operacje wszystkich komponentów realizujące dany scenariusz przypadku użycia. UWAGA: za pomyślne wykonanie testów odpowiada Administrator, który mam za zadanie sprawdzić kompletność modeli i wykonać testy przed zajęciami. (5 pkt. grup.) |
Spotkanie 13 |
Prezentacja projektu dla drugiej iteracji. Omówienie przez głównego architekta i projektantów stanu prac nad rozszerzeniem projektu dla drugiego zestawu przypadków użycia. (3 pkt. grup.) |
Spotkanie 14 |
Testowanie systemu dla drugiej iteracji. Testy są wykonywane dla drugiego zestawu przypadków użycia ustalonego podczas Spotkania 3. Testy wykonywane są jak podczas spotkania 12. (5 pkt. grup.) |
Spotkanie 15 |
Podsumowanie. (15 pkt. ind.) |