1. Omów przedmiot i zakres inżynierii oprogramowania.
Inżynieria oprogramowania jest wiedzą techniczną dotycząca wszystkich faz cyklu życia oprogramowania. Traktuje oprogramowanie jako produkt, który ma spełniać potrzeby techniczne, ekonomiczne lub społeczne.

Zakres:

- 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 niezawodnoś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 i rozszerzeń)

- Techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

/* Można dopisać dodatkowo:

Inżynieria oprogramowania:

-dziedzina inżynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej do jego pielęgnacji

-jest wiedzą empiryczną, syntezą doświadczenia wielu ośrodków zajmujących się budową oprogramowania

-Informatyka obejmuje teorie i podstawowe zasady działania komputerów, a inżynieria oprogramowania obejmuje praktyczne problemy konstruowania oprogramowania

-Zajmuje się efektywnymi teoriami, metodami i narzędziami związanymi z procesem wytwarzania oprogramowania

-Zastosowanie systematycznego, zdyscyplinowanego, ilościowego podejścia do wykonywania, wykorzystywania i konserwowania oprogramowania [IEEE 93]

*/

2. Omów zagadnienie języka programowania i semiotyki języka programowania.
Język programowania jest środkiem umożliwiającym zapis algorytmów w postaci zrozumiałej dla człowieka, a równocześnie przetwarzalnej do postaci zrozumiałej dla komputera (maszyny algorytmicznej)

Semiotyka zajmuje się badaniem symboli, znaków. W jej skład wchodzą:

-syntaktyka, zajmująca się określeniem przynależności danego słowa do zestawu słownika określonego języka programowania. //składnia języka.

-semantyka, zajmująca się określeniem znaczenia programu, zapisanego w określonym języku programowania.

3. Omów zagadnienie i skutki tzw. „kryzysu oprogramowania”.
-Syndrom LOOP:

Late (późno)

Over budget (przekroczony budżet)

Overtime (nadgodziny)

Poor quality (kiepska jakość)

Skutki: Dane empiryczne:

- 27% projektów powstaje w założonym czasie, budżecie i funkcjonalności

- 33% projektów przekracza czas, budżet i ma mniejszą funkcjonalność

- 40% projektów jest przerywanych

- 53% projektów przekracza koszty o 51%

- 68% projektów przekracza czas o 51%

-„Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania”

- Przyczyny niepowodzeń w realizacji SI:

- brak jasno sprecyzowanych celów

- brak porozumienia

- nieumiejętne zarządzanie

- niesprawny sprzęt i oprogramowanie

- zła ocena złożoności systemu

- wielkość projektu

- inne

69% niepowodzeń to czynniki pozainformatyczne

/* Można dopisać dodatkowo:

-Zasadnicze problemy wytwórców oprogramowania:

• wzrost mocy sprzętu zwiększa zapotrzebowanie na nowe, bardziej złożone oprogramowanie;

• długi i kosztowny cykl wytwarzania oprogramowania;

• frustracje projektantów oprogramowania i programistów wynikające ze zbyt szybkiego postępu w zakresie języków, narzędzi i metod;

• uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są stabilne w długim horyzoncie czasowym;

• brak kontaktów pomiędzy użytkownikiem i firmą;

• problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych;

• niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania;

• zbyt późne wykrywanie błędów i słabych punktów;

• brak koordynacji w pracy zespołów projektowych;

• ogromne koszty utrzymania oprogramowania;

*/

4. Omów przykładowe źródła złożoności projektu informatycznego.
-Dziedzina problemowa - obejmuje ogromną liczbę wzajemnie uzależnionych aspektów i problemów.

-Środki i technologie informatyczne - sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia.

-Zespół projektantów - podlega ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji.

-Potencjalni użytkownicy - czynniki psychologiczne ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

5. Omów sposoby opanowywania złożoności projektu informatycznego.
-Zasada dekompozycji - rozdzielenie problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości.

-Zasada abstrakcji - eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnych informacji; wyodrębnienie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzenie pojęć lub symboli oznaczających takie cechy

-Zasada ponownego użycia - wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania itd.

-Zasada sprzyjania naturalnym ludzkim własnościom - dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata

6. Omów zagadnienie modelowania pojęciowego w projekcie informatycznym.
-Projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania

-Pojęcie modelowania pojęciowego (conceptual modeling) oraz modelu pojęciowego (conceptual model) odnoszą się do procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem.

-Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię, Służą one do przedstawienia rzeczywistości opisywanej przez dane procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu

-Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz konstrukcji SI jest dążenie do minimalizacji luki pomiędzy myśleniem o rzeczywistym problemie, a myśleniem o danych i procesach zachodzących na danych.

/* Można dopisać dodatkowo:

Perspektywy w modelowaniu pojęciowym

*/

7. Co to jest metodyka prowadzenia projektu informatycznego?
-Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego, logicznego i/lub fizycznego

-Metodyka powiązana jest z notacją służącą do dokumentowania wyników faz projekt (pośrednich, końcowych), jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem

-Metodyka ustala:

+fazy projektu, role uczestników projektu,

+modele tworzone w każdej z faz,

+scenariusze postępowania w każdej z faz.

+reguły przechodzenia od fazy do następnej fazy,

+notacje, których należy używać,

+dokumentację powstającą w każdej z faz

8. Omów następujący model cyklu życia oprogramowania: … nazwa modelu
Model kaskadowy: ciag czynnosci wykonywanych sekwencyjnie:
-okreslenie wymagan
-analiza
-projektowanie
-implementacja
-testowanie
-konserwacja
wady:

-Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac
-Wysoki koszt błędów popełnionych we wczesnych fazach
-Długa przerwa w kontaktach z klientem

Z drugiej strony, jest on do pewnego stopnia niezbędny dla planowania, harmonogramowania, monitorowania i rozliczeń finansowych.

Model iteracyjny:

• wczesne iteracje zajmują się największym ryzykiem;

• w każdej powstaje wersja uruchomieniowa;

• każda iteracja zawiera integrację i testowanie;

• projekt realizuje się przyrostowo - każdy; „przyrost” jest podzbiorem funkcjonalnym systemu;

• model iteracyjny:

• ułatwia detekcję ryzyka zanim się dokona dużych inwestycji;

• zapobiega utknięciu całego systemu w martwym punkcie;

• umożliwia wczesną reakcję użytkownika;

• zapewnia ciągłe testowanie i integrację;

• zwraca szczególną uwagę na krótko-terminowość wykonania projektu;

• umożliwia dystrybucję częściowych implementacji;

Model V
Rozwinięciem modelu wodospadu jest model V, charakteryzujący się rozbudowaną fazą testów. Model V jest jednym z najpopularniejszych podejść do procesu testowania. Testy mają na celu weryfikację i walidację poprawności wykonania każdego etapu stanowiącego cykl życia oprogramowania. Dzięki rozbudowaniu sekwencji etapów wytwórczych o testowanie otrzymujemy produkt o najwyższej jakości, spełniający wymagania klienta.

Model V jest często stosowany w metodykach „Rational” bazujących na języku UML.

Specyfikacja \ projekt systemu \ projekt podsystemu \ projekt modułu \ kodowanie, wstępne testowanie modułu / formalne testowanie modułu / integracja i walidacja podsystemu / integracja i walidacja systemu / testy akceptacyjne systemu

Model ewolucyjny:
-opracowaniu wstępnej implementacji,
-pokazaniu jej użytkownikowi z prośbą o komentarze
-oraz udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu;

-wyroznia sie tworzenie badawcze (praca z klientem) oraz prototypowanie (praca z elementami systemu budzacymi watpliwosci)

-Wady modelu ewolucyjnego:

+Proces nie jest widoczny;

+System ma złą strukturę;

+Konieczne mogą być specjalne narzędzia i techniki;

Model spiralny:
opiera się na ewolucyjnym projekcie, który jest początkowo planowany, następnie następuje analiza ryzyka systemu, konstrukcja (często odbywa się zgodnie z modelem kaskadowym) a potem klient testuje system, informuje, co wymaga zmian i poprawek, i zgodnie z nimi cały cykl rozpoczyna się od początku, w kolejnym obrocie pętli do istniejącego systemu wprowadzane są poprawki dopóki klient nie zaakceptuje systemu.

Programowanie odkrywcze:

„Programowanie odkrywcze” nie jest obecnie dobrym sposobem budowy jakichkolwiek systemów informatycznych. Tworzone dziś systemy są po prostu zbyt skomplikowane, aby przez cały cykl życia tych systemów, mogła nad nimi panować jedna osoba.

1. określ ogólne wymagania

2. zbuduj system

3. przetestuj system

4. zadowala? goto 5 : goto 2;

5. dostarcz system

Prototypowanie:
Sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe.
Fazy:

• ogólne określenie wymagań

• budowa prototypu

• weryfikacja prototypu przez klienta

• pełne określenie wymagań

• realizacja pełnego systemu zgodnie z modelem kaskadowym

Cele:

• wykrycie nieporozumień pomiędzy klientem a twórcami systemu

• wykrycie brakujących funkcji

• wykrycie trudnych usług

• wykrycie braków w specyfikacji wymagań

Zalety:

• możliwość demonstracji pracującej wersji systemu

• możliwość szkoleń zanim zbudowany zostanie pełny system

9. Omów zadania kierownictwa przedsięwzięcia informatycznego w cyklu wytwórczym oprogramowania.

Podstawowe zadania kierownictwa przedsięwzięcia informatycznego:

1. Opracowanie propozycji dotyczących sposobu prowadzenia przedsięwzięcia

2. Kosztorysowanie przedsięwzięcia

3. Planowanie i harmonogramowanie przedsięwzięcia

4. Monitorowanie i kontrolowanie realizacji przedsięwzięcia

5. Dobór i ocena personelu

6. Opracowanie i prezentowanie sprawozdań dla kierownictwa wyższego szczebla

10. Omów podstawowe czynniki psychologiczne w procesie wytwórczym i rodzaje osobowości twórców oprogramowania.

-Użytkowanie - implikuje zasady tworzenia interfejsu użytkownika i dokumentacji użytkowej,

-Tworzenie - zagadnienia psychologiczne odgrywające rolę w tworzeniu oprogramowania.

-Elementy ludzkiej inteligencji:

+Umiejętność całościowego (syntetycznego) spojrzenia na problem.

+Posługiwanie się wiedzą płynącą z doświadczenia, a więc stosowania nieścisłych zasad wnioskowania na bazie wcześniejszych doświadczeń.

Istnieją ogromne różnice w predyspozycjach osób dotyczące ich efektywności w produkcji oprogramowania.

Testy osobowości: metody określenia, czy dana osoba posiada cechy przydatne na danym stanowisku.

Stosowanie testów osobowości wiąże się z następującymi trudnościami:

1. Osobowość ludzka ma charakter dynamiczny (zmienia się). Wieloletnia praktyka zawodowa nie pozostaje bez wpływu na osobowość.

2. Różne zadania mogą wymagać różnych cech osobowości. Inne powinien posiadać analityk (kontakt z klientem), inne zaś programista lub osoba testująca oprogramowanie. Ponadto, metody inżynierii oprogramowania ulegają zmianie, co pociąga za sobą inny stosunek pożądanych cech osobowości do aktualnych zadań.

3. Osoby poddane testom będą starały się raczej odgadnąć pożądaną przez testujących odpowiedź niż odpowiadać zgodnie ze stanem faktycznym. Test nie będzie więc odzwierciedlał cech osobowości osoby, lecz raczej to, jak ta osoba wyobraża sobie cele i kryteria testowania oraz cechy pożądane przez pracodawcę.

11. Omów cechy dobrego inżyniera oprogramowania i sposoby zorientowania na pracę w cyklu wytwórczym oprogramowania.

-Umiejętność pracy w stresie. W pracy często zdarzają się okresy wymagające szybkiego wykonania złożonych zadań. Dla większości osób niewielki stres działa mobilizująco. Po przekroczeniu jednak pewnego progu następuje spadek możliwości danej osoby. Próg ten jest różny dla różnych osób.

-Zdolności adaptacyjne. Informatyka jest jedną z najszybciej zmieniających się dziedzin. Ocenia się, że 7-9 miesięcy przynosi w informatyce zmiany, które w innych dziedzinach zajmują 5-7 lat. Oznacza to konieczność stałego kształcenia dla wszystkich inżynierów oprogramowania - stałe poznawanie nowych narzędzi, sprzętu, oprogramowania, technologii, metod, sposobów pracy. Niestety, nie wszyscy to tempo wytrzymują.

