Temat: (Anemiczny) Model Dziedziny

Marek K.:
Wątpliwości czy anemiczny model jest modelem obiektowym to false dilema.

dlaczego? albo obiektowy albo nie... kryterium jest proste, co napisałem

To ma się nijak czy programujemy oop bo me czego są klasy abstrakcyjne i modele wielowarstwowe?

to do czego klasy abstrakcyjne zależy od tego w jakim modelu są użyte (model pojęciowy, model struktury, kodu, metamodel...)

modele wielowarstwowe to tylko jakaś architektura lub wzorce projektowe....

nadal nic tu nie tłumaczy tezy jakoby "model anemiczny musiał być".

no i nie mylmy (o ile się już nie powtarzam) projektowania i programowania obiektowego z programowaniem z użyciem narzędzi obiektowych bo to nie to samo...Ten post został edytowany przez Autora dnia 05.02.14 o godzinie 17:56

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:
Wątpliwości czy anemiczny model jest modelem obiektowym to false dilema.

dlaczego? albo obiektowy albo nie... kryterium jest proste, co napisałem

Temat zastępczy. Sedno problemu gdzie indziej. :-/

no i nie mylmy (o ile się już nie powtarzam) projektowania i programowania obiektowego z programowaniem z użyciem narzędzi obiektowych bo to nie to samo...

??? Paradygmaty oop zdefiniowano +- 25 lat temu więc nie zmieniajmy znaczenia pojęć że obiektowy to musi być nie anemiczny.

A teza że nieanemiczny be absurdalna. Nieanemiczny znaczy inny a wywołany dylemat znany odkad ludzie programuja komputery, w szczególności bazy danych. :-/

Zagadnienie czy łączyć dane z regułami ich użycia czy nie łączyć to pytanie jak reprezentować wiedzę. Oba podejścia mają swoje plusy i minusy, am jest szeroko dyskutowane w literaturze AI.

Stopień złożoności zależny od wielkości aplikacji. Problemem nie tworzenie ale aktualizacja edycja i późniejsza rozbudowa. Praktyczny problem rozwiąże aplikacja znająca kilkanaście - kilkadziesiąt reguł biznesowych. Systemy zintegrowane muszą zmierzyć się z kikuset - kilka tysięcy reguł. Systemy rozwiazujące problemy na poziomie eksperckim to powyżej kilkudziesięciu tysięcy reguł.

W tym kontekście odbieranie anemicznemu podejściu prawa dostępu do oop to jakieś kuriozum. :@

Temat: (Anemiczny) Model Dziedziny

Marek K.:

Jarosław Ż.:

Marek K.:
Wątpliwości czy anemiczny model jest modelem obiektowym to false dilema.

dlaczego? albo obiektowy albo nie... kryterium jest proste, co napisałem

Temat zastępczy. Sedno problemu gdzie indziej. :-/

sedno problemu jest tu: albo logika biznesowa (100%) jest w aplikacji i 0% w "bazie danych" i wtedy mamy "obiektowo zorientowany projekt" albo nie...

no i nie mylmy (o ile się już nie powtarzam) projektowania i programowania obiektowego z programowaniem z użyciem narzędzi obiektowych bo to nie to samo...

??? Paradygmaty oop zdefiniowano +- 25 lat temu więc nie zmieniajmy znaczenia pojęć że obiektowy to musi być nie anemiczny.

ja nic nie zmieniam, powtórzę: jeżeli obiektowy to znaczy "współpraca obiektów" a to znaczy, że obiekty nie mogą być "anemiczne" bo anemiczne (bez operacji) nie mają jak wspóracować... to raczej oczywiste (a paradygmat obiektowy to już lata 60te i SMALTALK....)

A teza że nieanemiczny be absurdalna. Nieanemiczny znaczy inny a wywołany dylemat znany odkad ludzie programuja komputery, w szczególności bazy danych. :-/

bazy danych nie są obiektowe a anemiczne właśnie :) dlatego encje nie współpracują a są przetwarzane prze funkcje czyli jak słusznie Pan napisał (metody strukturalne): algorytmy (funkcje) + struktury danych = programy

Zagadnienie czy łączyć dane z regułami ich użycia czy nie łączyć to pytanie jak reprezentować wiedzę. Oba podejścia mają swoje plusy i minusy, am jest szeroko dyskutowane w literaturze AI.

