Metodologia CASE

Przyczyny użycia narzędzi CASE Główną przesłanką użycia narzędzi CASE jest zwiększenie produktywności i jakości produkowanych systemów. Podnoszenie produktywności i jakości projektowanych systemów z wykorzystaniem narzędzia CASE odbywa się poprzez: Wspomaganie standardowych metod i działań projektowych – proces projektowania jest bardziej zintegrowany. Ulepszenie komunikacji między użytkownikami a specjalistami (projektantami) – duże zespoły i projekty są efektywnie koordynowane. Organizowanie i korelowanie komponentów projektu oraz zapewnienie szybkiego do nich dostępu poprzez bazę danych projektowych. Automatyzowanie nudnych i błędotwórczych kroków analizy, projektowania i programowania. Automatyzowanie testowania i kontroli. Integrowanie środowiska wytwarzania systemu ze środowiskiem eksploatacji.

Przyczyny stosowania CASE Większość organizacji stosuje narzędzia CASE aby: –Zwiększyć jakość projektowanych systemów. –Zwiększyć szybkość projektowania i konstrukcji systemów. –Ułatwić i ulepszyć proces testowania dzięki automatycznemu sprawdzaniu. –Zwiększyć integrację działań projektowych przez stosowanie jednolitego podejścia metodologicznego. –Zwiększyć jakość i kompletność dokumentacji. –Pomóc w standaryzacji procesu projektowania. –Ulepszyć zarządzanie projektami. –Uprościć utrzymywanie (pielęgnację) oprogramowania. –Ułatwić i promować ponowne użycie komponentów systemu i dokumentacji. –Zwiększyć możliwość zastosowania oprogramowania w różnych branżach.

Bariery stosowania CASE Wysoki koszt narzędzi CASE. Wysokie koszty szkolenia pracowników. Brak wiary ze strony pracowników (organizacji) w możliwość szybkiego (i w ramach istniejącego budżetu) wdrożenia wysoce specjalistycznej technologii. Postrzeganie CASE jako zagrożenia dla bezpieczeństwa pracy. Brak zaufania do narzędzi CASE (przekonanie o wyższości własnych umiejętności). Brak standardów metodologicznych wewnątrz organizacji.

Uwarunkowania rozwoju CASE Wcześniej czas powstawania systemów był dłuższy; dominowała metoda kaskadowego prowadzenia projektów, w wyniku czego dopiero po kilku miesiącach analizy definiowano wymagania dotyczące projektu. Ten system nie ułatwiał wprowadzania zmian w trakcie trwania kolejnych etapów, lecz wymagał kolejnych iteracji. Systemy wykonywane były w jednej wybranej na początku technologii, co wymagało dokonania, na wstępie, wyboru języka programowania, środowiska systemowego oraz bazy danych z którą system miał działać. Dostawca systemu nabywał przeważnie całe środowisko tworzenia systemu u jednego dostawcy, co dawało większe szanse na powodzenie projektu oraz bezproblemową współpracę narzędzi.

Uwarunkowania rozwoju CASE Obecnie systemy wykonywane są w kilku technologiach. Zdarza się często, że część aplikacji działa jako gruby klient, inna stworzona jest w technologii J2EE, kolejne w technologii.Net, całość zaś współpracuje z wieloma motorami baz danych. Sytuacja ta uwarunkowana jest koniecznością integracji tworzonych systemów z już istniejącą infrastrukturą informatyczną. W takich przypadkach wymaga się od narzędzi typu CASE znacznie więcej. Ponadto czas realizacji systemów uległ znacznemu skróceniu, co wynika z pojawienia się języka Java i nowych metod programowania typu XP(Extreme Programming).

CASE - oczekiwania Generowanie kodu Reverse engineering’u (rewersowania, czyli odtwarzania elementów projektowych na podstawie istniejącej aplikacji lub bazy danych) Wsparcia dla zmiany modelu na różnych poziomach abstrakcji (od analizy do kodu) Sprawdzania poprawności modeli Synchronizacji modeli z tworzonym kodem Wsparcia dla różnych języków programowania, motorów baz danych Generowania dokumentacji

