Projektowanie systemów informatycznych Wykład 1 - Wprowadzenie

Prezentacja na temat: "Projektowanie systemów informatycznych Wykład 1 - Wprowadzenie"— Zapis prezentacji:

1 Projektowanie systemów informatycznych Wykład 1 - Wprowadzenie
mgr inż. Bartosz Połok

2 Zaliczenie Zaliczenie wykładów Projekt Zaliczenie praktyczne
Składa się z kilku (prawdopodobnie trzech etapów)

3 Literatura J. Płodzień, E. Stemposz: Analiza i projektowanie systemów informatycznych, Wydawnictwo PJWSTK, 2003 E. Stemposz, K. Subieta: Slajdy do wykładu "Projektowanie systemów informacyjnych", 2003 OMG Unified Modeling Language. Specification, Version 1.4, The Object Management Group, September 2001,  P. Kruchten: The Rational Unified Process. An Introduction, Addison- Wesley, 1999 Ch. Marshall: Enterprise Modeling with UML. Designing Successful Software through Business Analysis, Addison-Wesley, 1999

4 Metody walki ze złożonością oprogramowania
Zwiększenie nacisku na następujące aspekty procesu wytwórczego: Dopasowanie modeli do sposobu w jaki rozumiemy świat Mechanizmy abstrakcji Mechanizmy strukturalizacji Ponowne użycie Dopasowanie modeli pojęciowych i realizacyjnych systemów informatycznych do mechanizmów percepcji i rozumienia świata przez ludzi, m.in. wykorzystywanie mechanizmów abstrakcji i mechanizmów strukturalizacji Mechanizmy abstrakcji, pozwalają operować jednostkami oprogramowania bez wnikania w ich wewnętrzną strukturę, np. poprzez oddzielenie specyfikacji od implementacji. Mechanizmy abstrakcji pozwalają także wyodrębniać cechy wspólne i niezmienne (inwariantne) dla pewnych zbiorów bytów. Z kolei, mechanizmy strukturalizacji umożliwiają komponowanie większych jednostek oprogramowania z mniejszych oraz dekomponowanie złożonych struktur na fragmenty w celu rozpatrywania tych fragmentów niezależnie od siebie i niezależnie od całości, co pozwala na: Bezpieczne pominięcie niektórych aspektów systemu i skoncentrowanie się na aspektach istotnych, którym w ten sposób można poświęcić więcej uwagi. Łatwiejsze znajdowanie błędów (zarówno w trakcie budowania, jak i konserwacji systemu), gdyż nie wszystkie jednostki oprogramowania muszą być testowane przy usuwaniu danego błędu. Zwiększenie wydajności pracy dzięki łatwiejszemu podziałowi pracy i przydzieleniu jej do poszczególnych zespołów i osób. Ponowne użycie, czyli wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd.

5 Metody walki ze złożonością oprogramowania
Ze strukturalizacją powiązane są dwa ważne pojęcia: Koherezja – zwartość, spoistość. Określenie wewnętrznego zintegrowania elementów składowych systemu. Skojarzenie – określa stopień powiązania pomiędzy jednostkami oprogramowania. Przyjmuje się, że jednostki oprogramowania powinny cechować się dużą koherencją i niezbyt silną skojarzeniowością. Ze strukturalizacją oprogramowania związane są dwa następujące ważne pojęcia: Kohezja, czyli zwartość, spoistość. Terminu tego używa się przede wszystkim w odniesieniu do większych jednostek oprogramowania (np. komponentów) na oznaczenie wzajemnego zintegrowania ich elementów składowych. Przyjmuje się, że jednostki oprogramowania powinna cechować duża kohezja, czyli silna interakcja wewnątrz i relatywnie słaba interakcja z innymi jednostkami oprogramowania. Skojarzenie określa stopień powiązania pomiędzy jednostakmi oprogramowania. Skojarzenie określa m.in. jak często dana jednostka odwołuje się do innych jednostek. Możliwe są skojarzenia silne, słabe oraz brak skojarzenia. Przyjmuje się, że duża liczba silnych skojarzeń między elementami składowymi jest niewskazana. Analiza stopnia kohezji i wzajemnych skojarzeń stanowi bazę dla konstruowania architektury systemu, czyli dla wyróżniania elementów składowych, określania wzajemnych interakcji tych elementów oraz sposobów przesyłania pomiędzy nimi danych.

