Inżynieria
oprogramowania
Opracowanie wykładow
WST
P
Inżynieria oprogramowania - Powszechnie przyjęta nazwa procesu tworzenia
programowania. Stanowi zbiór umiejętności, pojęd i procedur, mających pomóc ludziom
dobrze wykonywad pracę w tworzeniu oprogramowania. Ma za zadanie doprowadzid do
produkcji wysokiej jakości oprogramowania. Czyli oprogramowanie to produkt, a więc
oprogramowanie powinno byd:
" zgodne z wymaganiami i oczekiwaniami
użytkownika
" niezawodne
" efektywne
" łatwe w konserwacji
" ergonomiczne
Jest to wiedza polegająca m.in. na umiejętności pracy w zespole, tworzeniu nie tylko kodu,
ale specyfikacji i architektury projektu, umiejętności modelowania, weryfikacji i testowania,
a także opracowania użytecznych metryk i pielęgnowania wszystkich wytworzonych
składników oprogramowania i dokumentacji, oraz umiejętności planowania i zarządzania
całym przedsięwzięciem programistycznym.
1
Historia
1950-60  drobne oprogramowanie  cele naukowe
1960-80  liczniejsze zastosowania komputerów  rozwój języków programowania wyższego
poziomu
1980-00  gwałtowny rozwój sprzętu i znaczne zwiększenie jego możliwości  próby
nadążenia z oprogramowaniem  kompletne fiasko (wiele przedsięwzięd informatycznych
nie zakooczono ze względu na ich zbyt wielką złożonośd bądz
też przekroczenie założonego
czasu lub budżetu.
Kryzys oprogramowania:
Rozwój technik programowania nie nadąża za rozwojem sprzętu.
 Programista nie może panowad na raz nad więcej niż jednym ekranem tekstu programu
 Komputer wykona to, co zaprogramujesz, a nie to czego oczekujesz
 Błędy w programie ujawniają się dopiero po przeprowadzeniu kontroli programu
 Testowanie wskazuje błędy w oprogramowaniu, lecz nie wskazuje jego bezbłędności
 Nie ma programów bezbłędnych, znalezienie w nich błędów jest tylko kwestią czasu
użytkowania
Szacowanie ilości niewykrytych błędów:
1. Wprowadzamy do systemu 1000 sztucznych błędów;
2. Każemy programistom wyszukiwad błędy w systemie;
3. Zakładając, że znaleziono n błędów w tym k sztucznych oraz n-k prawdziwych ilośd błędów
prawdziwych: il.bł.praw/1000=(n-k)/k
Szacowanie ilości błędów:
- Nie wykazuje gdzie są błędy;
- Zlicza tylko lokalne błędy typowe;
- Nie wskazuje przyczyn błędów.
Analiza przyczyn kryzysu oprogramowania wskazała następujące przyczyny:
" Duża złożonośd systemów informatycznych
" Niepowtarzalnośd poszczególnych przedsięwzięd
" Brak przejrzystych procedur opisu procesu budowy oprogramowania pozwalających na
precyzyjną ocenę stopnia zaawansowania projektu (wpadki: ZUS Płatnik, NFZ -
Świadczeniodawca, PESEL, system rejestracji pojazdów, CELNIK itd.)
" Założenie liniowości w procesie tworzenia kodu programu.
Propozycje wyjścia z kryzysu oprogramowania zaowocowały powstaniem nowego działu
informatyki - INŻYNIERIA OPROGRAMOWANIA
Co to jest inżynieria i produkt zwany oprogramowaniem
- analogia do innych specjalności  wiedza techniczna , zawód!!!
Pojęcia dotyczące tworzenia oprogramowania (odrobina filozofii)
- zespół czy indywiduum
- modele cyklu życia oprogramowania
- Szacowanie kosztów oprogramowania
2
ZAKRES INŻYNIERII OPROGRAMOWANIA
�� Zasady tworzenia oprogramowania:
- kontrola intelektualna nad projektem, dziel i zwyciężaj, odbiorcy?
od ogółu do szczegółu, dokumentuj!, wszystko to we-wy, co ze zmianami, nie wyważaj
otwartych drzwi, wez
odpowiedzialnośd.
�� Technologie wytwarzania oprogramowania
- podejście strukturalne i obiektowe
�� Cykl życia oprogramowania
- rola fazy strategicznej, etapy tworzenia oprogramowania (wymagania, specyfikowanie,
projektowanie, kodowanie, testowanie, konserwacja)
�� Wymagania
- analiza problemu, interpretacja potrzeb użytkownika (zrozumienie), dzielenie wejśd i wyjśd,
prototypowanie
- właściwości dobrych wymagao: brak elementów nieistotnych, poprawnośd, kompletnośd,
zwięzłośd, precyzja, jasnośd, jednoznacznośd, spójnośd, możliwośd śledzenia, łatwośd
modyfikacji, możliwośd testowania (weryfikacji), wykonalnośd!!
- przypadki użycia, uczestnicy, warunki początkowe, rozszerzenia
�� Specyfikowanie
- odbiorcy i ich potrzeby, precyzowanie wymagao-formalizm (precyzja jest celem)
- języki specyfikacji  metody formalne i nieformalne
- oprogramowanie niebezpieczne
- Programowanie specyfikacji  wprowadzenie do języka Prolog
�� Projektowanie
- ogólne zasady projektowania jako etap fazy analizy
- etapy projektowania (wysokiego poziomu i szczegółowe)
- tworzenie modeli obiektowych i strukturalnych,
- Sztuka tworzenia interfejsów
- notacja formalna
�� Kodowanie
- języki programowania i narzędzia wspomagające (analizatory, skrypty)
�� Projektowanie z użyciem pseudokodu
�� Abstrakcyjne typy danych, hermetyzacja i język C
�� Projektowanie obiektowe
- Obiekty rzeczywiste i programowe, wymagania obiektowe
- Języki obiektowe  Smalltalk, C++, Java - wprowadzenie
�� Diagramy przepływu danych
�� Kierowanie etapami projektowania i kodowania
�� Testowanie oprogramowania
- plan testów w trakcie cyklu życia
- Inspekcja a testowanie
- testowanie funkcjonalne i oparte na błędach
- testowanie jednostek i systemu
- testowanie losowe, automatyczne, systematyczne, regresywne
- Zarządzanie testowaniem
3
�� Dokumentacja systemu informatycznego
�� Wdrożenie systemu informatycznego
�� Zarządzanie projektem informatycznym
- konteksty procesu (interpersonalny, zachowawczy, organizacyjny)
- rola menagera, definiowanie projektu, zespół, sied krytyczna projektu, ryzyko i niepewnośd,
kontrola projektu, komunikacja i wymiana informacji w projekcie.
�� Narzędzia CASE w Inżynierii Oprogramowania.
ZESPÓA
TWORZ
CY OPROGRAMOWANIE
Klient
Zadania:
1. Zarządzanie produktem
2. Zarządzanie projektem
3. Programowanie
4. Testowanie
5. Doświadczenie użytkowników
6. Wdrażanie
�� Klientowi nigdy nie przyjdzie na myśl ile kosztuje produkt programistyczny (projekt),
tylko ile można na tym produkcie zarobid lub zaoszczędzid
�� Żaden klient tak do kooca nie wie czego chce
�� Każdy klient wie czego nie chce
�� Żaden klient nie chce tego co mamy już gotowe
�� Nie wie tak do kooca co chciałby zamiast tego
�� Jeżeli udało ci się wprowadzid w programie wymagane przez klienta poprawki, wtedy
często on z nich rezygnuje
�� Klient żąda większych zmian dokładnie wtedy, kiedy produkt jest już gotowy
�� Nie ma pełnej satysfakcji z produktu przy braku aktywności Klienta
Użytkownicy
1. Z statystyki rynku wynika iż 80% użytkowników programów stosuje tylko 20% ich funkcji
2. Z kolei 20% użytkowników wymaga 80 procent funkcji których program nie posiada
3. Kiedy opanujesz już dany program, to pojawi się jego nowa wersja czyniąca poprzednią
zupełnie przestarzałą
4. Podstawowa wada użytkowników produktów informatycznych to przyzwyczajenia
5. Nie istnieje pojęcie użytkownika zadowolonego (bo nie ma programów bezbłędnych 
wyjątek stanowią użytkownicy będący projektantami
6. Ilośd wykrytych błędów w oprogramowaniu jest proporcjonalna do ilości użytkowników
4
ZASADY TWORZENIA OPROGRAMOWANIA
1. Tylko złożone oprogramowanie wymaga inżynierii (cykl życia składający się z modelowania
i testowania oraz sprzężenia zwrotnego  prosty problem, zajęcia z programowania)
2. Złożonośd przedsięwzięcia programistycznego stanowi trzon problemu (niepowodzenie
uwarunkowane utratą kontroli intelektualnej)
3. Ogólną metodą rozwiązywania złożoności jest dekompozycja zagadnienia na części (sztuką
jest określenie, jakich?  pułapki!)
- rozwiązanie poszczególnych części może nie rozwiązad problemu  plan musi przewidywad
ich złożenie
- czasem części mogą byd trudniejsze do rozwiązania niż całośd.
Dziel i zwyciężaj (ogólna metoda rozwiązywania problemów)
1. Podstawa dekompozycji  części niezależne
2. Dekompozycja problemu przedstawiona w postaci drzewa
Odbiorcy
3. Każdy etap jest realizowany dla określonego odbiorcy (odbiorca zadao wykonanych na
danym etapie znajduje się na etapie następnym  wymagania  twórca  projektant 
kodujący  testujący (odbiorca na każdym etapie)
4. Zdolnośd do abstrakcyjnego myślenia jest bez wątpienia największym talentem ludzkiego
rozumu (największe niebezpieczeostwo) z kolei uogólnienie prowadzi do stereotypów
5. Zasada  od rozmycia do skupienia (wstępny ogólny diagram ma prowadzid do spójnych,
jasnych i jednoznacznych specyfikacji  rola inżyniera oprogramowania  system płacowy)
6. Dokumentacja  błędne jest twierdzenie  dobrze wykonana praca dokumentuje się sama
(kodowanie  program bez komentarzy jest prawie nie do zrozumienia), ( najbardziej
oczywiste informacje raz wykorzystane, nie zapisane, będą utracone ; notuj założenia i o
nich pamiętaj, nie powielaj informacji  powinna byd zapisana i ewentualnie modyfikowana
w jednym miejscu)
Dokumentacja
7. W dokumentacji nie stosuj synonimów i nie rozpraszaj pojęd
8. Wejście/wyjście (we-wy_ jest podstawą oprogramowania - określenie wszystkich wejśd i
wyjśd (widocznych i niewidocznych)
- określenie zakresu dopuszczalnego we-wy
- określenie szczególnych wartości we-wy (czek 0)
Nie przesadzaj!
1. Ma powstawad dobrze funkcjonujący program spełniający oczekiwania odbiorcy.
2. Jeżeli system nie jest uszkodzony nie naprawiaj go ( każdy system można poprawiad...
doprowadzając go do  śmierci )
3. Użytkownik docelowy ma decydujący głos w dyskusji na temat funkcji i użyteczności
produktu
4. Wykorzystaj poprzednie prace i doświadczenie  nie uszczęśliwiaj użytkownika (pulpit,
share documents, dokumentacja). Nie wynajduj koła!! Twórz oprogramowanie z myślą jego
ponownego wykorzystania.
5
5. Bądz
odpowiedzialny za oprogramowanie które tworzysz.
Rola menedżera
1. Dobry menedżer kierujący pracą inżyniera oprogramowania to osoba zapewniająca
odpowiedni sprzęt i izolująca inżynierów od problemów nietechnicznych.
2. Techniczne składniki pracy menedżera to harmonogram, budżet i jakośd.
3. Po rozpoczęciu projektu zadanie menedżera zmienia się ze zgadywania tego, co będzie
potrzebne na monitorowanie i utrzymywanie kierunku prac
Miary
1. Zarejestrowana historia (podobny projekt realizowaliśmy przez 1 rok) w inżynierii
oprogramowania nosi znamiona miary.
2. Powiązanie ilości kodu KDSI (thousand of delivered source code instruction), LOC (line of
code) z elementami potrzebnymi do napisania tego kodu:
Ludzie  ilu i w jakim czasie brało udział w realizacji projektu,
Czas  jak długi był harmonogram i jego poszczególne etapy
Sprzęt  jaki zasób rzeczy (komputery, biurka, pokoje, kawa był potrzebny
3. Brak własnych danych historycznych  modele estymacyjne  algorytmiczne (na podstawie
wzoru)
MODELE CYKLU ŻYCIA
�� Kaskadowy
Wady i zalety
1. Narzucona twórcom oprogramowania ścisła kontrola kolejności realizacji prac.
2. Wysoki koszt błędów popełnionych we wstępnych fazach ( błędy popełnione w fazie
wymagao i specyfikacji najpewniej zostaną odkryte dopiero w fazie testowania)
3. Klient (inwestor  użytkownik) bierze udział jedynie we wstępnej fazie projektu (jest mało
angażowany) więc jego zainteresowanie produktem słabnie, co ma oczywisty negatywny
wpływ na wartościowanie produktu przez Klienta.  Najbardziej cenimy to, co sami
wykonamy, lub jest realizowane z naszym udziałem
6
�� Realizacja kierowana dokumentami (model armii USA)
Kaskadowy z warunkiem kompletnej dokumentacji każdej fazy (szereg dokumentów
weryfikowanych przez klienta) pozwalającej nawet na zmianę firmy programistycznej
(dodatkowa praca, przerwy na
weryfikację).
�� Prototypowanie (prototyping)
Model pozwalający na minimalizację ryzyka związanego z błędami w fazie wymagao.
Pozwala na wyeliminowanie nieporozumieo klienta i twórców oprogramowania.
Prowadzi do wykrycia brakujących funkcji, trudnych usług, braków w specyfikacji
wymagao oraz punktów krytycznych systemu. (szybka demonstracja systemu,
wstępne szkolenia użytkowników.
Techniki:
" Niepełna realizacja  pominięcie elementów oczywistych i skupienie się na wymaganiach
trudnych.
" Opis systemu w językach wysokiego poziomu: Smalltalk. LISP, wykonywalne języki
specyfikacji formalnych.
" Wykorzystanie gotowych komponentów
" Szybkie programowanie (bez testów i finezji)
" Automatyczne generowanie interfejsu użytkownika
" Papier i ołówek  prototypowanie interfejsu uzytkownika
" Programowanie odkrywcze (exploratory programming) iteracyjna weryfikacja ogólnego
projektu przez klienta  systemy złożone
�� Programowanie odkrywcze
Złożone systemy o trudnych do sprecyzowania wymaganiach  cykliczna realizacja systemu
ogólnego do wymagao weryfikowanych przez klienta
Model może byd
stosowany
jako  sposób
tworzenia
systemu (amatorski).
Profesjonalnie stosuje
się go
w prototypowaniu
7
�� Realizacja przyrostowa
Po określeniu projektu wstępnego następuje iteracyjne testowanie podzbioru funkcji
systemu. Następnie jest realizowany projekt szczegółowy tej części i implementacja części
systemu realizującej te funkcje.
�� Montaż z gotowych elementów
Wykorzystywane na różnych etapach realizacji projektu (najczęściej implementacji) :
biblioteki, pełne aplikacje języki symboliczne itp.  narzędzia CASE (Computer Assisted/Aided
Software/System Engineering)
�� Model spiralny  (Boehma  1988)
Najbardziej ogólny model cyklu życia oprogramowania, cztery główne fazy cyklu życia
oprogramowania wykonywane cyklicznie: analiza ryzyka, konstrukcja, atestowanie,
planowanie.
" Niepełna realizacja  pominięcie elementów oczywistych i skupienie się na wymaganiach
trudnych.
" Opis systemu w językach wysokiego poziomu: Smalltalk. LISP, wykonywalne języki
specyfikacji formalnych.
" Wykorzystanie gotowych komponentów
" Szybkie programowanie (bez testów i finezji)
" Automatyczne generowanie interfejsu użytkownika
" Papier i ołówek  prototypowanie interfejsu uzytkownika
" Programowanie odkrywcze (exploratory programming) iteracyjna weryfikacja ogólnego
projektu przez klienta  systemy złożone
8
FAZA STRATEGICZNA
" Faza strategiczna (ang. strategy phase) jest wykonywana zanim zostanie podjęta decyzja o
realizacji dalszych etapów przedsięwzięcia.
" Faza, w której prowadzone są negocjacje z klientem/faza rozważania i planowania
produkcji nowego programu
" Celem tej fazy jest ustalenie możliwości realizacji przedsięwzięcia  ale nie tylko.
Czynności w fazie strategicznej
" rozmowy z klientami (przedstawicielami)
" cele przedsięwzięcia z punktu widzenia klienta
" zakres i kontekst przedsięwzięcia
" ogólne określenie wymagao  wykonanie wstępnej analizy i projektu systemu
" propozycja kilku sposobów realizacji systemu
" szacowanie kosztów oprogramowania
" analiza rozwiązao
" prezentacja wyników analizy klientowi  korekta
" budowa wstępnego harmonogramu
" określenie standardów wg których będzie realizowane przedsięwzięcie
" Określenie celów przedsięwzięcia z punktu widzenia klienta (jasne zdefiniowanie pozwala
uniknąd nieporozumieo, nawet jeśli cele są znane dla wszystkich osób zaangażowanych w
fazę strategiczną  to póz
niej niekoniecznie; ważny punkt odniesienia)
" Określenie zakresu przedsięwzięcia (jaką częśd działalności klienta ma obsługiwad system)
" Określenie kontekstu przedsięwzięcia (systemy zewnętrzne z którymi współpracowad
będzie tworzony system: program, sprzęt, grupa osób, działy firmy)
" Określenie celów, zakresu i kontekstu przedsięwzięcia to zwykle zbyt mało by oszacowad
złożonośd i koszt wykonania systemu
" Konieczne jest bardziej precyzyjne określenie wymagao, wykonanie modelu systemu oraz
wstępnego projektu (najlepiej pełne fazy wymagao, analizy i projektowania  ale zwykle nie
ma czasu i pieniędzy)
" W ogólny sposób opisad pełen zakres systemu (określid wszystkie główne wymagania oraz
wykonad ogólny model całości systemu)
" Typowym błędem jest zbyt szczegółowe koncentrowanie się na pewnych fragmentach
systemu, z pominięciem ogólnych wymagao.
Decyzje do podjęcia
" Wybór modelu zgodnie, z którym realizowane będzie przedsięwzięcie
" Wybór technik stosowanych w fazach analizy projektowania
" Wybór środowiska implementacji
" Wybór narzędzia CASE
" Określenie stopnia wykorzystania gotowych komponentów
" Podjęcie decyzji o współpracy z innymi producentami i/lub zatrudnieniu ekspertów z
zewnątrz
" Określenie ograniczeo przy których przedsięwzięcie ma byd zrealizowane:
- Maksymalne nakłady jakie można ponieśd na realizację przedsięwzięcia
- Dostępny personel
9
- Dostępne narzędzia
- Ograniczenia czasowe
Harmonogram przedsięwzięcia
Na tym etapie nie jest jeszcze możliwe wyszczególnienie poszczególnych zadao 
harmonogram jest bardzo ogólny i wymaga uszczegółowienia w dalszych fazach
Ocena rozwiązao
" Wybór najlepszego sposobu realizacji przedsięwzięcia jest podstawowym warunkiem
koocowego sukcesu.
" W fazie strategicznej rozważanych jest często kilka możliwych rozwiązao, z których wybiera
się najlepsze.
" Trudności z wyborem rozwiązao:
- wielośd celów przedsięwzięcia, czyli wielośd kryteriów oceny
- niepewnośd, tj. niemożnośd precyzyjnej oceny rezultatów
" Przykładowe kryteria oceny to: koszt, czas realizacji, niezawodnośd, stopieo możliwości
ponownego wykorzystania fragmentów systemu, przenośnośd na inne platformy, wydajnośd.
Wybór rozwiązania
" Usunięcie rozwiązao zdominowanych (rozwiązanie jest zdominowane jeśli istnieje inne
rozwiązanie nie gorsze z punktu widzenia żadnego kryterium i lepsze w co najmniej jednym
kryterium)
" Przydzielenie wag poszczególnym kryteriom
" Konieczne jest znormalizowanie wartości kryteriów (można je na przykład znormalizowad
do przedziału *0,1+, gdzie 0 oznacza najgorszą wartośd, a 1 najlepszą, pozostałym wartościom
 proporcjonalnie obliczone wartości)
" Znormalizowane wartości kryteriów przemnożone przez wagi i zsumowane dają łączną
ocenę rozwiązao
10
" Niepewnośd jest czynnikiem utrudniającym wybór najlepszego rozwiązania. Zwykle szacuje
się wartośd optymistyczną i pesymistyczną i wybiera strategię działania. Nie można w
obiektywny sposób stwierdzid która strategia jest lepsza
" Bardziej racjonalna ocena jest możliwa jeżeli dodatkowo zostaną oszacowane
prawdopodobieostwa subiektywne zajścia poszczególnych zdarzeo pod warunkiem wybrania
danego rozwiązania.
Spodziewany koszt rozwiązania - przykład:
A= koszt pesymistyczny * prawdopodobieostwo pesymistycznego rozwiązania + koszt
optymistyczny * prawdopodobieostwo optymistycznego rozwiązania = 0.5*100+0.5*40=70
*tys. zł+
Spodziewany koszt rozwiązania B= 0.2*80+0.8*65=68 *tys. zł+
Szacowanie kosztów oprogramowania
" Na koszt oprogramowania składają się następujące czynniki:
- koszt sprzętu będącego częścią tworzonego systemu
- koszt wyjazdów i szkoleo
- koszt zakupu narzędzi
- nakład pracy
" Trzy pierwsze czynniki są stosunkowo łatwe do oszacowania, natomiast ocena nakładów
pracy niezbędnych dla zrealizowania systemu jest bardzo trudna.Szacowanie kosztów
oprogramowania jest praktycznie tożsame z szacowaniem nakładów pracy.
Metody szacowania kosztów oprogramowania:
" Modele algorytmiczne (techniki te wymagają opisu danego przedsięwzięcia za pomocą
szeregu atrybutów liczbowych i opisowych. Odpowiedni algorytm daje w wyniku
spodziewany nakład pracy  COCOMO)
" Ocena przez eksperta (doświadczone osoby często z dużą precyzją potrafią oszacowad
koszt realizacji nowego systemu)
" Ocena przez analogię (wycena na podstawie wcześniej realizowanych przedsięwzięd. Tu
również takie narzędzi jak: sieci neuronowe, systemy ekspertowe)
" Prawo Parkinsona (prawo, które stwierdza że przedsięwzięcia  w tym programistyczne 
praktycznie zawsze wykonywane są przy założonych nakładach)
" Wycena dla wygranej (koszt oprogramowania szacowany jest na podstawie oceny
możliwości klienta oraz przewidywanych działao konkurentów. Zgodnie z prawem
Parkinsona i tak projekt się zmieści w założonych ramach)
" Szacowanie Wstępujące (realizację przedsięwzięcia dzieli się na mniejsze zadania, których
koszt jest łatwiej ocenid)  jeżeli programista wykona w ciągu jednego dnia zadanie, na które
dostał tydzieo, to potrafi poświęcid pozostałe cztery dni na to, by na karcie graficznej z
ośmioma kolorami uzyskad dziewiąty kolor
Algorytmiczne modele szacowania kosztów oprogramowania
" Modele takie opierają się na założeniu że łatwiej jest oszacowad rozmiar systemu niż
nakład pracy.
" Proponuje się modele, które nie opierają się na liczbie instrukcji kodu, np. Metoda punktów
funkcyjnych, gdzie szacowane są następujące czynniki:
 Dane odczytywane przez system i pobierane z systemu
