Inżynieria oprogramowania

Podstawowe cele i forma wykładu

Wprowadzenie do profesjonalnego tworzenia oprogramowania w ujęciu obiektowym. Wykład jest prowadzony metodą case study z położeniem nacisku na metody analizy i projektowania.

Metody i formy oceny

Egzamin w formie testu wielokrotnego wyboru po zakończeniu wykładu

1. Strukturalne i obiektowe podejście do tworzenia oprogramowania.

2. Historyczny podział na etapy tworzenia oprogramo- wania zorientowanego obiektowo. Cykle życia systemu informatycznego. Iteracyjny i przyrostowy proces tworzenia systemu informatycznego.

3. Metody zarządzania projektem informatycznym.

Przykłady - model kaskadowy i prototypowanie błyskawiczne.

4. Programowanie ekstremalne.

5. Modelowanie obiektowe. Dziedzina problemu i zakres obowiązków systemu – przykłady. Rozkład zobowiązań w modelowanym systemie informatycznym. Weryfikacja klas i obiektów.

6. Pojęcie klasy i obiektu. Paradygmaty programowania obiektowego. Hermetyzacja. Struktura definicji klasy:

atrybuty i usługi; składowe prywatne, publiczne i chronione; interfejs klasy. Dziedziczenie klas. Hierarchie klas. Abstrakcyjne klasy bazowe. Dziedziczenie i polimorfizm.

Nazwa przedmiotu: Inżynieria oprogramowania ^Egz.

Liczba godzin: 20 godz. wykładu

7. Budowa modeli analitycznych – język UML 8. Modelowanie przypadków użycia

9. Tworzenie modelu dziedziny - diagram klas.

10. Modelowanie dynamiki – diagramy interakcji i współdziałania,

11. Wzorce (szablony) funkcji i klas,

12. Korzystanie z bibliotek – standardowa biblioteka wzorców STL

13. Kontenery, algorytmy i funktory Literatura podstawowa:

1. Materiał ilustracyjny do wykładu, umieszczony w portalu http://edu.ics.p.lodz.pl/ Politechniki Łódzkiej,

2. Martin Fowler, Kendall Scott: UML w kropelce, LPT, 2002

Literatura uzupełniająca:

1. G. Booch, J. Rumbaugh, I. Jacobson: UML przewodnik użytkownika, WNT, 2002

2. Stanley B. Lippman: Model obiektu w C++, WNT, 2001 Już w latach sześćdziesiątych zauważono, że przebieg procesu tworzenia oprogramowania informatycznego podlega takim samym regułom, jak tworzenie dowolnego urządzenia np.

samochodu. Z tego też względu zaczęto mówić o stosowaniu tzw. Inżynierii Oprogramowania (Software Engineering).

Dwa podejścia do tworzenia oprogramowania:

- podejście strukturalne (proceduralne), - podejście obiektowe (object oriented).

Historyczne podział na etapy tworzenia oprogramowania zorientowanego obiektowo (lata 90-te):

- analiza obiektowa (OOA),

- projektowanie obiektowe (OOD), - programowanie obiektowe (OOP).

Na etapie analizy i projektowania obiektowego używany jest język UML (Unified Modeling Language), który od 1999 roku jest oficjalnym standardem w ramach OMT (ang. Object Management Group).

Aktualne podejście do tworzenia oprogramowania charakteryzuje:

- zacieranie podziałów między etapami analizy, projektowania i implementacji,

- rozdział w metodyce tworzenia systemów informatycznych korporacyjnych (opartych na platformach typu: Windows, Unix, OS )i systemów WEB-owych (opartych o Internet),

- ciągle wzrastający udział i specjalizacja gotowych komponentów w procesie tworzenia oprogramowania, - stosowanie wzorców projektowych.

Model kaskadowy i prototypowanie błyskawiczne

