Wprowadzenie do Analizy i Projektowania Obiektowego 2000.ppt

Wprowadzenie do Analizy i Projektowania Obiektowego

Ministerstwo FinansówCentralny Ośrodek Doskonalenia Kadr, Dębe17 listopada 2000

Wykładowca: dr hab. inż. Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawaprofesor, kierownik Katedry Systemów Informacyjnych

Instytut Podstaw Informatyki PAN, Warszawadocent

[email protected]/~subieta

K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 2 17 listopad 2000

Plan szkoleniaWykład 1 ( 9:00 - 9:45): Przedmiot inżynierii oprogramowania

Wykład 2 ( 9:45 - 10:30): Cykl życiowy oprogramowania,metodyki tworzenia oprogramowania

Wykład 3 (10:30 - 11:15): Wprowadzenie do obiektowości, cz.1 Przerwa

Wykład 4 (11:45 - 12:30): Wprowadzenie do obiektowości, cz.2

Wykład 5 (12:30 - 13:15): Diagramy klas

Wykład 6 (13:15 - 14:00): Diagramy przypadków użyciaPodsumowanie


Wykład 1: Przedmiot inżynierii oprogramowania

Zagadnienia inżynierii oprogramowaniaKryzys oprogramowaniaZłożoność projektu oprogramowaniaModelowanie pojęcioweNiezgodność modelu pojęciowego i realizacyjnego


Przedmiot inżynierii oprogramowaniaInżynieria oprogramowania jest wiedzą dotycząca wszystkich faz cyklu życia oprogramowania oraz wszystkich aspektów tworzenia i utrzymania oprogramowania. Traktuje oprogramowanie jako produkt, który ma spełniać potrzeby biznesowe, organizacyjne lub społeczne.

Dobre oprogramowanie powinno być: zgodne z wymaganiami użytkownika, jakościowe, niezawodne, efektywne, łatwe w pielęgnacji, ergonomiczne.

Produkcja oprogramowania jest procesem składającym się z wielu faz i obejmuje wiele aspektów, takich jak dokumentowanie i zarządzanie. Kodowanie (pisanie programów) jest tylko jedną z tych faz, często nie najważniejszą.


Teorie w inżynierii oprogramowaniaInżynieria oprogramowania jest wiedzą empiryczną, syntezą ludzkiego doświadczenia z tysięcy ośrodków zajmujących się budową oprogramowania.

Teorie, metody matematyczne w inżynierii oprogramowania skompromitowały się. Były one tworzone przez osoby niekompetentne w zakresie rzeczywistych problemów, manifestujących bardziej pęd do naukowych karier niż zainteresowanie tymi problemami. Wieloletni nacisk środowisk uniwersyteckich na tego rodzaju wiedzę i badania spowodował liczne patologie, m.in. dramatyczny niedorozwój polskiej kadry akademickiej w tej dziedzinie, zaniedbanie właściwej dydaktyki na większości polskich uczelni, itd. Odpowiedzialność za to bezpośrednio spada na prominentnych przedstawicieli uniwersyteckiej informatyki.

Konieczne jest ostrzeżenie polskiego środowiska informatycznego przed tego rodzaju pseudo-wiedzą i pseudo-specjalistami. "Nie!" dla scholastyki, wykorzystywania matematyki i haseł inżynierii oprogramowania jako wehikułów do karier!


Zagadnienia inżynierii oprogramowania (1)Analiza strategicznych uwarunkowań projektu oraz planowanego systemu w kontekście realizowanych funkcji biznesowych.

Inżynieria wymagań użytkownika i wymagań na tworzony system.

Zarządzanie przedsięwzięciami związanymi z projektowaniem i wdrożeniem oprogramowania, zarządzanie ryzykiem.

Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć informatycznych,

Metody estymacyjne i pomiarowe dotyczące procesów projektowych i produktów programistycznych.

Metodyki analizy, projektowania i konstrukcji systemów.

Informatyczne narzędzia wspomagania inżynierii oprogramowania (narzędzia CASE).


Zagadnienia inżynierii oprogramowania (2)

Techniki testowania, weryfikacji i walidacji oprogramowania, zarządzanie jakością oprogramowania.

Przygotowania dokumentacji technicznej i użytkowej.

Zarządzanie konfiguracjami i wersjami oprogramowania, repozytoria dokumentacji i oprogramowania.

Integracja, instalacja i wdrażanie oprogramowania.

Szkolenie kadr z zakresu inżynierii oprogramowania, metody dydaktyczne, szkolenie użytkowników oprogramowania.Pielęgnacja i serwis oprogramowania (usuwanie błędów, modyfikacje i rozszerzenia).

Organizacja zespołów projektowych, techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.


Kryzys oprogramowania (1)Sprzeczność pomiędzy odpowiedzialnością, jaka spoczywa na współczesnych SI, a ich zawodnością wynikającą ze złożoności i ciągle niedojrzałych metod tworzenia i weryfikacji oprogramowania.

Ogromne koszty utrzymania oprogramowania.

Niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania; niski stopień powtarzalności poszczególnych przedsięwzięć.

Długi i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo niepowodzenia projektu programistycznego.

Długi i kosztowny cykl życia SI, wymagający stałych (często globalnych) zmian.

Eklektyczne, niesystematyczne narzędzia i języki programowania.


Kryzys oprogramowania (2)

Frustracje projektantów oprogramowania i programistów wynikające ze zbyt szybkiego postępu w zakresie języków, narzędzi i metod oraz uciążliwości i długotrwałości procesów produkcji, utrzymania i pielęgnacji oprogramowania.

Uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są stabilne w długim horyzoncie czasowym.

Problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych.

Problemy przystosowania istniejących i działających systemów do nowych wymagań, tendencji i platform sprzętowo-programowych.


Walka z kryzysem oprogramowaniaStosowanie technik i narzędzi ułatwiających pracę nad złożonymi systemami;

Korzystanie z metod wspomagających analizę nieznanych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń;

Usystematyzowanie procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i monitorowanie;

Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia.

Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania.


Źródła złożoności projektu oprogramowania

Zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji.

Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów.

Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć,języki, narzędzia, udogodnienia.

Oprogramowanie:decyzje strategiczne,

analiza, projektowanie,konstrukcja,

dokumentacja,wdrożenie,szkolenie,

eksploatacja,pielęgnacja,

modyfikacja. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.


Jak walczyć ze złożonością ?Zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości.

Zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy.

Zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd.

Zasada sprzyjania naturalnym ludzkim własnościom:dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata.


Modelowanie pojęcioweProjektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania.

Pojęcia modelowania pojęciowego (conceptual modeling) oraz modelu pojęciowego (conceptual model) odnoszą się procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem.

Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu.


Perspektywy w modelowaniu pojęciowym

Percepcja rzeczywistego

świata

Analitycznymodel

rzeczywistości

Model struktur danych

i procesów SI

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

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

Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz konstrukcji SI jest dążenie do minimalizacji luki pomiędzy myśleniem o rzeczywistym problemie a myśleniem o danych i procesach zachodzących na danych.

odwzorowanie odwzorowanie


Niezgodność modelu pojęciowego i realizacyjnego (przykład)

FirmaNazwaMiejsce *

PracownikZawód *

OsobaNazwiskoImię *Adres *

ZatrudnienieWypłata *Ocena *

FZ PZ

Firma(NrF, Nazwa)

Lokal(NrF, Miejsce) Zatrudnienie(NrF, NrP)

Pracownik(NrP, NrOs)

Oceny(NrOceny, Ocena, NrF, NrP)

Dochód(NrDochodu, Wypłata, NrF, NrP) Osoba(NrOs, Nazwisko)

Wyszkolenie(Zawód, NrP)

Imiona(NrOs, Imię) Adresy(NrOs, Adres)

0..* 0..*1 1Pojęciowyschematobiektowy:

Schematrealizacyjny(relacyjny):


SBQL: (Firma where ”Radom” in Miejsce).FZ.Zatrudnienie.PZ.Pracownik.Adres

SQL: select a.Adres from Lokal as k, Zatrudnienie as z, Pracownik as p, Osoba as s, Adresy as a where k.Miejsce = “Radom” and k.NrF = z.NrF and z.NrP = p.NrP and p.NrOs = s.NrOs and s.NrOs =a.NrOs

Zapytanie w SQL jest znacznie dłuższe od zapytania w SBQL wskutek tego, że w SQL konieczne są „złączeniowe” predykaty (takie jak k.NrF=z.NrF i następne) kojarzące informację semantyczną, która została „zgubiona” w relacyjnej strukturze danych.

Skutki niezgodności pojęć i ich realizacjiSchemat relacyjny jest trudniejszy do odczytania i zinterpretowania przez programistę. Efektem jest zwiększona skłonność do błędów (mylnych interpretacji).

Programy manipulacyjne odwołujące się do schematu relacyjnego są dłuższe od programów odwołujących się do schematu obiektowego (szacunkowo od 30% do 70%). Programy te są często wolniejsze, trudniejsze do pielęgnacji.Mini-przykład:

Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu


Wykład 2: Cykl życiowy oprogramowania,

metodyki tworzenia oprogramowania

Cykl życiowy oprogramowaniaModele cyklu życia oprogramowaniaCo to jest metodyka (metodologia)?Metodyki obiektoweKlasyczna i obiektowa struktura aplikacji


Elementy cyklu życiowego oprogramowania

Faza strategiczna: cele, planowanie i definicja projektu.Określenie wymagań użytkownika.Analiza: dziedziny biznesu, wymagań na oprogramowanie.Projektowanie: pojęciowe, logiczne, szczegółowe.Implementacja/konstrukcja.Testowanie.Integracja oprogramowania.Instalacja.Przygotowanie użytkowników, akceptacja, szkolenie.Działanie, włączając wspomaganie tworzenia aplikacji, serwis i pielęgnację.


Zagadnienia wspólne dla wszystkich faz

Dokumentacja (analizy, projektu, kodu, techniczna, użytkownika, itd.).

Metody i narzędzia wspomagające analizę, projektowanie, konstrukcję i dokumentowanie oprogramowania.

Zarządzanie konfiguracjami i wersjami oprogramowania.

Zarządzanie przedsięwzięciem projektowym, w tym zarządzanie ryzykiem.

Weryfikacja, walidacja i zarządzanie jakością oprogramowania.

Metryki (metody pomiarowe) i metody estymacyjne dotyczące procesów, produktów i zasobów.


Uwarunkowania wpływające na cykl życia oprogramowania

Jakość, szczegółowość i stabilność wymagań użytkownika oraz wymagań na oprogramowanie.

Dekompozycja projektu na podprojekty (moduły oprogramowania).

Zależności czasowe pomiędzy podprojektami lub modułami.

Zależność projektu od kontekstu, np. nad-projektu lub innych projektów realizowanych równolegle przez inne zespoły.

Zmiany technologii informatycznych lub modeli biznesowych.

Zmiany wykonawców projektu lub zespołów projektowych


Modele cyklu życia oprogramowania

Model kaskadowy (wodospadowy)

Model spiralny

Model kaskadowy z prototypowaniem

...

Określenie wymagań Projektowanie Implementacja Testowanie Pielęgnacja

Faza strategiczna Analiza Instalacja

Dokumentowanie

Tego rodzaju modeli (oraz ich mutacji) jest bardzo dużo. Podręcznikowe modele cyklu życia oprogramowania są najczęściej idealizacją rzeczywistości. Dla każdego projektu należy wypracować własny cykl życiowy.


Model kaskadowy (wodospadowy)

Określeniewymagań

Projektowanie

Implementacja

Testowanie

Wdrożenie

Analiza

W wielu przypadkach niezbędny.Wygodny do planowania i rozliczania.W wielu przypadkach zbyt idealistyczny. Pielęgnacja


Jeżeli ocena nie jest w pełni pozytywna, rozpoczyna się kolejny cykl.

Model spiralny

Formułowanie wymagań Projektowanie

KonstrukcjaWdrożenie.

Start

Analiza

Testowanie

W wielu przypadkach trudny do zaakceptowaniaze względów planistyczno-finansowych

Stop


PrototypowanieSposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie ogólnych (zgrubnych) wymagań jest stosunkowo łatwe.

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

Cele wykrycie nieporozumień pomiędzy klientem a twórcami systemu wykrycie brakujących funkcji wykrycie trudnych usług wykrycie braków w specyfikacji wymagań

Zalety możliwość demonstracji pracującej wersji systemu możliwość szkoleń zanim zbudowany zostanie pełny system


Programista

Fazy cyklu życia oprogramowania, zadania i role uczestników projektu

Projekt

Pod-projekt 1 Pod-projekt 2 .....

Zadanie 11 Zadanie 12 Zadanie 21 Zadanie n1..... ..........

Kierownik Analityk Programista Analityk .....

Faza A Faza B Faza B Faza C.....

Role

Zespół 1 Zespół 2 Zespół 3 ..... Zespoły

Nowak Kowalski Maliniak Dudek ..... Osoby

Projekty

Pod-projekty

Fazy

Zadania

.....

.....

.....

Kierownik


Co to jest metodyka (metodologia)?Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego, logicznego i/lub fizycznego.

Metodyka jest powiązana z notacją służącą do dokumentowania wyników faz projektu (pośrednich, końcowych), jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem.

Metodykaustala:

• fazy projektu, role uczestników projektu,• modele tworzone w każdej z faz,• scenariusze postępowania w każdej z faz, • reguły przechodzenia od fazy do następnej fazy, • notacje, których należy używać,• dokumentację powstającą w każdej z faz.


Notacje w analizie i projektowaniu

Rodzaje notacji

Język naturalny Notacje graficzne Specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny

Szczególne znaczenie maja notacje graficzne. Inżynieria oprogramowania wzoruje się na innych dziedzinach techniki, takich jak elektronika i mechanika. Zalety notacji graficznych potwierdzają badania psychologiczne.

Funkcje notacji Narzędzie pracy analityka i projektanta, zapis i analiza pomysłów Współpraca z użytkownikiem Komunikacja z innymi członkami zespołu Podstawa implementacji oprogramowania Zapis dokumentacji technicznej


Główne aspekty notacjiDowolna notacja (czyli język) posiada trzy ważne aspekty.

Popularne notacje (przypisane do metodyk i narzędzi CASE) definiują składnię .

W większości przypadków, semantyka jest jasna, ale dla niektórych oznaczeń można mieć wątpliwości. Semantyka notacji stosowanych w metodologiach z reguły nie posiada (i nie może posiadać) algorytmicznej precyzji, ponieważ odwołuje się do ludzkiego wyobrażenia (a nie do listy rozkazów komputera).

Najtrudniejszą stroną wszystkich metodyk i ich notacji jest pragmatyka. Określa ona, jak w konkretnej sytuacji zastosować przyjętą notację oraz jak ją zinterpretować w dalszych fazach projektowania i konstrukcji oprogramowania. Pragmatykę można objaśniać wyłącznie na przykładach. Nauczanie pragmatyki jest trudne, oparte na próbach i błędach, zależne od stylu i wierzeń nauczającego.

Składnia określa, jak budować poprawne wyrażenia (diagramy) z przyjętych oznaczeń (symboli).

Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami.

Pragmatyka określa, jak i do czego należy używać przyjętych oznaczeń.


Metodyki obiektowe i strukturalne

Metodyki strukturalne - metody tradycyjne. Łączą statyczny opis danych ze statycznym opisem procesów.

Metodyki obiektowe - rozwijane od lat 80-tych, oparte na wyróżnianiu klas obiektów łącznie z operacjami.

