Zwinne tworzenie aplikacji internetowych typu RIA w środowisku Ruby on Rails

Transkrypt

1 UNIWERSYTET JAGIELLOŃSKI W KRAKOWIE Praca magisterska Zwinne tworzenie aplikacji internetowych typu RIA w środowisku Ruby on Rails Piotr Więcek kierunek: informatyka specjalność: informatyka stosowana Pracę wykonano w Zakładzie Technologii Informatycznych pod kierunkiem dr Katarzyny Grzesiak-Kopeć Wydział Fizyki, Astronomii i Informatyki Stosowanej Kraków 2010

2 Wydział Fizyki, Astronomii i Informatyki Stosowanej Uniwersytet Jagielloński Oświadczenie Ja niżej podpisany Piotr Więcek (nr indeksu: ) student Wydziału Fizyki, Astronomii i Informatyki Stosowanej Uniwersytetu Jagiellońskiego kierunku informatyka, oświadczam, że przedłożona przeze mnie praca magisterska pt.,,zwinne tworzenie aplikacji internetowych typu RIA w środowisku Ruby on Rails przedstawia wyniki badań wykonanych przeze mnie osobiście, pod kierunkiem dr Katarzyny Grzesiak-Kopeć. Pracę napisałem samodzielnie. Oświadczam, że moja praca dyplomowa została opracowana zgodnie z Ustawą o prawie autorskim i prawach pokrewnych z dnia 4 lutego 1994 r. (Dziennik Ustaw 1994 nr 24 poz. 83 wraz z późniejszymi zmianami). Jestem świadom, że niezgodność niniejszego oświadczenia z prawdą ujawnioną w dowolnym czasie, niezależnie od skutków prawnych wynikających z ww. ustawy, może spowodować unieważnienie tytułu nabytego na podstawie tej pracy. Kraków, dnia r. podpis studenta

3 Spis treści Wstęp... 6 Motywacja... 6 Cel pracy... 7 Rozdział 1. Inżynieria oprogramowania... 8 Rozdział 2. Zwinne metodologie tworzenia oprogramowania Manifest zwinności Metodologie tradycyjne vs zwinne Rational Unified Process zwinna metodologia czy ciężki proces Cykl tworzenia oprogramowania RUP jako ciężki proces RUP jako zwinna metodologia Podsumowanie Rozdział 3. Przegląd zwinnych metodologii tworzenia oprogramowania Programowanie Ekstremalne Wartości XP Cykl tworzenia oprogramowania Podstawowe praktyki Scrum Role w zespole Spotkanie planistyczne wydania Sprint Spotkanie planistyczne Sprintu Przebieg Sprintu Przegląd Sprintu Retrospektyw Sprintu Crystal family Adaptive Software Development

4 3.5 Dynamic System Development Method Feature Driven Development Podsumowanie Rozdział 4. RIA Wprowadzenie do środowiska RIA Platformy wspomagające tworzenie aplikacji RIA AJAX Adobe Flex Microsoft Silverlight JavaFX Rozdział 5. Platforma Ruby on Rails Historia Ruby Czym jest Ruby on Rails Zwinne tworzenie oprogramowania a Ruby on Rails Podstawowe koncepcje programistyczne DRY YAGNI CoC Język Ruby Podstawy składni Pełna obiektowośd Bloki Metaprogramowanie Architektura Rails Struktura katalogów Moduły Narzędzia Wzorzec MVC w Ruby on Rails Kontroler Model Widok Testowanie aplikacji Testy jednostkowe Testy funkcjonalne Testy integracyjne Rozdział 6. Zwinna realizacja projektu aplikacji internetowej Zdefiniowanie problemu

5 6.2 Uzasadnienie wybóru metodologii zarządzania projektem Zwinne środowisko pracy programisty RadRails Adobe Flex Builder System kontroli wersji Subversion Serwer ciągłej integracji CruiseControl.rb Architektura systemu Model-Widok-Kontroler Integracja Flexa z RoR Rejestr produktowy aplikacji Taskzilla Realizacja konkretnej iteracji Rejestr prac Sprintu Szkice ekranów Testy akceptacyjne Podsumowanie Spis rysunków Spis tabel Bibliografia

6 Wstęp Motywacja Współczesny świat przeżywa niesłychany poziom zmian w dziedzinie technologii, w biznesie, strukturach społecznych oraz ludzkich postawach. Jest to złożone i słabo rozumiane zjawisko, które zachodzi z ogromną szybkością. Pomimo tego, że niektórzy sądzą iż taka tendencja nie zdoła utrzymać się na dłuższą metę, gdyż światu zabraknie środków albo popadnie w społeczną anarchię oraz zniszczenie, to w obecnych czasach szybkie zmiany są kluczowym czynnikiem zarówno w biznesie, jak i w życiu publicznym. Postęp ten ma szczególny wpływ na branżę informatyczną. Technologie komputerowe, obecne dzisiaj praktycznie w każdej firmie i organizacji, mają niemały problem z dotrzymaniem kroku zmieniającemu się światu. Szczególnie twórcy oprogramowania mogli się wielokrotnie przekonać o zawodności tradycyjnej inżynierii oprogramowania, której techniki nie gwarantowały dostarczenia gotowego produktu w ustalonym budżecie i czasie [1]. Środowisko informatyczne doszło do przekonania, że dotychczasowe podejście do procesu wytwarzania oprogramowania musi ulec zmianie. Zbierając doświadczenia z projektów zakończonych niepowodzeniem, pod nazwą metodologii zwinnych (ang. Agile Software Development) zaproponowano zupełnie nowe podejście do procesu wytwarzania oprogramowania. Programowanie w stylu zwinnym obok nowych technik stosuje wiele rozwiązań, które istniały już od lat, jednak w całkowicie nowej konfiguracji. 6

7 Cel pracy Programowanie w stylu zwinnym staje się coraz bardziej popularne. Większość analityków wróży szybki koniec klasycznych metodologii programowania, a zatem należy odpowiedzieć sobie na pytanie, jakie faktycznie znaczenie dla programistów ma stosowanie wspomnianych technik. Celem niniejszej pracy jest: scharakteryzowanie najpopularniejszych zwinnych metodologii tworzenia oprogramowania, praktyczne zastosowanie metodologii Scrum do zarządzania projektem informatycznym, zwinne stworzenie aplikacji internetowej typu RIA w środowisku Ruby on Rails. 7

8 Rozdział 1. Inżynieria oprogramowania Pod koniec lat sześćdziesiątych, dzięki rozwojowi sprzętu komputerowego, możliwe stało się tworzenie nowoczesnych i rozbudowanych systemów informatycznych. Ludzie zaczęli zawodowo zajmować się tworzeniem oprogramowania uświadamiając sobie jednocześnie jego przydatność w nowych zastosowaniach, między innymi w zarządzaniu. Pierwsi informatycy podejmowali próby budowy złożonych systemów informatycznych, których realizacja wymagała zaangażowania wielu osób. Niestety spora część tych przedsięwzięć nie została nigdy ukończona, pozostałe natomiast przekroczyły założony czas i budżet. Okazało się, że stosowane techniki budowy oprogramowania nie nadążały za rozwojem sprzętu, a producenci programów nie dawali żadnej gwaracji na to, że ich produkt działa zgodnie z opisem. To właśnie zjawisko nazwano kryzysem oprogramowania [28]. Problemy związane z wytwarzaniem oprogramowania oraz przeróżne propozycje ich rozwiązania mające doprowadzić do wyjścia z kryzysu zaowocowały powstaniem nowego działu informatyki inżynierii oprogramowania (ang. Software Engineering). Według definicji IEEE (ang. Institute of Electrical and Electronics Engineers) jest to zastosowanie systematycznego, zdyscyplinowanego i ilościowego podejścia do rozwoju, eksploatacji oraz utrzymania oprogramowania. Inżynieria oprogramowania obejmuje wszystkie aspekty tworzenia oprogramowania oraz ma za zadanie dostarczyć produkt, który zaspokaja potrzeby techniczne, ekonomiczne oraz społeczne. Aby to osiągnąć tworzone oprogramowanie powinno być przede wszystkim zgodne z oczekiwaniami klienta, niezawodne, efektywne, łatwe w konserwcaji i ergonomiczne. Liczne konferencje i dyskusje na temat kryzysu oprogramowania zaowocowały wskazaniem głównych przyczyn jego powstania, do którch można zaliczyć: dużą złożoność systemów informatycznych, 8

9 niepowtarzalność poszczególnych przedsięwzięć, brak informacji zwrotnej od klienta, zmianę wymagań w czasie trwania projektu, brak wsparcia ze strony kierownictwa projektu, brak wystarczającej wiedzy w danej dziedzinie, za wysokie wymagania klienta, słabo zdefiniowane cele, restrykcyjne ramy czasowe projektu. W celu ich wyeliminowania inżynieria oprogramowania stara się wprowadzać i stosować różne metodologie projektowania i wdrażania systemów informatycznych. Metodologia jest tutaj rozumiana jako zestaw pojęć, notacji, modeli, języków, technik i procedur postępowania służących do osiągnięcia określonego celu [29]. Metodologia stosuje pewne sprawdzone praktyki inżynierskie i odpowiada na następujące pytania: po co? cele, ukierunkowanie, jakie rezultaty? dokumenty, oczekiwania, kiedy? terminy, powiązania, zależności, co robić? etapy, zadania, na bazie czego? dane wejściowe, w jaki sposób? notacje, narzędzia, dobre praktyki, kto może to zrobić? kompetencje. Na podstawie przeprowadzonych badań, amerykańska organizacja The Standish Group określiła listę (Tab. 1.1) najważniejszych cech, które przyczyniają się do ostatecznego sukcesu projektu [30]. Cecha Waga cechy [%] Zaangażowanie klienta 15,9 Wsparcie kierownictwa 13,9 Dobrze określone wymagania 13,0 Właściwe planowanie 9,6 Realistyczne cele 8,2 9

10 Cecha Waga cechy [%] Małe odstępy pomiędzy kamieniami milowymi 7,7 Kompetencje pracowników 7,2 Odpowiedzialność zespołu 5,3 Jasno zdefiniowane cele i wymagania 2,9 Ciężko pracujący pracownicy 2,4 Pozostałe 13,9 Tabela 1.1. Podstawowe czynniki sukcesu projektu wg The Standish Group (na podstawie [30]). Z raportu tejże organizacji jasno wynika, że główną przyczyną upadków projektów są błędy w zarządzaniu. Pierwsze sześć czynników dotyczy bowiem warstwy zarządczej projektu, dopiero dalsze dotyczą bezpośrednio pracy zespołów oraz kompetencji jej członków. Od razu nasuwa się wniosek, że nawet najlepszy zespół projektowy będzie miał problemy z realizacją projektu, jeśli ten będzie źle zarządzany zarówno w warstwie strategicznej, jak i operacyjnej. Dlatego właśnie kwestia odpowiedniej metodologii zarządzania projektami ma tak krytyczne znaczenie w kontekście ewentualnego sukcesu lub porażki. Należy pamiętać, iż metodologia proponuje pewne wzorce, zasady oraz etykiety, które pomagają w uniknięciu najczęstszych błędów, lecz nie niwelują ich zupełnie. Wybór właściwej metodologii w ogromnej mierze zależy od specyfiki projektu i wielkości zespołu projektowego. Mimo wielu lat rozwoju inżynierii oprogramowania oraz przeróżnych metodologii ryzyko prowadzenia projektów informatycznych jest nadal wysokie. Świadczą o tym chociażby wyniki kolejnych badań organizacji The Standish Group. W swoim raporcie The Chaos Report z 2009 roku podają, że aż 24% projektów informatycznych zostało anulowanych na jednym z etapów pośrednich, zaś niecała połowa ogólu przedsięwzięć (44%) przekroczyła planowany budżet. The Standish Group wyliczyło również, że w 2009 roku rozwój oprogramowania w USA pochłonął bagatela 250 miliardów dolarów oraz tylko 32% projektów zostało ukończonych zgodnie z założonym budżetem oraz w wyznaczonym czasie. 10

11 Rozdział 2. Zwinne metodologie tworzenia oprogramowania W rozdziale tym przedstawimy główne założenia metodologii zwinnych, wskażemy ich zalety oraz porównamy je z tradycyjnymi technikami wytwarzania oprogramowania. 2.1 Manifest zwinności Idea zwinnego wytwarzania oprogramowania pojawiła się po raz pierwszy w 2001 roku, kiedy to siedemnastu inżynierów oprogramowania z USA: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, postanowiło stworzyć metodologię będącą przeciwwagą dla powolnego procesu, często spóźnionego w terminach, przekraczającego budżet i wymagającego mnóstwa dokumentacji. Efektem ich pracy jest zbiór zasad i reguł nazwany zwinnym manifestem (ang. Agile Manifesto). Przestrzeganie ich ma wyeliminować niedociągnięcia tradycyjnych metodologii tworzenia oprogramowania (model spiralny, kaskadowy) i związane z nimi problemy. Zwinny manifest zawiera cztery wartości i dwanaście zasad, które legły u podstaw nowoczesnej metodologii wytwarzania oprogramowania [6]. 11

12 Wartości zwinnej inżynierii oprogramowania 1. Ludzie i komunikacja ponad procesy i narzędzia. 2. Działające oprogramowanie ponad obszerną dokumentację. 3. Współpraca z klientem ponad negocjację kontraktu. 4. Reagowanie na zmiany ponad realizowanie planu. Autorzy podsumowują powyższe wartości bardzo ważnym zdaniem: Nie negujemy wartości tego, co po prawej, natomiast bardziej cenimy to, co po lewej [6]. Zwinne metodologie stawiają przede wszystkim na członków zespołu w skład którego wchodzi klient. Ludzie, ich wiedza oraz zdolność do rozwiązywania problemów decydują o końcowym sukcesie projektu. Najważniejsza jest współpraca i efektywna komunikacja między nimi, ponieważ atmosfera panująca w zespole w znacznym stopniu przekłada się na wydajność w pracy. Dobrze dobrane narzędzia mogą wpływać na ostateczny efekt realizacji projektu, jednak nie zagwarantują jakości oraz sprawnego zarządzania pracą w zespole. Stworzenie działającego oprogramowania jest bardziej istotne niż skupianie się nad obszerną dokumentacją. Stos papierów będzie bezużyteczny, jeśli dostarczone oprogramowanie nie będzie spełniało postawionych mu wymagań. Trzecia wartość mówi nam o ścisłej współpracy z klientem w celu zrozumienia jego oczekiwań oraz wyjaśnienia wszelkich pojawiających się wątpliwości. Dzięki temu, będziemy w stanie stworzyć i dostarczyć oprogramowanie lepszej jakości. Kontrakt zawiera wymagania, harmonogram i koszty przyszłego systemu, które bardzo często stają sie nieaktualne podczas trwania projektu, a czasami nawet dezaktualizują sie przed jego rozpoczęciem. Stąd ostatnia i chyba najistotniejsza zasada opiera się na dostosowywaniu planu projektu do zmieniających się wymagań. Takie podejście przyczynia się do osiągnięcia sukcesu biznesowego, którego miarą jest zadowolenie klienta. 12

13 Zasady zwinnej inżynierii oprogramowania 1. Najwyższym priorytetem jest zadowolenie klienta poprzez ciągłe dostarczanie wartościowego oprogramowania. Powinniśmy co kilka tygodni dostarczać klientowi kolejne, coraz bardziej funkcjonalne warianty oprogramowania. Dzięki temu, może on dokonywać przeglądu istniejącej funkcjonalności i na bieżąco przekazywać informację zwrotną, która pozwoli nam od samego początku poprawiać oprogramowanie tak, aby najlepiej spełniało oczekiwania klienta. 2. Zmiany wymagań nie są problemem, nawet w zaawansowanym stadium tworzenia oprogramowania. Utrzymywanie elastycznej struktury tworzonego oprogramowania pozwala zminimalizować wpływ zmian wymagań na kształt budowanego systemu. Z racji częstych iteracji do ewentualnej poprawy mamy niewielki fragment funkcjonalności. 3. Dostarczaj regularnie działające oprogramowanie, w odstępach od kilku tygodni do kilku miesięcy, z naciskiem na jak najkrótszy czas. Takie podejście pozwoli na częstą weryfikację oprogramowania, szybkie wykrycie ewentualnych błędów oraz otrzymanie informacji zwrotnej od klienta. Pliki dokumentów czy nawet najbardziej rozbudowane plany nie są w stanie zastąpić rzeczywistej funkcjonalności przekazywanej do weryfikacji stronie zamawiającej. 4. Ścisła współpraca pomiędzy klientem i pozostałymi członkami zespołu. Zaangażowanie klienta w projekt oraz codzienna współpraca ma się przyczyniać do stworzenia oprogramowania w pełni spełniającego jego wymagania. Jest to jedna z głównych zasad odróżniających zwinne metodologie od tradycyjnych. 5. Projekt należy opierać na osobach zmotywowanych. Należy zapewnić im odpowiednie środowisko pracy, niezbędną pomoc oraz obdarzyć ich zaufaniem. Ludzie są najważniejszym czynnikiem decydującym o powodzeniu projektu, dlatego powinniśmy zorganizować im niezbędne środowisko pracy oraz zapewnić należyte wsparcie. 13

14 6. Najbardziej wydajnym i skutecznym sposobem przekazywania informacji w zespole jest rozmowa twarzą w twarz. W dobie rozwoju internetu i nowoczesnych komunikatorów sieciowych, nadal niezastąpionym sposobem wymiany informacji pomiędzy członkami zespołu jest rozmowa twarzą w twarz. 7. Działające oprogramowanie jest podstawową jednostką miary postępu pracy. Bieżący postęp prac nie powinien być szacowany na podstawie objętości wytworzonej dokumentacji, ilości napisanego kodu czy też realizowanej fazy projektu. Obserwowany przyrost nowych funkcjonalności spełniających oczekiwania klienta jest najlepszą miarą postępu prac nad zwinnym projektem. Do jego mierzenia bardzo często wykorzystuje się tzw. wykres spalania (ang. burndown chart), który został omówiony w Rozdz Zwinny proces promuje zrównoważony rozwój. Sponsorzy, programiści oraz użytkownicy powinni być zdolni do utrzymywania stałego tempa pracy przez cały czas realizacji projektu. Prace w projekcie powinny być rozłożone równomiernie na wszystkie iteracje. Programiści nie powinni starać się od razu osiągać maksymalnej wydajności, której utrzymanie na dłuższą metę mogłoby okazać sie niemożliwe. Lepszym rozwiązaniem jest stałe tempo prac, dzięki kóremu zespół będzie mógł realizować standardy najwyższej jakości przez cały okres trwania projektu. 9. Dobre projektowanie oraz dążenie do doskonałości od strony technicznej wpływają na zwinność projektu. Ogromne znaczenie ma stosowanie właściwych technik projektowych oraz prostej i przemyślanej struktury oprogramowania już od pierwszej iteracji, co pozwoli uchronić nas od wielu błędów. Cel ten osiągnąć można za pomocą elastycznych technik modelowania, standardowych wzorców projektowych i przede wszystkim prostoty. 10. Prostota sztuka maksymalizacji pracy jeszcze nie wykonanej. Na każdym etapie tworzenia oprogramowania powinniśmy się skupić tylko na tym, co jest faktycznie wymagane w danym momencie. Nie traćmy czasu na dodawanie niepotrzebnych 14

15 elementów, dzięki temu mamy większą szansę zrealizować powierzone nam zadanie. Nie starajmy się również budować na siłę wielkich i skomplikowanych systemów do realizacji postawionych celów wybierajmy zawsze najkrótszą drogę. 11. Najlepsza architektura, wymagania i projekty powstają w samoorganizujących się zespołach. Odpowiedzialność za przydzielone zadania powinna spoczywać na całym zespole, a nie na poszczególnych jego członkach. Zespół programistów powinien sam decydować jak rozdzielić powierzone mu zadania, oraz jak je najefektywniej zrealizować. Ważne jest aby każdy członek zespołu posiadał minimalną wiedzę na temat technologii, którą posługują się pozostali koledzy. Nie oznacza to oczywiście, że mają być oni równo biegli w każdej dziedzinie, wystarczy, że zespół będzie mógł kontynuować swoją pracę w przypadku nieobecności jednego z jego członków. 12. W regularnych odstępach czasu zespół projektowy zastanawia się nad swoją efektywnością, następnie dąży do jej poprawy. Środowisko, w którym pracują członkowie zespołu podlega stałym zmianom, dlatego zwinność zespołu zależy w dużej mierze od zdolności dostosowywania się do tych modyfikacji. Ważną rzeczą jest również identyfikowanie problemów oraz metod ich rozwiązania. Mimo usilnych starań programistów oraz zespołów projektowych, których głównych celem jest tworzenie możliwie jak najwyższej jakości oprogramowania, bardzo duży odsetek projektów informatycznych kończy się niepowodzeniem lub nie przynosi korzyści dla obu stron. Dlatego zwinne metodologie kładą nacisk przede wszystkim na: produkt wysokiej jakości, niskie koszty zmian, elastyczne wymagania, większą satysfakcję klienta, większą wydajność i produktywność, lepszą przewidywalność, zredukowane ryzyko. 15