ale to świat zna: po drugie "wiedza" tez ma swoją definicje i jest to, najogólniej rzecz biorąc, wszystko to co można utrwalić i przekazać, i nie należy tego mylić z "umiejętnością" (każdy z nas za darmo ściągnie sobie np. wiedzę o tym jak zagrać mazurka Chopina, nieliczni mają umiejętność zagrania).

AI to ściema... też dużo czytam :), AI to taki YETI, każdy o nim mówi a nikt nie widział ;)

Stopień złożoności zależny od wielkości aplikacji. Problemem nie tworzenie ale aktualizacja edycja i późniejsza rozbudowa.

to już sam napisałem wcześniej

Praktyczny problem rozwiąże aplikacja znająca kilkanaście - kilkadziesiąt reguł biznesowych. Systemy zintegrowane muszą zmierzyć się z kikuset - kilka tysięcy reguł. Systemy rozwiazujące problemy na poziomie eksperckim to powyżej kilkudziesięciu tysięcy reguł.

a jak się to ma do anemicznego modelu?

W tym kontekście odbieranie anemicznemu podejściu prawa dostępu do oop to jakieś kuriozum. :@

w moich oczach kuriozum to traktowanie "anemicznego" modelu jako "obiektowego", zarządzanie wiedzą realizuje praktycznie każdy system biznesowy, ilość tej wiedzy nie ma żadnego znaczenia (poza wpływem na wydajność).

Nadal nie wiemy jak metodą "anemicznego modelu" w zintegrowanej bazie poradzić sobie z tymi adresami na fakturach by nie pakować się w "sprzeczności w bazie".

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:

Jarosław Ż.:

Marek K.:
Wątpliwości czy anemiczny model jest modelem obiektowym to false dilema.

dlaczego? albo obiektowy albo nie... kryterium jest proste, co napisałem

Temat zastępczy. Sedno problemu gdzie indziej. :-/

sedno problemu jest tu: albo logika biznesowa (100%) jest w aplikacji i 0% w "bazie danych" i wtedy mamy "obiektowo zorientowany projekt" albo nie...

Inaczej to postrzegam. Stwierdzenie w aplikacji to za mało. Albo logika biznesowa jest w obiekcie dominującym dane i sposoby ich użycia albo dane i sposoby użycia to różne obiekty.

no i nie mylmy (o ile się już nie powtarzam) projektowania i programowania obiektowego z programowaniem z użyciem narzędzi obiektowych bo to nie to samo...

??? Paradygmaty oop zdefiniowano +- 25 lat temu więc nie zmieniajmy znaczenia pojęć że obiektowy to musi być nie anemiczny.

ja nic nie zmieniam, powtórzę: jeżeli obiektowy to znaczy "współpraca obiektów" a to znaczy, że obiekty nie mogą być "anemiczne" bo anemiczne (bez operacji) nie mają jak wspóracować... to raczej oczywiste (a paradygmat obiektowy to już lata 60te i SMALTALK....)

A teza że nieanemiczny be absurdalna. Nieanemiczny znaczy inny a wywołany dylemat znany odkad ludzie programuja komputery, w szczególności bazy danych. :-/

bazy danych nie są obiektowe a anemiczne właśnie :) dlatego encje nie współpracują a są przetwarzane prze funkcje czyli jak słusznie Pan napisał (metody strukturalne): algorytmy (funkcje) + struktury danych = programy

Zagadnienie czy łączyć dane z regułami ich użycia czy nie łączyć to pytanie jak reprezentować wiedzę. Oba podejścia mają swoje plusy i minusy, am jest szeroko dyskutowane w literaturze AI.

ale to świat zna: po drugie "wiedza" tez ma swoją definicje i jest to, najogólniej rzecz biorąc, wszystko to co można utrwalić i przekazać, i nie należy tego mylić z "umiejętnością" (każdy z nas za darmo ściągnie sobie np. wiedzę o tym jak zagrać mazurka Chopina, nieliczni mają umiejętność zagrania).

AI to ściema... też dużo czytam :), AI to taki YETI, każdy o nim mówi a nikt nie widział ;)

Stopień złożoności zależny od wielkości aplikacji. Problemem nie tworzenie ale aktualizacja edycja i późniejsza rozbudowa.

to już sam napisałem wcześniej

