Successfully reported this slideshow.

Filozofia aplikacja to element rzeczywistości

1

Share

Loading in …3
×
1 of 15
1 of 15

Filozofia aplikacja to element rzeczywistości

1

Share

Download to read offline

Oprogramowanie bardzo często zastępuje konstrukcje rzeczywiste takie jak zegarek, kartoteka, biblioteka, księgi handlowe, programator pralki i wiele innych rzeczy. Dlatego analiza powinna polega na zrozumieniu mechanizmy działania "tego czegoś" a nie spisaniu zewnętrznych oznak tego działania.

Oprogramowanie bardzo często zastępuje konstrukcje rzeczywiste takie jak zegarek, kartoteka, biblioteka, księgi handlowe, programator pralki i wiele innych rzeczy. Dlatego analiza powinna polega na zrozumieniu mechanizmy działania "tego czegoś" a nie spisaniu zewnętrznych oznak tego działania.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Filozofia aplikacja to element rzeczywistości

  1. 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. 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. 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. 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. 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. 6. człowiek, organizacja w jakiej funkcjonuje i oprogramowanie, jako jeden system
  7. 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. 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. 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. 10. rola analityka to projektowanie, rola developera to implementacja Analiza i projektowanie Cel Rekomendacja Opis produktu Realizacja/Implementacja Produkt
  11. 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. 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. 13. Model systemu i model dziedziny to ten sam model – to czego wymagamy należy zaprojektować
  14. 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. 15. PYTANIA…? Dziękuję za uwagę… © Jarosław Żeliński IT-Consulting 15

×