Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych Bartosz Bębel, Krzysztof Jankiewicz Instytut Informatyki, Politechnika.

Podobne prezentacje


Prezentacja na temat: "Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych Bartosz Bębel, Krzysztof Jankiewicz Instytut Informatyki, Politechnika."— Zapis prezentacji:

1 Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych Bartosz Bębel, Krzysztof Jankiewicz Instytut Informatyki, Politechnika Poznańska

2 (C) Instytut Informatyki, Politechnika Poznańska2 Cykl życia systemu informacyjnego Metodyka Oracle CASE (CASE*Method)

3 (C) Instytut Informatyki, Politechnika Poznańska3 Metodyka Oracle CASE – strategia ogólny model przedsiębiorstwa, wymagania, harmonogram prac, ograniczenia finansowe i techniczne,ogólny model przedsiębiorstwa, wymagania, harmonogram prac, ograniczenia finansowe i techniczne, modele:modele: –procesów (PD), –danych (ERD), –funkcji (FHD), –przepływów (DFD).

4 (C) Instytut Informatyki, Politechnika Poznańska4 Metodyka Oracle CASE – analiza uzupełnienie informacji zebranych na etapie strategii, szczegółowe, zaakceptowane modele: –procesów (PD), –danych (ERD), –funkcji (FHD), –przepływów (DFD), diagramy matrycowe.

5 (C) Instytut Informatyki, Politechnika Poznańska5 Metodyka Oracle CASE – projektowanie model danych, struktura logiczna i fizyczna bazy danych, modele aplikacji (formularzy, raportów, itp.)

6 (C) Instytut Informatyki, Politechnika Poznańska6 Metodyka Oracle CASE – implementacja i dokumentacja generacja, modyfikacja i testowanie aplikacji, implementacja + strojenie, dokumentacja użytkownika i techniczna.

7 (C) Instytut Informatyki, Politechnika Poznańska7 Cykl życia systemu informatycznego – Oracle Designer 6i strategia + analiza projektowanie Implementacja dokumentacja

8 Metodyki realizacji projektów informatycznych

9 (C) Instytut Informatyki, Politechnika Poznańska9 Projektowanie SI z wykorzystaniem Designer6i narzędzia do modelowania: PD, ERD, FHD, DFD, struktura logiczna bazy danych (model relacyjny), definicje aplikacji, generowanie obiektów bazy danych i kodu po stronie serwera, generowanie aplikacji. transformacje,

10 (C) Instytut Informatyki, Politechnika Poznańska10 Metodyka RAD (Rapid Application Development) szybkie tworzenie prototypów aplikacji, modyfikowanie prototypów zgodnie z wymaganiami użytkowników, tylko małe systemy, krótki czas od rozpoczęcia projektu do chwili dostarczenia aplikacji użytkownikowi.

11 (C) Instytut Informatyki, Politechnika Poznańska11 Metodyka IE (Information Engineering) technika top-down, główny nacisk na model danych, specyfikacja funkcji przetwarzających dane.

12 (C) Instytut Informatyki, Politechnika Poznańska12 Metodyka PMD (Process Model Driven) często używana jako punkt początkowy dla rozwoju systemów informatycznych, pozwala na identyfikację podstawowych procesów w organizacji przed analizą zakresu informacji potrzebnej do ich realizacji.

13 (C) Instytut Informatyki, Politechnika Poznańska13 Metodyka DCD (Design Capture Driven) stosowana w przypadku istnienia już systemów w przedsiębiorstwie, wykorzystuje mechanizmy reverse-engineering, pozwala na generowanie nowych systemów korzystając ze starych definicji, pozwala realizować nowe potrzeby przedsiębiorstwa przy minimalnych nakładach czasowych i finansowych.

14 Modelowanie procesów

15 (C) Instytut Informatyki, Politechnika Poznańska15 Modelowanie procesów Określa kolejność i miejsce realizacji funkcji przedsiębiorstwa. Umożliwia i ułatwia komunikację pomiędzy: –różnymi działami firmy, –użytkownikami a projektantami, –projektantami a programistami. Pozwala na zrozumienie funkcjonowania organizacji.

16 (C) Instytut Informatyki, Politechnika Poznańska16 Definicja zależności procesów Zależność procesu B od procesu A oznacza, że proces B nie może się rozpocząć dopóki nie zakończy się proces A. Powody zależności: –informacyjne, –produkcyjne, –prawne, –inne. AB

17 (C) Instytut Informatyki, Politechnika Poznańska17 Diagramy zależności procesów (PD – Process Diagram) Struktura i zależności pomiędzy jednostkami organizacyjnymi. Zależności pomiędzy procesami, składnicami, wyzwalaczami i wynikami.

18 (C) Instytut Informatyki, Politechnika Poznańska18 Obiekty diagramu procesów Jednostka organizacyjna Proces Składnica ZależnośćWyzwalacz Wynik

19 (C) Instytut Informatyki, Politechnika Poznańska19 Jednostka organizacyjna (organization unit) Określa miejsce realizacji poszczególnych procesów. Może dotyczyć jednostki organizacyjnej lub osoby o określonych kompetencjach.

20 (C) Instytut Informatyki, Politechnika Poznańska20 Proces (process) Opisuje operację składową działalności przedsiębiorstwa.

21 (C) Instytut Informatyki, Politechnika Poznańska21 Proces (process) Rodzaje procesów: –operacja składowa (process step), –punkt wprowadzania danych (data entry), –punkt decyzyjny (decision point), –raport (report), –zewnętrzny (external), –wewnętrzny (internal).

22 (C) Instytut Informatyki, Politechnika Poznańska22 Przepływ – zależność (flow) Pokazuje przepływy informacyjne i materiałowe oraz zależności czasowe pomiędzy procesami.

23 (C) Instytut Informatyki, Politechnika Poznańska23 Przepływ – zależność (flow) Czy przepływ jest wystarczający do rozpoczęcia realizacji procesu przeznaczenia? Warunek oraz częstość wyboru jednego z wielu przepływów wyjściowych przepływu (dotyczy punktów decyzyjnych).

24 (C) Instytut Informatyki, Politechnika Poznańska24 Przepływ – zależność (flow) Typy przepływów: –przepływ (flow), –temporalny (temporal) – zależność czasowa, –danych (data), –materialny (material).

25 (C) Instytut Informatyki, Politechnika Poznańska25 Wyzwalacz (trigger) Bodziec do podjęcia realizacji określonych procesów. Typy wyzwalaczy: –okresowy (time), –systemowy (system), –inny (other).