Praktyczny problem rozwiąże aplikacja znająca kilkanaście - kilkadziesiąt reguł biznesowych. Systemy zintegrowane muszą zmierzyć się z kikuset - kilka tysięcy reguł. Systemy rozwiazujące problemy na poziomie eksperckim to powyżej kilkudziesięciu tysięcy reguł.

a jak się to ma do anemicznego modelu?

W tym kontekście odbieranie anemicznemu podejściu prawa dostępu do oop to jakieś kuriozum. :@

w moich oczach kuriozum to traktowanie "anemicznego" modelu jako "obiektowego", zarządzanie wiedzą realizuje praktycznie każdy system biznesowy, ilość tej wiedzy nie ma żadnego znaczenia (poza wpływem na wydajność).

Nadal nie wiemy jak metodą "anemicznego modelu" w zintegrowanej bazie poradzić sobie z tymi adresami na fakturach by nie pakować się w "sprzeczności w bazie".

Temat: (Anemiczny) Model Dziedziny

Marek K.:

Jarosław Ż.:

Marek K.:

Jarosław Ż.:

Marek K.:
Wątpliwości czy anemiczny model jest modelem obiektowym to false dilema.

dlaczego? albo obiektowy albo nie... kryterium jest proste, co napisałem

Temat zastępczy. Sedno problemu gdzie indziej. :-/

sedno problemu jest tu: albo logika biznesowa (100%) jest w aplikacji i 0% w "bazie danych" i wtedy mamy "obiektowo zorientowany projekt" albo nie...

Inaczej to postrzegam. Stwierdzenie w aplikacji to za mało. Albo logika biznesowa jest w obiekcie dominującym dane i sposoby ich użycia albo dane i sposoby użycia to różne obiekty.

Odnoszę wrażenie, że tkwimy w pewnym nieporozumieniu:

1. najniższą warstwą każdego oprogramowania jest utrwalanie (RDBMS ale nie koniecznie). W metodach strukturalnych jest to istotna dla aplikacji "warstwa danych" będąca elementem logiki aplikacji (dane przetwarzane),

2. warstwa taka także występuje w implementacji oprogramowania obiektowego (bo gdzieś to trzeba zachować) ale w tym wypadku jest tylko "prostą pamięcią"; oprogramowanie w paradygmacie obiektowym zupełnie abstrahuje od metod (implementacji) utrwalania, bo żadnej logiki nie trzyma się w "bazach danych" (które mogą być czymkolwiek, nawet plikami CSV), w takim układzie projekt oprogramowania (np. w postaci modeli UML) zawiera 100% logiki w "nieanemicznym modelu dziedziny" (czyli obiekty z widocznymi operacjami i niewidocznymi atrybutami), bo skoro implementacja utrwalania jest niezależna od implementacji logiki i może być czymkolwiek, to znaczy, że żadnej logiki nie ma prawa tam być.

Wydaje mi się, że pisząc o "obiektach" i anemicznym modelu pisze Pan o "encjach" w rozumieniu diagramów ERD a nie o "obiektach" w rozumieniu obiektowego modelu.

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:
Odnoszę wrażenie, że tkwimy w pewnym nieporozumieniu:

Zgadzam się.

.. oprogramowanie w paradygmacie obiektowym zupełnie abstrahuje od metod (implementacji) utrwalania, bo żadnej logiki nie trzyma się w "bazach danych" ..

??? Nie w utrwalaniu rzecz a w przypisywaniu wartości. Logika to wiedzieć jak wyliczyć wartość i to uczynić. Samo utrwalenie tej wartości to już formalność.

A co do logiki w bazie danych to chociażby układ tabel, definicje pól ją zawierają więc z tym deklarowaniem nie trzymania logiki przez bazę byłbym bardziej ostrożny. Domyślam się, że tu jest nawiązanie do logiki wyższego rzędu ale mimo wszystko w większości przypadków to odcięcie to raczej nasza intencja niż stan faktyczny. ;-(

Wydaje mi się, że pisząc o "obiektach" i anemicznym modelu pisze Pan o "encjach" w rozumieniu diagramów ERD a nie o "obiektach" w rozumieniu obiektowego modelu.

Nie. Piszę o klasach definiujących obiekty które mogą reprezentować tylko ich properties (nawiązanie do encji) albo ich properties i metody (nawiązanie do oop). Properties w tym kontekście to dane. Logika biznesowa to oczywiście metody.

Anemia nie uwzględnia metod - ok, ale nie sugerujmy, że to ma się nijak do obiektowości, bo to w niczym wykorzystania tej obiektowości nie blokuje i że to beee z obiektowego punktu widzenia. Dziedziczenie i dołożenie metod "piętro wyżej" przenosi tę logikę do innej warstwy, co wcale nie jest bardziej ułomnym rozwiązaniem niż aplikowanie tego w jednej warstwie. ;-)

