Projektowanie systemów informacyjnych

34
wa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykład 2 Wprowadzenie do obiektowości, cz. 1

description

Projektowanie systemów informacyjnych. Wykład 2 Wprowadzenie do obiektowości, cz. 1. Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa. Zagadnienia. Kryzys oprogramowania. Geneza obiektowości. - PowerPoint PPT Presentation

Transcript of Projektowanie systemów informacyjnych

Page 1: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 1

Projektowanie systemów informacyjnych

Kazimierz Subieta, Ewa Stemposz

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 2

Wprowadzenie do obiektowości, cz. 1

Page 2: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 2

Zagadnienia

Geneza obiektowości

Podstawowe zasady obiektowości

• obiekt• tożsamość obiektu• hermetyzacja• klasa• dziedziczenie• polimorfizm

Obszary oddziaływania obiektowości

• obiektowe metodyki• obiektowe języki programowania• obiektowe bazy danych

Kryzys oprogramowania

Przeszkody dla obiektowości

Page 3: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 3

Kryzys współcześnie tworzonego oprogramowania

USA:

Utrzymanie 10 mld. linii istniejących programów kosztuje 70 mld. $ rocznie (IEEE Software Development, Aug 94, p.65)

31% projektów jest anulowane jeszcze w trakcie konstrukcji

53% projektów jest kończone z przekroczeniem zaplanowanego czasu, budżetui z ograniczeniem planowanego zbioru funkcji systemu

zaledwie 16% projektów jest kończone w zaplanowanym czasie, bez przekroczeniabudżetu i okrajania funkcjonalności (Failed technology projects in Investor’s Business Daily, Los Angeles, Jan. 25, 1995, p. A8)

31% nowych projektów jest anulowane przed zakończeniem;koszt 81 mld. $ (PC Week, 16 Jan 95, p.68)

Page 4: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 4

Kryzys oprogramowania (c.d.)Średnia wydajność wykonawców oprogramowania spadła o 13% w ciągu dwóch lat; stosunek najlepszej wydajności do najgorszej od 1990 r. rozszerzył się od 4:1 do 600:1. (Ed Yourdon’s Guerilla Programmer, Jul 95)

• zarówno wytwarzanie, jak i utrzymywanie oprogramowania kosztuje zbyt dużo,• oprogramowanie jest zawodne,• współdziałanie pomiędzy produktami programistycznymi stanowi poważny problem.

Symptomy kryzysu oprogramowania:

Powody:

• Złożoność systemów informatycznych, syndrom współczesnych produktów, przekleństwo ciążące na większości projektów i produktów informatyki.

Page 5: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 5

Kryzys oprogramowania (c.d.)

Po przekroczeniu pewnego progu złożoności człowiek przestaje “panować nad przygotowywanym produktem, ponieważ całościowe zrozumienie funkcjonowaniasystemu w różnych jego aspektach i na dowolnym poziomie szczegółowości z zasady przekracza jego możliwości.

• Konflikt między ogromną odpowiedzialnością, jaka spoczywa na współczesnych produktach informatycznych, a zawodnością wynikającą ze złożoności oprogramownia z jednej strony a ciągle niestabilnymi, niedojrzałymi metodami wytwarzania i weryfikacji z drugiej strony (dotyczy to np. niedopasowania metodyk analizy i projektowania systemów informacyjnych do bazy realizacyjnej systemów, czyli między innymi do języków programowania czy systemów zarządzania bazami danych).

• Szybkie zmiany w przemyśle informatycznym (5-7 miesięcy w porównaniu do 5-7 lat w innych dziedzinach) - stanowi to powód do frustracji nie tylko wytwórców oprogramowania ale także ich klientów.

Page 6: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 6

Jak walczyć ze złożonością oprogramowania

Złożoność powoduje, że głównym problememw procesie konstrukcji produktów informatycznych stał się człowiek (analityk, projektant, programista, ...) z jego różnymi uwarunkowaniami fizycznymi, psychologicznymi i mentalnymi.

Wniosek: Technologie komputerowe powinny być bardziej zorientowane na ludzi, niż na maszyny.

Corobić?

Mechanizmy abstrakcji pozwalające operować jednostkami bez wnikania w ich wewnętrzną strukturę, innymi słowy stosować zasadę oddzielenia specyfikacji od implementacji.

Należy wykorzystywać:

Page 7: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 7

Jak walczyć ze złożonością oprogramowania (c.d.)

