WYKŁAD XI

Jak powinna wyglądać dokumentacja.

Są trzy rodzaje dokumentacji ( dla obydwu technik )

DOKUMENTACJA OGÓLNA ( rozszerzenie specyfikacji założeń funkcjonalnych systemu )

Jest dla szczebla kierowniczego, dla obu stron: sprzedającej i kupującej. Nie jest przeznaczona dla informatyka, powinna zawierać jak najmniej pojęć informatycznych, na końcu tej dokumentacji powinien znajdować się słownik z wytłumaczonymi wszystkimi pojęciami informatycznymi użytymi w dokumentacji.

Spis rozdziałów

1. opis celu, zakresu działania systemu informatycznego ( jaki jest cel tworzenia tego systemu, co on będzie robił i jaki jest obszar tej firmy do której będzie zakupiony. Czy będzie obejmował wszystko czy tylko wybrane działy.

Nazwa funkcji ( nazwa i numer procesu - DFD)

Charaktery-styka funkcji ( krótki opis co robi funkcja)

Źródło danych wejściowych (od obiektu zewnętrznego, z magazynu, z innego procesu - musi być innym krojem pisma wyróżnione

Zawartość danych wejściowych ( bez wchodzenia w szczegóły - ogólnie, tylko z nazwy, bez typu)

Przeznaczenie danych wyjściowych ( dokąd te dane są przekierowane - czy do magazynu, czy do obiektu, czy procesu

Zawartość danych wyjściowych (ogólnie )

2. wymagania funkcjonalne ( najważniejszy rozdział ). Opis funkcji wykonywanych przez system, wyeksponowanie funkcji systemu. Pokazanie hierarchicznej budowy systemu. Do tego trzeba sporządzić tabelę która zbierze te wszystkie informacje związane z wymaganiami funkcjonalnymi.
   
   
   
   
   dla danej funkcji taki opis, dla następnej funkcji taki sam opis w kolejnym wierszu
   

3. Wymagania niefunkcjonalne. Opis dodatkowych wymagań i ograniczeń narzucanych na system które generowane są przez otoczenie i wszystkie te ograniczenia system musi respektować i nie tracić wymagań funkcjonalnych. ( np. przepisy prawne, jakieś normy itp.). Są to też dodatkowe wymagania wymagane przez użytkownika np. dla osób niepełnosprawnych, lub obsługa systemu tylko za pomocą klawiatury, dopasowanie się do struktur danych innego programu itp.

4. Model systemu
   a) lista zdarzeń na które system ma reagować
   b) drzewo procesów które wynika ze zbioru DFD
   c) diagram kontekstowy i rozsądna liczba procesów potomnych
   d) model przypadków użycia (diagram USE CASE )

5. opis ewolucji systemu ( jest to opcjonalny rozdział )- jeżeli planujemy rozbudowę systemu

6. wymagania sprzętowe i środowiskowe :
   sprzętowe:
   - po to aby klient wiedział czy ma odpowiedni sprzęt aby zainstalować dany system
   - jeżeli nie to jakie będą koszty nowego sprzętu który będzie mógł obsłużyć dany
   system
   
   środowiskowe:
   - określony system operacyjny pod którym będzie działa ten system
   - czy jest wymagany jakikolwiek system bazodanowy

7. słownik terminów
   dwie części:
   1. informatyczne
   2. dwie dziedziny przedmiotowe - pojęcia wynikające z instalacji systemu w danej dziedzinie przedmiotowej aby informatyk to zrozumiał

DOKUMENTACJA TECHNICZNA

1. cel i zakres systemu

2. opis modelu ( w oparciu o raporty )
   - poziomy dekompozycji DFD
   - opisy ( z raportów ) pojęć, komponentów które występują na poszczególnych
   poziomach ( procesy z opisem, zawartości przepływów, lista danych elementarnych
   z typami, lista magazynów danych z zawartościami i obiekty zewnętrzne )