11
 Interakcja z użytkownikiem
 Zewnętrzne interfejsy
 Pliki wykorzystywane przez system COCOMO
COCOMO (COst COnstruction MOdel):
Jeden z częściej wykorzystywanych modeli oparty na wielu rzeczywistych przedsięwzięciach.
(realizowane były bez użycia narzędzi CASE, więc model ten nie jest w pełni adekwatny w
przypadku współczesnych przedsięwzięd)Interesujące są czynniki brane pod uwagę oraz
ogólna postad zależności pojawiających się w tym modelu. Stosowanie modelu COCOMO
wymaga oszacowania liczby instrukcji, z których będzie się składał system. Model COCOMO
zakłada że znając nakład pracy można oszacowad czas realizacji przedsięwzięcia, z czego
wynika oczywiście przybliżona wielkośd zespołu, który powinien realizowad przedsięwzięcie.
Podstawowe wyrażenie stosowane w tym modelu to: Nakład *osobomiesiące+ = A*(KDSI)^b
Rozważane przedsięwzięcie należy zaliczyd do jednej z klas:
" Przedsięwzięcia organiczne  przedsięwzięcia wykonywane przez stosunkowo małe
zespoły, o podobnym, wysokim poziomie umiejętności technicznych. Dziedzina problemu
jest dobrze znana. Przedsięwzięcie jest wykonywane za pomocą dobrze znanych metod i
narzędzi. Czas realizacji: Czas*miesiące+ = 2,5*(Nakład)^0,32
" Przedsięwzięcia półoderwane  członkowie zespołu różnią się stopniem zaawansowania.
Pewne aspekty dziedziny oraz częśd metod i narzędzi nie jest znana. Czas*miesiące+ =
2,5*(Nakład)^0,35
" Przedsięwzięcia osadzone  polegają na realizacji systemów o bardzo złożonych
wymaganiach. Dziedzina problemu, metody, narzędzia  w dużej mierze nieznane. Większośd
członków zespołu nie ma doświadczenia w takich projektach. Czas*miesiące+ =
2,5*(Nakład)^0,38
Otrzymane szacowanie powinny zostad skorygowane za pomocą tzw. czynników
modyfikujących. Tworzy się je biorąc pod uwagę następujące atrybuty przedsięwzięcia:
 Wymagania wobec niezawodności systemu
 Rozmiar bazy danych w stosunku do rozmiaru kodu
 Złożonośd systemu, tj. złożonośd struktur danych, złożonośd algorytmów, stosowanie
