Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Wprowadzenie do Analizy i Projektowania Obiektowego Ministerstwo Finansów Centralny Ośrodek Doskonalenia Kadr, Dębe 17 listopada 2000 Wykładowca: dr hab.

Podobne prezentacje


Prezentacja na temat: "Wprowadzenie do Analizy i Projektowania Obiektowego Ministerstwo Finansów Centralny Ośrodek Doskonalenia Kadr, Dębe 17 listopada 2000 Wykładowca: dr hab."— Zapis prezentacji:

1 Wprowadzenie do Analizy i Projektowania Obiektowego Ministerstwo Finansów Centralny Ośrodek Doskonalenia Kadr, Dębe 17 listopada 2000 Wykładowca: dr hab. inż. Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa profesor, kierownik Katedry Systemów Informacyjnych Instytut Podstaw Informatyki PAN, Warszawa docent

2 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 2 17 listopad 2000 Plan szkolenia Wykład 1 ( 9:00 - 9:45): Przedmiot inżynierii oprogramowania Wykład 2 ( 9: :30): Cykl życiowy oprogramowania, metodyki tworzenia oprogramowania Wykład 3 (10: :15): Wprowadzenie do obiektowości, cz.1 Przerwa Wykład 4 (11: :30): Wprowadzenie do obiektowości, cz.2 Wykład 5 (12: :15): Diagramy klas Wykład 6 (13: :00): Diagramy przypadków użycia Podsumowanie

3 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 3 17 listopad 2000 Wykład 1: Przedmiot inżynierii oprogramowania Zagadnienia inżynierii oprogramowania Kryzys oprogramowania Złożoność projektu oprogramowania Modelowanie pojęciowe Niezgodność modelu pojęciowego i realizacyjnego

4 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 4 17 listopad 2000 Przedmiot inżynierii oprogramowania Inż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ą.

5 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 5 17 listopad 2000 Teorie w inżynierii oprogramowania Inż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!

6 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 6 17 listopad 2000 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).

7 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 7 17 listopad 2000 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.

8 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 8 17 listopad 2000 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.

9 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 9 17 listopad 2000 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.

10 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Walka z kryzysem oprogramowania Stosowanie 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.

11 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Ź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. 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. Ś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ść. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

12 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

13 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Modelowanie pojęciowe Projektant 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.

14 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Perspektywy w modelowaniu pojęciowym Percepcja rzeczywistego świata Analityczny model 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

15 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Niezgodność modelu pojęciowego i realizacyjnego (przykład) Firma Nazwa Miejsce * Pracownik Zawód* Osoba Nazwisko Imię * Adres * Zatrudnienie Wypłata * Ocena * FZPZ 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..* 11 Pojęciowy schemat obiektowy: Schemat realizacyjny (relacyjny):

16 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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 realizacji Schemat 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

17 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Wykład 2: Cykl życiowy oprogramowania, metodyki tworzenia oprogramowania Cykl życiowy oprogramowania Modele cyklu życia oprogramowania Co to jest metodyka (metodologia)? Metodyki obiektowe Klasyczna i obiektowa struktura aplikacji

18 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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ę.

19 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

20 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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

21 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Modele cyklu życia oprogramowania Model kaskadowy (wodospadowy) Model spiralny Model kaskadowy z prototypowaniem... Określenie wymagańProjektowanieImplementacjaTestowaniePielęgnacja Faza strategicznaAnaliza 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.

22 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Model kaskadowy (wodospadowy) Określenie wymagań Określenie wymagań Projektowanie Implementacja Testowanie Wdrożenie Analiza W wielu przypadkach niezbędny. Wygodny do planowania i rozliczania. W wielu przypadkach zbyt idealistyczny. Pielęgnacja

23 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Jeżeli ocena nie jest w pełni pozytywna, rozpoczyna się kolejny cykl. Model spiralny Formułowanie wymagań Projektowanie Konstrukcja Wdrożenie. Start Analiza Testowanie W wielu przypadkach trudny do zaakceptowania ze względów planistyczno-finansowych Stop

24 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Prototypowanie Sposó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

25 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Programista Fazy cyklu życia oprogramowania, zadania i role uczestników projektu Projekt Pod-projekt 1Pod-projekt Zadanie 11Zadanie 12Zadanie 21Zadanie n Kierownik Analityk Programista Analityk..... Faza AFaza B Faza C..... Role Zespół 1Zespół 2 Zespół Zespoły NowakKowalskiMaliniak Dudek..... Osoby Projekty Pod- projekty Fazy Zadania..... Kierownik

