Zaawansowane metody programowania obiektowego

Сентябрь 7, 2022

Главная
Алгебра
Zaawansowane metody programowania obiektowego

Содержание

2. Program zajęć Wprowadzenie w projektowanie i programowanie obiektowe Metody obiektowe projektowania oprogramowania Elementy notacji UML Zaawansowane
3. Zaliczenie przedmiotu Zaliczenie przedmiotu - na podstawie: egzaminu oraz zaliczenia zajęć laboratoryjnych. Egzamin w formie: egzaminu
4. Zaliczenie przedmiotu Wszystkie konsultacje odbywają się ul. Domagalskiego 7a Terminy: 2016-10-14, 8.50-9.35 2016-10-28, 8.50-9.35 2016-11-18, 8.50-9.35
5. Literatura podstawowa Metody obiektowe w teorii i w praktyce – Ian Graham, WNT, 2004 Podstawy metod
6. Startujemy!
7. Trochę historii … Babilon (1790 p.n.e.) – tablice m.in. o zawartości matematycznej, astronomicznej: Bagdad (780-850) –
8. Trochę historii … 1840 – Augusta Ada, córka lorda Byrona, od 19-tego roku życia po ślubie
9. Trochę historii … 1946 – powstał ENIAC (Electronic Numerical Integrator and Computer), skonstruowany przez Johna W.
10. Trochę historii … Komputer przenośny ☺
11. Programowanie … oprogramowanie System komputerowy – układ współdziałania dwóch składowych: sprzętu komputerowego oraz oprogramowania o strukturze:
12. Programowanie … oprogramowanie Oprogramowanie – to programy komputerowe, ich dokumentacja, dane, pliki konfiguracyjne i pomocnicze …;
13. Wymagania dla dobrego oprogramowania Dobre oprogramowanie powinno zapewniać: użyteczność - dostępność oczekiwanych usług, niezawodność, efektywność, bezpieczeństwo
14. Programowanie … oprogramowanie Język programowania powinien: wspomagać wierne odwzorowanie rzeczywistości, wymuszać i wspierać logiczną organizację programu,
15. Wymagania dla dobrego oprogramowania
16. Wymagania dla dobrego oprogramowania
17. Ewolucja technik programowania Obecnie na świecie jest kilka tysięcy języków programowania; Już w 1995 roku na
18. Ewolucja technik programowania 1950 1960 1970 1980 1990 2000 Fortran(54) Ada(95) Java(96) A S S E
19. Ewolucja technik programowania http://www.tiobe.com
20. Podsumowanie http://www.tiobe.com
21. Ewolucja technik programowania Paradygmat programowania (ang. programming paradigm) – zaakceptowany powszechnie wzorzec programowania definiujący sposób patrzenia
22. Ewolucja technik programowania
23. Ewolucja technik programowania Programowanie imperatywne – proces wykonywania programu jest sekwencją instrukcji zmieniających stan programu; Programy
24. Ewolucja technik programowania programowanie proceduralne: program = seria procedur, działających na danych; dane całkowicie odseparowane od
25. Ewolucja technik programowania Od programowania strukturalnego do obiektowego… F(1) F(2) F(3) … F(n) System zarządzania danymi
26. Ewolucja technik programowania Programowanie obiektowe: główne zadanie to modelowanie „obiektów” (tzn. rzeczy, zjawisk), a nie „danych.”;
27. Koncepcja obiektowości obiektowość - cecha naturalnego postrzegania świata - analiza otoczenia poprzez relacje między obserwatorem a
28. Koncepcja obiektowości Paradygmat obiektowy (podstawowy styl, techniki oraz wspomagające je konstrukcje językowe) : abstrakcja hermetyzacja (kapsułkowanie)
29. Koncepcja obiektowości Abstrakcja: Wszystko jest obiektem; Program to zbiór obiektów, które się ze sobą komunikują wysyłając
30. Koncepcja obiektowości Obiekt: podstawowa jednostka konstrukcyjna; konkretny lub abstrakcyjny byt (wyróżnialny w modelowanej rzeczywistości) posiadający nazwę,
31. Koncepcja obiektowości Klasa: zbiór obiektów, mających wspólne atrybuty i metody; wzorzec dla konkretnych egzemplarzy klasy –
32. Koncepcja obiektowości Klasy i ich instancje Jedna klasa może mieć wiele instancji, które różnić się mogą
33. Koncepcja obiektowości Hermetyzacja (kapsułkowanie, enkapsulacja) zamknięcie pewnego zestawu bytów programistycznych w “kapsułę” o dobrze określonych granicach;
34. Koncepcja obiektowości Dziedziczenie związek pomiędzy klasami obiektów, określający przekazywanie cech (definicji atrybutów, metod, itd.) z nadklasy
35. Koncepcja obiektowości class Pojazd { public: virtual void jedz() { cout virtual void hamuj() { cout
36. Koncepcja obiektowości class Pojazd { protected: string nazwa; public: Pojazd(string _nazwa) { nazwa = _nazwa; }
37. Ewolucja technik programowania Funkcje programu Np. obliczanie wartości X Stany programu (dane) Np. X = [x1,
38. Ewolucja technik programowania http://www.tiobe.com
39. Ewolucja technik programowania Zestawienie cech wybranych języków programowania
40. Ewolucja technik programowania Pamiętać jednak należy, że: Programowanie nie zaczyna się i nie kończy na przekładaniu
41. Geneza inżynierii oprogramowania
42. Kryzys oprogramowania Od początku lat 60-tych trwa walka z syndromem LOOP; 1968, 1969 - konferencje sponsorowane
43. Kryzys oprogramowania
44. Kryzys oprogramowania Walka z kryzysem oprogramowania: Usuń przyczyny -> wyeliminujesz zauważone symptomy; Stosowanie technik i narzędzi
45. Co to jest inżynieria oprogramowania? Jest to dziedzina inżynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od
46. Co to jest inżynieria oprogramowania? Metodyki: Strategia postępowania oparta na doświadczeniach i heurystykach oraz formalnych elementach;
47. Co to jest inżynieria oprogramowania? Techniki: szczegółowo określone sposoby (z wykazem czynności) posługiwania się środkami, w
48. Proces tworzenia oprogramowania Jest to zbiór czynności i związanych z nimi wyników, które prowadzą do powstania
49. Modele procesu tworzenia oprogramowania Model kaskadowy (wodospadowy) - waterfall model Definiowanie wymagań Projektowanie systemu i oprogramowania
50. Modele procesu tworzenia oprogramowania Tworzenie iteracyjne ocena wymagania planowanie planowanie wstępne analiza i projektowanie implementowanie testowanie
51. Modele procesu tworzenia oprogramowania Ewolucja inżynierii oprogramowania - podsumowanie: Assembly -> Fortran/COBOL -> Simula -> C++
52. Proces tworzenia oprogramowania Zbiór czynności i związanych z nimi wyników, które prowadzą do powstania produktu programowego;
53. Czynności procesu tworzenia oprogramowania Projektowanie i implementowanie wymagań: Metody projektowania: Stosowanie metod strukturalnych i obiektowych, które
54. Czynności procesu tworzenia oprogramowania Projektowanie i implementowanie oprogramowania: Celem fazy określania wymagań jest udzielenie odpowiedzi na
55. Czynności procesu tworzenia oprogramowania Projektowanie i implementowanie oprogramowania: Faza projektowania oprogramowania: opis struktury oprogramowania, które ma
56. Czynności procesu tworzenia oprogramowania Projektowanie i implementowanie wymagań: Charakterystyczne składowe analizy i projektowania:
57. Projektowanie architektury systemu System informatyczny jest złożoną konstrukcją, której stopień skomplikowania zależy od złożoności architektury; Wielkie
58. Projektowanie architektury systemu Modele obiektowe: Model obiektowy architektury systemu dzieli system na zbiór luźno uzależnionych od
59. Metodyki strukturalne a obiektowe Metodyki strukturalne: metodyki strukturalne są dojrzałe, lecz mogą nie być adekwatne do
60. Obiektowe podejścia do wytwarzania oprogramowania System jest analizowany w sposób obiektowy jeśli: Jest dzielony na obiekty
61. Obiektowe podejścia do wytwarzania oprogramowania OODA (Booch Methodology), Object Modelling Technique - OMT (Rumbaugh), Objectory(Jacobson), OOA/OOD(Coad/Yourdon),
62. Obiektowe podejścia do wytwarzania oprogramowania OMT-2 (rozwinięcie OMT-1): technika modelowanie obiektów; nacisk na analizę systemów oprogramowania;
63. Obiektowe podejścia do wytwarzania oprogramowania Analiza obiektowa opracowanie modelu obiektowego dziedziny zastosowania; rozpoznane obiekty odzwierciedlają byty
64. Faza analizy Identyfikacja aktorów: Grupy użytkowników wspierane przez system w: podstawowych i drugoplanowych zadaniach; administrowaniu i
65. Faza analizy Identyfikacja klas obiektów - typowe klasy: przedmioty namacalne (np. samochód, czujnik), role pełnione przez
66. Faza analizy Obiekty, zbiory obiektów i metadane: W wielu przypadkach przy definicji klasy należy dokładnie ustalić,
67. Faza analizy Zalecenia dotyczące identyfikacji klas: Wyraźnie zdefiniować kontekst (w tym opis) klasy; Unikać w nazwie
68. Faza analizy Zalecenia dotyczące identyfikacji związków klas: Unikać związków bez klasy docelowej; Pomijać związki z elementami
69. Faza analizy Zalecenia dotyczące modelu dynamicznego klas: Koncentrować się na behawioralnych aspektach systemu; Rozpatrzeć interakcje związane
70. Faza analizy Kluczowe czynniki sukcesu fazy analizy Zaangażowanie właściwych osób ze strony klienta; Kompleksowe i całościowe
71. Od analizy do szczegółowego projektu obiektów Celem projektowania jest opracowanie szczegółowego opisu implementacji systemu. W odróżnieniu
72. Faza projektowania Zadania w etapach fazy projektowania: uściślenie istniejących definicji klas, np. metod, dziedziczenie klas i
73. Faza projektowania Zadania fazy projektowania – przykład uściślenia definicji metod; Podanie nagłówków metod oraz ich parametrów.
74. Faza projektowania Zadania fazy projektowania – przykład sposobu implementacji związków (asocjacji); Związki można zaimplementować na wiele
75. Podstawowe rezultaty fazy projektowania Poprawiony i uszczegółowiony dokument opisujący wymagania; Poprawione i uszczegółowione modele; Uszczegółowiona specyfikacja
76. RUP Ukierunkowany na przypadki użycia Architekturo-centryczny Iteracyjny Przyrostowy Sterowany ryzykiem
77. RUP Dwa wymiary RUP FAZY (ang. phases) PRZEPŁYWY, DYSCYPLINY (ang. disciplines)
78. RUP Proces budowy systemu informatycznego składa się z dyscyplin, z których każda dzielona jest na fazy:
79. O czym teraz… Geneza i charakterystyka UML; Zapoznanie z wybraną notacją wykorzystywaną w modelowaniu, analizie i
80. UML – notacja obiektowa Rodzaje notacji: tekstowo-opisowa, specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny, notacje graficzne;
81. UML – notacja obiektowa
82. UML – notacja obiektowa Unified Modeling Language – UML The Unified Modeling Language™ (UML™) is the
83. UML – składowe Perspektywy modelowe – 4+1: Implementacyjna Przypadków użycia Wdrożenia Logiczna Procesowa
84. UML – składowe Słownik UML dzieli się na trzy grupy: elementy, związki (relacje), diagramy; Model –
85. UML – elementy Elementami UML są podstawowe obiektowe bloki konstrukcyjne stosowane do budowy modeli: strukturalne statyczne
86. UML – elementy Elementami UML są podstawowe obiektowe bloki konstrukcyjne stosowane do budowy modeli: czynnościowe elementy
87. UML – elementy Elementami UML są podstawowe obiektowe bloki konstrukcyjne stosowane do budowy modeli: grupujące bloki
88. UML – związki Związki: służą do łączenia elementów; w praktyce najczęściej stosowane są powiązanie i uogólnienie;
89. UML – związki Związki klas: Zależność Asocjacja Jednokierunkowa Dwukierunkowa Agregacja Kompozycja Generalizacji Realizacja
90. UML – notacja związków Przykład: Klasa abstrakcyjna 1..* 1 Widoczność: - private # protected + public
91. UML – notacja diagramów Diagram przypadków użycia: Przypadek 1 Przypadek 2 Przypadek 3 Przypadek 4 „extend”
92. UML – przykład systemu ewidencji studentów Diagram przypadków użycia
93. UML – przykład systemu ewidencji studentów Diagram klas (1) – klasy abstrakcyjne Arkusz rejestracji Kierownik ewidencji
94. UML – przykład systemu ewidencji studentów Diagram klas (2) – klasy uszczegółowione Arkusz rejestracji Kierownik ewidencji
95. UML – przykład systemu ewidencji studentów Diagram klas (3) – związki klas Arkusz rejestracji Kierownik ewidencji
96. UML – przykład systemu ewidencji studentów Diagram klas (4) – skierowanie i krotności związków Arkusz rejestracji
97. UML – przykład systemu ewidencji studentów Diagram klas (5) – generalizacja Arkusz rejestracji Kierownik ewidencji Kurs
98. UML – przykład systemu ewidencji studentów Diagram sekwencji zdarzeń : Student arkusz rejestracji kierownik ewidencji Kurs
99. UML – przykład systemu ewidencji studentów Diagram współpracy : Rejestrujący arkusz kursu : ArkuszKursu Kierownik :
100. UML – przykład systemu ewidencji studentów Diagram stanów Inicjalizacja Otwieranie entry: Zarejestruj studenta exit: Zwiększ licznik
101. System mapy pogody Przykład z książki Iana Sommerville’a „Inżynieria oprogramowania” System tworzący mapy pogody ma regularnie
102. System mapy pogody Zadania systemu: zbieranie danych, integracja danych z różnych źródeł, archiwizowanie danych, tworzenie map
103. Architektura warstwowa systemu mapy pogody Warstwa wyświetlania danych Obiekty warstwy przygotowują dane w postaci zrozumiałej dla
104. Podsystemy w systemie mapy pogody > Gromadzenie danych Obserwator Balon Stacja meteoro- logiczna Satelita Wspólne >
105. Kontekst systemu i modele użycia systemu Pierwszym krok procesu projektowania oprogramowania: zrozumienie związków między projektowanym oprogramowaniem
106. Przypadki użycia stacji meteorologicznej
107. Przypadki użycia stacji meteorologicznej System Stacja meteorologiczna Przypadek użycia Raportuj Aktorzy System gromadzenia informacji meteorologicznych, Stacja
108. Projektowanie architektury Drugi krok procesu projektowania oprogramowania: projektowanie architektury; Architektura na przykładzie automatycznej stacji meteorologicznej (model
109. Architektura stacji meteorologicznej
110. Klasy obiektów stacji meteorologicznej Trzeci krok procesu projektowania oprogramowania: Identyfikacja (wynajdowanie) klas i obiektów; StacjaMeteorologiczna -
111. Klasy obiektów stacji meteorologicznej StacjaMeteorologiczna identyfikator raportPogodowy () dostrój (przyrządy) testuj () uruchom (przyrządy) wyłącz (przyrządy)
112. Klasy obiektów stacji meteorologicznej > Interfejs SterownikKomunikacji StacjaMeteorologiczna DaneMeteorologiczne > Gromadzenie danych Stan przyrządów > Przyrządy
113. Sekwencja zdarzeń :Sterownik Komunikacji :Stacja Meteorologiczna :Dane Meteorologiczne podsumuj () raportuj () wyślij (raport) żądanie (raport)
114. Diagramy stanów Wyłączony Działanie Transmitowanie Testowanie Dostrajanie Oczekiwanie Podsumowywanie Gromadzenie uruchom () wyłącz () zegar koniec
115. Specyfikowanie interfejsów obiektów Szósty krok procesu projektowania: specyfikowanie interfejsów między komponentami; Pozwoli to na równoległe projektowanie
116. Specyfikowanie interfejsów obiektów Interfejs StacjaMeteorologiczna { public StacjaMeteorologiczna () ; public void uruchom () ; public
117. Ewolucja projektu Kolejne kroki projektowania: uszczegółowienie uproszczonego modelu; Zmiana wstępnie ustalonych szczegółów obiektu - nie wpłynie
118. Ewolucja projektu Do obiektu StacjaMeteorologiczna na tym samym poziomie co obiekt DaneMeteorologiczne należy dodać obiekt o
120. Скачать презентацию

Слайд 2

Program zajęć
Wprowadzenie w projektowanie i programowanie obiektowe
Metody obiektowe projektowania oprogramowania
Elementy notacji

UML
Zaawansowane techniki programowania obiektowego w językach obiektowo-zorientowanych
Wzorce projektowo-programowe
Programowanie aplikacji internetowych

Слайд 3

Zaliczenie przedmiotu
Zaliczenie przedmiotu - na podstawie: egzaminu oraz zaliczenia zajęć laboratoryjnych.
Egzamin

w formie: egzaminu pisemnego - test z teorii i zadania z programowania.
Podczas egzaminu pisemnego nie można korzystać z żadnych materiałów.
Warunek dopuszczenia do egzaminu: uzyskanie zaliczenia z zajęć laboratoryjnych.
Stosowana jest następująca reguła zaliczeń:
ocena dst: minimum 50 % możliwych do uzyskania punktów,
ocena dst+: minimum 60 % możliwych do uzyskania punktów,
ocena db: minimum 70 % możliwych do uzyskania punktów,
ocena db+: minimum 80 % możliwych do uzyskania punktów,
ocena bdb: minimum 90 % możliwych do uzyskania punktów.

Слайд 4

Zaliczenie przedmiotu
Wszystkie konsultacje odbywają się ul. Domagalskiego 7a
Terminy:
2016-10-14, 8.50-9.35
2016-10-28, 8.50-9.35
2016-11-18, 8.50-9.35
2016-12-02,

8.50-9.35
2016-12-16, 8.50-9.35
2017-01-13, 8.50-9.35
2017-01-20, 8.50-9.35
2017-01-27, 9.45-10.30

Слайд 5

Literatura podstawowa
Metody obiektowe w teorii i w praktyce – Ian Graham,

WNT, 2004
Podstawy metod obiektowych – J. Martin, J.J.Odell, 1997
UML – przewodnik użytkownika – Grady Booch, James Rumbaugh, Ivar Jacobson, WNT, 2001
Język C++ – Bjarne Stroustrup, 1997
Symfonia C++ – Jerzy Grębosz, 1999
Bruce Eckel. Thinking in C++. Edycja polska. Helion. 83-7197-709-3
Ian Sommerville, „Inżynieria oprogramowania”, WNT, 2003

Слайд 6

Startujemy!

Слайд 7

Trochę historii …
Babilon (1790 p.n.e.) – tablice m.in. o zawartości matematycznej,

astronomicznej:
Bagdad (780-850) – matematyk Mohammed Al-Khorezmi zapisał w podręczniku pierwsze algorytmy dla systemu 10-ego z zerem;
1623 – Wilhelm Schickard z Tubingen skonstruował sumator liczb do 6 cyfr;
1812 – Charles P. Babbage opracował i zbudował mechaniczną "maszynę różnicową", wykonującą skomplikowane działania metodą powtarzania kombinacji elementarnych operacji;

Znana tablica z formułami twierdzenia Pitagorasa a2+b2=c2 (podobno jest tam błąd – kto odnajdzie?)

Слайд 8

Trochę historii …
1840 – Augusta Ada, córka lorda Byrona, od 19-tego

roku życia po ślubie Lovelace – opublikowała pracę na temat dorobku Babbage'a. W swoich notatkach zawarła przemyślenia dotyczące przewagi systemu dwójkowego nad dziesiętnym w konstrukcji maszyn matematycznych oraz pętlą programową – stałą się pierwszą w dziejach programistką;
1850 – George Boole opracował zasady algebry Boole'a;

Maszyna analityczna splata algebraiczne wzory tak, jak maszyna Jacquarda tka kwiaty i liście.

Слайд 9

Trochę historii …
1946 – powstał ENIAC (Electronic Numerical Integrator and Computer),

skonstruowany przez Johna W. Mauchly'ego i J. Presper Eckerta z amerykańskiego Ballistic Research Laboratory;
1967 – w Norweskim Centrum Obliczeniowym w Oslo powstał język Simula, uważany za przodka obiektowości;
1972 - w Bell Laboratories opracowano język C;
1985 - Microsoft wypuścił na rynek Windows 1.0.
1991 - Linus Torvalds z Unwersytetu Helsińskiego opracował odchudzoną wersję Unixa – Linux;
1996 - po wielkiej kampanii reklamowej Microsoft zaprezentował Windows 95;
1996 - … Era sieci globalnych, urządzeń programowalnych, komputerów przenośnych;

Слайд 10

Trochę historii …
Komputer przenośny ☺

Слайд 11

Programowanie … oprogramowanie
System komputerowy – układ współdziałania dwóch składowych: sprzętu komputerowego

oraz oprogramowania o strukturze:
sprzęt,
oprogramowanie: systemowe, narzędziowe, użytkowe
użytkownicy;
System informatyczny – zbiór elementów, które przetwarzają dane przy użyciu techniki komputerowej:
sprzęt – głównie komputery,
oprogramowanie,
zasoby osobowe, elementy organizacyjne (procedury organizacyjne, instrukcje robocze), elementy informacyjne (dane);

Слайд 12

Programowanie … oprogramowanie
Oprogramowanie – to programy komputerowe, ich dokumentacja, dane, pliki

konfiguracyjne i pomocnicze …;
Program komputerowy – ciąg instrukcji dla procesora prowadzący do realizacji założonego zadania, utworzony w języku programowania w procesie tworzenia programu (czyli w programowaniu) przez programistę;
Gospodarki wszystkich rozwiniętych krajów zależą od oprogramowania … a jednocześnie…
wytwarzanie oprogramowania jest poważną gałęzią gospodarki narodowej każdego rozwiniętego kraju;
Czego wymagamy i wymaga się od nas? dobrego oprogramowania

Слайд 13

Wymagania dla dobrego oprogramowania
Dobre oprogramowanie powinno zapewniać:
użyteczność - dostępność oczekiwanych usług,

niezawodność,
efektywność,
bezpieczeństwo zasobów (w tym wyników pracy),
ochrona (w tym przed zewnętrznymi intruzami),
ergonomia,
wielokrotne wykorzystanie,
przenośność,
podatność na pielęgnowalnie;
efektywność kosztowa - opłacalność;

Слайд 14

Programowanie … oprogramowanie
Język programowania powinien:
wspomagać wierne odwzorowanie rzeczywistości,
wymuszać i wspierać logiczną

organizację programu,
tworzyć kod przenośny, czytelny i zrozumiały,
utrudniać popełnianie błędów algorytmicznych,
samodokumentować program;
A jaką mamy rzeczywistość?

Слайд 15

Wymagania dla dobrego oprogramowania

Слайд 16

Wymagania dla dobrego oprogramowania

Слайд 17

Ewolucja technik programowania
Obecnie na świecie jest kilka tysięcy języków programowania;
Już w

1995 roku na comp.lang.misc zanotowano ponad 2300 odwołań do różnych języków;
Klasyfikacja języków programowania:
imperatywne (imperative),
funkcjonalne, proceduralne (functional),
logiki (logic),
obiektowe, obiektowo zorientowane (object-oriented);

Слайд 18

Ewolucja technik programowania
1950
1960
1970
1980
1990
2000
Fortran(54)
Ada(95)
Java(96)
A S S E M B L E R
(ponad

200 wersji)

Eiffel (86)

Ada(83)

C#(00)

Ewolucja imperatywnych języków programowania

Слайд 19

Ewolucja technik programowania
http://www.tiobe.com

Слайд 20

Podsumowanie
http://www.tiobe.com

Слайд 21

Ewolucja technik programowania
Paradygmat programowania (ang. programming paradigm) – zaakceptowany powszechnie wzorzec

programowania definiujący sposób patrzenia programisty na przepływ sterowania i wykonywanie programu komputerowego;
Różne języki programowania mogą wspierać różne paradygmaty programowania – najczęściej dla języka istnieje jeden dominujący paradygmat, choć np. C++ posiada elementy programowania proceduralnego, obiektowego oraz uogólnionego (generycznego);
Powszechnie uznane paradygmaty programowania:

programowanie imperatywne
programowanie strukturalne
programowanie proceduralne
programowanie funkcyjne
programowanie obiektowe
programowanie uogólnione (generyczne)

programowanie sterowane zdarzeniami
programowanie logiczne (np. Prolog)
programowanie aspektowe (np. AspectJ)
programowanie deklaratywne
programowanie agentowe
programowanie modularne

Слайд 22

Ewolucja technik programowania

Слайд 23

Ewolucja technik programowania
Programowanie imperatywne – proces wykonywania programu jest sekwencją instrukcji

zmieniających stan programu;
Programy imperatywne składają się z ciągu komend (żądania czynności) do wykonania przez komputer;
Przykłady języków programowania FORTRAN, ALGOL, Pascal, C i Ada;
Programowanie strukturalne – opiera się na podziale kodu źródłowego programu na procedury i hierarchicznie ułożone bloki z wykorzystaniem struktur kontrolnych w postaci instrukcji: sekwencji, wyboru i pętli;
Programowanie obiektowe – programy definiuje się za pomocą obiektów – elementów łączących stan (czyli dane) i zachowanie (czyli procedury, metody) – komunikujących się ze sobą w celu wykonywania zadań;
Programowanie logiczne – odmiana programowania deklaratywnego, w której program to zestaw zależności, a obliczenia są dowodem pewnego twierdzenia w oparciu o te zależności;

Слайд 24

Ewolucja technik programowania
programowanie proceduralne:
program = seria procedur, działających na danych;
dane całkowicie

odseparowane od procedur;
programowanie strukturalne:
rozszerzenie programowania proceduralnego;
główna idea: „dziel i rządź” – od ogółu do szczegółu;
programowanie obiektowe:
główne zadanie to modelowanie „obiektów” a nie „danych”;
łączy w logiczną całość dane oraz manipulujące nimi funkcje;
wspiera konstruowanie systemów od szczegółu do ogółu;

Слайд 25

Ewolucja technik programowania
Od programowania strukturalnego do obiektowego…
F(1)
F(2)
F(3)
…
F(n)
System zarządzania danymi
C
A
B
Architektura systemu
komputerowego

Von Neumanna

Architektura systemu
obiektowego

F(1)

F(2)

…

Слайд 26

Ewolucja technik programowania
Programowanie obiektowe:
główne zadanie to modelowanie „obiektów” (tzn. rzeczy,

zjawisk), a nie „danych.”;
modelowanymi obiektami mogą być zarówno elementy programowe (np. przyciski, pola list), jak i obiekty świata rzeczywistego, np. samoloty, organizmy, procesy;
łączy w logiczną całość dane oraz manipulujące nimi funkcje;
wspiera konstruowanie systemów od szczegółu do ogółu – zysk:
umożliwia ponowne wykorzystanie komponentów;
ułatwia modyfikowanie oprogramowania;

Слайд 27

Koncepcja obiektowości
obiektowość - cecha naturalnego postrzegania świata - analiza otoczenia poprzez

relacje między obserwatorem a otaczającymi obiektami;
świat jest złożony - składa się z wielu funkcjonujących obiektów, pozostających w pewnych relacjach względem siebie;
obiektami są ludzie, państwa, domy, samochody, ale także płace, zadania, decyzje…;
obiektowość jest podstawą obiektowej analizy, projektowania i programowania systemów;

Слайд 28

Koncepcja obiektowości
Paradygmat obiektowy (podstawowy styl, techniki oraz wspomagające je konstrukcje językowe)

:
abstrakcja
hermetyzacja (kapsułkowanie)
dziedziczenie
tożsamość instancji klas (obiektów)
polimorfizm
komunikaty
klasy generyczne

Слайд 29

Koncepcja obiektowości
Abstrakcja:
Wszystko jest obiektem;
Program to zbiór obiektów, które się ze sobą

komunikują wysyłając sobie komunikaty;
Każdy obiekt składa się z innych obiektów;
Każdy obiekt ma swój typ;
Wszystkie obiekty tego samego typu akceptują te same komunikaty;
Proces projektowania ignoruje detale:
Co odróżnia obiekt od pozostałych?
Co obiekt może robić? (nie jest interesujące, jak to robi)
wg Alan Kay, autor języka Smalltalk

Слайд 30

Koncepcja obiektowości
Obiekt:
podstawowa jednostka konstrukcyjna;
konkretny lub abstrakcyjny byt (wyróżnialny w modelowanej

rzeczywistości) posiadający nazwę, jednoznaczną identyfikację, określone granice, atrybuty i inne własności;
posiada następujące rodzaje właściwości i odpowiedzialności:
Atrybuty – reprezentują stan obiektu i związki z innymi obiektami, np. kolor, rozmiar, przynależność…
Procedury (usługi, metody) – operacje, które obiekt może wykonywać, np. przemieszczanie, całkowanie, wyznaczanie stanu konta…
Zasady – niezmiennicze reguły określające widzialność obiektu i sposób powiązania z innymi obiektami.
abstrakcyjny typ danych, korzystający z dostępnych w języku programowania typów danych wraz z operacjami, które mogą być wykonywane na tych typach;

Слайд 31

Koncepcja obiektowości
Klasa:
zbiór obiektów, mających wspólne atrybuty i metody;
wzorzec dla konkretnych egzemplarzy

klasy – obiektów;
instensja typu obiektowego - definicja pojęcia, pewna koncepcja, idea stosująca się do określonej grupy obiektów, np. środek umożliwiający transport ludzi i rzeczy;
ekstensja typu obiektowego - zbiór konkretnych typów (klas, pojęć), np. pojazdy lądowe, statki powietrzne i wodne;
wyrażenie językowe specyfikujące budowę obiektów, dozwolone operacje na obiektach, ograniczenia dostępu, wyjątki, itd.

Слайд 32

Koncepcja obiektowości
Klasy i ich instancje
Jedna klasa może mieć wiele instancji, które

różnić się mogą wartościami atrybutów. Każde wystąpienie klasy nazywane jest Instancją Klasy lub Obiektem.

Слайд 33

Koncepcja obiektowości
Hermetyzacja (kapsułkowanie, enkapsulacja)
zamknięcie pewnego zestawu bytów programistycznych w “kapsułę” o

dobrze określonych granicach;
informacja o wewnętrznej budowie obiektu nie jest dostępna poza jego definicją – oddzielenie specyfikacji obiektu (także klasy, modułu, ...) od implementacji;
ortodoksyjna hermetyzacja – wszelkie operacje, które można wykonać na obiekcie, są określone przez metody obiektu danej klasy a bezpośredni dostęp do atrybutów obiektu jest niemożliwy (każdy atrybut ma skojarzone dwie operacje – odczyt, zapis);
ortogonalna hermetyzacja – dowolny atrybut obiektu (i dowolna metoda) może być prywatny (niedostępny z zewnątrz) lub publiczny;

Слайд 34

Koncepcja obiektowości
Dziedziczenie
związek pomiędzy klasami obiektów, określający przekazywanie cech (definicji atrybutów, metod,

itd.) z nadklasy do jej podklas;
np. obiekt klasy Samochód dziedziczy wszystkie własności (definicje atrybutów, metody) określone w klasie Pojazd;
dziedziczenie jest podstawowym mechanizmem sprzyjającym ponownemu użyciu i rozszerzaniu;
formy dziedziczenia:
statyczne
dynamiczne,
jednostkowe,
wielokrotne;

Слайд 35

Koncepcja obiektowości
class Pojazd {
public:
virtual void jedz() { cout << "Jade"

<< endl; }
virtual void hamuj() { cout << "Hamuje" << endl; }
};
class Samochod : public Pojazd {
public:
virtual void otworzDrzwi() { cout << "Otwieram drzwi" << endl; }
virtual void zatankuj() { cout << "Tankuje" << endl; }
};
class SamochodOsobowy : public Samochod {
public:
virtual void zapnijFotelikDzieciecy() { cout << "Zapinam fotelik" << endl; }
};
int main() {
SamochodOsobowy samochodOsobowy;
Samochod& samochod = samochodOsobowy;
Pojazd& pojazd = samochodOsobowy;
samochodOsobowy.hamuj();
samochod.hamuj();
pojazd.hamuj();
return 0;
}

Слайд 36

$Koncepcja obiektowości class Pojazd { protected: string nazwa; public: Pojazd(string _nazwa)$

Koncepcja obiektowości
class Pojazd {
protected:
string nazwa;
public:
Pojazd(string _nazwa) { nazwa =

_nazwa; }
virtual void jedz() { cout << "Jade" << endl; }
virtual void hamuj() { cout << "Hamuje" << endl; }
};
class Lodz {
protected:
double wypornosc;
public:
Lodz(double _wypornosc){ wypornosc = _wypornosc; }
};
class Amfibia : public Pojazd, public Lodz {
...
};

Dziedziczenie wielobazowe

Слайд 37

Ewolucja technik programowania
Funkcje programu
Np. obliczanie wartości X
Stany programu (dane)
Np. X =

[x1, x2, …, xN]
Klasy i obiekty
relacje
Agenty
autonomia
komunikacja
percepcja
agent, agenty – forma bezosobowa

Funkcje

Stan

Слайд 38

Ewolucja technik programowania
http://www.tiobe.com

Слайд 39

Ewolucja technik programowania
Zestawienie cech wybranych języków programowania

Слайд 40

Ewolucja technik programowania
Pamiętać jednak należy, że:
Programowanie nie zaczyna się i nie

kończy na przekładaniu pomysłów z głowy na polecenia języka programowania – po drodze są różne etapy/fazy/dyscypliny/zadania;
Podobnie jak budowa domu – potrzebny są:
pomysł, prototyp/projekt, murarz, aranżator wnętrz, wyposażenie, użytkownik, sponsor;
Odpowiada to w programowaniu pojęciom:
koncepcja, makieta/projekt, programista, grafik GUI, dane, użytkownik i sponsor.
Kodowanie (programowanie) jest tylko jedną z faz/etapów;

Слайд 41

Geneza inżynierii oprogramowania

Слайд 42

Kryzys oprogramowania
Od początku lat 60-tych trwa walka z syndromem LOOP;
1968, 1969

- konferencje sponsorowane przez NATO w Garmisch i Rzymie;

Loop

Слайд 43

Kryzys oprogramowania

Слайд 44

Kryzys oprogramowania
Walka z kryzysem oprogramowania:
Usuń przyczyny -> wyeliminujesz zauważone symptomy;
Stosowanie

technik i narzędzi ułatwiających pracę nad złożonymi systemami;
Korzystanie z metod wspomagających analizę nieznanych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń;
Usystematyzowanie procesu wytwarzania oprogramowania, tak, aby ułatwić jego planowanie i monitorowanie;
Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia;

Слайд 45

Co to jest inżynieria oprogramowania?
Jest to dziedzina inżynierii, która obejmuje wszystkie

aspekty tworzenia oprogramowania od fazy początkowej do jego pielęgnacji;
Inżynieria oprogramowania jest wiedzą empiryczną, syntezą doświadczenia wielu ośrodków zajmujących się budową oprogramowania;
Informatyka obejmuje teorie i podstawowe zasady działania komputerów a inżynieria oprogramowania obejmuje praktyczne problemy konstruowania oprogramowania;
Zajmuje się efektywnymi teoriami, metodami i narzędziami związanymi z procesem wytwarzania oprogramowania;
Zastosowanie systematycznego, zdyscyplinowanego, ilościowego podejścia do wykonywania, wykorzystywania i konserwowania oprogramowania [IEEE 93];

Слайд 46

Co to jest inżynieria oprogramowania?
Metodyki:
Strategia postępowania oparta na doświadczeniach i heurystykach

oraz formalnych elementach;
Zbiór reguł, zasad, metod, technik i narzędzi wykorzystywany do realizacji funkcji planowania, zarządzania, projektowania i realizacji przedsięwzięć informatycznych;
Metody:
uporządkowane procedury budowy oprogramowania, które poprzez zdefiniowane techniki umożliwią posługiwanie się narzędziami w celu poznania rzeczywistości oraz modelowania jej zgodnie z przyjętym celem działania;

Слайд 47

Co to jest inżynieria oprogramowania?
Techniki:
szczegółowo określone sposoby (z wykazem czynności) posługiwania

się środkami, w tym narzędziami, z danej metody dla osiągnięcia założonego celu;
Narzędzia CASE:
przeznaczone do wspomagania rutynowych czynności, takich jak praca nad diagramami projektowymi, sprawdzanie poprawności diagramów oraz śledzenie wykonanych testów;
Upper-CASE (dla wszystkich etapów);
Lower-CASE (wspomaganie implementacji);
Integrated-CASE (wszystkie fazy);

Слайд 48

Proces tworzenia oprogramowania
Jest to zbiór czynności i związanych z nimi

wyników, które prowadzą do powstania produktu programowego;
Zasadnicze czynności wspólne dla wszystkich procesów:
Specyfikowanie oprogramowania
Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane;
Projektowanie i implementowanie oprogramowania
Oprogramowanie, które spełnia specyfikację, musi być stworzone;
Zatwierdzenie oprogramowania
Wytworzone oprogramowanie musi spełniać oczekiwania klienta;
Ewolucja oprogramowania
Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników;

Слайд 49

Modele procesu tworzenia oprogramowania
Model kaskadowy (wodospadowy) - waterfall model

Definiowanie wymagań
Projektowanie

systemu
i oprogramowania

Implementacja i testowanie
jednostek

Integracja i testowanie systemu

Działanie i pielęgnacja

Слайд 50

Modele procesu tworzenia oprogramowania
Tworzenie iteracyjne
ocena
wymagania
planowanie
planowanie
wstępne
analiza i projektowanie
implementowanie
testowanie
dystrybucja
zarządzanie
środowiskiem

Слайд 51

Modele procesu tworzenia oprogramowania
Ewolucja inżynierii oprogramowania - podsumowanie:
Assembly -> Fortran/COBOL ->

Simula -> C++ -> Java / C#
prosty HW -> BIOS -> OS -> Middleware -> Domain-specific
Waterfall -> Spiral -> Iterative -> Agile
Procedural -> Object Oriented -> Service Oriented
Early tools -> CLE -> IDE -> XDE -> CDE
Individual -> Workgroup -> Organization

Języki:
Platformy:
Modele (cykle):
Architektura:
Narzędzia:
Org. pracy:

Слайд 52

Proces tworzenia oprogramowania
Zbiór czynności i związanych z nimi wyników, które

prowadzą do powstania produktu programowego;
Zasadnicze czynności wspólne dla wszystkich procesów:
Specyfikowanie oprogramowania
Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane;
Projektowanie i implementowanie oprogramowania
Oprogramowanie, które spełnia specyfikację, musi być stworzone;
Zatwierdzenie oprogramowania
Wytworzone oprogramowanie musi spełniać oczekiwania klienta;
Ewolucja oprogramowania
Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników;

Слайд 53

Czynności procesu tworzenia oprogramowania
Projektowanie i implementowanie wymagań:
Metody projektowania:
Stosowanie metod strukturalnych i

obiektowych, które są zbiorami notacji i porad dla projektantów oprogramowania;
Ich użycie polega głównie na opracowaniu graficznych modeli systemu oraz opisów tekstowych wg ustalonych szablonów;
Metody strukturalne obejmują np.:
modele przepływu danych,
modele encja-związek;
Niezwykle popularne są metody obiektowe, w tym np.:
modele klas, dynamiki,
modele architektury;
Niestety wciąż jeszcze projektowanie jest działaniem ad hoc, gdzie wymagania zapisuje się w języku naturalnym;

Слайд 54

Czynności procesu tworzenia oprogramowania
Projektowanie i implementowanie oprogramowania:
Celem fazy określania wymagań jest

udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić?
Faza analizy:
Jest łącznikiem między specyfikacją wymagań a projektowaniem;
Ustalane są wszystkie uwarunkowania dziedzinowe, organizacyjne i inne, które mogą wpłynąć na decyzje projektowe i na realizację wymagań;
Celem fazy analizy jest udzielenie odpowiedzi na pytanie: Jak system ma działać?
wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujących od szczegółów implementacyjnych;

Слайд 55

Czynności procesu tworzenia oprogramowania
Projektowanie i implementowanie oprogramowania:
Faza projektowania oprogramowania:
opis struktury

oprogramowania, które ma być zaimplementowane, opis danych, które są częścią systemu, opis interfejsów między komponentami systemu i użytych algorytmów;
Celem fazy projektowania jest udzielenie odpowiedzi na pytanie: Jak system ma być zaimplementowany?
faza projektowania może obejmować opracowanie wielu modeli systemu na różnych poziomach abstrakcji;
Wynikiem jest szczegółowy opis sposobu implementacji;
Faza implementowania w tworzeniu oprogramowania to proces przekształcania specyfikacji systemu w działający system;

Слайд 56

Czynności procesu tworzenia oprogramowania
Projektowanie i implementowanie wymagań:
Charakterystyczne składowe analizy i projektowania:

Слайд 57

Projektowanie architektury systemu
System informatyczny jest złożoną konstrukcją, której stopień skomplikowania zależy

od złożoności architektury;
Wielkie systemy są zwykle podzielone na podsystemy, które oferują pewien zbiór powiązanych ze sobą interfejsów;
Wymagane jest projektowanie architektoniczne, którego wynikiem jest opis architektury oprogramowania;
Urzeczywistnienie pomysłów architektonicznych wymaga:
idei (pomysł, cel),
planów (architektura, zagospodarowanie),
wiedzy (metody, techniki),
zasobów (materiały, narzędzia, czas, ludzie),
nadzoru i pielęgnacji we wszystkich etapach życia (projekt, budowa, użytkowanie, wycofanie);

Слайд 58

Projektowanie architektury systemu
Modele obiektowe:
Model obiektowy architektury systemu dzieli system na zbiór

luźno uzależnionych od siebie obiektów, z dobrze zdefiniowanymi interfejsami.
Obiekty korzystają z usług oferowanych przez inne obiekty.
Podział obiektowy uwzględnia klasy obiektów, ich atrybuty i operacje.

Слайд 59

Metodyki strukturalne a obiektowe
Metodyki strukturalne:
metodyki strukturalne są dojrzałe, lecz mogą nie

być adekwatne do współczesnych tendencji wytwarzania systemów informatycznych;
wadą metodyk strukturalnych są trudności w zintegrowaniu modeli;
Metodyki obiektowe:
intuicyjne podejście do modelowania;
relatywnie młode i szybko zmieniające się;
wprowadzają narzuty implementacyjne;
dobre dla systemów czasu rzeczywistego;

Слайд 60

Obiektowe podejścia do wytwarzania oprogramowania
System jest analizowany w sposób obiektowy jeśli:
Jest

dzielony na obiekty posiadające:
Tożsamość, Stan, Zachowanie
Obiekty są grupowane w klasy złożone z obiektów o podobnych stanach i zachowaniu
Metody obiektowe:
są wygodnym narzędziem analizy złożonych systemów, w szczególności systemów o dużej stronie pasywności i złożonej funkcjonalności
ukrywają dane (hermetyzacja)
wykorzystują gotowe elementy
pozwalają na szybkie prototypowanie i przyrostowy rozwój
programowanie oparte na zdarzeniach

Слайд 61

Obiektowe podejścia do wytwarzania oprogramowania
OODA (Booch Methodology),
Object Modelling Technique - OMT

(Rumbaugh),
Objectory(Jacobson),
OOA/OOD(Coad/Yourdon),
Express,
OOSA(Shlaer-Mellor),
MOSES/OPEN,
Real-Time Object-Oriented Modelling,
Schlear-Mellor,
UML->RUP;

Слайд 62

Obiektowe podejścia do wytwarzania oprogramowania
OMT-2 (rozwinięcie OMT-1):
technika modelowanie obiektów;
nacisk na

analizę systemów oprogramowania;
słaba w projektowaniu;
Booch ’93 (powstała z Booch ’91):
nacisk na projektowanie i tworzenie systemów oprogramowania;
słaba w analizie;
OODE
obiektowa technika programowania;
kładła nacisk na modelowanie biznesowe i analizę wymagań;

Слайд 63

Obiektowe podejścia do wytwarzania oprogramowania
Analiza obiektowa
opracowanie modelu obiektowego dziedziny zastosowania;
rozpoznane

obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem;
Projektowanie obiektowe
opracowanie modelu obiektowego systemu oprogramowania, który będzie implementacją zidentyfikowanych wymagań;
obiekty projektu obiektowego są związane z rozwiązaniem problemu;
Programowanie obiektowe
realizacja projektu oprogramowania za pomocą języka programowania obiektowego;
języki obiektowe umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do definiowania klas obiektów;

Слайд 64

Faza analizy
Identyfikacja aktorów:
Grupy użytkowników wspierane przez system w:
podstawowych i drugoplanowych zadaniach;
administrowaniu

i utrzymywaniu;
Źródła danych wej. i odbiorcy wyników:
osoby;
zewnętrzne systemy lub urządzenia;
Identyfikacja przypadków użycia:
Jakie zadania dla użytkownika realizuje system?
Jakie dane z systemu interesują użytkownika lub system zewnętrzny?
Czy są zainteresowani zdarzeniami w systemie?
Max liczba przypadków użycia: 5-15, 15-40, 40-100;

Слайд 65

Faza analizy
Identyfikacja klas obiektów - typowe klasy:
przedmioty namacalne (np. samochód, czujnik),
role

pełnione przez osoby (np. pracownik, wykładowca, student),
zdarzenia, o których system przechowuje informacje (lądowanie samolotu, wysłanie zamówienia, dostawa),
interakcje pomiędzy osobami i/lub systemami o których system przechowuje informacje (np. pożyczka, spotkanie, sesja),
lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów,
grupy przedmiotów namacalnych (np. kartoteka, samochód jako zestaw części),
organizacje (np. firma, wydział, związek),
wydarzenia (np. posiedzenie sejmu, demonstracja uliczna),
koncepcje i pojęcia (np. zadanie, miara jakości),
dokumenty (np. faktura, prawo jazdy),
interfejsy do systemów zewnętrznych,
interfejsy do urządzeń sprzętowych;

Слайд 66

Faza analizy
Obiekty, zbiory obiektów i metadane:
W wielu przypadkach przy definicji klasy

należy dokładnie ustalić, z jakiego rodzaju abstrakcją obiektu mamy do czynienia;
Należy zwrócić uwagę na następujące aspekty:
czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej?
czy mamy do czynienia z konkretnym obiektem w pewnym odcinku czasu?
czy mamy do czynienia z opisem tego obiektu (dokument, metadane)?
czy mamy do czynienia z pewnym zbiorem konkretnych obiektów?
Np. klasa „samochód” - może chodzić o:
egzemplarz samochodu wyprodukowany przez pewną fabrykę;
model samochodu produkowany przez fabrykę;
pozycję w katalogu samochodów opisujący własności modelu;
historię stanów pewnego konkretnego samochodu;

Слайд 67

Faza analizy
Zalecenia dotyczące identyfikacji klas:
Wyraźnie zdefiniować kontekst (w tym opis) klasy;
Unikać

w nazwie synonimów i nazw zbliżonych znaczeniowo;
Pomijać klasy, które nie mieszczą się w zakresie systemu;
Wyeliminować klasy będące w rzeczywistości:
atrybutami lub grupami atrybutów (właściwościami) innych klas;
operacjami (usługami) innych klas;
związkami lub rolami pełnionymi w związkach przez inne klasy;
→ można połączyć takie byty w większe klasy;
Utworzyć wiele klas z jednej, jeżeli grupuje atrybuty lub operacje kontekstowo odległe;
Uzupełnić o atrybuty opisujące klasy w kontekście systemu;
Klasy kontekstowo powiązane pogrupować w podsystemy – np. kandydatami są grupy powiązane silnymi relacjami (np. dziedziczenie);
Unikać w tej fazie klas reprezentujących elementy implementacyjne;

Слайд 68

Faza analizy
Zalecenia dotyczące identyfikacji związków klas:
Unikać związków bez klasy docelowej;
Pomijać związki

z elementami spoza systemu;
Dążyć do związków dwuelementowych;
Zwracać szczególną uwagę na związki trwałe w czasie – związki nietrwałe wykorzystać podczas konstrukcji modelu dynamicznego (np. do budowy komunikatów);
Kompletować związki i role klas w związkach;
Uszczegółowić związki o krotności obiektów;
Klasy o podobnych cechach powiązać relacją dziedziczenia;
Zweryfikować dostępność informacji w modelu klasy-związki-klasy z różnych punktów startowych;
Unikać w tej fazie związków reprezentujących zależności implementacyjne;

Слайд 69

Faza analizy
Zalecenia dotyczące modelu dynamicznego klas:
Koncentrować się na behawioralnych aspektach systemu;
Rozpatrzeć

interakcje związane z pożądanym, błędnym i awaryjnym zachowaniem systemu;
Kompletować „trójki”: Nadawca (Aktor lub obiekt)-zdarzenie-Odbiorca;
Przedstawić uporządkowany w czasie przepływ zdarzeń w systemie dla każdej klasy;
Zdarzenia odpowiadające jednej klasie należy łączyć we wspólny diagram;

Слайд 70

Faza analizy
Kluczowe czynniki sukcesu fazy analizy
Zaangażowanie właściwych osób ze strony klienta;
Kompleksowe

i całościowe podejście do problemu, nie koncentrowanie się na partykularnych jego aspektach;
Nie unikanie trudnych problemów (bezpieczeństwo, skalowalność, szacunki objętości i przyrostu danych, itd.);
Zachowanie przyjętych standardów, np. w zakresie notacji;
Sprawdzenie poprawności i wzajemnej spójności modelu;
Przejrzystość, logiczny układ i spójność dokumentacji;

Слайд 71

Od analizy do szczegółowego projektu obiektów
Celem projektowania jest opracowanie szczegółowego opisu

implementacji systemu.
W odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa środowisko implementacji.
Dwa etapy fazy projektowania:
projekt strategiczny, projekt systemy (strategic, system design):
podział na podsystemy,
współbieżność,
przechowywanie danych,
sterowanie.
projekt szczegółowy (detailed design):
uściślanie definicji klas,
dziedziczenie,
optymalizacja modelu,
modularyzacja,
ukrywanie informacji;

Слайд 72

Faza projektowania
Zadania w etapach fazy projektowania:
uściślenie istniejących definicji klas, np. metod,

dziedziczenie klas i operacji,
szczegółowy projekt operacji wraz z przeprojektowaniem ich algorytmów,
wprowadzenie ogólnych mechanizmów realizacji dynamiki obiektów,
decyzje o trwałości obiektów,
modularyzacja i ukrywanie informacji,
optymalizacja modelu,
dokumentacja projektu;
Zatem projektanci muszą więc posiadać dobrą znajomość języków, bibliotek, i narzędzi stosowanych w trakcie implementacji;

Слайд 73

Faza projektowania
Zadania fazy projektowania – przykład uściślenia definicji metod;
Podanie nagłówków

metod oraz ich parametrów.
Określenie, które z metod będą realizowane jako funkcje wirtualne (poźno wiązane) a które jako zwyczajne funkcje (wiązane statyczne).
Zastąpienie niektórych prostych metod bezpośrednim dostępem do atrybutów.
Np. metody PobierzNazwisko, UstawNazwisko, etc.
Zastąpienie niektórych atrybutów redundantnych przez odpowiednie metody, np.
Wiek = BieżącaData - DataUrodzenia;
KwotaDochodu = KwotaPrzychodu - KwotaKosztów;

Слайд 74

Faza projektowania
Zadania fazy projektowania – przykład sposobu implementacji związków (asocjacji);
Związki

można zaimplementować na wiele sposobów, z reguły poprzez wprowadzenie dodatkowych atrybutów (pól) - mogą one być następujące:
obiekty powiązanej klasy,
wskaźniki (referencje) do obiektów powiązanej klasy,
identyfikatory obiektów powiązanej klasy,
klucze kandydujące obiektów powiązanej klasy;
W zależności od przyjętego sposobu oraz od liczności związków (1:1, 1:n, n:1, m:n) możliwe są bardzo różne deklaracje w przyjętym języku programowania.

TypSłowoKluczowe SłowaKluczowe[100];
list< TypSłowoKluczowe *> SłowaKluczowe;
char * WskaźnikiSłówKluczowych[100];

Tablica obiektów:
Lista wskaźników:
Tablica wskaźników:

Слайд 75

Podstawowe rezultaty fazy projektowania
Poprawiony i uszczegółowiony dokument opisujący wymagania;
Poprawione i uszczegółowione

modele;
Uszczegółowiona specyfikacja słownika danych;
Dokument opisujący stworzony projekt składający się z (dla obiektowych):
diagramu klas
diagramów interakcji obiektów
diagramów stanów
innych diagramów, np. diagramów modułów, konfiguracji
zestawień zawierających:
definicje klas
definicje atrybutów
definicje danych złożonych i elementarnych
definicje metod
Zasoby interfejsu użytkownika, np. menu, dialogi;
Projekt bazy danych;
Projekt fizycznej struktury systemu;
Poprawiony plan testów;
Pierwszy harmonogram implementacji;

Слайд 76

RUP
Ukierunkowany na przypadki użycia
Architekturo-centryczny
Iteracyjny
Przyrostowy
Sterowany ryzykiem

Слайд 77

RUP
Dwa wymiary RUP
FAZY (ang. phases)
PRZEPŁYWY, DYSCYPLINY (ang. disciplines)

Слайд 78

RUP
Proces budowy systemu informatycznego składa się z dyscyplin, z których każda

dzielona jest na fazy:
Rozpoczęcie
Opracowanie
Budowa
Przekazanie
Kamienie milowe
Podejście iteracyjne

Слайд 79

O czym teraz…
Geneza i charakterystyka UML;
Zapoznanie z wybraną notacją wykorzystywaną w

modelowaniu, analizie i projektowaniu systemów informatycznych;

Слайд 80

UML – notacja obiektowa
Rodzaje notacji:
tekstowo-opisowa,
specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny,
notacje

graficzne;
Jeżeli notacja posiada składnię (np. symbole graficzne) oraz semantykę (znaczenie symboli graficznych), staje się językiem;
Szczególną uwagę skupimy na notacji graficznej;
Omówimy notację (język) UML….

Слайд 81

UML – notacja obiektowa

Слайд 82

UML – notacja obiektowa
Unified Modeling Language – UML
The Unified Modeling Language™

(UML™) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. (http://www-306.ibm.com/software/rational/uml/)
Znormalizowany język graficzny służący do specyfikowania, tworzenia i dokumentowania wyników (np. modeli) systemów informatycznych;
Cechy:
uniwersalny – może być stosowany do modelowania zarówno systemów informacyjnych, systemów WWW, systemów czasu rzeczywistego;
wspomaga jednoznacznie i szczegółowo specyfikowanie istotnych decyzji etapów analizy, projektu i implementacji;
umożliwia dokumentowanie architektury systemu i wszystkich jego szczegółów w postaci tzw. artefaktów: wymagania, architektura, projekt, kod źródłowy, plany projektu, testy, prototypy, kolejne wersje.

Слайд 83

UML – składowe
Perspektywy modelowe – 4+1:
Implementacyjna
Przypadków użycia
Wdrożenia
Logiczna
Procesowa

Слайд 84

UML – składowe
Słownik UML dzieli się na trzy grupy:
elementy,
związki

(relacje),
diagramy;
Model – kolekcja diagramów i informacji dodatkowych, opisujących statyczne i dynamiczne aspekty modelowanego systemu;

Слайд 85

UML – elementy
Elementami UML są podstawowe obiektowe bloki konstrukcyjne stosowane do

budowy modeli:
strukturalne
statyczne części modelu reprezentujące składniki pojęciowe lub fizyczne;
klasa, interfejs, przypadek użycia, komponent, węzeł, kooperacja (grupa współdziałania);

Kooperacja

Przypadek
użycia

Węzeł

Interfejs

Слайд 86

UML – elementy
Elementami UML są podstawowe obiektowe bloki konstrukcyjne stosowane do

budowy modeli:
czynnościowe
elementy dynamiczne wyrażone czasownikami
interakcja, stan;

stan

Pokaż okno

Слайд 87

UML – elementy
Elementami UML są podstawowe obiektowe bloki konstrukcyjne stosowane do

budowy modeli:
grupujące
bloki organizacyjne modelu;
pakiet;
komentujące
elementy objaśniające dla uwypuklenia lub zaznaczenia składników;
notatka;

Notka

Слайд 88

UML – związki
Związki:
służą do łączenia elementów;
w praktyce najczęściej stosowane są

powiązanie i uogólnienie;
zależność, powiązanie (asocjacja), uogólnienie (generalizacja), realizację;

związek zależności
związek asocjacji
związek generalizacji
związek realizacji

10..20

Rola 1

Rola 2

Слайд 89

UML – związki
Związki klas:
Zależność
Asocjacja
Jednokierunkowa
Dwukierunkowa
Agregacja
Kompozycja
Generalizacji
Realizacja

Слайд 90

UML – notacja związków
Przykład:
Klasa abstrakcyjna
1..* 1
Widoczność:
- private
# protected
+ public
Krotność związku

Слайд 91

UML – notacja diagramów
Diagram przypadków użycia:
Przypadek 1
Przypadek 2
Przypadek 3
Przypadek 4
„extend”
„include”
generalizacja
generalizacja
asocjacja
Protokół komunikacji

pomiędzy użytkownikiem a usługą

„include” oraz „extend” są standardowymi stereotypami uszczegóławiającymi związek

Слайд 92

UML – przykład systemu ewidencji studentów
Diagram przypadków użycia

Слайд 93

UML – przykład systemu ewidencji studentów
Diagram klas (1) – klasy

abstrakcyjne

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

Слайд 94

UML – przykład systemu ewidencji studentów
Diagram klas (2) – klasy

uszczegółowione

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

dodajStudenta(Kurs, daneStudent)

liczbaMiejsc
nazwa

nazwisko
nr indeksu

nazwisko
specjalizacja

dodajStudenta(daneStudenta)
otwórzKurs()

miejsce

Слайд 95

UML – przykład systemu ewidencji studentów
Diagram klas (3) – związki

klas

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

dodajStudenta(Kurs, daneStudent)

liczbaMiejsc
nazwa

nazwisko
…

nazwisko
specjalizacja

dodajStudenta(daneStudenta)
otwórzKurs()

miejsce

0..*

1..*

3..10

0..4

Слайд 96

UML – przykład systemu ewidencji studentów
Diagram klas (4) – skierowanie

i krotności związków

Arkusz rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

dodajStudenta(Kurs, daneStudent)

liczbaMiejsc
nazwa

nazwisko
nr indeksu

nazwisko
specjalizacja

dodajStudenta(daneStudenta)
otwórzKurs()

miejsce

0..*

1..*

3..10

0..4

Слайд 97

UML – przykład systemu ewidencji studentów
Diagram klas (5) – generalizacja
Arkusz

rejestracji

Kierownik ewidencji

Kurs

Student

Oferta kursów

Profesor

Algorytm zarządzania

dodajStudenta(Kurs, daneStudent)

liczbaMiejsc
nazwa

nr indeksu

specjalizacja

dodajStudenta(daneStudenta)
otwórzKurs()

miejsce

0..*

1..*

3..10

0..4

nazwisko

Osoba

Слайд 98

UML – przykład systemu ewidencji studentów
Diagram sekwencji zdarzeń
: Student
arkusz

rejestracji

kierownik

ewidencji

Kurs 1

1: wprowadzenie danych

2: zatwierdzenie

3: dodanie osoby(Nowak, Kurs 1)

4: Czy otwarty?

5: Czy otwarty?

6: Dodaj(Nowak)

7: Dodaj(Nowak)

Слайд 99

UML – przykład systemu ewidencji studentów
Diagram współpracy
: Rejestrujący
arkusz kursu

ArkuszKursu

Kierownik :

KierownikProgramowy

kurs :

Kurs

1: określ opis kursu

2: przetwarzaj

3: dodaj kurs

4: nowy kurs

Слайд 100

UML – przykład systemu ewidencji studentów
Diagram stanów
Inicjalizacja
Otwieranie
entry: Zarejestruj studenta
exit: Zwiększ

licznik

Zamknięcie

Anulowanie

do: Inicjalizuj kurs

do: Zamknij kurs

do: Powiadom studenta

Dodaj Studenta /

Licznik = 0

Dodaj Studenta[ licznik < 10 ]

[ Licznik = 10 ]

Anuluj

Слайд 101

System mapy pogody
Przykład z książki Iana Sommerville’a „Inżynieria oprogramowania”
System tworzący mapy

pogody ma regularnie generować mapy pogody;
Źródła danych:
zdalne, niestrzeżone stacje meteorologiczne,
inne źródła danych: obserwatorzy pogody, balony i satelity;
Stacje meteorologiczne
przekazują dane do komputera obszaru na jego żądania;
System komputera obszaru
weryfikuje i integruje dane zebrane z różnych źródeł;
Po zintegrowaniu dane są archiwizowane w zbiorach;
Lokalne mapy pogody są tworzone na podstawie archiwum i bazy danych map komputerowych;
Mapy można drukować lub wyświetlać w różnych formatach;

Слайд 102

System mapy pogody
Zadania systemu:
zbieranie danych,
integracja danych z różnych źródeł,
archiwizowanie danych,
tworzenie

map pogody;
Każdy etap działania zależy jedynie od wyników przetwarzania z poprzedniego etapu;
Proponowana architektura:
warstwowa,
odzwierciedla etapy przetwarzania danych w systemie: zbieranie danych, integrację danych itd.;

Слайд 103

Architektura warstwowa systemu mapy pogody
Warstwa wyświetlania danych
Obiekty warstwy przygotowują dane w

postaci
zrozumiałej dla człowieka

Warstwa archiwizacji danych
Obiekty warstwy zajmują się składowaniem danych

Warstwa przetwarzania danych
Obiekty warstwy weryfikują i integrują dane

Warstwa gromadzenia danych
Obiekty warstwy zajmują się pozyskaniem danych ze zdalnych źródeł

Propozycja architektury systemu

Слайд 104

Podsystemy w systemie mapy pogody
<>
Gromadzenie
danych
Obserwator
Balon
Stacja meteoro-
logiczna
Satelita
Wspólne
<>
Przetwarzanie

danych

Sprawdzanie
danych

Integracja
danych

<>
Wyświetlanie
danych

Interfejs
użytkownika

Mapa

Drukarka
map

Wyświetlacz
map

Składowanie
danych

Składnica
map

Składnica
danych

<>
Archiwizacja danych

Слайд 105

Kontekst systemu i modele użycia systemu
Pierwszym krok procesu projektowania oprogramowania:
zrozumienie związków

między projektowanym oprogramowaniem a jego środowiskiem zewnętrznym;
określenie kontekstu systemu:
model statyczny;
tu jest to podsystem gromadzenia danych;
określenie modeli użycia systemu
model dynamiczny
opisuje, w jaki sposób system porozumiewa się ze swoim środowiskiem;

Слайд 106

Przypadki użycia stacji meteorologicznej

Слайд 107

Przypadki użycia stacji meteorologicznej
System Stacja meteorologiczna
Przypadek użycia Raportuj
Aktorzy System gromadzenia

informacji meteorologicznych, Stacja meteorologiczna
Dane Stacja meteorologiczna wysyła do systemu gromadzenia informacji meteorologicznych podsumowanie danych meteorologicznych odczytanych z przyrządów w określonym czasie. Przesyłane dane to: maksymalne, minimalne i średnie temperatury gruntu i powietrza, maksymalne, minimalne i średnie ciśnienia powietrza, maksymalną, minimalną i średnią prędkość wiatru, całkowity opad i kierunek wiatru (co 5 minut).
Bodziec System gromadzenia informacji meteorologicznych nawiązuje połączenie ze stacją meteorologiczną i wywołuje przekazanie danych.
Reakcja Wysyłanie podsumowania danych do systemu gromadzenia informacji meteorologicznych.
Komentarz Stacje meteorologiczne są proszone o raport zazwyczaj raz na godzinę. Ta częstotliwość może być inna dla różnych stacji i w przyszłości może ulec zmianie.

Opis przypadku użycia „Raportuj”

Слайд 108

Projektowanie architektury
Drugi krok procesu projektowania oprogramowania:
projektowanie architektury;
Architektura na przykładzie automatycznej

stacji meteorologicznej (model 3-warstwowy):
1-warstwa interfejsu –
porozumiewanie się z innymi częściami systemu i oferowanie zewnętrznych interfejsów systemu;
2-warstwa gromadzenia danych
zarządzanie odczytem danych z przyrządów i podsumowywanie danych meteorologicznych przed przesłaniem ich do systemu tworzącego mapy;
3-warstwa przyrządów
pakiet przyrządów służących do gromadzenia surowych danych o warunkach pogodowych;

Слайд 109

Architektura stacji meteorologicznej

Слайд 110

Klasy obiektów stacji meteorologicznej
Trzeci krok procesu projektowania oprogramowania:
Identyfikacja (wynajdowanie) klas i

obiektów;
StacjaMeteorologiczna - oferuje podstawowy interfejs stacji meteorologicznej;
DaneMeteorologiczne - jej operacje służą do gromadzenia i podsumowywania danych odczytanych z różnych przyrządów stacji meteorologicznej;
Termometr gruntowy, Wiatromierz i Barometr - bezpośrednio związane z przyrządami systemu; odzwierciedlają namacalne byty sprzętowe systemu; operacje służą do sterowania tym sprzętem;

Слайд 111

Klasy obiektów stacji meteorologicznej
StacjaMeteorologiczna
identyfikator
raportPogodowy ()
dostrój (przyrządy)
testuj ()
uruchom (przyrządy)
wyłącz

(przyrządy)

DaneMeteorologiczne
temperaturyPowietrza
temperaturyGruntu
siłyWiatru
kierunkiWiatru
cisnienia
opad
gromadź ()
podsumuj ()

Termometr gruntowy
temperatura
testuj ()
dostrój ()

Wiatromierz
SiłaWiatru
kierunekWiatru
test ()

Barometr
ciśnienie
wysokość
test ()
dostrój ()

Przykłady klas obiektów w systemie stacji meteorologicznej

Слайд 112

Klasy obiektów stacji meteorologicznej
<>
Interfejs
SterownikKomunikacji
StacjaMeteorologiczna
DaneMeteorologiczne

<>
Gromadzenie danych
Stan
przyrządów
<>
Przyrządy
Termometr
powietrza
Termometr

gruntowy

Barometr

Łopatka
wiatrowa

Wskaźnik
opadu

Wiatromierz

Przykład modelu podsystemów: powiązania obiektów stacji meteorologicznych

Слайд 113

Sekwencja zdarzeń
:Sterownik
Komunikacji
:Stacja
Meteorologiczna
:Dane
Meteorologiczne
podsumuj ()
raportuj ()
wyślij (raport)
żądanie (raport)
potwierdzenie ()
odpowiedź (raport)
potwierdzenie ()
Czwarty krok

procesu projektowania

Przebieg operacji Gromadzenia danych

Слайд 114

Diagramy stanów
Wyłączony
Działanie
Transmitowanie
Testowanie
Dostrajanie
Oczekiwanie
Podsumowywanie
Gromadzenie
uruchom ()
wyłącz ()
zegar
koniec
gromadzenia
koniec transmisji
testuj

()

dostrój ()

dostrojony

koniec testu

Podsumowanie
gotowe

podsumowanie
gotowe

raportPogodowy ()

Przykład dla klasy StacjaMeteorologiczna

Piąty krok procesu projektowania

Слайд 115

Specyfikowanie interfejsów obiektów
Szósty krok procesu projektowania:
specyfikowanie interfejsów między komponentami;
Pozwoli to

na równoległe projektowanie komponentów;
Jeden obiekt może mieć kilka interfejsów, które są sposobami postrzegania oferowanych metod;
Realizacja w Java - interfejsy są deklarowane w oderwaniu od obiektów, a obiekty „implementują” interfejsy;

Слайд 116

Specyfikowanie interfejsów obiektów
Interfejs StacjaMeteorologiczna {
public StacjaMeteorologiczna () ;
public void

uruchom () ;
public void uruchom (Przyrząd p) ;
public void wyłącz () ;
public void wyłącz (Przyrząd p) ;
public void raportPogodowy () ;
public void testuj () ;
public void testuj (Przyrząd p) ;
public void dostrój (Przyrząd p) ;
public int podajID () ;
} // StacjaMeteorologiczna

Слайд 117

Ewolucja projektu
Kolejne kroki projektowania:
uszczegółowienie uproszczonego modelu;
Zmiana wstępnie ustalonych szczegółów obiektu -

nie wpłynie na inne obiekty systemowe;
Wprowadzenie nowych obiektów - nie prowadzi do istotnych konsekwencji dla reszty systemu (obiekty są luźno powiązane);

Слайд 118

Ewolucja projektu
Do obiektu StacjaMeteorologiczna na tym samym poziomie co obiekt DaneMeteorologiczne

należy dodać obiekt o nazwie Jakość powietrza;
Należy dodać operację raport Jakości powietrza, której działanie polega na wysłaniu danych o zanieczyszczeniach do głównego komputera;
Należy dodać obiekty reprezentujące przyrządy do pomiaru poziomu zanieczyszczeń. W tym wypadku pomiarom będą podlegać tlenek azotu, dym i benzen;

Zaawansowane metody programowania obiektowego

Содержание

Program zajęćWprowadzenie w projektowanie i programowanie obiektoweMetody obiektowe projektowania oprogramowaniaElementy notacji

Zaliczenie przedmiotuZaliczenie przedmiotu - na podstawie: egzaminu oraz zaliczenia zajęć laboratoryjnych.Egzamin

Zaliczenie przedmiotuWszystkie konsultacje odbywają się ul. Domagalskiego 7aTerminy:2016-10-14, 8.50-9.352016-10-28, 8.50-9.352016-11-18, 8.50-9.352016-12-02,

Literatura podstawowaMetody obiektowe w teorii i w praktyce – Ian Graham,

Startujemy!

Trochę historii …Babilon (1790 p.n.e.) – tablice m.in. o zawartości matematycznej,

Trochę historii …1840 – Augusta Ada, córka lorda Byrona, od 19-tego

Trochę historii …1946 – powstał ENIAC (Electronic Numerical Integrator and Computer),

Trochę historii …Komputer przenośny ☺

Programowanie … oprogramowanieSystem komputerowy – układ współdziałania dwóch składowych: sprzętu komputerowego

Programowanie … oprogramowanieOprogramowanie – to programy komputerowe, ich dokumentacja, dane, pliki

Wymagania dla dobrego oprogramowaniaDobre oprogramowanie powinno zapewniać:użyteczność - dostępność oczekiwanych usług,

Programowanie … oprogramowanieJęzyk programowania powinien:wspomagać wierne odwzorowanie rzeczywistości,wymuszać i wspierać logiczną

Wymagania dla dobrego oprogramowania

Wymagania dla dobrego oprogramowania

Ewolucja technik programowaniaObecnie na świecie jest kilka tysięcy języków programowania;Już w

Ewolucja technik programowania195019601970198019902000Fortran(54)Ada(95)Java(96)A S S E M B L E R(ponad

Ewolucja technik programowaniahttp://www.tiobe.com

Podsumowaniehttp://www.tiobe.com

Ewolucja technik programowaniaParadygmat programowania (ang. programming paradigm) – zaakceptowany powszechnie wzorzec

Ewolucja technik programowania

Ewolucja technik programowaniaProgramowanie imperatywne – proces wykonywania programu jest sekwencją instrukcji

Ewolucja technik programowaniaprogramowanie proceduralne:program = seria procedur, działających na danych;dane całkowicie

Ewolucja technik programowaniaOd programowania strukturalnego do obiektowego…F(1)F(2)F(3)…F(n)System zarządzania danymiCABArchitektura systemu komputerowego

Ewolucja technik programowaniaProgramowanie obiektowe: główne zadanie to modelowanie „obiektów” (tzn. rzeczy,

Koncepcja obiektowościobiektowość - cecha naturalnego postrzegania świata - analiza otoczenia poprzez

Koncepcja obiektowościParadygmat obiektowy (podstawowy styl, techniki oraz wspomagające je konstrukcje językowe)

Koncepcja obiektowościAbstrakcja:Wszystko jest obiektem;Program to zbiór obiektów, które się ze sobą

Koncepcja obiektowościObiekt: podstawowa jednostka konstrukcyjna;konkretny lub abstrakcyjny byt (wyróżnialny w modelowanej

Koncepcja obiektowościKlasa:zbiór obiektów, mających wspólne atrybuty i metody;wzorzec dla konkretnych egzemplarzy

Koncepcja obiektowościKlasy i ich instancjeJedna klasa może mieć wiele instancji, które

Koncepcja obiektowościHermetyzacja (kapsułkowanie, enkapsulacja)zamknięcie pewnego zestawu bytów programistycznych w “kapsułę” o

Koncepcja obiektowościDziedziczeniezwiązek pomiędzy klasami obiektów, określający przekazywanie cech (definicji atrybutów, metod,

Koncepcja obiektowościclass Pojazd {public: virtual void jedz() { cout << "Jade"

Koncepcja obiektowościclass Pojazd {protected: string nazwa;public: Pojazd(string _nazwa) { nazwa =

Ewolucja technik programowaniaFunkcje programuNp. obliczanie wartości XStany programu (dane)Np. X =

Ewolucja technik programowaniahttp://www.tiobe.com

Ewolucja technik programowaniaZestawienie cech wybranych języków programowania

Ewolucja technik programowaniaPamiętać jednak należy, że:Programowanie nie zaczyna się i nie

Geneza inżynierii oprogramowania

Kryzys oprogramowaniaOd początku lat 60-tych trwa walka z syndromem LOOP;1968, 1969

Kryzys oprogramowania

Kryzys oprogramowania Walka z kryzysem oprogramowania:Usuń przyczyny -> wyeliminujesz zauważone symptomy;Stosowanie

Co to jest inżynieria oprogramowania?Jest to dziedzina inżynierii, która obejmuje wszystkie

Co to jest inżynieria oprogramowania?Metodyki:Strategia postępowania oparta na doświadczeniach i heurystykach

Co to jest inżynieria oprogramowania?Techniki:szczegółowo określone sposoby (z wykazem czynności) posługiwania

Proces tworzenia oprogramowania Jest to zbiór czynności i związanych z nimi

Modele procesu tworzenia oprogramowaniaModel kaskadowy (wodospadowy) - waterfall model Definiowanie wymagańProjektowanie

Modele procesu tworzenia oprogramowaniaTworzenie iteracyjneocenawymaganiaplanowanieplanowaniewstępneanaliza i projektowanieimplementowanietestowaniedystrybucjazarządzanie środowiskiem

Modele procesu tworzenia oprogramowaniaEwolucja inżynierii oprogramowania - podsumowanie:Assembly -> Fortran/COBOL ->

Proces tworzenia oprogramowania Zbiór czynności i związanych z nimi wyników, które

Czynności procesu tworzenia oprogramowaniaProjektowanie i implementowanie wymagań:Metody projektowania:Stosowanie metod strukturalnych i

Czynności procesu tworzenia oprogramowaniaProjektowanie i implementowanie oprogramowania:Celem fazy określania wymagań jest

Czynności procesu tworzenia oprogramowaniaProjektowanie i implementowanie oprogramowania:Faza projektowania oprogramowania: opis struktury

Czynności procesu tworzenia oprogramowaniaProjektowanie i implementowanie wymagań:Charakterystyczne składowe analizy i projektowania:

Projektowanie architektury systemuSystem informatyczny jest złożoną konstrukcją, której stopień skomplikowania zależy

Projektowanie architektury systemuModele obiektowe:Model obiektowy architektury systemu dzieli system na zbiór

Metodyki strukturalne a obiektoweMetodyki strukturalne:metodyki strukturalne są dojrzałe, lecz mogą nie

Obiektowe podejścia do wytwarzania oprogramowaniaSystem jest analizowany w sposób obiektowy jeśli:Jest

Obiektowe podejścia do wytwarzania oprogramowaniaOODA (Booch Methodology),Object Modelling Technique - OMT

Obiektowe podejścia do wytwarzania oprogramowaniaOMT-2 (rozwinięcie OMT-1): technika modelowanie obiektów;nacisk na

Obiektowe podejścia do wytwarzania oprogramowaniaAnaliza obiektowa opracowanie modelu obiektowego dziedziny zastosowania;rozpoznane

Faza analizyIdentyfikacja aktorów:Grupy użytkowników wspierane przez system w:podstawowych i drugoplanowych zadaniach;administrowaniu

Faza analizyIdentyfikacja klas obiektów - typowe klasy:przedmioty namacalne (np. samochód, czujnik),role

Faza analizyObiekty, zbiory obiektów i metadane:W wielu przypadkach przy definicji klasy

Faza analizyZalecenia dotyczące identyfikacji klas:Wyraźnie zdefiniować kontekst (w tym opis) klasy;Unikać

Faza analizyZalecenia dotyczące identyfikacji związków klas:Unikać związków bez klasy docelowej;Pomijać związki

Faza analizyZalecenia dotyczące modelu dynamicznego klas:Koncentrować się na behawioralnych aspektach systemu;Rozpatrzeć

Faza analizyKluczowe czynniki sukcesu fazy analizyZaangażowanie właściwych osób ze strony klienta;Kompleksowe

Od analizy do szczegółowego projektu obiektówCelem projektowania jest opracowanie szczegółowego opisu

Faza projektowaniaZadania w etapach fazy projektowania:uściślenie istniejących definicji klas, np. metod,

Faza projektowaniaZadania fazy projektowania – przykład uściślenia definicji metod; Podanie nagłówków

Faza projektowaniaZadania fazy projektowania – przykład sposobu implementacji związków (asocjacji); Związki

Podstawowe rezultaty fazy projektowaniaPoprawiony i uszczegółowiony dokument opisujący wymagania;Poprawione i uszczegółowione

Program zajęć
Wprowadzenie w projektowanie i programowanie obiektowe
Metody obiektowe projektowania oprogramowania
Elementy notacji

Zaliczenie przedmiotu
Zaliczenie przedmiotu - na podstawie: egzaminu oraz zaliczenia zajęć laboratoryjnych.
Egzamin

Zaliczenie przedmiotu
Wszystkie konsultacje odbywają się ul. Domagalskiego 7a
Terminy:
2016-10-14, 8.50-9.35
2016-10-28, 8.50-9.35
2016-11-18, 8.50-9.35
2016-12-02,

Literatura podstawowa
Metody obiektowe w teorii i w praktyce – Ian Graham,

Trochę historii …
Babilon (1790 p.n.e.) – tablice m.in. o zawartości matematycznej,

Trochę historii …
1840 – Augusta Ada, córka lorda Byrona, od 19-tego

Trochę historii …
1946 – powstał ENIAC (Electronic Numerical Integrator and Computer),

Trochę historii …
Komputer przenośny ☺

Programowanie … oprogramowanie
System komputerowy – układ współdziałania dwóch składowych: sprzętu komputerowego

Programowanie … oprogramowanie
Oprogramowanie – to programy komputerowe, ich dokumentacja, dane, pliki

Wymagania dla dobrego oprogramowania
Dobre oprogramowanie powinno zapewniać:
użyteczność - dostępność oczekiwanych usług,

Programowanie … oprogramowanie
Język programowania powinien:
wspomagać wierne odwzorowanie rzeczywistości,
wymuszać i wspierać logiczną

Ewolucja technik programowania
Obecnie na świecie jest kilka tysięcy języków programowania;
Już w

Ewolucja technik programowania
1950
1960
1970
1980
1990
2000
Fortran(54)
Ada(95)
Java(96)
A S S E M B L E R
(ponad

Ewolucja technik programowania
http://www.tiobe.com

Podsumowanie
http://www.tiobe.com

Ewolucja technik programowania
Paradygmat programowania (ang. programming paradigm) – zaakceptowany powszechnie wzorzec

Ewolucja technik programowania
Programowanie imperatywne – proces wykonywania programu jest sekwencją instrukcji

Ewolucja technik programowania
programowanie proceduralne:
program = seria procedur, działających na danych;
dane całkowicie

Ewolucja technik programowania
Od programowania strukturalnego do obiektowego…
F(1)
F(2)
F(3)
…
F(n)
System zarządzania danymi
C
A
B
Architektura systemu
komputerowego

Ewolucja technik programowania
Programowanie obiektowe:
główne zadanie to modelowanie „obiektów” (tzn. rzeczy,

Koncepcja obiektowości
obiektowość - cecha naturalnego postrzegania świata - analiza otoczenia poprzez

Koncepcja obiektowości
Paradygmat obiektowy (podstawowy styl, techniki oraz wspomagające je konstrukcje językowe)

Koncepcja obiektowości
Abstrakcja:
Wszystko jest obiektem;
Program to zbiór obiektów, które się ze sobą

Koncepcja obiektowości
Obiekt:
podstawowa jednostka konstrukcyjna;
konkretny lub abstrakcyjny byt (wyróżnialny w modelowanej

Koncepcja obiektowości
Klasa:
zbiór obiektów, mających wspólne atrybuty i metody;
wzorzec dla konkretnych egzemplarzy

Koncepcja obiektowości
Klasy i ich instancje
Jedna klasa może mieć wiele instancji, które

Koncepcja obiektowości
Hermetyzacja (kapsułkowanie, enkapsulacja)
zamknięcie pewnego zestawu bytów programistycznych w “kapsułę” o

Koncepcja obiektowości
Dziedziczenie
związek pomiędzy klasami obiektów, określający przekazywanie cech (definicji atrybutów, metod,

Koncepcja obiektowości
class Pojazd {
public:
virtual void jedz() { cout << "Jade"

Koncepcja obiektowości
class Pojazd {
protected:
string nazwa;
public:
Pojazd(string _nazwa) { nazwa =

Ewolucja technik programowania
Funkcje programu
Np. obliczanie wartości X
Stany programu (dane)
Np. X =

Ewolucja technik programowania
http://www.tiobe.com

Ewolucja technik programowania
Zestawienie cech wybranych języków programowania

Ewolucja technik programowania
Pamiętać jednak należy, że:
Programowanie nie zaczyna się i nie

Kryzys oprogramowania
Od początku lat 60-tych trwa walka z syndromem LOOP;
1968, 1969

Kryzys oprogramowania
Walka z kryzysem oprogramowania:
Usuń przyczyny -> wyeliminujesz zauważone symptomy;
Stosowanie

Co to jest inżynieria oprogramowania?
Jest to dziedzina inżynierii, która obejmuje wszystkie

Co to jest inżynieria oprogramowania?
Metodyki:
Strategia postępowania oparta na doświadczeniach i heurystykach

Co to jest inżynieria oprogramowania?
Techniki:
szczegółowo określone sposoby (z wykazem czynności) posługiwania

Proces tworzenia oprogramowania
Jest to zbiór czynności i związanych z nimi

Modele procesu tworzenia oprogramowania
Model kaskadowy (wodospadowy) - waterfall model

Definiowanie wymagań
Projektowanie

Modele procesu tworzenia oprogramowania
Tworzenie iteracyjne
ocena
wymagania
planowanie
planowanie
wstępne
analiza i projektowanie
implementowanie
testowanie
dystrybucja
zarządzanie
środowiskiem

Modele procesu tworzenia oprogramowania
Ewolucja inżynierii oprogramowania - podsumowanie:
Assembly -> Fortran/COBOL ->

Proces tworzenia oprogramowania
Zbiór czynności i związanych z nimi wyników, które

Czynności procesu tworzenia oprogramowania
Projektowanie i implementowanie wymagań:
Metody projektowania:
Stosowanie metod strukturalnych i

Czynności procesu tworzenia oprogramowania
Projektowanie i implementowanie oprogramowania:
Celem fazy określania wymagań jest

Czynności procesu tworzenia oprogramowania
Projektowanie i implementowanie oprogramowania:
Faza projektowania oprogramowania:
opis struktury

Czynności procesu tworzenia oprogramowania
Projektowanie i implementowanie wymagań:
Charakterystyczne składowe analizy i projektowania:

Projektowanie architektury systemu
System informatyczny jest złożoną konstrukcją, której stopień skomplikowania zależy

Projektowanie architektury systemu
Modele obiektowe:
Model obiektowy architektury systemu dzieli system na zbiór

Metodyki strukturalne a obiektowe
Metodyki strukturalne:
metodyki strukturalne są dojrzałe, lecz mogą nie

Obiektowe podejścia do wytwarzania oprogramowania
System jest analizowany w sposób obiektowy jeśli:
Jest

Obiektowe podejścia do wytwarzania oprogramowania
OODA (Booch Methodology),
Object Modelling Technique - OMT

Obiektowe podejścia do wytwarzania oprogramowania
OMT-2 (rozwinięcie OMT-1):
technika modelowanie obiektów;
nacisk na

Obiektowe podejścia do wytwarzania oprogramowania
Analiza obiektowa
opracowanie modelu obiektowego dziedziny zastosowania;
rozpoznane

Faza analizy
Identyfikacja aktorów:
Grupy użytkowników wspierane przez system w:
podstawowych i drugoplanowych zadaniach;
administrowaniu

Faza analizy
Identyfikacja klas obiektów - typowe klasy:
przedmioty namacalne (np. samochód, czujnik),
role

Faza analizy
Obiekty, zbiory obiektów i metadane:
W wielu przypadkach przy definicji klasy

Faza analizy
Zalecenia dotyczące identyfikacji klas:
Wyraźnie zdefiniować kontekst (w tym opis) klasy;
Unikać

Faza analizy
Zalecenia dotyczące identyfikacji związków klas:
Unikać związków bez klasy docelowej;
Pomijać związki

Faza analizy
Zalecenia dotyczące modelu dynamicznego klas:
Koncentrować się na behawioralnych aspektach systemu;
Rozpatrzeć

Faza analizy
Kluczowe czynniki sukcesu fazy analizy
Zaangażowanie właściwych osób ze strony klienta;
Kompleksowe

Od analizy do szczegółowego projektu obiektów
Celem projektowania jest opracowanie szczegółowego opisu

Faza projektowania
Zadania w etapach fazy projektowania:
uściślenie istniejących definicji klas, np. metod,

Faza projektowania
Zadania fazy projektowania – przykład uściślenia definicji metod;
Podanie nagłówków

Faza projektowania
Zadania fazy projektowania – przykład sposobu implementacji związków (asocjacji);
Związki

Podstawowe rezultaty fazy projektowania
Poprawiony i uszczegółowiony dokument opisujący wymagania;
Poprawione i uszczegółowione