26 (C) Instytut Informatyki, Politechnika Poznańska26 Składnica (store) Magazyn informacji (zbiór relacji, arkuszy kalkulacyjnych akt itp.), materiałów lub inny.

27 (C) Instytut Informatyki, Politechnika Poznańska27 Składnica (store) Typy składnic: –informacyjna (data store), –materialna (material store), –ogólna (store).

28 (C) Instytut Informatyki, Politechnika Poznańska28 Wynik (outcome) Jest efektem realizacji sekwencji czynności. Typy wyników: –okresowy (time), –systemowy (system), –inny (other).

29 (C) Instytut Informatyki, Politechnika Poznańska29 Process Modeler Pozwala na: –definiowanie podstawowych procesów zachodzących w przedsiębiorstwie, –modelowanie elementów składowych procesów, –identyfikowanie procesów wymagających usprawnienia – modyfikacji, –modelowanie procesów nie istniejących w przedsiębiorstwie, –włączanie do diagramów obiektów utworzonych w innych składnikach Oracle Designer6i.

30 (C) Instytut Informatyki, Politechnika Poznańska30 Modelowanie elementów składowych procesów

31 (C) Instytut Informatyki, Politechnika Poznańska31 Identyfikacja procesów wymagających reorganizacji

32 (C) Instytut Informatyki, Politechnika Poznańska32 Import istniejących obiektów do diagramów

33 Modelowanie związków encji

34 (C) Instytut Informatyki, Politechnika Poznańska34 Modelowanie związków encji Metoda określania potrzeb informacyjnych firmy lub organizacji. Modelowanie związków encji ma na celu: –Dostarczenie dokładnego modelu potrzeb informacyjnych przedsiębiorstwa, który stanowiłby podstawę do konstruowania nowych lub ulepszonych systemów, –dostarczanie modelu niezależnego od sposobu przechowywania danych i metod dostępu do nich, umożliwiającego podejmowanie decyzji, dotyczących metod implementacji oraz sposobu współdziałania z istniejącymi systemami.

35 (C) Instytut Informatyki, Politechnika Poznańska35 Diagramy związków encji

36 (C) Instytut Informatyki, Politechnika Poznańska36 Obiekty występujące na diagramach związków encji Encja Związki jeden do wiele Związki wiele do wiele Związki jeden do jeden

37 (C) Instytut Informatyki, Politechnika Poznańska37 Encja (entity) Encja – obiekt rzeczywisty lub niematerialny mający znaczenie dla organizacji, o którym informacje muszą być przechowywane.

38 (C) Instytut Informatyki, Politechnika Poznańska38 Encja (entity) Każda encja musi być jednoznacznie identyfikowalna – to znaczy, że każda instancja (wystąpienie) encji musi być wyraźnie odróżnialna od wszystkich innych instancji tego typu encji. Uzyskuje się to poprzez definicję jednoznacznego identyfikatora.

39 (C) Instytut Informatyki, Politechnika Poznańska39 Unikalny identyfikator (unique identifier) Unikalny identyfikator to zbiór atrybutów, końców związków lub związków wykluczających, których wartości pozwalają rozróżnić instancje encji.

40 (C) Instytut Informatyki, Politechnika Poznańska40 Atrybut (attribute) Atrybut – cecha służąca do identyfikacji, klasyfikacji lub wyrażenia stanu encji.

41 (C) Instytut Informatyki, Politechnika Poznańska41 Atrybut (attribute) Wartości jakie mogą być przyjmowane przez atrybuty są ograniczane przez typ, wielkość, i zbiór wartości dopuszczalnych.

42 (C) Instytut Informatyki, Politechnika Poznańska42 Związek (relationship) Związek – nazwane, istotne powiązanie pomiędzy encjami. Każdy związek ma dwa końce, z których każdy ma przypisaną: –nazwę, –stopień/liczebność, –opcjonalność (opcjonalny/wymagany). ZESPÓŁ INSTYTUT Wiele Jeden Wymagany Opcjonalny Związek rekurencyjny składową złożony z

43 (C) Instytut Informatyki, Politechnika Poznańska43 Nazywanie związków Każdy INSTYTUT może być złożony z jednego lub wielu ZESPOŁÓW. Każdy ZESPÓŁ musi być składową jednego i tylko jednego INSTYTUTU.

44 (C) Instytut Informatyki, Politechnika Poznańska44 Dziedzina (domain) Zbiór reguł kontroli poprawności danych, ich formatów, i innych własności stosowanych do definicji atrybutów.

45 (C) Instytut Informatyki, Politechnika Poznańska45 Dziedzina (domain) Wartości dopuszczalne zdefiniowane w ramach domen będą wpływały na zawartość relacji CG_REF_CODES.

46 (C) Instytut Informatyki, Politechnika Poznańska46 Konstrukcje specjalne Związki wykluczające Hierarchie encji Związki nieprzechodnie

47 (C) Instytut Informatyki, Politechnika Poznańska47 Związki wykluczające Występują w postaci łuku łączącego dwa (lub więcej) końce związków dochodzących do tej samej encji. Opisują sytuacje kiedy dla pojedynczej instancji encji może wystąpić tylko jeden ze związków wykluczających. Pracownik zatrudniony jest albo na poziomie instytutu, albo na poziomie zespołu. lub (precyzyjnie) Każdy Pracownik musi być albo zatrudniony w jednym i tylko jednym instytucie albo zatrudniony w jednym i tylko jednym zespole.

48 (C) Instytut Informatyki, Politechnika Poznańska48 Tworzenie związku wykluczającego

49 (C) Instytut Informatyki, Politechnika Poznańska49 Hierarchie encji Hierarchie encji składają się z encji-nadtypu i zawartych w niej encji-podtypów. Podtyp oprócz swoich własnych atrybutów i związków, posiada wszystkie atrybuty, związki i funkcje dziedziczone z encji-nadtypu.

50 (C) Instytut Informatyki, Politechnika Poznańska50 Związki nieprzechodnie Oznaczane są za pomocą rombu przy jednym z końców związku. Instancja encji, przy której istnieje związek nieprzechodni nie może zmieniać przypisania do innej instancji encji wynikającego z tego związku. Zespół raz przypisany do określonego instytutu nie może zostać przeniesiony do innego instytutu (nie może zmienić przypisania).

