©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 1 Restrukturyzacja oprogramowania l Przedstawienie procesu restrukturyzacji oprogramowania,

Prezentacja na temat: "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 1 Restrukturyzacja oprogramowania l Przedstawienie procesu restrukturyzacji oprogramowania,"— Zapis prezentacji:

1 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 1 Restrukturyzacja oprogramowania l Przedstawienie procesu restrukturyzacji oprogramowania, który ma zwiększyć zdatność do pielęgnacji systemu oprogramowania

2 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 2 Cele l Dowiedzieć, dlaczego restrukturyzacja oprogramowania może być opłacalnym wariantem ewolucji systemu oprogramowania. l Poznać czynności, takie jak inżynieria wstecz i przebudowa programu, które mogą wchodzić w skład procesu restrukturyzacji oprogramowania. l Poznać różnice między restrukturyzacją oprogramowania a restrukturyzacją danych oraz dowiedzieć, dlaczego restrukturyzacja danych jest procesem kosztownym i czasochłonnym.

3 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 3 Zawartość l Tłumaczenie kodu źródłowego l Inżynieria wstecz l Ulepszanie struktury programu l Modularyzacja programu l Restrukturyzacja danych

4 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 4 l Polega na ponownym zaimplementowaniu systemów odziedziczonych w celu zwiększenia ich zdatności do pielęgnacji. l Restrukturyzacja może obejmować ponowne dokumentowanie systemu, porządkowanie i przebudowę systemu, przetłumaczenie systemu na nowocześniejszy język programowania oraz modyfikowanie i aktualizację struktur oraz wartości danych systemu. Restrukturyzacja oprogramowania

5 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 5 l Rozmiar kodu systemów odziedziczonych jest ogromny. W latach dziewięć dziesiątych XX wieku oszacowano ją (Ulrich, 1990) na 120 miliardów wierszy kodu źródłowego. Większość z tych systemów napisano w języku COBOL przystosowanym do przetwarzania danych gospodarczych lub w języku FORTRAN. FORTRAN jest językiem do pisania programów matematycznych i naukowych. Języki te mają niewiele udogodnień do strukturyzacji programu, a FORTRAN ma bardzo ograniczone udogodnienia do strukturyzacji danych. l Chociaż wiele z tych programów wymieniono na nowe, większość z nich prawdopodobnie ciągle jest w użyciu. W latach dziewięćdziesiątych XX wieku nastąpił ogromny wzrost wykorzystania komputerów do celów gospodarczych. Obecnie istnieje około 250 miliardów wierszy kodu, które trzeba pielęgnować. Większa ich część nie jest zapisana w językach programowania obiektowego. Wiele z nich działa ciągle na komputerach głównych. Ocena złożoności problemów systemów odziedziczonych

6 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 6 Zalety restrukturyzacji systemu oprogramowania l Mniejsze ryzyko. Ponowne tworzenie oprogramowania ważnego dla firmy wiąże się z wysokim ryzykiem. Można popełnić błędy w specyfikacji systemu, mogą pojawić się kłopoty z tworzeniem itd. l Mniejszy koszt. Koszty restrukturyzacji są znacznie niższe niż koszty budowania nowego oprogramowania. Urlich (1990) podaje przykład komercyjnego systemu, którego ponowną implementację wyceniono na 50 milionów dolarów. Z powodzeniem zrestrukturyzowano go za 12 milionów. Jeśli te dane są typowe, to restrukturyzacja jest około cztery razy tańsza niż przepisywanie.

7 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 7 Inżynieria do przodu i restrukturyzacja Specyfikacja systemu Specyfikacja systemu Projektowanie i implementacja Projektowanie i implementacja Rozpoznawanie i przekształcanie Rozpoznawanie i przekształcanie Istniejący system oprogramowania Istniejący system oprogramowania Nowy system Nowy system Zrestrukturyzowany system Zrestrukturyzowany system Inżynieria do przodu Restrukturyzacja oprogramowania

8 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 8 Proces restrukturyzacji Zrestrukturyzowane dane Zrestrukturyzowane dane Ulepszanie struktury programu Ulepszanie struktury programu Restrukturyzacja danych Restrukturyzacja danych Modularyzacja programu Modularyzacja programu Inżynieria wstecz Inżynieria wstecz Tłumaczenie kodu źródłowego Tłumaczenie kodu źródłowego Program strukturalny Program strukturalny Pierwotne dane Pierwotne dane Zmodulary- zowany program Zmodulary- zowany program Dokumentacja programu Dokumentacja programu Pierwotny program Pierwotny program

