Wykład 8

Projektowanie aplikacji bazodanowej

Streszczenie

Projektowanie i implementacja systemu informacyjnego nie są na ogół  sprawami prostymi. Dlatego wymagane jest stosowanie się do ogólnych zasad prac projektowych obejmujących między innymi zasady zarządzaniami zespołami projektowymi. Dla celów realizacji projektów w ramach zajęć  z Relacyjnych baz danych sformułujemy proste zasady prowadzenia takich prac. W drugiej części wykładu przedstawimy zarys trochę bardziej złożonej i całościowej metodyki prowadzenia projektów mianowicie MSF – czyli Microsoft Solutions Framework.

W całej swojej złożoności problem tworzenia systemów informacyjnych będzie przedstawiony na wykładach Projektowanie systemów informacyjnych i Budowa i integracja systemów informacyjnych, gdzie zostanie osadzony w projektowym i programistycznym środowisku obiektowym.
 

Projektowanie aplikacji

Obiekty aplikacji:

• Mają właściwości, dzięki czemu można uzyskać pożądany wygląd i sposób działania obiektów. Na przykład, właściwość obiektu formularza o nazwie Edycja dozwolona pozwala ustalić, czy użytkownik może edytować dane na formularzu.
• Reagują automatycznie na zdarzenia np. gdy użytkownik zmieni wartość w polu tekstowym, następuje automatyczne sprawdzenie, czy nowa wartość jest poprawnego typu danych. Zdarzenia dotyczą formularzy, raportów i elementów dialogowych (kontrolek).
  • Oprócz wbudowanej w systemie reakcji na zdarzenia jest możliwość określania akcji (w postaci procedury zdarzenia) - do wykonania przy każdym zajściu danego zdarzenia.
    

Etapy prac projektowych nad systemem informacyjnym (aplikacją bazodanową)

Większość metodyk prowadzenia prac projektowych obejmuje fazy:

1. Strategia (analiza wstępna problemu)
2. Analiza szczegółowa problemu
3. Projektowanie systemu
4. Implementacja systemu (z tworzeniem dokumentacji i testowaniem)
5. Wdrożenie systemu

Oto trochę szczegółów - więcej znajdzie się przy omawianiu dokumentacji projektowej:

1. Analiza (wstępna i szczegółowa)
   - określa cel i zakres aplikacji.
   • W oparciu o rozmowy z użytkownikami, następuje sporządzenie listy zadań, jakie aplikacja ma realizować.
   • Analizowane są kopie używanych papierowych formularzy i raportów.
   • Identyfikuje się, jakie dane są przetwarzane i jakie są między nimi związki (tworzy się diagram związków encji).
