Wprowadzenie do Analizy i Projektowania Obiektowego

Prezentacja na temat: "Wprowadzenie do Analizy i Projektowania Obiektowego"— Zapis prezentacji:

1 Wprowadzenie do Analizy i Projektowania Obiektowego
Ministerstwo Finansów Centralny Ośrodek Doskonalenia Kadr, Dębe 17 listopada 2000 Wprowadzenie do Analizy i Projektowania Obiektowego Wykładowca: dr hab. inż. Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa profesor, kierownik Katedry Systemów Informacyjnych Instytut Podstaw Informatyki PAN, Warszawa docent

2 Plan szkolenia metodyki tworzenia oprogramowania Podsumowanie
Wykład 1 ( 9: :45): Przedmiot inżynierii oprogramowania Wykład 2 ( 9: :30): Cykl życiowy oprogramowania, metodyki tworzenia oprogramowania Wykład 3 (10: :15): Wprowadzenie do obiektowości, cz.1 Przerwa Wykład 4 (11: :30): Wprowadzenie do obiektowości, cz.2 Wykład 5 (12: :15): Diagramy klas Wykład 6 (13: :00): Diagramy przypadków użycia Podsumowanie

3 Wykład 1: Przedmiot inżynierii oprogramowania
Zagadnienia inżynierii oprogramowania Kryzys oprogramowania Złożoność projektu oprogramowania Modelowanie pojęciowe Niezgodność modelu pojęciowego i realizacyjnego

4 Przedmiot inżynierii oprogramowania
Inżynieria oprogramowania jest wiedzą dotycząca wszystkich faz cyklu życia oprogramowania oraz wszystkich aspektów tworzenia i utrzymania oprogramowania. Traktuje oprogramowanie jako produkt, który ma spełniać potrzeby biznesowe, organizacyjne lub społeczne. Dobre oprogramowanie powinno być: zgodne z wymaganiami użytkownika, jakościowe, niezawodne, efektywne, łatwe w pielęgnacji, ergonomiczne. Produkcja oprogramowania jest procesem składającym się z wielu faz i obejmuje wiele aspektów, takich jak dokumentowanie i zarządzanie. Kodowanie (pisanie programów) jest tylko jedną z tych faz, często nie najważniejszą.

5 Teorie w inżynierii oprogramowania
Inżynieria oprogramowania jest wiedzą empiryczną, syntezą ludzkiego doświadczenia z tysięcy ośrodków zajmujących się budową oprogramowania. Teorie, metody matematyczne w inżynierii oprogramowania skompromitowały się. Były one tworzone przez osoby niekompetentne w zakresie rzeczywistych problemów, manifestujących bardziej pęd do naukowych karier niż zainteresowanie tymi problemami. Wieloletni nacisk środowisk uniwersyteckich na tego rodzaju wiedzę i badania spowodował liczne patologie, m.in. dramatyczny niedorozwój polskiej kadry akademickiej w tej dziedzinie, zaniedbanie właściwej dydaktyki na większości polskich uczelni, itd. Odpowiedzialność za to bezpośrednio spada na prominentnych przedstawicieli uniwersyteckiej informatyki. Konieczne jest ostrzeżenie polskiego środowiska informatycznego przed tego rodzaju pseudo-wiedzą i pseudo-specjalistami. "Nie!" dla scholastyki, wykorzystywania matematyki i haseł inżynierii oprogramowania jako wehikułów do karier!

6 Zagadnienia inżynierii oprogramowania (1)
Analiza strategicznych uwarunkowań projektu oraz planowanego systemu w kontekście realizowanych funkcji biznesowych. Inżynieria wymagań użytkownika i wymagań na tworzony system. Zarządzanie przedsięwzięciami związanymi z projektowaniem i wdrożeniem oprogramowania, zarządzanie ryzykiem. Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć informatycznych, Metody estymacyjne i pomiarowe dotyczące procesów projektowych i produktów programistycznych. Metodyki analizy, projektowania i konstrukcji systemów. Informatyczne narzędzia wspomagania inżynierii oprogramowania (narzędzia CASE).

7 Zagadnienia inżynierii oprogramowania (2)
Techniki testowania, weryfikacji i walidacji oprogramowania, zarządzanie jakością oprogramowania. Przygotowania dokumentacji technicznej i użytkowej. Zarządzanie konfiguracjami i wersjami oprogramowania, repozytoria dokumentacji i oprogramowania. Integracja, instalacja i wdrażanie oprogramowania. Szkolenie kadr z zakresu inżynierii oprogramowania, metody dydaktyczne, szkolenie użytkowników oprogramowania. Pielęgnacja i serwis oprogramowania (usuwanie błędów, modyfikacje i rozszerzenia). Organizacja zespołów projektowych, techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

8 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.

9 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.

10 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. Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania.

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

12 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.

13 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 zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu.

14 Perspektywy w modelowaniu pojęciowym
odwzorowanie odwzorowanie ... 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.

15 Niezgodność modelu pojęciowego i realizacyjnego (przykład)
Pojęciowy schemat obiektowy: FZ PZ Firma Zatrudnienie Pracownik Osoba 1 0..* 0..* 1 Nazwa Wyp ł ata * Zawód * Nazwisko Miejsce * Ocena * Imi ę * Adres * Schemat realizacyjny (relacyjny): 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)