9 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 9 Podejścia do restrukturyzacji Rosnące koszty Automatyczna konwersja Automatyczna przebudowaPrzebudowa i zmiany kodu źródłowego ze zmianami manualnymi architektoniczne Automatyczna Przebudowa przebudowa danych programu i programu

10 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 10 Inne czynniki mające wpływ na koszty restrukturyzacji l Jakość oprogramowania do restrukturyzacji. Im niższa jest jakość oprogramowania i związanej z nim dokumentacji (jeśli istnieje), tym wyższe są koszty restrukturyzacji. l Wspomaganie narzędziowe restrukturyzacji. Restrukturyzacja systemu oprogramowania jest zwykle nieopłacalna, chyba że można skorzystać z narzędzi CASE, aby zautomatyzować większość modyfikacji programu. l Zakres niezbędnej konwersji danych. Jeśli restrukturyzacja powoduje konieczność konwersji wielkich ilości danych, to koszt tego procesu jest znacznie większy. l Dostępność ekspertów. Jeśli personel odpowiedzialny za pielęgnację systemu nie może wziąć udziału w procesie restrukturyzacji, to koszt tego procesu będzie wyższy. Osoby restrukturyzujące system spędzą wiele czasu na rozpoznawaniu systemu.

11 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 11 Tłumaczenie kodu źródłowego l Najprostszą formą restrukturyzacji oprogramowania jest tłumaczenie programu, które polega na automatycznym przekładzie kodu źródłowego w jednym języku programowania na kod źródłowy w jakimś innym języku. l Struktura i porządek samego programu pozostają bez zmian. l Docelowy język może być nową wersją pierwotnego języka (np. z języka COBOL-74 na język COBOL-85) lub zupełnie innym językiem (np. z języka FORTRAN na język C).

12 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 12 Przyczyny konieczności tłumaczenia kodu źródłowego l Aktualizacja platformy sprzętowej l Braki w umiejętnościach personelu l Zmiany strategii firmy l Brak wspomagania dla oprogramowania

13 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 13 Proces tłumaczenia programu Przetłumacz kod manualnie Przetłumacz kod manualnie Zrestrukturyzowany system Zrestrukturyzowany system System do restrukturyzacji System do restrukturyzacji System do restrukturyzacji System do restrukturyzacji Przetłumacz kod automatycznie Przetłumacz kod automatycznie Zaprojektuj instrukcje translatora Zaprojektuj instrukcje translatora Rozpoznaj różnice w kodzie źródłowym Rozpoznaj różnice w kodzie źródłowym

14 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 14 Inżynieria wstecz Inżynieria wstecz to proces analizy oprogramowania, którego celem jest odtworzenie projektu i specyfikacji. W tym procesie program nie ulega zmianie. Kod źródłowy oprogramowania jest zwykle dostępny i stanowi daną wejściową dla procesu inżynierii wstecz. Czasem zagubiono nawet kod źródłowy, inżynierię wstecz trzeba więc zacząć od analizy kodu wykonywalnego. Celem inżynierii wstecz jest określenie projektu i specyfikacji systemu na podstawie kodu źródłowego. (Celem restrukturyzacji jest utworzenie nowego, zdatniejszego do pielęgnacji systemu.)

15 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 15 Proces inżynierii wstecz System do restrukturyzacji System do restrukturyzacji Składnica informacji o programie Składnica informacji o programie Macierze śladu Diagramy struktur danych Diagramy struktur danych Diagram struktury programu Diagram struktury programu Dodawanie adnotacji Dodawanie adnotacji Analiza automatyczna Analiza automatyczna Generowanie dokumentów Generowanie dokumentów

16 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 16 Ulepszanie struktury programu l Potrzeba optymalizacji użycia pamięci i nieznajomość inżynierii oprogramowania u wielu programistów spowodowały, że wiele systemów odziedziczonych nie ma dobrej struktury. l Struktura sterowania jest zagmatwana przez wiele bezwarunkowych odgałęzień i niezgodna z logiką sterowania. l Ta struktura mogła podlegać dalszej degradacji z powodu regularnej pielęgnacji. l Zmiany w programie mogły uczynić nieosiągalnymi pewne fragmenty kodu; można je wykryć jedynie po intensywnej analizie. l Programiści pielęgnujący często nie mają odwagi usunąć kodu, ponieważ obawiają się, że może być on wykorzystywany pośrednio.

