Inżynieria oprogramowania

Transkrypt

1 Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne Inżynieria oprogramowania część I dr inż. Bartłomiej Prędki Bartlomiej.Predki@cs.put.poznan.pl Pok. 124 CW, tel Semestr letni 2014/2015

2 Literatura A. Jaszkiewicz, Inżynieria oprogramowania, Helion, Gliwice, B. Begier, Inżynieria oprogramowania problemy jakości, Wydawnictwo Politechniki Poznańskiej, Poznań, Janusz Górski (red.). Inżynieria oprogramowania w projekcie informatycznym. Mikom, Warszawa, 2000, wyd. II. G. Booch, J. Rambaugh, I. Jacobson, UML przewodnik użytkownika, WNT, Warszawa, C. Larman, UML i wzorce projektowe., Helion 2011 D. Hamlet, J. Maybee, Podstawy techniczne inżynierii oprogramowania, WNT 2003

3 Literatura S. Maguire, Niezawodność oprogramowania, Helion, Gliwice, 2002 E. Freeman, B. Bates, K. Sierra, Wzorce projektowe. Rusz głową!, Helion, 2010 Z. Szyjewski, Zarządzanie projektami informatycznymi, Placet 2001 K. Beck, M. Fowler, W. Opdyke, D. Roberts, Refaktoryzacja. Ulepszanie struktury istniejącego kodu, WNT 2006 E. Gamma, R. Helm, R. Johnson, J. Vlissides, Wzorce projektowe, WNT 2008

4 Rynek oprogramowania 2011 Świat miliardów dolarów (42.6% Ameryka) Bez oprogramowania wytwarzanego na własne potrzeby Wzrost 6.6% rocznie miliardów euro dodatkowych usług W UE 60-70% oprogramowania jest wytwarzane w firmach, dla których nie jest to główną działalnością W 2016 ponad 396 mld dolarów

5 Rynek oprogramowania

6 Rynek oprogramowania

7 Rynek oprogramowania

8 Najwięksi gracze IBM Microsoft Oracle SAP

9 Trochę historii Lata 50-te Sprzęt o bardzo ograniczonych możliwościach Ograniczone zastosowania Małe programy Programy pisane często dla własnych potrzeb lub potrzeb dobrze znanych osób Dobrze wyspecyfikowane zadania

10 Rozwój technik wytwarzania oprogramowania Lata 60-te Profesjonalni programiści Nowe języki programowania COBOL, Fortran, Algol Sprzęt o dużo większych możliwościach, np. pamięć wirtualna Nowe zastosowania np. w biznesie Próba realizacji wielu dużych przedsięwzięć programistycznych

11 Kryzys oprogramowania Rozwój technik wytwarzania oprogramowania nie nadąża za rozwojem sprzętu komputerowego Czy kryzys oprogramowania trwa do dzisiaj? Nadal większość przedsięwzięć przekracza czas i/lub budżet Około 25% przedsięwzięć programistycznych nie jest kończona 90% firm przyznaje, że dość często zdarzają im się opóźnienia przedsięwzięć Powszechna akceptacja kiepskiej jakości oprogramowania (w pewnych obszarach)

12 Zależność osiągnięcia-oczekiwania w wytwarzaniu oprogramowania Efekty Oczekiwania Rzeczywiste osiągnięcia Czas

13 Przyczyny kryzysu oprogramowania Duża złożoność systemów informatycznych Złożoność, zmienność, nieadekwatność wymagań Niepowtarzalność poszczególnych przedsięwzięć Nieprzejrzystość procesu budowy oprogramowania Pozorna łatwość wytwarzania i modyfikowania oprogramowania Potrzeba kreatywności Czynnik ludzki Mało wymagający rynek Niedoskonałość narzędzi

14 Przykład - system dla PKW błędy po stronie klienta zbyt krótki czas na zrealizowanie prac brak oceny złożoności problemu i wymagań brak samokrytycyzmu błędy po stronie kontrahenta brak doświadczenia zbyt swobodne podejście

15 Początek inżynierii oprogramowania 1968 NATO Conference on Software Engineering

16 Podejście amatorskie a inżynierskie Co by tu wymyślić!? Do pracy.