Temat: (Anemiczny) Model Dziedziny

proszę to odnieść do faktu, że obiektowo zorientowany projekt ma "pod sobą" niczym niepowiązane "dane" w plikach, tablicach itp... żadnych "relacji" między nimi, nie licząc oczywiście tego, że np. znalezienie tego samego NIP na fakturze i karcie klienta daje możliwość ich skojarzenia ale to skojarzenie będzie efektem działania metody klasy szukającej tych skojarzeń, skojarzenie to (ta logika) nie będzie w żaden sposób "zapisana" na "dysku"...

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:
proszę to odnieść do faktu, że obiektowo zorientowany projekt ma "pod sobą" niczym niepowiązane "dane" w plikach, tablicach itp... żadnych "relacji" między nimi, ..

Ale jeżeli nie wskażemy powiązań, relacji to przecież nie mamy modelu biznesowego. :-( Mając tylko dane nikt nie napisze żadnej aplikacji. Potrzebna jest przecież dodatkowa wiedza co i jak zrobić, więc przyznam, że nie rozumiem uwagi. :-(

Temat: (Anemiczny) Model Dziedziny

Marek K.:

Jarosław Ż.:
proszę to odnieść do faktu, że obiektowo zorientowany projekt ma "pod sobą" niczym niepowiązane "dane" w plikach, tablicach itp... żadnych "relacji" między nimi, ..

Ale jeżeli nie wskażemy powiązań, relacji to przecież nie mamy modelu biznesowego. :-(

A czym tu jest model biznesowy?

Mając tylko dane nikt nie napisze żadnej aplikacji. Potrzebna jest przecież dodatkowa wiedza co i jak zrobić, więc przyznam, że nie rozumiem uwagi. :-(

Napisze... na podstawie nieanemicznego modelu obiektowego (czyli pełnego obiektowego projektu aplikacji) zawierającego komplet potrzebnych klas, każda z atrybutami i operacjami.

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:

Jarosław Ż.:
proszę to odnieść do faktu, że obiektowo zorientowany projekt ma "pod sobą" niczym niepowiązane "dane" w plikach, tablicach itp... żadnych "relacji" między nimi, ..

Ale jeżeli nie wskażemy powiązań, relacji to przecież nie mamy modelu biznesowego. :-(

A czym tu jest model biznesowy?

Dane bez wiedzy po co, jak, .. to informacja niekompletna. Model biznesowy jest tym czego tu brakuje. ;-)

Mając tylko dane nikt nie napisze żadnej aplikacji. Potrzebna jest przecież dodatkowa wiedza co i jak zrobić, więc przyznam, że nie rozumiem uwagi. :-(

Napisze... na podstawie nieanemicznego modelu obiektowego (czyli pełnego obiektowego projektu aplikacji) zawierającego komplet potrzebnych klas, każda z atrybutami i operacjami.

Jeżeli znane są operacje to jest wiedza co i jak, więc gdzie różnica pomiędzy nami? Przecież ja o sytuacji kiedy to co i jak nie jest znane, czyli o sytuacji kiedy projekt jest dzielony na części: anemiczny model wykorzystywany do budowy bazy danych (i któremu odbierane jest prawo do obiektowości) oraz model opisujący wszelkie akcje.

Temat: (Anemiczny) Model Dziedziny

Marek K.:
Jeżeli znane są operacje to jest wiedza co i jak, więc gdzie różnica pomiędzy nami?

tu, że "konstrukcja" (struktura) programu "obiektowego" nie rozdziela danych od tego do czego służą, oraz że nie jest tworzony w ogóle współdzielony model (skład) danych. Tu (obiektowość) niczego się nie normalizuje do żadnej, nie tylko trzeciej czy innej postaci. Dlatego "dane" faktur i "dane" kontrahentów (moje poprzednie pytanie) nie są wspołdzielone a powielane... dzięki czemu:
- nie ma miejsca na jakiekolwiek "sprzeczności w bazie"
- kontrahent zna swój aktualny adres
- adres historyczny zawsze znajdę w historycznej fakturze
- mogę w dowolnym momencie oddzielić "moduł" Kontrahenci od faktur bez żad ej szkody i potrzeby modyfikacji
- dane zahermetyzowane w klasach (najwyżej agregatach) sa proste i i nie występuje problem spadku wydajności z powodu rosnącej złożoności zapytań SQL"

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:
Jeżeli znane są operacje to jest wiedza co i jak, więc gdzie różnica pomiędzy nami?

tu, że "konstrukcja" (struktura) programu "obiektowego" nie rozdziela danych od tego do czego służą, oraz że nie jest tworzony w ogóle współdzielony model (skład) danych. Tu (obiektowość) niczego się nie normalizuje do żadnej, nie tylko trzeciej

Ale ja nie w ty temacie się odezwałem. Po prostu nie uważam że anemiczny model jest be i że należy odbierać ot prawo do obiektowości. Nie. Pa sytuacje kiedy jest on niezastąpiony a tworzona w łęgu użyciem aplikacja może być tworzona oop.

Temat: (Anemiczny) Model Dziedziny

Marek K.:

Jarosław Ż.:

Marek K.:
Jeżeli znane są operacje to jest wiedza co i jak, więc gdzie różnica pomiędzy nami?

tu, że "konstrukcja" (struktura) programu "obiektowego" nie rozdziela danych od tego do czego służą, oraz że nie jest tworzony w ogóle współdzielony model (skład) danych. Tu (obiektowość) niczego się nie normalizuje do żadnej, nie tylko trzeciej

Ale ja nie w ty temacie się odezwałem. Po prostu nie uważam że anemiczny model jest be i że należy odbierać ot prawo do obiektowości. Nie. Pa sytuacje kiedy jest on niezastąpiony a tworzona w łęgu użyciem aplikacja może być tworzona oop.

ustalmy może wiec co nazywamy "modelem dziedziny", bo ja używam go "po bożemu" w kontekście "obiektowego modelu dziedziny oprogramowania" (projektowanego metodami obiektowymi)...

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:

Jarosław Ż.:

Marek K.:
Jeżeli znane są operacje to jest wiedza co i jak, więc gdzie różnica pomiędzy nami?

tu, że "konstrukcja" (struktura) programu "obiektowego" nie rozdziela danych od tego do czego służą, oraz że nie jest tworzony w ogóle współdzielony model (skład) danych. Tu (obiektowość) niczego się nie normalizuje do żadnej, nie tylko trzeciej

Ale ja nie w ty temacie się odezwałem. Po prostu nie uważam że anemiczny model jest be i że należy odbierać ot prawo do obiektowości. Nie. Pa sytuacje kiedy jest on niezastąpiony a tworzona w łęgu użyciem aplikacja może być tworzona oop.

ustalmy może wiec co nazywamy "modelem dziedziny", bo ja używam go "po bożemu" w kontekście "obiektowego modelu dziedziny oprogramowania" (projektowanego metodami obiektowymi)...

OK. Nie widzę powodów tego zmieniać.

Za ważniejsze pozwolę sobie uznać jednak coś innego, określenie celu. To ten element uważam za istotny z punktu widzenia kiedy mówimy beee, a kiedy cacy.

Kiedy napisałem, że modelowanie to nie programowanie, to na myśli miałem nie to, żeby zabronić modelarzowi prawa do programowania, nie to że używać można różnych narzędzi lub tp. . Nie.

Modelowanie to nie programowanie ponieważ różni je cel. Zadaniem modelarza jest zrozumieć biznes (rozpoznać ograniczenia, wyjątki, zagrożenia, itd., itp.) i opisać go w sposób zrozumiały dla twórcy oprogramowania. Zadaniem programisty jest napisać aplikację.

Tych dwoje ludzi tworzy więc różny model dziedziny, modelarz bazując na wymaganiach prawnych, procesach biznesowych, itd. itp., programista na modelu biznesowym modelarza. W szczególnym przypadku (małe aplikacje) oba modele mogą być takie same (mamy więc jeden model). W przypadku dużego projektu, nie ma szans na identyczność - dlaczego już było.

Nie widzę więc przeszkód aby modelarz tworzył obiektowy model dziedziny lecz bądźmy konsekwentni i nie odsądzajmy od czci i wiary developera, jeżeli ten zechce obiektowy model modelarza zastąpić na potrzeby tworzenia aplikacji modelem anemicznym dziedziny bo np: staje przed wyborem spełnienia sprzecznych wymagań w jednej aplikacji.

Nie. Model anemiczny nie przeszkodzi developerowi w dalszej pracy oop jeżeli tylko tak postanowi. ;-)

Temat: (Anemiczny) Model Dziedziny

Marek K.:
Modelowanie to nie programowanie ponieważ różni je cel.

Nie tyle modelowanie a projektowanie architektury, to wazne bo "modelarz" to nie opowiadacz historii a projektant architektury 9części biznesowej) tego co powstanie...

Zadaniem modelarza jest zrozumieć biznes (rozpoznać ograniczenia, wyjątki, zagrożenia, itd., itp.) i opisać go w sposób zrozumiały dla twórcy oprogramowania. Zadaniem programisty jest napisać aplikację.

to jest zadanie "opisywacza historii", analityk to tak na prawdę także projektant, ktoś kto rozumie to co się dzieje i jak i zapisze to w postaci obiektowej czyli gotowej do dalszej pracy nad implementacją. (tu wpadamy w DDD)

Reszta Pana opisu to "stare czasy" gdy jeden coś tam opisywał prozą lub obrazkami (bo nie były to modele, zresztą tak wygląda nadal 90% tak zwanych analiz) a inny zaczynał od projektowania 'modelu danych" a potem pisało się funkcje...

Tych dwoje ludzi tworzy więc różny model dziedziny,

jeżeli tworzą róny to jest masakra w projekcie

modelarz

nie ma takiej roli w sensownych projektach

bazując na wymaganiach prawnych, procesach biznesowych, itd.

analityk-projektant modeluje metodami obiektowymi szkielet oprogramowania (częśc dziedzinową) jaki powstanie: logika będzie zawarta w operacjach klas (a wymagane informacje w ich hermetyzowanych atrybutach)

Nie widzę więc przeszkód aby modelarz tworzył obiektowy model dziedziny lecz bądźmy konsekwentni i nie odsądzajmy od czci i wiary developera, jeżeli ten zechce obiektowy model modelarza zastąpić na potrzeby tworzenia aplikacji modelem anemicznym

u mnie sie to nazywa "implementacja niezgodna z projektem" i w skrajnym wypadku zerwanie umowy bez wynagrodzenia dla developera :) do czego mam pełne prawo zlecając wykonanie oprogramowania jako umowe o dzieło.

:)

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:
Modelowanie to nie programowanie ponieważ różni je cel.

Nie tyle modelowanie a projektowanie architektury, to wazne bo "modelarz" to nie opowiadacz historii a projektant architektury 9części biznesowej) tego co powstanie...

