PODSTAWY PROGRAMOWANIA

1. PODSTAWY PROGRAMOWANIA Temat lekcji: Inżynieria oprogramowania: fazy tworzenia projektu informatycznego Cele: poznanie zasad tworzenia projektu informatycznego: orientacja w zagadnieniu tworzenia projektu informatycznego oraz eksploatacji programów

2. Fazy tworzenia projektu informatycznego: • zdefiniowanie problemu, • określenie planu działania, • zaprojektowanie metod rozwiązania, • implementacja projektu - wybór gotowego oprogramowania lub zaprogramowanie w odpowiednio wybranym języku (systemie) oprogramowania, • przetestowanie i analiza poprawności działania programu, • opracowanie dokumentacji.

3. Zdefiniowanie problemu • precyzyjne określenie elementów tworzących sytuację problemową i powiązań między nimi: • dane, • wyniki, • cel przetwarzania.

4. Podstawy programowania • Podział problemu na zwarte logiczne moduły i określenie powiązania miedzy nimi. • Projektowaniealgorytmów rozwiązania problemów: lista kroków, sieć działań, elementy strukturalne algorytmów - warunki, pętle. • Języki programowania. Dokumentacja programu.

5. INŻYNIERIA OPROGRAMOWANIAPROJEKT INFORMATYCZNY • Inżynieria oprogramowania: Źródła i rola inżynierii oprogramowania, modele cyklu życia oprogramowania. • Projekt informatyczny - fazy tworzenia projektu informatycznego, testowanie a uruchamianie programów. • Rozwiązywanie problemów za pomocą komputerów:

6. Rozwiązywania problemów za pomocą komputerów • Analiza: zdefiniowanie problemu, określenie wymagań: powiązania, dane, wyniki, cel przetwarzania • Określenie planu działania: podział na podproblemy • Projekt rozwiązania problemu: zaprojektowanie metod (algorytmów) rozwiązania podproblemów i zapewnienie przepływu informacji • Implementacja projektu: wybór sprzętu, systemu operacyjnego oraz oprogramowania - gotowego lub zaprogramowanie w odpowiednim języku (systemie) - kodowanie, usuwanie błędów, testy modułów • Przetestowanie i analiza poprawności działania całego programu - integracja i testowanie systemu • Sprawdzenie czy problem został rozwiązany - czy generowane rozwiązanie zgodne ze specyfikacją problemu • Opracowanie dokumentacji programu (systemu) dla użytkownika, szkolenie użytkownika • Konserwacja systemu, modyfikacja oprogramowania

7. Inżynieria oprogramowania • Inżynieria oprogramowania – dziedzina inżynierii systemów zajmująca się wszelkimi aspektami produkcji oprogramowania: od analizy i określenia wymagań, przez projektowanie i wdrożenie, aż do ewolucji gotowego oprogramowania. • Podczas gdy informatyka zajmuje się teoretycznymi aspektami produkcji oprogramowania, inżynieria oprogramowania koncentruje się na stronie praktycznej.

8. Źródła i rola inżynierii oprogramowania/programowania (IP) • Przedmiotem inżynierii programowania są • różne aspekty rozwijania i eksploatacji oprogramowania, • próby racjonalizacji postępowania, • metody i narzędzia - ograniczenie wysiłku i czasu, • tworzenie oprogramowania bardzo dokładnego.

9. Przedmiot zainteresowania IP, aspekty: • Przedmiot IP • organizacja prac • metodyka • narzędzia • Obszar zainteresowań: "duże systemy": liczba wykonawców 50-3000; zespół kierujący 1-50; zróżnicowanie kwalifikacji członków zespołu, niestabilność załogi. • Odbiorcy: wykonawcy, menedżerowie (wykorzystanie zasobów ludzkich, wykorzystanie doświadczeń), użytkownicy - koszt, efekty.

