Wykład 2. Definiowanie przeznaczenia aplikacji Definiowanie funkcji aplikacji Projektowanie bazy danych i procesów aplikacji Implementacja

Transkrypt

1 Wykład 2 Definiowanie przeznaczenia aplikacji Definiowanie funkcji aplikacji Projektowanie bazy danych i procesów aplikacji Implementacja Bazy danych 2 W2 1

2 Definiowanie przeznaczenia aplikacji Pierwszym krokiem w procesie projektowania każdej aplikacji jest określenie jej przeznaczenia. Należy odpowiedzieć na pytanie co aplikacja ma robić? Przykładowo projekt systemu użytkowego dla pewnej firmy, która zajmuje się wynajmowaniem nieruchomości. Oprogramowanie systemu ma wspomagać zarządzanie nieruchomościami, które ta firma wynajmuje. Nazwijmy ten system użytkowy WYNAJEM. Przeznaczenie aplikacji powinno być wyrażone pojedynczym zdaniem zawierającym podmiot, orzeczenie i dopełnienie Bazy danych 2 W2 2

3 - Podmiot opisuje aplikację, np. "System WYNAJEM... ", - orzeczenie informuje o zadaniu, jakie aplikacja ma wykonywać, np. "System WYNAJEM będzie wspomagać... " -dopełnienie opisuje obiekt, którego dotyczy zadanie, np. "System WYNAJEM będzie wspomagać zarządzanie wynajmem nieruchomości". Zdanie formułujące przeznaczenie systemu powinno być jak najprostsze i możliwie krótkie. Niepożądane są w nim określenia nie wnoszące żadnej nowej informacji, takie jak np. "na rzecz instytucji... ", czy "dla klienta... ". Powinno się także unikać zdań złożonych i spójników Bazy danych 2 W2 3

4 Definiowanie funkcji aplikacji Po sformułowaniu przeznaczenia aplikacji należy określić jakie funkcje musi ona realizować, aby wypełnić zadanie, do którego została powołana. Lista tych funkcji powinna stanowić mały zbiór najważniejszych funkcji. Konstrukcja zdań, opisujących poszczególne funkcje powinna przypominać konstrukcję zdania, wyrażającego przeznaczenie całej aplikacji. Przykładowy system WYNAJEM będzie: rejestrować i obsługiwać umowy najmu nieruchomości, śledzić prace związane z konserwacją nieruchomości, generować rachunki dla najemców, generować informacje o historii poszczególnych nieruchomości. Lista ta powinna obejmować wszystkie najważniejsze funkcje aplikacji, ale nie powinna być zbyt szczegółowa Bazy danych 2 W2 4

5 Projektowanie bazy danych i procesów aplikacji W procesie projektowania bazy danych można wyróżnić trzy etapy: 1. Sporządzenie dokumentacji reguł przetwarzania, niezbędnych do realizacji funkcji aplikacji. 2. Sporządzenie diagramu związków encji, wymaganych do obsługi procesów. 3. Stworzenie logicznego projektu bazy danych, niezbędnego do implementacji związków encji i reguł przetwarzania Bazy danych 2 W2 5

6 Bazy danych 2 W2 6

7 Główne czynności związane z kolejnymi fazami cyklu życia aplikacji bazy danych Faza Planowanie bazy danych Definicja systemu Gromadzenie i analiza wymagań Projektowanie bazy danych Wybór Systemu Zarządzania Bazą Danych Projektowanie aplikacji Tworzenie prototypów Implementacja Konwersja i migracja danych Testowanie Bieżąca konserwacja Główne czynności Planowanie najbardziej skutecznych i wydajnych metod realizacji faz cyklu życia. Określenie zakresu i granic stosowania danej aplikacji bazy danych, wskazanie jej użytkowników oraz obszarów zastosowań. Zbieranie i analiza wymagań pochodzących od użytkowników i wynikających z obszarów zastosowań. Projektowanie konceptualne, logiczne i fizyczne bazy danych. Wybór SZBD odpowiedniego dla aplikacji bazy danych. Projektowanie interfejsów użytkowników i programów użytkowych, które będą przetwarzać bazę danych. Budowanie działającego modelu aplikacji bazy danych, który pozwala projektantom i użytkownikom zobrazować i ocenić sposób działania i wygląd końcowego systemu. Tworzenie zewnętrznych, konceptualnych i wewnętrznych definicji bazy danych i programów użytkowych. Przenoszenie danych ze starego systemu do nowego. Testowanie i usuwanie błędów z aplikacji bazy danych oraz sprawdzanie zgodności z wymaganiami użytkowników. Aplikacja bazy danych jest w pełni zaimplementowana. System jest na bieżąco monitorowany i konserwowany. W razie potrzeby do aplikacji bazy danych są wprowadzane nowe wymagania poprzez ponowne przejście przez powyższe fazy Bazy danych 2 W2 7