• pozwalające budować większe jednostki oprogramowania z mniejszych; • pozwalające na dekomponowanie złożonych struktur na ich fragmenty i rozpatrywanie tych fragmentów niezależnie od siebie i niezależnie od całości.

Mechanizmy kompozycji i dekompozycji:

Ponowne użycie (reuse) wcześniej wytworzonych składników oprogramowania. Może ono dotyczyć wszystkich elementów projektu i oprogramowania.

Zwrócenie uwagi na możliwości percepcyjne człowieka.

Nie tylko wzrost efektywności procesu wytwarzania produktu programistycznego ale też i wzrost jakości oprogramowania, czyli np. poprawności, niezawodności, czytelności, testowalności, skalowalności,łatwej pielęgnacji, współdziałania, przenaszalności, itp.

Nie tylko wzrost efektywności procesu wytwarzania produktu programistycznego ale też i wzrost jakości oprogramowania, czyli np. poprawności, niezawodności, czytelności, testowalności, skalowalności,łatwej pielęgnacji, współdziałania, przenaszalności, itp.

Efekty:

Page 8: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 8

Geneza obiektowości

Mentalna percepcja światarzeczywistego

Model pojęciowy

Schemat strukturydanych

W modelu relacyjnym model pojęciowy stara się odwzorować świat rzeczywisty, lecz jest ograniczony dostępną bazą implementacyjną. W rezultacie, schemat struktury danych gubi semantykę danych.

Obiektowość jest nową ideologią która wynika z zaobserwowanych wad istniejącego światai podaje jakąś receptę, jak te wady usunąć, a więc przede wszystkim stara się o uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości (dziedzinie problemowej) a myśleniem o danych i procesach, które zachodzą na danych.

Model obiektowy podtrzymuje te zgodności, przybliżając semantykę danych do świata rzeczywistego.

Page 9: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 9

Współczesnepojęcia

obiektowości

Współczesnepojęcia

obiektowości

Źródła obiektowości

Metodyki projektowania oprogramowania, od swojego początku bazujące na wyróżnianiu obiektów i ich klas w otaczającej nas rzeczywistości

Języki programowania operującena złożonych strukturach danych,wprowadzające klasy, metody,dziedziczenie i hermetyzację.(Simula 67, Smalltalk)

Bazy danych, od początku bazujące na obiektach (IMS, CODASYL).Wady modelu relacyjnego baz danych;odrzucenie jego powierzchownej prostoty.

Skierowanie uwagi na czynniki ludzkie w tworzeniu oprogramowania.

Page 10: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 10

Obszary oddziaływania obiektowościMetodyki analizy i projektowania SI (Rumbaugh, Booch, Jacobson, Yourdon,...) ioparte o nie narzędzia CASE. Najbardziej istotna zmiana w stosunku do metodyk wykorzystujących model encja-związek to możliwość związania z obiektami operacji,które można na nich wykonywać.

Języki programowania (Smalltalk, C++, Java, Eiffel,...)Klasy, dziedziczenie, hermetyzacja, metody, późne wiązanie.

Bazy danych i składy trwałych obiektów (standard ODMG-93, ObjectStore, O2, Poet, Versant, ...)Przeniesienie obiektowych technologii programowania na grunt baz danych.

Współdziałanie systemów heterogenicznych (OMG CORBA,OLE/DCOM/ActiveX)

Obiekty i klasy jako podstawa wymiany informacji pomiędzy systemami.

Wizyjne środowiska programistyczne (Smalltalk, CA OpenRoad, IBM VisualAge,...)Przeniesienie technik obiektowych do programowania wizyjnego.

Inne: biblioteki oprogramowania, grafika, miary i oceny oprogramowania,re-inżynieria biznesu (BPR)

Page 11: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 11

Obiektowe języki programowania (1)

SmalltalkSmalltalkJezyk zrobiony w latach 1976-83 w Xerox Palo Alto Research Centerw Kalifornii. Zawiera klasy, podklasy, wirtualne funkcje, przesyłanie komunikatów, meta-klasy. Wszystko jest tu obiektem, a w szczególności liczby i klasy. Istotą sukcesu Smalltalk’a jest to, że nie jest on tylko językiem, ale także mocnym zintegrowanym środowiskiem programistycznym z doskonałym interfejsem okienkowym. Prostota, możliwość szybkich dynamicznych zmian, elastyczna natura Smalltalk’a uczyniła go doskonałym narzędziem do szybkiego tworzenia prototypów. Mniej są znane przemysłowe aplikacje na dużą skalę.

