Projektowanie systemów informatycznych

Transkrypt

1 Projektowanie systemów informatycznych Tytuł kursu: projektowanie systemów informatycznych Cel kursu: Celem wykładu jest zapoznanie studentów z najważniejszymi aspektami projektowania systemów informatycznych a w szczególności realizacją diagramów UML w perspektywie implementacyjnej. Planowany zakres wykładu Wykład 1: Wprowadzenie do projektowania systemów informatycznych. Wykład 2: Diagramy klas UML w perspektywie implementacyjnej. Wykład 3: Diagramy sekwencji, pakietów, stanu i wdrożenia. Wykład 4. Projektowanie interfejsu użytkownika cz. 1 Wykład 5. Projektowanie interfejsu użytkownika cz. 2 Projektowanie systemów informatycznych, wykład 1 1 Niniejszy kurs będzie poruszał zagadnienia dotyczące projektowania systemów informatycznych. Ponieważ dziedzina jest bardzo obszerna a rozmiar kursu dość ograniczony więc zdecydowałem się na prezentację najważniejszych aspektów oraz najczęściej wykorzystywanych technik w projektowaniu systemów informatycznych. Przy czym w dalszej części kursu zamiast używać długiego określenia: projektowanie systemów informatycznych będę pisał krótko projektowanie. Niniejszy kurs nie należy traktować jako kompendium wiedzy z dziedziny projektowania. Jest on jedynie wstępem do obszernej wiedzy na temat której napisano wiele książek. Dopiero przestudiowanie literatury podanej na slajdzie 3 daje w miarę pełny obraz dziedziny. Biorąc pod uwagę powyższe zdecydowałem się podzielić kurs na dwie główne części: Pierwsza część będzie dotyczyła wprowadzenia do projektowania systemów informatycznych ze szczególnym uwzględnieniem roli UML i metod obiektowych. Myślę, że to wprowadzenie zaprezentuję w trzech jednostkach wykładowych. Druga część będzie dotyczyła projektowania interfejsu użytkownika, innych aspektów nie związanych z dziedziną problemu. Niniejszy kurs zwłaszcza w pierwszej części będzie pewną kontynuacją kursu z poprzedniego semestru, który dotyczył modelowania systemów informatycznych, gdyż projektowanie traktowane jest jako kolejny etap budowy systemu informatycznego po modelowaniu. Stąd wyniki modelowania stanowią dane wejściowe dla projektowania. Zakładam, że student realizujący niniejszy kurs zna podstawy inżynierii oprogramowania. Stąd, w celu przypomnienia, proponuję przed rozpoczęciem studiowania dalszej części tego kursu przeczytać wykład 1 kursu z modelowania systemów informatycznych realizowanego na poprzednim semestrze. 1