17 Definicje inżynierii oprogramowania Duże systemy wymagające pracy wielu osób praca grupowa Wielowersyjność oprogramowania

18 Definicja inżynierii oprogramowania Wiedza techniczna, dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu - oprogramowania.

19 Jakość oprogramowania Użyteczność (usefulness) Niezawodność (reliability) Ergonomia (usability) Efektywność (efficiency) Łatwość konserwacji (maintability) Bezpieczeństwo użytkownika (user safety) Koszt?

20

21 Zakres inżynierii oprogramowania Wytwarzanie oprogramowania i innych produktów (np. dokumentacji) Zarządzanie wytwarzaniem oprogramowania

22 Plan wykładów I semestr Wprowadzenie i podstawowe modele cyklu życia oprogramowania Analiza/modelowanie systemów z wykorzystaniem języka UML, w tym elementy analizy wymagań UML jako narzędzie projektowania i dokumentowania oprogramowania Projektowanie oprogramowania Niezawodność oprogramowania Dokumentacja techniczna i użytkowa Narzędzia inżynierii oprogramowania

23 Zaliczenie Wykład jest zaliczany w trakcie testu na ostatnim wykładzie, czyli 27 kwietnia 2014 r.

24 Modele cyklu życia oprogramowania Uporządkowanie prac. Ustalenie kolejności prac. Planowanie i monitorowanie realizacji.

25 Programowanie odkrywcze Ogólne określenie wymagań Ogólny projekt Budowa systemu Ocena systemu Wdrożenie Tak System poprawny Nie

26 Model kaskadowy Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja

27 Dodatkowe fazy w modelu kaskadowym

28 Ścisłe i elastyczne rozumienie modelu kaskadowego Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja

29 Przykład elastycznego podejścia do modelu kaskadowego

30 Wady i zalety modelu kaskadowego (rozumianego ściśle) +Łatwość zarządzania planowanie i monitorowanie -Wysoki koszt błędów popełnionych we wstępnych fazach Koszt błędu w wymaganiach razy większy od kosztu błędu programistycznego! -Długa przerwa w kontaktach z klientem -Nie lubiany przez wykonawców

31 Prototypowanie Cel lepsze określenie wymagań Fazy: Ogólne określenie wymagań. Budowa prototypu. Weryfikacja prototypu przez klienta. Pełne określenie wymagań. Realizacja pełnego systemu zgodnie z modelem kaskadowym.

32 Sposoby budowy prototypu Prototyp musi być zbudowany szybko i niskim kosztem. Niepełna realizacja. Języki wysokiego poziomu. Wykorzystanie gotowych komponentów. Generatory interfejsu użytkownika. Szybkie programowanie (quick-and-dirty programming). Papier. Programowanie odkrywcze.

33 Wady i zalety prototypowania +Mniejsze ryzyko popełnienia kosztownych błędów we wczesnych fazach. +Możliwość szybkiej demonstracji prototypu i szkolenia użytkowników. -Koszt budowy prototypu, który może się nie zwrócić. -Możliwość nieporozumień z klientem.

34 Realizacja przyrostowa Określenie wymagań i wstępny projekt Wybór przyrostu - podzbioru funkcji Proces realizowany iteracyjnie Realizacja przyrostu Wdrożenie przyrostu

35 Wady i zalety realizacji przyrostowej + Możliwość wcześniejszego korzystania z pewnych funkcji systemu. + Skrócenie przerw w kontaktach z klientem. + Możliwość elastycznego reagowania na opóźnienia. -Kłopoty z integracją oddzielnie realizowanych modułów.

36 Realizacja przyrostowa Zalecana w większości lekkich (żwawych) metodyk np. w programowaniu ekstremalnym często małe przyrosty (kilka tygodni) Dobrze opisuje realizację wielu (zwłaszcza udanych) projektów wolnego oprogramowania (free/open source)

37 Wybór modelu do konkretnego przedsięwzięcia Duże przedsięwzięcia, np. > 6 miesiecy realizacja przyrostowa, mniejsze m. kaskadowy W lekkich metodykach także dla mniejszych przedsięwzięć Trudności w określeniu wymagań: nowatorski system z punktu widzenia klienta mała znajomość dziedziny problemu przez wykonawcę: Jeżeli tak, to prototypowanie

38

39 Unified Modeling Language - UML Obiektowa notacja graficzna służąca do modelowania, projektowania i specyfikacji oprogramowania Następca licznych notacji obiektowych z lat 80- tych i 90-tych Powstał na bazie metod Boocha, Rumbaugh (OMT) i Jacobsona stworzony przez tych właśnie autorów

40 Unified Modeling Language - UML Standard Object Management Group (OMG) Wspierany przez firmę Rational De facto standard przemysłowy Pierwsza wersja w 1997 Notacja, a nie metodyka

41 Analiza/modelowanie Opracowanie logicznego modelu dziedziny problemu Cele: Lepsze zrozumienie dziedziny problemu i lepsze określenie wymagań Podstawa przyszłego projektu

42 Dziedzina problemu System Dziedzina problemu W pw p Model

43 Dlaczego notacje graficzne w modelowaniu Ogromny wzrost precyzji Ogromna poprawa efektywności Zapis modelu Analiza modelu Wprowadzanie zmian Łatwe przejście do projektowania

44 Diagramy przypadków użycia use case diagrams modelowanie wymagań Użytkownik, klasa użytkowników, system zewnętrzny (ang. actor) Grupa użytkowników wykorzystujących system w podobny sposób Przypadek użycia, wymaganie funkcjonalne, funkcja (ang. use case)

45 Korzystanie z funkcji (ang. actor flow)

46 Związki używania (use) i rozszerzania (extend)

47 Przykład i związek generalizacji (generalization)

48 Diagramy klas Model statyczny

49 Obiekt Składowa dziedziny problemu posiadająca: tożsamość dane ją opisujące zachowanie Obiekty wewnętrzne systemu, dane np. wektor, plik, raport, drzewo binarne, okno, dokument elektroniczny Obiekty zewnętrzne, metadane osoba, samochód, dokument papierowy, projekt

50 Klasa Wzorzec, uogólnienie grupy obiektów opisywanych za pomocą podobnych danych i mających podobne zachowanie Samochody

51 Związek generalizacji-specjalizacji Pojazd Samochód ciężarowy Samochód W p Samochód osobowy

52 Wiele generalizacji

53 Związek klas Uogólnienie możliwych powiązań obiektów

54 Krotności związków 0..1 zero lub jeden, opcjonalny 1 dokładnie jeden, wymagany * - dowolna liczba 1..* - jeden lub więcej N..M od N do M N dokładnie N

55 Przykłady

56 Opisy związków Rola Nazwa

57 Różne związki pomiędzy tymi samymi klasami

58 Związek pomiędzy obiektami tej samej klasy

59 Ograniczenia dotyczące związków

60 Związek kompozycji

61 Przykład - giełda usług przewozowych

62 Przykład grafika wektorowa

63 Przykład czasopismo naukowe

64 Diagramy stanów Model dynamiczny Zastosowania: Modelowanie zmian stanów (grup) obiektów Modelowanie reakcja na zdarzenia Modelowanie algorytmów

65 Zdarzenie Zjawisko, które zachodzi w pewnym punkcie czasu, np.: odjazd pociągu do Gdańska, wprowadzenie danych, wybranie polecenia z menu, przekroczenie temperatury 50 C.

66 Zdarzenia Zdarzenie zewnętrzne zachodzi poza systemem, np.: wprowadzenie danych, wybranie polecenia z menu, przerwanie przez użytkownika wykonywania operacji. Zdarzenie wewnętrzne zachodzi w ramach systemu, np.: zakończenie wykonywania metody, błąd arytmetyczny, przekroczenie czasu.

67 Stan Okres czasu ograniczony przez dwa zdarzenia System (fragment systemu) znajdując się w różnych stanach reaguje w sposób jakościowo różny na zachodzące zdarzenia. (Stan artykułu w czasopiśmie naukowym)

68 Stany początkowy i końcowy Początkowy Końcowy

69 Przejście Zmiana stanu w wyniku zdarzenia Może być obwarowane warunkami Zachodzi natychmiastowo (w przybliżeniu) Zdarzenia Warunek

70 Akcja Czynność wykonywana (w przybliżeniu) natychmiastowo w momencie zajścia zdarzenia

