io wykład 1 - poznań university of technologyfcds.cs.put.poznan.pl › myweb › praca › io ›...
TRANSCRIPT
Inżynieria oprogramowania część I
Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne
Semestr zimowy 2015/2016
dr inż. Bartłomiej Prędki
Pok. 124 CW, tel. 61665 2932
http://zajecia.predki.com
Literatura❖ A. Jaszkiewicz, Inżynieria oprogramowania, Helion, Gliwice, 1997.
❖ B. Begier, Inżynieria oprogramowania – problemy jakości, Wydawnictwo Politechniki Poznańskiej, Poznań, 1999.
❖ Janusz Górski (red.). Inżynieria oprogramowania w projekcie informatycznym. Mikom, Warszawa, 2000, wyd. II.
❖ G. Booch, J. Rambaugh, I. Jacobson, UML przewodnik użytkownika, WNT, Warszawa, 2000.
❖ C. Larman, UML i wzorce projektowe., Helion 2011
❖ D. Hamlet, J. Maybee, Podstawy techniczne inżynierii oprogramowania, WNT 2003
Literatura❖ S. Maguire, Niezawodność oprogramowania, Helion,
Gliwice, 2002
❖ E. Freeman, B. Bates, K. Sierra, Wzorce projektowe. Rusz głową!, Helion, 2010
❖ Z. Szyjewski, Zarządzanie projektami informatycznymi, Placet 2001
❖ K. Beck, M. Fowler, W. Opdyke, D. Roberts, Refaktoryzacja. Ulepszanie struktury istniejącego kodu, WNT 2006
❖ E. Gamma, R. Helm, R. Johnson, J. Vlissides, Wzorce projektowe, WNT 2008
Rynek oprogramowania 2011
❖ Świat 292.9 miliardów dolarów (42.6% Ameryka)
❖ Bez oprogramowania wytwarzanego na własne potrzeby
❖ Wzrost 6.6% rocznie
❖ + 125 miliardów euro dodatkowych usług
❖ W UE 60-70% oprogramowania jest wytwarzane w firmach, dla których nie jest to główną działalnością
❖ W 2016 ponad 396 mld dolarów
Rynek oprogramowania
Rynek oprogramowania
Rynek oprogramowania
Najwięksi gracze
❖ IBM
❖ Microsoft
❖ Oracle
❖ SAP
Trochę historii
❖ Lata 50-te
❖ Sprzęt o bardzo ograniczonych możliwościach
❖ Ograniczone zastosowania
❖ Małe programy
❖ Programy pisane często dla własnych potrzeb lub potrzeb dobrze znanych osób
❖ Dobrze wyspecyfikowane zadania
Rozwój technik wytwarzania oprogramowania
❖ Lata 60-te
❖ Profesjonalni programiści
❖ Nowe języki programowania – COBOL, Fortran, Algol
❖ Sprzęt o dużo większych możliwościach, np. pamięć wirtualna
❖ Nowe zastosowania – np. w biznesie
❖ Próba realizacji wielu dużych przedsięwzięć programistycznych
Kryzys oprogramowania
❖ Rozwój technik wytwarzania oprogramowania nie nadąża za rozwojem sprzętu komputerowego
❖ Czy kryzys oprogramowania trwa do dzisiaj?
❖ Nadal większość przedsięwzięć przekracza czas i/lub budżet
❖ Około 25% przedsięwzięć programistycznych nie jest kończona
❖ 90% firm przyznaje, że dość często zdarzają im się opóźnienia przedsięwzięć
❖ Powszechna akceptacja kiepskiej jakości oprogramowania (w pewnych obszarach)
Zależność osiągnięcia-oczekiwania w wytwarzaniu oprogramowania
Czas
Efekty
Rzeczywiste osiągnięcia
Oczekiwania
Przyczyny kryzysu oprogramowania❖ Duża złożoność systemów informatycznych
❖ Złożoność, zmienność, nieadekwatność wymagań❖ Niepowtarzalność poszczególnych przedsięwzięć❖ Nieprzejrzystość procesu budowy oprogramowania
❖ Pozorna łatwość wytwarzania i modyfikowania oprogramowania
❖ Potrzeba kreatywności
❖ Czynnik ludzki
❖ Mało wymagający rynek
❖ Niedoskonałość narzędzi
Przykład - system dla PKW❖ błędy po stronie klienta
❖ zbyt krótki czas na zrealizowanie prac
❖ brak oceny złożoności problemu i wymagań❖ brak samokrytycyzmu
❖ błędy po stronie kontrahenta
❖ brak doświadczenia
❖ zbyt „swobodne” podejście
Początek inżynierii oprogramowania
1968
NATO Conference on Software Engineering
Podejście amatorskie a inżynierskie
Co by tu wymyślić!? Do pracy.
Definicje inżynierii oprogramowania
❖ Duże systemy wymagające pracy wielu osób – praca grupowa
❖ Wielowersyjność oprogramowania
Definicja inżynierii oprogramowania
Wiedza techniczna, dotycząca wszystkich faz cyklu życia oprogramowania, której
celem jest uzyskanie wysokiej jakości produktu - oprogramowania.
Jakość oprogramowania
❖ Użyteczność (usefulness) ❖ Niezawodność (reliability) ❖ Ergonomia (usability) ❖ Efektywność (efficiency) ❖ Łatwość konserwacji (maintability) ❖ Bezpieczeństwo użytkownika (user safety) ❖ Koszt?
Zakres inżynierii oprogramowania
❖ Wytwarzanie oprogramowania i innych
produktów (np. dokumentacji)
❖ Zarządzanie wytwarzaniem
oprogramowania
Plan wykładów I semestr
❖ Wprowadzenie i podstawowe modele cyklu życia oprogramowania
❖ Analiza/modelowanie systemów z wykorzystaniem języka UML, w tym elementy analizy wymagań
❖ UML jako narzędzie projektowania i dokumentowania oprogramowania
❖ Projektowanie oprogramowania
❖ Niezawodność oprogramowania
❖ Dokumentacja techniczna i użytkowa
❖ Narzędzia inżynierii oprogramowania
Zaliczenie
Wykład jest zaliczany w trakcie testuna ostatnim wykładzie,czyli 16 stycznia 2016 r.
Modele cyklu życia oprogramowania
❖ Uporządkowanie prac.
❖ Ustalenie kolejności prac.
❖ Planowanie i monitorowanie realizacji.
Programowanie odkrywcze
Ogólne określenie wymagań
Ogólny projekt
Budowa systemu
Ocena systemu
System poprawnyWdrożenie
Tak Nie
Model kaskadowy
Określenie wymagań
Projektowanie
Implementacja
Testowanie
Konserwacja
Dodatkowe fazy w modelu kaskadowym
Ścisłe i elastyczne rozumienie modelu kaskadowego
Określenie wymagań
Projektowanie
Implementacja
Testowanie
Konserwacja
Przykład elastycznego podejścia do modelu kaskadowego
Wady i zalety modelu kaskadowego (rozumianego ściśle)
+Łatwość zarządzania – planowanie i monitorowanie
-Wysoki koszt błędów popełnionych we wstępnych fazach
❖ Koszt błędu w wymaganiach 100-1000 razy większy od kosztu błędu programistycznego!
-Długa przerwa w kontaktach z klientem
-Nie lubiany przez wykonawców
Prototypowanie❖ Cel – lepsze określenie wymagań
❖ Fazy:
❖ Ogólne określenie wymagań.
❖ Budowa prototypu.
❖ Weryfikacja prototypu przez klienta.
❖ Pełne określenie wymagań.
❖ Realizacja pełnego systemu zgodnie z modelem kaskadowym.
Sposoby budowy prototypu
❖ Prototyp musi być zbudowany szybko i niskim kosztem. ❖ Niepełna realizacja. ❖ Języki wysokiego poziomu . ❖ Wykorzystanie gotowych komponentów. ❖ Generatory interfejsu użytkownika. ❖ Szybkie programowanie (quick-and-dirty programming). ❖ Papier. ❖ Programowanie odkrywcze.
Wady i zalety prototypowania
+Mniejsze ryzyko popełnienia kosztownych błędów we wczesnych fazach.
+Możliwość szybkiej demonstracji prototypu i szkolenia użytkowników.
-Koszt budowy prototypu, który może się nie zwrócić.
-Możliwość nieporozumień z klientem.
Realizacja przyrostowaOkreślenie wymagań i wstępny
projekt
Wybór przyrostu - podzbioru
funkcji
Realizacja przyrostu
Wdrożenie przyrostu
Proces realizowany iteracyjnie
Wady i zalety realizacji przyrostowej
+Możliwość wcześniejszego korzystania z pewnych funkcji systemu.
+ Skrócenie przerw w kontaktach z klientem.
+Możliwość elastycznego reagowania na opóźnienia.
-Kłopoty z integracją oddzielnie realizowanych modułów.
Realizacja przyrostowa
❖ Zalecana w większości lekkich (żwawych) metodyk – np. w programowaniu ekstremalnym – często małe przyrosty (kilka tygodni)
❖ Dobrze opisuje realizację wielu (zwłaszcza udanych) projektów wolnego oprogramowania (free/open source)
Wybór modelu do konkretnego przedsięwzięcia
❖ Duże przedsięwzięcia, np. > 6 miesiecy – realizacja przyrostowa, mniejsze m. kaskadowy
❖ W lekkich metodykach także dla mniejszych przedsięwzięć
❖ Trudności w określeniu wymagań:
❖ nowatorski system z punktu widzenia klienta
❖ mała znajomość dziedziny problemu przez wykonawcę:
Jeżeli tak, to prototypowanie
Unified Modeling Language - UML
❖ Obiektowa notacja graficzna służąca do modelowania, projektowania i specyfikacji oprogramowania
❖ Następca licznych notacji obiektowych z lat 80-tych i 90-tych
❖ Powstał na bazie metod Boocha, Rumbaugh (OMT) i Jacobsona – stworzony przez tych właśnie autorów
Unified Modeling Language - UML
❖ Standard Object Management Group (OMG)
❖ Wspierany przez firmę Rational
❖ De facto standard przemysłowy
❖ Pierwsza wersja w 1997
❖ Notacja, a nie metodyka
Analiza/modelowanie
❖ Opracowanie logicznego modelu dziedziny problemu
❖ Cele:
❖ Lepsze zrozumienie dziedziny problemu i lepsze określenie wymagań
❖ Podstawa przyszłego projektu
Dziedzina problemu
Wp
System
Dziedzina problemu
Wp
Model
Dlaczego notacje graficzne w modelowaniu
❖ Ogromny wzrost precyzji
❖ Ogromna poprawa efektywności
❖ Zapis modelu
❖ Analiza modelu
❖ Wprowadzanie zmian
❖ Łatwe przejście do projektowania
Diagramy przypadków użycia – use case diagrams – modelowanie wymagań
❖ Użytkownik, klasa użytkowników, system zewnętrzny (ang. actor)❖ Grupa użytkowników wykorzystujących system w podobny sposób
❖ Przypadek użycia, wymaganie funkcjonalne, funkcja (ang. use case)
Korzystanie z funkcji (ang. actor flow)
Związki używania (use) i rozszerzania (extend)
Przykład i związek generalizacji (generalization)
Diagramy klas
❖ Model statyczny
Obiekt
❖ Składowa dziedziny problemu posiadająca:❖ tożsamość❖ dane ją opisujące❖ zachowanie
❖ Obiekty wewnętrzne systemu, dane❖ np. wektor, plik, raport, drzewo binarne, okno, dokument elektroniczny
❖ Obiekty zewnętrzne, metadane❖ osoba, samochód, dokument papierowy, projekt
KlasaWzorzec, uogólnienie grupy obiektów opisywanych za pomocą podobnych danych i mających podobne zachowanie
Samochody
Związek generalizacji-specjalizacji
Wp
Samochód osobowy
Samochód ciężarowy
SamochódPojazd
Wiele generalizacji
Związek klas❖ Uogólnienie możliwych powiązań obiektów
Krotności związków
❖ 0..1 – zero lub jeden, opcjonalny
❖ 1 – dokładnie jeden, wymagany
❖ * - dowolna liczba
❖ 1..* - jeden lub więcej
❖ N..M – od N do M
❖ N – dokładnie N
Przykłady
Opisy związków
Rola Nazwa
Różne związki pomiędzy tymi samymi klasami
Związek pomiędzy obiektami tej samej klasy
Ograniczenia dotyczące związków
Związek kompozycji
Przykład - giełda usług przewozowych
Przykład – grafika wektorowa
Przykład – czasopismo naukowe
Diagramy stanów
❖ Model dynamiczny
❖ Zastosowania:
❖ Modelowanie zmian stanów (grup) obiektów
❖ Modelowanie reakcja na zdarzenia
❖ Modelowanie algorytmów
Zdarzenie
❖ Zjawisko, które zachodzi w pewnym punkcie czasu, np.:
❖ odjazd pociągu do Gdańska,
❖ wprowadzenie danych,
❖ wybranie polecenia z menu,
❖ przekroczenie temperatury 50°C.
Zdarzenia
❖ Zdarzenie zewnętrzne – zachodzi poza systemem, np.:
❖ wprowadzenie danych,
❖ wybranie polecenia z menu,
❖ przerwanie przez użytkownika wykonywania operacji.
❖ Zdarzenie wewnętrzne – zachodzi w ramach systemu, np.:
❖ zakończenie wykonywania metody,
❖ błąd arytmetyczny,
❖ przekroczenie czasu.
Stan
❖ Okres czasu ograniczony przez dwa zdarzenia
❖ System (fragment systemu) znajdując się w różnych stanach reaguje w sposób jakościowo różny na zachodzące zdarzenia.
(Stan artykułu w czasopiśmie naukowym)
Stany początkowy i końcowy
Początkowy
Końcowy
Przejście
❖ Zmiana stanu w wyniku zdarzenia
❖ Może być obwarowane warunkami
❖ Zachodzi natychmiastowo (w przybliżeniu)
Zdarzenia Warunek
Akcja
❖ Czynność wykonywana (w przybliżeniu) natychmiastowo w momencie zajścia zdarzenia
Czynność
❖ Działanie wykonywane w czasie kiedy system jest w pewnym stanie
❖ Może zostać przerwana w momencie zajścia zdarzenia, które powoduje wyjście ze stanu
❖ Jeżeli kończy się samoczynnie, to generuje zdarzenie, które powoduje przejście do innego stanu.
Akcje wejściowe, wyjściowe i wewnętrzne
=
Stan złożony
Przykład – stany artykułu
Przykład – zaznaczanie i przesuwanie obiektów w programie graficznym
Diagramy sekwencji
Przepływ komunikatów pomiędzy elementami dziedziny problemu
Obiekt
Nazwa obiektu:Nazwa klasy : Osoba - nieokreślony obiekt
klasy Osoba, Jan Nowak : Osoba - obiekt Jan Nowak
klasy Osoba, Jan Nowak : - obiekt Jan Nowak
nieokreślonej klasy.
Lina życia
Czas
Komunikaty
AsynchronicznySynchroniczny
Przykład – korzystanie z bankomatu
Specyfikacja modelu
❖ UML jest językiem graficznym
❖ Na diagramach można umieszczać szereg dodatkowych informacji – ograniczenia, stereotypy, komentarze
❖ W praktyce diagramy często wspiera się dodatkową specyfikacją – wspiera to szereg narzędzi CASE
Specyfikacja klas
❖ Opis❖ Lista pól❖ Lista metod❖ Ograniczenia
❖ Np. Wzrost > 0❖ Płaca minimalna < Płaca maksymalna
❖ Szacowana lub dokładna liczba obiektów tej klasy❖ Trwałość
Specyfikacja metod❖ opis – specyfikacja deklaratywna
❖ dane wejściowe
❖ dane wyjściowe
❖ algorytm
❖ warunki wstępne
❖ warunki końcowe
❖ wyjątki
❖ złożoność czasowa
❖ złożoność pamięciowa
Specyfikacja pól i parametrów
❖ typ przechowywanych wartości
❖ jednostka miary
❖ zakres dopuszczalnych wartości
❖ lista możliwych wartości
❖ wymagana precyzja
❖ wartość domyślna
❖ czy pole może być puste
❖ ograniczenia
❖ metody, które mogą czytać, ustawiać i modyfikować wartości tego pola.
Specyfikacja algorytmów❖ Algorytm klasyfikacji na podstawie reguł decyzyjnych❖ Dane wejściowe
❖ Uporządkowana (wg. ważności) lista reguł decyzyjnych w postaci:
❖ Jeżeli (A1 = ...) i ... i (An ...) to Decyzja = ...
❖ Reguła domyślna z pustą częścią warunkową❖ Obiekt do zaklasyfikowania opisany atrybutami A1
do An
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 decyzja 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łę domyślną
Budowa statycznego modelu klas
❖ Identyfikacja klas
❖ Identyfikacja związków klas
❖ Identyfikacja pól
❖ Identyfikacja metod
Identyfikacja klas
❖ Typowe klasy:
❖ przedmioty namacalne (np. samochód, czujnik),
❖ role pełnione przez osoby (np. pracownik, wykładowca, polityk),
❖ zdarzenia, o których system przechowuje informacje (np. lądowanie samolotu, zamówienie, dostawa),
❖ interakcje pomiędzy osobami i/lub systemami, o których system przechowuje informacje (np. pożyczka, spotkanie, konferencja),
❖ lokalizacje, tj. miejsca przeznaczone dla ludzi lub przedmiotów,
Identyfikacja klas❖ Typowe klasy
❖ grupy przedmiotów namacalnych (samochody, czujniki),
❖ organizacje (np. firma, wydział, związek),
❖ koncepcje (np. miara jakości, zadanie),
❖ dokumenty (np. prawo jazdy, faktura),
❖ klasy będące interfejsami dla systemów zewnętrznych,
❖ klasy będące interfejsami dla urządzeń sprzętowych.
Identyfikacja klas
❖ Analiza dziedziny problemu (problem domain analysis) – wykorzystanie wiedzy dziedzinowej
❖ literatura
❖ seminaria
❖ prezentacje
❖ rysunki
❖ inne modele – np. modele procesów biznesowych
Analiza opisu w języku naturalnym
❖ Rzeczowniki - potencjalne klasy, obiekty lub pola
❖ Czasowniki - potencjalne operacje lub związki klas
❖ „Ma”, „posiada”, „obejmuje”, „składa się”, „jest częścią”,… - związki kompozycji
❖ Rzeczowniki odczasownikowe – związki klas
❖ Rzeczowniki mogą oznaczać role pełnione w związkach
Przykład
Każdy projekt jest realizowany przez konsorcjum złożone z co najmniej trzech organizacji. Organizacja może być firmą komercyjną, jednostką badawczą lub organizacją publiczną. Organizacja może realizować wiele projektów badawczych. Każdy projekt ma jednego koordynatora.
Przykład
Identyfikacja klas
❖ Wykorzystanie związków klas i obiektów
❖ Czy klasa ma potencjalne specjalizacje i/lub generalizacje?
❖ Czy klasa ma części składowe i/lub jest częścią większej całości?
❖ Czy klasa pozostaje w związkach z innymi klasami?
Identyfikacja klas
❖ Analiza funkcji
❖ Jakie obiekty, jakich klas będą niezbędne do realizacji poszczególnych funkcji
Weryfikacja klas
❖ Nieobecność pól i operacji
❖ Nieliczne (pojedyncze) pola i operacje
❖ Brak związków z innymi klasami
❖ Tylko jeden obiekt w klasie
❖ Dobrą klasą jest klasa Samochód, złymi Samochód Kowalskiego i Samochód Nowaka.
Identyfikacja krotności związków
Analiza przykładowych (rzeczywistych lub wymyślonych) powiązań obiektów
Weryfikacja związków obligatoryjnych np. 1 lub 1..*
Czy instytut musi mieć pracowników?
Identyfikacja związków kompozycji
❖ Zwroty pojawiające się w słownym opisie systemu jak:
zawiera, składa się, obejmuje
❖ Klasy posiadające części składowe
❖ Klasy będące zbiorami pewnych elementów
Części składowe
Zbiory
Do zobaczenia 29 listopada
