Inżynieria oprogramowania, wykład 3, slajd 1
Analiza i projektowanie oprogramowania
dr inż. Grzegorz
Bliźniuk
Inżynieria oprogramowania
wykład 3
Inżynieria oprogramowania, wykład 3, slajd 1
Analiza i projektowanie oprogramowania
dr inż. Grzegorz
Bliźniuk
Inżynieria oprogramowania
wykład 3
Inżynieria oprogramowania, wykład 3, slajd 2
Plan wykładu
1. Faza analizy systemów
2. Projektowanie architektoniczne
3. Przegląd metodyk pod kątem analizy i projektowania
4. Modele i wyniki pochodne fazy A&D
5. Narzędzia CASE
6. Podsumowanie
Bonus: materiały do samodzielnego studiowania
Przygotowane głównie na podstawie wykładu BYT K.Subiety,
D.Pierzchały
i materiałów własnych prowadzącego
Inżynieria oprogramowania, wykład 3, slajd 3
1. Faza analizy
Celem fazy określenia wymagań jest udzielenie odpowiedzi na
pytanie:
Co i przy jakich ograniczeniach system ma robić?
Wynikiem tej fazy jest zbiór wymagań na system.
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ń.
Wynikiem jest logiczny model systemu, opisujący sposób
realizacji przez system postawionych wymagań, lecz
abstrahujących od szczegółów implementacyjnych.
W odróżnieniu, celem fazy projektowania jest udzielenie odpowiedzi
na pytanie:
Jak system ma być zaimplementowany? Wynikiem jest opis sposobu
implementacji.
Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja
Faza strategiczna
Analiza
Instalacja
Dokumentacja
Inżynieria oprogramowania, wykład 3, slajd 4
Model analityczny
Z reguły wykracza poza zakres odpowiedzialności systemu. Przyczyny:
Ujęcie w modelu pewnych elementów dziedziny problemu nie
będących częścią systemu czyni model bardziej zrozumiałym.
Przykładem jest ujęcie w modelu systemów zewnętrznych, z
którymi system ma współpracować.
Na etapie modelowania może nie być jasne, które elementy
modelu będą realizowane przez oprogramowanie, a które w
sposób sprzętowy lub ręcznie.
Dostępne środki mogą nie pozwolić na
realizację systemu w całości.
Celem analizy może być wykrycie tych
fragmentów dziedziny problemu, których
wspomaganie za pomocą oprogramowania
będzie szczególnie przydatne.
Model analityczny
Zakres
odpowiedzialności
systemu
Dziedzina problemu
Inżynieria oprogramowania, wykład 3, slajd 5
Cechy modelu analitycznego
(logicznego)
Uproszczony opis systemu;
Hierarchiczna dekompozycja funkcji systemu;
Model logiczny jest opisany przy pomocy notacji zgodnej z
pewną konwencją;
Jest on zbudowany przy użyciu dobrze rozpoznanych metod i
narzędzi;
Jest on używany do wnioskowania o przyszłym oprogramowaniu;
Model oprogramowania powinien być jego uproszonym opisem,
opisującym wszystkie istotne cechy oprogramowania na
wysokim poziomie abstrakcji.
Model ten jednakże nie zastępuje doświadczenia i wnikliwości
projektantów, lecz pomaga projektantom w zastosowaniu tych
walorów.
Logiczny model oprogramowania:
• pokazuje co system musi robić;
• jest zorganizowany hierarchicznie, wg poziomów
abstrakcji
• unika terminologii implementacyjnej
• pozwala na wnioskowanie „od przyczyny do skutku” i
odwrotnie.
Inżynieria oprogramowania, wykład 3, slajd 6
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.
W zasadzie analiza nie powinna stawiać nacisku na zmianę
rzeczywistości poprzez wprowadzenie tam nowych elementów np.
w postaci systemu komputerowego. Jej celem jest rozpoznanie
wszystkich tych aspektów rzeczywistości, które mogłyby mieć
wpływ na postać, organizację lub wynik projektu.
Inżynieria oprogramowania, wykład 3, slajd 7
Reguły modelu logicznego opartego na
funkcjach
Funkcje muszą mieć pojedyncze, zdefiniowane cele.
Funkcje powinny być zdefiniowane na tym samym poziomie
(np.
funkcja Oblicz Sumę Kontrolną jest niższego poziomu niż funkcja
Obsługa Protokołu Sieciowego).
Interfejsy do funkcji (wejście i wyjście) powinny być minimalne.
Pozwala to na łatwiejsze oddzielenie poszczególnych funkcji.
Przy dekompozycji funkcji należy trzymać się zasady „nie więcej
niż 7 funkcji podrzędnych”.
Opis funkcji nie powinien odwoływać się do pojęć i terminów
implementacyjnych
(takich jak plik, zapis, zadanie, moduł, stacja
robocza).
Należy podawać wskaźniki wydajnościowe funkcji
(szybkość,
częstość, itd)
wszędzie tam, gdzie jest to możliwe.
Powinny być zidentyfikowane funkcje krytyczne
(od których zależy
istota systemu).
Nazwy funkcji powinny odzwierciedlać ich cel i mówić co ma być
zrobione, a nie jak ma być zrobione.
Nazwy funkcji powinny mieć charakter deklaracyjny
(np.
Walidacja Zlecenia Zewnętrznego),
a nie proceduralny
(np. Czynności
Systemu po Otrzymaniu Zlecenia).
Inżynieria oprogramowania, wykład 3, slajd 8
Notacje w fazie analizy
Rodzaje
notacji
Język naturalny
Notacje graficzne
Specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny
Szczególne znaczenie maja notacje graficzne. Inżynieria
oprogramowania wzoruje się na innych dziedzinach techniki,
takich jak elektronika i mechanika. Zalety notacji graficznych
potwierdzają badania psychologiczne.
Funkcje notacji
Narzędzie pracy analityka i projektanta, zapis i analiza pomysłów
Współpraca z użytkownikiem
Komunikacja z innymi członkami zespołu
Podstawa implementacji oprogramowania
Zapis dokumentacji technicznej
Notacje powinny być przejrzyste, proste, precyzyjne, łatwo zrozumiałe,
umożliwiające modelowanie złożonych zależności.
Inżynieria oprogramowania, wykład 3, slajd 9
Czynności procesu tworzenia
oprogramowania
Projektowanie i implementowanie wymagań:
– Charakterystyczne składowe analizy i projektowania:
Projektowanie
architektury
Specyfikowa
nie
abstrakcyjne
Projektowanie
interfejsów
Projektowanie
komponentów
Architektura
systemu
Specyfikacja
programowania
Specyfikacja
interfejsów
Specyfikacja
komponentów
Projektowan
ie
struktury
danych
Specyfikacja
struktury
danych
Specyfikacja
algorytmów
Projektowanie
algorytmów
Specyfikacja
wymagań
Produkty projektowania
Składowe projektowe
Inżynieria oprogramowania, wykład 3, slajd 10
Czynności procesu tworzenia
oprogramowania
Zakres fazy analizy:
–Wykracza poza zakres odpowiedzialności systemu ->
kontekst użycia i współpracy;
–Ujęcie w modelu pewnych elementów nie będących
częścią systemu -> model jest bardziej zrozumiały;
–Abstrakcja modelowania -> podczas modelowania może
nie być jasne, które elementy modelu będą realizowane
przez oprogramowanie a które w sposób sprzętowy lub
ręcznie;
–Dostępne środki mogą nie pozwolić na realizację systemu
w całości -> analiza może wykryć fragmenty, które mogą
być szczególnie ważne;
Inżynieria oprogramowania, wykład 3, slajd 11
Czynności procesu tworzenia
oprogramowania
Wybrane zadania i techniki fazy analizy i
projektowania:
–Ustalenie kontekstu projektu;
–Modelowanie i dokumentowanie rzeczywistości lub
problemu będącego przedmiotem projektu;
–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
Inżynieria oprogramowania, wykład 3, slajd 12
Architektura systemu
System informatyczny jest złożoną konstrukcją, której
stopień skomplikowania zależy od złożoności architektury;
Wielkie systemy są zwykle podzielone na podsystemy, które
oferują pewien zbiór powiązanych ze sobą interfejsów;
Wymagane jest projektowanie architektoniczne, którego
wynikiem jest opis architektury oprogramowania;
Urzeczywistnienie pomysłów architektonicznych wymaga:
–idei (pomysł, cel),
–planów (architektura, zagospodarowanie),
–wiedzy (metody, techniki),
–zasobów (materiały, narzędzia, czas, ludzie),
–nadzoru i pielęgnacji we wszystkich
etapach życia (projekt, budowa,
użytkowanie, wycofanie);
Inżynieria oprogramowania, wykład 3, slajd 13
Architektura systemu
Architektura systemu informatycznego jest modelem
systemu uwzględniającym decyzje analityka/projektanta
dotyczące podziału systemu na elementy składowe,
wzajemne relacje pomiędzy tymi elementami, interakcje
pomiędzy nimi, jak również ich przeznaczenie.
Często dla tego samego systemu opisuje się różne
architektury stanowiące różne i komplementarne
punkty jego widzenia, np.: architektura przetwarzania
danych,
architektura
bezpieczeństwa
systemu,
architektura
sprzętowo-systemowa,
architektura
interoperacyjności, architektura warstw systemu itd.
Inżynieria oprogramowania, wykład 3, slajd 14
Architektura systemu
Proces projektowania architektonicznego polega
na ustaleniu podstawowego zrębu systemu;
Podział architektoniczny jest niezbędny do
strukturalizacji i porządkowania specyfikacji;
Model architektoniczny jest zwykle punktem
początkowym do specyfikowania rozmaitych
części systemu;
Obejmuje identyfikację najważniejszych
komponentów systemu i komunikacji między
nimi;
Architektury są charakterystyczne dla różnych
dziedzin;
Inżynieria oprogramowania, wykład 3, slajd 15
Architektura systemu
Składowe procesy projektowania architektonicznego:
–Strukturalizacja systemu:
»System jest dzielony na kilka podstawowych podsystemów,
przy czym podsystem jest niezależną jednostką
oprogramowania;
»Identyfikuje się tu komunikację między podsystemami;
–Modelowanie sterowania:
»Określa się ogólny model związków sterowania między
częściami systemu;
–Podział na moduły:
»Każdy zidentyfikowany podsystem jest dzielony na moduły;
»Architekt musi wskazać typy modułów i ich połączenia;
Inżynieria oprogramowania, wykład 3, slajd 16
Architektura systemu
Wyniki projektowania architektonicznego:
–Dokumentacja zawierająca modele graficzne i opisy tekstowe;
–Modele przedstawiają rozmaite perspektywy architektury;
Modele architektoniczne:
–Statyczny model strukturalny - komponenty lub podsystemy,
które można zbudować jako niezależne jednostki;
–Model dynamiczny procesu - przedstawia się podział systemu
na procesy realizujące się podczas pracy systemu;
–Model interfejsów - definiuje się usługi oferowane przez każdy
podsystem za pośrednictwem jego interfejsu publicznego;
–Model związków - związki, takie jak przepływ danych między
podsystemami;
Inżynieria oprogramowania, wykład 3, slajd 17
Architektura systemu
Wybrane wyniki projektowania architektonicznego:
–Podsystem:
»jest systemem autonomicznym;
»jego usługi nie zależą od usług oferowanych przez inne podsystemy;
»składa się z modułów i ma interfejsy do komunikacji z innymi
podsystemami;
–Moduł:
»jest komponentem systemu - nie jest traktowany jako niezależny
system;
»oferuje usługi innym modułom i korzysta z usług innych modułów;
»zazwyczaj zbudowany z kilku innych, prostszych komponentów:
»prezentowany jako:
Model obiektowy - system jest dzielony na zbiór porozumiewających się obiektów;
Model przepływu danych (strukturalny) - system jest dzielony na moduły
funkcjonalne, które pobierają dane wejściowe i przetwarzają je na dane wyjściowe;
Inżynieria oprogramowania, wykład 3, slajd 18
Architektura systemu
Modele obiektowe:
–Model obiektowy architektury systemu dzieli
system na zbiór luźno uzależnionych od siebie
obiektów, z dobrze zdefiniowanymi interfejsami.
–Obiekty korzystają z usług oferowanych przez
inne obiekty.
–Podział obiektowy uwzględnia klasy obiektów,
ich atrybuty i operacje.
Inżynieria oprogramowania, wykład 3, slajd 19
Architektura systemu
Modele przepływu danych:
–Przekształcenia funkcyjne przetwarzają swoje dane
wejściowe na dane wyjściowe.
–Dane przepływają od jednego do drugiego procesu i są
przekształcane w miarę swojej wędrówki przez cały ciąg.
–Każdy krok przetwarzania jest implementowany jako
przekształcenie.
–Dane wejściowe przepływają przez te przekształcenia do
chwili wytworzenia z nich danych wyjściowych.
–Przekształcenia mogą działać sekwencyjnie lub
równolegle.
–Przekształcenie może przetwarzać dane jedna po drugiej
lub w postaci jednego wsadu.
Inżynieria oprogramowania, wykład 3, slajd 20
Architektura systemu
Modele przepływu danych:
Wystaw
upomnienia
Wystaw
pokwitowania
Zidentyfikuj
płatności
Odczytaj
wystawione
faktury
Płatności
Faktury
Upomnienia
Pokwitowanie
Znajdź
przetermino
wane
faktury
Inżynieria oprogramowania, wykład 3, slajd 21
Architektura systemu
Własności architektury systemu:
–Efektywność (performance)
» Krytyczne operacje w niewielkiej liczbie podsystemów aby
zminimalizować komunikację
–Zabezpieczenie (security)
» Należy zastosować w architekturze strukturę warstwową, krytyczne
elementy w warstwie wewnętrznej
–Bezpieczeństwo (safety)
» Operacje dotyczące bezpieczeństwa powinny znaleźć się w jednym
podsystemie lub w niewielkiej liczbie podsystemów.
–Dostępność (availability)
» Należy uwzględnić w architekturze komponenty nadmiarowe.
–Zdatność do pielęgnacji (maintainability)
» Architektura systemu powinna składać się z drobnoziarnistych,
samodzielnych komponentów.
Inżynieria oprogramowania, wykład 3, slajd 22
Architektura systemu
Własności architektury systemu - security vs.
safety:
–Security (zabezpieczenie):
»Niedopuszczenie do nieautoryzowanego dostępu do danych;
»Dotyczy narażenia na ryzyko prywatności;
»Przewiduje i zabezpiecza przed złośliwymi działaniami;
–Safety (bezpieczeństwo):
»Uniknięcie groźnych konsekwencji;
»Dotyczy bardziej narażenia na niebezpieczeństwo ludzkiego
życia, środowiska;
»Przewiduje nie tylko złośliwe działania, ale także te w dobrej
intencji, które mogą narazić na niebezpieczeństwo;
Inżynieria oprogramowania, wykład 3, slajd 23
Czynności procesu tworzenia
oprogramowania
Projektowanie i implementowanie wymagań:
–Metodyki (metody) analizy i projektowania:
»strukturalne;
»coraz bardziej popularne obiektowe;
–Ich użycie polega głównie na opracowaniu graficznych
modeli systemu oraz opisów tekstowych wg ustalonych
szablonów;
–Metodyka:
»Strategia postępowania oparta na doświadczeniach i
heurystykach oraz zbiorach reguł, zasad, metod, technik i
narzędzi;
–Metoda:
»uporządkowane procedura, która poprzez zdefiniowane techniki
umożliwia posługiwanie się narzędziami;
Inżynieria oprogramowania, wykład 3, slajd 24
3. Przegląd metodyk A&D
Obecnie dominują dwa podejścia:
1.
Podejście semantyczne (nazywane
również strukturalnym)
2.
Podeście obiektowe
Inżynieria oprogramowania, wykład 3, slajd 25
Notacja a metodyka
Dowolny język, w tym notacje stosowane w metodykach, oprócz
składni posiada dwa znacznie od niej ważniejsze aspekty:
semantykę i pragmatykę.
Pragmatyka określa, jak do konkretnej sytuacji dopasować pewien wzorzec
notacyjny. Pragmatyka wyznacza więc procesy prowadzące do wytworzenia
zapisów wyników analizy i projektowania, które są zgodne z intencją
autorów tej notacji. Jakakolwiek notacja nie ma większego sensu bez
wiedzy o tym, w jaki sposób może być ona użyta w ramach pewnego
procesu analizy i projektowania.
W metodykach pragmatyka stosowanej notacji (czyli jak i do czego jej
użyć) jest sprawą podstawową. Jest ona zazwyczaj trudna do objaśnienia:
nie ma innego sposobu oprócz pokazania sposobów użycia na przykładach
przypominających realne sytuacje. Niestety, realne sytuacje są zazwyczaj
bardzo skomplikowane, co powoduje pewien infantylizm przykładów
zamieszczanych w podręcznikach.
Semantyka
określa, co należy rozumieć pod przyjętymi
oznaczeniami.
Pragmatyka
określa, w jaki sposób i do czego należy używać
przyjętych oznaczeń.
Składnia
określa, jak wolno kombinować ze sobą przyjęte
oznaczenia.
Inżynieria oprogramowania, wykład 3, slajd 26
Metodyki strukturalne – podejście
semantyczne
Metodyki strukturalne - łączą statyczny opis danych oraz
statyczny opis procesów.
Do tej klasy należą:
• Metodyka Yourdona (DeMarco i Ward/Mellor);
• Structured System Analysis and Design Methodology (SSADM);
• Structured Analysis and Design Technique (SADT).
Uważa się, że wadą
metodyk
strukturalnych są
trudności w
zintegrowaniu modeli.
Zgodnie z DeMarco, analiza strukturalna używa następujących technik.
•
Diagramy Przepływu Danych (Data Flow Diagrams, DFD)
• Słownik Danych (Data Dictionary)
• Strukturalny Angielski (Structured English) -> strukturalny polski
• Tablice Decyzyjne (Decision Tables)
• Drzewa Decyzyjne (Decision Trees)
structured methodologies, structured analysis
Dodatkowo:
•
Schemat Transformacyjny (Transformation Schema)
• Diagram Przejść Stanów (State Transition Diagram)
• Lista Zdarzeń (Event List)
• Schemat Danych (Data Schema)
• Pre- i post- warunki (Pre- and Post-Conditions)
• Diagramy Encja-Związek (występują w SSADM)
• Historie Życia Encji (występują w SSADM)
Inżynieria oprogramowania, wykład 3, slajd 27
Klasyczny cykl życia w analizie
strukturalnej
Inżynieria oprogramowania, wykład 3, slajd 28
Strategia
Obejmuje:
–ogólny model przedsiębiorstwa,
–wymagania,
–harmonogram prac,
–ograniczenia finansowe i techniczne;
Modele:
–procesów (PD),
–danych (ERD),
–funkcji (FHD),
–przepływów (DFD);
Inżynieria oprogramowania, wykład 3, slajd 29
Faza analizy strukturalnej
Głównym celem analizy jest wprowadzenie strukturalnej
specyfikacji opisu projektu za pomocą narzędzi
modelowania:
–diagramów przepływu danych — DFD,
–diagramów obiekt-relacja-atrybut — ERD,
–diagramów przejść stanów — STD;
Wynikiem analizy jest zbudowanie następujących modeli:
–model otoczenia,
–model zachowania systemu;
Modele są opisem formalnym systemu, niezależnym od
technologii, jakiej użyje się do implementacji nowego
systemu;
Na końcu etapu analizy określa się dokładniej niż w
poprzednim etapie budżet projektu oraz kalkulację
kosztów i zysków;
Inżynieria oprogramowania, wykład 3, slajd 30
Faza projektowania strukturalnego
Polega na:
–wyodrębnienie tych części modelu zachowania systemu, które będą
implementowane w systemie informatycznym;
–przydzielenie poszczególnych części specyfikacji do odpowiednich
procesorów lub serwerów (przetwarzanie rozproszone); fragmenty
DFD (te, które będą implementowane) są mapowane na zadania;
–zaprojektowanie struktury hierarchii modułów wewnątrz danego
zadania;
–transformacja diagramów ERD na relacyjną bazę danych
(projektowanie logiczne danych);
W fazie implementacji:
–realizowane jest kodowanie i integracja modułów;
–stosuje się techniki programowania strukturalnego oraz
implementacji top-down;
Inżynieria oprogramowania, wykład 3, slajd 31
Poziomy modelowania systemu
Inżynieria oprogramowania, wykład 3, slajd 32
Modelowanie procesów
Określa kolejność i miejsce realizacji
funkcji przedsiębiorstwa;
Umożliwia i ułatwia komunikację
pomiędzy:
–różnymi działami firmy,
–użytkownikami a projektantami,
–projektantami a programistami;
Pozwala na zrozumienie
funkcjonowania organizacji;
Inżynieria oprogramowania, wykład 3, slajd 33
Modelowanie danych
Służy określeniu potrzeb informacyjnych firmy lub
organizacji;
Modelowanie przepływu danych (ang. Dataflow
Diagrams)
:
–ma na celu zobrazowanie procesów zachodzących w organizacji,
wymiany informacji między nimi oraz miejsc wprowadzania i
wyprowadzania danych;
Modelowanie związków encji ma na celu:
–dostarczenie dokładnego modelu potrzeb informacyjnych
przedsiębiorstwa, który stanowiłby podstawę do konstruowania
nowych lub ulepszonych systemów;
–dostarczanie modelu niezależnego od sposobu przechowywania
danych i metod dostępu do nich, umożliwiającego podejmowanie
decyzji, dotyczących metod implementacji oraz współdziałania z
istniejącymi systemami;
Inżynieria oprogramowania, wykład 3, slajd 34
Diagramy związków encji
Inżynieria oprogramowania, wykład 3, slajd 35
Diagramy przepływu danych
Opisują przepływ informacji pomiędzy
funkcjami - procesami realizowanymi w
systemie
Reprezentuje wymianę danych między
elementami systemu i wymianę danych ze
światem zewnętrznym
Inżynieria oprogramowania, wykład 3, slajd 36
Modelowanie hierarchii funkcji
Modelowanie hierarchii funkcji tworzy diagramy pokazujące
dekompozycję funkcji na różnych poziomach działalności
przedsiębiorstwa
Inżynieria oprogramowania, wykład 3, slajd 37
Reguły dla modelowania funkcji
Funkcje muszą mieć pojedyncze, zdefiniowane cele.
Interfejsy do funkcji (wejście i wyjście) powinny być minimalne,
co pozwala to na łatwiejsze oddzielenie poszczególnych funkcji.
Przy dekompozycji funkcji należy trzymać się zasady „nie
więcej niż 7+/-2 funkcji podrzędnych”.
Opis funkcji nie powinien odwoływać się do pojęć i terminów
implementacyjnych (takich jak plik, zapis, moduł, stacja
robocza).
Należy podawać wskaźniki wydajnościowe funkcji (szybkość,
częstość, itd.) wszędzie tam, gdzie jest to możliwe.
Powinny być zidentyfikowane funkcje krytyczne (od których
zależy istota systemu).
Nazwy funkcji powinny odzwierciedlać ich cel i mówić co ma
być zrobione, a nie jak ma być zrobione.
Nazwy funkcji powinny mieć charakter deklaracyjny (np.
Walidacja Zlecenia Zewnętrznego), a nie proceduralny (np.
Czynności Systemu po Otrzymaniu Zlecenia).
Inżynieria oprogramowania, wykład 3, slajd 38
Custom Development Method (CDM)
Przykład metodyki - CDM-Oracle-1996
–stosowana do procesów biznesowych i funkcji, które nie
mogą być obsłużone za pomocą dostępnych aplikacji „z
półki”;
–CDM jest zbiorem zdefiniowanych procesów tworzenia
oprogramowania, które zostały określone przy założeniu,
że w procesie wytwórczym stosowane są metody i
narzędzia CASE;
–zakłada, że potrzeby biznesowe zostają wyraźnie
zdefiniowane na samym początku cyklu projektowego
oraz że ich zweryfikowanie jest możliwe podczas całego
procesu wytwórczego;
Inżynieria oprogramowania, wykład 3, slajd 39
Custom Development Method (CDM)
CDM wyróżnia następujące procesy:
–definicja potrzeb biznesowych (studium możliwości),
–analiza istniejących systemów,
–opracowanie architektury technicznej,
–projektowanie i budowa bazy danych,
–projektowanie i budowa modułów,
–konwersja danych,
–opracowanie dokumentacji technicznej,
–testowanie,
–szkolenie,
–przejście na nowy system,
–obsługa serwisowa;
Inżynieria oprogramowania, wykład 3, slajd 40
Custom Development Method (CDM) –
ścieżka pełna
Procesy CDM:
Definicja wymagań
Analiza istniejących
systemów
Architektura
techniczna
Projekt i budowa
bazy danych
Projekt i budowa
modułów
Konwersja danych
Dokumentacja
Testowanie
Szkolenia
Wdrożenie
Obsługa serwisowa
Fazy
Definicja Analiza Projektowanie Programowanie
Wdrożenie Eksploatacja
ORACLE
Inżynieria oprogramowania, wykład 3, slajd 41
Custom Development Method (CDM) –
ścieżka szybka
Procesy CDM:
Definicja wymagań
Analiza istniejących
systemów
Architektura
techniczna
Projekt i budowa
bazy danych
Projekt i budowa
modułów
Konwersja danych
Dokumentacja
Testowanie
Szkolenia
Wdrożenie
Obsługa serwisowa
Fazy
Modelowanie wymagań Projekt i generacja produkcji
Wdrożenie do produkcji
ORACLE
Inżynieria oprogramowania, wykład 3, slajd 42
Metodyki strukturalne a obiektowe
Metodyki strukturalne:
–wadą metodyk strukturalnych są trudności w
zintegrowaniu modeli;
–metodyki strukturalne są dojrzałe, lecz mogą nie być
adekwatne do współczesnych tendencji wytwarzania
systemów informatycznych;
Metodyki obiektowe:
–młode i szybko zmieniające się;
–wymagają dużego nakładu pracy;
–wprowadzają narzuty implementacyjne;
–dobre dla systemów czasu rzeczywistego;
Inżynieria oprogramowania, wykład 3, slajd 43
Obiektowe podejścia do wytwarzania
oprogramowania
System jest analizowany w sposób obiektowy jeśli:
–
Jest dzielony na obiekty posiadające:
»Tożsamość, Stan, Zachowanie
–
Obiekty są grupowane w klasy złożone z obiektów o
podobnych stanach i zachowaniu
Metody obiektowe:
–
są wygodnym narzędziem analizy złożonych systemów, w
szczególności systemów o dużej stronie pasywności i
złożonej funkcjonalności
–
ukrywają dane (hermetyzacja)
–
wykorzystują gotowe elementy
–
pozwalają na szybkie prototypowanie i przyrostowy rozwój
–
programowanie oparte na zdarzeniach
Inżynieria oprogramowania, wykład 3, slajd 44
Metodyki obiektowe
Metodyka wykorzystująca pojęcia obiektowości dla celów
modelowania pojęciowego oraz analizy i projektowania
systemów informatycznych.
Podstawowym składnikiem jest diagram klas, będący zwykle
wariantem notacyjnym i pewnym rozszerzeniem diagramów
encja-związek.
Diagram klas zawiera: klasy, w ramach klas specyfikacje
atrybutów i metod, związki generalizacji, związki asocjacji i
agregacji, liczności tych związków, różnorodne ograniczenia
oraz inne oznaczenia.
Uzupełnieniem tego diagramu są inne: diagramy dynamiczne
uwzględniające stany i przejścia pomiędzy tymi stanami,
diagramy
interakcji
ustalające
zależności
pomiędzy
wywołaniami metod, diagramy funkcjonalne (będące zwykle
pewną mutacją diagramów przepływu danych), itd.
Koncepcja
przypadków
użycia
(use
cases)
zakłada
odwzorowanie struktury systemu z punktu widzenia jego
użytkownika.
Przykłady: Express, OODA(Booch), OMT(Rumbaugh), OOSA(Shlaer-
Mellor), Objectory(Jacobson), MOSES/OPEN, OOA/OOD(Coad/Yourdon),
Notacja UML - RUP.
Inżynieria oprogramowania, wykład 3, slajd 45
Różnice pomiędzy metodykami
Podejścia proponowane przez różnych autorów różnią się
częściowo, nie muszą być jednak ze sobą sprzeczne. Nie ma
metodyk uniwersalnych. Analitycy i projektanci wybierają
kombinację technik i notacji, która jest w danym momencie
najbardziej przydatna.
Poszczególne
metodyki
zawierają
elementy
rzadko
wykorzystywane w praktyce (np. model przepływu danych w
OMT).
Notacje proponowane przez różnych autorów nie są
koniecznie nierozerwalne z samą metodyką. Np. notacji UML
można użyć dla metodyki Coad/Yourdon.
Narzędzia CASE nie narzucają metodyki; raczej, określają one
tylko notację. Twierdzenia, że jakieś narzędzie CASE “jest
oparte” na konkretnej metodyce jest często wyłącznie hasłem
reklamowym. Nawet najlepsze metodyki i narzędzia CASE nie
są w stanie zapewnić jakości projektów.
Kluczem
do
dobrego
projektu
jest
zespół
doświadczonych, zaangażowanych i kompetentnych
osób, dla których metodyki, notacje i narzędzia CASE
służą jako istotne wspomaganie.
Inżynieria oprogramowania, wykład 3, slajd 46
UML - przykład notacji
UML (Unified Modeling Language) powstał jako synteza trzech
metodyk/notacji:
OMT (Rumbaugh): metodyka ta była dobra do
modelowania dziedziny przedmiotowej. Nie przykrywała
jednak dostatecznie dokładnie zarówno aspektu
użytkowników systemu jak i aspektu
implementacji/konstrukcji.
Objectory (Jacobson): metodyka ta dobrze podchodziła do
kwestii modelowania użytkowników i cyklu życiowego
systemu. Nie przykrywała jednak dokładnie modelowania
dziedziny przedmiotowej jak i aspektu
implementacji/konstrukcji.
OOAD (Booch): metodyka dobrze podchodziła do kwestii
projektowania, konstrukcji i związków ze środowiskiem
implementacji. Nie przykrywała jednak dostatecznie dobrze
fazy analizy i rozpoznania wymagań użytkowników.
Istniało wiele aspektów systemów, które nie były właściwie
przykryte przez żadne z wyżej wymienionych podejść, np.
włączenie prototypowania w cykl życiowy, rozproszenie i
komponenty, przystosowanie notacji do preferencji projektantów, i
inne. Celem UML jest przykrycie również tych aspektów.
Inżynieria oprogramowania, wykład 3, slajd 47
Diagramy definiowane w UML
Diagramy przypadków użycia (use case)
Diagramy klas,
w tym diagramy pakietów
Diagramy zachowania się (behavior)
Diagramy implementacyjne
• Diagramy stanów
• Diagramy aktywności
• Diagramy sekwencji
• Diagramy współpracy (collaboration)
• Diagramy komponentów
• Diagramy wdrożeniowe (deployment)
Autorzy UML wychodzą z założenia, że żadna pojedyncza
perspektywa spojrzenia na projektowany system nie jest
wystarczająca. Stąd wiele środków:
Diagramy te zapewniają mnogość perspektyw systemu podczas analizy i rozwoju.
Opis wymagań
Analiza,
projekt
wstępny
Projekt
szczegółowy,
wstępna
implementacja
Inżynieria oprogramowania, wykład 3, slajd 48
Proces tworzenia modelu obiektowego
Zadania:
Identyfikacja klas i obiektów
Identyfikacja związków pomiędzy klasami
Identyfikacja i definiowanie pól (atrybutów)
Identyfikacja i definiowanie metod i komunikatów
Czynności te są wykonywane iteracyjnie. Kolejność ich
wykonywania nie jest ustalona i zależy zarówno od stylu pracy,
jak i od konkretnego problemu.
Inny schemat realizacji procesu budowy modelu obiektowego
polega na rozpoznaniu funkcji, które system ma wykonywać.
Dopiero w późniejszej fazie następuje identyfikacja klas,
związków, atrybutów i metod. Rozpoznaniu funkcji systemu służą
modele funkcjonalne (diagramy przepływu danych) oraz model
przypadków użycia.
Inżynieria oprogramowania, wykład 3, slajd 49
Identyfikacja klas i obiektów
Typowe klasy:
przedmioty namacalne (samochód, czujnik)
role pełnione przez osoby (pracownik, wykładowca, student)
zdarzenia, o których system przechowuje informacje (lądowanie
samolotu, wysłanie zamówienia, dostawa),
interakcje pomiędzy osobami i/lub systemami o których system
przechowuje informacje (pożyczka, spotkanie, sesja),
lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów
grupy przedmiotów namacalnych (kartoteka, samochód jako
zestaw części)
organizacje (firma, wydział, związek)
wydarzenia (posiedzenie sejmu, demonstracja uliczna)
koncepcje i pojęcia (zadanie, miara jakości)
dokumenty (faktura, prawo jazdy)
klasy będące interfejsami dla systemów zewnętrznych
klasy będące interfejsami dla urządzeń sprzętowych
Inżynieria oprogramowania, wykład 3, slajd 50
3. Przegląd metodyk, c.d. - RUP
4. Przykłady modeli i wyników fazy A&D
Wcześniej pokazano kilka
przykładów diagramów z metody
CDM
Na kolejnych slajdach będą
pokazane modele z metodyki RUP
Inżynieria oprogramowania, wykład 3, slajd 51
RUP
Ukierunkowany na przypadki użycia
Architekturo-centryczny
Iteracyjny
Przyrostowy
Sterowany ryzykiem
Inżynieria oprogramowania, wykład 3, slajd 52
RUP
Dwa wymiary RUP
– FAZY (ang. phases)
– PRZEPŁYWY, DYSCYPLINY (ang. disciplines)
Inżynieria oprogramowania, wykład 3, slajd 53
RUP
Proces budowy systemu informatycznego
składa się z dyscyplin, z których każda
dzielona jest na fazy:
–Rozpoczęcie
–Opracowanie
–Budowa
–Przekazanie
Kamienie milowe
Podejście iteracyjne
Inżynieria oprogramowania, wykład 3, slajd 54
System mapy pogody
Przykład z książki Iana Sommerville’a „Inżynieria
oprogramowania”
System tworzący mapy pogody ma regularnie generować
mapy pogody;
Źródła danych:
–zdalne, niestrzeżone stacje meteorologiczne,
–inne źródła danych: obserwatorzy pogody, balony i satelity;
Stacje meteorologiczne
–przekazują dane do komputera obszaru na jego żądania;
System komputera obszaru
–weryfikuje i integruje dane zebrane z różnych źródeł;
Po zintegrowaniu dane są archiwizowane w zbiorach;
Lokalne mapy pogody są tworzone na podstawie archiwum i
bazy danych map komputerowych;
Mapy można drukować lub wyświetlać w różnych formatach;
Inżynieria oprogramowania, wykład 3, slajd 55
System mapy pogody
Zadania systemu:
–zbieranie danych,
–integracja danych z różnych źródeł,
–archiwizowanie danych,
–tworzenie map pogody;
Każdy etap działania zależy jedynie od wyników
przetwarzania z poprzedniego etapu;
Proponowana architektura:
–warstwowa,
–odzwierciedla etapy przetwarzania danych w systemie:
zbieranie danych, integrację danych itd.;
Inżynieria oprogramowania, wykład 3, slajd 56
Architektura warstwowa systemu mapy
pogody
Warstwa wyświetlania danych
Obiekty warstwy przygotowują dane w postaci
zrozumiałej dla człowieka
Warstwa archiwizacji danych
Obiekty warstwy zajmują się
składowaniem danych
Warstwa przetwarzania danych
Obiekty warstwy weryfikują i integrują
dane
Warstwa gromadzenia danych
Obiekty warstwy zajmują się
pozyskaniem danych ze zdalnych źródeł
Propozycja architektury systemu
Gromadzenie
danych
<<subsystem>>
Przetwarzanie danych
<<subsystem>>
Archiwizacja danych
Wyświetlanie danych
Inżynieria oprogramowania, wykład 3, slajd 57
Podsystemy w systemie mapy pogody
<<subsystem>>
Gromadzenie
danych
Obserwator
Balon
Stacja meteoro-
logiczna
Satelita
Wspólne
<<subsystm
>>
Przetwarzan
ie
danych
Sprawdzanie
danych
Integracja
danych
<<subsystem>>
Wyświetlanie
danych
Interfejs
użytkownika
Mapa
Drukarka
map
Wyświetlacz
map
Składowanie
danych
Składnica
map
Składnica
danych
<<subsystem>>
Archiwizacja danych
Inżynieria oprogramowania, wykład 3, slajd 58
Kontekst systemu i modele użycia
systemu
Pierwszy krok
procesu projektowania
oprogramowania:
–zrozumienie związków między projektowanym
oprogramowaniem a jego środowiskiem
zewnętrznym;
–określenie kontekstu systemu:
»model statyczny;
»tu jest to podsystem gromadzenia danych;
–określenie modeli użycia systemu
»model dynamiczny
»opisuje, w jaki sposób system porozumiewa się ze swoim
środowiskiem;
Inżynieria oprogramowania, wykład 3, slajd 59
Przypadki użycia stacji
meteorologicznej
Dostrój
Uruchom
Wyłącz
Raportuj
Użytkownik
Testuj
Inżynieria oprogramowania, wykład 3, slajd 60
Przypadki użycia stacji
meteorologicznej
System
Stacja meteorologiczna
Przypadek użycia Raportuj
Aktorzy
System gromadzenia informacji
meteorologicznych, Stacja
meteorologiczna
Dane
Stacja meteorologiczna wysyła do systemu gromadzenia
informacji
meteorologicznych podsumowanie danych
meteorologicznych odczytanych
z przyrządów w określonym czasie.
Przesyłane dane to: maksymalne,
minimalne i średnie
temperatury gruntu i powietrza, maksymalne, minimalne i
średnie ciśnienia powietrza, maksymalną, minimalną i średnią prędkość wiatru,
całkowity opad i kierunek wiatru (co 5 minut).
Bodziec
System gromadzenia informacji meteorologicznych
nawiązuje połączenie
ze stacją meteorologiczną i wywołuje
przekazanie danych.
Reakcja
Wysyłanie podsumowania danych do systemu
gromadzenia informacji
meteorologicznych.
Komentarz
Stacje meteorologiczne są proszone o raport zazwyczaj raz na
godzinę.
Ta częstotliwość może być inna dla różnych stacji i w
przyszłości może
ulec zmianie.
Opis przypadku użycia „Raportuj”
Inżynieria oprogramowania, wykład 3, slajd 61
Projektowanie architektury
Drugi krok
procesu projektowania
oprogramowania:
–projektowanie architektury;
Architektura na przykładzie automatycznej stacji
meteorologicznej (model 3-warstwowy):
–1-warstwa interfejsu –
»porozumiewanie się z innymi częściami systemu i oferowanie
zewnętrznych interfejsów systemu;
–2-warstwa gromadzenia danych
»zarządzanie odczytem danych z przyrządów i podsumowywanie
danych meteorologicznych przed przesłaniem ich do systemu
tworzącego mapy;
–3-warstwa przyrządów
»pakiet przyrządów służących do gromadzenia surowych danych
o warunkach pogodowych;
Inżynieria oprogramowania, wykład 3, slajd 62
Architektura stacji meteorologicznej
Stacja meteorologiczna
Gromadzenie
danych
<<subsystem>>
Przyrządy
<<subsystem>>
Interfejs
<<subsystem>>
Obsługuje całą
komunikację
zewnętrzną
Gromadzi i
podsumowuje dane
Pakiet przyrządów
do zbierania
surowych danych
Inżynieria oprogramowania, wykład 3, slajd 63
Klasy obiektów stacji meteorologicznej
Trzeci
krok procesu projektowania oprogramowania:
–Identyfikacja (wynajdowanie) klas i obiektów;
StacjaMeteorologiczna - oferuje podstawowy interfejs
stacji meteorologicznej;
DaneMeteorologiczne - jej operacje służą do
gromadzenia i podsumowywania danych odczytanych
z różnych przyrządów stacji meteorologicznej;
Termometr gruntowy, Wiatromierz i Barometr -
bezpośrednio związane z przyrządami systemu;
odzwierciedlają namacalne byty sprzętowe systemu;
operacje służą do sterowania tym sprzętem;
Inżynieria oprogramowania, wykład 3, slajd 64
Klasy obiektów stacji meteorologicznej
StacjaMeteorologiczna
identyfikator
raportPogodowy ()
dostrój (przyrządy)
testuj ()
uruchom (przyrządy)
wyłącz (przyrządy)
DaneMeteorologiczne
temperaturyPowietrza
temperaturyGruntu
siłyWiatru
kierunkiWiatru
cisnienia
opad
gromadź ()
podsumuj ()
Termometr
gruntowy
temperatura
testuj ()
dostrój ()
Wiatromierz
SiłaWiatru
kierunekWiat
ru
test ()
Barom
etr
ciśnieni
e
wysoko
ść
test ()
dostrój
()
Przykłady klas obiektów w systemie stacji meteorologicznej
Inżynieria oprogramowania, wykład 3, slajd 65
Klasy obiektów stacji meteorologicznej
<<subsystem>>
Interfejs
SterownikKomunikacji
StacjaMeteorologiczna
DaneMeteorologiczne
<<subsystem>>
Gromadzenie danych
Stan
przyrządów
<<subsystem>>
Przyrządy
Termometr
powietrza
Termometr
gruntowy
Barometr
Łopatka
wiatrowa
Wskaźnik
opadu
Wiatromierz
Przykład modelu podsystemów: powiązania obiektów
stacji meteorologicznych
Inżynieria oprogramowania, wykład 3, slajd 66
Sekwencja zdarzeń
:Sterownik
Komunikacji
:Stacja
Meteorologiczna
:Dane
Meteorologiczne
podsumu
j ()
raportuj ()
wyślij (raport)
żądanie
(raport)
potwierdzenie ()
odpowiedź (raport)
potwierdzenie ()
Użytkownik
Czwarty
krok procesu projektowania
Przebieg operacji Gromadzenia danych
Inżynieria oprogramowania, wykład 3, slajd 67
Diagramy stanów
Wyłączony
Działan
ie
Transmitowanie
Testowanie
Dostrajanie
Oczekiwanie
Podsumowywanie
Gromadzenie
uruchom
()
wyłącz
()
zegar
koniec
gromadzenia
koniec transmisji
testuj ()
dostrój ()
dostrojony
koniec testu
P
o
d
s
u
m
o
w
a
n
i
e
g
o
t
o
w
e
podsumowa
nie
gotowe
raportPogodow
y ()
Przykład dla klasy StacjaMeteorologiczna
Piąty
krok procesu projektowania
Inżynieria oprogramowania, wykład 3, slajd 68
Specyfikowanie interfejsów obiektów
Szósty
krok procesu projektowania:
–specyfikowanie interfejsów między komponentami;
Pozwoli to na równoległe projektowanie
komponentów;
Jeden obiekt może mieć kilka interfejsów,
które
są
sposobami
postrzegania
oferowanych metod;
Realizacja w Java - interfejsy są deklarowane
w oderwaniu od obiektów, a obiekty
„implementują” interfejsy;
Inżynieria oprogramowania, wykład 3, slajd 69
Specyfikowanie interfejsów obiektów
Interfejs StacjaMeteorologiczna {
public StacjaMeteorologiczna () ;
public void uruchom () ;
public void uruchom (Przyrząd p) ;
public void wyłącz () ;
public void wyłącz (Przyrząd p) ;
public void raportPogodowy () ;
public void testuj () ;
public void testuj (Przyrząd p) ;
public void dostrój (Przyrząd p) ;
public int podajID () ;
} // StacjaMeteorologiczna
Inżynieria oprogramowania, wykład 3, slajd 70
Ewolucja projektu
Kolejne
kroki projektowania:
–uszczegółowienie uproszczonego modelu;
Zmiana wstępnie ustalonych
szczegółów obiektu - nie wpłynie na
inne obiekty systemowe;
Wprowadzenie nowych obiektów - nie
prowadzi do istotnych konsekwencji
dla reszty systemu (obiekty są luźno
powiązane);
Inżynieria oprogramowania, wykład 3, slajd 71
Ewolucja projektu
Do obiektu StacjaMeteorologiczna na tym
samym poziomie co obiekt DaneMeteorologiczne
należy dodać obiekt o nazwie Jakość powietrza;
Należy dodać operację raport Jakości powietrza,
której działanie polega na wysłaniu danych o
zanieczyszczeniach do głównego komputera;
Należy dodać obiekty reprezentujące przyrządy
do pomiaru poziomu zanieczyszczeń. W tym
wypadku pomiarom będą podlegać tlenek azotu,
dym i benzen;
Inżynieria oprogramowania, wykład 3, slajd 72
Ewolucja projektu
Przyrządy do pomiaru zanieczyszczeń
MiernikTlenkuAzotu
MiernikBenzenu
MiernikDymu
StacjaMeteorologiczna
Identifier
raportPogodowy ()
raportJakościPowietrza ()
dostrój (przyrządy)
testuj ()
uruchom (przyrządy)
wyłącz (przyrządy)
Jakość powietrza
poziomTlenkuAzotu
poziomDymu
poziomBenzenu
gromadź ()
podsumuj ()
Nowe obiekty do monitorowania zanieczyszczeń
Inżynieria oprogramowania, wykład 3, slajd 73
CASE – Computer Aided Software Engineering
Dla dwóch podejść do analizy i projektowania systemów mamy
dwa wiodące na rynku systemy notacyjne i narzędzia CASE
pochodzące od:
–
IBM Rational UML
(Booch, Jacobson, Rumbaugh) –
Rational Rose
podejście obiektowe
–
Oracle CASE Method
(Barker) – Oracle Designer
podejście semantyczne
Narzędzia te poznamy w czasie zajęć laboratoryjnych
5. Narzędzia CASE
6. Podsumowanie
dziękuję za uwagę
Inżynieria oprogramowania, wykład 3, slajd 74
Materiały dodatkowe
Do samodzielnego przestudiowania
przez Studentów
Inżynieria oprogramowania, wykład 3, slajd 75
A
B
A
B
1
A
B
1
A
B
A
B
A
B
A
B
1..N
A
B
1,m
A
B
1+
A
B
A
B
A
B
0..
1
A
B
0,1
A
B
A
B
A
B
A
B
N
A
B
0,m
A
B
A
B
Równoważne wersje opisu siły i liczności
związków
(analisys)
Inżynieria oprogramowania, wykład 3, slajd 76
Metodyki obiektowe
Wykorzystują pojęcia obiektowości do modelowania
oraz analizy i projektowania systemów informatycznych;
Podstawowym jest diagram klas, będący zwykle
wariantem notacyjnym i pewnym rozszerzeniem
diagramów encja-związek;
Uzupełnieniem diagramu klas są inne: diagramy
dynamiczne uwzględniające stany i przejścia pomiędzy
tymi stanami, diagramy interakcji ustalające zależności
pomiędzy wywołaniami metod, diagramy funkcjonalne
(będące zwykle pewną mutacją diagramów przepływu
danych);
Koncepcja przypadków użycia (use cases) zakłada
odwzorowanie struktury systemu z punktu widzenia
jego użytkownika;
Inżynieria oprogramowania, wykład 3, slajd 77
Obiektowe podejścia do wytwarzania
oprogramowania
Analiza obiektowa
–opracowanie modelu obiektowego dziedziny zastosowania;
–rozpoznane obiekty odzwierciedlają byty i operacje związane z
rozwiązywanym problemem;
Projektowanie obiektowe
–opracowanie modelu obiektowego systemu oprogramowania, który
będzie implementacją zidentyfikowanych wymagań;
–obiekty projektu obiektowego są związane z rozwiązaniem
problemu;
Programowanie obiektowe
–realizacja projektu oprogramowania za pomocą języka
programowania obiektowego;
–języki obiektowe umożliwiają bezpośrednią implementację
obiektów i dostarczają udogodnienia do definiowania klas obiektów;
Inżynieria oprogramowania, wykład 3, slajd 78
Faza analizy
Podstawowe rezultaty fazy analizy
–Poprawiony dokument opisujący wymagania;
–Słownik danych zawierający specyfikację
modelu;
–Dokument opisujący stworzony model
analityczny;
–Harmonogram fazy projektowania;
–Wstępne przypisanie ludzi i zespołów do zadań;
–Uzyskane przy użyciu dobrze rozpoznanych
metod i narzędzi;
Inżynieria oprogramowania, wykład 3, slajd 79
Faza analizy
Model analityczny - uproszczony opis systemu:
–hierarchiczna dekompozycja funkcji systemu;
–logiczny model oprogramowania:
» uproszony opis oprogramowania, opisujący wszystkie istotne cechy
oprogramowania na wysokim poziomie abstrakcji;
» opisany przy pomocy notacji zgodnej z pewną konwencją;
» pokazuje co system musi robić;
» jest zorganizowany hierarchicznie, wg poziomów abstrakcji;
» unika terminologii implementacyjnej;
» pozwala na wnioskowanie „od przyczyny do skutku” i odwrotnie;
–w podejściu obiektowym zawiera:
» diagram przypadków użycia,
» diagram klas,
» diagramy sekwencji komunikatów (dla wybranych sytuacji),
» diagramy stanów (dla wybranych sytuacji),
» raport zawierający definicje i opisy klas, atrybutów, związków, metod;
Inżynieria oprogramowania, wykład 3, slajd 80
Faza analizy
Identyfikacja aktorów:
–Grupy użytkowników wspierane przez system w:
»podstawowych i drugoplanowych zadaniach;
»administrowaniu i utrzymywaniu;
–Źródła danych wej. i odbiorcy wyników:
»osoby;
»zewnętrzne systemy lub urządzenia;
Identyfikacja przypadków użycia:
–Jakie zadania dla użytkownika realizuje system?
–Jakie dane z systemu interesują użytkownika lub system
zewnętrzny?
–Czy są zainteresowani zdarzeniami w systemie?
–Max liczba przypadków użycia: 5-15, 15-40, 40-100;
Inżynieria oprogramowania, wykład 3, slajd 81
Faza analizy
Identyfikacja klas obiektów - typowe klasy:
–przedmioty namacalne (np. samochód, czujnik),
–role pełnione przez osoby (np. pracownik, wykładowca, student),
–zdarzenia, o których system przechowuje informacje (lądowanie
samolotu, wysłanie zamówienia, dostawa),
–interakcje pomiędzy osobami i/lub systemami o których system
przechowuje informacje (np. pożyczka, spotkanie, sesja),
–lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów,
–grupy przedmiotów namacalnych (np. kartoteka, samochód jako
zestaw części),
–organizacje (np. firma, wydział, związek),
–wydarzenia (np. posiedzenie sejmu, demonstracja uliczna),
–koncepcje i pojęcia (np. zadanie, miara jakości),
–dokumenty (np. faktura, prawo jazdy),
–interfejsy do systemów zewnętrznych,
–interfejsy do urządzeń sprzętowych;
Inżynieria oprogramowania, wykład 3, slajd 82
Faza analizy
Obiekty, zbiory obiektów i metadane:
–W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z
jakiego rodzaju abstrakcją obiektu mamy do czynienia;
–Należy zwrócić uwagę na następujące aspekty:
»
czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej?
»
czy mamy do czynienia z konkretnym obiektem w pewnym odcinku
czasu?
»
czy mamy do czynienia z opisem tego obiektu (dokument, metadane)?
»
czy mamy do czynienia z pewnym zbiorem konkretnych obiektów?
Np. klasa „samochód” - może chodzić o:
–egzemplarz samochodu wyprodukowany przez pewną
fabrykę;
–model samochodu produkowany przez fabrykę;
–pozycję w katalogu samochodów opisujący własności
modelu;
–historię stanów pewnego konkretnego samochodu;
Inżynieria oprogramowania, wykład 3, slajd 83
Faza analizy
Zalecenia dotyczące identyfikacji klas:
– Wyraźnie zdefiniować kontekst (w tym opis) klasy;
– Unikać w nazwie synonimów i nazw zbliżonych znaczeniowo;
– Pomijać klasy, które nie mieszczą się w zakresie systemu;
– Wyeliminować klasy będące w rzeczywistości:
» atrybutami lub grupami atrybutów (właściwościami) innych klas;
» operacjami (usługami) innych klas;
» związkami lub rolami pełnionymi w związkach przez inne klasy;
można połączyć takie byty w większe klasy;
– Utworzyć wiele klas z jednej, jeżeli grupuje atrybuty lub operacje
kontekstowo odległe;
– Uzupełnić o atrybuty opisujące klasy w kontekście systemu;
– Klasy kontekstowo powiązane pogrupować w podsystemy – np.
kandydatami są grupy powiązane silnymi relacjami (np. dziedziczenie);
– Unikać w tej fazie klas reprezentujących elementy implementacyjne;
Inżynieria oprogramowania, wykład 3, slajd 84
Faza analizy
Zalecenia dotyczące identyfikacji związków klas:
–Unikać związków bez klasy docelowej;
–Pomijać związki z elementami spoza systemu;
–Dążyć do związków dwuelementowych;
–Zwracać szczególną uwagę na związki trwałe w czasie –
związki nietrwałe wykorzystać podczas konstrukcji modelu
dynamicznego (np. do budowy komunikatów);
–Kompletować związki i role klas w związkach;
–Uszczegółowić związki o krotności obiektów;
–Klasy o podobnych cechach powiązać relacją dziedziczenia;
–Zweryfikować dostępność informacji w modelu klasy-
związki-klasy z różnych punktów startowych;
–Unikać w tej fazie związków reprezentujących zależności
implementacyjne;
Inżynieria oprogramowania, wykład 3, slajd 85
Faza analizy
Zalecenia dotyczące modelu dynamicznego klas:
–Koncentrować się na behawioralnych aspektach systemu;
–Rozpatrzeć interakcje związane z pożądanym, błędnym i
awaryjnym zachowaniem systemu;
–Kompletować „trójki”: Nadawca (Aktor lub obiekt)-
zdarzenie-Odbiorca;
–Przedstawić uporządkowany w czasie przepływ zdarzeń w
systemie dla każdej klasy;
–Zdarzenia odpowiadające jednej klasie należy łączyć we
wspólny diagram;
Inżynieria oprogramowania, wykład 3, slajd 86
Faza analizy
Kluczowe czynniki sukcesu fazy analizy
–Zaangażowanie właściwych osób ze strony klienta;
–Kompleksowe i całościowe podejście do problemu, nie
koncentrowanie się na partykularnych jego aspektach;
–Nie unikanie trudnych problemów (bezpieczeństwo,
skalowalność, szacunki objętości i przyrostu danych, itd.);
–Zachowanie przyjętych standardów, np. w zakresie
notacji;
–Sprawdzenie poprawności i wzajemnej spójności modelu;
–Przejrzystość, logiczny układ i spójność dokumentacji;
Inżynieria oprogramowania, wykład 3, slajd 87
Od analizy do szczegółowego projektu
obiektów
Celem projektowania jest opracowanie szczegółowego opisu
implementacji systemu.
W odróżnieniu od analizy, w projektowaniu dużą rolę
odgrywa środowisko implementacji.
Dwa etapy fazy projektowania:
–projekt strategiczny, projekt systemy (strategic, system design):
» podział na podsystemy,
» współbieżność,
» przechowywanie danych,
» sterowanie.
–projekt szczegółowy (detailed design):
» uściślanie definicji klas,
» dziedziczenie,
» optymalizacja modelu,
» modularyzacja,
» ukrywanie informacji;
Inżynieria oprogramowania, wykład 3, slajd 88
Faza projektowania
Zadania w etapach fazy projektowania:
–uściślenie istniejących definicji klas, np. metod,
–dziedziczenie klas i operacji,
–szczegółowy projekt operacji wraz z przeprojektowaniem ich
algorytmów,
–wprowadzenie ogólnych mechanizmów realizacji dynamiki
obiektów,
–decyzje o trwałości obiektów,
–modularyzacja i ukrywanie informacji,
–optymalizacja modelu,
–dokumentacja projektu;
Zatem projektanci muszą więc posiadać dobrą znajomość
języków, bibliotek, i narzędzi stosowanych w trakcie
implementacji;
Inżynieria oprogramowania, wykład 3, slajd 89
Faza projektowania
Zadania fazy projektowania – przykład uściślenia
definicji metod;
–Podanie nagłówków metod oraz ich parametrów.
–Określenie, które z metod będą realizowane jako funkcje
wirtualne (poźno wiązane) a które jako zwyczajne funkcje
(wiązane statyczne).
–Zastąpienie niektórych prostych metod bezpośrednim
dostępem do atrybutów.
»Np. metody PobierzNazwisko, UstawNazwisko, etc.
–Zastąpienie niektórych atrybutów redundantnych przez
odpowiednie metody, np.
»Wiek = BieżącaData - DataUrodzenia;
»KwotaDochodu = KwotaPrzychodu - KwotaKosztów;
Inżynieria oprogramowania, wykład 3, slajd 90
Faza projektowania
Zadania fazy projektowania – przykład sposobu
implementacji związków (asocjacji);
–Związki można zaimplementować na wiele sposobów, z reguły
poprzez wprowadzenie dodatkowych atrybutów (pól) - mogą one
być następujące:
» obiekty powiązanej klasy,
» wskaźniki (referencje) do obiektów powiązanej klasy,
» identyfikatory obiektów powiązanej klasy,
» klucze kandydujące obiektów powiązanej klasy;
–W zależności od przyjętego sposobu oraz od liczności związków
(
1:1, 1:n, n:1, m:n
) możliwe są bardzo różne deklaracje w
przyjętym języku programowania.
TypSłowoKluczowe SłowaKluczowe[100];
list< TypSłowoKluczowe *> SłowaKluczowe;
char * WskaźnikiSłówKluczowych[100];
Tablica obiektów:
Lista wskaźników:
Tablica wskaźników:
Inżynieria oprogramowania, wykład 3, slajd 91
Podstawowe rezultaty fazy
projektowania
Poprawiony i uszczegółowiony dokument opisujący wymagania;
Poprawione i uszczegółowione modele;
Uszczegółowiona specyfikacja słownika danych;
Dokument opisujący stworzony projekt składający się z (dla
obiektowych):
–
diagramu klas
–
diagramów interakcji obiektów
–
diagramów stanów
–
innych diagramów, np. diagramów modułów, konfiguracji
–
zestawień zawierających:
» definicje klas
» definicje atrybutów
» definicje danych złożonych i elementarnych
» definicje metod
Zasoby interfejsu użytkownika, np. menu, dialogi;
Projekt bazy danych;
Projekt fizycznej struktury systemu;
Poprawiony plan testów;
Pierwszy harmonogram implementacji;
Inżynieria oprogramowania, wykład 3, slajd 92
Jakość i poprawność modeli
Poprawność i kompletność projektu:
–Poprawność oznacza, że opis projektu jest zgodny z zasadami
posługiwania się notacjami.
–Nie gwarantuje, że projekt jest zgodny z wymaganiami użytkownika.
–Poprawny projekt musi być:
» kompletny
» niesprzeczny
» spójny
» zgodny z regułami składniowymi notacji
–Kompletność projektu oznacza, że zdefiniowane są:
» wszystkie klasy
» wszystkie pola (atrybuty)
» wszystkie metody
» wszystkie dane złożone i elementarne
» a także że opisany jest sposób realizacji wszystkich wymagań
funkcjonalnych.
–Spójność projektu oznacza semantyczną zgodność wszystkich
informacji zawartych na poszczególnych diagramach i w specyfikacji.
Inżynieria oprogramowania, wykład 3, slajd 93
Jakość i poprawność modeli
Poprawność diagramów klas i stanów:
–Diagramy klas:
» Acykliczność związków generalizacji-specjalizacji;
» Opcjonalność cyklicznych związków agregacji;
» Brak klas nie powiązanych w żaden sposób z innymi klasami;
(Sytuacja taka może się jednak pojawić, jeżeli projekt dotyczy
biblioteki klas, a nie całej aplikacji)
» Umieszczenie w opisie metod informacji o parametrach wejściowych,
wyjściowych i specyfikacji wyniku;
–Diagramy stanów:
» Brak stanów (oprócz początkowego), do których nie ma przejścia;
» Brak stanów (oprócz końcowego), z których nie ma wyjścia;
» Jednoznaczność wyjść ze stanów pod wpływem określonych
zdarzeń/warunków;
Inżynieria oprogramowania, wykład 3, slajd 94
Jakość i poprawność modeli
Optymalizacja projektu:
–Bezpośrednia implementacja projektu może prowadzić do
systemu o zbyt niskiej efektywności.
»Wykonanie pewnych funkcji jest zbyt wolne;
»Struktury danych mogą wymagać zbyt dużej pamięci operacyjnej i
masowej;
–Optymalizacja może być dokonana:
»Na poziomie projektu;
»Na poziomie implementacji;
–Sposoby stosowane na etapie implementacji:
»Stosowanie zmiennych statycznych zamiast dynamicznych
(lokalnych);
»Umieszczanie zagnieżdżonego kodu zamiast wywoływania procedur;
»Dobór typów o minimalnej, niezbędnej wartości;
Inżynieria oprogramowania, wykład 3, slajd 95
Jakość i poprawność modeli
Co może przynieść zasadnicze zyski optymalizacyjne?
–Zmiana algorytmu przetwarzania.
» Np. zmiana algorytmu sortującego poprzez wprowadzenie pośredniego
pliku zawierającego tylko klucze i wskaźniki do sortowanych obiektów
może przynieść nawet 100-krotny zysk.
–Wyłowienie “wąskich gardeł” w przetwarzaniu i optymalizacja tych
wąskich gardeł poprzez starannie rozpracowane procedury.
» Znane jest twierdzenie, że 20% kodu jest wykonywane przez 80% czasu.
–Zaprogramowanie “wąskich gardeł” w języku niższego poziomu,
np. w C dla programów w 4GL.
–Denormalizacja relacyjnej bazy danych, łączenie dwóch lub więcej
tablic w jedną.
–Stosowanie indeksów, tablic wskaźników i innych struktur
pomocniczych.
–Analiza mechanizmów buforowania danych w pamięci operacyjnej
i ewentualna zmiana tego mechanizmu (np. zmniejszenie liczby
poziomów).
Inżynieria oprogramowania, wykład 3, slajd 96
Diagram klas opisuje wynik analizy w podejściu
obiektowym
Course
Student
Professor
RegistrationUser
RegistrationForm
RegistrationManager
CourseOffering
ScheduleAlgorithm
addStudent(Course, StudentInfo
)
open()
addStudent(StudentInfo)
open()
addStudent(StudentInfo)
major
name
numberCredits
location
tenureStatus
name
1
0..*
0..*
1
1
1..*
4
3..10
0..4
1
UML Diagram asocjacji klas (CAD)
(analisys)
Inżynieria oprogramowania, wykład 3, slajd 97
Diagramy stanów
(behavior)
Pochodzą od koncepcji „map stanów” (statecharts) Harela
Idea pierwotna: odwzorowanie stanu obiektów pewnej klasy
podczas ich cyklu życiowego oraz przejścia pomiędzy tymi
stanami powodowane przez zdarzenia.
W UML diagramy stanów zostały uogólnione i stanowią
raczej diagramy przepływu sterowania (flowcharts) z
drugorzędnymi opcjami syntaktycznymi i semantycznymi.
Stany odnoszą się nie do pojedynczego obiektu lecz raczej
do przebiegu pewnego procesu lub przypadku użycia.
W większości przypadków diagramy stanów są albo zbędne,
albo trudne do sporządzenia.
Powinny być tworzone tylko wtedy, kiedy zachowanie
danego procesu jest złożone i dające się dobrze zdefiniować.
Inżynieria oprogramowania, wykład 3, slajd 98
Stan spoczynku
Sygnał ciągły
Wybieranie numeru
Łączenie
Dzwonek
Połączenie
Rozłączenie
Komunikat o błędzie
Koniec limitu czasu
Sygnał zajętości
położenie słuchawki
podniesienie
słuchawki
położenie słuchawki
czas się skończył
cyfra(n)
cyfra(n)
błędny numer
czas się
skończył
prawidłowy numer
linia zajęta
podniesienie
słuchawki przez
odbiorcę
położenie słuchawki
przez odbiorcę
koniec komunikatu
Diagramy stanów - przykład działania telefonu
(behavior)
Inżynieria oprogramowania, wykład 3, slajd 99
Diagramy aktywności
(behavior)
W swoim pomyśle pochodzą od sieci Petriego (Petri
Nets)
Jest to odmiana diagramów stanów, w których stany są
aktywnościami reprezentującymi wykonywanie się
operacji, a dowolna tranzycja (przejście) wykonuje się
automatycznie po zakończeniu aktywności, w której
tranzycja ma źródło.
Zawierają elementy synchronizacji procesów
równoległych i współbieżnych.
Wykorzystywane najczęściej wtedy, gdy opisywany
proces lub przypadek użycia jest jest dostatecznie
złożony, ale możliwy do zobrazowania na diagramie o
rozsądnych rozmiarach.
Inżynieria oprogramowania, wykład 3, slajd 100
Nasyp
kawy do
filtra
Dolej
wody do
zbiornika
Weź
filiżankę
Włóż filtr
do
maszynki
Włącz
maszynkę
Gotowani
e kawy
Nalej
kawę
Diagramy aktywności – przykład obsługi ekspresu
do kawy
(behavior)
Inżynieria oprogramowania, wykład 3, slajd 101
Wymiar pionowy - czas
Wymiar poziomy -
obiekty (kolejność
obiektów nie ma
znaczenia)
Istotna jest kolejność
pewnych zdarzeń a nie
rzeczywista miara czasu
Dla systemów
uwarunkowanych
czasowo czas może być
przedstawiony w
pewnej mierzalnej skali
Obiekt 2:"Klasa 1"
Obiekt 1:"Klasa 1"
Zdarzenie 2
Zdarzenie 1
Zdarzenie 1
Zdarzenie 2
Zdarzenie 1
Zdarzenie 1
Diagramy sekwencji
(behavior)
Inżynieria oprogramowania, wykład 3, slajd 102
Diagramy sekwencji – elementy notacji
(behavior)
Obiekt
aktywny
Obiekt
nieaktywny
Alternatyw
ne
zachowani
e się
obiektu
Tworzenie
i
kasowanie
obiektu
Inżynieria oprogramowania, wykład 3, slajd 103
: Student
registration
form
registration
manager
math 101
1: fill in info
2: submit
3: add course(joe, math 01)
4: add(Joe)
5: are you open?
6: add (Joe)
math 101
section 1
Diagram sekwencji – przykład rejestracji
studenta
(behavior)
Spróbuj dokonać interpretacji poniższego
diagramu sekwencji:
Inżynieria oprogramowania, wykład 3, slajd 104
Ze swojej natury są raczej słabym środkiem
specyfikacji programów.
Nadmierne wprowadzanie dodatkowych oznaczeń
może zaciemniać diagram, nie wprowadzając przy
tym wymaganej algorytmiczne precyzji.
W wielu sytuacjach diagramy te mogą znacznie
rozjaśnić zależności sterowania programu z
punktu widzenia modelowania pojęciowego.
Dla bardziej złożonych zależności sterowania lepiej
jest użyć diagramów stanów lub diagramów
aktywności.
Wady i zalety diagramów sekwencji
(behavior)
Inżynieria oprogramowania, wykład 3, slajd 105
Kontekst współpracy stanowi
statyczna struktura obiektów w
niej uczestniczących (włączając
związki, atrybuty i operacje).
Sekwencja komunikatów
wymienianych pomiędzy
obiektami dla realizacji
konkretnego zadania.
Współpraca może dotyczyć:
– skutków powodowanych przez
dany fragment programu w
środowisku zewnętrznym
– wewnętrznej implementacji
obiektów i ich zachowania
Obiekt 1:"Klasa 1"
Obiekt 2:"Klasa 1"
5: Zdarzenie 1
4: Zdarzenie 1
2: Zdarzenie 1
1: Zdarzenie 1
6: Zdarzenie 2
3: Zdarzenie 2
Diagramy współpracy obiektów
(behavior)
Inżynieria oprogramowania, wykład 3, slajd 106
: Registrar
course form :
CourseForm
theManager :
CurriculumManager
aCourse :
Course
1: set course info
2: process
3: add course
4: new course
Diagram współpracy – przykład definiowania
kursów
(behavior)
Diagram opisujący przepływ komunikatów w
systemie
Inżynieria oprogramowania, wykład 3, slajd 107
Course
Course
Offering
Student
Professor
Course.dll
People.dll
Course
User
Register.exe
Billing.exe
Billing
System
Diagramy komponentów
(implementation)
Umożliwiają opis fizycznych komponentów
aplikacji wraz z przyporządkowaniem do
nich elementów modelu logicznego (np.
obiekty, aktorzy)
Inżynieria oprogramowania, wykład 3, slajd 108
Diagramy wdrożeniowe (montażowe)
(implementation)
Registration
Database
Library
Dorm
Main
Building
Umożliwiają opis fizycznej alokacji poszczególnych
komponentów aplikacji – na przykład w serwerowniach
głównych, serwerowniach zapasowych, czy też miejscach
użytkowania aplikacji na urządzeniach statycznych i
urządzeniach mobilnych