Sybase opublikował kolejną wersję swojego flagowego pakietu do modelowania aplikacji. Power Designer 12 to produkt solidny, a przy tym oferujący analitykowi bardzo dużą elastyczność.

Pakiet Sybase Power Designer 12 oferuje chyba wszystko, co zostało dotychczas wymyślone w dziedzinie modelowania aplikacji. Pozwala modelować wymagania, tworzyć modele koncepcyjne, wiązać je z fizycznym modelem danych, modelować "obiektowo", definiować procesy biznesowe w kilku językach. Unikalną funkcją Power Designer 12 jest to, że pozwala traktować proces replikacji jako element modelu. Pakiet zawiera ponadto mechanizmy do definiowania schematów XML i wiązania ich w różnych kontekstach z modelem, czy wykorzystywania tworzenia diagramów. Dzięki bardzo rozbudowanym możliwościom dostosowywania pakietu, taki "bezkontekstowy" diagram też może wygenerować pewien kod.

Fundamenty modelu

Do gromadzenia wymagań w PowerDesigner 12 w pierwszym etapie wykorzystywany jest Word; poszczególne wymagania spisywane są w hierarchii przy użyciu stylów. Następnie taki dokument importowany jest do specjalnego edytora, za pomocą którego definiowane jest odwzorowanie pomiędzy stylami a elementami w siatce wymagań.

Potem, po imporcie i korekcie, można na podstawie takiego dokumentu wygenerować raport. Podstawowa lista zawiera po prostu kolejne wymagania danego systemu. Z kolei tak zwana macierz śledzenia (traceability) określa powiązania pomiędzy wymaganiami i innymi obiektami z modelu. Po ręcznym ustawieniu takich związków można dokładnie obserwować, jakie elementy są niezbędne, by zrealizować dany punkt diagramu. Niestety, w Power Designer 12 możliwe jest jedynie określenie grup odpowiedzialnych za konkretne zadanie - nie ma bardziej rozbudowanych mechanizmów, np. do śledzenia postępu prac czy pracochłonności zadań.

Po zgromadzeniu wymagań powstaje koncepcyjny model (diagram) aplikacji (CDM). Na jego podstawie analityk tworzy diagram ERD określający związki pomiędzy encjami. Na tym etapie Power Designer 12 pozwala sprawdzić poprawność modelu - jeżeli Power Designer 12 wykrywa błąd, to można od razu przenieść się do miejsca (składnika diagramu czy opcji w modelu), w którym wadliwy element można poprawić. Można też wykonać analizy współzależności, aby wykryć, na jakie inne elementy będzie miała wpływ wprowadzona zmiana.

Na podstawie tego diagramu Power Designer 12 generuje szkielet fizycznego modelu bazy PDM, dla konkretnego motoru bazodanowego, oraz model obiektowy OOM. Projektowanie bazy danych pozwala modelować tabele, generować procedury przechowywane, gdy chcemy np. w ADO .Net wykorzystywać tzw. CRUD - bezpołączeniowy model pracy (Create, Read, Update, Delete) itp. Co ciekawsze, można generować równolegle modele dla różnych motorów bazodanowych przy zachowaniu informacji, że określone składniki realizują taki, a nie inny element modelu ERD.

Modelowanie obiektowe pozwala na wykorzystanie wszystkich mechanizmów, jakie oferuje UML 2. Można definiować diagram strukturalny, przypadki użycia czy diagram implementacji. Power Designer 12 obsługuje także tzw. dynamiczny diagram stanów, który reprezentuje przebiegi procesów w aplikacji (np. diagram sekwencji lub współpracy). Warto dodać, że na podstawie tych diagramów może również powstać w pełni działający kod.