2. Projektowanie, protypowanie i implementacja
   - jakie obiekty (tabele, kwerendy, formularze, raporty, strony, moduły) mają tworzyć projektowaną aplikację.
   • Projektowanie aplikacji może się odbywać albo metodą z góry w dół (top-down) albo metodą z dołu w górę (bottom-up) albo za pomocą połączenia obu tych metod.
   • W pierwszej kolejności należy zaplanować tabele i powiązania między nimi.
   • Przy użyciu narzędzia CASE (jak MS Visio), z diagramu związków encji można automatycznie wygenerować schemat bazy danych.
   • Następnie zgodnie z metodą z góry w dół projektujemy strukturę aplikacji w postaci drzewa (lub ogólniej grafu).
     • Wierzchołkami są planowane formularze, raporty, strony i procedury.
     • Strzałki reprezentują przejścia między nimi.
     • Wyróżniony wierzchołek początkowy - korzeń drzewa -  stanowi formularz, który jest wyświetlany na samym początku.

     • Strzałkom i wierzchołkom przyporządkowuje się odpowiednie własności jak np.
       • wierzchołkom - typ obiektu w wierzchołku np. formularz, raport;
         • jeśli formularz to jakiego rodzaju:
           • panel sterowania,
           • informacyjny,
           • do wprowadzania danych,
           • do modyfikowania danych,
           • do wyświetlania danych,
           • do filtrowania danych w tym samym formularzu lub innym.
         • podobnie dla raportu - jakiego ma być rodzaju.
         • każdemu rodzajowi operacji przetwarzania danych, jak  wyszukiwanie, wprowadzanie, modyfikowanie, powinien odpowiadać osobny formularz. Później w uzasadnionych przypadkach - jak względy efektywności lub wygody użytkownika można połączyć dwa lub więcej formularzy w jeden.
     • strzałkom:
       • jakie dane zostają przekazane,
       • co robić z obiektem, od którego zaczyna się strzałka np. czy uczynić go niewidzialnym na ekranie, czy zamknąć go,
       • czy sterowanie programu powróci z powrotem po tej strzałce.
   • Po utworzeniu drzewa (grafu) aplikacji buduje się wstępny prototyp aplikacji, na którym przedstawia się strukturę kontrolną aplikacji (jeszcze bez realizacji konkretnych funkcji) oraz zasady interfejsu użytkownika.
   • Prototypy pokazuje się użytkownikom do akceptacji testowanych rozwiązań projektowych. Mają one charakter próbny i powinny zostać później zastąpione przez bardziej dojrzałe, lepiej dopasowane do potrzeb i wyobrażeń użytkowników wersje.
   • Stosując metodę z dołu w górę kolejno projektuje się formularze i raporty, zaczynając od zapytań wybierających mających być ich źródłami wierszy oraz następnie sam formularz lub raport.
   • Z kolei należy utworzyć kwerendy i procedury potrzebne do odpowiedniego działania formularza.
   • Należy przetestować formularz (raport) sprawdzając, czy przy jego użyciu można we właściwy sposób wykonywać operacje na danych.
   • Formularze i raporty należy z kolei zintegrować ze sobą, projektując przejścia między nimi - wykorzystując zdarzenia, przyciski na formularzu lub na dostosowanych paskach menu.
     

Dokumentacja projektowa

Cały czas w trakcie prowadzenia prac projektowych jest przygotowywana i aktualizowana dokumentacja projektowa - raportująca uzyskane przez zespół projektowy wyniki. Stanowi ona istotny element prowadzonych prac projektowych. Oto jej znaczenie:

• Podstawa do zatwierdzenia kolejnego etapu tworzenia systemu jak i do wytyczenia planu kolejnego etapu.
• Środek komunikacji wiedzy o projekcie między ludźmi - klientami, użytkownikami, analitykami, projektantami, programistami itd.
• Prowadzi do zmniejszenia złożoności, usystematyzowania wiedzy o aplikacji.
• Łączy użytkowników i ich potrzeby z samą aplikacją i jej uwarunkowaniami.
• Niezbędna przy wprowadzaniu zmian w fazie eksploatacji systemu.

Na samym początku jest tworzony dokument definiujący potrzeby, zadania i ograniczenia projektu nazywany TOR - Terms Of Reference.  Oto jego przykładowe części:

• Nazwa projektu
• Kontekst opisuje otoczenie, w którym bierze się pod uwagę możliwość powstania aplikacji bazy danych.
• Potrzeby wyjaśniają dlaczego baza danych jest potrzebna, dlaczego jest bez niej źle, jak również uzasadniają, że spodziewane korzyści przewyższą przewidywane koszty.
• Zakres i ograniczenia - jakie zadania będą realizowane, a jakie ewentualnie nie; przy jakich ograniczeniach trzeba prowadzić projekt jak czas, ludzie, pieniądze; jakie mogą się pojawić przeszkody.

Dokumenty fazy analizy:

• diagram związków encji oraz lista opisów znaczenia encji, atrybutów i związków,
• spis definicji funkcji biznesowych ze wskazaniem, które mają być realizowane w ramach aplikacji bazy danych,
• spis grup użytkowników, którzy będą korzystać z systemu - z zaznaczeniem funkcji i encji, które będą wykorzystywać.