obliczeo równoległych
 Wymagania co do wydajności systemu
 Ograniczenia pamięci
 Zmiennośd maszyny wirtualne tj. zmiennośd sprzętu i oprogramowania systemowego
tworzących środowisko pracy
Rezultaty fazy strategicznej
Udostępniamy klientowi:
�� Raport obejmujący
 Definicję celów przedsięwzięcia
 Opis zakresu
 Opis systemów zewnętrznych
 Ogólny opis wymagao
 Ogólny model systemu
 Opis proponowanego rozwiązania
 Oszacowanie kosztów
 Wstępny harmonogram prac
12
�� Raport oceny rozwiązao, zawierający informacje o rozważanych rozwiązaniach oraz
przyczynach wyboru jednego z nich
�� Opis wymaganych zasobów
�� Definicję standardów
�� Harmonogram fazy analizy
FAZA OKREŚLENIA WYMAGAO
" Trudności określania wymagao:
 Klient z reguły nie wie dokładnie w jaki sposób osiągnąd założone cele
 Duże systemy są wykorzystywane przez wielu użytkowników
 Zleceniodawcy i użytkownicy to często inne osoby
" Wymagania klienta mogą byd opisane na różnych poziomach abstrakcji:
 Definicja wymagao
 Specyfikacja wymagao
 Specyfikacja oprogramowania
