Regularnie widuje pytania takie jak to:

I have an assignment for developing a hotel reservation system! One of tasks is to develop UML class diagram! However, in the task description it is written “Class diagram should represent your database”. I am a bit confused about the rules, notations and etc… because I can’t find any official UML class diagrams specifically for databases! Could you help me please? (UML class diagram for database).

i regularnie piszę: używanie diagramu klas jako reprezentacji [relacyjnej] bazy danych to świadectwo kompletnego niezrozumienia analizy i projektowania zorientowanego obiektowo (żeby nie powiedzieć ignorancji). Jest to także świadectwo braku znajomości literatury, bo faktycznie, jak zauważa autor powyższych słów, nie ma oficjalnych materiałów (organizacja standaryzująca UML) mówiących o modelowaniu relacyjnych modeli danych diagramami klas notacji UML. Do modelowania relacyjnego modelu danych używamy notacji ERD (ang. Entity Relationship Diagram, diagram związków encji). Niestety takie wzmianki – jak stosować diagram klas UML do modelowania RDBMS –  można znaleźć w książkach uznawanych za wartościowe (okładka jednej z nich po prawej), można usłyszeć na wielu szkoleniach dotyczących notacji UML, a nawet usłyszeć o tym można – modelowanie danych w UML – z ust niejednego wykładowcy na uczelniach wyższych technicznych (co jest smutne, mam na półce podręcznik akademicki z opisem stosowania kluczy głównych i obcych na diagramach klas w modelowaniu danych).

Przy okazji. Książkę tę [zotpressInText item=”{5085975:AFU3SXIM}”], mam na półce, przeczytałem, i mam obawy przez jej polecaniem, mimo, że przez wielu jest uważana niemalże za biblię analityka biznesowego (ale jako ogólny opis modelu kompetencyjnego analityka można ją uznać).

Krótkie przypomnienie pojęć (sł. j. polskiego):

dane
1. ?fakty, liczby, na których można się oprzeć w wywodach?
2. ?informacje przetwarzane przez komputer?

obiekt
1. ?przedmiot, który można zobaczyć lub dotknąć?
2. ?rzecz abstrakcyjna, np. cecha lub pojęcie?
3. ?coś, czego dotyczą czyjeś działania, zainteresowania lub uczucia?
4. ?budynek lub zespół budynków; też: urządzenia terenowe?

Generalnie dane to zapis faktów (informacje, wiedza), obiekt to abstrakcyjny bądź rzeczywisty byt, mający określone cechy i reagujący na bodźce. To dwa różne światy. Tak zwany paradygmat obiektowy to modelowanie (traktowanie) systemu jako zbioru współpracujących w określonym celu obiektów.  Model danych zaś, to opis organizacji danych w ich repozytorium. Model obiektowy to struktura współpracujących obiektów mających określone zachowania. Nie tylko na uczelniach nadal pokutuje “stare”: Algorytmy plus struktury danych równa się programy, ale to  definicja jeszcze z czasów przetwarzania wsadowego. Dzisiaj mamy wokół siebie współdziałające komputery, smartfony, linie produkcyjne, a nawet sprzęt AGD, gdzie tu są te oddzielne “struktury danych i algorytmy”? Nie ma, są współdziałające obiekty. Owszem, każdy obiekt operuje określonymi danymi, ale są one “w środku” i nie są “jedną wielką bazą danych” [zotpressInText item=”{5085975:JMUUJ5TN}”].

Notacja UML bazuje na obiektowym paradygmacie, diagram klas tej notacji służy do modelowania obiektowej struktury dowolnego systemu (obiekt to nazwa, atrybuty i operacje jakie wykonuje on na żądanie). Nie ma tu mowy o żadnych danych, co najwyżej obiekty cechują się określonymi atrybutami, te jednak nie są współdzielone a zamknięte w tych obiektach, bo to ich “prywatne” cechy. Gdyby te atrybuty były współdzielone, system taki byłby niemodyfikowalny, niepodzielny i niepodatny na zmiany, na wymianę w nim jednego obiektu na inny (co obserwujemy nadal w systemach zintegrowanych metodą współdzielenia danych, tak jest skonstruowane wiele systemów ERP!).