-Uśpienie, zajmowanie się jednym problemem w jednym środowisku przez lata jest w informatyce bardzo groźne!

Czynniki psychologiczne mają zasadniczy wpływ na efektywność pracy zespołu. Wyróżnia się następujące typy psychologiczne:

1. Zorientowani na zadania (task-oriented). Osoby samowystarczalne, zdolne, zamknięte, agresywne, lubiące współzawodnictwo, niezależne.

2. Zorientowani na siebie (self-oriented). Osoby niezgodne, dogmatyczne, agresywne, zamknięte, lubiące współzawodnictwo, zazdrosne.

3. Zorientowani na interakcję (interaction-oriented). Osoby nieagresywne, o niewielkiej potrzebie autonomii i indywidualnych osiągnięć, pomocne, przyjazne.

Osoby typu 1 są efektywne, o ile pracują w pojedynkę. Zespół złożony z takich osób może być jednak nieefektywny. Lepsze wyniki dają zespoły złożone z typów 3. Typ 1 i 2 może być także efektywny w zespole, o ile jest odpowiednio motywowany przez kierownictwo. Typy 3 są konieczne w fazie wstępnej wymagającej intensywnej interakcji z klientem.

12. Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według Prince2

„Projekt, to sposób prowadzenia przedsięwzięć gospodarczych zmierzający do wytworzenia produktu uzasadnionego biznesowo, w ramach określonego czasu, budżetu, z odpowiednią strukturą organizacyjną , rolami i zakresami odpowiedzialności.”

-W Prince2 skoncentrowano się na określeniu zasad organizacji i zarządzania projektem, co ma w przekonaniu jej autorów gwarantować prawidłowe jego rozpoczęcie i doprowadzenie do pomyślnego zakończenia oraz wypracowanie oczekiwanych produktów, przy jednoczesnym dotrzymaniu planowanego czasu, budżetu i jakości projektu.

-Dzięki oddzieleniu grupy zarządczej, odpowiedzialnej za organizację i kierowanie, od technicznej wytwarzającej produkt, może ona znaleźć zastosowanie w wielu dziedzinach

Produkt:

-Przez produkty projektu rozumie się wszystkie jego elementy, które mogą powstać w wyniku jego realizacji.

-Może to być gotowe oprogramowanie, zainstalowane systemy, dokumentacja oprogramowania, różnego rodzaju procedury, wykształcone kadry ludzkie itp.

-Opracowanie planów działań w wymiarze produktów odbywa się na podstawie definicji zakresu projektu.

Wymiar czasu:

-Na podstawie precyzyjnie zdefiniowanego zakresu projektu można zdefiniować drugi wymiar projektu, czyli czas, który jest najczęściej zapisywany w postaci harmonogramu.

-Często spotykaną formą prezentacji harmonogramu są na przykład tabele lub arkusze kalkulacyjne, jak również wykresy Gantta, które przedstawiają poszczególne czynności projektowe w sieci uwzględniającej wzajemne ich zależności, następstwa i zasoby niezbędne do ich wykonania w odpowiednio zdefiniowanej skali czasu.

Koszt:

-Budżet projektu stanowi zestawienie kosztów realizacji projektu.

-Koszt ten powinien być podzielony na poszczególne jego kategorie.

-Mogą to być

+koszty osobowe,

+koszty sprzętu,

+administracji projektu,

+delegacji,

+szkoleń itp.

Wymiar jakości dotyczy:

• oceny zarówno poszczególnych produktów projektowych:

• dokumentacji,

• oprogramowania,

• platformy techniczno-systemowej itp.

• jak i oceny organizacji procesu projektowego:

• planu wzajemnych oddziaływań procesów projektowych,

• zasobów ludzkich zaangażowanych w projekt,

• zarządzania poszczególnymi wymiarami projektu itp.

13. Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń Prince2.

Sponsor projektu:

-Najczęściej jest to członek zarządu klienta lub jego bezpośredni przedstawiciel.

-Jest on odpowiedzialny za finansowanie całego przedsięwzięcia i reprezentuje informatyzowany biznes.

-Zna on dokładnie wartość biznesową projektu i musi posiadać uprawnienia do podejmowania decyzji w zakresie zmian dotyczących projektu.

Sponsor w początkowej fazie projektu:

- formułuje misję przedsięwzięcia informatycznego i uzasadnia ją biznesowo

- wyznacza budżet projektu

- ustala główne oczekiwane produkty projektu

- mianuje Przewodniczącego Rady Projektu, zatwierdza pozostałych członków Rady

W pozostałych fazach projektu:

- zatwierdza odbiór produktów projektu,

- na poziomie taktycznym decyduje w kluczowych momentach projektu, (wstrzymuje projekt , przydziela dodatkowe finanse itp.),

- jest mediatorem w ważnych konfliktach, niemożliwych do rozstrzygnięcia na niższych szczeblach struktury projektu.

Rada Projektu:

-Rada Projektu (Komitet Sterujący) zawiera w swoim ciele reprezentację wszystkich uczestników projektu, takich jak: Sponsor, użytkownicy, dostawcy. Składa się on z:

+Przewodniczącego Rady, mianowanego przez Sponsora

+pozostałych członków Rady zaproponowanych przez Przewodniczącego Rady

-obraduje w kluczowych momentach projektu, takich jak: początek i koniec projektu oraz tzw. punktach krytycznych (ang. milestones) poszczególnych faz projektu

-Spotyka się również doraźnie w przypadku występowania zagrożeń dla prawidłowej realizacji projektu

-główne zadania Rady Projektu:

+mianowanie Szefów Projektu,

+okresowa i etapowa ocena stanu projektu i zatwierdzanie planów dalszych prac,

+rozstrzyganie sporów występujących na szczeblu Szefów Projektu

+zatwierdzanie Wniosków o Zmianę w zakresie funkcjonalnym i niefunkcjonalnym projektu

+zatwierdzanie akceptacji kolejnych produktów projektu

Szef projektu:

-Szef (Kierownik) Projektu jest personalnie odpowiedzialny za sukces lub porażkę projektu

-Szef Projektu decyduje na szczeblu operacyjnym

-Szefowie projektów ze strony wytwórcy i ze strony dostawcy tworzą Zarząd Projektu

-Zarząd Projektu decyduje na szczeblu taktyczno-operacyjnym

-pozostałe szczeble decyzyjne:

+decyzje taktyczne - Rada Projektu

+decyzje strategiczne - Sponsor Projektu

Szef jakości:

-Szef Jakości jest współpracuje z Szefami Projektu

-uczestniczy we wszystkich pracach zespołów realizacyjnych (bardzo dyskusyjne)

-w zakresie jakości podlegają mu

+plany i dokumentacja projektu

+produkty i ich testy

+praca zespołów realizacyjnych

+kontakty z poddostawcami

+gospodarka finansowa projektu

+zarządzanie ryzykiem projektu

Komitet kontroli zmian:

-Komitet Kontroli Zmian składa się z przedstawicieli zarówno dostawcy jak i klienta. Jego skład wyznacza Rada Projektu

-Spotkania Komitetu odbywają się doraźnie, w przypadku konieczności rozpatrzenia Wniosków o zmianę w projekcie, składanych przez Szefów Projektów oraz w czasie przeglądów zatwierdzania etapów zarządczych.

-W przypadku niemożności podjęcia decyzji o dokonaniu zmian przedkłada on sprawę do rozstrzygnięcia Radzie Projektu.

Komitet akceptacyjny:

-Komitet Akceptacyjny składa się przeważnie z przedstawicieli obu stron, często jednak spotyka się w nim wyłącznie przedstawicieli klienta.

-Podlega mu zespół testów akceptacyjnych.

-Podstawowym zadaniem Komitetu Akceptacyjnego jest wypracowanie decyzji odnośnie przyjęcia lub odrzucenia produktów, na podstawie wyników testów i opinii specjalistów, a następnie przedstawieniu jej Radzie Projektu, która podejmuje decyzję o akceptacji bądź braku akceptacji produktów projektu

sekretariat/administracja biura projektu

-Wykonuje zadania w zakresie:

+prowadzenia biblioteki projektu, planów, raportów, Wniosków o Zmianę itp.

+zarządzania korespondencją, dokumentacją spotkań

+zbierania i konsolidacji raportów z zespołów technicznych,

+przygotowania materiałów do raportów Szefa Projektu

+spraw osobowych (urlopy, rozliczenia finansowe, sprawy pracownicze itp.)

+rozliczeń finansowych z dostawcami zewnętrznymi

+rozliczeń finansowych z klientem

-w większych projektach powołuje się:

+Menedżera Konfiguracji (ang. Configuration Manager)

+Bibliotekarza Projektu (ang. Librarian)

+Planistę (ang. Planner)

Zespoły realizacyjne:

-Zespoły realizacyjne są wykonawcami produktów i dlatego od ich prawidłowego składu i organizacji zależy powodzenie realizacji projektu.

-często łączy się w nich fachowców tych samych specjalnościach.

-Szefów Zespołów powinni być oni doświadczonymi fachowcami z danej dziedziny przedmiotowej projektu, posiadających zdolności kierowania ludźmi.

-Najczęściej pełnią one również rolę zespołów testów (lub powoływany jest oddzielny zespół testów)

14. Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według metodyki PMI.

wymiar zakresu

-Zarządzanie zakresem projektu obejmuje procesy wymagane dla uzyskania pewności, że projekt uwzględnia wszystkie konieczne czynności niezbędne dla pomyślnego zakończenia projektu i uzyskania oczekiwanego zakresu produktu.

-Procesy te w głównej mierze są skoncentrowane na permanentnym ustalaniu, co powinno mieścić się w zakresie projektu, czy w zakresie produktu

-Główne procesy:

+inicjowanie faz projektu

+planowanie zakresu

+definiowanie zakresu

+weryfikacja zakresu

+kontrola zmian zakresu

wymiar kosztu

-Zarządzanie kosztem projektu obejmuje procesy wymagane do zapewnienia, że projekt zostanie ukończony w ramach zaakceptowanego budżetu.

-Główne procesy:

+planowanie zasobów

+estymowanie kosztu

+przypisywanie kosztów (budżetowanie)

+kontrola kosztu

+zarządzanie zmianami budżetu

wymiar czasu

-Zarządzanie harmonogramem projektu obejmuje procesy wymagane do zapewnienia przestrzegania przez zespół projektowy ustalonych granic czasowych dla poszczególnych czynności w projekcie.

-Główne procesy:

+definiowanie czynności

+sekwencjonowanie czynności

+estymowanie czasu

+opracowanie harmonogramu

+kontrola wykonania harmonogramu

+zarządzanie zmianami harmonogramu

wymiar jakości

-Zarządzanie jakością projektu obejmuje procesy wymagane do zapewnienia zaspokojenia przez rezultaty projektu tych potrzeb, dla których został on powołany.

-Zalicza się tu wszystkie czynności z zakresu funkcji zarządzania, których wykonanie decyduje o celach i polityce jakości w projekcie.

-Główne procesy:

+planowanie jakości,

+zapewnienie jakości

+kontrola jakości

wymiar komunikacji

-Zarządzanie komunikacją obejmuje procesy służące zapewnieniu terminowego i właściwego tworzenia, gromadzenia, rozpowszechniania, przechowywania i usuwania informacji niezbędnej do efektywnego zarządzania projektem.

-Analizuje się tutaj wszystkie istotne połączenia między ludźmi, ideami oraz wszelkimi informacjami potrzebnymi dla osiągnięcia sukcesu przedsięwzięcia informatycznego.

-Każdy zatrudniony w projekcie musi być przygotowany do wysyłania i odbierania komunikatów w języku projektu i musi rozumieć w jaki sposób komunikacja, w której bierze udział, wpływa całość projektu.

-Główne procesy:

+planowanie komunikacji

+dystrybuowanie informacji

+sprawozdawczość

wymiar integracji

-Zarządzanie integracją projektu obejmuje procesy wymagane do zapewnienia poprawnej koordynacji wszystkich elementów projektu.

-Procesy te umożliwiają koordynację działań mających na celu:

+zaspokojenie wszystkich zidentyfikowanych potrzeb stron zainteresowanych projektem

+spełnienie ich oczekiwań w stopniu zapewniającym pomyślność projektu

-Główne procesy:

+wypracowanie planu projektu

+wykonywanie planu projektu