8 Planowanie bazy danych To czynności związane z zarządzaniem, które pozwolą skutecznie i efektywnie zrealizować wszystkie fazy cyklu życia aplikacji. Należy: Zidentyfikować cele i plany przedsiębiorstwa powiązane z późniejszym określeniem wymagań wobec systemu informacyjnego. Ocenić aktualnie używany w przedsiębiorstwie system informacyjny co pozwoli określić jego mocne i słabe strony. Oszacować możliwości technologii informatycznych, które pomogą uzyskać przewagę nad konkurencją Bazy danych 2 W2 8

9 Projektowanie bazy danych Bazy danych 2 Proces, w którym powstaje projekt bazy danych. Baza ta ma wspomagać funkcjonowanie przedsiębiorstwa i realizację jego zadań. Dwa główne podejścia do projektowania: metoda wstępująca projektowanie rozpoczyna się od podstawowego poziomu zawierającego atrybuty (tzn. własności encji i związków), a następnie poprzez analizę powiązań pomiędzy atrybutami łączy sieje w relacje reprezentujące encje i związki pomiędzy encjami. Metoda wstępująca nadaje się do projektowania prostych baz danych zawierających względnie małą liczbę atrybutów. Prowadzi do komplikacji, jeśli stosuje się ją do projektowania złożonych baz danych zawierających dużą liczbę atrybutów; bardzo trudno jest wtedy ustalić wszystkie zależności funkcyjne pomiędzy nimi; metoda zstępująca - rozpoczyna się od stworzenia modeli danych, które zawierają tylko pewną niewielką liczbę "ogólnych" encji, związków i związanych z nimi atrybutów. Następnie, drogą kolejnych uściśleń, wprowadza się encje, związki i związane z nimi atrybuty niższych poziomów. Podejście zstępujące można zilustrować za pomocą pojęć modelu związków encji, zaczynając od identyfikacji tych encji i związków pomiędzy encjami, które są istotne dla danej instytucji Bazy danych 2 W2 9

10 Modelowanie danych jest ważnym etapem procesu projektowania bazy danych Dwa główne cele modelowania danych to: ułatwienie zrozumienia znaczenia (semantyki) danych i pomoc w porozumiewaniu się w sprawie wymagań informacyjnych. Budowa modelu danych wymaga znalezienia odpowiedzi na wiele pytań dotyczących encji, ich związków i atrybutów. W trakcie realizacji tego zadania projektanci odkrywają semantykę danych przedsiębiorstwa, która oczywiście istnieje zawsze, niezależnie od tego, czy zostanie zapisana w formalnym modelu danych, czy też nie. Encje, związki pomiędzy encjami i ich atrybuty są podstawowymi składnikami każdego przedsiębiorstwa. Ich znaczenia nie zawsze jest w pełni zrozumiałe aż do czasu, kiedy zostaną właściwie udokumentowane. Model danych ułatwia uświadomienie sobie znaczenia danych, zatem konstruujemy go między innymi po to, by przekonać się, że dobrze rozumiemy: sposób widzenia (perspektywę) danych każdego użytkownika; naturę samych danych, niezależnie od ich fizycznej reprezentacji; zastosowania danych w różnych perspektywach Bazy danych 2 W2 10

11 Optymalny model danych powinien spełniać kryteria zawarte w poniższej tabeli (Fleming i Von Halle, 1989). Czasami jednak jednoczesne spełnienie wszystkich kryteriów nie jest możliwe i konieczne jest dokonanie wyboru. Kryterium Poprawność strukturalna Prostota Wyrażalność Brak redundancji Uniwersalność Rozszerzalność Integralność Łatwość graficznej prezentacji Znaczenie Zgodność ze sposobem definiowania i organizacji danych w przedsiębiorstwie. Zrozumiałość zarówno dla informatyków, jak i dla nieprofesjonalnych użytkowników Zdolność odróżniania różnych typów danych, związków pomiędzy danymi oraz więzów. Eliminacja niepotrzebnych informacji; w szczególności dbałość o reprezentowanie każdej informacji tylko raz (normalizacja) Brak powiązań modelu z jakąś konkretną aplikacją czy technologią, a zatem dostępność dla wielu różnych klientów. Zdolność do rozbudowy o elementy realizujące nowe wymagania przy minimalnych skutkach dla istniejących użytkowników. Zgodność ze sposobami wykorzystywania informacji i zarządzania nią w przedsiębiorstwie. Zdolność do reprezentacji modelu za pomocą prostych i zrozumiałych schematów Bazy danych 2 W2 11