" Celem tej fazy jest dokładne określenie wymagao klienta wobec tworzonego systemu.
" W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające
osiągnięcie tych celów.
" Klient może nie rozumied oprogramowania, ale wie czego chce.
" Zadaniem analizy wymagao jest określenie  czego on chce i zarejestrowanie tego w taki
sposób, że wytwarzanie może toczyd się dalej bez użytkownika.
" Klient rzadko dokładnie wie jakie wymagania zapewniają osiągnięcie jego celów. Proces
określania wymagao należy więc rozumied, nie jako proste zbieranie wymagao klienta, lecz
jako proces, w którym klient wspólnie z przedstawicielami producenta konstruuje zbiór
wymagao wobec systemu zgodny z postawionymi celami.
 Jeśli klient dla którego jest przeznaczone oprogramowanie, nie zostanie wysłuchany i
zrozumiany, to prawdopodobnie nie będzie zadowolony z wyniku.
" Podstawowym sposobem pracy jest wykonywanie wywiadów z różnymi osobami ze strony
klienta (są to z reguły przyszli użytkownicy systemu)
" Przekształcenie wymagane od systemu oprogramowania ma postad wejśd i wyjśd z
systemu. Powinno byd określone, który zbiór wejśd zostanie przetworzony na który zbiór
wyjśd.
" Nie należy wskazywad jak wejścia zostanąprzekształcone na wyjścia. �� dokumentacja
projektowa
Trudności określania wymagao
" Klient z reguły nie wiem dokładnie w jaki sposób osiągnąd określone cele. A można je
osiągnąd na wiele sposobów
" Duże systemy są wykorzystywane przez wielu użytkowników. Ich cele są często sprzeczne.
Różni użytkownicy mogą posługiwad się różną terminologią mówiąc o tych samych
problemach
" Zleceniodawcy i użytkownicy to często inne osoby. Głos zleceniodawców może byd
decydujący w tej fazie, chod nie zawsze potrafią oni przewidzied rzeczywiste potrzeby
13
użytkowników.
Dobry opis wymagao powinien:
- Byd kompletny oraz niesprzeczny
- Opisywad zewnętrzne zachowanie systemu a nie sposób jego realizacji
- Obejmowad ograniczenia przy jakich musi pracowad system
- Byd łatwy w modyfikacji
- Brad pod uwagę przyszłe możliwe zmiany wymagao wobec systemu
- Opisywad zachowanie systemu w niepożądanych sytuacjach
Typowym błędem jest koncentrowanie się na sytuacjach typowych i pomijanie wyjątków.
Opis wymagao
" Wymaganie powinny zostad zebrane w dokumencie  opisie wymagao.
" Dokument ten powinien byd podstawą formalnego, szczegółowego kontraktu między
klientem a producentem
" Powinien byd zrozumiały dla obu stron
" Producenci oprogramowanie często nie są zainteresowani precyzyjnym opisem wymagao,
który pozwoliłby na rzeczywista weryfikację wyprodukowanego systemu.
Dokument opisujący wymagania powinien zawierad:
- Wprowadzenie  cele, zakres i kontekst systemu. Ta częśd dokumentu zawiera więc wyniki
fazy strategicznej
- Opis ewolucji systemu  opis przewidywanych zmian wymagao wobec systemu
- Opis wymagao funkcjonalnych  opisują funkcje (Czynności, operacje) wykonywane przez
system
- Opis wymagao niefunkcjonalnych  opisują ograniczenia, przy zachowaniu których system
powinien realizowad swoje funkcje
- Model systemu
- Słownik  pis wymagao może zawierad szereg terminów niezrozumiałych dla jednej ze
stron. Opis wymagao
Ponadto może zawierad:
- Specyfikacja wymagao funkcjonalnych
- Specyfikacja wymagao niefunkcjonalnych
- Wymagania sprzętowe
- Wymagania dot. Bazy danych
- Indeks
Tworząc dokument opisujący wymagania należy przestrzegad następujących zasad:
- Wymagania funkcjonalne powinny byd oddzielone od wymagao niefunkcjonalnych
- Należy rozdzielad opisy poszczególnych wymagao
- Dla każdego wymagania należy powinien byd podany powód jego wprowadzenia.
Wymagania funkcjonalne
" Opisują funkcje wykonywane przez system. Mogą one byd wykonywane przy udziale
systemów zewnętrznych
" Język naturalny jest bardzo często sposobem opisu wymagao. Ale ma wady:
- Niejednoznacznośd języka naturalnego, która utrudnia precyzyjny zapis wymagao.
Może prowadzid do różnej interpretacji tego samego tekstu przez różne osoby
14
- Elastycznośd języka naturalnego, która pozwala te same treści wyrazid na różne
sposoby. Utrudnia to wykrycie powiązanych wymagao. Może tez prowadzid do
przeoczenia sprzeczności wymagao sformułowanych w różny sposób.
Powyższych wad pozbawione są notacje formalne, ale są niezrozumiałe dla klienta.
" Swego rodzaju kompromisem pomiędzy językiem naturalnym a metodami formalnymi jest
stosowanie formularzy opisu wymagao.
" Formularze takie wykorzystują język naturalny, jednak zapis jest podzielony na konkretne
pola co pozwala uniknąd szeregu błędów.
" Definiując wymagania funkcjonalne z reguły podaje się jedynie wymagany efekt realizacji
funkcji a nie jej algorytm.
" Liczba wymagao funkcjonalnych może byd bardzo duża  nawet do 8000.
Hierarchia wymagao funkcjonalnych
" Pewne funkcje wykonywane przez system są składowymi (podfunkcjami) innych bardziej
ogólnych funkcji.
" Proponuje się, aby wymagania funkcjonalne zapisywad w formie hierarchicznej.
" Dana funkcja powinna byd dekomponowana na wszystkie, i wyłącznie te funkcje, które są
niezbędne dla jej wykonania.
" Kolejnośd funkcji składowych nie ma znaczenia
" Wykonanie funkcji nadrzędnej nie musi oznaczad wykonania funkcji składowych w każdej
sytuacji
" Pewne funkcje składowe mogą byd wykonywane wielokrotnie podczas realizacji funkcji
podrzędnej
" Każda funkcja składowa musi byd w pewnych sytuacjach wykonana podczas realizacji
funkcji nadrzędnej.
Wymagania funkcjonalne cd
" Powinny dotyczyd wyłącznie zewnętrznych funkcji systemu.
" Funkcji systemu nie należy rozbijad do poziomu funkcji, które mają znaczeni czysto
implementacyjne
" Pewne funkcje składowe mogą pojawiad się w ramach wielu funkcji nadrzędnych
" Jednym ze sposobów konstruowania hierarchii funkcji jest technika zstępująca. Zgodnie z
tą techniką określanie wymagao funkcjonalnych należy zacząd od poszukiwania najbardziej
ogólnych funkcji, a następnie należy dekomponowad je na funkcje składowe aż do
osiągnięcia poziomu funkcji elementarnych.
" W praktyce nie zawsze jest możliwe kierowanie wywiadu z użytkownikami w taki sposób by
zaczynad od funkcji maksymalnie ogólnych, a kooczyd na szczegółowych.
" Użytkownicy często wolą koncentrowad się na szczegółowych funkcjach, które uważają na
ważniejsze, z ich punktu widzenia.
" Szczegółowe funkcje należy agregowad do funkcji wyższego poziomu. W praktyce
hierarchia funkcji powstaje więc zarówno poprzez dekompozycję, jak i agregację funkcji
Wymagania niefunkcjonalne:
" Wymagania niefunkcjonalne opisują ograniczenia, przy których system musi
realizowad swoje funkcje:
 Wymagania dotyczące produktu np. musi istnied możliwośd przeglądania danych wyłącznie
