Chodziło o to, aby na podstawie badań empirycznych sprawdzić, czy prototypowanie z zastosowaniem UML (z profilem RT) + metod formalnych (do formalnego wsparcia semantyki UML) w RIA (swoiste MDE, z ukierunkowaniem na RAD) może przynieść wymierne korzyści. Do tego celu posłużyłem się modelem COCOMO II.2000 (Constructive Cost Model) + Nelsen dla estymacji przewidywanych kosztów, oraz rozkładem Rayleigh’a (plus „wagi” Pressman’a) dla oszacowania gęstości występowania defektów w poszczególnych fazach projektu, a w konsekwencji kosztu usunięcia defektów w danej fazie produkcyjnej. Nie będę tu prezentował lekko rozbudowanych wzorów, które były podstawą do przeprowadzenia badań, a następnie odniesienia rezultatów do świata rzeczywistego (zresztą niedługo pojawi się pewna publikacja w tym względzie, to może pochwale się linkiem ;)).

Jakby nie było biorąc pod uwagę osiągnięte rezultaty mogę stwierdzić, że stosowanie formalnych metod prototypowania RIA średniej wielkości może zmniejszyć o około 43% koszt usunięcia błędów – jest to niebagatelna wartość, biorąc pod uwagę, że szacuje się, że koszt usunięcia błędów w fazie implementacji, jest średnio około 10 razy większy niż usunięcie danego błędu w fazie projektowania (w tym w procesie modelowania). Biorąc pod uwagę fakt, że stosowanie takich metod wydłuża fazy projektowania, skompensowany zysk to około 23% mniej kosztów, co też nie jest małą wartością. Zatem zainteresowanie się prototypowaniem RIA oraz stosowaniem metod formalnych w ich procesie wytwórczym wydaje się niegłupie … polecam.

Inna sprawa jak widać COCOMO może mieć wiele postaci, niesamowita zbieżność nazw z Adobe Cocomo ;)

Tadeusz Chełkowski – RIA w biznesie – LiveCycle Process Management
RIA Day 2008 – 27.11.2008 Wrocław

Proces produkcyjny RIA (i wszelkich innych aplikacji) standardowo zawiera m.in. fazę analizy, która powinna kończyć się m.in. modelem aplikacji, który powinien możliwie najdokładniej odzwierciedlać wymagania/aspekty statyczne i behawioralne (charakterystykę) projektowanego systemu.

Aplikację Flex można zaprojektować używając do tego celu m.in. języka UML. Aby możliwie najdokładniej opisać aspekty behawioralne aplikacji dodatkowo należy użyć rozszerzenia RT UML (w tej chwili trwają też prace nad MARTE (UML Profile for Modeling and Analysis of Real-time and Embedded Systems ), który jest rozwinięciem kwestii poruszonych w profilu RT UML i ma za zadanie w przyszłości go zastąpić). W sumie jestem współautorem rozszerzenia języka UML o diagramy i mechanizmy, które pozwalają opisać dokładniej aplikację multimedialną/RIA (jest to m.in. wprowadzenie nowego typu diagramu do UML tj. diagramu prezentacji, czy rozszerzenie meta modelu języka RT UML o zbiór zdarzeń synchronizujących się, który pozwala na wyrażanie ograniczeń czasowych na diagramach sekwencji oraz aktywności, w celu ich późniejszej weryfikacji (niesprzeczność ograniczeń itd.) przy automatycznym przejściu z modelu do kodu) i muszę przyznać, że UML dosyć dobrze (po zaaplikowaniu pewnych profili) radzi sobie z modelowaniem RIA.

Piszę o tym wszystkim, ponieważ na wyżej przedstawionym tle (problematyce) widać jak ważne w kontekście automatyzacji pewnej części procesu produkcyjnego oraz po części prototypowania RIA jest Adobe Thermo, który powinien pojawić się w niedługim czasie. Otóż Thermo będzie pozwalał na możliwie wczesnym stadium projektu zaprezentować klientowi nie tylko wygląd, ale i planowany behawioryzm tworzonej aplikacji Flex. Ma to szczególnie duże znaczenie w przypadku adaptowalnej realizacji projektów RIA, gdzie zakłada się jak najwcześniejszą i możliwie najczęstszą prezentację prototypu klientowi.

