Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 1 Czerwiec 1999 Wprowadzenie do obiektowych metodyk projektowania i notacji.

Podobne prezentacje


Prezentacja na temat: "K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 1 Czerwiec 1999 Wprowadzenie do obiektowych metodyk projektowania i notacji."— Zapis prezentacji:

1 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 1 Czerwiec 1999 Wprowadzenie do obiektowych metodyk projektowania i notacji UML (Unified Modeling Language) Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Jedenasta Górska Szkoła PTI Szczyrk99

2 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 2 Czerwiec 1999 Plan wykładu Trochę o obiektowości Trochę o inżynierii oprogramowania Trochę o obiektowych metodykach analizy i projektowania Trochę o UML Podziękowanie dla Artura Kasprzyka za okazaną pomoc w przygotowaniu materiału.

3 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 3 Czerwiec 1999 Część 1: Inżynieria oprogramowania Wprowadzenie do obiektowych metodyk projektowania i notacji UML Jedenasta Górska Szkoła PTI Szczyrk99

4 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 4 Czerwiec 1999 Przedmiot inżynierii oprogramowania Inżynieria oprogramowania jest to wiedza techniczna dotycząca wszystkich faz cyklu życia oprogramowania. Traktuje oprogramowanie jako produkt. Dobre oprogramowanie powinno być: zgodne z wymaganiami użytkownika, niezawodne, efektywne, łatwe w konserwacji, ergonomiczne. Produkcja oprogramowania jest procesem składającym się z wielu faz. Kodowanie (pisanie programów) jest tylko jedną z nich, niekoniecznie najważniejszą. Inżynieria oprogramowania jest wiedzą empiryczną, a nie pochodną teorii.

5 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 5 Czerwiec 1999 Zagadnienia inżynierii oprogramowania Sposoby prowadzenia przedsięwzięć informatycznych. Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przesięwzięć informatycznych. Metody analizy i projektowania systemów. Techniki zwiększania niezawodności oprogramowania. Sposoby testowania systemów i szacowania niezawodności. Sposoby przygotowania dokumentacji technicznej i użytkowej. Procedury kontroli jakości. Metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń) Techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

6 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 6 Czerwiec 1999 Tworzenie niezawodnego oprogramowania Znaczenie niezawodności: Troska o zadowolenie klientów oprogramowania. Niezawodność oprogramowania ustępuje niezawodności sprzętu. Jest to prawdopodobnie nieuchronne ze względu na znacznie mniejszą powtarzalność oprogramowania i większy stopień jego złożoności. Potencjalnie wysokie straty finansowe wynikające z błędnego działania oprogramowania, zagrożenie dla bezpieczeństwa ludzi i ludzkich własności. Nieprzewidywalność skutków oraz trudność usunięcia błędów w oprogramowaniu. Kompromis pomiędzy efektywnością i niezawodnością. Łatwiej jednak pokonać problemy zbyt małej efektywności niż zbyt małej niezawodności.

7 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 7 Czerwiec 1999 Kryzys oprogramowania (1) Sprzeczność pomiędzy odpowiedzialnością, jaka spoczywa na współczesnych SI, a ich zawodnością wynikającą ze złożoności i ciągle niedojrzałych metod tworzenia i weryfikacji oprogramowania. Ogromne koszty utrzymania oprogramowania. Niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania; niski stopień powtarzalności poszczególnych przedsięwzięć. Długi i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo niepowodzenia projektu programistycznego. Długi i kosztowny cykl życia SI, wymagający stałych (często globalnych) zmian. Eklektyczne, niesystematyczne narzędzia i języki programowania.

8 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 8 Czerwiec 1999 Kryzys oprogramowania (2) Frustracje projektantów oprogramowania i programistów wynikające ze zbyt szybkiego postępu w zakresie języków, narzędzi i metod oraz uciążliwości i długotrwałości procesów produkcji, utrzymania i pielęgnacji oprogramowania. Uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są stabilne w długim horyzoncie czasowym. Problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych. Problemy przystosowania istniejących i działających systemów do nowych wymagań, tendencji i platform sprzętowo-programowych. Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania.

9 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 9 Czerwiec 1999 Źródła złożoności oprogramowania Zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji. Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów. Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów. Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia. Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia. Oprogramowanie : decyzje strategiczne, analiza, projektowanie, konstrukcja, dokumentacja, wdrożenie, szkolenie, eksploatacja, pielęgnacja, modyfikacja. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

10 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 10 Czerwiec 1999 Jak walczyć ze złożonością ? Zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości. Zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy. Zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd. Zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata.

11 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 11 Czerwiec 1999 Walka z kryzysem oprogramowania Stosowanie technik i narzędzi ułatwiających pracę nad złożonymi systemami; Korzystanie z metod wspomagających analizę nieznanych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń; Usystematyzowanie procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i monitorowanie; Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia.

12 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 12 Czerwiec 1999 Modelowanie pojęciowe Projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania. Pojęcia modelowania pojęciowego (conceptual modeling) oraz modelu pojęciowego (conceptual model) odnoszą się procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzacych w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu.

13 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 13 Czerwiec 1999 Perspektywy w modelowaniu pojęciowym Percepcja rzeczywistego świata Analityczny model rzeczywistości Model struktur danych i procesów SI... Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz konstrukcji SI jest dążenie do minimalizacji luki pomiędzy myśleniem o rzeczywistym problemie a myśleniem o danych i procesach zachodzących na danych. odwzorowanie

14 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 14 Czerwiec 1999 Niezgodność modelu pojęciowego i relacyjnego Firma Nazwa Miejsce * Pracownik Zawód* Osoba Nazwisko Imię * Adres * Zatrudnienie Wypłata * Ocena * FZPZ Firma(NrF, Nazwa) Lokal(NrF, Miejsce) Zatrudnienie(NrF, NrP) Pracownik(NrP, NrOs) Oceny(NrOceny, Ocena, NrF, NrP) Dochód ( NrDochodu, Wypłata, NrF, NrP) Osoba (NrOs, Nazwisko) Wyszkolenie (Zawód, NrP) Imiona (NrOs, Imię) Adresy (NrOs, Adres ) 0..* 11 Pojęciowy schemat obiektowy: Schemat relacyjny:

15 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 15 Czerwiec 1999 SBQL: (Firma where Radom in Miejsce).FZ.Zatrudnienie.PZ.Pracownik.Adres SQL: select a.Adres from Lokal as k, Zatrudnienie as z, Pracownik as p, Osoba as s, Adresy as a where k.Miejsce = Radom and k.NrF = z.NrF and z.NrP = p.NrP and p.NrOs = s.NrOs and s.NrOs =a.NrOs Zapytanie w SQL jest znacznie dłuższe od zapytania w SBQL wskutek tego, że w SQL konieczne są złączeniowe predykaty (takie jak k.NrF=z.NrF i następne) kojarzące informację semantyczną, która jest dana implicite w relacyjnej strukturze danych. Jakie są skutki niezgodności modelu pojęciowego i relacyjnego? Schemat relacyjny jest trudniejszy do odczytania i zinterpretowania przez programistę. Efektem jest zwiększona skłonność do błędów (mylnych interpretacji). Programy manipulacyjne odwołujące się do schematu relacyjnego są dłuższe od programów odwołujących się do schematu obiektowego (szacunkowo od 30% do 70%). Ma to ogromne znaczenie dla tempa tworzenia oprogramowania, jego jakości, pielęgnacyjności, itd. Programy te są też zwykle znacznie wolniejsze. Mini przykład: Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu

16 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 16 Czerwiec 1999 Część 2. Pojęcie metodyki analizy i projektowania Wprowadzenie do obiektowych metodyk projektowania i notacji UML Jedenasta Górska Szkoła PTI Szczyrk99

17 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 17 Czerwiec 1999 Co to jest metodyka (metodologia)? Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego, logicznego i/lub fizycznego. Metodyka jest powiązana z notacją służącą do zapisywania wyników faz projektu (pośrednich, końcowych), jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem. Metodyka ustala: Metodyka ustala: fazy projektu, role uczestników projektu, modele tworzone w każdej z faz, scenariusze postępowania w każdej z faz, reguły przechodzenia od fazy do następnej fazy, notacje, których należy używać, dokumentację powstającą w każdej z faz.

18 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 18 Czerwiec 1999 Metodyki obiektowe i strukturalne Metodyki strukturalne - metody tradycyjne rozwijane od lat 60-tych. Łącza składowe pasywne (opis danych) oraz aktywne (wykonywanie operacji). Metodyki obiektowe - rozwijane od lat 80-tych, oparte na wyróżnianiu obiektów łącznie z operacjami. Analiza strukturalna (structured analysis) rozpoczyna się od budowy dwóch różnych modeli systemu: modelu danych oraz modelu funkcji. Te dwa modele są integrowane.Wynikiem jest model przepływu danych (data flow model). Wadą podejścia są trudności w zintegrowaniu modeli. Ostatnio coraz bardziej popularne są metodyki obiektowe. Metodyki posługują się notacją, z reguły graficzną, którą dość często utożsamia się z samą metodyką (niesłusznie).

19 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 19 Czerwiec 1999 Różnice pomiędzy metodykami Podejścia proponowane przez różnych autorów róznią się częściowo, nie sa jednak ze sobą sprzeczne. Poszczególne metodyki zawieraja elementy rzadko wykorzystywane w praktyce (np. model przepływu danych w OMT). Notacje proponowane przez różnych autorów nie są koniecznie nierozerwalne z samą metodyką. Np. notacji UML można użyć dla metodyki Coad/Yourdon. Nie ma metodyk uniwersalnych. Analitycy i projektanci wybierają kombinację technik i notacji, która jest w danym momencie najbardziej przydatna. Wybór może być jednak utrudniony istniejącą rutyną w danej firmie. Narzędzia CASE nie narzucają metodyki; raczej, określają one tylko notację. Twierdzenia, że jakieś narzedzie CASE jest oparte na konkretnej metodyce jest najczęściej wyłącznie hasłem reklamowym.