C++C++Język hybrydowy, pochodna języka C. Łączy własności C niskiego poziomu,takie jak arytmetyka wskaźników, z konstrukcjami wysokiego poziomu, takimijak klasy, podklasy, hermetyzacja, funkcje wirtualne. (Eklektyczna natura C++ jest przedmiotem krytyki.) Duże zastosowania na skalę przemysłową.Jednocześnie, jest on krytykowany z powodu wolnego tworzenia aplikacji,zawodności, słabej przenaszalności, dużego ryzyka wadliwego działaniaprogramów.

Page 12: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 12

Obiektowe języki programowania (2)

JavaJavaMieszanina C++, Smalltalk’a i Objective-C, z obcięciem własności niskiegopoziomu. Język pomyślany jako narzędzie do programowania stron Webu (ale oczywiście, jest to tylko jedno z zastosowań). Istotną własnością Java jest to, że programy kompiluje się nie do poziomu kodu maszynowego, a do poziomu znakowego języka pośredniego, czyli. tzw. apletów (applets), które są następnie interpretowane. Daje to efekt dużej przenaszalności programów oraz zwiększeniabezpieczeństwa (security), co jest szczególnie istotne w środowiskach rozproszonych, takich jak np. Internet.

Ada95Ada95 AgoraAgora

CLOSCLOS

EiffelEiffelModula-3Modula-3

Objective-CObjective-C

OO-COBOLOO-COBOL

SelfSelf LENSLENS

SatherSather

PythonPython

SinaSinaThetaTheta

DylanDylan

Ponadto mrowie języków: Trellis-OwlTrellis-Owl

DSMDSMActorActorObject PascalObject PascalBetaBeta

Page 13: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 13

Obiektowe bazy danych

Bazy danych w swoich początkach były obiektowe, chociaż nie realizowały wszystkich pojęć obiektowości, takich jak klasy, metody i dziedziczenie.

Bazy danych w swoich początkach były obiektowe, chociaż nie realizowały wszystkich pojęć obiektowości, takich jak klasy, metody i dziedziczenie.

trwałe obiekty + identyfikatory obiektów

Docelowa tendencja:Docelowa tendencja:

Programista podczas programowania nie musi nic wiedzieć o bazie danych, ma operować na jej obiektach, tak jak na zmiennych programu, co oznacza, że baza danych powinna być dla niego niewidoczna (przezroczysta).

Programista podczas programowania nie musi nic wiedzieć o bazie danych, ma operować na jej obiektach, tak jak na zmiennych programu, co oznacza, że baza danych powinna być dla niego niewidoczna (przezroczysta).

Podstawowy wyróżnik bazy obiektowej to:

Bazy obiektowe: O2 , Gemstone, ObjectStore, Poet, Versant, UniSQL, ...

Page 14: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 14

Trwałość

Wartość jest trwała, jeżeli żyje dłużej niż czas działania programu, który jej używa(przenosi się pomiędzy kolejnymi uruchomieniami programu). Wszystko, co zawierają bazy danych, jest trwałe.

Wartość jest trwała, jeżeli żyje dłużej niż czas działania programu, który jej używa(przenosi się pomiędzy kolejnymi uruchomieniami programu). Wszystko, co zawierają bazy danych, jest trwałe.

Trwała zmienna: zmienna programistyczna, która ma wszystkie własności normalnej zmiennej (w sensie konstrukcji programistycznych, w których może być użyta), ale której wartość przy nowym uruchomieniu programu jest taka sama jak przy zakończeniu poprzedniego uruchomienia programu. Popularne języki programowania (C, C++, Smalltalk, Pascal, Java,...) nie mają trwałych zmiennych. Wymagają one wczytania explicite trwałej wartości z pliku zewnętrznego na swoją zmienną (i zapisania vice versa). Istnieje grupa prototypowych języków posiadających trwałe zmienne (PJama).

persistence

Trwały obiekt: obiekt o własnościach trwałej zmiennej, obiekt bazy danych.

Page 15: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 15

Ortogonalna trwałość orthogonal persistence

Tradycyjnie, bazy danych przechowywały typy trwałe i masowe (zbiory, relacje, etc.).Tradycyjnie, języki programowania zajmowały się typami indywidualnymi i

nietrwałymi (zmienne, struktury, zapisy, etc.).Tradycyjnie, istnieją różnice w koncepcjach dostępu do bazy danych i dostępu do

zmiennych programu.

Tradycyjnie, bazy danych przechowywały typy trwałe i masowe (zbiory, relacje, etc.).Tradycyjnie, języki programowania zajmowały się typami indywidualnymi i