+ogólna kontrola zmian projektu

wymiar ryzyka

-Zarządzanie ryzykiem obejmuje procesy identyfikacji, analizowania i reakcji na zaistnienie czynników ryzyka w projekcie.

-Jest to związane z podejmowaniem przez Szefa Projektu decyzji w warunkach niepełnej i niepewnej wiedzy o skutkach tej decyzji dla projektu.

-Główne procesy:

+identyfikacja ryzyka

+estymowanie ryzyka

+optymalizacja ryzyka

+monitorowanie ryzyka

wymiar ludzki

-Zarządzanie zasobami ludzkimi obejmuje procesy ułatwiające efektywne wykorzystanie ludzi w projekcie (klientów, sponsorów i innych uczestników).

-Procesy te uwzględniają między innymi:

+przywództwo, komunikację, negocjacje,

+delegowanie, motywowanie, mentoring,

+budowę zespołów, rozwiązywanie konfliktów,

+rekrutację, różne regulacje

zaopatrywanie

-Zarządzanie zaopatrywaniem/zleceniami/sprzedażą obejmuje zdobywanie dóbr i usług spoza organizacji wykonującej projekt.

- Obszar ten jest badany z perspektywy kupującego oraz relacji kupujący-dostawca. Relacja ta może istnieć na wielu szczeblach jednego projektu.

- Dla dostawcy kluczowym podmiotem jest odbiorca.

- Główne procesy:

• planowanie zleceń

• planowanie ofert

• realizacja ofert, selekcja dostawców

15. Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń metodyki Chestra SBS.

-Silna pozycja Kierownika Projektu (Szefa Projektu),

-zakres projektu i zakres produktu jest określany przez Architekta Systemowego i Architekta Biznesowego,

-Menedżer Jakości podlega pod Szefa Projektu

-Menedżer Konfiguracji nie jest już składową administracji projektu

-wyróżniono obszary dokumentacji i testów

16. Porównaj zalecenia Prince2, PMI i Chestra SBS w zakresie obszarów zarządzania projektem informatycznym i organizacji biura projektu informatycznego.

/* Tej części nie ma w wykładach:

Studiując metodyką Prince2 można odnieść nieodparte wrażenie, że jest ona mocno sugerowana osiągnięciami standardów PMI. Wydaje się, że autorom metodyki Prince2 zależało przede wszystkim na pewnym zagregowaniu, usystematyzowaniu i przełożeniu zasad

określonych w standardach północno-amerykańskich na uwarunkowania rynku europejskiego.

• Różnice w zakresie zarządzania projektem informatycznym w Prince2 i PMI

Różnice w organizacji biura projektu informatycznego w Prince2 i Chestr SBS:

W zaleceniach Prince 2 wyróżnia się szefa projektu od strony użytkownika i dostawcy (tworzą oni zarząd projektu), w Chestr jest jeden szef projektu inaczej zwany kierownikiem, posiadający silną pozycje. Istotne różnice w administracji projektu to: w Prince2 menedżer konfiguracji(powoływany do większych projektów) który to w metodyce Chestr nie jest składową administracji projektu a dodatkowo w Chestr powołuje się menedżerów budżetu i jakości. Kolejną różnicą jest w Chestr architekt systemowy i biznesowy(określają zakres projektu i produktu) natomiast w Prince2 sekretariat biura projektu. Wyróżnionymi obszarami w Chestr jest dokumentacja i testowanie. W metodyce Prince2 dzięki oddzieleniu grupy zarządczej, odpowiedzialnej za organizację i kierowanie, od technicznej wytwarzającej produkt, może ona znaleźć zastosowanie w wielu dziedzinach. Co do Chestra to ambitnych odsyłam do toolboxa Siemensa który dodaje jako załącznik.

Cechy:

W Prince2 skoncentrowano się na określeniu zasad organizacji i zarządzania projektem, co ma w przekonaniu jej autorów gwarantować prawidłowe jego rozpoczęcie i doprowadzenie do pomyślnego zakończenia oraz wypracowanie oczekiwanych produktów, przy jednoczesnym dotrzymaniu planowanego czasu, budżetu i jakości projektu.

*/

17. Omów zagadnienie zarządzania konfiguracją w przedsięwzięciu informatycznym na podstawie metodyki RUP.

/* Tej części nie ma w wykładach: ???

RUP:

-Ukierunkowany na przypadki użycia

-Architekturo-centryczny

-Iteracyjny

-Przyrostowy

-Sterowany ryzykiem

-Proces budowy systemu informatycznego składa się z dyscyplin, z których każda dzielona jest na fazy:

+Rozpoczęcie

+Opracowanie

+Budowa

+Przekazanie

-Kamienie milowe

*/

-Proces zarządzania konfiguracją oprogramowania jest realizowany w celu:

+identyfikacji i udokumentowania funkcjonalnych oraz niefunkcjonalnych charakterystyk produktów projektowych,

+monitorowania wszelkich zmian tych charakterystyk,

+zapisywania i raportowania tych zmian oraz stopnia implementacji tych zmian,

+weryfikacji poszczególnych produktów projektowych pod względem spełniania wymagań ustalonych dla tych produktów

-Zarządzanie konfiguracją jest związane z:

+zarządzaniem żądaniami zmian (ang. Change Request Management CRM),

+raportowaniem statusu konfiguracji,

+śledzeniem zmian

+zarządzaniem wersjami dokumentacji i oprogramowania

+zarządzaniem architekturą oprogramowania

18. Omów zakres działania tzw. „inżynierii wymagań” w procesie wytwórczym oprogramowania.

-Budowę systemu należy zacząć od wyraźnego określenia:

+celu, jaki ma zostać osiągnięty,

+użytkowników z podziałem na role,

+zakresu wsparcia uzyskanego w wyniku wdrożenia systemu;

-Zakres systemu określa się poprzez wymagania;

-Wymagania należy formułować z punktu widzenia wszystkich zidentyfikowanych użytkowników;

-Użytkownikami są

+fizyczne osoby,

+inne systemy informatyczne komunikujące się z projektowanym systemem;

-Pojęcie wymaganie nie jest jednoznaczne:

+Może być postrzegane jako: abstrakcyjne określenie usług, które system powinien oferować, albo ograniczenie działania systemu;

+Może być też: szczegółową, matematycznie formalną definicją funkcji systemu;

-Proces inżynierii wymagań to:

+wynajdowanie,

+analizowanie,

+specyfikowanie i dokumentowanie,

+sprawdzania usług i ograniczeń.

-Czynność ta powinna doprowadzić do stworzenia dokumentu zwanego Specyfikacją Wymagań Systemowych (SWS);

-Podczas wytwarzania systemu niezbędne jest duże zaangażowania ze strony:

+klienta,

+przyszłych użytkowników systemu,

+ekspertów w dziedzinie.

-Celem fazy określenia wymagań jest ustalenie wymagań klienta wobec tworzonego systemu;

-Klient wspólnie z przedstawicielem producenta konstruuje zbiór wymagań zgodnie z postawionymi celami;

-Dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie tych celów;

-System nie może być dla klienta niespodzianką w rodzaju „króliczka z kapelusza”;

19. Omów podstawowe metody rozpoznawania wymagań i cechy jakościowego dobrego opisu wymagań.

Dobry opis wymagań powinien:

-być kompletny oraz niesprzeczny

-opisywać zewnętrzne działanie systemu, a nie sposób jego realizacji

-obejmować ograniczenia przy jakich musi pracować system

-być łatwym w modyfikacji

-brać pod uwagę przyszłe możliwe zmiany wymagań wobec systemu

-opisywać zachowanie systemu w niepożądanych lub skrajnych sytuacjach

/* Można dopisać dodatkowo:

Najbardziej typowy błąd w tej fazie: koncentrowanie się na sytuacjach typowych i pomijanie wyjątków oraz przypadków granicznych. Zarówno użytkownicy jak i analitycy mają tendencję do nie zauważania sytuacji nietypowych lub skrajnych.

*/

Metody rozpoznawania wymagań:

-Wywiady i przeglądy. Jako lista pytań; podzielone na odrębne zagadnienia; przykrywające całość tematu; reprezentatywna grupa użytkowników;

-Studia nad istniejącym oprogramowaniem. Stare opr. Zastępuje nowe -> ustalić dobre i złe strony starego opr.

-Studia osiągalności. Określenie realistycznych celów i metod ich osiągnięcia.

-Prototypowanie. Model w mniejszej skali i uproszczonym interfejsem.

20. Omów główne klasy wymagań na system informatyczny. Podaj przykłady takich wymagań.

a)Wymagania funkcjonalne

+Są stwierdzeniami, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach.

+W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić.

+Mogą być również wykonywane przy użyciu systemów zewnętrznych.

Przykład:
a) Użytkownik będzie mógł przeszukać zbiór wszystkich baz danych lub wybrać tylko ich podzbiór.
b) System udostępni odpowiednie narzędzia do oglądania, aby użytkownik mógł czytać dokumenty z magazynu.

b)Wymagania niefunkcjonalne

+To ograniczenia usług i funkcji systemu.

+Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.

Przykład:
a) System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób jego organizacji powinien zmniejszać liczbę błędów użytkownika.
b) Doświadczeni kontrolerzy powinni móc używać wszystkich funkcji systemu po szkoleniu trwającym dwie godziny. Po tym szkoleniu średnia liczba błędów robionych przez doświadczonych użytkowników nie powinna przekroczyć dwóch dziennie.

c)Wymagania dziedzinowe

+Pochodzą z dziedziny zastosowania systemu - odzwierciedlają jej charakterystykę.

+Mogą być funkcjonalne lub niefunkcjonalne.

Przykład:

wymagania stawiane systemowi biblioteki
a) Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z39.50.
b) względu na ochronę praw autorskich niektóre dokumenty należy składać natychmiast po ich otrzymaniu. Zależnie od wymagań użytkownika, dokumenty te będą drukowane lokalnie na serwerze systemowym i przekazywane do rąk czytelnika albo wysyłane na drukarkę sieciową.

/* Moja indywidualna odpowiedź:

a)) Klient ma dostęp do funkcji systemu po podaniu loginu i hasła za pośrednictwem strony internetowej. Do wszystkich tych funkcji ma również dostęp bezpośrednio w biurze maklerskim po podaniu nazwiska (wylegitymowanie się) i numeru rachunku inwestycyjnego. Pracownik biura obsługujący klienta zalogowany na swoim koncie w systemie, po podaniu w/w danych klienta, ma dostęp do jego rachunku inwestycyjnego i może w jego imieniu dokonywać na nim takich samych zmian jak klient (jeśli dana funkcja systemu nie wymaga dodatkowej autoryzacji). Zalogowanie się do sytemu w powyższy sposób jest warunkiem niezbędnym dla wszystkich niżej opisanych funkcji i nie będzie ponownie uwzględniane w warunkach wstępnych.

b)) Wydajność: Możliwość obsługi tysiąca transakcji w ciągu godziny.Zwracanie wyniku zapytania po max 5 sekundach przy zalogowanych 20 użytkownikach. Płynne funkcjonowanie na komputerach klasy PC Pentium 3 ze 128 MB RAM-u.

Rozmiar: 2 TB serwera. 2 TB drugiego serwera.

Łatwość użytkowania: Wymagane przeszkolenie 12 godzinne. Okienko pomocy dla każdej funkcji.

Niezawodność: Dostępność systemu 24h/dobę. Czas restartu po awarii systemu: 5 min.

P- stwo zniszczenia danych po awarii: 0,001%.

P- stwo błędu podczas realizacji transakcji: 0,001%.

Przenaszalność: System działa na komputerach z platformą Windows od wersji 2000.

c)) System do zakupów przez internet ma być dostępny dla osób niewidomych. (wszystkie operacje powinny być głosowe).

*/

21. Omów i podaj przykłady wymagań funkcjonalnych dla systemu informatycznego.

Określenie wymagań funkcjonalnych obejmuje:

-Określenie wszystkich rodzajów użytkowników, którzy:

-będą korzystać z systemu,

-są niezbędni do działania systemu (obsługa, wprowadzanie danych, administracja);

-Dla każdego rodzaju użytkownika określenie funkcji systemu oraz sposobów korzystania z planowanego systemu.

-Określenie systemów zewnętrznych, które będą wykorzystywane podczas działania systemu (zewn. bazy danych, sieci, Internet).

-Ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń, instrukcji, itd., które pośrednio lub bezpośrednio określają funkcje systemu.