Analiza strukturalna (structured analysis) rozpoczyna się od budowy dwóch modeli systemu: modelu danych (zwykle model encja-związek, ERD) oraz modelu funkcji (zwykle model przepływu danych, DFD). Te dwa modele są integrowane oraz doprowadzane do wzajemnej spójności.

Wadą metodyk strukturalnych jest słabe uwzględnienie modelowania pojęciowego, co owocuje większą dowolnością (przypadkowością) wyborów przy przejściu od projektu do konstrukcji oprogramowania.

Ostatnio metodyki obiektowe są bardziej popularne. Wiele obecnych narzędzi CASE jest oparte na metodykach obiektowych.


Co to jest “metodyka obiektowa”?Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego oraz analizy i projektowania systemów informatycznych.

Podstawowym składnikiem jest diagram obiektów, będący zwykle wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek.

Diagram obiektów zawiera: klasy, w ramach klas specyfikacje atrybutów i metod, związki generalizacji, związki asocjacji i agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia.

Uzupełnieniem tego diagramu są inne: diagramy dynamiczne uwzględniające stany i przejścia pomiędzy tymi stanami, diagramy zależności pomiędzy wywołaniami metod, diagramy funkcjonalne (będące zwykle pewną mutacją diagramów przepływu danych), itd.

Popularność zdobyła koncepcja przypadków użycia (use cases), której podstawowym celem i walorem jest odwzorowanie struktury systemu z punktu widzenia jego użytkownika.


Metodyki obiektowe

Martin/Odell

BON (Business Object Notation), Nerson & Walden

OODA, Booch Catalysis, D’Souza & Wills

EROOS (Entity-Relationship Object-Oriented Specification)

Fusion, HP Laboratories

MOSES/OPEN (Methodology for OO Software Engineering of Systems)

OORAM

OSA

OOSA, Shlaer-Mellor

Sintropy

OMT, Rumbaugh

Objectory, Jacobson

OOA/OOD, Coad/Yourdon

DOOS, Wirfs-Brock

MainstreamObjects, YourdonExpress

Goldberg/Rubin

1985-2000: Eksplozja metodyk i notacji obiektowych. Powstało ich ponad 20.Obecnie obserwuje się ich zredukowanie, koncentrację: UML, OPEN, BON,...


Różnice pomiędzy metodykami

Podejścia proponowane przez różnych autorów różnią się częściowo, nie są jednak ze sobą sprzeczne.

Poszczególne metodyki zawierają elementy rzadko wykorzystywane w praktyce (np. model przepływu danych w OMT).

Notacje proponowane przez różnych autorów nie są koniecznie nierozerwalne z samą metodyką. Np. notacji UML można użyć dla metodyki Coad/Yourdon.

Nie ma metodyk uniwersalnych. Analitycy i projektanci wybierają kombinację technik i notacji, która jest w danym momencie najbardziej przydatna. Wybór może być jednak utrudniony istniejącą rutyną w danej firmie.

Narzędzia CASE nie narzucają metodyki; raczej, określają one tylko notację.Twierdzenia, że jakieś narzędzie CASE “jest oparte” na konkretnej metodyce jest często wyłącznie hasłem reklamowym.


Relacyjna i obiektowa struktura aplikacji

Klasyczna struktura aplikacji

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

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

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

Typy

Biblioteki procedur i funkcji

Modułyaplikacyjne

Słowniki,katalogi

Procedury bazy danych,perspektywy, reguły

Pasywne dane(relacje)

Powiązane obiekty

Klasy i typy.........

...

...

...

.........

...

...

......

......

Obiektowa struktura aplikacji

...

Biblioteki procedur i funkcji

Modułyaplikacyjne

Słowniki,katalogi

Procedury bazy danych,perspektywy, reguły

Schematbazy danych

Schematbazy danych

Zmiana metodyki pociąga za sobą zmianę struktury aplikacji.


Wpływ środków implementacyjnych na metodykę

Strukturę aplikacji wymuszają zastosowane narzędzia, np. relacyjny SZBD. Zmiany w konstrukcji oprogramowania mogą więc nie być zasadnicze.

Obiektowość jest istotna na poziomie dokumentowania wyników faz analizy i projektowania.

Tradycyjne narzędzia implementacyjne wymuszają konieczność odwzorowania tych wyników na struktury danych i funkcje zgodne z zastosowanym narzędziem (np. odwzorowanie obiektowego diagramu klas na tabele w relacyjnej bazie danych).

Jest to dzisiejsza rynkowa sytuacja, która jest niekorzystna dla rozwoju obiektowych metod projektowania systemów.

Jest nadzieja, że w niedługiej przyszłości ulegnie to poprawie.


Wykład 3: Wprowadzenie do pojęć obiektowości (1)

Źródła i motywacje obiektowości

Obszary oddziaływania obiektowości

Przeszkody dla obiektowości

Podstawowe pojęcia obiektowości

Obiekty, atrybuty, obiekty złożone

Powiązania pomiędzy obiektami, asocjacje


Źródła obiektowości

Współczesnepojęcia

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 czynnik ludzki w tworzeniu oprogramowania,

zmniejszenie dystansu pomiędzy modelem pojęciowym a modelem

realizacyjnym


Motywacje dla obiektowości

Celem nadrzędnym obiektowości jest lepsze dopasowaniu modeli pojęciowych i realizacyjnych systemów do wrodzonych ludzkich instynktów, własności psychologicznych i mentalnych mechanizmów percepcji i rozumienia świata.

Miliony lat ewolucji wykształciło mechanizmy percepcji i klasyfikacji, których podstawą jest wyróżnianie obiektów o określonych granicach, posiadających odpowiedniki językowe i podlegających określonemu zachowaniu.

Centralnym punktem zainteresowań tej informatycznej ideologii jest człowiek (analityk, projektant, programista), którego wrodzone mechanizmy percepcji świata są wykorzystane do budowania wizji wnętrza systemu informatycznego.

Obiektowość - w założeniu - bazuje na własnościach i mechanizmach ludzkiego umysłu na podobnej zasadzie jak koncepcja klawiatury komputera bazuje na anatomicznym fakcie posiadania przez ludzi rąk i palców.

Naturalne ludzkie predyspozycje są wzmacniane poprzez mechanizmy abstrakcji (hermetyzacji), modelowania, klasyfikacji, dekompozycji i ponownego użycia.

Misja obiektowości: walka ze złożonością.


Obszary oddziaływania obiektowościMetodyki analizy i projektowania SI, narzędzia CASE. Pojęcia obiektowości jako podstawa ideologiczna i koncepcyjna.

Języki programowania (Smalltalk, C++, Java, Eiffel,...). Obiekty, klasy, metody, dziedziczenie, hermetyzacja, polimorfizm.

Bazy danych i składy trwałych obiektów (standard ODMG, Gemstone, Versant, ObjectStore, Objectivity/DB, O2, Poet, ...). Przeniesienie obiektowych technologii programowania na grunt baz danych. Obiektowość w systemach relacyjnych, systemy obiektowo-relacyjne.

Współdziałanie systemów heterogenicznych (OMG CORBA, COM/DCOM,...). Obiekty i klasy jako abstrakcyjny poziom przykrywający szczegóły implementacji.

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

Inne: biblioteki oprogramowania, grafika, miary i oceny oprogramowania, re-inżynieria procesów biznesowych (BPR).


Przeszkody dla obiektowościZastany świat środkow programistycznych (C, Basic, Fortran, ...)Zastane wierzenia, mity, fałszywe stereotypy i przekręty:

Ogromne inwestycje w relacyjne bazy danych.Konkurencja technologicznie dojrzałych systemów relacyjnych (i ich następców tzw. "obiektowo-relacyjnych").Własna słabość: niedopracowane zasady, formalizmy, języki, standardy; kompromisy w zakresie celów.

