Temat: Analiza obiektowa

Analiza to nie zbieranie informacji a rozkładanie "organizacji" na "czynniki pierwsze". Tymi czynnikami pierwszymi są elementy budulcowe, proste klasy itp. UML i wzorce ... więcej tu:

http://it-consulting.pl/autoinstalator/wordpress/2012/...

Czy jako analitycy stosujecie wzorce projektowe?

Temat: Analiza obiektowa

Zasadniczo uważam, że wzorce projektowe nie są dla analityków. Dla analityków są wzorce analizy.
Tzn. uważam, że jest w kompetencji wykonawcy czy będzie korzystał z wzorca Factory czy z wzorca Builder - natomiast w kompetencji analityka, czy postawi własne wymagania na dziedzinę związaną z kontrahentem, czy skorzysta z wzorca Party, autorstwa Fowlera.

Temat: Analiza obiektowa

Mateusz Kurleto:
Zasadniczo uważam, że wzorce projektowe nie są dla analityków. Dla analityków są wzorce analizy.

owszem ale nie wyodrębnia się ich... niestety

Tzn. uważam, że jest w kompetencji wykonawcy czy będzie korzystał z wzorca Factory czy z wzorca Builder - natomiast w kompetencji analityka, czy postawi własne wymagania na dziedzinę związaną z kontrahentem, czy skorzysta z wzorca Party, autorstwa Fowlera.

Faktem jest, że "fabryka" na etapie analizy jest tu metaforą fabryki abstrakcyjnej, buildera czy prototypu. Jednak sens polega na oddzieleniu w analizie i projekcie 'tworzenia" od "używania" klas (agregatów) ... :), masz rację, że wybór ostatecznej implementacji tego wzorca jest decyzją developera ale moim zdaniem nie powinien on (nie może bez konsultacji z autorem) zrezygnować z Fabryki i wtrynić "New" jako własną operację klasy tworzonej.

P.S.
Spotkałeś się gdzieś z "czystymi" wzorcami analitycznymi? Ja jedynie w DDD (tu mamy tylko fabrykę jako "klasę odpowiedzialną za tworzenie obiektów", builder, prototyp itp. to wzorce projektowe z poza DDD) Jarek Żeliński edytował(a) ten post dnia 12.10.12 o godzinie 23:24

Temat: Analiza obiektowa

Jarek Żeliński:
Faktem jest, że "fabryka" na etapie analizy jest tu metaforą fabryki abstrakcyjnej, buildera czy prototypu. Jednak sens polega na oddzieleniu w analizie i projekcie 'tworzenia" od "używania" klas (agregatów) ... :), masz rację, że wybór ostatecznej implementacji tego wzorca jest decyzją developera ale moim zdaniem nie powinien on (nie może bez konsultacji z autorem) zrezygnować z Fabryki i wtrynić "New" jako własną operację klasy tworzonej.

Dla mnie to poprostu standard wytwórczy. Już nie tylko my - jako firma - nie potrzebujemy w modelu domeny fabryk - nasi programiści sami wiedzą, że klasa sama sobą nie zarządza, więc nawet na etapie projektu za wyjątkiem naprawde skomplikowanych elementów nie ma sensu przekazywać czegokolwiek więcej niż modelu domeny.

P.S.
Spotkałeś się gdzieś z "czystymi" wzorcami analitycznymi? Ja jedynie w DDD (tu mamy tylko fabrykę jako "klasę odpowiedzialną za tworzenie obiektów", builder, prototyp itp. to wzorce projektowe z poza DDD)

Nie bardzo - niektóre Fowlera jedynie - jak np. Party wspomniane.

Temat: Analiza obiektowa

Jarek Żeliński:
Analiza to nie zbieranie informacji a rozkładanie "organizacji" na "czynniki pierwsze". Tymi czynnikami pierwszymi są elementy budulcowe,

Tak

proste klasy itp. UML i wzorce ...

Nie, bo nie dla analityka "rozkładającego organizację na czynniki pierwsze".