20 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 20 Czerwiec 1999 Czy wierzyć metodykom? Nie istnieją wiarygodne testy wskazujące na to, że przyjęcie pewnej konkretnej metodyki lub notacji usprawniło proces projektowania, lub że dana metodyka lub notacja jest lepsza od innej. Zalety/wady metodyk i notacji są subiektywne i sprowadzają się często do zręczności w sztuce retoryki. Wielu specjalistów uważa twórczość w zakresie metodyk za arbitralny zestaw reguł i zaleceń, czy też spekulacje, za którymi nie kryją się ani głębokie uzasadnienia ani obiektywne prawdy. Dość często doświadczenie praktyczne twórców metodyk jest ograniczone lub dotyczy poprzedniej epoki informatycznej, której problemy i paradygmaty uległy dezaktualizacji. Nawet najlepsze metodyki i narzędzia CASE nie są w stanie zapewnić jakości projektów. Kluczem do dobrego projektu jest zespół doświadczonych, zaangażowanych i kompetentnych osób, dla których metodyka i notacja taka jak UML oraz wykorzystujące ją narzędzia CASE mogą wyłącznie służyć jako istotne, lecz drugorzędne wspomaganie.

21 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 21 Czerwiec 1999 Co to jest metodyka obiektowa? Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego oraz analizy i projektowania systemów informatycznych. Podstawowym składnikiem jest diagram obiektów, będący zwykle wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek. Diagram obiektów zawiera: klasy, w ramach klas specyfikacje atrybutów i metod, związki generalizacji, związki asocjacji i agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia. Uzupełnieniem tego diagramu są inne: diagramy dynamiczne uwzględniające stany i przejścia pomiędzy tymi stanami, diagramy zależności pomiędzy wywołaniami metod, diagramy funkcjonalne (będące zwykle pewną mutacją diagramów przepływu danych), itd. Popularność zdobyła koncepcja przypadków użycia (use cases), której podstawowym celem i walorem jest odwzorowanie struktury systemu z punktu widzenia jego użytkownika.

22 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 22 Czerwiec 1999 Metodyki obiektowe Martin/Odell BON (Business Object Notation), Nerson & Walden OODA, Booch Catalysis, DSouza & Wills EROOS (Entity-Relationship Object-Oriented Specification) Fusion, HP Laboratories MOSES/OPEN (Methodology for OO Software Engineering of Systems) OORAM OSA OOSA, Shlaer-Mellor Sintropy OMT, Rumbaugh Objectory, Jacobson OOA/OOD, Coad/Yourdon DOOS, Wirfs-Brock MainstreamObjects, Yourdon Express Goldberg/Rubin : Eksplozja metodyk i notacji obiektowych. Powstało ich ponad 20. Obecnie obserwuje się ich zredukowanie, koncentrację: UML, OPEN, BON,...

23 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 23 Czerwiec 1999 Notacje w analizie i projektowaniu Rodzaje notacji Język naturalny Notacje graficzne Specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny Szczególne znaczenie maja notacje graficzne. Inżynieria oprogramowania wzoruje się na innych dziedzinach techniki, takich jak elektronika i mechanika. Zalety notacji graficznych potwierdzają badania psychologiczne. Funkcje notacji Narzędzie pracy analityka i projektanta, zapis i analiza pomysłów Współpraca z użytkownikiem Komunikacja z innymi członkami zespołu Podstawa implementacji oprogramowania Zapis dokumentacji technicznej Notacje powinny być przejrzyste, proste, precyzyjne, łatwo zrozumiałe, umożliwiające modelowanie złożonych zależności.

24 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 24 Czerwiec 1999 Cykl życiowy oprogramowania Określenie strategicznych celów wprowadzenia informatyki Planowanie i definicja projektu Analiza Analiza dziedziny przedsiębiorczości Analiza wymagań systemowych Projektowanie Projektowanie pojęciowe Projektowanie logiczne Projektowanie fizyczne Konstrukcja Rozwijanie Testowanie Dokumentacja Przygotowanie użytkowników, akceptacja, szkolenie Działanie, włączając wspomaganie tworzenia aplikacji Utrzymanie, konserwacja, pielęgnacja

25 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 25 Czerwiec 1999 Analiza Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu; Ustalenie kontekstu projektu; Ustalenie wymagań użytkowników; Ustalenie wymagań organizacyjnych Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd. Analiza włącza następujące czynności: Analiza nie zajmuje się zmianą rzeczywistości poprzez wprowadzenie tam nowych elementów np. w postaci SI. Jej celem jest dokładne rozpoznanie wszystkich tych aspektów rzeczywistości, które mogłyby mieć wpływ na postać, organizację lub wynik projektu.

26 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 26 Czerwiec 1999 Projektowanie systemowe Etap w którym projektant systemu podejmuje decyzje wysokiego poziomu dotyczące całościowej architektury systemu. Wynikowy system jest organizowany w podsystemy na podstawie wyników analizy jak i założeń co do ogólnej architektury. Projektant musi podjąć decyzje dotyczące optymalizacji charakterystyk wydajnościowych, wybrać strategię rozwiązania tego problemu oraz podjąć decyzje odnośnie alokacji zasobów. Np. projektant musi określić charakterystyki monitorów (rozdzielczość, rozmiar ekranu, kolory), musi wybrać konfigurację sprzętu, strategię buforowania pamięci, właściwe protokóły komunikacyjne, itd.

27 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 27 Czerwiec 1999 Projektowanie Projekt bazuje na wyniku analizy oraz wyniku projektowania systemowego. Zawiera wiele elementów implementacyjnych odnoszących się do struktury danych oraz algorytmów (metod) przetwarzania. Klasy obiektów rzeczywistych wyodrębnione podczas analizy są również istotne na etapie projektowania obiektowego, z następującymi różnicami: Niektóre klasy wyodrębnione podczas analizy nie kwalifikują się do implementacji; Zwykle konieczne jest wprowadzenie nowych klas odnoszących się do struktur danych i algorytmów niezbędnych dla implementacji (ekranów, plików, itd). Zzwyczaj pojęcia odnoszące się do analizy i projektowania są opisywane w sposób jednorodny przy pomocy tej samej notacji.

28 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 28 Czerwiec 1999 Konstrukcja (implementacja) Obiekty i klasy wyodrębnione podczas projektowania obiektowego są ostatecznie odwzorowane w postaci konstrukcji języka programowania, systemu zarządzania bazą danych, udogodnień sieciowych, oraz konfiguracji sprzętowej. Zakłada się, że etap programowania powinien być mniej ważną, w zasadzie pół-mechaniczną czynnością, która nie wypacza elementów projektu. Wskazane byłoby, aby trudne decyzje dotyczące implementacji były podjęte i udokumentowane na etapie projetu. To założenie jest szczególnie ważne dla dużych projektów, gdzie pojedynczy programista nie ma możliwości ogarnięcia całościowej logiki. Odwzorowanie projektu w implementację powinno być bezszwowe, bezpośrednie, tak, aby każdy fragment oprogramowania mógł być jednoznacznie przyporządkowany odpowiedniemu fragmentowi projektu.

29 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 29 Czerwiec 1999 Tematyka analizy i projektowania obiektowego Analiza i modelowanie struktur obiektów Analiza i modelowanie procesów i sekwencji transakcji Analiza i modelowanie interakcji pomiędzy obiektami Analiza i modelowanie cyklu życiowego obiektów Kompleksowe modelowanie systemów Planowanie projektu Zarządzanie projektami dotyczącymi obiektowości Analiza wymagań dotyczących systemu Projektowanie pojęciowe, logiczne i fizyczne bazy danych Rozwijanie obiektowych aplikacji Testowanie, akceptacja, wdrażanie, działanie

30 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 30 Czerwiec 1999 Klasyczna i obiektowa struktura aplikacji Klasyczna struktura aplikacji... Typy Biblioteki procedur i funkcji Moduły aplikacyjne Słowniki, katalogi Procedury bazy danych, perspektywy, reguły Pasywne dane (relacje) Powiązane obiekty Klasy i typy... Obiektowa struktura aplikacji... Biblioteki procedur i funkcji Moduły aplikacyjne Słowniki, katalogi Procedury bazy danych, perspektywy, reguły Schemat bazy danych Schemat bazy danych

31 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 31 Czerwiec 1999 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Jedenasta Górska Szkoła PTI Szczyrk99 Część 3: Wprowadzenie do obiektowości

32 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 32 Czerwiec 1999 Źródła obiektowości Współczesne pojęcia obiektowości Współczesne pojęcia obiektowości Metodyki projektowania oprogramowania, od swojego początku bazujące na wyróżnianiu obiektów i ich klas w otaczającej nas rzeczywistości Języki programowania operujące na złożonych strukturach danych, wprowadzające klasy, metody, dziedziczenie i hermetyzację. (Simula 67, Smalltalk) Języki programowania operujące na złożonych strukturach danych, wprowadzające klasy, metody, dziedziczenie i hermetyzację. (Simula 67, Smalltalk) Bazy danych, od początku bazujące na obiektach (IMS, CODASYL). Wady modelu relacyjnego baz danych; odrzucenie jego powierzchownej prostoty. Skierowanie uwagi na czynnik ludzki w tworzeniu oprogramowania, zmniejszenie dystansu pomiędzy modelem pojęciowym a modelem realizacyjnym

33 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 33 Czerwiec 1999 Obszary oddziaływania obiektowości Metodyki analizy i projektowania SI, narzędzia CASE. Pojęcia obiektowości jako podstawa ideologiczna i koncepcyjna. Języki programowania (Smalltalk, C++, Java, Eiffel,...). Obiekty, klasy, metody, dziedziczenie, hermetyzacja, polimorfizm. Bazy danych i składy trwałych obiektów (standard ODMG, Gemstone, Versant, ObjectStore, Objectivity/DB, O2, Poet,...). Przeniesienie obiektowych technologii programowania na grunt baz danych. Obiektowość w systemach relacyjnych, systemy obiektowo-relacyjne. Współdziałanie systemów heterogenicznych (OMG CORBA, COM/DCOM,...). Obiekty i klasy jako abstrakcyjny poziom przykrywający szczegóły implementacji. Wizyjne środki programistyczne (Smalltalk, IBM VisualAge,...). Przeniesienie technik obiektowych do programowania wizyjnego. Inne: biblioteki oprogramowania, grafika, miary i oceny oprogramowania, re- inżynieria procesów biznesowych (BPR).

