Tytułowy pro­blem ma chy­ba każ­dy począt­ku­ją­cy . Jak słusz­nie zauwa­żył autor poniż­sze­go tekstu:

Eksperci od obiek­to­we­go podej­ścia do pro­ce­su two­rze­nia opro­gra­mo­wa­nia dzie­lą się na dwa obo­zy, w zależ­no­ści od pro­po­no­wa­ne­go przez nich spo­so­bu iden­ty­fi­ka­cji klas:

W opar­ciu o odpo­wie­dzial­no­ści klas (RDD – Responsibility Driven Design) – naj­pierw roz­po­zna­wa­ne są wszyst­kie odpo­wie­dzial­no­ści sys­te­mu (na pod­sta­wie potrzeb przy­szłych użyt­kow­ni­ków), a następ­nie, bazu­jąc na tych odpo­wie­dzial­no­ściach, wyróż­nia­ne są kla­sy, któ­rym przy­pi­su­je się odpo­wie­dzial­no­ści sys­te­mu. W ten spo­sób defi­niu­je się odpo­wie­dzial­no­ści klas, któ­re odpo­wia­da­ją zbio­ro­wi zacho­wań ich obiek­tów. Przykładem tego podej­ścia jest wyko­rzy­sty­wa­na w nie­któ­rych meto­dy­kach meto­da CRC.

W opar­ciu o dane (DDD – Data Driven Design) – podej­ście to pole­ga na iden­ty­fi­ko­wa­niu wszyst­kich danych w sys­te­mie i podzia­le ich na kla­sy, bez spe­cjal­ne­go roz­wa­ża­nia ich odpo­wie­dzial­no­ści. Przykładem tej tech­ni­ki jest iden­ty­fi­ka­cja rze­czow­ni­ków i fraz rze­czow­ni­ko­wych w tek­ście wyma­gań użytkownika. )

Niestety dalej jest gorzej bo autor tek­stu poświę­cił się prak­tycz­nie w cało­ści meto­dzie opar­tej na danych. Napisał Wyróżnianie klas poprzez iden­ty­fi­ka­cję rze­czow­ni­ków i fraz rze­czow­ni­ko­wych w tek­ście spe­cy­fi­ku­ją­cym wyma­ga­nia użyt­kow­ni­ka jest jed­ną z pod­sta­wo­wych i powszech­nie sto­so­wa­nych tech­nik.”. Zgodzę z bólem z tym, że jest to meto­da naj­czę­ściej sto­so­wa­na, jed­nak nie jest to pod­sta­wo­wa meto­da. Bazowanie, w ana­li­zie obiek­to­wej, na danych pro­wa­dzi pro­stą dro­gą do powsta­nia kon­struk­cji w posta­ci antyw­zor­ca o nazwie [[ane­micz­ny model dzie­dzi­ny]]. Ta meto­da ma rodo­wód z rela­cyj­ne­go mode­lu danych, gdzie dane iden­ty­fi­ko­wa­ne były wła­śnie jako rze­czow­ni­ki, z tego powo­du, że dane to z natu­ry rzeczowniki.

Nieco dalej autor pisze: Identyfikacja aso­cja­cji. Sposób postę­po­wa­nia przy iden­ty­fi­ka­cji aso­cja­cji jest podob­ny do spo­so­bu iden­ty­fi­ka­cji klas, z tą róż­ni­cą, że w tek­ście wyma­gań zamiast rze­czow­ni­ków (ogól­nie: fraz rze­czow­ni­ko­wych) wyszu­ki­wa­ne są cza­sow­ni­ki (ogól­nie: fra­zy cza­sow­ni­ko­we). Zgodnie z tą zasa­dą z powyż­sze­go przy­kła­du z biblio­te­ką moż­na wyde­du­ko­wać aso­cja­cje: wypo­ży­czy­ła (od fra­zy wypo­ży­czać”) oraz jest egzem­pla­rzem (od fra­zy może być kil­ka egzem­pla­rzy tej samej książ­ki”).”. W kon­se­kwen­cji poja­wia się idea (i potrze­ba) sto­so­wa­nia klas pośred­ni­czą­cych czy­li kon­struk­cji rodem z z mode­lu rela­cyj­ne­go, sto­so­wa­nych w celu roz­wią­zy­wa­nia związ­ków wie­le do wie­lu” (nie­do­pusz­czal­nych w mode­lu rela­cyj­nym a dopusz­czal­nych w mode­lu obiek­to­wym). Niestety to podej­ście to kon­se­kwen­cja trak­to­wa­nia dia­gra­mu klas jako mode­lu danych, co jest kom­plet­nym nie­po­ro­zu­mie­niem, jeśli uznać, że para­dyg­mat obiek­to­wy to uzna­nie, że sys­tem to zbiór obiek­tów współ­pra­cu­ją­cych w okre­ślo­nym celu” .

Autor koń­czy roz­dział tego pod­ręcz­ni­ka” dla stu­den­tów (PJWSTK) przy­kła­dem o nazwie Diagram klas dla biblioteki”. 

Jednak dia­gram klas to nota­cja, a model (wyko­na­ny z uży­ciem tej nota­cji) może być albo mode­lem poję­cio­wym albo mode­lem struk­tu­ry sys­te­mu o okre­ślo­nym pozio­mie abs­trak­cji. Przykłady tam poda­ne to w zasa­dzie antyw­zor­ce (patrz tak­że M.Fowler: Anemic Domain Model): model z dzie­dzi­cze­niem nie­spe­cjal­nie nada­je się na model dzie­dzi­ny z uwa­gi na to, że dzie­dzi­cze­nie łamie zasa­dy uni­ka­nia ści­słych zależ­no­ści” (uży­cie dzie­dzi­cze­nia bar­dzo sil­nie uza­leż­nia wszyst­kie kla­sy pochod­ne od uogól­nia­ją­cych na szczy­cie hie­rar­chii). Zaś kom­po­zy­cje nie są sto­so­wa­ne w mode­lach poję­cio­wych, bo mode­le poję­cio­we to słow­ni­ki pojęć w for­mie gra­ficz­nej. Pojęcia mogą być z sobą powią­za­ne (aso­cja­cje) ale nie ma tu licz­no­ści czy zawie­ra­nia się w sobie (czy książ­ka skła­da się z egzem­pla­rzy książek”???).

Osobiście radzę ana­li­ty­kom i pro­jek­tan­tom sku­pić się na pro­jek­to­wa­niu obiek­tów, któ­re współ­pra­cu­ją: mają odpo­wie­dzial­no­ści i komu­ni­ku­ją się wywo­łu­jąc swo­je ope­ra­cje. Dane to pro­blem na sam koniec ana­li­zy a nie jest to coś, od cze­go nale­ży ja zaczy­nać. Karty CRC są dosko­na­łym narzę­dziem dla począt­ku­ją­cych, ana­li­za rze­czow­ni­ków chy­ba najgorszym.

Na koniec pole­cam jed­nak książ­ki, któ­re na stro­nach blo­ga cytu­ję (jeże­li już ktoś uwa­ża, że moje tek­sty są mało wiarygodne ;)).

Źródła

Wirfs-Brock, R., & McKean, A. (2009). Object design: roles, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley.
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.