3. 2 modele struktur danych ( model systemu )
   
   *
   - logiczny ( CDM ) na poziomie strukturalnym
   - diagram klas - obiektowy
   - model fizyczny z modelu CDM na konkretną bazę danych ( jakiś język: Sybase,
   Oracle itp. )
   - i do tego wszystkie komentarze
   
   *
   - opis działania za pomocą DFD. Jak on wygląda od strony użytkownika, czy jest
   menu zaraz po włączeniu programu. Pokazać jak poszczególne funkcje są
   realizowane w menu, przejścia poprzez stanu na diagramie przejść stanów
   
   *
   jeszcze takie zestawienie:
   
   

Funkcje (procesy) DFD	Stany STP	Moduły procesowe Stc





*
- dla jednego procesu trzeba opisać specyfikację

• złożony : potomne procesy wypisać

• elementarny: wypisać algorytm

• słownik terminów

DOKUMENTACJA UŻYTKOWNIKA

( instrukcja obsługi działającego systemu )

• tak napisana aby końcowy użytkownik umiał go dobrze obsłużyć, zrozumiał po co go ma

• ten użytkownik nie ma dostępu do dokumentacji ogólnej i technicznej

• pierwszy rozdział powtórzony

• rozdzielona na dwa typy użytkowników
  - administrator i inny użytkownik ( wiąże się to z prawami dostępu
  użytkownika do funkcji i zasobów )
  
  * co powinien zawierać podręcznik użytkownika:
  - sposób uruchamiania i kończenia pracy systemu
  - sposób realizacji najczęściej wykonywanych funkcji systemu
  informatycznego
  - metody obsługi błędów
  - korzystanie z systemu pomocy
  
  * co powinien zawierać podręcznik dla administratora systemu
  - opis instalacji systemu
  - dostrojenie środowiska do systemu operacyjnego
  - problem zarządzania kontami użytkowników

My robimy zlepek dokumentacji technicznej i ogólnej

W ogólnej:

W rozdziale model systemu dokładamy model struktur danych :

- to co w technicznej
- model CDM
- model fizyczny ( wygenerowany )
- diagram klas
- diagram przejść stanów

+ rozsądne raporty pokazujące te elementy z naszych diagramów ( zawartości przepływów, składnice danych itp. )

Język modelowania obiektowego.

Cel tego języka - ogólne modelowanie systemu informatycznego za pomocą obiektów

• jest to pośrednia notacja (pomost) pomiędzy pojmowaniem ludzi struktury a działania programów