• Relacyjna baza danych zapewnia prostotę struktur danych. • Relacyjne bazy danych mają solidne podstawy matematyczne.• Wskaźniki/hermetyzacja/... w bazie danych są niekorzystne.• Tylko relacyjne bazy danych umożliwiają realizację języków zapytań.• SQL jest uniwersalną i unikalną ("intergalaktyczną") mową danych.• Tylko relacyjna baza danych zapewnia przetwarzanie transakcji/rozproszenie/...• Relacyjne bazy danych mają nieosiągalną dla innych wydajność/skalowalność/...


Podstawowe pojęcia obiektowości (1)

Obiekty, tożsamość. Złożone struktury danych z przypisanymi do nich operacjami, czyli obiekty, z unikalnymi identyfikatorami.

Powiązania, asocjacje. Obiekty mogą być powiązane związkami o charakterze wskaźników.

Hermetyzacja (encapsulation). Informacja o obiekcie jest zamknięta w jednej bryle. Niepotrzebna informacja jest ukryta.

Klasy, typy, interfejsy. Cechy niezmienne dla grup obiektów, np. definicje ich atrybutów i operacji, są zbierane wewnątrz klas. Typy umożliwiają kontrolę budowy obiektów i poprawności ich użycia. Specyfikacja klasy (interfejs) jest oddzielona od jej implementacji.

Abstrakcyjne typy danych. Dostęp do struktur danych odbywa się wyłącznie poprzez zdefiniowany dla tych struktur zestaw operacji.


Podstawowe pojęcia obiektowości (2)Operacje, metody, komunikaty. Operacja na obiekcie jest wykonywana przy pomocy jednej z jego metod, po wysłaniu komunikatu do obiektu.

Hierarchia klas i dziedziczenie. Klasy są organizowane w hierarchię. Klasy bardziej szczegółowe dziedziczą cechy klas bardziej ogólnych (m.in. definicje atrybutów i metod).

Przesłanianie, późne wiązanie, polimorfizm. Ten sam komunikat wysłany do różnych obiektów może wywoływać różne operacje. Wiązanie nazw operacji następuje na etapie wykonania. Metoda z klasy bardziej ogólnej może być przesłonięta przez inna metodę z klasy wyspecjalizowanej.

Trwałość. Niektóre obiekty zachowują swój stan dłużej niż czas pojedynczego uruchomienia programu.


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ć, ...).

Obiekt posiada swoją tożsamość, która wyróżnia go spośród 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.

Obiektem jest rzecz lub pojęcie obserwowane w świecie rzeczywistym którego dotyczy SI. 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).


Obiekty (2)Obiekt może być złożony, tj. może składać się z mniejszych obiektów.Obiekt złożony odnoszący się do modelowanej rzeczywistości zawiera w sobie wszystkie cechy modelowanego obiektu.

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 przypisany typ, tj. wyrażenie językowe, które ogranicza budowę obiektu, ustala operacje, które wolno wykonać na obiekcie, oraz ogranicza kontekst, w którym dany obiekt może być użyty w programie.


Przykład obiektu

WypłaćWpłać

Sprawdźstan

UpoważnijZmień

upoważnienie

Porównajpodpis

Zlikwidujkonto

Nalicz procent

KONTONumer 123-4321

SaldoZł 34567

Właściciel Jan Kowalski

Upoważniony Ewa Kowalska

....


Atrybuty obiektu, obiekty złożone

Obiekt może składać się z pewnej liczby komponentów (atrybutów), które także mogą być złożone.

Komponenty obiektu mogą być traktowane jako obiekty („pod-obiekty”) lub mogą być uważane za kategorię różną od obiektów.

Nie powinno istnieć ograniczenie rozmiaru obiektu, liczby komponentów składających się na obiekt, liczby poziomów hierarchii komponentów lub rozmiarów/typów komponentów.

Obiekt złożony reprezentujący pewien byt świata rzeczywistego powinien zawierać wewnątrz siebie wszelkie informacje, które odnoszą się do tego bytu.

Ustalenia, które informacje odnoszą się do danego obiektu, a które do innego, zależą od modelu pojęciowego projektanta lub programisty i nie powinny podlegać ograniczeniom ze strony bazy realizacyjnej.


Przykład obiektu złożonego

Pracownicy

.....

PracownikZatrudnienia

.....

Zatrudnienie

Zatrudnienie

Stanowisko

Nazwisko

Dzieci...

Dziecko Dziecko

PracownikZatrudnienia

.....

Zatrudnienie

Zatrudnienie

Stanowisko

Nazwisko

Dzieci...

Dziecko Dziecko


Powiązania pomiędzy obiektami, asocjacje

FIRMA

NrFirmy 102030

Nazwa Syntex

PrezesZatrudnia

Zatrudnia

Zatrudnia

PRACOWNIKNazwisko NowakZarobek 1500PracujeW

PRACOWNIKNazwisko BabelZarobek 2000PracujeW

PRACOWNIKNazwisko KowalZarobek 2500PracujeW

PRACOWNIK Nazwisko Zarobek

FIRMA NrFirmy

Nazwa

Prezes Zatrudnia

PracujeW0..*

0..1

Diagram klas:

Na poziomie realizacyjnym powiązania pomiędzy obiektami można sobie wyobrazić jako wskaźniki prowadzące od obiektu do obiektu.

Na poziomie pojęciowym powiązania nie mają charakteru wskaźników, lecz pewnych abstrakcyjnych “nitek” łączących obiekty.

Asocjacje: abstrakcyjne oznaczenia powiązań na diagramach klas.


Powiązania jako “nitki” łączące obiekty

OSOBANowak

OSOBABober

OSOBAKowalska

OSOBABielicka

OSOBAMaciąg

OSOBAWilczek

Transakcja

KupującySprzedający

Pośrednik

TransakcjaKupujący

Sprzedający

Pośrednik

TransakcjaKupujący

Sprzedający

Pośrednik

OSOBA Nazwisko

Sprzedający Kupujący

Transakcja

Pośrednik Diagram klas:


Wykład 4: Wprowadzenie do pojęć obiektowości (2)

Atrybuty powiązań

Liczność asocjacji

Hermetyzacja i ukrywanie informacji

Metody i komunikaty

Klasy

Generalizacja, specjalizacja, dziedziczenie

Polimorfizm

Wielokrotne dziedziczenie


Atrybuty powiązań

OSOBANowak

OSOBABober

OSOBAKowalska

OSOBABielicka

OSOBAMaciąg

OSOBAWilczek

Kupujący Sprzedający

Kupujący

Sprzedający

Pośrednik

TransakcjaSamochód1998.05.1520000

Kupujący

Sprzedający

Pośrednik

Pośrednik

DaneTransakcji PrzedmiotTransakcji DataTransakcji WartośćTransakcji

TransakcjaDom1992.11.05300000

TransakcjaPlac1995.08.1640000

Pośrednik

OSOBA Nazwisko


Transakcja

Diagram klas:


Modelowanie powiązań jako obiektów

OSOBANowak

OSOBABober

OSOBAKowalska

OSOBABielicka

OSOBAMaciąg

OSOBAWilczek


KupującySprzedający

Pośrednik


Pośrednik

Pośrednik

TRANSAKCJADom

1992.11.05300000

TRANSAKCJAPlac

1995.08.1640000

TRANSAKCJASamochód1998.05.15

20000

0..*

0..*0..*

Pośrednik

OSOBA Nazwisko


Diagram klas:

Transakcja PrzedmiotTransakcji DataTransakcji WartośćTransakcji



A B: min = 1, max = 1

Oznaczenia liczności nadiagramie klas:

A A AA A

B B B

A

B

1..*

B A: min = 1, max = n

B B B

A

B

0..*

1..*

A A AA A

B: min = 1, max = nA

A: min = 0, max = nB

B B B

A

B

0..*

0..1

A A AA A

B: min = 0, max = 1A

A: min = 0, max = nB