To są owszem czynniki pierwsze ale dla programisty i kadry zarządzającej wykonawcami. Łączenie tych rzeczy to gwałt na metodologii, która dzisiaj wyraźnie oddziela model biznesowy od modelu logicznego, a tym bardziej od modelu fizycznego. :-(

To, że dzisiaj przejście z jednego do drugiego modelu oddziela jeden click, wcale nie upoważnia analityka "rozkładającego organizację na czynniki pierwsze" do jego wykonania. :-( Samoograniczenie bezcenne. ;-)

Temat: Analiza obiektowa

@J: Czy jako analitycy stosujecie wzorce projektowe?
- nie stosujemy, bo nie ma porozumienia co do innych warunków kiedy można te wzroce - jak i inne zdobycze dziedziny - zastosować.
'Zbieranie informacji' - tak decydujący uparcie chcą rozumieć rolę analityka i ciężko o przełożenie między koncepcją analityczną a architekturą rozwiązania.

Nnoo a jeśli nawet - to wzroce projektowe niespecjalnie, ale wzorce _projektowania *) - owszem! - i to z namaszczeniem:
*) obiektowego (OOP): np: SRP (Single Responsibility Principle), OCP, LSP, ISP, .. .
Ja do wzorców analitycznych co prawda nie mam przekonania _praktycznego (co nie przeszkadza mi uznawać Fowlera za Biblę.), jednak zarówno te analityczne jak i projektowe - uczą _myślenia. Konstruowania.

Rozwiązania bezwzorcowe mogą być sobie poprawne (choć zwykle nie są, ale to głównie z inych powodów), ale oczywiście bedą różnić się jak podróż w kosmos wahadłowcem od podróży magnetokraftem. (czyli kosztami na wiecznosć : ) )

Btw, po wzorcach jest jeszcze jeden poziom tajemniczenia: ANTYWZORCE (i te analityczne **), projektowe ***). programowe ***), konfiguracji,.. etc) - wszystko to układa w głowie raz na zawsze pewne strategie organizacji zależnosci)

**) np. Phony requirements
***)np. Anemiczny model dziedziny (p. Jarosław tutaj odezwie się dzwonem (i słusznie)), Spaghetti code (-> Spaghetti analysis)
w zasadzie wiele koncepcji wzorcowych można odnosić na wielu poziomach zastosowań - od abstrakcji do realizacji.

Pozdrawiam, (wzrocowo).

Temat: Analiza obiektowa

Moim zdaniem, przede wszystkim, należy mieć na uwadze wzorce (zasady?) GRASP. Pamiętając o nich, nawet bez używania wzorców projektowych (chociaż nie jestem pewny, czy taki zabieg byłby możliwy do zrealizowania:), produkt końcowy powinien być bardzo dobrej jakości.
No i oczywiście DDD :)

Temat: Analiza obiektowa

Dla mnie to poprostu standard wytwórczy. Już nie tylko my - jako firma - nie potrzebujemy w modelu domeny fabryk - nasi programiści sami wiedzą, że klasa sama sobą nie zarządza, więc nawet na etapie projektu za wyjątkiem naprawde skomplikowanych elementów nie ma sensu przekazywać czegokolwiek więcej niż modelu domeny.

dotknąłeś drażliwej sprawy: nie każdy zespół developerski tam ma, po drugie znam fajne firmy/zespoły programistyczne, które oczekuje właśnie takich informacji o architekturze. Po trzecie życie mnie nauczyła, żeby nie liczyć na "rzeczy oczywiste" dla developera ;) bo nie dla każdego sa one oczywiste ;)))

Temat: Analiza obiektowa

Marek Kubiś:

Jarek Żeliński:
Analiza to nie zbieranie informacji a rozkładanie "organizacji" na "czynniki pierwsze". Tymi czynnikami pierwszymi są elementy budulcowe,

Tak

proste klasy itp. UML i wzorce ...

Nie, bo nie dla analityka "rozkładającego organizację na czynniki pierwsze".

to jaki "zestaw czynników pierwszych" widzisz dla analityka?