Posłużyłem się językiem potocznym aby przedstawić to co najistotniejsze. Wiadomo, że w rzeczywistości są różne role, jest różna struktura uprawnień i odpowiedzialności więc są tacy co opowiadają, są tacy co projektują projekty, są tacy co projektują w ramach tego co inni projektowali, ale dalsze rozbudowywanie niniejszego to logomachia.

Reszta Pana opisu to "stare czasy" gdy jeden coś tam opisywał prozą lub obrazkami (bo nie były to modele, zresztą tak wygląda nadal 90% tak zwanych analiz) a inny zaczynał od projektowania 'modelu danych" a potem pisało się funkcje...

?? Są projekty, których inaczej się nie "ugryzie".

Tych dwoje ludzi tworzy więc różny model dziedziny,

jeżeli tworzą róny to jest masakra w projekcie

Masakra jeżeli są sprzeczne, niekompletne, itd, itp.. Różny użyłem w znaczeniu inny a nie błędny i ja to akceptuję. Przecież ktoś może to samo chcieć robić inaczej niż mnie się wydaje, bo może ku temu mieć istotne powody, których ja nie znam.

Nie widzę więc przeszkód aby modelarz tworzył obiektowy model dziedziny lecz bądźmy konsekwentni i nie odsądzajmy od czci i wiary developera, jeżeli ten zechce obiektowy model modelarza zastąpić na potrzeby tworzenia aplikacji modelem anemicznym