10. Powstanie inżynierii oprogramowania • Termin "inżynieria oprogramowania" po raz pierwszy został użyty w przełomie lat 1950/60 ale oficjalnie za narodziny tej dyscypliny podaje się lata 1968 i 1969, w których miały miejsce dwie konferencje sponsorowane przez NATO, odpowiednio w Garmisch i Rzymie.

11. Wyzwania dla inżynierii oprogramowania • systemy spadkowe – jak konserwować oprogramowanie, które powstało wiele lat temu i ciągle jest w użyciu • systemy heterogeniczne – problem integracji systemów zbudowanych z użyciem różnych języków i technologii • sprawna produkcja systemów – umożliwienie produkcji oprogramowania na czas bez uszczerbku dla jego jakości

12. Fazy procesu produkcji oprogramowania • W inżynierii oprogramowania proces produkcji oprogramowania dzieli się na pewne fazy,typowy podział to: • specyfikacja – na tym etapie następuje określenie i ustalenie wymagań, które musi spełniać oprogramowanie • projektowanie – ustalenie ogólnej architektury systemu, wymagań dla poszczególnych jego składowych • implementacja– realizacja ustalonej architektury poprzez implementację składowych (modułów) i połączeń między nimi. • integracja – zintegrowanie poszczególnych składowych w jeden system, testowanie całego systemu • ewolucja – uruchomienie systemu, usuwanie wykrytych podczas jego używania błędów, rozszerzanie systemu

13. Modele życiowe oprogramowania • pisz i poprawiaj • model kaskadowy • model prototypowy • model przyrostowy (iteracyjny) • model równoległy • programowanie zwinne (ang. agile programming) • programowanie ekstremalne (ang. extremeprogramming) • synchronizuj i stabilizuj • model spiralny

14. Języki inżynierii oprogramowania • Inżynieria oprogramowania rozwinęła szereg języków wspomagających proces tworzenia oprogramowania. • Obecnie popularność zyskały języki wspierające programowanie obiektowe– najważniejszym z nich jest UML. • Inżynieria oprogramowania wypracowała jednak już wcześniej inne metodologie– takie, jak metoda strukturalna Yourdona.

15. UML (UnifiedModelingLanguage) Zunifikowany Język Modelowania • Język formalny wykorzystywany do modelowania różnego rodzaju systemów, stworzony przez Grady Boocha, Jima Rumbaugha oraz Ivara Jackobsona, obecnie rozwijany przez Object Management Group. • Służy do modelowania dziedziny problemu (opisywania-modelowania fragmentu istniejącej rzeczywistości – na przykład modelowanie tego, czym zajmuje się jakiś dział w firmie) – w przypadku stosowania go do analizy oraz do modelowania rzeczywistości, która ma dopiero powstać – tworzy się w nim głównie modele systemów informatycznych. • UML jest głównie używany wraz z jego reprezentacją graficzną – jego elementom przypisane są symbole, które wiązane są ze sobą na diagramach

16. Modelowanie obiektowe • Modelowanie obiektowe pojawiło się w latach 70. ubiegłego wieku w odpowiedzi na powstające języki programowania obiektowego (Simula, Smalltalk i Ada). W latach 90. istniało ponad 50 metod obiektowych. Wielu użytkowników miało problem ze znalezieniem języka modelowania odpowiadającego ich potrzebom. Opracowano metody nowej generacji, ale tylko kilka z nich zyskało uznanie. Były to: Metoda Boocha, Object-Oriented Software Engineering (OOSE) oraz ObjectModelingTechnique (OMT). Powstały także metody Fusion, Shlaera-Mellora i Coada-Yourdona. Każda z tych metod miała wady i zalety, nadawała się tylko do pewnych zastosowań.

17. UML • W czerwcu 1996 roku opracowana została dokumentacja wersji 0.9 Unified Method. Utworzono Konsorcjum UML, w które zaangażowali się tacy giganci jak HP, IBM, Oracle i Microsoft. Wynikiem współpracy był UML 1.0, precyzyjny język modelowania. • W styczniu 1997 roku UML 1.0 przekazanogrupieObject Management Group (OMG), która do dzisiaj zajmuje się jego rozwojem.

