Inżynieria oprogramowania - Faza analizy
1. Celem fazy analizy jest ustalenie wszystkich tych czynników lub warunków w dziedzinie przedmiotowej, w otoczeniu realizatorów projektu w istniejących lub planowanych systemach komputerowych, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na realizację wymagań. Warunkiem jest logiczny model systemu opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujących od szczegółów implementacyjnych.
2. Cechy modelu analitycznego, czyli takiego który wykracza poza zakres odpowiedzialności systemu:
- uproszczony opis systemu
- hierarchiczna dekompozycja funkcji systemu
- model logiczny jest opisany przy pomocy notacji zgodnej z pewną konwerncją
- jest on zbudowany przy użyciu dobrze rozpoznanych metod oraz narzędzi
- jest on używany do wnioskowania o przyszłym oprogramowaniu
3. Logiczny model oprogramowania:
- pokazuje co system musi robić
- jest zorganizowany hierchicznie, wg poziomów abstrakcji
- unika terminologii implementacyjnej
- pozwala na wnioskowanie "od przyczyny do skutku" i odwrotnie
4. Czynności w fazie analizy:
- Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu;
- Ustalenie kontekstu projektu;
- Ustalenie wymagań użytkowników;
- Ustalenie wymagań organizacyjnych
- Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd.
- Budowa statycznego modelu klas
- Analiza funkcji i przypadków użycia
- Weryfikacja klas i obiektów
- Identyfikacja i definiowanie metod oraz komunikatów
- Modelowanie stanów i przejść między stanami
- Modelowanie procesów i przepływów danych
- Modelowanie przepływu sterowania
- język naturalny
- notacje graficzne
- specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny
7. Metodyki strukturalne - łączą statyczny opis danych oraz statyczny opis procesów.
8. W metodyce obiektowej podstawowym składnikiem jest diagram klas, który zawiera klasy, w ramach klas specyfikacje atrybutów i metod, związki generalizacji, związki asocjacji i agregacji, liczebności tych związków, różnorodne ograniczenia oraz inne oznaczenia. Uzupełnienie tego diagramu są inne: diagramy dynamiczne, diagramy interakcji, diagramy funkcjonalne itp.
9. Składnia określa, jak wolno kombinować ze sobą przyjęte oznaczenia.
10. Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami.
11. Pragmatyka określa, w jaki sposób i do czego należy używać przyjętych oznaczeń.
12. UML powstał jako synteza trzech metodyk/notacji:
- OMT (dobra do modelowania dziedziny przedmiotowej)
- OOSE (dobra do kwestii modelowania użytkowników i cykly życiowego systemu)
- OOAD (dobra do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji)
13. Diagramy definiowane w UML:
- Diagramy przypadków użycia
- Diagramy klas
- Diagramy zachowania się (diagramy stanów, aktywności, sekwencji, współpracy)
- Diagramy implementacyjne (diagramy komponentów, wdrożeniowe)
14. Proces tworzenia modelu obiektowego:
- identyfikacja klas i obiektów
- identyfikacja związków pomiędzy klasami
- identyfikacja i definiowanie pól
- identyfikacja i definiowanie metod i komunikatów
15. Należy zwrócić na następujące aspekty:
- czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej
- czy mamy do czynienia z konkretnym w pewnym odcinku czasu
- czy mamy do czynienia z opisem tego obiektu
- czy mamy do czynienia z pewnym zbiorem konkretnych obiektów