Podstawowe ograniczenia stosowania CASE Większość współczesnych metodologii zakłada stosowanie technologii CASE w pełnym cyklu życia systemu, we wszystkich możliwych aspektach. Jednak pełne metodyczne wykorzystanie wspomagania komputerowego jest warunkowane wieloma czynnikami. Wśród podstawowych ograniczeń kompleksowego stosowania narzędzi CASE można wyróżnić: –Ograniczenia metodologiczne wynikające ze specyfiki procesów projektowania, w których zawsze występują procesy twórcze mało podatne na automatyzację, wspomaganie komputerowe. –Ograniczenia ekonomiczne sprowadzające się do tego, że nakłady na wspomaganie komputerowe (zakup sprzętu i oprogramowania, nakłady na szkolenia w zakresie projektowania wspomaganego) powinny się mieścić w wielkości uzyskiwanych efektów. –Ograniczenia sprzętowo-programowe polegające na tym, że systemy wspomagania wymagają dużych zasobów komputera, różnorodnych urządzeń zewnętrznych, języków komunikowania się z komputerem, odpowiedniego, otwartego oprogramowania (aspekt ten stopniowo traci na znaczeniu w dobie coraz tańszych systemów mikrokomputerowych, nowoczesnych metod obiektowych programowania czy graficznego interfejsu użytkownika). –Ograniczenia socjologiczno-psychologiczne związane z trudnościami w przyswojeniu dużych zasobów wiedzy i umiejętności z zakresu analizy i projektowania, stosowaniu zasad metodycznego postępowania, konsekwencji w modelowaniu.

Rozwój CASE Zastosowania CASE wciąż się rozwijają, gdyż technologia ta może automatyzować wiele „ręcznych” czynności w procesie projektowania, zachęcać do standaryzacji na podstawie określonej metody, promować większą spójność i koordynację w czasie projektu oraz generować duże fragmenty dokumentacji. Narzędzia CASE nie zapewniają jednak automatycznego wygenerowania odpowiedniego (funkcjonalnego) systemu (zły system można równie łatwo zaprojektować i wykonać narzędziami CASE, jak i bez nich). Również niemożliwe jest radykalne przekształcenie procesów analizy i projektowania (zwłaszcza działań twórczych) oraz zmuszanie projektanta do ścisłego przestrzegania zasad wybranej metody. Oznacza to, że narzędzia CASE wspomagają wytwarzanie systemów informatycznych, automatyzują pewne czynności w cyklu życia systemu, natomiast nie zastępują (nie eliminują) działań twórczych człowieka. Czołowi producenci narzędzi CASE oprócz samych narzędzi proponują również własne podejścia do budowy systemów – z użyciem tych narzędzi i własnych metodyk. Firma Rational proponuje Rational Unifield Process (RUP), który jest wzorcem iteracyjnego procesu wytwarzania i utrzymania systemu, bazującym na modelowaniu z wykorzystaniem języka UML.

Metodyka RUP Wyróżnione w metodyce RUP dziewięć (modelowanie danych przedsiębiorstwa, rozpoznawanie wymagań, analiza i projektowanie, implementacja, testowanie, wdrażanie, zarządzanie konfiguracją, zarządzanie przedsięwzięciem oraz zarządzanie środowiskiem) czteroetapowych (rozpoczęcie, opracowanie, konstrukcja i przekazanie) procesów iteracyjnych jest wspomaganych przez zestaw kilkunastu narzędzi, gwarantujących realizację systemu w zintegrowanym środowisku.

Metodyki „miękkie” Przy wykorzystaniu „miękkich” (Agile Modeling) metodologii prace nad systemem mogą być prowadzone równolegle w wielu warstwach projektu, przestaje rozróżniać się poszczególne jego etapy (analiza, projekt, programowanie). W tym przypadku wprowadzanie zmian do projektu może odbywać się na dowolnym etapie. W sytuacji, gdy już funkcjonuje zaprojektowana struktura bazy danych, podczas realizacji w którymś z języków obiektowych okazuje się, że brakuje kilku atrybutów klasy; programista nie musi konsultować takich zmian z analitykiem – wprowadza je do definicji klasy, a następnie zapisuje zmiany w kodzie systemu. Dopiero potem analityk synchronizuje kod i aprobuje zmiany w modelu bądź logicznym, bądź struktury bazy danych.