Upload
tranthu
View
219
Download
0
Embed Size (px)
Citation preview
Plan wykładu 2.
• Modelowanie danych (ERD)
• Normalizacja relacyjnych baz danych
• Modelowanie obiektowe (UML)
• Narzędzia CASE
2
WPROWADZENIE
3
Inżynieria oprogramowania
Niestrukturalizowane tworzenie
oprogramowania
„Kryzys oprogramowania”
Nowy dział informatyki: Inżynieria
oprogramowania (ang. Software
engineering)
1. Projektowanie
2. Implementacja
Inżynieria baz danych
4
Utrzymanie
Wdrożenie
Implementacja
Projektowanie
Analiza
Cykl projektowy systemu informatycznego
5
1. Kaskadowy
2. Typu V
3. Przyrostowy (ewolucyjny)
4. Szybkie prototypowanie (makietowanie)
5. Model spiralny
Modele procesu tworzenia oprogramowania
6
Model kaskadowy
Wymagania i specyfikacja
Projektowanie
Programowanie
Testowanie
Integracja
7
Paradygmaty programowania
• programowanie proceduralne
• programowanie strukturalne
• programowanie funkcyjne
• programowanie imperatywne
• programowanie obiektowe
• programowanie uogólnione
• programowanie sterowane zdarzeniami
• programowanie logiczne (np. Prolog)
• programowanie aspektowe (np. AspectJ)
• programowanie deklaratywne
• programowanie agentowe
• programowanie modularne
8
Obecnie stosowane są dwie główne
metodologie tworzenia systemów
informatycznych:
• Podejście strukturalne – starsze ale
mające wiele zastosowań praktycznych
• Podejście obiektowe – nowsze, znajdujące
coraz większą popularność
Metodologie tworzenia systemów
9
• Język modelowania UML
• Mapowanie obiektowo-relacyjne (ORM)
Obiektowy model danych
10
MODELOWANIE ERD
11
Testowanie systemu
Tworzenie aplikacji
Opracowanie modelu fizycznego
Opracowanie modelu logicznego
Opracowanie konceptualnego modelu danych
Analiza wycinka rzeczywistości
Sformułowanie problemu
Etapy projektowania systemów bazodanowych
12
• Faza analizy
1. Analiza wycinka rzeczywistości
2. Analiza wymagań funkcjonalnych
3. Analiza wymagań niefunkcjonalnych
Model konceptualny
I. Projektowanie (modelowanie)
konceptualne
13
1. Analiza wycinka rzeczywistości
• Wywiad z ekspertem dziedzinowym
14
• Należy zidentyfikować i opisać funkcje,
np.:
– Wprowadzenia, modyfikowanie, usuwanie
danych – operacje CRUD (od ang. Create, Read,
Update i Delete),
– Wyszukiwanie danych,
– Przetwarzanie danych,
– Sporządzanie statystyk,
– Przygotowywanie raportów.
2. Analiza wymagań funkcjonalnych
15
• Na tym etapie opisujemy wszystkie
pozostałe aspekty związane z
opracowywana bazą danych
3. Analiza wymagań niefunkcjonalnych
16
• Tryb pracy (np. graficzny)
• Czy program ma pracować w sieci?
• Platforma sprzętowa (np. procesor Intel i7)
• Platforma systemowa (np. Windows 7)
• Środowisko implementacyjne BD (np. MySQL)
• Środowisko programistyczne (Visual C++)
• Rodzaj bazy danych (np. relacyjna)
• Oszacowanie liczby danych wejściowych,
tempo przyrostu danych
Analiza wymagań niefunkcjonalnych (2)
17
ERD – ang. Entity Relationship Diagram
• ERD jest graficznym odpowiednikiem modelu związków encji ERM
ERM – ang. Entity Relationship Model
EER – ang. Enhanced Entity–Relationship
• ERD pozwala na graficzne zamodelowanie struktur danych oraz relacji pomiędzy nimi.
• Mając diagram ERD korzystając z systemów CASE często mamy możliwość wygenerowania gotowej bazy danych.
Diagram Związków Encji
18
19
Przykład diagramu ERD
19
• Encja – jest „rzeczą”, która w
modelowanym środowisku jest
rozpoznawana jako istniejący niezależnie
obiekt, zdarzenie lub pojęcie
• Związek – reprezentuje powiązania między
encjami, wynikające z opisu
modelowawnego fragmentu rzeczywistości
– Opcjonalność związków
– Krotność związków
ERD – podstawowe pojęcia
20
• 1:1 – jeden do jeden encji odpowiada dokładnie jedna encja
• 1:N – jeden do wiele encji odpowiada jedna lub więcej encji
• N:M – wiele do wiele jednej lub więcej encjom odpowiada jedna lub więcej encji
• W przypadku związków N:M należy dokonać normalizacji diagramu, która polega na dodaniu encji pośredniczącej i zastąpienie związku N:M dwoma związkami 1:N z nową encją.
Liczebność związków:
21
Przykłady diagramów ERD w różnych
notacjach
źródło: pl.wikipedia.org/wiki/Diagram_zwi%C4%85zk%C3%B3w_encji 22
• Model logiczny jest modelem świata
rzeczywistego, wyrażony za pomocą reguł
pewnego architektonicznego modelu
danych.
– Relacyjny model danych
• Transformacja modelu konceptualnego do
modelu logicznego
II. Projektowanie logiczne
23
• Modelowanie fizyczne obejmuje
konstruowanie modelu świata
rzeczywistego wyrażonego za pomocą
struktur danych i mechanizmów dostępu
istniejących w wybranym SZBD.
• Wybór konkretnego SZBD.
III. Projektowanie fizyczne
24
NORMALIZACJA RELACYJNYCH
BAZ DANYCH
25
Normalizacja baz danych
• Proces modyfikacji wybranej relacyjnej
bazy danych według ustalonych zasad.
• Proces ten polega na modyfikacji
schematu bazy danych, a nie na usuwaniu
danych.
• Mówimy o tzw. postaciach normalnych
(ang. Normal Form, NF).
26
W jakim celu normalizujemy?
• Bazy danych normalizujemy w celu
uniknięcia anomalii:
– Redundancji danych – dane powtarzają się w
kilku krotkach,
– Modyfikacji niespójność danych – dana
zostanie zmodyfikowana tylko w jednej
krotce,
– Problemów z dołączaniem i usuwaniem danych
– np. usuwając krotkę możemy stracić pewne
informacje. 27
Etapy normalizacji
28
Pierwsza postać normalna – 1NF
• „Najsłabsza” postać.
• Pierwsza postać normalna mówi o atomowości
danych.
• Wprowadza także pojęcie istnienia klucza
głównego identyfikującego bezpośrednio każdy
unikalny rekord.
• Dziedziny atrybutów elementarne.
• Rozbicie atrybutów na mniejsze czynniki.
29
1NF - przykład
• Brak normalizacji (UNF):
• Zastosowanie 1NF:
Imię i nazwisko Adres
Andrzej Kowalski Wrocław, 54-203, Legnicka 23
Adrian Tomaszewski Gdańsk, 75-400, Traugutta 8
Imię Nazwisko Miasto Kod Ulica Numer
Andrzej Kowalski Wrocław 54-203 Legnicka 23
Adrian Tomaszewski Gdańsk 75-400 Traugutta 8
30
Druga postać normalna (2NF)
• Każdy atrybut, który nie jest kluczowy, jest
w pełni funkcyjnie zależny od każdego
potencjalnego klucza głównego
(kandydującego).
31
2NF - przykład
Imię Nazwisko Płeć Stanowisko Płaca
Antoni Gal Męska Tokarz 2200
Natalia Holender Żeńska Sekretarka 2500
Karolina Gal Żeńska Sekretarka 2500
Antoni Polak Męska Frezer 2300
Imię Nazwisko Stanowisko Płaca
Antoni Gal Tokarz 2200
Natalia Holender Sekretarka 2500
Karolina Gal Sekretarka 2500
Antoni Polak Frezer 2300
Imię Płeć
Antoni Męska
Natalia Żeńska
Karolina Żeńska
1NF
2NF
32
Trzecia postać normalna (3NF)
•Nie występują żadne pola, które nie zależą
od klucza głównego encji.
•Normalizacja do tej postaci polega na
przeniesieniu wszystkich pól niezależnych
od klucza do osobnej encji.
33
3NF - przykład
NrFaktury NazwaKlienta Miasto Kod Ulica Numer
100 Animex Wrocław 54-203 Legnicka 32
101 Animex Wrocław 54-203 Legnica 32
102 Betard Gdańsk 80-827 Długa 3
NrFaktury Nazwa Klienta
100 Animex
101 Animex
102 Betard
NazwaKlienta Miasto Kod Ulica Numer
Animex Wrocław 54-203 Legnicka 32
Betard Gdańsk 80-827 Długa 3
2NF
3NF
34
Wyższe postacie normalne
• 3,5 NF - Postać normalna Boyce’a-Codda
• 4 NF
• 5 NF
35
Wady normalizacji
• Zwiększenie ilości tabel = zmniejszenie
wydajności, poprzez konieczność
wykonywania złączeń przez RDBMS.
• Więc czasami decydujemy się na
denormalizację danych.
• Hurtownia danych jest przykładem
zdenormalizowanej postaci danych.
36
JĘZYK UML
Modelowanie obiektowe
37
Modelowanie obiektowe
• Modelowania systemów informacyjnych z wykorzystaniem podejścia obiektowego i języka UML.
• Zastosowania języka UML w różnych obszarach, od projektowania systemów czasu rzeczywistego poprzez projektowanie baz danych aż po modelowanie systemów biznesowych.
38
Klasa a obiekt klasy
• Obiekt – konkretne wystąpienie abstrakcji
– byt o dobrze określonych granicach i tożsamości
– obejmuje stan i zachowanie
– egzemplarz klasy
• Klasa – opis zbioru obiektów, które mają takie same atrybuty, operacje,
związki i znaczenie
– częściowa lub całkowita definicja dla obiektów
– zbiór wszystkich obiektów mających wspólną strukturę i zachowanie
39
Definicja klasy wraz z kilkoma
obiektami (instancjami klasy)
Źródło: http://www.egrafik.pl/kurs-c-plus-plus/6.1.php 40
UML
• UML (ang. Unified Modeling Language) -
Ujednolicony Język Modelowania
• Aktualna wersja: 2.4.1
41
UML
• Graficzny język do obrazowania, specyfikowania,
tworzenia i dokumentowania elementów
systemów informatycznych.
• Diagramy UML to schematy przedstawiające
zbiór bytów i związków między nimi.
42
Literatura (wybór)
• G. Booch, J. Rumbaugh, I. Jacobson, UML
przewodnik użytkownika, WN-T, Warszawa
2002.
• R. A. Maksimchuk, E. J. Naiburg, UML dla
zwykłych śmiertelników, Warszawa 2007.
• http://www.uml.org/
• http://www.omg.org/spec/UML/
43
Historia UML
• Modelowanie obiektowe w latach 70 i 80
• 1996 r. – dokumentacja wersji 0.9
• 1997 r. – UML 1.0 w gestii Object
Management Group (OMG)
• Wersje: 1.1, 1.2, 1.3, 1.4, 1.4.2 (ta została
poddana standaryzacji ISO/IEC 19501), 1.5, 2.1.1,
2.1.2
• 2012 r. – najnowsza wersja: 2.4.1 (ISO/IEC 19505-1 i 19505-2)
44
45
Zastosowania
• tworzenie systemów informacyjnych przedsiębiorstw,
• usługi bankowe i finansowe,
• przemysł obronnym i lotniczy,
• rozproszone usługi internetowe,
• telekomunikacja,
• transport,
• sprzedaż detaliczna,
• elektronika w medycynie,
• nauka.
45
Diagramy UML
• Diagramy struktury
• Diagramy zachowania (dynamiki)
46
Diagramy UML
Diagramy struktury Diagramy zachowania
Diagramy klas
Diagramy obiektów
Diagramy wdrożenia
Diagramy komponentów
Diagramy przypadków użycia
Diagramy stanów
Diagramy czynności
Diagramy interakcji
Diagramy przebiegu Diagramy kooperacji
Diagramy struktury UML
• Klas
• Obiektów
• Wdrożeniowy
– Komponentów
– Rozlokowania
• Pakietów
• Struktur połączonych
47
źródło: http://www.erudis.pl/pl/node/93
Diagramy dynamiki UML
• Przypadków użycia
• Czynności
• Interakcji
– Sekwencji
– Komunikacji
– Harmonogramowania
– Sterowania interakcją
• Maszyny stanowej
48 źródło: http://www.erudis.pl/pl/node/93
Zastosowania w projektowaniu
systemów informatycznych • Projektując system informatyczny, rozpoczyna się
przeważnie od tworzenia diagramów w następującej kolejności: – Przypadków użycia,
– Klas,
– Czynności,
– Sekwencji.
• Są to najczęściej wykorzystywane diagramy. Pozostałe z nich bywają pomijane, zwłaszcza przy budowaniu niedużych systemów informatycznych.
49
Diagramy przypadków użycia
(Use Case Diagrams) • Definicja:
Diagramy służące do modelowania zachowania systemu. Opisują co system powinien robić z punktu widzenia obserwatora z zewnątrz. Przedstawiają scenariusze realizacji określonych zachowań (funkcji systemu).
• Zawartość: – przypadki użycia (ang. use case) - opisy zdarzeń,
– aktorzy - osoby/rzeczy inicjujące zdarzenia,
– powiązania między aktorami i przypadkami użycia,
– zależności, uogólnienia i powiązania między przypadkami użycia,
– pakiety, notatki i ograniczenia.
• Zastosowania: – modelowanie zachowania bytów - opis ciągu akcji zmierzających do realizacji
danej funkcji systemu,
– modelowanie otoczenia systemu - definiowanie aktorów i ich ról,
– modelowanie wymagań stawianych systemowi – określenie co system powinien robić,
– testowanie systemu.
50
51 51
Diagramy klas (Class Diagrams)
• Definicja:
Schemat przedstawiający zbiór klas, interfejsów, kooperacji oraz związki między nimi.
• Używa się ich do modelowania struktury systemu.
• Stanowią bazę wyjściową dla diagramów komponentów i diagramów wdrożenia.
• Szczególnie przydatne do tworzenia systemów (inżynieria do przodu i wstecz).
• Zawartość: – klasy,
– interfejsy,
– kooperacje,
– zależności, uogólnienia, powiązania,
– notatki, ograniczenia, pakiety, podsystemy.
• Zastosowania: – modelowanie słownictwa systemu (struktura systemu),
– modelowanie prostych kooperacji,
– modelowanie schematu logicznej bazy danych.
52
53
Diagramy czynności
(Activity Diagrams)
• Definicja:
Diagramy czynności (schematy blokowe) przedstawiają przepływ sterowania od czynności do czynności. Większość diagramów czynności przedstawia kroki procesu obliczeniowego.
• Zawartość: – stany akcji i stany czynności,
– przejścia,
– obiekty,
– notatki i ograniczenia.
• Zastosowania: – modelowanie przepływu czynności
– Modelowanie operacji
54
55
Diagramy interakcji
• Definicja:
Diagramy interakcji (ang. Interaction Diagrams) służą do modelowania zachowania systemu. Ilustrują kiedy i w jaki sposób komunikaty przesyłane są pomiędzy obiektami.
• Diagramy przebiegu (ang. Sequence Diagrams)
• Diagramy kooperacji (ang. Collaboration Diagrams)
56
Diagramy interakcji
Na diagramie przebiegu uwypukla się kolejność wysyłania komunikatów w czasie.
Na diagramie kooperacji kładzie się nacisk na związki strukturalne między obiektami wysyłającymi i odbierającymi komunikaty.
Zawartość: – obiekty,
– wiązania,
– komunikaty,
– notatki i ograniczenia.
• Zastosowania: – modelowanie przepływu sterowania z uwzględnieniem
kolejności
– komunikatów w czasie,
– modelowanie przepływu sterowania z uwzględnieniem organizacji strukturalnej obiektów 57
58
Wybrane aplikacje wspomagające
tworzenie diagramów (darmowe) • ArgoUML - napisany w Javie, zaawansowane generowanie
kodu i podpowiedzi, ciągle tworzony,
• StarUML - środowiska modelowania pod platformę Windows,
• Dia - ogólne narzędzie do rysowania diagramów,
• UML Sculptor - prosty, łatwy w użyciu program do tworzenia diagramów klas,
• Umbrello - program dla Linuksa, część KDE,
• UMLpad,
• JUDE Community,
• NetBeans.
59
Wybrane aplikacje wspomagające
tworzenie diagramów (komercyjne)
• Borland Together - rodzina programów integrujących się z różnymi IDE, jest wersja darmowa,
• Poseidon for UML - zaawansowane narzędzie bazujące na ArgoUML, darmowa edycja Community,
• Enterprise Architect - Profesjonalne narzędzie w przystępnej cenie o wygodnym interfejsie działające na platformach Windows i Linux. Wspiera UML 2.0,
• Rodzina programów iGrafx - narzędzia począwszy od iGrafx FlowCharter wspierają tworzenie diagramów UML. Wersja testowa na witrynie iGrafx,
• Visual Paradigm for UML,
• IBM Rational Rose,
• Telelogic Tau G2,
• Visio. 60
Przykłady
• Stanisław Wrycza (red.), UML 2.1,
Ćwiczenia, Helion 2006.
61 61
DPU (ang. Use Case)
62
63
64
65
66
NARZĘDZIA DO MODELOWANIA
BAZ DANYCH
CASE (ang. Computer-Aided Software Engineering)
67
Wybrane narzędzia do modelowania
• Oracle MySQL Workbench
• Oracle SQL Developer Data Modeler
• SAP Sybase PowerDesigner DataArchitect
• IBM Rational Data Architect
• Microsoft Visio
68
Oracle MySQL Workbench
• Narzędzie do zarządzania i modelowania baz
danych MySQL
• Wsparcie dla projektowania baz na poziomach
koncepcyjnym, logicznym i fizycznym
• Wsparcie dla procesów reverse-engineeringu
• Możliwość generowania skryptów SQL
• Wersja: 6.2.5.0
• Licencja: GNU GPLicense lub zamknięta EULA
• http://www.mysql.com/products/workbench
69
MySQL Workbench
70
Oracle SQL Developer Data Modeler
• Zintegrowane środowisko programistyczne
dla użytkowników zajmujących się
programowaniem baz firmy Oracle
• Wersja: 4.0.3.853
• Licencja: zamknięta • http://www.oracle.com/technetwork/developer-
tools/datamodeler/overview/index.html
• http://www.oracle.com/technetwork/developer-
tools/datamodeler/downloads/datamodeler-087275.html
71
Oracle SQL Developer Data Modeler
72
SAP Sybase PowerDesigner DataArchitect
• Narzędzie do modelowania systemów: baz
danych, hurtowni danych, modelowanie
obiektowe, modelowanie procesów
biznesowych i in.
• Wersja: 16.5
• Licencja: zamknięta
• Cena: ~2000 € - ~10000 € źródło: www.powerdesigner.de/en/pricing/
73
SAP Sybase PowerDesigner DataArchitect
74
Porównanie narzędzi
Sebastian Łacheciński, Analiza porównawcza Wybranych narzędzi CASE
do modelowania danych w procesie projektowania relacyjnych baz
danych, (w:) Informatyka Ekonomiczna Business Informatics, nr 1 (31),
2014, s. 239-258.
http://www.dbc.wroc.pl/dlibra/doccontent?id=25198
75
Testom poddane zostały:
• ER Studio XE5 Data Architect 9.7
• CA ERWin 9.5 Workgroup
• SAP Sybase Power Designer 16.5 Data Architect RE
• Oracle SQL Developer Data Modeler 4.0.1
• MySQL Workbench 6.1.4
• MS Visio 2010/2013 Professional
• IBM InfoSphere Data Architect 9.1 76
Wyniki
• Najlepszy: SAP Sybase PowerDesigner 16.5
• Dla darmowych narzędzi najlepszy wynik
osiągnął: Oracle SQL Developer Data
Modeler v. 4
• Dla wdrożeń w oparciu o serwer MySQL
rozsądnym wyborem jest: MySQL
Workbench 6.1.4.
77
DZIĘKUJĘ ZA UWAGĘ
Pytania?