Wykład 1 2 październik 2018
Cel kursu Znacie język programowania oraz umiecie tworzyć proste aplikacje. Nie macie doświadczenia w tworzeniu dużych i złożonych systemów. Aby stworzyć duży system należy: zrobić analizę, zaprojektować a następnie zaimplementować system. Na kursie będziemy uczyć się systematycznego podejścia do analizowania i projektowania systemów. Nie można robić inaczej, bo: złożoność dziedziny i systemu zmiany wymagań i koncepcji
Aspekty poruszane na wykªadzie Analiza i projektowanie aplikacji Diagramy UML Metodyki wytwarzania oprogramowania Zasady GRASP Testowanie Wzorce projektowe Repozytoria: GIT, SVN Frameworki: Spring, Hibernate, JDBC Pewnie coś jeszcze ponadto...
Literatura Gamma, Helm, Johnson, Vlissides: "Wzorce projektowe. Elementy programowania obiektowego wielokrotnego użytku" Craig Larman: "UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji" Robert C. Martin: Zwinne wytwarzanie oprogramowania. Najlepsze zasady wzorce i praktyki
Metody walki ze zªo»ono±ci Złożoność dziedziny programowanie obiektowe (rzeczywistość -> obiekty) OOAD - Object Oriented Analysis and Design (usystematyzowane podejście do analizy i projektowania) Złożoność systemu - przekracza pojmowanie systemu przez jedna osobę. Trzeba więc podzielić system na mniejsze części. Dobranie odpowiedniej metodyki projektowej (np. agile) Systemy kontroli wersji: Git, SVN Diagramy UML
Metody walki ze zmianami Przyczyny zmian nieprecyzyjne wymagania klienta (klient nie wie czego chce) nieprecyzyjna analiza wymagania zmieniajace się w czasie czynniki zewnętrzne: nowe prawo, nowe technologie Jak z tym walczyć? Wykorzystanie metodyk zwinnych: Scrum, XP, Kanban
Object Oriented Analysis and Design(OOAD) >>
Analiza i projektowanie Analiza i projektowanie Analiza skupia się na badaniu problemu i wymagań a nie na rozwiazaniu. Projektowanie skupia się na koncepcji rozwiazania która spełnia wymagania a nie na implementacji. Do the right thing(analysis), and do the thing right (design) Analiza i projektowanie obiektowe Podczas analizy obiektowej skupiamy się na znalezieniu obiektów i pojęć w dziedzinie problemu. Np. czytelnik, ksiażka, biblioteka. Podczas projektowania obiektowego skupiamy się na definiowaniu obiektów oraz współpracy pomiędzy nimi w celu zrealizowania wymagań. Np. obiekt Ksiazka ma atrybut tytul oraz metodę PobierzRozdzial.
Po co analizowa wymagania klienta? >>
Wymagania u»ytkownika FURPS (requirements) Funkcjonalność (Functionality) - co system będzie robił? Używalność (Usability) - ergonomia, własności estetyczne, jakie elementy powinny działać tak samo,... Niezawodność (Reliability) - poprawność wyników, czas pomiędzy awariami,... Wydajność (Performance) - jak duże obciażenia system jest w stanie przetrwać, czas systemu na odpowiedź, prędkość działania,... Wsparcie (Supportability) - adaptowalność do innych warunków, zgodność z poprzednimi wersjami systemu, łatwość konfiguracji i instalacji,...
Dokument analizy - przykªad TrackNet - system do obsługi błędów w procesie tworzenia systemu
System rejestrowania bª dów przykªad systemu System do obsługi błędów w procesie tworzenia systemu: służy do obsługi błędów powstajacych podczas tworzenia oprogramowania i zarzadzania nimi. system wewnętrzny: wymagania użytkownika nie pochodza od klienta.
System rejestrowania bª dów wymagania Wymagania funkcjonalne: Wprowadzanie zgłoszeń Przegladanie zgłoszeń Obsługa zgłoszenia Definiowanie obiegu błędów dla projektu Zarzadzanie użytkownikami systemu Wymagania systemowe: Integracja z podsystemami Przyjazny interfejs użytkownika
Wprowadzanie zgªosze«- szczegóªowe wymagania wprowadzanie nowego zgłoszenia do systemu, przypisanie zgłoszenia do projektu lub modułu, ustalenie dla zgłoszenia wersji realizacji oraz priorytetu, przypisanie typu zgłoszenia, wymuszone przypisanie osoby prowadzacej zgłoszenie, edycję treści zgłoszenia i pozostałych jego parametrów wraz z zapisem wszelkich zmian w historii zgłoszenia, edycję informacji dodatkowych, ale tylko z zapisem w tekście, kto i kiedy dokonał zmiany, tworzenie duplikatu zgłoszenia, z możliwościa zmiany dowolnego z parametrów lub zmiany w treści, tworzenie powiazań między zgłoszeniami, potrzebne sa dwa typy powiazań jedno nie wpływajace na kolejność realizacji zgłoszeń, a drugie określajace kolejność realizacji, czyli nie można przejść w zgłoszeniu nadrzędnym do następnego stanu przed zamknięciem zgłoszenia podrzędnego, ustalenie, kto ma się zajać zgłoszeniem w przypadku, gdy dotrze ono do wybranego stanu z WorkFlow
Przypadek u»ycia. Co to jest? Sekwencja akcji niezbędna do wykonania pewnej funkcjonalności. Używany do odkrycia i opisu poszczególnych wymagań (funkcjonalnych) systemu. Nie jest zorientowany obiektowo.
Przypadek u»ycia. Z czego si skªada? Nazwa; Identyfikator (ID); Opis; Warunki wstępne (ang. precondition); Warunki końcowe (ang. postconditions); Sekwencja akcji
Sekwencja akcji >>
Sekwencja akcji cd. >>
Rola przypadków u»ycia Opisuja zachowanie się systemu z punktu widzenia użytkownika. Definiuja granice systemu oraz relacje pomiędzy systemem a jego otoczeniem. Pokazuja ogólny obraz funkcjonalności systemu nie ma na tym etapie żadnych decyzji odnośnie technologii. Pokazuja co się będzie działo w systemie. Umożliwia to przemyślenie badź przeprojektowanie całego procesu na wczesnym etapie.
Dlaczego si robi przypadki u»ycia? Sponsorzy sa w stanie stwierdzić, co będzie zrobione, a co nie. Użytkownicy wiedza, co system będzie robił, a co nie (ewentualne sugestie sa możliwe na tym etapie). Developerzy wiedza, nad czym będa pracować.
Jakie powinny by przypadki u»ycia? Kompletne Zrozumiałe Niezależne od implementacji i używanej technologii Dobrze zaprojektowane z punktu widzenia użytkownika
Elementy diagramu przypadków u»ycia Aktorzy (ang. actors) - osoba, organizacja, system wewnętrzny wchodzacy w interakcję z danym systemem. Przypadki użycia (ang. use cases) - sekwencja akcji wykonywana przez aktora (-ów). Asocjacje (ang. associations) - powiazanie pomiędzy aktorem a przypadkiem użycia.
Diagram przypadków u»ycia >>
Zwi zki pomi dzy komponentami Relacja rozszerzania («extend») - polega na dodaniu dodatkowych sekwencji akcji do sekwencji przypadku bazowego. Relacja zawierania («include» wcześniej «uses») - polega na wywoływaniu jednego przypadku przez drugi. Dziedziczenie aktorów - bardziej wyspecjalizowany aktor dziedziczy zachowanie mniej wyspecjalizowanego aktora.
Przykªad zwi zków pomi dzy komponentami >>
Przykład Rysunek: Lepiej Rysunek: Kiepsko Przypadek użycia powinien odzwierciedlać cel aktora. Ważny jest odpowiedni poziom szczegółowości.
Modelowanie koncepcyjne (Domain Model) Znalezienie obiektów i koncepcji istotnych dla systemu Modelowanie za pomoca klas i atrybutów oraz powiazań pomiędzy nimi (asocjacji). Przedstawione za pomoca diagramu klas na wysokim poziomie szczegółowości (tylko koncepcja - NIE PROJEKT!!!) Zmniejsza rozdźwięk pomiędzy naszym obrazem rzeczywistości a modelem projektowym Inspiracja dla obiektów programistycznych
Przykªad modelowania dziedziny >>
Gªówne elementy notacji: Klasa z atrybutami >> W modelowaniu dziedziny używamy mniej szczegółowej notacji
Gªówne elementy notacji: Asocjacja >> Asocjacja jest relacja pomiędzy dwiema lub więcej klasami, specyfikujac a połaczenie pomiędzy instancjami tych klas.
Liczno± >>
Klasa asocjacyjna >> Asocjacja jako klasa z atrybutami Używa się gdy zachodzi relacja wiele do wielu.
Następny wykład: diagramy UML