/* Moja indywidualna odpowiedź:

Klient ma dostęp do funkcji systemu po podaniu loginu i hasła za pośrednictwem strony internetowej. Do wszystkich tych funkcji ma również dostęp bezpośrednio w biurze maklerskim po podaniu nazwiska (wylegitymowanie się) i numeru rachunku inwestycyjnego. Pracownik biura obsługujący klienta zalogowany na swoim koncie w systemie, po podaniu w/w danych klienta, ma dostęp do jego rachunku inwestycyjnego i może w jego imieniu dokonywać na nim takich samych zmian jak klient (jeśli dana funkcja systemu nie wymaga dodatkowej autoryzacji). Zalogowanie się do sytemu w powyższy sposób jest warunkiem niezbędnym dla wszystkich niżej opisanych funkcji i nie będzie ponownie uwzględniane w warunkach wstępnych.

*/

22. Omów i podaj przykłady wymagań niefunkcjonalnych dla systemu informatycznego.

-Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje danych używane przez interfejsy systemu.

-Wymagania niefunkcjonalne wynikają z:

-potrzeb użytkownika,

-ograniczeń budżetowych,

- strategii firmy,

- konieczności współpracy z innymi systemami sprzętu lub oprogramowania,

-czynników zewnętrznych.

-Wymagania produktowe:

-Określają zachowanie produktu. Przykładami są wymagania efektywnościowe dotyczące szybkości działania systemu i jego zapotrzebowania na pamięć, wymagania niezawodności.

-Wymagania organizacyjne

-Wynikają ze strategii i procedur w firmie klienta i w firmie wytwórcy.

-Wymagania zewnętrzne:

-Ta szeroka kategoria mieści wszystkie wymagania wynikające z czynników zewnętrznych. Obejmują m.in. wymagania współpracy, które definiują interakcje systemu z systemami innych firm i wymagania prawne.

Wymaganie produktowe

-System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób jego organizacji powinien zmniejszać liczbę błędów użytkownika.

oraz wersja weryfikowalna:

-Doświadczeni kontrolerzy powinni móc używać wszystkich funkcji systemu po szkoleniu trwającym dwie godziny.
Po tym szkoleniu średnia liczba błędów robionych przez doświadczonych użytkowników nie powinna przekroczyć dwóch dziennie.

Wymaganie organizacyjne:

-Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w standardzie XYZCo-SP-STAN-95.

Wymaganie zewnętrzne

-System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych

/* Tego nie ma w wykładach:

-Wymagania dotyczące produktu. Np. musi istnieć możliwość operowania z systemem wyłącznie za pomocą klawiatury.

-Wymagania dotyczące procesu. Np. proces realizacji harmonogramowania zleceń musi być zgodny ze standardem opisanym w dokumencie XXXA/96.

-Wymagania zewnętrzne. Np. system harmonogramowania musi współpracować z bazą danych systemu komputerowego działu marketingu opisaną w dokumencie YYYB/95. Niedopuszczalne są jakiekolwiek zmiany w strukturze tej bazy.

*/

23. Omów metody specyfikacji wymagań dla systemów informatycznych.

-Język naturalny - najczęściej stosowany. Wady: niejednoznaczność powodująca różne rozumienie tego samego tekstu; elastyczność, powodująca wyrazić te same treści na wiele sposobów. Utrudnia to wykrycie powiązanych wymagań i powoduje trudności w wykryciu sprzeczności.

-Formalizm matematyczny. Stosuje się rzadko (dla specyficznych celów).

Język naturalny strukturalny. Język naturalny z ograniczonym słownictwem i składnią. Tematy i zagadnienia wyspecyfikowane w punktach i podpunktach.

-Tablice, formularze. Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych) tablic, kojarzących różne aspekty (np. tablica ustalająca zależność pomiędzy typem użytkownika i rodzajem usługi).

-Diagramy blokowe: forma graficzna pokazująca cykl przetwarzania.

-Diagramy kontekstowe: ukazują system w postaci jednego bloku oraz jego powiązania z otoczeniem, wejściem i wyjściem.

-Diagramy przypadków użycia: poglądowy sposób przedstawienia aktorów i funkcji systemu.

24.Omów przykładowy zakres treści dokumentu opisującego wymagania na system

informatyczny.

Dokument opisujący wymagania na system informatyczny ma pewien schemat:
Informacje organizacyjne:
Streszczenie (około 200 słów), Spis treści, Statut dokumentu(autorzy, firmy, podpisy),
Zmiany w stosunku do poprzedniej wersji.
Zasadnicza zawartość dokumentu:
1. Wstęp
(1.1 Cel 1.2 Zakres 1.3 Definicje akronimy i skróty 1.4 Referencje, odsyłacze do innych
dokumentów 1.5 Krótki przegląd )
2. Ogólny opis
(2.1 Walory użytkowe i przydatność projektowanego systemu 2.2 Ogólne możliwości
projektowanego systemu 2.3 Ogólne ograniczenia 2.4 Charakterystyka
użytkowników 2.5 Środowisko operacyjne 2.6 Założenia i zależności )

3. Specyficzne wymagania
( 3.1 Wymagania funkcjonalne 3.2 Wymagania niefunkcjonalne )
Dodatki

Kolejność i numeracja punktów w przedstawionym spisie treści powinna być zachowana. W przypadku gdy pewien punkt nie zawiera żadnej informacji należy wyraźnie to zasygnalizować przez umieszczenie napisu „Nie dotyczy”.
Dla każdego wymagania powinien być podany powód jego wprowadzenia: cele przedsięwzięcia, których osiągnięcie jest uwarunkowane danym wymaganiem.

25. Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych.

• Wykracza poza zakres odpowiedzialności systemu -> kontekst użycia i współpracy;

• Ujęcie w modelu pewnych elementów nie będących częścią systemu -> model jest bardziej zrozumiały;

• Abstrakcja modelowania -> podczas modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie a które w sposób sprzętowy lub ręcznie;

• Dostępne środki mogą nie pozwolić na realizację systemu w całości -> analiza może wykryć fragmenty, które mogą być szczególnie ważne;

26. Omów główne cechy modelu analitycznego i podstawowe czynności w fazie analizy systemu informatycznego.

Cechy modelu analitycznego (logicznego):

-Uproszczony opis systemu;

-Hierarchiczna dekompozycja funkcji systemu;

-Model logiczny jest opisany przy pomocy notacji zgodnej z pewną konwencją;

-Jest on zbudowany przy użyciu dobrze rozpoznanych metod i narzędzi;

-Jest on używany do wnioskowania o przyszłym oprogramowaniu;

Model oprogramowania powinien być jego uproszonym opisem, opisującym wszystkie istotne cechy oprogramowania na wysokim poziomie abstrakcji.

Model ten jednakże nie zastępuje doświadczenia i wnikliwości projektantów, lecz pomaga projektantom w zastosowaniu tych walorów.

/* Można dodatkowo dopisać:

Logiczny model oprogramowania:

-pokazuje co system musi robić;

-jest zorganizowany hierarchicznie, wg poziomów abstrakcji

-unika terminologii implementacyjnej

-pozwala na wnioskowanie „od przyczyny do skutku” i odwrotnie.

*/

Czynności w fazie analizy:

-Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu;

-Ustalenie kontekstu projektu;

-Ustalenie wymagań użytkowników;

-Ustalenie wymagań organizacyjnych

-Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd.

/* Można dodatkowo dopisać:

W zasadzie analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam nowych elementów np. w postaci systemu komputerowego. Jej celem jest rozpoznanie wszystkich tych aspektów rzeczywistości, które mogłyby mieć wpływ na postać, organizację lub wynik projektu.

*/

27. Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.

Analiza:

Głównym celem analizy jest wprowadzenie strukturalnej specyfikacji opisu projektu za pomocą narzędzi modelowania:

- diagramów przepływu danych — DFD,

- diagramów obiekt-relacja-atrybut — ERD,

- diagramów przejść stanów — STD;

Wynikiem analizy jest zbudowanie następujących modeli:

- model otoczenia,

- model zachowania systemu;

Modele są opisem formalnym systemu, niezależnym od technologii, jakiej użyje się do implementacji nowego systemu;

Na końcu etapu analizy określa się dokładniej niż w poprzednim etapie budżet projektu oraz kalkulację kosztów i zysków;

Projektowanie:

Polega na:

- wyodrębnienie tych części modelu zachowania systemu, które będą implementowane w systemie informatycznym;

- przydzielenie poszczególnych części specyfikacji do odpowiednich procesorów lub serwerów (przetwarzanie rozproszone); fragmenty DFD (te, które będą implementowane) są mapowane na zadania;

- zaprojektowanie struktury hierarchii modułów wewnątrz danego zadania;

- transformacja diagramów ERD na relacyjną bazę danych (projektowanie logiczne danych);

Implementacja:

W fazie implementacji:

- realizowane jest kodowanie i integracja modułów;

- stosuje się techniki programowania strukturalnego oraz implementacji top-down;

/*

Metodyki strukturalne - łączą statyczny opis danych oraz statyczny opis procesów.

Do tej klasy należą:

1. Metodyka Yourdona (DeMarco i Ward/Mellor);

2. Structured System Analysis and Design Methodology (SSADM);

3. Structured Analysis and Design Technique (SADT).

Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli oraz iż pomimo dojrzałości, mogą nie być adekwatne do współczesnych tendencji wytwarzania systemów informatycznych;

Przykład metodyki - CDM-Oracle-1996

• stosowana do procesów biznesowych i funkcji, które nie mogą być obsłużone za pomocą dostępnych aplikacji „z półki”;

• CDM jest zbiorem zdefiniowanych procesów tworzenia oprogramowania, które zostały określone przy założeniu, że w procesie wytwórczym stosowane są metody i narzędzia CASE;

• zakłada, że potrzeby biznesowe zostają wyraźnie zdefiniowane na samym początku cyklu projektowego oraz że ich zweryfikowanie jest możliwe podczas całego procesu wytwórczego;

CDM wyróżnia następujące procesy:

1. definicja potrzeb biznesowych (studium możliwości),

2. analiza istniejących systemów,

3. opracowanie architektury technicznej,

4. projektowanie i budowa bazy danych,

5. projektowanie i budowa modułów,

6. konwersja danych,

7. opracowanie dokumentacji technicznej,

8. testowanie,

9. szkolenie,

10. przejście na nowy system,

11. obsługa serwisowa; */

28. Omów przykłady obiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.

Analiza obiektowa

- opracowanie modelu obiektowego dziedziny zastosowania;

- rozpoznane obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem;

Projektowanie obiektowe

- opracowanie modelu obiektowego systemu oprogramowania, który będzie implementacją zidentyfikowanych wymagań;

- obiekty projektu obiektowego są związane z rozwiązaniem problemu;

Zadania w etapach fazy projektowania:

- uściślenie istniejących definicji klas, np. metod,

- dziedziczenie klas i operacji,

- szczegółowy projekt operacji wraz z przeprojektowaniem ich algorytmów,

- wprowadzenie ogólnych mechanizmów realizacji dynamiki obiektów,

- decyzje o trwałości obiektów,

- modularyzacja i ukrywanie informacji,

- optymalizacja modelu,

- dokumentacja projektu;

Programowanie obiektowe

- realizacja projektu oprogramowania za pomocą języka programowania obiektowego;

- języki obiektowe umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do definiowania klas obiektów;

/*

Analiza i Projektowanie - metody obiektowe

Wspólna zasada: zaczynamy od rozpoznania struktury obiektów. Najważniejsze jest, czym są obiekty, a nie co robią.

Wspólne kroki wszystkich metod obiektowych:

16. Identyfikacja klas i obiektów, ich atrybutów i metod

17. Ustalenie powiązań między obiektami

18. Ustalenie interfejsu każdego obiektu (protokołu)

19. Ustalenie współpracy obiektów, przepływ informacji

20. Implementacja, tworzenie prototypu.

# Przykład- Metoda Coad/Yourdon

5 głównych czynności

1. znajdowanie klas i obiektów

2. identyfikacja struktur

3. identyfikacja tematów

4. definiowania atrybutów

5. definiowania usług

model analizy obiektowej zawiera 5 warstw

1. warstwa tematów

2. warstwa klas i obiektów

3. warstwa struktury

4. warstwa atrybutów

5. warstwa usług

# Przykłąd Analiza metoda OMT (metoda Rumbaugh)

OMT - Object Modelling Technique

3 części składowe modelu, pokazujące różne jego aspekty:

Model Obiektów (OMT Object Model)

statyczny obraz struktury modelu

- klasy

- atrybuty

- operacje

- relacje między klasami i instancjami (powiązania - asocjacje,

całość - część (agregacje), gen- spec)

Model Dynamiczny (OMT Dynamic Model)

współdziałanie obiektów (powiązania wyznaczone przez komunikaty).

Tu mieszczą się różne diagramy pokazujące przepływ sterowania,

także ograniczenia i warunki na wartości atrybutów.

Model Funkcyjny (OMT Functional Model)

specyfikacja operacji jako funkcji przekształacących wejście na

wyjście, warunki poprawności (asercje).

*/