Poniżej wklejam zrzuty ekranu Adobe Thermo, którego wczesna wersja beta ma zostać zaprezentowana na Adobe MAX 2008. Obrazy te zostały opublikowane w ostatnim czasie przez Adobe, jak mniemam celem przypomnienia nam wszystkim, że Thermo i prace nad nim nie umarły.

Na Adobe Thermo czekają nie tylko analitycy/projektanci RIA w oparciu o technologię Flex, ale i specjaliści użyteczności RIA, ponieważ Thermo pozwoli im przebadać “na użytkownikach” nie tylko statyczny projekt aplikacji RIA, ale i jej behawioryzm w możliwie najwcześniejszej fazie projektu. No nic, to czekamy na Thermo …

Każdy proces jest uporządkowanym zbiorem faz oraz artefaktów. Fazy mogą być realizowane w sposób kaskadowy (ang. waterfall model), bądź równoległy. W jednym z poprzednich postów wspominałem o metodykach lekkich jak XP (eXtreame Programming). Bardzo dobrą metodyką lekką, która sprawdza się w kontekście adaptowalnego prowadzenia przedsięwzięć RIA, jest SCRUM, jako, że jej stosowanie wymusza m.in. spotkania zespołu pomiędzy kolejnymi fazami/iteracjami procesu, które pozwalają na kontrolowane rozbudowywanie/korygowanie zakresu projektu od strony funkcjonalnej razem z klientem. Porównując chociażby Flex’a z Flash’em, należy stwierdzić, że Flex to takie małe błogosławieństwo dla stosowania procesu adaptowalnego w kontekście wytwarzania RIA (czy nawet w kontekście stosowania programowania parami (ang. pair programming) w RIA). Flex, jako technologia oraz środowisko wytwórcze, pozwala chociażby na zrównoleglenie poszczególnych faz, na dostarczanie szybkich prototypów oraz artefaktów funkcjonalnych do klienta, nie zaburzając przy tym architektury aplikacji oraz płynności samego procesu produkcyjnego. Jego zorientowanie na warstwę prezentacji wymaga chociażby zainteresowania się tematyką UCD (ang. User-Centered Design, usabilty, itd…) oraz włączenia ideii UCD choćby w szczątkowej postaci do procesu produkcyjnego.

Jak stosowanie procesu adaptowalnego, UCD oraz SCRUM, jako „jedność” wygląda w praktyce? No, na pewno wszystkiego tutaj nie opiszę (po szczegóły ad. procesów adaptowalnych zapraszam m.in. do sięgnięcia do publikacji m.in. mojego autorstwa – link tu, i tu ), jako że temat jest dosyć obszerny. Niemniej jednak chcąc wszystko przedstawić w sposób bardzo zwięzły na potrzeby tego wpisu w skrócie wygląda to tak. Zamiast WBS stosuje się FBS (ang.  Functional (czasami mówi się Features) Breakdown Structure), który jest drzewiastą reprezentacją modułów, obszarów funkcjonalnych oraz funkcjonalności projektów wraz z wagami realizacyjnymi (priorytety) określonymi przez klienta (czasami, choć rzadko przed stworzeniem FBS’a stosuje się badania fokusowe, aby „wybadać”, czego przyszli użytkownicy (z grupy docelowej) mogą pożądać w aplikacji, od strony funkcjonalności). Na bazie FBS’a tworzone są scenariusze odpowiadające realizacji danych funkcjonalności (np. w postaci diagramów aktywności UML’a) – opisy stanów oraz tranzycji (przejść) między nimi, które następnie są upraszczane (redukowane) w kontekście możliwości Flex’a. Następnym krokiem jest szukanie możliwych kolaboracji danych stanów pochodzących ze scenariuszy odrębnych funkcjonalności, tak, aby zbudować model interakcji pomiędzy odpowiednimi obszarami funkcjonalnymi projektu. Na bazie wszystkiego co powyżej, tworzy się makiety oraz prototypy, które są poddawane testom z użytkownikami (ang. user-tests). Ważne jest to, że przed kreacją makiet jasno określa się interfejsy pomiędzy warstwą prezentacji, a logiką biznesową, tak, aby faza implementacji (logiki biznesowej) mogła zacząć się równolegle z wytwarzaniem GUI. Faza wdrożenia, to iteracyjna i równoległa realizacja połączonych faz projektowania oraz implementacji, – czyli po prostu stosowanie podejścia adaptowalnego w kontekście SCRUM, które skutkuje dostarczaniem kolejnych funkcjonalności systemu przy współpracy z klientem oraz w kolejności, które określają wcześniej zdefiniowane priorytety realizacyjne. Tak to w DUŻYM skrócie wygląda.