Owszem, na poziomie technologicznym nadal korzystamy z plików na dyskach i baz danych (nie zawsze relacyjnych) ale to co innego, korzystamy z nich do zapisu (utrwalania) danych/treści, utrwalania informacji  (danych). Na styku tych dwóch światów korzystamy (jeżeli jest taka konieczność) z mapowania modelu obiektowego na utrwalane dane i wtedy korzystamy z notacji UML do modelowania obiektowej architektury aplikacji i np. z notacji ERD do modelowania np. relacyjnej struktury danych, łącznie nazywa się mapowanie obiektowo-relacyjne (ORM). Tak więc modelowanie danych notacją UML to pogwałcenie zasad stosowania tej notacji i niezrozumienie samej notacji, pojęcia obiekt i klasa. Skąd się biorą takie pomysły? Bardzo wielu ludzi używa notacji tylko w charakterze bibliotek obrazków/symboli, zaś notacja to system pojęciowy, a to nie jest to samo.

A przy okazji: tworzenie takich modeli w notacji UML, jako projekty modelu dziedziny systemu (obiektowego), to klasyczny antywzorzec projektowy o nazwie anemiczny model dziedziny:

Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten przedmiotem wielu dyskusji – znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób. (https://pl.wikipedia.org/wiki/Antywzorzec_projektowy)

Bibliografia

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Z cyklu mity OpenSource:

Kwietniowa awaria OpenSSL, w wyniku której serwery dosłownie ?krwawiły? poufnymi danymi (stąd w języku angielskim błąd ten nazwano ?heartbleed?), jest niezaprzeczalnym dowodem na to, że otwarte kody źródłowe nie są ani analizowane ani testowane mimo wielu możliwości weryfikacji otwartego oprogramowania w celach bezpieczeństwa.  Dlaczego open source nie jest tak bezpieczny, jak powinien? – Computerworld.

Niedawno w artykule o dość wyzywającym tytule 😉  Gdzie są te cholerne szczegóły pisałem o złożoności wymagań i tym, gdzie ta złożoność jest (mogła by być, powinna być dokumentowana, jak kto woli). Tam skupiłem  się na takich szczegółach jak reguły biznesowe i złożone typy danych, czyli tym co potocznie (i nie do końca słusznie) nazywa się “walidacjami” ([[walidacja]]).

Drugim elementem “niosącym” szczegóły jest dialog użytkownika z aplikacją czyli “ekrany”. Tu pojawia się kolejna porcja wymagań, nie raz bardzo szczegółowych, zaciemniających nie raz główny sens tworzenia danego oprogramowania: scenariusze pracy z ekranem (formatką ekranową itp.).

Jak już nie raz pisałem, ogólna zasadą (dobrą praktyką) w inżynierii jest abstrahowanie oraz  zarządzanie poziomem szczegółowości każdego etapu pracy na projektem. Operowanie pojęciami (terminami) zamiast ich definicjami, to abstrahowanie od szczegółów czyli ich hermetyzacja, np. “Kontrahent” to “nazwa podmiotu, jego NIP, adres”.

Wymagania wobec aplikacji związane z interakcją aktor-system, ich definiowanie i projektowanie realizacji,  nie należą do łatwych etapów analizy i projektu, są nie raz bardzo szczegółowe. To powód dla którego warto je także  “hermetyzować”. Jak? Pomagają w tym dwie rzeczy: wyodrębnienie projektowania (dokumentowania) szczegółów interakcji jako etap projektowania nazywany [[User Experience]] (dalej UX) oraz użycie wzorca projektowego MVVM-MVC.

Najpierw jednak wzorce, bo te dadzą nam kontekst i granice hermetyzacji. Wzorzec MVVM i korzyści płynące z jego użycia, przystępnie opisano na stronie MSDN:

Przed omówieniem wzorca, warto zastanowić się, po co utrudniać sobie zadanie poprzez wykorzystywanie MVVM, zamiast pisać aplikację w klasyczny sposób (za pomocą code-behind)? W końcu wdrożenie praktycznie każdego wzorca projektowego wymaga trochę większych początkowych nakładów pracy.

Podejście Code-Behind (autonomous view ? AV) ma poważną wadę ? nie gwarantuje elastyczności oraz testowalności. Podsumowując, wprowadzenie wzorca umożliwia:

1. niezależność logiki od sposobu wyświetlania danych,
2. niezależność kodu od technologii, w której wykonana jest warstwa prezentacji,
3. wykonywanie testów ? za pomocą MVVM czy MVP możliwe jest wykonanie testów zautomatyzowanych (np. jednostkowych),
4. łatwą zamianę widoków (brak sztywnych powiązań między widokiem a logiką).

(Wprowadzenie do wzorca projektowego Model-View-ViewModel na przykładzie aplikacji WPF | MSDN (Polska).)

Z perspektywy analizy i projektowania ([[OOAD]]) najistotniejsze są pierwsze dwa punkty, bo umożliwiają hermetyzację (oddzielenie) logiki biznesowej i projektu opisującego interakcje aktor-system czyli UX. Punkt czwarty daje spełnienie jednej z zasad SOLID czyli “łatwość rozszerzenia bez potrzeby modyfikacji”. Ta ostatnia cecha to np. dodawanie nowych interfejsów użytkownika do kolejnych nowych urządzeń (smartfon, tablet, dedykowane urządzenia i wyświetlacze), bez potrzeby ingerowania w kod obsługujący już oprogramowane urządzenia.

Jak to wygląda z perspektywy architektury aplikacji i jej projektanta? Poniżej model:

Co tu mamy? Mamy MVVM i MVC na jednym diagramie. MVVM polega na wstawieniu pomiędzy widok (View) a Model dodatkowe komponentu, który stanowi wersję logiki biznesowej zawierającą ograniczenia “wyświetlacza” i dedykowane (specyfiaczne) tylko dla niego zachowania (to także pozwala unikania bardzo złej praktyki jaką jest umieszczanie logiki biznesowej w komponencie View). Innymi słowy, jeżeli jakieś zachowania systemu są specyficzne dla konkretnego typu wyświetlacza (ale może to być specyfika aktora o czym dalej), logikę tę hermetyzujemy w komponencie ViewModel.

Mając taką abstrakcję aplikacji jak powyżej, łatwo będzie osobno opisać ją przypadkami użycia, uznając je za “usługi systemu (te świadczy komponent Model) oraz osobno szczegółowymi scenariuszami UX zamkniętymi w parze komponentów View-ViewModel. Oba te elementy projektu – UX i Use Case, są więc “ładnie” odseparowane, nie wpływają na siebie nawzajem i pozwalają na łatwą rozbudowę całego systemu, niewymagającą modyfikowania już powstałego kodu (i dokumentacji).

Nawiąże jeszcze do  “specyfiki aktora”. Bardzo często w systemach internetowych, mamy potrzebę separacji użytkowników “z poza firmy” (np. klienci sklepu internetowego, interfejsy samoobsługi dla klientów serwisu itp.). Wiąże się to nie raz z bardzo złożonymi zasadami kontroli dostępu do elementów modelu 9czyli dość głęboko w systemie).  Potrafi to bardzo skomplikować cały projekt komponentu Model, a nie raz potrzeby jego istotnej przebudowy. Można tego uniknąć, hermetyzując ten obszar. Bardzo często osoba (użytkownik, aktor systemu) z zewnątrz ma bardzo ograniczone możliwości korzystania z logiki całego systemu. Łatwiej jest zaprojektować dedykowany, relatywnie prosty komponent ViewModel i połączyć go z Modelem, niż modyfikować Model Dziedziny systemu by obsługiwał, nowe, nie raz bardzo wyrafinowane, ograniczenia dostępu.