26 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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. Metodyka ustala: Metodyka ustala: 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.

27 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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

28 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Główne aspekty notacji Dowolna 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ń.

29 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

30 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

31 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Metodyki obiektowe Martin/Odell BON (Business Object Notation), Nerson & Walden OODA, Booch Catalysis, DSouza & 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, Yourdon Express Goldberg/Rubin : Eksplozja metodyk i notacji obiektowych. Powstało ich ponad 20. Obecnie obserwuje się ich zredukowanie, koncentrację: UML, OPEN, BON,...

32 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

33 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Relacyjna i obiektowa struktura aplikacji Klasyczna struktura aplikacji... Typy Biblioteki procedur i funkcji Moduły aplikacyjne 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ły aplikacyjne Słowniki, katalogi Procedury bazy danych, perspektywy, reguły Schemat bazy danych Schemat bazy danych Zmiana metodyki pociąga za sobą zmianę struktury aplikacji.

34 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

35 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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

36 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Źródła obiektowości Współczesne pojęcia obiektowości Współczesne poję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ące na złożonych strukturach danych, wprowadzające klasy, metody, dziedziczenie i hermetyzację. (Simula 67, Smalltalk) Języki programowania operujące na 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

37 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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ą.

38 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Obszary oddziaływania obiektowości Metodyki 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).

39 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Przeszkody dla obiektowości Zastany ś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ść/...

40 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

41 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

42 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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).

43 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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ć 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.

44 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Przykład obiektu Wypłać Wpłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto Nalicz procent KONTO Numer SaldoZł Właściciel Jan Kowalski Upoważniony Ewa Kowalska....

45 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

46 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Przykład obiektu złożonego Pracownicy..... Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko

47 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Powiązania pomiędzy obiektami, asocjacje FIRMA NrFirmy Nazwa Syntex Prezes Zatrudnia PRACOWNIK Nazwisko Nowak Zarobek 1500 PracujeW PRACOWNIK Nazwisko Babel Zarobek 2000 PracujeW PRACOWNIK Nazwisko Kowal Zarobek 2500 PracujeW PRACOWNIK Nazwisko Zarobek FIRMA NrFirmy Nazwa PrezesZatrudnia PracujeW 0..* 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.

48 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Powiązania jako nitki łączące obiekty OSOBA Nowak OSOBA Bober OSOBA Kowalska OSOBA Bielicka OSOBA Maciąg OSOBA Wilczek Transakcja Kupujący Sprzedający Pośrednik Transakcja Kupujący Sprzedający Pośrednik Transakcja Kupujący Sprzedający Pośrednik OSOBA Nazwisko Sprzedający Kupujący Transakcja Pośrednik Diagram klas:

49 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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

50 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Atrybuty powiązań OSOBA Nowak OSOBA Bober OSOBA Kowalska OSOBA Bielicka OSOBA Maciąg OSOBA Wilczek Kupujący Sprzedający Kupujący Sprzedający Pośrednik Transakcja Samochód Kupujący Sprzedający Pośrednik DaneTransakcji PrzedmiotTransakcji DataTransakcji WartośćTransakcji Transakcja Dom Transakcja Plac Pośrednik OSOBA Nazwisko Sprzedający Kupujący Transakcja Diagram klas:

51 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Modelowanie powiązań jako obiektów OSOBA Nowak OSOBA Bober OSOBA Kowalska OSOBA Bielicka OSOBA Maciąg OSOBA Wilczek KupującySprzedający Kupujący Sprzedający Pośrednik Kupujący Sprzedający Pośrednik TRANSAKCJA Dom TRANSAKCJA Plac TRANSAKCJA Samochód * Pośrednik OSOBA Nazwisko Sprzedający Kupujący Diagram klas: Transakcja PrzedmiotTransakcji DataTransakcji WartośćTransakcji

52 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Liczność asocjacji AB: min = 1, max = 1 Oznaczenia liczności na diagramie klas: AAAAA BBB A B 1..* BA: min = 1, max = n BBB A B 0..* 1..* AAAAA B: min = 1, max = nA A: min = 0, max = nB BBB A B 0..* 0..1 AAAAA B: min = 0, max = 1A A: min = 0, max = nB

53 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Hermetyzacja i ukrywanie informacji Hermetyzacja: 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.