Jakby nie było metodologie ad. projektów adaptowalnych to jak dla mnie przyszłość w realizacji złożonych projektów RIA, dodatkowo bardzo dobrze „radzą sobie” z pracą zdalną (ang. telecommuting), dlatego jestem dosyć mocno zaangażowany w ich promocję oraz precyzowanie (Adam pracujący w SAP’ie testował je od strony wdrażania aplikacji programowych, natomiast ja od strony aplikacji multimedialnych (systemów czasu rzeczywistego) – i razem stwierdzamy, że proces adaptowalny daje radę oraz przynosi wymierne rezultaty w stosunku do podejścia konwencjonalnego). Jako, że temat jest z pogranicza zarządzania projektami i technologii Flex, nie chcę już Was więcej zanudzać ;)

Na zdrowy rozsądek, narzędzie mające zautomatyzować i nadzorować powyższe kwestie powinno dysponować jakimś standardem opisu zależności pomiędzy poszczególnymi modułami, który krótko mówiąc opisywałby budowę aplikacji, a także szereg innych informacji dotyczących m.in. konfiguracji środowisk wytwórczych, generowania raportów, czy opisu zespołu projektowego wraz z referencją do zdefiniowanych wcześniej artefaktów, za które odpowiedzialni są poszczególni członkowie zespołu.

Narzędziem, które pozwala to zrobić jest Apache Maven, natomiast standardem dokumentu zawierającym definicje między innymi wymienionych wyżej aspektów jest POM – Project Object Model (który jasna sprawa bazuje na języku XML). Niestety ciężko by było w tym poście opisać poszczególne tagi niezbędne do tego, aby stworzyć POM – dlatego odsyłam do tego linku po specyfikację wraz z przykładami.

Jednak przed tym jak zaczniemy definiować POM’y musimy zainstalować plugin Maven’a do Flex SDK 2.0 (przyznam się, ze plugina z SDK 3 jeszcze nie używałem, nie wiem, czy da radę). Jakby nie było, plugin ten, nie jest może zbyt rozbudowany, niemniej jednak oferuje cztery bardzo przydatne dyrektywy (czynności) [ flex2:asdoc, flex2:compile-swc, flex2:copy-flex-applications, flex2:compile-swf], których nazwy mówią same za siebie i o których można sobie więcej poczytać tu. Przykłady użycia są tu. Jeżeli natomiast w swoich projektach używasz webserviceów WSDL’a polecam wsdl2as plugin, jest tam też plugin pod Maven’a – niezmiernie ułatwiająca życie sprawa.

Maven rządzi i jak dla mnie to teraźniejszość i przyszłość, z pewnością więc warto zapoznać się z nim w kontekście tworzenia rozbudowanych aplikacji Flex’owych.

Więcej o używaniu Mercury do testów:

http://download.macromedia.com/pub/documentation/en/flex/2/flex2_testing_with_mercury_qtp.pdf

http://flex.org/ACDS/AutomatedTestingInFlex.pdf

Jak wystartować z Flex Builder 3:

http://labs.adobe.com/wiki/index.php/Flex_3:Release_Notes#Requirements_for_Using_the_QTP_Plug-in