18. Kryzys oprogramowania • Inżynieria oprogramowania jest dziedziną informatyki, która pojawiła się w połowie lat 60-tych. Rozwój inżynierii oprogramowania poprzedziło zwrócenie uwagi na tzw. kryzysoprogramowania. W latach 50 i na początku lat 60-tych tworzono tylko małe programy. Rozwój sprzętu komputerowego oraz języków programowania umożliwił tworzenie znacznie bardziej złożonych systemów. Stało się jasne, że rozwój technik oprogramowania nie nadąża za rozwojem sprzętu i to zjawisko nazwano "kryzysem oprogramowania", który trwa do dziś. W latach 90-tych 90% poważnych firm programistycznych w USA uważa, że często zdarzają się im opóźnienia w realizacji przedsięwzięć programistycznych. • Oprogramowanie jest też chyba jedynym produktem technicznym, w którym błędy są powszechnie akceptowane. Przykładem może być wykrycie błędu w pierwszych egzemplarzach PENTIUM. Producenci programów sprzedawanych w milionach egzemplarzy nie dają praktycznie żadnej gwarancji na to, że ich produkt działa zgodnie z opisem.

19. Przyczyny kryzysu oprogramowania: • Duża złożoność systemów informatycznych. • Niepowtarzalność poszczególnych przedsięwzięć. • Nieprzejrzystość procesu budowy oprogramowania, tj. fakt trudności w ocenie stopnia zaawansowania prac. Najgorszym sposobem oceny postępów jest pytanie się programistów o ocenę stopnia zaawansowania. Jeżeli po miesiącu uzyskamy odpowiedź, że prace są zaawansowane w 90%, można się spodziewać, że przedsięwzięcie potrwa jeszcze cały rok. • Pozorna łatwość wytwarzania i dokonywania poprawek w oprogramowaniu. • Narzędzia pozwalające tworzyć nawet całkiem duże programy są stosunkowo tanie. Każdy, kto korzystając z nich napisał w ciągu jednego dnia program liczący 100 linii, może sądzić, że w ciągu 10 dni napisze program zawierający 1000 linii, a 10 osób w ciągu 100 dni opracuje program liczący 100000 linii, co nie jest słuszne. • Rozmaite propozycje wyjścia z "kryzysu oprogramowania" zaowocowały powstaniem nowego działu oprogramowania - inżynierii oprogramowania.

20. Zakres inżynierii oprogramowania: • Inżynieria oprogramowania wiedza techniczna dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu - oprogramowania. • Jest wiedzą techniczną a nie teoretyczną nauką choć wykorzystuje dorobek wielu nauk, np. teorii programowania, sztucznej inteligencji, badań operacyjnych, psychologii, nauki o zarządzaniu. • Inżynieria oprogramowania traktuje oprogramowanie jako produkt.

21. Główne cechy oprogramowania • Dobre oprogramowanie powinno być: • zgodne z wymaganiami użytkownika • niezawodne (niezawodność) • efektywne (wydajność) • łatwe w konserwacji (pielęgnowalność) • ergonomiczne (wygoda w użyciu)

22. Inżynieria oprogramowania obejmuje m. in. zagadnienia • sposobyprowadzenia przedsięwzięć informatycznych • techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć informatycznych • metodyanalizy i projektowania systemów • techniki zwiększania niewodności oprogramowania • sposobytestowania systemów i szacowania niezawodności • sposoby przygotowania dokumentacji technicznej i użytkowej • procedurykontroli jakości • metodyredukcji kosztów konserwacji (usuwania błędów, modyfikacji, rozszerzeń) • techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy

23. CASE • Narzędzia CASE (Computer assisted/aided software/system engineering - komputerowo wspomagana inżynieria programowania/systemów) • Narzędzia CASE pełnią w pracy inżyniera oprogramowania podobną rolę jak narzędzia CAD/CAM w pracy inżynierów innych dziedzin. Dzieli się je na narzędzia Upper-CASE i Lower-CASE. • ProgramyUpper-CASE to narzędzia wysokiego poziomu, które koncentrują się na wstępnych etapach realizacji przedsięwzięcia - określaniu wymagań, modelowaniu i projektowaniu systemu realizującego te wymagania. Narzędzia takie nie wspomagają bezpośrednio implementacji systemu. • ProgramyLower-CASE, czyli narzędzia niskiego poziomu koncentrują się na fazie implementacji.

24. Modele cyklu życia oprogramowania • Produkcja oraz eksploatacja oprogramowania jest procesem, który powinien być realizowany w sposób systematyczny. Jak powinien wyglądać ten proces określają tzw. modele cyklu życia oprogramowania. • Modele te wprowadzają pewne fazy życia oprogramowania, określają czynności wykonywane w poszczególnych fazach oraz ustalają kolejność ich realizacji. • Modele cyklu życia oprogramowania pozwalają uporządkować przebieg prac, ułatwiają planowanie zadań oraz monitorowanie przebiegu ich realizacji.

25. Cykl życia oprogramowania - model ogólny (ujęcie podstawowe)

26. Rozkład kosztów W fazie projektowania nie żyłuje się szybkości i efektywności. Efektywność poprawia się w czasie eksploatacji i konserwacji. Jakość prac projektowych ma być największa. Produkcja oraz eksploatacja oprogramowania jest pewnym procesem, który powinien być realizowany w sposób systematyczny. Jest szereg tzw. modeli cyklu życia oprogramowania. Modele te wprowadzają pewne fazy życia oprogramowania, określają czynności oraz ustalają kolejność realizacji.

27. Model kaskadowy (waterfall) • Model kaskadowy cyklu życia oprogramowania wprowadza fazy: • faza określania wymagań (analiza i definiowanie wymagań), w której określane są cele oraz szczegółowe wymagania wobec tworzonego systemu • faza projektowania - design (projektowanie systemu i oprogramowań), w której powstaje szczegółowy projekt systemu spełniającego ustalone wcześniej wymagania • faza implementacji/kodowania oraz testowania modułów (implementacja i testowanie jednostek), w której projekt zostaje zaimplementowany w konkretnym środowisku programistycznym oraz wykonywane są testy poszczególnych modułów • faza testowania (integracja i testowanie systemu), w której następuje integracja poszczególnych modułów połączona z testowaniem poszczególnych podsystemów oraz całego oprogramowania • faza konserwacji (działanie i pielęgnacja), w której oprogramowanie jest wykorzystywane przez użytkownika(ów), a producent dokonuje konserwacji oprogramowania - modyfikacje polegające na usuwaniu błędów, zmiany i rozszerzenia funkcji systemu

28. W modelu kaskadowym często wyróżnia się pewne dodatkowefazy: • Faza strategiczna (strategy) wykonywana przed formalnym podjęciem decyzji o realizacji przedsięwzięcia. Podejmowane są strategiczne decyzje dotyczące dalszych etapów prac. Faza wymaga przynajmniej ogólnego określenia wymagań. • Faza analizy - budowany jest logiczny model systemu. Obejmuje częściowo fazę określenia wymagań i projektowania • Faza dokumentacji, w której wytwarzana jest dokumentacja użytkownika. Opracowanie dokumentacji przebiega równolegle z produkcją oprogramowania. Faza ta może rozpocząć się już w trakcie określania wymagań. Ostatnie zmiany dokonywane są w fazie instalacji • Faza instalacji, w której następuje przekazanie systemu użytkownikowi. Jest na granicy testowania i konserwacji - obejmuje częściowo te 2 fazy