34 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 34 Czerwiec 1999 Przeszkody dla obiektowości Zastany świat interfejsów programistycznych (C, COBOL, Fortran, SQL,...) Zastane poglądy, mity, steoretypy i przekręty konkurencji. Typowe, często powtarzane półprawdy, nieprawdy i bzdury: Ogromne inwestycje w przedrelacyjne i relacyjne bazy danych. Konkurencja technologicznie dojrzałych systemów relacyjnych (obiektowo-relacyjnych). Własna słabość: niedopracowane zasady, formalizmy, języki, standardy; kompromisy w zakresie celów. Relacyjna baza danych zapewnia prostotę struktur danych. Relacyjne bazy danych mają solidne podstawy matematyczne. Wskaźniki/hermetyzacja/... w bazie danych są niekorzystne. Tylko relacyjne bazy danych umożliwiają realizację języków zapytań. Tylko relacyjna baza danych zapewnia przetwarzanie transakcji/rozproszenie/... Relacyjne bazy danych mają nieosiągalną dla innych wydajność/skalowalność/...

35 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 35 Czerwiec 1999 Podstawowe pojęcia obiektowości (1) Obiekty, tożsamość. Złożone struktury danych z przypisanymi do nich operacjami, czyli obiekty. Unikalny identyfikator obiektu. Powiązania, asocjacje. Obiekty mogą być powiązane związkami o charakterze wskaźników. Hermetyzacja (encapsulation). Informacja o obiekcie jest zamknięta w jednej bryle. Niepotrzebna informacja jest ukryta. Klasy, typy, interfejsy. Cechy niezmienne dla grup obiektów, np. definicje ich atrybutów i operacji, są zbierane wewnątrz klas. Typy umożliwiają kontrolę budowy obiektów i poprawności ich użycia. Specyfikacja klasy (interfejs) jest oddzielona od jej implementacji. Abstrakcyjne typy danych. Dostęp do struktur danych odbywa się wyłącznie poprzez zdefiniowy dla tych struktur zestaw operacji.

36 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 36 Czerwiec 1999 Podstawowe pojęcia obiektowości (2) Operacje, metody, komunikaty. Operacja na obiekcie jest wykonywana przy pomocy jednej z jego metod, po wysłaniu komunikatu do obiektu. Hierarchia klas i dziedziczenie. Klasy są organizowane w hierarchię. Klasy bardziej szczegółowe dziedziczą cechy klas bardziej ogólnych (definicje atrybutów, metody, itd.). Przesłanianie, późne wiązanie, polimorfizm. Ten sam komunikat wysłany do różnych obiektów może wywoływać różne operacje. Wiązanie nazw operacji następuje na etapie wykonania. Metoda z klasy bardziej ogólnej może być przesłonięta przez inna metodę z klasy wyspecjalizowanej. Trwałość. Niektóre obiekty zachowują swój stan dłużej niż czas pojedynczego uruchomienia programu.

37 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 37 Czerwiec 1999 Obiekty (1) Obiektem może być także pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu,...), którym można operować jako zwartą bryłą (wyszukiwać, wiązać, kopiować, blokować, usuwać, indeksować,...). Obiekt posiada swoją tożsamość, która wyróżnia go spośród innych obiektów. Tożsamość obiektu jest niezależna od wartości jakichkolwiek jego atrybutów i od jego lokacji w świecie rzeczywistym lub w przestrzeni adresowej komputera. Obiektem jest rzecz lub pojęcie obserwowane w świecie rzeczywistym którego dotyczy SI. Obiekt jest odróżnialny od innych obiektów, ma dobrze określone granice i nazwę. Obiekt posiada stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu).

38 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 38 Czerwiec 1999 Obiekty (2) Obiekt może być złożony, tj. może składać się z mniejszych obiektów. Obiekt złożony odnoszący się do modelowanej rzeczywistości zawiera w sobie wszystkie cechy modelowanego obiektu. Obiekt może być złożony, tj. może składać się z mniejszych obiektów. Obiekt złożony odnoszący się do modelowanej rzeczywistości zawiera w sobie wszystkie cechy modelowanego obiektu. Obiekt może być powiązany z innymi obiektami związkami skojarzeniowymi. Obiekt ma przypisane zachowanie, tj. zestaw operacji które wolno do niego stosować. Implementacja operacji jest zwana metodą. Obiekt ma przypisany typ, tj. wyrażenie językowe, które ogranicza budowę obiektu, ustala operacje, które wolno wykonać na obiekcie, oraz ogranicza kontekst, w którym dany obiekt moze być użyty w programie.

39 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 39 Czerwiec 1999 Przykład obiektu Wypłać Wpłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto Nalicz procent KONTO Numer SaldoZł Właściciel Jan Kowalski Upoważniony Ewa Kowalska....

40 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 40 Czerwiec 1999 Obiekt złożony Obiekt może składać się z pewnej liczby komponentów (atrybutów), które także mogą być złożone. Komponenty obiektu mogą być traktowane jako obiekty (pod-obiekty) lub mogą być uważane za kategorię różną od obiektów. Nie powinno istnieć ograniczenie rozmiaru obiektu, liczby komponentów składających się na obiekt lub liczby poziomów hierarchii komponentów. Obiekt złożony reprezentujący pewien byt świata rzeczywistego powinien zawierać wewnątrz siebie wszelkie informacje, które odnoszą się do tego bytu. Ustalenia, które informacje odnoszą się do danego obiektu, a które do innego, zależą od modelu pojęciowego projektanta lub programisty i nie powinny podlegać ograniczeniom ze strony bazy realizacyjnej.

41 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 41 Czerwiec 1999 Obiekty złożone (kompozytowe) Pracownicy..... Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko

42 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 42 Czerwiec 1999 Powiązania pomiędzy obiektami FIRMA NrFirmy Nazwa Syntex Prezes Zatrudnia PRACOWNIK Nazwisko Nowak Zarobek 1500 PracujeW PRACOWNIK Nazwisko Babel Zarobek 2000 PracujeW PRACOWNIK Nazwisko Kowal Zarobek 2500 PracujeW PRACOWNIK Nazwisko Zarobek FIRMA NrFirmy Nazwa PrezesZatrudnia PracujeW 0..* 0..1 Diagram klas: Na poziomie realizacyjnym powiązania pomiędzy obiektami można sobie wyobrazić jako wskaźniki prowadzące od obiektu do obiektu. Na poziomie pojęciowym powiązania nie mają charakteru wskaźników, lecz pewnych abstrakcyjnych nitek łączących obiekty. Asocjacje: abstrakcyjne oznaczenia powiazań na diagramach klas.

43 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 43 Czerwiec 1999 Powiązania jako nitki łączące obiekty OSOBA Nowak OSOBA Bober OSOBA Kowalska OSOBA Bielicka OSOBA Maciąg OSOBA Wilczek Transakcja Kupujący Sprzedający Pośrednik Transakcja Kupujący Sprzedający Pośrednik Transakcja Kupujący Sprzedający Pośrednik OSOBA Nazwisko Sprzedający Kupujący Transakcja Pośrednik Diagram klas:

44 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 44 Czerwiec 1999 Atrybuty powiązań OSOBA Nowak OSOBA Bober OSOBA Kowalska OSOBA Bielicka OSOBA Maciąg OSOBA Wilczek Kupujący Sprzedający Kupujący Sprzedający Pośrednik Transakcja Samochód Kupujący Sprzedający Pośrednik DaneTransakcji PrzedmiotTransakcji DataTransakcji WartośćTransakcji Transakcja Dom Transakcja Plac Pośrednik OSOBA Nazwisko Sprzedający Kupujący Transakcja Diagram klas:

45 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 45 Czerwiec 1999 Modelowanie powiązań jako obiektów OSOBA Nowak OSOBA Bober OSOBA Kowalska OSOBA Bielicka OSOBA Maciąg OSOBA Wilczek KupującySprzedający Kupujący Sprzedający Pośrednik Kupujący Sprzedający Pośrednik TRANSAKCJA Dom TRANSAKCJA Plac TRANSAKCJA Samochód * Pośrednik OSOBA Nazwisko Sprzedający Kupujący Diagram klas: Transakcja PrzedmiotTransakcji DataTransakcji WartośćTransakcji

46 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 46 Czerwiec 1999 Liczność asocjacji AB: min = 1, max = 1 Oznaczenia liczności na diagramie klas: AAAAA BBB A B 1..* BA: min = 1, max = n BBB A B 0..* 1..* AAAAA B: min = 1, max = nA A: min = 0, max = nB BBB A B 0..* 0..1 AAAAA B: min = 0, max = 1A A: min = 0, max = nB

47 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 47 Czerwiec 1999 Hermetyzacja i ukrywanie informacji PRACOWNIK NAZWISKO NowakROK_UR 1951 ZAROBEK 2500 ZmieńZarobek(...) {...}; Podatek(){...}; ZarobekNetto() {...}; Wiek() { return RokBież - ROK_UR }; DZIAŁ Zabawki Wewnętrzna struktura obiektuZewnętrzna struktura obiektu PRACOWNIK NAZWISKO Nowak ZmieńZarobek(...) ZarobekNetto() Wiek() DZIAŁ Zabawki Hermetyzacja: zamykanie szczegółów w bryłę, którą można manipulować tak jak jednostką (D. Parnas, 1972). Ukrywanie informacji: programista ma tyle wiedzieć o tworze programistycznym (procedurze, module, obiekcie, klasie), ile mu trzeba, aby go efektywnie używać. Wszystko, co może być przed nim ukryte, powinno być ukryte.

48 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 48 Czerwiec 1999 Komunikaty Numer SaldoZł Właściciel Jan Kowalski Upoważniony Wpłać Wypłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto Nalicz procent Wypłać ( 1000 ) OK, wypłaciłem Graj ??? błąd! KONTO Komunikat jest wyrażeniem językowym skierowanym do obiektu. Nazwa użyta w komunikacie jest nazwą metody skojarzonej z obiektem. Źródłem komunikatu jest pewien obiekt lub aktualnie działający program. Komunikat może mieć parametry. Obiekt otrzymujący komunikat wykonuje odpowiednią metodę, która może zmienić jego stan. Po wykonaniu metody obiekt, który otrzymał komunikat, może zwrócić odpowiedź do obiektu lub programu, który go wysłał. Odpowiedź nie jest komunikatem.