17 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 17 Program sterujący o logice spaghetti Początek:Podaj (Czas-włączenia, Czas-wyłączenia, Ustawienie, Temperatura, Przełącznik) if Przełącznik = Wyłączony goto Wyłączony if Przełącznik = Włączony goto Włączony goto Sterowany Wyłączony:if Stan-grzania = Włączony goto Wyłącz-grzanie goto Pętla Włączonyif Stan-grzania = Wyłączony goto Włącz-grzanie goto Pętla Sterowany:if Czas = Czas-włączenia goto Włączony if Czas = Czas-wyłączenia goto Wyłączony if Czas < Czas-włączenia goto Początek if Czas > Czas-wyłączenia goto Początek if temperatura > Ustawienie goto Wyłączony Wyłącz-grzanie:Stan-grzania := Wyłączony goto Przełączenie Włącz-grzanie:Stan-grzania := Włączony Przełączenie:Przełącz-grzanie Pętla:goto Początek

18 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 18 Strukturalny program sterujący loop -- Instrukcja Podaj powoduje odczyt ze środowiska systemu wartości -- dla zadanych zmiennych Podaj (Czas-włączenia, Czas-wyłączenia, Ustawienie, Temperatura, Przełącznik) case Przełącznik of when Włączony => if Stan-grzania = Wyłączony then Przełącz-grzanie ; Stan-grzania: = Włączony ; end if; when Wyłączony => if Stan-grzania = Włączony then Przełącz-grzanie ; Stan-grzania :=Wyłączony ; enf if; when Sterowany => if Czas >= czas-włączenia and Czas <= Czas-wyłączenia then if Temperatura > Ustawienie and Czas-grzania = Włączony then Przełącz-grzanie ; Stan-grzania := Wyłączony ; else if Temperatura < Ustawienie and Stan-grzania = Wyłączony then Przełącz-grzanie ; Stan-grzania := Włączony ; end if ; end case ; End loop ;

19 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 19 Upraszczanie warunków -- Złożony warunek if not (A > B and (C F) ) )... -- Uproszczony warunek if A = D and E > F)...

20 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 20 Automatyczna przebudowa programu Program do przebudowy Program do przebudowy Analizator i generator grafów Analizator i generator grafów Przebudowany program Przebudowany program Reprezentacja grafowa Reprezentacja grafowa Generator programu Generator programu

21 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 21 Kłopoty związane z automatyczną przebudowa programu l Utrata komentarzy. W wyniku procesu przebudowy komentarze wbudowane w wiersze programu są nieuchronnie tracone. l Utrata dokumentacji. Analogicznie traci się powiązanie między programem a jego zewnętrzna dokumentacją. W wielu przypadkach zarówno dokumentacja, jak i komentarze są nieaktualne, więc nie jest to istotny czynnik. l Wysokie wymagania stawiane mocy obliczeniowej. Algorytmy sterowane w czasie przebudowy są złożone. Nawet przy zastosowaniu szybkiego, nowoczesnego sprzętu przebudowa ogromnych programów może trwać bardzo długo.

22 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 22 Modularyzacja programu l Modularyzacja programu to proces reorganizacji programu tak, aby jego powiązane części zgromadzić razem i traktować jak jeden moduł. l Po ukończeniu tego procesu usuwanie nadmiarowości z tych powiązanych komponentów, optymalizacja ich interakcji i uproszczenie ich interfejsów z resztą programu stają się łatwiejsze. l Np. w programie, który gromadzi dane sejsmograficzne, wszystkie operacje związane z prezentacją graficzną danych będą na przykład zgrupowane w jednym module. l Jeśli system ma być rozproszony, to utworzenie moduły można zamknąć w obiektach i udostępnić za pośrednictwem wspólnego interfejsu.

23 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 23 Typy modułów l Abstrakcje danych. Są to abstrakcyjne typy danych utworzone przez kojarzenie danych z komponentami przetwarzającymi. l Moduły sprzętowe. Są bardzo podobne do abstrakcji danych. Gromadzi się w nich funkcje używane do sterowania konkretnym urządzeniem sprzętowym. l Moduły funkcyjne. Są to moduły, w których gromadzi się funkcje realizujące podobne lub ściśle powiązane zadania. l Moduły wspomagania procesu. Są to moduły, w których grupuje się wszystkie funkcje i specyficzne elementy danych niezbędne do pomocy przy realizacji konkretnego procesu gospodarczego.