29. Wady modelu kaskadowego: • Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac. Osoby pracujące nad programowaniem preferują mniej rygorystyczny styl pracy. • Wysoki koszt błędów popełnionych we wstępnych fazach. Błędy te zostaną wykryte prawdopodobnie dopiero w fazie testowania lub konserwacji. Ich koszt może o rzędy wielkości przewyższać koszt błędów np. w fazie implementacji • Długa przerwa w kontaktach z klientem. Faza strategiczna oraz określenia wymagań i analizy są realizowane w ścisłej współpracy z klientem (gdy oprogramowanie na zamówienie). Projektowanie, implementacja i w dużej mierze testowanie wykonywane są wyłącznie przez firmę programistyczną. Pojawia się ryzyko zmniejszenia zainteresowania klienta przedsięwzięciem.

30. Inne modele cyklu życia oprogramowania • Model realizacji przyrostowej. Projekt ogólny, wybór podzbioru funkcji, szczegółowy projekt, implementacja, testowanie.. • Programowanie odkrywcze. W jak najszybszym czasie działający system i jego modyfikacja. Spotykane w dziedzinie sztucznej inteligencji - nie do końca wiemy czego chcemy. • Prototypowanie. • Montaż z gotowych elementów - składanie systemu z "cegiełek" - wykorzystanie składników wielokrotnego użycia. NarzędziaCASE ułatwiają wykorzystanie modeli i projektów z poprzednich przedsięwzięć. • Realizacja kierowana dokumentami. Wady modelu: duży nakład pracy na dokumenty, przerwy w realizacji. • Model spiralny. Najbardziej chyba ogólny model cyklu życia oprogramowania, zaproponowany przez Boehma(1988).

31. Model realizacji przyrostowej • Model realizacji przyrostowej. Projekt ogólny, wybór podzbioru funkcji, szczegółowy projekt, implementacja, testowanie. Realizacja zaczyna się od określenia wymagań oraz wykonania wstępnego, ogólnego projektu całości sytemu. Następnie wybierany jest pewien podzbiór funkcji systemu. Dalej zgodnie z modelem kaskadowym, wykonywany jest szczegółowy projekt oraz implementacja części systemu realizującej te funkcje. Po przetestowaniu zrealizowany fragment pełnego systemu może być dostarczony klientowi. Zwiększenie częstotliwości kontaktów z użytkownikiem. Użytkownik może korzystać z wersji pośredniej. Wada - wersja pośrednia - dokumentacja dla użytkownika.

32. Programowanie odkrywcze • Programowanie odkrywcze. W jak najszybszym czasie działający system i jego modyfikacja. Spotykane w dziedzinie sztucznej inteligencji - nie do końca wiemy czego chcemy. Stosowane, gdy trudności ze sprecyzowaniem wymagań.

33. Prototypowanie • Prototypowanie. Zakładamy, że w ramach cyklu projektu, użytkownik zgłasza się z mętnym rozwiązaniem. Tworzy sie prototyp, nie przykładając się specjalnie, nie dba o interfejs, reakcje na błędy. Może się wyjaśnić użytkownikowi czego potrzebuje.Później np. model wodospadowy i porządny projekt.

34. Transformacje formalne • Transformacje formalne. Zakłada, że wymagania wobec systemu specyfikowane są w pewnym formalnym języku. Wymagania te są następnie transformowane automatycznie do pewnej postaci pośredniej bliższej kodowi w jakimś języku programowania. Formalne specyfikacje, zbiór transformacji formalnych, wynik poprawny. Atrakcyjne do pewnego momentu. Trudno sporządzić dokumentację wstępną - kontrakty w specyficznych zastosowaniach. Klient musi reprezentować wysoki poziom.

35. Montaż z gotowych elementów • Montaż z gotowych elementów - składanie systemu z "cegiełek" - wykorzystanie składników wielokrotnego użycia. Przykładem może być stosowanie: bibliotek, języków czwartej generacji, pewnych aplikacji (np. przeglądarki plików pomocy w MS Windows). Narzędzia CASE ułatwiają wykorzystanie modeli i projektów z poprzednich przedsięwzięć.