16 2.2 Metodologie tradycyjne vs zwinne Różnic pomiędzy tradycyjnym modelem wytwarzania oprogramowania, którego reprezentantem jest model kaskadowy (ang. Waterfall model), a modelem zwinnym jest sporo, można jednak spośród nich wybrać kilka najistotniejszych. Na samym początku przedstawimy cechujące te metodologie podejście do procesu wytwórczego: sterowany planem (ang. plandriven) oraz zorientowany na wartość (ang. value/vision-driven). Model kaskadowy jest sterowany planem. Oznacza to, że już na samym początku projektu dokładnie znamy zakres naszej pracy i to dopiero ma wpływ na termin dostarczenia produktu finalnego, i jego koszty. W przypadku metodologii zwinnych jest odwrotnie posiadając z góry określony budżet i oczekiwany przez klienta termin realizacji, tak manewrujemy zakresem pracy, aby jak najlepiej spełnić wymagania klienta. Jest to podejście zorientowane na wartość. Obrazowo przedstawia to Rys Rysunek 2.1. Podejście do procesu wytwórczego w modelu kaskadowym oraz zwinnym (na podstawie [7]). W modelu kaskadowym jesteśmy zobowiązani do dostarczenia zamówionego produktu w określonym czasie i za określone pieniądze. Jeśli w trakcie projektu okaże się, że koszty znacznie przekraczają budżet, będziemy wręcz zmuszeni do ucinania niektórych aktywności, żeby tylko zmieścić się w terminie (najczęściej wybór pada na testy). W przypadku lekkich metodologii, zakres projektów może być (i zazwyczaj jest) płynny. Ograniczające ramy czasowe i ryzyko, że nie wszystkie wymagane przez klienta funkcjonalności 16

17 zostaną zaimplementowane zmuszają nas do ustalenia pewnych priorytetów. Klient powinien wskazać zespołowi projektowemu, które funkcjonalności są dla niego najważniejsze, a z których może w najgorszym wypadku zrezygnować. Pozwala to skupić się programistom na kwestiach priorytetowych. Jeśli istnieje ryzyko, że wymagana funkcjonalność nie zostanie zrealizowana, klient musi być zawsze o tym wcześniej poinformowany. Może on zadecydować o zwiększeniu budżetu lub przesunięciu terminu oddania. Kolejną istotną różnicą pomiędzy dwoma modelami jest kolejność etapów wytwarzania oprogramowania. Model kaskadowy charakteryzuje się tym, że kolejne etapy wykonywane są sekwencyjnie, jeden po drugim i nie możemy przejść do następnej fazy przed ukończeniem poprzedniej. I tak, na samym początku zbieramy wymagania klienta, dokonujemy ich analizy i na tej podstawie projektujemy cały system. Później przechodzimy do kodowania, a na koniec testujemy i finalnie oddajemy klientowi gotowy produkt (Rys. 2.2). Rysunek 2.2. Etapy wytwarzania oprogramowania w modelu kaskadowym (na podstawie [7]). Tradycyjny model kaskadowy ma swoje zalety i wady. Jego zaletą jest przede wszystkim przejrzystość i uporządkowanie. Jest także łatwy do zrozumienia przez klienta, zwłaszcza nie posiadającego wiedzy technicznej. Minusem natomiast jest zagrażające widmo przyśpieszonego tempa prac w jego końcowej części. Często rezygnuje się z testów, które zostały przewidziane na sam koniec, skutkiem czego klient nie zawsze otrzymuje sprawdzone oprogramowanie. Tego typu modelu należy używać wyłącznie w przypadku, gdy wymagania klienta są dobrze znane i przejrzyste. Twórcy zwinnych metodologii postanowili zakmnąć kolejne etapy wytwarzania oprogramowania w iteracje o niezmiennej długości, w których za każdym razem przeprowadza się pełny cykl zadań programistycznych zaczynając od zbierania wymagań, analizy, przygotowania testów, poprzez projektowanie, kodowanie na integracji kończąc (Rys. 2.3). 17

18 Rysunek 2.3. Etapy wytwarzania oprogramowania w modelu zwinnym (na podstawie [7]). Każda iteracja kończy się dostarczeniem klientowi kolejnej działającej wersji oprogramowania. Takie podejście sprawia, że zmieniające się potrzeby klienta nie wymuszają całkowitej reorganizacji kodu. Innowacją jest fakt, że testy są przygotowywane najpierw, zanim programiści przystąpią do właściwego kodowania. Technika ta nosi nazwę programowania sterowanego testami (ang. Test-Driven Development, TDD) i została szczegółowo opisana w Rozdz Rational Unified Process zwinna metodologia czy ciężki proces Rational Unified Process (w skrócie RUP) to zunifikowany proces iteracyjnego i przyrostowego wytwarzania oprogramowania, którego twórcami są Philippe Kruchten i Ivar Jacobson z firmy Rational Software Corporation. Proces RUP sięga swoimi korzeniami do spiralnego modelu cyklu życia oprogramowania oraz wcześniejszych metod, które legły u podstaw powstania języka UML (ang. Unified Modeling Language). RUP nie jest jednym, ściśle określonym procesem, definiuje natomiast szablon (ang. framework) postępowania, który może być dopasowany do potrzeb budowy dowolnego oprogramowania z uwzględnieniem specyfiki organizacji. Powstał on na bazie analizy najczęstszych przyczyn niepowodzeń istniejących procesów wytwarzania oprogramowania. Autorzy diagnozowali projekty, które zakończyły się fiaskiem próbując jednocześnie wskazać czynniki, które do tego doprowadziły. Według nich, niepowodzenia projektów były spowodowane błędami, do których należy zaliczyć: niewystarczająco precyzyjne zarządzanie wymaganiami, brak testów, zbytnia złożoność oprogramowania, nieprecyzyjna komunikacja, brak zarządzania ryzykiem oraz automatyzacji prowadzenia projektu. Efektem badań był zbiór podstawowych zasad i dobrych praktyk, które legły u podstaw powstania Rational Unified 18

19 Process. Proces RUP opiera się na zbiorze sześciu najlepszych praktyk [8], które zostały przedstawione i scharakteryzowane w Tab Praktyki RUP 1. Iteracyjne tworzenie oprogramowania 2. Zarządzanie wymaganiami 3. Używanie architektury opartej na komponentach 4. Wizualizacja 5. Kontrola jakości oprogramowania 6. Kontrola zmian oprogramowania Charakterystyka Szybka identyfikacja błędów, redukcja ryzyka, możliwość pokazania klientowi działającej częsci systemu. Identyfikacja wymagań systemu zmieniających się w czasie jest procesem ciągłym: identyfikacja i specyfikacja wymagań oraz wykrywanie ich zmian. Zwiększa elastyczność architektury, wspomaga ponowne użycie, umożliwia zarządzanie modułami. Graficzne modele poprawiają zrozumienie projektów przez wszystkich członków zespołu (język UML). Przeprowadzanie testów pod koniec każdej iteracji pomaga nam szybciej wykryć ewentualne błędy, naprawiać je w fazie konstrukcji oprogramowania redukując tym samym koszty. Definiuje metody śledzenia i zarządzania zmianami oraz bada ich wpływ na proces tworzenia oprogramowania. Dzięki temu możemy efektywnie mierzyć postęp prac nad projektem poprzez częstotliwość oraz rodzaj wprowadzanych zmian. Tabela 2.1.Praktyki RUP (na podstawie [8]) Cykl tworzenia oprogramowania Cykl wytwórczy Rational Unified Process bazuje na modelu spiralnym. Jego cechą charakterystyczną jest umiejscowienie procesów w dwóch płaszczyznach (Rys. 2.4). W pionie przedstawione są dyscypliny, czyli grupy zadań wykonywane przez pracowników oraz odpowiadające im role, przepływy oraz artefakty. W poziomie natomiast przedstawione zostały 19

20 fazy projektu oraz kolejne iteracje [9]. Projekt RUP został podzielony na cztery fazy: rozpoczęcia (ang. Inception), opracowywania (ang. Elaboration), budowania (ang. Construction) oraz przekazania systemu (ang. Transition). Zakończenie każdej z nich wiąże się z osiągnięciem kamienia milowego, czyli końcowego punktu, który podsumowuje określony zestaw zadań i zatwierdza wykonaną pracę. Wszystkie fazy dodatkowo podzielone są na iteracje kończące się dostarczeniem klientowi uruchamialnego fragmentem kodu programu bądź systemu. Czas trwania pojedynczej iteracji waha się w przedziale od dwóch tygodni do sześciu miesięcy. Rysunek 2.4. RUP cykl tworzenia oprogramowania (na podstawie [9]). Rozpoczęcie Pierwsza faza w projekcie to faza rozpoczęcia, w której formułowane jest zagadnienie biznesowe. Ustala się w niej założenia techniczne, rynkowe i ekonomiczne. Na tym etapie tworzony jest harmonogram prac, szacuje się ryzyko oraz koszt prowadzenia projektu. Dodatkowo tworzony jest prosty model przypadków użycia, opis projektu (wymagania, ograniczenia, funkcjonalność) oraz wstępna architektura systemu. Pod koniec fazy następuje weryfikacja projektu. Jeśli nie osiągnie on kamienia milowego (nazywanego ang. Lifecycle 20

21 Objective Milestone) może być albo zakończony, albo faza ta zostanie powtórzona (w celu poprawienia projektu wstępnego). Opracowanie Gdy zapadnie decyzja o kontynuacji, projekt przechodzi w kolejną fazę nazywaną fazą opracowania. Następuje tutaj ustalenie wymagań, zdefiniowanie końcowej architektury systemu oraz przygotowanie planu całego procesu wytwarzania systemu. Zakończenie tej fazy wiąże się z osiągnięciem kolejnego kamienia milowego (nazywanego ang. Lifecycle Architecture Milestone). Jeśli nie jesteśmy w stanie tego dokonać możemy albo zakończyć nasz projekt, albo opracować go od nowa. Budowa Kolejną fazą jest budowa. Rozpoczynając ją przechodzimy w obszar zwiększonego ryzyka, w którym wprowadzanie zmian jest dużo trudniejsze. Główny nacisk w tej fazie położony jest na tworzenie kolejnych komponentów systemu. W sposób iteracyjny i przyrostowy następuje integracja wszystkich komponentów składających się na tworzony system oraz przekazanie jego części klientowi. Zakończenie fazy budowy również wiąże się z osiągnięciem kamienia milowego (nazywanego ang. Initial Operational Capability Milestone). Po jego osiągnięciu, posiadamy w pełni przetestowany oraz udokumentowany program nadający się do wdrożenia. Przekazanie Ostatnią fazą jest przekazanie systemu. Jej celem jest dostarczenie końcowemu użytkownikowi gotowego systemu. Dodatkowo przeprowadzane są szkolenia użytkowników i administratorów oraz następuje końcowe sprawdzenie jakości. Po tych czynnościach i osiągnięciu ostatniego kamienia milowego (nazywanego ang. Produkt Release Milestone) może nastąpić produkcja systemu, która kończy cykl wytwarzania oprogramowania. Jak już wspomnieliśmy wyżej, iteracje podzielone są na dziewięć dyscyplin wykonywanych równolegle. Każda z nich obejmuje zadania zmierzające do osiągnięcia specyficznych celów produkcji oprogramowania i w mniejszym, bądź większym stopniu zaznacza swój udział w każdej iteracji. Dyscypliny podzielone są na dwie kategorie: 21

22 inżynierskie: modelowanie biznesowe, wymagania, analiza i projektowanie, implementacja, testowanie, wdrożenie, pomocnicze: zarządzanie zmianami oraz konfiguracją, zarządzanie projektem, środowisko. Większość z tych pojęć jest dobrze znana w inżynierii oprogramowania. Jednak dwa z nich: modelowanie biznesowe i środowisko wymagają wyjaśnienia. Modelowanie biznesowe Modelowanie biznesowe tłumaczy w jaki sposób opisać wizję organizacji, w której będzie wdrożony system. Inżynierowie oprogramowania muszą zrozumieć jej strukturę, dynamikę i bieżące problemy oraz zidentyfikować potencjalne obszary, które można ulepszyć dzięki ciągłej modyfikacji procesu wytwórczego. Środowisko Praktycznie cała praca należąca do tej dyscypliny wykonywana jest w fazie rozpoczęcia projektu. Celem środowiska jest wspieranie pracy zespołu projektowego poprzez wybór i określenie narzędzi, które będą użyte w procesie produkcji, identyfikację środowiska systemowego oraz dostarczanie wytycznych odnośnie samego procesu RUP. RUP jest procesem iteracyjnym, kładącym nacisk na dobrą architekturę systemu. Iteracyjność oznacza ulepszanie systemu w wielu cyklach procesu, dzięki czemu każdy z nich kończy się uruchamialnym fragmentem kodu programu bądź systemu. Nacisk położony na możliwie wczesne opracowanie architektury ma istotne znaczenie dla procesu tworzenia oprogramowania, a ukierunkowanie na przypadki użycia określa funkcjonalność systemu, która powinna być zgodna z wymaganiami nakładanymi przez klienta. Na uwagę zasługuje fakt, iż RUP jest konfigurowalnym środowiskiem. Oznacza to, że nadaje się on do zastosowania w każdej organizacji tworzącej oprogramowanie. Sprawdza się zarówno przy małych projektach (od 3 do 10 programistów, czas procesu wytwórczego krótszy niż rok) jak i dużych. Rational Unified Process pojawił się mniej więcej w tym samym czasie co metody zwinne, dlatego od razu rozgorzała gorąca dyskusja na temat ich zgodności. Pomimo, że obydwie grupy metodologii zakładają iteracyjne tworzenie oprogramowania, różnią się wieloma innymi 22

23 aspektami, m. in. stosunkiem do modelowania, planowania, sposobu komunikacji i współpracy z klientem RUP jako ciężki proces RUP jest uniwersalnym oraz konfigurowalnym szablonem procesu. Z racji tego bardzo często postrzegany jest jako ciężki i kosztowny. Główne problemy stwarza jego nieograniczona dostosowywalność, mnogość zdefiniowanych ról, procesów oraz dokumentów. Warto jednak zauważyć, że RUP nie został opracowany i przygotowany jako gotowy do użycia proces, który od razu można wdrożyć w konkretnej organizacji czy zespole. Należy go traktować raczej jako zbiór narzędzi, z którego w zależności od potrzeb wybieramy tylko te, które uważamy w danej chwili za najlepsze i najbardziej pomocne. Martin Fowler w artykule na temat nowych metodologii [10] opisuje swoje doświadczenia z procesem RUP: Napotkałem przypadki użycia RUP począwszy od modelu kaskadowego z analitycznymi iteracjami, aż do pełnego procesu zwinnego. Takie podejście wg Fowlera czyni RUP nic nie znaczącym słowem, ponieważ promowanie RUPu jako pojedynczego procesu doprowadziło do tego, że ludzie mogą zrobić wszystko i nazwać to RUPem RUP jako zwinna metodologia Współpraca pomiędzy dostawcą a klientem jest główną cechą i oznaką zwinności. Szczególne znaczenie dla procesu RUP oraz jego uzwinnienia powinien mieć aktywny udział zainteresowanych stron podczas całego cyklu tworzenia oprogramowania. Dzięki prostym narzędziom takim jak papier i tablica oraz technikom tworzenia opowiadań użytkownika i szkiców ekranu, zainteresowane strony mogą stać się aktywnymi uczestnikami procesu tworzenia oprogramowania. Nauka i stosowanie tak prostych narzędzi nie sprawia nikomu kłopotu oraz odbywa się bardzo szybko, czego nie można powiedzieć np.: o nauce diagramów UML. Należy pamiętać także o zapewnieniu dobrej komunikacji między wszystkimi członkami zespołu, która znacząco zmniejsza zapotrzebowanie na dokumentację oraz spotkania kontrolne redukując tym samym koszty oraz czas. Klient powinien również brać udział w dziedzinie analizy i projektowania, a nie tylko podczas modelowania biznesowego oraz zbierania wymagań, jak ma to miejsce w przypadku typowego procesu RUP. 23

24 Kolejnym kluczowym aspektem jest okresowe dostarczanie działającego oprogramowania. Metodyki zwinne zalecają aby robić to w odstępach od jednego do dwóch tygodni. RUP stara się dostarczać tymczasowe działające fragmenty oprogramowania pod koniec każdej iteracji w fazie konstrukcji czyli mniej więcej w odstępach od jednego do sześciu miesięcy. Warto zastanowić się nad tym po co marnować cenny czas na pisanie szczegółowych przypadków użycia, po co używać skomplikowanych narzędzi do projektowania graficznego interfejsu użytkownika jeśli szkic wykonany na zwykłej tablicy jest w zupełności wystarczający. Po co sporządzać raporty o stanie systemu jeśli osoby do których potem trafią mogą uczestniczyć w codziennych spotkaniach zespołu projektowego. Wiele zespołów pracujących w metodologii RUP grzęźnie z powodu zbyt długich iteracji, nieraz przekraczających cztery tygodnie. Im dłuższa iteracja tym łatwiej odłożyć na bok krytyczne aktywności takie jak np.: pisanie testów Podsumowanie Podsumowując powyższe rozważania można śmiało stwierdzić, iż termin zwinny RUP nie jest oksymoronem. Rational Unified Process można usprawnić, jeśli tylko tego chcemy. Jednakże dzięki bogactwu szczegółowych porad i dokumentacji o wiele bardziej nadaje się on jako baza do tworzenia cięższych procesów. Jeśli naprawdę potrzebujemy zwinności, lepiej postawić na Programowanie Ekstremalne, FDD czy DSDM, ponieważ o wiele łatwiej jest określić, że czegoś nam brakuje, a następnie dodać to do lekkiego procesu niż usuwać zbędne procedury lub ich części z cięższych. Dlatego też zaliczenie procesu RUP do grona zwinnych metogologii zależy tylko i wyłącznie od nas samych, od naszych potrzeb i doświadczenia w wyborze jego elementów składowych. 24

25 Rozdział 3. Przegląd zwinnych metodologii tworzenia oprogramowania Do grupy metodologii wytwarzania oprogramowania nazywanych zwinnymi możemy zaliczyć m.in. Programowanie Ekstremalne (XP), Scrum, Crystal family, Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM) oraz Feature Driven Development (FDD). Metody te mają pewne cechy wspólne, które wynikają z przyjętej ideologii tworzenia oprogramowania zapisanej w manifeście zwinnych metodologii. Poniżej scharakteryzujemy i przedstawimy główne założenia każdej z nich. 3.1 Programowanie Ekstremalne Programowanie Ekstremalne (ang. extreme Programming, XP) to zwinna metodologia prowadzenia projektów informatycznych, która powstała jako próba zaradzenia problemom związanym z długimi cyklami dostarczania oprogramowania. Charakteryzuje ją przede wszystkim ewolucyjne podejście do projektowania i programowania oraz ekstremalnie ścisła współpraca z klientem. Rezygnuje ona z formalizmów, które często nadmiernie obciążaja programistów i kierowników zespołów, jak np. tworzenia rozbudowanej dokumentacji. Dzięki ekstremalnie krótkim iterajcom w dostarczaniu kolejnych wersji oprogramowania oraz nadaniu wysokiego priorytetu kontaktom członków zespołu z klientem, projekty prowadzone metodologią XP szybciej potrafią przystosować się do zmiennych wymagań klienta [13]. Twórcami XP są Kent Beck, Ward Cunningham oraz Ron Jeffries. Metodyka powstała w latach podczas prac nad systemem przetwarzającym listy płac dla pracowników firmy Chrysler Corporation. Po roku pracy, na skutek błędnego zarządzania i kłopotów technicznych system nie potrafił obliczyć i wydrukować pojedynczej wypłaty. W tym czasie szefem projektu został Kent Beck, który na podstawie wcześniejszych doświadczeń oraz podstaw 25

26 teoretycznych opracowanych przez Warda Cunninghama stworzył podwaliny nowej metodyki, która była stosowana podczas rozwoju projektu. Pierwszy sukces pojawił sie juz po roku, kiedy oddano do użytku pierwszą część systemu. Niestety w ostateczności projekt popadł w finansowe tarapaty i został zawieszony w 1999 roku. Jednakże pomysły wykorzystane podczas realizacji systemu zostały w 2000 roku dokładnie opisane przez Becka w książce pt. Extreme Programming Explained: Embrace Change, zyskując akceptację wielu członków zespołów programistycznych Wartości XP Programowanie Ekstremalne jest metodyką budowy oprogramowania opartą na fundamentach pięciu wartości: komunikacji, prostoty, informacji zwrotnej, odwagi i szacunku. Komunikacja Pierwszą wartością XP jest komunikacja. Budowanie systemów informatycznych wymaga przekazania wymagań klienta programistom. W tradycyjnych metodykach wykorzystuje się w tym celu dokumenty takie jak np. specyfikacja wymagań. XP posługuje się komunikacją werbalną, dzięki czemu wiedza o systemie bardzo szybko rozprzestrzenia się wśród członków zespołu. Prostota Drugą wartością jest prostota. XP zachęca do tworzenie najprostszych działających rozwiązań, ponieważ rzeczy proste łatwiej zrozumieć. Każdy projekt powinien kłaść nacisk na jak najmniejszą liczbę komponentów niezbędnych do realizacji określonej funkcjonalności. Stosowane przez programistów rozwiązania powinny być czytelne i zrozumiałe. Informacja zwrotna Kolejna wartość to informacja zwrotna. Dotyczny ona różnych wymiarów: Systemu odpowiedź systemu otrzymywana w procesie testowania jednostkowego pozwala natychmiast sprawdzić efekt wprowadzonych zmian, 26

27 Klienta testy akceptacyjne pozwalają sprawdzić w jakim stanie znajduje się aktualnie budowany system, Zespołu oszacowanie czasu realizacji nowych wymagań pomaga klientowi podjąć decyzję, czy dane wymaganie będzie realizowane od razu, w przyszłości, a może w ogóle. Odwaga Programowanie Ekstremalne wymaga od członków zespołu odwagi. Przede wszystkim, muszą oni przestrzegać ustalonych zasad projektowania i kodowania bez obaw związanych z dalszą realizacją projektu. Muszą mieć także odwagę rozpocząć kodowanie bez rozbudowanego etapu analizy i projektowania. Na zakończenie, nie mogą się bać refaktoryzacji działającego oprogramowania i dokonywać jej zawsze wtedy, kiedy jest to potrzebne. Szacunek Ostatnia wartość to szacunek. Chodzi tutaj przede wszystkim o szacunek do pracy, projektu i czasu pozostałych członków zespołu, poprzez dążenie do najwyższej jakości tworzonego oprogramowania i szukanie najlepszych rozwiązań projektowych Cykl tworzenia oprogramowania Cykl życia projektu XP składa się z pięciu faz: eksploracja (ang. Exploration), planowanie (ang. Planning), iteracja (ang. Iteration), przygotowanie do produkcji (ang. Productionizing), utrzymanie (ang. Maintenance) oraz zakończenie projektu (ang. Death) (Rys. 3.1) [8]. 27