29. Co to jest system informatyczny i jakie są jego główne wyznaczniki jakości.

-System informatyczny jest złożoną konstrukcją, której stopień skomplikowania zależy od złożoności architektury;

-Wielkie systemy są zwykle podzielone na podsystemy, które oferują pewien zbiór powiązanych ze sobą interfejsów;

-Wymagane jest projektowanie architektoniczne, którego wynikiem jest opis architektury oprogramowania;

-Urzeczywistnienie pomysłów architektonicznych wymaga:

+idei (pomysł, cel),

+planów (architektura, zagospodarowanie),

+wiedzy (metody, techniki),

+zasobów (materiały, narzędzia, czas, ludzie),

+nadzoru i pielęgnacji we wszystkich
etapach życia (projekt, budowa,
użytkowanie, wycofanie);

Wyznaczniki jakości systemu informatycznego:
-zgodny z wymaganiami użytkownika
-niezawodny
-efektywny
-łatwy w konserwacji

-interoperacyjny (jeżeli nie jest autonomiczny)
-ergonomiczny

/*

System informatyczny to złożony program komputerowy lub zespół współdziałających ze sobą programów, przeznaczonych do wykonywania określonych funkcji: np. system operacyjny, system zarządzania bazami danych .
Najczęściej o systemie informatycznym mówi się wtedy, gdy do zbierania, gromadzenia, przesyłania i przetwarzania danych zastosowane są techniczne środki informatyki, a przynajmniej komputer do przetwarzania. Zestaw technicznych środków informatyki jest przeznaczony do realizacji zadań określonych przez system informacyjny .
Podsumowując - system informatyczny to określony obszar systemu informacyjnego danego obiektu, obsługiwany za pomocą technicznych środków dostępnych w informatyce.

System informatyczny - jest to zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu techniki komputerowej. Na systemy informatyczne składają się obecnie takie elementy jak:

• sprzęt - obecnie głównie komputery, oraz

• urządzenia służące do przechowywania danych

• urządzenia służące do komunikacji między sprzętowymi elementami systemu

• urządzenia służące do komunikacji między ludźmi a komputerami

• urządzenia służące do odbierania danych ze świata zewnętrznego - nie od ludzi (na przykład czujniki elektroniczne, kamery, skanery)

• urządzenia służące do wpływania systemów informatycznych na świat zewnętrzny - elementy wykonawcze (na przykład silniki sterowane komputerowo, roboty przemysłowe, podłączony do komputera ekspres do kawy, sterowniki urządzeń mechanicznych)

• urządzenia służące do przetwarzania danych nie będące komputerami

• oprogramowanie

• zasoby osobowe - ludzie

• elementy organizacyjne - czyli procedury (procedury organizacyjne - termin z zarządzania) korzystania z systemu informatycznego, instrukcje robocze itp.

• elementy informacyjne; bazy wiedzy - ontologie dziedziny/dziedzin, w których używany jest system informatyczny - na przykład podręcznik księgowania w wypadku systemu finansowo-księgowego

*/

30. Omów podstawowe diagramy statyczne w języku IBM/Rational UML.

Diagram klas,

• zastosowanie: opis struktury systemu;

• elementy: klasy, interfejsy, grupy współdziałania;

• związki: zależności, generalizacji, asocjacji, agregacji;

• najczęściej używany diagram UML;

Diagram obiektów,

zamiast klas pokazują instancje. Przydają się do wyjaśniania drobnych elementów ze skomplikowanymi relacjami, zwłaszcza rekurencyjnymi. Każdy prostokąt na diagramie obiektów odpowiada pojedynczej instancji. Nazwy instancji na diagramach UML są podkreślone. Nazwy klas lub instancji mogą zostać pominięte na diagramach obiektów, pod warunkiem, że sens diagramu pozostaje jasny.

Diagramy komponentów

• Obrazuje fizyczne i statyczne aspekty systemu;

• Przedstawia uporządkowanie komponentów i zależności między nimi;

• Przykłady komponentów:

• programy wykonywalne, biblioteki, tabele, pliki, dokumenty, bazy danych itp.

• Ściśle związany z diagramem klas, ponieważ zazwyczaj każdemu komponentowi przyporządkowane są pewne klasy, interfejsy i kooperacje;

• Składowe:

• komponenty,

• interfejsy,

• związki: zależności, uogólnienia, powiązania, realizacje;

Diagram pakietów;

to diagram służący do porządkowania struktury systemu. Stosowane, aby uprościć skomplikowane diagramy klas, klasy grupujemy w pakiety. Pakiet to zbiór logicznie powiązanych elementów UML.
Pakiety to prostokąty z małymi zakładkami na górze. Nazwa pakietu znajduje się na zakładce albo wewnątrz prostokąta. Strzałki z przerywanymi liniami to zależności. Jeden pakiet jest zależny od drugiego, jeśli zmiany w drugim pakiecie mogą wymusić zmiany w pierwszym.

Diagram wdrożenia

• Obrazują konfigurację sprzętową (węzły) z uwzględnieniem rozmieszczenia (rozproszenia) komponentów;

• Węzły dzielimy na:

• Procesory - reprezentują zasoby obliczeniowe:

• Posiadają pewną ilość pamięci i zdolność przetwarzania,

• Mogą wykonywać kod komponentu;

• Urządzenia - są interfejsem do świata zewnętrznego:

• Nie mają zdolności przetwarzania (np. monitor, drukarka);

• Wiąże się z diagramem komponentów, ponieważ zwykle każdy węzeł zawiera co najmniej jeden komponent;

• Składowe:

• węzły,

• zależności,

• powiązania;

31. Omów podstawowe diagramy dynamiczne w języku IBM/Rational UML.

Diagram przypadków użycia,

• stosowany do opisu statycznej struktury usług systemu;

• definiuje granice systemu, określa jego kontekst;

• pokazuje system z zewnątrz poprzez użytkowników i funkcje im udostępniane;

• elementami diagramu są:

• przypadki użycia:

• reprezentują zamkniętą i kompletną funkcjonalność dostępną z zewnątrz systemu;

• są inicjowane z zewnątrz i dostarczają wyniki na zewnątrz;

• aktorzy:

• reprezentuje punkt widzenia na system;

• inicjuje wykonanie funkcji systemu;

• jest odbiorcą wyników działania systemu;

Diagramy stanów

• opisuje stany z życia obiektu, jako reakcje na zewnętrzne zdarzenia i komunikaty;

• akcja - elementarna (niepodzielna) czynność, np. wywołanie operacji, utworzenie lub skasowanie obiektu, obliczenie wartości wyrażenia;

• aktywność - nieelementarna czynność;

• elementami są: stany, tranzycje, zdarzenia, aktywności, łączniki pomiędzy stanami;

Diagramy czynności/aktywności

• Uogólniona wersja diagramu stanów;

• Obrazuje przepływ sterowania od czynności do czynności;

• Czynności odpowiadają stanom wyróżnialnym w trakcie przetwarzania, a nie stanom obiektów;

• Czynność może być interpretowana jako:

• zadanie do wykonania przez człowieka lub komputer,

• odpowiedzialność/operacja/metoda klasy;

• Składowe:

• stany akcji,

• stany czynności,

• przejścia,

• obiekty;

Diagramy sekwencji

• prezentuje chronologiczną sekwencję interakcji obiektów;

• odwzorowuje dynamikę obiektów uczestniczących w interakcjach oraz kolejność wymienianych komunikatów;

• nie przedstawia związków pomiędzy obiektami;

• może opisywać wszystkie możliwe scenariusze lub tylko jeden wybrany;

Diagramy współpracy (kolaboracji)

-Kontekst współpracy stanowi statyczna struktura obiektów w niej uczestniczących (włączając związki, atrybuty i operacje).

-Sekwencja komunikatów wymienianych pomiędzy obiektami dla realizacji konkretnego zadania.

-Współpraca może dotyczyć:

+skutków powodowanych przez dany fragment programu w środowisku zewnętrznym

+wewnętrznej implementacji obiektów i ich zachowania

32. Omów podstawowe diagramy w metodyce Oracle CASE Method.

Diagram zależności
Diagram zależnosci to narzedzie do przedstawiania złożonych zależnosci miedzy przyczynami i skutkami. Diagramy zależności pozwalają odnaleźć często trudną do wykrycia zależnosc problemu od pierwotnej przyczyny. Pomagaja zilustrowac łancuchy zaleznosci i wzajemnych zaleznosci, przez co ułatwiaja podjecie działania w odpowiednim miejscu. Pomagaja równiez w identyfikacji efektów ubocznych tych działan.

Diagram przepływu danych - (DFD - Data Flow Diagram)

jest graficzną prezentacją przepływu danych w procesie. Na proces składają się następujące elementy:
-Funkcje — (procesy) realizują określone cele; jeśli funkcji nie można rozbić na pod-funkcje, wówczas nosi ona nazwę elementarnej.
-Magazyny danych — trwałe lub tymczasowe składnice danych, które są argumentami dla funkcji.
-Terminatory — obiekty, które nie są częścią systemu, ale stanowią odbiorców bądź źródła danych lub argumentów funkcji.
Przepływy — elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków, pakietów..).
Diagram przepływu danych obrazuje za pomocą przepływów kierunek przepływu danych pomiędzy funkcjami, magazynami i obiektami zewnętrznymi

/*

Modelowanie przepływu danych (ang. Dataflow Diagrams):

• ma na celu zobrazowanie procesów zachodzących w organizacji, wymiany informacji między nimi oraz miejsc wprowadzania i wyprowadzania danych;

Modelowanie związków encji ma na celu:

• dostarczenie dokładnego modelu potrzeb informacyjnych przedsiębiorstwa, który stanowiłby podstawę do konstruowania nowych lub ulepszonych systemów;

• dostarczanie modelu niezależnego od sposobu przechowywania danych i metod dostępu do nich, umożliwiającego podejmowanie decyzji, dotyczących metod implementacji oraz współdziałania z istniejącymi systemami;

*/

33. Porównaj następujące podejścia do analizy i projektowania systemów informatycznych: 1) podejście: encja-związek, 2) podejście obiektowe.

Model encja - związek reprezentuje dane i związki pomiędzy nimi. Podejście to pozwala na odwzorowanie w systemie danych i powiązań pomiędzy nimi. Pozwala na analizę rodzajów danych, ich przepływu w procesach przetwarzania, oraz na odpowiednie zaprojektowanie przechowywania danych. Jest to podejście dobre dla systemów, których głównym zadaniem jest przetwarzanie danych i ich przedstawianie, a także przechowywanie. Korzystne dla systemów bazodanowych.

Model obiektowy skupia się bardziej nad tym jak dane są przetwarzane, jaki jest do nich dostęp, jaka jest wymiana danych pomiędzy obiektami. W modelu obiektowym na drugi plan przesunięte jest jak dane są przechowywane, a także jak są reprezentowane. Znacznie istotniejsze jest kto ma do nich dostęp, jakie obiekty biorą udział w ich przetwarzaniu i jakie metody operują na danych. Podejście to jest korzystne dla wszystkich systemów, gdzie konieczna jest odpowiednia kontrola dostępu do danych, poprawności danych, oraz kontrola sposobu przetwarzania.

/*

1)Metodyki strukturalne:

• wadą metodyk strukturalnych są trudności w zintegrowaniu modeli;

• metodyki strukturalne są dojrzałe, lecz mogą nie być adekwatne do współczesnych tendencji wytwarzania systemów informatycznych;

2)Metodyki obiektowe:

• młode i szybko zmieniające się;

• wymagają dużego nakładu pracy;

• wprowadzają narzuty implementacyjne;

• dobre dla systemów czasu rzeczywistego;

-Metody obiektowe:

• są wygodnym narzędziem analizy złożonych systemów, w szczególności systemów o dużej stronie pasywności i złożonej funkcjonalności

• ukrywają dane (hermetyzacja)

• wykorzystują gotowe elementy

• pozwalają na szybkie prototypowanie i przyrostowy rozwój

• programowanie oparte na zdarzeniach

*/