36. Realizacja kierowana dokumentami • Realizacja kierowana dokumentami. Model został zaproponowany przez armię amerykańską i jest ścisłą realizacją modelu kaskadowego ale dodatkowo zakłada się, że każda faza kończy się opracowaniem dokumentów, w pełni opisujących wyniki fazy. Dokumenty powinny być podstawą do realizacji dalszych faz. Dokumenty te są udostępniane klientowi. Dopiero po zaakceptowaniu dokumentacji przez klienta zaczyna się następna faza. Wady modelu: duży nakład pracy na dokumenty, przerwy w realizacji.

37. Model spiralny Najbardziej chyba ogólny model cyklu życia oprogramowania, zaproponowany przez Boehma (1988). • Model ten składa się z 4 głównych faz wykonywanych cyklicznie: • analizy ryzyka, • konstrukcji, • atestowania, planowania.

38. Rozwiązywanie problemów za pomocą komputerów • Zdefiniowanie problemu - precyzyjne określenie elementów tworzących sytuację problemową i powiązań między nimi: dane, wyniki, cel przetwarzania (cel do osiągnięcia); ewentualne przesyłanie informacji • Określenie planu działania - podział problemu na podproblemy i określenie powiązania miedzy nimi • Zaprojektowanie metod (algorytmów) rozwiązania podproblemów i zapewnienie przepływu informacji między nimi: sposoby przedstawiania algorytmów - lista kroków, sieć działań, elementy strukturalne algorytmów - warunki, pętle • Wybór gotowego oprogramowania lub zaprogramowanie opracowanych metod rozwiązania w odpowiednio wybranym języku (systemie) programowania • Przetestowanie i zanalizowanie poprawności działania programu • Sprawdzenie czy problem został rozwiązany, tj. czy generowane rozwiązanie jest zgodne ze specyfikacją problemu • Opracowanie dokumentacji programu (systemu)

39. PROJEKTY INFORMATYCZNE • Projekt informatyczny - do jego realizacji trzeba używać narzędzi informatyki. • Fazy tworzenia projektu informatycznego: następne strony

40. I. Analiza problemu, określenie wymagań, projektowanie Przeprowadzają realizujący projekt i klient ewentualnie osoba zlecająca.Np. system FK - rozeznać sposoby pracy. Wymagana umiejętność rozmowy z klientem. • Wywiad z klientem: dokładne zdefiniowanie tematu, obieg dokumentów (dla księgowej oczywiste, dla programisty nie), postać wydruku, ekranu, rodzaje dokumentów, bazy danych (zgromadzone informacje, np. katalogi na potrzeby książek), przepływ informacji (diagram przepływu informacji), prawa dostępu (istotne uprawnienia, ustawa o ochronie danych osobowych) • Inwentaryzacja stanu bieżącego, określenie co trzeba zmienić. • Projekt rozwiązania problemu (dokumentacja przedstawiana temu, dla kogo tworzymy oprogramowanie), zatwierdzenie projektu (postacie raportów, ekranów, wzorce nowych dokumentów). Powinny wykonywać grupy ludzi - analitycy systemowi, analitycy projektu - osoby niezależne od programisty

41. II. Implementacja projektu 1. Wybory - sprzętu, systemu operacyjnego, języka programowania. Oprogramowanie działa w otoczeniu: sprzęt (w sieci lub nie), SO (systemu operacyjnego), języka programowania • Sprzęt • Trzeba doradzić sprzęt - ograniczenie od góry i dołu. Czy środowisko sieciowe - typu klient serwer czy system rozproszony (dane gromadzone tam gdzie powstają). Nie może być sztywnych czynników w opracowaniu (np. dyski, katalogi). • Serwer - dużo pamięci operacyjnej, dyski, szybki procesor, nieistotne multimedia i grafika. Stanowiska klienta - odwrotność wymagań serwera: ważny monitor, karta wideo, możliwości multimedialne. • System typu Klient-Serwer: programy działający na serwerze i stacji klienta - 2 programy. Program na serwerze udostępnia dane, na stacji klienta pobiera i przekazuje dane do serwera. • System rozproszony - każdy komputer jest serwerem i klientem. Wymagane ściągnięcie danych z każdego komputera do jednego. W systemach FK - rozwiązanie typu klient-serwer. • Wielkości HD i RAM zależą od sytemu operacyjnego - z zapasem, za 2 lata nie będą wystarczać.

