Złożoność programowania - Programming complexity

Złożoność programowania (lub złożoność oprogramowania ) to termin obejmujący wiele właściwości fragmentu oprogramowania, z których wszystkie wpływają na interakcje wewnętrzne. Zdaniem kilku komentatorów istnieje różnica między terminami złożonymi i skomplikowanymi. Skomplikowanie oznacza, że jest trudny do zrozumienia, ale wymaga czasu i wysiłku, ostatecznie poznawalny. Złożoność natomiast opisuje interakcje między wieloma podmiotami. Wraz ze wzrostem liczby bytów liczba interakcji między nimi wzrastałaby wykładniczo i doszłoby do punktu, w którym nie można byłoby ich wszystkich poznać i zrozumieć. Podobnie, wyższy poziom złożoności oprogramowania zwiększa ryzyko niezamierzonej ingerencji w interakcje, a tym samym zwiększa prawdopodobieństwo wprowadzenia defektów podczas wprowadzania zmian. W bardziej ekstremalnych przypadkach może to praktycznie uniemożliwić modyfikację oprogramowania. Pomysł powiązania złożoności oprogramowania z łatwością utrzymania oprogramowania został szeroko zgłębiony przez profesora Manny'ego Lehmana , który na podstawie swoich badań opracował swoje Prawa ewolucji oprogramowania . On i jego współautor Les Belady zbadali liczne możliwe wskaźniki oprogramowania w swojej często cytowanej książce, które można by wykorzystać do pomiaru stanu oprogramowania, ostatecznie dochodząc do wniosku, że jedynym praktycznym rozwiązaniem byłoby użycie takiego, które wykorzystuje deterministyczną złożoność modele.

Środki

Zaproponowano wiele miar złożoności oprogramowania. Wiele z nich, chociaż daje dobrą reprezentację złożoności, nie daje się łatwo zmierzyć. Niektóre z częściej używanych wskaźników to

Miara złożoności cyklicznej McCabe'a
Metryki nauki oprogramowania Halsteads
Henry i Kafura wprowadzili metryki struktury oprogramowania oparte na przepływie informacji w 1981 r., Które mierzą złożoność w zależności od wejścia i wyjścia. Definiują rozwinięcie procedury jako liczbę lokalnych przepływów do tej procedury oraz liczbę struktur danych, z których ta procedura pobiera informacje. Rozwinięcie definiuje się jako liczbę lokalnych przepływów z tej procedury oraz liczbę struktur danych, które procedura aktualizuje. Przepływy lokalne odnoszą się do danych przekazywanych do iz procedur, które wywołują lub są wywoływane przez daną procedurę. Wartość złożoności Henry'ego i Kafury jest definiowana jako „długość procedury pomnożona przez kwadrat wlotu pomnożony przez rozwinięcie” (długość × (wlot × rozejście) ²).
Pakiet metryk dla projektowania zorientowanego obiektowo został wprowadzony przez Chidambera i Kemerera w 1994 roku, skupiając się, jak sugeruje tytuł, na metrykach specjalnie dla kodu zorientowanego obiektowo. Wprowadzają sześć metryk złożoności obiektów obiektowych; metody ważone na klasę, sprzężenie między klasami obiektów, odpowiedź dla klasy, liczba dzieci, głębokość drzewa dziedziczenia i brak spójności metod

Istnieje kilka innych wskaźników, których można użyć do pomiaru złożoności programowania:

Złożoność rozgałęzień (Sneed Metric)
Złożoność dostępu do danych (dane karty)
Złożoność danych (Chapin Metric)
Złożoność przepływu danych (metryka Elshofa)
Złożoność decyzyjna (miernik McClure)

Prawo Tesler za to powiedzenie w interakcji człowiek-komputer stwierdzając, że każda aplikacja posiada swoistą ilość komplikacji, które nie mogą być usunięte lub ukryte.

Rodzaje

Złożoność związana ze zmianą programu jest powiązana i zależna od złożoności istniejącego programu. Złożoność problemu można podzielić na dwie części:

Przypadkowa złożoność: odnosi się do trudności, z jakimi boryka się programista w związku z wybranymi narzędziami inżynierii oprogramowania. Lepiej dopasowany zestaw narzędzi lub bardziej zaawansowany język programowania może to zmniejszyć. Przypadkowa złożoność często jest także konsekwencją braku wykorzystania domeny do obramowania formy rozwiązania, czyli kodu. Jedną z praktyk, która może pomóc w uniknięciu przypadkowej złożoności, jest projektowanie oparte na domenie .
Zasadnicza złożoność: jest spowodowana charakterystyką problemu, który ma zostać rozwiązany i nie może zostać zredukowana.

Chidamber i Kemerer Metrics

Chidamber i Kemerer zaproponowali zestaw programowych metryk złożoności, szeroko stosowany w wielu pomiarach i artykułach naukowych. Są to WMC, CBO, RFC, NOC, DIT i LCOM, opisane poniżej:

WMC - metody ważone na klasę
- ${\ displaystyle WMC = \ sum _ {i = 1} ^ {n} c_ {i}}$
- n to liczba metod w klasie
- ${\ displaystyle c_ {i}}$ to złożoność metody
CBO - sprzężenie między klasami obiektów
- liczba innej klasy, która jest sprzężona (przy użyciu lub w użyciu)
RFC - odpowiedź dla klasy
- ${\ displaystyle RFC = | RS |}$ gdzie
- ${\ displaystyle RS = \ {M \} \ cup _ {wszystko \ i} \ {R_ {i} \}}$
- ${\ displaystyle R_ {i}}$ jest zbiorem metod wywoływanych przez metodę i
- ${\ displaystyle M}$ to zbiór metod w klasie
NOC - liczba dzieci
- suma wszystkich klas, które dziedziczą tę klasę lub jej potomka
DIT - głębokość drzewa dziedziczenia
- maksymalna głębokość drzewa dziedziczenia dla tej klasy
LCOM - brak spójności metod
- Mierzy przecięcie atrybutów używanych wspólnie przez metody klas
- ${\ Displaystyle LCOM = {\ rozpocząć {przypadki} | P | - | Q |, & {\ tekst {if}} | P |> | Q | \\ 0, & {\ tekst {inaczej}} \ koniec {przypadków }}}$
- Gdzie ${\ displaystyle P = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} = \ emptyset \}}$
- I ${\ Displaystyle Q = \ {(ja_ {i}, ja_ {j}) | ja_ {i} \ czapka I_ {j} \ neq \ emptyset \}}$
- With jest zbiorem atrybutów (zmiennych instancji), do których dostęp (odczyt lub zapis) uzyskuje się za pomocą -tej metody klasy ${\ displaystyle I_ {i}}$ ${\ displaystyle i}$