Slajd 1

Karty CRC

Inżynieria oprogramowania

Slajd 2

Zadania w ramach podejścia:

Identyfikacja obiektów i klas Identyfikacja związków pomiędzy klasami (generalizacji-

specjalizacji oraz asocjacji) Identyfikacja i definiowanie atrybutów Identyfikacja i definiowanie metod i komunikatów

Tworzenie modelu obiektowego – podejście pierwsze

Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania nie jest ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu.

Slajd 3

Inny schemat realizacji procesu budowy modelu obiektowego polega na rozpoznaniu funkcji, które system ma wykonywać. Dopiero w późniejszej fazie następuje identyfikacja klas, związków, atrybutów i metod. Rozpoznaniu funkcji systemu służą modele funkcjonalne (diagramy przepływu danych) oraz model przypadków użycia.

Tworzenie modelu obiektowego – podejście drugie

Slajd 4

Identyfikacja klas

Właściwa identyfikacja klas (abstrakcji opisujących grupy bytów o podobnych własnościach, wyróżnialnych w analizowanej rzeczywistości), to kluczowa umiejętność w obiektowym podejściu do procesu konstrukcji oprogramowania.

Ma to, tzn. oparcie oprogramowania o wykorzystanie klas, duże znaczenie dla technologii ponownego użycia.

Slajd 5

Identyfikacja klas

Klasy są najbardziej stabilnym elementem dziedziny problemowej. Dobry system oparty jest tak dalece, jak tylko jest to możliwe, na klasach reprezentujących grupy bytów wyróżnialnych w dziedzinie problemowej, a nie na funkcjonalności potrzebnej dziś i to dla specyficznego być może zastosowania. Oprogramowanie wykorzystujące klasy powstałe w wyniku analizy dziedzinowej jest znacznie bardziej odporne na zmiany wymagań niż oprogramowanie oparte o jednostki funkcjonalne.

Slajd 6

Typowe klasy:

przedmioty namacalne (samochód, czujnik) grupy przedmiotów namacalnych (kartoteka, samochód jako zestaw części) role pełnione przez osoby (pracownik, wykładowca, student) zdarzenia, o których system przechowuje informacje (lądowanie samolotu, wysłanie zamówienia, dostawa) interakcje pomiędzy osobami i/lub systemami o których system przechowuje informacje (pożyczka, spotkanie, sesja)

lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów

organizacje (firma, wydział, związek)

wydarzenia (posiedzenie sejmu, demonstracja uliczna) koncepcje i pojęcia (zadanie, miara jakości) dokumenty (faktura, prawo jazdy)

Typowe klasy

Slajd 7

W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z jakiego rodzaju bytem mamy do czynienia.

egzemplarz samochodu wyprodukowany przez pewną fabrykę historię stanów pewnego konkretnego samochodu pozycję w katalogu samochodów opisujący własności modelu model samochodu produkowany przez fabrykę

czy mamy do czynienia z konkretnym bytem w danej chwili czasowej? czy mamy do czynienia z konkretnym bytem w pewnym odcinku czasu? czy mamy do czynienia z opisem tego bytu (dokument, metadane)? czy mamy do czynienia z pewnym zbiorem konkretnych bytów?

Np. klasa „samochód”. Może chodzić o:

Należy zwrócić uwagę na następujące aspekty:

Obiekty, zbiory obiektów, metadane (1)

Slajd 8

konkretny egzemplarz gazety kupiony przez czytelnika konkretne wydanie gazety (niezależne od ilości egzemplarzy) tytuł i wydawnictwo, niezależne od egzemplarzy i wydań partię egzemplarzy danej gazety dostarczaną codziennie do kiosku

Analogicznie z klasą „gazeta”. Może chodzić o:

Obiekty, zbiory obiektów, metadane (2)

Slajd 9

Eksperci od podejścia obiektowego do procesu tworzenia oprogramowania dzielą się na dwa obozy w zależności od proponowanego przez nich sposobu identyfikacji klas:

w oparciu o dane (DDD - Data Driven Design), w oparciu o odpowiedzialności klas (RDD - Responsibility Driven Design).

Odpowiedzialność klasy odpowiada zbiorowi zachowań obiektów tej klasy.

DDD a RDD

Slajd 10

DDD - polega na zidentyfikowaniu wszystkich danych w systemie i podziale ich na klasy bez specjalnego rozważania ich odpowiedzialności; przykładem tej techniki jest identyfikacja rzeczowników i fraz rzeczownikowych w tekście wymagań.

RDD - rozpoznaje się wszystkie odpowiedzialności systemu (w oparciu o potrzeby przyszłych użytkowników) i bazując na nich wyróżnia się klasy; przykładem jest tu metoda CRCwykorzystywana w kilku metodykach.

Najbardziej efektywne, jak to z reguły w praktyce bywa, są techniki mieszane, wykorzystujące każdą dostępną metodę.

DDD a RDD

Slajd 11

Metoda CRC (Class, Responsibilities, Collaborations) została zaprezentowana przez K. Beck’a i W. Cunningham’a w 1989 r. w celu ułatwienia programistom “nie-obiektowym” naukę “myślenia obiektowego”. Okazała się być przydatna na wczesnych etapach rozwoju systemu do identyfikacji klas. Metoda CRC nie jest częścią UML.

Na małej kartce papieru notuje się następujące elementy:

u góry kartki - nazwę klasy, po lewej stronie - odpowiedzialności (responsibilities), czyli obowiązki danej klasy, po prawej stronie - współpracowników (collaborators), czyli klasy, które pomagają danej klasie w wypełnianiu jej obowiązków.

Metoda CRC

Slajd 12

Odpowiedzialności danej klasy opisywane są na wysokim poziomie abstrakcji - jako podstawa (główny powód, cel) zaistnienia danej klasy.

Są powiązane z operacjami, które można wykonywać na obiektach tej klasy, ale są wyrażone w bardziej ogólny sposób. Np. akceptowalna jest odpowiedzialność, taka jak “zarządzanie danymi dotyczącymi książki”, co implikuje operacje, które czytają i zapisują dane.

Klasa nie powinna mieć więcej niż trzy, cztery odpowiedzialności (wiele klas ma tylko jedną lub dwie). Jeśli klasa ma zbyt dużo odpowiedzialności (niska kohezja), należy zastanowić się czy zostały one dostatecznie zwięźle określone lub czy nie rozdzielić odpowiedzialności i mieć więcej klas. Zbyt wielu współpracowników sugeruje zbyt silne skojarzenie klas.

Metoda CRC

Slajd 13

CRC wykorzystuje się wspólnie z przypadkami użycia - postępując w zgodzie ze scenariuszem identyfikuje klasy, których odpowiedzialności włączają potrzebną operację i znajduje ewentualnych współpracowników, zaangażowanych w realizację danego przypadku użycia.

Upraszczając - odpowiedzialności każdej klasy mogą być postrzegane jako suma operacji, które można wykonywać na obiektach tej klasy.

Kiedy brakuje klasy, która mogła by wykonać potrzebną operację, oznacza to błędy lub braki w modelu. Być może trzeba dodać nową klasę lub zmienić odpowiedzialności lub współpracowników klasy już istniejącej (być może jedno i drugie).

Metoda CRC (2)

Slajd 14

Związek generalizacji-specjalizacji jest tu wyjaśniany w kategoriach współdzielenia odpowiedzialności i współpracowników. Klasa specjalizowana ma te własności odpowiednio większe.

Sytuacja ta może też być postrzegana w drugą stronę - jeśli dwie klasy mają nakładające się odpowiedzialności i współpracowników, to może to być sugestia dla wydzielenia dla nich nadklasy.

Metoda CRC (3)

Slajd 15

DDD – identyfikacja klas poprzez rzeczowniki