51 (C) Instytut Informatyki, Politechnika Poznańska51 Entity Relationship Diagrammer Jest narzędziem służącym do modelowania i definiowania potrzeb informacyjnych w postaci diagramów związków encji. Pozwala na: –tworzenie diagramów związków encji, –automatyczny rozkład obiektów na diagramie, –dostęp do narzędzi systemu Oracle Designer powiązanych i weryfikujących związki encji.

52 Modelowanie przepływów danych

53 (C) Instytut Informatyki, Politechnika Poznańska53 Modelowanie przepływu danych Modelowanie przepływu danych (ang. Dataflow Diagrams) ma na celu zobrazowanie procesów zachodzących w organizacji, wymiany informacji między nimi oraz miejsc wprowadzania i wyprowadzania danych.

54 (C) Instytut Informatyki, Politechnika Poznańska54 Diagramy przepływu danych Opisują przepływ informacji pomiędzy funkcjami – procesami realizowanymi w systemie. Reprezentuje wymianę danych między elementami systemu i wymianę danych ze światem zewnętrznym.

55 (C) Instytut Informatyki, Politechnika Poznańska55 Diagramy przepływu danych Są podstawowym narzędziem do wiązania procesów z przetwarzanymi danymi. Na ogólnym poziomie specyfikacji procesów pozwalają wyznaczyć funkcje elementarne oraz te, które wymagają dalszej dekompozycji. Stanowią podstawę do specyfikacji aplikacji. Nie opisują algorytmu przetwarzania danych wewnątrz funkcji. Nie opisują zależności czasowych i kolejnościowych pomiędzy funkcjami. Odzwierciedlają pojedyncze procesy zaznaczając udział i rolę ich poszczególnych składowych.

56 (C) Instytut Informatyki, Politechnika Poznańska56 Obiekty diagramów przepływów danych Proces – funkcja Przepływ Składnica danych Byt zewnętrzny

57 (C) Instytut Informatyki, Politechnika Poznańska57 Składnica danych (datastore) Składnica danych – kolekcja encji i ich atrybutów, które powinny być przechowywane przez określony czas. EtykietaNazwa opisowa

58 (C) Instytut Informatyki, Politechnika Poznańska58 Składnica danych Typy składnic danych: –komputerowe (computer), –papierowe (manual), –inne (transient).

59 (C) Instytut Informatyki, Politechnika Poznańska59 Przepływ danych (dataflow) Przepływ danych jest nazwaną kolekcją encji i ich atrybutów przekazywanych między dwoma procesami, procesem a składnicą lub procesem a bytem zewnętrznym.

60 (C) Instytut Informatyki, Politechnika Poznańska60 Przepływ danych (dataflow) Przepływ danych jest chwilowym przeniesieniem danych. Gdy osiągną one cel (proces) decyzja o tym co się z nimi dalej stanie zależy od procesu przyjmującego. Jeśli odbiorca zignoruje nadchodzące dane zostaną one utracone na zawsze.

61 (C) Instytut Informatyki, Politechnika Poznańska61 Przepływ danych a składnica Gdy przepływ danych dotrze do składnicy danych, jej zawartość jest modyfikowana zawartością przepływu. Może to oznaczać dodanie, modyfikację lub usunięcie danych znajdujących się w składnicy. Składnica danych służy do przechwytywania na stałe chwilowego przepływu danych.

62 (C) Instytut Informatyki, Politechnika Poznańska62 Proces (function) Opisuje składową działalności przedsię- biorstwa.

63 (C) Instytut Informatyki, Politechnika Poznańska63 Przepływ danych a proces Zawartość przepływu wychodzącego z funkcji uzupełnia zawartość ENTITY USAGES dla tej funkcji. Zawartość przepływu wchodzącego do funkcji nie ma wpływu na ENTITY USAGES. Zawartość ENTITY USAGES dla funkcji nie ma żadnego wpływu na zawartość przepływów związanych z tą funkcją.

64 (C) Instytut Informatyki, Politechnika Poznańska64 Byt zewnętrzny (external) Obiekt będący zewnętrznym (poza systemem) źródłem lub odbiorcą informacji. Może reprezentować określoną encję lub jednostkę organizacyjną.

65 (C) Instytut Informatyki, Politechnika Poznańska65 Dataflow Diagrammer Narzędzie służące do rysowania diagramów przepływów danych. Pozwala na: –jednoczesną współpracę wielu użytkowników, –automatyczny rozkład elementów, –dostęp do narzędzi weryfikujących kompletność wykorzystania encji przez funkcje, –przechodzenie do składowych procesów lub procesów znajdujących się wyżej w hierarchii.

66 Modelowanie hierarchii funkcji

67 (C) Instytut Informatyki, Politechnika Poznańska67 Modelowanie hierarchii funkcji Modelowanie hierarchii funkcji tworzy diagramy pokazujące dekompozycję funkcji na różnych poziomach działalności przedsiębiorstwa.

68 (C) Instytut Informatyki, Politechnika Poznańska68 Funkcja (function) Składowa operacja przedsiębiorstwa.

69 (C) Instytut Informatyki, Politechnika Poznańska69 Funkcje specjalnego znaczenia Funkcje wspólne (common function). Funkcje atomowe (atomic function) – funkcje, które nie podlegają dalszej dekompozycji. Funkcje elementarne (elementary function). Funkcje atomowe

70 (C) Instytut Informatyki, Politechnika Poznańska70 Funkcje wspólne Występują w kilku miejscach w hierarchii reprezentując tą samą operację. Pierwsze wystąpienie takiej funkcji nazwane jest funkcją główną (master function), pozostałe wystąpienia to tylko referencje do funkcji głównej. Funkcje wspólne Funkcja główna

71 (C) Instytut Informatyki, Politechnika Poznańska71 Funkcje elementarne Funkcje elementarne pozostawiają system w stanie spójnym, wykonanie funkcji elementarnej, nie będącej funkcją atomową, wymaga pomyślnej realizacji wszystkich jej funkcji podrzędnych.

72 (C) Instytut Informatyki, Politechnika Poznańska72 Function Hierarchy Diagrammer Pozwala na utworzenie diagramu hierarchii funkcji realizowanych przez organizację. Umożliwia: –tworzenie, modyfikację i dekompozycję funkcji, –automatyczne tworzenie podzbiorów dużych i złożonych hierarchii, –określanie sposobu wykorzystania danych przez funkcje, –zwijanie i rozwijanie gałęzi hierarchii, –automatyczną zmianę układu funkcji (pionowy, poziomy, hybrydowy).