28 Rysunek 3.1. Cykl życia projektu XP (na podstawie [8]). Faza eksploracji W fazie eksploracji zespół projektowy zapoznaje się z tematem prac i pozyskuje podstawowe informacje od klienta. Na podstawie tzw. opowiadań użytkownika (ang. user stories, dokładny opis w rozdziale piątym) budowana jest lista funkcjonalności, które realizowany system musi posiadać. W tym samym czasie, projektanci testują wybraną technologię tworząc niezbędne prototypy architektury systemu oraz zapoznają się z używanymi narzędziami i praktykami, które będą stosowane podczas realizacji projeku. Faza planowania Opowiadaniom przedstawionym przez użytkownika nadawane są priorytety. Następnie, w porozumieniu z użytkownikiem, zestawiana jest lista funkcjonalności, które mają być opracowane w nadchodzącej iteracji. Programiści oceniają czas realizacji zadań, ustalany jest harmonogram prac i termin zakończenia iteracji. Faza iteracji Składa się z jedno lub kilkutygodniowych cykli implementujących kolejne właściwości systemu wybrane przez klienta. W każdym cyklu wykonywane są działania analityczne, projektowe, kodowanie i testowanie. Programiści regularnie zatwierdzają wprowadzane zmiany oraz integrują 28

29 je z pozostałymi modułami systemu. Na końcu każdego cyklu wykonywane są testy akceptacyjne. Po zakończeniu ostatniego cyklu system jest gotowy do produkcji. Faza przygotowania do produkcji W tej fazie system zawierający uzgodnioną porcję funkcjonalności jest przygotowywany do wdrożenia. Wykonywane są dodatkowe testy oraz sprawdzana jest wydajność systemu, zanim trafi on w ręce klienta. Pojawiające się ewentualne uwagi użytkownika są implementowane w bieżącym wydaniu lub przeznaczane do implementacji w następnej wersji oprogramowania. Faza utrzymania Po wdrożeniu systemu klient jest wyposażony w działającą wersję oprogramowania, która wymaga opieki i nadzoru. Poza utrzymywaniem i konserwacją systemu zespół projektowy równocześnie wykonuje kolejną wersję oprogramowania. Dodatkowo, w trakcie pracy z oprogramowaniem, klient formułuje kolejne postulaty dla zespołu projektowego. Faza utrzymania często pociąga za sobą zmiany w zespołach projektantów oraz wzrost zatrudnienia. Faza zakończenia Gdy klient nie jest już zainteresowany dodawaniem nowej funkcjonalności do systemu spada tempo współpracy z zespołem projektowym, a formułowane wnioski o rozszerzenie funkcjonalności mają charakter drugorzędny i często nie są wdrażane z powodów ekonomicznych. W tej fazie zespół projektowy podejmuje decyzję o zakończeniu projektu, blokuje zmiany w architekturze systemu i kodzie źródłowym oraz opracowuje niezbędną dokumentację systemu Podstawowe praktyki Programowania Ekstremalnego bazuje na zbiorze dwunastu najlepszych praktyk, które stanowią fundamentalny element pracy zespołu programistycznego. Należą do nich: gra planistyczna, małe wydania, metafora, prosty projekt, programowanie sterowane testami, refaktoryzacja, programowanie w parach, współwłasność kodu, ciągła integracja, brak nadgodzin, udział klienta w zespole i standard kodowania. Większość z nich skupia się przede 29

30 wszystkim na apsekcie technicznym, a ich realizacja służy wytworzeniu artefaktów (kodu źródłowego i przypadków testowych) wysokiej jakości, odpowiadających faktycznym potrzebom klienta. Część praktyk dotyczy również wymiaru społecznego, skupiając się na budowie atmosfery pełnego zaangażowania w wykonywaną pracę i zaufania w zespole oraz dobrej komunikacji pomiędzy klientem a wykonawcą. W kolejnych punktach przedstawimy i opiszemy wybrane praktyki. Udział klienta w zespole (ang. Whole Team) Większość współczesnych metodyk zakłada stałą współpracę zamawiającego z wykonawcami. Jednak w wielu przypadkach obecność klienta oznacza jego zainteresowanie projektem, sporadyczny udział w spotkaniach i ścisłe określenie wymagań. XP zakłada znacznie ściślejszą współpracę klienta z zespołem wykonawców. W praktyce oznacza to, że przedstawiciel klienta lub on sam jest członkiem zespołu projektowego. Stara się na bieżąco i stale uczestniczyć w przedsięwzięciu, posiada pełną wiedzę na temat systemu i jest w stanie samodzielnie podjąć wszelkie decyzje związane z projektowaniem i planowaniem. Prosty projekt (ang. Simple design) Regułą, na której powinno opierać się projektowanie systemu, jest tworzenie najprostszych działających rozwiązań. Zatem dobry projekt to taki, który jest pokryty dużą liczbą testów jednostkowych, nie posiada duplikacji funkcjonalności oraz zawiera najmniejszą możliwą liczbę komponentów niezbędnych do realizacji danej funkcji. Z drugiej strony, prostota projektu nie oznacza, że musi on stosować banalne rozwiązania. Istotne jest jedynie, aby rozwiązania te były czytelne i zrozumiałe. Programowanie w parach (ang. Pair programming) Programowanie w parach jest praktyką, która wzbudza najwięcej emocji oraz kontrowersji. Polega ona na tym, że para programistów wyposażona w jeden komputer przydzielana jest do wspólnego zadania programistycznego. Jeden z programistów pisze kod, natomiast drugi śledzi jego pracę, sugeruje możliwe rozwiązania, zadaje pytania i zwraca uwagę na błędy syntaktyczne. Według zasad tej praktyki, pary powinny się między sobą mieszać. Również programiści wewnątrz pary powinni co jakiś czas zamieniać się miejscami. W ten sposób, wysiłek jest 30

31 rozłożony równomiernie, a każdy programista zna praktycznie całość kodu, w związku z tym bardzo szybko wyrównują się różnice w wiedzy i umiejętnościach członków zespołu. Programowanie w parach jest trudne i wymaga dobrego zgrania zespołu, jest też często krytykowane przez menedżerów organizacji programistycznych, którzy postawieni przed perspektywą dwukrotnego zwiększenia kosztów produkcji, wątpią w opłacalność takiego podejścia. Pogląd ten jest jednak tylko na pierwszy rzut oka zasadny. Każdy, kto kiedykolwiek spróbował programować w parach, doświadczył, że całkowicie zmienia ono sposób pisania kodu. Powoduje znacznie wyższą wydajność pary od pojedynczego programisty. Gdyby wziąć pod uwagę również jakość i liczbę błędów, to wydajność dwóch programistów mogłaby być dwukrotnie wyższa od pojedynczego. Refaktoryzacja (ang. Refactoring) Refaktoryzacja jest jedną z kluczowych praktyk wspomagających pielęgnację oprogramowania. Polega ona na wprowadzaniu zmian w strukturze kodu projektu bez zmiany realizowanej przez niego funkcjonalności. Przykładowe konkretne działania podczas refaktoryzacji to: skracanie metod oraz klas, usuwanie powtarzajacych sie fragmentów kodu, usuwanie niepotrzebnych iteracji oraz zbyt wielu zmiennych roboczych. Zabiegi te prowadzą do uzyskania lepszej struktury systemu oraz bardziej przejrzystego kodu. Warunkiem skutecznej refaktoryzacji jest ponowne przeprowadzenie wszystkich testów po wprowadzeniu zmian. Standardy kodowania (ang. Coding standards) Praktyka ta narzuca wszystkim programistom stosowanie jednego wspólnego standardu kodowania. Standard taki powinien być ustalony i zaakceptowany przez całą grupę, a jego zadaniem jest jednoznacznie określić wygląd kodu źródłowego tak, aby wszyscy programiści czuli się jego współautorami, łatwo go czytali i rozumieli, a tym samym byli w stanie go modyfikować. Istnieje wiele gotowych standardów dedykowanych dla konkretnych języków programowania. Jednak w przypadku zwinnych metodologii istotniejsze jest nie skorzystanie z gotowych, sprawdzonych wzorców, ale ustalenie własnego standardu tak, aby był stosowany w praktyce przez wszystkich członków zespołu. 31

32 Ciągła integracja (ang. Continuous integration) Ciągła integracja polega na częstym i regularnym włączaniu dokonanych w kodzie zmian do głównego repozytorium. Zwinne metodologie zakładają, że integracja jest przeprowadzana co kilka godzin, jednak nie rzadziej niż raz dziennie. W ten sposób pod koniec każdego dnia system tworzy spójną, przetestowaną całość, którą można skompilować i która nie zawiera błędów. W celu ułatwienia procesu ciągłej integracji, powstały dedykowane serwery, których zadaniem jest ciągłe monitorowanie zmian pojawiających się w repozytorium kodu i odpowiednie przebudowywanie projektu z jednoczesnym poinformowaniem wszystkich programistów o dokonanych zmianach. Ciągła integracja pozwala na szybkie wykrycie dwóch popularnych problemów przy zdalnej produkcji oprogramowania. Pierwszy problem dotyczy projektów rozwijanych na wiele platform (Windows, Linux, MacOS). Rzadko który programista ma pod ręką wszystkie docelowe systemy operacyjne i nie ma możliwości przetestowania, czy jego kod kompiluje się poprawnie na innych platformach.wykona to za niego serwer ciągłej integracji. Drugi problem jest popularniejszy. Zdarza się często, że wraz z naszą poprawką zapominamy wgrać kilka wymaganych plików. I mimo, że wydaje nam się, że wszystko jest w porządku, to na innym komputerze nie da się zbudować i uruchomić aplikacji z powodu braku zasobów. System do ciągłej integracji jest w stanie zgłosić taki problem w ciągu kilku minut pozwalając naprawić pomyłkę zanim ktokolwiek z pozostałych osób zorientuje się, że coś jest nie tak. Programowanie sterowane testami (ang. Test-Driven Development, TDD) Tworzenie i wykonywanie testów jest czynnością żmudną, dlatego zwykle jest ona odkładana na sam koniec prac. Wówczas, gdy brakuje czasu, faza testowania jest często skracana do minimum. Jednak testowanie jest zbyt ważne, aby można je pominąć lub zredukować, dlatego zwinne podejście do wytwarzania oprogramowania proponuje rozpoczęcie testowania przed właściwym kodowaniem, a następnie utrzymywanie i aktualizację zestawów testowych w miarę postępu prac programistycznych. Jest to jedna z trudniejszych praktyk ponieważ wymaga od programisty zmiany sposobu myślenia podczas projektowania. Przed napisaniem kodu realizującego daną funkcję, programista ma obowiązek przygotować zestaw testów jednostkowych, które będą wykonywane po zaimplementowaniu funkcji, i które zweryfikują poprawność jej działania. Jako testy jednostkowe (ang. unit tests) należy rozumieć 32

33 tutaj testy weryfikujące poprawność działania pojedynczych elementów programu np. metod lub obiektów w programowaniu obiektowym, czy procedur w programowaniu proceduralnym. Kolejność działania programisty składa się z trzech kroków: testowania, kodowania oraz refaktoryzacji. Praktyka TDD nakazuje nam, aby test był niewielki, odnoszący się do równie niewielkiej części kodu. Natomiast refaktoryzacja powinna dotyczyć nie tylko właściwego kodu aplikacji ale również testów. Cały cykl testowanie-kodowanie-refaktoryzacja powinien zająć około 10 minut. Zaprojektowane przypadki testowe powinny być utrzymywane (tzn. powiązane z zaimplementowanymi opowiadaniami użytkownika) i uruchamiane za każdym razem, gdy następuje integracja nowych funkcji z systemem. W przypadku znalezienia błędu, który nie był dotąd wykrywany przez przypadki testowe, należy stworzyć brakujące testy i dołączyć je do zestawu testowego. Główną z zalet pisania testów zanim zaczniemy pisać właściwy kod jest konieczność zawarcia w nich przypadków, które ocenią, czy nasz kod działa zgodnie z oczekiwaniem. Gdy pracy jest dużo, łatwo zapomnieć o fragmencie funkcjonalności. W tym przypadku uruchomienie wcześniej napisanego testu przypomni nam, które fragmenty nie zostały napisane, lub zostały napisane błędnie. 3.2 Scrum Scrum jest jedną z najpopularniejszych i najpowszechniej (często łącznie z Programowaniem Ekstremalnym) stosowanych metodologii zwinnych. Używa się jej do zarządzania projektami innowacyjnymi o trudnym do przewidzenia efekcie prac. Skupia się przede wszystkim na włączaniu się przyszłych użytkowników w proces wytwórczy oraz na samoorganizacji zespołu projektowego [8]. Nazwa metodyki wywodzi się od formacji w grze w rugby używanej do wznawiania gry po przerwie lub faulu, która nazywa się właśnie scrum (polska nazwa tej formacji to młyn ). Po raz pierwszy analogię do rugby i termin scrum w odniesieniu do procesów wytwórczych zastosowali japońscy akademicy Ikujiro Nonaka i Hirotaka Takeuchi w artykule The New Product Development Game (Harvard Business Review styczeń-luty 1986) opisując całościowe procesy produkcyjne w firmach Fuji Xerox, Canon, Honda, NEC, Epson, 3M i Hewlett-Packard. Termin ten został przeniesiony na grunt produkcji oprogramowania przez Jeffa Sutherlanda, Johna Scumniotalesa i Jeffa McKenna 33

34 w 1993 roku. Dwa lata poźniej Ken Schwaber, jeden z największych autorytetów metodyki Scrum, wspólnie z Jeffem Sutherlandem dokonali formalnego opisu Scruma oraz przedstawili go na konferencji OOPSLA w 1995 roku [24] Role w zespole W metodologii Scrum określa się jedynie trzy role, jakie mają otrzymywać uczestnicy projektu: Właściciel Produktu (ang. Product Owner), Mistrz (ang. Scrum Master) oraz Zespół (ang. Scrum Team). Właściciel Produktu Właściciel Produktu reprezentuje interesy wszystkich ludzi zaangażowanych w projekt i finalny produkt klientów, użytkowników itd. Odpowiedzialny jest za decyzje w sprawie cech funkcjonalnych produktu oraz zarządzanie priorytetami w ich implementacji. Prowadzi rejestr produktowy, ustala hierarchię cech wg wartości rynkowej oraz akceptuje lub odrzuca efekty pracy zespołu projektowego. Rola Właściciela Produktu utożsamiana jest z rolą klienta w manifeście metodologii zwinnych. Mistrz Zadaniem Mistrza jest dopilnowanie przestrzegania przez zespół projektowy wartości, praktyk i reguł Scruma. Pomimo, że pełni on rolę kierownika projektu, jego obowiązki nie polegają ani na planowaniu, ani na przydzielaniu, ani na kontrolowaniu wykonywanych zadań, lecz przede wszystkim na usuwaniu wszelkich przeszkód w pracy zespołu, a także zapewnieniu zgodności wyników pracy z celami biznesowymi Właściciela Produktu. Nie podejmuje on żadnych decyzji - ani biznesowych ani technicznych lecz, jak już wspomnieliśmy, ochrania zespół przed negatywnymi czynnikami zewnętrznymi np. zmieniającymi się w czasie Sprintu wymaganiami, dodatkowymi zadaniami czy problemami. Zespół Zespół w Scrumie jest interdyscyplinarny, samoorganizujący się i samowystarczalny. Sam decyduje jak zrealizować zadania wyznaczone w danym Sprincie. Z tego też powodu nie obejmuje on żadnej tradycyjnej roli inżynierii oprogramowania, takiej jak programisty, 34

35 projektanta, testera, bądź architekta. Wszyscy w projekcie współpracują na równych zasadach, nie istnieje hierarchia służbowa. Każdy może być zaangażowany w dowolną z czynności: projektowanie, programowanie, testowanie itd. niezależnie od swojego zakresu ekspertyzy. Nikt, nawet Mistrz, nie może mówić zespołowi, jak przekształcać elementy rejestru produktowego w zbywalną funkcjonalność. Zespół dochodzi do tego sam. Każdy członek Zespołu wykorzystuje swoje kompetencje do rozwiązania problemu. Powstająca synergia podnosi całkowitą wydajność i skuteczność Zespołu [25] Spotkanie planistyczne wydania Na samym początku projektu, jeszcze przed rozpoczęciem jakichkolwiek prac, odbywa się spotkanie planistyczne wydania (ang. release planning meeting). Jego celem jest opracowanie ogólnego zarysu systemu oraz wstępnego planu jego tworzenia. Plan ten opisuje ostateczny cel projektu, główne zagrożenia, które mogą wystąpić podczas jego realizacji oraz wyznacza orientacyjną datę zakończenia pracy i koszt wytworzonego produktu. Na etapie planowania wydania powstaje również tzw. rejestr produktowy (ang. product backlog). Jest to zbiór wszystkich wymagań funkcjonalnych, które należy wykonać w celu wytworzenia produktu. Rejestr nie jest nigdy zamknięty. Jego wstępna wersja zawiera jedynie początkowo znane i najlepiej rozumiane wymagania. Ewoluuje on wraz z produktem i środowiskiem, w którym jest używany. Rejestr jest dynamiczny w tym znaczeniu, że stale się zmienia, aby uwzględnić to, czego produkt wymaga, aby być odpowiednim, konkurencyjnym i użytecznym Sprint Jednostką pracy Zespołu jest Sprint, który jest innym określeniem dla pojawiającej się w manifeście zwinnych metodologii iteracji. Sugerowany czas trwania pojedynczego Sprintu wynosi od jednego do czterech tygodni. Zaleca się jednak stosowanie przebiegów o stałym czasie trwania (jedno- lub dwutygodniowe), co pomaga zespołowi w wypracowaniu regularnego rytmu pracy oraz upraszcza zarówno zarządzanie, jak i śledzenie czynności procesowych. Naczelną zasadą pracy w metodologii Scrum jest to, że każdy przebieg musi dostarczyć użytkownikowi kolejną działającą wersję produktu. Nie jest przy tym ważne, jak wiele nowych funkcji systemu zostanie dodanych w ciągu trwania Sprintu. Liczy się to, że każde kolejne wydanie musi 35

36 dodawać nową wartość, którą daje się zweryfikować w praktycznym użytkowaniu, nie zaś na papierze. Warto podkreślić, że skład osobowy zespołu projektowego, jak i cele jakościowe muszą pozostać niezmienne przez cały okres trwania Sprintu. Na Rys. 3.2 przedstawiliśmy schemat przebiegu pojedynczego Sprintu. Rysunek 3.2. Cykl Scrum (na podstawie [27]) Spotkanie planistyczne Sprintu Na początku każdego Sprintu organizowane jest spotkanie planistyczne (ang. sprint planning meeting), które jest zajęciem jednodniowym, podzielonym na dwie części. Opowiadania użytkownika Pierwsza część spotkania to czterogodzinna sesja planowania, na której Właściciel Produktu tworzy tzw. rejestr prac Sprintu (ang. sprint backlog) zestaw czynności w ilości takiej, jaką Zespół może wykonać w bieżącym Sprincie. Czynności te wybierane są z rejestru produktowego, który zawiera ogólną listę wymagań użytkownika. Poprawniej byłoby zresztą mówić o liście życzeń, ponieważ wymagania gromadzone są w postaci tzw. opowiadań użytkownika (ang. user stories), mówiących o tym, jak właściciel wyobraża sobie swój przyszły produkt. Opowiadania muszą być krótkie i treściwe, najlepiej aby z każdego z nich wynikała wprost jedna cecha 36

37 systemu. Szablon opowiadania użytkownika składa się z nazwy oraz opisu, który przyjmuje następującą postać: Jako [osoba odgrywająca daną rolę] chciałbym móc [wykonać jakąś czynność] aby [osiągnąć jakiś cel]. Każde opowiadanie powinno zmieścić się w jednym Sprincie tak, aby efekt można było zaprezentować Właścicielowi Produktu. Demonstrowalność jest bowiem jedną z ich głównych cech, dzięki której można ocenić, czy Zespół dobrze zrozumiał to, co zostało mu przekazane w danym opowiadaniu. Pomysły użytkownika można gromadzić na zwykłych kartkach papieru, albo wpisywać je do kolejnych wierszy arkusza kalkulacyjnego. Zanim zespół przystąpi do pracy, właściciel produktu proszony jest jeszcze o ustalenie priorytetów wymagań. Priorytet ustala się na podstawie ryzyka, wartości biznesowej i konieczności realizacji danego elementu Nie muszą być one ułożone według bardzo wyrafinowanej skali. W wielu przypadkach wystarczy wskazanie tych cech, bez których realizacja systemu w ogóle mija się z celem (ang. must be) oraz tych, których obecność bardzo ułatwiłaby pracę (ang. should be) i wreszcie tych, których obecność sprawiłaby właścicielowi przyjemność (ang. nice to have). Po utworzeniu rejestru prac Sprintu, Właściciel Produktu i Zespół określają tzw. cel Sprintu (ang. sprint goal), czyli biznesową korzyść, jaką zmiany w produkcie muszą dostarczyć, niezależnie od implementowanej funkcjonalności. Cel Sprintu powinien być mierzalny, dzięki czemu można łatwo określić, kiedy został osiągnięty. Na przykład, celem dla tworzonej w niniejszej pracy aplikacji dla danego Sprintu może być Umożliwienie administratorowi zarządzania poszczególnymi pracownikami dydaktycznymi. Zdefiniowanie zadań W drugiej części spotkania planistycznego, Zespół dzieli rejestr prac Sprintu na poszczególne zadania, których celem jest dostarczenie wymaganej funkcjonalności. Pracochłonność każdego zadania jest szacowana z dokładnością do pojedynczej roboczogodziny, a Zespół sam ustala, kto jest najbardziej odpowiedni do wykonania każdego z nich. W przypadku uzyskania zbyt dużej lub zbyt małej łącznej liczy roboczogodzin, zespół dodaje lub zwraca wymagania do rejestru w ten sposób, by zmieścić się możliwie dokładnie w ramach czasu trwania jednej iteracji. Lista prac do wykonania niekoniecznie musi być kompletna, ponieważ wiele zadań może pojawić się 37

