Inżynieria oprogramowania część I

Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne

Semestr letni 2014/2015

dr inż. Bartłomiej Prędki

Bartlomiej.Predki@cs.put.poznan.pl

Pok. 124 CW, tel. 61665 2932

http://zajecia.predki.com

Literatura❖ A. Jaszkiewicz, Inżynieria oprogramowania, Helion, Gliwice, 1997.

❖ B. Begier, Inżynieria oprogramowania – problemy jakości, Wydawnictwo Politechniki Poznańskiej, Poznań, 1999.

❖ 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, 2000.

❖ C. Larman, UML i wzorce projektowe., Helion 2011

❖ D. Hamlet, J. Maybee, Podstawy techniczne inżynierii oprogramowania, WNT 2003

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

Rynek oprogramowania 2011

❖ Świat 292.9 miliardów dolarów (42.6% Ameryka)

❖ Bez oprogramowania wytwarzanego na własne potrzeby

❖ Wzrost 6.6% rocznie

❖ + 125 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

Rynek oprogramowania

Rynek oprogramowania

Rynek oprogramowania

Najwięksi gracze

❖ IBM

❖ Microsoft

❖ Oracle

❖ SAP

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

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

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)

Zależność osiągnięcia-oczekiwania w wytwarzaniu oprogramowania

Czas

Efekty

Rzeczywiste osiągnięcia

Oczekiwania

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

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

Początek inżynierii oprogramowania

1968

NATO Conference on Software Engineering

Podejście amatorskie a inżynierskie

Co by tu wymyślić!? Do pracy.

Definicje inżynierii oprogramowania

❖ Duże systemy wymagające pracy wielu osób – praca grupowa

❖ Wielowersyjność oprogramowania

Definicja inżynierii oprogramowania

Wiedza techniczna, dotycząca wszystkich

faz cyklu życia oprogramowania, której

celem jest uzyskanie wysokiej jakości

produktu - oprogramowania.

Jakość oprogramowania

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

Zakres inżynierii oprogramowania

❖ Wytwarzanie oprogramowania i innych

produktów (np. dokumentacji)

❖ Zarządzanie wytwarzaniem

oprogramowania

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

Zaliczenie

Wykład jest zaliczany w trakcie testuna ostatnim wykładzie,czyli 27 kwietnia 2014 r.

Modele cyklu życia oprogramowania

❖ Uporządkowanie prac.

❖ Ustalenie kolejności prac.

❖ Planowanie i monitorowanie realizacji.

Programowanie odkrywcze

Ogólne określenie wymagań

Ogólny projekt

Budowa systemu

Ocena systemu

System poprawnyWdrożenie

Tak Nie

Model kaskadowy

Określenie wymagań

Projektowanie

Implementacja

Testowanie

Konserwacja

Dodatkowe fazy w modelu kaskadowym

Ścisłe i elastyczne rozumienie modelu kaskadowego

Określenie wymagań

Projektowanie

Implementacja

Testowanie

Konserwacja

Przykład elastycznego podejścia do modelu kaskadowego

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 100-1000 razy większy od kosztu błędu programistycznego!

-Długa przerwa w kontaktach z klientem

-Nie lubiany przez wykonawców

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.

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.

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.

Realizacja przyrostowaOkreślenie wymagań i wstępny

projekt

Wybór przyrostu - podzbioru

funkcji

Realizacja przyrostu

Wdrożenie przyrostu

Proces realizowany iteracyjnie

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.

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)

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

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

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

Analiza/modelowanie

❖ Opracowanie logicznego modelu dziedziny problemu

❖ Cele:

❖ Lepsze zrozumienie dziedziny problemu i lepsze określenie wymagań

❖ Podstawa przyszłego projektu

Dziedzina problemu

Wp

System

Dziedzina problemu

Wp

Model

Dlaczego notacje graficzne w modelowaniu

❖ Ogromny wzrost precyzji

❖ Ogromna poprawa efektywności

❖ Zapis modelu

❖ Analiza modelu

❖ Wprowadzanie zmian

❖ Łatwe przejście do projektowania

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)

Korzystanie z funkcji (ang. actor flow)

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

Przykład i związek generalizacji (generalization)

Diagramy klas

❖ Model statyczny

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

KlasaWzorzec, uogólnienie grupy obiektów opisywanych za pomocą podobnych danych i mających podobne zachowanie

Samochody

Związek generalizacji-specjalizacji

Wp

Samochód osobowy

Samochód ciężarowy

SamochódPojazd

Wiele generalizacji

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

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

Przykłady

Opisy związków

Rola Nazwa

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

Związek pomiędzy obiektami tej samej klasy

Ograniczenia dotyczące związków

Związek kompozycji

Przykład - giełda usług przewozowych

Przykład – grafika wektorowa

Przykład – czasopismo naukowe

Diagramy stanów

❖ Model dynamiczny

❖ Zastosowania:

❖ Modelowanie zmian stanów (grup) obiektów

❖ Modelowanie reakcja na zdarzenia

❖ Modelowanie algorytmów

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.

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.

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)

Stany początkowy i końcowy

Początkowy

Końcowy

Przejście

❖ Zmiana stanu w wyniku zdarzenia

❖ Może być obwarowane warunkami

❖ Zachodzi natychmiastowo (w przybliżeniu)

Zdarzenia Warunek

Akcja

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

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.

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

=

Stan złożony

Przykład – stany artykułu

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

Diagramy sekwencji

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

Obiekt

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.

Lina życia

Czas

Komunikaty

AsynchronicznySynchroniczny

Przykład – korzystanie z bankomatu

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

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ść

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

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.

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

Algorytm klasyfikacji na podstawie reguł decyzyjnych

powtarzaj od reguły najważniejszej do najmniej ważnejjeż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ą

Budowa statycznego modelu klas

❖ Identyfikacja klas

❖ Identyfikacja związków klas

❖ Identyfikacja pól

❖ Identyfikacja metod

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,

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.

Identyfikacja klas

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

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

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.

Przykład

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?

Identyfikacja klas

❖ Analiza funkcji

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

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.

Identyfikacja krotności związków

Analiza przykładowych (rzeczywistych lub wymyślonych) powiązań obiektów

Weryfikacja związków obligatoryjnych np. 1 lub 1..*

Czy instytut musi mieć pracowników?

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

Części składowe

Zbiory

Identyfikacja związków generalizacji-specjalizacji

Dziedziczenie pól i metod

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

Identyfikacja związków generalizacji-specjalizacji

❖ Pola, którym nie zawsze można przypisać wartości

❖ Metody, które nie zawsze mają sens

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

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

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?

Przykład

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

UML a kod w C++ i Javie

❖ Projektowanie oprogramowania

❖ Dokumentowanie oprogramowania

Diagramy przypadków użycia

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

Przypadki użycia

❖ Funkcje systemu

❖ Elementy interfejsu użytkownika

❖ menu, podmenu, polecenia w menu

❖ dialogi

Związki pomiędzy przypadkami użycia

❖ Struktura menu

❖ Polecenia dostępne w dialogach, np. wywoływanie innych dialogów

❖ Kreatory (creators, wizards)

Diagramy klas

❖ Bezpośrednie przełożenie na kod

❖ Wiele dodatkowych elementów wykorzystywanych na etapie projektowania

Klasa

class Pojazd {...}

class CStudentDzienny {...}

Nazwy - prefixy, suffixy, zamiana spacji i niedozwolonych znaków

Pola C++class CPojazd {

... ... Nazwa;

... CenaKilometra; ... CenaGodziny;

}

class CPojazd { protected:

char* Nazwa; double CenaKilometra; double CenaGodziny;

}

Na przykład:

Pola Java, C#class Pojazd { ... nazwa;

... cenaKilometra; ... cenaGodziny;

}

class CPojazd { protected String nazwa;

protected double cenaKilometra; protected double cenaGodziny;

}

Na przykład:

Symbole widoczności pól i operacji

+ public – publiczne# protected – zabezpieczone/chronione- private – prywatne ~ - w ramach pakietu

class CPojazd { public: ... Nazwa; protected: ... CenaKilometra; private: ... CenaGodziny; }

C++

class Pojazd { public ... nazwa; protected ... cenaKilometra; private ... cenaGodziny; }

Java, C#

Typy pól

Operacje i metody C++

class CPojazd { ... public: ... Koszt (...); }; ...

... CPojazd::Koszt (...) { ... }

Operacje i metody Java, C#

class Pojazd { ... public ... koszt (...) { ... } }

Nagłówki operacji C++

class CPojazd { ... public: double Koszt (double Czas, double Droga); }; ... double CPojazd::Koszt (double Czas, double Droga) { ... }

Nagłówki operacji Java, C#

class Pojazd {... public double koszt (double czas, double droga) { ... } }

Generalizacja-specjalizacjaclass CStudentDzienny : public CStudent { ... }

C++

class StudentDzienny extends Student { ... }

Java

class StudentDzienny: Student { ... }

C#

Klasy abstrakcyjnePochyła czcionka

Klasy nie posiadające obiektów (bezpośrednio tej klasy)

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;

}

Klasy abstrakcyjne Java, C#abstract class Student {

...

}

abstract class Student {

...

abstract CGrupa podajGrupe ();

}

albo

Interfejsy (interfaces)

