Złożoność EA (2) - miary złożoności IT

Zgodnie z definicją CUEC (Consortium for Untangling Enterprise Complexity): złożoność, to cecha systemu, która powoduje, że jest on trudny w użyciu, w zrozumieniu, w zarządzaniu i/lub trudny do implementacji. Złożoność może więc dotyczyć różnych aspektów IT, np. złożoności implementacji systemu, złożoności komunikacji między ludzi w projekcie czy złożoności procesów biznesowych wspieranych przez system.

Jeśli budujemy prostą, jednostanowiskową aplikację do używania przez jednego użytkownika, wtedy prawdopodobnie nie będziemy potrzebować żadnego architekta. Jeśli jednak zamierzamy zbudować rozwiązanie o architekturze rozproszonej, używane w całej organizacji i wspierające krytyczne procesy firmy, wtedy najprawdopodobniej będziemy potrzebować architekta baz danych, architekta rozwiązań architekta infrastruktury, architekta biznesowego oraz architekta korporacyjnego.

W celu skutecznego zarządzania złożonością w IT niezbędny jest jakiś sposób jej zmierzenia. Istnieje wiele miar złożoności oprogramowania. Opierają się one głównie na badaniu struktury kodu źródłowego. W tym artykule przedstawiam dwie najbardziej znane miary złożoności oprogramowania: miarę złożoności cyklomatycznej oraz miarę złożoności Halstead'a. Jednak miary złożoności oprogramowania niestety nie nadają się do mierzenia złożoności architektury. Najczęściej cytowane w tym obszarze są wyniki prac Rogera Sessions, który zdefiniował miarę złożoności architektury IT, przedstawioną na końcu tego artykułu.

Miara złożoności cyklomatycznej

Miara złożoności cyklomatycznej oprogramowania została opracowana przez Thomasa J. McCabe’a w 1976 roku. Mierzy liczbę pełnych, niezależnych ścieżek, przez które można przejść w programie. Oryginalnie oblicza się ją przy użyciu grafu skierowanego reprezentującego przepływ sterowania w danym programie. Węzły tym grafie odpowiadają podstawowym blokom programu (niepodzielny ciąg instrukcji, jedno wejście, jedno wyjście, instrukcje wykonywane po kolei, bez skoków z i do wnętrza bloku) a skierowane krawędzie oznaczają skoki w przepływie sterowania. Dla danego grafu przepływu sterowania G, złożoność cyklomatyczna M jest zdefiniowana jako :
v(G) = E - N + 2P
gdzie:
E = liczba krawędzi w grafie
N = liczba węzłów w grafie
P = liczba oddzielnych podgrafów (połączonych komponentów mierzonego grafu)

Po uproszczeniach, złożoność cyklomatyczną CC dla danej funkcji lub metody lub całej klasy lub całego systemu złożonego z wielu takich elementów, można wyrazić następująco:
CC = d - e + 2
gdzie:
d = liczba węzłów decyzyjnych o charakterze binarnym
e = liczba wyjść z programu

Dla przykładu: jeśli program ma jedno wyjście, nie zawiera żadnej instrukcji if/else (lub innej sprawdzającej warunek) ani żadnej pętli, wtedy złożoność cyklomatyczna takiego programu będzie wynosiła 1, gdyż zawiera on tylko jedną ścieżkę przejścia. Jedna instrukcja if/else zwykle wprowadza dwie możliwe ścieżki - jedną, gdy badany warunek jest spełniony i drugą, gdy badany warunek nie jest spełniony. Złożoność cyklomatyczna programu z jednym wyjściem i jedną instrukcją if/else, nawet zawierającego wiele funkcji, będzie wynosiła 2.

Złożoność cyklomatyczna programu przekłada się na trudność jego zrozumienia, pracochłonność testowania, niezawodność, trudność utrzymania, itd . Jedną z metod zmniejszania zmniejszania złożoności cyklomatycznej jest partycjonowanie oprogramowania, czyli podział na moduły o wysokiej kohezji i słabych związkach z innymi modułami.

Miary złożoności Halstead'a

