Inżynieria systemów informacyjnych

Slides:



Advertisements
Podobne prezentacje
Piotr Czekalski, ZMiTAC, Politechnika Śląska 2003
Advertisements

Związki w UML.
Unified Modeling Language Wykład 4 Przypadki użycia
Modelowanie przypadków użycia
Projektowanie w cyklu życia oprogramowania
Modelowanie procesów biznesowych
Język UML (Unified Modelling Language)
Tomasz Pieciukiewicz Rafał Hryniów
Projektowanie Aplikacji Komputerowych
Projektowanie Aplikacji Komputerowych
Inżynieria Oprogramowania II
UML Unified Modeling Language
Co UML może zrobić dla Twojego projektu?
INŻYNIERIA OPROGRAMOWANIA [ 1968 ].
Bartosz Walter Prowadzący: Bartosz Walter
Modelowanie i język UML
Unified Modeling Language Wykład 5 Diagram czynności
Diagramy klas w języku UML
Diagram czynności (Activity Diagrams)
Projektowanie i programowanie obiektowe II - Wykład IV
Projekt i implementacja
Projektowanie - wprowadzenie
Projektowanie dynamiki - diagramy interakcji
Wykład 4 Analiza i projektowanie obiektowe
Wykład 5 UML - Unified Modeling Language
Wykład 3 Analiza i projektowanie strukturalne
Wykład 2 Cykl życia systemu informacyjnego
Modelowanie systemu informatycznego
C.d. wstępu do tematyki RUP
Unified Modeling Language graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych.
Inżynieria Oprogramowania
UML 2.x Robert Pająk.
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych
Model przestrzenny Diagramu Obiegu Dokumentów
Moduł Lojalnościowy. Czyli zatrzymanie klienta przy naszym zakładzie optycznym.
Związki w UML Do zrobienia jest: -Przerysować jak ktoś ma Visio te dwa diagramy tak żeby podmienić tylko nazwy a reszta Taka sama, -I dodać po jednym zdaniu.
Zawansowane techniki programistyczne
Modelowanie obiektowe Diagramy czynności
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Modelowanie obiektowe Diagramy sekwencji
Unified Modeling Language - Zunifikowany Język Modelowania
Wprowadzenie do UML dr hab. inż. Kazimierz Subieta profesor PJWSTK.
Modelowanie obiektowe Diagramy klas
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Diagramy przypadków użycia ALINA SUCHOMSKA. Przypadki użycia systemu  technika wyznaczania funkcjonalnych wymagań systemu  opisują typowe interakcje.
1 (21) Modelowanie i opis wymagań Bogdan Bereza – blogomocja.blogspot.com –
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Model obiektowy bazy danych
Diagram aktywności (czynności)
Diagram przypadków użycia
Diagram klas Kluczowymi elementami są: klasy (class)
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Modelowanie obiektowe - system zarządzania projektami.
Diagram komunikacji (communication diagram)
Diagram przypadków użycia
Projekt modułu Nazwa całego projektu Nazwa modułu Imię i Nazwisko Inżynieria Oprogramowania II dzień, godzina rok akademicki W szablonie na niebiesko zamieszczone.
Diagramy przepływu danych
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Projektowanie i analiza systemów informacyjnych
Część 1.  Pierwszym etapem metodyki strukturalnej jest analiza strukturalna której efektem jest model podstawowy systemu.
Modelowanie model związków encji
Wstęp do systemów informatycznych Model przypadków użycia.
E. Stemposz. Wprowadzenie do UML, Wykład 1, Slajd 1/24 Wykład 1 Wprowadzenie do UML dr inż. Ewa Stemposz
MAS Rafał Hryniów. Agenda  Zasady  Referaty  Projekt  Kolosy.
Temat: Tworzenie bazy danych
T. 18. E Proces DGA - Działania (operatorka).
Inżynieria Oprogramowania Laboratorium
Projekt modułu BANK INTERNETOWY Moduł funkcji banku
Zapis prezentacji:

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

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

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

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

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

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

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.

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.

Diagramy przepływu danych

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.

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ą

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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.

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.