Inżynieria oprogramowania wykład VI Faza analizy Analiza strukturalna modelowanie procesów, słownik danych
|
|
- Ryszard Góra
- 5 lat temu
- Przeglądów:
Transkrypt
1 Inżynieria oprogramowania wykład VI Faza analizy Analiza strukturalna modelowanie procesów, słownik danych prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO
2 Faza analizy systemowej c.d. Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza Instalacja Dokumentacja Przypomnienie: Celem tej fazy jest udzielenie odpowiedzi na pytanie: jak system ma działać? W wyniku fazy analizy otrzymujemy logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujący jeszcze od szczegółów implementacyjnych. K. Bartecki, Inżynieria oprogramowania, VI/2
3 Modelowanie procesów Diagram Przepływu Danych (ang. Data Flow Diagram, DFD) pokazuje, w jaki sposób dane przepływają w systemie oraz opisuje procesy służące do przetwarzania tych danych, opisany jest za pomocą określonej notacji, zbudowany jest przy użyciu odpowiednich narzędzi CASE, bazuje na hierarchicznej dekompozycji funkcji systemu, używany jest do wnioskowania o przyszłym oprogramowaniu,. unika terminologii implementacyjnej. K. Bartecki, Inżynieria oprogramowania, VI/3
4 Składniki diagramu DFD terminatory (obiekty zewnętrzne), procesy, magazyny (składnice) danych, przepływy danych. Uwaga: w wykładzie przedstawiono notację graficzną Yourdona- DeMarco (istnieją również inne notacje). K. Bartecki, Inżynieria oprogramowania, VI/4
5 TERMINATOR Terminator (ang. Terminator), inna nazwa: Encja zewnętrzna (ang. External Entity) reprezentuje źródło lub miejsce przeznaczenia informacji, które jest zewnętrzne w stosunku do sytemu, może być to np. osoba, dział urzędu, firma, inny system komputerowy, maszyna, lub inny obiekt znajdujący się na zewnątrz systemu, nazwa terminatora, to rzeczownik w liczbie pojedynczej, np. KLIENT, DZIAŁ SPRZEDAŻY, URZĄD SKARBOWY, DOSTAWCA. K. Bartecki, Inżynieria oprogramowania, VI/5
6 Inne właściwości terminatora Jest obiektem generującym lub przyjmującym strumienie danych, przepływy łączące terminatory z różnymi składowymi modelu reprezentują interfejsy pomiędzy systemem a światem zewnętrznym, leży poza zakresem odpowiedzialności projektowanego systemu, analityk/projektant systemu nie może zmieniać zawartości terminatora, w modelu DFD nie pokazuje się przepływów danych między terminatorami, nawet jeśli takie w rzeczywistości istnieją. K. Bartecki, Inżynieria oprogramowania, VI/6
7 PROCES Proces (ang. Process) realizuje transformację danych wejściowych w dane wynikowe odpowiada tym składnikom systemu, które przetwarzają dane, otrzymuje i przesyła dane za pośrednictwem przepływów danych, kojarzy się z procedurą, której specyfikacja może być przedstawiona przy użyciu innych technik strukturalnych, nazwa procesu, to rzeczownik odczasownikowy + dopełnienie, np. WYSTAWIENIE FAKTURY, PRZYJĘCIE TOWARU, OBLICZENIE PŁAC, dla celów porządkowych proces może być oznaczony numerem. K. Bartecki, Inżynieria oprogramowania, VI/7
8 Magazyn danych (ang. Data store) magazyn danych reprezentuje miejsce, w którym przez pewien czas określone dane są przechowywane, jest dostępny tylko dla procesów, tzn. nie może być połączony bezpośrednio z terminatorem lub z innym magazynem, istnienie magazynu danych w diagramie ma sens, gdy przechowywane dane służą do realizacji co najmniej dwóch procesów, z których jeden zapisuje w magazynie dane, a drugi je odczytuje, nazwa magazynu danych to rzeczownik w liczbie mnogiej, np. klienci, faktury, towary, studenci, grupy, pracownicy, nazwy magazynów, takie jak rejestr faktur, archiwum zleceń, baza pojazdów nie są zalecane, lepiej po prostu: faktury, zlecenia, pojazdy. dla celów porządkowych magazyn danych może być oznaczony numerem. K. Bartecki, Inżynieria oprogramowania, VI/8
9 Cel istnienia magazynu Umożliwienie przechowywania danych w sytuacji, gdy: dane są używane nie od razu po wytworzeniu, dana jest kilkakrotnie odczytywana, dane są używane w innej kolejności niż były wytworzone. Przykład: SKŁADANIE PODAŃ ROZPATRYWANIE PODAŃ podania K. Bartecki, Inżynieria oprogramowania, VI/9
10 Inne właściwości magazynu danych Przepływ wychodzący z magazynu interpretowany jest jako odczyt (R) zawartej w nim informacji, zamówienie Realizacja najstarszego zamówienia zamówienia przepływ do magazynu interpretowany jest jako zapis (C), modyfikacja (U) lub usunięcie (D) danych z magazynu, klient Rejestracja klienta klienci K. Bartecki, Inżynieria oprogramowania, VI/10
11 Inne właściwości magazynu danych c.d. jeśli przepływ reprezentujący operację na magazynie nie ma etykiety, oznacza to, że operacja ta dotyczy wielu/wszystkich pakietów danych (np. odczytywane są wszystkie rekordy zapisane w magazynie), jeśli etykieta na przepływie jest taka sama jak na magazynie, ale w liczbie pojedynczej, oznacza to, że operacja dotyczy pojedynczego wystąpienia pakietu (jednego rekordu), zamówienie Sortuj zamówienia zamówienia Realizacja najstarszego zamówienia zamówienia K. Bartecki, Inżynieria oprogramowania, VI/11
12 Inne właściwości magazynu danych c.d. jeśli etykieta (etykiety) przepływu jest inna niż nazwa magazynu, oznacza to, że pobierany jest jeden (lub więcej) fragmentów jednego lub większej liczby pakietów: zrealizowane data zamówienia zmiana statusu zamówienia zamówienia policz dzisiejsze zamówienia zamówienia zawartość magazynu nie ulega zmianie w wyniku odczytu z magazynu pobierana jest kopia pakietu, a stan magazynu pozostaje bez zmiany. K. Bartecki, Inżynieria oprogramowania, VI/12
13 przepływ danych Przepływ danych (ang. Data flow) opisuje strumień danych o określonej zawartości, przepływający pomiędzy dwoma składnikami DFD: terminatorem a procesem (lub odwrotnie), procesem a innym procesem, procesem a magazynem danych (lub odwrotnie). nazwa przepływu to rzeczownik w liczbie pojedynczej np. kwestionariusz osobowy, umowa, faktura dla klienta, potwierdzenie transakcji. K. Bartecki, Inżynieria oprogramowania, VI/13
14 Inne właściwości przepływu danych Przepływ danych nie odpowiada na wiele pytań proceduralnych, np.: kiedy wchodzi do procesu, czy jest wynikiem zapytania systemu, czy istnieje jakaś współzależność pomiędzy przepływem wchodzącym a wychodzącym, jeśli przekazywana jest informacja zwrotna, można używać kolejnych linii lub strzałek dwukierunkowych. wniosek wniosek PRZYJMOWANIE WNIOSKÓW potwierdzenie PRZYJMOWANIE WNIOSKÓW potwierdzenie K. Bartecki, Inżynieria oprogramowania, VI/14
15 zamówienie nazwisko i adres klienta adres dostawy potwierdzenie zamówienia PRZYJĘCIE ZAMÓWIENIA błędne zamówienie prośba o potwierdzenie zamówienie do realizacji przepływy wejściowe proces przepływy wyjściowe K. Bartecki, Inżynieria oprogramowania, VI/15
16 Przykład przepływu rozbieżnego (te same dane dostarczane są do kilku różnych procesów) K. Bartecki, Inżynieria oprogramowania, VI/16
17 Przykład przepływu rozbieżnego (pakiet danych dzielony jest na kilka różnych składowych) K. Bartecki, Inżynieria oprogramowania, VI/17
18 Przykłady różnych notacji stosowanych na diagramach DFD nazwa Yourdon- DeMarco Gane- Sarson SSADM KLIENT terminator KLIENT KLIENT KLIENT terminator powtórzony przepływ danych faktura faktura faktura K. Bartecki, Inżynieria oprogramowania, VI/18
19 1 KALKULACJA CEN 1 proces KALKULACJA CEN KALKULACJA CEN KALKULACJA CEN * proces elementarny 1 KALKULACJA CEN proces wielokrotny magazyn danych faktury faktury D1 D1 faktury faktury magazyn powtórzony K. Bartecki, Inżynieria oprogramowania, VI/19
20 Błędne konstrukcje na diagramach DFD Typowe błędy przy tworzeniu diagramów DFD wynikają z: użycia niewłaściwych nazw dla składników diagramu, niewłaściwego łączenia komponentów, użycia procesów duchów i procesów studni, niewłaściwego bilansowania przepływów w przypadku dekompozycji, niezgodności diagramu przepływu danych z diagramem związków encji. K. Bartecki, Inżynieria oprogramowania, VI/20
21 Błędne nazwy składników diagramu Cel raport roczny drukowanie raporu rocznego Szef raport roczny drukowanie raporu rocznego Niewłaściwa nazwa terminatora Klient wprowadzanie danych rejestracja danych Klient infomacja o kliencie rejestracja danych Niewłaściwa nazwa przepływu danych K. Bartecki, Inżynieria oprogramowania, VI/21
22 Kontrahent dane kontrahenta Kowalski Kontrahent dane kontrahenta przygotowanie umowy Niewłaściwa nazwa procesu rejestracja p łatności termin zap łaty FV 345/2004 rejestracja p łatności termin zap łaty faktury Niewłaściwa nazwa magazynu danych K. Bartecki, Inżynieria oprogramowania, VI/22
23 Niewłaściwe łączenie komponentów Dostawca Klient Kontrahent faktura zakupu Towary Niedopuszczalne połączenie dwóch terminatorów Niedopuszczalne połączenie terminatora z magazynem faktury klienci Niedopuszczalne połączenie dwóch magazynów K. Bartecki, Inżynieria oprogramowania, VI/23
24 Procesy duchy i procesy studnie oferta tworzenie rejestru sprzeda ży zamówienie klienta rejestracja zam ówień rejestr sprzeda ży Proces bez przepływów wyjściowych ( studnia ) Proces bez przepływów wejściowych ( duch ) K. Bartecki, Inżynieria oprogramowania, VI/24
25 Dekompozycja procesów diagramy hierarchiczne Umieszczenie na jednym poziomie wszystkich procesów skutkowałoby powstaniem nieczytelnego diagramu ze zbyt dużą liczbą procesów, przepływów, magazynów danych. Z tego względu modelowanie przepływów danych polega zazwyczaj na stworzeniu hierarchicznej, wielopoziomowej grupy diagramów DFD. K. Bartecki, Inżynieria oprogramowania, VI/25
26 W skład hierarchicznego DFD wchodzą następujące poziomy diagramów: diagram kontekstowy definiujący zakres i granice systemu, diagram systemowy (diagram poziomu zerowego) pokazujący główne funkcje systemu, diagramy szczegółowe (procesów elementarnych) ukazujący podział głównych procesów systemu, rozłożonych na podprocesy: diagramy poziomu 1, ew. diagramy poziomu 2, itd. K. Bartecki, Inżynieria oprogramowania, VI/26
27 Diagram kontekstowy to szczególny przypadek DFD, na którym cały modelowany system reprezentowany jest przez pojedynczy proces, diagram ten ma na celu przedstawienie powiązań systemu ze środowiskiem zewnętrznym (terminatorami), system powiązany jest z terminatorami za pomocą przepływów danych, z lub do danego terminatora może wypływać/wpływać bardzo wiele różnych przepływów, dlatego dla większej czytelności diagramu, dopuszcza się powielanie terminatorów. K. Bartecki, Inżynieria oprogramowania, VI/27
28 Przykładowy diagram kontekstowy K. Bartecki, Inżynieria oprogramowania, VI/28
29 Przykładowy diagram kontekstowy K. Bartecki, Inżynieria oprogramowania, VI/29
30 Przykładowy diagram kontekstowy K. Bartecki, Inżynieria oprogramowania, VI/30
31 Diagram systemowy (zerowego poziomu) przedstawia główne funkcje, kluczowe dla modelowanego systemu, stanowi najbardziej ogólne spojrzenie na wnętrze systemu, zawiera kilka procesów (2-8), terminatory oraz magazyny danych. K. Bartecki, Inżynieria oprogramowania, VI/31
32 Przykładowy diagram kontekstowy (po lewej) oraz odpowiadający mu diagram systemowy (po prawej) K. Bartecki, Inżynieria oprogramowania, VI/32
33 Przykładowy diagram kontekstowy (u góry) oraz odpowiadający mu diagram systemowy (na dole) K. Bartecki, Inżynieria oprogramowania, VI/33
34 Przykładowy diagram systemowy K. Bartecki, Inżynieria oprogramowania, VI/34
35 Diagramy szczegółowe przedstawiają procesy, na które dekomponowany ( rozkładany ) jest każdy z procesów diagramu systemowego, proces o numerze 1. z diagramu systemowego dekomponowany jest na podprocesy o numerach 1.1, 1.2, 1.3, itd., proces 2. na podprocesy 2.1, 2.2, 2.3, itd., na kolejnym poziomie dekompozycji proces 1.1 może być rozłożony na podprocesy 1.1.1, 1.1.2, itd., dekompozycję prowadzi się tak długo, aż otrzymamy procesy elementarne. K. Bartecki, Inżynieria oprogramowania, VI/35
36 DK Przykładowa hierarchia diagramów przepływu danych K. Bartecki, Inżynieria oprogramowania, VI/36
37 Przykładowy diagram systemowy (po lewej) oraz diagram pierwszego poziomu dla procesu 1.0 (po prawej) K. Bartecki, Inżynieria oprogramowania, VI/37
38 Zasady tworzenia diagramów wielopoziomowych Prosty system powinien mieć nie więcej niż 2-3 poziomy, średni 3-5 poziomów, duży do 8 poziomów, liczba procesów na jednym diagramie nie powinna być większa niż 6-8, nie wszystkie procesy muszą być rozwijane do tej samej liczby poziomów (różny stopień złożoności), obiekty, które łączą się z dekomponowanym procesem za pomocą przepływów (terminatory, magazyny, inne procesy) muszą wystąpić na poziomie niższym, diagramy powinny być zbalansowane (zrównoważone). K. Bartecki, Inżynieria oprogramowania, VI/38
39 Metody rozwijania hierarchicznych DFD są analogiczne, jak w przypadku tworzenia hierarchii wymagań funkcjonalnych (patrz wykład 4): z góry na dół (top-down), z dołu do góry (bottom-up), mieszane. W metodzie z góry na dół rozpoczynamy budowę od diagramu kontekstowego i drogą kolejnych uszczegółowień (dekompozycji) procesów dochodzimy do rozwiązania końcowego w postaci procesów atomowych (elementarnych). W metodzie z dołu do góry najpierw tworzy się listę niezależnych procesów, które nie będą dalej dekomponowane. Następnie grupuje się je do postaci procesów wyższego rzędu, aż do otrzymania diagramu kontekstowego. K. Bartecki, Inżynieria oprogramowania, VI/39
40 Bilansowanie (równoważenie) diagramów DFD Hierarchiczne diagramy DFD powinny być zbilansowane, czyli zrównoważone względem kolejnych poziomów dekompozycji, wszystkie przepływy, które pojawiły się na diagramie poziomu wyższego, powinny się znaleźć na diagramie poziomu niższego, na niższym poziomie pojawiają się dodatkowe przepływy pomiędzy pomiędzy nowymi procesami, które pojawiły się w wyniku dekompozycji procesów wyższego poziomu, ewentualnie także między procesami i lokalnymi magazynami danych danego procesu. K. Bartecki, Inżynieria oprogramowania, VI/40
41 a b c a d e f b d c f e Równoważenie diagramu DFD K. Bartecki, Inżynieria oprogramowania, VI/41
42 Równoważenie diagramu DFD K. Bartecki, Inżynieria oprogramowania, VI/42
43 Równoważenie diagramu przepływu danych (DFD) względem diagramu związków encji (ERD) Każdy magazyn danych na DFD musi odpowiadać encji na ERD, nazwy encji na ERD oraz nazwy magazynów danych na DFD muszą sobie odpowiadać (np. encja: KLIENT, magazyn danych: KLIENCI), jeżeli są na diagramie DFD magazyny danych nie mające swojego odpowiednika na diagramie ERD, model należy poprawić. jeżeli są na diagramie ERD encje nie mające swojego odpowiednika na diagramie DFD, model należy poprawić, na diagramie DFD powinny istnieć procesy, realizujące operacje tworzenia, odczytu oraz usuwania instancji każdej z encji (rekordu, elementu magazynu danych). K. Bartecki, Inżynieria oprogramowania, VI/43
44 Specyfikacja procesów stanowi algorytmiczną definicję procesu, czyli opisuje, co dzieje się wewnątrz procesu w celu przekształcenia danych wejściowych w dane wyjściowe, tworzona jest dla procesów elementarnych (atomowych), czyli dla procesów na najniższym poziomie diagramu przepływu danych, stanowi możliwie precyzyjny i jednoznaczny opis czynności wykonywanych przez proces, istnieje wiele sposobów specyfikowania procesów, np. opis w języku strukturalnym (tzw. pseudokod), opis warunków zachodzących przed i po wykonaniu procesu, drzewo lub tablica decyzyjna, wzory matematyczne. K. Bartecki, Inżynieria oprogramowania, VI/44
45 Przykład specyfikacji procesu w formie pseudokodu K. Bartecki, Inżynieria oprogramowania, VI/45
46 Przykład specyfikacji procesu w formie pseudokodu SERWISANCI potwierdzenie wykonania 1.3 POTWIERDZENIE WYKONANIA status wykonania Zlecenia data ostatniego przeglądu wysłanie rachunku Przeglądy KLIENCI GET potwierdzenie wykonania FROM TERMINATOR Serwisanci AS potwierdzenie IF (potwierdzenie) { SEND wysłanie rachunku TO TERMINATOR Klienci SET data ostatniego przeglądu AS aktualna data SAVE data ostatniego przeglądu TO STORE Przeglądy SET status wykonania AS wykonane SAVE status wykonania TO STORE Zlecenia } K. Bartecki, Inżynieria oprogramowania, VI/46
47 Przykład specyfikacji procesu w formie pseudokodu KIEROWNICTWO raport 1.5 TWORZENIE RAPORTÓW Zlecenia IF (data systemowa > 27 danego miesiąca) { FOR Serwisanci { DO { } FIND (Serwisant, data realizacji, status) FROM STORE Zlecenia IF (data realizacji = bieżący miesiąc AND status = wykonane) WHILE TRUE } SEND raport TO TERMINATOR Kierownictwo K. Bartecki, Inżynieria oprogramowania, VI/47
48 Przykład specyfikacji procesu w formie opisu warunków zachodzących przed i po wykonaniu procesu K. Bartecki, Inżynieria oprogramowania, VI/48
49 Przykład specyfikacji procesu w formie tablicy i drzewa K. Bartecki, Inżynieria oprogramowania, VI/49
50 Macierz CRUD jest tabelą, odwzorowującą związki pomiędzy procesami a magazynami danych lub pomiędzy procesami a danymi elementarnymi. Nazwa macierzy pochodzi od pierwszych liter operacji wykonywanych przez procesy na magazynach lub elementach danych: C Create, w przypadku zapisu danych, R Read, w przypadku odczytu danych, U Update, w przypadku modyfikacji danych, D Delete, w przypadku usuwania danych. K. Bartecki, Inżynieria oprogramowania, VI/50
51 Nagłówkami kolumn macierzy CRUD są nazwy procesów, a nagłówkami wierszy nazwy magazynów lub elementów danych, natomiast na przecięciu kolumn i wierszy występują odpowiednie litery oznaczające wykonywaną operację. Analizując zawartość macierzy można przeprowadzić dodatkową kontrolę modelu pod kątem wykorzystania magazynów danych. Możliwe jest zarówno stworzenie jednej macierzy CRUD dla wszystkich procesów (na wszystkich poziomach dekompozycji), jak również oddzielnych macierzy dla poszczególnych poziomów. W praktyce magazyny danych najczęściej oznaczają tablice relacyjnej bazy danych, w odniesieniu do których wykonywane są standardowe instrukcje języka SQL: zapis (INSERT), odczyt (SELECT), aktualizacja (UPDATE), kasowanie (DELETE). K. Bartecki, Inżynieria oprogramowania, VI/51
52 Przykładowa macierz CRUD K. Bartecki, Inżynieria oprogramowania, VI/52
53 Przykładowa macierz CRUD K. Bartecki, Inżynieria oprogramowania, VI/53
54 Przykładowy diagram DFD System rejestracji studentów Diagram kontekstowy K. Bartecki, Inżynieria oprogramowania, VI/54
55 Diagram systemowy (zerowego poziomu) K. Bartecki, Inżynieria oprogramowania, VI/55
56 Diagram szczegółowy (pierwszego poziomu) dla procesu 4. K. Bartecki, Inżynieria oprogramowania, VI/56
57 Przykładowy diagram DFD diagram systemowy K. Bartecki, Inżynieria oprogramowania, VI/57
58 Diagram pierwszego poziomu dla procesu 1.1 K. Bartecki, Inżynieria oprogramowania, VI/58
59 Diagram pierwszego poziomu dla procesu 1.2 K. Bartecki, Inżynieria oprogramowania, VI/59
60 Diagram pierwszego poziomu dla procesu 1.3 K. Bartecki, Inżynieria oprogramowania, VI/60
61 Diagram pierwszego poziomu dla procesu 1.4 K. Bartecki, Inżynieria oprogramowania, VI/61
62 Słownik danych Nie jest możliwe zamodelowanie wymagań użytkownika bez zdefiniowania danych występujących w systemie. Dlatego oprócz diagramu związków encji (ERD) oraz diagramu przepływu danych (DFD), w skład modelu strukturalnego wchodzi również słownik danych (ang. data dictionary). Słownik danych to szczegółowy, uporządkowany wykaz wszystkich danych, występujących w projektowanym systemie. K. Bartecki, Inżynieria oprogramowania, VI/62
63 Zawartość słownika danych W słowniku danych opisywane są: pakiety danych przenoszonych przez przepływy na diagramach DFD, pakiety danych zawartych w magazynach na diagramach DFD, odpowiadających encjom z diagramu ERD, wraz i ich atrybutami. K. Bartecki, Inżynieria oprogramowania, VI/63
64 Pełna definicja elementu danych powinna określać: znaczenie elementu danych w kontekście aplikacji użytkownika, na ogół w formie komentarza, budowę elementu danych, zbiór wartości, jakie może przyjmować element danych, w przypadku danych elementarnych, czyli niepodlegających dekompozycji. Słownik danych powstaje na etapie analizy wymagań dotyczących systemu, nie zaś na etapie projektowania fizycznej implementacji. Dlatego uwzględnia on istnienie elementów danych, a nie ich postać fizyczną np. pensja to siedem cyfr dziesiętnych z dwoma miejscami po przecinku. K. Bartecki, Inżynieria oprogramowania, VI/64
65 Notacja słownika danych Istnieje wiele różnych notacji słownika danych, ale jednym z najprostszych i najpopularniejszych jest schemat składający się z następujących operatorów: = jest złożony z + i () element opcjonalny {} element powtarzalny (iteracja) [ ] wybór z możliwości alternatywnych rozdzielenie możliwości alternatywnych ** początek i zakończenie komentarza (tzw. minispecyfikacji elementu identyfikator K. Bartecki, Inżynieria oprogramowania, VI/65
66 Fragment przykładowego słownika danych cyfra = [ ] litera = [a...z A...Z] znak = # $ % & * ( ) _ + - = { } [ ] ; < >,.? / ^ ] Dostawca + Nazwa + Adres + ( ) + Telefon + Osoba = 1{cyfra}8 ** Nazwa = Nazwa firmy ** Nazwa = {litera} ** Adres = Adres firmy ** Adres = Ulica + Numer budynku + (Numer lokalu) + Kod + Miejscowość Ulica = {litera} Numer budynku = {cyfra} + (litera) Numer lokalu = {cyfra} + (litera) K. Bartecki, Inżynieria oprogramowania, VI/66
67 Fragment przykładowego słownika danych c.d. ** Kod = Kod pocztowy ** Kod = cyfra + cyfra + znak - + cyfra + cyfra + cyfra Miejscowość = {litera} = {litera + (znak. znak _)} + + {litera + (znak. znak _)} Telefon = (znak ( + {cyfra} + znak )) + {cyfra} ** Osoba kontaktowa = Osoba odpowiedzialna za kontakty z obsługą systemu ** Osoba kontaktowa = Imię + (Drugie imię) + Nazwisko Imię = {litera} Drugie imię = {litera} Nazwisko = {litera} Cena towaru = Id towaru + Cena netto + VAT + Ilość dla upustu + Upust + Data ważności ** Id towaru = Identyfikator towaru, którego dotyczy kalkulacja ceny ** Id towaru = {cyfra} Cena netto = {cyfra} + znak, + cyfra + cyfra K. Bartecki, Inżynieria oprogramowania, VI/67
68 Fragment przykładowego słownika danych c.d. ** VAT = Wielkość podatku VAT naliczanego dla danego towaru ** VAT = {cyfra} **Ilość dla upustu = Minimalna liczba sztuk towaru gwarantująca upust cenowy** Ilość dla upustu = {cyfra} ** Upust = Wartość określająca, o ile procent zmniejszy się cena w przypadku upustu ** Upust = {cyfra} ** Data ważności = Data końcowa obowiązywania kalkulacji cenowej dla danego towaru w formacie dd-mm-rrrr ** Data ważności = cyfra + cyfra + znak - + cyfra + cyfra + znak - + cyfra + cyfra + cyfra + cyfra K. Bartecki, Inżynieria oprogramowania, VI/68
69 Przykładowa lista elementów danych modelu encji w programie PowerDesigner K. Bartecki, Inżynieria oprogramowania, VI/69
MODELOWANIE PRZEPŁYWU DANYCH
MODELOWANIE PRZEPŁYWU DANYCH 1. Diagram przepływu danych (DFD) 2. Weryfikacja modelu strukturalnego za pomocą DFD Modelowanie SI - GHJ 1 Definicja i struktura DFD Model części organizacji rozważany z punktu
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoWymagania klienta mogą być opisane na różnych poziomach abstrakcji: Podział wymagań: Wymagania funkcjonalne Wymagania niefunkcjonalne
Definiowanie wymagań Wymagania klienta mogą być opisane na różnych poziomach abstrakcji: 1. Definicja wymagań jest zapisana w języku naturalnym jako rezultat rozmów z przedstawiciela klienta 2. Specyfikacja
Bardziej szczegółowoDiagramy przepływu danych I
Literatura bazowa: Projektowanie systemów informatycznych Zajęcia: Diagramy przepływu danych I E.Yourdon, Współczesna analiza strukturalna, WNT, Warszawa 1996 J.Roberston, S.Robertson, Pełna analiza systemowa,
Bardziej szczegółowoDiagram Przepływu Danych - podstawowe bloki składowe i reguły konstrukcji
Diagramu Przepływu danych - CELE Określenie kluczowych obiektów zewnętrznych będących w interakcji z firmą (systemem); Określenie kluczowych procesów występujących w firmie; Określenie sposobu przepływu
Bardziej szczegółowoProjektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)
Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II) Jacek Cichosz www.zssk.pwr.wroc.pl Katedra Systemów i Sieci Komputerowych Politechnika Wrocławska Narzędzia modelowania
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Bardziej szczegółowoNarzędzia szczegółowe - diagramy. specyfikacje procesów (pseudokod).
Projektowanie systemów informatycznych - konspekt do zajęć z tematów: Strukturalna metodyka projektowania SI. Narzędzia szczegółowe - diagramy przepływu danych, słowniki danych, specyfikacje procesów (pseudokod).
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoBazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,
Bazy Danych Modele danych Krzysztof Regulski WIMiIP, KISiM, regulski@agh.edu.pl Cele modelowania Strategia informatyzacji organizacji Cele informatyzacji Specyfikacja wymagań użytkownika Model procesów
Bardziej szczegółowoPodstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko
Podstawowe pojęcia dotyczące relacyjnych baz danych mgr inż. Krzysztof Szałajko Czym jest baza danych? Co rozumiemy przez dane? Czym jest system zarządzania bazą danych? 2 / 25 Baza danych Baza danych
Bardziej szczegółowoAnaliza strukturalna systemów informatycznych
Analiza strukturalna systemów informatycznych Modelowanie i analiza systemów informatycznych, w4 Dr inż. Walery Susłow walery.suslow@ie.tu.koszalin.pl Metodyki tworzenia systemów informatycznych (TSI)
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoAPIO. W7 SPECYFIKACJA (UŻYCIA) DOSTĘPU DO DANYCH I SPOSOBU ICH PRZETWARZANIA 1. METODA CRUD 2. LOGIKA FUNKCJI
APIO. W7 SPECYFIKACJA (UŻYCIA) DOSTĘPU DO DANYCH I SPOSOBU ICH PRZETWARZANIA 1. METODA CRUD 2. LOGIKA FUNKCJI dr inż. Grażyna Hołodnik-Janczura W8/K4 CO SIĘ MOŻE DZIAĆ PODCZAS WYKONYWANIA BIZNESOWEJ FUNKCJI
Bardziej szczegółowoTworzenie prostego diagramu przepływu danych (DFD) z wykorzystaniem modułu Business Process Model pakietu Power Designer 15
K.Bartecki, 2015 1 Ćwiczenie 1 Tworzenie prostego diagramu przepływu danych (DFD) z wykorzystaniem modułu Business Process Model pakietu Power Designer 15 Celem ćwiczenia jest zapoznanie się z możliwościami
Bardziej szczegółowoPrzepływy danych. Oracle Designer: Modelowanie przepływów danych. Diagramy przepływów danych (1) Diagramy przepływów danych (2)
Przepływy danych Oracle Designer: Modelowanie przepływów danych Cele: zobrazowanie funkcji zachodzących w organizacji, identyfikacja szczegółowych informacji, przetwarzanych przez funkcje, pokazanie wymiany
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoZasady organizacji projektów informatycznych
Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych
Bardziej szczegółowoModelowanie KONCEPCJA. przedstawiana przez INDYWIDUALNOŚĆ GHJ 6
Modelowanie KONCEPCJA staje się zrozumiała wyrażona za pomocą INDYWIDUALNOŚĆ przedstawiana przez SYMBOL GHJ 6 Podejścia w modelowaniu Pełny zakres WSTĘPUJĄCE Opuszczone szczegóły ZSTĘPUJĄCE Niepotrzebne
Bardziej szczegółowoProjektowanie bazy danych przykład
Projektowanie bazy danych przykład Pierwszą fazą tworzenia projektu bazy danych jest postawienie definicji celu, założeń wstępnych i określenie podstawowych funkcji aplikacji. Każda baza danych jest projektowana
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoPrzykłady normalizacji
Przykłady normalizacji Nr faktury Za okres Nabywca Usługa Strefa czasowa od 21113332437 1.11.2007 30.11.2007 Andrzej Macioł, Kraków ul. Armii Krajowej 7 21113332437 1.11.2007 30.11.2007 Andrzej Macioł,
Bardziej szczegółowoZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH ZSE - Systemy baz danych 2 rzeczywistość uzyskanie od użytkowników początkowych informacji i wymagań dotyczących przetwarzania danych analiza
Bardziej szczegółowoIII. Dane podstawowe definiowanie organizacji
Ćwiczenia z użytkowania systemu MFG/PRO 1 III. Dane podstawowe definiowanie organizacji 1.1.1 Kartoteka kodów statusów zapasów Kod statusu zapasów określa parametry statusu zapasów w zakresie: Dostępne
Bardziej szczegółowoBazy danych 2. dr inż. Tadeusz Jeleniewski
Wykład 4 Projektowanie bazy danych i procesów aplikacji Modelowanie reguł przetwarzania Środowisko przykładowego programu do modelowania reguł przetwarzania Reguły poprawności 2018-02-23 Bazy danych 2
Bardziej szczegółowoStrukturalne metodyki projektowania systemûw informatycznych
Strukturalne metodyki projektowania systemûw informatycznych Kalendarium 1976 ó Chen P. (Entity Relationship Model ñ ERD ) 1978 ó DeMarco T. 1979 ó Yourdon E., Constantine L. 1983 ó Jackson M. 1989 ñ Yourdon
Bardziej szczegółowoTechnologia informacyjna
Technologia informacyjna Pracownia nr 9 (studia stacjonarne) - 05.12.2008 - Rok akademicki 2008/2009 2/16 Bazy danych - Plan zajęć Podstawowe pojęcia: baza danych, system zarządzania bazą danych tabela,
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów
Bardziej szczegółowoBAZY DANYCH LABORATORIUM. Studia niestacjonarne I stopnia
BAZY DANYCH LABORATORIUM Studia niestacjonarne I stopnia Gdańsk, 2011 1. Cel zajęć Celem zajęć laboratoryjnych jest wyrobienie praktycznej umiejętności tworzenia modelu logicznego danych a nastepnie implementacji
Bardziej szczegółowoZasady transformacji modelu DOZ do projektu tabel bazy danych
Zasady transformacji modelu DOZ do projektu tabel bazy danych A. Obiekty proste B. Obiekty z podtypami C. Związki rozłączne GHJ 1 A. Projektowanie - obiekty proste TRASA # * numer POZYCJA o planowana godzina
Bardziej szczegółowoPodstawowy Wykład z Systemów Baz Danych
Bazy Danych Wykład I Wprowadzenie Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.Widom Copyrights by Arkadiusz Rzucidło 1 Definicje Baza danych to uporządkowany zbiór danych,
Bardziej szczegółowoBaza danych. Modele danych
Rola baz danych Systemy informatyczne stosowane w obsłudze działalności gospodarczej pełnią funkcję polegającą na gromadzeniu i przetwarzaniu danych. Typowe operacje wykonywane na danych w systemach ewidencyjno-sprawozdawczych
Bardziej szczegółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoDFD Diagram przepływu danych (Data Flow Diagram) dr Tomasz Ordysiński
DFD Diagram przepływu danych (Data Flow Diagram) dr Tomasz Ordysiński DFD - definicja Jedną z metod wykorzystywanych na etapie analizy i projektowania służących do modelowania funkcji systemu jest Diagram
Bardziej szczegółowoBazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych
Plan wykładu Bazy danych Wykład 9: Przechodzenie od diagramów E/R do modelu relacyjnego. Definiowanie perspektyw. Diagramy E/R - powtórzenie Relacyjne bazy danych Od diagramów E/R do relacji SQL - perspektywy
Bardziej szczegółowoDiagramy czynności. Widok logiczny. Widok fizyczny
Diagramy czynności System widoków 4+1 Kruchtena Widok logiczny Widok fizyczny Widok procesu Widok przypadków użycia Widok konstrukcji Diagramy czynności są jedynym diagramem w widoku procesu modelowanego
Bardziej szczegółowoPOLITECHNIKA OPOLSKA
POLITECHNIKA OPOLSKA WYDZIAŁ MECHANICZNY Katedra Technologii Maszyn i Automatyzacji Produkcji Laboratorium Podstaw Inżynierii Jakości Ćwiczenie nr 2 Temat: Schemat blokowy (algorytm) procesu selekcji wymiarowej
Bardziej szczegółowoProjektowanie Systemów Informacyjnych
Projektowanie Systemów Informacyjnych Wykład II Encje, Związki, Diagramy związków encji, Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.Widom Copyrights by Arkadiusz Rzucidło
Bardziej szczegółowoSystemy informatyczne. Modelowanie danych systemów informatycznych
Modelowanie danych systemów informatycznych Diagramy związków encji Entity-Relationship Diagrams Modelowanie danych diagramy związków encji ERD (ang. Entity-Relationship Diagrams) diagramy związków encji
Bardziej szczegółowo2017/2018 WGGiOS AGH. LibreOffice Base
1. Baza danych LibreOffice Base Jest to zbiór danych zapisanych zgodnie z określonymi regułami. W węższym znaczeniu obejmuje dane cyfrowe gromadzone zgodnie z zasadami przyjętymi dla danego programu komputerowego,
Bardziej szczegółowoKrzysztof Kadowski. PL-E3579, PL-EA0312,
Krzysztof Kadowski PL-E3579, PL-EA0312, kadowski@jkk.edu.pl Bazą danych nazywamy zbiór informacji w postaci tabel oraz narzędzi stosowanych do gromadzenia, przekształcania oraz wyszukiwania danych. Baza
Bardziej szczegółowoAutor: Joanna Karwowska
Autor: Joanna Karwowska W bazie danych przechowujemy tylko niektóre informacje o świecie rzeczywistym. Wybór właściwych wycinków rzeczywistości i dotyczących ich danych jest bardzo istotny od niego zależy
Bardziej szczegółowoAPIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.
APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI. dr inż. Grażyna Hołodnik-Janczura W8/K4 ZDARZENIA BIZNESOWE W otoczeniu badanego zakresu
Bardziej szczegółowoDiagramy związków encji. Laboratorium. Akademia Morska w Gdyni
Akademia Morska w Gdyni Gdynia 2004 1. Podstawowe definicje Baza danych to uporządkowany zbiór danych umożliwiający łatwe przeszukiwanie i aktualizację. System zarządzania bazą danych (DBMS) to oprogramowanie
Bardziej szczegółowoTransformacja modelu ER do modelu relacyjnego
Transformacja modelu ER do modelu relacyjnego Wykład przygotował: Robert Wrembel BD wykład 4 (1) 1 Plan wykładu Transformacja encji Transformacja związków Transformacja hierarchii encji BD wykład 4 (2)
Bardziej szczegółowoPOLITECHNIKA OPOLSKA
POLITECHNIKA OPOLSKA WYDZIAŁ MECHANICZNY Katedra Technologii Maszyn i Automatyzacji Produkcji Laboratorium Podstaw Inżynierii Jakości Ćwiczenie nr 2 Temat: Schemat blokowy (algorytm) procesu selekcji wymiarowej
Bardziej szczegółowoUniwersytet Zielonogórski Instytut Sterowania i Systemów Informatycznych Bazy Danych - Projekt. Zasady przygotowania i oceny projektów
Uniwersytet Zielonogórski Instytut Sterowania i Systemów Informatycznych Bazy Danych - Projekt Zasady przygotowania i oceny projektów 1 Cel projektu Celem niniejszego projektu jest zaprojektowanie i implementacja
Bardziej szczegółowoDiagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między
Bardziej szczegółowoWykład 2. Relacyjny model danych
Wykład 2 Relacyjny model danych Wymagania stawiane modelowi danych Unikanie nadmiarowości danych (redundancji) jedna informacja powinna być wpisana do bazy danych tylko jeden raz Problem powtarzających
Bardziej szczegółowoPodstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem. dr Jakub Boratyński. pok. A38
Podstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem zajęcia 1 dr Jakub Boratyński pok. A38 Program zajęć Bazy danych jako podstawowy element systemów informatycznych wykorzystywanych
Bardziej szczegółowoModelowanie danych, projektowanie systemu informatycznego
Modelowanie danych, projektowanie systemu informatycznego Modelowanie odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym Modele - konceptualne reprezentacja obiektów w uniwersalnym
Bardziej szczegółowoBazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Bazy danych Wykład 3: Model związków encji. dr inż. Magdalena Krakowiak makrakowiak@wi.zut.edu.pl Co to jest model związków encji? Model związków
Bardziej szczegółowoTechnologie baz danych
Technologie baz danych Wykład 4: Diagramy związków encji (ERD). SQL funkcje grupujące. Małgorzata Krętowska Wydział Informatyki Politechnika Białostocka Plan wykładu Diagramy związków encji elementy ERD
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoINFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji
Modelowanie danych. Model związków-encji Plan wykładu Wprowadzenie do modelowania i projektowania kartograficznych systemów informatycznych Model związków-encji encje atrybuty encji związki pomiędzy encjami
Bardziej szczegółowoP o d s t a w y j ę z y k a S Q L
P o d s t a w y j ę z y k a S Q L Adam Cakudis IFP UAM Użytkownicy System informatyczny Aplikacja Aplikacja Aplikacja System bazy danych System zarządzania baz ą danych Schemat Baza danych K o n c e p
Bardziej szczegółowoSpis treści OPIS PLIKU W FORMACIE CSV Z DANYMI PPE LUB EP 1
O PIS PLIKU W F O R M A C I E CSV Z D A N Y M I PRZEKAZÓW PIENIĘŻNYCH L U B E K S PRESÓW PIENIĘŻNYCH D O K U M E N T A C J A T E C H N I C Z N A W E R S J A 4.0 L I P I E C 2 0 1 4 Spis treści 1. Struktura
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoModelowanie obiektowe - Ćw. 6.
1 Modelowanie obiektowe - Ćw. 6. Treść zajęć: Dokumentacja przypadków użycia diagramy czynności. Poznane wcześniej diagramy przypadków użycia pokazują co system powinien robić. Natomiast diagramy czynności
Bardziej szczegółowoDiagramy związków encji ERD Ćwiczenia w modelowaniu danych
Diagramy związków encji ERD Ćwiczenia w modelowaniu danych dr Lidia Stępień wykład 5 ERD ang. Entity-Relationship Diagram Diagram związków encji Proces konstruowania projektu systemu bazy danych. Abstrakcyjna
Bardziej szczegółowoPojęcie bazy danych. Funkcje i możliwości.
Pojęcie bazy danych. Funkcje i możliwości. Pojęcie bazy danych Baza danych to: zbiór informacji zapisanych według ściśle określonych reguł, w strukturach odpowiadających założonemu modelowi danych, zbiór
Bardziej szczegółowoCo to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?
ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest
Bardziej szczegółowoPodstawy projektowania systemów komputerowych
Podstawy projektowania systemów komputerowych Diagramy klas UML 1 Widok logiczny Widok logiczny Widok fizyczny Widok przypadków użycia Widok procesu Widok konstrukcji Używany do modelowania części systemu
Bardziej szczegółowoNormalizacja baz danych
Wrocławska Wyższa Szkoła Informatyki Stosowanej Normalizacja baz danych Dr hab. inż. Krzysztof Pieczarka Email: krzysztof.pieczarka@gmail.com Normalizacja relacji ma na celu takie jej przekształcenie,
Bardziej szczegółowoInformatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny) kierunkowy (podstawowy / kierunkowy / inny HES)
KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu w języku angielskim Modeling and Analysis of Information Systems Obowiązuje od roku akademickiego
Bardziej szczegółowoTeoretyczne podstawy informatyki
Teoretyczne podstawy informatyki Wykład 8b: Algebra relacyjna http://hibiscus.if.uj.edu.pl/~erichter/dydaktyka2009/tpi-2009 Prof. dr hab. Elżbieta Richter-Wąs 1 Algebra relacyjna Algebra relacyjna (ang.
Bardziej szczegółowoPODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"
PODSTAWY BAZ DANYCH 5. Modelowanie danych 1 Etapy tworzenia systemu informatycznego Etapy tworzenia systemu informatycznego - (według CASE*Method) (CASE Computer Aided Systems Engineering ) Analiza wymagań
Bardziej szczegółowoPodstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Bardziej szczegółowo030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła
030 PROJEKTOWANIE BAZ DANYCH Prof. dr hab. Marek Wisła Elementy procesu projektowania bazy danych Badanie zależności funkcyjnych Normalizacja Projektowanie bazy danych Model ER, diagramy ERD Encje, atrybuty,
Bardziej szczegółowoModelowanie procesów (1) Oracle Designer: Modelowanie procesów. Modelowania procesów (2) Modelowanie procesów (3)
Modelowanie procesów (1) Oracle Designer: Modelowanie procesów Identyfikuje kluczowe aktywności w działalności organizacji. Modeluje wybrane lub wszystkie aktywności w ramach organizacji. Określa kolejność
Bardziej szczegółowoWarstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.
Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy
Bardziej szczegółowoTechnologie informacyjne - wykład 12 -
Zakład Fizyki Budowli i Komputerowych Metod Projektowania Instytut Budownictwa Wydział Budownictwa Lądowego i Wodnego Politechnika Wrocławska Technologie informacyjne - wykład 12 - Prowadzący: Dmochowski
Bardziej szczegółowo15. Funkcje i procedury składowane PL/SQL
15. Funkcje i procedury składowane PLSQL 15.1. SQL i PLSQL (Structured Query Language - SQL) Język zapytań strukturalnych SQL jest zbiorem poleceń, za pomocą których programy i uŝytkownicy uzyskują dostęp
Bardziej szczegółowoInżynieria oprogramowania. Wykład 6 Analiza i specyfikowanie wymagań
Inżynieria oprogramowania Wykład 6 Analiza i specyfikowanie wymagań Proces inżynierii wymagań Feasibility Study Feasibility Report Requirements Analysis System Models Requirements Definition Definition
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity
Bardziej szczegółowoPrzykłady najlepiej wykonywać od razu na bazie i eksperymentować z nimi.
Marek Robak Wprowadzenie do języka SQL na przykładzie baz SQLite Przykłady najlepiej wykonywać od razu na bazie i eksperymentować z nimi. Tworzenie tabeli Pierwsza tabela W relacyjnych bazach danych jedna
Bardziej szczegółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Bardziej szczegółowoFUNKCJE SZBD. ZSE - Systemy baz danych 1
FUNKCJE SZBD ZSE - Systemy baz danych 1 System zarządzania bazami danych System zarządzania bazami danych (SZBD, ang. DBMS) jest zbiorem narzędzi stanowiących warstwę pośredniczącą pomiędzy bazą danych
Bardziej szczegółowoSQL (ang. Structured Query Language)
SQL (ang. Structured Query Language) SELECT pobranie danych z bazy, INSERT umieszczenie danych w bazie, UPDATE zmiana danych, DELETE usunięcie danych z bazy. Rozkaz INSERT Rozkaz insert dodaje nowe wiersze
Bardziej szczegółowoE-1IZ s2. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)
KARTA MODUŁU / KARTA PRZEDMIOTU Załącznik nr 7 do Zarządzenia Rektora nr 10/12 z dnia 21 lutego 2012r. Kod modułu E-1IZ2-1003-s2 Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu
Bardziej szczegółowoJęzyk UML. dr inż. Piotr Szwed C3, pok
Język UML dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl Przypadki użycia Przypadki użycia: Definicja Przypadek użycia to specyfikacja ciągów akcji i ich wariantów,
Bardziej szczegółowoTworzenie warstwy zasobów projektowanie metodą strukturalną
Tworzenie warstwy zasobów projektowanie metodą strukturalną Autor Zofia Kruczkiewicz Programowanie i wdrażanie systemów informatycznych 2011-03-27 1 1. Zasady modelowania wymagań funkcjonalnych systemu
Bardziej szczegółowoPlan. Formularz i jego typy. Tworzenie formularza. Co to jest formularz? Typy formularzy Tworzenie prostego formularza Budowa prostego formularza
4 Budowa prostych formularzy, stany sesji, tworzenie przycisków Plan Co to jest formularz? Typy formularzy Tworzenie prostego formularza Budowa prostego formularza 2 Formularz i jego typy Tworzenie formularza
Bardziej szczegółowoWprowadzenie do baz danych
Wprowadzenie do baz danych Bazy danych stanowią obecnie jedno z ważniejszych zastosowań komputerów. Podstawowe zalety komputerowej bazy to przede wszystkim szybkość przetwarzania danych, ilość dostępnych
Bardziej szczegółowoModelowanie hierarchicznych struktur w relacyjnych bazach danych
Modelowanie hierarchicznych struktur w relacyjnych bazach danych Wiktor Warmus (wiktorwarmus@gmail.com) Kamil Witecki (kamil@witecki.net.pl) 5 maja 2010 Motywacje Teoria relacyjnych baz danych Do czego
Bardziej szczegółowoWykład 8. SQL praca z tabelami 5
Wykład 8 SQL praca z tabelami 5 Podzapytania to mechanizm pozwalający wykorzystywać wyniki jednego zapytania w innym zapytaniu. Nazywane często zapytaniami zagnieżdżonymi. Są stosowane z zapytaniami typu
Bardziej szczegółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoWykład II Encja, atrybuty, klucze Związki encji. Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.
Bazy Danych Wykład II Encja, atrybuty, klucze Związki encji Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.Widom Copyrights by Arkadiusz Rzucidło 1 Encja Byt pojęciowy
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 8 Diagram pakietów I Diagram pakietów (ang. package diagram) jest diagramem
Bardziej szczegółowoZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia
ZP/ITS/11/2012 Załącznik nr 1a do SIWZ ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia Przedmiotem zamówienia jest: Przygotowanie zajęć dydaktycznych w postaci kursów e-learningowych przeznaczonych
Bardziej szczegółowoBazy Danych. Bazy Danych i SQL Podstawowe informacje o bazach danych. Krzysztof Regulski WIMiIP, KISiM, regulski@metal.agh.edu.pl
Bazy Danych Bazy Danych i SQL Podstawowe informacje o bazach danych Krzysztof Regulski WIMiIP, KISiM, regulski@metal.agh.edu.pl Literatura i inne pomoce Silberschatz A., Korth H., S. Sudarshan: Database
Bardziej szczegółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoPrzykładowa baza danych BIBLIOTEKA
Przykładowa baza danych BIBLIOTEKA 1. Opis problemu W ramach zajęć zostanie przedstawiony przykład prezentujący prosty system biblioteczny. System zawiera informację o czytelnikach oraz książkach dostępnych
Bardziej szczegółowoProcesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Bardziej szczegółowoLogika funkcji. Modelowanie SI - GHJ 1
Logika funkcji precyzyjne i niedwuznaczne definiowanie szczegółów funkcji stosowana w tych przypadkach, w których funkcja jest złożona lub wymaga arbitralnego algorytmu Celem - zrozumienie przez projektanta
Bardziej szczegółowoSposób implementacji e-faktury w oprogramowaniu Sage. e-faktura. implementacja w oprogramowaniu
e-faktura implementacja w oprogramowaniu Korzystaj w pełni z e-faktury Spis treści 1. Wstęp 2. Zawartość e-faktury 3. Błędy podczas eksportu e-faktury 4. Ostrzeżenia podczas eksportu e-faktury 1. Wstęp
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowo