Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych

1. Wykorzystanie oprogramowania Oracle Designer do budowy systemów informatycznych Bartosz Bębel, Krzysztof JankiewiczInstytut Informatyki, Politechnika Poznańska Bartosz.Bebel@cs.put.poznan.pl Krzysztof.Jankiewicz@cs.put.poznan.pl

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

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

4. 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. (C) Instytut Informatyki, Politechnika Poznańska

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

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

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

8. Metodyki realizacji projektów informatycznych

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

10. 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. (C) Instytut Informatyki, Politechnika Poznańska

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

12. 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. (C) Instytut Informatyki, Politechnika Poznańska

13. 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. (C) Instytut Informatyki, Politechnika Poznańska

14. Modelowanie procesów

15. 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. (C) Instytut Informatyki, Politechnika Poznańska

16. 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. A B (C) Instytut Informatyki, Politechnika Poznańska

17. 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. (C) Instytut Informatyki, Politechnika Poznańska

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

19. Jednostka organizacyjna (organization unit) • Określa miejsce realizacjiposzczególnych procesów. • Może dotyczyć jednostki organizacyjnejlub osoby o określonych kompetencjach. (C) Instytut Informatyki, Politechnika Poznańska

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

21. 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). (C) Instytut Informatyki, Politechnika Poznańska

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

23. 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). (C) Instytut Informatyki, Politechnika Poznańska

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

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

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

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

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

29. 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. (C) Instytut Informatyki, Politechnika Poznańska

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

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

32. Import istniejących obiektówdo diagramów (C) Instytut Informatyki, Politechnika Poznańska

33. Modelowanie związków encji

34. Modelowaniezwią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. (C) Instytut Informatyki, Politechnika Poznańska

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

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

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

38. 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. (C) Instytut Informatyki, Politechnika Poznańska

39. 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. (C) Instytut Informatyki, Politechnika Poznańska

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

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

42. 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). Związek (relationship) składową ZESPÓŁ złożony z INSTYTUT Jeden Wiele Związek rekurencyjny Wymagany Opcjonalny (C) Instytut Informatyki, Politechnika Poznańska

43. 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. (C) Instytut Informatyki, Politechnika Poznańska

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

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

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

47. 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. Związki wykluczające (C) Instytut Informatyki, Politechnika Poznańska

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

49. 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. (C) Instytut Informatyki, Politechnika Poznańska

50. 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). Związki nieprzechodnie (C) Instytut Informatyki, Politechnika Poznańska