Dokumenty fazy projektowania:

• schemat projektowy bazy danych (tabele, kolumny, klucze główne i obce, perspektywy, indeksy), więzy spójności,
• diagram i spis modułów systemu (formularze, raporty, powiązania między nimi).

Wyniki fazy implementacji systemu (łącznie z dokumentowaniem i testowaniem):

1. działająca aplikacja,
2. dokumentacja końcowego użytkownika w tym podręczniki szkoleniowe,
3. dokumentacja eksploatacyjna administratora systemu,
4. dokumentacja programistyczna systemu dla osób, które w przyszłości będą administrować i/lub zmieniać system.

Faza wdrażania systemu obejmuje jego instalację, szkolenie użytkowników i wprowadzanie danych (ewentualnie migrację danych z poprzedniego wydania systemu).

Faza eksploatacji systemu połączona z wprowadzaniem do niego zmian wymaga powrotu do dokumentacji przygotowanej w poprzednich fazach i jej modyfikacji.

Cechami charakterystycznymi faz projektowania aplikacji jest przetwarzanie informacji zebranych w poprzedzającej fazie:

• ogólna specyfikacja danych przechodzi w diagram związków encji, który z kolei przechodzi w schemat bazy danych, a następnie w bazę danych;
• ogólna specyfikacja funkcji przechodzi w spis funkcji, następnie w diagram i specyfikację modułów systemu a następnie w aplikację i jej opis w dokumentacji użytkownika i w dokumentacji programistycznej.

Wynikiem prac każdej fazy jest także plan przeprowadzenia następnej fazy.

Inną cechą procesu tworzenia aplikacji jest używanie prototypów – próbnych aplikacji - na długo przed tym jak rozpocznie się implementacja systemu. W wyniku analizy działania tych próbnych aplikacji można uzyskać potwierdzenie prawidłowego zrozumienia wymagań użytkowników co do reprezentowanych danych, realizowanych funkcji i interfejsu ekranowego aplikacji.

Ważną cechą procesu tworzenia aplikacji jest użycie narzędzi CASE umożliwiających automatyzację pewnych procesów projektowych. Charakteryzuje je:

1. Skoncentrowanie na komputerowym wspomaganiu etapów analizy i projektowania oraz bezpośrednim użyciu ich rezultatów w fazie implementacji.
2. Centralne pojęcie to repozytorium projektowe – baza danych zawierająca wszystkie obiekty (w tym dokumenty) używane wspólnie przez cały zespół projektowy przez cały okres działalności projektowej:
• diagramy np. diagramy związków encji;
• elementy diagramów np. encja, funkcja, proces, moduł, tabela;
• projektowe reprezentacje obiektów bazy danych poziomu fizycznego np. indeksy, przestrzenie tabel, segmenty wycofań;
• dokumenty projektowe jak terminologia biznesu, cele, krytyczne czynniki powodzenia.
3. Repozytorium projektowe jest dzielone na części – systemy aplikacyjne, foldery.
4. Obiekty projektowe mogą być:
   •   transformowane między kolejnymi poziomami projektowymi np. można dokonać transformacji encji na tabelę a także tabeli na encję;
   •   wersjowane – kolejnym wersjom obiektu repozytorium przypisuje się numer wersji;
   •   poddawane generowaniu (forward engineered) do obiektów aplikacji jak tabele w bazie danych, formularze aplikacji;
   •   wprowadzane wstecz (backward engineered) – tworzone na podstawie istniejących obiektów jak tabele w bazie danych, formularze aplikacji;
   •   współdzielone między różnymi projektami w tym także na zasadzie wypożyczania i zwracania z/do repozytorium projektowego.
5. Narzędzie CASE jest w stanie automatycznie produkować raporty projektowe (w tym produkty kończące etapy projektowania) na podstawie zawartości repozytorium projektowego. Np. w MS Visio z menu "Database -> Report" możemy wybrać:

Przejście do drugiej części wykładu