Identyfikacja klas poprzez identyfikację rzeczowników i fraz rzeczownikowych w tekście specyfikującym wymagania użytkownika jest jedną z podstawowych, powszechnie stosowanych technik.

Proces ten przebiega w dwóch etapach:

Etap I. Identyfikacja potencjalnych klas poprzez podkreślenie wszystkich rzeczowników i fraz rzeczownikowych w tekście wymagań.

Etap II. Odrzucenie niektórych kandydatów i zmiana nazw, o ile wyniknie taka potrzeba. Nazwy przyszłych klas powinny być rozważane jako rzeczowniki w liczbie pojedynczej.

Niektórzy analitycy konstruują dwie listy potencjalnych kandydatów: silnych i słabych. Kandydaci są przenoszeni w razie potrzeby z listy na listę. Taka technika chroni przed utratą informacji, być może przydatnej krok dalej.

Slajd 16

Redukcja zbioru potencjalnych kandydatówOdrzucamy potencjalnego kandydata na klasę, gdy rzeczownik (fraza rzeczownikowa):

jest redundantny - tzn. gdy istnieją różne rzeczowniki dla określenia tego samego bytu; trzeba tu brać pod uwagę następujący fakt: byty mogą być podobne, ale niekoniecznie dokładnie takie same, a to z kolei może wskazywać na związek generalizacji-specjalizacji istniejący między nimi;

jest nieuchwytny - trudno jest określić, co właściwie oznacza i w jaką klasę miałby być odwzorowany - być może inne elementy notacji byłyby bardziej użyteczne do opisania go;

oznacza wydarzenie lub operację - tutaj pomocnicze może być zadanie pytania, czy obiekty przyszłej klasy miałyby atrybuty, zachowanie i tożsamość;

stanowi wyrażenie metajęzyka, tzn. służy do definiowania czegoś, np. rzeczowniki wymagania czy system używane są raczej w procesie modelowania niż do reprezentowania bytów istniejących w analizowanej dziedzinie problemowej;

oznacza coś, co znajduje się na zewnątrz systemu, np. aktorzy - z reguły nie istnieje potrzeba do modelowania ich w postaci klasy;

oznacza atrybut - coś prostszego niż klasa, bez interesującego zachowania.

Slajd 17

DDD - identyfikacja klas; przykładPrzykład wymagań dla biblioteki:

Biblioteka zawiera książki i czasopisma. Może być kilka egzemplarzy tej samej książki. Tylko personel może wypożyczać czasopisma. Członek biblioteki może mieć jednocześnie wypożyczonych sześć pozycji, podczas gdy osoba pracująca w bibliotece może mieć ich wypożyczonych dwanaście. System musi rejestrować wypożyczenia i zwroty oraz pilnować, by przestrzegano wymienionych powyżej reguł (ograniczeń).

Zostawiamy: książka, czasopismo, egzemplarz książki, członek biblioteki, personel

Odrzucamy: biblioteka (1 obiekt i to znajdujący się na zewnątrz systemu ), system (wyrażenie metajęzyka), osoba pracująca w bibliotece oznacza to samo co personel, reguła (nieuchwytne), ograniczenie (nieuchwytne)

Każdy rzeczownik, kandydat na przyszłą klasę, jest tu rozważany w liczbie pojedynczej.

pozycja (?), wypożyczenie (?), zwrot (?),

Slajd 18

CRC- identyfikacja klas; przykład

Członek bibl.Odpowiedzialności Współpracownicy

zarządzanie danymi dotyczącymi członka biblioteki

kontrola wypełniania ograniczeń narzuconych na liczbęegzemplarzy

egzemplarz

Książka.Odpowiedzialności Współpracownicy

zarządzanie danymi dotyczącymi książki

sprawdzanie, czy są egzemplarze możliwe do wypożyczenia

egzemplarz

Slajd 19

Identyfikacja generalizacji-specjalizacji

Osoba

Personel Członek bibl.

Książka

Egzemplarzksiążki

Książka Czasopismo

Pozycja