73 Repozytorium Oracle Designer 6i

74 (C) Instytut Informatyki, Politechnika Poznańska74 Repozytorium Oracle Designer 6i Repozytorium Oracle Designer 6i jest miejscem składowania wszelkich obiektów tworzonych na diagramach. Dzięki repozytorium obiekty utworzone np. na diagramie zależności procesów można importować do pozostałych diagramów.

75 (C) Instytut Informatyki, Politechnika Poznańska75 Repository Object Navigator Służy do przeglądania i modyfikacji obiektów składowanych w repozytorium Oracle Designer6i. Dla każdego obiektu dostępna jest lista własności.

76 Zależności pomiędzy diagramami

77 (C) Instytut Informatyki, Politechnika Poznańska77 Zależności pomiędzy diagramami Wszystkie trzy metody modelowania procesów i funkcji, tj. konstrukcja diagramów zależności procesów, modelowania przepływów danych i tworzenie hierarchii funkcji przenikają się wzajemnie operując na tych samych obiektach.

78 (C) Instytut Informatyki, Politechnika Poznańska78 Funkcje – procesy

79 (C) Instytut Informatyki, Politechnika Poznańska79 Składnice danych

80 (C) Instytut Informatyki, Politechnika Poznańska80 Przepływy

81 (C) Instytut Informatyki, Politechnika Poznańska81 Hierarchie funkcji

82 Sposoby i wskazówki dotyczące tworzenia diagramów i modeli

83 (C) Instytut Informatyki, Politechnika Poznańska83 Poziomy modelowania systemu informatycznego Poziom przedsiębiorstwa – dotyczy podstawowych obszarów działalności przedsiębiorstwa. Poziom systemu – wyznacza sposób, w jaki wymagania przedsiębiorstwa są lub mogą być realizowane. Funkcje na tym poziomie pokazują czynności pracowników. Poziom programu – pokazuje sposób fizycznej realizacji funkcji systemu przez określone mechanizmy komputerowe, biurowe itp. Funkcje na tym poziomie pokazują elementarne operacje.

84 (C) Instytut Informatyki, Politechnika Poznańska84 Wykorzystanie metod modelowania

85 (C) Instytut Informatyki, Politechnika Poznańska85 Podstawowe podejścia przy modelowaniu funkcji Modelowanie z góry do dołu – polega na dekompozycji kolejnych poziomów rozpoczynając od pojedynczej funkcji głównej reprezentującej działalność przedsiębiorstwa. Modelowanie z dołu do góry – na początku identyfikuje się funkcje przedsiębiorstwa, a następnie dla każdej z nich próbuje się znaleźć odpowiednie miejsce w hierarchii funkcji. Technika mieszana.

86 (C) Instytut Informatyki, Politechnika Poznańska86 Kiedy zakończyć dekompozycję funkcji? Metoda funkcji elementarnych: Hierarchia funkcji jest traktowana jako kompletną, jeżeli przejście od funkcji głównej do funkcji atomowych możliwe jest tylko przez funkcje elementarne.

87 (C) Instytut Informatyki, Politechnika Poznańska87 Mechanizmy Powiązania określonych funkcji ze sposobem ich realizacji. Typy mechanizmów: –myślowy, –komputerowy, –mechaniczny, –ręczny. Unikanie mechanizmów w nazwach i opisach funkcji pozwala budować modele bardziej ogólne. Pobudza do reorganizacji, usprawniania lub wprowadzania nowych metod realizacji określonych zadań.

88 (C) Instytut Informatyki, Politechnika Poznańska88 Tworzenie modeli informacyjnych Warunkiem tworzenia poprawnych i efektywnych modeli informacyjnych jest stosowanie określonych konwencji i zasad. Nie dopuszczają one do powstawania niejednoznaczności i ułatwiają zrozumienie potrzeb informacyjnych przedsiębiorstwa.

89 (C) Instytut Informatyki, Politechnika Poznańska89 Zasady dotyczące encji Każda instancja encji musi być wyraźnie odróżnialna od wszystkich innych instancji tej encji. Każda encja powinna: być związana co najmniej jednym związkiem, posiadać co najmniej dwa atrybuty, być wykorzystywana przez co najmniej jedną funkcję, –po zakończeniu etapu analizy być kompletna informacyjnie.

90 (C) Instytut Informatyki, Politechnika Poznańska90 Zasady dotyczące związków Nazwy pojawiające się na końcach związków powinny tworzyć poprawne konstrukcje zdaniowe z poprzedzającymi je zwrotami musi być dla związków wymaganych lub może być dla związków opcjonalnych. Związek nie może wchodzić w skład więcej niż jednego łuku. Każdy związek po zakończeniu etapu analizy powinien być kompletny informacyjnie.

91 (C) Instytut Informatyki, Politechnika Poznańska91 Nieprawidłowe związki

92 (C) Instytut Informatyki, Politechnika Poznańska92 Zasady dotyczące atrybutów Nazwy atrybutów nie powinny zawierać w sobie nazw encji. Ściśle należy trzymać się reguł normalizacji danych. W uproszczeniu oznacza to, że: w encji nie mogą powtarzać się atrybuty, wartości atrybutów powinny być atomowe, wartość każdego atrybutu powinna zależeć od całości jednoznacznego identyfikatora, wartości atrybutów powinny zależeć tylko od jednoznacznego identyfikatora. Po zakończeniu etapu analizy każdy z atrybutów powinien być informacyjnie kompletny.

93 (C) Instytut Informatyki, Politechnika Poznańska93 Zasady dotyczące związków wykluczających Łuk musi obejmować co najmniej dwa końce związków, a zwykle nie więcej niż trzy lub cztery. Łuki prawie zawsze rysuje się wokół końców wiele związków. Jeśli jeden koniec związku, będącego częścią jednoznacznego identyfikatora encji, znajduje się w łuku, wówczas każdy inny koniec związku w tym łuku musi być również częścią jednoznacznego identyfikatora dla tej encji.

94 (C) Instytut Informatyki, Politechnika Poznańska94 Niepoprawne związki wykluczające Łuki mogą dotyczyć końców związków, które albo wszystkie są obowiązkowe, albo wszystkie opcjonalne. Łuki nie mogą obejmować związków dotyczących różnych encji.

