W dzisiejszym wpisie chciałbym zaprezentować macierz zależności i co można z niej odczytać. Pominiemy aspekty matematyczne – ze względu, że jest to macierz istnieje wiele faktów matematycznych ale myślę, że nie są one najważniejsze dla programisty. Załóżmy, że mamy prostą aplikację składającą się z klienta, warstwy usług, biznesowej oraz DAL. Macierz możemy wygenerować w nDepend – o tym programie kiedyś już pisałem. Umożliwia przede wszystkim liczenie metryk kodu i monitorowanie jakości kodu. Macierz dla opisanej aplikacji, wygląda następująco:

 

Macierz można tworzyć dla dowolnych elementów np. typy, biblioteki dll, namespace. W powyższym przypadku pokazano biblioteki. Zielone pola oznaczają ile jest referencji od wiersza do kolumny. Pole (1,1) oznacza, że Client ma jedną referencję do ServiceLayer. Kolejne, że ServiceLayer ma jedną referencję do BusinessLayer. Niebieskie pola z kolei, opisują tą samą zależność ale odczytywaną od kolumny do wiersza.

Generując zatem macierz zależności, możemy określić jak zbudowany jest system. Pierwszą rzecz, na jaką powinniśmy zwrócić uwagę są cykle, których zawsze powinniśmy unikać. Dodajmy zatem dodatkową referencję z DAL do BusinessLayer:

Fragment systemu, który zawiera cykl został oznaczony czerwonym kwadratem. DAL ma referencję do BusinessLayer a z kolei BusinessLayer również ma referencję do DAL (biblioteki oznaczone są czarnym kwadratem). Dobrze zaprojektowany system powinien zawsze być macierzą trójkątną, czyli taką, która posiada zera wyłącznie po jednej stronie przekątnej. W nDepend będzie to macierz, która posiada wyłącznie elementy zielone i niebieskie.

Ponadto, można wyświetlić pośrednie zależności:

Pośrednio Client posiada oczywiście referencje do BusinessLayer (przez ServiceLayer) oraz DAL (przez ServiceLayer->BusinessLayer).

Teoretycznie macierz przedstawia te same informacje co graf:

Dla dużych systemów jednak, graf zwykle jest nieczytelny. Oczywiście, zależy to co chcemy analizować. Jeśli chcemy sprawdzić czy nie mamy cykli w całym systemie, wtedy macierz jest lepsza. Jednak gdy chcemy przyjrzeć się z bliska jakiemuś fragmentowi, wtedy graf jest bardziej przejrzysty.

nDepend posiada rozbudowany system pomocy. Wystarczy najechać na komponent aby zobaczyć jego opis:

To samo tyczy się opisu metryk. Naprawdę wiele można dowiedzieć się  o dobrych praktykach czytając dołączoną dokumentację.

Co w kolejnym wpisie? Pokażę, jak macierz powinna wpłynąć na refaktoryzację systemu. Istnieje szereg metryk, które w łatwy sposób mogą być odczytane z macierzy i często powinny być sygnałem do refaktoryzacji kodu.