Diagramy w notacji UML

Wprowadzenie "The Unified Modeling Language User Guide" autorstwa Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że "możesz wykonać 80% modelowania za pomocą 20% UML" gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią". Diagramy UML i sposób ich użycia, od samego początku istnienia tej notacji, budzą emocje i fale sprzecznych komentarzy. Powodem jest wysoki poziom abstrakcji etapu…

Czytaj dalejDiagramy w notacji UML

ICONIX jako zwinny proces projektowania oprogramowania z użyciem UML

Ten często aktualizowany przeze mnie wpis, stał się niemalże kompletnym opisem metodyki projektowania oprogramowania. Nie jest to moja metodyka, to metodyka z której ja także korzystam. Artykuł zaopatrzyłem w bogaty spis literatury źródłowej i kilka ciekawych referatów konferencyjnych. Polecam szczególnie moim obecnym i potencjalnym klientom, bo to opis produktu jaki ode mnie dostaną (polecam także wpis: Moja rola w projektach). "The Unified Modeling Language User Guide" autorstwa Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że "możesz wykonać 80% modelowania za pomocą 20% UML" gdzieś po stronie…

Czytaj dalejICONIX jako zwinny proces projektowania oprogramowania z użyciem UML

MVC a etapy projektowania aplikacji HLD i LLD – Czym jest Architektura Systemu

W perspektywie krótkoterminowej architektura oprogramowania pomaga zredukować czas i koszty rozwoju.W dłuższej perspektywie architektura oprogramowania pomaga zredukować koszty utrzymaniu. https://medium.com/@learnwithwhiteboard_digest/basics-of-software-architecture-a-guide-for-developers-8098a76881ca Wstęp W 2017 roku pisałem dość ogólnie o logice wzorca architektonicznego MVC kończąc artykuł słowami: A gdzie mitycz­na baza danych? Tam gdzie jej miej­sce: zarzą­dza dany­mi utrwa­la­ny­mi w pamię­ci. Baza danych i sys­te­my zarzą­dza­nia dany­mi w archi­tek­tu­rze obiek­to­wej nie sta­no­wią miej­sca na logi­kę biz­ne­so­wą, stan­dar­do­wym wzor­cem pro­jek­to­wym jest tu acti­ve records. Podstawową zale­tą sto­so­wa­nie tego wzor­ca jest sepa­ra­cja utrwa­lo­nych danych od apli­ka­cji. To pozwa­la sku­pić całą logi­kę i jej zmien­ność w kodzie apli­ka­cji i jego archi­tek­tu­rze. Dzięki temu…

Czytaj dalejMVC a etapy projektowania aplikacji HLD i LLD – Czym jest Architektura Systemu

ICONIX and Use Case Driven Object Modeling with UML

Tym razem recenzje dwóch książek w jednym wpisie:

  1. Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens
  2. Use Case Driven Object Modeling with UML. Theory and Practice. 2nd Edition. By Doug Rosenberg , Matt Stephens

Pierwsza wydana w 2005 roku, druga 2013 r. Pierwsza metodę ICONIX opisuje na przykładach, w kontekście zwinnych metod, proces projektowania i tworzenia oprogramowania bazujący na modelach. Są to:

  1. Model przypadków użycia specyfikujący wymagane zachowania aplikacji.
  2. Dziedzinowy model pojęciowy
  3. Model dziedziny (architektura).
  4. “Robustness diagram” abstrakcyjny model zachowania bazujący na jednoznacznych tylko biznesowych pojęciach (diagram komunikacji).
  5. Diagram sekwencji obrazujący zachowania się elementów architektury systemu w toku realizacji scenariuszy przypadków użycia.
(więcej…)

Czytaj dalejICONIX and Use Case Driven Object Modeling with UML

Bo najważniejsi Panie są Aktorzy…

Bardzo często spotykam się z projektami, w których użytkownicy narzekają na dostawcę oprogramowania, uważają że program nie całkiem spełnia ich oczekiwania (wymagania podpisali... ale to nie rozwiązuje tego problemu). Problem polega na często spotykanym podejściu: analiza wymagań tylko w postaci wywiadów i w konsekwencji niepełne zrozumienie specyfiki biznesowej oraz fakt, że developer ma skłonności do uproszczeń i "normalizacji". Innym, moim zdaniem jeszcze gorszym podejściem, jest rozpoczęcie kodowania jeszcze w trakcie trwania wywiadów i tworzenie oprogramowania metodą codziennych, lub co tygodniowych spotkań z użytkownikiem opisującym kolejne aspekty systemu. Zbyt późne odkrywanie (a nie raz nawet niedostrzeganie tego), tego że pewne rzeczy są 'tymi samymi rzeczami" ale w innych kontekstach, prowadzi do bardzo wielu problemów z implementacją. Ale po kolei.

Czytaj dalejBo najważniejsi Panie są Aktorzy…

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostatnio wzorzec DDD jako narzędzie dokumentowania analizy. Faktycznie, czytelnicy mają wiele racji, jest on dość "bliski implementacji". Niejednokrotnie "lepszym pomysłem" jest opis logiki systemu na nieco wyższym poziomie abstrakcji pozostawiając tym samym więcej swobody developerowi. [...] Nieco inne podejście, to które stosuję obecnie, opisuję poniżej. Zachowując podstawowe znaczenia tych trzech klas, dostosowałem je do wzorca MVVC. Jest to o tyle wygodne i ważne, że stosowanie wzorca BCE wyłącznie do modelowania logiki biznesowej wymaga zachowania hermetyzacji komponentu Model. W takim układzie boundary nie będzie elementem komponentu View a Modelu. Jego rola to stworzenie dedykowanego interfejsu do model np. pomiędzy komponentem View lub Controlerem. Dzięki temu możliwe jest stworzenie odrębnego interfejsu dla View na duży ekran i odrębnego dla View na np. małych ekranach smartfonów. Tak więc jest moim zdaniem droga do modelowania wymagań metodą "tak to ma działać" a nie tylko "tak to ma wyglądać", bo to drugie jest przyczyną wielu problemów...

Czytaj dalejWzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Koniec treści

Nie ma więcej stron do załadowania