Hermetyzacja i ukrywanie informacjiHermetyzacja: zamykanie szczegółów w bryłę, którą można manipulować tak jak jednostką (tworzyć, przesuwać, kopiować, usuwać, zabezpieczać, itd.).

Ukrywanie informacji: programista ma tyle wiedzieć o procedurze, module, obiekcie, itd., ile mu trzeba, aby go efektywnie używać. Wszystko, co może być przed nim ukryte, powinno być ukryte. Jest to ważne z punktu widzenia efektywności tworzenia oprogramowania (nie musi interesować się szczegółami) oraz bezpieczeństwa i niezawodności (nie może nic zepsuć).

Hermetyzacja i ukrywanie informacji są podstawowymi zasadami dowolnej inżynierii, włączając inżynierię oprogramowania. Np. telewizor jest hermetyzowaną bryłą ukrywającą ogromną liczbę szczegółów, które nie są interesujące dla użytkowników. Dla nich istotny jest tylko "interfejs" telewizora, tj. ekran i przyciski na pilocie. Rozhermetyzowanie tej bryły (zdjęcie obudowy) grozi porażeniem użytkownika i uszkodzeniem aparatu!

Pewne mechanizmy hermetyzacji są zrealizowane w systemach relacyjnych (np. perspektywy i procedury BD w SQL). Są one jednak zbyt słabe, chociażby w stosunku do języków programowania takich jak Modula-2.


Wewnętrzna i zewnętrzna struktura obiektu

PRACOWNIK

NAZWISKO Nowak ROK_UR 1951

ZAROBEK 2500

ZmieńZarobek(...) {...};

Podatek(){...};ZarobekNetto() {...};

Wiek() { return RokBież - ROK_UR };

DZIAŁ Zabawki

Wewnętrzna struktura obiektu Zewnętrzna struktura obiektu

PRACOWNIK

NAZWISKO Nowak

ZmieńZarobek(...)

ZarobekNetto()

Wiek()

DZIAŁ Zabawki


Metody i komunikaty

Numer 123-4321SaldoZł 34567Właściciel Jan KowalskiUpoważniony .......

WpłaćWypłać

Sprawdźstan

UpoważnijZmień

upoważnienie

Porównajpodpis

Zlikwidujkonto

Nalicz procent

Wypłać ( 1000 )

OK, wypłaciłem

Graj

??? błąd!

KONTO

Komunikat jest wyrażeniem językowym skierowanym do obiektu. Nazwa użyta w komunikacie jest nazwą metody skojarzonej z obiektem. Źródłem komunikatu jest pewien obiekt lub aktualnie działający program. Komunikat może mieć parametry. Obiekt otrzymujący komunikat wykonuje odpowiednią metodę, która może zmienić jego stan.

Po wykonaniu metody obiekt, który otrzymał komunikat, może zwrócić odpowiedź do obiektu lub programu, który go wysłał. Odpowiedź nie jest komunikatem.


Komunikat a wołanie proceduryWołanie procedury: obiekt jest komunikowany jako parametr:

procedura( obiekt, par1, par2,...)

Komunikat: obiekt-adresat poprzedza wywołanie metody: obiekt.metoda(par1, par2,...)

Komunikat nie określa która konkretnie metoda ma być wywołana; komunikat jest kierowany do obiektu, i w zależności od niego może być wywołana zupełnie inna metoda.

Pojęcia są bardzo podobne:

Zasadnicza różnica:

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

Musi być przełączenie explicite wewnątrz procedury dochody; procedurę musi pisać jeden programista, na wszystkie okazje.

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

Nie ma przełączenia; wywoływana jest zupełnie inna metoda dochody w zależności od obiektu - adresata komunikatu. Te metody (i ich programiści) nie muszą nic o sobie wiedzieć.


Przesyłanie komunikatów a równoległośćCzęsto termin „przesyłanie komunikatów” (message passing) jest mylnie interpretowany. Zgodnie z wypowiedziami niektórych autorów, obiekty komunikują się ze sobą asynchronicznie i równolegle poprzez mechanizm komunikatów, zaś obiektowość postuluje taką równoległość (lub wręcz rozwiązuje problem równoległości).

Są to poglądy nieuzasadnione. Są one oparte na budowaniu analogii ze światem rzeczywistym, gdzie obiekty posiadają własną autonomię i funkcjonują niezależnie od siebie, komunikując się między sobą w ramach swoich potrzeb.

Obiektowość nic takiego nie zakłada. Przetwarzanie równoległe jest ważnym i trudnym problemem, całkowicie niezależnym w stosunku do obiektowości, a w szczególności do mechanizmu przesyłania komunikatów.

Komunikat należy rozumieć jako obiektowy odpowiednik wołania procedury.


Klasy

Klasa jest miejscem przechowywania cech obiektów, które są niezmienne (inwariantów). Klasa nie jest zbiorem obiektów i nie jest definicją zbioru obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus niektóre własne.

Najważniejsze inwarianty to:

Możliwe są inne inwarianty:

Zdarzenia lub wyjątki, które mogą zajść w operacjach na obiekcieObsługa zdarzeń lub wyjątkówLista eksportowa, określająca, które atrybuty dostępne są z zewnątrzOgraniczenia, którym musi podlegać każdy obiekt......

Nazwa, czyli językowy identyfikator obiektuTyp, czyli statyczna budowa obiektu (atrybuty)Metody, czyli operacje, które można wykonać na obiekcie

Klasa jest nazwanym zbiorem obiektów o podobnych własnościach. Własności te (zestaw atrybutów, metody) są określone w definicji klasy. Stosunek klasa/podklasa oznacza zawieranie się zakresów znaczeniowych. Np. zbiór obiektów Student zawiera się w zbiorze obiektów Osoba.

Zładefinicja:

Dobradefinicja:


Klasa, interfejs, typKlasa. Zestaw cech wspólnych dla obiektów zarówno w planie ich populacji, jak i zmian zachodzących w czasie. Klasa jest jednostką ponownego użycia i obrotu handlowego. Zawiera wszystko to, co jest potrzebne do tego, aby ją umieścić wewnątrz pewnej aplikacji, w szczególności, implementację metod, implementację bloków reakcji na zdarzenia, itd.

Interfejs. Komplet informacji o tych własnościach obiektów klasy, które są niezbędne do ich poprawnego użycia. Interfejs posiada znaczenie pojęciowe dla użytkownika lub programisty, pozwalając na manipulowanie zewnętrznymi cechami obiektów i przewidywanie skutków tych manipulacji. Interfejs może być (nieodpłatnie) opublikowany w podręczniku. Pojedynczy interfejs może cechować wiele implementacji, jak również jedna klasa może być wyposażona w wiele interfejsów.

Typ. Specyfikacja ograniczająca kontekst, w którym obiekty danej klasy mogą być użyte w wyrażeniach, zapytaniach lub programach. Typ określa również reprezentację wartości przechowywanych wewnątrz obiektu. Niekiedy typ określa również wewnętrzną budowę obiektów. Typ jest pojęciem różnym zarówno od klasy jak i od interfejsu.


Wyodrębnienie klasy

Wpłać

Porównajpodpis

Zlikwidujkonto

Wpłać

Porównajpodpis

Zlikwidujkonto

WpłaćWypłać

Sprawdźstan

UpoważnijZmień

upoważnienie

Porównajpodpis

Zlikwidujkonto

Nalicz procent

Obiekty KONTO (punkt widzenia użytkownika)

Obiekty KONTO(reprezentacja wewnątrz pamięci)

Klasa KONTO

Związki “jest wystąpieniem

klasy”

Numer: char[8]SaldoZł: integerWłaściciel: stringUpoważniony: string....

WpłaćWypłać

Sprawdźstan

UpoważnijZmień

upoważnienie

Porównajpodpis

Zlikwidujkonto

Nalicz procent

KONTO

KONTO

