1.
Filozofia czyli Aplikacja jako element biznesowej
rzeczywistości
(a nie gra komputerowa)
Jarosław Żeliński – analityk
biznesowy, projektant systemów
18 marzec 2016
18-20 marca 2016, Politechnika Gdańska, Wydział Elektrotechniki, Telekomunikacji i Informatyki.

2.
O mnie…
Od 1991 roku w branży IT i zarządzania jako analityk
projektant rozwiązań
Od 1998 – 2004 doradca IT w kilku spółkach akcyjnych
Od 2004 roku jako niezależny ekspert i analityk
Dziesiątki publikacji w prasie branżowej IT i gospodarczej
Członek stowarzyszenia doradców gospodarczych
 Były wykładowca katedry systemów informacyjnych
wydziału przedsiębiorczości Akademii Morskiej w Gdyni
Kilkudziesięciu odbiorców usług doradczych, małe,
średnie i duże firmy zarówno informatyczne jak i ich
klienci.
Poświadczenie bezpieczeństwa wydane przez ABW
Były ekspert analityk biznesowy przy gabinecie komisji
nadzoru finansowego
Wykładowca Wyższej Szkoły Informatyki Stosowanej i
Zarządzania pod auspicjami Polskiej Akademii Nauk
Projekty analityczne
między innymi dla…
Publikacje między innymi w …

3.
Agenda
• ​człowiek, organizacja w jakiej
funkcjonuje i oprogramowanie jako jeden system
• metody obiektowe jako odwzorowanie ogólnej
teorii systemów
• metody obiektowe jako narzędzie analizy świata
rzeczywistego i projektowania oprogramowania
• mechanizm, cóż to jest?
• rola analityka to projektowanie, rola developera
to implementacja

4.
Od strony filozofii…
Modelowanie
wymaga więc
określenia nie
tylko notacji ale
także pragmatyki
wskazującej: co
jest modelowane,
jak dokładnie i jak
ogólnie…
Artur Schopenhauer, Czworaki Korzeń Racji Dostatecznej

5.
Ogólna teoria systemów jako metoda naukowa i
szkielet analizy strategicznej
UWAGA! Modele same z siebie nigdy nie są celem pracy, nie są
żadnymi produktami, są tylko narzędziami analizy. Model to teoria
(naukowa) mówiąca: „tak działa ta organizacja”.
Kluczowe znaczenie dla rozróżnienia czy dana teoria jest teorią naukową, czy nie, ma
obecnie kryterium falsyfikowalności. Pojęcie to zostało wprowadzone przez Karla Poppera
w dziele "Logika odkrycia naukowego" i stanowi podstawę metody naukowej.

6.
człowiek, organizacja w jakiej
funkcjonuje i oprogramowanie, jako jeden system

7.
metody obiektowe jako odwzorowanie ogólnej
teorii systemów
• System: złożony obiekt wyróżniony w badanej
rzeczywistości, stanowiący całość tworzoną przez
zbiór obiektów elementarnych (elementów) i
powiązań (związków i relacji) między nimi
(Sienkiewicz, 1994)
• Paradygmat: przyjęty sposób widzenia
rzeczywistości w danej dziedzinie, doktrynie itp.
(źr. sł.j.p. PWN)
• Paradygmat obiektowy: w analizie i
projektowaniu uznanie, że system to abstrakcja
modelowana jako ograniczony spójny zbiór
współpracujących ze sobą obiektów

8.
Cechy (tej) abstrakcji
• Obiekty są „czarnymi skrzynkami” (hermetyzacja)
• Obiekty współpracują wyłącznie poprzez wzajemne
świadczenie sobie usług
– Wiedze o stanie obiektu można pozyskać wyłącznie od niego i za
jego zgodą
• Obiekty złożonych systemów mogą być grupowane w
podsystemy (komponenty) co nie może zaburzać zasady
hermetyzacji
• Obiekty mogą być z sobą trwale powiązane
• UWAGA! Pojęcie dziedziczenia dotyczy wyłącznie modeli
pojęciowych i budowania bytów abstrakcyjnych (złe
pojmowanie dziedziczenia w językach programowania, tu
jest to jedynie re-użycie kodu)

9.
metody obiektowe jako narzędzie analizy świata
rzeczywistego i projektowania oprogramowania
Otóż nie da się czymś tak złożonym
jak oprogramowanie (zakładam, że to nie
trywialny system), zarządzać na poziomie
detalicznych szczegółów. Jedynym
sposobem jest upraszczanie i praca z
abstrakcjami. Czym są owe abstrakcje?
Modele! Już w 1984 roku zauważono, że:
• I just read an idea by Stephen
Hawking and Leonard Mlodinow,
calledModel-Dependent Realism[2]: “the
idea that a physical theory or world
picture is a model (generally of a
mathematical nature) and a set of rules
that connect the elements of the model
to observations.” (za Model-Dependent
Realism: Is This the Worldview of
Software Engineering? « THINK IN
MODELS).

10.
rola analityka to projektowanie, rola developera
to implementacja
Analiza i
projektowanie
Cel
Rekomendacja
Opis produktu Realizacja/Implementacja Produkt

11.
ZŁOŻONOŚĆ
Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są
zwykle „problemami złośliwymi” (Rittel i Webber, 1973). „Problem złośliwy”
to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą
bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter
problemu objawia się dopiero w miarę opracowywania rozwiązania.

12.
Model systemu i model dziedziny to ten sam
model
• Każdy pełny
obrót
sekundnika
powoduje
przesunięcie
wskazówki
minut o 1/60
• Każdy pełny
obrót
wskazówki
minutowej
powoduje
przesunięcie
wskazówki
godzinowej o
1/6
To co obserwujemy
To czego wymagamy
To co powstało
To co powstało

13.
Model systemu i model dziedziny to ten sam
model – to czego wymagamy należy zaprojektować

14.
O powszechnie popełnianych błędach
• UML to rozbudowany uniwersalny język
• Diagramy przypadków użycia i klas to najczęściej używane narzędzia UML
ale także „najgorzej”:
– Model przypadków użycia to diagram przypadków użycia opisujacy model
„czarnej skrzynki” (system) i jej otoczenia (aktorzy) więc nie powinien zawierać
żadnych informacji o wnętrzu (include i extend to reliktowe, obecnie zbędne
elementy tego diagramu)
– Model pojęciowy do diagram klas modelujący pojęcia opisujące system (tu
korzystamy z dziedziczenia i abstrakcji)
– Model logicznej struktury systemu to diagram klas modelujący mechanizm
działania modelowanego systemu (nazywany: model dziedziny systemu, tu nie
korzystamy z dziedziczenia i abstrakcji). Jest to model PIM wg. MDA
– Model implementacji z użyciem konkretnego języka programowania to
diagram klas modelujący strukturę kodu. Jest to model PSM wg. MDA (tu
dziedziczenie i abstrakcje mają inne znaczenie niż w modelu PIM)
– Nie da pokazać powyższych trzech modeli na jednym diagramie klas! Ale
wielu stale próbuje…..

15.
PYTANIA…?
Dziękuję za uwagę…
© Jarosław Żeliński IT-Consulting 15