Terminy spotkań:

Terminy przesyłania projektów

• 5.02.2017 (termin podstawowy)
• 15.02.2017 (poprawki w przypadku oceny ndst)

Uwaga: oceny będą publikowane w miarę sprawdzania projektów: w sekcji oceny

Szanowni Państwo, proszę o sprawdzenie swoich ocen. Jeżeli grupa nie ma oceny, oznacza to, że praca nie została sprawdzona. Przyczyny mogą być dwie: (1) nie została dostarczona (2) nie zauważyłem, że praca została przesłana. W obu przypadkach proszę o kontakt

Projekty mają zostać dostarczone wyłącznie w wersji elektronicznej (jeden dokument PDF). Proszę o:

• wklejenie rysunków wektorowych
• w miarę możliwości zmianę stylu Viso (na bardziej czytelny, tzn. nie małe białe napisy na niebieskim tle)

Zawartość projektu:

• Temat i lista autorów
• Kilkuzdaniowy opis (koncepcja systemu)
• Specyfikacja DFD
  • Diagram kontekstowy
  • Diagram wstępny
  • Dekompozycja procesów aż do poziomu procesów atomowych
• Słownik
  • ERD dla magazynów danych
  • Przepływających danych
• Specyfikacje procesów atomowych, 12 specyfikacji, 6 procesów

Uwagi

• Diagramy DFD:
  • numeracja procesów
  • przepływy danych powinny być unikalne, nie trzeba oznaczać przepływów z magazynów
• ERD:
  • na ogół magazyn odpowiada jednej encji i nosi jej nazwę
  • obok diagramu ERD proszę o krótki opis słowny (jak interpretować encje?)
• Specyfikacje procesów
  • Specyfikacje PRE/POST odnoszą się do wartości danych lub obecności rekordów w magazynie, nie mogą zawierać czynności
  • W specyfikacji typu pseudokod/schemat blokowy nie powinno się pojawić wyświetl bład. W takim przypadku proces powinien zwrócić wartość błędu za pośrednictwem przepływu wyjściowego.

Przesyłanie projektów:

• Osoby uczestniczące w zajęciach AMO mogą skorzystać z funkcji upload
• Pozostałe grupy proszone są o przesłanie projektu za pośrednictwem e-mail. Proszę w nagłówku umieścić na początku następujący tekst: Inż.Oprog.2016

Celem projektu 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 powinien być jeden dokument zawierający:

Diagramy przepływu danych DFD

1. kilkuzdaniowy opis problemu
2. diagram kontekstowy
3. diagram wstępny
4. diagramy niższych poziomów

Słownik danych

1. diagram ERD definiujący magazyny
2. specyfikacje danych w przepływach

Specyfikacje procesów atomowych (12 specyfikacji różnych procesów)

1. opis w postaci prewarunków i postwarunków
2. opis słowny (pseudokod)
3. flowchart

Cała specyfikacja musi być spójna.

Wybierz jeden z tematów i zarejestruj

Należy zwrócić uwagę, że formalnie Analiza strukturalna jest metodą specyfikacji wymagań odnoszącą się do

• funkcji systemu i ich dekompozycji
• opisu danych przetwarzanych przez system

Jednak perspektywa opisu jest inna niż w przypadku specyfikacji wymagań z użyciem UML (zwłaszcza przypadków użycia). Przypadek użycia definiuje zachowanie systemu traktowanego jako czarna skrzynka. Diagramy DFD definiują wymagane funkcje i ich wewnętrzną strukturę (spójną hierarchię funkcji).

Elementy składowe:

1. Diagram kontekstowy: obiekty zewnętrzne (wejścia/wyjścia, interfejsy, terminatory) i proces opisujący system
2. Diagram wstępny obejmujący: podstawowe procesy, magazyny danych i przepływy
3. Kolejne diagramy powstałe w wyniku dekompozycji procesów (aż do osiągnięcia poziomu procesów atomowych)

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.

• Nazwą procesu powinien być czasownik + dopełnienie, np. Dodaj klienta. Stosowany jest zwykle tryb rozkazujący (Dodaj) lub imiesłów (Dodawanie).

• 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 kropce 1.2 → 1.2.3 → 1.2.3.1…

• Przepływy danych nie powinny zawierać czasowników. Są to dane klienta, ale nie Zapisz dane klienta.
• Przepływ danych do/od magazynu odpowiada zawartości magazynu (proces realizuje pełny dostęp do zawartości magazynu, może iterować po elementach, czytać, wstawiać, wybierać rekordy, itp).
• Przepływy pomiędzy procesami i terminatorami muszą być opisane
• Dane przepływów powinny być unikalne. Jeżeli proces Przetwórz dane osoby ma na wejściu i wyjściu te same dane osoba, to jaki jest jego cel? Powinno być osoba→Przetwórz dane osoby→przetworzona_osoba.