42. System operacyjny • Moda na grafikę - niepotrzebne do banków - lepsze systemy UNIX-owe, w trybie tekstowym, w sieci. • System: Windows’y serii NT (użytkownicy, hasła), UNIX/Linux, Novell (sieciowy). W Windows NT zawieszenie (pad) jednego zadania nie powoduje padu innego. • UNIX - system bardzo stabilny. Był od początku zdefiniowany jako sieciowy. Jego cechy to sieciowość, wielozadaniowość, wielo-użytkowość (wielu użytkowników). Działanie tekstowe szybsze. Z punktu widzenia użytkownika trudniejszy, nie wybacza pomyłek. • Novell do poziomu 4 - serwer plików, nie ma telnetu, usług sieciowych. Nie był pełnym systemem sieciowym. Pozwala zdefiniować prawa dostępu. Programy ściągane do lokalnego komputera.

43. Język programowania • Grupy języków programowania • Bazodanowe: dBase, Clipper, FoxPro, Access, Delphi, SQL-owe (np. Oracle). Ukierunkowanie na tworzenie aplikacji baz danych (zbiór informacji jednorodnych, łatwiej dopisywać informacje, dostosowanie do pracy w sieci, sortowanie) • Obliczeniowe (naukowo techniczne, statystyka), np. Fortran (są biblioteki do grafiki) • Pascal • C/C++ (ojciec Pascal, matka assembler), podobny do UNIXa, wykonuje instrukcje nie dyskutuje. Jest jakby językiem uniwersalnym, właściwości sieciowe. C++ cechuje obiektowość. Gorzej z zastosowaniami bazodanowymi, biblioteka funkcji matematycznych mniejsza niż w Fortranie. • Specjalizowane: sztuczna inteligencja, systemy ekspertowe, przetwarzanie list, do symulacji procesów • "Visual" (np. Visual C++, Visual Basic, Delphi)

44. 2. Implementacja (kodowanie) • W fazie implementacji następuje proces kodowania (pisania oprogramowania w konkretnym języku), projekt zostaje zaimplementowany w konkretnym środowisku programistycznym oraz wykonywane są testy poszczególnych modułów • Wydzielenie modułów funkcji • Wstępne testowanie (debugger) • Dokumentacja techniczna dla programisty. Komentuje algorytm a nie instrukcje. Opis procedur, funkcji, danych we/wy • Kompilacja, usunięcie błędów (kod max zbliżony do ANSII, nie ignorować ostrzeżeń) • Generatory - generują aplikacje. Duża szybkość ale produkty niedotestowane.

45. III. Testowanie i uruchamianie aplikacji, instalacja, dokumentacja użytkownika, szkolenie użytkownika • W fazie testowania i uruchamiania następuje integracja poszczególnych modułów połączona z testowaniem poszczególnych podsystemów oraz całego oprogramowania. • Zostaje sporządzona na koniec dokumentacjaużytkownika, przeprowadza się instalację i szkolenie użytkownika.