Tak więc przypadkami użycia opisujemy abstrakcję jaką jest [[Model Dziedziny Systemu]].  Są one wtedy proste, zawierają  scenariusz, który w skrócie ma postać: aktor inicjuje usługę, system prezentuje formularz do wypełnienia, aktor wypełnia go i potwierdza, system potwierdza odebranie danych i pokazuje wynik swojej pracy (lub komunikaty o błędach). Tu skupiamy się na opisie tego jakie usługi są wymagane od systemu. Kolejny etap to “komplikowanie” każdego scenariusza w postaci projektowania, dla każdego przypadku użycia, który tego wymaga, różnego rodzaju wizardów lub wprowadzamy ograniczenia związane z uprawnieniami użytkowników.  Ten etap to praca projektantów UX i grafików, specjalistów od ergonomii itp.

Bardzo ciekawa książka, przydatna każdemu kto zajmuje się nie tylko inżynierią oprogramowania (ale tą także). Analiza systemowa, projektowanie systemów, to szersza dziedzina niż tylko IT. O ogólnej teorii systemów następna książka.

Modern Methods of Systems Enginieering to rodzaj podręcznika. Kolejne rozdziały opisują metody i narzędzia stosowane w projektach z obszaru szeroko pojętej inżynierii systemów. Można tu znaleźć opis procesów analizy systemowej, spis treści kluczowych dokumentów w kolejnych etapach prac. Co nieco o notacji SysML (Systems Modeling Language).

