Metryki kodu — sprzęganie klas

Sprzęganie klas jest również określane przez nazwę Sprzężenie między obiektami (CBO) zgodnie z pierwotnie zdefiniowanym przez CK94. Zasadniczo sprzężenie klas jest miarą liczby klas używanych przez pojedynczą klasę. Duża liczba jest zła, a niska liczba jest zwykle dobra w przypadku tej metryki. Sprzężenie klas wykazano, że jest dokładnym predyktorem awarii oprogramowania, a ostatnie badania wykazały, że górna wartość limitu 9 jest najbardziej wydajną wartością S2010.

Zgodnie z dokumentacją firmy Microsoft sprzęganie klas "mierzy sprzężenie z unikatowymi klasami za pomocą parametrów, zmiennych lokalnych, typów zwracanych, wywołań metod, wystąpień ogólnych lub szablonów, klas bazowych, implementacji interfejsu, pól zdefiniowanych na typach zewnętrznych i dekoracji atrybutów. Dobry projekt oprogramowania określa, że typy i metody powinny mieć wysoką spójność i niskie sprzężenia. Wysokie sprzęganie wskazuje projekt, który jest trudny do ponownego użycia i utrzymania ze względu na wiele współzależności w innych typach."

Koncepcje sprzężenia i spójności są wyraźnie powiązane. Aby utrzymać tę dyskusję na ten temat, nie będziemy zagłębiać się w spójność inną niż podać krótką definicję z KKLS2000:

"Spójność modułu została wprowadzona przez Yourdon i Constantine jako "jak ściśle związane lub powiązane wewnętrzne elementy modułu są ze sobą" YC79. Moduł ma silną spójność, jeśli reprezentuje dokładnie jedno zadanie [...], a wszystkie jego elementy przyczyniają się do tego pojedynczego zadania. Opisują one spójność jako atrybut projektu, a nie kod, oraz atrybut, który może służyć do przewidywania możliwości ponownego użycia, konserwacji i możliwości zmiany.

Przykład sprzęgania klas

Przyjrzyjmy się sprzężenia klasy w działaniu. Najpierw utwórz nową aplikację konsolową i utwórz nową klasę o nazwie Person z niektórymi właściwościami, a następnie natychmiast oblicz metryki kodu:

Zwróć uwagę, że sprzężenie klasy wynosi 0, ponieważ ta klasa nie używa żadnych innych klas. Teraz utwórz kolejną klasę o nazwie PersonStuff z metodą, która tworzy wystąpienie osoby i ustawia wartości właściwości. Ponownie oblicz metryki kodu:

Zobacz, jak wartość sprzęgania klas wzrasta? Należy również zauważyć, że bez względu na liczbę ustawionych właściwości wartość sprzężenia klasy idzie w górę o 1, a nie przez inną wartość. Sprzęganie klas mierzy każdą klasę tylko raz dla tej metryki niezależnie od tego, ile jest używana. Ponadto można zobaczyć, że DoSomething() ma wartość 1, ale konstruktor , PersonStuff()ma wartość 0 dla jej wartości? Obecnie w konstruktorze nie ma kodu używającego innej klasy.

Co zrobić, jeśli umieścisz kod w konstruktorze, który używał innej klasy? Oto, co otrzymujesz:

Teraz konstruktor wyraźnie ma kod, który używa innej klasy, a metryka sprzęgania klas pokazuje ten fakt. Ponownie widać, że ogólny sprzężenie klasy dla PersonStuff() parametru to 1, a DoSomething() także 1, aby pokazać, że używana jest tylko jedna klasa zewnętrzna bez względu na to, ile kodu wewnętrznego używasz.

Następnie utwórz kolejną nową klasę. Nadaj tej klasie nazwę i utwórz wewnątrz niej pewne właściwości:

Teraz zużyj klasę w naszej DoSomething() metodzie w PersonStuff klasie i ponownie oblicz metryki kodu:

Jak widać, sprzężenie klas dla klasy PersonStuff wzrośnie do 2, a jeśli przejdziesz do szczegółów klasy, zobaczysz, że DoSomething() metoda ma najwięcej sprzężenia, ale konstruktor nadal zużywa tylko 1 klasę. Korzystając z tych metryk, możesz zobaczyć ogólną maksymalną liczbę dla danej klasy i przejść do szczegółów na podstawie poszczególnych składowych.

Liczba magiczna

Podobnie jak w przypadku złożoności cyklatycznej, nie ma limitu, który pasuje do wszystkich organizacji. Jednak S2010 wskazuje, że limit 9 jest optymalny:

"W związku z tym uważamy wartości progowe [...] jako najbardziej skuteczne. Te wartości progowe (dla jednego elementu członkowskiego) to CBO = 9[...]". (dodano wyróżnienie)

Analiza kodu

Analiza kodu obejmuje kategorię reguł konserwacji. Aby uzyskać więcej informacji, zobacz Reguły konserwacji. W przypadku korzystania ze starszej analizy kodu zestaw reguł rozszerzonych wytycznych dotyczących projektowania zawiera obszar możliwości konserwacji:

Wewnątrz obszaru konserwacji jest reguła sprzęgania klas:

Ta reguła wyświetla ostrzeżenie, gdy sprzężenie klasy jest nadmierne. Aby uzyskać więcej informacji, zobacz CA1506: Unikanie nadmiernego sprzężenia klas.

Cytatów

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). Pakiet metryk dla projektowania obiektowego (transakcje IEEE w zakresie inżynierii oprogramowania, vol. 20, nr 6). Pobrano 14 maja 2011 r. z witryny internetowej University of Pittsburgh: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F., i Saint-Denis, G. (2000). Revisited class spójność: Badanie empiryczne systemów przemysłowych (Proceedings of the Workshop on Quantitative Approaches in Object-Oriented Software Engineering). Pobrano 20 maja 2011 r. z witryny internetowej Firmy Montrealé de Montréal http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Kryszna, M. S. (2003). Empiryczna analiza metryk CK pod kątem złożoności projektowej zorientowanej na obiekt: implikacje dla wad oprogramowania (transakcje IEEE na temat inżynierii oprogramowania, vol. 29, nr 4).

S2010

Shatnawi, R. (2010). Badanie ilościowe akceptowalnych poziomów ryzyka metryk zorientowanych na obiekty w systemach typu open source (transakcje IEEE na temat inżynierii oprogramowania, vol. 36, nr 2).

YC79

Edward Yourdon i Larry L. Constantine. Projekt ustrukturyzowany. Prentice Hall, Englewood Cliffs, NJ, 1979.