38 dopiero podczas trwania Sprintu. Właściciel Produktu jest także obecny podczas drugiej części spotkania planistycznego. Odpowiada na ewentualne pytania Zespołu dotyczące rejestru prac Sprintu oraz pomaga w osiągnięciu kompromisu pomiędzy swoimi oczekiwaniami, a możliwościami produkcyjnymi Przebieg Sprintu Po etapie przygotowawczym Zespół zaczyna właściwą pracę. Jako, że jest on z założenia samoorganizującym się ciałem, nie ma mowy o odgórnym przypisywaniu zadań do poszczególnych członków Zespołu, lecz samodzielnie dokonują oni ich wyboru według wspólnych ustaleń, umiejętności czy innych preferencj. Jeśli chodzi o inżynierskie sprawy (projektowanie, kodowanie, zarządzanie konfiguracją, testowanie itd.) Zespół bardzo często bazuje na praktykach dostarczanych przez zwinną metodologię Programowania Ekstremalnego, które zostały opisane w Rozdz Każdy członek Zespołu wykonuje swoje zadania z największą efektywnością na jaką go stać, co wcale nie oznacza, że zespół ma pracować ponad siły. Przeciwnie, w celu utrzymania na dłuższą metę wysokiej jakości wyników, praca w nadgodzinach traktowana jest jako wyjątek, którego należy unikać. W trakcie trwania Sprintu Właścicielowi Produktu nie wolno wtrącać się do pracy Zespołu, a w szczególności zmieniać wymagań lub ich priorytetów. Wszelkie zmiany koncepcji produktu i składu osobowego Zespołu dozwolone są jedynie pomiędzy iteracjami. Wykres spalania Podstawowym narzędziem kontroli pracy pozostającej do wykonania w trakcie trwania Sprintu jest wykres spalania (ang. burndown chart). Szacowana praca pozostająca w Sprincie jest obliczana codziennie, przy czym jednostką spalania są godziny pracy Zespołu. Oś pionowa pokazuje pozostające w Sprincie godziny pracy, natomiast oś pozioma przedstawia kolejne dni Sprintu. Zespół stara się uwzględnić właściwą ilość pracy w Sprincie, ale czasami podczas spotkania planistycznego umieszcza się zbyt dużo lub zbyt mało pracy. W takim przypadku Zespół musi dodawać lub usuwać zadania. Na przykładowym wykresie spalania Sprintu (Rys. 3.3) można zobaczyć, że Zespół początkowo zaplanował zbyt dużo pracy i szóstego dnia ciągle miał ponad 50 godzin do wypracowania. W takim przypadku skonsultowano się z Właścicielem Produktu i ustalono usunięcie części pracy ze Sprintu, efektem czego był duży spadek na 38

39 roboczogodziny [ZWINNE TWORZENIE APLIKACJI INTERNETOWYCH TYPU RIA W ŚRODOWISKU RUBY ON RAILS] Kraków 2010 wykresie pomiędzy szóstym a siódmym dniem pracy. Od tego punktu Zespół dokonywał stałego postępu i ukończył Sprint z powodzeniem kolejne dni sprintu Rysunek 3.3. Przykładowy wykres spalania. Codzienne spotkania Obowiązkowym elementem metodyki Scrum jest codzienne, piętnastominutowe spotkanie całego Zespołu (ang. daily scrum meeting), które odbywa się o tej samej porze, w tym samym miejscu oraz najlepiej jeszcze przed rozpoczęciem pracy. Podczas tego spotania każdy członek Zespołu odpowiada na trzy pytania: Co robiłeś wczoraj? Co będziesz robić dzisiaj? Jakie napotykasz przeszkody? Codzienny Scrum Meeting poprawia komunikację, eliminuje potrzebę innych spotkań, podkreśla i promuje szybkie podejmowanie decyzji oraz podnosi poziom znajomości stanu prac projektowych w całym Zespole. Zebranie nie służy natomiast do rozwiązywania problemów, takie rozpatrywane są po zakończeniu spotkania przez Mistrza. Wystarczy, że uczestnicy zorientowali się w sytuacji i ustalili, kto danym problemem powinien się zająć. Uczestnictwo w spotkaniu jest otwarte dla każdego, kto jest zainteresowany projektem. Uczestnicy są jednak podzieleni na dwie grupy. Pierwszą stanowią Właściciel Produktu, Mistrz oraz Zespół, i tylko oni mają prawo głosu. Druga grupa to wszyscy ci, którzy mają ochotę przyjść i posłuchać, ale nie 39

40 mogą wypowiadać się na jakikolwiek temat. Zastosowanie tej reguły powoduje, że spotkanie jest krótkie, ludzie są skupieni na istotnych sprawach, a uczestnicy projektu są doinformowani na temat postępu prac i napotkanych problemów Przegląd Sprintu Ukoronowaniem Sprintu jest spotkanie przeglądowe (ang. sprint review meeting), na którym Zespół przedstawia Właścicielowi Produktu co osiągnięto w ostatniej iteracji. W spotkaniu przeglądowym uczestniczą Właściciel Produktu, Zespół, Mistrz, a także inżynierowie z innych projektów. Tym razem prawo głosu mają wszyscy, a produkt ocenia się względem celu Sprintu ustalonego na spotkaniu planistycznym. Zespół prezentuje przed Właścicielem Produktu oraz innymi zainteresowanymi osobami funkcjonalności, które wykonał podczas Sprintu. Na podstawie tej prezentacji Właściciel Produktu określa, czy cel Sprintu został osiągnięty oraz czy funkcjonalność spełnia kryteria akceptacji, które zostały określone przez klienta przed rozpoczęciem pracy. Ostatnim punktem spotkania przeglądowego, które trwa zazwyczaj nie dłużej niż cztery godziny, jest ustalenie terminu spotkania planistycznego dla następnegu Sprintu Retrospektyw Sprintu Po przeglądzie Sprintu, a przed kolejnym spotkaniem planistycznym, Zespół przeprowadza retrospektywę Sprintu (ang. sprint retrospective meeting). W czasie tego spotkania, trwającego nie dłużej niż trzy godziny, Mistrz zachęca członków Zespołu do przejrzenia, w ramach procesu i praktyki Scrum, ich pracy programistycznej, aby w kolejnym Sprincie uczynić ją bardziej efektywną. Celem retrospektywy jest również sprawdzenie przebiegu minionego Sprintu pod kątem osób biorących udział w przedsięwzięciu, relacji zachodzących między nimi, procesu i narzędzi. Inspekcja ta powinna zidentyfikować i zhierarchiwizować główne elementy, które były pozytywne oraz te, które, gdyby zostały zrealizowane inaczej, mogłyby wpłynąć pozytywnie na efekt pracy. Dotyczy to składu Zespołu, rozkładu spotkań, narzędzi, metod komunikacji i procesów stosowanych w przekształcaniu rejestru produktowego w gotowe fragmenty produktu. W trakcie trwania retrospektywy Zespół powinien ustalić kroki naprawcze, które zostaną podjęte w kolejnych Sprintach. 40

41 3.3 Crystal family Twórcą metodyk Crystal jest Alistair Cockburn, który został zatrudniony pod koniec lat 90-tych przez IBM Consulting Group w celu skonstruowania nowej metodologii. Cockburn przesłuchując zespoły stwierdził istotną zależność pomiędzy sposobem komunikacji, a końcowym sukcesem projektu. Doszedł do wniosku, iż w zależności od rozmiaru zespołu oraz krytyczności budowanego systemu potrzebne są nieco inne praktyki, stąd pomysł stworzenia całej rodziny podobnych metodologii [31]. Rys. 3.4 przedstawia ich podział w zależności od liczby zaangażowanych osób oraz rozmiaru strat jakie zostaną spowodowane defektami produktu. Wyróżniamy cztery poziomy krytyczności projektu, a osiągnięcie każdego z nich może powodować utratę: C komfortu (ang. Comfort), D małych pieniędzy (ang. Discretionary Money), E dużych pieniędzy (ang. Essential Money), L życia (ang. Life Critical). Cockburn zastosował również podział na kolorowe pasma. Przesuwając się wzdłuż osi X kolor staje się bardziej intensywny. Oznacza to, że realizowany projekt jest większy i wymaga zastosowania bardziej rozbudowanych metod. Dla przykładu kwadrat D6 oznacza metodologię prowadzenia projektu składającego się z maksymalnie sześciu osób. Realizowany przez nich system jest bardzo mały, a znalezione defekty powodują jedynie niewielkie straty materialne. 41

42 Rysunek 3.4. Podział metodologii Crystal family (na podstawie [31]). Jednym z najważniejszych założeń metodologii jest to, iż każdy projekt posiada wyjątkowe cechy co powoduje, że ich realizacja wiąże się z koniecznością każdorazowego stworzenia indywidualnych procesów oraz praktyk aby dostarczać zamawiającemu klientowi unikalny produkt. Dlatego metodologia Crystal family definiuje siedem własności projektu, dzięki którym może zakończyć się on sukcesem: częste iteracje (maksymalna długość cztery miesiące, preferowana od jednego do trzech), przemyślane udoskonalanie (krytykuj i naprawiaj), osmotyczna komunikacja i zdobywanie wiedzy, osobiste bezpieczeństwo (można być szczerym w przedstawianiu swojego zdania), koncentracja (jasne zadania i priorytety), eksperci w zasięgu ręki, zwinne środowisko (automatyczne testowanie, częsta integracja). 3.4 Adaptive Software Development Twórcą Adaptive Software Development (ASD) jest James A. Highsmith III. Duża część zasad przyjętych przez ASD pochodzi z wcześniejszych badań Highsmitha nad rozwojem metod iteracyjnych. Metodyka powstała w 1995 roku, a jej najbardziej znanym przodkiem jest RADical Software Development autorów J. Highsmitha oraz S. Bayera [8]. 42

43 Celem ASD jest wspieranie dużych i skomplikowanych projektów poprzez organizację pracy pozwalającą na łatwiejsze dostosowanie się do zmieniającego środowiska. Główny nacisk kładziony jest na iteracyjne i przyrostowe tworzenie oprogramowania, kulturę oraz filozofię pracy, spychając na drugi plan konkretne rozwiązania, praktyki i narzędzia. Projekt ASD podzielony jest na iteracje, gdzie każda z nich składa się z trzech dynamicznych faz (Rys. 3.5): 1. Spekulacji. 2. Współpracy. 3. Nauki. Rysunek 3.5. Fazy iteracji w projekcie ASD (na podstawie [8]). Spekulacja Faza spekulacji składa się z następujących czynności: inicjalizacji projektu - ustalenia misji, określenia ram czasowych dla całego projektu, określenia liczby iteracji oraz czasu ich trwania, wybrania tematu oraz celu każdej iteracji, przypisania rezultatów każdej iteracji przez klienta i programistów. Współpraca Celem fazy współpracy jest dostarczenie przez programistów gotowego systemu. Menadżer projektu ma za zadanie wspomagać zespół oraz tworzyć dokumentację projektu. Dobra 43

44 współpraca to przede wszystkim umiejętność pracy w grupie, dzielenie się wiedzą oraz wspólne podejmowanie decyzji. Nauka Ostatnia faza to nauka po iteracji, która skoncentrowana jest na czterech dziedzinach: 1. Ocenie jakości z punktu widzenia klienta. 2. Ocenie jakości z technicznego punktu widzenia. 3. Ocenie funkcjonowania i optymalizacji zadań zespołu programistycznego. 4. Ocenie statusu projektu. Wykorzystując metodologię ASD, która stawia na intensywną współpracę programistów, kierownictwa i klienta, tworzone oprogramowanie jest bliższe wymaganiom zamawiającego. Analiza ryzyka, otwartość na zmiany oraz ciągłe uczenie się zwiększa dodatkowo pewność prawidłowego zakończenia projektu informatycznego. 3.5 Dynamic System Development Method Dynamic System Development Method (DSDM) jest zwinnym szkieletem projektowym zaproponowanym w latach dziewięćdziesiątych przez brytyjskie konsorcjum DSDM [11]. Fundamentalną zasadą DSDM jest dostarczanie systemów informatycznych w wyznaczonym czasie i budżecie przy jednoczesnym dostosowywaniu do zmieniających się wymagań. Cykl tworzenia projektu składa się z pięciu faz (Rys. 3.6) [8]: 1. Inspekcji stosowalności (ang. Feasibility Study). 2. Badań biznesowych (ang. Business Study). 3. Iteracyjnego opracowania modelu funkcjonalnego (ang. Functional Model Iteration). 4. Iteracyjnego projektowania i implementacji (ang. Design and Build Iteration). 5. Wdrożenia (ang. Implementation). 44

45 Rysunek 3.6. DSDM fazy projektu (na podstawie [8]). Inspekcja stosowalności Fazą wykonywaną na samym początku projektu w celu potwierdzenia zasadności stosowania DSDM jest inspekcja stosowalności. Określa się w niej czy DSDM jest właściwe dla danego projektu, definiuje się problem, oszacowuje koszty, ryzykowne punkty oraz buduje wstępny prototyp. Rozległość prac w tej fazie jest ograniczona do kilku tygodni. Badania biznesowe Badania biznesowe mają na celu analizę kluczowych dla projektu lub jego części zagadnień biznesowych i technicznych. Organizowane są warsztaty, których celem jest ustalenie priorytetów wymagań oraz identyfikacja osób po stronie klienta, które zostaną w późniejszym okresie włączone w proces tworzenia oprogramowania. Rezultatami zakończenia fazy są: wysokopoziomowy opis systemu oraz zarys architektury wraz z jej prototypem. Model funkcjonalny Kolejną fazą jest iteracyjne opracowywanie modelu funkcjonalnego polegające na analizie i budowie prototypów. Rezultaty tych zabiegów służą do poprawienia i uszczegółowienia modeli analitycznych. Wynikiem tej fazy jest model funkcjonalny oraz kod prototypów. W każdym przebiegu iteracji powstają następujące dokumenty: lista funkcjonalności wraz z ich priorytetami, 45

46 podsumowanie prac w aktualnym przebiegu wraz z uwagami i komentarzami, wymagania niefunkcjonalne oraz analiza ryzyka pod kątem dalszych prac. Projektowanie i implementacja Właściwe wytwarzanie oprogramowania odbywa się w fazie iteracyjnego projektowania i implementacji. Wyniki prac nad modelem funkcjonalnym są przetwarzane w kod źródłowy właściwego produktu. Finalnym produktem tej fazy jest w pełni przetestowany system zawierający uzgodniony wcześniej zestaw funkcjonalności. Wdrożenie Końcowym etapem cyklu DSDM jest faza wdrożenia produktu polegająca na przejściu ze środowiska programistycznego do produkcyjnego. Przygotowywane są również szkolenia dla przyszłych użytkowników oraz dostarczana jest finalna dokumentacja systemu. Szkielet projektowy DSDM jest niezależny od pozostałych metodologii zwinnych jak np. Programowanie Ekstremalne, ale jednocześnie jeśli występuje taka konieczność może z nimi współpracować. Jego zaletą jest to, że przez cały cykl tworzenia oprogramowania produkt jest sprawdzany przez jego twórców oraz przyszłych użytkowników. Dzięki temu uwagi powstałe w danej iteracji mogą być opracowywane w ramach kolejnych iteracji. 3.6 Feature Driven Development Feature Driven Development (FDD) jest metodyką tworzenia oprogramowania należącą do grupy metodyk zwinnych, opracowaną w 1998 roku przez Jaffa De Luca i Petera Coada. Istotą FDD jest realizacja projektu w krótkich iteracjach wynikających z wymagań użytkownika. Jako przedstawiciel tzw. zwinnych metodyk kładzie ona również nacisk na komunikację między członkami zespołu i klientem oraz elastyczność w doborze technik, pozwalając tym samym na szybsze dostarczanie wysokiej jakości produktu. Głównym elementem FDD jest pojęcie cechy (ang. feature). Cechy to użyteczne dla klienta aspekty produktu (niewielkie, dające się zdefiniować przy pomocy pojedynczego zdania). Za ich pomocą opisywane są wymagania funkcjonalne stawiane przez klienta. Biznesowo powiązane ze 46

47 sobą cechy są grupowane w zbiory cech (ang. features set), które są następnie implementowane iteracyjnie [12]. Projekt w myśl FDD składa się z pięciu sekwencyjnie wykonywanych faz, z których dwie ostatnie powtarzane są wielokrotnie podczas tworzenia oprogramowania (Rys. 3.7). Rysunek 3.7. FDD fazy projektu (na podstawie [8]). Tworzenie ogólnego modelu systemu Prace rozpoczynają się od stworzenia ogólnego modelu funkcji biznesowych realizowanego produktu. Jest on dziełem zespołu projektantów, programistów oraz klienta, który jest najlepszym ekspertem z dziedziny produktu. Opracowany model powinien dostarczać informacji o wszystkich wymaganiach funkcjonalnych jednak bez zbytniego zagłębiania się w szczegóły. Realizacja fazy wstępnej owocuje stworzeniem modelu obiektowego, nieformalnej listy cech oraz rozwiązań alternatywnych. Budowa listy cech Na podstawie opracowanego modelu tworzona jest lista cech produktu (ang. feature list) będąca opisem wymaganej przez klienta funkcjonalności. W pierwszym kroku lista cech dzielona jest na obszary przedmiotowe odpowiadające głównym fragmentom funkcjonalnym. Następnie każdy taki obszar jest dzielony na poszczególne aktywności, czyli zbiory cech. Końcowym efektem tej fazy jest hierarchicznie uporządkowana lista cech produktu. Planowanie implementacji cech W uzgodnieniu z klientem przygotowywany jest plan określający w jakiej kolejności cechy będą implementowane. Poszczgólnym cechom przypisywany jest priorytet, określana jest ich 47

48 pracochłonność, występujące zależności i związane z nimi ryzyko. Efektem tej fazy jest plan implementacji, który określa termin realizacji każdego zbioru cech. Dodatkowo każdy taki zbiór ma przypisanego głównego programistę, który jest za niego odpowiedzialny. Znany jest również przydział poszczególnych klas programistom, którzy jako ich właściciele będą je realizować. Projektowanie i implementacja Dwie ostatnie fazy powtarzane są iteracyjnie aż do zakończenia projektu. Ich istotą jest cykliczne dostarczanie działających wersji oprogramowania poprzez projektownie i implementację wybranych zbiorów cech produktu. Na czas każdej iteracji tworzony jest zespół składający się z właścicieli klas zmienianych w ramach implementacji danej grupy cech. Zespół wykonuje szczegółowy projekt, a następnie implementuje zaplanowane cechy. Napisany kod podlega inspekcji w celu wykrycia i poprawienia błędów. Po pomyślnym przejściu testów jednostkowych nowy kod jest integrowany z resztą produktu, który staje się bogatszy o kolejną cechę. 3.7 Podsumowanie Przedstawione w pracy zwinne metodologie tworzenia oprogramowania pomimo wspólnych cech wynikających z przyjętej ideologii zawartej w manifeście, jak częste dostarczanie działającego produktu, czy zorientowanie na ludzi, reprezentują istotnie różne podejścia do procesu wytwórczego. Liczne dyskusje na temat ich wad i zalet, których celem jest wyłonienie najlepszej z nich kończą się zwykle fiaskiem, ponieważ nie istnieje jedyne i uniwersalne podejście, które sprawdza się we wszystkich okolicznościach. Rys. 3.8 przedstawia porównanie prezentowanych w pracy zwinnych metodologii biorąc pod uwagę trzy aspekty: wsparcie procesu zarządzania projektem, dokładny opis procesu tworzenia oprogramowania, proponowane praktyki. Łatwo można zauważyć, że skupiają się one na różnych aspektach cyklu tworzenia oprogramowania. Niektóre koncentrują się wyłącznie na dostarczaniu praktyk i technik (Programowanie Ekstremalne), podczas gdy inne na zarządzaniu projektem, współpracy z klientem i planowaniu (Scrum). Dodatkowo możemy wyróżnić wśród nich dwie metodologie, 48

49 które zapewniają pełne wsparcie w obrębie wszystkich faz tworzenia oprogramowania (RUP, DSDM), podczas gdy wiekszość z pozostałych czyni to dopiero od fazy specyfikacji wymagań (np. FDD). Rysunek 3.8. Porównanie zwinnych metodologii w oparciu o ich udział w poszczególnych fazach wytwarzania oprogramowania (na podstawie [8]). Decydujący wpływ na wybór odpowiedniej metodologii ma także rozmiar zespołu projektowego. XP i Scrum przeznaczone są dla małych zespołów, gdzie liczba członków nie przekracza 10. Metodologie Crystal, FDD, RUP, ASD oraz DSDM są bardzo dobrze skalowalne i mogą być wdrażane z powodzeniem w wiekszych zespołach, gdzie liczba członków przekracza 100. Warto tutaj jednak zaznaczyć, że zwolennicy zwinnych metodologii ostrzegają przed wzrostem liczby członków zespołu, która przyczynia się do zwiększenia powstającej dokumentacji, co czyni projekt mniej zwinnym. 49