Opisana tu metoda i narzędzia pracy są zgodne (kompatybilne) z [[DoD Systems Engineering Fundamentals]], [[NASA Systems Engineering Handbook]] i [[INCOSE Systems Engineering Handbook]].

Książka jest adresowana zarówno do początkujących (poznają metodę analizy) jak i do doświadczonych analityków (porównają opisane tu metody ze tymi które sami stosują).

Końcowe rozdziału nawiązują do notacji UML i SysML. Książkę polecam jako opis metody a nie jako bogaty opis analizy. Bliżej jej do takich pozycji jak PMBook czy BABook niż do bogatych opisów teorii i praktyki analizy.

Tytuł: Modern Methods of Systems Enginieering: With an Introduction to Pattern and Model Based Methods

Autorzy: Joe Jenney (Author), Mike Gangl (Contributor), Rick Kwolek (Contributor), David Melton (Contributor), Nancy Ridenour (Contributor), Martin Coe (Contributor)

W toku prowadzonych analiz, regularnie spotykam na etapie “zgłaszania wymagań biznesowych”, oczekiwania w rodzaju: “system ma pozwalać na wystawienie faktury na towar, którego nie ma w magazynie i pozwalać na ujemne stany magazynowe”, “system ma pozwalać na korygowanie treści historycznych dokumentów”, i wiele podobnych. To jest to co nazywam “łamanie praw fizyki w systemach”.

W zasadzie przyczyna takich żądań jest dość prosta: wielu ludzi lubi drogę na skróty, z powodów popełnianych błędów czy nawet nieuczciwości, chciało by zamazać historię albo np. móc kolejny raz oszukać. Takie “łamanie praw” pozostało by tylko “pobożnym życzeniem”, gdyby nie szkodnik w postaci programisty, który powie: ależ ja to bez problemu mogę oprogramować! Jak klient choć raz coś takiego usłyszy, to pojawia się feeria kolejnych podobnych życzeń! Jaki tego efekt? Ano lawina błędów logiki, kolejne wymagania “naprawiające” skutki poprzednich w rodzaju: ujemne stany magazynowe mają zostać bo są fajne, ale proszę dopisać jakieś reguły, żeby raporty magazynowe remanentowe nie pokazywały tego, bo wychodzą głupoty. I tak bez końca… a wdrożenie trwa i trwa i trwa….. jedna “fajna poprawka” i kolejne dziesiątki błędów (lub długie dni korekt wszystkich zależnych funkcji) w innych miejscach systemu.

