„Inżynieria oprogramowania I ” sem. III 28 w. + 28 lab.

Podstawowe cele

Wprowadzenie do profesjonalnego tworzenia oprogramowania w ujęciu obiektowym.

Podstawy programowania obiektowego: hermetyzacja, konstruktory i destruktory, konstruktory kopiujące, obiekty automatyczne, dynamiczne i statyczne.

Analiza obiektowa OOA: Dziedzina problemu i zakres obowiązków systemu. Pięciowarstwowy model analizy - klasy i obiekty, struktura klas, atrybuty klas, warstwa tematów, warstwa usług i komunikatów.

Dziedziczenie klas. Rodzaje dziedziczeń. Kontrola zakresu dostępu. Polimorfizm składowych. Zasłanianie, przeciążanie i przywracanie zakresu dostępu składników klasy. Dziedziczenie wielobazowe. Dziedziczenie wirtualne.

Drugorzędne cechy klas: Składowe statyczne. Obiekty stałe i ulotne. Funkcje uprzywilejowane. Zagnieżdżanie obiektów. Funkcje i klasy zaprzyjaźnione. Obiekty trwałe.

Operatory i ich przeciążenie (Funkcje operatorowe).

Przykłady reprezentacji obiektów: tablica asocjacyjna, klasy-iteratory, klasy-uchwyty i klasy-kontrolery. Klasy abstrakcyjne i interfejsy.

Szablony funkcji i klas. Obsługa błędów i wyjątków.

Inżynieria oprogramowania: modelowanie struktury klas, modelowanie dynamiki obiektów. Standaryzacja modelowania obiektowego UML.

Literatura:

1. Bjarne Stroustrup: Język C++, WNT, 1994-2000

2. Edward Yourdon Carl Argila: Analiza obiektowa
   i projektowanie - przykłady zastosowań, WNT, 2000

3. Andrzej Jaszkiewicz: Inżynieria oprogramowania, Helion, 1997

4. Mariusz Kaliszewski: Inżynieria oprogramowania obiektowego, Respekt, 1994

Jak się uczyć ?

Cytaty [ Bjarne Stroustrup ]

"Główna trudność, a zarazem przyjemność i zysk, tkwi w nabyciu biegłości w stosowaniu nowych technik projektowania ..."

"Projektowanie i programowanie obiektowe, to zajęcie praktyczne, a nie teoretyczne. Koncepcje stosowane tylko na przykładach modelowych mogą stać się niebezpiecznymi 'religiami'."

"Ucząc się języka C++ trzeba stale pamiętać o podstawowych pojęciach, aby nie zagubić się w szczegółach technicznych języka. Skupianie się na szczegółach może bardzo rozproszyć i przyczynić się do niepełnego wykorzystania możliwości języka. Wszak nie powinno się uczyć obcego języka ze słownika i opisu gramatyki !"

"Dopóki uczeń nie zrozumie istoty abstrakcyjnych typów danych i programowania obiektowego, dopóty jedynym skutkiem będzie niewłaściwe 'barokowe' użycie właściwości języka ..."

"Na ogół kogoś, kto tego nie chce, nie można niczego nauczyć."

Paradygmaty programowania obiektowego:

• hermetyzacja (enkapsulacja)

• dziedziczenie

• polimorfizm

Korzyści:

• łatwość rozbudowy i testowania,

• mała wrażliwość na uszkodzenie kodu.

Przykłady:

1. Podejście proceduralne

struct DATA

{ int dzień, miesiąc, rok; };

............................................................

DATA dzisiaj; // deklaracja zmiennej typu DATA

............................................................

// deklaracje procedur obsługi danych typu DATA

void wstaw_date( DATA *, int, int, int);

void nast_data( DATA * );

void drukuj_date( const DATA * );

2. Podejście obiektowe

1. Niepełne wykorzystanie definicji klasy

struct DATA

{ int dzień, miesiąc, rok;

void ustaw( int, int, int);

void pobierz( int *, int *, int * );

void nast( void);

void drukuj( void );

};

............................................................

DATA dzisiaj, moje_urodziny, data; // deklaracja zmiennych

............................................................

// przykład definicji funkcji

