Transcript PODSTAWY PROGRAMOWANIA

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
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.
Zdefiniowanie problemu
• precyzyjne określenie elementów
tworzących sytuację problemową i
powiązań między nimi:
–dane,
–wyniki,
–cel przetwarzania.
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.
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:
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
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.
Ź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.
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.
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.
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
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
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
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.
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 (opisywaniamodelowania 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
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 CoadaYourdona.
Każda z tych metod miała wady i zalety, nadawała się tylko
do pewnych zastosowań.
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.
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.
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.
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.
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)
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
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.
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.
Cykl życia oprogramowania - model ogólny
(ujęcie podstawowe)
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.
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
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
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.
•
•
•
•
•
•
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).
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.
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ń.
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.
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.
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ęć.
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.
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.
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)
PROJEKTY INFORMATYCZNE
• Projekt informatyczny - do jego realizacji
trzeba używać narzędzi informatyki.
• Fazy tworzenia projektu
informatycznego:
 następne strony
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
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ć.
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ść, wielouż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.
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)
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.
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.
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.
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.
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.
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
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.
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
System Engineer
– 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.