Read more about the article Związki w UML czyli abstrakcja vs rzeczywistość
#1 - a 3d render series showing change and motion

Związki w UML czyli abstrakcja vs rzeczywistość

Wstęp Tym razem o kilku powszechnie popełnianych błędach w korzystaniu z UML. Chodzi o pojęcia abstrakcji, metamodeli i zależności oraz o związki między elementami na diagramach. Kluczową, moim zdaniem, przyczyną tworzenia "złych" modeli obiektowych jest używanie notacji UML do tworzenia modeli strukturalnych, nie mających z obiektowym paradygmatem nic wspólnego. Druga to niezrozumienie pojęcia paradygmatu obiektowego. Ogromna ilość diagramów wykonanych z  użyciem symboli notacji UML, z UML i paradygmatem obiektowym ma niewiele wspólnego. Najpierw kilka definicji i pojęć. Paradygmat programowania (ang. programming paradigm) ? wzorzec programowania komputerów przedkładany w danym okresie…

Czytaj dalejZwiązki w UML czyli abstrakcja vs rzeczywistość

Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pewnie wielu z Was czeka, tak przynajmniej sugerują listy do mnie i głosy na forach, a także potencjalni klienci. Ci, których niestety czasem krytykuję, także pewnie czekają. Pokażę na prostym przykładzie, proces od analizy przez wymagania aż do projektu dedykowanego oprogramowania. Całość będzie zgodna z fazami CIM/PIM (www.omg.org/mda). Projekt dziedziny, który powstanie będzie spełniał zasady SOLID projektowania obiektowego, projektowania przez kompozycje (zamiast dziedziczenia)  (polecam artykuł Łukasza Barana)  i DDD. Opis dotyczy każdego projektu związanego z oprogramowaniem, także gotowym np. ERP, CRM, EOD itp.

Korzystałem z opisu zasad gry w szachy zamieszczonego na WIKI:

Zasady gry w szachy ? prawidła regulujące sposób rozgrywania partii szachów. Choć pochodzenie gry nie zostało dokładnie wyjaśnione, to współczesne zasady ukształtowały się w średniowieczu. Ewoluowały one do początków XIX wieku, kiedy to osiągnęły właściwie swą bieżącą postać. W zależności od miejsca zasady gry różniły się od siebie, współcześnie za przepisy gry odpowiada Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się różnić w przypadku różnych wariantów gry, np. dla szachów szybkich, błyskawicznych czy korespondencyjnych. (Zasady gry w szachy ? Wikipedia, wolna encyklopedia).

To na co chcę zwrócić tu uwagę w szczególności, to metafora:

projektując (modelując) oprogramowanie dla człowieka, modelujemy narzędzie dla tego człowieka a nie jego samego.

Swego czasu pisałem, w artykule o nazywaniu klas,  że oprogramowanie z reguły zastępuje dotychczasowe narzędzie człowieka a nie człowieka jako takiego. Druga ważna rzecz: aktor jest równoprawnym elementem systemu (tu systemem jest organizacja z jej ludźmi i używanymi przez nich narzędziami). No to zaczynamy.

(więcej…)

Czytaj dalejPlansza do gry w szachy czyli analiza i projektowanie

Bo banki od wszystkiego są do niczego czyli złe modele dziedziny

Swego czasu na jednej z konferencji o analizie wymagań, mówiłem o potrzebie zrozumienia funkcjonowania analizowanej organizacji (firmy): ...wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Pamiętajmy, że jedna z najtrudniejszych gier na świecie ? szachy ? to tylko kilkanaście figur i proste reguły ich przemieszczania. Nawet największą organizację można, w toku analizy, rozłożyć na skończoną liczbę ról i reguł ich postępowania i zrozumieć jej funkcjonowanie. (żr. Jarosław Żeliński, referat na konferencji o systemach ERP). Analiza biznesowa to etap opisu (zrozumienia) modelowanej organizacji (modele procesów itp.). Potem, powstaje model rozwiązania, którym jest nie raz własnie oprogramowanie, jego logika (patrz powyższy cytat) to "obiektowy model dziedziny systemu", a nie jakiś diagram klas nafaszerowany atrybutami i pozbawiony operacji bo jest dokładnie odwrotnie...

Czytaj dalejBo banki od wszystkiego są do niczego czyli złe modele dziedziny

Koniec treści

Nie ma więcej stron do załadowania