PO Obiektowe modelowanie dziedziny: Różnice pomiędzy wersjami
Linia 35: | Linia 35: | ||
Przykładowy częściowego model dziedziny dla aplikacji wspomagającej rezerwację miejsc i sprzedaż biletów kinowych znajduje się na diagramie. | Przykładowy częściowego model dziedziny dla aplikacji wspomagającej rezerwację miejsc i sprzedaż biletów kinowych znajduje się na diagramie. | ||
[[grafika:po_1_1_przyklad.png|opcjonalny tekst]] |
Wersja z 23:12, 15 lip 2006
Wprowadzenie
Programowanie obiektowe (ang. object-oriented programming) jest obecnie najpopularniejszą techniką tworzenia programów komputerowych. Program komputerowy wyraża się się jako zbiór obiektów będących bytami łączącymi stan (czyli dane) i zachowanie (czyli metody, które są procedurami operującymi na danych obiektu). W celu realizacji zadania obiekty wywołują nawzajem swoje metody zlecając tym samym innym obiektom odpowiedzialność za pewne czynności. W porównaniu z tradycyjny programowaniem proceduralnym, w którym dane i procedury nie są ze sobą związane, programowanie obiektowe ułatwia tworzenie dużych systemów i współpracę wielu programistów. Programy obiektowe łatwiej jest rozwijać i ponownie wykorzystywać ich fragmenty.
Historia programowania obiektowego
Pierwszy język obiektowy – Simula 67 – powstał już w latach sześćdziesiątych ubiegłego stulecia. Jego twórcami byli Ole-Johan Dahl i Kristen Nygaard z Norsk Regnesentral w Oslo. Podczas ich pracy nad symulacją statków musieli dla każdego rodzaju statku uwzględniać wiele atrybutów. Ponieważ liczba modelowanych rodzai statków była duża, uwzględnienie wszystkich możliwych zależności między atrybutami stało się problematyczne. Pojawił się pomysł, aby pogrupować różne rodzaje statków w klasy obiektów. Każda klasa obiektów sama miała być odpowiedzialna za definiowanie swoich danych i zachowania. Simula była pierwszym językiem programowania, w którym wprowadzono pojęcie klasy i jej egzemplarza. Warto tu zwrócić uwagę, że zgodnie z nazwą języka takie odwzorowanie obiektów spotykanych w świecie rzeczywistym na obiekty programowe można nazwać symulacją.
Nie długo potem w laboratorium badawczy Xerox's Palo Alto stworzono Smalltalk. Jego głównym pomysłodawcom był Alan Kay. Smalltalk zawierał wiele rewolucyjnych pomysłów w tym dziedziczenie i zyskał sobie sporą popularność. W pewnej skali był również z powodzeniem stosowany w praktyce. Standardem przemysłowym programowanie obiektowe stało się jednak dopiero w latach dziewięćdziesiątych za sprawą języka C++, który jest obiektowym rozszerzeniem C. Obecnie najpopularniejszym językiem obiektowym i równocześnie najpopularniejszym językiem programowania w ogóle jest Java.
Znajomość języka obiektowego takiego jak Java jest niezbędna, aby zostać programistom obiektowym, jednak zgodnie z powiedzeniem "posiadanie młotka nie czyni architektem" zanim przyjrzymy się konstrukcjom spotykanym w obiektowych językach programowania wyjaśnijmy kilka pojęć i nauczmy się tego co najważniejsze, czyli co to znaczy myśleć obiektowo.
Czemu programowanie obiektowe stało się takie popularne?
Największym atutem programowania obiektowego jest zbliżenie programów komputerowych do naszego sposobu postrzegania rzeczywistości. Często nazywa się to zmniejszeniem luki reprezentacji (ang. representational gap). Wymyślając nowy lub analizując istniejący program obiektowy nasz mózg ma ułatwione zadanie. Dlatego ludzie są w stanie łatwiej zapanować nad kodem i tym samym tworzyć większe programy. Łatwiej jest również zrozumieć kod i pomysły innych programistów i tym samym współpracować w zespole oraz ponownie wykorzystywać istniejące rozwiązania. Co więcej ten sam, naturalny dla ludzi sposób myślenia i te same pojęcia można użyć przy analizie problemu który ma być rozwiązany i projektowaniu jego programowego rozwiązania. Zauważmy, że już Arystoteles analizując rzeczywistość wprowadził pojęcia formy i materii. Formie w programowaniu obiektowym odpowiada Klasa, materii jej egzemplarz wymiennie nazywany obiektem. Klasyfikacja, czyli łączenie występujących w rzeczywistości obiektów w grupy --- klasy, jest najbardziej naturalnym sposobem rozumienia rzeczywistości.
Analiza i projektowanie obiektowe
Z programowanie obiektowym nieodzownie wiążą się analiza i projektowanie obiektowe (ang. Object-Oriented Analysis and Design, OOA/D). Analiza to badanie problemu i wymagań, ale nie rozwiązania. Analiza to obszerny termin. Analiza obiektowa (ang. object-oriented analisys) zajmuje się odnajdywaniem i badaniem obiektów pojęciowych. Obiekty pojęciowe nie mają nic wspólnego z programowaniem. Reprezentują pojęcia i koncepcje ze świata rzeczywistego, a dokładniej z dziedziny, która jest analizowana. W wypadku systemu informacyjnego dla Zakładu Transportu Miejskiego, obiektami pojęciowymi są na przykład: Autobus, Linia i Kierowca.
Projektowanie to wymyślanie koncepcyjnego rozwiązania (programistycznego i sprzętowego), które realizuje wymagania. Takim koncepcyjnym rozwiązaniem może być opis schematu bazy danych lub obiektów programowych. Podczas projektowania zazwyczaj pomija się niskopoziomowe lub oczywiste (dla zamierzonych odbiorców projektu) szczegóły i koncentruje się na wysokopoziomowych pomysłach oraz ideach. Projektowanie obiektów programowych określane jest jako projektowanie obiektowe (ang. object-oriented design).
Najważniejszą czynnościom projektowania obiektowego jest wyznaczenie odpowiedzialności obiektom programowym oraz określenie jak mają współpracować, by wykonać zadanie. Tak naprawdę są to jedyne czynność jakie na pewno trzeba będzie wykonać. Główna trudność polega na tym że istniej wiele poziomów swobody, a każde rozwiązanie ma swoje wady i zalety. Na programowaniu obiektowym nauczysz się na co zwracać uwagę i jak świadomie wybierać. Poznasz również wzorce projektowe, czyli typowe rozwiązania typowych problemów, których wady i zalety dobrze poznano.
Analiza i projektowanie dają się krótko streścić jako "zrób co należy (analiza) i zrób to jak należy (projektowanie)".
Proces wytwórczy
Należy tu podkreślić, że w większości przedsięwzięć programistycznych nie da się najpierw wykonać całej analizy, potem przygotować kompletnego projekt, a na końcu jedynie przekształcić go w kod. Takie podejście nazywane "kaskadowym" opiera się na błędnych przekonaniach, że wytwarzanie oprogramowania jest podobne do innych zajęć, np. budowania domów. Tak nie jest. Większość przedsięwzięć programistycznych to opracowywanie nowego produktu, gdzie nawet klient nie wie dokładnie czego chce. Najlepiej wytwarzać oprogramowanie przyrostowo, dzieląc całą pracę na krótkie, trwające od dwóch do sześciu tygodni iteracje. W każdej iteracji wykonuję się zarówno analizę, projektowanie jak i pisze kod. Oczywiście w początkowych iteracjach więcej czasu będzie poświęcane jest na analizę, a w końcowych na projektowanie i kodowanie. Wynikiem każdej iteracji powinien być sprawny system posiadający jedynie część funkcjonalności. Zmiany będą się pojawiały i trzeba się z nimi pogodzić, ale można ograniczyć ich zasię i koszt wybierając do realizacji w początkowych iteracjach wymagania, które mają największą wartość dla klienta, których realizacja wywiera największy wpływ na architekturę systemu i które niosą za sobą największe ryzyko. W ten sposób zmniejsza się prawdopodobieństwo zmian, które powodują zmarnowanie części już wykonanej pracy.
Więcej o procesach wytwórczych i tworzeniu iteracyjnym dowiesz się na Inżynierii oprogramowania !!! link !!! Mimo, że w tej chwili ta rada może wydawać ci się na wyrost i prawdopodobnie nie możesz się już doczekać poznawania obiektowych języków programowania zapamiętaj: pisząc program zaliczeniowy z programowania obiektowego oraz w przyszłej pracy zawodowej nie odraczaj trudnych i ryzykownych zagadnień na sam koniec!
Obiektowe modelowanie dziedziny
Zgodnie ze swoją nazwą model dziedziny ma odzwierciedlać pojęcia z modelowanej części świata rzeczywistego oraz ich zależności. Jest to najważniejszy artefakt analizy obiektowej. W modelu dziedziny nie zajmujemy się obiektami programowymi. Może on posłużyć jako źródło inspiracji prze ich projektowaniu, ale nie myślmy na razie o programowaniu. Tworzenie modelu dziedziny nie jest obowiązkowe ale bardzo przydatne, jeżeli dziedzina problemu, który rozwiązujemy nie jest dobrze zrozumiała. Jeżeli jest, tworzenie modelu dziedziny należy potraktować jako dekompozycję dziedziny na godne uwagi pojęcia i obiekty. Inspirowanie się nim podczas projektowania systemu pomoże w zmniejszeniu luki reprezentacji.
W modelu dziedziny pokazuję się:
- klasy pojęciowe
- powiązania między klasami pojęciowymi
- atrybuty klas pojęciowych
Przykładowy częściowego model dziedziny dla aplikacji wspomagającej rezerwację miejsc i sprzedaż biletów kinowych znajduje się na diagramie.