Rozpoczynając budowę systemu informatycznego pierwszym krokiem stanowiącym podstawę dalszych działań jest próba zrozumienia strony klienta, co do zakresu funkcjonalności, jaką ma oferować system. Klient ma pewne wyobrażenie, co do sposobu funkcjonowania systemu (ang. mental model), a naszym zadaniem jest zrozumienie, często niejasnych życzeń klienta. W tym celu tworzony jest model wymagań (ang. requirements model). W zależności od wielkości przedsięwzięcia, aby model taki zbudować, niekiedy wystarczy krótka pogawędka, ale często konieczne jest wielomiesięczne studium wykonalności. Zawsze jednak dążymy do zrozumienia zachowania systemu wykorzystując przypadki użycia i scenariusze przypadków użycia.

Read the rest of this entry »

Nie jestem fanem technologii EJB. Każdy, kto musiał przejść proces uczenia się EJB doskonale wie, dlaczego ciężko jest być fanem EJB. A ja jestem do tego stopnia leniwy, że wolę korzystać z mniej pracochłonnych kontenerów IoC.

Przyszedł jednak czas, aby sprawdzić co słychać w najnowszej wersji specyfikacji EJB 3.0, oraz może co najważniejsze, czy aby da się wykorzystać SpringFramework do uproszczenia implementacji komponentów EJB tak jak było to możliwe z EJB 2.0/2.1.

Read the rest of this entry »

Pracując od kilku lat przy budowie różnego rodzaju systemów informatycznych, przyszedł czas, aby zadać sobie zasadnicze pytanie. Mianowicie, co ma wspólnego zagadnienie modelowania z wytwarzania oprogramowania? Kluczem jest tu zrozumienie słowa modelowanie. Czym więc jest model? Po co budowane są modele? Na czym polega proces modelowanie? W końcu jak się ma do tego wszystkiego notacja UML?

Read the rest of this entry »

Mock Objects są to tak zwane obiekty imitujące, używane zazwyczaj w procesie testowania aplikacji jako lekkie i przenośne obiekty zastępujące działanie ich ciężkich odpowiedników produkcyjnych. W mowie potocznej Mock Objects tłumaczymy jako zaślepki, i tego tłumaczenia będę używał najczęściej, ponieważ najlepiej oddaje ono istotę rzeczy. W tym artykule chcę omówić koncepcję testowania kodu przy pomocy przy użyciu zaślepek programowalnych: generowanych dynamicznie na podstawie definicji zaślepianego interfejsu. Na początku, chcę pokazać, czemu umiejętność korzystania z tego typu rozwiązań jest, moim zdaniem, obowiązkowym narzędziem w arsenale dobrego programisty, a później omówić szczegóły techniczne wybranej implementacji. Moim normalnym środowiskiem pracy jest Java, dlatego odwołania do praktyk popieram przykładami właściwymi dla tego środowiska. Do szczegółowych analiz kodu wybrałem język Java w wersji JDK 5.0, biblioteki JUnit 4.0 oraz EasyMock 2.2.

Read the rest of this entry »