nietrwałymi (zmienne, struktury, zapisy, etc.).Tradycyjnie, istnieją różnice w koncepcjach dostępu do bazy danych i dostępu do

zmiennych programu.

Nie istnieje logiczne uzasadnienie takiego podziału. Można podać wiele przykładów, kiedy przydałoby się zapamiętanie w bazie danych jakichś zmiennych indywidualnych (np. nazwiskoprezydenta RP). Podobnie, brak typów masowych w językach programowania doprowadził dokoncepcji “sterty” (heap), która ma liczne wady, w szczególności, ograniczoną kontrolę typów,konieczność dynamicznych operacji alokacji i zwalniania pamięci, konieczność przetwarzaniapoprzez wskaźniki.Ortogonalna trwałość oznacza nowy typ języka programowania, w którym cecha

trwałości jest ortogonalna do konstruktorów typu. W szczególności, baza danych możeprzechowywać dane indywidualne (trwałe), zaś w obszarze roboczym programu mogą znajdować się wartości masowe (nietrwałe). Cecha trwałości powinna być obsługiwana przez wyspecjalizowane funkcje, ale wszystkie pozostałe funkcjonalności (w tym językizapytań) powinny nie robić żadnej różnicy w dostępie do trwałych i nietrwałych danych.

Ortogonalna trwałość oznacza nowy typ języka programowania, w którym cechatrwałości jest ortogonalna do konstruktorów typu. W szczególności, baza danych możeprzechowywać dane indywidualne (trwałe), zaś w obszarze roboczym programu mogą znajdować się wartości masowe (nietrwałe). Cecha trwałości powinna być obsługiwana przez wyspecjalizowane funkcje, ale wszystkie pozostałe funkcjonalności (w tym językizapytań) powinny nie robić żadnej różnicy w dostępie do trwałych i nietrwałych danych.

Page 16: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 16

Obiektowo-relacyjne bazy danych

Ostatnio karierę robi termin „uniwersalny serwer” (universal server), dający możliwość zastosowania systemu do przechowywania i przetwarzania obiektów, relacji, danych multimedialnych, itd. Podstawą ideologiczną systemów obiektowo-relacyjnych jest zachowanie sprawdzonych technologii relacyjnych (np. SQL) i wprowadzanie na ich wierzchołku innych własności, w tym obiektowych.

Systemy te powstają w wyniku ostrożnej ewolucji systemów relacyjnych w kierunku obiektowości. Liczą na pozycję systemów relacyjnych na rynku i odwołują się do ich wiernej klienteli.

Kluczowymi produktami tej technologii są systemy: Informix Universal Server, DB2 Universal Database, Oracle8, UniSQL/X, OSMOS, OpenIngres, Sybase Adaptive Server i inne. Systemy te są wyposażane w atrakcyjne cechy umożliwiające efektywną produkcję aplikacji. Wśród nich można wymienić przystosowanie do multimediów (duże obiekty BLOB, CLOB), dane przestrzenne (spatial), abstrakcyjne typy danych (ADT), metody (funkcje i procedury) definiowane przez użytkownika w różnych językach (C, C++, VisualBasic, Java), kolekcje (zbiory, wielozbiory, sekwencje, zagnieżdżone tablice, tablice o zmiennej długości), typy referencyjne, przeciążanie funkcji, późne wiązanie i inne.

Page 17: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 17

Integracja schematu pojęciowego z systemami relacyjnymi

System relacyjny jako back-end, tj. baza implementacyjna. Na czubku systemu relacyjnego budowany jest front-end, tj. zestaw interfejsów do zarządzania złożonymi obiektami, klasami, dziedziczeniem, itd. Podejście mające sporo opracowań oraz zaimplementowany co najmniej jeden prototyp (Starburst).

Odwzorowanie obiektowego projektu na struktury relacyjne. Podejście tradycyjne (znane z modelu encja-związek). Wady: niemożliwość odwzorowania wszystkich detali schematu obiektowego, zniekształcenie semantyki danych, konieczność wprowadzania sztucznych cech do schematu (niektórych atrybutów, itd.).

Obiektowe perspektywy nad strukturą relacyjną - możliwośćistniejąca jak dotąd raczej w strefie akademickiej z kilku powodów: aktualizacja perspektyw, wydajność,....

Wady: Podejście wymaga budowy nowego systemu; narzuty relacyjnego back-end na czasy wykonania mogą być istotne i trudne do wyeliminowania.

Page 18: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 18

Obiektowy SZBD jest to SZBD

Klasyczne funkcje SZBD:Klasyczne funkcje SZBD:

Zarządzanie pamięcią zewnętrzną Zarządzanie schematem Sterowanie współbieżnością Zarządzanie transakcjami Zapewnienie odtwarzalności Przetwarzanie zapytań Kontrola dostępu

Dla baz obiektowych, do powyższych funkcji, zostały dołożone:Dla baz obiektowych, do powyższych funkcji, zostały dołożone:

Obiekty (również złożone) Tożsamość obiektów Hermetyzacja Typy i/lub klasy oraz ich hierarchia Typy definiowane przez użytkownika Przesłanianie/przeciążanie/późne wiązanie

Page 19: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 19

Przeszkody dla obiektowościKażda nowa ideologia ściera się z zastanym stanem rzeczy i poprzednimi ideologiami.

Z czym walczy obiektowość?Z czym walczy obiektowość?

Zastany świat interfejsów programistycznych (C, COBOL, Fortran, SQL, ...)

Mity i fałszywe steoretypy:

• Relacyjna baza danych zapewnia prostotę struktur danych. • Bezpośrednie powiązania (wskaźniki) w bazie danych są niekorzystne.• Tylko relacyjna baza danych zapewnia możliwość definiowania języków zapytań.• Tylko relacyjna baza danych zapewnia sprawne przetwarzanie transakcji.• Relacyjne bazy danych mają solidne podstawy matematyczne.• Relacyjne bazy danych mają bardzo dobrą wydajność, nieosiągalną dla innych.

Własne słabości: słabo wyartykułowane zasady, zbyt dużo formalizmów, różne języki, brak standardów.

“Spuścizna”: ogromne inwestycje w hierarchiczne, sieciowe i relacyjne bazy danych.

Page 20: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 20

Obiektowość - potencjalne ryzyko

Nieopracowane mechanizmy zarządzania dużą bazą obiektów, sterowaniawersjami, rejestrowania zmian.

Technologie obiektowe są jak dotąd stosowane przez małe i średnie organizacje.Nie jest do końca pewne jak przeskalują się dla wielkich organizacji.Duża liczba tematów znajduje się ciągle w fazie laboratoryjnej.Szereg technologii jest mało stabilnych (np. metodyki projektowania).

Przejście na technologie obiektowe może zagrozić funkcjonowaniu obecniedziałających i sprawnych systemów, które są krytyczne dla misji organizacji.

Zbyt mała liczba ekspertów jest wyszkolona w zakresie technologii obiektowych.

Nie jest jasne, jakie koszty pociągnie za sobą przejście na technologie obiektowe.

Standardy w zakresie obiektowości są niedopracowane i niestabilne.Nie wiadomo w jakim zakresie będą one pełnić swoją funkcję.

Page 21: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 21

Podstawowe zasady obiektowościObiekt - struktura danych, występująca łącznie z operacjami dozwolonymi do wykonywania na niej, odpowiadająca bytowi wyróżnialnemu w analizowanejrzeczywistości.

Hermetyzacja - rozróżnienie pomiędzy interfejsem do obiektu opisującym co obiekt robi, a implementacją definiującą, jak jest zbudowany i jak robi, to co ma zrobić.

Klasa - Zgrupowanie obiektów o tych samych charakterystykach.

Dziedziczenie - Wielokrotne użycie tego, co wcześniej zostało zrobione: definiowanie klas, które mają wszystkie cechy zdefiniowane wcześniej (z nadklasy) plus cechy nowe.

Polimorfizm - Wybór nazwy dla operacji jest określony wyłącznie semantyką operacji.Decyzja o tym, która metoda implementująca daną operację, zależy od przynależności obiektu do odpowiedniej klasy.

Tożsamość obiektu - wewnętrzny identyfikator, który pozwala na odróżnienie go od innych obieków.

Page 22: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 22

Obiekty (1)

Obiektem może być także pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu,...), którym można operować jako zwartą bryłą (wyszukiwać, wiązać, kopiować, blokować, usuwać, indeksować, ...).

Obiektem może być także pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu,...), którym można operować jako zwartą bryłą (wyszukiwać, wiązać, kopiować, blokować, usuwać, indeksować, ...).

Każdy obiekt posiada tożsamość, która odróżnia go od innych obiektów.Tożsamość obiektu jest niezależna od wartości jakichkolwiek jego atrybutów i od jego lokacji w świecie rzeczywistym lub w przestrzeni adresowej komputera.(W praktyce: tożsamość = trwały wewnętrzny identyfikator obiektu)