Podział procesu tworzenia systemu informatycznego określany jest mianem cyklu życia systemu. Poniżej przedstawione zostaną wybrane modele cyklu życia systemu informatycznego:

- model kaskadowy,

- prototypowanie błyskawiczne, - programowanie ekstremalne.

Model kaskadowy

przekazanie

Rys. 1

Model KASKADOWY cyklu życia systemu

Ścisła interpretacja modelu kaskadowego traktuje poszczególne fazy jako niezależne okresy realizacji przedsięwzięcia. Według tej interpretacji okresy te nie nakładają się na siebie, zaś ich wykonanie przebiega sekwencyjnie, bez procesów iteracyjnych.

W rzeczywistości proces ten musi mieć charakter iteracyjny (w postaci powrotów do wcześniejszych faz modelu w przypadku wykrycia błędów powstałych w tychże fazach) i przyrostowy (w każdej fazie nawrotu następuje wzbogacenie modelu).

Do zalet modelu kaskadowego należy zaliczyć:

 Łatwość zarządzania przedsięwzięciem,

 Łatwość harmonogramowania poszczególnych etapów,

 Łatwość określenia kosztów całego przedsięwzięcia,

 Łatwość tworzenia dokumentacji.

Analiza Analiza

Projektowanie Projektowanie

Implementacja Implementacja

Testowanie Testowanie

Konserwacja Konserwacja

Wadami tego modelu są;

 Wysoki koszt błędów popełnionych we wstępnych fazach projektu (błędy z fazy analizy i projektowania mogą wyjść na jaw dopiero w fazie testowania lub konserwacji)

 Długa przerwa w kontaktach z klientem (od określenia wymagań – do przekazania).

Prototypowanie błyskawiczne

przekazanie

Rys. 2

Prototypowanie błyskawiczne

Model prototypowy cyklu życia systemów powstał jako antidotum na jedną z najbardziej „bolesnych” wad modelu kaskadowego – duże koszty błędów popełnionych w fazie analizy wymagań, co ma miejsce zwłaszcza w przypadku nowatorskich i złożonych systemów.

W modelu prototypowym wyróżnia się następujące fazy:

 Ogólne określenie wymagań,

 Budowa prototypu pierwszego,

 Weryfikacja prototypu przez klienta, (!!!)

 Budowa kolejnego prototypu,

 . . .

 Przekazanie systemu klientowi,

 Dalsze doskonalenie systemu,

 . . .

Prototyp 1 Prototyp

1 Prototyp

2 Prototyp

2 Prototyp

N Prototyp Prototyp N

N-1 Prototyp

N-1

Głównym celem budowy prototypów jest lepsze określenie wymagań, realizowane poprzez:

 Wykrycie nieporozumień pomiędzy klientem a twórcami systemu,

 Wykrycie brakujących i trudnych usług.

Prócz tego pojawiają się dodatkowe zalety budowy prototypów:

 Możliwość szybkiej demonstracji pracującej wersji systemu,

 Możliwość szkoleń, zanim zbudowany zostanie pełen system.

Model ten posiada oczywiście swoje wady. Zaliczyć do nich należy:

 Dodatkowo ponoszony i trudny do określenia koszt budowy prototypów,

 Trudny do określenia moment zakończenia całego przedsięwzięcia (bardzo często proces ten nigdy się nie kończy),

 Pewne zaskoczenie klienta, który musi długo czekać na odbiór systemu, którego „prawie całkowite” wykonanie (demonstrowany prototyp) zajęło tak mało czasu.

Prototypowanie błyskawiczne jest często łączone z nasilonym korzystaniem z gotowych komponentów.

Przedstawione dwie metodyki (model kaskadowy i prototypowanie błyskawiczne), stoją jak gdyby na dwóch przeciwstawnych sobie biegunach koncepcji tworzenia oprogramowania i w rzeczywistości żadne z nich w tak czystej postaci nie jest stosowane. Dodatkowo ostatnio pojawiło się