16 Skutki niezgodności pojęć i ich realizacji
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%). Programy te są często wolniejsze, trudniejsze do pielęgnacji. Mini-przykład: Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu 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 została „zgubiona” w relacyjnej strukturze danych.

17 Wykład 2: Cykl życiowy oprogramowania, metodyki tworzenia oprogramowania
Modele cyklu życia oprogramowania Co to jest metodyka (metodologia)? Metodyki obiektowe Klasyczna i obiektowa struktura aplikacji

18 Elementy cyklu życiowego oprogramowania
Faza strategiczna: cele, planowanie i definicja projektu. Określenie wymagań użytkownika. Analiza: dziedziny biznesu, wymagań na oprogramowanie. Projektowanie: pojęciowe, logiczne, szczegółowe. Implementacja/konstrukcja. Testowanie. Integracja oprogramowania. Instalacja. Przygotowanie użytkowników, akceptacja, szkolenie. Działanie, włączając wspomaganie tworzenia aplikacji, serwis i pielęgnację.

19 Zagadnienia wspólne dla wszystkich faz
Dokumentacja (analizy, projektu, kodu, techniczna, użytkownika, itd.). Metody i narzędzia wspomagające analizę, projektowanie, konstrukcję i dokumentowanie oprogramowania. Zarządzanie konfiguracjami i wersjami oprogramowania. Zarządzanie przedsięwzięciem projektowym, w tym zarządzanie ryzykiem. Weryfikacja, walidacja i zarządzanie jakością oprogramowania. Metryki (metody pomiarowe) i metody estymacyjne dotyczące procesów, produktów i zasobów.

20 Uwarunkowania wpływające na cykl życia oprogramowania
Jakość, szczegółowość i stabilność wymagań użytkownika oraz wymagań na oprogramowanie. Dekompozycja projektu na podprojekty (moduły oprogramowania). Zależności czasowe pomiędzy podprojektami lub modułami. Zależność projektu od kontekstu, np. nad-projektu lub innych projektów realizowanych równolegle przez inne zespoły. Zmiany technologii informatycznych lub modeli biznesowych. Zmiany wykonawców projektu lub zespołów projektowych

21 Modele cyklu życia oprogramowania
Model kaskadowy (wodospadowy) Model spiralny Model kaskadowy z prototypowaniem ... Tego rodzaju modeli (oraz ich mutacji) jest bardzo dużo. Podręcznikowe modele cyklu życia oprogramowania są najczęściej idealizacją rzeczywistości. Dla każdego projektu należy wypracować własny cykl życiowy. Określenie wymagań Projektowanie Implementacja Testowanie Pielęgnacja Faza strategiczna Analiza Instalacja Dokumentowanie

22 Model kaskadowy (wodospadowy)
Określenie wymagań Analiza Projektowanie Implementacja Testowanie W wielu przypadkach niezbędny. Wygodny do planowania i rozliczania. W wielu przypadkach zbyt idealistyczny. Wdrożenie Pielęgnacja

23 Model spiralny W wielu przypadkach trudny do zaakceptowania
Analiza Formułowanie wymagań Projektowanie Jeżeli ocena nie jest w pełni pozytywna, rozpoczyna się kolejny cykl. Stop Start Wdrożenie. Konstrukcja Testowanie W wielu przypadkach trudny do zaakceptowania ze względów planistyczno-finansowych

24 Prototypowanie Sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie ogólnych (zgrubnych) wymagań jest stosunkowo łatwe. ogólne określenie wymagań budowa prototypu weryfikacja prototypu przez klienta pełne określenie wymagań realizacja pełnego systemu zgodnie z modelem kaskadowym Fazy wykrycie nieporozumień pomiędzy klientem a twórcami systemu wykrycie brakujących funkcji wykrycie trudnych usług wykrycie braków w specyfikacji wymagań Cele możliwość demonstracji pracującej wersji systemu możliwość szkoleń zanim zbudowany zostanie pełny system Zalety

25 Fazy cyklu życia oprogramowania, zadania i role uczestników projektu
..... Projekty Pod- projekty Pod-projekt 1 Pod-projekt 2 ..... ..... Faza A Faza B Faza C ..... ..... Fazy Zadanie 11 Zadanie 12 ..... Zadanie 21 ..... Zadanie n1 ..... Zadania Zespół 1 Zespół 2 Zespół 3 ..... Zespoły Kierownik Analityk Programista Analityk Programista ..... Role Kierownik Nowak Kowalski Maliniak Dudek ..... Osoby

26 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 dokumentowania 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. 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. Metodyka ustala:

27 Notacje w analizie i projektowaniu
Język naturalny Notacje graficzne Specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny Rodzaje notacji 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

28 Główne aspekty notacji
Składnia określa, jak budować poprawne wyrażenia (diagramy) z przyjętych oznaczeń (symboli). Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami. Pragmatyka określa, jak i do czego należy używać przyjętych oznaczeń. Dowolna notacja (czyli język) posiada trzy ważne aspekty. Popularne notacje (przypisane do metodyk i narzędzi CASE) definiują składnię . W większości przypadków, semantyka jest jasna, ale dla niektórych oznaczeń można mieć wątpliwości. Semantyka notacji stosowanych w metodologiach z reguły nie posiada (i nie może posiadać) algorytmicznej precyzji, ponieważ odwołuje się do ludzkiego wyobrażenia (a nie do listy rozkazów komputera). Najtrudniejszą stroną wszystkich metodyk i ich notacji jest pragmatyka. Określa ona, jak w konkretnej sytuacji zastosować przyjętą notację oraz jak ją zinterpretować w dalszych fazach projektowania i konstrukcji oprogramowania. Pragmatykę można objaśniać wyłącznie na przykładach. Nauczanie pragmatyki jest trudne, oparte na próbach i błędach, zależne od stylu i wierzeń nauczającego.