Każdy obiekt posiada tożsamość, która odróżnia go od innych obiektów.Tożsamość obiektu jest niezależna od wartości jakichkolwiek jego atrybutów i od jego lokacji w świecie rzeczywistym lub w przestrzeni adresowej komputera.(W praktyce: tożsamość = trwały wewnętrzny identyfikator obiektu)

Obiektem jest byt (rzecz lub pojęcie) obserwowalny w świecie rzeczywistym, którego dotyczy SI (dziedzina problemowa). Obiekt jest odróżnialny od innych obiektów, ma dobrze określone granice i nazwę.

Obiektem jest byt (rzecz lub pojęcie) obserwowalny w świecie rzeczywistym, którego dotyczy SI (dziedzina problemowa). Obiekt jest odróżnialny od innych obiektów, ma dobrze określone granice i nazwę.

Obiekt posiada stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu).

Obiekt posiada stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu).

Page 23: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 23

Obiekty (2)

Obiekt może być złożony, tj. może składać się z mniejszych obiektów.Obiekt może być złożony, tj. może składać się z mniejszych obiektów.

Obiekt może być powiązany z innymi obiektami związkami skojarzeniowymi.Obiekt może być powiązany z innymi obiektami związkami skojarzeniowymi.

Obiekt ma przypisane zachowanie, tj. zestaw operacji które wolno do niego stosować(implementacja operacji jest zwana metodą).

Obiekt ma przypisane zachowanie, tj. zestaw operacji które wolno do niego stosować(implementacja operacji jest zwana metodą).

Obiekt ma przypisany typ, tj. wyrażenie językowe, które określa dopuszczalną budowę obiektu oraz ustala operacje, które wolno wykonywać na obiekcie.

Obiekt ma przypisany typ, tj. wyrażenie językowe, które określa dopuszczalną budowę obiektu oraz ustala operacje, które wolno wykonywać na obiekcie.

Page 24: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 24

Przykład obiektu

ObiektKONTO

Numer: 123-4321Stan konta: 34567 PLNWłaściciel: Jan KowalskiUpoważniony: ...Podpis: …....

WypłaćWpłać

Sprawdźstan

UpoważnijPodaj osobyupoważnione

Porównajpodpis

Zlikwidujkonto

Nalicz procent

Page 25: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 25

Tożsamość obiektuObiekt jest wyróżnialny w otaczającym nas świecie poprzez swoje istnienie,nie poprzez jakąkolwiek wartość, która go odróżnia od innych obiektów.

Obiekt jest wyróżnialny w otaczającym nas świecie poprzez swoje istnienie,nie poprzez jakąkolwiek wartość, która go odróżnia od innych obiektów.

Może się zdarzyć, że z punktu widzenia naszych obserwacji (tj. stanu obiektu) dwa obiekty są nieodróżnialne. Niemniej jednak są to różne obiekty.

W implementacji obiektowej bazy danych system automatycznie nadaje unikalny identyfika-tor dla obiektu, który odróżnia go od innych obiektów oraz umożliwia budowanie referencji do obiektu. Taki identyfikator jest wewnętrzny, nie ma żadnego znaczenia dla dziedziny problemowej i programista/użytkowwnik nigdy nie operuje jego wartością explicite. Identyfikator może być trwały, tj. niezmienny dla całego życia obiektu.

W implementacji obiektowej bazy danych system automatycznie nadaje unikalny identyfika-tor dla obiektu, który odróżnia go od innych obiektów oraz umożliwia budowanie referencji do obiektu. Taki identyfikator jest wewnętrzny, nie ma żadnego znaczenia dla dziedziny problemowej i programista/użytkowwnik nigdy nie operuje jego wartością explicite. Identyfikator może być trwały, tj. niezmienny dla całego życia obiektu.

identity

Page 26: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 26

Powiązania pomiędzy obiektami

W obiektowych językach programowania, metodykach i bazach danych możliwe jest tworzenie bezpośrednich powiązań prowadzących od jednego obiektu do innego. Powiązanie jest daną zawierającą identyfikator obiektu. Unika się tu pojęcia wskaźnika, na rzecz czegoś “bardziej abstrakcyjnego” - powiązania.

W obiektowych językach programowania, metodykach i bazach danych możliwe jest tworzenie bezpośrednich powiązań prowadzących od jednego obiektu do innego. Powiązanie jest daną zawierającą identyfikator obiektu. Unika się tu pojęcia wskaźnika, na rzecz czegoś “bardziej abstrakcyjnego” - powiązania.

PRACOWNIK

Nazwisko Nowak

Zarobek 1500