Numer 123-4321SaldoZł 34567Właściciel Jan KowalskiUpoważniony .......

123-432134567Jan Kowalski....


Generalizacja, specjalizacja, dziedziczenieGeneralizacja: budowa pojęć bardziej ogólnych jeżeli mamy pojęcia bardziej szczegółowe.

Specjalizacja: budowa pojęć bardziej szczegółowych jeżeli mamy pojęcia bardziej ogólne.

Sklepnazwaadres

Rodzaj towaru

Firma usługowanazwaadres

Rodzaj usługi

Firmanazwaadres

SklepRodzaj towaru

Firma usługowaRodzaj usługi

Firmanazwaadres

...Rodzaj towaru?...Rodzaj usługi?

Generalizacja

Specjalizacja


PolimorfizmOSOBAnazwiskokategoria

....

....

STUDENT....

dochody()....

obiektobiektobiektobiektobiekt

PRACOWNIK....

dochody()....

EMERYT....

dochody()....

obiektobiektobiekt

Każda klasa ma własną metodę dochody.Są one niezależne i są niezależnie programowane


Ekstensja klasy

OSOBANazwisko Nowacki

RokUr 1940

OSOBANazwisko Abacki

RokUr 1948

OSOBANazwisko Nowak

RokUr 1951

OSOBA Nazwisko

RokUrWiek()

PRACOWNIKZarobek

DziałZarobekNetto()

ZmieńZarobek(...)

OSOBANazwisko Kowalska

RokUr 1975

PRACOWNIKNazwisko Nowak

RokUr 1951Zarobek 2000Dział zabawki

PRACOWNIKNazwisko Abacki

RokUr 1948Zarobek 2500Dział zabawki

PRACOWNIKNazwisko Nowacki

RokUr 1940Zarobek 3000Dział sprzedaż

Ekstensjaklasy OSOBA

Ekstensja klasy PRACOWNIK


Wielokrotne dziedziczenie

POJAZDciężar

.....prędkość_eksploat()

POJAZD_LĄDOWYilość_kół

max_prędkość.....

POJAZD_WODNYwyporność

max_prędkość.....

AMFIBIASAMOCHÓD JACHTTRAKTOR ŻAGLÓWKA

Klasa może dziedziczyć z dwóch lub więcej klas.

Wielokrotne dziedziczenie ma duże znaczenie dla modelowania pojęciowego. Jest jednak powodem anomalii i wad koncepcji, m.in. w C++. Z tego względu twórcy niektórych języków (m.in. Java) zrezygnowali z tej własności.


Wykład 5: Diagramy klas

Metoda oparta na diagramy klas

Zastosowania diagramu klas

Oznaczenia klas, atrybutów i operacji

Asocjacje

Generalizacja i dziedziczenie

Agregacje (kompozycje)

Budowa diagramu klas - ćwiczenie


Metoda oparta na diagramy klas

Diagramy klas są podstawową osią, dookoła której rozwija się każdy projekt obiektowy.

Są one odmianą dość klasycznych diagramów encja-związek (entity-relationship), ale wzbogacone o istotne nowe własności.

Podstawowymi oznaczeniami są oznaczenia klas (UML: prostokąty), oznaczenia hierarchii dziedziczenia (UML: strzałki z białym grotem), oznaczenia związków asocjacji (UML: linie) oraz oznaczenia związków agregacji (UML: białe i czarne romby).

Te podstawowe oznaczenia są uzupełnione o dużą liczbę pomocniczych oznaczeń.

Wprowadzane są rozszerzenia poprawiające czytelność diagramów i przystosowujące je do dziedziny zastosowań.


Zastosowania diagramu klas

Zapis modelu pojęciowego. Diagramy reprezentują pojęcia w dziedzinie zastosowań. Model pojęciowy nie musi być związany z oprogramowaniem; jest on wyłącznie sformalizowaną wizją wyobrażeń powstających w trakcie twórczych procesów myślowych związanych z danym problemem.

Sformalizowana specyfikacja danych i metod. Jest ona związana z oprogramowaniem, ale dotyczy jego zewnętrznego opisu (interfejsów) bez wchodzenia w szczegóły implementacyjne (hermetyzacja). Dla wielu celów zależy nam wyłącznie na określeniu cech zewnętrznych pewnych bytów programistycznych (obiektów, metod, itd.), bez wchodzenia w szczegóły. Rozróżnienie pomiędzy specyfikacją i implementacją jest charakterystyczne dla nowo powstających języków i standardów (CORBA, Java, ODMG).

Implementacja. W tym zastosowaniu diagram klas może służyć bezpośrednio jako graficzny środek pokazujący szczegóły implementacji klas, np. w C++, Java, IDL CORBA lub ODMG ODL.


Dopuszcza się różne poziomy abstrakcji i szczegółowości.

Okno Oknorozmiarczy_widoczne

Oknorozmiarczy_widocznewyświetl()schowaj()

Oknorozmiar: Obszarczy_widoczne: Booleanwyświetl()schowaj()

Okno{abstrakcyjna,

autor=Kowalskistatus=przetestowane}

+rozmiar: Obszar = (100,100)#czy_widoczne: Boolean = false+rozmiar_domyślny: Prostokąt#rozmiar_maksymalny: Prostokąt-xwskaźnik: XWindow*

+wyświetl()+schowaj()+utwórz()-dołączXWindow(xwin: XWindow*)

Prostokąt

punkt1: Punktpunkt2: Punkt

«konstruktor»Prostokąt(p1: Punkt, p2: Punkt)

«zapytania»obszar(): Realaspekt(): Real...«aktualizacje»przesuń (delta: Punkt)przeskaluj(współczynnik: Real)

Oznaczenia klas


AtrybutyAtrybut jest nazwaną wartością przechowywaną przez obiekty w ramach klasy. Niekiedy wartość atrybutu jest obiektem lub referencją do obiektu.

nazwiskowiek

atrybuty obiektu Osoba

Klasa z atrybutami

(Osoba)

Jan Nowak53

(Osoba)

Ewa Stycz24

Obiekty (wystąpienia) z wartościami

Atrybut identyfikujący obiekt (czyli klucz główny) nie jest konieczny. System obiektowy automatycznie generuje wewnętrzny unikalny identyfikator obiektu. Nie mają one znaczenia dla dziedziny problemu.

Osoba

nazwisko: stringwiek: integer


Operacja jest funkcją lub transformacją, która może być zastosowana doobiektu (lub przez obiekt). Jest ona własnością klasy obiektów.

zatrudnijzwolnijwypłać_dewidendę

operacje na obiektach klasy Firma

Wszystkie obiekty w ramach klasy podlegają tym samym operacjom.

Ta sama operacja może być zastosowana do obiektów wielu różnych klas. Jest to określane jako polimorfizm. Metoda jest implementacją operacji dla jednej klasy.

drukuj

Plik ASCII

Plik postscript

Plik graficzny

Różne operacje drukowania

Operacje i metody


Operacja/metoda może mieć argumenty (oprócz obiektu, który jest argumentem implicite). Sygnatura operacji: liczba i typ argumentów + typ wyniku operacji. Wszystkie metody implementujące daną operację muszą mieć tę samą sygnaturę.

operacje

Osoba

nazwiskowiek

zmień_pracęzmień_adres

Plik

nazwa_plikudługość_w_bajtachostatnia_zmiana

drukuj

Obiekt geometryczny

kolorpozycja

przesuń( delta: Wektor )wewnątrz( p: Punkt ): Booleanobróć( kąt )

Jeżeli argumenty nie są specyfikowane, to może ich być dowolnie dużo.

Argumenty operacji


Asocjacje

Firma OsobaPracuje_dla 1..*

Oznaczenia klas są połączone liniami oznaczającymi asocjacje, czyli powiązania pomiędzy obiektami tych klas. Np. asocjacja Pracuje_dla pomiędzy obiektami klasy Osoba i obiektami klasy Firma.