W 1977 roku Maurice Howard Halstead opracował kilka metryk oprogramowania na podstawie empirycznych doświadczeń. Jedną z nich jest miara złożoności, która określa trudność zrozumienia lub skłonność do występowania błędów. Wg Halstead'a, trudność (D) programu jest proporcjonalna do liczby unikalnych operatorów w programie. D jest również proporcjonalna do stosunku pomiędzy całkowitą liczbą wystąpień operandów, a liczbą operandów unikalnych. Zapis matematyczny :
D = (n1 / 2) * (N2 / n2)
gdzie:
n1 – liczba unikalnych (różnych) operatorów w programie
n2 – liczba unikalnych (różnych) operandów w programie
N1 – całkowita liczba wystąpień operatorów
N2 – całkowita liczba wystąpień operandów

Miara złożoności Halstead'a mówi, że jeśli te same operandy są używane w programie wielokrotnie, to błędy występują w nim częściej.

Złożoność architektury IT Sessions'a

Obie ww. miary zostały przewidziane jedynie do mierzenia złożoności oprogramowania, nie nadają się więc bezpośrednio do mierzenia złożoności architektury IT.
Na poziomie architektury IT można wyróżnić dwa aspekty złożoności: złożoność funkcjonalna i złożoność koordynacji .

Złożoność funkcjonalna
Weźmy system, które ma zaimplementowaną jedną funkcjonalność. Taki system będzie mniej złożony od systemu, który ma trzy funkcjonalności. A z kolei system z trzema funkcjonalnościami będzie mniej złożony od systemu, który ma ich dziewięć - patrz poniższy rysunek:

 

Błędne działanie systemu z jedną funkcją a będzie spowodowane błędem tylko w tej jednej funkcji a. Błędne działanie systemu z dwoma funkcjami a i b może być spowodowane błędem w funkcji a lub błędem w funkcji b lub błędem w obu funkcjach a i b. Błędne działanie systemu z trzema funkcjami a, b i c może być spowodowane błędem w: a, b, c, a+b, a+c, b+c, a+b+c.

Widać, że złożoność systemu C rośnie szybciej, niż ilość funkcjonalności F w tym systemie. W 1979 roku S. N. Woodfield przeprowadził eksperyment wykazujący empirycznie, że wzrost ilości funkcjonalności o 25% powoduje wzrost złożoności o 100%. Czyli dla funkcjonalności F=1 złożoność C wynosi 1 a dla funkcjonalności F=1.25 złożoność C wynosi 2. Ta obserwacja prowadzi do wzoru na złożoność będącą funkcją liczby N funkcjonalności systemu:
FC(N) = 10^(3.11 * log(N))

Po uproszczeniu:
FC(N) = N^3.11

Złożoność współdziałania
Złożoność danego systemu może rosnąć nie tylko z powodu wzrostu liczby funkcjonalności, ale również wraz ze wzrostu zależności tego systemu od innych systemów - patrz poniższy rysunek:

Te zależności, które składają się na złożoność danego systemu, to mogą być zarówno usługi innych systemów w sensie SOA jak i współdzielone dane, wywołania funkcji innych systemów, czy współdzielone transakcje. Każda taka zależność, to po pierwsze dodatkowa funkcjonalność w danym systemie a po drugie potencjalne źródło błędu, więc dodatkowy element do sprawdzenia podczas szukania przyczyny nie działania systemu czyli dodatkowe punkty złożoności danego systemu. Możemy więc przyjąć, że wzór na złożoność współdziałania CC wynikającą z M zależności danego systemu od innych będzie analogiczny do wzoru na złożoność wynikającą z liczby funkcjonalności :
CC(M) = M^3.11

Złożoność całkowita architektury IT
Złożoność danego systemu składa się ze złożoności wynikającej liczby funkcjonalności oraz ze złożoności wynikającej z liczby zależności danego systemu od innych. Przy założeniu, że te dwie złożoności są od siebie niezależne, wzór na całkowitą złożoność C systemu zawierającego N funkcjonalności oraz M zależności można wyrazić wzorem:
C(N, M) = N^3.11 + M^3.11

