Uszkodzenie oprogramowania , zwany także erozja oprogramowanie jest brak równowagi między architekturą oprogramowania i wdrożenia . Termin „starzenie się oprogramowania” jest również używany w odniesieniu do błędów występujących w oprogramowaniu w czasie. Wydaje się, że niemożliwe jest zapobieganie temu starzeniu się, ale istnieją sposoby, aby go spowolnić, stąd zainteresowanie różnymi architekturami oprogramowania.
Architektura oprogramowania , aby opisać, w jaki sposób oprogramowanie muszą być tak zaprojektowane, aby spełnić wymagania z nim. Oprogramowanie realizacja musi pasować do modelu architektonicznego wytwarzane w fazie projektowania. W praktyce nie zawsze łatwo jest przestrzegać tej zasady. Źródła rozbieżności są wielorakie: rozwój oprogramowania, błędy wdrożeniowe, sprzeczności w planowanej architekturze, których nie można było przewidzieć przed opracowaniem itp. Można stawić czoła temu problemowi, stosując koncepcje inżynierii oprogramowania .
Aby zrozumieć znaczenie architektury , konieczne jest poznanie poszczególnych etapów realizacji projektu. Każdy projekt wynika z potrzeby. Aby zadowolić przyszłych użytkowników, przed opracowaniem rozwiązania konieczne jest zbadanie ich potrzeb. Dzięki temu możliwe będzie zdefiniowanie dostosowanej architektury oprogramowania w celu uzyskania wyniku zbliżonego do oczekiwanego. Dzięki dobrze zdefiniowanej architekturze wdrożenie rozwiązania będzie łatwiejsze i będzie lepiej odpowiadać oczekiwaniom klienta, jeśli nie będzie między nimi różnic.
Architektura oprogramowania pozwala na realizację programu w całości w formie teoretycznej przed realizując go w sposób praktyczny. Umożliwia to przewidywanie ograniczeń technicznych, uwzględnianie zmian w dostosowany sposób i zagwarantowanie jakości oprogramowania. W rezultacie koszty są niższe, a oprogramowanie jest znacznie lepszej jakości. Architektura oprogramowania odgrywa ważną rolę w następujących sześciu aspektach tworzenia oprogramowania:
Aby połączyć architekturę z wdrożeniem , konieczne jest zdefiniowanie zestawu reguł. Pozwoli to wykryć, kiedy implementacja odbiega od architektury.
Można wyróżnić dwa typy reguł: reguły strukturalne i reguły interakcji. Reguły strukturalne odnoszą się do istnienia tych samych jednostek i relacji między nimi, podczas gdy reguły interakcji dotyczą przede wszystkim obecności wywołań metod w tej samej kolejności.
W przypadku tego zestawu reguł podczas analizy istnieją trzy typy możliwych wyników:
Teraz wystarczy po kolei poradzić sobie z każdą rozbieżnością i nieobecnością. Najczęstszą praktyką jest modyfikowanie kodu w celu dopasowania do architektury. Istnieje jednak możliwość modyfikacji architektury projektu ze względu na trudności techniczne podczas opracowywania.
Głównymi przyczynami degradacji oprogramowania są modyfikacje dokonane w kodzie, dokumentacji pod kątem nieprzestrzegania zasad architektonicznych. Te zmiany są konieczne z następujących powodów.
Jedną z głównych przyczyn degradacji architektur jest ewolucja potrzeb klientów. Klient nie zawsze wie, czego się spodziewać, dopóki nie otrzyma pierwszej wersji produktu. Następnie próbuje wprowadzić zmiany w specyfikacji . Ten problem jest również widoczny, gdy specyfikacje nie są wystarczająco precyzyjne. Te dwa punkty definiują dwa główne typy starzenia się oprogramowania: awarie spowodowane zmianami dokonanymi przez właścicieli produktu w następstwie zmian w wymaganiach oraz wynik zmian dokonanych w wyniku nieporozumień obu stron (klienta / projektanta produktu). oprogramowanie) podczas projektowania i rozwoju produktu.
Inną przyczyną degradacji oprogramowania jest sprzęt, do którego jest ono podłączone. Architektury oprogramowania są projektowane z uwzględnieniem sprzętu, od którego zależy oprogramowanie. Z biegiem czasu sprzęt jest podatny na zmiany, co może spowodować niestabilność i zagrozić zamierzonej architekturze .
Zmiany wprowadzone w oprogramowaniu podczas jego życia powodują problem z alokacją pamięci. Rzeczywiście, im więcej jest zmian w kodzie, tym bardziej rośnie rozmiar programu, a im bardziej rozmiar programu rośnie, tym więcej pamięci żądanej od systemu jest konsekwentne. Trudno jest wstępnie zdefiniować pamięć do alokacji.
Aby poradzić sobie z degradacją oprogramowania, istnieje kilka rozwiązań, które spowalniają proces starzenia, ale także gwarantują jakość przy jednoczesnym zachowaniu równowagi między architekturą a wdrożeniem . Niektóre technologie (wymienione poniżej) umożliwiają radzenie sobie z degradacją. Istnieją jednak praktyczne elementy, które należy wprowadzić, aby utrzymać jakość oprogramowania.
Celem fazy projektowania jest stworzenie projektu zdolnego do przyjmowania wniosków o przyszłe zmiany.
Jest to sprzeczne z iteracyjnym charakterem wielu metod programowania (ekstremalne programowanie, szybkie prototypowanie itp.), Ponieważ te metodologie generalnie uwzględniają nowe wymagania, które mogą mieć wpływ na architekturę, podczas opracowywania, podczas gdy dobry projekt wymaga wcześniejszej znajomości tych wymagań.
Dlatego ważne jest, aby zaplanować architektury, które dostosowują się do zmian, ale także są zgodne z zastosowanymi metodologiami rozwoju. Dlatego wydaje się, że można mówić o zwinnych architekturach do zwinnych opracowań i zastosować je, aby lepiej zagwarantować żywotność oprogramowania.
Kiedy trzeba wprowadzić zmiany w oprogramowaniu, wydaje się, że łatwiej (taniej) jest zastosować te zmiany w kodzie. Aby móc opóźnić starzenie, konieczne jest utrzymanie architektury i dokumentacji. Rzeczywiście, przy każdej zmianie w kodzie należy zagwarantować, że zasady architektury są przestrzegane, a dokumentacja aktualizowana. Pozwala to uniknąć opóźnień, które mogą powstać między implementacją a architekturą oprogramowania.
Dobra konserwacja oprogramowania może wydłużyć jego żywotność. Procesy utrzymania są generalnie oparte na iteracyjnym doskonaleniu lub na modelu pełnego ponownego wykorzystania. Ponowne użycie oszczędza czas, zmniejsza koszty, ale może być niebezpieczne. Dlatego ważne jest, aby:
Podczas konserwacji ważne jest przestrzeganie zasad architektonicznych, zwłaszcza podczas integracji nowych komponentów.
Poniżej znajdują się praktyczne elementy zapewniające równowagę między architekturą oprogramowania a jego implementacją .
Karta została opracowana przez Claire Dimech i Dharini Balasubramaniam z School of Computer Science na University of St Andrews.
Karta jest narzędziem do sprawdzania zgodności architektury i implementacji , jest zintegrowana jako wtyczka w Eclipse . Weryfikacja odbywa się statycznie między opisem architektury w UML a jej implementacją w Javie . Ta struktura zawiera dwa moduły przetwarzania wstępnego: jeden dla diagramów UML 2.0, a drugi dla kodu źródłowego Java. Karta jest odpowiedzialna za znalezienie plików UML i Java w strukturze drzewa projektu Eclipse, a następnie wykorzystuje jej preprocesory do wyodrębnienia właściwości architektonicznych. Właściwości te są przechowywane w strukturach danych odpowiednich do przeprowadzania analizy zgodności.
Karta oparta jest na koncepcji „Master Slave”, architekturze preskryptywnej (Master) i architekturze opisowej (Slave), do której odnoszą się zasady. Karta pozwala na zdefiniowane przez użytkownika ustawienia na trzech poziomach wymagań (wysoki, średni, niski), sprawdza struktury danych i wyświetla naruszenia wysyłając je z powrotem do slave'a. Programiści mogą sprawdzić zgodność swojego kodu z modelem w trybie statycznym (offline) lub dynamicznie (mogą to wybrać w preferencjach).
Karta została przetestowana w wielu projektach i nigdy nie ujawniła żadnych fałszywych naruszeń ani przeoczeń. Nie ma jednak żadnych formalnych dowodów.
SAVE został opracowany wspólnie przez Fraunhofer IESE (Instytut Eksperymentalnej Inżynierii Oprogramowania) w Kaiserslautern w Niemczech i Fraunhofer Center Maryland (Centrum Eksperymentalnej Inżynierii Oprogramowania) w Maryland w USA.
SAVE to narzędzie programistyczne, które w sposób schematyczny pokazuje zbieżności i rozbieżności między dwoma elementami projektu. To narzędzie jest dostępne jako wtyczka Eclipse i dlatego jest z nim w pełni zintegrowane. Może być używany w projektach opracowanych w Javie , C / C ++ i Delphi.
Wersja statyczna została przetestowana w firmie TESTO przez okres trzech lat w celu opracowania kilkunastu produktów, a badanie przedstawia rozstrzygające wyniki.
Istnieje również wtyczka (LiFe) do przeprowadzania weryfikacji podczas pisania kodu aplikacji. Ta wtyczka została również przetestowana w promocji studenckiej, w której niektóre grupy miały wtyczkę SAVE Life, a reszta nie miała narzędzia do weryfikacji. Z badania wynika, że po kilku tygodniach grupy studentów, którzy tworzyli wtyczkę, popełniły znacznie mniej błędów implementacyjnych . Ostatecznie projekt był bliższy oczekiwanego rezultatu niż w przypadku innych grup.
ArchJava to jedno z pierwszych rozwiązań opracowanych w celu kontrolowania spójności między architekturą a wdrożeniem . Rozwiązanie to zostało wprowadzone w 2002 roku w Stanach Zjednoczonych.
ArchJava jest rozszerzonym językiem Java umożliwiającym ustalenie ograniczeń architektonicznych podczas implementacji. Te ograniczenia są wyraźnie określone w kodzie przez dodanie jednostek o nazwie port w klasach. Te porty służą do definiowania, które obiekty mogą się ze sobą komunikować i jakie metody są autoryzowane na tym porcie.
Przeprowadzono badanie w celu zweryfikowania następujących punktów:
Wszystkie punkty zostały pomyślnie zweryfikowane, a zrozumienie kodu testowanego projektu znacznie się poprawiło, ponieważ komunikacja została uproszczona.