Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne Inżynieria oprogramowania część I dr inż. Bartłomiej Prędki Bartlomiej.Predki@cs.put.poznan.pl Pok. 124 CW, tel. 61665 2932 http://zajecia.predki.com Semestr zimowy 2016/2017
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 Efekty Oczekiwania Rzeczywiste osiągnięcia Czas
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 testu na ostatnim wykładzie, czyli 14 stycznia 2017 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 Wdrożenie Tak System poprawny 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 przyrostowa Określenie wymagań i wstępny projekt Wybór przyrostu - podzbioru funkcji Proces realizowany iteracyjnie Realizacja przyrostu Wdrożenie przyrostu
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 System Dziedzina problemu Model W pw p
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 zawierania (include) 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
Klasa Wzorzec, uogólnienie grupy obiektów opisywanych za pomocą podobnych danych i mających podobne zachowanie Samochody
Związek generalizacji-specjalizacji Pojazd Samochód ciężarowy Samochód W p Samochód osobowy
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 Lina życia Czas 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.
Komunikaty Synchroniczny Asynchroniczny
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
Do zobaczenia 6 listopada