Systemy w złożonych architekturach przeważnie nie funkcjonują samodzielnie. Złożoność architektury A złożonej z X systemów będzie więc sumą złożoności poszczególnych systemów:
C(A) = SUMA( C(X) )

Zakończenie

Problem złożoności, wstępnie zidentyfikowany 25 lat temu, gdy architektura korporacyjna powstawała, dzisiaj dochodzi do punktu krytycznego. Złożoność i koszt systemów IT wzrosły wykładniczo a łatwość uzyskiwania realnej wartości z użycia tych systemów dramatycznie zmalała . Tymczasem architektura korporacyjna miała m.in. właśnie zaadresować problem rosnącej złożoności organizacji, łącznie z jej komponentami technologicznymi. Po to właśnie powstały metodologie zarządzania architekturą korporacyjną - aby zmniejszyć ryzyka i poprawić jakość efektów planowania i realizacji zmian w architekturze przedsiębiorstwa. Pomimo to żadna z dzisiejszych metodyk zarządzania architekturą korporacyjną nie definiuje, czym ta złożoność jest, jak ją można kontrolować ani jak sprawdzać, czy udało się ją zmniejszyć lub wyeliminować.

Zgodnie z zasadą, że nie da się zarządzać czymś, czego nie da się zmierzyć więc w celu poradzenia sobie ze złożonością w IT konieczny jest jakiś jej pomiar. W mniejszym artykule przedstawiłem dwie miary złożoności oprogramowania oraz jedną miarę złożoności architektury, ale jest zaledwie drobny wyimek z dostępnych metod, których istnieje około 100.

Złożoność kosztuje. Samo zmierzenie złożoności nie powoduje, że staje się ona mniejsza, ale pomaga w skupieniu się na tych działaniach, które ją zmniejszają. Metody radzenia sobie ze złożonością zastaną przedstawię w następnym artykule.

Źródła

• Standard Definitions of Common Terms, CUEC (Consortium for Untangling Enterprise Complexity), http://www.cuec.info/index.php/download_file/view/166/205/, [2013-04-27].
• McCabe T. J., A Complexity Measure, [w:] IEEE Transactions on Software Engineering, 1976, vol. 2, nr 4, s. 308-320, http://www.literateprogramming.com/mccabe.pdf, [2012-06-09].
• Halstead M. H., Elements of Software Science, Amsterdam 1977, Elsevier North-Holland, Inc.
• Sessions R., The Mathematics of IT Simplification, ObjectWatch, Inc., 2011-04-01, http://www.objectwatch.com/whitepapers/MathOfITSimplification-103.pdf, [2012-06-09].
• Sessions R., Simple Architectures for Complex Enterprises, 1 edycja kindle 2010, Microsoft Press.
• Watson A. H., McCabe T. J., Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric, Wrzesień 1996, NIST Special Publication 500-235, s. 16, http://www.mccabe.com/pdf/mccabe-nist235r.pdf, [2012-06-09].
• Woodfield S.N., An Experiment on Unit Increase in Problem Complexity, 1979, IEEE.

Złożoność EA (1) - podejście do złożoności w architekturze korporacyjnej

Historia podejścia do złożoności w architekturze korporacyjnej wydaje się być analogiczna do historii podejścia do baz danych. Do roku 1970 bazy danych były w większości oparte o model sieciowy - rekordy bazy zawierały wskaźniki do rekordów, które zawierały wskaźniki do rekordów. Sieciowy model baz danych nie miał żadnych matematycznych, logicznych lub innych teoretycznych podstaw. Projektowanie takich baz danych było oparte na doświadczeniu i intuicji.

W 1970 roku Edgar Codd opublikował artykuł , w którym przedstawił osadzony w matematyce (bo oparty o matematyczne pojęcie relacji) model baz relacyjnych oraz sposoby walidacji, czy dane w bazie danych są dobrze lub źle zorganizowane (koncepcja normalizacji danych). Model ten był początkiem baz relacyjnych, jakie są dziś powszechnie stosowane.

