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