29 Metodyki obiektowe i strukturalne
Metodyki strukturalne - metody tradycyjne. Łączą statyczny opis danych ze statycznym opisem procesów. Metodyki obiektowe - rozwijane od lat 80-tych, oparte na wyróżnianiu klas obiektów łącznie z operacjami. Analiza strukturalna (structured analysis) rozpoczyna się od budowy dwóch modeli systemu: modelu danych (zwykle model encja-związek, ERD) oraz modelu funkcji (zwykle model przepływu danych, DFD). Te dwa modele są integrowane oraz doprowadzane do wzajemnej spójności. Wadą metodyk strukturalnych jest słabe uwzględnienie modelowania pojęciowego, co owocuje większą dowolnością (przypadkowością) wyborów przy przejściu od projektu do konstrukcji oprogramowania. Ostatnio metodyki obiektowe są bardziej popularne. Wiele obecnych narzędzi CASE jest oparte na metodykach obiektowych.

30 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.

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

32 Różnice pomiędzy metodykami
Podejścia proponowane przez różnych autorów różnią się częściowo, nie są jednak ze sobą sprzeczne. Poszczególne metodyki zawierają 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ś narzędzie CASE “jest oparte” na konkretnej metodyce jest często wyłącznie hasłem reklamowym.

33 Relacyjna i obiektowa struktura aplikacji
Zmiana metodyki pociąga za sobą zmianę struktury aplikacji. Klasyczna struktura aplikacji Obiektowa struktura aplikacji Pasywne dane (relacje) Powiązane obiekty Schemat bazy danych ... ... ... ... ... ... Schemat bazy danych ... ... ... Klasy i typy ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... Biblioteki procedur i funkcji Moduły aplikacyjne Typy Biblioteki procedur i funkcji Moduły aplikacyjne Słowniki, katalogi Słowniki, katalogi Procedury bazy danych, perspektywy, reguły Procedury bazy danych, perspektywy, reguły

34 Wpływ środków implementacyjnych na metodykę
Strukturę aplikacji wymuszają zastosowane narzędzia, np. relacyjny SZBD. Zmiany w konstrukcji oprogramowania mogą więc nie być zasadnicze. Obiektowość jest istotna na poziomie dokumentowania wyników faz analizy i projektowania. Tradycyjne narzędzia implementacyjne wymuszają konieczność odwzorowania tych wyników na struktury danych i funkcje zgodne z zastosowanym narzędziem (np. odwzorowanie obiektowego diagramu klas na tabele w relacyjnej bazie danych). Jest to dzisiejsza rynkowa sytuacja, która jest niekorzystna dla rozwoju obiektowych metod projektowania systemów. Jest nadzieja, że w niedługiej przyszłości ulegnie to poprawie.

35 Wykład 3: Wprowadzenie do pojęć obiektowości (1)
Źródła i motywacje obiektowości Obszary oddziaływania obiektowości Przeszkody dla obiektowości Podstawowe pojęcia obiektowości Obiekty, atrybuty, obiekty złożone Powiązania pomiędzy obiektami, asocjacje

36 Źródła obiektowości Języki programowania operujące
na złożonych strukturach danych, wprowadzające klasy, metody, dziedziczenie i hermetyzację. (Simula 67, Smalltalk) Skierowanie uwagi na czynnik ludzki w tworzeniu oprogramowania, zmniejszenie dystansu pomiędzy modelem pojęciowym a modelem realizacyjnym 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 Bazy danych, od początku bazujące na obiektach (IMS, CODASYL). Wady modelu relacyjnego baz danych; odrzucenie jego powierzchownej prostoty.

37 Motywacje dla obiektowości
Celem nadrzędnym obiektowości jest lepsze dopasowaniu modeli pojęciowych i realizacyjnych systemów do wrodzonych ludzkich instynktów, własności psychologicznych i mentalnych mechanizmów percepcji i rozumienia świata. Miliony lat ewolucji wykształciło mechanizmy percepcji i klasyfikacji, których podstawą jest wyróżnianie obiektów o określonych granicach, posiadających odpowiedniki językowe i podlegających określonemu zachowaniu. Centralnym punktem zainteresowań tej informatycznej ideologii jest człowiek (analityk, projektant, programista), którego wrodzone mechanizmy percepcji świata są wykorzystane do budowania wizji wnętrza systemu informatycznego. Obiektowość - w założeniu - bazuje na własnościach i mechanizmach ludzkiego umysłu na podobnej zasadzie jak koncepcja klawiatury komputera bazuje na anatomicznym fakcie posiadania przez ludzi rąk i palców. Naturalne ludzkie predyspozycje są wzmacniane poprzez mechanizmy abstrakcji (hermetyzacji), modelowania, klasyfikacji, dekompozycji i ponownego użycia. Misja obiektowości: walka ze złożonością.

38 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).