6 Obiektowość a kryzys oprogramowania
Złożoność procesu wytwórczego sprawia, że człowiek ze swoimi uwarunkowaniami fizycznymi, psychologicznymi i mentalnymi bardzo często nie jest w stanie zrealizować go w sposób efektywny. Rozwiązanie – obiektowość Eliminowanie niezgodności na linii: mentalna percepcja świata rzeczywistego - model pojęciowy -  schemat struktury danych Złożoność procesu wytwórczego sprawia, że człowiek ze swoimi uwarunkowaniami fizycznymi, psychologicznymi i mentalnymi bardzo często nie jest w stanie zrealizować go w sposób efektywny. Obserwacja ta prowadzi do następującego wniosku: proces wytwórczy powinien być bardziej zorientowany na ludzi niż na maszyny, czyli nacisk powinien być położony przede wszystkim na to, aby wykorzystywana w procesie wytwórczym metoda pracy mogła być w łatwy i naturalny sposób zastosowana przez informatyka. Obecnie największe nadzieje wiązane są z obiektowością, która w porównaniu do konkurencyjnych podejść jest bardziej zorientowana na ludzi oraz oferuje dużo większą liczbę pojęć, koncepcji, mechanizmów, itd., co znacząco ułatwia budowę systemów informatycznych. Jednym z głównych zadań obiektowości jest w intencji jej twórców wyeliminowanie (a przynajmniej zminimalizowanie) wad charakterystycznych dla innych podejść do konstruowania systemów informatycznych, w szczególności wad podejścia strukturalnego i relacyjnego modelu danych. Z jednej strony, podejście strukturalne oferuje stosunkowo niewielką liczbę koncepcji z zakresu modelowania pojęciowego. Z drugiej strony, istniejące ograniczenia relacyjnego modelu danych wymuszają podczas implementacji wprowadzenie szeregu zmian niskiego poziomu. Obiektowość wskazuje, jak te wady usunąć: podstawową metodą jest eliminowanie niezgodności na linii mentalna percepcja świata rzeczywistego - model pojęciowy - schemat struktury danych, a więc pomiędzy myśleniem o dziedzinie problemowej a myśleniem o danych i operujących na nich procesach. Głównym sposobem zmniejszenia owych niezgodności jest udostępnienie zestawu takich samych (a przynajmniej bardzo podobnych) pojęć na każdym etapie procesu wytwórczego.