To są owszem czynniki pierwsze ale dla programisty i kadry zarządzającej wykonawcami. Łączenie tych rzeczy to gwałt na metodologii, która dzisiaj wyraźnie oddziela model biznesowy od modelu logicznego, a tym bardziej od modelu fizycznego. :-(

diagram klas i wspomniane wzorce to nie tylko "poziom fizyczny", to dowolnie wysoki poziom abstrakcji. Np. DDD to dość wysoki poziom abstrakcji.

To, że dzisiaj przejście z jednego do drugiego modelu oddziela jeden click, wcale nie upoważnia analityka "rozkładającego organizację na czynniki pierwsze" do jego wykonania. :-( Samoograniczenie bezcenne. ;-)

nie upoważnia ale tez i nie zabrania, z mojego doświadczenia mogę powiedzieć, że kluczowym problemem jaki obserwuję jest częste upraszczanie przez developerów modeli logiki bo dzięki temu mają "mniej klepania", po drugie nie potrafią stosować metod obiektowych co zabija ich zalety (szczególnie hermetyzacja i właściwy podział odpowiedzialności klas i interfejsów). Po trzecie pewne konstrukcje są konsekwencją logiki biznesowej, której developer najczęściej nie zna (nie jest ekspertem od zarządzania i ma prawo jej nie rozumieć) i nie musi.

Z praktyki powiem, że nie raz muszę chronić projekty przez developerem bo trafia się np. "głęboko wierzący w bazy w 3. postaci normalnej" i normalizuje diagram klas modelu dziedziny albo inny, który nie widzi żadnego powodu by komplikować system oddzielaniem metod wytwórczych od klas tworzonych, mogę tak długo.

Swego czasu wysiadł mi zamek centralny w samochodzie, podjechałem do podobno dobrego warsztatu, mechanik przyjrzał się i mówi: "Panie, założę Panu proste zamki, te elektryczne są skomplikowane, psuja się i sam Pan tego nie naprawi, po co to panu"... szybko wyjechałem z tego warsztatu...

I na koniec: uważam, że model dziedziny (logika biznesowa w postaci obiektowej) to wymaganie a nie projekt developerski, tak samo jak model procesów biznesowych w BPMN, tu moim zdaniem developer realizuje a nie "tworzy po swojemu" bo nie ma żadnych podstaw by dyskutować z zasadami biznesu. Tak samo jak murarz stawiający dom, który ma wykonać projekt a nie dyskutować o tym gdzie jest ścianka działowa pomiędzy kuchnią a kibelkiem bo "on by ją wstawił gdzie indziej"...

Temat: Analiza obiektowa

Katarzyna Korcewicz:
- nie stosujemy, bo nie ma porozumienia co do innych warunków kiedy można te wzroce - jak i inne zdobycze dziedziny - zastosować.

porozumienia może nie, mi osobiście bardzo podoba się koncepcja DDD bo sprowadza analizę do poziomi siedmiu, nawet nie wzorców (bo to chyba faktycznie nadużycie), a "konstruktów" (Evans: building blocks DDD):




(źr. Sławek Sobótka)

nie ma tu mim zdaniem "wchodzenia" w kompetencje developera ale ma on ograniczenie "swobody swojej twórczości" i o to chodzi. Ma swobodę implementacji każdego z tych bloków więc ma kupę roboty.

powyższe w moich oczach jak najbardziej można stosować...

więcej tu:
http://it-consulting.pl/autoinstalator/wordpress/2011/...

P.S.
Nie wiem skąd mit, że tylko programiści mają moralne prawo projektowania logiki oprogramowania...Jarek Żeliński edytował(a) ten post dnia 13.10.12 o godzinie 11:05

Temat: Analiza obiektowa

Jarek Żeliński:

Dla mnie to poprostu standard wytwórczy. Już nie tylko my - jako firma - nie potrzebujemy w modelu domeny fabryk - nasi programiści sami wiedzą, że klasa sama sobą nie zarządza, więc nawet na etapie projektu za wyjątkiem naprawde skomplikowanych elementów nie ma sensu przekazywać czegokolwiek więcej niż modelu domeny.

dotknąłeś drażliwej sprawy: nie każdy zespół developerski tam ma, po drugie znam fajne firmy/zespoły programistyczne, które oczekuje właśnie takich informacji o architekturze. Po trzecie życie mnie nauczyła, żeby nie liczyć na "rzeczy oczywiste" dla developera ;) bo nie dla każdego sa one oczywiste ;)))

To już kwestia tego jakiego dewelopera zatrudniasz. Chciałem też zauważyć, że analityk nie powinien zajmować się architekturą rozwiązania. Analityk jest od odpowiedzi na pytanie co i dlaczego - a nie jak.
Myślę, zresztą, że jeśli zespół wytwórczy sam nie zna zasad OOP to żaden poziom szczegółowości modelu domeny mu nie pomoże, bo i tak go nie zrozumie i każdy będzie pisał co chce tak długo aż ktoś to odbierze.Mateusz Kurleto edytował(a) ten post dnia 13.10.12 o godzinie 11:07

Temat: Analiza obiektowa

Mateusz Kurleto:
To już kwestia tego jakiego dewelopera zatrudniasz.

dlatego od pewnego czasu w dokumentacji wymagań zawsze umieszczam zapis o wymaganiach wobec wykonawcy, który to zapis zresztą znasz :)

Chciałem też zauważyć, że analityk nie powinien zajmować się architekturą rozwiązania. Analityk jest od odpowiedzi na pytanie co i dlaczego - a nie jak.

architekturą nie, ale realizowaną logiką biznesową jak najbardziej tak, w końcu to ja odpowiadam (ja opisuję wymagania) czy oprogramowanie poprawnie realizuje reguły biznesowe wiążące zamówienia z fakturami i reklamacjami a nie programista...

Jeżeli dzielimy zwyczajowo wymagania na funkcjonalne i poza-funkcjonalne to moim zdaniem za realizację (a wcześniej udokumentowanie) pierwszych odpowiada analityk a drugich developer, bo logikę biznesową developer implementuj a nie projektuje. Po drugie fajną rzecz usłyszałem kiedyś od architekta:

"jeżeli jako architekt biurowca, po rozmowie z klientem, jestem przekonany, że ścianki działowe powinny być wykonane z płyty gipsowo-kartonowej, to wpisuję to do projektu, żeby przypadkiem ktoś nie postawił jej z cegły tylko dlatego, że mu tak wygodniej".

I jestem głęboko przekonany do tego podejścia. Owszem architekt po politechnice doskonale wie jaka jest różnica i jakościowa i kosztowa pomiędzy tymi rozwiązaniami, uważam, że analityk biznesowy w IT nie znający bardzo dobrze metod obiektowych (zakładam, że takie są te projekty) będzie tylko dyktafonem kolekcjonującym życzenia zamawiającego, a to w wielu przypadkach wręcz szkodliwa działalność... :(

Temat: Analiza obiektowa

Mateusz Kurleto:
Dla mnie to poprostu standard wytwórczy. Już nie tylko my - jako firma - nie potrzebujemy w modelu domeny fabryk - nasi programiści sami wiedzą, że klasa sama sobą nie zarządza, więc nawet na etapie projektu za wyjątkiem naprawde skomplikowanych elementów nie ma sensu przekazywać czegokolwiek więcej niż modelu domeny.

Ale czym jest model domeny? Powinien zawierać obiekty biznesowe, działania biznesowe (usługi) i ich logikę. Ta logika to operacje, które trzeba powiązać z tymi miejscami, których dotyczą. Jeżeli model dziedziny nie ma być "anemiczny" to musi zawierać klasy nie tylko z atrybutami ale także z operacjami bo one także "trzymają" reguły biznesowe.

Jeżeli odkrywam w firmie szczególne sposoby kojarzenia klientów z ich zamówieniami to wskazuję (tworzę) atrybuty klas, które pozwalają te skojarzenia wykonać. Jeżeli do tego odkrywam, że "klient to podmiot, który dokonał ostatniego zamówienia nie dawniej niż 6 m-cy temu" to nie pozostaje mi nic innego jak "zaprojektować" w modelu dziedziny klasę, która za realizację tej reguły odpowiada, nazwać ją i przydzielić jej jakąś odpowiedzialność bo zapewne będą jeszcze inne podobne reguły ...

tak więc model dziedziny to na pewno nie "namiastka bazy danych" jak sądzi wielu developerów (Ciebie o to nie posądzam ;))... w modelu dziedziny pojawią się więc klasy: usługi, agregaty itp...

Temat: Analiza obiektowa

Marek Kubiś:
to gwałt na metodologii, która dzisiaj wyraźnie oddziela model biznesowy od modelu logicznego, a tym bardziej od modelu fizycznego. :-(

Jak udokumentować model biznesowy by był jednoznaczny jako zadanie implementacji dla developera?

Jeżeli nie jest modelem biznesowym ani fizycznym to czym jest model logiczny i kto powinien za tę logikę odpowiadać?Jarek Żeliński edytował(a) ten post dnia 13.10.12 o godzinie 12:19

Temat: Analiza obiektowa

Jarek Żeliński:
to jaki "zestaw czynników pierwszych" widzisz dla analityka?

Na poziomie ogółu: biblioteka ITIL, norma ISO 20000 (w szczególności Part 2: Code of practice). Na poziomie szczegółu wspomniane przez Panią Katarzynę wzorce projektowania (SRP, OCP, LSP, ISP, ..) czy może trafniej nazywając to o co chodzi (aby nie narażać się na pomyłkę z wzorcami projektowymi) - best practises.

nie upoważnia ale tez i nie zabrania,

dlatego napisałem o samoograniczaniu. ;-)

z mojego doświadczenia mogę powiedzieć, że kluczowym problemem jaki obserwuję jest częste upraszczanie przez developerów modeli logiki bo dzięki temu mają "mniej klepania"

To "typowy" problem w każdej bez wyjątku pracy z ludźmi.

po drugie nie potrafią stosować metod obiektowych

Zmienić

Po trzecie pewne konstrukcje są konsekwencją logiki biznesowej, której developer najczęściej nie zna (nie jest ekspertem od zarządzania i ma prawo jej nie rozumieć) i nie musi.

??? Na jakiej podstawie oczekiwać realizacji logiki biznesowej kiedy ktoś jej nie zna? A konstrukcje zależne od logiki biznesowej to typowy błąd projektanta w zakresie Interface Segregation Principle (ISP).

Tak samo jak murarz stawiający dom, który ma wykonać projekt a nie dyskutować o tym gdzie jest ścianka działowa pomiędzy kuchnią a kibelkiem bo "on by ją wstawił gdzie indziej"...