39 Przeszkody dla obiektowości
Zastany świat środkow programistycznych (C, Basic, Fortran, ...) Zastane wierzenia, mity, fałszywe stereotypy i przekręty: Ogromne inwestycje w relacyjne bazy danych. Konkurencja technologicznie dojrzałych systemów relacyjnych (i ich następców tzw. "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ń. SQL jest uniwersalną i unikalną ("intergalaktyczną") mową danych. Tylko relacyjna baza danych zapewnia przetwarzanie transakcji/rozproszenie/... Relacyjne bazy danych mają nieosiągalną dla innych wydajność/skalowalność/...

40 Podstawowe pojęcia obiektowości (1)
Obiekty, tożsamość. Złożone struktury danych z przypisanymi do nich operacjami, czyli obiekty, z unikalnymi identyfikatorami. 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 zdefiniowany dla tych struktur zestaw operacji.

41 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 (m.in. definicje atrybutów i metod). 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.

42 Obiekty (1) 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ę. 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. Obiekt posiada stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu).

43 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ć 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 może być użyty w programie.

44 Przykład obiektu KONTO Wypłać Wpłać Porównaj Sprawdź podpis stan
Numer Właściciel Jan Kowalski Upoważniony Ewa Kowalska Nalicz procent SaldoZł 34567 Zlikwiduj konto .... Zmień upoważnienie Upoważnij

45 Atrybuty obiektu, obiekty złożone
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, liczby poziomów hierarchii komponentów lub rozmiarów/typów 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.

46 Przykład obiektu złożonego
Pracownicy Pracownik Zatrudnienia ..... Zatrudnienie Stanowisko Nazwisko Dzieci ... Dziecko Pracownik Zatrudnienia ..... Zatrudnienie Stanowisko Nazwisko Dzieci ... Dziecko .....

47 Powiązania pomiędzy obiektami, asocjacje
Na poziomie realizacyjnym powiązania pomiędzy obiektami można sobie wyobrazić jako wskaźniki prowadzące od obiektu do obiektu. FIRMA NrFirmy Nazwa Syntex Prezes Zatrudnia PRACOWNIK Nazwisko Nowak Zarobek 1500 PracujeW Nazwisko Babel Zarobek 2000 Nazwisko Kowal Zarobek 2500 Diagram klas: PRACOWNIK Nazwisko Zarobek 0..* PracujeW Prezes Zatrudnia 0..1 FIRMA NrFirmy Nazwa Na poziomie pojęciowym powiązania nie mają charakteru wskaźników, lecz pewnych abstrakcyjnych “nitek” łączących obiekty. Asocjacje: abstrakcyjne oznaczenia powiązań na diagramach klas.

48 Powiązania jako “nitki” łączące obiekty
OSOBA Bober OSOBA Kowalska Sprzedający Pośrednik Diagram klas: Kupujący Transakcja Transakcja Sprzedający OSOBA Nazwisko Kupujący Pośrednik Sprzedający OSOBA Nowak Kupujący OSOBA Wilczek Pośrednik Pośrednik Transakcja Kupujący Transakcja OSOBA Maciąg OSOBA Bielicka Sprzedający

49 Wykład 4: Wprowadzenie do pojęć obiektowości (2)
Atrybuty powiązań Liczność asocjacji Hermetyzacja i ukrywanie informacji Metody i komunikaty Klasy Generalizacja, specjalizacja, dziedziczenie Polimorfizm Wielokrotne dziedziczenie

50 Atrybuty powiązań Diagram klas: Sprzedający Kupujący Pośrednik
OSOBA Bober OSOBA Kowalska Diagram klas: Sprzedający Sprzedający OSOBA Nazwisko Kupujący Kupujący Pośrednik Transakcja Plac 40000 Transakcja Dom 300000 Pośrednik Pośrednik OSOBA Nowak OSOBA Wilczek Kupujący Sprzedający Transakcja Pośrednik Transakcja Samochód 20000 DaneTransakcji PrzedmiotTransakcji DataTransakcji WartośćTransakcji Kupujący OSOBA Maciąg OSOBA Bielicka Sprzedający

51 Modelowanie powiązań jako obiektów
OSOBA Bober OSOBA Kowalska Sprzedający Kupujący Pośrednik TRANSAKCJA Plac 40000 TRANSAKCJA Dom 300000 Diagram klas: Sprzedający OSOBA Nazwisko Kupujący Pośrednik OSOBA Nowak Kupujący Sprzedający OSOBA Wilczek Pośrednik Pośrednik 0..* Transakcja PrzedmiotTransakcji DataTransakcji WartośćTransakcji TRANSAKCJA Samochód 20000 0..* 0..* Kupujący Sprzedający OSOBA Maciąg OSOBA Bielicka

52 Liczność asocjacji A A A B B B B B B B B B A B: min = 1, max = 1
B: min = 1, max = n A B: min = 0, max = 1 A B A: min = 1, max = n A: min = 0, max = n B A: min = 0, max = n B A A A Oznaczenia liczności na diagramie klas: 1..* 0..* 0..* 1..* 0..1 B B B