za pomocą klawiatury
15
 Wymagania dotyczące procesu np. proces realizacji systemu harmonogramowania zleceo
musi byd zgodny ze standardem opisanym w dokumencie XXXXXX
 Wymagania zewnętrzne system harmonogramowania zleceo musi współpracowad z bazą
danych systemu komputerowego opisanego w dokumencie YYYYY. Niedopuszczalne są żadne
zmiany w strukturze tej bazy.
Czynniki sukcesu
" Zaangażowanie odpowiednich osób ze strony klienta
" Pełne rozpoznanie wymagao, wykrycie sytuacji szczególnych i nietypowych
" Sprawdzenie kompletności i spójności wymagao
" Określenie wymagao niefunkcjonalnych w sposób możliwy do weryfikacji.
FAZA ANALIZY (MODELOWANIA), FAZA PROJEKTOWANIA
" Celem fazy określania wymagao jest udzielenie odpowiedzi na pytanie: co i przy jakich
ograniczeniach system ma robid? Wynikiem tej analizy jest zbiór wymagao czyli zewnętrzny
opis systemu.
" Celem fazy analizy jest udzielenie odpowiedzi na pytanie: jak system ma działad? Wynikiem
jest logiczny model systemu, opisujący sposób realizacji przez system postawionych
wymagao, lecz abstrahujący od szczegółów implementacyjnych
" Celem fazy projektowania jest udzielenie odpowiedzi na pytanie: jak system ma zostad
zaimplementowany? Wynikiem jest projekt oprogramowania, czyli opis systemu
implementacji
Model analityczny
Z reguły wykracza poza zakres odpowiedzialności systemu ponieważ:
- Ujęcie w modelu pewnych elementów nie będących częścią systemu czyni model bardziej
zrozumiałym
- Na etapie modelowania może nie byd 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 pozwolid na realizację systemu w całości. Celem analizy może
byd wykrycie tych fragmentów które mogą byd szczególnie ważne
Dlaczego modelujemy?
" Podjęcie decyzji, jakie modele tworzyd, ma wielki wpływ na to, w jaki sposób zaatakujemy
problem jaki kształt przyjmie rozwiązanie
" Każdy model może byd opracowany na różnych poziomach szczegółowości
" Najlepsze modele odpowiadają rzeczywistości
" Żaden model nie jest wystarczający. Niewielka liczba niemal niezależnych modeli to
najlepsze rozwiązanie w wypadku każdego niebanalnego systemu.
Model analityczny
�� Model oprogramowania powinien byd jego uproszczonym opisem  opisującym
wszystkie istotne cechy oprogramowania na wysokim poziomie abstrakcji.
- Uproszczony opis systemu
16
- Hierarchiczna dekompozycja funkcji systemu
- Model logiczny jest opisany za pomocą notacji zgodnej z pewną konwencją
- Zbudowany przy użyciu dobrze znanych metod i narzędzi
- Używany do wnioskowania o przyszłym oprogramowaniu
" Pokazuje co system ma robid
" Jest zorganizowany hierarchicznie, według poziomów abstrakcji
" Unika terminologii implementacyjnej
" Pozwala na wnioskowanie  od przyczyny do skutku i odwrotnie
Notacja w fazie analizy
Do opisu modelu stosuje się następujące rodzaje notacji:
- Język naturalny
- Notacje graficzne
- Specyfikacje  częściowo ustrukturalizowany zapis tekstowy i numeryczny
Szczególną rolę tutaj odgrywają notacje graficzne (wzorując się na innych dziedzinach
techniki)
Notacja graficzna
" Diagramy graficzne ułatwiają szybkie przekazywanie podstawowych informacji, nie
pozwala jednak na ukazanie wszystkich szczegółów.
" Nadmierne nagromadzenie szczegółów na diagramie graficznym może skutecznie
zniweczyd jego czytelnośd
" Notacje graficzne uzupełniane są o dodatkowe informacje tzw. specyfikacje
Funkcje notacji
" Są one podstawowym narzędziem pracy analityka i projektanta
" Notacje wykorzystywane w fazie analizy są często wykorzystywane do współpracy z
użytkownikiem (muszą byd proste, przejrzyste, zrozumiałe)
" Ułatwia pracę w grupie. Służą szybkiemu i precyzyjnemu przekazywaniu idei
" Notacje są podstawą implementacji oprogramowania
" Służą do zapisu dokumentacji technicznej
Analiza strukturalna
" Metody strukturalne tworzenia oprogramowania, opierają się na wyróżnianiu w
tworzonym oprogramowaniu dwóch rodzajów składowych: pasywnych odzwierciedlających
fakt przechowywania w systemie pewnych danych oraz składowych aktywnych
odzwierciedlających fakt wykonywania w systemie pewnych operacji. Metody obiektowe
wyróżniają w systemie składowe, które łączą w sobie możliwośd
przechowywania danych oraz wykonywania operacji.
" Analiza strukturalna zaczyna się od budowy dwóch różnych modeli systemu: modelu,
będącego opisem pasywnej części systemu oraz modelu funkcji opisującego aktywną częśd
systemu.
" Te dwa modele są następnie integrowane i wynikiem jest model przepływów danych.
" Zwolennicy analizy strukturalnej twierdzą, że budowa dwóch oddzielnych modeli ułatwia
zrozumienie różnych aspektów systemu.
" Krytycy zwracają uwagę, na to że integracja tych dwóch modeli może byd bardzo trudna.
17
Analiza obiektowa
System jest analizowany w sposób obiektowy jeśli:
- Jest dzielony na obiekty posiadające:
- Tożsamośd, 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.
Analiza i programowanie obiektowe ułatwia:
- Ukrywanie danych (hermetyzację)
- Wykorzystywanie gotowych elementów
- Ponowne wykorzystanie oprogramowania
- Szybkie prototypowanie
- Programowanie oparte na zdarzeniach
- Programowanie przyrostowe
WYMAGANIA SPECYFIKACJA I PROJEKTOWANIE
" Wymagania zrozumiałe dla użytkowników. aby zapewnid przewidywalne działanie, system
nie powinien posługiwad się metodami niedeterministycznymi. Działanie systemu powinno
byd przewidywalne i powtarzalne
" Dokument wymagao: co oprogramowanie będzie robid (nie jak). Oprogramowanie
zastosuje B-drzewa w celu składowania informacji przechowywanej w pamięci. Decyzje
dotyczące algorytmów lub struktur danych należą do dokumentu projektowania a nie do
dokumentu wymagao.
" Jedynym sędzią poprawności jest użytkownik. Wymagania zasadnicze z punktu widzenia
kosztów i możliwości (łatwo realizowane) należą do twórców oprogramowania.
" Kompletnośd - Czy nie brakuje żadnego z wymagao koniecznych? Czy w danym wymaganiu
nie brakuje informacji? system dostarczy operatorowi komunikaty z zaznaczeniem czasu i
informacje potrzebne do bezpiecznego wyłączenia maszyny, jeśli wystąpi sytuacja
wyjątkowa.
" Wiemy, że dobre systemy dostarczają użytkownikowi docelowemu dobrych
parametrów przy jak największej pojemności pamięci operacyjnej. Z tego
powodu sugerujemy aby system uzyskiwał odpowiednią efektywnośd pracy
przy wielkości PAO równej 1GB, ponieważ jest to najtaosza pamięd, jaką
18
możemy zakupid u wskazanego dostawcy. Użytkownik oczywiście może wybrad
skonfigurowanie systemu dla większej pamięci operacyjnej, co zalecalibyśmy,
ale będziemy próbowad rozwiązad większośd problemów wynikających z użycia
mniejszej pamięci i sądzimy, że mogą byd one w całości rozwiązane. Wymaganie główne:
system będzie realizował wszystkie określone funkcje przy konfiguracji z 1-gigabajtową
pamięcią operacyjną. Wymaganie wyprowadzone: system będzie konfigurowalny ze względu
na dostępną pamięd operacyjną.
" System będzie przyjmował tylko dopuszczalne numery ID pracownika zgodnie z definicją
podaną w TBP. Żadne inne liczby nie będą przyjmowane poza liczbami całkowitymi z
przedziału od 1 do 9999 włącznie, reprezentowane bez zer wiodących.
" Elementy w kolumnach oddzielonych znakiem tabulatora i wiersze oddzielone
podkreśleniem, dotyczące wyjścia, mogą odwoływad się do siebie, ale żaden element na
pozycji (wiersz, kolumna) (i,j) nie może odwoływad się do innego elementu na pozycji (p,q),
chyba że p" Wynik składa się z wierszy i kolumn. Elementy znajdujące się w wierszu są oddzielone
tabulatorami. Między wierszami znajduje się podkreślenie. Gdy element X odwołuje się do
elementu Y, Y musi byd albo w wierszu powyżej X, albo, jeśli oba elementy są w tym samym
wierszu, Y musi byd w kolumnie na lewo od X. Element nie może odwoływad się do samego
siebie.
" Niejednoznacznośd jest głównym problemem przy formułowaniu wymagao. Jeżeli nie jest
całkowicie oczywiste, co system ma robid  z pewnością nie może byd testowany!!
" Zbiór wymagao jest niespójny, gdy dwie jego części są sprzeczne lub po prostu inne. Takie
problemy pojawiają się najczęściej przy zmianach wymagao systemu. Wymagania łatwe do
modyfikacji nie tracą szybko spójności.
" Wprowadzenie unikatowych identyfikatorów np. wymaganie 4.1.2. Wykorzystanie
wprowadzonych identyfikacji w pozostałych dokumentach projektowych - możliwośd
śledzenia w drugą stronę  jeżeli projektant chce zmienid fragment projektu to musi wiedzied
które wymagania są realizowane przez ten fragment aby sprawdzid, czy nadal będą one
spełnione.
" A
atwośd modyfikacji.
" Nie nakładamy wymagao których nie można przetestowad. Nie nakładamy tzw. wymagao
 mglistych .
