Zgodność logiki biznesowej

Zgodność logiki biznesowej wymaga, by reguły aplikacji odpowiadały rzeczywistej strukturze i regułom danych.

Logika biznesowa jako warstwa reguł aplikacji

Zgodność logiki biznesowej oznacza, że aplikacja wykonuje operacje zgodnie z rzeczywistymi zasadami opisującymi dane, proces i zależności między obiektami. Reguły te określają między innymi, jakie wartości są dopuszczalne, kiedy można zmienić status sprawy, które rekordy mogą zostać ze sobą połączone oraz jakie warunki muszą być spełnione przed zapisaniem wyniku. Sama poprawność składni programu nie wystarcza, jeżeli kod pozwala wykonać operację sprzeczną z modelem danych albo z przebiegiem procesu.

Przykładem może być system obsługi naprawy laptopów. Zlecenie może mieć status „przyjęte”, „w diagnostyce”, „oczekuje na akceptację kosztów”, „w naprawie”, „gotowe do odbioru” albo „zamknięte”. Zgodna logika nie powinna pozwalać oznaczyć urządzenia jako gotowego do odbioru, jeżeli nie zapisano wyniku naprawy, nie zakończono wymaganych czynności albo nie istnieje informacja o rozliczeniu. Reguła powinna być stosowana w każdym miejscu, z którego można zmienić zlecenie: w formularzu, interfejsie API, zadaniu automatycznym i skrypcie administracyjnym.

Powiązanie reguł programu ze strukturą danych

Spójność przepływu danych wymaga dopasowania kodu do rzeczywistego schematu bazy. Jeżeli kolumna przechowuje identyfikator klienta jako klucz obcy, aplikacja nie powinna traktować jej jak dowolnego tekstu ani umożliwiać zapisania wartości wskazującej na nieistniejący rekord. Jeżeli tabela rozdziela urządzenie, zlecenie i pozycje kosztorysu, logika programu powinna zachować te zależności zamiast kopiować te same informacje w kilku niezależnych polach. W przeciwnym razie zmiana numeru seryjnego, ceny lub statusu może zostać zapisana tylko w części systemu.

Ważną rolę odgrywają ograniczenia integralności danych, takie jak klucze główne, klucze obce, ograniczenia unikalności, wartości wymagane oraz warunki zakresu. Walidacja w interfejsie użytkownika poprawia obsługę formularza, ale nie zastępuje kontroli po stronie serwera i bazy danych. Przykładowo pole ceny może być sprawdzane w przeglądarce, lecz serwer powinien ponownie zweryfikować typ, zakres i uprawnienie do zmiany kwoty. Operacja obejmująca kilka powiązanych zapisów powinna korzystać z transakcji, aby nie pozostawić zlecenia utworzonego bez pozycji kosztorysu albo płatności przypisanej do nieistniejącego dokumentu.

Stany, przejścia i skutki uboczne operacji

Najczęstsze rozbieżności pojawiają się wtedy, gdy program dopuszcza przejścia między stanami bez sprawdzenia poprzedniego stanu. Status „zamknięte” powinien być osiągalny tylko z określonych stanów, a cofnięcie zamkniętego zlecenia powinno być świadomą operacją z jasno zdefiniowanym skutkiem. Warto opisać dozwolone przejścia w jednym miejscu, zamiast powielać warunki w wielu kontrolerach i formularzach. Dzięki temu łatwiej wykryć sytuację, w której ekran blokuje zmianę statusu, ale bezpośrednie żądanie HTTP nadal ją akceptuje.

Zmiana danych może uruchamiać dodatkowe działania: utworzenie historii, przeliczenie sumy, wysłanie powiadomienia albo wygenerowanie dokumentu. Zgodność logiki wymaga określenia, czy takie działanie ma nastąpić przed zatwierdzeniem transakcji, po nim, czy dopiero po potwierdzeniu przez osobny proces. Nie powinno się wysyłać komunikatu o zakończeniu naprawy, jeżeli zapis zmiany statusu zakończył się błędem. Testy jednostkowe mogą sprawdzać pojedyncze reguły, natomiast testy integracyjne powinny potwierdzać pełny przebieg od wejścia danych, przez zapis, do odczytu wyniku przez inny fragment aplikacji.

Weryfikacja zgodności podczas obsługi komputera

Przy analizie problemu należy porównać opis procesu z kodem, modelem danych, walidacją oraz rzeczywistymi wartościami zapisanymi w bazie. Przydatne są logi zawierające identyfikator operacji, identyfikator zlecenia, poprzedni i nowy status oraz wynik walidacji. Sam komunikat „zapisano dane” nie pokazuje, czy zapisano wszystkie wymagane elementy i czy późniejszy odczyt korzysta z tych samych źródeł. W przypadku rozbieżności sprawdza się także obsługę wartości pustych, wielokrotnych żądań, przerwania połączenia i ponowienia tej samej operacji.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego podczas serwisowania można ocenić także poprawność działania aplikacji używanej do ewidencji urządzeń, diagnostyki oraz obsługi zleceń. W praktyce oznacza to rozdzielenie usterki sprzętowej od błędu programu: awaria dysku, pamięci lub zasilania wymaga innych testów niż nieprawidłowa zmiana statusu, błędne naliczenie kosztu czy brak powiązania między formularzem a zapisanym rekordem. Dopiero sprawdzenie całego przepływu pozwala ustalić, czy problem wynika z urządzenia, danych wejściowych, kodu aplikacji czy niespójnego modelu procesu.