Ale my nie dyskutujemy o tym, że murarz dyskutuje gdzie ma być ścianka działowa, bo taką dyskusję ucina się krótko, tylko raczej o tym, że ten murarz jak wykonuje tę ściankę to powinien wiedzieć czy ma użyć płytę karton-gips, czy cegłę i w tym kontekście kto ma mu tę informację przekazać: pani która zamieszka w tym mieszkaniu, agent nieruchomości lub ich przedstawiciel (nasz analityk) czy architekt/kierownik budowy (szef projektu IT, kierownik programistów). Ja uważam, że ten drugi.

Jak udokumentować model biznesowy by był jednoznaczny jako zadanie implementacji dla developera?

Testami akceptacyjnymi. Ktoś kto opracowuje model biznesowy powinien koncentrować się na testach, które użyje aby prace odebrać. Jeżeli dodatkowo zależy mu na tym aby można było projekt dalej kontynuować, rozwijać w określonym kierunku, to oceniać należy interfejs, a nie czy klasy są ładne (zasada Open Closed Principle, OCP).

Jeżeli nie jest modelem biznesowym ani fizycznym to czym jest model logiczny i kto powinien za tę logikę odpowiadać?

Szef programistów.

Temat: Analiza obiektowa

Marek Kubiś:

Jarek Żeliński:
to jaki "zestaw czynników pierwszych" widzisz dla analityka?

Na poziomie ogółu: biblioteka ITIL, norma ISO 20000 (w szczególności Part 2: Code of practice). Na poziomie szczegółu wspomniane przez Panią Katarzynę wzorce projektowania (SRP, OCP, LSP, ISP, ..) czy może trafniej nazywając to o co chodzi (aby nie narażać się na pomyłkę z wzorcami projektowymi) - best practises.

powyższe nie jest żadną listą elementów składowych czy wzorców a listą dobrych praktyk i zaleceń

nie upoważnia ale tez i nie zabrania,

dlatego napisałem o samoograniczaniu. ;-)

jak tu rozumieć samoograniczanie? Bo ja raczej widzę samoograniczenie "aby programista nie wymyślał biznesu jeżeli go nie zna"... i drugie poważniejsze "aby nikt sam sobie nie stawiał wymagań a potem ich nie akceptował"

z mojego doświadczenia mogę powiedzieć, że kluczowym problemem jaki obserwuję jest częste upraszczanie przez developerów modeli logiki bo dzięki temu mają "mniej klepania"

To "typowy" problem w każdej bez wyjątku pracy z ludźmi.

wiec trzeba z nim walczyć :)

po drugie nie potrafią stosować metod obiektowych

Zmienić

nauczyć ich? jestem za :)

Po trzecie pewne konstrukcje są konsekwencją logiki biznesowej, której developer najczęściej nie zna (nie jest ekspertem od zarządzania i ma prawo jej nie rozumieć) i nie musi.

??? Na jakiej podstawie oczekiwać realizacji logiki biznesowej kiedy ktoś jej nie zna?

no właśnie, więc analityk po stronie zamawiającego ma robotę... zna się na tym i ma dać opis tej logiki najlepiej w postaci "kompatybilnej" z narzędziami develelopera.

A konstrukcje zależne od logiki biznesowej to typowy błąd projektanta w zakresie Interface Segregation Principle (ISP).

to kiepski projektant... i nie dyskutujemy tu i ISP, tę zasadę także znam.

Tak samo jak murarz stawiający dom, który ma wykonać projekt a nie dyskutować o tym gdzie jest ścianka działowa pomiędzy kuchnią a kibelkiem bo "on by ją wstawił gdzie indziej"...

Ale my nie dyskutujemy o tym, że murarz dyskutuje gdzie ma być ścianka działowa, bo taką dyskusję ucina się krótko, tylko raczej o tym, że ten murarz jak wykonuje tę ściankę to powinien wiedzieć czy ma użyć płytę karton-gips, czy cegłę i w tym kontekście kto ma mu tę informację przekazać: pani która zamieszka w tym mieszkaniu, agent nieruchomości lub ich przedstawiciel (nasz analityk) czy architekt/kierownik budowy (szef projektu IT, kierownik programistów). Ja uważam, że ten drugi.

architekt (dom tej Pani) to osoba, która po rozmowie z nią zaprojektowała dom i tę ściankę - to jego rola.

Jak udokumentować model biznesowy by był jednoznaczny jako zadanie implementacji dla developera?

Testami akceptacyjnymi.

Uuuuuuuu, to tylko badanie czarnej skrzynki, testy akceptacyjne jako metoda odbioru są bardzo dobre, jako metoda definiowania wymagań - najgorsza... bo nie wiem co dostanę dopóki nie dostanę.