71 Czynność Działanie wykonywane w czasie kiedy system jest w pewnym stanie Może zostać przerwana w momencie zajścia zdarzenia, które powoduje wyjście ze stanu Jeżeli kończy się samoczynnie, to generuje zdarzenie, które powoduje przejście do innego stanu.

72 Akcje wejściowe, wyjściowe i wewnętrzne =

73 Stan złożony

74 Przykład stany artykułu

75 Przykład zaznaczanie i przesuwanie obiektów w programie graficznym

76 Diagramy sekwencji Przepływ komunikatów pomiędzy elementami dziedziny problemu

77 Obiekt Lina życia Czas Nazwa obiektu:nazwa klasy : Osoba - nieokreślony obiekt klasy Osoba, Jan Nowak : Osoba - obiekt Jan Nowak klasy Osoba, Jan Nowak : - obiekt Jan Nowak nieokreślonej klasy.

78 Komunikaty Synchroniczny Asynchroniczny

79 Przykład korzystanie z bankomatu

80 Specyfikacja modelu UML jest językiem graficznym Na diagramach można umieszczać szereg dodatkowych informacji ograniczenia, stereotypy, komentarze W praktyce diagramy często wspiera się dodatkową specyfikacją wspiera to szereg narzędzi CASE

81 Specyfikacja klas Opis Lista pól Lista metod Ograniczenia Np. Wzrost > 0 Płaca minimalna < Płaca maksymalna Szacowana lub dokładna liczba obiektów tej klasy Trwałość

82 Specyfikacja metod opis specyfikacja deklaratywna dane wejściowe dane wyjściowe algorytm warunki wstępne warunki końcowe wyjątki złożoność czasowa złożoność pamięciowa

83 Specyfikacja pól i parametrów typ przechowywanych wartości jednostka miary zakres dopuszczalnych wartości lista możliwych wartości wymagana precyzja wartość domyślna czy pole może być puste ograniczenia metody, które mogą czytać, ustawiać i modyfikować wartości tego pola.

84 Specyfikacja algorytmów Algorytm klasyfikacji na podstawie reguł decyzyjnych Dane wejściowe Uporządkowana (wg. ważności) lista reguł decyzyjnych w postaci: Jeżeli (A1 =...) i... i (An...) to Decyzja =... Reguła domyślna z pustą częścią warunkową Obiekt do zaklasyfikowania opisany atrybutami A1 do An

85 Algorytm klasyfikacji na podstawie reguł decyzyjnych powtarzaj od reguły najważniejszej do najmniej ważnej jeżeli obiekt spełnia warunki reguły, to podejmowana jest decyzja wskazywana przez regułę dopóki nie podjęto decyzji lub nie sprawdzono wszystkich reguł jeżeli nie podjęto decyzji, to podejmij decyzję wskazywaną przez regułę domyślną

86 Budowa statycznego modelu klas Identyfikacja klas Identyfikacja związków klas Identyfikacja pól Identyfikacja metod

87 Identyfikacja klas Typowe klasy: przedmioty namacalne (np. samochód, czujnik), role pełnione przez osoby (np. pracownik, wykładowca, polityk), zdarzenia, o których system przechowuje informacje (np. lądowanie samolotu, zamówienie, dostawa), interakcje pomiędzy osobami i/lub systemami, o których system przechowuje informacje (np. pożyczka, spotkanie, konferencja), lokalizacje, tj. miejsca przeznaczone dla ludzi lub przedmiotów,

88 Identyfikacja klas Typowe klasy grupy przedmiotów namacalnych (samochody, czujniki), organizacje (np. firma, wydział, związek), koncepcje (np. miara jakości, zadanie), dokumenty (np. prawo jazdy, faktura), klasy będące interfejsami dla systemów zewnętrznych, klasy będące interfejsami dla urządzeń sprzętowych.

89 Identyfikacja klas Analiza dziedziny problemu (problem domain analysis) wykorzystanie wiedzy dziedzinowej literatura seminaria prezentacje rysunki inne modele np. modele procesów biznesowych

90 Analiza opisu w języku naturalnym Rzeczowniki - potencjalne klasy, obiekty lub pola Czasowniki - potencjalne operacje lub związki klas Ma, posiada, obejmuje, składa się, jest częścią, - związki kompozycji Rzeczowniki odczasownikowe związki klas Rzeczowniki mogą oznaczać role pełnione w związkach

91 Przykład Każdy projekt jest realizowany przez konsorcjum złożone z co najmniej trzech organizacji. Organizacja może być firmą komercyjną, jednostką badawczą lub organizacją publiczną. Organizacja może realizować wiele projektów badawczych. Każdy projekt ma jednego koordynatora.

92 Przykład

93 Identyfikacja klas Wykorzystanie związków klas i obiektów Czy klasa ma potencjalne specjalizacje i/lub generalizacje? Czy klasa ma części składowe i/lub jest częścią większej całości? Czy klasa pozostaje w związkach z innymi klasami?

94 Identyfikacja klas Analiza funkcji Jakie obiekty, jakich klas będą niezbędne do realizacji poszczególnych funkcji

95 Weryfikacja klas Nieobecność pól i operacji Nieliczne (pojedyncze) pola i operacje Brak związków z innymi klasami Tylko jeden obiekt w klasie Dobrą klasą jest klasa Samochód, złymi Samochód Kowalskiego i Samochód Nowaka.

96 Identyfikacja krotności związków Analiza przykładowych (rzeczywistych lub wymyślonych) powiązań obiektów

97 Weryfikacja związków obligatoryjnych np. 1 lub 1..* Czy instytut musi mieć pracowników?

98 Identyfikacja związków kompozycji Zwroty pojawiające się w słownym opisie systemu jak: zawiera, składa się, obejmuje Klasy posiadające części składowe Klasy będące zbiorami pewnych elementów

99 Części składowe

100 Zbiory

101 Identyfikacja związków generalizacji-specjalizacji Dziedziczenie pól i metod

102 Identyfikacja związków generalizacji-specjalizacji Nazwy zawierające się w sobie pracownik i pracownik naukowy samochód i samochód osobowy Wspólne części nazw pracownik naukowy i pracownik techniczny -> generalizacja pracownik

103 Identyfikacja związków generalizacji-specjalizacji Pola, którym nie zawsze można przypisać wartości Metody, które nie zawsze mają sens

104 Związki, które mogą dotyczyć tylko pewnych obiektów

105 Pola służące do rozróżniania obiektów

106 Identyfikacja pól Co jest potrzebne do opisu danej klasy w ramach dziedziny problemu? Jakie dane będą potrzebne operacjom danej klasy do realizacji ich zadań? Jakie pola należy wprowadzić, aby opisać stany w jakich mogą znajdować się obiekty danej klasy? Klasa czy pole?

107 Przykład

108 Weryfikacja związków Czy sensownie brzmi zdanie "A jest rodzajem B" (jeżeli klasa A jest specjalizacją klasy B)? Czy sensownie brzmi zdanie "A [czasownik] B" (jeżeli klasy A i B są związane związkiem klas)? Czy sensownie brzmią zdania "A jest częścią B" lub "B składa się (zawiera) A" (jeżeli obiekty klasy A są składowymi obiektów klasy B)?

109 UML a kod w C++ i Javie Projektowanie oprogramowania Dokumentowanie oprogramowania

110 Diagramy przypadków użycia

111 Klasy użytkowników i wykorzystywane funkcje Mogą sugerować podział systemu na odrębne aplikacje, np. aplikacja dla użytkowników systemu aplikacja dla administratora Elementy interfejsu użytkownika, np. różne tryby pracy, np. różne systemy menu oddzielne fragmenty w strukturze menu blokowanie dostępu do pewnych funkcji

112 Przypadki użycia Funkcje systemu Elementy interfejsu użytkownika menu, podmenu, polecenia w menu dialogi

113 Związki pomiędzy przypadkami użycia Struktura menu Polecenia dostępne w dialogach, np. wywoływanie innych dialogów Kreatory (creators, wizards)

114 Diagramy klas Bezpośrednie przełożenie na kod Wiele dodatkowych elementów wykorzystywanych na etapie projektowania

115 Klasa class Pojazd {... } Nazwy - prefixy, suffixy, zamiana spacji i niedozwolonych znaków class CStudentDzienny {... }