• bezpośrednie powiązanie elementów modelu pojęciowego (konceptualnego0 z wykonywanymi programami

Zastosowanie:

1. Metodyka Jacobsona - OOSE (Object Oriented Software Engineering )

2. Metodyka Booch'a - OODA (Object Oriented Design with Application )

3. Metodyka rumbaugh'a - OMT (Object Modeling Technique )

Ad. 1

+ nastawiona na modelowanie użytkowników, wymagań funkcjonalnych, cyklu życia

systemu informatycznego

- niekompletnie modeluje dziedzinę przedmiotową

Ad. 2

+ dobrze obsługuje fazę projektowania, implementacji i związki systemu z

środowiskiem implementacji

- obsługa fazy analizy, nie ma dobrych technik rozpoznania wymagań użytkowników

Ad. 3

+ nastawiona na modelowanie dziedziny przedmiotowej

- modelowanie wymagań użytkownika i sprawy implementacyjne


UML stosuje się niezależnie od metodyki

Druga grupa diagramów


- diagram klas ( zawsze się go buduje )


Nazwa klasy




Pola klasy

( atrybuty i typy )




Operacje na zmiennych

I argumentach

( czyli public,private
I protected )






Klasa jest pojęciem istniejącym w projektowaniu od początku.

Etap analizy

Klasa - wzorzec dla grupy obiektów ze wspólnym stanem i zachowaniem

Etap projektowania i implementacji ( pisanie kodu )

Klasa - typ obiektowy w danym języku programowania

Diagram klas - diagram związków encji ( ERD )

Encja nie może istnieć bez atrybutu

Klasy mogą istnieć bez atrybutu

Diagram klas

- pomiędzy dwoma klasami istnieje powiązanie ( związek ) jeżeli obiekty pierwszej klasy są w ramach dziedziny przedmiotowej w pewien sposób powiązane z obiektami z drugiej klasy

obiekt klasy służy do modelowania konceptualnego

związki ( 1:1, 1;n, n:n )

Krotność ( liczność )	Symbol graficzny
Jeden	1
Zero lub jeden	0...1
Jeden lub wiele	1...*
Podana liczba	5
Zakres liczb	4...7
Zakres lub liczba	3...7, 10






Student Wykład



1...* 1...*









10...20

0...*




Grupa laboratoryjna







Student może ale nie musi być przydzielony do wielu grup laboratoryjnych, do grupy laboratoryjnej musi być przypisanych nie mniej niż 10 i nie więcej niż 20 studentów. Student uczęszcza na wiele wykładów, wykład jest prowadzony dla wielu studentów

Możliwość opisania związków za pomocą pól które nie są za polami z żadnej z klas

Klasa pasażerów i klasa lot

Pasażer lecący danym lotem zajmuje jedno konkretne miejsce, miejsce ( numer ) nie opisuje ani lotu ani pasażera, jest opisem samego związku

Związek opisany dodatkową klasą która opisuje miejsce pasażera w danym locie





Pasażer 1...* 1...* Lot












miejsce







Związek uogólnienia ( generalizacji, specjalizacji )

Dwie klasy pozostają w związku uogólnienia jeżeli jedna z nich zawiera specjalizację, jest rodzajem drugiej

Klasa specjalizująca jest typem klasy uogólnionej uogólnienie








Klasa osoba Osoba student




to uogólnienie

klasy pracownik









uogólnienie




Klasa pracownik Pracownik


to uogólnienie

klasy kierownik projektu klasa generalizacji








uogólnienie




Kierownik klasa specjalizacji

Projektu







Generalizacja może mieć wiele specjalizacji i na odwrót

Dziedziczenie jest wynikiem związku uogólnienia




Osoba




Pesel

Data urodzenia


Imie i nazwisko

Adres




Wylicz wiek ( )





Student




Numer indeksu

Średnia ocen




Stypendium ( )




Pracownik




Data zatrudnienia

Stanowisko

Stawka godzinowa




Zarobek ( )

Staż pracy ( )







Kierownik

Projektu




Liczba projektów




Dodaj nowy

Projekt ( )

Związek - uogólnienia: ( można zauważyć pomiędzy )

• przypadki użycia

• aktorzy

Jeśli mamy generalizację taką że jest tylko 1 klasa będąca generalizacją.

Jeśli dana specjalizacja ma jedną generalizację to zachodzi dziedziczenie pojedyncze

Jeśli dana specjalizacja ma większą liczbę generalizacji to znaczy może dziedziczyć od wielu klas będących generalizacjami mówimy wtedy o zjawisku wielodziedziczenia





Element element

Oprocentowany do ubezpieczenia






dziedziczenie

wielodziedziczenie pojedyncze








Aktywa

















wielodziedziczenie






Rachunek nieruchomość papier

Bankowy wartościowy











dziedziczenie pojedyncze







Rachunek rachunek akcje obligacje

bieżący oszczędnościowy

Związek agregacji ( związek całość - część )

Jeżeli obiekt pewnej klasy tworzy całość składającą się z obiektów innych klas stanowiących części, w tym związki obiektów należące do całości, nie muszą być tego samego typu co obiekty stanowiące części.

1. Związek agregacji w szczególnym przypadku sprowadza się do kompozycji, dotyczy on wtedy bytów tego samego typu

2. wszystkie części w kompozycji przynależą tylko do jednej części
   - zlikwidowanie tej całości pociąga za sobą likwidację tych części
   

W przypadku agregacji ( normalnym ) - byty mogą być różnych typów i części występujące mogą przynależeć do więcej niż jednej całości

- likwidacja całości nie likwiduje części




przykład

związek zawierania się

Kompozycja uczelnia składa się z wydziałów







Agregacja

Ten sam typ










Uczelnia ma wydział
















1 1...* 1...*

całosć część całość

różne typy zatrudnia





każda część część

przynależy do wykładowca


jednej, jedynej 1...*


całości




( likwidacja uczelni ( całości ) )

( likwiduje wydział ( część ) )

szczególnym przypadkiem agregacji jest agregacja tego samego typu.

---