odbiegające jeszcze dalej od prototypowania błyskawicznego podejście, zwane programowanie ekstremalnym.

Programowanie ekstremalne (eXtreme Programming - XP) Ogólnie, podejście to, które pojawiło się w 1999 roku, charakteryzuje:

 Stawianie programisty, a nie analityka systemowego i projektanta, w centrum zainteresowania,

 Korzystanie z tzw. wzorców projektowych (nazwa jest myląca, są to bowiem wzorce na poziomie kodu, a nie projektu), przykłady wzorców projektowych: wzorzec fasady, fabryka abstrakcyjna

 Uznanie kodu za dokumentację projektu,

 Ścisła współpraca programistów z przyszłym użytkownikiem.

Podejście to ma wiele cech prototypowania błyskawicznego, zatarła się jednak granica między poszczególnymi prototypami. Było to możliwe dzięki:

 Rozwojowi metodyki obiektowej, co wyraziło się opracowaniem wielu bibliotek wzorców obiektowych, w tym wielu wzorców projektowych,

 Pojawieniu się nowych metodyk w zakresie architektury oprogramowania, jak: refaktoryzacja, czy transformacje architektury oprogramowania,

 Rozwój i wzrost znaczenia metodyk testowania, na przykład Test - Driven Development(TDD) – programowanie sterowane testami,

Stosuje się tu, mniej lub bardziej świadomie, czteroetapowy model sukcesu:

1. Określ cel, 2. Wykonaj działanie, 3. Odbierz informację zwrotną,

4. Skoryguj działanie tak, aby kolejny efekt był bliższy sukcesowi.

Fasadę dla XP tworzą, również cztery, główne wartości:

1. Komunikacja w zespole (do stałej praktyki należy programowanie w parach) i komunikacja z klientem, 2. Prostota (stałe utrzymywanie przejrzystości i spójności

projektu),

3. Informacja zwrotna (informacje te programiści uzyskują zarówno od klienta, jak i na podstawie wyników przeprowadzanych testów),

4. Odwaga w podejmowaniu i wdrażaniu kluczowych decyzji, wynikająca z wysokiego profesjonalizmu, przy pełnej świadomości odpowiedzialności za podjęte decyzje.

Modelowanie obiektowe

Dziedzina problemu jest słownikiem zawierającym wyłącznie te pojęcia, które wiążą się ściśle z założonymi celami. Tak skonstruowany słownik zawierać więc będzie nazwy najważniejszych klas w przyszłym systemie informatycznym.

Abstrahowanie pojęć w trakcie tworzenia definicji klas nie może odbywać się w oderwaniu od celu, którym jest stworzenie konkretnego, wykonującego określone obowiązki, systemu informatycznego.

Zakres obowiązków systemu jest dość ogólną, ale kompletną specyfikacją czynności realizowanych przez moduł systemu informatycznego.

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 ruch pacjentów w szpitalu:

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

Ogólny schemat definicji klasy

Klasa jest typem danych, abstrahującym z rzeczywistości pewien zbiór obiektów, dających się opisać za pomocą tych samych danych przy użyciu tych samych metod ich obsługi.

Przykład graficznej wizualizacji klasy w języku UML

Nazwa klasy

Atrybuty (parametry, dane składowe, pola)

Metody (usługi, funkcje składowe, operacje)

DATA

Dzien : integer Miesiac : integer Rok : integer ustaw ( ) pobierz ( ) nast ( ) drukuj ( )

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

Każdy obiekt jest konkretną egzemplifikacją klasy, tak jak w klasycznym ujęciu - zmienna jest egzemplifikacją typu.

Jednocześnie każdy obiekt jest składową dziedziny problemu i posiada:

 tożsamość (konkretną nazwę),

 stan (zbiór wartości atrybutów),

 zachowanie (metody).

Korzyści wynikające z podejścia obiektowego:

 łatwość rozbudowy i testowania oprogramowania,

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