46. Testowanie • Testowanie to zbiór czynności wykonywanych z intencją wykrycia w programie jak największej liczby błędów. Jednym z jego głównych składników jest obserwacja zgodności produkowanych przez program wyników z wcześniej przygotowanymi poprawnymi wynikami odniesienia. Celem testowania programu jest upewnienie się, że program rozwiązuje to zadanie, do którego został zaprojektowany, i że w każdych warunkach daje poprawne wyniki. Testowanie jest to proces różny od uruchamiania programu.Program uruchomiony nie zawiera błędów sygnalizowanych przez translator i jawnie niepoprawnych fragmentów kodu oraz daje jakieś wyniki. Czy wyniki te są poprawne, zgodnie z oczekiwaniami ustalonymi w specyfikacji, pozwala ocenić testowanie. Przy testowaniu programu należy dążyć do: sprowokowania błędu, sporządzenia dokładnego opisu okoliczności, które doprowadziły do błędu, co umożliwi przejście do fazy uruchamiania w celu poszukiwania niewłaściwej pracy programu. Ważna jest liczba wykonanych testów. Testowanie gruntowne (dla wszystkich możliwych kombinacji danych wejściowych) jest prawie zawsze niemożliwe. Możliwe są 2 skrajnie odmienne podejścia do testowania: względem struktury wewnętrznej (kodu) i względem specyfikacji zewnętrznej. Wyróżnia się testowaniewstępujące (od modułów najniższego poziomu) i zstępujące (z góry - od programu głównego w dół) przy stosowaniu zaślepek zamiast nie zakodowanych modułów.

47. Uruchamianie • Uruchamianie to proces znajdowania i usuwania z programu błędów pierwotnych (w zasadzie tych, które ujawniły się w czasie wykonywania programu). Do uruchamiania przystępujemy zwykle po stwierdzeniu dowodów lub symptomów istnienia błędu. Obecność błędów wykrywana jest zazwyczaj w czasie procesu testowania. Należy dążyć do wykrycia jak największej liczby błędów przed przekazaniem programu użytkownikowi. Ze względu na moment ujawnienia błędy w programach można podzielić na: błędy kompilacji (sygnalizowane przy kompilacji) i błędy wykonania (przy wykonywaniu programu przez sam program lub system operacyjny, np. dzielenie przez 0, nadmiar). Błędne wyniki nie są jawnie sygnalizowane - powinny być dostrzeżone w czasie testowania. Na etapie kodowania (pisania tekstu programu) programista może popełnić najwięcej błędów. Są takie kategorie błędów jak: błędy syntaktyczne (np. brak średnika, nawiasu, nieprawidłowy symbol), błędy semantyczne (np. brak deklaracji, niezgodność typów w wyrażeniu, przekroczenie zakresu, niedozwolona wartość argumentu). Inne błędy zaliczamy do błędów logicznych, np. użycie pętli repeat zamiast while, użycie nieodpowiedniego wzoru, brak inicjalizacji.

48. Testowanie a uruchamianie • Testowanie i uruchamianie przeplatają się. Testując nie wiemy, czy w programie są jakieś błędy, a uruchamiając wiemy, że błąd jest. Po napisaniu całego programu, gdy kompilator dostarczy kod wynikowy, najczęściej testujemy "na dym", przyjmując proste dane testowe. Wykrywamy wtedy grube błędy i przechodzimy do uruchamiania, kiedy to lokalizujemy błędy i je usuwamy. Z kolei wracamy do testowania, przygotowując bardziej finezyjne dane testowe, co pozwala na ujawnienie drobniejszych lub rzadziej występujących błędów. Wracamy do uruchamiania i w ten sposób testowanie przeplata sie z uruchamianiem, przy czym dane testowe i błędy są coraz bardziej wyrafinowane.

49. IV. Eksploatacja/konserwacja - działanie systemu i pielęgnacja • W fazie eksploatacji oprogramowanie jest wykorzystywane przez użytkownika(ów), a producent dokonuje konserwacji oprogramowania - modyfikacje polegające na usuwaniu błędów, zmiany i rozszerzenia funkcji systemu (pielęgnacja systemu

50. Optymalizacja programów • Program, który nie musi być poprawny można uczynić tak sprawnym, ile dusza zapragnie - Dennie Van Tassel • Powyższa zasada przypomina, że w dążeniu do usprawniania (optymalizacji) programów musimy mieć na uwadze, że podstawowym wymaganiem jest niezawodność. Następnie, jeśli program jest pożyteczny można Myślec o optymalizacji. • Optymalizacja programu może być czasowa lub pamięciowa.