• 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). To jest czysta zależność przyczynowości: aby wyprodukować dane wyjściowe trzeba dostarczyć dane wejściowe.
• 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 niższych 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

Visio: Oprogramowanie i baza danych/Software → Diagram przepływu danych/Data Flow Diagram

1. Fragment podręcznika Yourdona
2. Opis metody SART http://home.agh.edu.pl/~pszwed/se/sart/kss09.html - sekcja Przykład

Obejmuje dwie składowe:

1. Diagram ERD (Entity Relationship Diagram) - najczęściej opisują dane w magazynach
2. Specyfikację przepływających danych

Diagram ERD pokazuje obiekty (encje) oraz relacje pomiędzy nimi:

• [Książka]—-<ma autora>—-[Osoba]

• [Książka]—-<ma egzemplarz>—-[EgzemplarzKsiążki]

• [Książka]—-<jest wypożyczona przez>—-[Czytelnik]

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

Na przykłady umieszczone w Diagramy ERD należy spojrzeć krytycznie. Sugerują one, że relacje są pewnego rodzaju czynnościami lub funkcjami systemu, np:

• [Lekarz]–<leczy>–[Pacjenta]
• [Lekarz]–<obciąża fakturą>–[Pacjenta]
• [Sprzedawca]–<negocjuje cenę>–[Nabywca]
• [Pełnomocnik sprzedawcy]–<negocjuje warunki z>–[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]–<jest wypożyczony przez>–[Czytelnika] ale niekoniecznie
• [Czytelnik]–<zwraca>–[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]–<wykonuje>–[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.

Podczas modelowania można użyć:

• klasycznego diagramu ERD (odpowiednie kształty występują w Visio w przyborniku dla DFD)
• 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]–<jest wypożyczony przez>–[Czytelnika] - dodajemy encję Wypożyczenie z kluczami obcymi wskazującymi na czytelnika i egzemplarz oraz atrybutami typu data wypożyczenia, zwrotu

• Visio: Oprogramowanie i baza danych/Software → Diagram przepływu danych/Data Flow Diagram
• Visio: Oprogramowanie i baza danych →Diagram modelu bazy danych (lub Database → Database Model

Słownik danych ma obejmować definicje wszystkich przepływów. Przykłady są podane tu: Specyfikacja przepływów danych

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 *

Diagramy ERD

http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
Specyfikacja przepływów danych

Proces atomowy to proces, który nie podlega dalszej dekompozycji.

• Jest więc czystą funkcją, która odwzorowuje kombinacje wartości na wejściu w kombinacje wartości na wyjściu.
• Proces atomowy nie ma stanu (procesy ze stanami występują w rozszerzeniach Analizy Strukturalnej, jak np. SART)

Specyfikacja procesów atomowych to specyfikacja ich funkcji P: input → output. Specyfikacje te muszą zachować spójność ze słownikiem danych. (Nazwy przepływów danych wejściowych i wyjściowych muszą pojawić się w specyfikacji.)

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 )

Specyfikacja z użyciem prewarunków i postwarunkó

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

1. Wybierz co najmniej 6 różnych procesów atomowych (ale nie procesy typu logowanie)
2. Przygotuj 12 specyfikacji procesów (np.: 6 procesów x 2 typy specyfikacji) stosując:
   • pseudokod (Structured English)
   • prewarunki i postwarunki
   • diagramy flowchart
   • tablice decyzyjne

Metody specyfikacji procesów atomowych są opisane w podręczniku Yourdona

Przed oddaniem proszę sprawdzić następujące elementy:

• czy nazwy procesów są czasownikami?
• czy procesy są numerowane
• czy przepływające dane są rzeczownikami (ale nie odczasownikowymi, jak zapis, odczyt)
• czy przy przejściu pomiędzy poziomami hierarchii zachowana jest zgodność przepływów
• czy magazynom danych można przypisać encje ERD
• czy specyfikacja procesów atomowych jest zgodna z diagramem DFD (wejścia i wyjścia)
• czy specyfikacja PRE/POST odwołuje się do wartości danych wejściowych i wyjściowych, a nie czynności

Dostęp do ocen jest zabezpieczony hasłem

• user: io
• passwd: hasło jest konkatencacją oznaczenia budynku i sali, w której odbywały się zajęcia – wszystko pisane małymi literami, czyli np.: c2224

• Punkty za elementy projektu .

• Projekt: oceny indywidualne.