Podobnie jest dzisiaj z architekturą korporacyjną. Mamy wiele metodyk projektowania architektury korporacyjnej. Jednak żadna z nich nie ma matematycznych lub logicznych podstaw. Zamiast tego polegają na doświadczeniu, intuicji czy szczęściu. Takie podejście czasami daje dobre wyniki a czasami nie. Innymi słowy wyniki konstruowania architektury korporacyjnej nie są dzisiaj ani powtarzalne ani weryfikowalne.

W swoich artykułach oraz w książce Simple Architectures for Complex Enterprises, Roger Session zaprezentował matematyczny model złożoności architektury korporacyjnej oraz ugruntowane w teorii zbiorów podejście prowadzące do zmniejszania i/lub unikania tej złożoności. Przy założeniu, że celem architekta korporacyjnego jest konstruowanie m.in. prostej architektury, podejście to może zapewnić powtarzalność i weryfikowalność wyników jej projektowania.

Ten artykuł jest pierwszym z serii artykułów poświęconych złożoności architektury korporacyjnej. Zaczynamy od jej (złożoności) zamodelowania.

Matematyczny model złożoności

Zgodnie z definicją CUEC (ang. Consortium for Untangling Enterprise Complexity): złożoność, to cecha systemu, która powoduje, że jest on trudny w użyciu, w zrozumieniu, w zarządzaniu i/lub trudny do implementacji . W swoich pracach Sessions stawia tezę, że najlepszym estymatorem złożoności systemu jest liczba znaczących stanów, w których ten system może się znaleźć (prawo złożoności oprogramowania Sessions'a).

Weźmy program, który rozpoznaje i wyświetla wynik rzutu jedną monetą - patrz poniższy rysunek (sposób wykrycia strony monety po jej rzucie jest tutaj nieistotny). Jeśli wykrytą stronę będzie orzeł, program wyświetla napis "Orzeł". Jeśli wykrytą stroną będzie reszka, program wyświetla napis "Reszka".

Program rozpoznający i wyświetlający wynik rzutu jedną monetą.

Taki program będzie miał jedną instrukcję IF badającą wartość z "czujnika" wykrywającego stronę, którą moneta upadła podczas rzutu i w zależności od dwóch możliwych wartości warunku wyświetli odpowiedni napis. Taki program będzie miał jedną zmienną o dwóch możliwych wartościach, przechowującą wynik rzutu jedną monetą. Taki program może znaleźć się w dwóch różnych stanach końcowych. Taki program ma dwie ścieżki przejścia więc w takim programie trzeba wykonać dwa testy, aby się upewnić, że program działa poprawnie. Gdyby ten program wspierał proces biznesowy sprawdzania stanu monety po rzucie jedną monetą, to ilość ścieżek w tym procesie biznesowym wynosiłaby również dwa.

Weźmy inny program, który tym razem wykrywa i wyświetla wynik rzutu dwiema ponumerowanymi monetami - patrz rysunek poniżej.

Program rozpoznający i wyświetlający wynik rzutu dwiema monetami.

Taki program będzie już miał kilka instrukcji IF rozpoznających różne kombinacje wynikowe. Taki program będzie już miał dwie zmienne, każda o dwóch możliwych wartościach, przechowujące wyniki rzutu dwiema monetami W takim programie możliwych stanów końcowych będzie wynosiła 4: orzeł+orzeł lub orzeł+reszka lub reszka+orzeł lub reszka+reszka. Taki program będzie miał już cztery ścieżki przejścia, więc w takim programie trzeba będzie wykonać cztery testy, aby się upewnić, że działa on poprawnie. Gdyby ten program wspierał proces biznesowy sprawdzania stanu monet po rzucie dwiema, ponumerowanymi monetami, to ilość ścieżek w tym procesie biznesowym wynosiłaby cztery. Widać, że po dodaniu jednej monety złożoność programu wzrosła dwukrotnie.

Istotną cechą takiego sposobu pomiaru złożoności jest to, że nawet jeśli dokładnie nie wiadomo, co to właściwie znaczy, że dany program ma złożoność 256, to wiadomo, że będzie on dwa razy bardziej złożony, niż program o złożoności 128. Z tego płynie Pierwszy Wniosek Sessions'a Złożoności Oprogramowania : relatywna złożoność dwóch systemów A i B jest taka sama, jak współczynnik wynikający z liczby stanów systemu A podzielonej przez liczbę stanów systemu B.

Z powyższych obserwacji można wyciągnąć następujący wniosek: liczba stanów systemu jest równa średniej liczbie znaczących / istotnych stanów kontrolowanych przez zmienne tego systemu, podniesionej do potęgi równej liczbie zmiennych tego systemu . System z dwiema zmiennymi, z których każda kontroluje średnio 6 istotnych stanów, jako całość może się znaleźć w 6^2 = 36 stanach. Taki system można przetestować w całości testując 36 różnych ścieżek przejścia. Reasumując, dla danego system, złożoność C tego systemu można wyrazić wzorem:
C = S^V
gdzie:
V = liczba zmiennych programu
S = liczba istotnych stanów, średnio, kontrolowanych przez każdą ze zmiennej

Liczba ścieżek w procesie biznesowym, analogicznie, równa jest liczbie punktów decyzyjnych, podniesionej do (średniej) liczby wynikowych decyzji w każdym z tych punktów. W procesie z dwoma punktami decyzyjnymi, z których każdy może skierować proces w jednym z sześciu kierunków, będziemy mieć 6^2 = 36 możliwych ścieżek przejścia procesu. Płynie stąd analogiczny do złożoności oprogramowania, sposób obliczania złożoności procesu biznesowego: złożoność procesu biznesowego jest funkcją liczby możliwych ścieżek w tym procesie (Prawo Złożoności Procesu Biznesowego Sessions'a). I analogicznie do Pierwszego Wniosku Sessions'a Złożoności Oprogramowania, Pierwszy Wniosek Sessions'a Złożoności Procesu Biznesowego brzmi: relatywna złożoność dwóch procesów biznesowych A i B jest taka sama, jak współczynnik wynikający z liczby ścieżek procesu A podzielonej przez liczbę ścieżek procesu B.

Reasumując, dla danego procesu biznesowego, złożoność C tego procesu można wyrazić wzorem:
C = P^D
gdzie:
D = liczba punktów decyzyjnych w procesie
P = średnia liczba ścieżek generowanych przez każdy z punktów decyzyjnych

Oba wzory na złożoność, złożoność oprogramowania oraz złożoność procesu biznesowego, mają postać C = x^z. Podobny wzór stosuje się w analizie probabilistycznej, gdy chcemy się dowiedzieć, ile permutacji ma dany układ D różnych kostek, z których każda ma F ścianek. Dla takiego układu liczba możliwych wyników rzutu będzie wyrażona wzorem:
O = F^D
gdzie:
O = liczba możliwych wyników rzutu kostkami
D = liczba kostek
F = liczba ścian każdej kostki

Dla przykładu, liczba możliwych wyników dla rzutu dwiema kostkami sześciościennymi będzie wynosiła 6^2 = 36.

Widać, że wszystkie 3 systemy są do siebie podobne (układ kostek, system komputerowy i proces biznesowy). Pozwala nam to na wyciąganie wniosków o jednym systemie na podstawie obserwacji cech drugiego. Innymi słowy można przyjąć, że wszystkie trzy systemy są ze sobą homomorficzne.

Model wzrostu złożoności układu

Układ złożony z 1 kostki sześciościennej ma 6 możliwych stanów, w których może się znaleźć. Układ złożony z 2 takich kostek ma już 36 możliwych stanów przy założeniu, że obie kostki są identyfikowalne (można stwierdzić, która jest pierwsza a która jest druga). W ogólności układ złożony z D kostek F ściennych ma F^D możliwych stanów. Poniższe zestawienie przedstawia liczbę stanów układu kostek sześciościennych w zależności od liczby kostek.
1 / 6 (liczba kostek / liczba stanów układu)
2 / 36
3 / 216
4 / 1.296
5 / 7.776
6 / 46.656
7 / 279.936
8 / 1.679.615
9 / 10.077.696
10 / 60.466.176
11 / 362.797.056
12 / 2.176.782.336

Przy założeniu, że układ 12 kostek jest homomorficzny z systemem informatycznym zawierającym 12 zmiennych, z których każda może się znaleźć w jednym z sześciu istotnych stanów, możemy przyjąć, że taki system będzie posiadał ponad 2 miliardy stanów, w których może się znaleźć. Podobnie z procesem biznesowym: przy założeniu, że układ 12 kostek jest homomorficzny z procesem biznesowym zawierającym 12 punktów decyzyjnych, w których można podjąć jedną z sześciu decyzji, możemy przyjąć, że taki proces biznesowy będzie posiadał ponad 2 miliardy stanów, w których może się znaleźć. Innymi słowy taki system lub proces biznesowy będzie bardzo, bardzo złożony.

Podsumowanie

W powyższym przykładzie zwiększenie liczby kostek z 11 do 12, czyli o mniej, niż 10%, powoduje sześciokrotny wzrost liczby stanów układu. Przenosząc tę analogię na system informatyczny możemy powiedzieć, że dodając niewielką liczbę funkcjonalności powodujemy bardzo duży wzrost złożoności systemu. Dlatego redukcja nawet małej liczby zbędnych elementów funkcji biznesowych, istotnie zmniejszy złożoność architektury, jako całości. A bardziej konkretnie - np. czy funkcja windykacji koniecznie musi wysyłać cokwartalne raporty? Jeśli nie - zrezygnujemy z nich. To istotnie zmniejszy złożoność procesów biznesowych i systemów informatycznych firmy.

Źródła

• E. Codd, A relational Model for Large Shared Data Banks, [w:] Communications of the ACM, Volume 13, Issue 6, s. 377-387, czerwiec 1970, IBM Research Lab, San Jose.
• Standard Definitions of Common Terms, CUEC (Consortium for Untangling Enterprise Complexity), www.cuec.info/standards/CUEC-Std-CommonTerminology-Latest.pdf, [2012-06-09].
• R. Sessions, The Mathematics of IT Simplification, 2011-04-01, ObjectWatch, Inc., http://www.objectwatch.com/whitepapers/MathOfITSimplification-103.pdf, [2012-06-09]. 
• R. Sessions, Simple Architectures for Complex Enterprises, 1 edycja kindle 2010, Microsoft Press.
• S.N. Woodfield, An Experiment on Unit Increase in Problem Complexity, IEEE, 1979.

III Forum Architektów IT, 18 kwietnia 2013

III Forum Architektów IT

Serdecznie zapraszam na III Forum Architektów IT organizowane przez Computerworld. Spotkanie odbędzie się 18 kwietnia w budynku Biblioteki Uniwersytetu Warszawskiego.

Na konferencji będę miał przyjemność podzielić się ze słuchaczami najważniejszymi wnioskami z przeprowadzonych przeze mnie badań nad szeroko rozumianą złożonością architektury korporacyjnej IT oraz opowiedzieć, jak ta teoria jest przekładana na praktykę w Orange Polska. Swoje wystąpienie zakończę odniesieniem realizowanych zmian do etapów dojrzałości architektonicznej przedsiębiorstwa, o których pisałem w listopadzie 2012.

Premiera e-booka "Oblicza architektury korporacyjnej"

Podczas Forum będzie również miała miejsce oficjalna premiera e-book’a pt. „Oblicza architektury korporacyjnej”. Jest to praca zbiorowa pod redakcją Prof. SGH Andrzeja Sobczaka, w której znajduje się m.in. artykuł mojego autorstwa pt. „Metody zmniejszania złożoności architektury”. Wyjaśniam w nim dokładniej niektóre tezy, które postawię podczas prezentacji oraz dodatkowo wyjaśniam, w jaki sposób konstruować prostą architekturą. Po premierze e-book będzie publicznie dostępny do pobrania m.in. ze strony ArchitekturaKorporacyjna.pl.

Serdecznie zapraszam na III Forum Architektów IT a po konferencji - do pobrania e-book’a„Oblicza architektury korporacyjnej” ze strony ArchitekturaKorporacyjna.pl.