34. Omów zagadnienie audytu w procesie wytwórczym systemów informatycznych.

Audytem nazywany jest niezależny przegląd i ocenę jakości oprogramowania, która zapewnia zgodność z wymaganiami na oprogramowanie, a także ze specyfikacją, generalnymi założeniami, standardami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi wymaganiami.

Aby zapewnić obiektywność, audyt powinien być przeprowadzony przez osoby niezależne od zespołu projektowego.

Audyt powinien być przeprowadzany przez odpowiednią organizację audytu (która aktualnie formuje się w Polsce, Polskie Stowarzyszenie Audytu) lub przez osoby posiadające uprawnienia/licencję audytorów.

Reguły i zasady audytu są określone w normie:

ANSI/IEEE Std 1028-1988 „IEEE Standard for Reviews and Audits”.

Celem audytu projektu informatycznego jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych informacji o stanie całego projektu

Jest to osiągane przez zbieranie dowodów, że projekt:

-posiada możliwości (zasoby, kompetencje, metody, standardy) by osiągnąć sukces,

-optymalnie wykorzystuje te możliwości,

-rzeczywiście osiąga założone cele (cząstkowe).

Zebrane informacje służą jako podstawa do podejmowania strategicznych decyzji w projekcie

Przedmioty

-procesy projektu informatycznego - ma to na celu sprawdzenie czy wykonywane prace oraz sposób ich wykonywania są prawidłowe

-produkty (cząstkowe) projektu informatycznego - ma to na celu sprawdzenie czy rezultaty poszczególnych prac odpowiadają zakładanym wymaganiom

Perspektywy

-technologia - ma to na celu sprawdzenie czy użyte techniki oraz opracowane rozwiązania są prawidłowe i prawidłowo stosowane

-zarządzanie - ma to na celu sprawdzenie czy sposób zarządzania projektem umożliwia jego sukces

35. Omów zagadnienie inspekcji oprogramowania w procesie wytwórczym systemów informatycznych.

Inspekcja to formalna technika oceny, w której wymagania na oprogramowanie, projekt lub kod są szczegółowo badane przez osobę lub grupę osób nie będących autorami, w celu identyfikacji błędów, naruszenia standardów i innych problemów [IEEE Std. 729-1983]

-Technika o najlepszej skuteczności (od 50% do 80%; średnia 60%; dla testowania średnia 30%, max 50%)

-Stosowane dla „elitarnych” systemów

-Dlaczego nie są powszechne?

• trudne w sprzedaży: nie potrzeba narzędzi, potrzeba planowania i kompetentnych ludzi

• analiza kosztów i zysków nie jest prosta

-Cechy inspekcji:

• Sesje są zaplanowane i przygotowane

• Błędy i problemy są notowane

• Wykonywana przez techników dla techników (bez udziału kierownictwa)

• Dane nie są wykorzystywane do oceny pracowników

• Zasoby na inspekcje są gwarantowane

• Błędy są wykorzystywane w poprawie procesu programowego (prewencja)

• Proces inspekcji jest mierzony

• Proces inspekcji jest poprawiany

36. Omów rodzaje testów oprogramowania w odniesieniu do cyklu życia systemu informatycznego.

Testy można klasyfikować z różnych punktów widzenia:

-Wykrywanie błędów, czyli testy, których głównym celem jest wykrycie jak największej liczby błędów w programie

-Testy statystyczne, których celem jest wykrycie przyczyn najczęstszych błędnych wykonań oraz ocena niezawodności systemu.

Z punktu widzenia techniki wykonywania testów można je podzielić na:

-Testy dynamiczne, które polegają na wykonywaniu (fragmentów) programu albo modeli symulacyjnych i porównywaniu uzyskanych wyników z wynikami poprawnymi.

-Testy statyczne, oparte na analizie kodu albo modeli analitycznych/projektowych

37. Omów uwarunkowania prawne i inżynierskie procesu testów akceptacyjnych systemu informatycznego.

W rozporządzeniu zdefiniowano podstawowe definicje pojęć i sposób przeprowadzania testów oprogramowania interfejsowego umożliwiającego kontakt z instytucjami publicznymi w Polsce. Zostały zdefiniowane również formularze wykorzystywane do opisu poszczególnych przypadków testowych i scenariuszy testowych.

38. Omów istotę testowania metodą black box i white box.
White box
Testowanie n/z białej skrzynki pozwala sprawdzić wewnętrzną logikę programów prześledzić wszystkie ścieżki przebiegu sterowania programu wykonanie programu krok po kroku. Dane testowe powinny być dobrane tak, aby każda ścieżka programiu była co najmniej raz przetestowana.

-Tak określa się sprawdzanie wewnętrznej logiki oprogramowania. (Lepszym terminem byłoby „testowanie n/z szklanej skrzynki”.)

-Testowanie n/z białej skrzynki pozwala sprawdzić wewnętrzną logikę programów poprzez odpowiedni dobór danych wejściowych, dzięki czemu można prześledzić wszystkie ścieżki przebiegu sterowania programu.

-Tradycyjnie programiści wstawiają kod diagnostyczny do programu aby śledzić wewnętrzne przetwarzanie. Debuggery pozwalają programistom obserwować wykonanie programu krok po kroku.

-Często niezbędne staje się wcześniejsze przygotowanie danych testowych lub specjalnych programów usprawniających testowanie (np. programu wywołującego testowaną procedurę z różnymi parametrami).

-Dane testowe powinny być dobrane w taki sposób, aby każda ścieżka w programie była co najmniej raz przetestowana.

-Ograniczeniem testowania na zasadzie białej skrzynki jest niemożliwość pokazania brakujących funkcji w programie. Wadę tę usuwa testowanie n/z czarnej skrzynki.

Black box

Tak określa się sprawdzanie funkcji oprogramowania bez zaglądania do środka programu. wnętrze jest niewidoczne. przyczyna-skutek.

-Testowanie n/z czarnej skrzynki powinno obejmować cały zakres danych wejściowych.

-Testujący powinni podzielić dane wejściowe w „klasy równoważności”, co do których istnieje duże przypuszczenie, że będą produkować te same błędy. Np. jeżeli testujemy wartość „Malinowski”, to prawdopodobnie w tej samej klasie równoważności jest wartość „Kowalski”. Celem jest uniknięcie efektu „eksplozji danych testowych”.

-„Klasy równoważności” mogą być również zależne od wyników zwracanych przez testowane funkcje. Np. jeżeli wejściem jest wiek pracownika i istnieje funkcja zwracająca wartości „młodociany”, „normalny” „wiek emerytalny”, wówczas implikuje to odpowiednie klasy równoważności dla danych wejściowych.

-Wiele wejść dla danych (wiele parametrów funkcji) może wymagać zastosowania pewnych systematycznych metod określania ich kombinacji, np. tablic decyzyjnych lub grafów przyczyna-skutek.

39. Omów zagadnienie architektury systemów informatycznych.

Architektura systemu informatycznego jest modelem systemu uwzględniającym decyzje analityka/projektanta dotyczące podziału systemu na elementy składowe, wzajemne relacje pomiędzy tymi elementami, interakcje pomiędzy nimi, jak również ich przeznaczenie.Często dla tego samego systemu opisuje się różne architektury stanowiące różne i komplementarne punkty jego widzenia, np.: architektura przetwarzania danych, architektura bezpieczeństwa systemu, architektura sprzętowo-systemowa, architektura interoperacyjności, architektura warstw systemu itd.

40. Omów zagadnienie projektowania architektonicznego systemów informatycznych.

-Proces projektowania architektonicznego polega na ustaleniu podstawowego zrębu systemu;

-Podział architektoniczny jest niezbędny do strukturalizacji i porządkowania specyfikacji;

-Model architektoniczny jest zwykle punktem początkowym do specyfikowania rozmaitych części systemu;

-Obejmuje identyfikację najważniejszych komponentów systemu i komunikacji między nimi;

-Architektury są charakterystyczne dla różnych dziedzin;

-Składowe procesy projektowania architektonicznego:

+Strukturalizacja systemu:

• System jest dzielony na kilka podstawowych podsystemów, przy czym podsystem jest niezależną jednostką oprogramowania;

• Identyfikuje się tu komunikację między podsystemami;

+Modelowanie sterowania:

• Określa się ogólny model związków sterowania między częściami systemu;

+Podział na moduły:

• Każdy zidentyfikowany podsystem jest dzielony na moduły;

• Architekt musi wskazać typy modułów i ich połączenia;

-Wyniki projektowania architektonicznego:

+Dokumentacja zawierająca modele graficzne i opisy tekstowe;

+Modele przedstawiają rozmaite perspektywy architektury;

-Modele architektoniczne:

+Statyczny model strukturalny - komponenty lub podsystemy, które można zbudować jako niezależne jednostki;

+Model dynamiczny procesu - przedstawia się podział systemu na procesy realizujące się podczas pracy systemu;

+Model interfejsów - definiuje się usługi oferowane przez każdy podsystem za pośrednictwem jego interfejsu publicznego;

+Model związków - związki, takie jak przepływ danych między podsystemami;

-Wybrane wyniki projektowania architektonicznego:

+Podsystem:

• jest systemem autonomicznym;

• jego usługi nie zależą od usług oferowanych przez inne podsystemy;

• składa się z modułów i ma interfejsy do komunikacji z innymi podsystemami;

+Moduł:

• jest komponentem systemu - nie jest traktowany jako niezależny system;

• oferuje usługi innym modułom i korzysta z usług innych modułów;

• zazwyczaj zbudowany z kilku innych, prostszych komponentów:

• prezentowany jako:

-Model obiektowy - system jest dzielony na zbiór porozumiewających się obiektów;

-Model przepływu danych (strukturalny) - system jest dzielony na moduły funkcjonalne, które pobierają dane wejściowe i przetwarzają je na dane wyjściowe;

41. Omów istotę koncepcji wzorców projektowych w projektowaniu systemów informatycznych.

-Sprawdzone szkieletowe rozwiązania:

+Wzorce dostarczają sprawdzonych rozwiązań dla powtarzających się problemów;

+Możliwe do zastosowania w wielu rzeczywistych kontekstach;

+Wpływają na sposób modelowania;

+Zapobiegają „wymyślaniu koła od nowa”;

-Usprawniają komunikację:

+Ułatwiają dyskusję nad problemem i znalezienie właściwego rozwiązania;

-Ułatwiają tworzenie dokumentacji:

+Pozwalają na dużo szybsze zdefiniowanie i opisanie systemu;

+Dokumentacja może zawierać odwołania do katalogów wzorców i książkach o wzorcach w celu uzupełnienia opisu systemu;

Wzorce projektowe zwiększają:

-elastyczność,

-wielokrotne wykorzystanie

-oraz czytelność projektu;

42. Omów wzorzec projektowy …… (nazwa jednego z wzorców z wykładu).

Wzorce konstrukcyjne:

-Służą do pozyskiwania obiektów;

-Opisują szczegółowo, jak obiekt może zostać stworzony,

-Czynią kod niezależnym od typów tworzonych obiektów;

-Wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych;

-Przykłady:

+Singleton,

{

-Zapewnia powołanie tylko jednej instancji obiektu w całej aplikacji i kontrolowany dostęp;

-Obiekt powołany wg tego wzorca jest globalnym punktem dostępu do instancji danej klasy ;

-Wzorzec może być zmodyfikowany do tworzenia określonej liczby instancji danej klasy (>1);

-Funkcje wzorca:

+utworzenie obiektu,

+inicjalizacja obiektu,

+punkt dostępu,

+modyfikacja obiektu;

-Prostszym rozwiązaniem jest: globalnie dostępna zmienna statyczną przechowująca referencję do obiektu;

}

+Fabryka,

{

-Fabryka nowych obiektów w zdefiniowanych klasach wzorcowych;

-Wszystkie klasy wzorcowe mają metody o tej samej nazwie, ale o innych realizacjach;

-Zaleta - możliwość modyfikowania klas wzorcowych (tworzących) w jednym miejscu projektu;

-Popularne wersje Fabryki:

+Metoda Fabrykująca,

+Fabryka Abstrakcji,

+Budowniczy,

+Prototyp;

}

+Metoda Fabrykująca - tworzenie obiektów w klasach pochodnych;

