Wzorce projektowe to bardzo ważna część ??zawodu? analityka i architekta oprogramowania. […] Generalnie wzorce są to skatalogowane standardy i dobre praktyki . (Obiektowe wzorce projektowe )
Szkolenia dla analityków poprzedzam ankietami przed szkoleniowymi, jak do tej pory żadna nie zawierała pytań o wzorce projektowe: ani tego że są używane ani tego, że są celem szkolenia, niemalże każdy deklaruje albo, że używa UML lub, że chce zacząć używać UML, nawet gdy są to programiści. Zauważyłem, że wzorce projektowe w świadomości analizy biznesowej i projektowania (OOAD) „nie istnieją”. Wśród programistów, jeżeli jest spotykana, to wiedza o wzorcach przydatnych w tworzeniu bibliotek i narzędzi, często też powielane są wyuczone stare i złe praktyki programistyczne rodem z lat 60-tych (np. praktyki SmallTalk, patrz dalej).
Z drugiej strony od wielu lat znane są techniki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), które w różnych formach, ale jednak wskazują, że najskuteczniejsza forma wyrażania wymagań wobec rozwiązania to projekt architektury i logiki dziedzinowej (model) działania aplikacji . O projektowaniu poprzedzającym implementację pisze sie od dość dawna, metody obiektowe i dobre praktyki znane są od lat .
Autorzy BABoK praktycznie od początku istnienia tego wydawnictwa, zwracają uwagę na tak zwaną „białą skrzynkę”, czyli wymagania wyrażone w postaci wewnętrznej struktury produktu, wskazując, że to znacznie skuteczniejsza metoda definiowania wymagań wobec rozwiązania, niż tak zwana „czarna skrzynka”, czyli tradycyjne, i jednak mniej skuteczne, wymagania wyrażone tylko jako cechy funkcjonalne i poza-funkcjonalne. Pamiętajmy, że adresatem wymagań jest zawsze dostawca produktu!
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Tym razem wpadł mi w oko doskonały artykuł Pana Bogdana Berezy w COMPUTEROWRLD nr. 4 – 1019 z tego roku. Polecam cały artykuł do przeczytania, a po prawej cytat, który obudził we mnie potrzebę uzupełnienia.
Cały artykuł dotyczy ignorowania nauki w inżynierii oprogramowania na rzecz prostych pseudorozwiązań. Tu się z autorem w pełni zgadzam: nauka jako szukanie zrozumienia i rozwiązań problemów poprzez analizę i uogólnianie ma głęboki sens, historia pokazuje, że tak zwane metody naukowe są skuteczne (o czym nie raz tu już pisałem) ale też nielubiane bo trudne.
Autor napisał także (cytat po prawej, moim zdaniem prawdę), że nastąpiło pewne szaleństwo, które w moich oczach doprowadziło w branży IT to totalnego pomieszania pojęć (ostatni akapit cytatu obok). Nie zgodzę się jednak z tym, że „dane i funkcje, zadeklarowane wewnątrz jednej funkcji przestają istnieć, gdy się te funkcję opuści” (pierwszy akapit cytatu po prawej). Otóż w metodach obiektowych nie istnieje pojęcie „funkcji”, są operacje i metody oraz atrybuty a nie dane, a zniknąć mogą co najwyżej atrybuty obiektu (tu traktowane jako jakieś dane) pod warunkiem, że go – ten obiekt – zniszczymy. Tu chyba jednak mamy pomieszanie pojęć (dodam, że nie rozumiem stwierdzenia „funkcja zawiera funkcje i dane”).
W czym problem? Otóż należy bardzo rygorystycznie odróżnić:
Autor artykułu, pisząc jedynie o programowanie obiektowym, w moich oczach ma rację. Co do zgodności OO z psychiką to i ja mam wątpliwości, i tu chyba faktycznie pomysłodawcy popłynęli.
Tu przypomnę kolejne ważne pojęcia:
ogólna teoria systemów to teoria operująca pojęciem system, definiowanym jako „zbiór elementów współpracujących w określonym celu”, teoria ta w zasadzie stanowi obecnie podstawę tak zwanych metod naukowych,
paradygmat obiektowy to traktowanie określonej rzeczywistości jako „zbioru współpracujących obiektów realizujących określone funkcje wobec swojego otoczenia”.
Jak widać są to bardzo do siebie podobne (niemalże tożsame) pojęcia. Studiując literaturę przedmiotu zaryzykuję tezę, że ta zbieżność nie jest przypadkowa :), pierwsze obiektowe języki programowania powstały w ośrodkach akademickich na potrzeby prowadzenia badań opartych o symulacje.
W świecie „ludzi IT” pojęcie „obiektowości” zostało całkowicie zawłaszczone na użytek języków programowania. Jest to w moich oczach wielka szkoda wyrządzona obiektowemu podejściu, teorii a także samej inżynierii oprogramowania. Autor ma rację pisząc, że „obiektowość” jako taka (powyższe definicje) nie ma nic wspólnego (nie tylko) z przenoszeniem danych ze stosu na stertę czy z dziedziczeniem. Ale to właśnie efekt tego zawłaszczenia (i opis implementacji „obiektowości” w językach programowania).
Gdzie zalety i sukces obiektowości?
Jednym z kluczowych czynników ryzyka projektów z obszaru inżynierii oprogramowania, tworzonego dla firm i organizacji, jest zła jakość specyfikacji wymagań. Zajmuję się o tym od lat, wszelkie (słusznie skrytykowane przez Pana Berezę) „proste metody zbierania wymagań” dają w efekcie to, co nazywane jest niekompletnością i niespójnością. Przyczyną porażek projektów programistycznych, podawaną w 100% przypadków tych porażek, jest niekompletność i nadmiarowość specyfikacji wymagań. Niekompletność to wymagania odkrywane dopiero na etapie wdrożenia, nadmiarowość to tak zwane wymagania osierocone, czyli funkcjonalności zgłoszone jako wymagane na etapie analizy wymagań i nie wykorzystywane po dostarczeniu oprogramowania. Pierwsze generują dodatkowe koszty, drugie to czyste marnotrawstwo środków. Nieodkryte wymagania dodatkowo „niszczą” pierwotny harmonogram.
Jak pomaga tu „obiektowość”? Pomaga jako metoda analizy, pomaga jako metoda projektowania, poprzedzającego specyfikowanie wymagań. W czym rzecz?
Popularna i fałszywa teza, mówiąca, że „wymagania się zbiera”, prowadzi do deklaratywnej i nieweryfikowalnej specyfikacji wymagań funkcjonalnych i poza-funkcjonlanych (przypominam wymagania odkryte i osierocone). Popularna i mityczna jakość wymagań nazywana SMART i FURPS nie daje żadnego narzędzia do testowania kompletności i niesprzeczności wymagań, więc nie da się stwierdzić, że konkretna specyfikacja wymagań jest SMART i FURPS, wcześniej niż po zakończeniu projektu. Tak więc FURPS i SMART spokojnie, moim zdaniem, można zaliczyć do tego co Pan Bereza nazywa „bzdurną mistyfikacją”, i co niejako wyjaśnia pewna filozoficzna „prawda” mówiąca: nie istnieją proste metody rozwiązywania złożonych problemów.
Sprawdzoną w inżynierii jako takiej, metodą, jest proces wytwórczy mający trzy etapy: analiza potrzeb, projektowanie i testy, wykonanie (wytworzenie) na bazie projektu. Wprowadzenie zmian w każdym następnym etapie jest przeciętnie o rząd wielkości kosztowniejsze. Wynika z tego, że inwestycja w analizę i projektowanie poprzedzające budowę, jest jak najbardziej uzasadniona. Jednak „kolekcjonowanie wymagań” to nie jest żadna analiza, to dopiero zbieranie danych do analizy.
A gdzie tu OOA, OOD, OOP?
Jak podejść do problemu „specyfikowania wymagań” z dużo mniejszym ryzykiem? Zamówić oprogramowanie na bazie projektu, a nie na bazie opisu „czarnej skrzynki”. Co projektować? Na pewnie nie wszystko. Wg. różnych szacunków, tak zwana logika biznesowa to ok. 3 – 5% całości kodu (który zawiera między innymi rozbudowane komponenty komunikacyjne, integracyjne, wydajnościowe, bezpieczeństwa, setki bibliotek, itp.) problem w tym, że te 3 – 5% kodu decyduje w 100% o przydatności aplikacji.
Analiza obiektowa (OOA) to metoda analizy i opisu przedmiotu analizowanego (np. organizacji). Projektowanie obiektowe (OOD) to metoda opisu logiki działania tego co chcemy stworzyć (narzędzie pracy). Programowanie obiektowe to jest to co przywołał Pan Bereza, jednak cechą OOP jest to, że projekt obiektowy, produkt OOD jest możliwy do implementacji „wprost” w języku obiektowym na etapie OOP. Innymi słowy wymaganiem nie jest „lista wymagań” a projekt, analogicznie jak w każdej innej inżynierii: wymaganiem wobec wykonawcy jest projekt tego co należy wykonać a nie tylko słowny opis tego czego oczekuje zamawiający.
OOA i OOD jest łączone w OOAD z tego powodu, że obiektowy opis (model) „czegoś” jest 9w metodach obiektowych) zarazem projektem „tego czegoś”. Mając obiektowy model oprogramowania (części opisującej jego biznesową logikę działania, nazywanej Modelem Dziedziny) możemy sprawdzić (przetestować) jak spełnia on wymagania funkcjonalne zanim jeszcze, powstanie znacznie droższa od projektu, implementacja. Mamy szanse, relatywnie niskim kosztem, zmienić projekt zanim uruchomimy kosztowny zespół programistów. Na bazie takiego modelu możliwe jest w ogóle wykonanie analizy wykonalności.
Tak więc obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy „świata” i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie – obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonała (ale tylko na tyle na ile doskonały jest projekt).
Arystoteles (jak słusznie zauważył Pan Bereza), uważał, że przedmioty cięższe spadają szybciej i miał on prawo posłużyć się heurystyką, w jego czasach fizyka nawet nie raczkowała. Nie zapominajmy jednak, że Arystoteles dał podwaliny dzisiejszych metod naukowych, tezą: prawdziwa wiedza to znajomość przyczyn.
Mamy jednak inny paradoks: Znamy statystyki mówiące, że ok. 75% projektów IT to porażki, a mimo to nadal najczęściej stosowane są metody wykorzystywane przez „większość”. To się nazywa konformizm Project Managera, który jak widać, jest silniejszy od umiejętności wyciągania wniosków: historia uczy ludzi, że historia niczego ludzi nie nauczyła…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.