Temat: Wykorzystanie istniejących klas/bibliotek w procesie...
Na etapie analizy wymagań nie widzę możliwości korzystania z bibliotek.
A wymagania niefunkcjonalne? Że na przykład w naszym środowisku wykorzystujemy tylko bazy danych (stary MySQL) nie obsługujące transakcji i w związku z tym należy to uwzględnić przy projektowaniu systemu.
Na etapie projektowania raczej wzorce projektowe.
Zgoda. Wzroce projektowe, gotowe architektury czy nawet zaprojektowane w innym projekcie struktury danych --- to tez reusability.
Na etapie implementacji można myśleć o gotowych komponentach ale w kontekście czystej rentowności jako decyzja: albo gotowy cudzy komponent z dodatkowym czasem na jego rozpoznanie i ryzykiem "nieprzewidzianych zachowań" (należy go przetestować) czyli dodatkowe koszty i czas lub pisanie od zera albo własny moduł i koszt jego opracowania i implementacji.
Jeśli istniejący komponent jest dobrej jakości (np. często używany, polecany przez kogoś), to budowa własnego rozwiązania może oznaczać nie tylko dodatkowe koszty, ale wyważanie drzwi (czytaj popełnienie błędów), które ktoś już wyważył (przetestował komponent). Trudność decyzji będzie raczej wydaje mi się polegała na ocenie jakości komponentu.
Moim zdaniem wyższością wielu dedykowanych rozwiązań jest właśnie to, ze są dedykowane czyli program pod użytkownika a nie odwrotnie. Użycie gotowych komponentów niewiele się różni od gotowego parametryzowanego programu...
Ale ja nie mówię tu o tym, że użytkownik ma się dostosować do istniejącego oprogramowania. Ponowne użycie komponentów zakłada nie tylko ich znalezienie, ale i taką modyfikację, żeby spełniały wymagane warunki. Więc może to być trudniejsze od parametryzowania, zwłaszcza jeśli będzie uwzględniało zrozumienie jak czyjś program działa.
Poza tym wybór i sklejenie gotowych komponentów to też sztuka. W końcu taki był też jeden z celów języków wysokiego poziomu, tzn. obiektowych. Budowa z klocków.
Ale powyższe dotyczy obszaru dziedzinowego. Powtórne użytkowanie ma moim zdaniem duży sens w obszarze wymagań pozafunkcjonalnych takich jak bezpieczeństwo, wydajność, dostęp do sprzętu itp...
Hmm... A jeśli tym komponentem ma być jakiś komponent który rysuje wykresy? Albo usługa zdalna (Web serwis) która przysyła mi stan giełdy? To wszystko mogą być komponenty, które realizują wymagania funkcjonalne, związane z dziedziną aplikacji.
Na pewno komponenty, które są niezależne od dziedziny (MVC, bazy danych, drivery, biblioteki matematyczne etc.) mogą być bardziej powszechne w użyciu, bo nie tylko w obrębie aplikacji z danej dziedziny (np. finansowej).
Potwierdza to zresztą tekst z 1993: "Repository evaluation of software reuse" (myślę, że się nie przedawniło): "The success of a program of software reuse depends upon the degree of commonality among the applications across which software is shared. Prior research distinguishes between reuse across vertical and horizontal domains. *Vertical reuse* can occur when the majority of the applications built by software developers are representative of a single kind of data processing activity, and many software objects that are employed by one can be shared among the others. *Horizontal reuse*, by contrast, occurs across a broad range of application areas. Horizontal reuse is more often employed and better understood than vertical reuse."
ale powyższe co napisałem to ... frameworki i MVC - to takie moje subiektywne przemyślenia...
Dziękuję za komentarz :-) Temat rozjaśnia mi się dzięki rozmowie.
Pytanie czy w oficjalnej specyfikacji RUPa, albo jakiejś inne metodologii określone są kryteria, które elementy aplikacji realizować za pomocą istniejących rozwiązań, jakie przyjąć kryteria wyszukiwania zewnętrznego komponentu, jak znaleziene komponenty adaptować/integrować z resztą aplikacji?
Maciej Gawinecki edytował(a) ten post dnia 28.01.10 o godzinie 20:43
пропозиції роботи
