• Niektóre encje mogą odpowiadać podklasom, np. towary sprzedawane przez pewną firmę (modelowane encją Towar) mogą dzielić się na sprzęt, oprogramowanie i materiały pomocnicze.

• Niektóre relacyjne bazy danych (np. PostgreSQL) pozwalają reprezentować takie hierarchie tabel, jednak podklasy powinny być rozłączne.

1. Atrybuty i zależności, grupowanie

2. Odwzorowanie encji/obiektów i związków w relacje/tabele

3. Normalizacja i denormalizacja.

4. Strojenie bazy, definiowanie ścieżek dostępu.

• Projektowanie obejmuje projekt logiczny bazy danych i projekt implementacji fizycznej.

• Projektowanie logiczne bazy danych polega na zdefiniowaniu tabel, określeniu ścieżek dostępu (access paths) dla tabel (np. indeksów) oraz dostosowaniu indeksów do potrzeb aplikacji.

  • Warto korzystać z perspektyw — upraszcza to zwłaszcza projektowanie formularzy i raportów w wielu narzędziach.

• Projektowanie implementacji fizycznej dotyczy rozmieszczenia plików bazy danych na dyskach, planów archiwowania i odtwarzania oraz integracji z narzędziami systemu operacyjnego.

• UML (Unified Modeling Language) został zaprojektowany przez Boocha, Jacobsena i Rumbaugh.

• W 1997 roku Object Management Group przyjęła UML 1.1 jako swój standard przemysłowy.

• Służą do modelowania struktury systemu.

• Używane w

  • modelowaniu dziedziny systemu (modelowanie biznesowe)

  • projektowaniu (w tym bazy danych), pojawiają się wtedy klasy ,,techniczne”

  • inżynierii odwrotnej (reverse engineering)

• Podstawowym składnikiem diagramu klas są nazwane klasy.

• Najprostsza reprezentacja klasy nie zawiera nic więcej.

• Oprócz nazwy klasa może zawierać

  • atrybuty

  • metody.

Rodzaje powiązań:

• Asocjacja

• Agregacja i kompozycja

• Dziedziczenie

• Zależność

• refinement — realizacja lub uszczegółowienie

Klasa może być w relacji agregacji z wieloma klasami nadrzędnymi, natomiast w relacji kompozycji tylko z jedną nadrzędną.

Zależność między klasami oznacza, że klasy nie mają powiązania, natomiast klasa zależna otrzymuje obiekt tej drugiej klasy np. jako parametr jednej ze swoich metod.

• Wiąże ze sobą dwa opisy tej samej rzeczy na różnych poziomach abstrakcji.

• W przypadku gdy wiąże typ z klasą realizującą go zwane jest realizacją.

• Może być użyte do modelowania różnych implementacji tej samej rzeczy.

• Czy są jakieś operacje na całości, które są automatycznie stosowane do składowych?

• Jeśli rodzaj obiektu (np. Student) może ulec zmianie (np. z dziennego na zaocznego) bez zmiany reszty atrybutów, to przy dziedziczeniu będzie to wymagało zmiany klasy obiektu!

Czasem mamy wątpliwości, czy w danej sytuacji użyć atrybutu czy asocjacji. Ogólna zasada jest następująca:

• Atrybuty służą do łączenia obiektów z wartościami. Wartość to element nie posiadający identity, np. liczba 1.

• Asocjacje łączą obiekty z obiektami.

Wartości zawsze mogą być zapisane bezpośrednio i odtworzone. Z obiektami jest trudniej, bo należy uwzględnić wszystkie związki.

• Modelu tego używa się przede wszystkim do opracowania specyfikacji wymagań.

• Dwa podstawowe składniki: aktorzy i przypadki użycia.

• Model przypadków użycia wyznacza granice systemu.

  • Najczęściej są to granice budowanego systemu (aplikacji), jednak przypadki użycia służą także do modelowania przedsiębiorstwa (tzw. przypadki biznesowe).

  • Nie należy jednak mieszać tych dwóch podejść w jednym modelu.

• Każdy przypadek to realizacja jakiejś rzeczywistej potrzeby użytkownika (aktora), nazwa przypadku powinna to uwzględniać, a nie opisywać czynności systemu. Wyświetlanie wyników klasówki to zła nazwa, lepszą będzie Przeglądanie wyników klasówki.

• Przypadki użycia powinny odpowiadać kolejnym fragmentom podręcznika użytkownika. Jeśli używamy pakietów do grupowania dużej liczby przypadków użycia, to każdy pakiet odpowiada rozdziałowi podręcznika.

• Scenariusze (opisy) przypadków użycia należy pisać z perspektywy użytkownika, a nie systemu.

• Nie należy tworzyć przypadków użycia zgrupowanych wokół ,,obiektów”, np. Przetwarzanie informacji o studentach. Mają one zwykle za dużo aktorów i zbyt długie specyfikacje.

• Stan stanowi abstrakcję wartości zmiennych (parametrów itp.) obiektu taką, że ich wszystkie te kombinacje dają jednakową jakościowo odpowiedź na zdarzenia.

• Przejścia etykietuje się warunkami, których spełnienie powoduje wskazaną zmianę stanu. Zamiast warunków można też stosować zdarzenia, powodujące wskazaną zmianę stanu.

• Oprócz tego z poszczególnymi przejściami mogą być związane akcje sterujące, uaktywaniające odpowiednie procesy.

• Przy bardziej złożonym zachowaniu stosuje się sieci zagnieżdżone, zwane też diagramami Harela. W sieciach takich każde przejście dotyczące stanu złożonego dotyczy wszystkich jego podstanów wewnętrznych.

• Modelując zachowanie obiektów staramy się pokazać dwie rzeczy: zmiany stanu oraz interakcje z innymi obiektami.

• Robiąc diagramy stanów dla klas trzeba pamiętać, że klasa musi mieć atrybuty lub związki, przez zmianę których realizuje zmianę stanu. Inaczej mówiąc, stany są reprezentowane pośrednio ich wartościami.

• rysowanie diagramów (obejmuje znajmość semantyki symboli i reguł poprawności)

• repozytorium modeli i ich elementów (np. gdy zmienimy nazwę klasy, powinno to być widoczne na wszystkich diagramach)

• wspieranie nawigacji po modelach

• możliwość pracy kilku użytkowników

• generowanie (szkieletu) kodu

• inżynieria odwrotna (reverse engineering)

• integracja z innymi narzędziami

• obsługa poziomów abstrakcji modelu

• wymiana modeli (eksport i import)

• Do zarządzania repozytorium używane są zwykle systemy relacyjnych baz danych, np. SQL Anywhere (Sybase).

• Możliwa jest często inżynieria odwrotna, tzn. wciąganie do modeli analitycznych i projektowych obiektów z już istniejących programów i baz danych.