Pomysł na TDD, pojawił się niedługo po ukłuciu i rozpowszechnieniu się terminu XP (ang. eXtreme Programing), jednej z bardziej popularnych metodyk lekkich (inaczej zwanych zwinnymi ang. agile) wytwarzania oprogramowania, które kładą nacisk na dostarczanie klientowi artefaktów programowych, zamiast papierowych tj. dokumentacji – która w XP ma formę szczątkową w porównaniu m.in. do RUP (ang. Rational Unified Process), który czerpie korzenie z USDP (ang. Unified Software Development Process)) i jest reprezentantem metodyk ciężkich. XP jako uznana metodyka zwinna, zaczeła permanentnie dążyc do skracania faz produkcyjnych i tak m.in. powstał pomysł na to, aby zautomatyzowac testowanie poprzez wprowadzenie testów jednostkowych (nazwa bierze się z testowania danej jednostki, jaka jest metoda (funkcja) lub klasa) oraz przeniesienie fazy testowania na poczatek fazy implementacji, a docelowo zmusić programistę, aby pisał przypadki testowe przed napisaniem właściwego kodu aplikacji programowej, pisać na początku, co kod ma zrobić, a nie jak coś ma być zrobione. W porównaniu do tradycyjnego procesu wytwarzania oprogramowania, w którym testy (czy to weryfikacyjne, walidacyjne, wydajnościowe, czy to ilościowe) sa przeprowadzane za zwyczaj w koncowych fazach procesu wytwarzania oprogramowania, była to koncepcja nadzwyczaj rewolucyjna (nawet jak na poczatki XXI wieku ). Z ”marketingowego” punktu widzenia, wydawalo sie od razu, ze programisci będą mieć wiekszy zapał aby pisać testy na początku fazy wdrożenia, niż w kolejnych fazach (przecież na zdrowy rozsądek każdy z nas jak podchodzi do projektu ma najwięcej zaangażowania na początku prac, najmniej na żmudnym końcu, kiedy należy poprawiac i poprawiac, i nie zawsze wiadomo, gdzie się popełniło błąd ), a kod tworzony wedle ścisłych reguł umożliwiajacych automatyzację testowania oraz przypadków testowych będzie łatwiejszy w pielęgnacji i rozbudowie.

Nie ma co się oszukiwać, TDD sprawdza się dobrze przede wszystkim w duzych projektach, dotyczy to takze Flex’a, w małych m.in. programiści nie rozumieją po co mają pisać “nadmiarowy kod” testujący coś, co po prostu “musi działać”  - jednym slowem stosowanie TDD w malych projektach bardziej prowadzi do frustracji niż jest pomocne. Ale przecież to m.in. za sprawa Flex’a – technologia Flash wchodzi pod strzechy rozwiazań korporacyjnych, gdzie takowe metodyki się sprawdzają. Kod testuje siebie, o to własnie chodzi, i dlatego też powstał FlexUnit , czy ASUnit. Obecna wersja np. FlexUnit, czyli 0.85 jeżeli chodzi o stosowanie metodyki TDD sprawdza się bardzo dobrze, tym bardziej jezlei ktos stosowal JUnita (Java) w Eclipsie, nie bedzie mial za duzo problemow z przesiadka ;)

Chcąc zabrać się za TDD we Flex, musisz wpierw zrozumiec co to jest test jednostkowy, asercja i przypadek testowy i troche zmienic swoj tradycyjny punkt wytwarzania oprogramowania ;) – sam wiem, po sobie, ze potrzebowalem troche czasu, aby przywyknąć. Polecam artykuł Neil’a - Unit testing and Test Driven Development (TDD) for Flex and ActionScript 3.0 - zrobil na prawde dobra robote przedstawiajać to zagadnienie w dosyc zwiezly sposob, czego ja bym nie potrafił ;) Warto też zapisać się na listę dyskusyjną FlexUnit - http://groups.google.com/group/as3flexunitlib.

Przepraszam, za ten przydługi wpis, ale jedno jest pewne, mówie to z własnego doswiadczenia, jeżeli macie duży projekt RIA, spróbujcie stosować TDD, a zobaczycie, że jego siła tkwi przede wszystkim w tym, że stosujac go, o wiele łatwiej jest zlokalizować “gdzie jest problem w kodzie”.

P.S. Miałem poruszyc w tym poscie BDD (ang. Behaviour Driven Development), czyli wytwarzanie oprogramowania zorientowane na behavioryzm, które jest niejako ewolucją TDD, i osobiście uważam, że jest przyszłością. W trakcie pisania tego postu zdecydowalem, ze bym Was juz całkiem zanudził z tym BDD, stad napisze o nim w innym poscie ;) – kiedys indziej, być może pokusze się o jakis tutorial, jako, że o stosowniu BDD we Flexie na razie w sieci dosyc mało informacji.

http://www.insideria.com/2008/01/anatomy-of-an-enterprise-flex.html

http://www.insideria.com/2008/01/running-the-sample-code-last.html

http://www.insideria.com/2008/02/the-project-structure.html

http://www.insideria.com/2008/02/the-three-child-projects.html

 Jest tam wszystko co trzeba, więc szkoda tracić czasu na gadanie.