====== Zadanie 1 - Analiza Strukturalna ====== Celem pierwszego ćwiczenia projektowanego na trzy ćwiczenia jest sporządzenie modelu systemu w konwencji Analizy Strukturalnej obejmującego: *Specyfikację procesów oraz ich dekompozycję (DFD) *Słownik danych dla przepływów i ERD dla magazynów *Specyfikację procesów atomowych Efektem zadania powinien być jeden dokument zawierający: **Diagramy przepływu danych DFD** - kilkuzdaniowy opis problemu - diagram kontekstowy - diagram wstępny - diagramy niższych poziomów **Słownik danych** - diagram EDR definiujący magazyny - specyfikacje danych w przepływach **Specyfikacje procesów atomowych** (9 specyfikacji) - opis słowny (pseudokod) - opis prewarunków i postwarunków - flowchart - opcjonalnie: tabele decyzyjne Cała specyfikacja musi być spójna. ===== Ćwiczenia 1 ===== - Wybierz temat dla grupy 3 osobowej oraz zarejestruj grupę [[io:zadania_tematy|Tematy i rejestracja]] - Przeczytaj o diagramach DFD - Fragment podręcznika Yourdona [[http://yourdon.com/strucanalysis/wiki/index.php/Chapter_9]] - Opis metody SART [[http://home.agh.edu.pl/~pszwed/se/sart/kss09.html]] - sekcja Przykład - Uruchom Visio (najlepiej starą wersję Visio 2002, ponieważ analizuje składnię i zaznacza błędy na czerwono). Wybierz Oprogramowanie i baza danych/Software -> Diagram przepływu danych/Data Flow Diagram - Rozpocznij rysowanie procesów: - Diagram kontekstowy: obiekty zewnętrzne (wejścia/wyjścia, interfejsy, terminatory) i proces opisujący system - Diagram wstępny obejmujący: podstawowe procesy, magazyny danych i przepływy - Spróbuj zdekomponować jeden z procesów **Wskazówki i uwagi** * Celem jest zbudowanie modelu systemu informatycznego wspierającego działalność firmy lub organizacji. W opisie nie powinny pojawiać się procesy wykonywane manualnie, np.: zaadresowanie przesyłki = wydruk etykiety i przyklejenie na paczkę. Wydruk jest funkcją systemu, przyklejenie etykiety już nie. * Należy zastanowić się nad wejściami i wyjściami systemu. Kto go używa lub z nim współpracuje: użytkownik, inny system. Obiektami zewnętrznymi mogą być też urządzenia (np. drukarka) * Należy zastanowić się, jakimi danymi manipuluje system: czytelnikami, klientami, księgozbiorem, towarami, zamówieniami, itd. * Procesy diagramu wstępnego to często //zarządzanie// tymi danymi: //Zarządzanie klientami// (dodaj, usuń, edytuj dane, wyszukaj), //Zarządzanie księgozbiorem//, //Zarządzanie towarami//. * Procesy powinny być numerowane. Procesy diagramu wstępnego otrzymują numery 1.0, 2.0, 3.0. Procesy podrzędne otrzymują numery 1.1, 1.2, 1.3. Schodząc coraz niżej w dekompozycji, dodajemy kolejne numery po kropcje 1.2 -> 1.2.3 -> 1.2.3.1... * Nazwą procesu powinien być czasownik + dopełnienie, np. //Dodaj klienta//. Stosowany jest zwykle tryb rozkazujący (//Dodaj//) lub imiesłów (//Dodawanie//). * Przyepływy danych nie powinny zawierać czasowników. Są to //dane klienta//, ale nie //Zapisz dane klienta//. * Diagram DFD pokazuje, jakie dane należy dostarczyć, aby wykonać proces i jakie dane zostaną wyprodukowane. DFD nigdy nie definiuje, //kiedy, w jakiej sytuacji// proces zostanie uruchomiony (np. jaką komendą lub opcją menu). * Diagram DFD nie jest opisem algorytmu, ale raczej usług systemu, z których można złożyć algorytm postępowania * Proces tworzenia diagramu DFD jest zazwyczaj opisywany jako //top-down//: od diagramu //kontekstowego//, poprzez //wstępny// i kolejnych nizszych poziomów, aż do osiągnięcia niedekomponowalnych procesów atomowych. Tak wygląda ostateczna forma dokumentacji, ale sam proces może przebiegać w różnych kierunkach. * Przed przystąpieniem do rysowania naszkicować hierarchię procesów, np: System projektów studenckich 1.0 Zarządzanie tematami 1.1 Dodaj temat 1.2 Edytuje temat 1.3 Usuń temat 2.0 Zarządzanie grupami 2.1 Utwórz grupę 2.2 Edytuj grupę 2.2.1 Dodaj osobę 2.2.2 Usuń osobę 2.2.3 Zmień dane kontaktowe ... 2.3 Usuń grupę 3.0 Zarządzanie przydziałem tematów 4.0 Wystawianie ocen ===== Ćwiczenia 2 ===== Celem ćwiczeń jest zdefiniowanie dwóch składowych słownika danych: - Diagramu ERD (Entity Relationship Diagram) - Specyfikację przepływów danych Podczas zajęć skupimy się na ERD. 1) Diagram ERD pokazuje **obiekty (encje)** oraz **relacje** pomiędzy nimi: *''[Książka]--------[Osoba]'' *''[Książka]--------[EgzemplarzKsiążki]'' *''[Książka]--------[Czytelnik]'' 2) Diagram ERD pokazuje również atrybuty encji *Książka: Tytuł, Wydawnictwo, ISBN, liczba stron, ("autor" i "ma egzemplarz" są relacjami) *Osoba: Imię, Nazwisko, Miejsce urodzenia, Data urodzenia... *EgzemplarzKsiążki: Sygnatura, Stan egzemplarza (Dobry, Zużyty, USzkodzony, Zgubiony, Wycofany) *Czytelnik: Imię, Nazwisko, PESEL, Adres ==== Do zrealizowania ==== -Przeczytaj o diagramach ERD [[http://yourdon.com/strucanalysis/wiki/index.php/Chapter_12|Diagramy ERD]] -Uruchom Visio (dowolna wersja) i wybierz: //Oprogramowanie i baza danych// ->//Diagram modelu bazy danych// (lub //Database// -> //Database Model Diagram// -Zidentyfikuj podstawowe klasy (typy) obiektów i ich relacje oraz zilustruj je na diagramie -Zanim przystąpisz do rysowania - przeczytaj uwagi ponżej ==== Uwagi ==== Na przykłady umieszczone w [[http://yourdon.com/strucanalysis/wiki/index.php/Chapter_12|Diagramy ERD]] należy spojrzeć krytycznie. Sugerują one, że relacje są pewnego rodzaju czynnościami lub funkcjami systemu, np: * ''[Lekarz]----[Pacjenta]'' * ''[Lekarz]----[Pacjenta]'' * ''[Sprzedawca]----[Nabywca]'' * ''[Pełnomocnik sprzedawcy]----[Pełnomocnikiem nabywcy] '' Relacje nie są czynnościami. To są pewne powiązania występujące w modelu danych przechowywanych w systemie. Interesuje nas powiązanie: * ''[EgzemplarzKsiążki]----[Czytelnika]'' ale niekoniecznie * ''[Czytelnik]----[EgzemplarzKsiążki]'' Zauważmy, że w pierwszym przypadku jest to jakiś stan, który można zapisać i odczytać; w drugim nazwa sugeruje trwająca kilka minut czynność. Diagramy ERD nie opisują czynności, ale związki przechowywane w sposób trwały w systemie IT.. W Wikipedii jest przykład ''[Artysta]----[Utwór]''. Przykład jest lepszy, nie sugeruje, że wykonuje teraz (Present Continuous: //is performing//), ale wykonuje wielokrotnie i jest z utworem trwale związany ( Simple Present: //performs//). Encja na diagramie ERD jest zbiorem obiektów. Nie ma sensu używać nazw typu //BazaKsiążek//, //ListaKsiążek// -- po prostu //Książka// Magazyn danych DFD powinien nazywać się tak samo, jak encja. :!: Modelowanie * Podczas modelowania proponuje się użycia diagramu równoważnego ERD, który jest bliższy poziomowi projektowania baz danych. *Atrybut oznaczony PK (ang. //primary key//) to klucz główny - jednoznacznie identyfkujący obiekt *Atrybut oznaczony FK (ang. //foreign key//) to klucz obcy - jest tego samego typu, co klucz główny w innej encji i służy do zrealizowania relacji *W wielu przypadkach relacja (romb) z ERD stanie się encją (tabelą), np. ''[EgzemplarzKsiążki]----[Czytelnika]'' - dodajemy encję ''Wypożyczenie'' z kluczami obcymi wskazującymi na czytelnika i egzemplarz oraz atrybutami typu data wypożyczenia, zwrotu ==== Literatura==== [[http://yourdon.com/strucanalysis/wiki/index.php/Chapter_12|Diagramy ERD]]\\ [[http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model]]\\ [[http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_10|Specyfikacja przepływów danych]]\\ ===== Ćwiczenia 3 ===== Celem ćwiczeń jest przygotowanie specyfikacji procesów atomowych. ==== Do zrealizowania ==== - Przeanalizuj metody specyfikacji procesów opisane w [[http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_11]] - Wybierz co najmniej 3 różne procesy atomowe (ale nie procesy typu logowanie) - Przygotuj 9 specyfikacji procesów (np.: 3 procesy x 3 typy specyfikacji) stosując: * pseudokod (Structured English) * prewarunki i postwarunki * diagramy flowchart * tablice decyzyjne Uwaga: :!: specyfikacja: * Powinna być poprzedzona definicją przepływów wejściowych i wyjściowych * Musi być spójna z listą wejść i wyjść * Musi być spójna ze słownikiem danych (można użyć wyłącznie atrybutów ze słownika/ERD) * Nie mogą w niej wystąpić niejawne przepływy wyjściowe (np. //Wyświetl komunikat o błędzie //) ==== Przykład ==== Przygotowując specyfikacje proszę zachować spójność ze słownikiem danych. (Nazwy przepływów danych wejściowych i wyjściowych muszą pojawić się w specyfikacji.) **Słownik danych (fragment)** users={@login+haslo} login = *tekst do 32 znaków zwierajacy litery, cyfry i znak podkreślenia* haslo = * tekst do 32 znaków* login_we = *dowolny tekst* haslo_we = * dowolny tekst* rezultat=tak | nie * wartość logiczna * **Specyfikacja z użyciem prewarunków i postwarunkó** ^Proces ''SPRAWDŹ dane logownia'' ^ INPUT: login_we, hasło_we, users (przepływ z magazynu) OUTPUT: rezultat 1. PRE login_we jest pusty POST rezultat = nie 2. PRE login_we nie jest pusty i users zawiera rekord u taki, że u.login==login_we i u.haslo==haslo_we POST rezultat = tak 3. PRE login_we nie jest pusty i users zawiera rekord u taki, że u.login==login_we i u.haslo != haslo_we POST rezultat = nie ===== Co ma się znaleźć w sprawozdaniu (termin 17.11) ===== - DFD - diagram kontekstowy - diagram wstępny - diagramy otrzymane w wyniku dekompozycji - Słownik danych - Diagram ERD dla magazynów - specyfikacja danych występujących w przepływach - Specyfikacje procesów atomowych - co najmniej 3 procesy - co najmniej 3 metody specyfikacji (3x3=9) Uwaga: *DFD ma być spójne ze słownikiem *DFD podczas dekompozycji ma zachowywać wejścia i wyjścia *Specyfikacje procesów atomowych spójne ze słownikiem i DFD(zachowane wejścia i wyjścia)