95 (C) Instytut Informatyki, Politechnika Poznańska95 Reguły rozmieszczania elementów na diagramie związków encji Końce związków wiele umieszcza się na górze lub po lewej stronie, dzięki temu obiekty o dużym znaczeniu, służące do opisywania innych obiektów, są grupowane i znajdują się na dole po prawej stronie diagramu. Na diagramach rozmiar i kształt encji nie jest istotny – wszystko ma służyć przejrzystości i czytelności diagramu.

96 (C) Instytut Informatyki, Politechnika Poznańska96 Zamiana związków wiele do wiele Historyczność REZERWACJA # * status * data REZERWACJA # * data STATUS # * wartość # * od dnia ° do dnia Encja intersekcji Encje referencyjne

97 (C) Instytut Informatyki, Politechnika Poznańska97

98 Budowanie bazy danych

99 (C) Instytut Informatyki, Politechnika Poznańska99 Dane wejściowe Diagramy związków encji, a w szczególności: –definicje encji wraz z atrybutami –definicje związków między encjami –definicje dziedzin atrybutów encji Wynik Baza danych projektowanego systemu

100 (C) Instytut Informatyki, Politechnika Poznańska100 Przebieg procesu krok 1.Transformowanie diagramów związków encji do schematu logicznego bazy danych krok 2.Generowanie schematu fizycznego bazy danych

101 (C) Instytut Informatyki, Politechnika Poznańska101 Budowanie bazy danych krok 1. Transformowanie diagramów związków encji do schematu logicznego bazy danych

102 (C) Instytut Informatyki, Politechnika Poznańska102 Reguły transformacji Jak przetransformować: encję? hierarchię encji? związek?

103 (C) Instytut Informatyki, Politechnika Poznańska103 Transformacja encji Encja relacja Atrybut encji kolumna relacji Typ atrybutu typ kolumny Dziedzina atrybutu ograniczenie check Unikalny identyfikator encji klucz podstawowy relacji

104 (C) Instytut Informatyki, Politechnika Poznańska104 Transformacja hierarchii encji Sposoby: –transformacja do pojedynczej relacji –transformacja do oddzielnych relacji –transformacja do oddzielnych relacji połączonych ograniczeniami referencyjnymi w łuku

105 (C) Instytut Informatyki, Politechnika Poznańska105 Sposób pierwszy Zasady: –jedna relacja –schemat relacji: atrybuty wszystkich encji z hierarchii + dodatkowa kolumna, określająca typ specjalizacji Kiedy stosować: –większość atrybutów w nadtypie –większość związków do nadtypu Zalety: –uproszczenie schematu bazy danych Wady: –atrybuty obowiązkowe podtypu stają się kolumnami opcjonalnymi Transformacja hierarchii

106 (C) Instytut Informatyki, Politechnika Poznańska106 Sposób drugi Zasady: –jedna relacja dla każdego podtypu –schemat relacji: atrybuty nadtypu + atrybuty podtypu Kiedy stosować: –większość atrybutów w podtypach –większość związków do podtypów Zalety: –zachowanie obowiązkowości atrybutów w podtypach Wady: –komplikacja schematu –konieczność powielenia kluczy obcych implementujących związki przyłączone do nadtypu Transformacja hierarchii

107 (C) Instytut Informatyki, Politechnika Poznańska107 Sposób trzeci Kiedy stosować: –związki przywiązane zarówno do nadtypu jak i podtypów Zalety: –zachowanie obowiązkowości atrybutów w podtypach –łatwy dostęp do informacji z nadtypu Wady: –komplikacja schematu –konieczność stosowania połączeń (SQL) Zasady: –jedna relacja z atrybutami wspólnymi, dla każdego podtypu osobna relacja z jego atrybutami specyficznymi –relacje połączone kluczami obcymi w łuku Transformacja hierarchii

108 (C) Instytut Informatyki, Politechnika Poznańska108 Transformacja związków Implementacja związku za pomocą ograniczeń referencyjnych (kluczy obcych) Sposób transformacji zależy od parametrów związku: –krotności (1:1, 1:N, M:N) –obowiązkowości/opcjonalności

109 (C) Instytut Informatyki, Politechnika Poznańska109 Związek 1:1 jednostronnie obowiązkowy Zasady: –do relacji impl. encję wiązaną obowiązkowo zostaje dodany klucz obcy, wskazujący na klucz podstawowy relacji impl. encję wiązaną opcjonalnie (z drugiej strony związku) –na kolumny klucza obcego zostaje nałożone ograniczenie not null Transformacja związków TABLICA_A ( ID_APRIMARY KEY, ATR_1 NULL) TABLICA_B ( ID_BPRIMARY KEY, ATR_1NOT NULL ID_ANOT NULL REFERENCES TABLICA_A(ID_A))

110 (C) Instytut Informatyki, Politechnika Poznańska110 Związek 1:1 obustronnie opcjonalny Zasady: –do relacji impl. tą encję ze związku, dla której określono większy średni przyrost wystąpień, zostaje dodany klucz obcy, wskazujący na klucz podstawowy z relacji impl. drugą encję w związku –na kolumny klucza obcego nałożone zostaje ograniczenie null Transformacja związków

111 (C) Instytut Informatyki, Politechnika Poznańska111 Związek 1:N Zasady: –do relacji impl. encję po stronie N związku zostaje dodany klucz obcy, wskazujący na klucz podstawowy relacji impl. encję po stronie 1 związku –obowiązkowość związku po stronie N - ograniczenie not null na kolumny w kluczu obcym –opcjonalność związku po stronie N - ograniczenie null na kolumny w kluczu obcym –obowiązkowość/opcjonalność związku po stronie 1 nie ma wpływu na transformację Transformacja związków TABLICA_A ( ID_APRIMARY KEY, ATR_1 NULL ID_BNOT NULL REFERENCES TABLICA_B(ID_B)) TABLICA_B ( ID_BPRIMARY KEY, ATR_1NOT NULL)

112 (C) Instytut Informatyki, Politechnika Poznańska112 Związek M:N Zasady: –zostaje utworzona nowa relacja –w nowej relacji zostają utworzone klucze obce, wskazujące na klucze podstawowe relacji w związku –kolumny obu kluczy obcych tworzą klucz podstawowy relacji Transformacja związków TABLICA_A ( ID_APRIMARY KEY, ATR_1 NULL) TABLICA_B ( ID_BPRIMARY KEY, ATR_1NOT NULL) TABLICA_A_B ( ID_ANOT NULL REFERENCES TABLICA_A(ID_A), ID_BNOT NULL REFERENCES TABLICA_B(ID_B), PRIMARY KEY(ID_A, ID_B))

