Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Inżynieria systemów informacyjnych

Podobne prezentacje


Prezentacja na temat: "Inżynieria systemów informacyjnych"— Zapis prezentacji:

1 Inżynieria systemów informacyjnych
dr inż. Krzysztof Michalak

2 Plan wykładu Diagramy przepływu danych – Data Flow Diagrams Elementy UML’a

3 Diagramy przepływu danych
Diagramy Przepływu danych tworzone są w celu: Określenia kluczowych procesów Określenie sposobu przepływu informacji i danych pomiędzy procesami Identyfikacji obiektów zewnętrznych Identyfikacja magazynów danych umożliwiających przechowywanie danych

4 Diagramy przepływu danych
Elementy diagramów DFD: Procesy Terminatory – obiekty zewnętrzne Magazyny danych Przepływy

5 Diagramy przepływu danych
Błędy przy modelowaniu DFD X

6 Diagramy przepływu danych
Błędy przy modelowaniu DFD X

7 Diagramy przepływu danych
Tworzenie diagramów DFD należy rozpocząć od stworzenia diagramu kontekstowego. Diagram kontekstowy to szczególny przypadek DFD, na którym pojedynczy proces reprezentuje cały modelowany system. Diagram kontekstowy przedstawia proces komunikacji obiektów zewnętrznych z systemem.

8 Diagramy przepływu danych
W kolejnym korku tworzone są diagramy tzw. poziomu zerowego. Następuje dekompozycja procesu głównego na mniejsze procesy. Dekompozycję procesów przeprowadza się do momentu gdy uznamy, że diagramy są na wystarczającym poziomie szczegółowości. Dekomponując procesy należy pamiętać o tym, że diagramy powinny być zbalansowane. Oznacza to, że wszystkie przepływy, które pojawiły się na diagramie poziomu wyższego powinny się znaleźć na diagramie poziomu niższego.

9 Diagramy przepływu danych

10 Unified Modeling Language
UML to graficzny język umożliwiający wizualizację systemów informatycznych. UML wykorzystywany jest do opracowania dokumentacji technicznej systemów na podstawie, której odbywa się wytwarzanie systemów informatycznych. UML umożliwia zarówno opisanie struktury statycznej systemu jaki dynamiki systemu.

11 Diagram struktur połączonych Diagramy wdrożenia Diagram komponentów
UML 2.0 Diagramy struktur Diagram klas Diagram obiektów Diagram pakietów Diagram struktur połączonych Diagramy wdrożenia Diagram komponentów Diagram rozlokowania Diagramy zachowań Diagram przypadków użycia Diagram czynności Diagram maszyny stanowej Diagramy interakcji Diagram sekwencji Diagram harmonogramowania Diagram komunikacji Diagram sterowania interakcją

12 Diagramy przypadków użycia
Diagramy przypadków użycia umożliwiają definiowanie wymagań systemowych dla projektowanego systemu informatycznego. Diagramy przypadków użycia umożliwiają przedstawienie przypadków użycia, aktorów oraz związków między nimi.

13 Diagramy przypadków użycia
Przypadek użycia (Use Case) to specyfikacja ciągu czynności i ich wariantów, które system realizuje w wyniku interakcji z aktorami. Przypadek użycia można utożsamiać z konkretną funkcjonalnością systemu. Nazwa przypadku użycia powinna być sformułowana w trybie rozkazującym.

14 Diagramy przypadków użycia
Aktorzy to zbiór ról które wchodzą w interakcję z systemem. Aktorzy mogą być: Osobowi Nieosobowi Nazwa przypadku użycia powinna być sformułowana w trybie rozkazującym.

15 Diagramy przypadków użycia
W celu określenia granic definiowanego systemu można na diagramie wprowadzić element grupujący przypadki użycia – granice systemu.