void DATA:: ustaw(int dd, int mm, int yy)

{ dzień = dd; miesiąc = mm; rok = yy; }

DATA:: - kwalifikator zakresu

// przykłady wywołania funkcji składowych na rzecz obiektu

moje_urodziny.ustaw( 30, 12, 1950 );

dzisiaj.drukuj( );

2. Pełne wykorzystanie definicji klasy

class DATA

{ int dzień, miesiąc, rok;

public:

void ustaw( int, int, int);

void pobierz( int *, int *, int * );

void nast( void);

void drukuj( void );

};

Metody zadeklarowane w części publicznej definicji klasy stanowią interfejs do obiektów klasy. Atrybuty obiektów klasy mogą być obsługiwane tylko przez własne metody klasy.

Ogólny schemat definicji i deklaracji obiektów klasy:

class < oznacznik klasy >

{

private:

............................

protected:

............................

public:

............................

} < lista obiektów, wskazań i referencji do obiektów klasy > ;

Specyfikatory sekcji mogą być użyte wielokrotnie w obrębie danej definicji klasy. Nie określenie kwalifikatora dostępu (specyfikatora sekcji) w pierwszej części definicji czyni składowe domyślnie prywat-nymi.

Kwalifikator private (sekcja prywatna) chroni pola obiektów klasy i niektóre funkcje ( o znaczeniu lokalnym) przed użyciem z zewnątrz obiektu. Pola i funkcje umieszczone w sekcji zabezpieczonej (kwali-fikator protected ) będą widoczne poza obiektem klasy wy-łącznie w obiektach klas pochodnych. Pola i funkcje umieszczone w sekcji publicznej (kwalifikator public ) będą widoczne poza obiektami klasy do końca pliku.

Metody publiczne służą do:

- sterowania obiektem, - zmiany jego stanu,

- sterowania obiektami innych typów (komunikaty)

Dziedzina problemu i zakres obowiązków systemu

Obiekt jest składową dzie-

dziny problemu i posiada:

- tożsamość,

- stan,

- zachowanie.

Klasa opisuje możliwie wiernie zbiór obiektów realnego świata w kategoriach konkretnej dziedziny problemu podany z punktu widzenia obowiązków systemu.

Przykłady:

Przykłady dziedzin problemu:

• ruch pacjentów w szpitalu,

• funkcjonowanie obiektu technicznego, np. samochodu, komputera, centrali telefonii komórkowej.

Przykłady obowiązków systemu dla dziedziny działalność szpitala:

1. Przyjęcie pacjenta, 2. Przechowywanie wyników badań laboratoryjnych, 3. Prowadzenie historii chorób, 4. Sporzą-dzenie karty wypisowej.

Pięciowarstwowy model analizy:

• warstwa tematów,

• warstwa klas i obiektów,

• warstwa struktury,

• warstwa atrybutów,

• warstwa usług.

Typowe klasy to:

• przedmioty fizyczne ( osoby, urządzenia techniczne),

• role pełnione przez osoby (kierownik, wykładowca, księgowa)

• zdarzenia ( zakup, rejestracja pojazdu),

• interakcja między osobami lub zdarzeniami ( pożyczka, zamówienie, połączenie telefoniczne),

• organizacja ( bank, szpital, wydział ),

• pojęcie ( jakość produktu ),

• dokumenty ( faktura, prawo jazdy),

• klasy będące interfejsami do systemów zewnętrznych,

• klasy będące interfejsami do użytkowników systemu.

Weryfikacja klas i obiektów:

• nie można określić żadnych pól lub usług jawnych
  → klasa jest zbyteczna,

• pola lub/i metody są pojedyncze → można je schować w innych klasach,

• istnieje tylko jeden obiekt dla klasy → na ogół klasa jest zbyteczna,

• brak związków z innymi klasami → klasa poza zakresem obowiązków systemu.
  

klasa abstrakcyjna

6

Model analizy

Dziedzina problemu

Figura_2D

Narysuj

Ukryj

Punkt_2D

int x, y;

Przesuń

Okrąg

int promień;

Skaluj

Trójkąt

Punkt A, B, C;

Skaluj

Obróć

---