12 Etapy projektowania bazy danych Projektowanie bazy danych odbywa się w trzech głównych etapach nazywanych projektowaniem konceptualnym, logicznym i fizycznym. Konceptualne projektowanie bazy danych - jest to proces konstrukcji modelu dla informacji używanej w przedsiębiorstwie, który jest niezależny od wszelkich aspektów fizycznych. Logiczne projektowanie bazy danych - proces konstrukcji modelu informacji używanej w przedsiębiorstwie, który jest oparty na specyficznym modelu danych, ale niezależny od konkretnego SZBD i innych aspektów fizycznych. Fizyczne projektowanie bazy danych - tworzenie opisu implementacji bazy danych w pamięci zewnętrznej. Opis ten zawiera bazowe relacje oraz organizację plików i indeksów zapewniającą efektywny dostęp do danych, realizację więzów integralności i środków bezpieczeństwa danych Bazy danych 2 W2 12

13 Projektowanie aplikacji To faza, w której powstają projekty interfejsu użytkownika oraz modułów stosujących i przetwarzających bazę danych. Projektowanie transakcji Transakcja to jedna lub kilka spójnych operacji odwołujących się do zawartości bazy danych lub ją modyfikujących, których wykonanie zleca pojedynczy użytkownik lub aplikacja. Transakcje reprezentują różne zdarzenia ze "świata rzeczywistego", takie jak rejestracja nieruchomości do wynajęcia, dopisanie nowej osoby z personelu, rejestracja nowego klienta lub wynajęcie klientowi nieruchomości. Transakcje te muszą być wykonane na bazie danych w taki sposób, aby dane w bazie pozostały zgodne z odpowiadającymi im "rzeczywistymi" sytuacjami oraz aby system mógł dostarczać użytkownikom potrzebne im informacje (cechy transakcji ACID). Celem projektowania transakcji jest zdefiniowanie i udokumentowanie ogólnej charakterystyki wszystkich transakcji, które będą realizowane przez bazę danych. Projekt powinien zawierać: dane, które są używane w transakcji; opis czynności realizowanych przez transakcję; wyniki transakcji; znaczenie transakcji dla użytkowników; oczekiwaną częstość wykonywania transakcji Bazy danych 2 W2 13

14 Zasady projektowania interfejsu użytkownika Pierwszą czynnością przy implementacji formularza lub raportu powinno być zaplanowanie jego układu. Zasady projektowania interfejsu użytkownika: Znaczący nagłówek Zrozumiałe instrukcje Logiczne grupowanie i ustawianie kolejności pól Atrakcyjny wizualnie układ formularza/raportu Znajome użytkownikom opisy pól Spójna terminologia i skróty Spójne używanie kolorów Widoczna przestrzeń i granice pól służących do wprowadzania danych Wygodna obsługa ruchów kursora Korekcja błędnie wprowadzonych znaków i całych pól Komunikaty błędów informujące o nieakceptowanych polach Wyraźne oznaczenie pól opcjonalnych Komunikaty objaśniające pola Sygnał zakończenia wprowadzania Bazy danych 2 W2 14

