Podstawy Inżynierii Oprogramowania WYKŁAD 7 Modele cyklu życia oprogramowania MODEL KASKADOWY Faza Projektowania (c.d.) Dr hab. inż. Barbara Dębska, prof. PWSZ Dr hab. inż. Barbara Dębska, prof. PWSZ

Zasady Shneidermana (1993 r.) projektowania interfejsu użytkownika: Spójność, wygląd i obsługa systemu powinna być podobna w momencie korzystania z różnych funkcji. Ponadto powinna być zgodna z innymi programami, z których korzysta użytkownik systemu. Skróty dla doświadczonych użytkowników, mogą oni korzystać ze skrótów powodujących natychmiastowe wykonanie poleceń. Potwierdzenie przyjęcia polecenia użytkowników, należy potwierdzać polecenia, które są długo wykonywane, aby użytkownik nie poczuł się zdezorientowany. Prosta obsługa błędów, błędne dane powinny być objaśniane, a potem samoczynnie system powinien się ustawić na przyjęcie nowych danych. Dr hab. inż. Barbara Dębska, prof. PWSZ

Zasady Shneidermana (1993 r Zasady Shneidermana (1993 r.) projektowania interfejsu użytkownika: (cd) Odwoływanie akcji, możliwość wycofywania się (wielokrotnego) z podjętych akcji, Wrażenie kontroli nad systemem, system nie powinien sam podejmować pewnych akcji lub uniemożliwiać przerwanie realizowanych akcji. Nieobciążanie pamięci krótkotrwałej, należy brać pod uwagę, że użytkownik może zapomnieć w jakim celu uruchomił pewną akcję i przypominać mu, np. wyświetlając tytuł akcji. Grupowanie powiązanych operacji, dotyczy grupowania dialogów i okien przez które się kolejno przechodzi realizując jakieś zadanie i obejmuje możliwość cofnięcia się w każdym momencie do wcześniej wykonanego etapu (np. edytowanie wykresów za pomocą Excel’a). Ważne jest również grupowanie w dialogach powiązanych pól. Dr hab. inż. Barbara Dębska, prof. PWSZ

Projektowanie składowej zarządzania danymi. Do przechowywania trwałych danych najczęściej wykorzystuje się systemy baz danych. MIEJSCE PRZECHOWYWANIA DANYCH: Zwykłe pliki systemu operacyjnego, różnego rodzaju dokumenty będące wynikiem działania edytorów tekstowych i graficznych czy arkuszy kalkulacyjnych. Dokumenty składające się z wielu obiektów różnych klas są najczęściej zapisywane w jednym pliku systemu operacyjnego i odczytywane oraz zapisywane na żądanie użytkownika. W tym przypadku należy zaprojektować format pliku oraz scenariusze odczytu oraz zapisu dokumentów. W (najczęściej relacyjnej) bazie danych, używanej w przypadku systemów operujących na dużych zbiorach danych. Projektowanie relacyjnej bazy danych, zgodnej z modelem opisującym trwałe dane oraz zaprojektowanie zapytań wobec bazy danych wykorzystuje diagramy związków klas i encji. Projektując relacyjną bazę danych należy: określić kolumny identyfikujące dla każdej relacji, znormalizować strukturę bazy danych, określić indeksy poszczególnych relacji Dr hab. inż. Barbara Dębska, prof. PWSZ

OPTYMALIZACJA PROJEKTU Optymalizacja może być realizowana: na poziomie projektu, lub na poziomie implementacji. Optymalizacja powinna: - być stosowana wyłącznie do funkcji, które rzeczywiście realizowane są w zbyt długim czasie, - doprowadzić do wykrycia krytycznych funkcji ze względu na czas realizacji tzw. operacji dominujących, - dotyczyć tych danych, które powodują rzeczywiste problemy z pamięcią operacyjną i masową. Optymalizacja może spowodować: 1. znaczne zmniejszenie zrozumiałości projektu, 2. wzrost stopnia skomplikowania projektu, 3. może być przyczyną dodatkowych błędów na etapie projektowania i implementacji, 4. może utrudniać dokonywanie modyfikacji na etapie implementacji. Dr hab. inż. Barbara Dębska, prof. PWSZ

Dostosowanie do ograniczeń środowiska implementacji Środowisko implementacji systemu może zarówno: pozwalać na stosunkową łatwą implementację pewnych elementów modelu dzięki możliwości wykorzystania gotowych składowych, jak również nie pozwalać na bezpośrednią implementację pewnych konstrukcji modelu. Środowisko implementacji może zawierać szereg gotowych składowych, które mogą ułatwić implementację, np. może mieć miejsce sytuacja, że biblioteki, które standardowo obejmuje środowisko implementacji zawierają funkcje i klasy o możliwościach bardzo zbliżonych do funkcji i klas wprowadzonych w modelu. Koniecznym staje się: zmodyfikowanie składowych bibliotecznych, lub dostosowanie składowej dziedziny problemu do wymogów składowych bibliotecznych (należy sprawdzić, czy to rozwiązanie nie zaburzy naturalnej składowej dziedziny problemu, a więc czy korzyści wynikające ze stosowania gotowych elementów są opłacalne). Dr hab. inż. Barbara Dębska, prof. PWSZ

Głównym ograniczeniem środowiska implementacji, z którym może się zetknąć projektant systemu informatycznego to brak dziedziczenia. Brak dziedziczenia: Jeśli środowisko programistyczne nie zawiera mechanizmów dziedziczenia, to rozwiązaniem, które można przyjąć na etapie projektowania jest jedna z metod: zastąpienie związku generalizacji-specjalizacji związkiem klas lub encji, PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT pojedynczego podatnika Adres PIT małżeństwa Adres męża Adres żony PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT pojedynczego podatnika Adres PIT małżeństwa Adres męża Adres żony Dr hab. inż. Barbara Dębska, prof. PWSZ

PIT pojedynczego podatnika Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT pojedynczego podatnika Adres PIT małżeństwa Adres męża Adres żony 2. umieszczenie wszystkich pól i metod generalizacji na poziomie specjalizacji, PIT pojedynczego podatnika Adres Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT małżeństwa Adres męża Adres żony Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok Dr hab. inż. Barbara Dębska, prof. PWSZ

3. umieszczenie na poziomie generalizacji pól i metod wszystkich jej specjalizacji oraz dodatkowego pola opisującego rodzaj aktualnego obiektu. PIT Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok PIT pojedynczego podatnika Adres PIT małżeństwa Adres męża Adres żony PIT Adres Adres męża Adres żony Kwota do zwrotu Należny podatek Podstawa opodatkowania Rok Rodzaj PITu Dodatkowe pole Rozwiązanie to prowadzi do zwiększonej zajętości pamięci, ale zapewnia zgodność typu specjalizacji i generalizacji. Dr hab. inż. Barbara Dębska, prof. PWSZ

OKREŚLENIE FIZYCZNEJ STRUKTURY SYSTEMU Określenie fizycznej struktury systemu obejmuje: określenie struktury kodu źródłowego, to jest wyróżnienie plików źródłowych, zależności pomiędzy nimi oraz rozszerzenia składowych projektu w plikach źródłowych, podział systemu na poszczególne aplikacje, fizyczne rozmieszczenie danych i aplikacji na stacjach roboczych i serwerach. Dr hab. inż. Barbara Dębska, prof. PWSZ

Przykłady notacji Boocha: Podczas określania fizycznej struktury systemu korzysta się ze specjalnych notacji, np. notacji Boocha (1994 rok). Przykłady notacji Boocha: symbol deklaracji klas i funkcji symbol definicji klas i funkcji symbol modułu głównego aplikacji Nazwa Nazwa Nazwa Dr hab. inż. Barbara Dębska, prof. PWSZ

MODUŁOWA STRUKTURA PROJEKTU Moduły specyfikuje się podając listę składowych projektu, które są w nich umieszczane. W projekcie typu obiektowego jest to np. lista klas deklarowanych definiowanych w danym module. Cechy dużego systemu: - Może składać się z wielu odrębnych aplikacji. - Wyróżniając aplikacje projektant kieruje się opisem wymagań funkcjonalnych opracowanych w fazie określania wymagań. - Poszczególne programy powinny odpowiadać konkretnym funkcjom lub grupom funkcji, najczęściej wysokiego poziomu. - Funkcje wchodzące w skład danej aplikacji powinny być również funkcjami wykorzystywanymi przez konkretną klasę użytkowników. - System może obejmować jeden lub wiele serwerów baz danych, jeden lub wiele serwerów aplikacji, wiele stacji roboczych, to jest komputerów wykorzystywanych przez końcowych użytkowników. Cechy małego systemu: - Dane mogą być przechowywane, a wszystkie aplikacje uruchamiane na jednym komputerze. Dr hab. inż. Barbara Dębska, prof. PWSZ

Przykład fizycznego rozmieszczenia danych i aplikacji - fragment projektu sprzętowej konfiguracji systemu (zgodny z notacją Boocha dotyczącą opisu sprzętu komputerowego): PC Płace Główny serwer bazy danych przedsiębiorstwa PC Zakupy Serwer baz danych działu finansowego Serwer plików działu finansowego Dr hab. inż. Barbara Dębska, prof. PWSZ

POPRAWNOŚĆ PROJEKTU Cechy poprawnego projektu: Kompletny Zdefiniowane powinny być: wszystkie klasy, wszystkie pola, wszystkie metody, wszystkie dane złożone i elementarne. Niesprzeczny Żaden element nie może mieć dwóch lub więcej sprzecznych definicji. Spójny Spójność oznacza semantyczną zgodność informacji zawartych w różnych diagramach i w specyfikacji. Zgodny z regułami składniowych notacji Zasady były cytowane przy omawianiu notacji, np. związki generalizacji-specyfikacji powinny być acykliczne, opis klas nie powiązanych z innymi klasami, brak przepływu danych między zbiornikami, itp. Dr hab. inż. Barbara Dębska, prof. PWSZ

FAZA IMPLEMENTACJI Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Analiza Faza strategiczna Instalacja Dokumentacja Dr hab. inż. Barbara Dębska, prof. PWSZ

Główne czynniki od których zależy poprawność fazy implementacji to: wysoka jakość i wystarczająca szczegółowość projektu, dobra znajomość środowiska implementacji, zachowanie przyjętych standardów, unikanie błędów. Automatyzacja fazy implementacji poprzez zastosowanie: języków wysokiego poziomu, gotowych elementów, narzędzi szybkiego wytwarzania aplikacji (RAD), generatorów kodu. Dr hab. inż. Barbara Dębska, prof. PWSZ

Narzędzia RAD (Rapid Application Development) pozwalają: na łatwą implementację pewnych funkcji systemu poprzez tworzenie bezpośredniego połączenia pomiędzy elementami składowej kontaktu z użytkownikiem (dialogami) i elementami składowej zarządzania danymi (np. relacjami w relacyjnej bazie danych), w dialogowy sposób projektować elementy interfejsu użytkownika, tzn. menu, dialogi oraz raporty i wytwarzać fragmenty oprogramowania, oraz na definiowanie podstawowych reakcji systemu na akcje podejmowane przez użytkownika. Dr hab. inż. Barbara Dębska, prof. PWSZ

Generatory kodu - moduły składowe narzędzi CASE, które na podstawie opisu projektu zawartego w słowniku danych automatycznie tworzą kod programu (najczęściej jest to szkielet kodu, który musi być jeszcze uzupełniony przez programistów). Przykład generatora kodu w języku C++ - pakiet Select OMT Professional Workbench firmy Select lub odpowiednia opcja programu Umbrello. Jeżeli system składa się z modułów w fazie implementacji należy nie tylko zakodować poszczególne moduły, ale także je przetestować. Test całego systemu ma miejsce już w kolejnej fazie budowy modelu kaskadowego – fazie testowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

Tworzenie niezawodnego programu Znaczenie niezawodności programu: ponieważ sprzęt jest niezawodny, użytkownicy oczekują też niezawodnego oprogramowania, błędne wykonanie programu może generować duże koszty, np. wysokie straty finansowe lub nawet zagrożenie dla ludzi, koszty usunięcia błędów z programu mogą być wysokie i często musi być ustalony kompromis pomiędzy niezawodnością a efektywnością oprogramowania. Zwiększenie niezawodności na etapie implementacji można osiągnąć dzięki unikaniu błędów oraz tolerancji błędów. Dr hab. inż. Barbara Dębska, prof. PWSZ

Unikanie błędów Unikanie niebezpiecznych technik programowania: stosowanie instrukcji goto lub innych o podobnym działaniu, które zaburzają naturalną strukturę programu, liczby zmiennoprzecinkowe – obliczenia wykonywane ze skończoną dokładnością, błędy zaokrągleń, błędy wynikające z porównywania liczb zmiennoprzecinkowych, wskaźniki – posługiwanie się wskaźnikami prowadzić może do błędów dostępu do pamięci, obliczenia równoległe lub przerwania – stosowanie tych metod prowadzi do złożonych zależności czasowych, utrudniających uruchamianie oprogramowania, Dr hab. inż. Barbara Dębska, prof. PWSZ

Unikanie niebezpiecznych technik programowania: (c.d.) rekurencja - jej stosowanie utrudnia śledzenie programu, a czasem może być przyczyną zapętlenia programu, function silnia(n:integer): longint; begin if n=0 then silnia := 1; if n=1 then silnia := 1 else silnia := silnia(n-1)* n end; if n<=1 then silnia:= 1; for i:= 2 to n do silnia := silnia * i; złożone wyrażenia wymagające uwzględnienia priorytetu operatorów – wielu błędów unika się rozbijając złożone wyrażenia na kilka prostszych lub zawsze zapisując podwyrażenia w nawiasach, nawet wtedy, gdy to się wydaje nie konieczne, Dr hab. inż. Barbara Dębska, prof. PWSZ

Unikanie niebezpiecznych technik programowania: (c.d.) zasada ograniczonego dostępu – dostęp do poszczególnych elementów programu powinny mieć tylko te składowe, które rzeczywiście odwołują się do tych elementów, np. konkretne pole powinno być dostępne tylko dla tych metod, które je edytują, błędne deklarowanie typów zmiennych – dobrze jest stosować kompilatory, które sprawdzają zgodność typów zmiennych, tzn. nie pozwalają programiście na wykonanie błędnej operacji chyba, że konwersja typów została jawnie wymuszona. Dr hab. inż. Barbara Dębska, prof. PWSZ

Tolerancja błędów Tolerancja błędów oznacza, że program może działać poprawnie a przynajmniej sensownie także wtedy, gdy zawiera błędy. Tolerancja błędów wymaga wykonania przez program następujących zadań: Przykład. var err_num : word; s : string; if err_num > 0 then begin case err_num of 1 : s := ‘Niemożliwe otwarcie pliku’; 2 : s := ‘Nie ma takiego pliku’; 3 : s := ‘Zła ścieżka dostępu’; 4 : s := ‘Za dużo otwartych plików’; 5 : s := ‘Dostęp do plików wzbroniony’; 6 : s := ‘Brak pamięci’; end; writeln (s); keypressed; exit wykrycia błędu, wyjścia z błędu, to jest zakończenia pracy modułu, w którym wystąpił błąd, w poprawny sposób, - ewentualnej naprawy błędu , to jest zmiany programu tak, aby zlikwidować wykryty błąd. Dr hab. inż. Barbara Dębska, prof. PWSZ

Sposoby automatycznego wykrywania błędów: sprawdzanie warunków poprawności danych, Przykład. REPEAT clrscr; write (‘Czy dane zostały napisane poprawnie? (T/N’); readln(odp); UNTIL UpCase(odp) in [’T’, ’N’] Przykład. REPEAT clrscr; gotoXY(38,20); read(wybór); UNTIL wybor in [’1’, ’2’, ’3’, ’4’, ’5’] Dr hab. inż. Barbara Dębska, prof. PWSZ

sprawdzanie warunków poprawności danych, (c.d.) Przykład. Fragment programu obliczania pola trójkąta, gdy znane są jego boki: a, b, c. (Sprawdza się, czy z odcinków a, b, c można zbudować trójkąt.) pobierz_dane; while ((a+b<=c) or (b+c<=a) or (a+c<=b)) do begin writeln('Złe dane ?'); readln; pobierz_dane; {złe dane - pobierz od nowa} end; Dr hab. inż. Barbara Dębska, prof. PWSZ

porównywanie wyników różnych wersji modułu. programowanie N-wersyjne Poszczególne wersje danego modułu powinny zostać zaimplementowane przez niezależne zespoły programistów. Wersja 1 Wersja 2 Wersja 3 Porównanie wyjść i wybór poprawnego wyniku Dr hab. inż. Barbara Dębska, prof. PWSZ

b. technika zapasowych modułów. W danym momencie pracy programu pracuje tylko jedna wersja modułu. Praca modułu jest monitorowana. W przypadkach wątpliwych aktywowany jest moduł zapasowy. Następuje ponowne wykonanie tych samych operacji przez moduł zapasowy. Naprawa błędu polega na zastąpieniu błędnej wersji nową wersją. Wersja podstawowa Wersja zapasowa Ocena poprawności wyników Dr hab. inż. Barbara Dębska, prof. PWSZ

TYPOWE ŚRODOWISKA IMPLEMENTACJI OPROGRAMOWANIA A. Języki proceduralne. To tradycyjne i najbardziej popularne środowiska implementacji. Dobrze nadają się do implementacji projektu strukturalnego: - procesy i moduły wysokiego poziomu – to całe aplikacje, - procesy i moduły pośredniego poziomu – to grupy procedur i funkcji, - procesy i moduły najniższego poziomu – to pojedyncze procedury i funkcje, - zbiorniki danych – to struktury danych języka proceduralnego lub pliki zewnętrzne. W językach tego typu z reguły dostęp do danych i procedur zabezpiecza się na poziomie modułów. Dr hab. inż. Barbara Dębska, prof. PWSZ

- pola klas umieszczane będą w strukturach danych, np. rekordach, Języki proceduralne pozwalają także na implementację projektu obiektowego. Przyjmuje się, że: - pola klas umieszczane będą w strukturach danych, np. rekordach, - metody klas implementowane będą jako procedury i funkcje, - nie możliwe będzie zapewnienie wiązania danych z procedurami i funkcjami, które na nich operują, - implementacja modelu obiektowego będzie ograniczona, gdyż języki proceduralne nie pozwalają na dziedziczenie i wykorzystanie metod wirtualnych. Dr hab. inż. Barbara Dębska, prof. PWSZ

B. Języki obiektowe. Są szczególnie przydatne do implementacji projektu obiektowego, ponieważ zazwyczaj zezwalają na realizację wszystkich elementów projektu obiektowego. Kompilatory języków obiektowych są wyposażone w biblioteki ułatwiające przechowywanie klas w plikach. Gdy niezbędne jest przechowywanie bardzo dużych zbiorów danych języki te zazwyczaj umożliwiają współpracę z systemem baz danych. Ponieważ większość języków obiektowych pozwala na stosowanie technik proceduralnych można z ich pomocą również programować projekty strukturalne. Dr hab. inż. Barbara Dębska, prof. PWSZ

C. Relacyjne bazy danych. Są to najlepiej przygotowane środowiska do implementacji dużych zbiorów danych. Zalety relacyjnych baz danych: wielodostęp, automatyczna weryfikacja warunków poprawności, możliwość ograniczenia dostępu poszczególnych użytkowników, wysoka niezawodność wiodących systemów, rozszerzalność, możliwość rozproszenia danych, oraz możliwość usuwania kaskadowego powiązania obiektów. Dr hab. inż. Barbara Dębska, prof. PWSZ

Wady relacyjnych baz danych: stosunkowo mała efektywność przy częstych odwoływaniach do pojedynczych, wzajemnie powiązanych krotek z różnych relacji, brak typów złożonych i niewielki wybór typów podstawowych, niewielkie możliwości ograniczenia dostępu do danych dla poszczególnych procedur, oraz brak dziedziczenia. Systemy zarządzania baz danych obejmują specjalizowane języki programowania, które z reguły są językami proceduralnymi, a więc niezbyt dobrze nadają się do implementacji projektów obiektowych. Rozwój standardów dostępu do relacyjnych baz danych (np. standard ODBC – Open DataBase Connectivity) skutkuje tym, że w tych przypadkach możliwa staje się implementacja projektu obiektowego, połączona z przechowywaniem trwałych klas w relacyjnej bazie danych. Dr hab. inż. Barbara Dębska, prof. PWSZ

D. Obiektowe bazy danych. Są to nowe środowiska implementacji projektów programistycznych, dające możliwość automatycznego przechowywania trwałych klas oraz wyszukiwania obiektów na podstawie zapytań. E. Środowiska programistyczne programów użytkowych. Niektóre programy użytkowe zostały wyposażone w proste języki makrodefinicji, które pozwalały na lepsze dostosowanie programów do potrzeb konkretnego użytkownika Dr hab. inż. Barbara Dębska, prof. PWSZ

Program Microsoft Excel: Przykład. Program Microsoft Excel: zawiera pełny, proceduralny język programowania Visual Basic dla Aplikacji, obejmuje bardzo rozbudowaną bibliotekę obiektów, udostępniającą praktycznie wszystkie możliwości tego programu, pozwala na nagrywanie makrodefinicji w formie procedur języka Visual Basic, posiada możliwości dialogowe projektowania interfejsu użytkownika, takie jak: projektowanie dialogów, menu i pasków narzędziowych, umieszczanie pól dialogowych w arkuszach, definiowanie relacji na zajście rozmaitych zdarzeń, zawiera ułatwiający uruchamianie programów debugger, pozwala na dystrybucję aplikacji bez rozprowadzania kodu źródłowego, oraz obejmuje rozbudowane możliwości współpracy z innymi programami, np. DDL, DDE, OLE, czy ODBC. Dr hab. inż. Barbara Dębska, prof. PWSZ

F. Narzędzia szybkiego wytwarzania implementacji. Środowiska programistyczne programów użytkowych bardzo ułatwiają opracowanie prototypów, ponieważ pozwalają szereg operacji zaprogramować w sposób czysto dialogowy, tzn. przez nagranie makrodefinicji. Jeżeli tworzony system zawiera szereg funkcji dostępnych w danym programie użytkowym, to zastosowanie takiego środowiska skraca czas implementacji systemu, a samo podejście staje się równoważne z „montażem systemu z gotowych elementów”. F. Narzędzia szybkiego wytwarzania implementacji. Do tej grupy należą narzędzia RAD – nadają się one do implementacji systemów przeznaczonych do przechowywania danych, wymagających stosunkowo prostego przetwarzania. Dr hab. inż. Barbara Dębska, prof. PWSZ

Podstawowe rezultaty fazy implementacji to: poprawiony dokument opisujący wymagania, poprawiony model, poprawiony projekt, który od tej pory stanowi już dokumentację techniczną, kod składający się z przetestowanych modułów, dostrojona baza danych, oraz harmonogram fazy testowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

dokumentów wydrukowanych, lub/oraz Programiści dokonujący implementacji systemu korzystają z dwóch rodzajów dokumentacji projektu: dokumentów wydrukowanych, lub/oraz dokumentacji w postaci diagramów i słowników danych zbudowanych z wykorzystaniem dostępnego narzędzia projektowania typu CASE. Narzędzia CASE mają zazwyczaj wbudowane generatory kodu, które na podstawie zawartości słownika danych generują szkielety kodu programu, uzupełniane następnie przez programistów. Dr hab. inż. Barbara Dębska, prof. PWSZ

Automatycznie mogą być generowane: skrypty tworzące relacje w bazie danych, definicje struktur danych, nagłówki procedur i funkcji, definicje klas, oraz nagłówki metod. Kod powinien być uzupełniony wieloma komentarzami tworzonymi na podstawie informacji zawartych w słowniku danych. Niektóre narzędzia CASE umożliwiają odwołania do narzędzi RAD, co dodatkowo może przyśpieszyć proces implementacji systemu. Przykład generowania kodu może być zrealizowany za pomocą programu Umbrello. Dr hab. inż. Barbara Dębska, prof. PWSZ

Generowanie kodu szkieletowego w wybranym języku programowania Z menu głównego wybieramy plecenie: Kod->Asystent generowania kodu. Polecenie to spowoduje wyś- wietlenie okna dialogowego kreatora, który krok po kroku poprowadzi do wygenerowania szkieletu kodu dla przyszłej aplikacji. Dr hab. inż. Barbara Dębska, prof. PWSZ

Kreator generowania kodu szkieletowego – etap 1 Lista klas dla których będzie wygenerowany szkielet kodu. Lista wszyst- kich dostęp- nych klas. Nie wszystkie klasy muszą być wybrane. Dr hab. inż. Barbara Dębska, prof. PWSZ

Kreator generowania kodu szkieletowego – etap 2 Pole wyboru języka programowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

Kreator generowania kodu szkieletowego – etap 3 Wybrano język C++. Dr hab. inż. Barbara Dębska, prof. PWSZ

Kreator generowania kodu szkieletowego – etap 4 Ustawienie sposobu formatowania kodu. Dr hab. inż. Barbara Dębska, prof. PWSZ

Kreator generowania kodu szkieletowego – etap 5 Dodatkowe opcje dotyczące treści kodu. Dr hab. inż. Barbara Dębska, prof. PWSZ

Kreator generowania kodu szkieletowego – etap 6 Etap generowania pokazujący jakie pliki będą utworzone. Lista potencjalnych plików do utworzenia. Dr hab. inż. Barbara Dębska, prof. PWSZ

Kreator generowania kodu szkieletowego – etap 7 Etap generowania pokazujący jakie pliki zostały utworzone. Lista plików, które zostały utworzone. Dr hab. inż. Barbara Dębska, prof. PWSZ

Widok listy wygenerowanych plików z kodem szkieletowym Do wyświetlenia listy plików użyto menedżera plików o nazwie Konqueror będące-go standardowym wyposaże-niem środowiska KDE). Drzewo katalogów systemu operacyjnego Linux. Lista widokowa wygenerowanych plików. Katalog zawierający utworzone pliki. Dr hab. inż. Barbara Dębska, prof. PWSZ

Dziękuję za uwagę Dr hab. inż. Barbara Dębska, prof. PWSZ