24 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 24 Odtwarzanie abstrakcji danych l Aby zmniejszyć koszt modyfikacji współdzielonych obszarów danych, w procesie modularyzacji można skoncentrować się na identyfikacji abstrakcji danych. l Abstrakcje danych lub abstrakcyjne typy danych łączą razem dane i powiązane z nimi przetwarzanie; są odporne na zmiany. l Abstrakcje danych ukrywają reprezentację danych i oferują funkcje konstruktorowe i inspekcyjne, które służą do modyfikowania i odczytu danych. Dopóki interfejs nie ulega zmianie, dopóty zmiany typu danych nie powinny mieć wpływu na inne części programu.

25 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 25 Kroki wykonywane w celu przekształcenia współdzielonych, globalnych obszarów danych w obiekty lub abstrakcyjne typy danych l Przeanalizuj wspólne obszary danych w celu rozpoznania logicznych abstrakcji danych. Zwykle kilka abstrakcji jest połączonych w jeden współdzielony obszar danych. Należy je zidentyfikować i logicznie przebudować. l Utwórz abstrakcyjny typ danych lub obiekt dla każdej z tych abstrakcji. Jeśli język programowania nie ma udogodnień do ukrywania informacji, to zasymiluj abstrakcyjny typ danych przez zdefiniowanie funkcji do aktualizacji i odczytywania wszystkich pól danych. l Użyj systemu do przeglądania programów albo generatora wzajemnych odwołań w celu odszukania wszystkich użyć danych. Zastąp je wywołaniami odpowiednich funkcji.

26 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 26 Restrukturyzacja danych l W wielu wypadkach pojawiają się podobne kłopoty z ewolucja danych. l Przechowywanie, organizacja i format danych przetwarzanych przez programy odziedziczone mogą ewoluować odzwierciedlając zmiany oprogramowania. l Proces analizy i reorganizacji struktur danych, a czasem też wartości danych w systemie w celu zwiększenia ich zrozumiałości nosi nazwę restrukturyzacji danych.

27 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 27 Przyczyny konieczności modyfikacji danych l Degradacja danych. W miarę upływu czasu jakość danych maleje. Np. modyfikacje danych powodują ich błędy. l Naturalne ograniczenia wbudowane w program. W pierwotnych projektach wielu programów ich twórcy uwzględnili wbudowane ograniczenia ilości danych, które mogą być przetworzone. l Ewolucja architektoniczna. Gdy system scentralizowany jest przenoszony na architekturę rozproszoną, ważne jest, aby rdzeniem tej architektury był system zarządzania danymi dostępny dla odległych klientów.

28 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 28 Podejścia do restrukturyzacji danych PodejścieOpis CzyszczenieAnalizuje się rekordy danych i wartości w celu poprawienia ich danychjakości. Usuwa się duplikaty i nadmiarowe informacje. Wszystkim rekordom nadaje się spójny format. Te czynności zwykle nie wymagają zmiany programów, które korzystają z danych. RozszerzenieW tym wypadku restrukturyzacje się dane i związane z nimi danychprogramy, aby usunąć ograniczenia przetwarzania danych. Może to wymagać zmian w programach w celu zwiększenia długości pól, modyfikacji górnych granic tabel itd. Czasem same dane trzeba potem przepisać i oczyścić, aby odzwierciedlić zmiany programu. PrzeniesienieW tym wypadku dane przenosi się do nowoczesnego systemu danych zarządzania bazą danych. Dane mogły być przechowywane w oddzielnych plikach lub zarządzane przez starszy typ SZBD. Sytuacje pokazano na rysunku.

29 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 29 Kłopoty z danymi, które mogą się pojawić w systemach odziedziczonych l Kłopoty z nazewnictwem danych l Kłopoty z długością pól l Kłopoty z organizacją rekordów l Jawne literały w kodzie l Brak słownika danych

30 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 30 Przeniesienie danych z… Program 4 Program 5 Program 6 Program 7 Program 3 Program 2 Program 1 Plik 5Plik 4Plik 3Plik 2 Plik 6 Plik 1

31 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 31 Przeniesienie danych do … Program 2 Program 3 Program 4 Program 5 Program 6 Program 7 Program 1 System zarządzania Bazą danych Logiczny i fizyczny model danych Logiczny i fizyczny model danych

32 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 32 Niespójności wartości danych Niespójność danychOpis Niespójne wartościRóżne programy przypisują inne wartości domyślne tym samym logicznym elementom danych. domyślnePowoduje to kłopoty we wcześniejszych programach poza tym, który utworzył dane. Kłopoty są jeszcze poważniejsze, gdy brakującym wartościom przypisuje się wartości domyślne, które są dopuszczalne. Nie można wówczas wykryć brakujących danych. Niespójne jednostkiTa sama informacja jest reprezentowana w innych jednostkach w różnych programach. W USA i Wlk. Brytanii w starszych programach ciężar zapisuje się w funtach, ale w nowszych używa się już kilogramów. Poważny kłopot tego rodzaju pojawił się w Europie przy wprowadzaniu jednej europejskiej waluty. Systemy odziedziczone napisano tak, żeby radziły sobie z narodowymi waluta,mi. Dane trzeba więc przeliczyć na euro. Niespójne regułyRóżne programy stosują inne reguły zatwierdzania danych. Dane zapisane przez jeden program zatwierdzania mogą być odrzucane przez inny. Ta komplikacja dotyczy zwłaszcza danych archiwalnych, których nie aktualizowano zgodnie z modyfikacjami reguł zatwierdzania. Niespójne znaczenieW programach założono pewne znaczenie sposobu reprezentacji elementów danych. Niektóre reprezentacjiprogramy mogą uważać, że tekst zapisany wersalikami oznacza adres. Programy mogą stosować różne konwencje, czasem więc odrzucają dane poprawne znaczeniowo. Niespójności obsługiNiektóre programy odrzucają ujemne wartości bytów, które zawsze powinny być dodane. ujemnych danych Inne mogą jednak akceptować ujemne wartości lub nie rozpoznając ich jako ujemne, przekształcić w dodatnie.

33 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 33 Proces restrukturyzacji danych Zmodyfikowane dane Zmodyfikowane dane Modyfikacja nazw bytów Zastąpienie literałów Reorganizacja definicji danych Modyfikacja nazw bytów Zastąpienie literałów Reorganizacja definicji danych Zmień tabele z podsumowaniami Analiza danych Analiza danych Program do restrukturyzacji Zmiana formatu danych Przekształcenie wartości domyślnych Modyfikacja reguł zatwierdzania Zmiana formatu danych Przekształcenie wartości domyślnych Modyfikacja reguł zatwierdzania Analiza danych Analiza danych Konwersja danych Konwersja danych Etap 1 Etap 2 Etap 3

34 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 34 Główne tezy l Celem restrukturyzacji systemu jest poprawa struktury systemu i zwiększenie jego zrozumiałości. Koszty przyszłej pielęgnacji systemu powinny być więc mniejsze. l Proces restrukturyzacji obejmuje tłumaczenie kodu źródłowego, inżynierię wstecz, poprawę struktury programu, modularyzację programu i restrukturyzację danych. l Tłumaczenie kodu źródłowego jest automatyczną konwersją programu napisanego w jednym języku programowania na inny język. Może być nieuniknione, gdy oryginalny język programowania jest już przestarzały. l Inżynieria wstecz to proces wyprowadzania projektu i specyfikacji systemu z jego kodu źródłowego. W tym procesie mogą być pomocne narzędzia, np. przeglądarki programu.

35 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 28Slide 35 Główne tezy l Poprawa struktury programu polega na zastąpieniu niestrukturalnych konstrukcji sterujących, takich jak instrukcje skoku, pętlami while i instrukcjami warunkowymi. Można to zautomatyzować. l Modularyzacja programu polega na zreorganizowaniu kodu źródłowego programu tak, aby pogrupować powiązane byty. Zwiększa to zrozumiałość programu i ułatwia ich modyfikowanie. l Restrukturyzacja danych może być niezbędna ze względu na niespójności w zarządzaniu danymi w programach systemu odziedziczonego. Celem restrukturyzacji danych może być restrukturyzacja wszystkich programów tak, aby korzystały ze wspólnej bazy danych. l Koszt restrukturyzacji danych jest znacznie wyższy, jeśli istniejące dane trzeba przekształcić w jakiś nowy format.