Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne. Inżynieria oprogramowania

Transkrypt

1 Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne Inżynieria oprogramowania 27 kwietnia 2014

2 Wzorce projektowe Prawie każdy problem, także projektowy, nad którym się zastanawiasz, ktoś już rozwiązał Wzorce (patterns) zawierają dobre praktyki Antywzorce przykłady złych praktyk Wzorce mogą też przyśpieszać komunikację

3 Przechowywanie Jak przechować pojedynczą wielkość? double IloscPaliwa;! Problem: W jakiej jednostce przechowywane jest to pole? Litry, hektolitry, metry sześcienne, mililitry, tony?

4 Wzorzec Quantity

5 Wzorzec Quantity - Lub np. pole typu Wielkosc

6 Wzorzec Quantity - cechy Informacja o jednostce jest zawsze przechowywana wraz z ilością

7 Współpracujące klasy np.:

8 Wzorzec Client-Server

9 Przykład wzorca

10 Wzorzec Client-Server - Zmiany klienta nie wymuszają zmian serwera Np. zmiany w klasie interfejsowej nie wymuszają zmian w klasie należącej do dziedziny problemu Serwer pełni rolę pasywną Częściowo można to obejść korzystając np. ze wzorca Observer

11 Wzorzec Client-Server dla pakietów klas

12 Uniezależnienie interfejsu użytkownika od części obliczeniowej programu

13 Wzorzec Facade Facade

14 Wzorzec Facade - cechy Zmiany w pakiecie serwera nie wymuszają zmian klientów o ile fasada pozostaje taka sama Klasy wyłącznie delegujące swoje zadania (jak fasada) są często traktowane jako niepożądane

15 Niezależność współpracujących klas We wzorcu client-server klient jest zależny od serwera Jest to szczególnie niekorzystne, jeżeli współpraca z serwerem jest tylko niewielką częścią funkcjonalności klienta Jak tego uniknąć?

16 Wzorzec Mediator

17 Przykład wzorca Mediator

18 Wzorzec Mediator - cechy Pozwala na współpracę klas (pakietów, modułów) całkowicie od siebie niezależnych Role aktywną pełni mediator Częściowo można to obejść korzystając np. Z wzorca Observer

19 Kosztowne obiekty

20 Wzorzec Proxy

21 Przykład wzorca Proxy

22 Wzorzec Proxy - cechy Kosztowny obiekt jest konstruowany tylko wtedy jeżeli będą na nim wykonywane jakieś operacje Opóźnione konstruowanie kosztownego obiektu jest niewidoczne dla klienta

23 Niespójne klasy

24 Wzorzec Adapter

25 Przykład wzorca Adapter

26 Wzorzec Adapter - cechy Adaptowana klasa może być wykorzystywana tak jak inne klasy implementujące standardowy interfejs Fakt korzystania z niestandardowej klasy jest niewidoczny dla klienta

27 Potrzeba wielopoziomowej hierarchii agregacji Przykład: Rysunek składa się z figur Figury mogą tworzyć grupy W skład grupy może wchodzić inna grupa figur Pewne operacja można wykonywać zarówno na pojedynczych figurach, jak i grupach figur.

28 Wzorzec Composite

29 Przykład wzorca

30 Wzorzec Composite - cechy Hierarchia zawierania się może być dowolnie zagłębiona Liście mogą się pojawiać na dowolnym poziomie hierarchii obok grup (dowolnego poziomu) Jak tego uniknąć?

31 Jak oddzielić konstrukcję złożonego obiektu od jego reprezentacji Np. zapis danych programu graficznego w różnych formatach

32 Wzorzec Builder

33 Przykład wzorca builder

34 Wzorzec Builder Reżyser (director) zna tylko ogólną strukturę budowanego obiektu Budowniczy (builder) zna tylko elementarne kroki budowy obiektu w zadany sposób

35 Polecenia Jak zapewnić: Możliwość stosowania różnych sposobów wydawania poleceń Niezależność pomiędzy obiektem wysyłającym polecenie i odbiorcą

36 Wzorzec Command

37 Przykład wzorca

38 Wzorzec Command Nadawca jest niezależny od odbiorcy i vice versa To samo polecenie może być wydawane przez różnych nadawców Łączenie poleceń z nadawcami może być dynamiczne

39 Różna reakcja na zdarzenia w zależności od stanu