" Wymagania absurdalne są nie do realizacji.
19
Specyfikowanie formalne:
Metody formalne - w sposób naturalny skierowane nie na to co system robi, lecz jak to ma
byd zrobione (wewnętrzna dekompozycja - projektowanie). Metody formalne uznawane jako
pierwsza częśd projektowania. Etapy tworzenia oprogramowania są definiowane przez
DOKUMENTACJ
tworzona do ich rozdzielenia.
Główną trudnością w tworzeniu oprogramowania jest komunikacja z użytkownikiem
docelowym  język specyfikacji.
TWORZENIE MODELU OBIEKTOWEGO
Metody strukturalne tworzenia oprogramowania, opierają się na wyróżnianiu w tworzonym
oprogramowaniu dwóch rodzajów składowych: pasywnych odzwierciedlających fakt
przechowywania w systemie pewnych danych oraz składowych aktywnych
odzwierciedlających fakt wykonywania w systemie pewnych operacji.
Metody obiektowe wyróżniają w systemie składowe, które łączą w sobie możliwośd
przechowywania danych oraz wykonywania operacji.
Analiza strukturalna zaczyna się od budowy dwóch różnych modeli systemu: modelu,
będącego opisem pasywnej części systemu oraz modelu funkcji opisującego aktywną częśd
systemu. Te dwa modele są następnie integrowane i wynikiem jest model
przepływów danych. Zwolennicy analizy strukturalnej twierdzą, że budowa dwóch
oddzielnych modeli ułatwia zrozumienie różnych aspektów systemu. Krytycy zwracają
uwagę, na to że integracja tych dwóch modeli może byd bardzo trudna.
Analiza obiektowa: System jest analizowany w sposób obiektowy jeśli:
- Jest dzielony na obiekty posiadające:
- Tożsamośd, 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.
20
NOTACJA OBIEKTOWA
Obiekt
Analiza ą� Składowa dziedziny problemu posiadająca tożsamośd,
stan i zachowanie.
Projektowanie i implementacja ą� Konstrukcja języka programowania łącząca
dane i metody (procedury i funkcje)
Symbol obiektu ą� Nazwa obiektu : nazwa klasy (np. Jan Kowalski :
Osoba)
Klasa
Analiza ą� Wzorzec grupy obiektów
Projektowanie i implementacja ą� Typ obiektowy w języku programowania
Pola (atrybuty) ą� Opisują stan obiektów klasy
Metody (usługi, operacje) ą� Opisują operacje jakie można na polach tej
klasy wykonywad
Symbol obiektu
Generalizacja-specjalizacja:
Dwie klasy pozostają w związku generalizacji-
specjalizacji, jeżeli jedna z nich, zwana
specjalizacją jest rodzajem drugiej zwanej
generalizacją.
Diagramy przejśd stanów:
Prezentują zmienne w czasie aspekty systemu (dynamiczne zachowanie się klas i grup klas;
przedstawienie sposobów realizacji funkcji systemu).
Zdarzenie  zjawisko występujące w określonej chwili czasu (wprowadzenie danych,
wybranie opcji, odczyt parametru)  może byd zewnętrzne lub wewnętrzne.
Stan  okres pomiędzy zdarzeniami (np. stan overwrite, input, edycji, prezentacji)
Przejście systemu  zmiana stanu systemu j.w. (dodatkowe warunkowanie)
Akcja  czynności wykonywane w momencie zajścia zdarzenia, natychmiast (wypełnienie
wartością pola, realizacja określonego obliczenia)
Operacja  wykonywane w czasie określonego stanu systemu, przerywana
automatycznie poprzez zdarzenie zmieniające stan systemu (monitorowanie czasu)
21
Specyfikacja metod:
dane wejściowe;
dane wyjściowe;
algorytm (opisywany poprzez język naturalny, schemat blokowy lub minispecyfikację);
warunki wstępne (warunki jakie musza spełniad pola klasy do której należy metoda oraz
dane wejściowe, aby metoda mogła rozpocząd się poprawnie) ;
warunki koocowe (warunki jakie musza spełniad pola klasy do której należy metoda oraz
dane wyjściowe po zakooczeniu poprawnie rozpoczętej oraz poprawnie wykonanej metody);
wyjątki  sytuacje mogące zajśd w trakcie realizacji metody (błąd otwarcia pliku);
złożonośd czasowa;
złożonośd pamięciowa;
Algorytm klasyfikacji na podstawie reguł decyzyjnych:
powtarzaj od reguły najważniejszej do najmniej ważnej
jeżeli obiekt spełnia warunki reguły, to
podejmowana jest reguła wskazywana przez regułę
dopóki nie podjęto decyzji lub nie sprawdzono wszystkich reguł
jeżeli nie podjęto decyzji, to
podejmij decyzję wskazywaną przez regułę domniemaną
22
Identyfikacja klas i obiektów:
-podejście klasyczne, oparte na obserwacji z propozycją pojawiających się w systemach
typowych klas; przedmioty, role, zdarzenia, interakcje, lokalizacje, dokumenty, organizacje,
koncepcje, interfejsy dla systemów zewnętrznych, itp.
- analiza dziedziny problemu; przeniesienie modelu opisanego przez ekspertów bądz
w
literaturze i wcześniejszych podobnych realizacjach
- analiza w języku naturalnym; wykorzystuje opis fachowego modelu  rzeczowniki
potencjalne klasy,
obiekty lub pola; czasowniki to potencjalne metody lub związki klas
- analiza scenariuszy; tworzenie przypadków użycia
Weryfikacja klas i obiektów: (odrzucenie zbędnych klas)
- nieobecnośd pól i metod  klasa poza odpowiedzialnością systemu
- nieliczne pola i metody  przenieśd do innej klasy
- jeden obiekt w klasie  (klasa pit nowaka zbyt rozbudowane specjalizacje)
- brak związku z innymi klasami  klasa znajduje się poza zakresem odpowiedzialności
systemu.
Identyfikacja związków klas i obiektów - uogólnienie wielu pojedynczych związków
pojawiających się pomiędzy obiektami tych klas.
�� związki agregacji (zawiera, składa się, obejmuje)
�� związki generalizacji-specjalizacji (np. klasyfikacja wyrobów, pracowników itp.;
dziedziczenie pól i metod często wskazuje na związek G-S.)
23
Identyfikacja i definiowanie pól
- co jest potrzebne dla opisu danej klasy w ramach dziedziny problemu
- jakie dane są potrzebne metodom danej klasy dla realizacji ich zadao
- jakie pola należy wprowadzid dla opisu stanów w jakich mogą się znajdowad obiekty danej
klasy
Identyfikacja i definiowanie metod i komunikatów
�� Algorytmicznie proste
- Konstruktory (metody tworzące nowe obiekty danej klasy)
- Destruktory (metody usuwające obiekty danej klasy)
- Metody pobierania/ustawiania wartości pól danej klasy ( GetData, SetData, GetField,
SetField  stanowią bezpośrednie odwołania do pól, czasem z warunkami)
- Metody służące do ustawiania związków pomiędzy obiektami
- Metody służące do edycji pól danej klasy
�� Algorytmicznie złożone (metody śledzenia, wykonywanie obliczeo)
UML (UNIFIED MODELING LANGUAGE)
Graficzny język do obrazowania, specyfikowania, tworzenia i dokumentowania systemów
informatycznych.
Klasy
" Modelowanie polega między innymi na zidentyfikowaniu bytów istotnych z pewnego
szczególnego punktu widzenia. Byty te składają się na słownictwo systemu,
który jest modelowany.
" DOM: ściany, drzwi, okna, szafki, oświetlenie
" Każdy byt znacząco różni się od pozostałych  ma swój własny zestaw właściwości
" Pojedyncze ściany, drzwi i okna rzadko istnieją w oderwaniu od siebie
" Wszystkie takie byty identyfikowane są jako klasy. Nie jest pojedynczym obiektem lecz
zbiorem wielu obiektów.
Klasy w UML
" Klasa to opis zbioru obiektów o tych samych atrybutach, związkach i znaczeniu. Jej
symbolem graficznym jest prostokąt.
" Atrybut to nazwana właściwośd klasy. Klasa może mied dowolną liczbę atrybutów  lub nie
mied ich wcale. Atrybut reprezentuje właściwośd pewnego modelowanego bytu, która jest
określona dla wszystkich jego wystąpieo.
" Operacja to implementacja pewnej usługi, której wykonania można zażądad od każdego
obiektu klasy. Jest to abstrakcja, tego co można zrobid z każdym obiektem tej klasy.
" Odpowiedzialnośd klasy, czyli za jakie zadania dana klasa jest odpowiedzialna.
Związki
" Niewielka liczba klas występuje samotnie. Większośd z nich współpracuje ze sobą na wiele
sposobów.
" W modelowaniu obiektowym najważniejszymi rodzajami związków są zależnośd,
uogólnienie i powiązanie.
24
" Zależnośd: zmiany dokonane w specyfikacji jednego elementu mogą mied wpływ na inny
element, który używa tego pierwszego.
Związki w UML
" Uogólnienie: to związek pomiędzy elementem ogólnym a pewnym specyficznym jego
rodzajem (nadklasa  podklasa)
" Potomek (podklasa) może wystąpid wszędzie tam gdzie występuje przodek. Potomek
wszystkie właściwości, a w szczególności atrybuty i operacje. Często potomek ma także
własne właściwości. Operacja potomka, która ma taką samą sygnaturę co operacja przodka
jest ważniejsza  polimorfizm.
" Powiązania: związek, który wskazuje że elementy jednego elementu są połączone z
obiektami innego.
Przypadki użycia
" Przypadki użycia służą do utrwalania oczekiwanego zachowania budowanego systemu bez
konieczności określania sposobu implementacji tego zachowania.
" Umożliwiają wypracowanie porozumienia między programistami a użytkownikami i
ekspertami
" Ułatwiają weryfikację architektury i samego systemu w miarę tworzenia go.
" Przypadek użycia określa zbiór ciągów akcji, z których każdy reprezentuje interakcję
elementów z otoczenia systemu z samym systemem. Te działania są w istocie
funkcjami systemowymi.
" Przypadki użycia są podstawą do opracowywania testów
25
Przypadki użycia w UML
" W UML diagramy przypadków użycia służą do obrazowania zachowania systemu,
podsystemu klub klasy w taki sposób, by użytkownicy mogli zrozumied jak z tego bytu
skorzystad, a programiści mogli go zaimplementowad
" Diagramy użycia można stosowad do dwóch celów:
- Modelowania otoczenia systemu (wyznaczenie granicy wokół całego systemu i na
wskazaniu leżących poza nią aktorów, którzy wchodzą w interakcję z systemem)
- Modelowania wymagao stawianych systemowi (określenie, co system powinien robid,
niezależnie od tego jak ma to robid.
Diagramy przypadków użycia
" Modelując otoczenie systemu postępuj zgodnie z podanymi wytycznymi:
- zidentyfikuj aktorów działających wokół systemu. Rozważ, które grupy są niezbędne do
realizacji funkcji systemu, są w interakcji z urządzeniami zewnętrznymi lub innymi systemami
informatycznymi, wypełniają drugorzędne funkcje
- Uporządkuj podobnych aktorów za pomocą uogólnieo
- Zaludnij tymi aktorami diagram przypadków użycia i zdefiniuj ścieżki komunikacyjne od
każdego aktora do przypadków użycia systemu
Diagram przypadków użycia:
Budowa statycznego modelu klas
Podejście klasyczne: opiera się na obserwacji, że w wielu systemach pojawiają się podobne
klasy i obiekty. Na tej podstawie można poszukiwad podobnych klas w systemie. Typowe
klasy to:
" Przedmioty namacalne (samochód, czujnik)
" Role pełnione przez osoby (pracownik, wykładowca)
" Zdarzenia, o których system przechowuje informacje (zamówienie, dostawa)
26
" Interakcje pomiędzy osobami/systemami (pożyczka, spotkanie)
" Lokalizacje  miejsca
" Grupy przedmiotów namacalnych
" Organizacje (Firma, wydział)
" Koncepcje (miara jakości, zadanie)
" Dokumenty
Analiza funkcji (przypadków użycia)
Metoda ta opiera się od wyboru pewnej funkcji systemu (niekoniecznie elementarnej). W
języku naturalnym opisuje się sposób w jaki system wykonuje tę funkcję. Na tej podstawie
tworzy się scenariusz funkcji  przypadek użycia  wprowadzając niezbędne klasy i metody.
Weryfikacja klas i obiektów
" Stosowanie tych metod może prowadzid do wykrycia znacznej liczby potencjalnych klas,
które nie znajdą się w ostatecznym modelu.
" Należy wziąd pod uwagę następujące czynniki:
- nieobecnośd atrybutów i operacji
- nieliczne atrybuty i operacje
- tylko jeden obiekt w klasie
- brak związków z innymi klasami
Artefact - fizyczny element informacyjny wyprodukowany lub używany w
procesie wytwarzania oprogramowania (pliki .sor .com , elementy bazy danych,
dokumenty, fragmenty modeli, itp.)
Klasyfikatory - elementy składowe modelu opisujące jego zachowanie lub
strukturę posiadające swoją reprezentacje geometryczną. W szczególności zaliczamy do nich:
klasy, aktorzy, przypadki użycia, relacje.
Obiekt (paradygmat obiektowości) -  kawałek kodu posiadający:
�� stan  definiowany przez wartości atrybutów;
�� zachowanie  operacje i usługi świadczone przez obiekt na żądanie innych o.
�� tożsamośd  unikalna cecha obiektu rozróżniająca obiekty o tych samych atrybutach i
operacjach (dwa obiekty mogą byd równe ale nie identyczne)
Klasyfikacja modeli obiektowych:
�� Model stanu systemu (State models)  statyczny stan systemu
�� Model zachowania systemu (Behavior models)
�� Model zmiany stanu systemu (State change models)
UML wprowadza sześd typów diagramów: struktura stanu (state structure), przypadki użycia
(use case), wykres (rejestr) stanu (statechart), diagram współpracy (collaboration,
communication diagrams), wykres aktywności (activity diagrams), wykres implementacji
(implementation diagram).
Statyczna struktura modelu (State models) wyraża się poprzez diagramy klas (Class
Diagrams)  obrazują klasy (interfejsy), ich wewnętrzna strukturę i relacje do innych klas.
27
Klasa
- grupa obiektów o tych samych własnościach, ograniczeniach i semantyce.
- deskryptor grupy obiektów o podobnej strukturze, zachowaniu i relacjach
Do własności klasy zaliczamy:
�� Atrybuty  własnośd typu strukturalnego
�� Operacje  własnośd typu behawioralnego klasy, aktorzy, przypadki użycia, relacje.
Relacje dotyczą połączeo pomiędzy klasyfikatorami (np. klasami w diagramach klas)
Instancja danej klasy (instance) - obiekt przypisany do określonej klasy obiektów.
Elementy diagramu klas:
Asocjacja - zależnośd łącząca dwie klasy lub więcej (łącząca instancje!!)
Mnogośd  określa jak wiele instancji jednej klasy jest w relacji do jednej instancji drugiej
klasy ( 0 w mnogości określa asocjacje opcjonalną)
Agregacja - jest rodzajem asocjacji wskazującej na zawieranie się klas. Nadklasa zawiera
wszystkie instancje podklasy
Generalizacja - jest rodzajem związku pomiędzy klasyfikatorami (klasami a nie instancjami)
Nie definiujemy więc w nim mnogości.
Diagramy klas  pełnią dominującą rolę w OOM jak DFD s w modelowaniu strukturalnym.
Diagramy klas jak i DFD s definiują operacje i struktury danych  podstawowa różnica:
koncentracja odpowiednio na operacjach i strukturach danych.
Fazy:
- Analizy
- Projektu
Diagramy przypadków użycia
Model zachowania systemu (nie generują hierarchicznej struktury systemu jak DFD s)
- Tekstowa specyfikacja przypadków użycia  składane w repozytorium
28
- Pozwalają na właściwe prowadzenie analizy, projektowania implementacji systemu
- Dają możliwośd określenia przypadków testowania, rejestrowania uszkodzeo systemu oraz
identyfikacji przyszłych rozszerzeo (enhancements) systemu
Przypadki użycia  główne elementy funkcjonalności systemu. Aktor  ktoś (coś) gra role,
komunikuje się (przekazuje) z przypadkami użycia (via <>) oczekując reakcji 
wartości lub widocznego efektu.
29


Wyszukiwarka

Podobne podstrony:
pawlikowski, fizyka, szczególna teoria względności
Teoria i metodologia nauki o informacji
teoria produkcji
Cuberbiller Kreacjonizm a teoria inteligentnego projektu (2007)
Teoria B 2A
Teoria osobowości H J Eysencka
silnik pradu stalego teoria(1)
Rachunek prawdopodobieństwa teoria
Teoria konsumenta1 2
niweleta obliczenia rzednych luku pionowego teoria zadania1
Teoria wielkiego podrywu S06E09 HDTV XviD AFG
koszałka,teoria sygnałów, Sygnały i przestrzenie w CPS
Teoria Drgań Mechanicznych Opracowanie 04
ELE III cw 5 teoria wybrane B
10 Kinetyczna teoria gazow

więcej podobnych podstron