Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

PODSTAWY PROGRAMOWANIA

Podobne prezentacje


Prezentacja na temat: "PODSTAWY PROGRAMOWANIA"— Zapis prezentacji:

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. Projektowanie algorytmó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 OPROGRAMOWANIA PROJEKT 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 ; 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. extreme programming) 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 (Unified Modeling Language) 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 Object Modeling Technique (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 przekazano grupie Object 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. kryzys oprogramowania. 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 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
sposoby prowadzenia przedsięwzięć informatycznych techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć informatycznych metody analizy i projektowania systemów techniki zwiększania niewodności oprogramowania sposoby testowania systemów i szacowania niezawodności sposoby przygotowania dokumentacji technicznej i użytkowej procedury kontroli jakości metody redukcji 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. Programy Upper-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. Programy Lower-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 dodatkowe fazy:
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ędzia CASE 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 dokumentacja uż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ę testowanie wstę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.

51 Modelowanie danych Pierwszy krok - logiczna reprezentacja danych w systemie. Najbardziej przyjął się model relacyjny - wykorzystywany w 90%. Dane przechowywane są w tabelach. Tabela składa się z wierszy i kolumn. Wiersz symbolizuje konkretne wystąpienie obiektu, np. Osoba. W modelowaniu nie stosuje się pojęcia tabela a ENCJA - symbolizuje obiekt występujący w rzeczywistości. Encja - porcja danych n.t. osoby, np. Kowalski. Wystąpienie encji - Entity instance. Fizyczna realizacja to tabela. Atrybuty encji. Każda encja - porcja danych. Generalizacja - grupowanie różnych encji. Encja bardziej generalna - bazowa, np. Osoba. Podtypy - np. Pracownik Pokrywa się to z dziedziczeniem. W modelu znajduje odzwierciedlenie powiązanie - relacja - model relacyjny. Graficzna reprezentacja modelu Diagramy związków i encji: ERD (Entity Relationship Diagram), E-R. Notacje: Pierwotna: encja, atrybut encji i związku, związek, krotność, dziedziczenie Profesjonalna - w pakiecie System Engineer: encja, K-krotność, O-obligatoryjność, | jeden, < wiele, podtypy: | całkowite, O - częściowe

52 System Engineer Analiza, modelowanie
Baza danych elementarnych Baza danych o modelach Baza danych o związkach Listy i tabele asocjacji Data Model Subset - podzbiory. Wygenerowanie skryptu DDL (database description language). Generatory na różne platformy sprzętowe. Koncepcja strukturalna - jak całościowo potraktować koncepcję strukturalną. Koncepcja zaproponowana przez twórców pakietu - niezależna praca różnych zespołów. Etapy Analiza, modelowanie Projektowanie - opracowanie fizycznego modelu Wygenerowanie skryptów - interfejs użytkownika w pseudokodzie, nawet w Cobolu.


Pobierz ppt "PODSTAWY PROGRAMOWANIA"

Podobne prezentacje


Reklamy Google