Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA oferuje do modelowania budowanych systemów 10 z pośród 13 diagramów języka UML 2.0. Diagramy, których nie można zbudować w RSA to diagram obiektów (ang. Object Diagram), diagram widoku interakcji (ang. Interaction Overview Diagram), diagram przebiegów czasowych (ang. Timing Diagram).

RSA jest nowoczesnym rozwiązaniem wspierającym podejście Model Driven-Development, które ukierunkowane jest na modele. Z racji tego podczas analizy i projektowania systemów za pomocą RSA duży nacisk kładziony jest na architekturę systemu (co zostało opisane w innym tekście). Ponadto RSA wspiera użytkownika szeregiem widoków. Do najważniejszych z nich należą Model Explorer stanowiący repozytorium modeli projektu oraz widoki diagramów wraz z paletami elementów jakie mogą być zastosowane na diagramach.

Rysunek 1. Modelowanie w RSA

Ważną cecha RSA jest możliwość budowania systemów informatycznych od wymagań na system po jego implementację. Już od modelu przypadków użycia, które stanowi wizualny obraz wymagań funkcjonalnych. Pozawala na, zamieszczenie w dokumentacji diagramu takich elementów jak funkcjonalność jaką reprezentuje przypadek użycia, aktorów, którzy korzystają (otrzymują kwant funkcjonalności) z danego przypadku użycia. Ważne jest także opisanie scenariuszy: głównego i alternatywnych, jakie są realizowane przez przypadek użycia. Dodatkowo w dokumentacji przypadka użycia można zamieścić opis warunków początkowych przypadku użycia oraz podać nazwy związków rozszerzenie i zawierania. Zgromadzenia w jednym miejscu tych informacji ma na celu lepsze i dokładniejsze zrozumienia funkcji jaka pełni w systemie dany przypadek użycia oraz ukierunkowuje projektanta systemu na jego dalsze postępowanie w kolejnych fazach projektu.

Istotnym faktem jest to, że stosowanie RSA wspomaga projektantów systemu nie tylko w trakcie projektu ale umożliwia także przechowywanie w jednolitym repozytorium wymagania na system


Rysunek 2. Integracja z RequisitePro

Rational Software Architect integruje się z RequisitePro, które jest narzędziem wyspecjalizowanym w przechowywaniu i zarządzaniu wymaganiami na system. W RSA można w oddzielnym oknie mieć przez cały czas dostęp do wymagań systemu. Nowością w tego typu rozwiązaniach (również dla firmy IBM) jest stosowanie techniki ?przeciagnij&upuść? (ang. ?drop&down). Czynność taka skutkuje automatycznym połączeniem zależnością trace elementu z modelu RSA z wybranym elementem co jest zaznaczone w Eksploratorze RequisitePro oraz w widoku Requirements View (rysunek 3)


Rysunek 3. Zarządzanie wymaganiami w RequistePro

Na końcu należy wspomnieć o dość ważnym widoku jakim jest UML Model Editor (rysunek 4). Zawiera on najważniejsze informacje o modelu takie jak: specyfikacja diagramów, opis modelu i jego profil


Rysunek 4. UML Model Editor

Transformacje

Rational Software Architect, poza możliwością budowania projektów w języku UML lub tworzenia aplikacji, pozwala na transformacje artefaktów. Te transformacje to przede wszystkim generowanie szkieletu kodu systemu za pomocą inżynierii wprzód oraz tworzenie na podstawie kodu aplikacji równoważnej mu specyfikacji wyrażonej w języku UML.


Rysunek 5. Inżynieria do przodu

Zaprezentowane na rys 5 przejście z modelu UML do kodu źródłowego pozwala na wygenerowanie z elementów języka UML szkielet aplikacji co zaprezentowano na kolejnym rysunku.


Rysunek 6. Szkielet kodu wygenerowany na podstawie klasy UML

RUP w Rational Software Architect

Bardzo istotnym elementem Rational Software Architect?a jest zintegrowanie tego środowiska z Rational Unified Process. RUP jest uruchamiany w widoku Process Advisior. RSA oferuje w tym względzie pomoc kontekstową a sam proces jest dostosowany do potrzeb środowiska Eclipse oraz posiada uaktualnień o język UML 2.0 oraz SOA. Zastosowanie dobrych praktyk i zaleceń RUP pozwoli Ci na lepsze budowanie rozwiązań informatycznych.


Rysunek 7. Pomocna dłoń RUP

Raporty

Kolejną przydatną funkcją jaką oferuje RSA jest raportowanie, które wspomaga dokumentację procesu wytwórczego systemu. RSA oferuje dwa rodzaje raportów. Pierwszy z nich jest raportem uproszczonym (bez diagramów) a drugi szczegółowym, gdzie poza specyfikacją elementów modelu znajdują sie wszystkie zbudowane diagramy. Raporty w RSA zapisywane są w postaci dokumentów *.pdf i generowane mogą być w każdym momencie procesu wytwórczego.


Rysunek 8. Raporty w RSA

W razie trudności

Ostatnim elementem, który przedstawiono jest moduł pomocy (zakładka help).

Rysunek 9. System pomocy w RSA

Jest to bardzo rozbudowane narzędzie zawierające takie elementy jak ogólne informacje o RSA. W dziale nowości (What?s New) można znaleźć artykuły o najnowszych trendach w dziadzienie inżynierii oprogramowania. Kolejny element to dział z przewodnikami (Tutorials), w którym krok po kroku wskazano jak zbudować wybrane elementy rozwiązań informatycznych. Tutoriale odnoszą się od modelowania UML poprzez budową prostych aplikacji po całe portale. W dziale Przykładów (Samples) zamieszczono przykłady już gotowych rozwiązań. Dla początkujących istotny będzie dział First Steps, w którym zaprezentowano jak korzystać z istniejącego już projektu lub jak uruchomić nowy projekt. Ostatnim przyciskiem jest odnośnik do zasobów umieszczonych w sieci Internet.

Wydaje się, że moduł pomocy ze względu na swoją obszerność będzie przydatny nie tylko dla początkujących ale także średniozaawansowanych użytkowników RSA.

Podsumowanie

Jak można zauważyć RSA to prawdziwy kombajn do produkcji oprogramowania. W Artykule tym ograniczono się do prezentacji najważniejszych jego elementów jakimi są:

  • budowa modeli w języku UML,
  • pakiety wielokrotnego użycia RAS,
  • zaawansowany system pomocy,
  • Process Advisior,
  • projektowanie implementacja w zintegrowanym środowisku programistycznym,
  • zaawansowane metody inżynierii do przodu

Zakres możliwości RSA sprawia, ze narzędzie to może być wielce przydatne przy produkcji dużych systemów informatycznych. Czy będzie przydatne dla przeciętnego dewelopera, który buduje małe projekty. Zapewne tak, tylko czy warto z armaty strzelać do much?


Artykuł napisano w 2005 roku. Od tego czasu wiedza i narzędzia mogły ulec zmianie. 🙂

Technorati Tagi: Rational Software Architect,inżynieria oporgramowania,UML,modelowanie systemów informatycznych

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close