1 Inżynieria systemów informacyjnychdr inż. Krzysztof Michalak

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

3 Diagramy przepływu danychDiagramy 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 danychElementy diagramów DFD: Procesy Terminatory – obiekty zewnętrzne Magazyny danych Przepływy

5 Diagramy przepływu danychBłędy przy modelowaniu DFD X

6 Diagramy przepływu danychBłędy przy modelowaniu DFD X

7 Diagramy przepływu danychTworzenie 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 danychW 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 LanguageUML 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życiaDiagramy 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życiaPrzypadek 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życiaAktorzy 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życiaW celu określenia granic definiowanego systemu można na diagramie wprowadzić element grupujący przypadki użycia – granice systemu.

16 Diagramy przypadków użyciaZależ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życiaZależ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życiaDodatkowe 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życiaUogólnienia umożliwiają agregację wielu przypadków/aktorów specjalizowanych do jednego przypadku/aktora ogólnego.

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

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

22 Dokumentacja przypadków użyciaDokumentacja 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życiaSzablon 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życiaNazwa 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życiaPrzebieg 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życiaPrzebieg 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.