Jarosław Żeliński – Strona 26 – Jarosław Żeliński IT-Consulting

diagram klas, ikony, stereotypy, dział handlowy

Jak identyfikować klasy?

Post author:Jarosław Żeliński
Post published:9 lipca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:23 lipca 2020

Tytułowy problem ma chyba każdy początkujący . Jak słusznie zauważył autor poniższego tekstu: Eksperci od obiektowego podejścia do procesu tworzenia oprogramowania dzielą się na dwa obozy, w zależności od proponowanego przez nich sposobu identyfikacji klas: W oparciu o odpowiedzialności klas (RDD - Responsibility Driven Design) - najpierw rozpoznawane są wszystkie odpowiedzialności systemu (na podstawie potrzeb przyszłych użytkowników), a następnie, bazując na tych odpowiedzialnościach, wyróżniane są klasy, którym przypisuje się odpowiedzialności systemu. W ten sposób definiuje się odpowiedzialności klas, które odpowiadają zbiorowi zachowań ich obiektów. Przykładem tego podejścia jest wykorzystywana w niektórych…

Czytaj dalej

Zarządzanie zmianami biznesowymi

Post author:Jarosław Żeliński
Post published:9 lipca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:9 lipca 2015

Strategia organizacji to długo terminowe cele i polityka ich realizacji, konkretne roczne czy kwartalne działania to taktyki a nie strategia... Co więc robić? Przede wszystkim opisać strategię i politykę jej realizacji (strategia to plan ale polityka to reguły działania a nie opis działań). Polityka ta powinna wyznaczać także sposób budowy AK, która musi pozwolić na realizowanie strategii. Mają politykę, zbudować AK w zgodzie między innymi z zasadą, że ?architektura korporacyjna powinna być zamknięta na zmiany i otwarta na rozszerzenia?.

Czytaj dalej

The Object Primer 3rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)

Post author:Jarosław Żeliński
Post published:8 lipca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:4 komentarze
Post last modified:11 lipca 2022

Niestety i w literaturze i w materiałach szkoleniowych, czy nawet dydaktycznych na uczelniach (o zgrozo) można się spotkać z takimi "antywzorcami" jak wyżej. Jednym z najbardziej kuriozalnych jest obecnie modelowanie danych z użyciem diagramu klas, nanosząc na nie np. jeszcze klucze główne. Niestety bardzo często autorzy tych materiałów, wykładowcy i trenerzy, zamiast korzystać ze źródeł, przepisują jeden od drugiego pogłębiając marazm w tej dziedzinie, a pierwowzorem wielu tych herezji są niestety materiały publikowane przez firmę SPARX (producent oprogramowania Enterprise Architect) jak choćby mój ulubieniec: czas jako Aktor systemu

Czytaj dalej

Analysis Patterns: Reusable Object Models

Post author:Jarosław Żeliński
Post published:4 lipca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:16 lipca 2017

Jedna z ciekawszych i popularniejszych książek (ja mam dodruk z 2010 roku). Bardzo często spotykam się w sieci z powoływaniem się na tę książkę w kwestii "wzorców analitycznych". Jednak po pierwsze nie należy zapominać, że napisana została w 1996 roku (od tamtej pory mamy jednak pewien postęp, do tego książka jest ilustrowana symbolami opartymi na notacji ERD a nie UML), a po drugie, o czym wielu zapomina, Fowler prezentuje w niej modele koncepcyjne a nie strukturalne (wytłuszczenie moje): Analysis Patterns provides a catalogue of patterns that have emerged in a wide…

Czytaj dalej

SOA Patterns

Post author:Jarosław Żeliński
Post published:18 czerwca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:18 czerwca 2015

Większość książek z dziedziny analizy biznesowej i projektowania to traktaty o UML, "zbieraniu wymagań" itp., czasem o wzorcach projektowych (wzorce analityczne nie pojawiają się w tytułach, napiszę o tym innym razem). Rzecz w tym, że to wszystko tu "zamyka się" w jednej aplikacji gdzie "interfejsy mają blisko". Obecna rzeczywistość gospodarcza w zasadzie wyklucza sensowność drogi w stronę "jednej wielkiej uniwersalnej aplikacji" (polecam tu mój ostatni referat na IT Future Expo). Od integracji nie ma więc ucieczki, pojawiają się chmury, współpraca B2B z kontrahentami i ich systemami, rozproszone terytorialnie firmy, kilka…