53 Hermetyzacja i ukrywanie informacji
Hermetyzacja: zamykanie szczegółów w bryłę, którą można manipulować tak jak jednostką (tworzyć, przesuwać, kopiować, usuwać, zabezpieczać, itd.). Ukrywanie informacji: programista ma tyle wiedzieć o procedurze, module, obiekcie, itd., ile mu trzeba, aby go efektywnie używać. Wszystko, co może być przed nim ukryte, powinno być ukryte. Jest to ważne z punktu widzenia efektywności tworzenia oprogramowania (nie musi interesować się szczegółami) oraz bezpieczeństwa i niezawodności (nie może nic zepsuć). Hermetyzacja i ukrywanie informacji są podstawowymi zasadami dowolnej inżynierii, włączając inżynierię oprogramowania. Np. telewizor jest hermetyzowaną bryłą ukrywającą ogromną liczbę szczegółów, które nie są interesujące dla użytkowników. Dla nich istotny jest tylko "interfejs" telewizora, tj. ekran i przyciski na pilocie. Rozhermetyzowanie tej bryły (zdjęcie obudowy) grozi porażeniem użytkownika i uszkodzeniem aparatu! Pewne mechanizmy hermetyzacji są zrealizowane w systemach relacyjnych (np. perspektywy i procedury BD w SQL). Są one jednak zbyt słabe, chociażby w stosunku do języków programowania takich jak Modula-2.

54 Wewnętrzna i zewnętrzna struktura obiektu
Wewnętrzna struktura obiektu Zewnętrzna struktura obiektu PRACOWNIK PRACOWNIK NAZWISKO Nowak ROK_UR 1951 NAZWISKO Nowak ZAROBEK 2500 DZIAŁ Zabawki DZIAŁ Zabawki ZarobekNetto() {...}; Podatek(){...}; ZarobekNetto() ZmieńZarobek(...) {...}; ZmieńZarobek(...) Wiek() { return RokBież - ROK_UR }; Wiek()

55 Metody i komunikaty 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. Wypłać ( 1000 ) Wypłać Wpłać KONTO OK, wypłaciłem Sprawdź stan Porównaj podpis Numer SaldoZł 34567 Właściciel Jan Kowalski Upoważniony ... .... Graj Nalicz procent Zlikwiduj konto Zmień upoważnienie ??? błąd! Upoważnij 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.

56 Komunikat a wołanie procedury
Pojęcia są bardzo podobne: Wołanie procedury: obiekt jest komunikowany jako parametr: procedura( obiekt, par1, par2,...) Komunikat: obiekt-adresat poprzedza wywołanie metody: obiekt.metoda(par1, par2,...) Zasadnicza różnica: 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. Musi być przełączenie explicite wewnątrz procedury dochody; procedurę musi pisać jeden programista, na wszystkie okazje. X = dochody( emeryt ) Y = dochody( pracownik ) 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ć. X = emeryt.dochody() Y = pracownik.dochody()

57 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. Są one oparte na budowaniu 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.

58 Klasy 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: 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. Dobra definicja: Nazwa, czyli językowy identyfikator obiektu Typ, czyli statyczna budowa obiektu (atrybuty) Metody, czyli operacje, które można wykonać na obiekcie Najważniejsze inwarianty to: 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 ...... Możliwe są inne inwarianty:

59 Klasa, interfejs, typ 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.

60 Wyodrębnienie klasy KONTO KONTO 123-4321 34567 Jan Kowalski ....
Klasa KONTO Wypłać Wpłać KONTO Obiekty KONTO (punkt widzenia użytkownika) Sprawdź stan Porównaj podpis Numer: char[8] SaldoZł: integer Właściciel: string Upoważniony: string .... Wpłać Porównaj podpis Zlikwiduj konto Wpłać Porównaj podpis Zlikwiduj konto Nalicz procent Zlikwiduj konto Wypłać Wpłać Zmień upoważnienie Upoważnij KONTO Sprawdź stan Porównaj podpis Numer SaldoZł 34567 Właściciel Jan Kowalski Upoważniony ... .... Związki “jest wystąpieniem klasy” Nalicz procent Zlikwiduj konto Zmień upoważnienie 34567 Jan Kowalski .... Upoważnij Obiekty KONTO (reprezentacja wewnątrz pamięci)

61 Generalizacja, specjalizacja, dziedziczenie
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 ...Rodzaj towaru? ...Rodzaj usługi? Firma nazwa adres Generalizacja Sklep Rodzaj towaru Firma usługowa Rodzaj usługi Specjalizacja

62 Polimorfizm Każda klasa ma własną metodę dochody.
Są one niezależne i są niezależnie programowane OSOBA nazwisko kategoria .... PRACOWNIK .... dochody() STUDENT .... dochody() EMERYT .... dochody() obiekt obiekt obiekt

63 Ekstensja klasy Ekstensja klasy OSOBA Ekstensja klasy PRACOWNIK OSOBA
Nazwisko Kowalska RokUr 1975 OSOBA Nazwisko RokUr Wiek() Ekstensja klasy OSOBA OSOBA Nazwisko Nowak RokUr 1951 OSOBA Nazwisko Abacki RokUr 1948 OSOBA Nazwisko Nowacki RokUr 1940 PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(...) 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 PRACOWNIK

64 Wielokrotne dziedziczenie
Klasa może dziedziczyć z dwóch lub więcej klas. POJAZD ciężar ..... prędkość_eksploat() POJAZD_LĄDOWY ilość_kół max_prędkość ..... POJAZD_WODNY wyporność max_prędkość ..... SAMOCHÓD TRAKTOR ŻAGLÓWKA JACHT AMFIBIA Wielokrotne dziedziczenie ma duże znaczenie dla modelowania pojęciowego. Jest jednak powodem anomalii i wad koncepcji, m.in. w C++. Z tego względu twórcy niektórych języków (m.in. Java) zrezygnowali z tej własności.