+Fabryka Abstrakcyjna - Tworzenie rodzin powiązanych ze sobą obiektów bez konieczności posługiwania się ich konkretnymi klasami;

+Budowniczy - Obiekt tworzony jest wieloetapowo, na podstawie dostarczonych argumentów;

+Prototyp; - tworzenie obiektów przez klonowanie prototypu;

• Singleton - pojedyncza instancja obiektu;

• Metoda Fabrykująca - tworzenie obiektów w klasach pochodnych;

• Fabryka Abstrakcyjna - tworzenie rodzin obiektów bez wydzielonych klas fabryk;

• Budowniczy - ukrycie szczegółów tworzenia za interfejsem zarządcy;

• Prototyp - tworzenie kopii na podstawie w pełni zainicjalizowanej instancji;

Wzorce strukturalne:

-Stosowany do łączenia obiektów w większe struktury;

-Zastosowanie np. w implementacji złożonego interfejsu użytkownika;

-Przykłady:

+Fasada,

{

-Ujednolicony i prostszy interfejs do struktury złożonych podsystemów;

-Separacja klienta od złożonych podsystemów;

-Wybór odpowiedniej struktury dla żądania klienta;

-Możliwości zmian w ukrywanych podsystemach;

-Przykłady:

+w bibliotekach Javy: klasy pakietu java.sql (Statement, ResultSet);

+wejście usług w Service Oriented Architecture (SOA);

}

+Adapter

{

-Konwertuje (dopasowuje) interfejsy jednej klasy do interfejsu innej klasy;

-Umożliwia klasom o różnych interfejsach współpracę w jednym programie;

-Niewielka elastyczność - adaptacji podlega tylko jedna klasa (Adaptee), bez jej podklas;

-Zmiana zachowania klasy Adapter może zmienić zachowanie klasy dostosowywanej Adaptee;

-Dwa sposoby realizacji:

+dziedziczenie,

+kompozycja;

}

+Most

{

-podobny do wzorca Adapter;

-jest to także obiekt konwertujący jeden rodzaj interfejsu na inny;

-różnice:

+przeznaczeniem Adaptera jest dostosowanie interfejsu klasy istniejącej do innej klasy;

+Most odseparowuje interfejs od jego implementacji, co daje możliwość zmiany implementacji bez modyfikacji kodu wywołania w programie;

+implementacja będzie wybrana lub zmieniona w trakcie wykonania;

}

+Kompozyt

{

-System złożony z podsystemów o strukturze drzewiastej ( reprezentacja związku „całość-część”);

-Wspólny interfejs dla klas węzłów i liści - ujednolicone widzenie kontenerów i obiektów składowanych;

-Łatwo rozszerzalny o nowe podsystemy implementujące (określony interfejs);

-Przykłady:

+Przykład w bibliotekach Javy: kontenery (Panel, JComponent, …);

}

+Dekorator

{

-Podstawowe zachowanie klasy musi być czasami rozszerzone o dodatkowe operacje lub cechy;

-Funkcjonalność uzupełniająca umieszczana jest w osobnych klasach Decorator;

-Stosowany zamiast dziedziczenia, które mogłoby stworzyć zbyt wiele mało elastycznych klas;

-Dekorator agreguje w sobie dekorowane obiekty i dziedziczy z tej samej nadklasy, co te obiekty;

-Dynamiczna zmiana klasy nadrzędnej;

+Utworzenie klasy poprzez dodanie nowego zachowania;

+Przekazanie klasy rozszerzonej do konstruktora Dekoratora;

-Przykład:

+w bibliotekach Javy: klasy strumieni (BufferedInputStream, …);

}

+Waga Piórkowa

{

-Zastąpienie wielu obiektów jednym współdzielonym z opisem stanu zubożonym w porównaniu z pierwotnym obiektem;

-Zamiast przechowywać wewnątrz atrybuty stanu, obiekty dostają wartości z zewnątrz jako parametry wywołania metod;

-Zalety:

+Ograniczenie liczby tworzonych instancji obiektów;

+Przesunięcie części danych z obiektu do przekazywanych parametrów metod;

-Wady:

+Zwiększony koszt wywoływania metod obiektów;

+Uzyskuje się przyspieszenie programów operujących na wielu niezbyt złożonych obiektach;

-Przykład: zbiory obiektów „znaków literowych”;

}

+Proxy

{

-Punkt kontroli dostępu do rzeczywistego obiektu -ogranicza (ukrywa) dostęp do obiektu (podobnie jak Dekorator);

-Odsunięcie w czasie tworzenia rzeczywistego obiektu;

-Działania wykonywane są na Pośredniku, który działa na właściwej klasie o tym samym interfejsie;

-Stosowany, gdy obiekt docelowy jest złożony i np. potrzebuje wiele czasu na wczytanie (patrz sieć);

-Przykład:

+W bibliotekach Javy: ziarna "enterprise" (Enterprise JavaBeans) i komunikacja z bazą danych;

}

• Fasada - prosty interfejs złożonego (pod-)systemu;

• Adapter - dostosowanie interfejsów różnych klas;

• Most - odseparowanie interfejsu od implementacji;

• Kompozyt - elementy struktury drzewiastej;

• Dekorator - dynamiczne rozszerzenie obiektu;

• Waga Piórkowa - lekkie instancje obiektów;

• Proxy - aktualna reprezentacja obiektu docelowego;

Wzorce operacyjne (czynnościowe)

-W celu definiowania komunikacji pomiędzy obiektami;

-Pomagają kontrolować przepływ danych w złożonym programie;

-Przykłady:

+Iterator

{

-Upraszcza przemieszczanie po kolekcji danych (np. liście), z wykorzystaniem standardowego interfejsu;

-Nie wymaga znajomości wewnętrznej struktury kolekcji danych;

-Umożliwia równoczesne przeglądanie kilku kolekcji;

-Przykład:

+W bibliotekach Javy: iterator w kolekcjach z pakietu java.util;

}

+Łańcuch Odpowiedzialności

{

-Zestaw klas obsługuje żądanie w określonej kolejności;

-Żądanie jest przekazywane pomiędzy klasami w określonym łańcuchu;

-Czasami ostatni obiekt łańcucha obsługuje wszystkie żądania;

-Przykład:

+Realizacja w Javie: Frame -> Panel -> Component;

}

+Stan

{

-Tworzy obiekty pochodne z bazowej klasy State dla każdego stanu, w którym może znaleźć się aplikacja;

-Przełączanie pomiędzy obiektami stanu, gdy zmieni się stan aplikacji;

-Wraz ze zmianą stanu i tym samym obiektu może zmienić się zachowanie obiektu (inne implementacje metod);

-Eliminuje złożone instrukcje warunkowe (np. switch) w metodach obiektu;

-Wada: powstaje wiele małych klas;

-Zaleta: upraszcza program;

}

+Mediator

{

-Mediatora stanowi „zarządcę obiektów”;

-Wprowadza luźniejsze powiązania pomiędzy klasami - obiekty znają Mediatora a nie koniecznie inne obiekty;

-Zmiany stanu obiektów są za jego pośrednictwem (odpowiednich metod) propagowane do zainteresowanych obiektów;

-Często jest specjalizowany dla jednego projektu;

}

+Obserwator

{

-Ciągłe odpytywanie o stan obiektu prowadzi do znacznego spadku wydajności aplikacji;

-Obserwator (Observer) przechowuje informację o stanie lub reaguje na zmianę stanu innych obiektów;

-Luźne powiązanie z określonym obiektem;

-Może być kilku obserwatorów jednego obiektu: relacja obiektów 1:N;

-Wybrany obiekt powiadamia zainteresowanych o zmianie swojego stanu;

-Przykłady użycia:

+obsługa zdarzeń w okienkach,

+synchronizacja modelu z widokiem;

}

+Strategia;

{

-Potrzeba kilku wariantów algorytmu;

-Wybór określonego wariantu poprzez powołanie obiektu pochodnego do zdefiniowanego interfejsu bazowego lub klasy abstrakcyjnej;

-Każda wersja algorytmu jest implementowana w osobnej klasie;

-Zalety:

+algorytm może używać danych, których klient nie zna;

+hermetyzacja algorytmów w oddzielnych klasach pozwala na ich modyfikację niezależnie od kontekstu;

+to rozwiązanie zastępuje instrukcje wyboru lub warunkowe;

}

• Iterator - sekwencyjny dostęp do elementów kolekcji;

• Łańcuch Odpowiedzialności - sposób przekazywania wywołań w łańcuchu obiektów;

• Stan - zmiana zachowania (metod) ze zmianą stanu;

• Mediator - pośredniczy w komunikacji obiektów;

• Obserwator - rejestrowanie i informowanie o zmianach;

• Strategia - enkapsulacja algorytmu w klasie;

43. Omów model niezawodności oprogramowania według Jelińskiego-Morandy (1972).

-Wykrywanie błędów jest niezależne;

-Usuwanie wykrytych błędów nie generuje nowych;

-Intensywność wykrywania błędów - proporcjonalna do liczby błędów pozostających w oprogramowaniu

44. Omów zjawisko propagacji kosztów błędu oprogramowania i podaj przykładowe szacunki kosztów.

Koszt: Etap wykrycia:

1-2 wymagania - analiza

5 Analiza - projekt

10 Implementacja

20 Testowanie jednostkowe

50 Testy akceptacyjne

200 Pielęgnacja po wdrożeniu

45. Omów źródła kosztów nieprawidłowości oprogramowania.

Koszty oprogramowania złej jakości (model ISO 9004-1:1994):

• 1. Koszty jakości:

• koszty błędów (traktowane jako straty),

• koszty oceny (traktowane jako nakłady),

• koszty zapobiegania (traktowane jako nakłady).

• 2. Koszty procesu:

• koszty niezgodności (traktowane jako straty),

• koszty zgodności (traktowane jako nakłady).

• 3. Straty jakości (skutki odchyleń od wymagań jakościowych)

Wg Roger'a Pressman'a (1997):

• Testowanie: ~ 30 % - 40 % całkowitej pracochłonności;

• Testowanie systemów krytycznych: 70% - 80% całkowitej pracochłonności (!);

46. Co to jest testowanie, weryfikacja i walidacja oprogramowania? Podaj przykłady.

Testowanie oprogramowania proces związany z wytwarzaniem oprogramowania. Jest jednym z procesów kontroli jakości oprogramowania. Testowanie oprogramowania jest jednym z kluczowych etapów procesu zapewnienia jego jakości. Celem testowania oprogramowania jest sprawdzanie jak dobry jest docelowy produkt oraz sprawdzenie czy oprogramowanie spełni swoje zadanie.

Weryfikacja (verification) - testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań.

Walidacja (atestowanie) (validation) - ocena systemu lub komponentu podczas lub na końcu procesu jego rozwoju na zgodności z wyspecyfikowanymi wymaganiami. Atestowanie jest więc weryfikacją końcową.

47. Omów istotę i przykłady metod prognostycznego badania jakości oprogramowania.

Badanie prognostyczne - nie ma kodu źródłowego

„Zanim powstanie implementacja oprogramowania, jego przyszłe działanie jest badane na podstawie założeń analitycznych/ projektowych [Bliźniuk, 2000]”

Główne zalety podejścia prognostycznego:

• Zwiększenie prawdopodobieństwa uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji błędów,

• Stosunkowo niskie koszty testowania,

• Możliwość przebadania wielu różnych projektów oprogramowania w celu wyboru najlepszego do implementacji.

Wady podejścia prognostycznego:

• Bazowanie na modelu oprogramowania, co może zmniejszyc dokładność badania (potencjalna rozbieżność z właściwościami implemetacyjnymi).

Bazują na:

• Metodach specyfikacji formalnej programów (VDM, VDM+, Z, CSP) [Jones 1983, 1986, Hoare 1978]

• Badaniu logiki sterowania programów (logika algorytmiczna) [Pnueli 1991]

• Metrykach projaktu oprogramowania [Bliźniuk 2000]

• Probabilistycznych metrykach dynamiki programów [Bliźniuk, 2000]

• Modelach grafowych, sieciowych i symulacyjnych oprogramowania [Bliźniuk, 2000],

• Sieciach Petriego [Petri - lata 60-te]

• Metodach symulacji komputerowej [Nowicki 1994, Bliźniuk, 2000]

Dwa komplementarne podejścia:

1. badanie właściwości statycznych

2. badanie właściwości dynamicznych