Czytaj dalej

Rezygnujemy z waterfall bo agile jest lepsze. Co to znaczy i skąd to wiemy? Czyli widły Hume?a.

Post author:Jarosław Żeliński
Post published:18 czerwca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:17 czerwca 2024

11 go czerwca wygłosiłem referat inaugurujący targi IT Future Expo, dla tych którzy nie mogli być wtedy na sali :): http://www.slideshare.net/zelinski/j-elinski-rezygnujemy-z-waterfall Więcej o targach: II edycja IT Future Expo już za nami! Kolejny raz Warszawa stała się stolicą IT za sprawą targów IT Future Expo, które odbyły się w dniach 10-11 czerwca 2015 na Stadionie Narodowym. To największa impreza targowa B2B branży informatycznej w Polsce. Zaskakujące pomysły Wystawców, konkursy, gry i wspaniałe prezentacje przyciągnęły wielu Zwiedzających! Targi zorganizowane zostały pod honorowym patronatem Ministerstwa Gospodarki, Marszałka Województwa Mazowieckiego oraz Polskiej Izby…

Czytaj dalej

Systemowo o rentowności czyli właściwe granice systemu

Post author:Jarosław Żeliński
Post published:12 czerwca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:27 czerwca 2021

Wyznaczenie granicy (pod)systemu to rola analityka i architekta systemów. Szkoda, że tak rzadko się korzysta z tej specjalności. Być może nie zlikwidowany by tak wielu lokalnych połączeń kolejowych uznając, że stanowią one razem system a w pojedynkę są niesamodzielne. Pewnie uznanie, że nie sam Zakład Komunikacji Miejskiej a właśnie miasto i jego infrastruktura razem stanowi system, który należy oceniać i rozwijać. "Darmowe autobusy mają pomóc odkorkować Bełchatów" czyli może jednak łączymy jakimś związkiem w jeden system dostępność komunikacji miejskiej, liczbę prywatnych samochodów osobowych, koszty zanieczyszczenia atmosfery, koszt budowy parkingów i poszerzania ulic.

Czytaj dalej

Różne perspektywy wymagań

Post author:Jarosław Żeliński
Post published:8 czerwca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:15 lutego 2022

Nie powinniśmy zapominać, że model Kruchtena to połowa lat 90-tych, szczyt rozkwitu metod strukturalnych i raczkujące metody i narzędzia obiektowe. To stare systemy i ich relacyjne bazy danych wymusiły stosowanie [[mapowania ORM]] i takich narzędzi jak [[Hibernate]]. Dzisiaj mamy rok 2015, od tamtej pory minęło 20 lat. Nie musimy się cofać do początków inżynierii oprogramowania w wersji obiektowej. Coś takiego jak perspektywa danych to anachronizm. Podejście to w 100% zostały już dawno zastąpione przez MDA.

Czytaj dalej

Agile Modeling. Effective Practices for Modeling and Documentation

Post author:Jarosław Żeliński
Post published:27 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:31 maja 2015

Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć... Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below (click on the practice…

Czytaj dalej

Software Architecture in Practice

Post author:Jarosław Żeliński
Post published:27 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:27 maja 2015

Jednym z moich niedawnych nabytków jest bardzo wartościowa książka, jednak nie jest to podręcznik analizy i modelowania, a opis wieloletnich doświadczeń autorów w tworzeniu i dokumentowaniu architektury oprogramowania. The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in which architecture plays a critical role. Contexts include technical environment, the life cycle of a project, an organization?s business profile, and the architect?s professional practices. The authors also have greatly expanded their treatment of quality…

Czytaj dalej

Systemowo o ekonomii czyli modele biznesowe

Post author:Jarosław Żeliński
Post published:23 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:11 maja 2016

Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje: - sama struktura to nie model, - tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury, - dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]), - bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie.(dlatego też, diagramy ERD i tak zwane modele danych, pozbawione funkcji, nie są modelami czegokolwiek a jedynie określonym strukturami).

Czytaj dalej

Effective software delivery. White paper. May 2009

Krzywe i koszty… architektury

Post author:Jarosław Żeliński
Post published:21 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:27 października 2021

Niestety wiele systemów ERP i i nie tylko, powstało w latach 90'tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i "nad nią" funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie - jak to zachwalają ich dostawcy - zaletą...

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy

Starsze wpisy