Nie raz słyszę w firmach programistycznych, że “klient nasz Pan”, a gdy mówię, że to przecież nielogiczne i wywoła błędy w wielu innych miejscach (np. raporty  zawierające dane o ujemnych stanach magazynowych) słyszę: klient płaci to ma, za naprawianie błędów też płaci bo mamy kontrakt “czas i materiał”, i tu wygląda na to, że to ja jestem szkodnikiem, bo nie daję im zarobić, albo w innej sytuacji “czepiam się bo odrzucam  wymagania sponsora projektu”.

Czy to problem małych firm? Średnich? Niedoświadczonych? Czy to jest problem rzadki? Nie! To mega problem, bo takie zapędy mają nie tylko “pracownicy firm”, to zapędy polityków, wszelkich VIP-ów, całych korporacji, wręcz całego społeczeństwa. Co ciekawe, drugim po programistach szkodnikiem, są tu nie raz, o dziwo (mają na studiach logikę!), prawnicy. Dlaczego? Bo u tych obserwuję podobne ciągoty jak u programistów: “klient płaci, klient nasz pan, napiszemy taki paragraf”. W wielu przypadkach programiści i prawnicy to najemnicy, którzy wiedzą, że za takie “łamanie praw” zapłacą i tak ich klienci a nie oni, w końcu “klient sam chciał”, co niestety jest prawdą (ale tylko to, że chciał). Ale dlaczego klient nie dowiaduje się od nich  o ryzyku? A może dowiaduje się i ignoruje je?

Popatrzmy na to:

Kilka tygodni temu Europejski Trybunał zdecydował, że operatorzy wyszukiwarek muszą umożliwić Europejczykom możliwość wpływania na to, jakie informacje o nich prezentowane są w wynikach wyszukiwania. Google już dostosował się do tego orzeczenia i udostępnił użytkownikom stosowne narzędzie przez pierwsze trzy dni skorzystało z niego ponad 40 tys. osób, jednak decyzja trybunału wciąż budzi kontrowersje. Założyciel Wikipedii, Jimmy Wales nie owija w bawełnę ? jego zdaniem ?prawo do bycia zapomnianym? to po prostu cenzura. (Prawo do bycia zapomnianym czy zwykła cenzura? – Computerworld. 20.06.2014)

I to właśnie nie jest nic innego, jak próba łamania praw fizyki. Jak rozumieć “możliwość wpływania na to, jakie informacje o nich prezentowane są w wynikach wyszukiwania”, skoro wyszukiwarka pokazuje (wcześniej opisane gdzieś) fakty , czyli “ma pamięć historii” (podobnie jak każdy człowiek).  Owszem, na pewno jest masa ludzi, chcących czyścić zapisy o swoich “dokonaniach” w przeszłości, ale to jest właśnie próba ingerencji w prawa fizyki (ingerencja w przeszłość, a w pamięć ludzi się da? Też nie.). Czy programista może? Owszem, podobnie jak twórcy kreskówek, może łamać prawa fizyki,  ale kreskówek nikt nie używa jako narzędzia pracy w realnym świecie a oprogramowania tak (choć podobno dzieci oglądające zbyt dużo kreskówek, doznają więcej obrażeń ciała podczas zabaw z rówieśnikami).