Dawno temu Rosjanie kopiowali amerykańskie układy scalone metodą badania reakcji na bodźce elektryczne. To są właśnie przypadki użycia i testy akceptacyjne, ale oni oddali by dużo by dostać projekt logiki tych układów do ich wytworzenia ... nie mieli tych projektów z wiadomych powodów. Jako zamawiający wolę dać developerowi projekt logiki a przypadki użycia jako testy bo to pewniejsze, łatwiejsze i mniej ryzykowne a przede wszystkim mniej kosztowne (co potwierdza moja praktyka od lat): wycena i wytworzenie na bazie tylko przypadków użycia do wyceny na bazie projektu obiektowego ma się nie raz jak 10:1.

Nie rozumiem po skazywać developera na "badanie czarnej skrzynki" i kosztowne próby odtworzenia jej wnętrza, skoro to wnętrze jest znane: idę do klienta, modeluje to jak on pracuje, i daje na tacy developerowi już w postaci modelu dziedziny (i tylko to) i tak ma on kupę roboty z implementacją np. wymagań jakościowych czy GUI.

Ktoś kto opracowuje model biznesowy powinien koncentrować się na testach, które użyje aby prace odebrać.

z tym się nie zgodzę, to podejście "dostawcy". Ja uważam, że ktoś kto opracowuje model biznesowy powinien zadbać o to by był jak najwierniejszy i jak najtańszy w implementacji (czyli pozostawiający jak najmniej na błędy interpretacji wykonawcy).

Jeżeli dodatkowo zależy mu na tym aby można było projekt dalej kontynuować, rozwijać w określonym kierunku, to oceniać należy interfejs, a nie czy klasy są ładne (zasada Open Closed Principle, OCP).

nie widzę związku, "ładne klasy" (co to znaczy ładne?) to klucz do łatwości rozbudowy - zawsze, po drugie dobry projekt, także logiki, to projekt bazujący na interfejsach i nie widzę tu kolizji z tym co napisałem a nawet ma to - OCP- głęboki sens.

Jeżeli nie jest modelem biznesowym ani fizycznym to czym jest model logiczny i kto powinien za tę logikę odpowiadać?

Szef programistów.

a co on ma do zrozumienia biznesu klienta i jego sensu? Szef programistów odpowiada za implementację a nie za model biznesowy zamawiającego. No i o jaką logikę chodzi, bo logika biznesowa a logika architektury oprogramowania jako całości to dwie różne rzeczy. Jedyne co mają wspólnego to to, że logika biznesowa jest celem projektu z perspektywy zamawiającego i jest zawarta gdzieś w środku całości.

Padały tu różne zgrabne skróty: SRP, OCP, LSP, ISP ale to dobre praktyki i zalecenia analizy i projektowania obiektowego, wzorce projektowe to pewne sposoby (ale nie recepty) rozwiązywania pewnych typowych problemów. Większość z nich:

http://pl.wikipedia.org/wiki/Wzorzec_projektowy_(infor...

to wzorce stosowane w ogólnie pojętym programowaniu obiektowym, ale programowanie zawsze poprzedza (powinno) analiza problemu i projektowanie. Na etapie analizy większość tych wzorców nie ma zastosowania (np. obserwator czy pyłek) ale kilka jednak tak.

"Moje przesłanie" w tym tekście: skoro logikę biznesową także "programuje się" (implementuje się) z użyciem obiektowych wzorców projektowych, to ideałem jest sytuacja by wskazać te wzorce, które wg. najlepszych praktyk są wykorzystywane do implementacji logiki biznesowej i uczynić z nich "klocki", na które należy na etapie analizy biznesowej rozłożyć problem. To się nazywa DDD czyli siedem wzorców spośród wielu do modelowania wymagań na logikę biznesową..

Korzyści są ogromne, bo "wycinamy" etap głuchego telefonu między Zamawiającym i wymaganiami w postaci prozy i tabel a developerem. Dając mu obiektowy model czegoś, czego tak na prawdę nie rozumie, unikam efektu głuchego telefonu bo opis prozą jest niestety bardzo niejednoznaczny i podatny na przekłamania (głuchy telefon).

Nigdy nie mogę zrozumieć, developerów, którzy uważają, że nikt poza nimi nie ma prawa robić modelu dziedziny (logiki biznesowej w postaci obiektowej)...

Temat: Analiza obiektowa

Jarek Żeliński:
Analiza to nie zbieranie informacji a rozkładanie "organizacji" na "czynniki pierwsze". Tymi czynnikami pierwszymi są elementy budulcowe, proste klasy itp. UML i wzorce ... więcej tu:

http://it-consulting.pl/autoinstalator/wordpress/2012/...