u mnie sie to nazywa "implementacja niezgodna z projektem" i w skrajnym wypadku zerwanie umowy bez wynagrodzenia dla developera :) do czego mam pełne prawo zlecając wykonanie oprogramowania jako umowe o dzieło.

Jeżeli w umowie było, że nie wolno inaczej to nie protestuję.

No i proszę się zdecydować, czy są rzeczy mało realne, o czym była mowa na samym początku dyskusji. W nowych, małych projektach nie widzę przeszkód aby było tak jak Pan chce. Dzisiaj jest tego dużo więc latami można być w tym zanużonym. ;-) Ale jest równie duża grupa projektów bez szans na Pana porozumienie z developerami. ;-(

Dziękuję za dyskusję. Dalsze jej kontynuowanie to mogła by być czysta sofistyka. Nie ma takiej potrzeby. EOT

Temat: (Anemiczny) Model Dziedziny

Marek K.:

Jarosław Ż.:

Marek K.:
Modelowanie to nie programowanie ponieważ różni je cel.

uważam, że modelowanie to pierwszy etap i cel jest ten sam: ma powstać oprogramowanie zgodne z czyimiś oczekiwaniami.

Reszta Pana opisu to "stare czasy" gdy jeden coś tam opisywał prozą lub obrazkami (bo nie były to modele, zresztą tak wygląda nadal 90% tak zwanych analiz) a inny zaczynał od projektowania 'modelu danych" a potem pisało się funkcje...

?? Są projekty, których inaczej się nie "ugryzie".

jeszcze nie trafiłem na taki... ale wiele przede mną.

Przecież ktoś może to samo chcieć robić inaczej niż mnie się wydaje, bo może ku temu mieć istotne powody, których ja nie znam.

wtedy ma swój inny projekt, to tak jak by Pan zaprojektował sobie łazienkę a fachowiec zrobił "też użyteczenie ale inaczej"...

u mnie sie to nazywa "implementacja niezgodna z projektem" i w skrajnym wypadku zerwanie umowy bez wynagrodzenia dla developera :) do czego mam pełne prawo zlecając wykonanie oprogramowania jako umowe o dzieło.

