Oparcie na komponentach

Tworząc komponenty należy starać się aby:

• realizować w nich funkcjonalność, która będzie opierać się próbie czasu (ponowne użycie oznacza użycie w pewnym przedziale czasu) – funkcjonalność odpowiadającą „stabilnym abstrakcjom z dziedziny zastosowań”
• uwzględnić w interfejsie wszelkie aspekty użycia komponentu (czyli w praktyce przewidzieć wszelkie możliwe sposoby korzystania z dostarczanej przez komponent funkcjonalności), a jednak nie skomplikować komponentu tak, by jego użycie stało się zbyt trudne
• uniezależnić stosowanie komponentu od zmienności sprzętu i oprogramowania systemowego
• umożliwić stosowanie w różnych sytuacjach poprzez dodatkowe konfigurowanie komponentu przed użyciem
• uczynić komponent maksymalnie samowystarczalnym (np. dołączyć stosowane biblioteki do komponentu)‏

Tworząc oprogramowanie oparte na komponentach należy zmodyfikować podstawowe czynności:

• w trakcie ustalania wymagań należy wyszukać komponenty nadające się do wykorzystania w systemie, przeprowadzić ich walidację i w przypadku zaakceptowania dostosować wymagania do zastosowanych komponentów
• podobnie w fazie projektowania uwzględnia się już wybrane komponenty, a także inne nie wpływające na wymagania, natomiast wykorzystywane w implementacji systemu
• w fazie implementacji należy uwzględnić odpowiednio zwiększone zasoby przeznaczone na integrację komponentów (dostosowanie do ich interfejsów)‏
• w każdej z faz należy uwzględnić ryzyko, że komponent okaże się jednak nieodpowiedni co będzie wymagało zmian – w implementacji, może architekturze, a może także w wymaganiach

W praktyce zastosowanie komponentów opiera się dodatkowo na istnieniu:

• standardów specyfikacji komponentów i wymiany informacji miedzy komponentami
• środowisk (platform) integracji komponentów (oprogramowania warstwy pośredniej – middleware) umożliwiających integrację komponentów i wymianę komunikatów między nimi

Przykładami środowisk (modeli) komponentowych są CORBA, Enterprise Java Beans – EJB, (D)COM(+)‏. Środowiska integracji komponentów często umożliwiają rozproszone funkcjonowanie systemów komponentowych. Rozwijaną w ostatnich latach alternatywą dla rozproszonych systemów komponentowych jest stosowanie WebServices, usług internetowych.

Kompozycja komponentów dokonywana jest zazwyczaj w ramach konkretnego modelu (środowiska) i staje się problemem głównie technicznym (zakładając, że dostarczone komponenty prawidłowo funkcjonują w ramach środowiska)‏. Środowisko może samo dostarczać dodatkowe funkcje związane z obsługą komponentów (zapewnienie bezpieczeństwa, współbieżności, obsługi transakcji itp.). Istotnym problemem przy kompozycji jest obsługa błędów i sytuacji wyjątkowych (częściowo wspierana przez model komponentowy) – trzeba pamiętać, że w praktyce w konkretnym systemie wykorzystywana jest tylko część funkcjonalności dostarczanej przez komponent.

Schemat tworzenia oprogramowania CORBA

Jak zwykle są i problemy, te same jak w przypadku ponownego użycia innych elementów oprogramowania, jak i jeden dodatkowy, a szczególnie istotny: zaufanie do komponentów, które specyfikowane przez swoje interfejsy są czarnymi skrzynkami, które mogą kryć w swym wnętrzu nieprzyjemne niespodzianki (niezgodność ze specyfikacją, niespełnianie wymagań niefunkcjonalnych, nie mówiąc o zawieraniu szpiegów i wirusów)‏. Dla popularyzacji komponentów istotnym elementem mogłoby stać się certyfikowanie przez cieszące się zaufaniem instytucje, gwarantujące poprawność, efektywność i bezpieczeństwo stosowania komponentów (nie jest to jednak proste do zrealizowania)‏