Temat: Diagram E/R w UML?
Jakub Wojt:
...
Ok. Koniec zabawy :) Podaj proszę konkretny (bez nazwisk, cytatów i mądrości ludu IT) powód przewagi E/R nad UML.
Czytając twoje wypowiedzi zaczynam powątpiewać w celowość rolowania tego samego, ale spróbuję jeszcze raz opisać jak powinien (może) wyglądać proces projektowania warstwy danych i warstwy aplikacji.
W zamierzchłych czasach królowała architektura dwuwarstwowa typu klient-serwer. Gdzieś (w sieci lub na tym samym komputerze) był kombajn wykonujący wszystkie skomplikowane operacje i przechowujący dane. Natomiast tu (na własnym komputerze) była powłoka maksymalnie ułatwiająca operacje na tamtym kombajnie. Był to znaczący progres w porównaniu z aplikacjami wszystko tu u klienta, ale od lat używa się architektury trójwarstwowej i nieco krócej architektury wielowarstwowej (w tym SOA). Dlatego, że im więcej niezależnych warstw, tym jest mniejszy problem do rozwiązania, a wymiana takiej warstwy na nowszą lub inną jest o wiele mniej problematyczna.
Skupię się tu na architekturze trójwarstwowej, dlatego, że jest na tyle prosta, że może uda mi się w kilku akapitach wyjaśnić o co chodzi, a zarazem jest wystarczająco zaawansowana, by nie mówić o banałach. Najniższa warstwa odpowiada za dane. Jest to warstwa niezależna od pozostałych i opisuje ten aspekt rzeczywistości, który można opisać danymi. Aby to zrobić, trzeba te dane zamodelować, by opisywały biznesowe zapotrzebowanie w informacje. Podczas modelowania danych należy bezwzględnie posługiwać się przyjętymi standardami (najlepiej ISO). ISO opisuje zadziwiająco wiele różnych rzeczy: kody krajów, kody walut, numery telefonów, współrzędne geograficzne, adresy IP itd. Cokolwiek pomyślimy zostało prawdopodobnie ustandaryzowane. Jeśli nie ma standardu, trzeba posługiwać się przyjętymi krajowymi (lub międzynarodowymi) normami. Tak jak widzisz tu modelujemy uniwersalną rzeczywistość.
Takie modelowanie powinno zawierać cztery bardzo ważne kroki: logiczny model danych, normalizacja (najlepiej do 3NF), fizyczny model danych (uwzględnienie technicznych osobliwości silnika bazodanowego), ewentualna denormalizacja danych spowodowana osobliwościami silnika bazodanowego (np. tylko ORACLE ma wbudowane operacje na strukturach drzewiastych, w innych silnikach trzeba to samemu zaimplementować) lub osobliwościami biznesu (np. mamy wyszukiwać również po firmowemu ID, które przez lata zmieniało formaty i stanowi unikatowy identyfikator tylko z datą). Modele te są szalenie ważne by zbudować bardziej zaawansowane zapytanie niż do jednej tabeli. Modele te stanową techniczną specyfikację dla wyższej niezależnej warstwy. Modele możemy opisywać za pomocą IDEF1X, ER lub I/E (kurza łapka). Generalnie model logiczny trzeba wykonać jak najprościej i konceptualnie. A fizyczny na podstawie logicznego. Notacja I/E stała się powszechnym standardem i zawiera to czego diagram klas nie ma: klucze główne, klucze obce i widoki.
Na wyższej warstwie --- warstwie aplikacji znajduje się model dziedziny biznesu. Są to rzeczy typowe i specyficzne dla biznesu. I teraz jeśli zdecydujemy się na obiektowy język programowania nie mamy wyboru. Jest tylko UML, bo powstał jako kompromis różnych ośrodków i jest ustandaryzowany i ciągle rozwijany. I właśnie ten model dziedziny projektujemy innym narzędziem niż bazę, bo zawiera wiele różnych elementów właściwych dla tego konkretnego biznesu. Nie zawiera on algorytmów, a jedynie rzeczy architektoniczne. Jeśli programista potrzebuje zaprojektować jakieś algorytm, to nadal są aktualne diagramy blokowe, np. metoda
Oferta.znajdźNajbliższą(latitude, longitude)
nie mówi jak to powinno być zaimplementowane, i jeśli chcemy uprawiać geometrię sferyczną powinniśmy się zastanowić nad właściwym algorytmem i ewentualnie go rozrysować. Tu jak widzisz modelujemy specyfikę biznesu.
Trzecia warstwa to warstwa prezentacji. Tu możemy się popisać znajomością ergonomii i wiedzą o statystycznych rozkładach różnych elementów interfejsu. Ale nie przychodzimy z tym do klienta jako pierwszą rzeczą do zrobienia. Jest to najmniej trwała warstwa i najszybciej poddaje się różnym modom i trendom. Tu możemy pogenerować mockupy. Tu modelujemy grupowe przyzwyczajenie do interfejsów użytkownika.
U tu przechodzę do sedna sprawy. Są tacy, i to nie żart, co potrafią za pomocą mockupów opisać cały system: dane, dziedzinę biznesu i prezentację (do tego akurat służą). Pytanie brzmi czy powinno się tak robić, bo przecież się da :) Większość programistów wściekłości dostaje na widok okienka z kilkoma przyciskami typu znajdź (w domyśle ofertę położoną najbliżej geograficznie do IP komputera który tą operację zlecił). Pytanie jest takie: co pomyślał klient, co zrozumiał projektant, a co zrobi z tym programista?
I/E jest proste i zawiera unikatowe elementy relacyjnych baz danych, UML jest wszechstronne i zawiera osobliwości systemów biznesowych. Są to dwa zbiory rozłączne. Są systemy bez baz danych, są bazy danych bez systemów. Są też bazy i systemy bez interfejsu użytkownika (udostępniają tylko interfejsy programistyczne). Nie rozumiem co na silę próbujesz udowodnić? Że da się jedną tabelę zamodelować jedną klasą? Średniej wielkości system internetowy ma 50-100 tabel, dziedzina biznesu może się składać z kilkuset tabel. Jak to chcesz ogarnąć narzędziem, które do tego nie służy?
пропозиції роботи
