©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 1 Projektowanie z użyciem wielokrotnym l Jak w procesie projektowania systemu można ponownie wykorzystać istniejące oprogramowanie.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 2 Cele l Znać korzyści wynikające z użycia wielokrotnego komponentów programowych oraz związane z nim kłopoty, które możesz napotkać; l Znać różne rozdaje komponentów, które można użyć wielokrotnie, oraz procesy projektowania z użyciem wielokrotnym; l Rozumieć pojęcie rodziny programów użytkowych i wiedzieć, dlaczego takie rodziny są efektywnym sposobem użycia wielokrotnego oprogramowania; l Wiedzieć, dlaczego wzorce są abstrakcjami wysokiego poziomu, które sprzyjają użyciu wielokrotnemu projektów w tworzeniu obiektowym.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 3 Zawartość l Tworzenie komponentowe l Rodziny programów użytkowych l Wzorce projektowe

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 4 l W większości dyscyplin inżynieryjnych proces projektowania jest oparty na użyciu wielokrotnym komponentów. l Podstawą projektów są komponenty, które wypróbowano i przetestowano w innych systemach. l Obecnie powszechnie uważa się, że w wypadku tworzenia oprogramowania potrzebne jest podobne podejście. Oprogramowanie powinno być uważane za składnik majątku. Użycie wielokrotne tego składnika majątku jest zasadniczym warunkiem zwiększenia stopy zwrotu z inwestycji w jego tworzenie.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 5 Używane wielokrotnie elementy oprogramowania l Użycie wielokrotne systemów programów użytkowych. Można ponownie użyć cały system programów użytkowych przez włączenie go w niezmienionej postaci do innych systemów albo budowę rodziny programów użytkowych działających na różnych platformach lub dostosowanych do potrzeb konkretnych użytkowników. l Użycie wielokrotne komponentów. Można wielokrotnie używać komponentów programu użytkowego mających różne rozmiary, od podsystemów do pojedynczych obiektów. l Użycie wielokrotne funkcji. Można wielokrotnie użyć komponenty programowe, takie jak pojedyncze funkcje matematyczne.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 6 Praktyka l Użycie wielokrotne systemów programów użytkowych praktykuje się już od wielu lat – firmy budujące oprogramowanie implementują swoje systemy na wielu maszynach i dostosowują je do rozmaitych środowisk. l Użycie wielokrotne funkcji również jest uznane i występuje w postaci standardowych bibliotek funkcji użycia wielokrotnego, takich jak biblioteki matematyczne i graficzne.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 7 Zalety użycia wielokrotnego l Zwiększona niezawodność l Zmniejszone zagrożenie procesu l Efektywne wykorzystanie specjalistów l Zgodność ze standardami l Przyspieszone tworzenie

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 8 Wymagania stawiane projektowaniu i budowaniu oprogramowania z użyciem wielokrotnym l Musi istnieć możliwość znalezienia odpowiedniego komponentu użycia wielokrotnego. l Osoba ponownie używająca komponent musi być przekonana, że będzie on działał zgodnie ze specyfikacją i będzie niezawodny. l Komponenty muszą mieć dokumentację, która pomoże osobie pragnącej je wykorzystać w zrozumieniu ich i zaadaptowaniu do nowych zastosowań.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 9 Koszty i kłopoty l Zwiększone koszty pielęgnacji l Brak wspomagania narzędziowego l Syndrom „nie wymyślono tutaj” l Prowadzenie biblioteki komponentów l Znajdowanie i adaptowanie komponentów użycia wielokrotnego

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 10 Generowanie l Polega ono na umieszczaniu wielokrotnie używanej wiedzy w systemie generowania programów, który może posługiwać się językiem specyficznym dla dziedziny zastosowania. l W opisie programu użytkowego w abstrakcyjny sposób określa się, które komponenty użycia wielokrotnego maja być wykorzystane, jak maja być połączone i jakie maja mieć parametry. l Na podstawie tej informacji można wygenerować działający system oprogramowania.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 11 Typy generatorów programów l Generatory programów użytkowych do przetwarzania danych gospodarczych. l Generatory analizatorów składniowych do przetwarzania języków. l Generatory kodu w narzędziach CASE.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 12 Użycie wielokrotne oparte na generatorze Generator programów Wygenerowany program Wiedza o dziedzinie zastosowania Wiedza o dziedzinie zastosowania Baza danych Opis programu użytkowego

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 13 Tworzenie komponentowe l Tworzenie komponentowe albo komponentowa inżynieria oprogramowania pojawiła się we wczesnych latach dziewięćdziesiątych XX wieku w postaci podejścia do budowania systemów oprogramowania z użyciem wielokrotnym. l Przyczyną jej powstania był zawód, że tworzenie obiektowe nie doprowadziło do szerokiego stosowania użycia wielokrotnego, jak się wcześniej spodziewano. l Poszczególne klasy obiektów były zbyt szczegółowe i specyficzne. l Musiały być dowiązane do programu użytkowego w czasie kompilacji lub konsolidacji systemu. l Do ich wykorzystania była potrzebna szczegółowa wiedza, co zwykle oznaczało konieczność udostępnienia kodu źródłowego. l Powodowało to trudne problemy ze sprzedażą komponentów na rynku. l Wbrew wczesnym optymistycznym przewidywaniom nigdy nie powstał znaczący rynek pojedynczych obiektów.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 14 Komponenty l Postrzeganie komponentu jako dostawcy usług dotyczy dwóch istotnych charakterystyk komponentu użycia wielokrotnego: Komponent jest niezależnym wykonywalnym bytem. Kod źródłowy nie jest dostępny, a zatem komponentu nie kompiluje się z innymi komponentami systemu. Komponenty publikują swój interfejs. Wszystkie interakcje odbywają się przez ten interfejs. Interfejs komponentu jest zapisywany w kategoriach parametryzowanych operacji. Jego wewnętrzny stan nigdy nie jest ujawniany.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 15 Interfejsy komponentu Komponent Interfejs wymagany Interfejs oferowany

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 16 Interfejsy komponentów l Interfejs oferowany Definiuje się usługi oferowane przez ten komponent. l Interfejs wymagany Określa się, jakie usługi muszą być dostępne w systemie używającym tego komponentu. Jeśli nie są one oferowane, to komponent nie będzie działał.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 17 Komponent usług drukarskich Komponent usług drukarskich PodajPlikOpisu Interfejsdrukarki Drukuj PodajStanKolejki Usuń Przekaż Rejestruj Wyrejestruj Interfejs wymagany Interfejs oferowany

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 18 Poziomy abstrakcji komponentów l Abstrakcja funkcyjna. Komponent jest implementacją jednej funkcji, np. matematycznej. l Przypadkowe grupowanie. Komponent jest grupą luźno powiązanych bytów. l Abstrakcja danych Komponent jest abstrakcją danych lub klasą obiektowego języka programowania. l Abstrakcja grupowa. Komponent jest grupą powiązanych klas, które działają razem. l Abstrakcja systemowa. Komponent jest całym samodzielnym systemem.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 19 Tworzenie komponentowe l Tworzenie komponentowe można zintegrować z procesem budowania systemu przez dodanie specyficznych czynności związanych z użyciem wielokrotnym. l Projektant systemu buduje projekt na wysokim poziomie abstrakcji i specyfikuje jego komponenty. l Te specyfikacje służą do poszukiwania komponentów użycia wielokrotnego. l Czynność tę można dodać na poziomie architektonicznym lub na poziomie bardziej szczegółowym.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 20 Proces przypadkowego ponownego użycia komponentów Wyspecyfikuj komponenty Wyspecyfikuj komponenty Zaprojektuj architekturę systemu Zaprojektuj architekturę systemu Poszukaj komponentów użycia wielokrotnego Poszukaj komponentów użycia wielokrotnego Przyłącz znalezione komponenty Przyłącz znalezione komponenty

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 21 Tworzenie z wielokrotnym użyciem Projektowanie architektoniczne Projektowanie architektoniczne Poszukaj komponentów użycia wielokrotnego Poszukaj komponentów użycia wielokrotnego Zaprojektuj system korzystając z komponentów użycia wielokrotnego Zaprojektuj system korzystając z komponentów użycia wielokrotnego Naszkicuj wymagania systemowe Naszkicuj wymagania systemowe Poszukaj komponentów użycia wielokrotnego Poszukaj komponentów użycia wielokrotnego Na podstawie wyników poszukiwań zmień wymagania Na podstawie wyników poszukiwań zmień wymagania

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 22 Trudności przy tworzeniu komponentowym l Kwestia pielęgnacji i ewolucji. Kod źródłowy komponentów jest zwykle dostępny. W takiej sytuacji, gdy program użytkowy wymaga modyfikacji, nie ma możliwości zmiany komponentu mającej na celu odzwierciedlenie tych wymagań. l W tej fazie zmiana wymagań tak, by pasowały do istniejących komponentów, nie jest zwykle możliwa, gdyż program użytkowy już jest wykorzystywany. l Trzeba więc dodatkowej pracy nad ponownym użyciem komponentów i w miarę upływu czasu powoduje to zwiększenie kosztów pielęgnacji. l Tworzenie komponentowe umożliwia jednak szybsze dostarczanie oprogramowania, firmy mogą więc zaakceptować te wyższe koszty w odległej przyszłości.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 23 Zręby programów użytkowych l Zręby (lub zręby programów użytkowych) są projektami podsystemów składających się z kolekcji klas abstrakcyjnych i klas konkretnych oraz interfejsu między nimi. l Poszczególne części systemu programów użytkowych implementuje się przez dodanie komponentów i opracowanie konkretnych implementacji klas abstrakcyjnych zrębu. l Zręby rzadko są programami użytkowymi.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 24 Klasy zrębów l Zręby infrastruktury systemów. Wspomagają tworzenie infrastruktury systemów, takiej jak komunikacja, interfejsy użytkownika i kompilatory. l Zręby integracji śródprogramów. Składają się ze zbioru standardów i związanych z nimi klas obiektów, które wspomagają komunikację komponentów i wymianę informacji. l Zręby zastosowań przemysłowych. Dotyczą specyficznych dziedzin zastosowań, takich jak telekomunikacja lub finanse.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 25 Rozszerzanie zrębów l Rozszerzenie zrębu może polegać na dodaniu konkretnych klas, które dziedziczą operacje po klasach abstrakcyjnych zrębu. l Dodatkowo można zdefiniować funkcje wywołane zwrotnie. l Są to metody, które wywołuje się w odpowiedzi na zdarzenia rozpoznane przez zrąb.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 26 Zrąb Model-Widok-Koordynator l Po raz pierwszy przedstawiono go w latach osiemdziesiątych XX wieku jako podejście do projektowania GUI, który obejmuje wiele przedstawień obiektów i różne style interakcji z każdym z tych przedstawień. l Zrąb MVC pomaga w prezentacji danych na różne sposoby i odrębne oddziaływanie z każdą z nich. l Gdy dane są modyfikowane przez jedna prezentację, wszystkie inne są aktualizowane.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 27 Zrąb Model-Widok-Koordynator Stan widoku Metody widoku Stan modelu Metody modelu Stan koordynatora Metody koordynatora Zapytania i aktualizacje modelu Modyfikacje modelu Komunikaty o modyfikacji widoku

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 28 Użycie wielokrotne produktów COTS l Podejście produktów COTS (Commercial-Off- The-Shelf – komercyjne z półki) może być zastosowane do każdego komponentu oferowanego przez zewnętrznego dostawcę. l Zwykle używa się go jednak tylko w wypadku produktów będących systemami oprogramowania. l Od wielu lat wielokrotnie używano niektórych rodzajów systemów COTS. Systemy baz danych są chyba najlepszym tego przykładem.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 29 Problemy z integracją systemów COTS l Brak kontroli nad sterowaniem i efektywnością. l Chociaż z opublikowanych interfejsów produktu może wynikać, że ma on wymagane udogodnienia, mogą być one niewłaściwie zaimplementowane lub mogą działać wolno. l Kłopoty ze współdziałaniem systemów COTS. l Skłonienie produktów COTS do współpracy jest czasem trudne, ponieważ każdy z nich przyjmuje inne założenia o tym, jak należy go używać. l Brak panowania nad ewolucją systemu. l Dostawcy produktów COTS podejmują własne decyzje o zmianach systemu w odpowiedzi na żądania rynku. l Wspomaganie przez dostawców COTS. l Zakres wspomagania oferowany przez dostawców COTS może być rozmaity. Są to systemy z półki, więc wspomaganie dostawcy jest szczególnie ważne, gdy pojawiają się kłopoty, ponieważ programiści nie mają dostępu do kodu źródłowego i szczegółowej dokumentacji systemu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 30 Tworzenie komponentów użycia wielokrotnego l Komponenty użycia wielokrotnego sa specjalnie budowane z istniejących komponentów, które ponownie wykorzystano w przypadkowy sposób. l Różne cechy komponentu świadczą o jego zdatności do użycia wielokrotnego: komponent powinien odzwierciedlać stabilną abstrakcję dziedzinową komponent musi ukrywać sposób reprezentacji swoich danych i oferować operacje umożliwiające odczyt i aktualizację jego stanu komponent powinien być tak niezależny, jak to tylko jest możliwe wszystkie wyjątki powinny być częścią interfejsu komponentu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 31 Problemy l W wielu obecnie dostępnych systemach istnieją duże fragmenty kodu, które implementują abstrakcje dziedzinowe, ale nie mogą być wykorzystane jako komponenty. l Przyczyna leży w tym, że nie opakowano ich zgodnie z modelem z jasno określonymi interfejsami wymaganym i oferowanym. l Uczynienie z nich komponentów użycia wielokrotnego zwykle wymaga zbudowania osłony. l Osłona ukrywa złożoność schowanego kodu i oferuje zewnętrzne usługi.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 32 Uzdatnianie komponentów l Między zdatnością do użycia wielokrotnego a użytecznością komponentu występuje nieuchronny konflikt. l Uzdatnienie komponentu do użycia wielokrotnego pociąga za sobą zaoferowanie bardzo ogólnego interfejsu z operacjami obsługującymi rozmaite sposoby użycia tego komponentu. l Budowa użytecznego komponentu obejmuje zaoferowanie prostego, minimalnego interfejsu, który jest łatwy do zrozumienia. l Zdatność do użycia wielokrotnego zwiększa złożoność, a zatem zmniejsza zrozumiałość komponentu. l Inżynierom jest więc trudno zdecydować, kiedy i jak wielokrotnie używać komponentu. l Projektanci komponentów użycia wielokrotnego muszą zatem wypracować kompromis między ogólnością a zrozumiałością.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 33 Reusability enhancement process

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 34 Rodziny programów użytkowych l Rodzina programów użytkowych albo linia produktów jest zbiorem powiązanych programów użytkowych, które mają wspólną architekturę charakterystyczną dla dziedziny. l Poszczególne programy użytkowe są jednak na swój sposób wyspecjalizowane. l Wspólny rdzeń rodziny programów użytkowych jest za każdym razem ponownie używany, gdy jest potrzebny nowy program użytkowy. l Tworzenie nowego programu może polegać na napisaniu dodatkowych komponentów i adaptacji niektórych komponentów programu użytkowego tak, aby sprostać nowym oczekiwaniom.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 35 Rodzaje specjalizacji rodziny programów użytkowych l Specjalizacja platformowa. Polega na opracowaniu innych wersji programu użytkowego na różne platformy. Różne wersje programu mogą działać na przykład na platformy Windows NT, Solaris i Linux. l Specjalizacja konfiguracyjna. Polega na opracowaniu innych wersji programu użytkowego do obsługi różnych urządzeń zewnętrznych. l Specjalizacja funkcjonalna. Polega na opracowaniu innych wersji programu użytkowego dla klientów z różnymi wymaganiami.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 36 Uniwersalny system inwentaryzacji zasobów User a ccess Prgaccess Baza danych o zasobach Dostęp użytkownika UsuwanieDodawanie Dostęp programowy Specyfikacje raportówSpecyfikacje ekranówOpisy zasobów RaportyAdministracjaPrzeglądaniePoszukiwanie

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 37 Systemy inwentaryzacyjne l Takie systemy muszą oferować podstawowe udogodnienia, takie jak dodawanie zasobu do spisu, usunięcie zasobu ze spisu, przeglądanie i wyszukiwanie w spisie oraz tworzenie raportów. l Można więc tak zaprojektować architekturę systemy inwentaryzacyjnego, aby stał się rodziną programów użytkowych, której każdy członek służy do obsługi innych rodzajów zasobów.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 38 Architektura l Osiągnięcie znaczącej zdatności do użycia wielokrotnego wymaga zaprojektowania architektury, w której zasadnicze udogodnienia systemowe będą oddzielone od szczegółowej informacji o zasobach, które mają być inwentaryzowane i od dostępu użytkownika do tych informacji. l Architektura może spełniać te wymagania dzięki zastosowaniu architektury warstwowej, w której warstwa szczegółów zawiera opisy zasobów, wyświetlane ekrany i tworzone raporty. l Wyższe warstwy systemu korzystają z tych opisów i nie obejmują wpisanej na sztywno informacji o zasobach. Różne systemy inwentaryzacyjne powstają przez modyfikację tej warstwy opisowej.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 39 System biblioteczny Baza danych o zasobach Dostęp użytkownika do biblioteki PrzeglądaniePoszukiwanieUsuwanie DodawanieWypożyczenieRaporty AdministracjaZwrot Użytkownicy Specyfikacje raportówSpecyfikacje ekranówOpisy zasobów

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 40 System biblioteczny l Można również dodawać do systemu nową funkcjonalność przez wprowadzanie nowych modułów do warstw systemu. l Dodano nowe udogodnienia do pożyczania i zwracania zasobów oraz do umożliwiania rejestracji użytkowników systemu. l W tym wypadku nie jest potrzebny dostęp programowy, a najwyższa warstwa systemu musi obsługiwać jedynie dostęp do użytkownika.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 41 Tworzenie członka rodziny Wydobądź wymagania uczestników Wydobądź wymagania uczestników Wybierz najbardziej odpowiedniego członka rodziny Wybierz najbardziej odpowiedniego członka rodziny Zaadaptuj istniejący system Zaadaptuj istniejący system Dostarcz nowego członka rodziny Dostarcz nowego członka rodziny Renegocjuj wymagania

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 42 Tworzenie członka rodziny l Określ wymagania uczestników l Wybierz najbardziej odpowiedniego członka rodziny l Renegocjuj wymagania l Zaadoptuj istniejący system l Dostarcz nowego członka rodziny

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 43 Wzorce projektowe l Starając się ponownie użyć komponent wykonywalny, nie uchronimy się przed ograniczeniami wynikającymi ze szczegółowych decyzji projektowych, podjętych przez osoby implementujące ten komponent. l Jeśli te decyzje projektowe nie są zgodne z przyjętymi przez nas szczegółowymi wymaganiami, to ponowne użycie komponentu jest niemożliwe albo prowadzi do istotnego zmniejszenia efektywności systemu. l Jednym ze sposobów radzenia sobie z ta kwestią jest użycie wielokrotne bardziej abstrakcyjnych projektów, które nie obejmują szczegółów implementacyjnych. l Obecnie to podejście do użycia wielokrotnego przybrało postać wzorców projektowych.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 44 Elementy wzorca projektowego l Nazwa Spełniająca funkcję znaczącego odsyłacza do wzorca. l Opis rodzaju problemu, w którym opisuje się części rozwiązania projektowego, ich związki i zobowiązania. l Wyjaśnienie konsekwencji zastosowania wzorca, tzn. wyników końcowych i niezbędnych kompromisów.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 45 Wiele widoków A B C D A B C D Obserwator 1 Obserwator 2 Przedmiot A : 40 B : 25 C : 15 D : 20 Przedmiot A : 40 B : 25 C : 15 D : 20

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 46 Przykład wzorca Obserwator l Nazwa. Oddziela wyświetlanie stanu obiektu od samego obiektu. l Opis problemu. W wielu przypadkach należy udostępnić wiele prezentacji pewnej informacji o stanie, np. prezentacji tabelarycznej i graficznej. l Opis rozwiązania. Strukturę wzorca pokazano na rysunku. Są tam dwa obiekty abstrakcyjne: Przedmiot i Obserwator oraz dwa obiekty konkretne: PrzedmiotKonkretny i ObserwatorKonkretny, które dziedziczą atrybuty swoich obiektów abstrakcyjnych. l Konsekwencje. Przedmiot zna jedynie abstrakcyjnego Obserwatora, ale nie zna szczegółów klasy konkretnej. Wzajemne uzależnienie tych obiektów jest więc minimalne.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 47 Wzorzec Obserwator Przedmiot Podłącz (Obserwator) Odłącz (Obserwator) Informuj () Obserwator Aktualizuj () for all o in obserwatorzy o -> Aktualizuj () for all o in obserwatorzy o -> Aktualizuj () stanObserwatora= przedmiot -> PodajStan () ObserwatorKonkretny Aktualizuj () stanObserwatora Przedmiot konkretny PodajStan () stanPrzedmiotu

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 48 l Projektowanie z użyciem wielokrotnym polega na projektowaniu oprogramowania zgodnie z istniejącymi przykładami dobrych projektów i wykorzystaniu komponentów programowych tam, gdzie są potrzebne. l Korzyści z użycia wielokrotnego to niższe koszty, szybsze tworzenie oprogramowania i mniej zagrożeń. Przez wykorzystanie wiedzy specjalistów do budowania komponentów użycia zwiększa się niezawodność systemu, a specjaliści są wydajniejsi. l Tworząc komponentowo, polegamy na komponentach „czarnych skrzynkach” z jasno określonymi interfejsami wymaganym i oferowanym. Rodzaje komponentów, które można użyć wielokrotnie, obejmują funkcje, abstrakcje danych, zręby i całe systemy programów użytkowych. l Użycie wielokrotne produktów COTS polega na wykorzystaniu wielkich systemów z półki. Takie systemy maja mnóstwo funkcjonalności. Ich użycie wielokrotnie może znacząco zmniejszyć koszty i czas tworzenia. Główne tezy

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 14Slide 49 Główne tezy l Komponenty programowe, które zaprojektowano z myślą o użyciu wielokrotnym, powinny być niezależne, odzwierciedlać stabilne abstrakcje dziedzinowe i oferować dostęp do swego stanu przez operacje interfejsu oraz nie obsługiwać samemu swoich wyjątków. l Rodziny programów użytkowych zawierają powiązane programy użytkowe, które zbudowano na podstawie co najmniej jednego programu bazowego. Uniwersalny system jest adoptowany i specjalizowany tak, aby spełnił konkretne wymagania dotyczące funkcjonalności, docelowej platformy lub konfiguracji działania. l Wzorce projektowe to abstrakcje wysokiego poziomu, będące dokumentacją udanych rozwiązań projektowych. Są podstawowym sposobem użycia wielokrotnego projektów w tworzeniu obiektowym. Opis wzorca powinien obejmować nazwę wzorca, opis problemu i rozwiązania oraz wyjaśnienie wyników i kompromisów związanych ze stosowaniem wzorca.