54 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Wewnętrzna i zewnętrzna struktura obiektu PRACOWNIK NAZWISKO NowakROK_UR 1951 ZAROBEK 2500 ZmieńZarobek(...) {...}; Podatek(){...}; ZarobekNetto() {...}; Wiek() { return RokBież - ROK_UR }; DZIAŁ Zabawki Wewnętrzna struktura obiektuZewnętrzna struktura obiektu PRACOWNIK NAZWISKO Nowak ZmieńZarobek(...) ZarobekNetto() Wiek() DZIAŁ Zabawki

55 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Metody i komunikaty Numer SaldoZł Właściciel Jan Kowalski Upoważniony Wpłać Wypłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto 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.

56 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Komunikat a wołanie procedury Woł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ć.

57 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

58 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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 obiekcie Obsługa zdarzeń lub wyjątków Lista eksportowa, określająca, które atrybuty dostępne są z zewnątrz Ograniczenia, którym musi podlegać każdy obiekt Nazwa, czyli językowy identyfikator obiektu Typ, 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ła definicja: Dobra definicja:

59 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Klasa, interfejs, typ Klasa. 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.

60 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Wyodrębnienie klasy Wpłać Porównaj podpis Zlikwiduj konto Wpłać Porównaj podpis Zlikwiduj konto Wpłać Wypłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto 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ł: integer Właściciel: string Upoważniony: string.... Wpłać Wypłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto Nalicz procent KONTO Numer SaldoZł Właściciel Jan Kowalski Upoważniony Jan Kowalski....

61 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Generalizacja, specjalizacja, dziedziczenie Generalizacja: 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. Generalizacja: 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. Sklep nazwa adres Rodzaj towaru Firma usługowa nazwa adres Rodzaj usługi Firma nazwa adres Sklep Rodzaj towaru Firma usługowa Rodzaj usługi Firma nazwa adres...Rodzaj towaru?...Rodzaj usługi? Generalizacja Specjalizacja

62 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Polimorfizm OSOBA nazwisko kategoria.... STUDENT.... dochody().... obiekt PRACOWNIK.... dochody().... EMERYT.... dochody().... obiekt Każda klasa ma własną metodę dochody. Są one niezależne i są niezależnie programowane

63 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Ekstensja klasy OSOBA Nazwisko Nowacki RokUr 1940 OSOBA Nazwisko Abacki RokUr 1948 OSOBA Nazwisko Nowak RokUr 1951 OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(...) OSOBA Nazwisko Kowalska RokUr 1975 PRACOWNIK Nazwisko Nowak RokUr 1951 Zarobek 2000 Dział zabawki PRACOWNIK Nazwisko Abacki RokUr 1948 Zarobek 2500 Dział zabawki PRACOWNIK Nazwisko Nowacki RokUr 1940 Zarobek 3000 Dział sprzedaż Ekstensja klasy OSOBA Ekstensja klasy PRACOWNIK

64 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Wielokrotne dziedziczenie POJAZD ciężar..... prędkość_eksploat() POJAZD_LĄDOWY ilość_kół max_prędkość..... POJAZD_WODNY wyporność max_prędkość..... AMFIBIA SAMOCHÓDJACHTTRAKTORŻ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.

65 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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

66 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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ń.

67 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

