Inżynieria oprogramowania część I

Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne

Semestr zimowy 2016/2017

dr inż. Bartłomiej Prędki

Bartlomiej.Predki@cs.put.poznan.pl

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 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

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

SystemDziedzina 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 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

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

Do zobaczenia 6 listopada