Czy jako analitycy stosujecie wzorce projektowe?

Mam małą uwagę: MVC nie jest wzorcem projektowym, ale architektonicznym.

Temat: Analiza obiektowa

Jarek Żeliński:
Analiza to nie zbieranie informacji a rozkładanie "organizacji" na "czynniki pierwsze". Tymi czynnikami pierwszymi są elementy budulcowe, proste klasy itp. UML i wzorce ... więcej tu:

http://it-consulting.pl/autoinstalator/wordpress/2012/...

Czy jako analitycy stosujecie wzorce projektowe?

Zasadniczo wszystko zależy od tego, jaki zakres obowiązków ma analityk. Wzorce projektowe, jak sama nazwa wskazuje, dotyczą projektowania, więc projektanta. O ile analityk projektuje system na poziomie klas z pewnością powinien poznać czym są wzorce.

Z wzorcami trzeba uważać. Przy małym doświadczeni łatwo wpaść w zachwyt tego rodzaju rozwiązaniami i dążyć do jak największego stosowania tych wzorców. Wzorce są pomyślane jako wzorowe rozwiązania typowych problemów i tak trzebi je odbierać. Mogą stanowić inspirację do nietypowych problemów, lub ułatwiać refaktoryzację architektury i kodu.

Sam osobiście na nowo zebrałem i ujednoliciłem wzorce w ramach nauki. Dało to dla mnie wielką wartość. Polecam również wszystkim, zanim się weźmie jakiś wzorzec i realizację jego w konkretnym języku, sprawdzić do czego służy oraz jakie są jego alternatywne realizacje.

Temat: Analiza obiektowa

Jarek Żeliński:

Marek Kubiś:

Jarek Żeliński:
to jaki "zestaw czynników pierwszych" widzisz dla analityka?

Na poziomie ogółu: biblioteka ITIL, norma ISO 20000

powyższe nie jest żadną listą elementów składowych czy wzorców a listą dobrych praktyk i zaleceń

Ale pytanie było o "zestaw czynników pierwszych" a nie o listę elementów składowych i dla mnie to jest właśnie taki zestaw.

nie upoważnia ale tez i nie zabrania,

dlatego napisałem o samoograniczaniu. ;-)

jak tu rozumieć samoograniczanie? Bo ja raczej widzę samoograniczenie "aby programista nie wymyślał biznesu jeżeli go nie zna"... i drugie poważniejsze "aby nikt sam sobie nie stawiał wymagań a potem ich nie akceptował"

Ale kontekst pytania dotyczył analityka i w tym temacie aby analityk biznesowy nie wtrącał się w szczegóły warsztatu programisty

z mojego doświadczenia mogę powiedzieć, że kluczowym problemem jaki obserwuję jest częste upraszczanie przez developerów modeli logiki bo dzięki temu mają "mniej klepania"

To "typowy" problem w każdej bez wyjątku pracy z ludźmi.

wiec trzeba z nim walczyć :)

I się walczy. :-(

po drugie nie potrafią stosować metod obiektowych

Zmienić

nauczyć ich? jestem za :)

Tak

??? Na jakiej podstawie oczekiwać realizacji logiki biznesowej kiedy ktoś jej nie zna?

no właśnie, więc analityk po stronie zamawiającego ma robotę... zna się na tym i ma dać opis tej logiki najlepiej w postaci "kompatybilnej" z narzędziami develelopera.

Rolą analityka biznesowego jest właściwe rozpracowanie procesów biznesowych tak w kontekście misji/wizji biznesów, celów do osiągnięcia, struktury organizacyjnej, aktualnie obowiązujących wymagań prawnych, analizy tendencji rynkowych i trafnego przewidywania kierunku zmian tak w bliższej i dalszej przyszłości, a nie nauka wszystkich narzędzi developerskich. Analityk biznesowy, jak dla mnie, powinien siedzieć z nosem w Dziennikach Ustaw, w dokumentacji procesów biznesowych, rozmawiać z ludźmi którzy później z projektowanym systemem będą pracować aby trafnie podać co i jak ma być zrobione, a nie bawić się nowymi "tips & tricks" kolejnego narzędzia.

Jak udokumentować model biznesowy by był jednoznaczny jako zadanie implementacji dla developera?

Testami akceptacyjnymi.

Uuuuuuuu, to tylko badanie czarnej skrzynki, testy akceptacyjne jako metoda odbioru są bardzo dobre, jako metoda definiowania wymagań - najgorsza... bo nie wiem co dostanę dopóki nie dostanę.

STOP. Jak nie wiem co dostanę to znaczy, że źle wykonałem projekt i specyfikację wymagań!

Dawno temu Rosjanie kopiowali amerykańskie układy scalone