Czarny trójkącik określa kierunek wyznaczony przez nazwę powiązania. W danym przypadku określa on, że osoba pracuje dla firmy, a nie firma pracuje dla osoby.

Nazwy asocjacji, takie jak Pracuje_dla, wyznaczają znaczenie tej asocjacji w modelu pojęciowym.

Asocjacje mogą być wyposażone w oznaczenia liczności: ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy (minimalna i maksymalna liczbę takich obiektów).

Asocjacje mogą być także wyposażone w dodatkowe nazwy ról (przy odpowiednich końcach), np. pracodawca i pracownik.


Powiązanie Fizyczny lub pojęciowy związek pomiędzy wystąpieniami obiektów

Asocjacja Grupa powiązań posiadających wspólną strukturę i semantykę.Powiązanie jest wystąpieniem asocjacji.

Osoba

Firma

pracuje_w

(Osoba)Anna

(Firma)Krawiecka

pracuje_w

(Osoba)Jan

(Firma)Szewska

(Osoba)Ewa

pracuje_w pracuje_w

Klasy i asocjacja Obiekty i powiązania

Asocjacje nie mają kierunku: można “przechodzić” w dowolnym.Asocjacja może być nie nazwana, jeżeli jej znaczenie wynika z klas, które łączy.

*

Asocjacje i powiązania


Liczność jest oznaczana na końcach asocjacji binarnych.

11,2,3,...2,3,4,...3,4,52,4,1810,10,1,2,...0,1,2,...

11..*2..*3-52,4,18

0..10..**

UML znaczeniePaństwo Stolica

Firma Pracownik

Osoba Adres

1 *

0..* 0..1



W UML atrybuty asocjacji muszą tworzyć nową klasę.

Plik

Użytkownik

Prawo dostępuDostęp

Dostępny dla

czytanieczytanie-pisanie

Osoba

nazwiskopeseladres

Firma

nazwaadres

Zatrudnieniezarobekstanowisko

szef

pracownik

Pracuje_w

Ocena wydajnościocena

Kieruje

*

*

0..1

*

*

Atrybuty asocjacji


Generalizacja jest związkiem pomiędzy klasami. Łączy on klasę bardziej ogólną (nadklasę) z jedną lub więcej klas będących jej specjalizacjami (podklasami). Podklasy danej nadklasy dziedziczą wszystkie jej własności. Dziedziczenie jest przechodnie.

Pompa

ciśnienie ssaniaciśnienie tłoczeniaprzepływ

Wymiennik ciepła

powierzchnia wymianyśrednica rury

Zbiornik

objętośćciśnienie

...

typ wyposażenia

typ pompytyp zbiornika

aspekt generalizacji

Wyposażenie

nazwawytwórcakoszt

Generalizacja i dziedziczenie


Jak odróżnić agregację od asocjacji?

Artykuł

TytułAutor

Streszczenie Rozdział

Literatura

Faktura

Dane identyfikacyjne

Pozycja

Suma

Akceptacja

Kryterium istnienia: podobiekt nie może istnieć bez obiektu.

Kryterium wstawiania: podobiekt nie może być sam wprowadzony do systemu

Kryterium usuwania: usunięcie obiektu implikuje usunięcie podobiektu

Kryterium fizycznej części: jakiś obiekt jest fizyczną częścią innego obiektu

*

*

**

Agregacje (kompozycje)


Budowa diagramu klas - ćwiczenieZałożenia bazy danych uczelni:

Będą zbierane są informacje o studentach, profesorach i wykładach.

Każdy student posiada: imię, nazwisko, data urodzenia, miejsce urodzenia (miasto, województwo), miejsce zamieszkania, aktualny semestr.

Każdy student ma ustalony plan wykładów na cały okres studiów.

Każdy zaliczony wykład na danym semestrze kończy się wystawieniem oceny końcowej.

Studenci, którzy są dyplomantami, tj. ukończyli wszystkie zaplanowane wykłady, piszą pracę dyplomową, której tytuł musi być zapamiętany. Praca dyplomowa prowadzona jest pod opieką jednego z profesorów uczelni.

Po zdaniu egzaminu dyplomowego informacje o studencie uzupełniane są o datę obrony pracy oraz ocenę końcową.


Budowa diagramu klas - ćwiczenie, cd.

Każdy profesor pracujący na uczelni związany jest z jednym wydziałem, którego nazwa i telefon muszą być znane, oraz opisywany jest następującymi informacjami: imię, nazwisko, data urodzenia, tytuł, specjalność.

Uczelnia zatrudnia również profesorów kontraktowych. W takim przypadku dodatkowo należy pamiętać daty rozpoczęcia i zakończenia kontraktu.

Każdy profesor prowadzi przynajmniej jeden i co najwyżej 3 różne wykłady na uczelni, przy czym ten sam wykład może być prowadzony przez jednego tylko profesora.

Każdy profesor może prowadzić dowolną liczbę dyplomantów.

Wykład ma określony swój numer, temat, dzień oraz godzinę rozpoczęcia i zakończenia oraz odbywa się w jednym z wielu pomieszczeń uczelni, które znajdują się w różnych budynkach.

Założenia bazy danych uczelni, cd.:


Przykładowe rozwiązanie ćwiczenia

urodziła się

mieszka w1..*

MIASTONazwaWojewództwo

OSOBANazwiskoImięData_urNr_ewiden

STUDENTSemestr_studiów

PROFESORSpecjalnośćTytuł

WYDZIAŁNazwaTelefon

jest_zatrudniony_na

DYPLOMANTTytuł_pracyData_obronyOcena_końcowa

opiekuje_się

PROF_KONTRAKTOWYPocz_kontraktuKon_kontraktu

WYKŁADIdent_wykładuNazwa_wykładu

prowadzony_przez1-3

uczęszcza

PRZYPISANIEStatusSemestrOceny

SALAId_budynkuNr_sali

KALENDARZSemestrDzień tygodnia

GODZINYgodz_początkugodz_końca

odbywa się

Rozwiązanie jest niekompletne, np. brakuje metod.

*

*

*

*

*


Wykład 6: Diagramy przypadków użycia

Cel metody przypadków użycia

Podstawowe oznaczenia metody przypadków użycia

Przykłady diagramów przypadków użycia

Opis i dokumentacja przypadków użycia

Wyszukanie i analiza aktorów

Modele wykorzystujące przypadki użycia

Sporządzenie słownika pojęć


Cel metody przypadków użyciaPodstawowym problemem jest określenie wymagań na projektowany system. Celem metody opartej na przypadkach użycia jest:

Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy. Model musi być zrozumiały dla przyszłych użytkowników.

zrozumienie użycia systemu będącego przedmiotem procesu projektowania

zwiększenie stopnia świadomości analityków i projektantów co do celów tego systemu

umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami

weryfikacja poprawności i kompletności projektu

odzyskanie wszystkich strukturalnych i funkcjonalnych własności systemu

ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu

dostarczenie podstawy do sporządzenia planu testów systemu

use cases


Charakterystyka metody przypadków użycia

Model przypadków użycia dostarcza bardzo abstrakcyjnego poglądu na system z pozycji aktorów, którzy go używają. Nie włącza szczegółów, co pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie.

W późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przy pomocy notacji lub diagramów obiektowych. Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich w postaci scenariuszy.

Tworzenia przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele.


Model przypadków użycia wprowadza następujące pojęcia i notacje:

Aktor

Przypadek użycia

Aktor reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient).

Przypadek użycia reprezentuje sekwencję operacji lub transakcji wykonywanych w dialogu z systemem (np. potwierdzenie pisma, złożenie zamówienia).

Interakcja pokazuje interakcję pomiędzy przypadkiem użycia i aktorem (środowiskiem zewnętrznym).

