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…
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…
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…
ICONIX and Use Case Driven Object Modeling with UML
Tym razem recenzje dwóch książek w jednym wpisie:
- Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens
- 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:
- Model przypadków użycia specyfikujący wymagane zachowania aplikacji.
- Dziedzinowy model pojęciowy
- Model dziedziny (architektura).
- “Robustness diagram” abstrakcyjny model zachowania bazujący na jednoznacznych tylko biznesowych pojęciach (diagram komunikacji).
- Diagram sekwencji obrazujący zachowania się elementów architektury systemu w toku realizacji scenariuszy przypadków użycia.
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.