Pracuje_w o

FIRMA

Nazwa Relax Ltd. Szef o

Zatrudnia o

Zatrudnia o

Zatrudnia o

Zalety powiązań: naturalne odwzorowanie semantycznych związków między obiektami, łatwe nawigowanie dzięki wyrażeniom ścieżkowym, zwiększenie szybkości działania.

Wady: zwiększona “sztywność” struktury danych, możliwość utraty spójności wskutek“zwisających” wskaźników, możliwość naruszenia reguł hermetyzacji.

links, pointers, relationships

Page 27: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 27

Komunikat (1)Komunikat jest wyrażeniem językowym skierowanym do obiektu i wywołującym jedną z operacji, które są związane z tym obiektem.

Komunikat jest wyrażeniem językowym skierowanym do obiektu i wywołującym jedną z operacji, które są związane z tym obiektem.

Komunikat jest wysyłany z jednego obiektu do innego obiektu,lub z pewnego programu sterującego do obiektu (Smalltalk vs. C++).Komunikat może mieć zero, jeden lub więcej parametrów.

Obiekt, który otrzymał komunikat, może zmienić stan po wykonaniu wywołanej operacji.

Po wykonaniu operacji obiekt, który otrzymał komunikat może zwrócić odpowiedź do obiektu lub programu, który go wysłał (czyli wartość, lub w terminologii Smalltalka -obiekt). Odpowiedź nie jest komunikatem.

message

Postać komunikatu nie zależy od implementacji obiektu, natomiast wykonaniekomunikatu zależy od implementacji obiektu.

Page 28: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 28

Komunikat (2)

Numer: 123-4321Stan konta: 34567 PLNWłaściciel: Jan KowalskiUpoważniony: ...Podpis: …

WypłaćWpłać

Sprawdźstan

Upoważnij

Podaj osobyupoważnione

Porównajpodpis

Zlikwidujkonto

Nalicz procent

Wypłać 1000 PLN

OK, wypłaciłem

GrajCccco proszę...?

Page 29: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 29

Metoda jest implementacją operacji. Może być wiele metod implementującychdaną operację.

Komunikat a wołanie procedury (1)

Nie jest to wyłącznie różnica syntaktyczna, gdyż:

Dla metody, środowisko na którym działa, może zmieniać się dynamicznie(późne wiązanie metod, w odróżnieniu od wczesnego wiązania dla procedur).

Dla metody, środowisko na którym działa, może zmieniać się dynamicznie(późne wiązanie metod, w odróżnieniu od wczesnego wiązania dla procedur).

Komunikat nie określa, która z metod impementujących daną operację ma być wywołana; wysłanie komunikatu do konkretnego obiektu powoduje wywołanie metody, implementującejżądaną operację, związanej z danym obiektem.

Komunikat nie określa, która z metod impementujących daną operację ma być wywołana; wysłanie komunikatu do konkretnego obiektu powoduje wywołanie metody, implementującejżądaną operację, związanej z danym obiektem.

Wołanie procedury: obiekt jest komunikowany jako parametr:procedura (obiekt, arg1, arg2,...)

Komunikat: obiekt-adresat poprzedza wywołanie operacji: obiekt.operacja (arg1, arg2,...)

Page 30: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 30

Komunikat a wołanie procedury (2)X = dochody( emeryt )Y = dochody( pracownik )

Przełączanie, związane z rodzajem obiektu, następuje w ciele procedury dochody. Procedurę z reguły pisze jeden programista, na wszystkie okazje. Każda zmiana (nowy rodzaj obiektów) wymagazmian w ciele procedury.

X = emeryt.dochody()Y = pracownik.dochody()

Nie ma przełączenia; za każdym razem, w zależności od rodzaju obiektu - adresata komunikatu, wywoływana jest inna metoda dochody. Obie metody implementują operację dochody. Obie metody (i ichprogramiści) nie muszą nic o sobie wiedzieć.

Page 31: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 31

PolimorfizmZ greckiego, polimorfizm - oznacza “wiele form” (postaci) jednego bytu. Słowo“polimorfizm” też jest polimorficzne.

• Polimorfizm metod - (zostało już wyjaśnione w punkcie „Podstawowe zasady obiektowości”) - operacja wywoływana przez komunikat może być różnie wykonana, w zależności od rodzaju obiektu, do którego ten komunikat został wysłany.

• Polimorfizm metod - (zostało już wyjaśnione w punkcie „Podstawowe zasady obiektowości”) - operacja wywoływana przez komunikat może być różnie wykonana, w zależności od rodzaju obiektu, do którego ten komunikat został wysłany.

