Standardy związane ze spójnością bazy danych

Rozwiązania przyjęte w tym zakresie zmierzają do zapewnienia pełnej spójności bazy danych za pomocą mechanizmów bazy danych a nie aplikacji. Reguły spójności zaszywane są więc w bazie danych (związki referencyjne, wyzwalacze) i nie zależą od sposobu dostępu do bazy ( aplikacje, dostęp interakcyjny).

Standardy związane z prawami dostępu do bazy danych

Standardy te definiują sposób realizacji ochrony danych przed ich nie autoryzowanym odczytaniem/modyfikacją.

Przyjęte w Thomson Polkolor rozwiązanie charakteryzuje się otwartością i elastycznością z jednej strony, a pełnym

bezpieczeństwem danych z drugiej strony. Rozwiązanie to spełnia następujące wymagania:

• prawa dostępu definiować można na poziomie tablic, kolumn i wierszy

• na poziomie bazy danych udostępniane są wyłącznie prawa do odczytu, obowiązujące bez względu na sposób dostępu do bazy danych (aplikacja, Quest, ODBC)

• zapis i modyfikacja danych możliwe są wyłącznie za pomocą aplikacji w tym celu napisanych, zgodnie z oddzielnie

  definiowanymi prawami

• użytkownik korzysta z tego samego identyfikatora i hasła, bez względu na sposób dostępu do bazy.

Powyższe założenia realizowane są poprzez odpowiednie wykorzystanie procedur wbudowanych, wyzwalaczy i widoków.

Standardy definiujące wygląd i zawartość okien aplikacji, typowe akcje na oknach i sposoby ich realizacji. Składają się ze zdefiniowanej hierarchii klas, obejmującej typowe funkcje aplikacji. Dla każdego okna zdefiniowane są klasy obiektów, ich rozmieszczenie na ekranie oraz typowe akcje. Zdefiniowano również sposób nawigacji między typowymi oknami, jak i standardową obsługę błędów.

Standardy stworzone zostały jako biblioteka klas. Opracowano również szczegółowe procedury ich wykorzystywania.

Podsumowanie

Przedstawione powyżej zasady organizacji procesu wytwarzania aplikacji w Thomson Polkolor nie są jeszcze dokończone i dopracowane we wszystkich szczegółach. W trakcie ich tworzenia rozpatrywano wiele wariantów i możliwości rozwiązań. Niektóre, początkowo interesujące, nie spełniły pokładanych w nich nadziei i musiano się z nich wycofać. Inne są nadal rozwijane i ulepszane. Proces ten trwa i będzie rozwijany nadal, w miarę nabierania doświadczenia oraz opanowywania nowych technologii.

Z dotychczasowych doświadczeń można wyciągnąć następujące wnioski:

• zastosowanie nowych technologii wymaga zdecydowanie nowego podejścia do procesu tworzenia aplikacji

• przestawienie zespołu projektowoýprogramowego na nowe technologie nie jest procesem banalnym

• zastosowanie narzędzi CASE powoduje wydłużenie, przynajmniej na początku, procesu tworzenia projektu, jednak

  w ogólnym rachunku jest opłacalne

• sformalizowany proces tworzenia projektu wymaga dodatkowych nakładów na projektowanie, procentuje jednak zwiększeniem jakości i jasności projektu, a co za tym idzie, ułatwia w unikaniu nieporozumień zarówno między użytkownikiem a projektantami, jak i w ramach samego zespołu projektowoýwykonawczego

• włączenie użytkowników do wszystkich szczebli tworzenia projektu i przerzucenie na nich części prac, powoduje utożsamianie się ich z projektem i jest kluczem do sukcesu wdrożenia, a jednocześnie odciąża zespół projektowy

• stworzenie jasnych i prostych zasad tworzenia aplikacji (standardów) w znaczny sposób przyspiesza proces tworzenia aplikacji, poprawia jej jakość i jednorodność oraz, poprzez zapewnienie jednolitości kodu, uniezależnia aplikację od jej twórców.

Doświadczenia Thomson Polkolor w zakresie tworzenia aplikacji na bazie Systemu Engineer LBMS i SQLWindows należy uznać za pozytywne.