113 Proces transformacji

114 (C) Instytut Informatyki, Politechnika Poznańska114 Krok 1. Uruchomić narzędzie Database Design Transformer z grupy Transform Preliminary Designs Proces transformacji

115 (C) Instytut Informatyki, Politechnika Poznańska115 Krok 2 - opcje transformacji –transformacja wg ustawień domyślnych –transformacja wg ustawień użytkownika Proces transformacji

116 (C) Instytut Informatyki, Politechnika Poznańska116 Dostępne ustawienia Proces transformacji wybór encji do transformacji - domyślnie wszystkie sposób transformacja hierarchii - domyślnie do jednej relacji wybór typów tworzonych elementów (relacje, kolumny, klucze, indeksy) - domyślnie wszystkie wybór typów modyfikowanych elementów (istniejących już w repozytorium relacji, kolumn, kluczy, indeksów) - domyślnie żadne

117 (C) Instytut Informatyki, Politechnika Poznańska117 Dostępne ustawienia (2) Proces transformacji opcje ograniczeń referencyjnych: –usuwanie kaskadowe - domyślnie zabronione –modyfikowanie kaskadowe - domyślnie zabronione tworzenie sztucznych kluczy podstawowych relacji (w postaci dodatkowej kolumny numerycznej) - domyślnie tylko dla encji bez unikalnych identyfikatorów przedrostek nazw relacji - domyślnie brak przedrostki nazw kolumn (na podstawie krótkich nazw encji) - domyślnie brak

118 (C) Instytut Informatyki, Politechnika Poznańska118 Krok 3 - uruchomienie procesu Uruchomienie transformacji - przycisk Run Proces transformacji

119 (C) Instytut Informatyki, Politechnika Poznańska119 Wynik Proces transformacji Umieszczone repozytorium systemu definicje: relacji kolumn ograniczeń integralnościowych indeksów liczników - dla sztucznych kluczy podstawowych

120 (C) Instytut Informatyki, Politechnika Poznańska120 Wynik (2) Proces transformacji Podgląd definicji w repozytorium - narzędzie Design Editor z grupy Design and Generate

121 (C) Instytut Informatyki, Politechnika Poznańska121 Design Editor Umożliwia: –przeglądanie i ręczną modyfikację powstałego w wyniku transformacji schematu logicznego bazy danych –definiowanie dodatkowych obiektów schematu logicznego: liczników perspektyw kodu PL/SQL –utworzenie diagramu schematu modelu relacyjnego - pokazuje połączenia między relacjami (ograniczenia referencyjne)

122 (C) Instytut Informatyki, Politechnika Poznańska122 Przeglądanie i modyfikacja schematu logicznego Zakładka Server Model, gałęzie: Design Editor Relational Table Definitions - relacje, kolumny, ograniczenia itegralnościowe, inne Relational View Definition - perspektywy Sequence Definitions - liczniki PL/SQL Definitions - kod składowany

123 (C) Instytut Informatyki, Politechnika Poznańska123 Tworzenie diagramu schematu logicznego Z menu kontekstowego wybrać Show on New Diagram Design Editor Zaznaczyć obiekty (relacje lub perspektywy), które mają być uwidocznione na diagramie

124 (C) Instytut Informatyki, Politechnika Poznańska124 Przykładowy diagramu schematu logicznego Design Editor

125 (C) Instytut Informatyki, Politechnika Poznańska125 Jak to zrobić? Jak przetransformować hierarchię encji w sposób inny niż domyślny?

126 (C) Instytut Informatyki, Politechnika Poznańska126 Transformacja do oddzielnych relacji krok 1. Uruchomić Database Design Transformer krok 2. Zaznaczyć opcję Customize the Database Transformer i wybrać zakładkę Table Mappings Jak to zrobić - hierarchia encji

127 (C) Instytut Informatyki, Politechnika Poznańska127 Transformacja do oddzielnych relacji krok 3. Zmienić zbiór encji do transformacji - wyłączyć ze zbioru encję-nadtyp, dodać encje- podtypy Jak to zrobić - hierarchia encji

128 (C) Instytut Informatyki, Politechnika Poznańska128 Transformacja do oddzielnych relacji Jak to zrobić - hierarchia encji krok 4. Przystąpić do transformacji Wynik:

129 (C) Instytut Informatyki, Politechnika Poznańska129 Transformacja do relacji w łuku krok 1. Uruchomić Database Design Transformer krok 2. Zaznaczyć opcję Customize the Database Transformer i wybrać zakładkę Table Mappings Jak to zrobić - hierarchia encji

130 (C) Instytut Informatyki, Politechnika Poznańska130 Transformacja do relacji w łuku krok 3. Zmienić zbiór encji do transformacji - włączyć do zbioru encję-nadtyp wraz z encjami-podtypami Jak to zrobić - hierarchia encji

131 (C) Instytut Informatyki, Politechnika Poznańska131 Transformacja do relacji w łuku Jak to zrobić - hierarchia encji krok 4. Zmienić typ elementów do transformacji - zakładka Run Options - tylko definicje relacji (bez kolumn i ograniczeń integralnościowych) krok 5. Uruchomić transformację. Wygenerowane zostaną jedynie definicje relacji. Pozostać w narzędziu

132 (C) Instytut Informatyki, Politechnika Poznańska132 Transformacja do relacji w łuku Jak to zrobić - hierarchia encji krok 6. Przy encjach-podtypach zaznaczyć opcję Arc krok 7. Zmienić typ elementów do transformacji - zakładka Run Options - wszystkie elementy

133 (C) Instytut Informatyki, Politechnika Poznańska133 Transformacja do relacji w łuku Jak to zrobić - hierarchia encji krok 8. Przystąpić do transformacji Wynik:

134 (C) Instytut Informatyki, Politechnika Poznańska134 Budowanie bazy danych krok 2. Generowanie schematu fizycznego bazy danych

135 (C) Instytut Informatyki, Politechnika Poznańska135 Przebieg procesu krok 1. Uruchomić narzędzie Design Editor. Przejść na zakładkę Server Model, rozwinąć gałąź systemu aplikacji Generacja bazy danych krok 2. Wybrać pozycję Generate Database from Server Model z menu Generate

