Szukasz kursu specjalistycznego z BHP, SEP lub kursu na spawcza? Kurs edukacyjny!

Rzeczywistość oprogramowania

Skuteczne oprogramowanie jest użytkowane dłużej niż żyje maszyna, do której zostało pierwotnie napisane. Pojawiają się nowe, jeśli nie komputery, to przynajmniej dyski, monitory, drukarki. Trzeba więc dostosować oprogramowanie do tych urządzeń.

Krótko mówiąc, produkt programowy jest osadzony w kulturowej macierzy zastosowań, użytkowników, przepisów prawnych i maszyn. Wszystko to ciągle się zmienia, a proces ten nieuchronnie wymusza zmiany w oprogramowaniu.

Niewidoczność. Oprogramowanie jest niewidoczne i nie można go pokazać. Abstrakcje geometryczne to potężne narzędzia. Widząc plan budynku, zarówno architekt, jak i klient mogą ocenić przestrzeń, kierunki ruchu, widoki. Można wyłapać wszelkie sprzeczności, dostrzec luki. Rysunki w skali części mechanicznych i modele przestrzenne cząsteczek, choć są abstrakcjami, służą takim samym celom. Abstrakcja geometryczna odzwierciedla rzeczywistość geometryczną.

Rzeczywistość oprogramowania nie jest z istoty osadzona w przestrzeni. Nie ma zatem łatwego sposobu jej geometrycznego przedstawienia, analogicznego do przedstawienia terenu na mapie, kostki krzemowej na wykresie, komputera na schemacie połączeń. Kiedy tylko próbujemy wykreślić strukturę oprogramowania, stwierdzamy, że obejmuje ona nie jeden lecz kilka ogólnych grafów skierowanych, nałożonych na siebie. Na tych kilku grafach można przedstawiać przebieg sterowania, przepływ danych, układy zależności, następstwo czasowe i związki w obszarze nazw. Zazwyczaj grafy nie są nawet planarne, nie mówiąc już o tym, że nie są hierarchiczne. W istocie jednym ze sposobów ustanowienia koncepcyjnej kontroli nad taką strukturą jest wymuszenie przecinania powiązań aż do chwili, kiedy jeden lub więcej grafów nabierze charakteru hierarchicznego2.

Pomimo postępów w ograniczaniu i upraszczaniu struktur oprogramowania nie da się ich uwidocznić. Umysł jest więc pozbawiony najpotężniejszych narzędzi koncepcyjnych. Brak ten nie tylko utrudnia ogarnięcie procesu projektowania jednym umysłem, ale poważnie przeszkadza w komunikowaniu się różnych umysłów.

Przełomy w przeszłości prowadziły do rozwiązania trudności ubocznych

Gdy spróbujemy zbadać trzy najbardziej owocne w przeszłości etapy rozwoju technologii oprogramowania, zauważymy, że w każdym z nich pokonywano inne poważne trudności w budowaniu oprogramowania. Były one jednak uboczne, a nie zasadnicze. Dostrzeżemy też naturalne granice ekstrapolacji walki z tymi trudnościami w każdym etapie.

Języki wysokiego poziomu. Z pewnością najskuteczniejszym działaniem na rzecz efektywności, niezawodności i prostoty oprogramowania było sukcesywne wykorzystywanie do programowania języków wysokiego poziomu. Większość fachowców temu właśnie przypisuje przynajmniej pięciokrotny wzrost efektywności oprogramowania, przy jednoczesnym wzroście jego niezawodności, prostoty i zrozumiałości.

Co osiąga się dzięki językowi wysokiego poziomu? Uwalnia się program od znacznej części jego przypadkowej złożoności. Program abstrakcyjny składa się z konstrukcji koncepcyjnych: operacji, typów danych, sekwenq’i i komunikacji. Konkretny program maszynowy dotyczy bitów, rejestrów, warunków, rozgałęzień, kanałów, dysków itp. Język wysokiego poziomu eliminuje cały poziom złożoności, który nigdy nie wynikał z istoty programu, urzeczywistniając konstrukcje wymagane w programie abstrakcyjnym.

Zadaniem języka wysokiego poziomu jest „dostarczenie” wszystkich konstrukcji, jakie programista wyobraził sobie w programie abstrakcyjnym. To prawda, że poziom naszego wyrafinowania przy rozpatrywaniu struktur danych, typów danych i operacji stale się podnosi, ale coraz mniej. Poziom rozwoju języków natomiast coraz bardziej zbliża się do poziomu naszego wyrafinowania.

Ponadto w jakimś punkcie rozwinięcie języka wysokiego poziomu staje się ciężarem, który zwiększa, a nie zmniejsza intelektualne trudności, jakie napotyka użytkownik, rzadko kiedy korzystający z ezoterycznych konstrukcji.

Podział czasu. Większość fachowców właśnie wprowadzeniu możliwości podziału czasu przypisuje znaczny wzrost wydajności programi- stów i poprawę jakości ich produktów – choć nie tak dużą jak ta, którą osiągnięto dzięki językom wysokiego poziomu.

Przełomy w przeszłości prowadziły do rozwiązania trudności ubocznych cz. II

Z podziałem czasu wiążą się jednak całkiem inne kłopoty. To prawda, że zapewnia on natychmiastowość wykonania programu, a zatem umożliwia zbadanie jego złożoności. Powolny cykl przetwarzania wsadowego prowadzi do tego, że nie pamiętamy szczegółów, jeśli nie głównego celu, naszych przemyśleń z chwili, kiedy przerwaliśmy programowanie i zdecydowaliśmy się na kompilację oraz wykonanie. Ta przerwa w świadomości jest kosztowna czasowo, bo musimy odświeżyć sobie pamięć. Najpoważniejszą konsekwencją może być jednak utrata kontroli nad tym, co się dzieje w złożonym systemie.

Powolny cykl przetwarzania, podobnie jak złożoność języków maszynowych, jest raczej uboczną niż zasadniczą trudnością w procesie tworzenia oprogramowania. Można wprost określić granice wpływu podziału czasu na proces przetwarzania. Głównym skutkiem jest skrócenie czasu reakcji systemu. W miarę jak czas ten zbliża się do zera, w jakimś punkcie przekracza próg zauważania go przez człowieka, wynoszący około stu milisekund. Poniżej tej granicy nie należy więc oczekiwać żadnych korzyści.

Jednolite środowiska programistyczne. Uważa się, że UNIX i Inter- slip, pierwsze zintegrowane środowiska programistyczne o szerokim zastosowaniu, zwiększyły efektywność oprogramowania kilkakrotnie. W jaki sposób?

Eliminują uboczne trudności związane z łącznym wykorzystywaniem programów przez udostępnianie zintegrowanych bibliotek, ujednoliconych formatów plików, potoków i filtrów. W efekcie struktury koncepcyjne, które w teorii zawsze mogły się wzajemnie wywoływać, zasilać i wykorzystywać, mogą to rzeczywiście robić w praktyce.

Ten przełom doprowadził z kolei do opracowania całych pakietów narzędziowych. Można bowiem było zastosować każde nowe narzędzie do dowolnego programu korzystającego ze standardowych formatów.

Ze względu na te osiągnięcia środowiskom programistycznym poświęca się dziś wiele uwagi w inżynierii oprogramowania. W następnym podrozdziale będzie mowa o wiążących się z nimi nadziejach i ograniczeniach.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.