Ogólne zasady korzystania z narzędzi CASE
Autor: Michał Gallina
marzec 1999 roku
SPIS TREŚCI
Budowa Designer 2000
Jak jest zbudowany DES2K
Modelowanie procesów
Modelowanie związków encji
Modelowanie hierarchii funkcji
Modelowanie przepływów danych
Kreator bazy danych
Kreator aplikacji
Diagram schematu danych
Diagram logiki modułów
Diagram opisu modułu
Nawigator preferencji
Diagram struktury modułów
Generator bazy danych
Generator formatek
Generator raportów
Generator wykresów graficznych
Pozostałe generatory
Nawigator repozytorium
Macierz
Raporty
Narzędzi administracyjne
SQL*PLUS
Pomoc
Konwencje przyjęte w trakcie modelowania
Model danych
Encja
Relacja
Atrybut
Model funkcjonalny
Generacja logicznej bazy danych
Szczegółowa definicja tablic
Szczegółowa definicja modułów
Konstrukcje powiązań w module
Definiowanie detali opisu użycia tablicy
Rozplanowanie tabeli
Detale kolumny
Wyświetlanie kolumny
Generacja fizycznych modułów
Generacja fizycznej bazy danych
Spis ilustracji
ROZDZIAŁ 1
W niniejszym opracowaniu przedstawiono ogólny opis narzędzia Designer 2000. Opracowania tego nie należy traktować jako podręcznika, a jedynie jako zbiór wskazówek i wytycznych pomocnych przy projektowaniu systemu przy użyciu narzędzi CASE firmy ORACLE.
Konsola główna systemu Designer 2000 zawiera szereg narzędzi, które albo pozwalają manipulować repozytorium systemu, albo stanowią generatory kodu. Z lewej strony konsoli znajdują się narzędzia dodatkowe. Na prawo od kolumny narzędzi dodatkowych znajduje się zestaw narzędzi i generatorów do projektowania systemu.
Bezpośrednia integracja diagramerów i repozytorium zapewnia spójność modeli i natychmiastową wymianę informacji wewnątrz zespołu. Należy traktować diagram jako obraz tego co znajduje się w repozytorium. Jeżeli zapiszemy dowolny diagram, a następnie zmienimy dane występujące na diagramie w innym narzędziu (np. w Nawigatorze Repozytorium, lub na innym diagramie), wtedy zapisany wcześniej diagram zawiera nieaktualne informacje i wymaga konsolidacji.
Ilustracja 1 Widok konsoli systemu Designer 2000
Narzędzie to służy do modelowania procesów. Pozwala na definiowanie struktury organizacyjnej, w której zachodzą modelowane procesy. Poszczególne kroki procesów są zbudowane z funkcji, które można następnie zamodelować w postaci hierarchii oraz zdefiniować przepływy danych pomiędzy poszczególnymi funkcjami. Modelując proces podajemy jego nazwę, a następnie konstruujemy pojedyncze kroki tego procesu określając, w którym miejscu schematu organizacyjnego są realizowane. Definiujemy przepływy danych pomiędzy krokami procesu, możemy także tworzyć magazyny danych. Z punktu widzenia modelowania hierarchii funkcji proces stanowi funkcję nadrzędną do kroków procesu. Na poniższym rysunku przedstawiono ekran diagramera służącego do modelowania procesów.
Ilustracja 2 Ekran diagramu modelowania procesów
Narzędzie to pozwala na rysowanie diagramów encji i ich związków (relacji). Diagramy pozwalają na tworzenie nowych encji, pełne definiowanie ich atrybutów. Można tworzyć wiele diagramów przedstawiających jedynie wybrane fragmenty analizowanego modelu danych. Zbiór encji wraz z relacjami składa się na model danych analizowanego systemu. W przyszłości niektóre encje staną się tabelami bazodanowymi, inne widokami, inne będą stanowiły wspólne tabele rejestrujące dane dotyczące kilku obiektów (encji). Poniżej przedstawiono ekran diagramera.
Ilustracja 3 Ekran diagramu modelowania encji
Modelowanie hierarchii funkcji odbywa się również za pomocą diagramu. Tworząc nowy diagram podajemy funkcję z korzenia (funkcja, która nie jest podfunkcją), jeżeli nie ma takiej funkcji, musimy ją utworzyć. Za pomocą diagramu tworzymy hierarchie funkcji, wprowadzamy opisy poszczególnych funkcji. Dobrze skonstruowana hierarchia funkcji stanowi analizę funkcjonalną projektowanego systemu.
Ilustracja 4 Ekran diagramu modelowania hierarchii funkcji
Na diagramie możemy zamodelować przepływ danych pomiędzy poszczególnymi funkcjami w hierarchii, mającymi tą samą funkcję nadrzędną.
Przykład
Poniżej przedstawiono hierarchię funkcji systemu obsługującego faktury (własne i obce).
Ilustracja 5 Przykładowa hierarchia funkcji
Teraz możemy przedstawić przepływ danych w ramach funkcji FO (przepływ będzie zdefiniowany pomiędzy funkcjami podrzędnymi do FO).
Ilustracja 6 Przykładowy schemat przepływu danych
Poniżej pokazano sam ekran narzędzia
Ilustracja 7 Ekran diagramu modelowania przepływu danych
Narzędzie to pozwala na utworzenie logicznych[1] obiektów bazodanowych na podstawie definicji modelu danych opisanej za pomocą encji i relacji pomiędzy nimi. Używając tego kreatora tworzymy logiczne tablice bazodanowe, więzy oraz sekwencje. Tak wyprodukowana definicja bazy danych jest zapisana w repozytorium i po pewnych poprawkach można od razu wygenerować skrypty do tworzenia tych obiektów w bazie danych.
Na poniższym rysunku przedstawiono sposób generacji bazy danych przy wykorzystaniu narzędzi DES2K.
Ilustracja 8 Schemat generowania bazy danych
Kreator aplikacji pozwala na utworzenie logicznych modułów na podstawie funkcji zdefiniowanych na etapie analizy. Kreator ten nie przenosi hierarchii, tworzy jedynie moduły, które trzeba połączyć w strukturę za pomocą Diagramu struktury modułów otrzymując menu systemu. Kreator zamienia zdefiniowane wcześniej użycie encji i atrybutów przez funkcję na użycie tabel i kolumn przez moduł.
Po wygenerowaniu za pomocą kreatora modułu, w celu jego dalszej definicji, należy zmienić flagę CANDIDATE. Po stworzeniu modułu za pomocą kreatora flaga ta jest ustawiona i moduł jest jedynie kandydatem na jednostkę programową.
Kreator aplikacji jest w pełni użytecznym narzędziem jedynie, jeżeli wcześniej zdefiniuje się dla każdej funkcji, która ma się stać modułem użycia encji i atrybutów. Dla niedoświadczonego projektanta lepszym rozwiązaniem jest definicja użycia tablic i kolumn dopiero na etapie projektu. Dlatego też, na razie kreator aplikacji nie będzie używany.
Jest to narzędzie analogiczne do diagramu encji i relacji, z tym że korzystamy z niego na etapie projektu. Służy ono do manipulowania logicznymi tablicami. Wykorzystujemy go również do definiowania widoków. Połączenia pomiędzy tablicami powstają z relacji pomiędzy encjami. Połączenia te reprezentują więzy obce. Więzy mogą być definiowane również pomiędzy widokami. Jednak w takim przypadku należy ustawić sprawdzanie poprawności tych więzów jedynie na poziomie klienta[2].
Narzędzie to w bardzo wygodny sposób przedstawia opis tablicy logicznej, kolumn, indeksów i więzów z nią związanych.
Ilustracja 9 Ekran diagramu schematu danych
Pozwala na definiowanie logiki modułów PL/SQL. Innymi słowy pozwala edytować programy PL/SQL (funkcje, procedury, logikę wyzwalaczy bazodanowych, pakiety oraz kursory[3]). Narzędzie to przy wszystkich swoich zaletach - predefiniowania biblioteka konstrukcji PL/SQL, sprawdzanie składni, ma dwie wady (nie można użyć czcionki nieproporcjonalnej, automatyczne formatowanie jest przeprowadzane w ten sposób, że nie zapewnia czytelności kodu), które powodują, że nie można go polecić[4].
Ilustracja 10 Ekran diagramu logiki modułów
Diagram ten pozwala w pełni zdefiniować moduł. Na podstawie tej definicji generator generuje formatkę, raport, wykres, itd. Poprawne posługiwanie się tym narzędziem wymaga doświadczenia i jest kluczowe w osiągnięciu efektu 100% generowanego kodu. Tak naprawdę istnieją formatki, które po wygenerowaniu wymagają dużej „obróbki” i narzędziach pakietu Developer 2000. Należy jednak dążyć do ideału 100% generacji 0% „obróbki ręcznej”.
W trakcie generacji DES2K używa zestawu preferencji, które określają w jaki sposób mają być generowane poszczególne elementy systemu (np. Ilość linii odstępu pomiędzy tytułem bloku w formatce a pierwszym polem w bloku, wielkość strony formatki, sposób rysowania bloku - obramowanie prostokątem, wypełnienie kolorem, itd.). Zestaw preferencji liczy kilkaset elementów i nie da się go precyzyjnie opisać. Można tworzyć pewne określone zbiory preferencji, np. do generowania menu, do generowania raportów, do generowania formatek z blokiem wyboru osoby, do generowania pozostałych formatek. Wtedy w każdym z tych zbiorów można ustawić inne wartości tych samych preferencji (np. nazwę formatki będącej szablonem). W trakcie generacji możemy wtedy wybrać zbiór preferencji[5].
Struktura modułów to przede wszystkim menu systemu. Narzędzie to pozwala w pełni zaprojektować menu, które po wygenerowaniu praktycznie nie wymaga modyfikacji w narzędziach pakietu Developer 2000 (wyjątek stanowi jedynie litera „ś” w napisie „wyjście” - CASE generuje ją w formacie ISO-LATIN2, który różni się od zestawu znaków polskich obowiązującego w środowisku WINDOWS). Definiując strukturę menu korzystamy z wcześniej zdefiniowanych i utworzonych logicznych modułów[6] (menu, formatek, raportów, wykresów). Możemy także tworzyć nowe moduły, które zostaną dokładnie zdefiniowane (użycie tablic i kolumn) w diagramie opisu modułu.
Za pomocą tego narzędzia definiujemy również strukturę pakietów bazodanowych.
Generator pozwala generować w pełni automatycznie skrypty do zakładania bazy danych (*.SQL). Są to skrypty do tworzenia tablic, widoków, więzów, wyzwalaczy bazodanowych, indeksów, pakietów, procedur i funkcji zapisywanych w bazie danych, ról, uprawnień, klastrów, migawek bazodanowych, synonimów, sekwencji, a nawet segmentów wycofania i przestrzeni tabel.
Pozwala generować prototypy formatek, które następnie można modyfikować w ORACLE FORMS pakietu Developer 2000. W trakcie generacji można wykorzystywać zbiory preferencji zdefiniowane w nawigatorze preferencji.
Generator ten służy również do generacji menu. W tym przypadku poprawki w wygenerowanym menu nie są praktycznie potrzebne, a nawet są niedozwolone. Nie można dopuścić do sytuacji, w której definicja menu w CASE i menu aplikacyjne różnią się.
Co do formatek, niestety różnice te będą istniały, choć podstawowa definicja musi być zgodna.
Ilustracja 11 Schemat generacji fizycznych modułów
Pozwala generować prototypy raportów, które następnie można modyfikować w ORACLE REPORTS pakietu Developer 2000. Działa na podobnej zasadzie jak generator formatek. Praktycznie można powtórzyć schemat zamieszczony powyżej.
Pozwala generować wykresy graficzne uruchamiane w narzędziu pakietu Developer 2000 - ORACLE GRAPHICS. W chwili obecnej narzędzie to nie będzie raczej wykorzystywane, dlatego pominięto jego szczegółowy opis.
W tej chwili nie zamieszczono opisu pozostałych generatorów, z uwagi na to, że na razie nie będą one wykorzystywane. W przyszłości zostanie zapewne wykorzystany jedynie generator warstwy WEB.
Nawigator jest narzędziem pozwalającym na manipulacje całym repozytorium. Za pomocą tego narzędzia można manipulować wszystkimi obiektami zapisywanymi w repozytorium, w zakresie identycznym, jak w diagramach i pozostałych narzędziach pakietu Designer 2000. Dodatkowo, można tu definiować obiekty (np. dokumenty, problemy, węzły rozproszonej bazy danych, użytkowników, role bazodanowe, przestrzenie tablic, itd.), które nie występują w żadnym innym narzędziu pakietu.
Posługiwanie się nawigatorem wymaga pewnego zaawansowania w rozumieniu istoty repozytorium. W wielu przypadkach wygodniej jest się posługiwać innymi narzędziami (np. w nawigatorze można zdefiniować cały schemat modelu danych - encje + relacje, jednak w diagramie modelowania danych jest to o wiele wygodniejsze i bardziej przejrzyste). Mimo to nawigator jest ciągle najważniejszym narzędziem pakietu.
Ilustracja 12 Ekran nawigatora repozytorium
Pozwala definiować macierze stanowiące rodzaj raportu. Przykładowo na jednej z osi macierzy (kolumna) można zdefiniować moduły, na drugiej (wiersz) kolumny tablic bazodanowych, a na przecięciu (element macierzy) rodzaj operacji wykonywanej w danym module na danej kolumnie (np. INSERT-I, UPDATE-U, SELECT-S). Można definiować wiele innych macierzy.
Ilustracja 13 Ekran diagramu macierzy
Zestaw raportów przedstawiających dane o analizie i projekcie. Raporty te są jednak zupełnie nieużyteczne z uwagi na bardzo kiepskie wykorzystanie strony wydruku (prosty raport potrafi mieć około 100 stron!). Dlatego poleca się stosowanie narzędzia ORACLE BROWSER z pakietu Discoverer 2000.
Narzędzia do instalacji repozytorium CASE, administrowania użytkownikami systemu. Praktycznie używane jedynie przez administratora.
Uruchomienie narzędzia ORACLE - SQL*PLUS i podłączenie jako użytkownik aktualnie pracujący w CASE bez konieczności podawania hasła.
rafulus