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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 3 17 listopad 2000
Wykład 1: Przedmiot inżynierii oprogramowania
Zagadnienia inżynierii oprogramowaniaKryzys oprogramowaniaZłożoność projektu oprogramowaniaModelowanie pojęcioweNiezgodność modelu pojęciowego i realizacyjnego
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 4 17 listopad 2000
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ą.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 5 17 listopad 2000
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!
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).
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.
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.
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 10 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 11 17 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.
Ś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ść.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 12 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 13 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 14 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 15 17 listopad 2000
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):
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 16 17 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 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 17 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 18 17 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ę.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 19 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 20 17 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 21 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 22 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 23 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 24 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 25 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 26 17 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.
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 27 17 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 28 17 listopad 2000
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ń.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 29 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 30 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 31 17 listopad 2000
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,...
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 32 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 33 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 34 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 35 17 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 36 17 listopad 2000
Ź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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 37 17 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ą.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 38 17 listopad 2000
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).
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 39 17 listopad 2000
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ść/...
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 40 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 41 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 42 17 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).
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 43 17 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ć 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 44 17 listopad 2000
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
....
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 45 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 46 17 listopad 2000
Przykład obiektu złożonego
Pracownicy
.....
PracownikZatrudnienia
.....
Zatrudnienie
Zatrudnienie
Stanowisko
Nazwisko
Dzieci...
Dziecko Dziecko
PracownikZatrudnienia
.....
Zatrudnienie
Zatrudnienie
Stanowisko
Nazwisko
Dzieci...
Dziecko Dziecko
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 47 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 48 17 listopad 2000
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:
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 49 17 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 50 17 listopad 2000
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
Sprzedający Kupujący
Transakcja
Diagram klas:
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 51 17 listopad 2000
Modelowanie powiązań jako obiektów
OSOBANowak
OSOBABober
OSOBAKowalska
OSOBABielicka
OSOBAMaciąg
OSOBAWilczek
Kupujący Sprzedający
KupującySprzedający
Pośrednik
Kupujący Sprzedający
Pośrednik
Pośrednik
TRANSAKCJADom
1992.11.05300000
TRANSAKCJAPlac
1995.08.1640000
TRANSAKCJASamochód1998.05.15
20000
0..*
0..*0..*
Pośrednik
OSOBA Nazwisko
Sprzedający Kupujący
Diagram klas:
Transakcja PrzedmiotTransakcji DataTransakcji WartośćTransakcji
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 52 17 listopad 2000
Liczność asocjacji
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 53 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 54 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 55 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 56 17 listopad 2000
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ć.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 57 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 58 17 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 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:
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 59 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 60 17 listopad 2000
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....
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 61 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 62 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 63 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 64 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 65 17 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 66 17 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ń.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 67 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 68 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 69 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 70 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 71 17 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
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 72 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 73 17 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 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 74 17 listopad 2000
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
Liczność asocjacji
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 75 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 76 17 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 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 77 17 listopad 2000
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)
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 78 17 listopad 2000
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ą.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 79 17 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.:
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 80 17 listopad 2000
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.
*
*
*
*
*
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 81 17 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ęć
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 82 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 83 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 84 17 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 85 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 86 17 listopad 2000
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»
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 87 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 88 17 listopad 2000
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»
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 89 17 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?
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 90 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 91 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 92 17 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?
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 93 17 listopad 2000
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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 94 17 listopad 2000
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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 95 17 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 96 17 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.
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 97 17 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
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 98 17 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)
...
K.Subieta. Wprowadzenie do Analizy i Projektowania Obiektowego, Slajd 99 17 listopad 2000
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.
Top Related