49 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 49 Czerwiec 1999 Komunikat a wołanie procedury Wołanie procedury: obiekt jest komunikowany jako parametr: procedura( obiekt, par1, par2,...) Komunikat: obiekt-adresat poprzedza wywołanie metody: obiekt.metoda(par1, par2,...) Komunikat nie określa która konkretnie metoda ma być wywołana; komunikat jest kierowany do obiektu, i w zależności od niego może być wywołana zupełnie inna metoda. Pojęcia są bardzo podobne: Zasadnicza różnica: X = dochody( emeryt ) Y = dochody( pracownik ) Musi być przełączenie explicite wewnątrz procedury dochody; procedurę musi pisać jeden programista, na wszystkie okazje. X = emeryt.dochody() Y = pracownik.dochody() Nie ma przełączenia; wywoływana jest zupełnie inna metoda dochody w zależności od obiektu - adresata komunikatu. Te metody (i ich programiści) nie muszą nic o sobie wiedzieć.

50 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 50 Czerwiec 1999 Przesyłanie komunikatów a równoległość Często termin przesyłanie komunikatów (message passing) jest mylnie interpretowany. Zgodnie z wypowiedziami niektórych autorów, obiekty komunikują się ze sobą asynchronicznie i równolegle poprzez mechanizm komunikatów, zaś obiektowość postuluje taką równoległość (lub wręcz rozwiązuje problem równoległości). Są to poglądy nieuzasadnione i naiwne. Są one oparte na budowaniu pochopnej analogii ze światem rzeczywistym, gdzie obiekty posiadają własną autonomię i funkcjonują niezależnie od siebie, komunikując się między sobą w ramach swoich potrzeb. Obiektowość nic takiego nie zakłada. Przetwarzanie równoległe jest ważnym i trudnym problemem, całkowicie niezależnym w stosunku do obiektowości, a w szczególności do mechanizmu przesyłania komunikatów. Komunikat należy rozumieć jako obiektowy odpowiednik wołania procedury.

51 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 51 Czerwiec 1999 Klasy Klasa jest miejscem przechowywania cech obiektów, które są niezmienne (inwariantów). Klasa nie jest zbiorem obiektów i nie jest definicją zbioru obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus niektóre własne. Najważniejsze inwarianty to: Możliwe są inne inwarianty: Zdarzenia lub wyjątki, które mogą zajść w operacjach na obiekcie Obsługa zdarzeń lub wyjątków Lista eksportowa, określająca, które atrybuty dostępne są z zewnątrz Ograniczenia, którym musi podlegać każdy obiekt Nazwa, czyli językowy identyfikator obiektu Typ, czyli statyczna budowa obiektu (atrybuty) Metody, czyli operacje, które można wykonać na obiekcie Klasa jest nazwanym zbiorem obiektów o podobnych własnościach. Własności te (zestaw atrybutów, metody) są określone w definicji klasy. Stosunek klasa/podklasa oznacza zawieranie się zakresów znaczeniowych. Np. zbiór obiektów Student zawiera się w zbiorze obiektów Osoba. Zła definicja: Dobra definicja:

52 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 52 Czerwiec 1999 Wyodrębnienie klasy Wpłać Porównaj podpis Zlikwiduj konto Wpłać Porównaj podpis Zlikwiduj konto Wpłać Wypłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto Nalicz procent Obiekty KONTO (punkt widzenia użytkownika) Obiekty KONTO (reprezentacja wewnątrz pamięci) Klasa KONTO Związki jest wystąpieniem klasy Numer: char[8] SaldoZł: integer Właściciel: string Upoważniony: string.... Wpłać Wypłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto Nalicz procent KONTO Numer SaldoZł Właściciel Jan Kowalski Upoważniony Jan Kowalski....

53 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 53 Czerwiec 1999 Wyodrębnienie hierarchii dziedziczenia Klasa ogólna Klasa wyspecjalizowana PRACOWNIK Nazwisko Imię RokUrodz Zarobek Firma Zdjęcie Wiek() ZarobekNetto() ZmieńZarobek(...) PRACOWNIK Zarobek Firma Zdjęcie ZarobekNetto() ZmieńZarobek(...) Hierarchia dziedziczenia OSOBA Nazwisko Imię RokUrodz Wiek() OSOBA Nazwisko Imię RokUrodz Wiek()

54 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 54 Czerwiec 1999 Generalizacja/specjalizacja Generalizacja: budowa pojęć bardziej ogólnych jeżeli mamy pojęcia bardziej szczegółowe. Specjalizacja: budowa pojęć bardziej szczegółowych jeżeli mamy pojęcia bardziej ogólne. Generalizacja: budowa pojęć bardziej ogólnych jeżeli mamy pojęcia bardziej szczegółowe. Specjalizacja: budowa pojęć bardziej szczegółowych jeżeli mamy pojęcia bardziej ogólne. Sklep nazwa adres Rodzaj towaru Firma usługowa nazwa adres Rodzaj usługi Firma nazwa adres Sklep Rodzaj towaru Firma usługowa Rodzaj usługi Firma nazwa adres...Rodzaj towaru?...Rodzaj usługi? Generalizacja Specjalizacja

55 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 55 Czerwiec 1999 Polimorfizm OSOBA nazwisko kategoria.... STUDENT.... dochody().... obiekt PRACOWNIK.... dochody().... EMERYT.... dochody().... obiekt Każda klasa ma własną metodę dochody. Są one niezależne i są niezależnie programowane

56 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 56 Czerwiec 1999 Ekstensja klasy OSOBA Nazwisko Nowacki RokUr 1940 OSOBA Nazwisko Abacki RokUr 1948 OSOBA Nazwisko Nowak RokUr 1951 OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(...) OSOBA Nazwisko Kowalska RokUr 1975 PRACOWNIK Nazwisko Nowak RokUr 1951 Zarobek 2000 Dział zabawki PRACOWNIK Nazwisko Abacki RokUr 1948 Zarobek 2500 Dział zabawki PRACOWNIK Nazwisko Nowacki RokUr 1940 Zarobek 3000 Dział sprzedaż Ekstensja klasy OSOBA Ekstensja klasy PRACOWNIK

57 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 57 Czerwiec 1999 Delegacja Określenie sytuacji w modelu obiektowym, gdy komunikat wysyłany do danego obiektu powoduje wykonanie operacji na innym obiekcie (jest oddelegowany do innego obiektu). W UML delegacją jest nazywana sytuacja, kiedy obiekt po otrzymaniu komunikatu wysyła komunikat do innego obiektu. Często określenie delegacja dotyczy sytuacji, kiedy jakiś złożony atrybut obiektu jest także obiektem i jest wystąpieniem innej klasy. Jest ona także określana jako dziedziczenie w ramach wystąpień obiektów, co kojarzy ją z pojęciem prototypu. W tym znaczeniu pojęcie to jest wykorzystywane dla pewnych technicznych celów, np. obejścia braku dziedziczenia lub wielodziedziczenia. Pojęcie delegacji nie zawsze jest jasne, ponieważ opiera się na powierzchownych cechach specyficznych dla modelu obiektowego przyjętego w danym języku, co powoduje dość różne jego rozumienie. Np. w języku Smalltalk (gdzie wszystko jest obiektem) trudno wyróżnić istotną merytorycznie podstawę definicji tego pojęcia.

58 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 58 Czerwiec 1999 Klasa, interfejs, typ Mnóstwo nieporozumień na tle rozróżnień pomiędzy tymi pojęciami. Klasa. Zestaw cech wspólnych dla obiektów zarówno w planie ich populacji, jak i zmian zachodzących w czasie. Klasa jest jednostką ponownego użycia i obrotu handlowego. Zawiera wszystko to, co jest potrzebne do tego, aby ją umieścić wewnątrz pewnej aplikacji, w szczególności, implementację metod, implementację bloków reakcji na zdarzenia, itd. Interfejs. Komplet informacji o tych własnościach obiektów klasy, które są niezbędne do ich poprawnego użycia. Interfejs posiada znaczenie pojęciowe dla użytkownika lub programisty, pozwalając na manipulowanie zewnętrznymi cechami obiektów i przewidywanie skutków tych manipulacji. Interfejs może być (nieodpłatnie) opublikowany w podręczniku. Pojedynczy interfejs może cechować wiele implementacji, jak również jedna klasa może być wyposażona w wiele interfejsów. Typ. Specyfikacja ograniczająca kontekst, w którym obiekty danej klasy mogą być użyte w wyrażeniach, zapytaniach lub programach. Typ określa również reprezentację wartości przechowywanych wewnątrz obiektu. Niekiedy typ określa również wewnętrzną budowę obiektów. Typ jest pojęciem różnym zarówno od klasy jak i od interfejsu.

59 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 59 Czerwiec 1999 Wielokrotne dziedziczenie POJAZD ciężar..... prędkość_eksploat() POJAZD_LĄDOWY ilość_kół max_prędkość..... POJAZD_WODNY wyporność max_prędkość..... AMFIBIA SAMOCHÓDJACHTTRAKTORŻAGLÓWKA Przy wielodziedziczeniu klasa może dziedziczyć z dwóch lub więcej klas. Wielodziedziczenie prowadzi do anomalii i wad koncepcji. Z tego względu niektóre języki (m.in. Java) rezygnują z wielodziedziczenia. W wiekszości anomalie są konsekwencją faktu, że przy pomocy wielodziedziczenia próbuje się opanować koncepcję dynamicznych ról obiektu.

60 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 60 Czerwiec 1999 Dynamiczne role obiektów OSOBA Nazwisko Abacka RokUr 1948 OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(..) OSOBA Nazwisko Kowalska RokUr 1975 PRACOWNIK Zarobek 2500 Dział Kredyty STUDENT Semestr NrIndeksu WpiszOcenę(...) ObliczŚredniąOcen() OSOBA Nazwisko Nowak RokUr 1951 PRACOWNIK Zarobek 1500 Dział Obsługa STUDENT Semestr 7 NrIndeksu Klasy OSOBA Nazwisko Nowacki RokUr 1940 STUDENT Semestr 4 NrIndeksu Obiekty FIRMA Nazwa BankSA pracuje_w UCZELNIA Nazwa PW studiuje_na UCZELNIA Nazwa UW studiuje_najest_klientem