2 Zasady zaliczenia kursu W materiałach wykładowych przewidziano dwa zadania do rozwiązania. Końcowa ocena jest średnią Państwa ocen za poszczególne zadania. Końcowa ocena wyliczana jest według następujących zasad zamieszczonych w tabeli poniżej: Zakres średniej (2 2.75> ( > ( > ( > ( > (4.75 5> Ocena Dodatkowo na zjeździe, pod koniec semestru, mogę zapytać z dowolnego zadania oddanego przez studenta aby sprawdzić czy zadanie zostało wykonane samodzielnie. Projektowanie systemów informatycznych, wykład 1 2 W przypadku gdy student otrzymał ocenę końcową 2 istnieje możliwość jej poprawienia poprzez oddanie zadań na zjeździe w siedzibie WSInf, przy czym student może otrzymać wtedy maksymalną ocenę końcową równą 3. 2

3 Cel i zakres pierwszego wykładu Wykład 1: Wprowadzenie do projektowania systemów informatycznych Cel Prezentacja celów i zakresu projektowania systemów informatycznych. Zakres 1) Literatura przedmiotu 2) Etapy projektowania systemów informatycznych 3) Czynności realizowane na etapie projektowania 4) Perspektywy języka UML 5) Diagramy UML tworzone na etapie projektowania Projektowanie systemów informatycznych, wykład 1 3 3

4 Literatura przedmiotu Literatura: 1. Sommerville I.: Inżynieria oprogramowania, WNT 2. Fowler M.: UML w kropelce, LTP Warszawa Yourdon E., Argila C.: Analiza obiektowa i projektowanie, WNT, Jaszkiewicz A.: Inżynieria oprogramowania, Helion, Gamma E., Helm R., Johnson R., Vlissides J.: Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, WNT, J. Cooper.: Java. Wzorce projektowe, Helion, A. Shalloway, J. R. Trott.: Programowanie zorientowane obiektowo. Wzorce projektowe. Wydanie II, Helion, Projektowanie systemów informatycznych, wykład 1 4 Polecam szczególnie wykłady na stronie [8]. Uważam, że każdy student a w szczególności studenci e-studiów powinien zaglądać na tę stronę, gdzie można znaleźć bardzo profesjonalnie przegotowane wykłady z informatyki. Polecam szczególnie wykład nr. 18 inżynieria oprogramowania, jednostka wykładowa: zasady skutecznego działania. Polecam również biblię inżynierii oprogramowania [1] gdzie znajdą Państwo rzetelne napisane, zrozumiałym językiem, bardzo bogate kompendium wiedzy z inżynierii oprogramowania. Jako pierwszą książkę dotyczącą UML polecam [2]. Książka ta łagodnie wprowadza do użytkowania tego języka. Ponadto zawiera bardzo cenne uwagi dotyczące literatury inżynierii oprogramowania. Uwagi te można traktować jako przewodnik po studiowaniu tej obszernej dziedziny nauki. Polecam również szczególnie biblię wzorców projektowych [6] autorstwa bandy czworga twórców koncepcji wzorców projektowych. Do powyższej literatury będę odwoływał się w treści niniejszego kursu. 4

5 Etap projektowania Celem projektowania jest opracowanie szczegółowego opisu implementacji systemu, który po modyfikacjach na etapie implementacji systemu staje się również głównym elementem dokumentacji technicznej. Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja W odróżnieniu od etapu analizy, projektowanie przeprowadzane jest w kontekście środowiska implementacji oraz środowiska pracy systemu. Projektanci muszą więc posiadać dobrą znajomość języków, bibliotek, i narzędzi stosowanych w trakcie implementacji oraz systemu operacyjnego i platformy sprzętowej na jakiej będzie działał system. Projektowanie systemów informatycznych, wykład 1 5 Jak podano w [3] odkąd opracowano pierwsze metodyki kaskadowe, inżynierowie oprogramowania rozróżniali modelowanie (analizę) i projektowanie. Analiza zajmuje się tym, co system musi robić, a projektowanie tym, jak te wymagania będą zrealizowane. Przeprowadzając analizę, zwykle przyjmujemy założenie, że dostępny jest doskonały" sposób realizacji. Podczas projektowania zakładamy zazwyczaj świadomie lub nieświadomie, że dany system będzie realizowany na platformie sprzętowej x, w systemie operacyjnym y i w języku programowania z. Zasadniczą sprawą jest traktowanie projektowania i analizy jako odrębnych czynności. Mogą się one nakładać; oczywiście w typowym projekcie mogą być wykonywane jednocześnie. Ciągle jednak istnieje zasadnicza różnica między co" i,jak", rozpoznawana przez większość inżynierów oprogramowania. Niepostrzeżenie tej różnicy stwarza niebezpieczeństwo, że analityk lub użytkownik włączy do zestawu wymagań zbyt wiele założeń i ograniczeń dotyczących sposobu realizacji. Projektowanie systemów informatycznych jest konieczne ponieważ model budowany w fazie analizy abstrahuje od szczegółów środowiska implementacji, jest on zbyt ogólny, aby być bezpośrednią podstawą implementacji. Projektowanie wymaga więc uszczegółowienia wyników analizy. Rysunek zaprezentowany na slajdzie pokazuje umiejscowienie etapu projektowania w cyklu życia systemu. Rysunek ten sugeruje, że projektowanie, szczególnie na jego wczesnych etapach może być realizowane równolegle z analizą. Ponadto rysunek pokazuje, że projektowanie ma znaczący wkład do dokumentacji. Jednak pragnę podkreślić fakt, że większość metodologii tworzenia systemów informatycznych traktuje analizę i projektowanie jako dwa oddzielne etapy. 5

6 Podstawowe założenia inżynierii oprogramowania Struktura oprogramowania odzwierciedla model stworzony na etapie modelowania. Zachowanie przez system naturalnej struktury dziedziny problemu. Niewielkie zmiany w dziedzinie problemu powinny prowadzić do niewielkich, tanich zmian w oprogramowaniu. Projekt powinien być wynikiem transformacji konstrukcji występujących w modelu do odpowiadających im konstrukcji środowiska implementacji. Wykorzystanie idei programowania strukturalnego i obiektowego. Projektowanie systemów informatycznych, wykład 1 6 Jednym z podstawowych założeń inżynierii oprogramowania jest dążenie do tego, aby struktura tworzonego oprogramowania jak najbardziej zachowywała ogólną strukturę modelu stworzonego w poprzedniej fazie. Celem jest uzyskanie systemu, którego struktura odzwierciedlałaby naturalne zależności w danej dziedzinie problemu. Współczesne metody inżynierii oprogramowania są więc rozwinięciem znanej już od lat sześćdziesiątych idei programowania strukturalnego. Zachowanie przez system naturalnej struktury dziedziny problemu ma przede wszystkim podnieść jego zrozumiałość oraz ułatwić modyfikowanie systemu. Niewielkie zmiany w dziedzinie problemu powinny prowadzić do niewielkich zmian w oprogramowaniu. Ich wprowadzenie nie powinno być więc zbyt kosztowne i długotrwałe. Niekorzystna jest sytuacja, w której klient żądający niewielkiej jego zdaniem zmiany, dowiaduje się, że będzie ona wymagała istotnych zmian w systemie, podważa to bowiem zaufanie klienta do producenta oprogramowania. Z drugiej strony klient łatwiej zaakceptuje konieczność dokonania istotnych zmian w systemie, jeżeli żądana przez niego modyfikacja jest poważna również z jego punktu widzenia. 6

7 Czynności realizowane na etapie projektowania 1. Uszczegółowienie modelu składowej dziedziny problemu 2. Projektowanie elementów systemu nie związanych z dziedziną problemu 1. Interfejs użytkownika 2. Zarządzanie danymi 3. Zarządzanie pamięcią 4. Zarządzanie zadaniami 5. Optymalizacja systemu 3. Dostosowanie do ograniczeń i możliwości systemu 4. Określenie fizycznej struktury systemu Projektowanie systemów informatycznych, wykład 1 7 Oprogramowanie składa się z kilku składowych. Jedną z nich jest składowa dziedziny problemu odpowiedzialna za wykonywanie podstawowych funkcji systemu oraz przechowywanie podstawowych dla systemu danych. Jest to składowa, która powstaje poprzez uszczegółowienie modelu zbudowanego w fazie analizy. Uszczegółowienie wyników analizy polega między innymi na wyborze sposobu implementacji pewnych konstrukcji pojawiających się w modelu, które mogą być zrealizowane na jeden z kilku sposobów. Firma programistyczna może jednak przyjąć pewne standardy, które jednoznacznie definiują sposób implementacji tego typu konstrukcji. Pozwala to w istotnym stopniu zredukować nakład pracy w fazie projektowania. W fazie projektowania należy opracować także inne składowe oprogramowania, tj.: składową kontaktu z użytkownikiem odpowiedzialną za współpracę systemu z użytkownikiem (użytkownikami), składową zarządzania danymi odpowiedzialną za przechowywanie oraz dostęp do trwałych danych, składową zarządzania pamięcią oraz składową zarządzania zadaniami. W fazie analizy pewne funkcje i struktury danych mogą zostać zamodelowane w sposób mało efektywny. W fazie projektowania dokonywana jest więc również optymalizacja systemu. Środowisko implementacji może zarówno narzucać pewne ograniczenia, to jest nie pozwalać na bezpośrednie zaimplementowanie pewnych konstrukcji pojawiających się w modelu, jak i oferować dodatkowe możliwości ułatwiające implementację. Projektowanie polega więc także na dostosowaniu systemu do ograniczeń i możliwości środowiska implementacji. 7

8 Różne podejścia do projektowania Metody strukturalne wykorzystanie różnych pojęć oraz notacji graficznych na etapie analizy oraz projektowania. Metody obiektowe w fazie analizy, projektowania i implementacji wykorzystuje się te same pojęcia i notacje graficzne. Projektowanie systemów informatycznych, wykład 1 8 W przypadku metod strukturalnych w fazie projektowania i implementacji wykorzystywane są wyraźnie odmienne pojęcia niż te stosowane w fazie modelowania. W związku z tym w metodach tych pojawiają się także notacje graficzne odmienne od stosowanych w fazie modelowania. W przypadku metod obiektowych w fazach modelowania, projektowania i implementacji wykorzystywane są te same pojęcia. We wszystkich fazach operuje się pojęciami klas, pól i metod. W związku z tym w projektowaniu obiektowym wykorzystywane są w zasadzie te same notacje graficzne co w fazie analizy; choć pojawiają się w nich pewne rozszerzenia stosowane tylko w fazie projektowania. Ponieważ metody obiektowe wypierają metody strukturalne, które coraz rzadziej są wykorzystywane to zdecydowałem, że nie będę prezentował na tym kursie metod strukturalnych. Ponadto projektowanie strukturalne wymagałoby dodatkowo wyjaśnienia podstaw modelowania strukturalnego, co przekracza zakres niniejszego kursu a wcześniejszy kurs dotyczący modelowania nie prezentował metod strukturalnych. 8

9 UML a projektowanie systemów Trzy perspektywy UML Perspektywa pojęciowa Reprezentuje diagramy reprezentujące koncepcje na poziomie studiowania dziedziny problemu. Nie zawiera żadnych pojęć specyficznych dla implementacji oprogramowania. Realizacja niniejszej perspektywy ma prowadzić do odpowiedzi na pytanie Co jest problemem lub inaczej co powinien realizować system. Perspektywa specyfikacyjna (interfejsu) używa diagramów perspektywy pojęciowej rozbudowując je o elementy wskazujące jak rozwiązać problem na poziomie niezależnym od platformy implementacyjnej. Obejmuje specyfikację elementów, komponentów i interfejsów programu. Perspektywa implementacyjna rozwinięcie diagramów perspektywy specyfikacyjnej dla konkretnej platformy programistycznej Projektowanie systemów informatycznych, wykład 1 9 Otwarty format UML (ang. Unified Modeling Language, czyli Ujednolicony Język Modelowania), to język formalny służący do opisu świata obiektów w modelowaniu obiektowym, projektowaniu obiektowym i programowaniu obiektowym. Służy do modelowania dziedziny problemu (opisywania-modelowania fragmentu istniejącej rzeczywistości - na przykład modelowanie tego, czym zajmuje się jakiś dział w firmie) w przypadku stosowania go do analizy, oraz do modelowania rzeczywistości, która ma dopiero powstać -tworzy się w nim głównie modele systemów informatycznych. UML jest głównie używany wraz z jego reprezentacją graficzną jego elementom przypisane są symbole, które wiązane są ze sobą na diagramach. Podstawy UML były prezentowane na wykładzie Modelowanie Systemów Informatycznych w poprzednim semestrze. Znacząca część niniejszego kursu dotyczy wykorzystania UML w projektowaniu systemów. Jak podano w [2], przy rozpatrywaniu graficznych języków modelowania, zwykle myśli się o nich w kontekście procesu kaskadowego. W procesie kaskadowym zazwyczaj tworzy się dokumenty, które służą do przekazywania prac miedzy fazami projektowania i kodowania. Modele graficzne mogą stanowić większą część tych dokumentacji. Niezależnie od tego czy stosujemy model kaskadowy czy nie i tak wykonujemy czynności modelowania, projektowania, kodowania i testowania. Można np. uruchomić projekt iteracyjny z 1-tygodniowymi iteracjami, z których każda jest małym procesem kaskadowym. Ponieważ UML może być wykorzystany zarówno na etapie modelowania czy projektowania wyróżnia się trzy perspektywy odpowiadające etapom tworzenia systemów informatycznych. Każda z perspektyw odpowiada innemu spojrzeniu na system odpowiadającemu aktualnemu etapowi realizacji. Zrozumienie pojęcia perspektyw jest kluczowe dla poprawnego rysowania i czytania diagramów UML. Diagram UML powinien być przygotowywany z punktu widzenia jednej perspektywy. Kiedy diagram UML jest czytany, czytelnik powinien wiedzieć w jakiej perspektywie diagram został przygotowany. Ta wiedza jest nieodzowna aby zinterpretować diagram poprawnie. Niestety granice pomiędzy perspektywami nie są ostre. Najbardziej zatarto granice pomiędzy perspektywą specyfikacyjną a implementacyjną przygotowując najczęściej po diagramach pojęciowych od razu diagramy implementacyjne. Stąd pierwsze zadanie Państwa będzie polegało na modyfikacji diagramów perspektywy pojęciowej na diagramy perspektywy implementacyjnej oraz zbudowanie diagramów specyficznych dla perspektywy interfejsu i perspektywy implementacyjnej. Zadania te pojawią się po umieszczeniu wykładu 2 i 3. 9

10 Perspektywa pojęciowa a implementacyjna Poniższy rysunek pokazuje dwie perspektywy tego samego fragmentu diagramu UML. Na rysunku widać podstawowe różnice pomiędzy perspektywą pojęciową a implementacyjną. Źródło: Dice Dice Projektowanie systemów informatycznych, wykład 1 10 Na następnym wykładzie różnice między perspektywą pojęciową a implementacyjną diagramów klas i obiektów zostaną zaprezentowane dokładniej. 10

11 Diagramy UML na etapie projektowania Zwykle na etapie projektowania tworzone są perspektywie implementacyjnej: następujące diagramy w Diagramy klas z perspektywy oprogramowania przedstawiają klasy programu i relacje zachodzące między nimi. Diagramy sekwencji dla częstych scenariuszy wartościowym podejściem jest wybranie najważniejszych i najbardziej interesujących scenariuszy spośród przypadków użycia systemu i użycie kart CRC lub diagramów sekwencji do określenia, co się w trakcie tych scenariuszy dzieje w programie. Diagramy pakietów, które ukazują w ogólnym świetle sposób organizacji oprogramowania. Diagramy stanów dla klas ze skomplikowanymi cyklami działania. Diagramy wdrożenia pokazujące fizyczny układ oprogramowania. Projektowanie systemów informatycznych, wykład