136 (C) Instytut Informatyki, Politechnika Poznańska136 Przebieg procesu krok 3. Ustalić parametry generacji - zakładka Target: Generacja bazy danych Cel generacji: –skrypty DDL (różne formaty) –wskazany użytkownik bazy danych Oracle –baza danych ODBC Lokalizacja skryptów

137 (C) Instytut Informatyki, Politechnika Poznańska137 Przebieg procesu krok 4. Wybrać obiekty do generacji - zakładka Objects: Generacja bazy danych Typ obiektu: –relacje –liczniki –perspektywy i inne Konkretny obiekt

138 (C) Instytut Informatyki, Politechnika Poznańska138 Przebieg procesu krok 5. Uruchomić proces - przycisk Start Wynik - w zależności od parametrów generacji: skrypty DDL we wskazanym katalogu obiekty w schemacie wskazanego użytkownika obiekty w bazie danych przyłączonej za pomocą ODBC Generacja bazy danych

139 Budowanie aplikacji

140 (C) Instytut Informatyki, Politechnika Poznańska140 Dane wejściowe Diagramy hierarchii funkcji i przepływów danych, a w szczególności: –definicje funkcji –sposób użycia encji przez funkcje –przepływy z i do funkcji Wynik Definicje aplikacji w wybranym języku programowania

141 (C) Instytut Informatyki, Politechnika Poznańska141 Przebieg procesu krok 1.Transformowanie definicji funkcji do projektów aplikacji krok 2.Modyfikacja struktury aplikacji krok 3.Generowanie aplikacji w wybranym języku programowania

142 (C) Instytut Informatyki, Politechnika Poznańska142 Budowanie aplikacji krok 1. Transformowanie definicji funkcji do projektów aplikacji

143 (C) Instytut Informatyki, Politechnika Poznańska143 Reguły transformacji 1.Które funkcje transformować? 2.Co wpływa na wybór typu aplikacji, która powstanie z funkcji? 3.Jak znaleźć funkcje, które mogą być zaimplementowane przez tą samą aplikację? - łączenie funkcji

144 (C) Instytut Informatyki, Politechnika Poznańska144 Które funkcje transformować? Reguły transformacji Kandydatami do transformacji są: –liście hierarchii bez przodków, będących funkcjami elementarnymi lub wspólnymi –funkcje wspólne –funkcje elementarne

145 (C) Instytut Informatyki, Politechnika Poznańska145 Które funkcje transformować? Reguły transformacji

146 (C) Instytut Informatyki, Politechnika Poznańska146 Co wpływa na typ aplikacji? Reguły transformacji Typy aplikacji: –formularz (ang. Screen) - odczytuje i modyfikuje dane z relacji –wydruk (ang. Report) - tylko odczytuje dane z relacji –aplikacja użytkowa (ang. Utility) - może to być biblioteka, funkcja i procedura składowana, pakiet

147 (C) Instytut Informatyki, Politechnika Poznańska147 Co wpływa na typ aplikacji? (2) Reguły transformacji Jak określić typ aplikacji? –na podstawie zestawu operacji, jakie transformowana funkcja realizuje na encjach –na podstawie własności Reakcja (ang. Response) funkcji (ang. Immediate - Natychmiastowa, ang. Overnight - Odroczona)

148 (C) Instytut Informatyki, Politechnika Poznańska148 Co wpływa na typ aplikacji? (3) Reguły transformacji Zasady: –encje, których używa funkcja, nie zostały zaimplementowane jako relacje - typ aplikacji nieokreślony (musi zostać wskazany przez projektanta) –własność Reakcja określono na Natychmiastowa - typ aplikacji to formularz –funkcja realizuje tylko operacje odczytu na encjach, zaimplementowanych jako relacje - typ aplikacji to wydruk, –własność Reakcja określono na Odroczona - typ aplikacji to aplikacja użytkowa –w pozostałych przypadkach - typ aplikacji to formularz

149 (C) Instytut Informatyki, Politechnika Poznańska149 Łączenie funkcji Reguły transformacji Kryteria: –łącz funkcje przetwarzające ten sam zestaw encji –łącz funkcje przetwarzające ten sam zestaw encji i wykonujące ten sam zestaw operacji na encjach –łącz funkcje używające tych samych atrybutów encji

150 Proces transformacji

151 (C) Instytut Informatyki, Politechnika Poznańska151 Krok 1. Uruchomić narzędzie Application Design Transformer z grupy Transform Preliminary Designs Proces transformacji

152 (C) Instytut Informatyki, Politechnika Poznańska152 Krok 2. - ustawienie parametrów Proces transformacji wybór funkcji w hierarchii, od której rozpocznie się transformacja - Start Function przedrostek nazwy aplikacji - Module Prefix początkowy numer - będzie tworzył nazwę aplikacji w połączeniu z przedrostkiem - Start number domyślne języki implementacji aplikacji poszczególnych typów - Language (np. Oracle Forms, Oracle Reports, Visual Basic, itd.) kryteria łączenia funkcji - Merge Granularity

153 (C) Instytut Informatyki, Politechnika Poznańska153 Krok 3. - uruchomienie procesu Uruchomienie transformacji - przycisk Generate Proces transformacji

154 (C) Instytut Informatyki, Politechnika Poznańska154 Wynik Proces transformacji Umieszczone w repozytorium systemu definicje modułów- kandydatów na aplikacje Przeglądanie struktury - Design Editor, zakładka Modules, gałąź Modules

155 (C) Instytut Informatyki, Politechnika Poznańska155 Budowanie aplikacji krok 2. Modyfikacja struktury aplikacji

156 (C) Instytut Informatyki, Politechnika Poznańska156 Struktura aplikacji - składniki moduł - reprezentuje aplikację tabela bazowa - wskazuje relację, którą przetwarza aplikacja; przechowuje informacje o dopuszczalnych operacjach na relacji tabela look-up - uzupełnia dane z tabeli bazowej o dane z relacji powiązanej za pomocą ograniczeń referencyjnych; zawiera elementy związane wyświetlające dane z tej relacji powiązania między tablicami bazowymi lub między tablicą bazową a tablicą look-up - modelują hierarchię