61 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 61 Czerwiec 1999 Podsumowanie obiektowości Obiektowość jest informatyczną ideologią, która zmienia myślenie realizatorów SI z zorientowanego na maszynę na zorientowane na człowieka. Obiektowość jest konsekwencją kryzysu oprogramowania: kosztów związanych z oprogramowaniem, jego zawodnością, i trudną do opanowania złożonością. Obiektowość przenika wszystkie fazy projektowania, oraz narzędzia i interfejsy. Obiektowość dopracowała się własnej kolekcji pojęć i narzędzi. W dziedzinie baz danych obiektowość jest na początku drogi i musi walczyć z konserwą i spuścizną poprzednich ideologii i technologii.

62 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 62 Czerwiec 1999 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Jedenasta Górska Szkoła PTI Szczyrk99 Część 4. Wprowadzenie do UML

63 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 63 Czerwiec 1999 Unified Modeling Language (UML) RATIONAL SOFTWARE CORPORATION UML , 1995-wrzesień UML 1.0, styczeń 1997, przesłany do OMG UML 1.1, koniec 1997, zatwierdzony jako składnik standardu OMG UML 1.3, kwiecień 1999 (mówi się o wersji 1.4, ale brak danych) Połączone siły trzech znanych metodologów oprogramowania: GradyBOOCH, Ivar JACOBSON, James RUMBAUGH Wykorzystano doświadczenia poprzednich metodyk: OOAD (Booch), OMT (Rumbaugh, et al.), Fusion (Coleman et al.), OOSE (Jacobson) (dokumentacja on line)