Identyfikacja związków generalizacji-specjalizacji

Egzemplarz książki nie jest rodzajem pozycji

wydawniczej, jaką oznacza tu każde wystąpienie klasy

Książka.

Slajd 20

Identyfikacja asocjacji (1)Identyfikacja asocjacji: podobnie, jak klasy można identyfikować poprzez wyszukiwanie rzeczowników (czy fraz rzeczownikowych) w tekście wymagań, tak asocjacje mogą być identyfikowane poprzez wyszukiwanie w tym tekście czasowników (fraz czasownikowych).

Z przykładu z biblioteką moglibyśmy wydedukować następujące asocjacje: “wypożyczył”, “zwrócił”, “jest egzemplarzem”,. Nie wszystkie wystąpiły “jawnie” - w postaci czasowników (czy fraz czasownikowych).

Asocjacja (o danej semantyce) musi połączyć Klasę A z klasą B jeżeli w czasie działania programu:

obiekt klasy A wysyła komunikat do obiektu klasy B, obiekt klasy A tworzy obiekt klasy B (wywołuje konstruktor), obiekt klasy A posiada atrybut będący obiektem (lub kolekcją obiektów) klasy B, obiekt klasy A otrzymuje komunikat z argumentem będącym obiektem klasy B.

W skrócie - jeśli obiekt klasy A musi mieć możliwość dostępu do danych pewnego obiektu klasy B, to klasy A i B musi połączyć asocjacja.

Slajd 21

Identyfikacja asocjacji (2)Uwaga - nie archiwizujemy tu wypożyczeń; fakt zwrotu jest rejestrowany poprzez usunięcie powiązania wypożyczyła między obiektami klas Osoba i Egzemplarz Książki.

Osoba EgzemplarzKsiążki

wypożyczyła

0..1 *

OsobaWypożyczenie

EgzemplarzKsiążki

* 0..1

Preferowane jest rozwiązanie pierwsze - klasa Wypożyczenie nie posiada żadnych własności, ani atrybutów ani operacji.

1 1

Slajd 22

Identyfikacja asocjacji (3)Sytuacja ulegnie zmianie, gdy do poprzednich wymagań dołożymy sformułowanie: Książki mogą być wypożyczane na okres trzech tygodni, wypożyczanie książek jest archiwizowane, co implikuje konieczność pamiętania obu dat: wypożyczenia i zwrotu.

Osoba EgzemplarzKsiążki

wypożyczyła* *

Wypożyczeniedata wypożyczeniadata zwrotu

{data zwrotu - data wypożyczenia <= 3 tygod.}

OsobaWypożyczeniedata wypożyczeniadata zwrotu

EgzemplarzKsiążki

* *

{data zwrotu - data wypożyczenia <= 3 tygod.}

Oba rozwiązania są tu poprawne.

1 1

Slajd 23

Identyfikacja asocjacji (4)

Personel Czasopismowypożyczył

0..1 *

asocjacja wypożyczył między klasami Personel i Czasopismo

Książka

Egzemplarzksiążki

1..*

Książka

Egzemplarzksiążki

1..*1

asocjacja jest egzemplarzem między klasami Książka i Egzemplarz książki

nie archiwizuje się wypożyczeń dla czasopism, ani nie zostały nałożone żadne ograniczenia na długość okresu wypożyczenia

kompozycja silniej podkreśla tu związek istniejący między książką (byt wirtualny), a konkretnym egzemplarzem

Slajd 24

Diagram klas dla przykładowych wymagań

Członekbibl. Personel

Pozycja

CzasopismoKsiążka

Egzemplarzksiążki

Osoba

/liczba wyp. akt. pozycji

*0..1

{ liczba wyp. akt. pozycji <= 12 }

{ liczba wyp. akt. pozycji <= 6 } 1..*

Wypożyczeniedata wypożyczeniadata zwrotu

{ data zwrotu - data wypożyczenia <= 3 tygodnie }

*

*

wypożyczył