• Polimorfizm typów (z teorii typów) - polimorfizm w tzw. polimorficznych językach programowania - oznacza istnienie procedur lub funkcji, które mogą zarówno przyjmować wartości wielu typów jako swoje argumenty, jak też i zwracać wartości wielu typów. Przykładowo, funkcja daj_pierwszy(lista) zwraca pierwszy element dowolnej listy, niezależnie od tego, czy jest to lista liczb całkowitych, czy lista liczb rzeczywistych, czy lista rekordów, czy też inna. Polimorfizm typów jest uważany za podstawę programowania ogólnego (generic). Temat pozostaje jednak w strefie akademickiej, gdyż języki z polimorfizmem typów uważane są za zbyt wyrafinowane dla przeciętnego programisty, a w szczególności ML.

• Polimorfizm typów (z teorii typów) - polimorfizm w tzw. polimorficznych językach programowania - oznacza istnienie procedur lub funkcji, które mogą zarówno przyjmować wartości wielu typów jako swoje argumenty, jak też i zwracać wartości wielu typów. Przykładowo, funkcja daj_pierwszy(lista) zwraca pierwszy element dowolnej listy, niezależnie od tego, czy jest to lista liczb całkowitych, czy lista liczb rzeczywistych, czy lista rekordów, czy też inna. Polimorfizm typów jest uważany za podstawę programowania ogólnego (generic). Temat pozostaje jednak w strefie akademickiej, gdyż języki z polimorfizmem typów uważane są za zbyt wyrafinowane dla przeciętnego programisty, a w szczególności ML.

polymorphism

Page 32: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 32

Polimorfizm (c.d.)

Polimorficzne języki programowania (ML, Quest, Napier88,...) nie muszą być obiektowe, ale mogą być obiektowe (Fibonacci).

• Polimorfizm parametryczny. Rodzaj polimorfizmu typów, który oznacza, że typ bytu programistycznego może być parametryzowany innym typem, np. klasa WEKTOR (int) czy WEKTOR (char).

Dość powszechne jest plątanie polimorfizmu metod z polimorfizmem typów. Argumentacja, że polimorfizm metod jest szczególnym przypadkiem polimorfizmu typów (obiekt, do którego jest wysłany komunikat jest dodatkowym parametrem metody) jest niezbyt przekonywująca.

Page 33: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 33

PodsumowaniePotencjał obiektowości dla potrzeb redukcji złożoności oprogramowania:

• Modelowanie świata rzeczywistego jest ułatwione dzięki zastosowaniu podejścia obiektowego. Klasy, grupujące obiekty świata rzeczywistego, są najbardziej stabilnym elementem dziedziny problemu. Doświadczenie wykazuje, że oprogramowanie oparte o klasy powstałe w wyniku analizy dziedzinowej jest bardziej odporne na zmiany wymagań niż oprogramowanie skonstruowane w oparciu o jednostki funkcjonalne.

• Hermetyzacja wspomaga redukcję złożoności poprzez zachęcanie konsumentów, by opierali się raczej na interfejsie do obiektu niż jego wewnętrznej organizacji. Abstrahowanie od szczegółów implementacyjnych znacząco ułatwia proces rozumienia. Ponadto, hermetyzacja pozwala na ukrycie poprawek czy modyfikacji przed konsumentem oprogramowania.

Page 34: Projektowanie systemów informacyjnych

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 2, Folia 34

Potencjał obiektowości (c.d.)

• Dziedziczenie pozwala na specjalizowanie strukury i zachowania obiektu podklasy bez ingerowania w struktury i zachowania obiektów nadklass. Poprzez dostarczenie opisu wyjaśniającego zasady organizacji struktury dziedziczenia, można pośrednio wpływać na jej racjonalny rozwój, nawet nie zawsze w kierunku przewidzianym przez jej twórcę.

• Polimorfizm metod wspiera redukcję złożoności pozwalając, by nowe bardziej wyspecjalizowane komponenty mogły być wykorzystywane w tym samym środowisku, co mniej wyspecjalizowane, bez potrzeby zmiany środowiska przy każdej zmianie komponentów, związanej z rozszerzeniami wynikłymi ze specjalizacji.

• Polimorfizm parametryczny wspomaga redukcję złożoności umożliwiając definiowanie rodziny klas o takim samym interfejsie i implementacji, różniących się jedynie typem wyspecyfikowanym jako parametr klasy, np. klasa WEKTOR(int) czy WEKTOR(char).