Przypadki użycia reprezentują przepływ zdarzeń w systemie. Są one uruchamiane (inicjowane) przez aktorów. Aktorem jest dowolny byt zewnętrzny, który uczestniczy w interakcji z przypadkiem użycia.

Interakcja

Podstawowe oznaczenia metody


klientbanku

wpłata pieniędzy

wypłata pieniędzy

kasjer

sprawdźbilans

weźpożyczkę

zarządbanku

«uses»

Przykład modelu przypadków użycia


Przykład modelu przypadków użycia

Bazadanychbanku

Klient

Administratorsystemu

Prowadzeniekonta klienta

Informowanie o stanie konta klienta

Inicjalizacjakarty klienta

Weryfikacja kartyi kodu klienta

Automat do operacji bankowych

«uses»

«uses»

«uses»


Powiązania w modelu przypadków użycia

Generalizacja pomiędzy aktorami,dziedziczenie dostępudo przypadków użycia

Księgowy

Pracownik biura

«extends»

«uses»

Modeluje sytuację kiedy rozszerzający przypadek użycia definiuje wspólne lub dobrze wyodrębnione akcje. Rozszerzony przypadek użycia wykonuje wszystkie zdefiniowane w nim akcje plus niekiedy dodatkowo akcje określane przez przypadek rozszerząjący. Jest on zwykle niekompletny.

Modeluje sytuację kiedy przypadek (przypadki) użycia wykorzystuje (wykorzystują) wspólny przypadek użycia (np. blok ponownego użycia)na zasadzie podobnej do wywołania procedury.

Sekretarz Referent


Diagram przypadków użycia

Ustalenie limitów

Analiza ryzyka

Sprawy cenowe

Przekroczenie limitów

Ocena zysków

Aktualizacja rozliczeń

Wyliczenieocen

Dyrektor handlowy

Handlowiec

Sprzedawca

Systemrozliczeniowy

«extends»

«uses»

«uses»


Opis przypadku użycia

Opis przypadku użycia może być dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty:

Jak i kiedy przypadek użycia zaczyna się i kończy?

Opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane.

Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak i kiedy zapamiętuje dane w systemie?

Wyjątki przy przepływie zdarzeń.

Jak i kiedy używane są pojęcia dziedziny problemowej?


Dokumentacja przypadków użyciaTypowa dokumentacja przypadków użycia powinna zawierać następujące elementy:

Krótki opis przypadku użycia.

Przepływ zdarzeń opisany nieformalnie.

Związki pomiędzy przypadkami użycia.

Uczestniczące obiekty.

Specjalne wymagania (np. czas odpowiedzi, wydajność).

Obrazy interfejsu użytkownika.

Ogólny pogląd na przypadki użycia (powiązania w postaci diagramów).

Diagramy interakcji dla każdego aktora.


AktorzyMetoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych w jakiś sposób z projektowanym systemem.

Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy.

Metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba może pełnić rolę wielu aktorów; np. być jednocześnie sprzedawcą i klientem. I odwrotnie, jeden aktor może odpowiadać wielu osobom, np. strażnik budynku.

Każdy aktor będzie używać systemu na kilka specyficznych sposobów. Każdy z tych sposobów musi przyjąć postać przypadku użycia.


Wyszukanie aktorów

Wyszukanie potencjalnych aktorów musi być powiązane z ustaleniem granic systemu, tj. odrzucenia obszarów dziedziny problemowej, którymi system nie będzie się zajmować. Istotne są odpowiedzi na następujące pytania:

Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu?

Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje? Należy te funkcje rozbić na funkcje odnoszące się do dziedziny przedmiotowej (np. osoba rejestrująca korespondencję) i do wspomagania systemu (np. administrator systemu).

Z jakiego sprzętu zewnętrznego (komputerów, czujników, sieci, itp.) musi korzystać system aby realizować swoje funkcje?


Analiza aktorówZakresy znaczeniowe dla poszczególnych nazw aktorów, relacje pomiędzy zakresami; np. sekretarka pracownik administracji pracownik dowolna osoba.

Czy użytkownicy mogą łączyć funkcje kilku aktorów i jakich? (minimalizacja aktorów)

Jakie jest główne zadanie dla każdego aktora?

Czy aktor będzie czytał/pisał/zmieniał jakąkolwiek informację w systemie?

Czy aktor ma informować system o zmianach na zewnątrz?

Czy aktor życzy sobie być poinformowany o zmianach?

Wyjaśnić różnice pomiędzy konkretnymi użytkownikami i aktorami


Modele wykorzystujące przypadki użyciaModel przypadków użycia: definiuje zewnętrze (aktorów) oraz wnętrze (przypadki użycia), które określają zachowanie się systemu.

Obiektowy model dziedziny: przypadki użycia ustalają obiekty świata rzeczywistego relewantne dla projektowanego systemu.

Obiektowy model analityczny: przypadki użycia opisują strukturę istniejącej lub przyszłej rzeczywistości biznesowej.

Obiektowy model projektowy: przypadki użycia opisują założenia przyszłej implementacji, szczególnie interfejsów użytkownika

Model implementacyjny: przypadki użycia wyznaczają często architekturę i strukturę implementację systemu

Model testowania: przypadki użycia określają plan testów, specyfikacji i raportów.


Metoda oparta na przypadkach użycia

Krok Udokumentowany w:Sporządzenie słownika pojęć

Słownik pojęć

Ustalenie aktorów

Ustalenie przypadków użycia

Opis każdego przypadku użycia: * podział na nazwane części * wyspecyfikowanie w szczegółach * znalezienie wspólnych części w różnych przypadkach użycia

Dokument opisu aktorów

Diagram przypadków użycia

Dokument opisu przypadków użycia


Sporządzenie słownika pojęć

Polega na wyłowieniu wszystkich terminów z początkowych wymagań.

Słownik dotyczy dziedziny problemowej.

Terminy ze słownika powinny być normą przy opisie problemu, sytuacji lub modelu.

Powinny być zdefiniowane w sposób precyzyjny i jednoznaczny.

Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, aktywności, zdarzeń, itd.

Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika:

na rzeczowniki: mogą one oznaczać aktorów lub obiekty dziedziny problemowej;

na frazy opisujące funkcje, akcje, zachowanie się: mogą one być podstawą wyróżnienia przypadków użycia.


Tworzenie diagramu przypadków użycia

Wyszczególnienie pojęć

Szkicowy opis przepływu zdarzeń

Zdefiniowanie sposobu interakcji aktora z przypadkiem użycia

Ustanowienie związków uses (używa)

Ustanowienie związków extends (rozszerza)

Sporządzenie diagramu przypadków użycia, aktorów i związków

Przedyskutowanie i krytyka modelu

Sprawdzenie kompletności modelu


Inne diagramy i metody stosowane w analizie i projektowaniu obiektowym

Diagramy przypadków użycia i diagramy klas są dwiema zasadniczymi osiami, dookoła których rozwija się projekt.

Inne diagramy i związane z nimi metody umożliwiają spojrzenie na ten sam system z innych perspektyw:Diagramy pakietów

Diagramy stanów

Diagramy sekwencji

Diagramy współpracy (collaboration)

Diagramy komponentów

Diagramy wdrożeniowe (deployment)

...


PodsumowanieObiektowość jest informatyczną ideologią, która zmienia myślenie realizatorów SI z zorientowanego na maszynę na zorientowane na człowieka.

Obiektowość jest konsekwencją kryzysu oprogramowania: kosztów związanych z oprogramowaniem, jego zawodnością, i trudną do opanowania złożonością.

Obiektowość przenika wszystkie fazy projektowania, oraz narzędzia i interfejsy.

Obiektowość dopracowała się skutecznych pojęć i narzędzi, szczególnie w zakresie analizy i projektowania.

W dziedzinie baz danych obiektowość jest na początku drogi i musi walczyć z konserwą i spuścizną modelu relacyjnego.

Documents

Wprowadzenie do Analizy i Projektowania Obiektowego 2000.ppt