Table of Contents
Inżynieria oprogramowania (Projekt)
Terminy spotkań:
Lp | Termin | Opis |
---|---|---|
1 | 4.10.2016 11.10.2016 | Spotkanie organizacyjne. Podział na grupy. Wybór tematów, itp. |
2 | 18.10.2016 25.10.2016 | Rysujemy diagramy przepływu danych |
3 | 8.11.2016 15.11.2016 | Rysujemy diagramy ERD |
4 | 22.11.2016 29.11.2016 | Specyfikacje procesów |
5 | 6.12.2016 13.12.2016 | Konsultacje |
6 | 20.12.2016 3.01.2017 | Konsultacje |
7 | 10.01.2017 17.01.2017 | konsultacje i oddawanie projektów |
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
Przesyłanie projektów
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
Cel projektu
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
- kilkuzdaniowy opis problemu
- diagram kontekstowy
- diagram wstępny
- diagramy niższych poziomów
Słownik danych
- diagram ERD definiujący magazyny
- specyfikacje danych w przepływach
Specyfikacje procesów atomowych (12 specyfikacji różnych procesów)
- opis w postaci prewarunków i postwarunków
- opis słowny (pseudokod)
- flowchart
Cała specyfikacja musi być spójna.
Tematy projektów
Diagramy DFD
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:
- 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
- Kolejne diagramy powstałe w wyniku dekompozycji procesów (aż do osiągnięcia poziomu procesów atomowych)
Wskazówki i uwagi
Funkcje systemu IT a nie biznesu
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.
Diagram kontekstowy
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)
Procesy przetwarzają dane
- 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).
Numeracja procesów w hierarchii
- 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
- 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 daneosoba
, to jaki jest jego cel? Powinno byćosoba
→Przetwórz dane osoby
→przetworzona_osoba
.
Czym nie jest diagram DFD
- 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
Sposób konstrukcji
- 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
Oprogramowanie
Visio: Oprogramowanie i baza danych/Software → Diagram przepływu danych/Data Flow Diagram
Literatura
Specyfikacja danych
Obejmuje dwie składowe:
- Diagram ERD (Entity Relationship Diagram) - najczęściej opisują dane w magazynach
- Specyfikację przepływających danych
Diagram ERD
Obiekty i relacje
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]
Atrybuty
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
Uwagi
Relacje to trwałe powiązania
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 to nie czynności
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).
Encje reprezentują zbiory obiektów
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 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
Oprogramowanie
- 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
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 *
Literatura
Specyfikacja procesów atomowych
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 )
Przykład
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
Do realizacji w projekcie
- Wybierz co najmniej 6 różnych procesów atomowych (ale nie procesy typu logowanie)
- 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
Literatura
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
Oceny
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