116 Pola C++ class CPojazd { Nazwa;... CenaKilometra;... CenaGodziny; } Na przykład: class CPojazd { protected: char* Nazwa; double CenaKilometra; double CenaGodziny; }

117 Pola Java, C# class Pojazd {... nazwa;... cenakilometra;... cenagodziny; } Na przykład: class CPojazd { protected String nazwa; protected double cenakilometra; protected double cenagodziny; }

118 Symbole widoczności pól i operacji + public publiczne # protected zabezpieczone/chronione - private prywatne ~ - w ramach pakietu

119 class CPojazd { public:... Nazwa; protected:... CenaKilometra; private:... CenaGodziny; } class Pojazd { public... nazwa; protected... cenakilometra; private... cenagodziny; } C++ Java, C#

120 Typy pól

121 Operacje i metody C++ class CPojazd {... public:... Koszt (...); }; CPojazd::Koszt (...) {... }

122 Operacje i metody Java, C# class Pojazd {... public... koszt (...) {... } }

123 Nagłówki operacji C++ class CPojazd {... public: double Koszt (double Czas, double Droga); };... double CPojazd::Koszt (double Czas, double Droga) {... }

124 Nagłówki operacji Java, C# class Pojazd {... public double koszt (double czas, double droga) {... } }

125 Generalizacja-specjalizacja C++ Java C# class CStudentDzienny : public CStudent {... } class StudentDzienny extends Student {... } class StudentDzienny: Student {... }

126 Klasy abstrakcyjne Pochyła czcionka Klasy nie posiadające obiektów (bezpośrednio tej klasy)

127 Klasy abstrakcyjne C++ Brak tworzenia obiektów tej klasy w kodzie Operacje abstrakcyjne muszą być zdefiniowane w każdej ze specjalizacji, której obiekty będą tworzone class CStudent {... virtual CGrupa* PodajGrupe () = 0; }

128 Klasy abstrakcyjne Java, C# abstract class Student {... } albo abstract class Student {... abstract CGrupa podajgrupe (); }

129 Interfejsy (interfaces) Zbiór operacji (deklaracji metod) Przypomina klasę zawierającą wyłącznie operacje abstrakcyjne Może zawierać stałe

130 Interfejsy w C++ Nie wspierane? class CObiektGraficzny { public: virtual void Rysuj () = 0; }

131 Interfejsy w Javie interface IObiektGraficzny { } void rysuj (); Implementacja interfejsu class Rysunek implements IObiektGraficzny {... } public void rysuj ();

132 Interfejsy w C# interface IObiektGraficzny { void Rysuj(); } Implementacja interfejsu class Rysunek: IObiektGraficzny {... public void Rysuj(); }

133 Związki klas Ogólnie dowolny sposób pozwalający na przechowanie informacji o powiązanych obiektach Np. tablica zawierająca pary powiązanych obiektów Kolo naukowe Pracownik K. Informatyki Nowak K. Fizyki Kamiński K. Chemii Zieliński

134 Związki klas Najczęściej dodatkowe pola przechowujące informacje o powiązanych obiektach Każdy obiekt klasy Pracownik będzie przechowywał informacje o powiązanym obiekcie (dowolnej liczbie) klasy Kolo naukowe Każdy obiekt klasy Kolo naukowe będzie przechowywał informacje o powiązanych obiektach (dokładnie jednym jednym) klasy Pracownik

135 Sposób przechowywania informacji o powiązanych obiektach Identyfikatory (np. nazwy) Wskaźniki/referencje

136 Związki w C++ Najczęściej wskaźniki class CPracownik {... protected: vector <CKoloNaukowe*> rkolonaukowe; } class CKoloNaukowe {... protected: CPracownik* rpracownik; }

137 Związki w C++ Krotność 1 Wskaźnik, który musi wskazywać na powiązany obiekt Krotność 0..1 Wskaźnik, który może mieć wartość NULL Krotność *, 1..* Klasa vector (biblioteka STL) dla 1..* nie może być pusty Tablica wskaźników Inna struktura danych

