Szybkie prototypowanie (ang. rapid prototyping) aplikacji Flex nie jest sprawą oczywistą. Szybkie prototypowanie to w skrócie automatyczna generacja prototypu, czyli działającej aplikacji w wersji beta (wersję beta aplikacji rozumiem tu w kontekście terminologii USDP – gdzie oznacza ona wersję mniej zaawansowaną (wcześniejszą) od wersji alfa, która w powszechnej terminologii oznacza wersją prerelease). Słowo AUTOMATYCZNA generacja, samo AUTOMATYCZNA to kwestia decydująca o nietrywialności procesu zorientowanego na szybkie prototypowanie. Właśnie tu pojawia się pytanie, jak znaleźć sposób na automatyczną generację aplikacji Flex z jej modelu (aplikację Flex/multimedialną w tym kontekście należy rozumieć/definiować jako system czasu rzeczywistego)? Tak, tu jest pole do popisu – jak przykładowo z diagramów UML przejść w sposób automatyczny do kompilowanego kodu źródłowego? (w sumie na to pytanie starałem się odpowiedzieć w swoich pracach naukowych, gdzie zaprezentowałem pewien sposób transformacji model – kod, ale mniejsza z tym). No, nie jest to takie proste … a z pewnością jest niezmiernie istotne dla skrócenia procesu wytwórczego RIA oraz możliwie najefektywniejszego ich wytwarzania.

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 …