OOM składa się tak naprawdę z dwóch części. Pierwsza to elementy związane z ogólnym modelowaniem UML, druga - z konkretnym, wybranym środowiskiem (Java, C#, VB .Net, Power Builder itp). Power Designer 12 traktuje XML jako kolejny język obiektowy i dzięki temu na podstawie diagramu może powstać schemat XSD. Na marginesie warto dodać, że częścią pakietu jest edytor schematów XML. Wersja 12 obsługuje Java 5, ale przynajmniej na razie nie obsługuje .Net 2.0 (tylko 1.1).

Power Designer 12 pozwala korzystać z metodologii MDA. Z punktu widzenia środowiska jest to realizowane za pośrednictwem specjalnej transformacji - uniwersalnego mechanizmu do przekształcania modelu. Transformacja może także, np. na podstawie definicji komponentu i modelu bazy PDM, wygenerować warstwę mapowania obiektowo-relacyjnego. Podobnie można stworzyć interfejs użytkownika. Ale transformacja jest też narzędziem do synchronizacji modeli, np. wtedy gdy mamy dwie wersje modelu koncepcyjnego i chcemy by były one w pewnym sensie "spójne", albo gdy duży system został rozbity na etapy i chcemy uaktualnić zmiany w "kolejnym" kroku.

Przepływy i procesy

Modelowanie procesów biznesowych (BPM) obejmuje dwa podstawowe typy operacji. Pierwsza z nich to analiza procesów. Dzięki zgromadzeniu ich w jednym miejscu, opisaniu i powiązaniu z systemem informatycznym można obserwować, które elementy procesów stają się zbędne, a które zyskują na znaczeniu itp. Drugi typ operacji to zarządzanie procesami (orchestration), czyli układanie "klocków" systemu IT w taki sposób, by efektywnie obsługiwały konkretny proces biznesowy.

Analiza BPM zaczyna się zwykle od stworzenia ogólnych ram typu "zakup" czy "sprzedaż".

Następnie wskazywane są zadania składające się na dany proces, które można potem układać w ciągi i wiązać z elementami modelu definiującymi warstwę techniczną. Przykładowo, macierz CRUD pozwala określić, jakie są powiązania pomiędzy procesem a danymi, np. które dokładnie informacje ulegają zmianie w wyniku jego wykonania.

Przy modelowaniu przebiegu procesów (orchestration) można wybrać, jaki konkretny dialekt ma być stosowany przy generowaniu kodu. Może to być ebXML, BPEL4WS czy też Sybase WorkSpace Business Process. Oczywiście można generować (oraz importować) definicje WSDL określające sygnatury usług Web, czy dokładnie precyzować, jak będzie formowany dany komunikat. Szczególnym przypadkiem w BPM jest generowanie niezależnego od platformy modelu kontraktu SOA lub sposobu implementacji "zobowiązania" do wykonania danej czynności. Taki model może być podstawą definiowania usług Web - które będą odpowiadać za dostęp do danej funkcjonalności.

Ciekawą koncepcją w Power Designer 12 jest mechanizm ILM (czyli Information Liquidity Model), który pozwala definiować kolejne etapy transformacji danych, gdy są one przekazywane pomiędzy różnymi systemami lub modułami aplikacji. Podstawowym zastosowaniem tego mechanizmu jest modelowanie replikacji, ale można go także wykorzystać w innych scenariuszach. Składnikiem takiego modelu mogą być serwer replikacji, baza danych (tabela czy procedura), plik XML, sposób łączenia etapów lub transformacja danych. W ten sposób replikacja stanowi naturalną część modelu (a więc i aplikacji). Jest to coś, co w innych narzędziach wymaga mniej lub bardziej karkołomnych zabiegów. Standardowo obsługiwane są Sybase Replication Server 12.x i MobiLink.

W pakiecie znajduje się też sporo pozornie drobnych ułatwień, które jednak w praktyce mogą okazać się bardzo przydatne. Można np. zapisać zbiór wskazanych "ręcznie" obiektów, a potem taki zbiór wczytać do pakietu i wykonać na nim pewne zbiorcze operacje. Elementom projektu można przypisywać synonimy i potem używać ich przy odwołaniach do danego składnika. Tych synonimów może być kilka. W stosunku do poprzednich wersji pojawiło się dużo rozszerzeń w raportach - nowy kreator ułatwia wybór danego zestawienia, można szybko (dosłownie kilkoma kliknięciami) wygenerować listę obiektów danego typu, określonych atrybutów itp. Można też tworzyć raporty składające się z wielu typów raportów podstawowych.

Ważną zaletą Power Designer 12 jest spójny mechanizm zarządzania metadanymi, który umożliwia ich współdzielenie przez wiele modeli. Opis z tabeli może być powiązany z obiektami, które wykorzystują tę tabelę. Również elementy generowane na podstawie innych zachowują połączenie do swojego przodka.