40 Typowa implementacja void CZadanie::Zwolnij_zasob (TZasobID Zasob) {!! if (State == _ZDEFINIOWANE) {!!!...!! }!! else if (State == _ZAPLANOWANE) {!!!...!! }!! else if (State == _REALIZOWANE) {!!!...!! }!! else if (State == _ZREALIZOWANE) {!!!...!! }!

41 Wzorzec State

42 Przykład wzorca State

43 Wzorzec State - cechy Łatwiejsze dodawanie/usuwanie stanów Konieczne konstruowanie usuwanie obiektów przy zmianie stanów Trudniejsze dodawanie/usuwanie metod (trzeba je dodawać/usuwać w różnych stanach)

44 Schemat algorytmu Znajdź populację początkową powtarzaj Selekcja Rekombinacja Mutacja dopóki nie są spełnione warunki stopu

45 Wzorzec Template

46 Przykład wzorca Template method

47 Wzorzec Template Ponownie wykorzystywany jest szkielet algorytmu przy możliwości zmiany poszczególnych kroków

48 Grupowanie podobnych Gdzie umieścić operacje tego samego typu dotyczące grupy klas?

49 Klasyczne rozwiązanie

50 Przykład wzorca Visitor

51 Wzorzec Visitor - cechy Grupuje operacje danego typu, np. kod składowej zarządzania danymi Korzystne np. przy zmianach technologii składowych technicznych

52 Jak rozszerzyć działanie Np. jak w programie graficznym dodać do każdej figury i grupy figur możliwość wyświetlania nazwy?

53 Rozwiązanie klasyczne -

54 Wzorzec Decorator

55 Przykład wzorca Decorator

56 Wzorzec Decorator - Zachowanie każdego komponentu może zostać rozszerzone Rozszerzenia są niewidoczne dla klienta

57 Tworzenie obiektów Czy rysunek musi znać wszystkie manipulatory?

58 Wzorzec Factory method

59 Przykład wzorca Factory

60 Wzorzec Factory method Klient nie musi znać konkretnych klas, których obiekty są konstruowane

61 Wzorzec Singleton zapewnianie istnienia tylko

62 Wzorzec Singleton w C+ class CSingleton {! protected:!! static CSingleton* UniqueInstance;!! CSingleton () {!!...!! }! public:!! static CSingleton* Instance () {!!! if (UniqueInstance == NULL)!!! UniqueInstance = new CSingleton;!!! return UniqueInstance;!! }! };!! CSingleton* CSingleton::UniqueInstance = NULL;!...! CSingleton* Singleton = CSingleton::Instance ();

63 Wzorzec Singleton w Javie public class Singleton {! static protected Singleton uniqueinstance = null;! protected Singleton() {!...! }! static public Singleton instance() {! if(uniqueinstance == null) {!!! uniqueinstance = new Singleton();! }! return uniqueinstance;! }! }!...! Singleton singleton = Singleton.getInstance();

64 Dostarczanie i pielęgnacja

65 Instalacja oprogramowania Szkolenia użytkowników końcowych i administratorów systemu Instalacja sprzętu i przeniesienie oprogramowania Wypełnienie baz danych Uruchomienie oprogramowania Plany awaryjne

66 Instalacja oprogramowania Nadzorowane korzystanie z systemu, często równoległe z tradycyjnym sposobem pracy Usuwanie błędów w oprogramowaniu i dokumentacji użytkowej Przekazanie systemu klientowi Klient powinien otrzymać także dokumentację techniczną

67 Konserwacja oprogramowania Modyfikacje poprawiające/korygujące ulepszające dostosowujące

68 Źródła żądań zmian Klienci Wytwórcy oprogramowania Zarząd

69 Narzędzia zarządzania żądaniami zmian Keystone (Freeware) JitterBug (Freeware, Open Source) GNATS (Freeware) Visual Intercept (commercial) Bugzilla (Open source) Mantis (Open source)

70 Funkcje narzędzi zarządzania żądaniami Zarządzanie projektami/podprojektami i przydziałami odpowiedzialności Wprowadzanie żądań zmian Powiadamianie osób odpowiedzialnych, osób wprowadzających żądania Śledzenie żądań zmian Raporty, statystyki

71 Ocena żądanej zmiany Znaczenie wprowadzenia zmiany dla użytkowników Koszt wprowadzenia zmiany Wpływ zmiany za poszczególne składowe systemu Wpływ zmiany na poszczególne składowe dokumentacji technicznej Propagacja zmian

72 Zarządzanie żądaniami zmian Całościowa ocena i decyzja Kolejkowanie żądań zmian Zlecenie wykonania zmiany Przydział osoby/zespołu do wykonania zmiany Monitorowanie realizacji zmiany

73 Czynniki wpływające na koszty konserwacji Niezależne od firmy Stabilność środowiska, w którym pracuje system Stabilność platformy sprzętowej i oprogramowania systemowego Czas użytkowania systemu

74 Czynniki wpływające na koszty konserwacji Zależne od firmy Znajomość dziedziny problemu Wysoka jakość modelu i projektu Wysoka jakość dokumentacji technicznej pełna zgodność z systemem wystarczająca szczegółowość zgodność ze standardami Stabilność personelu

75 Dokumentacja techniczna Dokumentacja techniczna a projekt Jakość dokumentacji a jakość projektu Dobra dokumentacja Zły projekt Dobra dokumentacja Dobry projekt Zła dokumentacja Zły projekt Zła dokumentacja Dobry projekt

76 Inżynieria odwrotna Typowa składowa narzędzi CASE Generowanie kodu Synchronizacja projektu z kodem Narzędzia niezależne JavaDoc, Doxygen, NDoc,...

77 Reinżynieria oprogramowania Generowanie kodu CASE Kod Inżynieria odwrotna

78 Ponowne wykorzystanie oprogramowania Zalety Redukcja kosztów Wzrost niezawodność Narzucenie standardów

79 Przygotowanie kodu do ponownego wykorzystania Budowa klockowa Niezależność składowych Spójność składowych Odpowiednia złożoność Przejrzystość Dobra dokumentacja

80 Wzorce projektowe związane z ponownym wykorzystanie oprogramowania Mediator Adapter Decorator Template method

81 Dokumentacja użytkowa Odbiorcy dokumentacji Potencjalni użytkownicy Użytkownicy początkujący Użytkownicy zaawansowani Administratorzy

82 Składowe dokumentacji użytkowej Opis funkcjonalny Podręcznik użytkownika Kompletny opis (reference) Opis instalacji Podręcznik administratora systemu Słownik używanych terminów Indeks

83 Podręcznik użytkownika Sposoby uruchamiania oraz kończenia pracy z systemem Sposoby realizacji najczęściej wykorzystywanych funkcji systemu Metody obsługi błędów, np. sposoby odwoływania błędnych operacji wykonanych przez użytkownika Sposoby korzystania z systemu pomocy Podręcznik użytkownika powinien przedstawiać prosty przykład(y) korzystania z systemu.

84 Kompletny opis Szczegółowy opis wszystkich funkcji systemu Informacje o wszystkich sposobach wywoływania tych funkcji Opisy formatów danych Opisy wszystkich błędów, które mogą się pojawiać podczas pracy z systemem Informacje o wszelkich ograniczeniach dotyczących np. zakresów danych

85 Jakość dokumentacji użytkowej Struktura Zachowanie standardów Sposób pisania Stosowanie formy aktywnej oraz zwracanie się do czytelnika. Poprawność gramatyczna i ortograficzna. Krótkie zdania. Krótkie akapity. Oszczędność słów. Precyzyjna definicja używanych terminów. Powtarzanie trudnego opisu. Stosowanie tytułów i podtytułów sekcji, wyliczeń i wyróżnień. Zrozumiałe odwołania do innych rozdziałów.

86 Bezpieczeństwo użytkowników oprogramowania Zagrożenie dla życia lub zdrowia systemy medyczne, systemy sterowania Bezpieczeństwo prawne Bezpieczeństwo finansowe

87 Bezpieczeństwo niezawodność Program zawodny może być bezpieczny Program niezawodny może nie być bezpieczny

88 Jak zapewnić bezpieczeństwo Należy określić potencjalne zagrożenia Przykład - program sporządzający PIT-y błędne rozliczenie podatnika z urzędem podatkowym niezłożenie zeznania podatkowego złożenie wielu zeznań dla jednego podatnika, być może w różnych urzędach

89 Określanie potencjalnych przyczyn zagrożeń Analiza drzewa błędów Błędne rozliczenie podatnika Wprowadzenie błędnych danych Błąd obliczeniowy Błędny wydruk rozliczenia Błędnie obliczona podstawa opodatkowania Błędnie obliczony podatek Błędnie obliczona nadpłata - dopłata Błędnie zsumowane dochody Błędnie zsumowane ulgi

90 Unikanie zagrożeń Szczególny nacisk na niezawodność najważniejszych fragmentów systemu - unikanie błędów, testowanie Weryfikacja wprowadzonych danych Sprawdzanie warunków poprawności

91 Zapewnianie jakości Zapewnianie jakości a inżynieria oprogramowania Główne działania składające się na zapewnianie jakości: Standaryzacja Kontrole jakości formalne przeglądy techniczne

92 Standaryzacja Standardy dotyczące artefaktów: Kod, projekt, specyfikacja wymagań, dokumentacja techniczna, dokumentacja użytkowa Procedury standardy dotyczące działań Sposób zatwierdzania dokumentacji technicznej, sposób przekazywania modułu do testowania Cele: Promowanie dobrych praktyk Wymuszenie spójności Możliwość automatyzacji

93 Inne typowe problemy Czy wszystko zostało skompilowanie? Przetestowane? Jak usunąć niekompletną/błędną modyfikację? Nie mogę odtworzyć tego błędu. Jakie zmiany zostały uwzględnione w tej wersji? Muszę połączyć 250 plików? Jaką wersję ma ten klient? Czy dostarczyliśmy właściwą wersję? Czy klient zmodyfikował nam kod? Czy można klientowi dostarczyć najnowszą wersję jeżeli na zakupił dwóch poprzednich?

94 Praca grupowa

95 Praca grupowa Gdzie jest najnowsza wersja!!! Czy Kowalski cokolwiek robi w tym projekcie?!!! Kto popełnił ten błąd?!!! Nie ja!!! Przecież już raz poprawiłem ten błąd!!! Przecież poprzednio to działało!!! Ktoś nadpisał moje zmiany!!!

96 Praca grupowa i zarządzanie konfiguracjami Równoległa pracy wielu osób nad tym samym projektem Ryzyko nadpisywania zmian Problem najnowszej wersji Potrzeba odwoływania się do poprzednich wersji Monitorowanie prac

97 CVS concurrent versioning system Najpopularniejsze narzędzie zarządzania konfiguracjami w projektach open-source Często wykorzystywany komercyjnie Unix, Windows, WINCVS, WebCVS Komponenty pliki, przede wszystkim tekstowe Wypierany przez SVN (Subversion)

98 CVS - struktura Server CVS Centralne repozytorium

99 Podstawowy model pracy Server CVS Centralne repozytorium 1: Pobranie pliku(ów) (check-out) 3: Zapis pliku(ów) (check-in/commit) 2: Edycja pliku(ów)

100 Podstawowy model pracy Dołączanie komentarzy nt. wprowadzonych zmian podczas zapisu pliku(ów) Porównywanie lokalnej pliku(ów) z zawartością repozytorium Jaka powinna być częstotliwość zapisu do repozytorium?

101 Wersja bazowa Przed powstaniem wersji bazowej samodzielna praca osoby/zesołu Wersja bazowa od tego momentu komponent może być wykorzystywany przez inne osoby/zespoły i podlega zarządzaniu konfiguracjami

102 Praca równoległa unikanie konfliktów Blokowanie pliku(ów) lub pobieranie bez wyłączności (unreserved check-out) Synchronizacja lokalnej kopii pliku(ów) Wykrywanie konfliktów bez interpretacji zawartości pliku tekstowego Informowanie innych użytkowników o zapisie Możliwość sprawdzenia kto korzysta z pliku Obserwowanie wybranych plików - powiadamianie

103 Ochrona danych Użytkownicy Hasła Prawa dostępu

104 Wersjonowanie Jednostką wersjonowania jest plik Każda zmiana powoduje powstanie nowej wersji pliku Możliwość opisywania wersji etykietami Pobieranie poprzednich wersji na podstawie daty lub etykiety Porównywanie różnych wersji

105 Sposób zapisu wersji Wersja bazowa Zmiany Zmiany Zmiany Wersja Wersja Wersja 11.05

106 Rozgałęzianie i łączenie gałęzi Wersja 1.1b Wersja 1.2b Wersja 1.3b Wersja 1 Wersja 1.1a Wersja 1.2a Wersja 1.3

107 Przyczyny rozgałęzień Niezależne ścieżki rozwoju, np. konserwacja komponentu vs. jego dalszy rozwój Warianty np. konfiguracje na różne platformy Eksperymentalne ścieżki rozwoju Równoległa praca dwóch programistów/zespołów trudna do bieżącej synchronizacji

108 Śledzenie prac Obserwacja komentarzy Monitorowanie pracy użytkowników Analiza danych

109 System Subversion Praktycznie wszystkie cechy CVS-a Wersjonowanie operacji na katalogach (drzewach) katalogów Dołączanie i wersjonowanie metadanych Atomowe operacje zapisu Zapis danych w bazie danych Lepsza obsługa plików binarnych Łatwe i tanie rozgałęzianie Lepsza struktura kodu

110 Inne modele pracy w systemach zarządzania konfiguracjami Composition Model Long Transaction Model Change Set Model

111 Narzędzia wspomagające wytwarzanie oprogramowania Narzędzia programistyczne Narzędzia wspomagające pracę nad oprogramowaniem Narzędzia zarządzania i pracy grupowej Zaawansowane narzędzia wspomagające wytwarzanie oprogramowania

112 Narzędzia programistyczne Kompilatory Edytory kodu Debuggery IDE Narzędzia projektowania interfejsu użytkownika Biblioteki Narzędzia formatujące Analizatory kodu Narzędzia wspomagające refaktoryzację

113 Narzędzia wspomagające pracę nad oprogramowaniem Narzędzia zarządzania wymaganiami Narzędzia CASE modelowanie, projektowanie, generowanie i dokumentowanie oprogramowania Narzędzia zarządzania konfiguracjami Narzędzia wspomagające testowanie Narzędzia dokumentacji technicznej Narzędzia zarządzania zgłoszeniami zmian/błędów

114 Narzędzia zarządzania i pracy grupowej Narzędzia harmonogramowania przedsięwzięć Personalne plany zadań Narzędzia rozproszonego zarządzania przedsięwzięciami Narzędzia generujące metryki Narzędzia szacowania kosztów oprogramowania Narzędzia komunikacji Narzędzia zarządzania konfiguracjami

115 Zaawansowane narzędzia wspomagające wytwarzanie oprogramowania Narzędzia typu workflow Narzędzia śledzenia powiązań Narzędzia analizy danych

116 Narzędzia CASE Computer Assisted/Aided Software/System Engineering CAD dla inżynierów oprogramowania Upper-CASE głównie analiza Lower-CASE projektowanie, generowanie kodu, inżynieria odwrotna I-CASE, Integrated-CASE

117 Składowe narzędzi CASE Słownik danych repozytorium Edytor(y) notacji graficznych Generator raportów Generator dokumentacji technicznej Generator(y) kodu Moduł projektowania interfejsu użytkownika Moduł(y) inżynierii odwrotnej

118 Składowe narzędzi CASE Moduł kontroli poprawności Moduł kontroli jakości Moduł importu/eksportu danych Moduł zarządzania wersjami Moduł zarządzania pracą grupową

119 Główne zalety narzędzi CASE Wspomaganie analizy i projektowania Opracowywanie dokumentacji Wspomaganie pracy grupowej A co z generowaniem kodu?

120 Główne problemy we wdrażaniu narzędzi CASE Traktowanie narzędzi CASE wyłącznie jako generatorów kodu Nieznajomość metodyki analizy i projektowania Niewłaściwa organizacja i zarządzanie przedsięwzięciem Zbyt wysokie oczekiwania związane z wdrożeniem narzędzi CASE

121 Podsumowanie

122 Ważne trendy w inżynierii oprogramowania Lekkie metodyki Wpływ na podejścia klasyczne Narzędzia Integracja Zaawansowane narzędzia typu workflow, śledzenia powiązań, analizy danych Wolne oprogramowanie Wytwarzanie rozproszone Ponowne wykorzystanie oprogramowania W tym Applications framework Architektura/inżynieria kierowana modelem

123 Inżynieria oprogramowania Wiedza techniczna, dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu - oprogramowania.

124 Tanie Użyteczne Niezawodne Bezpieczne Dobre oprogramowanie Ergonomiczne Łatwe w konserwacji Zapewnianie jakości Efektywne

125 Określanie celów i wymagań Niezawodne Prototypowanie Użyteczne Ergonomiczne Analiza - modelowanie Projektowanie, implementacja, testowanie

126 Dobrze zaprojektowane Unikanie błędów Dobrze zaprojektowane Ponowne wykorzystanie oprogramowania Niezawodne Odporność na błędy Dobrze udokumentowane Testowanie Warunki poprawności

127 Projektowanie interfejsu użytkownika Ergonomiczne Dokumentacja użytkowa

128 Wzorce projektowe np. Proxy Efektywne Optymalizacja efektywności

129 Dobrze udokumentowane Inżynieria odwrotna Notacje Łatwe w konserwacji UML Refaktoryzacja Metody analizy i projektowania Dobrze zaprojektowane Przejrzyste Wzorce projektowe Zgodne z rzeczywistością Modularne

130 Zapewnianie bezpieczeństwa Bezpieczne Niezawodne

131 Łatwe w konserwacji Niezawodne Lekkie metodyki Ponowne wykorzystanie oprogramowania re-use Unikanie błędów Tanie Praca grupowa Narzędzia Modularne Narzędzia Notacje Wzorce projektowe

132 Standardy, procedury Zapewnianie jakości Przeglądy techniczne

133