❖ Zbiór operacji (deklaracji metod)

Przypomina klasę zawierającą wyłącznie operacje abstrakcyjne

Może zawierać stałe

Interfejsy w C++

❖ Nie wspierane?

class CObiektGraficzny {

public:

virtual void Rysuj () = 0;

}

Interfejsy w Javieinterface IObiektGraficzny {

void rysuj ();

}

Implementacja interfejsu

class Rysunek implements IObiektGraficzny {

...

public void rysuj ();

}

Interfejsy w C#interface IObiektGraficzny {

void Rysuj();

}

Implementacja interfejsuclass Rysunek: IObiektGraficzny

{

...

public void Rysuj();

}

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

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

Sposób przechowywania informacji o powiązanych obiektach

❖ Identyfikatory (np. nazwy)

❖ Wskaźniki/referencje

Związki w C++

❖ Najczęściej wskaźniki

class CPracownik {

...

protected:

vector <CKoloNaukowe*> rKoloNaukowe;

}

class CKoloNaukowe {

...

protected:

CPracownik* rPracownik;

}

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

Związki w Javie

❖ Najczęściej referencje i ich kolekcje

class Pracownik { ... protected Vector rKoloNaukowe; // lub protected KoloNaukowe[] rKoloNaukowe; }

class KoloNaukowe {

...

protected Pracownik pracownik;

}

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

Związki w C#

❖ Najczęściej referencje i ich kolekcje jak w Javieclass Pracownik { ... protected List<KoloNaukowe> rKoloNaukowe; // lub protected KoloNaukowe[] rKoloNaukowe; }

class KoloNaukowe {

...

protected Pracownik pracownik;

}

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

Wykorzystanie nazw ról w związkach

class CKoloNaukowe {

...

protected:

CPracownik* rOpiekun;

}

class KoloNaukowe {

...

protected Pracownik opiekun;

}

Związki skierowane

class CPracownik {

...

}

class CKoloNaukowe {

...

protected:

CPracownik* rPracownik;

}Brak informacji o powiązanych obiektach klasy Kolo naukowe

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)

Związek kompozycji (composition)

❖ W C++ czasami wykorzystanie obiektów zamiast wskaźników

class CWydzial {

...

protected:

vector <CInstytut> rInstytut;

}

Diagramy sekwencji

❖ Wywoływanie metod w programie

❖ Podstawa implementacji metod

Wywołanie metody (call)

void CRysunek::Rysuj () {

...

oLinia.Rysuj ();

...

}

Dla powiązanych obiektów w C++

void CRysunek::Rysuj () {

...

rLinia->Rysuj ();

...

}

Czy wywołanie w pętli?Wnioskowanie z diagramu klas

Komentarz

Sequence text, np. „*”

Braknazwyobiektu

Tworzenie i usuwanie obiektów w C++

void CKlient::PobierzDane () {

...

oPolaczenie = new CPolaczenie ();

...

oPolaczenie->Odczytaj (...);

...

delete oPolaczenie;

...

}

Tworzenie i usuwanie obiektów w Javie

public class Klient {

...

void pobierzDane () {

...

Polaczenie polaczenie = new Polaczenie ();

...

polaczenie.odczytaj (...);

...

}

...

}

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

Dostęp do pól i samowywołanie

void CRysunek::Rysuj () {

...

RysujLinie (rLinia->Punkty);

...

}

Pobranie danychSamowywołanie

Wywołania pochodzące z zewnątrz

=

Klasa interfejsowa

Operacje wirtualne (polimorficzne)

Operacje wirtualne

❖ W Javie domyślnie

❖ W C++ i C#

virtual void Rysuj ();

Punkt widzenia klasy Rysunek

Czy poprawne w UML dla klasy abstrakcyjnej?

Rzeczywiste wywołania metod dla obiektów

Ilustracja efektu operacji wirtualnej

W rzeczywistości ta metoda nie istnieje

Diagramy stanów

Zmiany stanów w metodachvoid CArtykul::OcenaZakresu (TZakres Zakres) {

if (Stan == _NOWY) {

if (Zakres == _ZGODNY)

Stan = _ZAAKCEPTOWANY_DO_RECENZJI;

else

Stan = _NIEODPOWIEDNI;

}

else

// Niepoprawne

...

}

Akcje/operacje -> metody (fragmenty metod)

...

if (Zakres == _ZGODNY)

Stan = _ZAAKCEPTOWANY_DO_RECENZJI;

else {

Stan = _NIEODPOWIEDNI;

PowiadomAutora ();

}

}

Akcje/operacje -> metody (fragment metody)

void CArtykul::Monitoruj () {

if (Stan == _U_RECENZENTA) {

...

}

}

Do zobaczenia 22 marca

速