64 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 64 Czerwiec 1999 Czym jest a czym nie jest UML? UML nie jest metodyką analizy i projektowania. UML (jak dotąd) nie definiuje procesu rozwoju oprogramowania UML nie jest wyłącznie notacją (tzn. składnią diagramów). Definicja podana przez Rational [http://www.rational.com/uml] : –"The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system." UML jest językiem do specyfikacji, konstruowania, wizualizaji i dokumentowania wytworów związanych z systemami intensywnie wykorzystującymi oprogramowanie.

65 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 65 Czerwiec 1999 Notacja a metodyka UML nie ogranicza się do notacji. Dowolny język, w tym UML, oprócz składni posiada dwa znacznie od niej ważniejsze aspekty: semantykę i pragmatykę. Pragmatyka określa, jak do konkretnej sytuacji dopasować pewien wzorzec notacyjny. Pragmatyka UML wyznacza więc procesy prowadzące do wytworzenia zapisów wyników analizy i projektowania, które są zgodne z intencją autorów tej notacji. Jakakolwiek notacja nie ma większego sensu bez wiedzy o tym, w jaki sposób może być ona użyta w ramach pewnego procesu analizy i projektowania. Autorzy UML pracują nad metodyką, noszącą obecnie nazwę Rational Objectory Process lub Rational Unified Development Process. ( Na razie nazwy zmieniają się zbyt szybko, aby można było mieć pewność...) Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami. Pragmatyka określa, w jaki sposób i do czego należy używać przyjętych oznaczeń. Składnia określa, jak wolno kombinować ze sobą przyjęte oznaczenia.

66 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 66 Czerwiec 1999 Zalety i wady poprzedników UML Każdy model lub notacja ma swoje zalety i wady. OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa dostatecznie dokładnie zarówno aspektu użytkowników systemu jak i aspektu implementacji/konstrukcji. OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji/konstrukcji. OOAD (Booch): dobrze podchodzi do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy analizy i rozpoznania wymagań użytkowników. Istnieje wiele aspektów systemów, które nie są właściwie przykryte przez żadne z wyżej wymienionych podejść, np. włączenie prototypowania w cykl życiowy, rozproszenie i komponenty, przystosowanie notacji do preferencji projektantów, i inne. Celem UML jest przykrycie również tych aspektów.

67 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 67 Czerwiec 1999 Cele UML (1) Podstawowym celem UML jest modelowanie systemów (nie tylko oprogramowania) z użyciem pojęć obiektowych. Utworzenie języka do modelowania użytecznego zarówno dla ludzi jak i dla maszyn. UML jest notacją pośrednią, pomostem pomiędzy ludzkim rozumieniem struktury i działania programów, a kodem programów. Taka notacja pośrednia jest niezbędna do specyfikacji, konstrukcji, wizualizacji i dokumentacji wytworów związanych z systemami intensywnie wykorzystującymi oprogramowanie.

68 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 68 Czerwiec 1999 Cele UML (2) Diagramy UML ustanawiają bezpośrednie powiązanie elementów modelu pojęciowego z wykonywalnymi programami. Jednocześnie umożliwiają one objęcie zagadnień związanych ze skalą problemu, towarzyszących bardzo złożonym systemom o krytycznej misji. Zdaniem autorów UML, tworzenie takiego języka nie jest istotnie różne od zaprojektowania nowego języka programowania. Z tym pogladem można polemizować. Zasadnicza różnica polega na tym, że język do modelowania nie musi mieć (i z reguły nie ma) precyzyjnej składni i semantyki umożliwiających tworzenie wykonywalnych specyfikacji struktur danych i akcji komputera (programów).

69 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 69 Czerwiec 1999 Zakres UML Specyfikacja, konstrukcja, wizualizacja i dokumentacja wytworów związanych z systemami intensywnie wykorzystującymi oprogramowanie. UML łączy pojęcia metodyk Boocha, OMT i OOSE. Rezultatem jest pojedynczy, wspólny, szeroko stosowalny język dla użytkowników tych i innych metodyk. UML przykrywa to, co może być zrobione przy pomocy istniejących metodyk. W szczególności, autorzy UML mieli na względzie systemy współbieżne i rozproszone. UML skupia się na standardzie języka do modelowania, a nie na standardzie procesów tworzenia oprogramowania. (Różne organizacje i problemy wymagają różnych procesów, które mogą być opisane przy pomocy tego samego języka.) Wysiłek autorów jest skoncentrowany na stworzeniu wspólnego metamodelu (unifikacji semantyki) i wspólnej notacji (odbioru tej semantyki przez ludzi). Promowany jest proces, który jest napędzany przez przypadki użycia, skoncentrowany na architekturze, iteracyjny i przyrostowy.

70 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 70 Czerwiec 1999 Diagramy definiowane w UML Diagramy przypadków użycia (use case) Diagramy klas, w tym diagramy pakietów Diagramy zachowania się (behavior) Diagramy implementacyjne Diagramy stanów Diagramy aktywności Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy komponentów Diagramy wdrożeniowe (deployment) Autorzy UML wychodzą z założenia, że żadna pojedyncza perspektywa spojrzenia na projektowany system nie jest wystarczająca. Stąd wiele środków: Diagramy te zapewniają mnogość perspektyw systemu podczas analizy i rozwoju.

71 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 71 Czerwiec 1999 UML - krótka charakterystyka diagramów Diagramy przypadków użycia (use cases): z OOSE (Objectory). Diagramy klas: z OMT i Boocha. Rozszerzenia specyficzne dla procesów rozwoju (np. stereotypy i odpowiadające im ikony). Diagramy stanów (machine-state): wykresy stanów D. Harela z modyfikacjami. Diagram aktywności, podobny do diagramów przepływu prac znanych z wcześniejszych metodyk. Diagramy sekwencji znane pod innymi nazwami (interakcji, tropów zdarzeń, tropów komunikatów). Diagramy współpracy znane z Boocha (object diagram) i Fusion (object interaction diagram). Są one nową formą ustalającą podstawę dla wzorców. Diagramy implementacyjne (komponentów i wdrożeniowe) pochodzą od diagramów modułów i procesów wg Boocha, ale są bardziej zorientowane na komponenty niż na moduły i są znacznie lepiej ze sobą związane. Stereotypy są jednym z mechanizmów rozszerzalności UML. Dają możliwość zdefiniowania nowych ikon dla przystosowania UML do specyficznego procesu oraz uszczegółowienia semantyki modelu.

72 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 72 Czerwiec 1999 Nowe pojęcia wprowadzone w UML Stereotypy Odpowiedzialności (responsibilities) Mechanizmy rozszerzalności : stereotypy, etykietowane wartości (tagged values), ograniczenia Wątki i procesy Rozproszenie i współbieżność (np. dla modelowania ActiveX/DCOM i CORBA) Wzorce / współpraca Diagramy aktywności (dla reinżynierii procesów biznesowych) Jasne odróżnienie klasy, typu i wystąpienia Uszczegóławianie (refinement) dla objęcia związków pomiędzy poziomami abstrakcji Interfejsy i komponenty.

73 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 73 Czerwiec 1999 Metamodel i semantyka UML Autorzy UML sporo uwagi poświęcają semantyce wprowadzanych notacji. Jest to spowodowane zarzutami w stosunku do metodyk OMT, Boocha, i innych, podnoszącymi fakt, że sprowadzają się one do radosnego rysowania prostokacików, kółeczek i strzałeczek bez precyzyjnych reguł pragmatycznych i semantycznych. Ta wada modeli analitycznych i projektowych jest prawdopodobnie nie do uniknięcia i bezpośrednio wiąże się z własnościami ludzkiego umysłu, który posługuje się bardziej wyobrażeniem niż formalną konstrukcją. Modele odwołują się do tego wyobrażenia i przez to nie są i nie mogą być matematycznie precyzyjne. Taka precyzja jest sprzeczna z niezbędnym wysokim poziomem abstrakcji, wieloaspektowością rozpatrywanych problemów oraz z charakterem twórczych procesów zachodzących w umysłach analityków i projektantów. Niemniej, to nieprecyzyjne wyobrażenie można uszczegółowić. Opis semantyki proponowany przez autorów UML jest w gruncie rzeczy opisem składni + ograniczenia typologiczne + klasyfikacja pojęć + związki pomiędzy pojęciami. Opisowi temu daleko do formalnej, algorytmicznej precyzji wymaganej przez maszynę. I bardzo dobrze...

74 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 74 Czerwiec 1999 UML: stereotypy Stereotypy są nazwami umożliwiającymi meta-klasyfikację elementów modelu. Są wspólnymi, nazwanymi własnościami klas. Stereotyp deklaruje meta-klasę wewnątrz modelu zapisanego w UML Element modelu może mieć co najwyżej jeden stereotyp Istnieje lista stereotypów dla każdego rodzaju elementu UML Niektóre stereotypy są predefiniowane, ale użytkownicy mogą dodawać własne Stereotypy mogą mieć implikacje semantyczne (ograniczenia). stereotypes > Klient Równoważne oznaczenia Stereotypy klas i obiektów: zdarzenie, wyjątek, interfejs, metaklasa, udogodnienie Sterotypy typu obiektów: obiekt istniejący, sterujący, interfejs Stereotypy zadań: proces, wątek Stereotypy węzłów i stereotypy pakietów Rodzaje stereo- typów:

75 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 75 Czerwiec 1999 Różne notacje stereotypów «sterowanie» PióroŚwietlne lokacja: Punkt uruchom( Tryb ) ZarządcaZadań Planista «woła» PióroŚwietlne «sterowanie» PióroŚwietlne lokacja: Punkt uruchom( Tryb ) PióroŚwietlne lokacja: Punkt uruchom( Tryb )

76 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 76 Czerwiec 1999 Etykietowane wartości tagged values Dowolny element modelu zbudowanego w UML może być skojarzony z etykietowanymi wartościami. Jest to ciąg znaków o postaci: słowo kluczowe = wartość Etykietowane wartości umieszcza się w nawiasach { }. Podobnie do stereotypów, etykietowane wartości są uważane za cechę wspomagającą rozszerzalność UML. W ten sposób można na diagramach umieścić dowolną dodatkową infiormację. Zakłada się, że narzędzia CASE umożliwią odszukanie odpowiedniego elementu na podstawie słowa kluczowego i skojarzonej z nim wartości. {autor = Jan Nowak, termin zakończenia = 31 Maja 1999, status = analiza} Przykłady: {abstrakcyjna = TRUE}{abstrakcyjna} można skrócić do

77 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 77 Czerwiec 1999 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Jedenasta Górska Szkoła PTI Szczyrk99 Część 5. UML: diagramy klas

78 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 78 Czerwiec 1999 Diagramy klas Są one odmianą dość klasycznych diagramów encja-związek (entity-relationship). Podstawowymi oznaczeniami są oznaczenia klas (prostokąty), oznaczenia hierarchii dziedziczenia (strzałki z białym grotem), oznaczenia związków asocjacji (linie) oraz oznaczenia związków agregacji (białe i czarne romby). Te podstawowe oznaczenia są uzupełnione o dużą liczbę pomocniczych oznaczeń. Oznaczenia praktycznie bez większych zmian są przejęte z OMT. Wprowadzone są rozszerzenia poprawiające czytelność diagramów i przystosowujące je do konkretnej dziedziny zastosowań (np. stereotypy i odpowiadające im ikony).

79 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 79 Czerwiec 1999 Zastosowania diagramu klas Zapis modelu pojęciowego. Diagramy reprezentują pojęcia w dziedzinie zastosowań. Model pojęciowy nie musi być związany z oprogramowaniem; jest on wyłącznie sformalizowaną wizją wyobrażeń powstających w trakcie twórczych procesów myślowych związanych z danym problemem. Sformalizowana specyfikacja danych i metod. Jest ona związana z oprogramowaniem, ale dotyczy jego zewnętrznego opisu (interfejsów) bez wchodzenia w szczegóły implementacyjne (hermetyzacja). Dla wielu celów zależy nam wyłącznie na określeniu cech zewnętrznych pewnych bytów programistycznych (obiektów, metod, itd.), bez wchodzenia w szczegóły. Rozróżnienie pomiędzy specyfikacją i implementacją jest charakterystyczne dla nowo powstających języków i standardów (CORBA, Java, ODMG). Implementacja. W tym zastosowaniu diagram klas może służyć bezpośrednio jako graficzny środek pokazujący szczegóły implementacji klas, np. w C++.

80 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 80 Czerwiec 1999 Oznaczenia klas Trzy pola identycznie jak w OMT. Różny poziom szczegółowości. Stereotypy moga być użyte dla oznaczenia grupy elementów. Okno rozmiar czy_widoczne Okno rozmiar czy_widoczne wyświetl() schowaj() Okno rozmiar: Obszar czy_widoczne: Boolean wyświetl() schowaj() Okno {abstrakcyjna, autor=Kowalski status=przetestowane} +rozmiar: Obszar = (100,100) #czy_widoczne: Boolean = false +rozmiar_domyślny: Prostokąt #rozmiar_maksymalny: Prostokąt -xwskaźnik: XWindow* +wyświetl() +schowaj() +utwórz() -dołączXWindow(xwin: XWindow*) Prostokąt punkt1: Punkt punkt2: Punkt «konstruktor» Prostokąt(p1: Punkt, p2: Punkt) «zapytania» obszar(): Real aspekt(): Real... «aktualizacje» przesuń (delta: Punkt) przeskaluj(współczynnik: Real)

81 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 81 Czerwiec 1999 Oznaczenia dziedziczenia Pracownik Osoba AsystentAdiunkt Profeso r DocentAsystentAdiunkt Profeso r Docent Pracownik Osoba Oznaczenia dziedziczenia zachowują konwencję OMT (z minimalną zmianą syntaktyczną). Strzałka (z białym trójkątnym grotem) prowadzi od pod-klasy do jej bezpośredniej nadklasy. Zakłada się, że obiekt pod-klasy automatycznie dziedziczy wszystkie atrybuty, metody, asocjacje i agregacje z wszystkich jej nadklas.

82 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 82 Czerwiec 1999 Asocjacje Firma Osoba Pracuje_dla 1..* Oznaczenia klas są połączone liniami oznaczającymi asocjacje, czyli powiązania pomiędzy obiektami tych klas, np. asocjację Pracuje_dla pomiędzy obiektami klasy Osoba i obiektami klasy Firma. Czarny trójkącik określa kierunek wyznaczony przez nazwę powiązania. W danym przypadku określa on, że osoba pracuje dla firmy, a nie firma pracuje dla osoby. Nazwy asocjacji, takie jak Pracuje_dla, wyznaczają znaczenie tej asocjacji w modelu pojęciowym. Asocjacje mogą być wyposażone w oznaczenia liczności. Jak zwykle, liczność oznacza, ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy; zwykle określa się to poprzez parę liczb (znaków), oznaczającą minimalną i maksymalną liczbę takich obiektów. Asocjacje mogą być także wyposażone w dodatkowe nazwy ról (przy odpowiednich końcach), np. pracodawca i pracownik.

83 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 83 Czerwiec 1999 Asocjacje skierowane Zamówienie dataZłożenia czyZapłacone sumaDoZapłaty realizuj() zamknij() Klient nazwisko adres wiarygodność() *1 PozycjaZamówienia ilość cena czyZrealizowana Produkt *1 1 * Na diagramach UML można zaznaczać kierunek nawigacji wzdłuż danej asocjacji. W takim przypadku asocjacja jest rysowana w postaci strzałki; nawigacja jest możliwa zgodnie z jej kierunkiem, ale nie odwrotnie.

84 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 84 Czerwiec 1999 Notacja stosowana w diagramach klas - przykład Firma Osoba Pracuje-dla * 1..* pracodawcapracownik Stanowisko zarobek szef podwładny * 0..1 Kieruje Konto Firma Osoba {or}

85 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 85 Czerwiec 1999 Przykładowy diagram klas w UML poprzedza następuje_po zawiera jest_składową ma_asystenta asystuje_w zapisany_na prowadzony_dla prowadzony_przez prowadzi PracownikStudent Osoba Kurs Student_asystentProfesor Wykład 1..* 0..* 1..* 0..* 0..1

86 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 86 Czerwiec 1999 Ograniczenia - przykład constraints Ograniczenie lub adnotacja Osoba Komitet Jest_członkiem ** Jest_przewodniczącym 1* {podzbiór} Osoba Firma Pracuje_dla 0..1 * pracownikpracodawca podwładny szef 0..1 * {Osoba.pracodawca = Osoba.szef.pracodawca}

87 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 87 Czerwiec 1999 Asocjacje kwalifikowane produkt Bank Osoba * 0..1 nrKonta Zamówienie WierszZamówienia ilość: Liczba 0..1 pozycja zamów Kwalifikator jest atrybutem asocjacji (lub zestawem atrybutów asocjacji), którego wartości służą do podziału zbioru obiektów definiowanych przez klasę znajdującą się na jednym z końców tej asocjacji.

88 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 88 Czerwiec 1999 Wieloaspektowe generalizacje/specjalizacje Pojazd {overlapping} Pojazd wiatrowy Pojazd silnikowy Pojazd lądowy Pojazd wodny napęd teren {overlapping} Ciężarówka Żaglówka Drzewo DąbBrzozaSosna {disjoint, incomplete} species: GatunkiDrzew «powertype» GatunkiDrzew stereotyp

89 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 89 Czerwiec 1999 Agregacje Agregacja jest szczególnym przypadkiem asocjacji wyrażającym zależność część-całość. Np. silnik jest częścią samochodu. Nie istnieje jednak powszechnie akceptowana definicja agregacji. P. Coad podaje przykład agregacji jako związek pomiędzy organizacją i jej pracownikami; dla odmiany J. Rumbaugh twierdzi, że firma nie jest agregacją jej pracowników. W wielu przypadkach związki agregacji są oczywiste. Jednakże wątpliwości powstają nawet w przypadku samochodu i silnika. Np. silnik może być towarem w sklepie nie związanym z żadnym samochodem. Ponadto, czy chodzi o konkretny samochód i silnik, czy też o typ samochodu i typ silnika? Mętlik dookoła pojęcia agregacji wynika również z tego, że jest ona nadużywana w celu usprawiedliwienia pewnych ograniczeń modelu obiektowego. Np. popularne wyjaśnienie powodów braku (wielo-) dziedziczenia podaje, że można je obejść przez agregację, co jest nonsensem z punktu widzenia celów modelowania pojęciowego, tak samo jak zdanie: asocjacje są zbędne, bo można je obejść przez atrybuty. Wszysto można obejść.... w assemblerze!

90 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 90 Czerwiec 1999 Kompozycja jako mocna forma agregacji Pojęcie agregacji jest rozumiane na dwa sposoby: Jako związek część-całość pomiędzy obiektami świata rzeczywistego; np. silnik jest częścią samochodu. Jako pomocniczy środek modelowania dowolnej innej sytuacji, kiedy trzeba wydzielić pod-obiekty w pewnych obiektach. np. informacja o ubezpieczeniach wewnątrz obiektów pracowników. W UML te dwie sytuacje zostały rozdzielone. Pierwszą formę nazwano kompozycją. Kompozycja oznacza, że cykl życiowy składowej zawiera się w cyklu życiowym całości, oraz że składowa nie może być współdzielona.

91 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 91 Czerwiec 1999 Agregacja i kompozycja Wielobok Punkt Styl kolor czyWypełniony Okrąg promień {ordered} 3..* ** 11 1 Kompozycja Agregacja

92 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 92 Czerwiec 1999 Różna postać zapisu kompozycji Okno pasekPrzesuwny[2]: Suwak tytuł: Nagłówek ciało: Panel Okno Nagłówek PanelSuwak tytułpasekPrzesuwnyciało Okno pasekPrzesuwny: Suwak tytuł: Nagłówek ciało: Panel Okno tytuł pasekPrzesuwny ciało Suwak Nagłówek Panel

93 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 93 Czerwiec 1999 Konstruowanie diagramu klas Konstruowanie diagramu klas wymaga następujących kroków: Identyfikacja obiektów i klas Przygotowanie słownika danych Zidentyfikowanie związków między obiektami Zidentyfikowanie atrybutów obiektów Zorganizowanie i uproszczenie klas obiektów z użyciem dziedziczenia Analiza ścieżek dostępu dla prawdopodobnych zapytań Iteracje i precyzowanie modelu Grupowanie klas w moduły

94 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 94 Czerwiec 1999 Budowa modelu obiektowego: ćwiczenie Mają być rejestrowane są informacje o wszystkich lotach konkretnych, odbytych i planowanych (data, numer lotu, samolot, pilot, itd ). Powinna istnieć możliwość zmiany danych o locie. Mają być rejestrowane dane o dostępnej flocie powietrznej (typ samolotu, nr_seryjny, rok produkcji, przeleciane godziny), z możliwością określenia, czy samolot spełnia warunki techniczne niezbędne do eksploatacji. Mają być rejestrowane informacje o pilotach, ich przypisaniu do poszczególnych lotów, miejsce ich zatrudnienia. Mają być rejestrowane informacje o liniach lotniczych, zatrudnianych przez nich pilotów i posiadanych przez nich maszynach Mają być rejestrowane informacje o przylotach i odlotach, portach i miastach Mają być rejestrowane informacje o pasażerach, rezerwacjach i wykupionych biletach an poszczególne loty Założenia systemu transportu lotniczego:

95 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 95 Czerwiec 1999 Przykładowe rozwiązanie: pierwsza przymiarka Miasto nazwa Linia lotnicza nazwa Port lotniczy nazwa Lot data nr lotu zmień_lot Samolot model nr seryjny rok_produkcji godziny_przeleciane czy_posiada_atest Pasażer rezerwacja bilet Fotel lokalizacja odlot przylot posiada przypisany obsługuje Sprzęt latający... Osoba nazwisko zatrudniony Pilot kwalifikacje prowadzi

96 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 96 Czerwiec 1999 Klasy parametryzowane Niektóre języki obiektowe, wśród nich C++, wprowadzają użyteczne pojęcie klasy parametryzowanej (zwane też szablonem, template). UML wprowadza specjalne oznaczenie dla klas parametryzowanych, które może być użyte w diagramie klas. class Zbiór { void wstaw ( T nowyElement ); void usuń ( T pewienElement ); } Zbiór wstaw( T ) usuń( T ) Parametr (typ)Klasa parametryzowana T

97 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 97 Czerwiec 1999 Diagramy pakietów Pakiety są zestawami elementów modelu wraz z zachodzącymi pomiędzy nimi zależnościami. Diagramy pakietów odwzorowują przekazywanie (import) informacji z pakietu do pakietu. Diagramy pakietów mogą być istotne dla dużych projektów, składających się z wielu modułów funkcjonalnych ze złożonymi zależnościami pomiędzy modułami. Pakiety mogą być zagnieżdżane. Zależności pomiędzy pakietami są przedstawiane w postaci strzałki z przerywaną linią. Strzałki zaznaczają przepływ (import) informacji pomiędzy pakietami. Pakiety są traktowane jako obiekty należące do swoich klas, które mogą podlegać związkom dziedziczenia.

98 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 98 Czerwiec 1999 Przykład diagramu pakietów Pakiety są rysowane jako duże prostokąty z małym prostokątem u góry (etykietą). Jeżeli zawartość pakietu nie jest pokazana, wówczas nazwa pakietu jest wpisana do większego prostokąta. Jeżeli jest pokazana, to nazwę pakietu wpisuje się do etykiety. Edytor Elementy diagramów graficznych Elementy dziedziny zastosowań Sterownik Rdzeń grafiki Rdzeń grafiki Motif Rdzeń grafiki Windows System okienkowy MotifMS Windows

99 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 99 Czerwiec 1999 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Jedenasta Górska Szkoła PTI Szczyrk99 Część 6. UML: przypadki użycia, modele dynamiczne, diagramy implementacyjne

100 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 100 Czerwiec 1999 Przypadki użycia Podstawowym problemem jest określenie wymagań na projektowany system. Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy. Celem metody opartej na przypadkach użycia jest: zrozumienie użycia systemu bedącego przedmiotem procesu projektowania zwiekszenie stopnia świadomości analityków i projektantów co do celów tego systemu umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami weryfikacja poprawności i kompletności projektu odzyskanie wszystkich strukturalnych i funkcjonalnych własności systemu ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu dostarczenie podstawy do sporządzenia planu testów systemu use case

101 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 101 Czerwiec 1999 Przykład modelu przypadków użycia klient banku wpłata pieniedzy wypłata pieniedzy kasjer sprawdź bilans weź pożyczkę zarząd banku «uses» Model przypadków użycia można rozbudowywać poprzez dodanie nowych aktorów, nowych przypadków użycia oraz nowych powiązań pomiędzy przypadkami użycia.

102 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 102 Czerwiec 1999 Diagram przypadków użycia Ustalenie limitów Analiza ryzyka Sprawy cenowe Przekroczenie limitów Ocena zysków Aktualizacja rozliczeń Wyliczenie ocen Dyrektor handlowy Handlowiec Sprzedawca System rozliczeniowy «extends» «uses» Model przypadków użycia dostarcza bardzo abstrakcyjnego poglądu na system z pozycji aktorów, którzy go używają. Nie włącza szczegółów, co pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie.

103 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 103 Czerwiec 1999 Opis przypadku użycia Opis przypadku użycia może być dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty: Jak i kiedy przypadek użycia zaczyna się i kończy? Opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane. Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak i kiedy zapamiętuje dane w systemie? Wyjątki przy przepływie zdarzeń. Jak i kiedy używane są pojęcia dziedziny problemowej?

104 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 104 Czerwiec 1999 Powiązania w modelu przypadków użycia Uczestnik projektu Analityk Programista Generalizacja pomiędzy aktorami «extends» «uses» Modeluje sytuację kiedy rozszerzający przypadek użycia definiuje wspólne lub dobrze wyodrębnione akcje. Rozszerzony przypadek użycia wykonuje wszystkie zdefiniowane w nim akcje plus niekiedy dodatkowo akcje określane przez przypadek rozszerząjący. Jest on zwykle niekompletny. Modeluje sytuację kiedy przypadek (przypadki) użycia wykorzystuje (wykorzystują) wspólny przypadek użycia (np. blok ponownego użycia) na zasadzie podobnej do wywołania procedury. Zmiany: «uses»«import»«extends»«extend» Dziedziczenie w ramach przypadków użycia, liczność związków aktor - przypadek użycia

105 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 105 Czerwiec 1999 Dokumentacja przypadków użycia Typowa dokumentacja przypadków użycia powinna zawierać następujące elementy: Krótki opis przypadku użycia. Przepływ zdarzeń opisany nieformalnie. Związki pomiędzy przypadkami użycia. Uczestniczące obiekty. Specjalne wymagania (np. czas odpowiedzi, wydajność). Obrazy interfejsu użytkownika. Ogólny pogląd na przypadki użycia (powiązania w postaci diagramów). Diagramy interakcji dla każdego aktora.

106 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 106 Czerwiec 1999 Przypadki użycia - analiza aktorów Przy wyszukiwaniu aktorów ze sformułowanych wymagań istotne są odpowiedzi na następujące pytania: Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu? Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje? Należy te funkcje rozbić na funkcje odnoszące się do dziedziny przedmiotowej (np. osoba rejestrująca korespondencję) i do wspomagania systemu (np. administrator systemu). Z jakiego sprzętu zewnętrznego (komputerów, czujników, sieci, itp.) musi korzystać system aby realizować swoje funkcje?

107 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 107 Czerwiec 1999 Modele i diagramy dynamiczne Są to modele i diagramy, które uwzględniają: czas, zdarzenia, następstwo czynności, synchronizację czynności, transakcje, stany procesów, spontaniczne akcje, interakcję z otoczeniem systemu, dialogi. Zwykle są notacjami opartymi na diagramach przepływu sterowania, diagramach automatów skończonych, sieciach Petriego, sieciach PERT, Modele dynamiczne są zwykle powiązane z innymi modelami wspólnymi oznaczeniami (obiektów, procesów). Modele dynamiczne są często istotnym uzupełnieniem diagramów klas, ale w wielu przypadkach ich znaczenie jest pomocnicze, drugorzedne. Warto je sporzadzać tylko wtedy, jeżeli odwzorowują one istotną informację. Często modele dynamiczne są trudne do sporządzenia, ze względu na nieprzewidywalność, wielowariantowość scenariuszy działania systemu.

108 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 108 Czerwiec 1999 Diagramy sekwencji Idea bardzo podobna do diagramów tropów zdarzeń lub diagramów tropów komunikatów, ale rozudowana o możliwość podawania ograniczeń czasowych, a nawet (co jest kontrowersyjne) skali czasowej. sterowaniedzwoniącyodbierający podniesienie słuchawki ton w słuchawce wybór cyfry łączenie ton dzwonka uruchomienie dzwonka podniesienie słuchawki koniec tonu koniec dzwonienia... a b c d d {b - a < 1 sec.} {c - b < 10 sec.} Rozmowa jest łączona poprzez sieć {d - d < 5 sec.} W tym punkcie rozmówcy mogą rozmawiać

109 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 109 Czerwiec 1999 Różne oznaczenia w diagramach sekwencji ob1:C1 ob4:C4 ob3:C3 op() [x>0] foo(x) [x<0] bar(x) doit(w) more() ob2:C2 Diagram sekwencji z warunkami, rekurencją, tworzeniem i kasowaniem Autorzy UML strają się doprowadzić te diagramy do precyzji języków programowania. Wydaje się, że jest to pseudo- koncepcja. Diagramy te, ze swojej natury, są raczej słabym środkiem specyfikacji programów. Wprowadzanie wielu opcji na tych diagramach mija się z ich celem.

110 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 110 Czerwiec 1999 Diagramy współpracy (kolaboracji) :OknoWprowadzaniaZamówienia :Zamówienie LiniaMacallana: WierszZamówieniaAkcjeMacallana: PozycjaAkcji :PozycjaDostarczana:PozycjaPonownieZamówiona Obiekt 1: przygotuj() Komunikat 2: *[dla wszystkich wierszy zamówienia] przygotuj() 3: maAkcje := sprawdź() 4:[maAkcje]:usuń() 5:czyNoweZamów := potrzebaNowegoZamów() 7: [maAkcje]: new 6:[czyNoweZamów]: new Numer kolejny komunikatu Istotą diagramów współpracy jest przedstawienie przepływu komunikatów pomiędzy obiektami. Współpraca pomiędzy obiektami włącza dwa aspekty: strukturę uczestniczących obiektów oraz sekwencję komunikatów wymienianych pomiędzy obiektami. Czas nie jest odwzorowany, natomiast odwzorowane są powiązania pomiędzy obiektami (część powiązań z diagramu klas).

111 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 111 Czerwiec 1999 Diagram stanów Diagram stanów nawiązuje do automatu skończonego. Opisuje on stany pewnego procesu, które są istotne z punktu widzenia modelu pojęciowego tego procesu, oraz przejścia pomiędzy stanami, wymuszane poprzez pewne zdarzenia. W UML ta pierwotna idea uległa istotnym modyfikacjom i rozszerzeniom. Stany są wzbogacone o akcje wykonywane wewnątrz stanów, zaś zdarzenia mogą być także pewnymi warunkami, w szczególności warunkiem który jest zawsze prawdziwy. W istocie, w diagramach stanów nie chodzi o stany. Nazwa diagram stanów (wprowadzona przez D. Harela jako statecharts) nie oddaje istoty. D iagramy stanów nie są tymi diagramami stanów, o których jest mowa w teorii automatów. Są to dość klasycznie diagramy przepływu sterowania (flowcharts), z szeregiem drugorzędnych opcji syntaktycznych i semantycznych. Nazwa diagramy stanów jest nieodpowiednia i myląca dla środowiska akademickiego, gdyż powoduje fałszywe asocjacje.

112 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 112 Czerwiec 1999 Przykład diagramu stanów Spoczynek Wybieranie numeru Łączenie Rozmowa podniesiona słuchawka /włącz ton 15 sec. wybierz cyfrę(n) [niekompletny] wybierz cyfrę(n) [numer poprawny] /połącz wybierz cyfrę(n) [zły numer] Zajęty Połączony rozmówca odpowiada /umożliwienie rozmowy Rozmowa zawieszona rozmówca odpowiada rozmówca zawiesza położona słuchawka /rozłącz Aktywny Nr telefonu Koniec czasu do/ odegraj komunikat Ton w słuchawce do/ odegraj ton Zły numer do/ odegraj komunikat Zajęty do/ odegraj ton zajętości Dzwonek u odbiorcy do/ odegraj ton dzwonka Stany (akcje) mogą być zagnieżdżane.

113 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 113 Czerwiec 1999 Diagram dynamiczny - specyfikacja wymagań Pracownik firmy zgłasza wniosek o zakup do kierownika zaopatrzenia. Kierownik uruchamia procedurę zakupu i wyznacza pracownika odpowiedzialnego. Pracownik odpowiedzialny przygotowuje informację o zakupie i swoje sugestie. Kierownik przegląda tę informację i zatwierdza wniosek lub nie. Jeżeli zatwierdza, to dalsze postępowanie zależy od szacunkowego kosztu zakupu. Jeżeli koszt jest poniżej 1000 zł, to wniosek musi zaakceptować dział finansowy. Dział finansowy może wniosek zaakceptować, odrzucić lub mieć wątpliwości i skierować do prezesa. Jeżeli zakup jest powyżej 1000 zł, to akceptacji musi dokonać prezes. Prezes może wniosek zaakceptować lub odrzucić. Po akceptacji prezesa wniosek musi jeszcze przejść procedurę w dziale finansowym, j.w. Jeżeli wniosek jest odrzucony w dowolnej fazie, to pracownik odpowiedzialny musi o tym pisemnie poinformować wnioskodawcę Jeżeli wniosek jest zakceptowany, to pracownik odpowiedzialny musi równocześnie pisemnie poinformować wnioskodawcę i uruchomić procedurę zakupu.

114 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 114 Czerwiec 1999 Przykład diagramu stanów: zakupy dla firmy Akceptacja przez prezesa [Wpłynął wniosek] Akceptacja przez kierownika zaopatrzenia Start wystąpienia procesu Przygotowanie informacji o zakupie (prac. odpow.) Przygotowanie informacji o odrzuceniu (prac. odpow.) Akceptacja przez dział finansowy Procedura zakupu AND [zaakceptowany][odrzucony] [wątpliwości] [zaakceptowany] [odrzucony] Ustalenie pracownika odpowiedzialnego Decyzja kierownika zaopatrzenia [zaakceptowany] Przygotowanie informacji o akceptacji (prac. odpow.) [koszt >= 1000zł] [koszt < 1000zł]

115 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 115 Czerwiec 1999 Diagram aktywności Osoba::Przygotowanie Napoju Znajdź Napój Nasyp kawy do filtru Dolej wody do zbiornika Włóż filtr do maszynki Włącz maszynkęGotowanie kawy Nalej kawę Wypij Zrób herbatę Weź sobie wody [nie ma kawy] [kawa znaleziona] [nie ma herbaty] [herbata znaleziona] MaszynkaDoKawy.włączona światełko zgasło Weź filiżankę 1..4

116 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 116 Czerwiec 1999 Diagramy implementacyjne Diagramy implementacyjne pokazują niektóre aspekty implementacji SI, włączając w to strukturę kodu źródłowego oraz strukturę kodu czasu wykonania (run-time). UML wprowadza dwa typy takich diagramów: Diagramy komponentów pokazujące strukturę samego kodu, Diagramy wdrożeniowe pokazujące strukturę systemu czasu wykonania.

117 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 117 Czerwiec 1999 Diagram implementacyjny: komponentów Program do harmonogramów Program planujący Interfejs graficzny rezerwacje aktualizacje Diagramy komponentów pokazują zależności pomiędzy komponentami oprogramowania, włączając komponenty kodu źródłowego, kodu binarnego oraz kodu wykonywalnego. Komponenty mogą istnieć w różnym czasie: niektóre z nich w czasie kompilacji, niektóre w czasie konsolidacji, zaś niektóre w czasie wykonania. Diagram komponentów jest przedstawiany jako graf, gdzie węzłami są komponenty, zaś strzałki (z przerywaną linią) prowadzą do klienta pewnej informacji do jej dostawcy.

118 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 118 Czerwiec 1999 Diagram implementacyjny: wdrożeniowy «baza danych» spotkaniaBD AdminServer:KomputerHost Program do harmonogramów rezerwacje KomputerJacka:PC Program planujący Diagram wdrożeniowy pokazują konfigurację elementów czasu wykonania: komponentów sprzętowych, komponentów oprogramowania, procesów, związanych z nimi obiektów. Diagram wdrożeniowy jest grafem, gdzie węzłami są elementy czasu wykonania połączone przez linie odwzorowujące ich połączenia komunikacyjne.

119 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 119 Czerwiec 1999 Diagram wdrożeniowy Specjalne symbole są zwykle znacznie lepsze. W UML są one w pełni legalne. Serwer diabetyków Serwer oddziału terapii Szpitalna sieć Ethernet Internet Klient Web Sieć Ethernet oddziału PC z Windows

120 K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 120 Czerwiec 1999 UML: Podsumowanie UML powstał w rezultacie połączonych wysiłków trzech znanych metodologów: G. Boocha, I. Jacobsona i J. Rumbaugha. UML stał się bardzo popularny, przez wiele lat będzie prawdopodobnie dominował w obszarze analizy i projektowania. UML nie ma ambicji być metodyką projektowania. Jest zestawem pojęć, diagramów i oznaczeń, który może być użyty w dowolnej metodyce. Notacja opiera się o podstawowe pojęcia obiektowości. UML wprowadza wiele pojęć, diagramów i oznaczeń, które w założeniu mają przykryć większość istotnych aspektów modelowanych systemów. Kwestia semantyki tej notacji pozostaje mglista, co jest nieuchronnym skutkiem sprzeczności pomiędzy naturą procesów twórczych i formalizacją. Pragmatyka użycia tej notacji (tj. dopasowanie jej do konkretnej sytuacji) pozostaje wielkim problemem, którego przyczyny są podobne do w/w. UML jest składową standardu OMG (CORBA). Nie wszyscy są zachwyceni UML. Niektórzy specjaliści uważają go za twór niestabilny, zbyt ciężki, przereklamowany, źle zdefiniowany. UML ma konkurentów w postaci metodyki i notacji OPEN, design by contracts, i innych.


Pobierz ppt "K.Subieta. Wprowadzenie do obiektowych metodyk projektowania i notacji UML, Folia 1 Czerwiec 1999 Wprowadzenie do obiektowych metodyk projektowania i notacji."

Podobne prezentacje


Reklamy Google