68 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Dopuszcza się różne poziomy abstrakcji i szczegółowości. Okno rozmiar czy_widoczne Okno rozmiar czy_widoczne wyświetl() schowaj() Okno rozmiar: Obszar czy_widoczne: Boolean wyświetl() schowaj() Okno {abstrakcyjna, autor=Kowalski status=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: Punkt punkt2: Punkt «konstruktor» Prostokąt(p1: Punkt, p2: Punkt) «zapytania» obszar(): Real aspekt(): Real... «aktualizacje» przesuń (delta: Punkt) przeskaluj(współczynnik: Real) Oznaczenia klas

69 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Atrybuty Atrybut jest nazwaną wartością przechowywaną przez obiekty w ramach klasy. Niekiedy wartość atrybutu jest obiektem lub referencją do obiektu. nazwisko wiek atrybuty obiektu Osoba Klasa z atrybutami (Osoba) Jan Nowak 53 (Osoba) Ewa Stycz 24 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: string wiek: integer

70 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Operacja jest funkcją lub transformacją, która może być zastosowana do obiektu (lub przez obiekt). Jest ona własnością klasy obiektów. zatrudnij zwolnij wypł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

71 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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 nazwisko wiek zmień_pracę zmień_adres Plik nazwa_pliku długość_w_bajtach ostatnia_zmiana drukuj Obiekt geometryczny kolor pozycja przesuń( delta: Wektor ) wewnątrz( p: Punkt ): Boolean obróć( kąt ) Jeżeli argumenty nie są specyfikowane, to może ich być dowolnie dużo. Argumenty operacji

72 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Asocjacje Firma Osoba Pracuje_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.

73 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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 Klasy i asocjacjaObiekty 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

74 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Liczność jest oznaczana na końcach asocjacji binarnych. 1 1,2,3,... 2,3,4,... 3,4,5 2,4,18 1 0,1 0,1,2, * 2..* 3-5 2,4, * * UML znaczenie PaństwoStolica FirmaPracownik OsobaAdres 1* 0..*0..1 Liczność asocjacji

75 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 W UML atrybuty asocjacji muszą tworzyć nową klasę. Plik Użytkownik Prawo dostępu Dostęp Dostępny dla czytanie czytanie-pisanie Osoba nazwisko pesel adres Firma nazwa adres Zatrudnienie zarobek stanowisko szef pracownik Pracuje_w Ocena wydajności ocena Kieruje * * 0..1 * * Atrybuty asocjacji

76 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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 ssania ciśnienie tłoczenia przepływ Wymiennik ciepła powierzchnia wymiany średnica rury Zbiornik objętość ciśnienie... typ wyposażenia typ pompy typ zbiornika aspekt generalizacji Wyposażenie nazwa wytwórca koszt Generalizacja i dziedziczenie

77 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Jak odróżnić agregację od asocjacji? Artykuł TytułAutor StreszczenieRozdział 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)

78 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Budowa diagramu klas - ćwiczenie Zał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ą.

79 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.:

80 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Przykładowe rozwiązanie ćwiczenia urodziła się mieszka w 1..* MIASTO Nazwa Województwo OSOBA Nazwisko Imię Data_ur Nr_ewiden STUDENT Semestr_studiów PROFESOR Specjalność Tytuł WYDZIAŁ Nazwa Telefon jest_zatrudniony_na DYPLOMANT Tytuł_pracy Data_obrony Ocena_końcowa opiekuje_się PROF_KONTRAKTOWY Pocz_kontraktu Kon_kontraktu WYKŁAD Ident_wykładu Nazwa_wykładu prowadzony_przez 1-3 uczęszcza PRZYPISANIE Status Semestr Oceny SALA Id_budynku Nr_sali KALENDARZ Semestr Dzień tygodnia GODZINY godz_początku godz_końca odbywa się Rozwiązanie jest niekompletne, np. brakuje metod. * * * * *

81 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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ęć

82 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Cel metody przypadków użycia Podstawowym 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

83 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

84 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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

85 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 klient banku wpłata pieniędzy wypłata pieniędzy kasjer sprawdź bilans weź pożyczkę zarząd banku «uses» Przykład modelu przypadków użycia

86 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Przykład modelu przypadków użycia Baza danych banku Klient Administrator systemu Prowadzenie konta klienta Informowanie o stanie konta klienta Inicjalizacja karty klienta Weryfikacja karty i kodu klienta Automat do operacji bankowych «uses»

87 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Powiązania w modelu przypadków użycia Generalizacja pomiędzy aktorami, dziedziczenie dostępu do 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

88 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Diagram przypadków użycia Ustalenie limitów Analiza ryzyka Sprawy cenowe Przekroczenie limitów Ocena zysków Aktualizacja rozliczeń Wyliczenie ocen Dyrektor handlowy Handlowiec Sprzedawca System rozliczeniowy «extends» «uses»

89 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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?

90 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Dokumentacja przypadków użycia Typowa 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.

91 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Aktorzy Metoda 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.

92 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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?

93 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Analiza aktorów Zakresy 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

94 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Modele wykorzystujące przypadki użycia Model 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.

95 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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

96 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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.

97 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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

98 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 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)...

99 K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd listopad 2000 Podsumowanie Obiektowość 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.


Pobierz ppt "Wprowadzenie do Analizy i Projektowania Obiektowego Ministerstwo Finansów Centralny Ośrodek Doskonalenia Kadr, Dębe 17 listopada 2000 Wykładowca: dr hab."

Podobne prezentacje


Reklamy Google