65 Wykład 5: Diagramy klas Metoda oparta na diagramy klas
Zastosowania diagramu klas Oznaczenia klas, atrybutów i operacji Asocjacje Generalizacja i dziedziczenie Agregacje (kompozycje) Budowa diagramu klas - ćwiczenie

66 Metoda oparta na diagramy klas
Diagramy klas są podstawową osią, dookoła której rozwija się każdy projekt obiektowy. Są one odmianą dość klasycznych diagramów encja-związek (entity-relationship), ale wzbogacone o istotne nowe własności. Podstawowymi oznaczeniami są oznaczenia klas (UML: prostokąty), oznaczenia hierarchii dziedziczenia (UML: strzałki z białym grotem), oznaczenia związków asocjacji (UML: linie) oraz oznaczenia związków agregacji (UML: białe i czarne romby). Te podstawowe oznaczenia są uzupełnione o dużą liczbę pomocniczych oznaczeń. Wprowadzane są rozszerzenia poprawiające czytelność diagramów i przystosowujące je do dziedziny zastosowań.

67 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++, Java, IDL CORBA lub ODMG ODL.

68 Oznaczenia klas Dopuszcza się różne poziomy abstrakcji i szczegółowości. Okno 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)

69 Atrybuty Atrybut jest nazwaną wartością przechowywaną przez obiekty w ramach klasy. Niekiedy wartość atrybutu jest obiektem lub referencją do obiektu. nazwisko wiek atrybuty obiektu Osoba (Osoba) Jan Nowak 53 (Osoba) Ewa Stycz 24 Osoba nazwisko: string wiek: integer Klasa z atrybutami Obiekty (wystąpienia) z wartościami Atrybut identyfikujący obiekt (czyli klucz główny) nie jest konieczny. System obiektowy automatycznie generuje wewnętrzny unikalny identyfikator obiektu. Nie mają one znaczenia dla dziedziny problemu.

70 Operacje i metody Operacja jest funkcją lub transformacją, która może być zastosowana do obiektu (lub przez obiekt). Jest ona własnością klasy obiektów. zatrudnij zwolnij wypłać_dewidendę operacje na obiektach klasy Firma Wszystkie obiekty w ramach klasy podlegają tym samym operacjom. Ta sama operacja może być zastosowana do obiektów wielu różnych klas. Jest to określane jako polimorfizm. Metoda jest implementacją operacji dla jednej klasy. Plik ASCII Różne operacje drukowania drukuj Plik postscript Plik graficzny

71 Argumenty operacji Operacja/metoda może mieć argumenty (oprócz obiektu, który jest argumentem implicite). Sygnatura operacji: liczba i typ argumentów + typ wyniku operacji. Wszystkie metody implementujące daną operację muszą mieć tę samą sygnaturę. Osoba nazwisko wiek zmień_pracę zmień_adres Plik nazwa_pliku długość_w_bajtach ostatnia_zmiana drukuj Obiekt geometryczny kolor pozycja przesuń( delta: Wektor ) wewnątrz( p: Punkt ): Boolean obróć( kąt ) operacje Jeżeli argumenty nie są specyfikowane, to może ich być dowolnie dużo.

72 Asocjacje Oznaczenia klas są połączone liniami oznaczającymi asocjacje, czyli powiązania pomiędzy obiektami tych klas. Np. asocjacja 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. Pracuje_dla 1..* Firma Osoba Asocjacje mogą być wyposażone w oznaczenia liczności: ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy (minimalna i maksymalna liczbę takich obiektów). Asocjacje mogą być także wyposażone w dodatkowe nazwy ról (przy odpowiednich końcach), np. pracodawca i pracownik.

73 Asocjacje i powiązania
Powiązanie Fizyczny lub pojęciowy związek pomiędzy wystąpieniami obiektów Grupa powiązań posiadających wspólną strukturę i semantykę. Powiązanie jest wystąpieniem asocjacji. Asocjacja (Osoba) Anna (Osoba) Ewa (Osoba) Jan Osoba pracuje_w pracuje_w pracuje_w pracuje_w * (Firma) Krawiecka (Firma) Szewska Firma Klasy i asocjacja Obiekty i powiązania Asocjacje nie mają kierunku: można “przechodzić” w dowolnym. Asocjacja może być nie nazwana, jeżeli jej znaczenie wynika z klas, które łączy.

74 Liczność asocjacji Liczność jest oznaczana na końcach asocjacji binarnych. UML znaczenie Państwo Stolica 1 1..* 2..* 3-5 2,4,18 0..1 0..* * 1 1,2,3,... 2,3,4,... 3,4,5 2,4,18 0,1 0,1,2,... 1 * Firma Pracownik 0..* 0..1 Osoba Adres

75 Atrybuty asocjacji W UML atrybuty asocjacji muszą tworzyć nową klasę.
Pracuje_w * Osoba nazwisko pesel adres Firma nazwa adres Plik szef 0..1 * Zatrudnienie zarobek stanowisko Dostępny dla Prawo dostępu Dostęp * Kieruje czytanie czytanie-pisanie pracownik * Użytkownik Ocena wydajności ocena