7 Obiektowość a kryzys oprogramowania
Obiektowość jest koncepcją uniwersalną, która ma wpływ na wiele obszarów współczesnej informatyki, w szczególności na: Metodyki budowy systemów informatycznych Języki programowania Bazy danych i składy trwałych obiektów Systemy heterogeniczne Wizyjne środowiska programistyczne -Metodyki budowy systemów informatycznych (Rumbaugh, Booch, Jacobson, Yourdon, itd.) oraz oparte o nie narzędzia CASE. Najbardziej istotna zmiana w stosunku do metodyk wykorzystujących tradycyjny model encja-związek to związanie obiektów z operacjami, które można na nich wykonywać. -Języki programowania (np. Smalltalk, C++, Java, Eiffel, C#), które wspierają takie pojęcia jak klasa, dziedziczenie, hermetyzacja, metody, późne wiązanie, itd. -Bazy danych i składy trwałych obiektów (np. standard ODMG, ObjectStore, O2, Poet, Versant), czyli przeniesienie obiektowych technologii programowania na grunt baz danych. -Systemy heterogeniczne (np. OMG CORBA, OLE/DCOM/ActiveX), gdzie obiekty i klasy są podstawą wymiany informacji pomiędzy systemami. -Wizyjne środowiska programistyczne (np. Smalltalk, CA OpenRoad, IBM VisualAge), czyli przeniesienie technik obiektowych do programowania wizyjnego.

8 Obiektowość a kryzys oprogramowania
Niedoskonałości podejścia obiektowego (trochę nieaktualne): Zasady obiektowości nie są w pełni określone Mechanizmy zarządzania bardzo dużymi bazami obiektów, sterowania wersjami, rejestrowania zmian są wciąż niedopracowane Technologie obiektowe są jak dotąd stosowane głównie przez małe i średnie organizacje Wdrożenie technologii obiektowych może zagrozić funkcjonowaniu systemów starszych generacji Wciąż nie są znane koszty, jakie pociągnie za sobą przejście na technologie obiektowe Rozważając szanse obiektowości na uzyskanie powszechnej akceptacji należy pamiętać jednak o tym, że jak każda nowa ideologia musi ona "konkurować" z ideologiami już istniejącymi; nie bez znaczenia jest tutaj istnienie "spuścizny" w postaci ogromnych inwestycji w hierarchiczne, sieciowe i relacyjne bazy danych. Z drugiej strony, popularność podejścia obiektowego jest ograniczona przez jego własne niedoskonałości: -Zasady obiektowości nie są w pełni określone; istnieje duża liczba języków bazujących na jej różnych odmianach; standardy w zakresie obiektowości są niedopracowane i niestabilne, w związku z czym wciąż nie wiadomo, w jakim zakresie będą one pełnić swoją funkcję. -Mechanizmy zarządzania bardzo dużymi bazami obiektów, sterowania wersjami, rejestrowania zmian są wciąż niedopracowane. -Technologie obiektowe są jak dotąd stosowane głównie przez małe i średnie organizacje. Oznacza to, że nie jest do końca pewne, czy będzie możliwe wykorzystanie ich w sposób efektywny dla wielkich organizacji. Duża liczba tematów związanych z obiektowością znajduje się ciągle w fazie badań, w związku z czym technologie obiektowe są wciąż mało stabilne. -Wdrożenie technologii obiektowych może zagrozić funkcjonowaniu systemów starszych generacji, które są kluczowe dla działalności używających je organizacji. -Wciąż nie są znane koszty, jakie pociągnie za sobą przejście na technologie obiektowe. Jak widać, obiektowość nie jest koncepcją idealną, nie tylko z technologicznego, ale także z biznesowego punktu widzenia. Wydaje się jednak, że ze względu na swoje zalety oraz wady konkurentów, podejście obiektowe prędzej czy później będzie powszechnie stosowane i zajmie miejsce dominującego obecnie podejścia strukturalnego. Jest to bardzo prawdopodobne, gdyż duże nakłady na badania związane z technologiami obiektowymi pozwalają sądzić, że przynajmniej niektóre z ich niedoskonałości i niedociągnięć zostaną w niedalekiej przyszłości usunięte.

9 Rola inżynierii oprogramowania
Najważniejsze zadania inżynierii oprogramowania: Propagowanie wykorzystywania technik i narzędzi ułatwiających pracę nad złożonymi systemami. Upowszechnianie metod wspomagających analizę nowych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń. Usystematyzowanie procesu wytwarzania oprogramowania w celu uproszczenia jego planowania i monitorowania. Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu informatycznego o wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia. Z perspektywy środowiska informatyków, kryzys oprogramowania musi skutkować wzrostem wysiłków na rzecz nabywania wiedzy o profesjonalnej budowie oprogramowania i wdrażania tej wiedzy do codziennej działalności. Właściwą organizację pracy i systematyczne podejście do procesu wytwarzania można osiągnąć wyłącznie poprzez skuteczne stosowanie zasad i technik wypracowanych przez inżynierię oprogramowania, do najważniejszych zadań której można zaliczyć: -Propagowanie wykorzystywania technik i narzędzi ułatwiających pracę nad złożonymi systemami. -Upowszechnianie metod wspomagających analizę nowych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń. -Usystematyzowanie procesu wytwarzania oprogramowania w celu uproszczenia jego planowania i monitorowania. -Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu informatycznego o wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia.

10 Proces wytwórczy oprogramowania definicje pojęć
Metodyka definiuje fazy realizacji przedsięwzięcia informatycznego, a ponadto dla każdej z jego faz wyznacza: role uczestników projektu scenariusze postępowania reguły przechodzenia do następnej fazy produkty, które powinny być wytworzone, m.in. modele, kod, dokumentacja, itd. notację, którą należy używać Jednym z podstawowych pojęć związanych z procesem wytwórczym oprogramowania jest metodyka, czyli zestaw pojęć, oznaczeń, języków, modeli, diagramów, technik i sposobów postępowania służących realizacji procesu. Metodyka definiuje fazy realizacji przedsięwzięcia informatycznego, a ponadto dla każdej z jego faz wyznacza:

11 Proces wytwórczy oprogramowania definicje pojęć
Najważniejsze rodzaje notacji: notacje tekstowe specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny notacje graficzne Notacja zobacz uwagę, czyli zbiór oznaczeń, jest tu wykorzystywana do dokumentowania wyników poszczególnych faz projektu (pośrednich i końcowych), ułatwiając komunikację zarówno między członkami zespołu projektowego, jak i między zespołem projektowym a klientem. Do najważniejszych rodzajów notacji zalicza się: -notacje tekstowe; -specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny; -notacje graficzne. Szczególne znaczenie mają notacje graficzne, zgodnie z zasadą, że "jeden obraz wart jest tysiąca słów". Zalety notacji graficznych potwierdza praktyka. Inżynieria oprogramowania wzoruje się tutaj na innych dziedzinach techniki, takich jak np. elektronika i mechanika. Bardzo często notacja danej metodyki może być wykorzystywana w innych metodykach; istnieją także notacje nie związane bezpośrednio z żadną konkretną metodyką.

12 Proces wytwórczy oprogramowania definicje pojęć
Język modelowania: Składnia Semantyka Pragmatyka Kolejnym z pojęć wykorzystywanych w trakcie omawiania procesu wytwórczego oprogramowania jest modelowanie. Budujemy modele, aby lepiej zrozumieć system, nad którym pracujemy i aby zapanować nad realizacją dużych, złożonych systemów. Modelowanie może i powinno być wspomagane przez środki służące do opisu analizowanego problemu w postaci struktur danych, operacji na danych i zachodzących w tej dziedzinie procesów. Jednym z takich środków jest język modelowania; składa się on z trzech podstawowych elementów: -składni, która określa jakie oznaczenia (czyli elementy składniowe) wolno stosować i w jaki sposób należy je ze sobą łączyć; -semantyki, która określa co należy rozumieć pod przyjętymi oznaczeniami; -pragmatyki, która określa w jaki sposób - zgodnie z intencją autorów języka - należy dopasować oznaczenie notacyjne do konkretnej sytuacji i problemu. Użyteczność języka modelowania jest w dużym stopniu zdeterminowana znajomością sposobów jego praktycznego wykorzystywania w procesie wytwarzania produktu programistycznego, co oznacza, że pragmatyka stosowanego języka jest kwestią podstawową. Niestety, zazwyczaj jest ona trudna do zdefiniowania w sposób ścisły i formalny, dlatego niemal zawsze objaśniana jest w sposób nieformalny, głównie na przykładach tylko przypominających realne sytuacje. Należy pamiętać, że rzeczywiste sytuacje są często znacznie bardziej skomplikowane niż te przedstawiane w podręcznikach, w związku z czym użyteczność takich przykładów jest w praktyce dosyć ograniczona.

13 Model a diagram Model jest semantycznie spójną abstrakcją projektowanego systemu i stanowi kompletny opis systemu utworzony z określonej perspektywy na pewnym poziomie szczegółowości Diagram służy do opisania modelu Mimo iż często używane zamiennie, pojęcia model oraz diagram nie są synonimami. Zależność pomiędzy nimi jest następująca: Model jest semantycznie spójną abstrakcją projektowanego systemu i stanowi kompletny opis systemu utworzony z określonej perspektywy na pewnym poziomie szczegółowości, co oznacza, że niektóre elementy systemu zostały ukryte, a inne wyeksponowane. Fraza "kompletny opis" zaświadcza, że żadna dodatkowa informacja nie jest potrzebna dla zrozumienia systemu z danej perspektywy. Pojedynczy model zazwyczaj nie wystarcza ani do zrozumienia wszystkich aspektów złożonego systemu jednocześnie ani do znalezienia odpowiedniego rozwiązania, zwykle potrzebujemy ich wiele. Razem stanowią kompletny opis systemu, muszą być wzajemnie spójne i nieredundantne. Diagram służy do opisania modelu; dany model może być opisany przy pomocy wielu diagramów, zaś dany element modelu może pojawiać się na wielu diagramach opisujących ten model.

14 Perspektywy Perspektywa pojęciowa Perspektywa projektowa
Perspektywa implementracyjna W trakcie konstruowania dowolnego modelu (diagramu) powinny być brane pod uwagę trzy następujące perspektywy: Perspektywa pojęciowa (koncepcyjna) - model przedstawia wyłącznie pojęcia funkcjonujące w dziedzinie problemowej; w szczególności analizowane są operacje wykonywane na bytach, cechy opisujące byty, oraz istniejące pomiędzy bytami różnego rodzaju związki semantyczne. Model pojęciowy w jak najmniejszym stopniu, a najlepiej wcale, powinien odnosić się do środowiska implementacji. Perspektywa projektowa - uwzględniane jest oprogramowanie, z tym, że ważny jest interfejs a nie implementacja. Chociaż podejście obiektowe kładzie duży nacisk na rozróżnienie pomiędzy interfejsem a implementacją, w praktyce w wielu językach obiektowych te dwa aspekty nie są wyraźnie oddzielone. Perspektywa implementacyjna, która związana jest bezpośrednio z programowaniem.

15 Perspektywy Należy pamiętać o następujących zaleceniach:
konstruując model należy uwzględniać jedną, wyraźnie określoną perspektywę aby poprawnie zinterpretować model, należy wiedzieć z jakiej perspektywy został on skonstruowany modele, tak jak i całość projektu, zawsze powstają (a przynajmniej powinny powstawać) w sposób iteracyjny i przyrostowy Zrozumienie perspektywy, która była brana pod uwagę w trakcie konstruowania danego modelu, jest ważnym czynnikiem mającym wpływ na prawidłowe zinterpretowanie modelu, m.in. przez programistów; innymi słowy, prawidłowa interpretacja (właściwe zrozumienie) jest warunkiem koniecznym prawidłowego wykorzystania modelu. Niestety, nie dość, że granice pomiędzy perspektywami nie są wyraźnie zakreślone, to jeszcze często analitycy i projektanci lekceważą tę kwestię i konstruują swoje modele od razu z perspektywy implementacyjnej, podczas gdy perspektywa pojęciowa lub projektowa mogłaby być w danej sytuacji znacznie bardziej użyteczna. Należy bowiem zdawać sobie sprawę z tego, że nadmiar informacji przedstawionej przez model może (nawet znacznie) ograniczać jego użyteczność. W związku z tym należy pamiętać o następujących zaleceniach: -konstruując model należy uwzględniać jedną, wyraźnie określoną perspektywę; -aby poprawnie zinterpretować model, należy wiedzieć z jakiej perspektywy został on skonstruowany; -modele, tak jak i całość projektu, zawsze powstają (a przynajmniej powinny powstawać) w sposób iteracyjny i przyrostowy.

16 Proces wytwórczy a metodyka
Niezależnie od przyjętej metodyki i modelu danych, proces wytwórczy systemu informatycznego zawiera zazwyczaj te same wykonywane w ściśle określonej kolejności fazy. Rys. 1 przedstawia podstawowy model procesu wytwórczego, tzw. model wodospadowy, w którym każda z faz wykonywana jest dokładnie jeden raz i przejście do następnej fazy jest możliwe tylko wówczas, gdy w pełni zakończone zostały wszystkie czynności związane z fazą aktualną. Model wodospadowy, chociaż jeszcze w latach 80-tych był uważany za jedyne rozsądne podejście do wytwarzania oprogramowania, niezbyt nadaje się do realizacji dużych, złożonych systemów. Nie mniej jednak, ponieważ te bardziej złożone modele (np. wodospadowy z iteracjami, przyrostowy, spiralny Bohem'a, RUP, itd.) także wykorzystały ideę modelu wodospadowego, omówimy poszczególne fazy cyklu życiowego systemu informatycznego w oparciu o ten model.

17 Proces wytwórczy a metodyka
W fazie analizy najczęściej wykorzystywane modele: Model przypadków użycia Model obiektowy Jedną z pierwszych faz w modelu wodospadowym jest faza analizy wymagań, podczas której identyfikuje się wymagania przyszłego użytkownika systemu (opisując je w postaci przypadków użycia), a następnie dokonuje się transformacji wymagań do zbioru klas i konstruujemodel pojęciowy systemu, będący modelem problemu (dziedziny problemowej). Analiza skupia się głównie na funkcjonalności systemu i ignoruje zarówno wymagania niefunkcjonalne (np. użyteczność, niezawodność, wydajność, wsparcie dla pielęgnacji, itp.), jak i ograniczenia środowiska implementacji. Można powiedzieć, że analiza prowadzi do uzyskania "prawie idealnego" obrazu systemu. W fazie analizy najczęściej wykorzystywane są następujące modele: -Model przypadków użycia, który opisuje funkcjonalność systemu widzianą z perspektywy jego przyszłych użytkowników. Model ten jest przedstawiany w postaci diagramu przypadków użycia. -Model obiektowy, który opisuje statyczną budowę systemu, czyli jego strukturę. Model ten jest przedstawiany w postaci diagramu klas i diagramu obiektów. Główna różnica pomiędzy diagramem klas a diagramem obiektów jest taka, że diagram klas przedstawia klasy oraz może przedstawiać obiekty, podczas gdy diagram obiektów przedstawia obiekty, ale nie przedstawia klas. Model dynamiczny (inaczej: model zachowań), który służy do zidentyfikowania metod niezbędnych systemowi do realizacji jego zadań; najczęściej rozważanymi rodzajami zadań są przypadki użycia. Model ten jest przedstawiany w postaci m.in. diagramów stanów i diagramów komunikacji między obiektami. Zidentyfikowane metody nanoszone są na stworzony uprzednio wstępny diagram klas uzupełniając w ten sposób definicje jego klas. W fazie projektowania model pojęciowy jest dostosowywany do wymagań niefunkcjonalnych oraz do ograniczeń środowiska implementacji, stając się modelem logicznym. Podstawowym zadaniem tej fazy jest określenie najlepszej strategii dla sposobu implementowania systemu. Wyniki powinny być szczegółowe na tyle, by w trakcie implementacji nie powstawały niejednoznaczności - stopień szczegółowości jest uzależniony od doświadczenia programistów i złożoności problemu. W fazie następnej, czyli podczas implementacji, model logiczny jest przekształcany w model fizyczny, czyli kod. Model logiczny oraz model fizyczny stanowią modele rozwiązania.

18 Język UML Język UML (Unified Modeling Language) - "The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system." Jednym z najbardziej znanych obecnie obiektowych języków modelowania jest język UML (Unified Modeling Language). Według definicji podanej przez firmę Rational: "The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system.", co oznacza, że jest to język służący do specyfikowania, konstruowania, obrazowania i dokumentowania składowych systemów oprogramowania. Twórcami UML są trzej sławni metodolodzy inżynierii oprogramowania: Grady Booch, Ivar Jacobson oraz James Rumbaugh. Każdy z nich jest autorem własnej metodyki i związanej z nią notacji. Ich intencją było stworzenie takiego języka modelowania, który nie miałby wad ich własnych rozwiązań oraz mógłby być wykorzystany w dowolnej metodyce obiektowej. Krótką charakterystykę tych metodyk zamieszczamy poniżej: OOAD (G. Booch) - jest to metodyka użyteczna w projektowaniu oraz określaniu związków ze środowiskiem implementacji, nie wspiera jednak dostatecznie dobrze fazy rozpoznania i analizy wymagań użytkowników. OOSE (I. Jacobson) - jest to metodyka użyteczna w modelowaniu aspektu użytkowników i cyklu życiowego systemu, nie wspiera jednak w wystarczającym stopniu implementacji. OMT (J. Rumbaugh) - jest to metodyka użyteczna w modelowaniu dziedziny przedmiotowej, nie wspiera jednak w wystarczającym stopniu modelowania użytkowników systemu oraz implementacji. Wiele ważnych zagadnień z zakresu konstruowania systemów informatycznych nie zostało objętych przez żadną z wyżej wymienionych metodyk, jak na przykład prototypowanie, komponenty, przystosowanie notacji do indywidualnych preferencji projektantów, itd. Celem twórców UML'a było uwzględnienie również tych aspektów. UML cieszy się aktualnie bardzo dużą popularnością i prawdopodobnie przez wiele najbliższych lat będzie dominował w obszarze analizy i projektowania. Należy jednak pamiętać, że UML jest językiem, a nie metodyką konstruowania oprogramowania. Oznacza to, że nie podaje on wskazówek, jak należy organizować poszczególne fazy procesu wytwórczego, zaś jako notacja może być zastosowany praktycznie w dowolnej metodyce obiektowej. Niezależnie od tego, zgodnie z intencją jego twórców, pojęcia wspierane przez ten język mają w założeniu odnosić się do większości istotnych aspektów budowanych współcześnie systemów informatycznych. UML posiada wiele zalet, nie jest jednak wolny od wad. Wielu specjalistów krytycznych w stosunku do niego zwraca uwagę na to, że jego definicja jest zbyt obszerna (kilkaset stron tekstu i rysunków) oraz niestabilna (co kilka lat pojawia się nowa wersja). Co więcej, definicja ta zawiera sporą liczbę nieścisłości, które sprawiają, że często różne osoby różnie interpretują te same elementy języka, przez co jego rola jako standardowego języka modelowania jest w konsekwencji znacznie ograniczona.

19 Diagramy UML Język UML definiuje następujący zestaw diagramów:
diagram przypadków użycia diagram klasdiagramy dynamiczne diagram stanów diagram aktywności diagramy interakcji: diagram sekwencji oraz diagram współpracy diagramy implementacyjne: diagram komponentów diagram wdrożeniowy diagram pakietów Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy do modelowania funkcjonalności systemu z punktu widzenia jego przyszłych użytkowników; diagram klas - służy do modelowania struktury danych przechowywanych w systemie; diagramy dynamiczne - służą do modelowania zachowań: diagram stanów; diagram aktywności; diagramy interakcji: diagram sekwencji oraz diagram współpracy; diagramy implementacyjne: diagram komponentów; diagram wdrożeniowy; diagram pakietów - służy do celów organizacyjnych. Powyższe diagramy pozwalają opisać projektowany system z wielu perspektyw, razem składając się na jego szczegółowy opis. Zależności pomiędzy diagramami i różnymi rodzajami modelów, oraz definiowane przez nie pojęcia, są przedstawione w Tab. 1.

20 Główny obszar działania
Diagramy UML Główny obszar działania Modele Diagramy UML Podstawowe pojęcia struktura model obiektowy diagram klas klasa, obiekt, asocjacja, generalizacja, zależność, realizacja, interfejs diagram obiektów model przypadków użycia diagram przypadków użycia aktor, przypadek użycia, «include», «extend», generalizacja model implementacji diagram komponentów komponent, interfejs, zależność, realizacja diagram wdrożeniowy węzeł, komponent, zależność, lokacja dynamika model dynamiczny diagram stanów stan, zdarzenie, przejście, akcja, aktywność diagram aktywności stan, aktywność, fork, join, romb decyzyjny diagram interakcji interakcja, współpraca, komunikat, aktywacja zarządzanie model zarządzania diagram pakietów pakiet, podsystem rozszerzalność wszystkie modele wszystkie diagramy stereotyp, wartość etykietowana, ograniczenie

21 Mechanizm rozszerzalności
Mechanizmy rozszerzalności w UML: Stereotypy Wartości etykietowane Ograniczenia Komentarze Istniejące w języku UML mechanizmy rozszerzalności umożliwiają definiowanie i wykorzystywanie nowych elementów składniowych diagramów oraz przedstawianie na diagramach dodatkowych informacji, których nie można wyrazić za pomocą standardowych elementów języka. Głównym przeznaczeniem tego rodzaju mechanizmów jest uczynienie z UML elastycznego narzędzia modelowania, które można przystosować do specyficznych preferencji analityka. W UML występują następujące mechanizmy rozszerzalności: stereotypy - służą do meta-klasyfikacji elementów diagramu; wartości etykietowane - są nazwanymi wartościami przypisanymi do elementów diagramu; ograniczenia - są warunkami nałożonymi na elementy diagramu (warunki te muszą być zawsze spełnione); komentarze - są adnotacjami przypisanymi do elementów diagramu; w przeciwieństwie do ograniczeń nie wnoszą one do diagramu żadnej nowej informacji z punktu widzenia analizowanej dziedziny problemowej.

22 Podsumowanie W wykładzie przedstawiono kilka podstawowych metod walki z kryzysem oprogramowania. Ponadto, umieszczono krótką charakterystykę obiektowego podejścia do wytwarzania oprogramowania i korzyści z tym związanych oraz zaprezentowano krótki opis języka UML.

23 Dziękuję za uwagę