Czy to, żądania innych niż w rzeczywistości reguł, ma sens? Nie ma żadnego, bo nawet jeżeli prawnik zapisze w umowie lub ustawie, że “wolno latać machając szybko rękami”, nie zmienia to faktu, że “fizyka mówi, że się nie da” i nikt i tak tą metodą nie poleci. Pierwszy konflikt praw fizyki z programem lub zapisem umownym, wywołuje kolejne żądania  naprawy skutków konkretnego przypadku, co oczywiście w żaden sposób nie chroni przed kolejnymi wpadkami: lawina korekt i narastająca niedoskonałość aplikacji, treści umowy czy ustawy (tak wygląda np. nasze prawo!) tylko podnosi koszt całości.

Długo tu nie trzeba było czekać:

Decyzja Trybunału Sprawiedliwości UE o “prawie do zapomnienia internauty” przez Google przyjęta została entuzjastycznie. Wiadomo – prywatność rzecz święta. Ale jego wprowadzenie wywołało nieprzewidziane skutki [kto nie przewidział?? przyp. mój].

Jak informuje The Guardian, z wyników wyszukiwania przez Google znikają strony z artykułami i felietonami gazety. Teksty te zawierają nazwiska osób, które nie chcą być znalezione w sieci. Zarówno The Guardian, jak i BBC oraz Daily Mail otrzymały powiadomienie (poprzez Google Webmaster Tools) następującej treści: “Z przykrością zawiadamiamy, że z powodów prawnych nie możemy dłużej pokazywać następujących stron z waszej witryny:” – i tu następuje lista linków. (“Prawo do bycia zapomnianym” stwarza dziwne sytuacje. 04-07-2014)

Tak się właśnie kończy z góry przegrana walka z prawami fizyki. Teraz będzie już, z europejskim prawem, tylko coraz gorzej. Nie ma żadnej świętości. Nie chcesz się wstydzić? Nie rób rzeczy wstydliwych! To proste prawdy, proste i niezmienne jak prawa fizyki, walka z nimi jest możliwa tylko w kreskówkach a w oprogramowaniu tylko do czasu, gdy się ono nie zetknie z rzeczywistością i tu zawsze przegra z “prawami fizyki”.

Dlatego zbieranie wymagań tylko metodą spisywania oczekiwań czy wręcz żądań, użytkowników, jest jedną z najgorszych metod pozyskiwania wymagań! Praktycznie zawsze prowadzi do powstawania specyfikacji bardzo złej jakości (niespójne i niekompletne) oraz niekontrolowanego rozrastania się harmonogramu i budżetu projektu. Dostawcy oprogramowania, godzący się na taki styl prowadzenia projektu, świadomie lub nie, działają na szkodę swoich klientów. Analiza systemowa organizacji jako sposób pozyskania wymagań, który chroni przed takimi zjawiskami.

Dlatego pamiętajcie Państwo, nie róbcie sobie krzywdy żądając zachowań systemu nieadekwatnych do rzeczywistości bo zawsze przegracie. Reguły biznesowe, to nic innego jak prawo organizacji, jeżeli będzie ono w zapisach kolidowało w prawami natury i logiką, przegracie. Niestety na Wasz koszt.

“Założyciel Wikipedii, Jimmy Wales nie owija w bawełnę ? jego zdaniem ?prawo do bycia zapomnianym? to po prostu cenzura”. I moim zdaniem ma trochę racji, ale to “prawo” to po protu próba “łamania praw fizyki”, historii nie zmieniamy…

W kwestii chciejstwa ludzi:

Amerykański koncern Google poinformował w czwartek, że w ciągu miesiąca otrzymał 70 tys. wniosków od europejskich użytkowników chcących usunięcia pewnych wyników podawanych przez jego wyszukiwarkę w ramach zagwarantowania “prawa do bycia zapomnianym” (Google otrzymał 70 tys. wniosków o ‘bycie zapomnianym’ – It).

Niestety realnie, w naturze, i tak nikt nie ma gwarantowanego “prawa do bycia zapomnianym”.

2014-11-94 Absurdy idą już jak lawina… Artysta chce, aby usunięto złą recenzję. Wszystko przez absurdalne unijne prawo | Gadżetomania.pl.