15 Znaczący nagłówek - informacja przekazywana w nagłówku powinna jasno i jednoznacznie określać przeznaczenie formularza lub raportu. Zrozumiałe instrukcje w instrukcjach należy przekazywać użytkownikom informacje za pomocą znanej im terminologii; powinny być krótkie, a w sytuacjach wymagających dłuższego wyjaśnienia należy udostępnić plansze pomocy. Kolejne wymagania to jednolitość stylistyczna (pod względem formy językowej) oraz standardowy format zapisu. Logiczne grupowanie i ustawianie kolejności pól Na formularzu lub raporcie pola, które są wzajemnie powiązane, należy umieszczać blisko siebie. Kolejność ustawienia pól powinna być logiczna i spójna. Atrakcyjny wizualnie układ formularza/raportu Formularze i raporty powinny mieć atrakcyjną dla użytkownika formę interfejsu. Wymagany jest zrównoważony układ graficzny składający się z równomiernie rozmieszczonych na całej powierzchni pól i grup pól. Należy unikać tworzenia obszarów raportu lub formularza, które zawierają zbyt mało lub zbyt wiele informacji. Pola lub grupy pól powinny być rozdzielane regularnymi odstępami, a w miejscach, które tego wymagają, powinny być wyrównane w pionie lub w poziomie. W przypadkach, gdy formularz pokazywany na ekranie ma również formę drukowaną, należy zachować jednolity wygląd obu postaci. "Znajome" użytkownikom opisy pól Opisy pól powinny być zrozumiałe dla użytkowników. Spójna terminologia i skróty Należy używać wcześniej uzgodnionej listy dobrze znanych określeń i skrótów. Spójne używanie kolorów Kolory powinny służyć do uatrakcyjnienia wyglądu formularzy i raportów, a także do podkreślenia znaczenia ważnych pól. Należy posługiwać się nimi w spójny i znaczący sposób Bazy danych 2 W2 15

16 Widoczna przestrzeń i granice pól służących do wprowadzania danych Użytkownik powinien być wizualnie informowany o całkowitej dostępnej wielkości każdego pola. Rozwiązanie to pozwala użytkownikom na wybór właściwej formy wprowadzanych danych przed przystąpieniem do tej czynności. Wygodna obsługa ruchów kursora Użytkownik powinien łatwo identyfikować operacje służące do przesuwania kursora po formularzu lub raporcie. W tym celu należy używać najprostszych dostępnych środków, takich jak klawisze strzałek i tabulacji oraz wskaźnik myszy. Korekcja błędnie wprowadzonych znaków i całych pól Użytkownik powinien łatwo identyfikować operacje przeznaczone do zmiany zawartości pól. W tym celu należy używać najprostszych dostępnych środków, takich jak klawisz cofający i tryb zastępowania. Komunikaty błędów informujące o nieakceptowanych polach Komunikat błędu powinien ukazywać się w sytuacjach, gdy użytkownik próbuje wprowadzić do pola niepoprawne dane. Powinien informować go o rodzaju błędu i wskazywać wartości dozwolone dla danego pola. Wyraźne oznaczenie pól opcjonalnych Pola opcjonalne powinny być łatwo rozpoznawalne przez użytkownika. Ten cel można osiągnąć poprzez użycie odpowiednich opisów pól lub poprzez wyświetlanie ich w specjalnie przypisanym im kolorze. Pola opcjonalne należy umieszczać za polami obligatoryjnymi. Komunikaty objaśniające pola Gdy użytkownik umieści kursor w wybranym polu, informacja o nim powinna ukazać się w ustalonym miejscu na ekranie, na przykład w pasku stanu okna lub w postaci tzw. "dymku". Sygnał zakończenia wprowadzania Każdy użytkownik wypełniający formularz powinien łatwo dostrzegać moment, kiedy kończy się proces wypełniania pól. Opcji zapisu danych nie należy jednak wykonywać automatycznie, ponieważ może on chcieć jeszcze zweryfikować wprowadzone dane Bazy danych 2 W2 16

17 Implementacja Ważny, jeden z końcowych etapów tworzenia systemu bazy danych. W wybranym wcześniej systemie zarządzania bazą danych należy "osadzić" obiekty bazy danych (tabele, indeksy, perspektywy, funkcje i procedury pamiętane, wyzwalacze) funkcjonujące po stronie serwera. Wykorzystuje się tutaj opis modelu danych za pomocą wyrażeń podzbioru DDL języka SQL. Często używa się wbudowanych w oprogramowanie SZBD elementów graficznego interfejsu (tworzenie tabel i innych obiektów w MSSQL Server Management Studio, system MS Access, narzędzia Power Designer, MySQL Workbench itp.). Po stronie klienta powinny powstać aplikacje udostępniające te obiekty użytkownikom. Do implementacji aplikacji klienckich wykorzystuje się środowiska programistyczne dysponujące możliwościami tworzenia graficznego interfejsu użytkownika (GUI) Bazy danych 2 W2 17

18 Baza danych Zarządzanie danymi Zarządzanie regułami Klient Oprogramowanie łączące Komunikacja Oprogramowanie łączące Komunikacja Serwer Logika aplikacji Logika prezentacji Bazy danych 2 W2 18