Projektowanie systemów informatycznych

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
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>
(2.72 3.25> (3.25 3.75> (3.75 4.25> (4.25 4.75> (4.75 5>
Ocena
2
3
3.5
4
4.5
5
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
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
Literatura przedmiotu
Literatura:
1. Sommerville I.: Inżynieria oprogramowania, WNT
2. Fowler M.: UML w kropelce, LTP Warszawa 2005
3. Yourdon E., Argila C.: Analiza obiektowa i projektowanie, WNT, 2000
4. Jaszkiewicz A.: Inżynieria oprogramowania, Helion, 1997
5. Gamma E., Helm R., Johnson R., Vlissides J.: Wzorce projektowe. Elementy
oprogramowania obiektowego wielokrotnego użytku, WNT, 2005
6. J. Cooper.: Java. Wzorce projektowe, Helion, 2001
7. A. Shalloway, J. R. Trott.: Programowanie zorientowane obiektowo. Wzorce
projektowe. Wydanie II, Helion, 2005
8. http://wazniak.mimuw.edu.pl/
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
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ń
Faza strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
Konserwacja
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
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
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.
2.
3.
4.
5.
Interfejs użytkownika
Zarządzanie danymi
Zarządzanie pamięcią
Zarządzanie zadaniami
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
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
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
specyfikacyjnej dla konkretnej platformy programistycznej
Projektowanie systemów informatycznych, wykład 1
perspektywy
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
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: http://www.informit.com/articles/article.aspx?p=360440&seqNum=6&rl=1
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
Diagramy UML na etapie projektowania
Zwykle na etapie projektowania tworzone są następujące diagramy w
perspektywie implementacyjnej:
¾
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 1
11
11