50 Rozdział 4. RIA Rich Internet Application (w skrócie RIA), nie jest technologią ściśle, a jedynie terminem opisującym nowy sposób tworzenia aplikacji internetowych. Termin RIA w tłumaczeniu na język polski można sformułować jako nowoczesna aplikacja internetowa. Rozwiązania należące do rodziny RIA wcześniej czy później pojawią się w większości organizacji. Dzisiaj dominują głównie w portalach internetowych, jednak coraz częściej wykorzystywane są w zastosowaniach biznesowych. Rozdział ten jest krótkim wprowadzeniem w świat nowoczesnych aplikacji internetowych i technologii wspomagających ich tworzenie. 4.1 Wprowadzenie do środowiska RIA Termin RIA został po raz pierwszy użyty przez pracowników firmy Macromedia na początku 2001 roku po zaobserwowaniu licznych stron internetowych utworzonych w technologii Flash oferujących pracę w dynamicznie generowanym, jednoekranowym interfejsie, eliminujących uciążliwości standardowych rozwiązań technologii HTML [2]. Aplikacje typu RIA są to aplikacje internetowe posiadające wszystkie mocne strony tradycyjnego oprogramowania biurowego. Cała logika prezentacji przeniesiona zostaje na urządzenie klienta, co pociąga za sobą efektywniejsze wykorzystania łączy internetowych i zredukowanie obciążenia serwerów. RIA łączy w sobie wszystkie funkcjonalne atuty aplikacji biurowych z dużym zasięgiem i dostępnością Internetu. Technologia ta ma na celu wyeliminowanie tych wszystkich utrudnień, które dotychczas stawały na drodze rozwoju aplikacji internetowych, takich jak obowiązek przeładowywania stron po każdorazowej akcji użytkownika czy też ograniczone możliwości interfejsu użytkownika. Nowoczesne aplikacje internetowe nie ograniczają się tylko i wyłącznie do aplikacji bazujących na technologii Flash. Coraz większą popularnością cieszą się biblioteki JavaScript, technologia 50

51 AJAX oraz nowe platformy, których twórcami są takie firmy jak Adobe, Microsoft czy Sun Microsystems. 4.2 Platformy wspomagające tworzenie aplikacji RIA Aktualnie każda poważna platforma programistyczna pozwala tworzyć nowoczesne aplikacje internetowe. Do najpopularniejszych należą: AJAX, Adobe Flex, Microsoft Silverlight oraz JavaFX. Jeżeli przyjrzeć się ich rozwojowi, nie ulega wątpliwości, że ich istotnym odbiorcą są klienci biznesowi. Kolejne podrozdziały krótko przedstawiają wspomniane wyżej platformy RIA AJAX AJAX (ang. Asynchronous JavaScript and XML, asynchroniczny JavaScript i XML) jest techniką tworzenia aplikacji internetowych, w której interakcja użytkownika z serwerem odbywa się w sposób asynchroniczny, bez konieczności przeładowywania całego dokumentu. Dzięki temu każde żądanie o nowe dane nie wiąże się z przesyłaniem całej strony HTML, co umożliwia bardziej dynamiczną interakcję z użytkownikiem [3]. AJAX nie wprowadza żadnych nowych języków programowania lecz bazuje na dobrze znanych standardach internetowych takich jak JavaScript, XML, HTML i CSS. Strona wykorzystująca AJAX jest zwykłym dokumentem HTML/CSS zawierającym skrypty JavaScript. Interakcje użytkownika (np. kliknięcie ikony, wskazanie elementu kursorem myszki) są realizowane poprzez zdarzenia zdefiniowane w specyfikacji HTML (m.in. onclick, onmouseover, onmouseout). Cała dynamiczna interakcja jest oprogramowana w języku JavaScript, którego zadaniem jest wysyłanie w tle zapytań HTTP do serwera o dodatkowe dane. Po odebraniu danych z serwera, strona WWW jest modyfikowana dzięki wykorzystaniu modelu DOM (ang. Document Object Model). Innymi słowy, w skrypcie JavaScript wywołujemy odpowiednie metody (np. getelementbyid(), getelementsbytagname()) by uzyskać dostęp do poszczególnych elementów HTML strony, która jest właśnie wyświetlona przez przeglądarkę. Różnymi właściwościami (np. innerhtml, style) modyfikujemy treść i wygląd poszczególnych elementów HTML. Podsumowując, technologia AJAX jest nowym podejściem do gotowych technologii (wymienionych wyżej), dzięki którym aplikacje internetowe stają się mniejszymi, szybszymi i bardziej przyjaznymi użytkownikowi. 51

52 4.2.2 Adobe Flex Adobe Flex to środowisko programistyczne stworzone przez amerykańskie przedsiębiorstwo Adobe Systems specjalnie do tworzenia nowoczesnych aplikacji internetowych bazujących na Adobe Flash. Umożliwia ono kreowanie wydajnych aplikacji sieciowych o zaawansowanych interfejsach użytkownika oraz rozbudowanej logice biznesowej. Obecnie Flex jest najbardziej dojrzałym środowiskiem do tworzenia tego typu aplikacji [22]. Pierwsza wersja o numerze 1.0 została swtorzona przez amerykańską firmę Macromedia w marcu 2004 roku. Wersja Flex 2.0 ujrzała światło dzienne w 2005 roku po tym jak w kwietniu tego samego roku firma Macromedia została wykupiona przez Adobe Systems. Najnowsza wersja nosi numer 4.0 i została wydana 22 marca 2010 roku. Środowisko Adobe Flex jest całkowicie niezależne od platformy sprzętowej i jest dostępne dla użytkowników takich systemów jak Windows, Max OS X oraz Linux [23]. Technologia Flex wykorzystuje dwa języki programowania: MXML (bazujący na XMLu język znaczników opisujący interfejs użytkownika oraz jego zachowanie, M pochodzi od nazwy firmy Macromedia) oraz ActionScript (obiektowy język programowania służący do tworzenia logiki i interakcji w aplikacji). Kod MXML i ActionScript jest kompilowany do jednego pliku SWF (ang. Small Web Format), który następnie uruchamiany jest w przeglądarce internetowej przy użyciu oprogramowania Adobe Flash Player. Dzięki temu aplikacje Flex zapewniają identyczny wygląd i działanie wszędzie tam, gdzie obsługiwany jest standard Flash. Aplikacja w postaci pliku *.swf (zwanego często plikiem Flash ) osadzona jest na stronie HTML. Użytkownik posiadający nowoczesną przeglądarkę internetową otwierając zwykłą stronę tak naprawdę włącza animację Flash. Plik SWF zawarty na stronie internetowej posiada dostęp zarówno do zasobów tej strony, jak i zasobów serwera, z którego został załadowany. Środowisko Flex zawiera zasobną bibliotekę składników do tworzenia nowoczesnych aplikacji internetowych. Biblioteka ta oferuje różnorodne kontrolki interfejsu, których potrzebują programiści od prostych przycisków i pól wyboru, po złożone tabele danych, listy oraz edytory tekstu. Do tworzenia aplikacji Flex można użyć bezpłatnego, otwartego Adobe Flex SDK (ang. Software Development Kit) lub płatnego środowiska IDE (ang. Integrated Development Environment) Flash Builder (wcześniej Flex Builder). Flex SDK obejmuje bibliotekę klas składników oraz 52

53 kompilator, dzięki czemu pozwala programować oraz wdrażać aplikacje RIA przy użyciu dowolnego środowiska programistycznego. Podsumowując, najważniejsze cechy technologii Flex to: szybkość działania spowodowana brakiem przeładowań stron, mała ilość danych przesyłanych do klienta (przeglądarki), wygląd i działanie niezależne od platformy i przeglądarki, bardzo wysoka dostępność (99% użytkowników internetu posiada obsługę standardu Flash), Dzięki swoim nowoczesnym rozwiązaniom, dojrzałości oraz wyżej wymienionym cechom technologia Adobe Flex błyskawicznie zdobywa zwolenników w gronie twórców i użytkowników aplikacji internetowych Microsoft Silverlight Silverlight firmy Microsoft jest przeznaczoną do zastosowań internetowych technologią prezentacji pozwalającą na tworzenie i uruchamianie multimedialnych, wysoce interaktywnych aplikacji internetowych (RIA) opartych o technologię.net. Oficjalna premiera technologii Silverlight, znanej wcześniej pod nazwą WPF/E (ang. Windows Presentation Foundation/ Everywhere), odbyła się w 2007 roku. Funkcje multimedialne Silverlight umożliwiają szybkie i ekonomiczne dostarczanie materiałów dźwiękowych i filmowych (w tym video o wysokiej rozdzielczości HD) oraz wyświetlanie ich we wszystkich najpopularniejszych przeglądarkach i na różnych systemach operacyjnych (Windows, Apple, Max OS X oraz od niedawna Linux) [4]. Podobnie jak w przypadku WPF technologii prezentacyjnej stworzonej dla Microsoft.NET Framework 3.0 podstawą Silverlight jest język XAML (ang. extensible Application Markup Language). XAML jest językiem opartym na języku XML zoptymalizowanym do opisu bogatych, wizualnych interfejsów użytkownika. Dzięki temu, iż jest to format tekstowy, wprowadzanie jakichkolwiek zmian w aplikacji sprowadza się do zapisania nowego pliku XAML na serwerze. Gdy użytkownik po raz kolejny otworzy stronę, interfejs użytkownika zostanie automatycznie zaktualizowany bez konieczności reinstalacji. Sercem technologii Silverlight jest moduł rozszerzający funkcjonalność przeglądarki o możliwość renderowania kodu XAML i wyświetlania wyników w oknie przeglądarki. Moduł ten jest niewielki (wielkość pliku do pobrania to około 2 MB) i może zostać 53

54 zainstalowany gdy użytkownik po raz pierwszy otworzy witrynę zawierającą treść opartą na Silverlight. Technologia Silverlight wydaje się być udanym produktem firmy Microsoft, jednak jest to produkt stosunkowo młody i w porównaniu z Adobe Flex, będący w fazie rozwoju. Biorąc jednak pod uwagę łatwość obsługi i zastosowania kodu Silverlight, czyni go groźnym konkurentem dla pozostałych platform wspomagających tworzenie nowoczesnych aplikacji internetowych JavaFX Zaledwie w kilka dni od premiery Silverlight, firma Sun Microsystems ogłosiła premierę JavyFX, kolejnej technologii do tworzenia nowoczesnych aplikacji internetowych RIA, przeznaczonej nie tylko na wiele systemów operacyjnych, ale też, docelowo, na wszystkie urządzenia z ekranem. W chwili obecnej JavaFX dostępna jest zarówno na komputery stacjonarne (JavaFX Desktop), jak i na urządzenia mobilne (JavaFX Mobile), trwają również prace nad wdrożeniem jej na platformę TV (JavaFX TV) [5]. Aplikacje JavaFX pisane są w skryptowym języku programowania JavaFX Script, podobnym składniowo do JavaScript, w pełni zorientowanym obiektowo (obiekty opisywane w formacie JSON JavaScript Object Notation). Język ten daje możliwość powiązania (ang. binding) właściwości różnych obiektów między sobą albo z wartościami zmiennych oraz zawiera mnóstwo efektów graficznych, statycznych oraz ruchomych (animowanych). Wszystko to pozwala na tworzenie zaawansowanych i bardzo efektownych interfejsów graficznych. JavaFX Script ma w założeniu stać sie konkurentem dla Adobe Flex, technologii AJAX oraz Microsoft Silverlight. Niestety wykorzystanie komponentów graficznych Swing, znanych z pierwotnego języka Java, jest jego największą słabością. Mimo to, iż na każdej platformie wyglądają one identycznie, ich możliwości multimedialne nie dorównują innym znanym technologiom RIA. Przed JavaFX stoi trudne zadanie. Wygląd aplikacji stworzonej przy użyciu technologii JavaFX nie dorównuje możliwościom wizualnej prezentacji jakie dają rozwiązania konkurencyjne. Dodatkowo instalacja środowiska uruchomieniowego JVM jest trudniejsza od instalacji Flash Playera, a rozmiar paczki instalacyjnej jest większy, co dla niektórych może być problemem. Jednak nie wszystko jest stracone, ponieważ JavaFX ma dużą szansę przyjąć się jako 54

55 technologia do tworzenia aplikacji na urządzenia mobilne, gdzie z pewnością będzie wiodła prym. 55

56 Rozdział 5. Platforma Ruby on Rails Przedstawione w pracy zwinne metodologie tworzenia oprogramowania opisują głównie organizację prac projektowych. Z manifestem zwinnych metodologii związane są również zagadnienia dotyczące bezpośrednio sposobu pracy programistów, znajdujące realne odzwierciedlenie w tworzonym przez nich kodzie. Celem niniejszego rozdziału jest przedstawienie praktycznych przykładów ich wdrożenia przez twórców nowoczesnych języków programowania, które wspomagają i znacząco przyśpieszają proces wytwarzania oprogramowania. W ostatnich latach bardzo popularnym stał się zwinny szkielet tworzenia aplikacji internetowych Ruby on Rails (w skrócie: RoR lub Rails). 5.1 Historia Ruby Przedstawiając szkielet Rails nie sposób nie wspomnieć o języku Ruby, w którym został on napisany. Ruby to interpretowany, w pełni obiektowy język programowania. Powstał w Japonii w 1995 roku, a jego twórcą jest programista i zwolennik wolnego oprogramowania Yukihiro Matsumoto. Inspiracją do jego stworzenia były języki Perl, Python, Smalltalk, CLU, Eiffel, Ada i Lisp. Matsumoto był zafascynowany ich możliwościami, jednak tak naprawdę żaden z nich nie spełniał w pełni wymogów programowania obiektowego. W związku z tym postanowił napisać swój własny język skryptowy potężniejszy niż Perl oraz bardziej obiektowy niż Python [14]. Tak oto powstał Ruby. Pomimo wprowadzenia go na rynek w 1995 roku, Ruby przez wiele lat nie był zauważany. Dopiero za sprawą szkieletu Ruby on Rails (rok 2005), oczy wielu programistów skierowały się na ten interesujący niewątpliwie język. Najlepiej obrazuje to ranking popularności języków programowania publikowany nieprzerwanie od 2000 roku przez firmę Tiobe Software (Rys. 5.1). 56

57 Ranking ten powstaje na bazie takich elementów jak liczba kompetentnych w danym języku inżynierów, prowadzonych kursów oraz niezależnych dostawców. Dane czerpane są z wyszukiwarek Google, Bing, Yahoo! oraz serwisów Wikipedia i YouTube [15]. Rysunek 5.1. Wykres popularności języka Ruby wg firmy Tiobe Software (na podstawie [15]). Rok 2006 był wyjątkowym rokiem dla języka Ruby, kiedy zanotował on skok w rankingu firmy Tiobe aż o 11 miejsc oraz został uhonorowany tytułem języka roku. Obecnie zajmuje on jedenastą pozycję wśród najpopularniejszych języków programowania. Cechy, które wyróżniają Rubiego spośród innych języków to całkowita obiektowość oraz elastyczność, pełna możliwość modyfikacji całej biblioteki klas, bogaty zestaw dodatkowych narzędzi oraz przede wszystkim kompaktowość. Przy tym wszystkim, język jest naprawdę żywy i pragmatyczny, a jedną z jego największych zalet jest przejrzysta składnia nierzadko sprawiająca wrażenie, że kod napisany w Rubim jest pseudokodem. Pierwsza implementacja języka Ruby została stworzona w języku C, jednak wraz ze wzrostem jego popularności zainteresowali się nim tacy giganci jak Sun oraz Microsoft, dzięki czemu powstaje kilka różnych interpreterów Rubiego [16]: JRuby implementacja w czystej Javie, dzięki której można korzystać ze wszystkich dostępnych bibliotek Javy. IronRuby implementacja na platformę Microsoft.NET (w trakcie rozwoju). 57

58 MacRuby implementacja w języku Objective-C dla systemu Max OS X (w trakcie rozwoju). Ruby rozwijany jest jako darmowe i otwarte oprogramowanie dostępne na licencji GPL. Darmowe jest nie tylko korzystanie, ale również kopiowanie, modyfikowanie i rozprowadzanie tego języka. Dzięki swojej prostocie i możliwościom język Ruby zyskał rzeszę zwolenników. Znajduje on zastosowanie niemal w każdej dziedzinie począwszy od biznesu, poprzez robotykę i telekominukację kończąc na administracji systemami. Używany jest między innymi przez Centrum Badań NASA, grupę badawczą w Motoroli oraz firmę Google. 5.2 Czym jest Ruby on Rails Ruby on Rails to szkielet programistyczny (ang. framework) przeznaczony do szybkiego tworzenia aplikacji internetowych stworzony przez duńskiego programistę Davida Heinemeiera Hanssona. Rails został napisany w języku Ruby z użyciem architektury Model-Widok-Kontroler (ang. Model-View-Controller, MVC). Innymi słowy RoR to środowisko wspomagające tworzenie, rozwój i testowanie aplikacji poprzez automatyczną generację szkieletu projektu, będącego jej zalążkiem [16]. Pomimo tego, że szkielet Rails miał przez pierwszy rok lub dwa słabą reputację z uwagi na braki w dokumentacji, jego popularność nieprzerwanie rośnie. Od pierwszego wydania, w lipcu 2004 roku, przyciąga on programistów PHP, Java i.net swoją prostotą i ogromnymi możliwościami. W związku z tym luki w dokumentacji zostały bardzo szybko wypełnione przez tysiące programistów, którzy korzystali z Ruby on Rails, współtworzyli go, jak również pisali na jego temat. Railsy są "upartym" oprogramowaniem. Oznacza to, że były tworzone z przekonaniem, że istnieje najlepszy sposób rozwiązywania pewnych problemów i zostały zaprojektowane tak, by zachęcać do wyboru tego sposobu, a w niektórych przypadkach, by zniechęcić do wyboru alternatywy. Dużą zaletą RoR jest to, że proces tworzenia kodu jest w nim przyjemny, a napisanie aplikacji jest naprawdę proste. 58

59 5.3 Zwinne tworzenie oprogramowania a Ruby on Rails Do głównych założeń, które legły u podstaw Ruby on Rails, należą szybkość i łatwość pisania kodu, a także możliwość użycia wtyczek, które w sposób błyskawiczny rozszerzają tworzone aplikacje o rozmaite funkcjonalności. Rails podbił serca wielu twórców oprogramowania i skupił wokół siebie dużą społeczność, stając się jednym z najpopularniejszych szkieletów do tworzenia aplikacj internetowych. Co więcej, zainspirował on także innych programistów do stworzenia podobnych pod względem założeń produktów, między innymi Django (Python) czy Grails (Groovy). Tego rodzaju narzędzia stanowią żywą realizację idei twórców manifestu zwinnych metodologii. Oprócz zasad sformułowanych na papierze programiści dostali również do dyspozycji konkretną pomoc technologiczną. Filozofia programowania zwinnego polega na krokowym tworzeniu aplikacji w połączeniu z nieustannym testowaniem jej kodu. Zakłada się tu także częsty kontakt z klientem, który na bieżąco przekazuje nam swoje uwagi. Taki styl tworzenia aplikacji wymaga częstych zwrotów i ciągłego przebudowywania wcześniej stworzonego kodu. Rails jest doskonale przygotowany do takiej pracy. Jako język interpretowany nie posiada fazy kompilacji, co powoduje obniżenie dodatkowych narzutów czasowych. Bardzo szybka pętla sprzężenia zwrotnego sprawia, że czas potrzebny do uruchomienia aplikacji po wprowadzeniu poprawek jest minimalny. Wysokopoziomowy szkielet programistyczny Ruby on Rails dzięki swojej dynamice jest zorientowany na człowieka i na interaktywność. Z tego powodu jest znacznie bardziej produktywny oraz przyjazny programiście, co jest czynnikiem decydującym o jego sukcesie. 5.4 Podstawowe koncepcje programistyczne Zwinne środowisko Ruby on Rails stara się do maksimum ułatwić pracę programiście oraz zwiększyć jego wydajność. W tym celu promuje proste koncepcje programistyczne znajdujące szerokie zastosowanie w wielu projektach, nie tylko realizowanych w Rubim. Pozwalają one na pisanie krótszego kodu, jednocześnie umożliwiając osiąganie lepszych rezultatów. Wszystkie układają się w ciąg łatwych do przyswojenia akronimów: DRY, YAGNI, CoC. 59

60 5.4.1 DRY Nazwa tej reguły jest skrótem od angielskiego wyrażenia Don't Repeat Yourself (czyli: nie powtarzaj się). Jak łatwo można się domyślić, oznacza nakaz unikania powtórzeń tych samych fragmentów kodu w różnych miejscach programu. Powielanie jest zwykle niepotrzebne i nie tylko wydłuża czas programowania, ale przede wszystkim jest szczególnie narażone na błędy. Wprowadzenie nawet drobnej zmiany w powtarzającym się kodzie wymaga często dużego nakładu pracy ze strony programisty. Rails w myśl reguły DRY zakłada odciążenie programisty od powtarzalnych i żmudnych czynności, ponieważ wiele elementów aplikacji jest generowanych automatycznie wraz z całą strukturą plików. Dzieje się to dzięki licznym generatorom kodu oraz klasom pomocniczym. Dbają one o to, aby pliki odpowiadające za każdą część wzorca MVC znalazły się tam, gdzie powinny w strukturze projektu. Dzięki takiemu podejściu każda informacja jest umieszczona tylko w jednym, ściśle zdefiniowanym miejscu. Przykładowo, nie jest konieczne definiowanie w kodzie aplikacji nazw kolumn dla każdej z tabel w bazie danych ponieważ Ruby pobiera takie informacje samodzielnie YAGNI YAGNI, czyli You Aren't Gonna Need It. Nie będziesz tego potrzebował" mówią twórcy zwinnego manifestu. W regule tej chodzi oczywiście o powstrzymanie się programisty przed dodawaniem do aplikacji funkcjonalności na wyrost. Te częsci kodu, które nie są potrzebne do implementacji istniejących wymagań klienta powinny zostać usunięte, ponieważ mogą stanowić potencjalne źródło błędów. Zgodnie z zasadą YAGNI twórca aplikacji powinien wybierać najprostsze drogi do celu, które dają większą szansę na niezawodną implementację. Zastosowanie tej zasady możemy zaobserwować na przykładzie praktyki Test-Driven Development. Jak już wiemy z Rozdz , zakłada ona tworzenie oprogramowania w krótkich iteracjach, w trakcie których najpierw formułujemy zagadnienia testowe mające na celu sprawdzenie nowej funkcjonalności naszej aplikacji. W dalszej kolejności produkowany jest kod konieczny do przejścia testów. Dodatkowo w razie potrzeby następuje jego refaktoryzacja i implementacja powstałych zmian. Zasada YAGNI może więc znaleźć zastosowanie wtedy, gdy na wstępie zdefiniujemy klasę i konkretny zestaw funkcji dla niej, następnie okaże się jednak, że 60

61 problem testowy stworzony dla klasy nie wykorzystuje wszystkich jej funkcji. W takim wypadku zakodujemy tylko część konieczną do przejścia testu, a pozostałe funkcjonalności zaimplementujemy, jeśli pojawi się taka konieczność CoC Reguła CoC (ang. Convention over Configuration), czyli konwencja ponad konfigurację, oznacza dążenie do ograniczenia czasu poświęconego na konfigurację aplikacji i skupienie większej uwagi na jej funkcjonalności. Przydatność tej reguły widać szczególnie przy dużych projektach, gdzie więcej pracy trzeba częstokroć poświęcić edycji plików konfiguracyjnych niż faktycznemu programowaniu. W ten sposób niepotrzebnie wydłuża się czas realizacji całego projektu. Niestety, w tym miejscu dochodzą do głosu ograniczenia technologiczne, gdyż często już samo środowisko pracy programisty wymaga zaangażowania wielu sił i środków w przeprowadzenie procesu konfiguracji. Jedną z głównych zalet RoR jest stosowanie konwencji, które dotyczą zarówno nazewnictwa klas, zmiennych, tabel czy pól w bazie danych, jak i całej budowy projektu. Dzięki stosowaniu przyjętych konwencji, struktura projektu oraz kod stają się czytelniejsze oraz łatwiejsze do zrozumienia dla nowych członków zespołu, którzy nie tracą czasu na zrozumienie budowy aplikacji, pracują szybiej i sprawniej. Celem RoR nie jest, jak niektórzy myślą, całkowite usunięcie konfiguracji, lecz zminimalizowanie liczby niezbędnych ustawień. 5.5 Język Ruby Według Yukihiro Matsumoto język Ruby jest prosty z wyglądu, ale bardzo skomplikowany w środku, tak jak ciało ludzkie [19]. Celem kolejnych podrozdziałów jest opisanie charakterystycznych elementów języka Ruby, które świadczą o jego sile i popularności. Pozwoli nam to również lepiej zrozumieć przykłady zawarte w dalszej części pracy. 61

62 5.5.1 Podstawy składni Ruby bazuje na wielu językach, takich jak CLU, Eiffel, Lisp, Perl, Python czy Smalltalk. Jego składnia jest zorientowana liniowo i oparta na CLU oraz, w mniejszym stopniu na Perlu. W poniższych punktach przedstawimy specyficzne elementy składni Rubiego, które odróżniają go od takich języków jak chociażby Java, C++ czy C#. Elastyczność Ruby mimo swojej obiektowości jest językiem bardzo elastycznym i nie narzuca nam pisania kodu w sposób obiektowy (co czyni np. Java). Przykładowo program wyświetlający na ekranie tekst Witaj Świecie może wyglądać następująco: print "Witaj Świecie" Jak widać nie deklarowaliśmy tutaj żadnej klasy ani metody, a kod odpowiedzialny za wykonanie tego zadania zmieścił sie w jednej linii. Ciekawostką jest fakt, że w większości definicji metod oraz wywołań w języku Ruby nawiasy są opcjonalne. To samo tyczy się separatorów instrukcji. Standardowo znak nowej linii traktowany jest jako separator, jednak chcąc mieć możliwość wpisywania kilku instrukcji w jednej linii będziemy zmuszeni do użycia znaku średnika po każdej z nich. Struktury sterujące W Rubim znajdziemy trzy podstawowe instrukcje warunkowe: if, unless, switch oraz pętle: while, do i for. Jak widać są to standardowe struktury sterujące dostępne w większości języków programowania. Jedyną różnicą jest brak nawiasów klamrowych oznaczających bloki instrukcji do wykonania. Zamiast nich używa się słowa kluczowego end. a = 5 if a > 2 a = 10 else a = 0 end Ciekawostką jest także to, że Ruby posiada specjalną konstrukcję warunkową unless, która pozwala sprawdzić czy warunek jest fałszywy: 62

63 unless cena > 100 przesylka = 20 end Instrukcji warunkowych możemy używać także wewnątrz funkcji, z odwróconą kolejnością najpierw instrukcja, a dopiero potem warunek: print "tak" if a > 0 Wiele wartości w instrukcji return Domyślnie każda metoda zwraca ostatnie obliczone wyrażenie, choć można oczywiście zastosować słowo kluczowe return, by zwrócić konkretną wartość. Jednak w Rubim, w odróżnieniu od języków C/C++ czy Java instrukcja return może zwracać więcej niż jedną wartość. W poniższym przykładzie metoda test zwraca jednocześnie trzy obiekty: napis ( a ), liczbę (0) oraz tablicę ([1, abc ]), które następnie mogą być przypisane do trzech kolejnych zmiennych: def test return "a", 0, [1, "abc"] end napis, liczba, tablica = test Pełna obiektowość W Rubim wszystko jest obiektem. Dotyczy to nawet łańcuchów znakowych czy liczb. Każdy fragment informacji i kodu może uzyskać swoje właściwości, zwane zmiennymi instancji oraz czynności, zwane metodami. Czysto obiektowe podejście Rubiego jest demonstrowane przy użyciu fragmentu kodu, który wywołuje metodę na liczbie (faktycznie jest to obiekt klasy Fixnum, która służy do przechowywania liczb całkowitych): 5.times { print "Wszystko jest obiektem" } Powyższy fragment kodu wypisze na ekranie pięć razy tekst Wszystko jest obiektem. 63

64 Jeśli chodzi o nazwy klas, metod, zmiennych oraz stałych Ruby przyjmuje pewne konwencje nazewnicze [18]. Ich podsumowanie zawarliśmy w Tab Konwencja Przykład zmienne lokalne zmienna mojazmienna zmienne globalne $zmienna $mojazmienna instancji klasy (statyczne) stałe Stała Stala nazwy klas Klasa MojaKlasa nazwy metod metoda mojametoda Tabela 5.1. Ruby konwencje nazewnicze (na podstawie [18]). W Rubim, definicja klasy jest regionem kodu pomiędzy słowami kluczowymi class i end. Słowo kluczowe def wewnątrz tego regionu rozpoczyna definicję metody danej klasy: class Pies def = "Hau hau" end def szczekaj end end Ruby nie wspiera wielokrotnego dziedziczenie, a więc klasy mogą mieć tylko jednego bezpośredniego przodka, nazywanego też rodzicem lub klasą bazową. Dziedziczenie oznacza się symbolem "<". class Pies < Ssak... end W powyższym przykładzie klasa Pies jest klasą pochodną, a klasa Ssak jest jej klasą bazową. 64

65 5.5.3 Bloki Bloki to fragmenty kodu, które wyglądają prawie jak parametry funkcji. Są one wywoływane zawsze w połączeniu z metodą, z którą współdzielą zmienne. W języku Ruby blok umieszczony jest w nawiasach klamrowych {} lub też pomiędzy słowami kluczowymi do oraz end, a jego działanie uzależnione jest od powiązanej z nim metody. Dla przykładu, tablice posiadają metodę detect, która zwraca pierwszy element, dla którego blok zwrócił wartość true: tablica.detect do element element > end W powyższym kodzie, blok jest opisany pomiędzy słowami do... end. Metoda detect aplikuje zadany blok do wszystkich elementów podanej tablicy, zwracając pierwszy, którego wartość będzie większa od Pomyślmy jak zaimplementowalibyśmy taką metodę w Javie. Trzeba by było zastosować jakąś pętlę, przed którą musielibyśmy zainicjować zmienną, pętla musiałaby się przerwać itd Metaprogramowanie W największym skrócie można powiedzieć, że metaprogramowanie pozwala w Rubim na dynamiczne modyfikowanie własności całych klas obiektów w czasie działania programu. Zasadnicze części języka mogą zostać usunięte lub przedefiniowane. Możliwe jest nawet przechwycenie próby wywołania nieistniejącej metody i wygenerowanie jej w razie potrzeby. Wszystko po to, by nie ograniczać programisty. Na przykład, dodawanie wykonuje się standardowo za pomocą operatora: +. Lecz gdybyśmy chcieli wykorzystać w tym celu słowo plus, moglibyśmy dodać stosowną metodę do klasy Numeric: class Numeric def plus(x) self.+(x) end end y = 5.plus 6 65

66 Powyższy kod nie definiuje klasy Numeric, ale przedefiniowuje standardowo istniejącą klasę dodając do niej nową metodę plus(x). 5.6 Architektura Rails Praca z Ruby on Rails rozpoczyna się zawsze od wygenerowania szkieletu projektu. Dzięki temu możemy od razu przystąpić do pracy nad nową aplikacją, zamiast tracić czas na wymyślanie poprawnej organizacji kodu. W niniejszym podrozdziale omówimy szczegółową organizację plików w projekcie, jego strukturę oraz pomocnicze narzędzia, których można używać podczas pracy nad projektem Struktura katalogów Nowy projekt Ruby on Rails tworzymy przy pomocy polecenia rails, podając jako parametr nazwę tworzonej aplikacji: > rails Taskzilla create create app/controllers create app/helpers create app/models create app/views/layouts create config/environments create db create lib... create test/unit create vendor... create app/controllers/application.rb create config/database.yml... Każdy projekt składa się z tej samej, ściśle okreslonej struktury katalogów i plików (Rys. 5.2). 66

67 Rysunek 5.2. Struktura nowego projektu RoR. Poszczególne katalogi i pliki mają swoje określone zastosowania, które przedstawia Tab Katalog Podkatalog Zastosowanie app tu przechowywany jest główny kod projektu controllers pliki z kontrolerami (np. users_controller.rb czy semesters_controller.rb); każdy kontroler zawiera klasę dziedziczącą po ApplicationController helpers tzw. helpery, moduły Rubiego zawierające pomocnicze funkcje używane w szablonach models pliki modeli klas używanych do mapowania obiektowo relacyjnego; nazwa modelu powinna być rzeczownikiem w liczbie pojedynczej (np. exercise.rb); wszystkie modele dziedziczą po klasie ActiveRecord::Base views pliki z szablonami dla warstwy widoku views/layouts szablony tzw. rozkładówek, szablonów wzorcowych lub po prostu layoutów config pliki konfiguracyjne bazy danych (plik database.yml), struktury 67

68 Katalog Podkatalog Zastosowanie środowiska Rails (environment.rb) oraz zasad przekazywania nadchodzących żądań (routes.rb) db schemat bazy danych (plik schema.rb) oraz plik migracji (podkatalog db/migration) doc pliki z dokumentacją projektu, która generowana jest za pomocą komendy rake doc:app na podstawie komentarzy w kodzie lib dodatkowe biblioteki i moduły automatycznie ładowane przez Rails podczas startu aplikacji log dzienniki błędów public pliki WWW, które nie ulegają zmianie, takie jak pliki skryptów języka JavaScript (public/javascripts), grafiki (public/images), arkuszy stylów (public/stylesheets) i pliki HTML (public) script skrypty pomocnicze generatory kodu, skrypty startujące serwer itp (więcej w Rozdz ) test testy, które napiszemy, oraz te, które utworzy dla nas Rails; katalogi dla makiet (test/mocks), testów jednostkowych (test/unit) i funkcjonalnych (test/functional) (więcej w Rozdz. 5.8) tmp pliki tymczasowe vendor zewnętrzne biblioteki (np. moduły logowania, biblioteki bezpieczeństwa itp.) Rakefile plik definiujący sporo pożytecznych zadań wykorzystujący bibliotekę Rake (odpowiednik Javowego Anta). Standardowa lista zadań jest spora i zawiera m.in. automatyczne uruchamianie testów, migracji oraz tworzenie dokumentacji Tabela 5.2. Struktura katalogów i plików projektu RoR (na podstawie [16]). Każdy nowo utworzony projekt Rails będzie miał taką samą strukturę i stosować się będzie do takich samych konwencji nazewniczych. Spójność ta przynosi korzyści zarówno programiście, jak i samemu szkieletowi RoR, bowiem bardzo często rozpoznaje on pliki, bazując tylko na ich 68

69 nazwach i położeniu w strukturze katalogów. Dzięki takiej budowie projektu wie, gdzie szukać definicji kontrolerów, modeli, migracji, gdzie znajdują się przypadki testowe oraz dodatkowo zainstalowane biblioteki czy moduły Moduły Szkielet programistyczny RoR zbudowany jest z sześciu podstawowych modułów (Rys. 5.3). Niektóre z nich mogą być używane niezależnie od niego (np. ActiveRecord), jednak dopiero poskładane razem tworzą to, czym jest Ruby on Rails. Rysunek 5.3. Moduły wchodzące w skład szkieletu Ruby on Rails (na podstawie [20]). ActionController Moduł Action Controller jest komponentem zarządzającym kontrolerami, które realizują logikę biznesową tworzonej aplikacji. Pobiera i przetwarza dane z warstwy modelu (ActiveRecord) i przekazuje je w postaci zmiennych do warstwy widoku (ActionView). Usługi świadczone przez Action Controller obejmują także zarządzanie sesją, renderowanie widoków, buforowanie oraz zarządzanie przekierowaniami. 69

70 ActionView Moduł Action View zarządza widokami poprzez wypełnianie ich szablonów danymi przekazanymi z konrolera. Obsługuje zarówno szablony RHTML, XML, JavaScript oraz AJAX. Szablon RHTML zawiera przemieszany kod HTML i Ruby. Znaczniki HTML dostarczają statycznej struktury dokumentu i określają style, natomiast kod języka Ruby dostarcza dynamicznej zawartości, w tym przypadku zmiennych określonych w kontrolerze. Szablon RHTML interpretowany jest przez program ERB (ang. Embedded Ruby), który działa podobnie do parsera PHP. ActiveRecord Moduł Active Record jest mechanizmem odwzorowywania obiektowo-relacyjnego (ang. Object- Relational Mapping, ORM). Dostarcza obiektowego interfejsu do tabel relacyjnej bazy danych. Posiada możliwość walidacji danych i emuluje klucze obce dla baz, które ich nie posiadają (więcej w Rozdz ). Zapewnia również niezależność od bazy danych dzięki jednolitemu interfejsowi, który obsługuje wszystkie dostępne sterowniki bazodanowe. ActionMailer Moduł implementujący obsługę i. Action Mailer może być używany do wysyłania, odbierania i przetwarzania przychodzących wiadomości. ActiveResource Moduł ActiveResource służy do implementacji serwisów internetowych opartych na architekturze REST (ang. Representational State Transfer), która polega na organizowaniu aplikacji wokół zasobów i standardowych zapytań HTTP (delete, get, post, put). Począwszy od Rails 2.0 moduł ten zastępuje wcześniej używany ActionWebService, który umożliwiał implementację serwisów internetowych opartych na protokole SOAP i XML-RPC. ActiveSupport Moduł Active Support jest obszernym zbiorem użytecznych klas oraz rozszerzeń standardowych bibliotek języka Ruby, które są wykorzystywane w Railsach. Do najważniejszych rozszerzeń należą dodatkowe metody zdefiniowane w klasach do obsługi napisów, liczb oraz daty i czasu. 70

71 5.6.3 Narzędzia Ruby on Rails poza bogatą gamą bibliotek oraz gotowych komponentów udostępnia również szeroki wachlarz skryptów oraz narzędzi, które w różnym stopniu wspomagają pracę programisty oraz upraszczają wykonywanie powtarzających się zadań takich jak instalowanie wtyczek, uruchamianie interaktywnej konsoli lub serwera WWW. Najważniejsze skrypty pomocnicze przedstawia Tab Skrypt./script/generate./script/server./script/console Opis tworzy wszystkie podstawowe bloki konstrukcyjne aplikacji: modele, kontrolery, szablony oraz migracje bazy danych (odpowiednie pliki wraz z wymaganą treścią) uruchamia aplikację na domyślnym serwerze WEBrick, który jest specjalnym serwerem HTTP napisanym w języku Ruby otwiera w środowisku projektowym specjalną konsolę IRB (ang. Interactive Ruby), która umożliwia interaktywną pracę z aplikacją bez konieczności uruchamiania serwera HTTP Tabela 5.3. Skrypty pomocnicze udostępniane przez RoR (na podstawie [16]). rake Rake jest narzędziem do budowania elementów projektów w Ruby on Rails podobnym w działaniu do znanego narzędzia make. Zawiera zestaw zadań, który może być dowolnie poszerzany poprzez definiowanie własnych zachowań. Dzięki niemu w szybki sposób możemy np. utworzyć nową bazę danych lub ją usunąć, uruchomić testy jednostkowe, sprawdzić wersję zainstalowanych wtyczek czy wygenerować dokumentację projektową. 5.7 Wzorzec MVC w Ruby on Rails Ruby on Rails zorganizowany jest wokół trzech warstw aplikacji realizujących wzorzec MVC. W skrócie: warstwę modelu (Model) relizuje ActiveRecord, za kontroler (Controller) odpowiedzialny jest ActionControler, a warstwę widoku (View) realizuje moduł ActionView. 71

72 Wszystkie trzy warstwy zostaną omówione niżej w oddzielnych podrozdziałach posiłkując się przy tym przykładami kodu z projektu Taskzilla Kontroler Zadaniem kontrolera jest realizacja logiki biznesowej. Odpowiada on za przetwarzanie żądań przychodzących z przeglądarki internetowej, pozyskiwanie danych z modeli i przekazywanie ich do widoków w celu prezentacji. Generowanie kodu Pliki kontrolerów mogą być tworzone ręcznie, ale znacznie wygodniej jest użyć dostępnych skryptów do generowania kodu. Nie tylko wypełniają one początkową treścią plik kontrolera, ale także generują klasy do testów jednostkowych oraz szablony widoku. Poniżej przedstawiamy wynik użycia skryptu generate do utworzenia kontrolera, który będzie zarządzał kursami. ruby script/generate controller courses exists app/controllers/ exists app/helpers/ create app/views/courses exists test/functional/ create test/unit/helpers/ create app/controllers/courses_controller.rb create test/functional/courses_controller_test.rb create app/helpers/courses_helper.rb create test/unit/helpers/courses_helper_test.rb Każdy kontroler składa się z klasy o nazwie wprowadzonej przez nas z dodanym automatycznie sufiksem Controller. Dla naszego powyższego przykładu będzie to: class CoursesController < ApplicationController end Domyślnie wszystkie kontrolery dziedziczą z klasy bazowej ApplicationController zdefiniowanej w pliku app/controllers/application_controller.rb. Wszystkie zdefiniowane tam metody są dostępne w każdym kontrolerze potomnym. 72

73 Akcje Metody instancji klasy kontrolera w Ruby on Rails nazywają się akcjami. Każda z nich może mieć inny zakres widoczności. Ruby kontroluje zakres dostępu za pomocą znanych z innych języków programowania słów kluczowych public, protected i private [16]. Domyślnie wszystkie akcje są publiczne i tylko takie są widoczne z poziomu przeglądarki. Podczas wywoływania przez użytkownika akcji standardowo przekazywane są do niej następujące obiekty: params tablica asocjacyjna zawierająca parametry żądania, request tablica asocjacyjna zawierająca takie dane jak adres pod który skierowano zapytanie czy nazwę przeglądarki użytkownika, session tablica asocjacyjna przechowująca dane zapisane w sesji użytkownika. Renderowanie odpowiedzi Akcja kontrolera zwraca odpowiedź do przeglądarki użytkownika dzięki użyciu specjalnej metody render. Jeśli nie wyspecyfikujemy jej jawnie, Rails będzie starał się odszukać w odpowiednim folderze szablonu widok o takiej samej nazwie jak akcja (więcej w Rozdz ). Dla przykładu weźmy akcję course_list z kontrolera zarządzającego kursami: class CoursesController < ApplicationController def course_list courses = Course.all :include => :semester render :xml => courses.to_xml(:include => [:semester], :dasherize => false) end end Wywołaniu powyższej akcji towarzyszy pobranie listy kursów z bazy danych oraz wyświetlenie ich na ekranie użytkownika w postaci XMLa (render :xml). Gdybyśmy usunęli ostatnią linijkę z akcji course_list, Rails wygenerowałby kod HTML na podstawie szablonu widoku zawartego w pliku app/views/courses/course_list.rhtml. Rails umożliwia wysyłanie danych w formatach HTML, XML, JSON oraz jako zwykły tekst. 73

74 Filtry Rails udostępnia trzy rodzaje filtrów pozwalających na wykonywanie dodatkowych operacji przed lub po akcji kontrolera. Dzięki temu nasz kod staje się czytelniejszy oraz ustrzegamy się przed powtarzaniem tego samego fragmentu kodu. Dostępne są trzy rodzaje filtrów [17]: before_filter umożliwia uruchomienie dodatkowych metod zanim wywołana zostanie właściwa akcja. Najczęściej stosowane są do implementacji mechanizmu chroniącego dostęp do wybranych akcji kontrolera np: before_filter :auth_user after_filter działa tak samo jak powyższy filtr, z tą różnicą, że wywołuje odpowiednie metody tuż po wykonaniu bieżącej akcji kontrolera, lecz jeszcze przed wysłaniem odpowiedzi do klienta. around_filter działa jak poprzednie dwa użyte równocześnie przed i po wywołaniu kodu bieżącej akcji kontrolera. System routingu Routing to wchodzący w skład ActiveSupport mechanizm generowania i translacji adresów URL na wywołania konkretnych kontrolerów i znajdujących się w nich akcji. Przyjętą przez Rails konwencję przedstawia Rys nazwa wołanego kontrolera miejsce przekazywania parametrów (domyślnie wartość parametru id) adres i port serwera, na którym uruchomiona została aplikacja nazwa uruchamianej akcji Rysunek 5.4. Mechanizm generowania i translacji adresów URL w RoR. 74