48. Omów istotę i przykłady metod diagnostycznego badania jakości oprogramowania.

Badanie diagnostyczne - istnieje kod źródłowy

Analiza dynamiczna:

• eksperymentowanie z działającym kodem programu;

Analiza statyczna:

• praca z kodem źródłowym w celu:

• rozpoznania funkcjonalności testowanego kodu;

• zaprojektowania odpowiednich testów;

Testowanie wykrywa anomalie [J. Górski]:

• Defekt

• nieprawidłowe działanie człowieka w procesie wytwarzania,
  np. złe sformułowanie wymagań, zła decyzja projektowa, pomyłka w implementacji, …;

• Błąd

• każde zdarzenie, w wyniku którego kod produkuje nieoczekiwany rezultat;

• Awaria

• stan, w którym program nie jest zdolny wykonać prawidłowo co najmniej jednej ze swoich funkcji;

49. Wymień i omów składowe jakości oprogramowania na drugim poziomie drzewa jakości.

//nic innego w wykładach nie było (* - dotyczy programów współbieżnych)

POPRAWNOŚĆ

Bezpieczeństwo (statyczne)*

Żywotność

Reaktywność

Brak zakleszczeń*

Brak zagłodzeń*

Brak blokad*

Czytelność

Zwięzłość

Jednoznaczność

Dostępność

ADEKWATNOŚĆ

Kompletność

Racjonalność funkcjonalna

Racjonalność komunikacyjna

Zwartość funkcjonalna

Zwartość komunikacyjna

NIEZAWODNOŚĆ

Nieuszkadzalność

Obsługiwalność

Odporność

Odnawialność

Niezmienność zachowań

Utrzymywalność

Testowalność

Przechowywalność

ZŁOŻONOŚĆ OPROGRAMOWANIA

Funkcjonalna

Komunikacyjna

W strukturze procesów współbieżnych*

W strukturze zadań*

W strukturze modułów programowych

W strukturze aktywnych komponentów

Struktury modułowej

Struktury zadaniowej*

Struktury wewnętrznej tekstu źródłowego

ZŁOŻONOŚĆ OBLICZENIOWA ALGORYTMÓW

Złożoność pamięciowa (zasobowa)

Złożoność czasowa

PIELĘGNACYJNOŚĆ

Wdrażalność

Progresywność

Modyfikowalność

Przenośność

Naprawialność

50. Omów główne klasy błędów w systemach informatycznych

Klasa błędu: Typowy, możliwy błąd:

Funkcjonalny Zła lub brakująca funkcja

Systemowy Błędnie użyte interfejsy, złe zarządzanie zasobami, zły przepływ sterowania

Przetwarzania Niewłaściwe przetwarzanie danych w module

Danych Błędna specyfikacja, projekt, rozmieszczenie lub inicjacja danych

Kodowania Niewłaściwe użycie instrukcji języka programowania

Dokumentacyjny Niepełna lub błędna treść dokumentacji

Inny Przyczyny nieznane

51. Omów czynności procesu testowania oprogramowania.

1. Opracuj przypadki testowe

2. Przygotuj dane testowe

3. Uruchom program na danych testowych

4. Porównaj wyniki z przypadkami testowymi

Wynikiem jest „Raport z testowania”

52. Co to jest przypadek testowy, scenariusz testów? Podaj przykłady.

Przypadek testowy (ang. test case) - specyfikacja:

• stan początkowy, czyli stan testowanego systemu (lub jego fragmentu) przed testem,

• dane wejściowe,

• warunki testu,

• dane wyjściowe (oczekiwane wyniki);

Jakość przypadku testowego :

• prawdopodobieństwo znalezienia jeszcze nie wykrytego błędu;

Test zakończony powodzeniem:

• WYKRYWA dotychczas nie wykryty błąd;

[G. Myers, The Art. Of Software Testing, 1979]

53. Co to jest macierz przykrycia testów akceptacyjnych? Podaj przykłady.

Funkcjonalności (1…m) testowane są przypadkami testowymi (1…n), przy czym:

-każda funkcjonalność musi być objęta, co najmniej jednym przypadkiem testowym

-przypadków testowych ma być nie więcej niż potrzeba

54. Omów podstawowe schematy testów integracyjnych. Podaj przykłady.

Skokowe - grupują wybrane (lub wszystkie) jednostki w celu ich równoczesnego przetestowania

Przyrostowe - zakładają dołączenie do tworzonej całości za każdym razem tylko jednej uprzednio przetestowanej jednostki:

-zstępujące (odgórne) - integruje się i testuje się komponenty wysokiego poziomu przed ukończeniem ich projektu i implementacji;

-wstępujące (oddolne) - testuje się i integruje komponenty niskiego poziomu przed ukończeniem budowy komponentów wyższego poziomu

Testowanie interfejsu jest wykonywane po zintegrowaniu modułów lub podsystemów w większe systemy.

Każdy moduł i podsystem ma zdefiniowany interfejs, który jest wywoływany przez inne komponenty programu, np.:

• Interfejsy parametryczne,

• Interfejs w pamięci dzielonej,

• Interfejsy proceduralne,

• Interfejsy z przekazywaniem komunikatów;

Celem testowania interfejsu jest wykrycie usterek, które pojawiły się w systemie z powodu błędów w interfejsach lub nieprawdziwych założeniach o interfejsach.

55. Jaka jest istota konstrukcyjnych wzorców projektowych? Przedstaw przykład wzorca konstrukcyjnego.

• Służą do pozyskiwania obiektów;

• Opisują szczegółowo, jak obiekt może zostać stworzony,

• Czynią kod niezależnym od typów tworzonych obiektów;

• Wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych;

Przykłady:

-Singelton-

-Zapewnia powołanie tylko jednej instancji obiektu w całej aplikacji i kontrolowany dostęp;

-Obiekt powołany wg tego wzorca jest globalnym punktem dostępu do instancji danej klasy ;

-Wzorzec może być zmodyfikowany do tworzenia określonej liczby instancji danej klasy (>1);

-Funkcje wzorca: utworzenie obiektu, inicjalizacja obiektu, punkt dostępu, modyfikacja obiektu;

-Prostszym rozwiązaniem jest: globalnie dostępna zmienna statyczną przechowująca referencję do obiektu;

-metoda fabrykująca;

Fabryka nie może przewidzieć, jakie obiekty i w jaki sposób tworzyć;

Klient zna tylko interfejs klasy abstrakcyjnej;

Informacje o sposobie i odpowiedzialność za tworzenie obiektu znajdują się w implementacjach „metody tworzącej” klas pochodnych;

Można tworzyć domyślny produkt, ale też dać użytkownikowi możliwość podstawienia swojej wyspecjalizowanej wersji;

-fabryka abstrakcyjna ;

-fabryka;

-Fabryka nowych obiektów w zdefiniowanych klasach wzorcowych;

Wszystkie klasy wzorcowe mają metody o tej samej nazwie, ale o innych realizacjach;

Zaleta - możliwość modyfikowania klas wzorcowych (tworzących) w jednym miejscu projektu;

Popularne wersje Fabryki: Metoda Fabrykująca, Fabryka Abstrakcji, Budowniczy, Prototyp;

-budowniczy;

-prototyp.

Podsumowanie:

Singleton - pojedyncza instancja obiektu;

Metoda Fabrykująca - tworzenie obiektów w klasach pochodnych;

Fabryka Abstrakcyjna - tworzenie rodzin obiektów bez wydzielonych klas fabryk;

Budowniczy - ukrycie szczegółów tworzenia za interfejsem zarządcy;

Prototyp - tworzenie kopii na podstawie w pełni zainicjalizowanej instancji;

56. Jaka jest istota strukturalnych wzorców projektowych? Przedstaw przykład wzorca strukturalnego.

• Stosowany do łączenia obiektów w większe struktury;

• Zastosowanie np. w implementacji złożonego interfejsu użytkownika;

• Przykłady:

• Fasada,

• Ujednolicony i prostszy interfejs do struktury złożonych podsystemów;

• Separacja klienta od złożonych podsystemów;

• Wybór odpowiedniej struktury dla żądania klienta;

• Możliwości zmian w ukrywanych podsystemach;

• Przykłady:

• w bibliotekach Javy: klasy pakietu java.sql (Statement, ResultSet);

• wejście usług w Service Oriented Architecture (SOA);

• Adapter,

• Konwertuje (dopasowuje) interfejsy jednej klasy do interfejsu innej klasy;

• Umożliwia klasom o różnych interfejsach współpracę w jednym programie;

• Niewielka elastyczność - adaptacji podlega tylko jedna klasa (Adaptee), bez jej podklas;

• Zmiana zachowania klasy Adapter może zmienić zachowanie klasy dostosowywanej Adaptee;

• Dwa sposoby realizacji:

• dziedziczenie,

• kompozycja;

• Most,

• Kompozyt,

• System złożony z podsystemów o strukturze drzewiastej ( reprezentacja związku „całość-część”);

• Wspólny interfejs dla klas węzłów i liści - ujednolicone widzenie kontenerów i obiektów składowanych;

• Łatwo rozszerzalny o nowe podsystemy implementujące (określony interfejs);

• Przykłady:

• Przykład w bibliotekach Javy: kontenery (Panel, JComponent, …);

• Dekorator,

• Waga Piórkowa,

• Zastąpienie wielu obiektów jednym współdzielonym z opisem stanu zubożonym w porównaniu z pierwotnym obiektem;

• Zamiast przechowywać wewnątrz atrybuty stanu, obiekty dostają wartości z zewnątrz jako parametry wywołania metod;

• Zalety:

• Ograniczenie liczby tworzonych instancji obiektów;

• Przesunięcie części danych z obiektu do przekazywanych parametrów metod;

• Wady:

• Zwiększony koszt wywoływania metod obiektów;

• Uzyskuje się przyspieszenie programów operujących na wielu niezbyt złożonych obiektach;

• Przykład: zbiory obiektów „znaków literowych”;

• Proxy;

57. Jaka jest istota czynnościowych wzorców projektowych? Przedstaw przykład wzorca czynnościowego.

• W celu definiowania komunikacji pomiędzy obiektami;

• Pomagają kontrolować przepływ danych w złożonym programie;

• Przykłady:

1. Iterator,

1. Upraszcza przemieszczanie po kolekcji danych (np. liście), z wykorzystaniem standardowego interfejsu;

2. Nie wymaga znajomości wewnętrznej struktury kolekcji danych;

3. Umożliwia równoczesne przeglądanie kilku kolekcji;

5. Przykład:

6. W bibliotekach Javy: iterator w kolekcjach z pakietu java.util;

2. Łańcuch Odpowiedzialności,

1. Zestaw klas obsługuje żądanie w określonej kolejności;

2. Żądanie jest przekazywane pomiędzy klasami w określonym łańcuchu;

3. Czasami ostatni obiekt łańcucha obsługuje wszystkie żądania;

5. Przykład:

6. Realizacja w Javie: Frame -> Panel -> Component;

3. Stan,

1. Tworzy obiekty pochodne z bazowej klasy State dla każdego stanu, w którym może znaleźć się aplikacja;

2. Przełączanie pomiędzy obiektami stanu, gdy zmieni się stan aplikacji;

3. Wraz ze zmianą stanu i tym samym obiektu może zmienić się zachowanie obiektu (inne implementacje metod);

4. Eliminuje złożone instrukcje warunkowe (np. switch) w metodach obiektu;

5. Wada: powstaje wiele małych klas;

6. Zaleta: upraszcza program;

4. Mediator,

1. Mediatora stanowi „zarządcę obiektów”;

2. Wprowadza luźniejsze powiązania pomiędzy klasami - obiekty znają Mediatora a nie koniecznie inne obiekty;

3. Zmiany stanu obiektów są za jego pośrednictwem (odpowiednich metod) propagowane do zainteresowanych obiektów;

4. Często jest specjalizowany dla jednego projektu;

5. Obserwator,

6. Strategia;

1. Potrzeba kilku wariantów algorytmu;

2. Wybór określonego wariantu poprzez powołanie obiektu pochodnego do zdefiniowanego interfejsu bazowego lub klasy abstrakcyjnej;

3. Każda wersja algorytmu jest implementowana w osobnej klasie;

4. Zalety:

5. algorytm może używać danych, których klient nie zna;

6. hermetyzacja algorytmów w oddzielnych klasach pozwala na ich modyfikację niezależnie od kontekstu;

7. to rozwiązanie zastępuje instrukcje wyboru lub warunkowe;

24/24

---