16 Diagramy przypadków użycia
Zależność zawierania include umożliwia odwzorowanie sytuacji gdy wraz z zawierającym przypadkiem użycia (bazowym) wykonywany jest przypadek zawierany. Związek jest związkiem obligatoryjnym – przypadek zawierany zawsze jest realizowany z przypadkiem bazowy.

17 Diagramy przypadków użycia
Zależność rozszerzania extend umożliwia odwzorowanie sytuacji gdy do przypadku rozszerzanego (bazowego) może zostać włączona dodatkowa funkcjonalność – przypadek rozszerzający. Związek jest związkiem opcjonalnym – przypadek rozszerzający może ale nie musi zostać zrealizowany z przypadkiem bazowy.

18 Diagramy przypadków użycia
Dodatkowe funkcjonalności w przypadkach rozszerzających wykonywane są po spełnieniu określonych warunków. Warunki te definiuje się w przypadku bazowym ja punkty rozszerzenia

19 Diagramy przypadków użycia
Uogólnienia umożliwiają agregację wielu przypadków/aktorów specjalizowanych do jednego przypadku/aktora ogólnego.

20 Diagramy przypadków użycia
Asocjacje pomiędzy aktorami i przypadkami użycia mogą być opisane za pomocą znaczników ilościowych.

21 Diagramy przypadków użycia
Modelowanie diagramów przypadków użycia można rozpocząć od diagramu kontekstowego.

22 Dokumentacja przypadków użycia
Dokumentacja przypadków użycia ma za zadanie opisać w jaki sposób dana funkcjonalności w systemie ma być zrealizowana – w jaki sposób będzie „działała”. Opis przypadku użycia można wykonać za pomocą: Tekstu niesformalizowanego Formalnego tekstu strukturalnego Pseudokodu Szablonów

23 Dokumentacja przypadków użycia
Szablon opisujący przypadek użycia może się składać z następujących sekcji: Nazwa przypadku użycia Identyfikator Twórca Aktorzy Opis Warunki początkowe Warunki końcowe Przebieg podstawowy Przebieg alternatywny Przebieg negatywny Wymagania specjalne Notatki i kwestie

24 Dokumentacja przypadków użycia
Nazwa Dodaj nowego kontrahenta Identyfikator UC_021 Twórca Jan Kowalski Aktorzy Dział handlowy Opis Przypadek użycia realizuje dodawanie nowego kontrahenta do systemu Warunki początkowe W systemie zdefiniowano przynajmniej jedną grupę klientów Warunki końcowe System dodaje nowy wpis w kartotece kontrahentów

25 Dokumentacja przypadków użycia
Przebieg podstawowy Użytkownik wyświetla rejestr kontrahentów zgodnie z UC_012 Użytkownik wybiera opcję dodaj. System wyświetla formularza umożliwiający wprowadzenie danych nowego kontrahenta. Użytkownik wprowadza dane kontrahenta: 4.1. Nazwę –wymagane 4.2. NIP – wymagane, unikalne 4.3. Ulica i nr – wymagane 4.4 Miasto – wymagane 4.5. Kod pocztowy – wymagane 4.6. … 5. Użytkownik wybiera opcję zapisz 6. System weryfikuje czy wprowadzono wymagane dane oraz czy dane są poprawne – weryfikacja poprawności numeru NIP zgodnie z UC_035 7. System zapisuje nowego kontrahenta Przebieg alternatywny Użytkownik dodaje nową fakturę zgodnie z UC_121 Użytkownik wybiera opcję dodaj kontrahenta. Powrót do przebiegu podstawowego pkt 3.

26 Dokumentacja przypadków użycia
Przebieg negatywny I 7. Użytkownik nie wprowadził wymaganych danych lub dane są niepoprawne – system wyświetla odpowiedni komunikat 8. Powrót do przebiegu podstawowego pkt 4. II Użytkownik anuluje dodawanie nowego kontrahenta.


Pobierz ppt "Inżynieria systemów informacyjnych"

Podobne prezentacje


Reklamy Google