75 Nie podanie nazwy konkretnej akcji kontrolera powoduje wywołanie domyślnej jaką jest index. Wszystkie reguły routingu Rails trzymane są w pliku config/routes.rb. Każdy projekt Rails posiada automatycznie stworzone dwie reguły: map.connect ':controller/:action/:id' map.connect ':controller/:action/:id.:format' Nic nie stoi na przeszkodzie jeśli chcemy je zmodyfikować lub zdefiniować własne Model Najważniejszą warstwą szkieletu Rails jest warstwa modelu, za którą odpowiedzialny jest moduł ActiveRecord (dalej: AR). Odpowiada ona za obsługę modelu biznesowego czyli przechowywanie i walidację danych. Zajmuje się odwzorowywaniem obiektowo relacyjnym (ORM). Takie podejście daje złudzenie pracy z obiektową bazą danych. Użycie przez Rails ORM zamiast czystego SQL znacząco upraszcza sposób pracy z bazą danych. Wszelkie relacje między tabelami są odzwierciedlane obiektowo. AR przyjmuje, że odpowiednikiem tabeli i jej kolumn będzie klasa Rubiego (dziedzicząca po ActiveRecord:Base) i jej atrybuty, a odpowiednikiem wierszy egzemplarze tej klasy [16]. Dzięki mechanizmowi ORM nie musimy się również martwić w przypadku ewentualnej zmiany bazy danych, ponieważ dba on o kwestie zgodności dialektów SQL. Warto też podkreślić, że ActiveRecord nie zakłada całkowitego wyeliminowania języka SQL. W przypadku bardziej skomplikowanych operacji istnieje możliwość korzystania z czystego SQLa, dzięki czemu możemy wykraczać poza ograniczenia implementacji AR. To nie wszystkie cechy tego modułu, bowiem zapewnia on także obiektową walidację danych, czyli kontrolę danych wprowadzanych do bazy. Pozwala również na symulację zachowań, których baza może nie posiadać. Jednym z przykładów jest symulacja kluczy obcych. W takim przypadku definicja relacji między tabelami jest ustawiana w klasie modelu ActiveRecord i działa nawet wtedy, gdy baza nie ma ustawionych kluczy obcych lub ich nie obsługuje. Konfiguracja połączenia z bazą danych Prawie każda aplikacja Rails korzysta z bazy danych. Rodzaj bazy danych, której używamy, jest określony w pliku konfiguracyjnym config/database.yml. Plik ten znajduje się poza publicznym zasięgiem serwera HTTP, więc nie ma ryzyka ujawnienia jego zawartości w razie problemów z serwerem. Standardowo, podczas generowania nowego projektu, tworzone są definicje dla 75

76 trzech różnych baz. Ma to związek z różnymi środowiskami, w których Rails może być uruchamiany: Baza testowa (środowisko test) używana do uruchamiana automatycznych testów. Baza rozwojowa (środowisko development) używana do pracy podczas tworzenia oprogramowania. Baza produkcyjna (środowisko production) przeznaczona do pracy na serwerze produkcyjnym. W tym trybie włączony jest cache i kod Rubiego nie jest przeładowywany podczas jego zmian. Aktualnie obsługiwane przez AR bazy danych to: DB2, FireBird, MySQL, OpenBase, Oracle, PostgreSQL, SQL Server, SQLite i Sybase. Konfiguracja połączenia z bazą danych różni się w zależności od wybranego sterownika. Przykładowo dla bazy MySQL konfiguracja środowiska wygląda następująco: development: adapter: mysql database: Taskzilla_development username: WIECEK password: ****** host: localhost port: 3306 encoding: utf8 Migracje Migracje są klasami Rubiego, które pozwalają na wersjonowanie zmian w strukturze bazy danych, podobnie jak systemy kontroli wersji zarządzają kodem aplikacji. Upraszczają tworzenie i modyfikowanie tabel w bazie danych z wykorzystaniem języka Ruby w sposób niezależny od użytej bazy danych. Przykładowa migracja tworząca tabelę exercises wygląda następująco: create_table :exercises do t t.integer :course_id, t.string :name, t.text :description t.date :expiration_date t.string :disc_path, end :null => false :null => false :null => false 76

77 Migracje umożliwiają również wykonanie takich akcji, jak: usunięcie tabeli (drop_table), zmianę nazwy tabeli (rename_table), dodanie nowej kolumny (add_column), utworzenie indexu (add_index) oraz wiele innych. Ograniczenia i wartości domyślne dla każdej z kolumn mogą zostać zdefiniowane przy pomocy następujących symboli: :default - ustawia domyślną wartość dla kolumny, :null określa, czy kolumna może przyjmować wartość NULL, :limit jest używany dla kolumn typu string i określa maksymalną ilość znaków. Standardowo przyjmuje się, że jeśli tabela posiada klucz główny, to powinien on być typu Integer i posiadać nazwę id. Jeśli jednak zachodzi taka potrzeba, to można tę konwencję zmienić używając opcji :primary_key tak, jak w poniższym przykładzie: create_table :exercises, :primary_key => : exercise_id do t... ActiveRecord tworzy specjalną tabelę schema_migrations z polem tekstowym version. Każda kolejna migracja jest przechowywana w oddzielnym pliku w katalogu db/migrate oraz dodaje swój prefiks do tabeli. Przykładowa nazwa pliku z migracją wygląda następująco: _create_exercises.rb. Prefiks w nazwie to bieżąca data według formatu YYYYMMDDHHMMSS. Dalsza część nazwy pliku migracyjnego ma ścisły związek ze znajdującą się w środku klasą Rubiego. Jeśli zmienimy nazwę pliku, to należy też zmienić nazwę klasy modelu. Uruchomienie migracji wiąże się z wykonaniem polecenia: rake db:migrate [VERSION=prefix] Bez podanej opcji VERSION uruchomione zostaną pliki migracyjne od bieżącej wersji w górę. W przypadku podania opcji VERSION uruchomimy migracje do podanej wersji. O tym, czy będzie to kierunek w górę (wprowadzenie zmian do bazy danych), czy w dół (wycofywanie wprowadzonych wcześniej zmian), decyduje miejsce rekordu na liście w tabeli schema_migrations. 77

78 Asocjacje W Ruby on Rails asocjacja to powiązanie ze sobą modeli ActiveRecord. Asocjacje są realizowane poprzez makro-połączenia, a więc dzięki dodaniu stosownej funkcji do modelu poprzez jej zadeklarowanie. Na przykład, deklarując, że jeden model należy do (belongs_to) innego, instruujemy ActiveRecord by utrzymywał powiązanie klucza podstawowego z obcym kluczem między instancjami tych dwóch modeli, a dzięki temu otrzymujemy także szereg metod, które możemy wykorzystać w swoim modelu. Rails definiuje cztery typy asocjacji: belongs_to, has_one, has_many i has_and_belongs_to_many [21]. Na ich podstawie ActiveRecord obsługuje trzy podstawowe typy relacji między tabelami (jeden-do-wielu, wieledo-wielu, jeden-do-jednego). Asocjacja has_many wskazuje relację typu jeden-do-wiele. Znajdziemy ją "po drugiej stronie" asocjacji belongs_to. Relacja ta wskazuje, że każda instancja modelu posiada zero lub więcej instancji innego modelu. Na przykład, w aplikacji Taskzilla zawierającej kursy oraz zadania, model kursu został zadeklarowany następująco: class Course < ActiveRecord::Base has_many :exercises end natomiast model opisujący zadanie przyjmuje postać: class Exercise < ActiveRecord::Base belongs_to :course end Kiedy deklarujemy asocjację has_many, nazwa wiązanego modelu (w naszym przypadku Exercise) jest zamieniana na jej liczbę mnogą, exercises. Dzięki użyciu asocjacji wiązane modele automatycznie zyskują dodatkowe metody. Możliwe są m.in. następujące - zwraca tablicę [array] wszystkich wiązanych obiektów (zadań w danym kursie). Jeśli nie istnieją żadne obiekty, zwraca pustą - zwraca wiązany obiekt (kurs do którego należy zadanie), jeśli tylko taki istnieje. Jeśli obiekt nie został znaleziony, metoda zwraca nil. 78

79 Asocjacje has_one i belongs_to ustanawiają relację typu jeden-do-jeden pomiędzy dwoma modelami. Wskazują one, iż każda instancja jednego modelu posiada dokładnie jedną instancję drugiego. Jest to szczególny przypadek relacji jeden-do-wielu. W relacji wiele-do-wielu jednemu rekordowi w pierwszej tabeli odpowiada wiele rekordów w drugiej i vice versa. W tym wypadku trzeba utworzyć tabelę pomocniczą, która będzie zawierała klucze obce obu modeli. Tabela łącząca modele nie może zawierać klucza głównego, nie potrzebujemy też tworzyć dla niej modelu. Kwestia jej nazwy jest też określona konwencjami Rails. Składa się ona z dwóch nazw łączonych tabel oddzielonych znakiem podkreślenia. Ważne, aby nazwy występowały w porządku alfabetycznym. Tabela pomocnicza reprezentująca relację studentów z kursami przyjmuje postać: create_table :courses_students, :id => false do t t.integer :student_id, :null => false t.integer :course_id, :null => false end Na samym końcu musimy dodać jeszcze asocjację has_and_belongs_to_many odpowiednio do modelu Student i Course: class Student < ActiveRecord::Base has_and_belongs_to_many: courses end class Course < ActiveRecord::Base has_and_belongs_to_many: students end Zgodnie z konwencjami Rails parametr asocjacji has_and_belongs_to_many musi być nazwą modelu w liczbie mnogiej Widok Ostatnim elementem architektury MVC jest warstwa widoku, za którą odpowiedzialny jest moduł ActionView. Jej zadaniem jest dostarczanie danych do przeglądarki internetowej lub innego narzędzia, które jest używane do prezentacji efektów działania aplikacji. 79

80 Kod widoku zapisuje się w specjalnych plikach (z rozszerzeniem *.html.erb) zwanych szablonami, w folderze app/views. Zgodnie z regułą Convention over Configuration kontrolery w RoR automatycznie wyświetlają szablony z nazwami odpowiadającymi wywołanym akcjom. Na przykład, jeśli mamy zdefiniowany kontroler BooksController, w którym znajduje się akcja show, Rails automatycznie po jej wykonaniu wyrenderują plik app/views/books/show.html.erb. Szablony widoków składają się głównie z języka znaczników, czyli HTMLa, z osadzonymi w nim wstawkami języka Ruby oraz kodu JavaScript. Jest to rozwiązanie znane z takich technologii jak ASP.NET, JSP czy choćby PHP. Tak przygotowany szablon interpretowany jest przez program ERB (Embedded Ruby - zagnieżdżony Ruby), który działa podobnie do parsera PHP tworząc dynamiczną zawartość strony na podstawie danych przekazanych przez kontroler. Zasady składni ERB są proste. Wewnątrz znacznika <% kod %> można wpisać dowolny kod Ruby. Taki kod zostanie wykonany, ale nie wyświetlony. Do wyświetlenia używa się znacznika <%= wyrażenie %>. To znaczy, że wynik ostatniego wyrażenia w środku zostanie wygenerowany po stronie serwera jako wynik całego znacznika. <% dowolny kod Ruby, który nie zostanie wyświetlony %> <%= Standardowa metoda, aby coś wyświetlić %> <% if true %> Ten fragment <b>kodu HTML</b> zostanie wyświetlony <% end %> Dane, które wyświetlają szablony pochodzą z kontrolera. To, w jaki sposób są one przekazywane zależy od typu zmiennych. Wszelkie zmienne instancji są automatycznie przekazywane do szablonu. Ma on też dostęp do wszystkich zmiennych globalnych i stałych zdefiniowanych w jego kontrolerze, kontrolerze bazowym lub zdefiniowanych na poziomie konfiguracji aplikacji RoR (np. w pliku config/environment.rb). 5.8 Testowanie aplikacji Ważnym, choć dosyć powszchnie ignorowanym, zagadnieniem jest automatyczne testowanie aplikacji. W nowoczesnych metodologiach wytwarzania oprogramowania testy jednostkowe są jednymi z najważniejszych elementów procesu. Dlatego też tworzenie systemów bez ich wykorzystania możemy porównać do pisania programów na kartce. 80

81 Środowisko Ruby on Rails zachęca do tworzenia dobrze przetestowanych aplikacji poprzez automatyczne generowanie szkieletów przypadków testowych, które później programista może rozbudowywać. Dodatkowo udostępnione jest specjalne środowisko testowe, które pomaga projektować i przeprowadzać testy jednostkowe, funkcjonalne i integracyjne posługując się przygotowaną wyłącznie do tego celu bazą danych [17]. Dzięki temu, że duża część środowiska testów jest tworzona automatycznie podczas prac nad aplikacją, programista może pozbyć się wielu typowych zmartwień związanych z przygotowaniem odpowiedniej konfiguracji oraz samym procesem uruchamiania testów. Rails definiuje trzy rodzaje testów: jednostkowe (testowanie modeli), funkcjonalne (testowanie kontrolerów) oraz integracyjne (testowanie interakcji pomiędzy kilkoma kontrolerami) Testy jednostkowe Do testowania jednostkowego Ruby on Rails używa standardowej biblioteki Test::Unit dostarczonej razem z interpreterem języka. Test::Unit jest podobny do szkieletu testowego xunit dostępnego dla większości języków programowania i realizuje trzy główne koncepcje [18]: 1) asercja pojedyńcza metoda wywoływana z jednym lub wiekszą liczbą parametrów w celu sprawdzenia wartości testowej z oczekiwaną, 2) test pojedyncza metoda, której nazwa zaczyna się od prefiksu test_, zawierająca szereg powiązanych ze sobą asercji, 3) klasa testowa podklasa Test::Unit::TestCase zawierająca zbiór metod testowych. Biblioteka Test::Unit dostarcza dużo różnorodnych asercji. Większość z nich przyjmuje opcjonalny parametr [msg] oznaczający komunikat błędu, który ma zostać wyświetlony, jeśli nie są one spełnione. Najczęściej używane asercje przedstawia Tab Rodzaj asercji Asercja prawdziwa jeśli? assert( boolean, [msg] ) boolean==true assert_equal( expected, actual, expected==actual [msg] ) assert_match( pattern, string, string =~ pattern 81

82 Rodzaj asercji Asercja prawdziwa jeśli? [msg] ) assert_nil( object, [msg] ) object == nil assert_instance_of( class, object.class == class object, [msg] ) assert_raise( Exception,... ) blok kodu wyrzuci wyjątek wymieniony {block} na liście assert_no_difference(expressions, wartość wyrażenia expression nie &block); zmieni się, w wyniku wykonania podanego bloku kodu assert_respond_to( obj, symbol, obj ma metodę nazwaną symbol [msg] ) assert_operator( obj1, operator, obj1.operator(obj2) jest prawdą obj2, [msg] ) Tabela 5.4. Lista asercji zawartych w Test::Unit, bibliotece testowej używanej przez RoR. Dodatkowo, w razie potrzeby, możemy użyć dwóch metod dostarczanych standardowo przez szkielet testowy: setup oraz teardown. Przed wykonaniem jakiegokolwiek testu najpierw uruchamiana jest metoda setup, w której możemy wykonać prace inicjalizacyjne. Podobnie, bezpośrednio po zakończeniu każdego testu, wołana jest metoda teardown w celu usunięcia lub zwolnienia zasobów zajętych przez setup. Przykładowy test dla klasy User, która w aplikacji Taskzilla odpowiedzialna jest za przechowywanie danych o użytkownikach wygląda następująco: class UserTest < Test::Unit::TestCase... def test_should_reset_password users(:quentin).update_attributes(:password => 'new pass') assert_equal users(:quentin), User.authenticate('quentin', 'new pass') end... end 82

83 W teście test_should_reset_password sprawdzamy działanie funkcji służącej do zmiany wartości dowolnego pola obiektu klasy User. W pierwszej linii wyciągamy z testowej bazy danych przykładowego użytkownika o loginie :quentin oraz zmieniamy mu hasło: users(:quentin).update_attributes(:password => 'new pass') Na końcu logujemy się jako powyższy użytkownik podając nowe hasło, a następnie sprawdzamy, czy zwrócony obiekt klasy User jest taki sam, jak obiekt pobrany z bazy: assert_equal users(:quentin), User.authenticate('quentin', 'new pass') Testy funkcjonalne Kontrolery zajmują się przychodzącymi do aplikacji żądaniami, współpracują z modelami oraz generują i wysyłają odpowiedzi. W Railsach za testowanie różnych akcji pojedynczego kontrolera pod kątem odpowiedniej obsługi przychodzących żądań odpowiedzialne są testy funkcjonalne. Wszystkie tego typu testy muszą dziedziczyć po klasie bazowej ActionController::TestCase. Poniżej prezentujemy przykładowy test kontrolera CoursesController, który w aplikacji Taskzilla odpowiedzialny jest za zarządzanie kursami: class CoursesControllerTest < ActionController::TestCase... def test_should_get_index get :index assert_response :success assert_not_nil assigns(:courses) end... end W teście test_should_get_index, Rails symuluje zapytanie na akcji nazwanej index: get :index upewnia się, że zapytanie zostało zakończone powodzeniem: assert_response :success oraz, że instancja kontrolera poprawnie przypisała wartość do 83

84 assert_not_nil assigns(:courses) Do symulowania zapytań HTTP Rails używa pięciu metod: get, post, put, head oraz delete. Każda z nich akceptuje cztery argumenty, przy czym tylko pierwszy jest wymagany: action nazwa akcji kontrolera, którą wywołujemy, parameters tablica asocjacyjna z parametrami żądania HTTP, session stan sesji do przekazania razem z żądaniem, flash tablica asocjacyjna z obiektami wiadomości. Asercja assert_response służy do sprawdzania statusu otrzymanej odpowiedzi. Może przyjmować zarówno oczekiwany numer, jak i opisowy symbol np.: :success, :redirect, :unauthorized. Dodatkowo po tym, jak imitowane zapytanie HTTP zostanie wysłane i przetworzone przez kontroler mamy do dyspozycji cztery tablice asocjacyjne: assigns, cookies, flash oraz session. Dzięki nim możemy sprawdzić np.: stan sesji, obiekt flash oraz zawartość jaką miałyby pliki cookies. Najważniejszą z tablic jest assigns. Przechowuje ona i pozwala odczytywać zmienne instancji kontrolera, które trafiają do szablonów widoku Testy integracyjne W Ruby on Rails testy integracyjne wykorzystywane są do sprawdzania interakcji pomiędzy wieloma kontrolerami oraz ich akcjami w celu zapewnienia, że współpracują one razem w oczekiwany sposób. Umożliwiają tworzenie złożonych scenariuszy testowych i porównywanie ich wyników z deklarowanymi przez użytkownika rezultatami. Swoją składnią przypominają testy funkcjonalne, wzbogacając ją o dodatkowy zestaw asercji pochodzący z klasy ActionController::IntegrationTest, która to jest klasą bazową dla wszystkich testów integracyjnych. Nie będziemy opisywać dokładnie tworzenia tego rodzaju testów, ponieważ bardzo często programiści Rails wykorzystują zamiast nich alternatywne rozwiązania, które pozwalają wykonywać testy za pośrednictwem instancji przeglądarki internetowej. Do takich rozwiązań należą chociażby Selenium IDE [32] czy Watir [33]. 84

85 Rozdział 6. Zwinna realizacja projektu aplikacji internetowej W niniejszym rozdziale, na przykładzie jednej z najbardziej znanych metodologii zwinnych jaką jest Scrum, zaprezentujemy zwinne zarządzanie procesem tworzenia aplikacji internetowej. Przedstawimy główne założenia aplikacji, jej architekturę oraz zwinne środowisko wykorzystane podczas prac programistycznych. Na samym końcu pokażemy jak wygląda praktyczna realizacja przykładowej iteracji w procesie tworzenia oprogramowania. 6.1 Zdefiniowanie problemu Ze względu na konieczność praktycznego zweryfikowania prezentowanych metodologii, w ramach pracy, na potrzeby Zakładu Technologii Informatycznych WFAIS UJ, została stworzona internetowa aplikacja Taskzilla. Jej głownym zadaniem jest wspieranie procesu dydaktycznego poprzez umożliwienie wymiany plików pod postacią materiałów dydaktycznych, zadań oraz ich rozwiązań pomiędzy studentami a prowadzącymi zajęcia pracownikami. W tym celu konieczne jest zrealizowanie modułów, które będą odpowiedzialne za najważniejsze funkcje systemu: rejestrację studentów na kursy, publikację materiałów oraz oddawanie zadań. Aplikacja z założenia ma być prosta, działać pod wszystkimi popularnymi przeglądarkami internetowymi i zapewniać bezpieczną komunikację. Przy tym wszystkim musi cechować się niezawodnością oraz skrupulatnie pilnować wyznaczonych terminów. Podsumowując, projektowana aplikacja ma ułatwiać komunikację między studentami a pracownikami dydaktycznymi oraz stanowić miejsce wymiany danych w Internecie. Każdy pracownik posiadający konto w systemie będzie mógł przy jej pomocy publikować materiały dydaktyczne oraz zamieszczać zadania, ustalając jednocześnie termin nadsyłania ich rozwiązań. 85

86 Natomiast zarejestrowani studenci będą mogli zaznajamiać się z tematyką ćwiczeń, pobierać materiały, a także zamieszczać w wyznaczonych terminach odpowiedzi do zadań. 6.2 Uzasadnienie wybóru metodologii zarządzania projektem Jak już wspomnieliśmy na początku tego rozdziału, zarządzanie projektem tworzonej przez nas aplikacji zostało oparte na zasadach metodologii Scrum. Wybraliśmy ją, ponieważ jest jedną z najbardziej znanych i cenionych metodologii zwinnych. Sprawdza się zarówno przy małych, jak i dużych wielomodułowych projektach. Iteracyjna i inkrementalna natura Scruma, połączona dodatkowo z zarządzaniem priorytetami wymagań, pozwala klientowi uzyskać całkowitą kontrolę nad kierunkiem i zakresem prac realizowanych w ramach projektu, a jego twórcom na wcześniejsze wykrywanie ewentualnych problemów. Na końcu każdej iteracji, klient może zdecydować o kontynuacji projektu, poprzez dodanie lub modyfikację istniejącej funkcjonalności, albo o jego zakończeniu, jeśli jest już zadowalającej jakości, bądź przestaje być opłacalny. Wreszcie, Scrum przynosi korzyści również menedżerowi projektu dostarczając mu narzędzi: rejestr produktowy, rejestr prac Sprintu, wykres spalania, oraz technik: codzienne spotkania, spotkanie planowania Sprintu, spotkanie przeglądu Sprintu, ukierunkowanych na zwiększenie możliwości obserwacji każdego aspektu projektu. 6.3 Zwinne środowisko pracy programisty Zwinny proces realizacji projektu nie jest możliwy bez odpowiedniego wsparcia narzędziowego. Interaktywne środowiska programistyczne (IDE), systemy kontroli wersji kodu źródłowego itp. są kluczowymi narzędziami decydującymi o funkcjonowaniu zespołu programistów. Celem tego podrozdziału jest przedstawienie narzędzi użytych podczas procesu tworzenia aplikacji Taskzilla. 86

87 6.3.1 RadRails Jak już wykazaliśmy w Rozdz. 5, Ruby on Rails to idealne środowisko do zwinnego tworzenia aplikacji internetowych. RadRails to darmowe, wysokiej klasy zintegrowane środowisko programistyczne (ang. Integrated Development Environment, IDE) dedykowane do pracy nad aplikacjami RoR. Edytor RadRails oparty jest na popularnym środowisku Eclipse, dzięki czemu może być używany na takich platformach systemowych jak Microsoft Windows, Mac OS czy Linux [34]. RadRails IDE zapewnia wiele rozwiązań i udogodnień, które w znaczący sposób wpływają na komfort i szybkość pracy programisty. Należą do nich m.in. generatory kodu, edytor z podświetlaniem składni i autouzupełnianiem, zintegrowany system kontroli wersji, automatyczna obsługa testów jednostkowych, interaktywna linia poleceń oraz wbudowana obsługa serwerów HTTP. Dzięki RadRails nie trzeba własnoręcznie uruchamiać żadnych skryptów Railsowych, ponieważ dostarcza on dedykowanego interfejsu do tworzenia i usuwania kontrolerów, modeli, widoków oraz obsługi serwerów HTTP Adobe Flex Builder Adobe Flex Builder to wydajne, oparte na środowisku Eclipse narzędzie programistyczne do kodowania oraz projektowania w trybie graficznym wyglądu interfejsu użytkownika aplikacji typu RIA opartych o technologię Adobe Flex. Oferuje edytory MXML, ActionScrip i CSS, kolorowanie składni, uzupełnianie wyrażeń oraz zwijanie kodu. Bogata biblioteka wbudowanych oraz własnych składników umożliwia projektowanie w trybie graficznym układu i działania interfejsu użytkownika oraz wyświetlanie ich w trybie podglądu. Dzięki Flex Builderowi wszystkie aplikacje oparte o technologię Flex mają profejsonalną budowę i wygląd, a szeroka gama dostępnych komponentów skraca okres przygotowywania nowych wersji oprogramowania. Co za tym idzie staje się on idealnym narzędziem do zwinnego rozwoju aplikacji przeznaczonych dla wymagających klientów. Środowisko Flex Builder jest dostępne bezpłatnie dla wszystkich użytkowników edukacyjnych, to znaczy dla uczniów/studentów, wykładowców i pracowników instytucji edukacyjnych. Dla pozostałych osób istnieje możliwość pobrania wersji demonstracyjnej udostępnionej bezpłatnie na stronie firmy Adobe [35]. 87

88 6.3.3 System kontroli wersji Subversion Subversion (znany również jako SVN) to system kontroli wersji, który służy do śledzenia zmian w kodzie źródłowym projektu oraz pomocy programistom w łączeniu i modyfikacji zmian dokonanych przez wiele osób w różnym czasie, w różnych fragmentach kodu. Zastąpił on starszy system o nazwie CVS (ang. Concurrent Versions System) dostarczając takiej funkcjonalności jak wersjonowanie nazw plików, atomowe transakcje czy przechowywanie danych w bazie danych Berkley DB [36]. Mimo, że głównym celem SVN jest praca w grupie, doskonale sprawdza się także w przypadku, gdy pracujemy sami i chcemy po prostu tworzyć kopie zapasowe naszych projektów, wraz z kontrolą wersji plików, by w każdej chwili móc bez problemu cofnąć nasze modyfikacje, bądź skontrolować zmiany w projekcie. Subversion jest scentralizowanym systemem wymiany informacji. Jego rdzeniem jest repozytorium, które jest głównym miejscem przechowywania danych. Możemy stworzyć je na własnym komputerze lub użyć dostępnych w internecie. Podczas relizacji projektu Taskzilla wykorzystane zostało konto w usłudze Google Code Project Hosting. Oferuje ona bezpłatny serwer SVN z limitem 1024MB, program do zarządzania błędami, strony wiki oraz przeglądarkę kodu [37]. W celu skorzystania z wcześniej utworzonego repozytorium wspomniane wyżej środowiska programistyczne muszą posiadać rozszerzenie w postaci klienta SVN. Najbardziej znanym klientem SVN dla środowisk opartych o platformę Eclipse jest Subclipse. Standardowo dostępny jest on tylko w RadRailsie, natomiast w przypadku Flex Buildera musiał zostać dodatkowo zainstalowany. Warto podkreślić, że repozytorium SVN wraz z umieszczonym w nim kodzie jest jednym z niezbędnych elementów potrzebnych do uruchomienia i działania serwera ciągłej integracji Serwer ciągłej integracji CruiseControl.rb CruiseControl.rb jest darmowym środowiskiem ciągłej integracji napisanym w języku Ruby. Dzięki jego użyciu, po każdorazowym włączeniu zmian w kodzie do głównego repozytorium, kod aplikacji jest automatycznie poddawany pełnemu zestawowi testów napisanych przez programistę. Jeśli któryś z testów nie przechodzi pomyślnie CruiseControl.rb natychmiast powiadamia o zaistniałym problemie oraz wysyła wiadomość z opisem błędu do osób wskazanych w konfiguracji środowiska. 88

89 CruiseControl.rb składa się z dwóch elementów: serwera integracyjnego oraz aplikacji WWW, której zadaniem jest prezentacja wyników przebiegu integracji. Zaletą serwera jest możliwość współpracy z wieloma systemami kontroli wersji, do których należą m.in. Subversion, Git, Mercurial oraz Bazaar. Dodatkowo, jedna instalacja może obsługiwać wiele projektów jednocześnie, gdzie każdy z nich może mieć zdefiniowanych kilka różnych rodzajów integracji [38]. Stosowanie ciągłej integracji z użyciem CruiseControl.rb przyczynia się do zmniejszenia kosztów i ilości pracy niezbędnej do łączenia fragmentów aplikacji wykonanych przez różne osoby oraz do wcześniejszego wykrywania błędów. 6.4 Architektura systemu Taskzilla jest systemem typu klient serwer zbudowanym w oparciu o szkielet programistyczny Ruby on Rails, który charakteryzuje się 3-warstwową architekturą Model- Widok-Kontroler (ang. Model-View-Controller, MVC). Dzięki takiemu podziałowi aplikacja jest bardziej modularna i elastyczna. Pragniemy również wspomnieć o dodaktowym elemencie nienależącym do wzorca MVC, lecz ściśle z nim związanym oraz będącym ważną częścią szkieletu Rails. Jest to moduł routingu, znany również pod nazwą dyspozytora (ang. dispatcher). Rys. 6.1 przedstawia uproszczony schemat architektury aplikacji Taskzilla oraz kierunek wymiany informacji między poszczególnymi jej elementami. Rysunek 6.1. Architektura aplikacji Taskzilla. 89

90 6.4.1 Model-Widok-Kontroler Widok Najwyżej położona warstwa prezentacji danych (widoku) została w całości wykonana przy użyciu technologii Adobe Flex (Rozdz ). Jej użycie ma na celu zastąpienie standardowych szablonów widoku ERB (HTML+JavaScript+Ruby) dostarczanych przez szkielet Rails, nowoczesnym podejściem zapewniającym rozbudowane możliwości tworzenia aplikacji typu RIA oraz wspomagającym proces budowy graficznego interfejsu użytkownika uruchamianego po stronie klienta. Pisząc o technologii Flex stosujemy pewne uogólnienie dla kompleksowego rozwiązania, w skład którego wchodzi Flex Software Development Kit (ang. Flex SDK) oraz zaawansowane środowisko programistyczne Flex Builder. Siłą Flex SDK jest wykorzystanie tandemu: języka MXML wraz z obiektowo zorientowanym językiem ActionScript, dobrze znanym wszystkim użytkownikom Flasha. Kontroler Strona serwerowa aplikacji obejmująca logikę biznesową wykonana jest z wykorzystaniem komponentów dostarczanych przez szkielet programistyczny Ruby on Rails. Za realizację logiki biznesowej odpowiedzialne są kontrolery, których zadaniem jest sklejanie warstwy modelu danych z warstwą prezentacji poprzez przetwarzanie żądań przychodzących z przeglądarki internetowej, pozyskiwanie danych z modeli i przekazywanie ich do aplikacji klienckiej w dwojaki sposób: albo jako dane tekstowe w postaci znaczników XML, albo jako dane binarne w formacie AMF (ang. Action Message Format). Dokładny opis możliwych sposobów wymiany danych pomiędzy klientem napisanym we Flexie, a aplikacją serwerową opartą o szkielet RoR zostanie przedstawiony w Rozdz Model Trzecim poziomem jest warstwa dostępu do danych. Za jej obsługę odpowiedzialny będzie moduł ActiveRecord, który przedstawia tabelaryczne dane z relacyjnej bazy danych w formie klas i obiektów (tzw. modeli). Zapewnia również niezależność od wybranego systemu bazy danych, dostarcza podstawowe funkcjonalności CRUD (Create, Read, Update, Delete utwórz, odczytaj, aktualizuj, usuń), zaawansowane możliwości wyszukiwania i zdolności do wiązania 90

91 modeli. Do budowy aplikacji Taskzilla zdecydowaliśmy się wykorzystać wolnodostępną, relacyjną bazę danych MySQL, ponieważ znana jest i ceniona ze względu na swoją wydajność oraz szybkość działania. Dyspozytor Dyspozytor to dodatkowy moduł, którego praca polega na łączeniu nadchodzących żądań HTTP z kodem odpowiedniego kontrolera oraz wywołaniu wskazanej przez adres URL akcji. Odpowiada on również za rozprowadzanie ruchu między kontrolerami oraz za poprawne przekazywanie danych, które zostały wysłane przez użytkownika. Przetwarzanie żądania HTTP Analizując przetwarzanie żądania HTTP, które przychodzi do aplikacji Taskzilla można zauważyć, jak poszczególne elementy architektury współpracują ze sobą. Proces ten rozbija się na następujące etapy: 1. Klient (przeglądarka internetowa) wysyła żądanie do serwera, na którym znajduje się aplikacja. 2. Serwer przekazuje żądanie do dyspozytora, który decyduje, jakiego typu kontrolera użyć oraz którą akcję tego kontrolera wykorzystać do obsługi żądania. Następnie wywołuje tę akcję, przekazując jej parametry żądania. 3. Akcja kontrolera pobiera parametry żądania i w oparciu o nie wykonuje swoją logikę, sprowadzającą się zazwyczaj do pobrania odpowiednich obiektów z warstwy modelu. 4. Po przygotowaniu odpowiednich danych generowana jest odpowiedź (obiekty konwertowane są do formatu tekstowego). 5. Odpowiedź zostaje przekazana do klienta (aplikacji wykonanej w technologii Flex osadzonej na stronie HTML) pod postacią znaczników XML Integracja Flexa z RoR Jak już wspomnieliśmy wyżej, Adobe Flex zapewnia rozbudowane możliwości tworzenia aplikacji RIA. Są to aplikacje wykonywane po stronie klienta, więc w celu stworzenia w pełni funkcjonalnego systemu konieczne jest zapewnienie odpowiedniego kanału komunikacyjnego 91

92 pozwalającego na wymianę informacji pomiędzy klientem i serwerem. Poniżej przedstawimy dwie najpopularniejsze metody pozwalające na komunikację Flexa z RoR [26]: HTTPServices (format tekstowy), RemoteObject (format binarny). HTTPServices Najczęściej używanym rozwiązaniem, stosowanym również przez aplikację Taskzilla, jest wymiana danych w tekstowym formacie XML za pośrednictwem protokołu HTTP. Flex, dzięki standardowej klasie HTTPServices, może poprzez dokładnie zdefiniowane adresy URL odwoływać się bezpośrednio do kontrolerów RoR. Kontrolery, dzięki rozbudowanej palecie wbudowanych metod wyświetlania danych, posiadają możliwość zwracania generowanej odpowiedzi w formacie XML. RemoteObject Drugim sposobem zapewnienia komunikacji pomiędzy technologią Flex i RoR jest użycie formatu AMF oraz zdalnych obiektów Flexa (ang. Flex RemoteObject). AMF jest binarnym formatem służącym do serializacji obiektów ActionScript. RoR może go obsługiwać dzięki jednej z dwóch dostępnych wtyczek: RubyAMF oraz WebORB for Rails. Zdalne obiekty Flexa odwzorowywane są na odpowiadające im klasy modeli w RoR. Dzięki temu, aplikacja kliencka może odwoływać się do nich tak, jakby były dostępne lokalnie. Każde wywołanie metody na zdalnym obiekcie powoduje wysłanie żądania oraz otrzymanie binarnej odpowiedzi z serwera, która następnie konwertowana jest na macierzyste obiekty klasy ActionScript używane przez technologię Flex. Więcej informacji na temat sposobów integracji Flexa z Ruby on Rails można znaleźć w [26]. 6.5 Rejestr produktowy aplikacji Taskzilla Do określenia wymagań klienta stawianych tworzonej przez nas aplikacji Taskzilla wykorzystaliśmy opowiadania użytkownika, ponieważ są one jednym z najbardziej przystępnych, szczególnie dla klienta, narzędzi umożliwiających precyzyjne określenie jak wyobraża on sobie swój przyszły produkt. Są także charakterystyczne dla wykorzystywanej przez 92

93 nas metodologii zarządzania projektem. Wstępny rejestr produktowy razem z ustalonymi przez Właściciela Produktu priorytetami (krytyczne, wymagane, opcjonalne) przedstawia Tab Tabela 6.1. Rejest produktowy aplikacji Taskzilla. 93

94 6.6 Realizacja konkretnej iteracji W niniejszym podrozdziale przedstawimy praktyczną realizację jednego z wybranych Sprintów. Z uwagi na to, że metodologia Scrum nie narzuca programistom żadnych technik dotyczących wytwarzania oprogramowania skupimy się wyłącznie na zwinnej specyfikacji wymagań. Kluczowymi elementami zwinnego podejścia do specyfikacji wymagań, które zostały przez nas opisane poniżej są: opowiadania użytkownika, szkice ekranów, testy akceptacyjne Rejestr prac Sprintu Zgodnie z założeniami metodologii Scrum realizacja opisywanego przez nas Sprintu rozpoczęła się od spotkania planistycznego, na którym wspólnie z Właścicielem Produktu ustaliliśmy zakres prac. Z rejestru produktowego zostały wybrane opowiadania użytkownika o najwyższej dla niego wartości biznesowej. Każde opowiadanie zostało następnie dokładnie omówione oraz oszacowane wstępnie pod względem pracochłonności. Poniżej przedstawiamy rejestr prac dla Sprintu opisywanego przez nas w tym podrozdziale. Z racji tego, że opowiadania użytkownika mają reprezentować, a nie dokumentować wymagania, ich opisy nie są zbyt szczegółowe (Tab ). Nazwa Utwórz konto Opis Jako administrator chciałbym móc utworzyć konto pracownikowi dydaktycznemu, aby umożliwić mu dostęp do systemu. Po wypełnieniu wymaganych pól, system automatycznie generuje hasło oraz wysyła nowemu użytkownikowi wiadomość z danymi dostępowymi. Priorytet Krytyczne Oszacowanie (godz.) 6 Tabela 6.2. Opowiadanie użytkownika Utwórz konto. 94

95 Nazwa Zablokuj\oblokuj konto Opis Jako administrator chciałbym móc zablokować\odblokować konto pracownika, aby uniemożliwić\umożliwić mu dostęp do systemu. Po wykonaniu akcji system wysyła do użytkownika wiadomość o zmianie aktywności konta. Priorytet Wymagane Oszacowanie (godz.) 3 Tabela 6.3. Opowiadanie użytkownika Zablokuj\oblokuj konto. Nazwa Usuń konto Opis Jako administrator chciałbym móc usunąć konto pracownika, który nigdy nie prowadził żadnego kursu, aby nie figurował zbędnie w systemie. Po wykonaniu akcji system wysyła do użytkownika wiadomość o usunięciu konta. Priorytet Krytyczne Oszacowanie (godz.) 3 Tabela 6.4. Opowiadanie użytkownika Usuń konto. Nazwa Zdefiniuj semestr Opis Jako administrator chciałbym móc zdefiniować semestr, aby pracownicy mogli dodawać kursy. Priorytet Krytyczne Oszacowanie (godz.) 8 Tabela 6.5 Opowiadanie użytkownika Zdefiniuj semestr. 95

96 Nazwa Modyfikuj semestr Opis Jako administrator chciałbym móc modyfikować daty rozpoczęcia i zakończenia semestru, aby wprowadzać ewentualne zmiany. Priorytet Wymagane Oszacowanie (godz.) 3 Tabela 6.6. Opowiadanie użytkownika Modyfikuj semestr. Nazwa Usuń semestr Opis Jako administrator chciałbym móc usunąć semestr, do którego nie przypisano żadnego kursu, aby nie figurował zbędnie w systemie. Priorytet Krytyczne Oszacowanie (godz.) 5 Tabela 6.7. Opowiadanie użytkownika Usuń semestr. Po utworzeniu rejestru prac, kolejnym krokiem jest wyznaczenie celu Sprintu. Wraz z Właścicielem Produktu ustaliliśmy, że biznesową korzyścią i głównym celem będzie dostarczenie funkcjonalności, która pozwoli administratorowi systemu zarządzać zarówno pracownikami, jak i semestrami. W tym miejscu nastąpił również podział rejestru prac na poszczególne zadania. Pracochłonność każdego z nich oszacowaliśmy z dokładnością do pojedynczej roboczogodziny. Wyniki naszej pracy przedstawia Tab

97 Tabela 6.8. Rejestr prac sporządzony dla przykładowego Sprintu Szkice ekranów Po przedyskutowaniu konkretnej funkcjonalności i zatwierdzeniu jej opisu przystąpiliśmy do szkicowania związanych z nią ekranów. Najczęściej wykorzystuje się do tego celu specjalne programy, jeśli jednak nie posiadamy takiego wystarczy zwykła tablica, coś do pisania i aparat fotograficzny. Szkice ekranów nie powinny być zbyt szczegółowe. Mają jedynie zwizualizować najważniejsze elementy funkcjonalne wynikające z opowiadań użytkownika. Dają nam one pierwszą, podstawową informacje zwrotną o wyglądzie tworzonego systemu i są stosowane obecnie jako integralny element procesu zwinnej specyfikacji wymagań. Do tworzenia szkiców ekranów aplikacji Taskzilla wykorzystaliśmy aplikację Balsamiq Mockups firmy Balsamiq Studio LLC [39], która umożliwia prototypownie interfejsu użytkownika zarówno aplikacji internetowych, biurowych, jak i na urządzenia przenośne. Wybraliśmy ją ponieważ jest przejrzysta i pozwala na szybką pracę metodą przeciągania i upuszczania odpowiednich elementów interfejsu. Dzięki temu możemy tworzyć prototypy ekranów już podczas rozmowy z klientem, unikając późniejszych nieporozumień dając mu poczucie wpływu na kształtowanie produktu. W efekcie otrzymujemy wstępny obraz naszego projektu. Przykład szkicu ekranu dla opowiadania - Utwórz konto - przedstawia Rys

98 Rysunek 6.2. Szkic ekranu związany z opowiadaniem użytkownika - Utwórz konto Testy akceptacyjne Na początku każdej iteracji wybieramy opowiadania użytkownika, które będą implementowane w ramach danej iteracji. Przy ich wyborze, z jednej strony kierujemy się wartością biznesową, z drugiej zaś, oszacowanym kosztem realizacji. Następnie, zespół wraz z klientem ustala dla każdego opowiadania szczegóły implementacji w formie testów akceptacyjnych. Takie podejście prowadzi do lepszego zrozumienia funkcji, które mają być zrealizowane przez system oraz odkrycia ewentualnych szczegółów, które nie zostały jeszcze ustalone. Specyfikowane testy akceptacyjne pozwalają zidentyfikować wszystkie niejawne założenia i oczekiwania poczynione zarówno przez klienta jak i zespół projektowy. Dodatkowo, w późniejszej fazie projektu są one formą sprawdzenia czy wymagania (opowiadania użytkownika) zostały zaimplementowane przez zespół tak, jak spodziewał się tego klient. Podczas tworzenia testów akceptacyjnych należy zwrócić szczególną uwagę na to, co programiści powinni jeszcze wiedzieć o danym opowiadaniu, jakie założenia można przyjąć w jego kontekście oraz czy są jakieś okoliczności, w których opisywana funkcjonalność powinna 98