157 (C) Instytut Informatyki, Politechnika Poznańska157 Struktura aplikacji - składniki (2) element związany - wskazuje na kolumny relacji, którą przetwarza aplikacja; grupowane w tabeli bazowej lub look-up; najczęściej służą do wyświetlania danych z kolumn relacji element niezwiązany - wyświetla informacje wyliczane, nie ma odpowiednika w schemacie relacji; nie wskazuje na żadną kolumnę w relacji komponent - grupuje elementy w strukturze (tabele bazowe, elementy związane i niezwiązane) okna argument aplikacji - wartość przesyłana do aplikacji po jej uruchomieniu lub zapisywana przez aplikację przy jej zakończeniu; służą do komunikacji pomiędzy aplikacjami

158 (C) Instytut Informatyki, Politechnika Poznańska158 Struktura aplikacji - składniki (3) Każdy element struktury posiada listę własności, określających m.in.: –nazwę elementu –typ elementu (np. grupa radiowa, lista, itd.) –dopuszczalne operacje, itd.

159 (C) Instytut Informatyki, Politechnika Poznańska159 Diagramy struktury aplikacji Tworzenie - menu kontekstowego danej aplikacji wybrać Show on New Diagram\ Rodzaje –widok danych - pokazuje wewnętrzną strukturę aplikacji –widok interfejsu - pokazuje układ interfejsu aplikacji Przełączanie pomiędzy widokami - przyciski

160 (C) Instytut Informatyki, Politechnika Poznańska160 Diagramy struktury aplikacji (2) widok danych widok interfejsu moduł podrzędna tabela bazowa tabela look-up element związany komponent element niezwiązany powiązania okno zawartość okna element interfejsu nadrzędna tabela bazowa

161 Proces modyfikacji struktury aplikacji

162 (C) Instytut Informatyki, Politechnika Poznańska162 Struktura aplikacji po transformacji jedna tabela bazowa dla każdej relacji, implementującej encję używaną przez funkcję elementy związane, odpowiadające kolumnom relacji argumenty aplikacji, odpowiadające atrybutom z przepływów wejściowych i wyjściowych funkcji brak powiązań między tabelami bazowymi brak tabel look-up brak elementów niezwiązanych

163 (C) Instytut Informatyki, Politechnika Poznańska163 Krok 1. Zaakceptowanie modułów-kandydatów jako aplikacji do ostatecznej generacji - ustawienie własności Candidate? na No. Wybór języka implementacji aplikacji. Proces modyfikacji struktury kandydat formularz wydruk aplikacja użytkowa

164 (C) Instytut Informatyki, Politechnika Poznańska164 Krok 2. Utworzenie związków pomiędzy tabelami bazowymi modelują hierarchię nadrzędny- podrzędny korzystają z definicji ograniczeń referencyjnych między relacjami Metody: tworzenie automatyczne tworzenie ręczne Proces modyfikacji struktury

165 (C) Instytut Informatyki, Politechnika Poznańska165 Krok 2. - wynik Proces modyfikacji struktury

166 (C) Instytut Informatyki, Politechnika Poznańska166 Krok 3. Utworzenie związku typu look-up Proces modyfikacji struktury

167 (C) Instytut Informatyki, Politechnika Poznańska167 Krok 4. Określenie własności poszczególnych składników struktury, np. zmiana typu elementu Proces modyfikacji struktury

168 (C) Instytut Informatyki, Politechnika Poznańska168 Krok 5. - dodanie elementu niezwiązanego Podział ze względu na źródło danych: –funkcja agregujące (MIN, MAX, SUM, AVG, COUNT) - Computed (wyliczany) –funkcja składowana na serwerze - Server Side Function –funkcja aplikacji - Client Side Function –wyrażenie wykorzystujące funkcje SQL, np. TO_DATE, TO_CHAR, LTRIM, itd. - SQL Expression Przykład - dodanie elementu niezwiązanego LICZBA_PRACOWNIKÓW - oblicza, ilu pracowników jest zatrudnionych w danym zespole Proces modyfikacji struktury

169 (C) Instytut Informatyki, Politechnika Poznańska169 Krok 5a) Dodanie elementu: Proces modyfikacji struktury

170 (C) Instytut Informatyki, Politechnika Poznańska170 Krok 5b) Proces modyfikacji struktury Określenie własności:

171 (C) Instytut Informatyki, Politechnika Poznańska171 Krok 5. - Wynik Proces modyfikacji struktury

172 (C) Instytut Informatyki, Politechnika Poznańska172 Budowanie aplikacji krok 3. Generowanie aplikacji

173 (C) Instytut Informatyki, Politechnika Poznańska173 Warunki wstępne Uporządkowana struktura aplikacji Dostępny schemat fizyczny bazy danych, na którym ma pracować aplikacja

174 (C) Instytut Informatyki, Politechnika Poznańska174 Preferencje generacji Zbiór ustawień, określających: –sposób implementacji struktury –sposób pracy aplikacji –wygląd elementów interfejsu –układ elementów interfejsu Ustawiane dla: –całego systemu aplikacji –konkretnej aplikacji –konkretnego elementu

175 (C) Instytut Informatyki, Politechnika Poznańska175 Preferencje generacji (2) Wyświetlanie zbioru preferencji: –całego systemu aplikacji –konkretnej aplikacji

176 Proces generacji aplikacji

177 (C) Instytut Informatyki, Politechnika Poznańska177 Krok 1. Uruchomić generator aplikacji Proces generacji aplikacji lub

178 (C) Instytut Informatyki, Politechnika Poznańska178 Krok 2. Ustawić parametry - przycisk Options: Proces generacji aplikacji –lokalizacja wersji źródłowych aplikacji (system plików czy baza danych) –lokalizacja wersji wykonywalnych –czy aplikacja ma zostać uruchomiona po generacji

179 (C) Instytut Informatyki, Politechnika Poznańska179 Krok 3. Uruchomić proces - przycisk Start Proces generacji aplikacji Przebieg procesu, komunikaty

180 (C) Instytut Informatyki, Politechnika Poznańska180 Wynik Proces generacji aplikacji

181 (C) Instytut Informatyki, Politechnika Poznańska181 Uwagi Proces generacji ma najczęściej charakter cykliczny: –pierwsza generacja –zmiana preferencji –kolejna generacja, itd. aż do uzyskania maksymalnie funkcjonalnej aplikacji Nie opłaca się kontynuować tego procesu aż do wygenerowania w pełni funkcjonalnej aplikacji. Proces generacji aplikacji

182 (C) Instytut Informatyki, Politechnika Poznańska182


Pobierz ppt "Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych Bartosz Bębel, Krzysztof Jankiewicz Instytut Informatyki, Politechnika."

Podobne prezentacje


Reklamy Google