Jeżeli w umowie było, że nie wolno inaczej to nie protestuję.

umowa o dzieło ma zawsze (u mnie) opis "dzieła" czyli jego dokumentację, innych nie zawieram, bo po co ???

No i proszę się zdecydować, czy są rzeczy mało realne, o czym była mowa na samym początku dyskusji. W nowych, małych projektach nie widzę przeszkód aby było tak jak Pan chce.

to nie jest "jak ja chcę" tylko to jest jedna z uznanych metod pracy, małe projekty raczej się robi "od ręki" bo małe jest ich ryzyko a koszt analizy i testowania relatywnie duży (swego czasu liczyłem granicę, poniżej 75 tys. z reguły nie ma sensu bawić się w analizy i projektowanie), w dużych trzeba najpierw myśleć, potem testować koncepcję (architekturę - studium wykonywalości) a na końcu dopiero kodować, wybór metody utrwalania (czyli projektowanie ewentualnej bazy) także na końcu a nie na początku, ale tu mówię o metodzie pracy, i jak widać nie jedynej... są różne, ja ich nie wartościuje ale obserwuje ryzyka projektowe.

Dzisiaj jest tego dużo więc latami można być w tym zanużonym. ;-) Ale jest równie duża grupa projektów bez szans na Pana porozumienie z developerami. ;-(

wiem i wcale nad tym nie ubolewam, dodam, że jest tu ma Pan rację - faktycznie większość jaką spotykam , ale też dodam, że w zasadzie jestem angażowany przy drugim, trzecim podejściu do projektu, prawie nigdy do pierwszego podejścia, być może ma to związek z tym co Pan napisał: "większość robi inaczej"... ale ja akurat z tą większością się absolutnie nie identyfikuję...

Dziękuję za dyskusję. Dalsze jej kontynuowanie to mogła by być czysta sofistyka. Nie ma takiej potrzeby. EOT

też sądzę, że nie ma już takiej potrzeby, cały czas traktuję tę, i podobne dyskusje, tylko jak wymianę poglądów i w moich oczach tylko taka ma sens, przekonywanie się "co lepsze" nie ma tu faktycznie sensu, robią to skuteczniej klienci.

Dziękuję za podzielenie się poglądami i pozdrawiam

EOT