Temat: z dyskusji o wymaganiach, do dalszej dyskusji...

Skoro wiemy już co jest cenne i jakim obróbkom to powinno być poddawane - wiedza, to warto zdać sobie sprawę, czym ona jest.
https://pl.m.wikipedia.org/wiki/Wiedza
- z tych wszystkich ujęć wynika mniej-wiecej tyle, jakby przekroić za każdym razem jakiś skomplikowany, lecz w miarę jednorodny przedmiot i opisać, co tam widać.
Bardziej w sposob zorganizowany mamy to podane tutaj http://neur.am.put.poznan.pl/mt/Wiedza.pdf

Jest jedna wspólna ciekawostka, do której wyjaśnienia użyje kolejnych ciekawych analogii z dziedziny systemów informatycznych.

A mianowicie, jezeli całe zespoły naukowców opisały standard dla choreografii procesow biznesowych, w których w sposob wyraźny identyfikujemy każde z pojęć wiedzy (kto, kiedy, jak) znajdują się w modelach BPMN. Ponadto elementy takie, jak (co) stanowią elementy asocjacji do procesow biznesowych, które UWAGA tyczą się struktur, o czym będziemy mowić potem, a także odpowiedź na pytanie (gdzie) znajdujemy w dwóch znaczeniach - (gdzie) "model/prototyp/nazwa" oraz (gdzie) "fizyczna instancja" - czyli jezeli coś się dzieje w sklepie, zawsze jest pytanie, w którym (referencja do instancji elementu).

Teraz popatrzmy sobie na ten rysunek opisujący "wymagania", ktory narysowany jest w tle mojego profilu na Facebook Arkadiusz Marek Binder, to generalnie jest to uproszczony model tego, o czym pisałem wczesniej. A teraz wróćmy do niesprecyzowanego profesjonalnie przez ówczesnych badaczy pojęcia "struktury", którego wyjaśnienie zdaje się nie bez przyczyny podejmuje w książce zespół naukowców, dodając oliwy Berthold Daum, w książce "modelling business objects with Xml-schema (xsd)", w słowach, że standard ten reprezentuje pełne i dokładnie przebadane doświadczenia 9 tysięcy lat ludzkości. Wkład pracy, trwający kilkadziesiąt lat, w międzyczasie dotyczący przejściowych standardów, takich jak SGML. Dopracowanie XSD trwało 30 miesięcy, tysiące weryfikacji dokumentów, wykonywanych przez grupy naukowców reprezentujących wszelkie możliwe dziedziny nauk, w których występowały wszelkie możliwe modele, w tym także i filologii, a także te, odczytywane z piramid. Pozwala to autorom stwierdzić, że nie istnieje żaden inny archetyp informacji, ktory nie dałby się zamodelować w tej technogii.

Ciekaostką jest to, że już od dawna strukturyzowałem w drzewie zasobów struktury, w których dostrzegałem pewne podobieństwa i usiłowałem je jakoś optymalizować, po części dochodząc w niektórych miejscach, do podobnych spostrzeżeń, ale genialna forma notacji była daleka od moich wyników pracy.

Poznanie XSD było wprost odpowiedzią na moje potrzeby. Jako, że budowałem modele urzadzen mierników w projekcie sklepu internetowego biall.com.pl, wytwarzałem struktury dotyczące nie danych jako takich - tylko cech fizycznych, funkcji pomiarowych, wyglądu, wyposażeń, części zamiennych, pasujących po innych parametrach cech. Można by rzec, że zbudowałem symulowany model percepcji struktur dotyczących rzeczy fizycznych w sposób taki, w jaki sami, wraz ze wzrostem naszej inteligencji, sobie systematyzujemy w naszej głowie - który to de-facto model w większości przypadków jest spójny z podziałami stosowanymi w dokumentacji producenta wyrobów. Odstępstwa od tej zasady łatwo dały się zastępować innymi modelami - ale wiązało się to z oporem czynnika ludzkiego na inaczej niż dotychczasowo przyjęta formułę. Według obiektowego podejścia dziedziny sklepu i produktów nie występuje taki podział na liście, jak latarka, latarka z obcęgami, obcęgi. To my rozumiemy przedmiot jako latarka, jezeli widzimy obiekt z funkcją świecenia. Funkcje świecenia może zapewniać np obiekt żarówki, ale tylko w zakresie określonej mocy.