76 Generalizacja i dziedziczenie
Generalizacja jest związkiem pomiędzy klasami. Łączy on klasę bardziej ogólną (nadklasę) z jedną lub więcej klas będących jej specjalizacjami (podklasami). Podklasy danej nadklasy dziedziczą wszystkie jej własności. Dziedziczenie jest przechodnie. Wyposażenie nazwa wytwórca koszt aspekt generalizacji typ wyposażenia Pompa ciśnienie ssania ciśnienie tłoczenia przepływ Wymiennik ciepła powierzchnia wymiany średnica rury ... Zbiornik objętość ciśnienie typ zbiornika typ pompy

77 Agregacje (kompozycje)
Autor Tytuł * Dane identyfikacyjne Artykuł * * Pozycja Faktura Akceptacja * Streszczenie Rozdział Suma Literatura Jak odróżnić agregację od asocjacji? Kryterium istnienia: podobiekt nie może istnieć bez obiektu. Kryterium wstawiania: podobiekt nie może być sam wprowadzony do systemu Kryterium usuwania: usunięcie obiektu implikuje usunięcie podobiektu Kryterium fizycznej części: jakiś obiekt jest fizyczną częścią innego obiektu

78 Budowa diagramu klas - ćwiczenie
Założenia bazy danych uczelni: Będą zbierane są informacje o studentach, profesorach i wykładach. Każdy student posiada: imię, nazwisko, data urodzenia, miejsce urodzenia (miasto, województwo), miejsce zamieszkania, aktualny semestr. Każdy student ma ustalony plan wykładów na cały okres studiów. Każdy zaliczony wykład na danym semestrze kończy się wystawieniem oceny końcowej. Studenci, którzy są dyplomantami, tj. ukończyli wszystkie zaplanowane wykłady, piszą pracę dyplomową, której tytuł musi być zapamiętany. Praca dyplomowa prowadzona jest pod opieką jednego z profesorów uczelni. Po zdaniu egzaminu dyplomowego informacje o studencie uzupełniane są o datę obrony pracy oraz ocenę końcową.

79 Budowa diagramu klas - ćwiczenie, cd.
Założenia bazy danych uczelni, cd.: Każdy profesor pracujący na uczelni związany jest z jednym wydziałem, którego nazwa i telefon muszą być znane, oraz opisywany jest następującymi informacjami: imię, nazwisko, data urodzenia, tytuł, specjalność. Uczelnia zatrudnia również profesorów kontraktowych. W takim przypadku dodatkowo należy pamiętać daty rozpoczęcia i zakończenia kontraktu. Każdy profesor prowadzi przynajmniej jeden i co najwyżej 3 różne wykłady na uczelni, przy czym ten sam wykład może być prowadzony przez jednego tylko profesora. Każdy profesor może prowadzić dowolną liczbę dyplomantów. Wykład ma określony swój numer, temat, dzień oraz godzinę rozpoczęcia i zakończenia oraz odbywa się w jednym z wielu pomieszczeń uczelni, które znajdują się w różnych budynkach.

80 Przykładowe rozwiązanie ćwiczenia
OSOBA Nazwisko Imię Data_ur Nr_ewiden MIASTO Nazwa Województwo WYDZIAŁ Nazwa Telefon urodziła się jest_zatrudniony_na * mieszka w 1..* * STUDENT Semestr_studiów PROFESOR Specjalność Tytuł * uczęszcza DYPLOMANT Tytuł_pracy Data_obrony Ocena_końcowa opiekuje_się PRZYPISANIE Status Semestr Oceny * PROF_KONTRAKTOWY Pocz_kontraktu Kon_kontraktu * WYKŁAD Ident_wykładu Nazwa_wykładu prowadzony_przez 1-3 KALENDARZ Semestr Dzień tygodnia SALA Id_budynku Nr_sali odbywa się GODZINY godz_początku godz_końca Rozwiązanie jest niekompletne, np. brakuje metod.

81 Wykład 6: Diagramy przypadków użycia
Cel metody przypadków użycia Podstawowe oznaczenia metody przypadków użycia Przykłady diagramów przypadków użycia Opis i dokumentacja przypadków użycia Wyszukanie i analiza aktorów Modele wykorzystujące przypadki użycia Sporządzenie słownika pojęć

82 Cel metody przypadków użycia
use cases Podstawowym problemem jest określenie wymagań na projektowany system. Celem metody opartej na przypadkach użycia jest: zrozumienie użycia systemu będącego przedmiotem procesu projektowania zwiększenie 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 Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy. Model musi być zrozumiały dla przyszłych użytkowników.

83 Charakterystyka metody przypadków użycia
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. W późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przy pomocy notacji lub diagramów obiektowych. Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich w postaci scenariuszy. Tworzenia przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele.

84 Podstawowe oznaczenia metody
Model przypadków użycia wprowadza następujące pojęcia i notacje: Przypadek użycia Interakcja Aktor Aktor reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient). Przypadek użycia reprezentuje sekwencję operacji lub transakcji wykonywanych w dialogu z systemem (np. potwierdzenie pisma, złożenie zamówienia). Interakcja pokazuje interakcję pomiędzy przypadkiem użycia i aktorem (środowiskiem zewnętrznym). Przypadki użycia reprezentują przepływ zdarzeń w systemie. Są one uruchamiane (inicjowane) przez aktorów. Aktorem jest dowolny byt zewnętrzny, który uczestniczy w interakcji z przypadkiem użycia.