Paradygmaty programowania obiektowego:

 hermetyzacja (kapsułkowanie)

 dziedziczenie

 polimorfizm Przykład:

1. Podejście proceduralne struct DATA

{ int dzień, miesiąc, rok; }; // definicja typu danych ...

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 * );

To podejście skazane jest na rozdzielenie kodu: definicji typów, deklaracji zmiennych i procedur obsługi tych struktur danych. Każda zmiana któregokolwiek z tych elementów wymaga sprawdzenia i ewentualnych korekt w pozostałych.

2. Podejście obiektowe class DATA

{ int dzień, miesiąc, rok;

public:

void ustaw( int, int, int);

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

void nast( void);

void drukuj( void );

};

...

DATA dzisiaj;

// deklaracja zmiennej (obiektu) klasy DATA Sekcja prywatna, chroniona i publiczna klasy class < nazwa klasy >

{ private:

...

protected:

...

public:

...};

o Atrybuty obiektów klasy są (w powyższym przykładzie)

prywatne (private) i mogą być obsługiwane tylko przez własne metody klasy.

o Składowe chronione (protected) będą dostępne tylko w obiektach klas, które dziedziczą z danej klasy.

o Metody zadeklarowane w części publicznej definicji klasy (public) są dostępne z zewnątrz klasy (mogą być wywoływane przez metody innych klas, lub funkcje zewnętrzne), stanowią więc interfejs do obiektów klasy.

Mówiąc bardziej szczegółowo metody publiczne służą do:

- sterowania obiektem, - zmiany jego stanu,

- sterowania obiektami innych typów (komunikaty)

 Funkcje prywatne klasy mają dostęp ograniczony tylko do atrybutów obiektu własnej klasy i nie są dostępne z zewnątrz klasy. Pełnią one jednak ważną rolę w tak zwanych obiektach aktywnych.

 Wartości atrybutów obiektu są zawsze określone. W ten sposób każdy obiekt zawsze znajduje się w pewnym stanie, wyznaczonym przez zespół wartości jego atrybutów.

Poszczególne obiekty mogą być modyfikowane niezależnie od siebie przez te same, upoważnione do ich modyfikacji funkcje.

 Wszystko, co obiekt "wie" jest wyrażone przez jego atrybuty. Wszystko co obiekt może zrobić, lub co z nim można zrobić, jest zawarte w funkcjach klasy, do której obiekt należy. Jednocześnie wszystko, co nie istotne na zewnątrz obiektu, jest ukryte w jego wnętrzu i niedostępne z zewnątrz. Obiekty mogą oddziaływać na siebie wyłącznie za pomocą komunikatów, które polegają na wywołaniu metod innych klas.

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.

o Wybór właściwych klas w modelu jest w znacznym stopniu subiektywny.

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

". . . trzeba stale pamiętać o podstawowych pojęciach, aby nie zagubić się w szczegółach technicznych.

Skupianie się na szczegółach może bardzo rozproszyć i przyczynić się do niepełnego wykorzystania możliwości języka [programowania]. Wszak nie powinno się uczyć obcego języka ze słownika i opisu gramatyki !"

[ Bjarne Stroustrup ]

Rozkład zobowiązań w modelowanym systemie

Ilościowy rozkład zobowiązań dla poszczególnych klas powinien w modelowanym systemie być taki, aby poszczególne klasy obejmowały porównywalne względem siebie ilości atrybutów i usług. Poniższy rysunek przedstawia poglądowo jako niedopuszczalne modele 1 i 3.

MODEL 1 – każde dana jest klasą ( klasy są jednopolowe )

MODEL

1 MODEL

2

MODEL3

MODEL 2 – model opcjonalny (ze zrównoważonym rozkładem zobowiązań)

MODEL 3 – model z jedną tylko klasą = model strukturalny

Modele 1 i 3 są nie do przyjęcia.