Metodologia CASE
Autor: Michał Gallina
SPIS TREŚCI
Co to jest metodologia CASE
Co to jest CASE
Projekt informatyczny
Zalety narzędzi CASE
Ogólna budowa narzędzi CASE
Metody modelowania
Modelowanie danych
Modelowanie przepływów danych
Inne metody modelowania
Krótki opis systemu Designer 2000
Przygotowywanie
Inżynieria procesów
Graficzne modelowanie i projektowanie systemów
Tworzenie aplikacji przez modelowanie
Otwarte repozytorium
Modelowanie systemów
Modelowanie procesów
Projektowanie systemów
Generowanie aplikacji
Generacja kodu serwera
Zarządzanie repozytorium
Zarządzanie projektami
ROZDZIAŁ 1
W niniejszym opracowaniu przedstawiono ogólny opis metodologii CASE. Opis ten przedstawia nowoczesne podejście do projektowania systemów informatycznych z wykorzystaniem narzędzi CASE. Opis sporządzono na podstawie systemu CASE firmy Oracle - pakiet Designer/2000.
Znaczenie słowa CASE tłumaczy się w dwojaki sposób. Pierwsze rozwinięcie tego skrótu to Computer Aided System Engineering (Komputerowe Wspomaganie Tworzenia Systemów) lub inne Computer Aided Software Engineering to oznacza Komputerowe Wspomaganie Tworzenia Oprogramowania. Trwa ciągle akademicka dyskusja, które z tych rozwinięć jest prawidłowe, proponuję jednak pozostawić tę dyskusję na boku i zapamiętać oba rozwinięcia kontrowersyjnego skrótu, który obecnie w języku informatycznym nabrał znaczenia osobnego słowa.
U podstaw powstania narzędzi CASE leży spostrzeżenie, że jeżeli dobremu programiście (koderowi) dostarczymy dobry, kompletny projekt systemu, to kodowanie staje się czynnością niemal automatyczną. Programista ogranicza się do wykorzystania swojej własnej biblioteki procedur dobrze sparametryzowanych, budując kolejne moduły systemu. W związku z tym podjęto próby powierzenia tej ostatniej czynności komputerowi, który zrobi to szybciej i bardziej bezbłędnie. Problemem stało się jedynie stworzenie systemu (programu), który będzie potrafił „programować”.
I w tym momencie dochodzimy do istoty narzędzi CASE. Jednym z takich narzędzi jest pakiet Designer 2000 firmy Oracle. Jego funkcje, możliwości i budowa zostaną opisane w dalszej części niniejszego opracowania.
W tym rozdziale opisano jak należy rozumieć projekt informatyczny w świetle koncepcji CASE. Projekt informatyczny to nie tylko projektowanie (ang. Design). Opisując metodologię CASE należy traktować projekt informatyczny jako przedsięwzięcie mające na celu informatyzację pewnego obszaru świata rzeczywistego. Taka definicja jest bardzo ogólna, ale równocześnie bardzo elastyczna. Stosując ją możemy nazwać projektem informatycznym informatyzację Urzędu Miejskiego w Poznaniu, opracowanie systemu Ewidencji Ludności, czy stworzenie oprogramowania dla centrali telefonicznej.
Każdy projekt informatyczny charakteryzuje się fazami, które następują po sobie, czasem następują powroty do faz poprzednich. Taki proces będziemy nazywali cyklem życia projektu informatycznego.
Bardzo istotne jest stwierdzenie pojawiające się w fachowej literaturze dotyczącej projektowania, że średni czas życia projektu to około 3 lata. Okres ten obejmuje zarówno powstawanie, jak i eksploatację systemu informatycznego. Po tych trzech latach należy podjąć prace nad stworzeniem nowego systemu lub istotną modernizację starego. Wynika to nie tyle ze zmieniających się realiów świata rzeczywistego modelowanego przez system, co z przyrostu informacji, rozwoju technologii informatycznej oraz rozwoju sprzętu komputerowego. Powoduje to, że nowoczesna informatyka staje się bardzo kosztowna. W Polsce takie podejście do informatyki jest ciągle jeszcze nieznane, choć w niedługim czasie stanie się powszechne.
W cyklu życia projektu możemy wyróżnić następujące fazy:
Przedstawiając te etapy na osi czasu otrzymujemy rysunek, na którym widać, że z każdego etapu istnieje pętla sprzężenia zwrotnego sięgająca do dowolnego etapu pośredniego. Istotne jest, aby pętle te były jak najrzadsze po etapie projektu technicznego. Nie należy jednak unikać ich i jeżeli jest taka potrzeba należy powtarzać prace, które są wymagane w celu zapewnienia odpowiedniej jakości produktu finalnego.
Rysunek przedstawia proporcje czasowe pomiędzy poszczególnymi etapami (wymiary poziome) i proporcje intensywności pracy zespołu projektowego w trakcie realizacji zadania (wymiary pionowe). Proporcje przedstawione na rysunku odpowiadają mniej więcej sytuacji, w której mamy możliwość stosowania narzędzi CASE.
Zastosowanie narzędzi CASE spowodowało przesunięcie proporcji pomiędzy poszczególnymi etapami. Skrócenie etapu kodowania (automatyzacja) pozwala wydłużyć etapy analizy i projektowania, przy zachowaniu tego samego czasu powstawania systemu informatycznego.
Narzędzia CASE są bardzo kosztowne, dlatego warto przedstawić korzyści płynące z ich stosowania.
1. Możliwość graficznego modelowania danych i procesów ułatwia spojrzenie na całość systemu.
2. Wszystkie narzędzia CASE są wyposażone w repozytorium, w którym można zapisać wszystkie istotne informacje związane z prowadzeniem projektu informatycznego. Informacje te są scentralizowane i dzięki temu stanowią wspaniałą dokumentację projektową, dostępną dla wszystkich członków grupy projektowej.
3. Możliwość przeglądania informacji zapisanej w repozytorium w dowolnym kontekście.
4. Zastosowanie ogólnie przyjętych standardów (ERD, DFD) ułatwia komunikację z użytkownikiem końcowym systemu na etapie analizy.
5. Istnienie generatorów kodu w znacznym stopniu przyspiesza moment, w którym możemy pokazać użytkownikowi prototyp systemu podlegający jego ocenie.
6. Proces generacji jest powtarzalny, wobec tego szybko można wprowadzać poprawki w modelu danych i w modułach.
7. Proces generacji kodu jest w zasadzie bezbłędny.
To tylko niektóre z zalet stosowania narzędzi CASE. Tak naprawdę siłę tych narzędzi poznaje się w trakcie pracy z nimi.
Do najważniejszych korzyści wynikających z zastosowania systemu CASE należy fakt, że stosując te narzędzia chcąc nie chcąc musimy stosować metodologię CASE prowadzenia projektu, bez omijania dwóch najważniejszych etapów analizy i projektowania.
W systemie CASE możemy wyróżnić dwie warstwy: górną i dolną (ang. Upper i Lower CASE). Warstwa górna służy do modelowania systemu. Warstwa dolna do przystosowania tego modelu do konkretnego zastosowania. W warstwie górnej nie jest istotne czy projektujemy bazę danych, czy algorytm optymalizacji procesu sterownia piecem do wypalania płytek ceramicznych. Warstwa dolna zależy od konkretnego narzędzia. W pakiecie Designer 2000 warstwa dolna jest wyposażona w generatory bazy danych Oracle i aplikacji pisanej w narzędziach Developer 2000.
ROZDZIAŁ 2
W tym rozdziale opisano bardzo ogólnie metody modelowania wykorzystywane przez narzędzia CASE. Do metod tych należy modelowanie danych (ERD - Entity Relationship Diagram) i modelowanie przepływów danych (DFD - Data Flow Diagram).
Każdy system w świecie rzeczywistym składa się z obiektów oraz powiązań pomiędzy nimi. Obiekty występujące w świecie rzeczywistym stanowią dane dla systemu informatycznego, które ulegają w jego wnętrzu przetworzeniu.
Definicja obiektu jest dość elastyczna, gdyż obiektem może być osoba (osoba fizyczna wraz z adresem i podstawowymi danymi), adres tej osoby także może być obiektem. Idąc dalej adres składa się z obiektów typu miejscowość, ulica, numer domu, itd... Co w takim razie jest obiektem? Proponuję wprowadzenie definicji obiektu, jako tworu posiadającego atrybuty. W sensie tej definicji ulica (nawa ulicy) czy miejscowość (nazwa miejscowości) to będą atrybuty obiektu adres lub bardziej złożonego obiektu osoba, w zależności od potrzeb analizy.
Co to jest powiązanie pomiędzy obiektami? Jest to relacja jeden do jeden, jeden do wielu, bądź wiele do wiele, która zachodzi pomiędzy dwoma obiektami różnego lub tego samego typu. Przykładowo pomiędzy małżonkami (dwa obiekty typu osoba) zachodzi relacja jeden do jeden zwana małżeństwem[1]. Jeżeli weźmiemy pod uwagę również małżeństwa archiwalne to pomiędzy dwoma obiektami typu osoba, różniącymi się wartością atrybutu płeć istnieje relacja wiele do wiele.
Zestaw symboli wchodzących w skład metody ERD jest bardzo ubogi, oto on:
Poniżej przedstawiono rysunek opisujący model danych wypożyczalni video[2].
Na rysunku przedstawiono obiekty wraz z atrybutami i relacje pomiędzy nimi. Zdefiniowano dodatkowe symbole: „#” oznacza klucz główny obiektu (odpowiednik klucza głównego tabeli bazodanowej), „*” oznacza atrybut nieopcjonalny, „o” oznacza atrybut opcjonalny, „|” na linii relacji oznacza, że wchodzi ona w skład klucza głównego obiektu, przy którym występuje (klucz główny obiektu wypożyczenie to dwie relacje do klienta i do kasety), i wreszcie „¨” oznacza, że relacja jest nietransformowalna, tzn. nie można przepiąć jej do innego obiektu (wypożyczenie można usunąć, ale nie można go przepisać do innego klienta czy kasety).
Czytając model obiektowy encji możemy stworzyć następujący opis. W centrum systemu znajdują się dwa obiekty: klient i kaseta. Klient posiada unikalny kod, kaseta unikalny numer. Dodatkowo klient może (nie musi) uzyskać rabat z jednej grupy rabatu. Kaseta musi posiadać jedną i tylko jedną cenę należącą do jakiejś grupy. Jedna cena (grupa cenowa) może (nie musi) dotyczyć wielu kaset. Podobnie jeden rabat (grupa rabatu) może przysługiwać wielu klientom. W momencie, gdy kaseta jest wypożyczana powstaje obiekt wypożyczenie, który musi dotyczyć dokładnie jednej kasety i musi być związany z dokładnie jednym klientem. Kaseta natomiast może być przedmiotem tylko jednego wypożyczenia, klient może realizować wiele wypożyczeń. Powiązanie wypożyczenia z klientem i kasetą jest kluczem głównym obiektu wypożyczenie.
Patrząc na ten model można zauważyć, że obiekt wypożyczenie stanowi relację pomiędzy kasetą a klientem (1:M.). Jednak relacja ta posiada atrybuty określające od kiedy klient wypożycza daną kasetę, do kiedy ma zamiar ją wypożyczać i kiedy ją zwrócił. Jednak w świetle definicji obiektu, jako tworu posiadającego atrybuty relacja ta staje się obiektem. Podobnie obiekt stare wypożyczenie jest relacją wiele do wiele pomiędzy kasetą i klientem i służy rejestracji wypożyczeń, których dokonał dany klient w przeszłości.
Aby opisać przykład dziedziczenia spróbujmy przeanalizować fragment schematu ERD systemu ewidencji pojazdów.
Obiekt właściciel jest nadrzędny i posiada atrybuty wspólne dla właściciela będącego osobą fizyczną i prawną. Obiekt fizyczny posiada atrybuty charakterystyczne dla osoby fizycznej i dziedziczy atrybuty obiektu właściciel. Podobnie obiekt prawny posiada nazwę i regon charakterystyczne dla osób prawnych i dziedziczy resztę atrybutów z obiektu właściciel. Dziedziczenie funkcjonuje również w drugą stronę, obiekt właściciel posiada oprócz atrybutów zdefiniowanych na jego poziomie, atrybuty obiektu fizyczny i obiektu prawny.
Podobnie fragment diagramu ewidencji pojazdów posłuży jako przykład zastosowania wykluczania. Otóż z pojazdem są związane zdarzenia (zdarzenia zmiany). Na poniższym rysunku przedstawiono, że takie zdarzenie może dotyczyć zmiany dokumentu (powiązania z dokumentem) albo zmiany właściciela (powiązanie z właścicielem). Nie może dotyczyć obu tych powiązań jednocześnie.
Modelowanie przepływów danych ma za zadanie przedstawienie przepływu danych pomiędzy funkcjami, obiektami i magazynami danych. Ten etap modelowania służy przedstawieniu graficznemu przepływu i przetwarzania informacji (danych) w modelowanym fragmencie świata rzeczywistego. Poniżej przedstawiono objaśnienie symboli pojawiających się na schematach DFD.
Jak przykład przeanalizujmy funkcję obsługi faktury obcej wpływającej do przedsiębiorstwa[3]. Faktura spływa do sekretariatu od klienta, gdzie jest przyjmowana i wpisywana do rejestru faktur obcych, nadawany jej jest tu numer. Następnie faktura podlega kontroli pod względem finansowym i merytorycznym. Jeżeli kontrola wykaże błędy finansowe lub bezzasadność faktury, jest on odsyłana do kontrahenta, jeżeli jest poprawna pod względem merytorycznym i finansowym jest umieszczana w odpowiednim segregatorze. Następnie jest wprowadzana do systemu komputerowego, a po wyprowadzeniu podlega dekretacji i księgowaniu.
System Designer 2000 wyposażony jest jeszcze w inne narzędzia do modelowania systemu. Są to:
Narzędzia te nie stanowią jednak podstawy metodologii, dlatego nie zamieszczono ich opisu, który znajduje się w opracowaniu „Sport Market”.
W tym rozdziale zamieszczono krótki opis pakietu Designer 2000[4]. Nie jest to podręcznik, a jedynie krótki opis narzędzia.
Zestaw wytwarzanych przez Oracle narzędzi do produkcji aplikacji składa się z dwóch części: Oracle Designer/2000 i Oracle Developer/2000. Designer/2000 wspiera graficzne modelowanie złożonych systemów w czasie inżynierii procesów, analizy i projektowania. Natomiast Developer/2000 umożliwia szybkie i tanie wytwarzanie złożonych aplikacji dla małych i wielkich zespołów. Wspólne repozytorium, elastyczna obsługa różnych metod modelowania , wygodne środowisko tworzenia aplikacji w środowisku klient/serwer oraz otwarta i przenośna architektura sprawiają, że Designer...
rafulus