85 Przykład modelu przypadków użycia
wpłata pieniędzy kasjer wypłata pieniędzy «uses» klient banku sprawdź bilans weź pożyczkę zarząd banku

86 Przykład modelu przypadków użycia
Automat do operacji bankowych Prowadzenie konta klienta Baza danych banku «uses» Weryfikacja karty i kodu klienta «uses» Informowanie o stanie konta klienta Klient «uses» Inicjalizacja karty klienta Administrator systemu

87 Powiązania w modelu przypadków użycia
Pracownik biura Generalizacja pomiędzy aktorami, dziedziczenie dostępu do przypadków użycia Sekretarz Referent Księgowy «extends» 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. «uses» 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.

88 Diagram przypadków użycia
Ustalenie limitów Aktualizacja rozliczeń System rozliczeniowy Dyrektor handlowy Analiza ryzyka «uses» Wyliczenie ocen Sprawy cenowe «uses» Handlowiec Ocena zysków «extends» Sprzedawca Przekroczenie limitów

89 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?

90 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.

91 Aktorzy Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych w jakiś sposób z projektowanym systemem. Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba może pełnić rolę wielu aktorów; np. być jednocześnie sprzedawcą i klientem. I odwrotnie, jeden aktor może odpowiadać wielu osobom, np. strażnik budynku. Każdy aktor będzie używać systemu na kilka specyficznych sposobów. Każdy z tych sposobów musi przyjąć postać przypadku użycia.

92 Wyszukanie aktorów Wyszukanie potencjalnych aktorów musi być powiązane z ustaleniem granic systemu, tj. odrzucenia obszarów dziedziny problemowej, którymi system nie będzie się zajmować 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?

93 Analiza aktorów Zakresy znaczeniowe dla poszczególnych nazw aktorów, relacje pomiędzy zakresami; np. sekretarka  pracownik administracji  pracownik  dowolna osoba. Czy użytkownicy mogą łączyć funkcje kilku aktorów i jakich? (minimalizacja aktorów) Jakie jest główne zadanie dla każdego aktora? Czy aktor będzie czytał/pisał/zmieniał jakąkolwiek informację w systemie? Czy aktor ma informować system o zmianach na zewnątrz? Czy aktor życzy sobie być poinformowany o zmianach? Wyjaśnić różnice pomiędzy konkretnymi użytkownikami i aktorami

94 Modele wykorzystujące przypadki użycia
Model przypadków użycia: definiuje zewnętrze (aktorów) oraz wnętrze (przypadki użycia), które określają zachowanie się systemu. Obiektowy model dziedziny: przypadki użycia ustalają obiekty świata rzeczywistego relewantne dla projektowanego systemu. Obiektowy model analityczny: przypadki użycia opisują strukturę istniejącej lub przyszłej rzeczywistości biznesowej. Obiektowy model projektowy: przypadki użycia opisują założenia przyszłej implementacji, szczególnie interfejsów użytkownika Model implementacyjny: przypadki użycia wyznaczają często architekturę i strukturę implementację systemu Model testowania: przypadki użycia określają plan testów, specyfikacji i raportów.

95 Metoda oparta na przypadkach użycia
Krok Udokumentowany w: Sporządzenie słownika pojęć Słownik pojęć Ustalenie aktorów Dokument opisu aktorów Ustalenie przypadków użycia Opis każdego przypadku użycia: * podział na nazwane części * wyspecyfikowanie w szczegółach * znalezienie wspólnych części w różnych przypadkach użycia Diagram przypadków użycia Dokument opisu przypadków użycia

96 Sporządzenie słownika pojęć
Polega na wyłowieniu wszystkich terminów z początkowych wymagań. Słownik dotyczy dziedziny problemowej. Terminy ze słownika powinny być normą przy opisie problemu, sytuacji lub modelu. Powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, aktywności, zdarzeń, itd. Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika: na rzeczowniki: mogą one oznaczać aktorów lub obiekty dziedziny problemowej; na frazy opisujące funkcje, akcje, zachowanie się: mogą one być podstawą wyróżnienia przypadków użycia.

97 Tworzenie diagramu przypadków użycia
Wyszczególnienie pojęć Szkicowy opis przepływu zdarzeń Zdefiniowanie sposobu interakcji aktora z przypadkiem użycia Ustanowienie związków uses (używa) Ustanowienie związków extends (rozszerza) Sporządzenie diagramu przypadków użycia, aktorów i związków Przedyskutowanie i krytyka modelu Sprawdzenie kompletności modelu

98 Inne diagramy i metody stosowane w analizie i projektowaniu obiektowym
Diagramy przypadków użycia i diagramy klas są dwiema zasadniczymi osiami, dookoła których rozwija się projekt. Inne diagramy i związane z nimi metody umożliwiają spojrzenie na ten sam system z innych perspektyw: Diagramy pakietów Diagramy stanów Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy komponentów Diagramy wdrożeniowe (deployment) ...

99 Podsumowanie 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ę skutecznych pojęć i narzędzi, szczególnie w zakresie analizy i projektowania. W dziedzinie baz danych obiektowość jest na początku drogi i musi walczyć z konserwą i spuścizną modelu relacyjnego.