Kompletny przewodnik po modelowaniu CRC (Class Responsibility Collaborator)
Opierając się na podstawowych zasadach analizy obiektowej (OO), ten przewodnik przedstawia proces modelowania CRC. Modelowanie CRC to bardzo skuteczna, niskoteknologiczna metoda zaprojektowana w celu wypełnienia luki komunikacyjnej między programistami a użytkownikami, zapewniając dokładne zidentyfikowanie i zrozumienie wymagań biznesowych przed napisaniem kodu.
1. Kluczowe pojęcia: Anatomia karty CRC
Modelowanie CRC opiera się na standardowych kartkach dzielonych na trzy różne sekcje. Każda sekcja reprezentuje kluczowe pojęcie w projektowaniu obiektowym.
A. Klasa (góra karty)
Klasa reprezentuje zbiór podobnych obiektów. Obiektem może być osoba, miejsce, rzecz, zdarzenie, pojęcie, ekran lub raport istotny dla systemu.
-
Zasada nazewnictwa: Używaj jednego lub dwóch słów liczby pojedynczej (np. Klient, nie Klienci).
-
Przykład: W systemie wysyłkowym/inwentarzowym klasy obejmują Element inwentarza, Zamówienie, Pozycja zamówienia, Klient, oraz Adres powierzchniowy.
B. Odpowiedzialność (lewa kolumna)
Odpowiedzialność to wszystko, co klasa wie lub robi.
-
Co zna (Dane/Atrybuty): Przykład: A Klient klasa zna swoje imię, numer klienta oraz numer telefonu.
-
Co robi (Zachowania/Metody): Przykład: A Klient klasa może zamawiać produkty, anulować zamówienia i dokonywać płatności.
C. Współpracownik (Kolumna prawostronna)
Współpraca ma miejsce, gdy klasa potrzebuje informacji lub pomocy od innej klasy w spełnieniu odpowiedzialności.
-
Przykład: Obiekt Zamówienie ma odpowiedzialność za „obliczenie całkowitej kwoty”. Jednak nie zna ceny produktów ani ilości zamówionych. Dlatego musi współpracować z Element zamówienia (który zna ilość) oraz Element magazynowy (który zna cenę), aby obliczyć końcową kwotę.
2. Zespół modelowania CRC
Pomyślna sesja CRC wymaga określonych ról, aby zapewnić płynność procesu i dokładne odwzorowanie logiki biznesowej.
-
Ekspertowie dziedziny biznesowej (BDE): Rzeczywisti użytkownicy systemu (zazwyczaj 4 do 5 osób z pierwszej linii). Posiadają codzienną wiedzę biznesową. Uwaga: Kierownicy ogólnie nie są idealni do CRC; są lepiej przystosowani do wysokopoziomowych przypadków użycia.
-
Moderator: prowadzi sesję, wyjaśnia technikę, zadaje istotne pytania, zapewnia poprawne wypełnianie kart i prowadzi testowanie scenariuszy.
-
Pisarz(zy):1 lub 2 osoby siedzące z tyłu/bokach. Nie uczestniczą aktywnie w modelowaniu, ale zapisują szczegółową logikę biznesową i zasady, które nie mieszczą się na małych kartkach.
-
Obserwatorzy:Uczniowie lub interesenci siedzący z tyłu i obserwujący bez uczestnictwa.
3. Sześciostopniowy proces modelowania CRC
Krok 1: Zbierz zespół
Zbierz 4–5 działowych BDE, prowadzącego i 1–2 sekretarzy. Upewnij się, że menedżerzy wspierają działanie, aby uczestnicy mogli poświęcić potrzebny czas.
Krok 2: Zorganizuj pomieszczenie
-
Powierzchnie do pisania:Tablice do rysowania lub tablice do pisania do przeprowadzania sesji mózgowej i prototypowania.
-
Stół modelowania:Duży, centralny stół, na którym BDE mogą umieszczać i przesuwać kartki.
-
Stacje sekretarzy:Stoły ustawione z boku, ale z jasnym widokiem na środek.
-
Materiały:Kartki indeksowe, markery orazmiękka, gąsienicowa piłka (używana później do testowania scenariuszy).
Krok 3: Sesja mózgowa
Wydobywaj pomysły bez ich oceny. Prowadzący zadaje pytania otwarte, aby zrozumieć potrzeby biznesowe.
-
Przykładowe pytania:„Dla kogo jest ten system?”, „Jakie potrzeby biznesowe obsługuje?”, „Jak możemy to zrobić szybciej/drożej/lepiej?”, „Czy są proste zadania, które możemy zautomatyzować?”
Krok 4: Wyjaśnij technikę
Prowadzący poświęca 10–15 minut na wyjaśnienie koncepcji CRC, wyraźnie umieszczając definicje na ścianie i prowadząc zespół przez stworzenie kilku przykładów kart.
Krok 5: Iteracyjne modelowanie CRC
BDE stoją lub siedzą wokół stołu i iteracyjnie budują model:
-
Znajdź klasy:Śledź przepływ pieniędzy, szukaj raportów/ekranów i natychmiast zidentyfikuj 3–5 głównych klas.
-
Znajdź odpowiedzialności:Zapytaj, co klasa zna i co robi.
-
Zdefiniuj współpracowników:Określ, kto posiada brakujące informacje potrzebne do spełnienia odpowiedzialności.
-
Ułóż karty: Kluczowy krok.Karty, które często współpracują, umieszcza się blisko siebie na stole. „Zajęte” karty umieszcza się w środku. Fizyczne przemieszczanie kart pomaga zespołowi wizualizować relacje i powiązania.
Krok 6: Testowanie scenariuszy przypadków użycia (ćwiczenie „Rzut piłką”)
Jest to ćwiczenie weryfikacyjne, w którym zespół „odgrywa” przepływy pracy systemu, aby upewnić się, że model jest poprawny.
-
Zadaj scenariusz:Moderator opisuje przypadki użycia (np. „Klient składa zamówienie”) i rzuca miękką piłkę do BDE trzymającego początkową kartę odpowiedzialności (np.Zamówienie).
-
Określ odpowiedzialność:Zespół potwierdza, że karta obsługuje zadanie. Jeśli nie, aktualizują ją lub tworzą nową kartę.
-
Opisz logikę:BDE trzymające piłkę opisuje krok po kroku logikę biznesową (kod pseudokodowy) dla sekretarza.
-
Współpracuj:Jeśli BDE potrzebuje informacji z innej klasy (np.Element magazynowy), rzuca piłkę do BDE trzymającego tę kartę. Ten BDE opisuje następnie swoją część logiki.
-
Przekaż piłkę z powrotem:Gdy zadanie zostanie wykonane, piłka jest rzucana z powrotem do poprzedniej osoby, aż w końcu wróci do moderatora, aby rozpocząć następny scenariusz.
4. Jak CRC pasuje do cyklu życia oprogramowania
Modelowanie CRC nie istnieje w próżni; jest częścią szerszego procesu modelowania obiektowego, który jestsekwencyjny na dużą skalę (przechodząc od wymagań do projektowania do kodu) oraziteracyjny na małą skalę (skakanie między modelami).
-
Poziom szczegółowości:CRC znajduje się w środku. Zaczynasz prosto zPrzypadkami użycia iPrototypy interfejsu użytkownika, przejdź do szczegółowości średniej Modele CRC, a na końcu zakończ szczegółowością wysoką Diagramy klas.
-
Dostarczane elementy napędzają dalsze elementy: Diagramy przypadków użycia są dokumentowane przypadkami użycia, które są dokumentowane diagramami sekwencji, które w końcu napędzają kod źródłowy. Modele CRC są bezpośrednio wykorzystywane do tworzenia diagramów klas.
5. Najlepsze praktyki i wskazówki dotyczące sukcesu
-
Wyślij agendę: Rozdaj agendę kilka dni wcześniej, aby BDE mogły się przygotować.
-
Wyświetl definicje: Przyklej duży układ kart CRC i ich definicje na przedniej ścianie pokoju.
-
Używaj terminologii dziedziny: Unikaj żargonu technicznego; używaj dokładnie tych samych słów, które BDE używają w swojej codziennej pracy.
-
Zachowaj niską technologię: Narzędzia do CRC są tylko opcjonalne. Kartki są tanie, przenośne i bardzo skuteczne.
-
Oczekuj prototypowania: Rysowanie ekranów i raportów na tablicach podczas sesji pomaga użytkownikom wizualizować system.
-
Zaplanuj kilka dni: Duże systemy wymagają kilku sesji. Jest to normalne i konieczne.
-
Uzyskaj wsparcie menedżerskie: Upewnij się, że kierownictwo rozumie wartość modelowania przed kodowaniem.
-
Skieruj się do personelu z linii frontu: CRC jest bardzo szczegółowy i najlepiej działa z użytkownikami codziennymi, a nie wysoko poziomowymi dyrygentami.
6. Zalety i wady
Zalety
-
Eksperci wykonują analizę: Osoby, które faktycznie wykonują pracę, budują model.
-
Wysokie zaangażowanie użytkowników:Aktywne uczestnictwo zwiększa satysfakcję użytkowników i poczucie własności.
-
Usuniecie barier:Użytkownicy i deweloperzy pracują obok siebie.
-
Proste i niegroźne:To tylko karty indeksowe. Użytkownicy nie są przerażeni skomplikowanymi narzędziami programowymi, a nie czują, że ich praca jest automatyzowana przez „maszynę”.
-
Niskocostowe i przenośne:Kosztuje kilka dolarów i mieści się w portfelu.
-
Bezproblemowy przejście:Doskonale łączy się z prototypowaniem i prowadzi bezpośrednio do formalnych diagramów klas.
Wady
-
Zagrożenie dla niektórych deweloperów:Niektórzy deweloperzy błędnie uważają, że ich wiedza techniczna przewyższa wiedzę użytkowników o działalności biznesowej.
-
Planowanie jest trudne:Zbieranie 4-5 kluczowych użytkowników w jednym pomieszczeniu w tym samym czasie wymaga szczegółowego planowania.
-
Karty są ograniczone:Stos karciek indeksowych nie jest akceptowalnym dokumentem formalnym dla większości organizacji. CRC musi być uzupełniony formalnymi przypadkami użycia, prototypami i diagramami klas.
Wnioski
Ostatecznym celem rozwoju aplikacji jest rozwiązywanie problemów biznesowych, a nie zaspokajanie ciekawości intelektualnej dewelopera nowymi technologiami. Modelowanie CRC zmusza deweloperów do pracy zużytkownikami, a nie przeciwko nim. Wykorzystując niskoteknologiczne, bardzo wspólne środowisko, zespoły mogą dokładnie zebrać, zweryfikować i dopracować wymagania biznesowe, zanim zostanie napisany pierwszy wiersz kodu.