138 Związki w Javie Najczęściej referencje i ich kolekcje class Pracownik {... protected Vector rkolonaukowe; // lub protected KoloNaukowe[] rkolonaukowe; } class KoloNaukowe { }... protected Pracownik pracownik;

139 Związki w Javie Krotność 1 Referencja, która musi wskazywać na powiązany obiekt Krotność 0..1 Referencja, która może mieć wartość NULL Krotność *, 1..* Obiekt klasy z biblioteki standardowych struktur danych Javy dla 1..* nie może być pusty Tablica referencji Inna struktura danych

140 Związki w C# Najczęściej referencje i ich kolekcje jak w Javie class Pracownik {... protected List<KoloNaukowe> rkolonaukowe; // lub protected KoloNaukowe[] rkolonaukowe; } class KoloNaukowe { }... protected Pracownik pracownik;

141 Związki w C# Krotność 1 Referencja, która musi wskazywać na powiązany obiekt Krotność 0..1 Referencja, która może mieć wartość NULL Krotność *, 1..* Obiekt klasy z biblioteki standardowych struktur danych.net (ArrayList, List<>) dla 1..* nie może być pusty Tablica referencji Inna struktura danych

142 Wykorzystanie nazw ról w związkach class CKoloNaukowe {... protected: CPracownik* ropiekun; } class KoloNaukowe {... protected Pracownik opiekun; }

143 Związki skierowane class CPracownik {... } Brak informacji o powiązanych obiektach klasy Kolo naukowe class CKoloNaukowe {... protected: CPracownik* rpracownik; }

144 Związek kompozycji (composition) W zasadzie na poziomie implementacji nierozróżnialne od związków zwykłych Często obiekt będący całością jest odpowiedzialny za przechowywanie swoich składowych (dodawanie, usuwanie)

145 Związek kompozycji (composition) W C++ czasami wykorzystanie obiektów zamiast wskaźników class CWydzial {... protected: vector <CInstytut> rinstytut; }

146 Diagramy sekwencji Wywoływanie metod w programie Podstawa implementacji metod

147 Wywołanie metody (call) void CRysunek::Rysuj () { }... olinia.rysuj ();...

148 Dla powiązanych obiektów w C++ void CRysunek::Rysuj () { }... rlinia->rysuj ();...

149 Czy wywołanie w pętli? Wnioskowanie z diagramu klas Sequence text, np. * Komentarz Brak nazwy obiektu

150 Tworzenie i usuwanie obiektów w C++ void CKlient::PobierzDane () { }... opolaczenie = new CPolaczenie ();... opolaczenie->odczytaj (...);... delete opolaczenie;...

151 Tworzenie i usuwanie obiektów w Javie public class Klient {... void pobierzdane () {... Polaczenie polaczenie = new Polaczenie ();... polaczenie.odczytaj (...);... }... }

152 Dostęp do pól Operacje: Pobierz dane / Get data Ustaw dane / Set data Pobierz pole / Get field Ustaw pole / Set field Mogą być implementowane jako odczyt/zapis pól

153 Dostęp do pól i samowywołanie void CRysunek::Rysuj () { }... RysujLinie (rlinia->punkty);... Samowywołanie Pobranie danych

154 Wywołania pochodzące z zewnątrz Klasa interfejsowa =

155 Operacje wirtualne (polimorficzne)

156 Operacje wirtualne W Javie domyślnie W C++ i C# virtual void Rysuj ();

157 Punkt widzenia klasy Rysunek Czy poprawne w UML dla klasy abstrakcyjnej?

158 Rzeczywiste wywołania metod dla obiektów

159 Ilustracja efektu operacji wirtualnej W rzeczywistości ta metoda nie istnieje

160 Diagramy stanów

161 Zmiany stanów w metodach void CArtykul::OcenaZakresu (TZakres Zakres) { } if (Stan == _NOWY) { } else if (Zakres == _ZGODNY) else Stan = _ZAAKCEPTOWANY_DO_RECENZJI; Stan = _NIEODPOWIEDNI; // Niepoprawne...

162 Akcje/operacje -> metody (fragmenty metod)... if (Zakres == _ZGODNY) Stan = _ZAAKCEPTOWANY_DO_RECENZJI; } else { } Stan = _NIEODPOWIEDNI; PowiadomAutora ();

163 Akcje/operacje -> metody (fragment metody) void CArtykul::Monitoruj () { if (Stan == _U_RECENZENTA) {... } }

164 Do zobaczenia 22 marca 速