To przykład układu niediagnozowalnego jako czarna skrzynka. Jeżeli analityk biznesowy opracowując projekt nie przewidział, że coś musi być "Design for testability" i później nie wie jak przekonać się co dostał, to znaczy że nie rozumie biznesu, który rozpracowuje i źle wykonał swoją pracę. Kłania się zasada Open Closed Principle, OCP.

Nie rozumiem po skazywać developera na "badanie czarnej skrzynki" i kosztowne próby odtworzenia jej wnętrza,

??? Odtwarzanie wnętrza - po co? Duże koszty badań? - zrozumieć co to znaczy "ready to test"!!!

Ktoś kto opracowuje model biznesowy powinien koncentrować się na testach, które użyje aby prace odebrać.

z tym się nie zgodzę, to podejście "dostawcy". Ja uważam, że ktoś kto opracowuje model biznesowy powinien zadbać o to by był jak najwierniejszy i jak najtańszy w implementacji (czyli pozostawiający jak najmniej na błędy interpretacji wykonawcy).

A ja uważam, że model biznesowy musi gwarantować osiąganie celów biznesowych z uwzględnieniem wymagań prawnych. Jeżeli projekt biznesowy to program komputerowy, to analitykowi nic do ceny i co najwyżej może kierując się swoimi kryteriami poszukiwać wykonawców z którymi chciałby pracować. Wykonawca (wykonawcy) dostają wymagania, przedstawiają swoją ofertę, także cenową, a klient porównując z tym co i za ile dostępne wybiera spośród przedstawionych opcji i decyduje.

dobry projekt, także logiki, to projekt bazujący na interfejsach i nie widzę tu kolizji z tym co napisałem a nawet ma to - OCP- głęboki sens.

Ale jest próba ingerencji dużo dalej niż interfejs. A to już niezgodne z best practice.

Jeżeli nie jest modelem biznesowym ani fizycznym to czym jest model logiczny i kto powinien za tę logikę odpowiadać?

Szef programistów.

a co on ma do zrozumienia biznesu klienta i jego sensu?

Nic i tak ma być.

Padały tu różne zgrabne skróty: SRP, OCP, LSP, ISP ..
Na etapie analizy większość tych wzorców nie ma zastosowania (np. obserwator czy pyłek) ale kilka jednak tak.

Nie-pra-wda. Właśnie na etapie analizy ich znaczenie jest ogromne, co również podkreśliła Pani Katarzyna "i to z namaszczeniem". Proszę jeszcze raz przeczytać jej opinię.

"Moje przesłanie" w tym tekście: skoro logikę biznesową także "programuje się" (implementuje się) z użyciem obiektowych wzorców projektowych, to ideałem jest sytuacja by wskazać te wzorce, które wg. najlepszych praktyk są wykorzystywane do implementacji logiki biznesowej i uczynić z nich "klocki", na które należy na etapie analizy biznesowej rozłożyć problem. To się nazywa DDD czyli siedem wzorców spośród wielu do modelowania wymagań na logikę biznesową..

To jest rola analityka IT ale po stronie wykonawcy a nie po stronie biznesu i to są dwie całkiem różne osoby pracujące w różnych obszarach odpowiedzialności. Czym powinien wg mnie zajmować się analityk biznesowy już napisałem.

Korzyści są ogromne, bo "wycinamy" etap głuchego telefonu między Zamawiającym i wymaganiami w postaci prozy i tabel a developerem. Dając mu obiektowy model czegoś, czego tak na prawdę nie rozumie, unikam efektu głuchego telefonu bo opis prozą jest niestety bardzo niejednoznaczny i podatny na przekłamania (głuchy telefon).

Tak się da z małymi projektami. W dużych i/lub skomplikowanych projektach analityków musi być conajmniej dwóch.

Nigdy nie mogę zrozumieć, developerów, którzy uważają, że nikt poza nimi nie ma prawa robić modelu dziedziny (logiki biznesowej w postaci obiektowej)...

Bo zapewne uważają, że powinni dostać prawdziwy opis dziedziny, a nie opis obiektowy, który ma ogromne szanse być niekompletnym, niewłaściwym, gdyż procesy biznesowe to często skomplikowany system naczyń połączonych z licznymi wyjątkami i sprzężeniami zwrotnymi, do opisu których użycie klas nie jest ani zrozumiałym ani żadną best practise.

Temat: Analiza obiektowa

Aleksander Olszewski:
Mam małą uwagę: MVC nie jest wzorcem projektowym, ale architektonicznym.

architektura także jest projektowana, ja nie widzę różnicy, to tylko kwestia poziomu ogólności modelu, nie tylko Fowler nie dzieli wzorców na projektowe i archtektoniczne bo trudno taki podział obronić.