Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości

Regularnie obserwuję pewną trudność jaką sprawia wielu ludziom, z jednej strony stosowanie systemów notacyjnych a z drugiej samo modelowanie. Wspólną częścią obu tych obszarów jest abstrahowanie od szczegółów. Praktycznie każdy mój klient i bardzo często, analitycy i projektanci developerów realizujących projekty które nadzoruję, zadają mi pytania: a gdzie zobaczę to, że zamówienie może być dla innego produktu i innego segmentu..... itp.  Innymi słowy: na dowolnym etapie pracy padają pytania o bardzo detaliczne szczegóły konkretnych operacji. Co prawda, jak to mawiają "diabeł tkwi w szczegółach", z czym wypada się zgodzić, ale…

Czytaj dalejAnaliza a modelowanie czyli ile abstrakcji a ile rzeczywistości

Diagram prawdę Ci powie

Dzisiaj będzie bardzo krótki wpis, którym niemalże w całości będzie cytat z artykułu pewnego programisty. Każdy analityk i projektant powinien  przeczytać cały artykuł (nie jest długi) i koniecznie komentarze pod nim. Jeden komentarz zacytuje bo jest znamienny, choćby dlatego, że moje doświadczenia są dokładnie takie same: Co Ty człowieku, życia nie znasz? Przecież w realu jakbyś poszedł do takiego i podzielił się takimi uwagami  to foch na pare tygodni co najmniej gwarantowany. Kiedyś miałem podobną sytuację (a raczej serię sytuacji, ale dotyczących rzeczy o mniejszej skali) to efekt był taki,…

Czytaj dalejDiagram prawdę Ci powie

Process for System Architecture and Requirements Engineering

Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną koncepcję analizy i modelowania systemów w rozumieniu organizacji. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny.

Czytaj dalejProcess for System Architecture and Requirements Engineering

Myślenie obiektowe w programowaniu

Książka adresowana do programistów, sam tytuł to sugeruje. Warto ją kupić (programiści) bo bardzo  wyczerpująco opisuje to, co nazywam "implementacją obiektowości". Samo nauczenie się (semantyka i syntaktyka) obiektowo zorientowanego języka programowania to mało, warto poznać na czym ta implementacja polega: czym jest obiekt, dziedziczenie czy kompozycja. Autor skupia się jednak na implementacji samej "obiektowości". Moim zdaniem książka jak najbardziej przydatna programistom, bo przykłady są ilustrowane kodem i diagramami UML. Jednak nie znajdziecie tam zbyt wiele o obiektowo zorientowanym opisie modelowanej rzeczywistości, czyli o biznesowym aspekcie programowania i projektowania. Z treści książki…

Czytaj dalejMyślenie obiektowe w programowaniu

Kolejna wpadka IT: obiektowość

obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy "świata" i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie - obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).

Czytaj dalejKolejna wpadka IT: obiektowość

Demo System Szachownica

Z uwagi na zainteresowanie moim projektem "demo" stworzyłem tę stronę. Tu będą się pojawiały informacje o kolejnych etapach tworzenia tego dokumentu. Powiadomienia o postępach będą wysyłane mailem do subskrybentów. Projekt Szachy ma na celu pokazanie na prostym przykładzie, toku analizy i produktów jakie tworzę w roli analityka i projektanta. Dokument ten może zawierać pewne braki (brak pewnych szczegółów) gdyż celem tego dokumentu jest zademonstrowanie zawartości tego rodzaju dokumentacji a nie szczegółowe opracowanie realnego projektu, będzie to jednak zaznaczone w treści. Kliknij i pobierz aktualny plik projektu Wszelkie pytania i sugestie na temat treści projektu…

Czytaj dalejDemo System Szachownica
Read more about the article System Analysis And Design with UML 2.0
System Analysis and Design with UML Version 2.0. An Object-Oriented Approach (Second Edition), Alan Dennis, Barbara Haley Wixdom, David Tergarden

System Analysis And Design with UML 2.0

Książkę polecam przede wszystkim analitykom do nauki ale także "wyżartym" programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.

Czytaj dalejSystem Analysis And Design with UML 2.0

Analiza procesowa a obiektowa czyli niedopasowanie oporu

Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.

Czytaj dalejAnaliza procesowa a obiektowa czyli niedopasowanie oporu

Piraci drogowi i limit prędkości – droga jako system

Artykuł ten napisałem z dwóch powodów. Pierwszy to odpowiedz na cytowaną tezę pod artykułem o radarach laserowych rodem z mojej Alma Mater (WAT). Sugeruję kierowcom nie używać na drodze prostych heurystyk tylko przestrzegać znaków drogowych, z dwojga złego lepiej zwolnić na źle oznakowanej jezdni niż kogoś zabić lub okaleczyć. Drugi to przestrzec przed prowadzeniem analiz wymagań metodą wywiadów wierząc, że "skoro klient mówi to wie i tak chce", bi niestety w większości przypadków jest to nieprawda.

Czytaj dalejPiraci drogowi i limit prędkości – droga jako system

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

Dlaczego nie podoba mi się klasa Pracownik?

Swego czasu pod artykułem Business Model vs. System Model, wywiązała się dyskusja, po tym jak napisałem, że oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Karteka Pracowników a nie Pracownicy. Jeden z czytelników napisał wtedy (dociekliwym polecam w tym momencie cała tę dyskusje pod artykułem): ... byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak). Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model). Gdzie problem? [...] No więc dlaczego nie podoba mi się klasa Pracownik? Bo pracownik to Aktor Systemu, a System ten przechowuje wybrane dane o tym pracowniku. Są to dane potrzebne np. do identyfikowania osób wystawiających dokumenty z Systemu, a do tego potrzebne są jedynie Karty Pracowników a nie Pracownicy. System (oprogramowanie) zastąpił papierowe Kartoteki Magazynowe dlatego są one teraz w Systemie, ale towary są w nadal magazynie 9a nie w Systemie), system "ma w środku" Kartę Towaru (zastąpiła papierową) zawierająca opis towaru i jego ilość w magazynie. Kartoteka Magazynowa to pudło zawierające Karty Towarów. Faktura VAT to obiekt w systemie, można ją wydrukować lub wysłać jej egzemplarz w postaci elektronicznej kontrahentowi.

Czytaj dalejDlaczego nie podoba mi się klasa Pracownik?

Koniec treści

Nie ma więcej stron do załadowania