Dochodzimy więc do miejsca, w którym możemy definiować przyrodę i optymalizować jej struktury, mamy standard do procesow, mamy pojęcie asocjacji, które dodatkowo potwierdza nam w tej teorii fakt, który znalazłem długo później, niż wpadłem na tą tożsamość - http://llpengage.eu/pl/index.php/home/narzedzia-szkole...

Znowu możemy wprost znaleźć potwierdzenie wszystkich klocków, ze w momencie fazy asocjacyjnej zapina się model wymagań systemu (requirements)

W związku z czym, odpowiedź na potrzeby na pewno znajduje się w odpowiedniej transformacji obiektow XSD, które wyrażone w technologiach XML są przekształcane w technologii XSL, a obejmują modele BPMN (xml).

Udało mi się wykonać pewne doświadczenie, w którym przekształciłem obiekty zagnieżdżone do postaci mapy XSD, po czym to samo wykonałem z danymi XML instancyjnymi, po czym za pomocą uproszczonego API do bazy danych zapisałem ten obiekt do setek małych tabel, po czym odczytałem go spowrotem do pierwotnej postaci. (Post na Facebooku dla tego zdarzenia https://www.facebook.com/arkadiusz.binder/posts/1020396... )

Powinniśmy teraz wrócić do zagadnienia wymagań jako wiedzy, jak ją rozumieją luzie oraz które jej fragmenty pasują pod nasze firmowe biznesowe potrzeby. Wiedząc, że model wykonawczy końcowy, jaki posiada pracownik wprowadzający dane do okna systemowego kończą się na naciskaniu palcem klawisza klawiatury, ale poprzez odpowiednie zamodelowanie struktur warstwy fizycznej otoczenia i danych systemu, otrzymujemy w pełni zorganizowany i dający sie zarządzać logiczny dokument. Coś, czego z pewnością nie potrafi ani wykonać ani zrozumiec starej daty jakościowec, ktory wiedzę traktuje tak samo jak arystoteles, gdyż nie ma pojęcia o technologii dziedziczenia elementów podobnych, struktur procesow, wyzwolen (to akurat potrafią), nie mając struktur zasobow, nie ma asocjacji. Wiec powstaje biblia, ktora następnego dnia jest do wywalenia do kosza.
Przyczyną tego stanu jest tez fakt, ze nie ma narzędzia (poza naszym procesy5) nie znalazłem takiego, które umożliwia modelowanie struktur, procesow, tworzenie szkoleń i jednoczesne wygenerowanie na tej podstawie aplikacji udostępniającej dokładnie to, co jest w danej dla użytkownika roli procesu.

Biznes nie jest łatwy, gdyż mamy przeciwko sobie kilka dziedzin :
-szkolenia, w których występują osobne komórki, jest to zlecane, a dane już jakoś występują w podmiotach.
-modelowanie procesow - nie jesteśmy w pełni zgodni z BPMN natywnie na modelerze; raczej jest to DITA, transformowana w locie do BPMN, co nam daje kolejnych przyzwyczajonych oponentów do robienia modeli procesow, a nie szkoleń;
-wytwarzanie aplikacji - lokalni programiści lubią grzebać w kodzie i nie są szczęśliwi, kiedy coś ich pracę zmieni. Często nie rozumieją modeli procesów, lubią, jak się im pokaże na ekranie palcem co ma inaczej wyglądać i nie czują, ze chodzi o obiekt będący w procesie. A w ogóle to ta robota odchodzi na stanowisko modelera procesow, ktory poprzez szczegółowe asocjacje w kroku, tak na prawdę szyje aplikacje;

Tak więc w istniejących warunkach systemu procesy5 musi usiąść na kolanie 3 ludzi o 3 specjalnościach, w związku z czym pojawia się kolejny problem - braku ludzi, na co odpowiedzią jest udoskonalany model wymagań do generycznych procesow dotyczących tworzenia procesow i zasobow.

- modelowanie dziedziny, powiązane modele danych z wyposażeniem fizycznym jest czymś, co pierwszy raz ludzie widzą na oczy i nie prędko dochodzą do wnioskow, ze to jest to samo, co maja rozwalone po kilkunastu plikach Word lub excel - do tego też mamy szkolenia.

Faza rozwoju o skomplikowane obiekty biznesowe w zasadzie dobiega końca, wymusi ona inny sposób zapisu asocjacji, ale nie będzie stanowić dużego problemu.

Temat: z dyskusji o wymaganiach, do dalszej dyskusji...

Ktos dołoży 3 grosze, co o tym mysli?