1. Pojcia wstpne-projektowanie, proces projektowania, inynieria oprogramowania, wymagania, co do jakoci oprogramowania, dokumentowania wynikw prac. Projektowanie - to sekwencja spjnych, interdyscyplinarnych i wielokryterialnie ocenianych czynnoci, zmierzajcych do zbudowania i wykorzystywania SI w organizacji. Projektowanie systemu informatycznego - jest procesem. Jest to skoczony cig krokw (etapw, czynnoci) powizanych ze sob relacjami, ktre maj doprowadzi do osignicia zamierzonego celu w postaci systemu speniajcego przyjte wymagania. Sam proces projektowania jest jednym z elementw wikszego procesu cyklu ycia systemu informatycznego. Cykl ycia SI: Planowanie (strategia) co, i dlaczego ma by informatyzowane Analiza (nastpuje badanie potrzeb uytkownika i modelowanie systemu) co, po co ma by wspomagane za pomoc SI Projektowanie: Dialog Baza danych Projektowanie procesw Baza modeli Baza wiedzy Inynieria oprogramowania - jest wiedz techniczn dotyczca wszystkich faz cyklu ycia oprogramowania, ktrej celem jest uzyskanie wysokiej jakoci produktu oprogramowania. Inynieria oprogramowania wymaga przede wszystkim mylenia w kategoriach zastosowania, a nie w kategoriach kodu. Dobre oprogramowanie powinno by: zgodne z wymaganiami uytkownika niezawodne efektywne atwe w konserwacji ergonomiczne Dokumentacja Dokumentacja powinna zawiera: Opis funkcjonalny dla pocztkujcych uytkownikw lub dla zainteresowanych kupnem systemu (opis przeznaczenia systemu, niezbdne informacje), Podrcznik uytkownika dla pocztkujcych uytkownikw. Powinien zawiera informacje o sposobie realizacji funkcji, przykady korzystania z systemu,

Kompletny opis systemu dla dowiadczonych uytkownikw. Zawiera: szczegowy opis wszystkich funkcji systemu, opisy formatw danych, opisy bdw i sposoby ich naprawy, Opis instalacji systemu dla administratora. Zawiera: procedury instalacji systemu dostosowujce system do rodowiska, w ktrym bdzie pracowa, Podrcznik administratora zawiera: moliwoci zmiany systemu, sposoby udostpniania systemu uytkownikom. Sownik uywanych terminw pojcia, ktrych uywamy w dokumentacji a w rzeczywistoci mao z nich korzystamy, Indeks zwroty, ktrych uytkownicy najczciej uywaj.

Czynniki wpywajce na jako dokumentacji struktura (rozdziay, podrozdziay). zastosowanie standardw

sposb pisania.

2. Pojcie oraz modele cyklu ycia oprogramowania. Cykl ycia oprogramowania (ang. software lifecycle) - cig dziaa projektowo-programowych, obejmujcy zakres od powstania zapotrzebowania na oprogramowanie a do jego wycofania z eksploatacji. Obejmuje wiele etapw skadajcych si na projektowanie, programowanie (kodowanie), testowanie i wdraanie oprogramowania oraz czas jego uytkowania. Nowa wersja oprogramowania na og wymaga zmiany lub rozszerzenia wyposaenia sprztowego. Modele cyklu ycia oprogramowania:

Model kaskadowy (wodospadowy) - polega na wykonywaniu podstawowych czynnoci jako odrbnych faz projektowych, w porzdku jeden po drugim. Kada czynno to kolejny schodek (kaskada): o Planowanie systemu (w tym specyfikacja wymaga),

1

oo o

o oZalety:

Analiza systemu (w tym analiza wymaga i studium wykonalnoci), Projekt systemu (poszczeglnych struktur itp.), Implementacja (wytworzenie kodu), Testowanie (poszczeglnych elementw systemu oraz elementw poczonych w cao), Wdroenie i pielgnacja powstaego systemu.

o o oo Wady:

atwo harmonogramowania i budetowania, formalny odbir poszczeglnych etapw (kamienie milowe): monitorowanie postpu prac, rozliczenia finansowe z klientem, tradycyjny, przejrzysty, uniwersalny, z podziaem zasobw. narzucona cisa kolejno faz, wysoki koszt bdw ze wczesnych faz, problemy ze wprowadzaniem zmian, duga przerwa w kontaktach z klientem.

o oo o

Model spiralny - w pierwszej fazie rozwaa si oglne opcje budowy systemu, nastpnie moliwoci te s analizowane przy wziciu pod uwag ryzyka zwizanego z ich realizacj. W kolejnej fazie konstruowana jest wersja systemu w sposb zgodny z modelem kaskadowym. W fazie testowania system jest oceniany przez klienta. Jeli ocena nie jest w peni pozytywna - rozpoczynany jest kolejny cykl. W fazie planowania ustalane s cele produkcji kolejnej wersji systemu. Zalety: o harmonogramowanie i budetowanie do atwe, cho utrudnione ze wzgldu na liczb iteracji, o moliwo wyznaczenia kamieni milowych, cho nie tak oczywistych jak w modelu kaskadowym, o elastyczno, atwo wprowadzania zmian,

Wady:

o o o o

wczesne wykrywanie bdw, zarzdzanie ryzykiem. nie tak atwe, jak w modelu kaskadowym, zarzdzanie, narzucone przez klienta wymogi dotyczce harmonogramu mog utrudnia skorzystanie z tego modelu

Model oparty o prototypowanie zakada zebranie wymaga dotyczcych systemu a nastpnie realizacj wersji testowej oraz zaprezentowanie uytkownikowi. Po prezentacji nastpuje powrt do okrelenia wymaga i ewentualna zmiana (specyfikacja bd uoglnienie wybranych funkcji). Jest to o tyle rne od modelu przyrostowego, e uwaga osb realizujcych projekt skupiona jest bardziej na realizacji prototypu ni na formalnym prowadzeniu projektu. Zalety: o wykrycie nieporozumie pomidzy klientem a twrcami systemu, o wykrycie brakujcych funkcji, o moliwo demonstracji pracujcej wersji systemu, o moliwo szkole, zanim zostanie zbudowany peny system. Wady: o moe powodowa zbytnie wyduenie realizacji projektu, gdy klient wci bdzie wprowadza jakie modyfikacje do systemu, Model realizacji przyrostowej po etapie okrelenia wymaga zostaje stworzony oglny projekt systemu. Nastpnie wymagane funkcje zostaj podzielone na zestawy i realizowane przyrostowo, tzn. po zrealizowaniu jednego zestawu funkcji realizowane s nastpne, i tak, a do realizacji caego projektu. Zalety: o skracanie przerw w kontaktach z klientem, o moliwo wczesnego wykorzystania dostarczonych fragmentw systemu,

2

o moliwo elastycznego reagowania na opnienia. Wady: o dodatkowy koszt zwizany z niezalen realizacj fragmentw systemu.

Model oparty na montau z gotowych komponentw - kadzie nacisk na moliwo redukcji nakadw poprzez wykorzystanie podobiestwa tworzonego oprogramowania do wczeniej tworzonych systemw oraz wykorzystanie gotowych komponentw dostpnych na rynku. Gotowe elementy mog by wykorzystane na rnych etapach realizacji przedsiwzicia. Zalety: o wysoka niezawodno, o zmniejszenie ryzyka, o narzucenie standardw. Wady: o dodatkowy koszt przygotowania elementw ponownego uycia, o ryzyko uzalenienia si od dostawcy, o maa elastyczno.

3. Wyrniki podejcia strukturalnego. Podstawy teoretyczne programowania strukturalnego dali Bohm i Jacopini w 1966r. Na podstawie tego fundamentalnego dowodu Dijkstra w latach 1968-1972 stworzy teoretyczne podstawy programowania strukturalnego. Podejcie strukturalne polega na rozoeniu problemu na skadowe i ustaleniu powiza midzy nimi, a nastpnie zintegrowaniu tych skadnikw dla opracowania uytecznego rozwizania problemu Cechy podejcia strukturalnego: hierarchiczna struktura projektu (top-down design) podzia projektu na moduy Podejcie strukturalne skada si z dwch etapw: analizy definiowanie modelu logicznego systemu, formalizacja wymaga uytkownika, szczegowa specyfikacja zada i funkcji realizowanych przez system wyraana przewanie przez graficzne jzyki opisu takie jak: o Diagramy FHD (Function Hierarchy Diagram) o Diagramy DFD (Data Flow Diagram), Specyfikacje procesw definiowanie mechanizmw transformacji danych wejciowych w wyjciowe, czyli okrelenie algorytmw miedzy nimi. o Diagramy przej stanowych pozwalaj na modelowanie dynamiki systemu tzn. na okrelenie, w jaki sposb wystpienie jednych zdarze wpywa na zmian innych a w rezultacie na zmian caego systemu. projektowanie powstanie fizycznego modelu procesu Zalet projektowania strukturalnego jest podzia przedsiwzicia projektowego na mniejsze czci. Natomiast trudnoci pojawiaj si przy powizaniu i zestrojeniu ze sob opracowanych oddzielnie moduw . 4. Metodyki, oznaczenia i zalecenia przy tworzeniu diagramu DFD DFD - podstawowe narzdzie reprezentacji modelu funkcjonalnego projektowanego systemu. Tworzenie DFD opiera si na czterech kategoriach pojciowych, s to:

o o

Diagramy ERD (Entity-Relationship Diagram),

proces (funkcja) - dziaalno realizowana w systemie przeksztacajca dane wejciowe w wynikowe, przepyw danych - powizanie midzy procesami i innymi kategoriami DFD, skadnica (zbir, magazyn) - kolekcja danych, ktre musz by przechowywane w systemie przez okrelony czas

terminator (obiekt zewntrzny) - rdo lub przeznaczenie danych zewntrzne obiekty, z ktrymi system komunikuje si, tj. osoby, dziay, jednostki organizacyjne itp. Istnieje kilka konwencji graficznych, z ktrych najczciej stosowane s dwie: YourdonaDeMarco i Gane'a-Sarsona.

3

Zasady

tworzenia (modelowania) systemu za pomoc diagramw przepyww danych: uporzdkowanie diagramw w hierarchi, przypisanie jednoznacznych nazw do wszystkich elementw na diagramie, adne dane nie wykorzystywane przez proces nie mog do niego wpywa , kady proces musi mie przynajmniej jedno wejcie i wyjcie , nie ma przepyww miedzy skadnicami danych a obiektami zawietrznymi, nie interesuj nas przepywy miedzy obiektami zewntrznymi, konsekwentnie uywa symboli i nazw, unikanie nadmiernie zoonych diagramw by zapewni spjno miedzy diagramami i diagramami a hierarchi danych Realizacj DFD rozpoczynamy od utworzenia diagramu kontekstowego reprezentujcego cay system w postaci jednego procesu wraz z zewntrznymi terminatorami powizanymi z nim przepywami. Nastpnie rozwijamy poszczeglne procesy na podpoziomy, zgodnie z reguami: kady poziom powinien zawiera nie wicej ni poow oglnej liczby procesw i skadw danych w systemie, prosty system powinien zawiera nie wicej ni 2-3 poziomy, redni 3-5, duy do 8 poziomw, nie wszystkie procesy musz by rozwijane do tej samej liczby poziomw,

przepywy wchodzce i wychodzce z procesu na jednym poziomie musz odpowiada przepywom wchodzcym i wychodzcym z caego diagramu na nastpnym, niszym poziomie, ktry jest rozwiniciem tego procesu (bilansowanie wzgldem DFD).

5. Metodyki, oznaczenia i zalecenia przy tworzeniu diagramu ERD Podstawow funkcj diagramu ERD jest przejrzyste przedstawienie modelu danych. Dziki temu, ju na etapie projektowania mona przeprowadzi oprcz identyfikacji poszczeglnych struktur danych ich wstpn normalizacj (sprowadzenie do kolejnych postaci normalnych). Umoliwia to zmniejszenie kosztw wdroenia, gdy zmiany na etapie projektu nie wymagaj zmian w kodzie aplikacji. Podstawowe komponenty diagramu ERD to: typy obiektw (encji): o regularna - oznacza dowolny znaczcy element, o ktrym informacja powinna by znana albo utrzymywana (czciowe uczestnictwo w zwizku). Notacja graficzna:Pracownik

o

saba jest to encja, ktra moe istnie tylko wtedy, gdy jest zwizana z innymi encjami lub te nie posiada wasnych atrybutw kluczowych (cakowite uczestnictwo w zwizku) Notacja graficzna:Sprzt

o

obiekt asocjacyjny przechowuje informacje o zwizku pomidzy dwiema encjami. Notacja graficzna:

4

Wypoyczenie

relacje - to nazwane powizania pomidzy dwoma obiektami. Nazwa relacji wraz z nazwami poczonych z ni obiektw stanowi zdanie o okrelonym znaczeniu. o typy relacji: a) 1:1 (jeden-do-jeden) b) 1:M (jeden-do-wiele) c) M:N (wiele-do-wiele)

o

opcjonalno: zwizek wymagany (obowizkowy) wszystkie wystpienia encji musz uczestniczy w zwizku, zwizek opcjonalny jeli istnieje przynajmniej jedno wystpienie encji, ktre nie uczestniczy w zwizku.

Etapy projektowania ERD: ustalenie kluczy gwnych i obcych, normalizacja danych, modelowanie tablic. 6. Problematyka normalizacji schematu relacyjnego Normalizacja relacji jest to proces, podczas ktrego schematy relacji posiadajce niepodane cechy s przeksztacane na mniejsze schematy relacji o podanych wasnociach. Celem normalizacji jest uzyskanie optymalnej struktury bazy danych. Rozrniamy pi kolejnych postaci normalnych relacji. W praktyce stosuje si relacje w trzeciej postaci normalnej jako optymalne do zaprogramowania systemu baz danych. Proces normalizacji musi spenia nastpujce warunki:

aden atrybut nie zostanie zagubiony w trakcie normalizacji, dekompozycja relacji nie prowadzi do utraty informacji, wszystkie zalenoci funkcyjne s reprezentowane w pojedynczych schematach relacji,

relacje midzy tabelami mog by tylko typu jeden do jeden lub jeden do wielu. Pierwsza posta normalna wymaga, aby wszystkie wartoci jej kolumn byy elementarne(niepodzielne, s to pojedyncze wartoci okrelonego typu, a nie zbiory wartoci.). Dlatego schemat relacji musimy tak przeksztaci, aby w kolumnach byy tylko wartoci elementarne oraz aby w trakcie przeksztace nie utraci adnej informacji. Druga posta normalna - aby tabela przyja tak posta musi by w pierwszej postaci normalnej i kada z jej kolumn musi by w peni zalena od klucza gwnego i od kadego atrybutu klucza gwnego, jeli klucz ten skada si z wielu kolumn. Oznacza to, e elementy kadej kolumny tabeli, niebdcej kluczem musz by jednoznacznie identyfikowane przez klucz gwny tabeli. Trzecia posta normalna - aby tabela bya w tej postaci kada z jej kolumn musi by cakowicie zalena od klucza gwnego i niezalena od pozostaych kolumn. A zatem tabela musi spenia warunki drugiej postaci normalnej, a ponadto kada kolumna, niebdca kluczem, musi by niezalena od pozostaych kolumn niekluczowych. Dekompozycja relacji, sigajca poza trzeci posta normaln, prowadzi na og do utworzenia bardzo skomplikowanego modelu, ktrego implementacja moe by nieopacalna. Warto doda, e wspczesne systemy baz danych dobrze obsuguj klucze zoone, dlatego trzecia posta normalna jest zupenie wystarczajca dla tabel bazy danych.

5

7. Podejcie obiektowe pojcia wstpne. Projektowanie obiektowe to metodyka projektowania programw komputerowych, ktra definiuje programy za pomoc obiektw - elementw czcych stan (czyli dane) i zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyraony jest jako zbir takich obiektw, komunikujcych si pomidzy sob w celu wykonywania zada. Podejcie to rni si od tradycyjnego programowania strukturalnego, gdzie dane i procedury nie s ze sob bezporednio zwizane. Najwikszym atutem projektowania oraz analizy obiektowej jest zgodno takiego podejcia z rzeczywistoci. Jeeli dziaajcy program ma by pewnym tworem przetwarzajcym informacj - pewnym modelem rzeczywistoci - to im bardziej ten twr bdzie naladowa rzeczywisto, w ktrej yjemy - tym lepiej bdzie z ni wsppracowa (tym bardziej bdzie zrozumiay). Pojcia podstawowe: Obiekt jest to struktura zawierajca: o argumenty (dane), o metody (funkcje). Z reguy obiekty (a waciwie klasy, do ktrych te obiekty nale) s konstruowane tak, aby dane przez nie przenoszone byy dostpne wycznie przez odpowiednie metody, co zabezpiecza je przed niechcianymi modyfikacjami. Takie zamknicie danych nazywa si enkapsulacj, czyli jakby zamknicie ich w kapsule. Kady obiekt ma 3 cechy: o tosamo czyli cech umoliwiajc jego identyfikacj i odrnienie od innych obiektw, o stan czyli aktualny stan danych skadowych, o zachowanie czyli zestaw metod wykonujcych operacje na danych. Metoda funkcja skadowa klasy, ktrej zadaniem jest dziaanie na rzecz okrelonych elementw danej klasy lub klas z ni spokrewnionych.

Abstrakcja to pewnego rodzaju uproszczenie rozpatrywanego problemu, polegajce na ograniczeniu zakresu cech manipulowanych obiektw wycznie do cech kluczowych dla algorytmu, a jednoczenie niezalenych od implementacji. Dziedziczenie to operacja, ktra powoduje przeniesienie danych i metod z klasy bazowej do potomnej. Dziedziczenie porzdkuje i wspomaga polimorfizm i enkapsulacj dziki umoliwieniu definiowania i tworzenia specjalizowanych obiektw na podstawie bardziej oglnych. Polimorfizm to wykazywanie przez metod rnych form dziaania w zalenoci od tego, jaki typ obiektu jest wskazywany przez wskanik lub referencj. Enkapsulacja polega na ukrywaniu pewnych danych skadowych lub metod obiektw danej klasy tak, aby byy one (i ich modyfikacja) dostpne tylko metodom wewntrznym danej klasy lub funkcjom z ni zaprzyjanionym.

8. Co to jest UML? Na przykadach objani najwaniejsze diagramy UML UML (Unified Modeling Language) ujednolicony jzyk modelowania, jest to jzyk formalny sucy do opisu wiata obiektw w analizie obiektowej oraz programowaniu obiektowym. Twrcami jzyka UML s: Grady Booch, Jamek Rumbaugh i Ivar Jacobson (nazywani czsto trzej amigos). Pocztkowo jzyk by wspierany gwnie przez firm Rational, obecnie opiekuje si nim OMG (Object Management Group). W najnowszej wersji jzyka UML (2.0), wyrnia si 13 diagramw gwnych oraz 4 abstrakcyjne (struktur, dynamiki, wdroeniowe i interakcji). Diagramy struktury: klas, obiektw, pakietw, struktur poczonych wdroeniowe: o komponentw, o rozlokowania. Diagramy dynamiki: przypadkw uycia,

aktywnoci (czynnoci), maszyny stanowej, interakcji:

6

o sekwencji, o komunikacji, o harmonogramowania, o sterowania interakcj. Projektujc system informatyczny, rozpoczyna si przewanie od tworzenia diagramw w nastpujcej kolejnoci: przypadkw uycia, sekwencji, klas, aktywnoci. S to najczciej wykorzystywane diagramy. Pozostae bywaj pomijane, zwaszcza przy budowaniu nieduych systemw informatycznych. 9. Diagram przypadkw uycia. Diagramy przypadkw uycia dokumentuj zachowanie systemu z punktu widzenia uytkownika. S wzgldnie atwe w czytaniu nawet bez znajomoci notacji. W diagramach przypadkw uycia wystpuj: aktorzy s kim w rodzaju uytkownikw systemu, oznaczaj co zewntrznego wobec systemu. Aktorem nie zawsze musi by czowiek (moe to by np. inny system informatyczny), przypadki uycia okrelaj zadania jakie musz by wykonywane przez projektowany system. Aktora i przypadek uycia czy linia, jeli aktor moe wspdziaa z systemem w celu odegrania jakiej roli w zadaniu. Istniej dwa gwne rodzaje sytuacji, w ktrych moe zachodzi potrzeba udokumentowania relacji midzy przypadkami uycia:

wielokrotne uycie przypadkw stosujemy aby pokaza w jaki sposb system moe korzysta z istniejcych ju wczeniej komponentw lub pokaza wsplne funkcje dla rnych przypadkw uycia. Relacj t oznaczamy przerywan strzak z otwartym grotem wraz z etykiet . Strzaka prowadzi od bazowego przypadku uycia do szczegowego, aby pokaza, i rdowy przypadek uycia zawiera docelowy przypadek,

rozdzielanie wariantw zachowania stosujemy, gdy przypadek uycia uwzgldnia dwa lub wicej diametralnie rnych scenariuszy, co oznacza, e w zalenoci od okolicznoci mog wydarzy si rne rzeczy. Relacj t oznaczamy przerywan strzak z otwartym grotem wraz z etykiet . Strzak prowadzimy od przypadku wyjtkowego do przypadku bazowego. 10. Diagram klas Diagramy klas su do obrazowania statycznych aspektw perspektywy projektowej, w ktrej bierze si pod uwag wymagania funkcjonalne systemu (usugi, jakie powinien dostarcza swoim uytkownikom). Poziomy tworzenia diagramw klas: konceptualny - zawiera wycznie podstawowe elementy, cechujc si przystpnoci nazewnictwa klas, atrybutw i operacji, implementacyjny - jest stopniowo wzbogacany o elementy opisu niezbdne dla prawidowej specyfikacji modelu, takie jak np. typy danych, zobowizania, widoczno i zalenoci. Kada klasa skada si z nazwy, zestawu atrybutw oraz zestawu operacji. Atrybuty, jak rwnie operacje mog posiada rny poziom widocznoci; publiczny (+) obiekty wszystkich klas maj dostp do atrybutu lub operacji, prywatny (-) tylko obiekty danej klasy maj dostp do atrybutu lub operacji, chroniony (#) wycznie obiekty klas dziedziczcych maj dostp do atrybutu lub operacji, pakietowy (~) warto domylna tylko skadowe pakietu, do ktrego dana klasa naley, maj dostp do atrybutu lub operacji. Asocjacje: s gwnym rodzajem zwizkw midzy klasami stanowi one zwizek strukturalny, ktry wskazuje, i obiekty jednego elementu s powizane z obiektami innego, mog by: o nazwane, o nienazwane, o scharakteryzowane poprzez role klas penione w asocjacji,

liczebno asocjacji okrela liczb obiektw jednej klasy pozostajcych w zwizku z pojedynczym obiektem klasy powizanej,

7

agregacja asocjacji - jest powizaniem midzy klas a jej komponentami nazywanym zwizkiem cao-cz. Cao z komponentami czona jest za pomoc linii. Na tej linii od strony caoci umieszczamy romb. Wyrniamy agregacj: o cakowit - obiekty-segmenty bdce czciami agregatw nie mog samodzielnie i niezalenie funkcjonowa, o czciow - usunicie obiektu bdcego agregatem nie powoduje likwidacji obiektw bdcych jego czciami, czyli obiektw-segmentw. Obiekty wspdzielone mog zatem funkcjonowa samodzielnie, niezalenie od agregatu.

11.Diagram obiektw Diagram obiektw naley do diagramw statyki, to wystpienie diagramu klas, odwzorowujce struktur systemu w wybranym momencie jego dziaania. Na diagramie obiektw przedstawia si egzemplarze elementw z diagramu klas. Jest to rzut systemu w danej chwili, uwzgldniajcy zbir obiektw, ich stan oraz zwizki. Inaczej mwic, przedstawia si nie same klasy, a instancje (wystpienia) klas. Diagramy obiektw mog by uyte do pokazania przykadowej konfiguracji obiektw. Przydatne s, zwaszcza, gdy moliwe powizania miedzy obiektami s skomplikowane. Nazwy elementw na diagramach s podkrelone, co oznacza, e s one instancjami. Kada nazwa ma posta nazwaInstancji:nazwaKlasy (np. JanKowalski:Osoba), jednak obie czci tej nazwy s opcjonalne, tzn. zarwno nazwa Jan, jak i nazwa :Osoba (obiekt anonimowy), byyby poprawne. 12. Diagram pakietw Diagram pakietw suy do tego, by uporzdkowa struktur zalenoci w systemie. Waciwoci pakietw: stanowi zgrupowanie elementw modelu. S rodkiem oglnego zastosowania przeznaczonym do budowania struktur hierarchicznych, mona umieci w nich dowolne elementy (klasy, komponenty, przypadki uycia, a take inne pakiety), kady pakiet musi mie przypisan swoj (niepowtarzaln) nazw,

doskonale potrafi pokaza zalenoci pomidzy czciami systemu, dziki temu atwiej jest oceni jako i stopie powiza midzy nimi, uatwiaj zarzdzanie przechowywaniem, konfiguracjami czy modyfikowaniem elementw systemu, uatwiaj zarzdzanie procesem konstrukcji produktu programistycznego.

Specjalne rodzaje pakietw:

fasada () - zawiera wycznie odwoania do elementw zdefiniowanych w innych pakietach, model - stanowi mniej lub wicej kompletn abstrakcj systemu (na pewnym poziomie szczegowoci), widzian z pewnej perspektywy. Zwykle zawiera wewntrz drzewo pakietw,

podsystem () - jest rodzajem pakietu, ktry reprezentuje pewien spjny, logiczny, dobrze wyizolowany fragment systemu. Posiada dobrze wyspecyfikowany zbir interfejsw, do interakcji z otoczeniem. Pakiety to prostokty z maymi zakadkami na grze. Nazwa pakietu znajduje si na zakadce albo wewntrz prostokta. Strzaki z przerywanymi liniami to zalenoci. Jeden pakiet jest zaleny od drugiego, jeli zmiany w drugim pakiecie mog wymusi zmiany w pierwszym. 13. Diagram struktur poczonych Przedstawia hierarchicznie wewntrzn struktur zoonego obiektu z uwzgldnieniem punktw interakcji (wzajemnego oddziaywania) z innymi czciami systemu. Elementy skadowe diagramu: klasyfikatory obejmuj i uoglniaj klasy, obiekty, operacje, wzy i inne wspdziaania, skadniki (czci) peni we wspdziaaniu okrelone role,

interfejsy:

8

konektory skadane poczenie interfejsu udostpniajcego i interfejsu pozyskujcego

porty zapewniaj komunikacj obiektu ze wiatem zewntrznym. Tworzenie diagramu: Okrelenie zakresu i nazwy wspdziaania, Identyfikacja poszczeglnych czci: klas, obiektw itp., jak rwnie ich rl, Wyspecyfikowanie pocze, Przypisanie klasyfikatorw do opracowanego wspdziaania oraz wskazanie konkretnych jego wystpie 14. Diagram komponentw Diagram komponentw robimy z podobnych powodw, co diagram pakietw chcemy podzieli system na prostsze elementy i pokaza zalenoci midzy nimi. Diagram pakietw koncentrowa si na podziale systemu z logicznego punktu widzenia, diagram komponentw z kolei dzieli system na fizyczne elementy oprogramowania: pliki, biblioteki, itp. Komponent - wymienna cze systemu, realizujca pewien zbir interfejsw. Komponenty (programy, biblioteki, pliki) to fizyczne opakowanie bytw logicznych (klas, kooperacji), su do modelowania elementw fizycznych, ktre mog by umieszczane na wzach. Stereotypy komponentw: executable okrela komponent, ktry mona wykona na wle, library okrela dynamiczn lub statyczn bibliotek obiektw, table okrela komponent reprezentujcy tabel bazy danych, document okrela komponent reprezentujcy dokument. Zalenoci midzy komponentami pokazuj jak zmiany jednego komponentu wpywaj na inne. Diagram komponentw jest przedstawiany jako graf, gdzie wzami s komponenty, za strzaki (z przerywan lini - zalenoci) prowadz od klienta pewnej informacji do jej dostawcy; Poszczeglne komponenty mog istnie w rnym czasie: niektre z nich w czasie kompilacji, niektre w czasie konsolidacji (linking) za niektre w czasie wykonania. Rodzaj zalenoci jest zaleny od typu jzyka programowania. Diagram moe take pokazywa interfejsy poszczeglnych komponentw. Strzaki oznaczajce zalenoci mog prowadzi od komponentu do interfejsu Dobrze skonstruowany komponent korzysta z innych komponentw wycznie za porednictwem ich interfejsw, co z zaoenia uatwia przysze modyfikacje. 15. Diagram rozlokowania Diagram rozlokowania to rodzaj diagramu wdroeniowego, ktry przedstawia fizyczn lub logiczna struktur systemu (w konkretnych moduach sprztowych) wraz ze ciekami interakcji zachodzcymi pomidzy nimi. Innymi sowy pokazuje nam cay hardware, oprogramowanie, ktre jest zainstalowane na nim, oraz oprogramowanie poredniczce, ktre czy rne maszyny. Diagramy te mog by tworzone do odkrywania architektury wbudowanych systemw, tzn. do pokazania jak wsppracuje ze sob oprogramowanie z komponentami maszyny. Mog take pokazywa wszelkie obecne lub planowane zalenoci pomidzy jednym systemem a innymi. Obrazuj gwne rozmieszczenie/powizanie aplikacji biznesowych. Wzy reprezentowane s przez trjwymiarowe kwadraty, reprezentujce zarwno oprogramowanie jak i komponenty maszyny. Fizyczne wzy powinny by oznakowane stereotypem . Diagram rozlokowania umoliwia modelowanie rozmieszczenia infrastruktury sprztowej oraz platform ubytkowania systemu. Diagram rozlokowania przedstawia wzy systemu (stacje robocze, serwery), na ktrych przedstawiono wdroone elementy systemu informatycznego (baza danych, aplikacja internetowa).

file okrela komponent reprezentujcy dokument zawierajcy kod rdowy lub dane,

9

16. Diagram czynnoci Diagramy czynnoci obrazuj przepywy sterowania oraz danych pomidzy uporzdkowanymi cigami czynnoci, akcji i obiektw. Diagramy czynnoci umoliwiaj okrelenie tego, w jaki sposb system bdzie osiga swoje zamierzone cele. Diagramy czynnoci modeluj dynamiczne zachowanie systemu, koncentrujc si na procesach. Wykonanie czynnoci rozpoczyna si w jej wle pocztkowym przedstawionym pod postaci wypenionego koa. Wze pocztkowy oznacza najzwyczajniej pocztek czynnoci. Na drugim kocu diagramu wystpuje wze kocowy czynnoci oznaczajcy jej koniec i przedstawiony pod postaci dwch koncentrycznych k, z ktrych rodkowe jest wypenione. Pomidzy wzem pocztkowym a kocowym czynnoci wystpuj akcje obrazowane za pomoc prostoktw o zaokrglonych naronikach. Przepyw czynnoci przedstawiony jest przy uyciu strzaek nazywanych krawdziami lub ciekami. W diagramach czynnoci wystpuj rwnie: wzy decyzyjne - odpowiada blokowi instrukcji typu if-else w kodzie programu,

poczenia - czy ze sob krawdzie wychodzce z wza decyzyjnego, oznaczajc w ten sposb koniec zachowania warunkowego, rozwidlenia oraz scalenia w celu zobrazowania krokw, ktre zachodz w tym samym czasie, wzy sygnau odbieranego lub wysyanego reprezentuj interakcj z zewntrznymi uczestnikami. Sygnay s komunikatami, ktre mog by nadawane lub odbierane, wzy kocowe przepywu kocz jedynie wasn ciek, a nie ca czynno. S one oznaczane przy uyciu symbolu koa z wpisanym znakiem x.

17. Diagram maszyny stanowej Diagram maszyny stanowej jest odzwierciedleniem dyskretnego, skokowego zachowania si skoczonych systemw stan przejcie (obiekty uytkowane w systemie przechodz w trakcie swojego cyklu ycia przez szereg kolejnych stanw). Zachowanie dyskretne maszyny stanowej naley interpretowa jako stany i przejcia midzy nimi organizowane w sekwencj stan-przejcie-stan.... Zalety diagramu maszyny stanowej: s bardzo potnym sposobem opisu i implementacji logiki sterujcej aplikacji, podlegaj prostym reguom i s atwe do weryfikacji, umoliwiaj generacj kodu, szeroki zakres zastosowa, np. protokoy komunikacji, sterowanie interakcjami GUI itp. Klasyfikacja stanw: proste, zoone, podstany. Klasyfikacja przej: proste, zwrotne, zewntrzne, lokalne, wewntrzne, zoone, automatyczne. Podzia maszyn stanowych:

protokoowe koncentruj si na konkretnym obiekcie, przedstawiaj dozwolone przejcia pomidzy stanami tego obiektu,

zachowania przedstawiaj przejcia midzy stanami obiektw w szerszym ni w protokoowych maszynach stanowych kontekcie zachowania systemu, podsystemu, przypadku uycia i innych obiektw. Algorytm tworzenia diagramu: okrelenie rodzaju tworzonej maszyny stanowej i identyfikacja obiektw, zidentyfikowanie poszczeglnych stanw maszyny stanowej, okrelanie hierarchii stanw, podstanw oraz obszarw wspbienych, powizanie stanw oraz ich podstanw przejciami, zastosowanie adekwatnoci pseudostanw, opracowanie specyfikacji sekcji stanw i przej zgodnie z przyjtymi skadniami. 18. Diagram sekwencji

10

Diagram sekwencji jest poczeniem midzy wiatem funkcjonalnym i obiektowym. Odpowiada konkretnemu scenariuszowi danego przypadku uycia. Gwny nacisk pooony jest na uwypuklenie kolejnoci komunikatw w czasie. W grnej czci diagramu sekwencji, wzdu osi X, umieszczone s obiekty uczestniczce w interakcji. Komunikaty s uporzdkowane w czasie wzdu osi Y, im pniejsza chwila wysania, tym komunikat umieszczony niej. Obiekt inicjujcy interakcj znajduje si zazwyczaj po lewej stronie diagramu, a coraz bardziej podrzdne kolejno po prawej. Diagramy sekwencji maj dwie cechy, ktre odrniaj je od diagramw komunikacji: linie ycia obiektw - pionowe przerywane kreski reprezentujce czas istnienia obiektw, uwzgldnienie orodka sterowania - poduny, cienki prostokt reprezentujcy okres wykonywania przez obiekt jakiej akcji. Sposoby wsppracy obiektw: scentralizowany - jeden z obiektw kontroluje cay przebieg przypadku, steruje operacjami i poredniczy w wymianie danych, zdecentralizowany - nie ma obiektu kontrolujcego i obiekty komunikuj si ze sob bezporednio. 19. Diagram komunikacji Diagram komunikacji jest rodzajem diagramu interakcji, specyfikujcym strukturalne zwizki pomidzy instancjami klasyfikatorw biorcymi udzia w interakcji oraz wymian komunikatw pomidzy tymi instancjami. S stosowane do okrelenia przepyww zdarze wyszczeglnionych w scenariuszach adekwatnego przypadku uycia oraz zalenych wewntrznych interakcjach systemu. Diagram komunikacji zawiera dwa cile powizane ze sob skadniki: strukturaln organizacj klasyfikatorw - wyraon za pomoc asocjacji, interakcj midzy instancjami - realizowan za porednictwem komunikatw w ujciu graficznym przyporzdkowanych do asocjacji czcych klasyfikatory. Konieczne jest wprowadzenie numeracji porzdkowej, poniewa kolejno wysyania komunikatw nie wynika z ich naturalnego uporzdkowania na osi czas, tak jak to ma miejsce w diagramach sekwencji. Wyrni mona nastpujce rodzaje numeracji: numeracja prosta w postaci kolejnych liczb naturalnych, numeracja kwalifikowana system klasyfikacji dziesitnej Deweya. Zaawansowane skadniki diagramu:

izomorfizm diagramw sekwencji i komunikacji, zagniedenie, poprzednik, wspbienik, obiekty wielokrotne, klasy aktywne.

20. Diagram harmonogramowania Diagram harmonogramowania jest uywany do pokazywania interakcji midzy obiektami. Celem tego diagramu jest badanie zachowania jednego lub wicej obiektw w pewnym przedziale czasowym. Do sporzdzenia harmonogramw interakcji dostpne s dwie notacje: czasowa (klasyczna), zadaniowa (alternatywna) Elementy diagramu harmonogramowania to: klasyfikator, nazwa stanu, linia zmiany stanw klasyfikatora. Proces tworzenia diagramu przebiegw czasowych: identyfikacja interakcji i jej diagramu sekwencji lub diagramu komunikacji, przeniesienie lub dobr obiektw/aktorw, identyfikacja stanw kadego obiektu z wykorzystaniem diagramw maszyny stanowej, ustalenie przedziau czasowego diagramu, okrelenie linii zmiany stanw obiektw, wprowadzenie ogranicze czasowych dla poszczeglnych stanw, wprowadzenie zdarze na podstawie diagramw maszyny stanowej, harmonizacja linii zmiany stanw wszystkich obiektw, ewentualne wprowadzenie komunikatw. Na osi poziomej znajduje si skala czasu. Na osi pionowej obiekty lub aktorzy.

11

21. Diagram sterowania interakcj Diagram sterowania interakcj dokumentuje przepyw sterowania midzy powizanymi logicznie diagramami i fragmentami interakcji Na diagramie sterowania interakcj znajduj si: podstawowe oraz wybrane zaawansowane elementy diagramw czynnoci, wybrane kategorie pojciowe poszczeglnych diagramw interakcji, tj. diagramw sekwencji, komunikacji itp. Proces tworzenia diagramu sterowania interakcj: zgromadzenie wszystkich dotychczasowych diagramw interakcji dla danego przypadku uycia, przeanalizowanie wzajemnych zalenoci midzy tymi diagramami, kwalifikacja tych diagramw do: o przywoanych wystpie interakcji (ref) w przypadku diagramw zoonych, o fragmentw interakcji (cd, sd, td) dla miej obszernych diagramw, ustalenie logicznej kolejnoci wykonywania poszczeglnych fragmentw interakcji, opracowanie kompletnego diagramu sterowania interakcj z wykorzystaniem podstawowych jak i zaawansowanych kategorii pojciowych, opcjonalne wymienienie w nagwku diagramu sterownia interakcj nazw instancji klasyfikatorw biorcych udzia w interakcji. 22. Co to jest feasibility study, jakie elementy powinno zawiera? Feasibility study studium moliwoci pierwszy etap w kadym cyklu projektowym. Powinno odpowiada na takie pytania jak: czy system bdzie odporny na czas? czy cele nie s we wzajemnym konflikcie? czy cele mog ulec zmianie? kto i jak zostanie poddany wpywowi systemu? Studium moliwoci powinno zawiera 3 fazy: Zdefiniowanie zadania, Przeksztacenie strategii w zaoenia projektowe systemu informatycznego, Ocen rozwiza. W pierwszej fazie powinny znale si: Opis zadania Sformuowanie celw Podanie kryteriw oceny Podanie ogranicze i uwarunkowa zewntrznych, istotnych dla analityka Zakresy odpowiedzialnoci Limit czasu Okrelenie nieprzekraczalnych kosztw Cele studium: Ocena, czy wystpuj dostatecznie uzasadnione technicznie, socjologicznie oraz ekonomicznie przyczyny wprowadzenia zmian Upewnienie si, e system bdzie do zaakceptowania przez uytkownika Sporzdzenie dostatecznie dokadnej specyfikacji proponowanego systemu, tak aby moga stanowi baz do negocjacji z twrcami przyszego systemu i dostawcami Przyczyny wprowadzenia studium: Identyfikacja ludzi odpowiedzialnych za okrelenie celu systemu Identyfikacja wad i niedostatkw aktualnego systemu informatycznego Ustalenie celw i ogranicze nowego systemu Okrelenie wykonalnoci systemu z podaniem kilku scenariuszy Okrelenie lidera projektu 23. Narzdzia CASE klasyfikacja, struktura, przykady. Termin CASE (Computer Assisted/Aided Software/System Engineering) oznacza komputerowo wspomagan inynieri oprogramowania/systemw. Nazwa ta sugeruje, e pod hasem tym kryj si wszelkie narzdzia komputerowe wykorzystywane w trakcie prac nad oprogramowaniem, a wic take kompilatory, debuggery edytory tekstu, narzdzia harmonogramowania przedsiwzi, arkusze kalkulacyjne, itp. Tradycyjnie jednak pod pojciem CASE rozumie si narzdzia, ktre: wspomagaj oglnie rozumiane wytwarzanie oprogramowania,

12

koncentruj si na fazach analizy i projektowania oraz bezporednim wykorzystaniu wynikw tych faz w implementacji. Technologia CASE powinna umoliwia przedstawienie istniejcych i realizowanych systemw w ich poszczeglnych fazach cyklu ycia, opracowanie dokadnego i wysokiej jakoci modelu systemu, transformacj, czyli zamian lub odtwarzanie modelu opracowanego na etapie jednej fazy cyklu ycia na model fazy nastpnej, zapisywanie poszczeglnych modeli systemu w repozytoriach, wspprac wielu osb w ramach tego samego projektu lub nawet modelu. Narzdzia CASE dziel si na dwie gwne grupy: Upper-CASE - koncentrujce si na wspomaganiu wczesnych faz pracy nad oprogramowaniem, w szczeglnoci fazy analizy. Narzdzia te nie s zwizane z konkretnym rodowiskiem implementacji, Lower-CASE - koncentrujce si na fazach projektowania i implementacji. Narzdzia te s z reguy cile zwizane z konkretnym rodowiskiem implementacji. Obecnie wikszo producentw pakietw CASE okrela swoje produkty jako narzdzia I-CASE (Integrated-CASE). S to pakiety czce w sobie moliwoci narzdzi Upper-CASE i Lower-CASE. W efektywny sposb wspomagaj one wykonywanie praktycznie wszystkich faz produkcji oprogramowania. Narzdzia CASE mog wspomaga jedn metodyk analizy i projektowania. Oferuj one spjny zestaw notacji, ktry pozwala na stosowanie tej metodyki. Przykady takich narzdzi to: Oracle CASE, EasyCASE, CASE 4.0, objectiF, Select OMT Professional. Inne narzdzia pozwalaj na stosowanie caego szeregu rnych notacji. Przykadami s pakiety: Paradigm Plus - ktry wspomaga szeroki zakres rnorodnych notacji obiektowych. Narzdzia typu I-CASE uzupenione o narzdzia wspomagajce zarzdzanie przedsiwziciem programistycznym nazywane s rodowiskami inynierii oprogramowania. 24. Wymagania, ich klasyfikacja, metody (techniki) uyteczne przy formuowaniu wymaga Wymagania klienta wobec tworzonego systemu s opisywane w fazie okrelania wymaga. W fazie tej dokonywana jest wic zamiana celw klienta na konkretne wymagania zapewniajce osignicie tych celw. Naley pamita, e klient rzadko dokadnie wie, jakie wymagania zapewniaj osignicie tych celw. Proces okrelania wymaga naley wic rozumie nie jako proste zbieranie wymaga klienta, lecz jako proces, w ktrym klient wsplnie z przedstawicielami producenta (analitykami) konstruuje zbir wymaga wobec systemu zgodny z postawionymi celami. Trudnoci okrelania wymaga wynika z nastpujcych czynnikw: klient z reguy nie wie dokadnie w jaki sposb osign zaoone cele. Z drugiej strony cele klienta czsto mona osign na wiele sposobw, due systemy s wykorzystywane przez wielu uytkownikw. Ich cele s czsto sprzeczne, zleceniodawcy i uytkownicy to czsto inne osoby. Wymagania klienta mog by opisywane na rnych poziomach abstrakcji (oglnoci): definicja wymaga - to oglny opis w jzyku naturalnym. Opis taki jest wstpnym rezultatem rozmw z przedstawicielami klienta, specyfikacja wymaga - to czciowo ustruktualizowany zapis wykorzystujcy zarwno jzyk naturalny, jak i proste, czciowo przynajmniej sformalizowane notacje, specyfikacja oprogramowania - to w peni formalny opis wymaga. Wymagania wobec oprogramowania mona podzieli na dwa zasadnicze rodzaje: wymagania funkcjonalne - opisuj funkcje (czynnoci, operacje) wykonywane przez system. Liczba wymaga funkcjonalnych moe by bardzo dua. Do metod uatwiajcych zapanowanie nad du liczb wymaga moemy zaliczy: o hierarchiczny zapis wymaga, o diagramy przypadkw uycia,

System Architect - ktry wspomaga szereg notacji strukturalnych i obiektowych,

wymagania niefunkcjonalne - opisuj ograniczenia, przy ktrych system musi realizowa swoje funkcje. Mona je podzieli na:

13

o o o

wymagania dotyczce produktu (np. musi istnie moliwo przegldania systemu wycznie za pomoc klawiatury), wymagania dotyczce procesu (np. proces realizacji systemu musi by zgodny ze standardem opisanym w dokumencie XXX), wymagania zewntrzne (np. system musi wsppracowa z baz danych jakiego dziau).

25. Projektowanie architektury (architektoniczne) Projektowanie architektury to pocztkowa faza procesu projektowania, identyfikuje si podsystemy, ustala zrb sterowania i komunikacji podsystemw. Produktem tej fazy procesu jest opis architektury oprogramowania. Wynikiem procesu projektowania architektonicznego jest dokumentacja projektu architektonicznego, ktra skada si z kilku graficznych przedstawie modeli systemu oraz tekstu opisowego. Ta dokumentacja powinna zawiera opis systemu jako struktury zoonej z podsystemw i kadego podsystemu jako struktury zoonej z moduw. Rne graficzne modele systemu przedstawiaj rozmaite perspektywy architektury. Architektura systemu ma wpyw na efektywno, solidno oraz zdatno do rozpraszania i pielgnacji. Wybrany dla danego zastosowania styl i struktura mog wic zalee od wymaga niefunkcjonalnych systemu: Efektywno, Zabezpieczenie, Bezpieczestwo, Dostpno, Zdatno do pielgnacji. Pierwsza faza projektowania architektonicznego podzia systemu na zbir oddziaujcych ze sob podsystemw. Projekt architektoniczny mona przedstawi w postaci diagramu blokowego, na ktrym kady prostokt odpowiada podsystemowi. Wyrniamy trzy standardowe modele: repozytorium - jest przystosowany do zastosowa, w ktrych dane s generowane przez jeden podsystem, a uywane przez inny, np systemy sterowania i kontroli, systemy zarzdzania informacjami, systemy CAD i zestawy narzdzi CASE., klient serwer - jest modelem rozproszonego systemu, w ktrym dane i przetwarzanie s rozdzielone midzy zbir procesorw. Gwnymi komponentami tego modelu s: o Zbir samodzielnych serwerw, o Zbir klientw, o Sie,

maszyny abstrakcyjnej - ukada system w cigi warstw, z ktrych kada oferuje pewne usugi. Kada warstwa jest maszyn abstrakcyjn, ktrej jzyk maszynowy suy do implementacji nastpnego poziomu maszyny abstrakcyjnej.

26. Projektowanie interfejsu uytkownika Interfejs uytkownika: Dobry projekt interfejsu uytkownika jest niezbdnym warunkiem prowadzenia systemu. Interfejs trudny w uyciu w najlepszym wypadku doprowadzi do wielu pomyek uytkownikw. W najgorszym wypadku uytkownicy po prostu odmwi uywania systemu niezalenie od jego funkcjonalnoci. Jeli informacja jest przedstawiona w sposb zagmatwany i mylcy, uytkownicy mog le zrozumie znaczenie systemu. Rodzaje interfejsw uytkownika: znakowy - pozwala na kontaktowanie si uytkownika z komputerem poprzez sekwencje znakw alfanumerycznych. Obecnie istniej nastpujce rodzaje interfejsw znakowych: o dialog pytanie-odpowied o jzyk polece o jzyk naturalny graficzny (GUI Graphical User Interface) - najwaniejszym elementem graficznego interfejsu jest okno programu, wewntrz takiego okna s rozmieszczone elementy interakcyjne, zwane widgetami. Uytkownik komunikuje si z aplikacj porednio przez te widgety najczciej za pomoc myszy i klawiatury. Projektujc interfejs mona uwzgldni nastpujce sposoby interakcji:

14

bezporednie dziaanie np. w Windows polega na przeniesieniu obiektu do usunicia do kosza, wybr z menu np. polega na wyborze z menu polecenia usu, wypenienie formularza polega na wypenieniu odpowiednich pl w celu realizacji zadania, jzyk polece np. jzyk DOS, aby usun plik naley wpisa odpowiednie polecenie,

jzyk naturalny uytkownik w jzyk naturalnym wpisuje polecenia np. usu plik 10 zasad projektowania interfejsu graficznego: 1. Interfejs jest dobrze zaprojektowany wtedy, gdy program zachowuje si dokadnie tak, jak oczekuje tego uytkownik 2. W trakcie projektowania interfejsu powinien on by testowany na uytkownikach - nie s do tego potrzebne specjalne laboratoria, czasami wystarczy maa grupa ludzi 3. Jeli nie jest znany model uytkownika, za pomoc metafory trzeba uytkownikowi przybliy model programu 4. Naley dy do ograniczenia liczby opcji, a co za tym idzie: liczby wyborw, ktrych musi dokona uytkownik 5. Dobrze zaprojektowany interfejs zachowuje zgodno z ju stosowanymi schematami (np. skrtw klawiaturowych czy ikon) 6. Projektowanie interfejsu powinno odbywa si z uwzgldnieniem warunkw ekstremalnych musi on by uyteczny nie tylko w idealnych warunkach (owietlenie, umiejtnoci uytkownika) 7. Dobry interfejs w maksymalnym stopniu uwzgldnia fakt, e uytkownicy czsto maj kopoty z poprawn obsug myszy 8. Nie obciajmy pamici uytkownikw - interfejs nie powinien wymaga zapamitywania zbyt wielu informacji 9. Uytkownicy nie czytaj - im wicej sw w oknach dialogowych, tym mniejsza szansa na ich przeczytanie i wiksza dezorientacja uytkownika 10. Osoba pracujca z komputerem lubi mie poczucie sprawowania kontroli nad maszyn powinno si je zapewni za wszelk cen Zasady projektowania interfejsu:

porady dla uytkownika, rozrnienie uytkownikw Interfejs mona oceni wedug:

zblienie do uytkownika, spjno, minimum niespodzianek, moliwo wycofania,

atwoci nauczenia, szybkoci dziaania, solidnoci, zdolnoci wycofania, zdolnoci adaptacji.

27. Pojcie testowania; rodzaje, etapy i techniki testowania Mwic o testowaniu naley rozrni nastpujce pojcia: atestowanie - czyli testowanie zgodnoci systemu z rzeczywistymi potrzebami uytkownika, weryfikacja - czyli testowanie zgodnoci systemu z wymaganiami zdefiniowanymi w fazie okrelenia wymaga. Testy mona klasyfikowa z rnych punktw widzenia. Z punktu widzenia gwnego celu testy mona podzieli na: wykrywanie bdw, testy statystyczne, ktrych celem jest wykrycie przyczyn najczstszych bdnych wykona oraz ocena niezawodnoci systemu Z punktu widzenia podstawowej techniki wykonywania testw mona je podzieli na: testy dynamiczne - ktre polegaj na wykonywaniu programu i porwnywaniu uzyskanych wynikw z wynikami poprawnymi, testy statyczne - oparte na analizie kodu. Testowanie systemu przebiega z reguy przez nastpujce fazy:

15

testy moduw - wykonywane ju w fazie implementacji, bezporednio po zakoczeniu realizacji poszczeglnych moduw, testy systemu - polegaj na integracji poszczeglnych moduw i testowany jest system jako cao,

testy akceptacji - realizowane w przypadku oprogramowania realizowanego na zamwienie, system przekazywany jest do przetestowania przyszemu uytkownikowi. Poza dokadniej przedstawionymi rodzajami testw wyrni moemy jeszcze nastpujce testy: operacyjne, wydajnociowe, ergonomiczne, dokumentacji uytkownika kocowego,

28. Faza wdraania pojcie, dziaania, strategie, przykady Wdraanie systemu jest nastpnym, po projektowaniu, etapem dziaa cyklu ycia systemu. Jest to jedno z najtrudniejszych zada w unowoczenianiu systemu informacji. W fazie wdroenia, system informatyczny jest w caoci przekazany uytkownikowi. Projektanci systemu zostaj zastpowani przez jego uytkownikw. Proces ten jest w caoci przeprowadzany w siedzibie przyszego uytkownika systemu. Instalacja oraz wdroenie obejmuj: instalacj oprogramowania i przekazanie dokumentacji uytkowej, szkolenie uytkownikw systemu, inicjacj i parametryzacj systemu, nadzorowanie pilotowej eksploatacji systemu, usuwanie bdw w systemie, przekazanie systemu do eksploatacji. W trakcie wdroenia nastpuje wprowadzenie do praktyki wczeniej opracowanego, zaprojektowanego i oprogramowanego modelu rzeczywistoci oraz dopasowanie systemu do wymaga rzeczywistoci. Tu rwnie ujawniaj si wszystkie niedoskonaoci i braki wynikajce z niedostatecznego dopracowania we wczeniejszych fazach cyklu ycia systemu. Strategie Przyjmujc jako kryterium zakres wdroenia i metod postpowania, moemy wydzieli nastpujce strategie dziaa:

wdraanie caociowe (totalne) to implementacja nowego systemu przy rwnoczesnej rezygnacji z eksploatacji dotychczasowego systemu. Podejcie wygodne i mao kosztowne jednak obarczone jest duym ryzykiem. W przypadku bdw w systemie powstaj znaczne dodatkowe koszy. Gdy system opracowywany jest dla nowej organizacji jest to jedyna moliwa strategia dziaania, wdraanie czstkowe mniejszy stopie ryzyka, wymaga podziau na czci. Wdraanie czstkowe moemy podzieli na: o pilotowe ograniczone ze wzgldu na zakres funkcjonowania systemu,

o

prbne obejmujce wszystkie funkcje systemu ale ograniczone ze wzgldu na objto zbiorw,

rwnolege - dotychczasowy system jest eksploatowany tak dugo, a nowy nie zostanie w peni wdroony. W praktyce przyjmuje si zazwyczaj, e pena zgodno wynikw przetwarzania tradycyjnego i nowego systemu w trzech kolejnych cyklach badawczych jest podstaw do zaniechania przetwarzania rwnolegego.

29. Wzorce projektowe pojcie, historia, przykady, wykorzystanie Termin wzorca projektowego zosta wprowadzony do inynierii oprogramowania w 1995 roku w ksice Design Patterns autorstwa Gammy, Helma, Johnsona i Vlissidesa. Wzorce projektowe mog przyspieszy proces rozwoju oprogramowania przez dostarczenie wyprbowanych rozwiza dla problemw, ktre mog nie by oczywiste na pocztku procesu projektowego. Zamiast skupia si na funkcjonowaniu poszczeglnych elementw, wzorce projektowe stanowi abstrakcyjny opis zalenoci pomidzy klasami, co w efekcie doprowadza do pewnej standaryzacji kodu i czyni go bardziej zrozumiaym, efektywniejszym i mniej zawodnym.

16

Warto wzorcw projektowych stanowi nie tylko samo rozwizanie problemu, ale take dokumentacja, ktra wyjania cel, dziaanie oraz zalety danego rozwizania, co pomaga w atwiejszym stosowaniu i adaptacji wzorcw w danym zastosowaniu. Wzorce konstrukcyjne - wykorzystywane do pozyskiwania obiektw zamiast bezporedniego tworzenia instancji klas: Fabryka abstrakcyjna, Budowniczy, Metoda fabrykujca, Prototyp, Singleton. Wzorce strukturalne - pomagaj czy obiekty w wiksze struktury: Klasowe wzorce strukturalne - wykorzystuj dziedziczenie do skadania interfejsw lub implementacji. Ten typ wzorcw jest szczeglnie przydatny wtedy, kiedy w jednym programie uywamy niezalenie utworzonych bibliotek klas. Obiektowe wzorce strukturalne - nie wykorzystuj skadania interfejsw lub implementacji, a opisuj sposoby skadania obiektw w celu uzyskania nowej funkcjonalnoci. Dodatkowa elastyczno zwizana ze skadaniem obiektw wynika z moliwoci zmieniania obiektu zoonego w czasie wykonywania programu. Do wzorcw strukturalnych moemy zaliczy taki wzorzec jak: o Adapter - wzorzec ten przeksztaca interfejs klasy w taki, jakiego klient oczekuje. Dziki Adapterowi klasy mog wsppracowa, co bez niego nie byo moliwe, poniewa maj niezgodne interfejsy. Wzorzec Adapter stosujemy, gdy: Chcemy wykorzysta istniejc klas, a jej interfejs nie odpowiada temu, ktrego potrzebujemy, Chcemy utworzy klas wielokrotnego uytku, ktra wsppracuje z niepowizanymi ze sob lub nieprzewidzianymi klasami, to znaczy takimi, ktre niekoniecznie maj zgodne interfejsy, Potrzebujemy uy kilku istniejcych podklas, ale zaadoptowanie ich interfejsw przez tworzenie ich podklas jest niepraktyczne; adapter obiektw moe adoptowa interfejs swojej nadklasy. Inne wzorce strukturalne: o Most, o Kompozyt, o Dekorator, o Fasada, o Porednik. Wzorce czynnociowe - su do zdefiniowania komunikacji pomidzy obiektami oraz kontrolowania przepywu danych w zoonej aplikacji. Wzorce czynnociowe dotycz algorytmw i przydzielania zobowiza obiektom. Uwzgldniaj one zarwno wzorce obiektw i klas, jak i wzorce komunikacji pomidzy nimi. Ponadto charakteryzuj zoone przepywy sterowania, ktre s trudne do przeledzenia w czasie wykonywania programu. Umoliwiaj skoncentrowanie si na przepywie sterowania, a nie na sposobie, w jaki obiekty s ze sob poczone. Klasowe wzorce czynnociowe wykorzystuj dziedziczenie do rozdzielania dziaa pomidzy klasy. Moemy wyrni 2 takie wzorce: o Interpreter - definiuje reprezentacj dla gramatyki zadanego jzyka , a take interpreter, ktry wykorzystuje t prezentacj do interpretowania zda w zadanym jzyku. Uzasadnienie stosowania: Gdy pewien rodzaj problemu pojawia si do czsto, warto wyrazi egzemplarze tego problemu jako zadania w prostym jzyku. w problem rozwizuje zbudowany interpreter, przez interpretowanie tych zda, o acuch odpowiedzialnoci, Obiektowe wzorce czynnociowe wykorzystuj skadnie obiektw zamiast dziedziczenia. Niektre z nich opisuj sposb wspdziaania rwnorzdnych obiektw w grupie w celu wykonania zadania, ktrego aden z nich nie mgby wykona w pojedynk. Przykady wzorcw obiektowych: o Obserwator - wzorzec ten okrela relacje jeden-do-wiele midzy obiektami. Oznacza to, e jeli jeden obiekt zmienia stan, wszystkie obiekty ode zalene s o tym automatycznie powiadamiane i uaktualniane. Uzasadnienie stosowania:

17

o o o o o o

Typowym efektem ubocznym dzielenia systemu na wsppracujce klasy jest potrzeba utrzymania spjnoci midzy powizanymi obiektami. Przy czym nie chodzi tu o wprowadzenie silnych powiza pomidzy klasami (zmniejsza to szanse na ponowne wykorzystanie tych klas), ani te o ograniczanie liczb zalenych obiektw do dwch. Liczba interfejsw uytkownika przedstawiajcych te same dane moe by dowolna, Mediator, acuch zobowiza, Strategia, Polecenie, Stan, Iterator.

30. Zarzdzanie projektem informatycznym, problem oceny oraz jakoci oprogramowania Zarzdzanie przedsiwziciem (projektem) jest to proces planowania, organizacji oraz zarzdzania zadaniami i zasobami w celu osignicia zdefiniowanego celu, zwykle w ramach ogranicze czasu, zasobw lub kosztu. Plan projektu moe by prosty, skada si na przykad z listy zada z ich datami rozpoczcia i zakoczenia zapisanymi w notatniku. Moe by take zoony, skada si na przykad z tysicy zada i zasobw oraz budetu liczonego w milionach zotych. Wikszo przedsiwzi ma takie same elementy, takie jak podzia na atwe do zarzdzania zadania, planowanie zada, czno w zespole i ledzenie zada w trakcie postpu pracy. Zwykle mona wyrni trzy gwne fazy: Budowa planu, ledzenie i zarzdzanie przedsiwziciem, Zamykanie przedsiwzicia Problem oceny oraz jakoci oprogramowania Na jako oprogramowania skadaj si cechy mierzalne i niemierzalne (subiektywne). Pomiary cech produktw programistycznych s utrudnione lub niemoliwe. Pojcie jakoci:

stopie uwolnienia wyrobu od wad i bdw. Trudnoci z ocen jakoci oprogramowania

trudne do zdefiniowania, posiada cechy obiektywne mierzalne, posiada cechy subiektywne, jako to pewien stopie doskonaoci,

Wieloaspektowo, niska przewidywalno wszystkich aspektw zastosowa w dugim czasie, Oceny jakoci najczciej musz by znane zanim powstanie gotowy, dziaajcy produkt, co wyklucza zastosowanie obiektywnych metod pomiarowych, Wiele czynnikw skadajcych si na jako produktu jest niemierzalna, Zoono powoduje trudnoci w wyodrbnieniu cech mierzalnych, ktre odzwierciedlayby istotne aspekty jakoci, Szerokie pole zastosowa produktw programistycznych sprawia, e mog dziaa w rnych zastosowaniach, o rnej skali. Wwczas pomiary jakoci mog okaza si nieadekwatne przy zmianie skali,

Kosztowno pomiarw, ich czasochonno lub niewykonalno z powodu niemoliwoci stworzenia rodowiska pomiarowego. Atrybuty oceny jakoci oprogramowania Funkcjonalno - okrela stopie realizacji potrzeb uytkownika przez funkcje programu, Niezawodno - zdolno aplikacji do niezakconej pracy przez dany duszy okres czasu, Uyteczno - atwo uycia aplikacji przez zdefiniowan grup odbiorcw, Wydajno stosunek iloci zada wykonanych przez program do iloci zasobw zuytych przy wykonywaniu tych zada, Przenono - zdolno oprogramowania do adaptacji do rnych rodowisk, Moliwoci konserwacji - ilo wysiku potrzebnego do wprowadzenia modyfikacji w toku uytkowania systemu

18

Metody oceny jakoci oprogramowania

Metoda GQM (Goal, Qestion, Metric) prosta i intuicyjna metoda, ktrej sens zawiera si w 3 krokach: o ustalenie celw podstawowych, jakie oceniany obiekt powinien spenia,

oo

przyporzdkowanie serii prostych pyta do kadego celu, ktre rozbijaj podstawowy problem na mniejsze podproblemy, okrelenie metryk i ich przyporzdkowanie do pyta, przygotowanych w punkcie drugim.

Metoda QFD (Quality Function Deployment) mierzy sposb, w jaki klienci odbieraj jako badanego programu, bazuje na zestawieniu cech badanego systemu, ktre umieszczane s w dwch kategoriach: o kategoria wymaga klienta - s to informacje o tym, czego klient oczekuje, wyraone w jzyku zrozumiaym dla klienta, o kategoria czynnikw technicznych - zawiera wszystkie techniki i metryki techniczne, niezbdne do zapewnienia implementacji wymaga klienta. SOJO (System Oceny Jakoci Oprogramowania) hierarchiczna reprezantacja cech produktu, ktre decyduj o jego jakoci. Hierarchia wyglda nastpujco: o Atrybuty (np.: elastyczno),

o o o

Charakterystyki (charakterystyki elastycznoci: przenono, konfiguralno, modyfikowalno), Metryki (dla modyfikowalnoci np. modularno), Miary (np. liczba linii kodu podana w tys.).

Metoda wyznacznikw jakoci McCalla ocenia jako systemw informatycznych wedug 3 grup wyznacznikw: o Funkcjonowanie systemu,

oo

Rozwojowo systemu, Uniwersalno systemu

31. Organizacyjne aspekty procesu projektowania, praca w zespole projektujcym system informatyczny Liderzy grup projektowych wymagaj od pracownikw zarwno gotowoci do kompromisu i podporzdkowania, jak i wysokiego poziomu indywidualizmu, kreatywnoci. Jednoczenie uwaa si, e wikszo ludzi w trakcie pracy zawodowej traci kreatywno i indywidualizm na rzecz konformizmu i standardowoci. Liderzy wol wic tworzy zespoy z modych pracownikw zdajc sobie spraw z braku ich dowiadczenia zawodowego. Kryteria doboru: Kompetencje, Motywacja do pracy, Atrybuty osobiste Przez skuteczno systemu komunikacji rozumie si stopie realizacji zaoonych celw projektu, czyli okrelonego ju wczeniej sukcesu. W praktyce stosowane s dwa systemy organizacyjne w zespoach projektowych: Sieciowy system komunikacji - powizania midzy uczestnikami zespou projektujcego s bezporednie i rnorodne, Tradycyjny - hierarchiczny system komunikacji Dla zwikszenia efektywnoci funkcjonowania systemu zarzdzania naley maksymalnie eliminowa ogniwa porednie. Nie mona rekomendowa systemu hierarchicznego, poniewa tu pracownik otrzymuje tylko polecenia.. Pracownik podlegy raczej niechtnie przekazuje wiedz liderowi. Mona powiedzie, e pracownik uznaje za swj obowizek przekazywanie informacji o realizacji projektu, ale nie dotyczy to przekazywania swojej wiedzy na ten temat. Wydaje si, e powd tego ley bardziej w sferze psychiki. Struktur organizacyjn i komunikacyjn w zespole projektujcym zorganizowanym sieciowo mona scharakteryzowa:

Podzia na zespoy zadaniowe zmienia si dynamicznie w trakcie realizacji projektu, W zarzdzaniu stosowany jest system bezporedniego podporzdkowania. Jedyn osob koordynujc cao prac jest lider projektu, Udzia grupy wykonawcw z jednego zespou w realizacji zada innego zespou. Wybrana grupa bardziej dowiadczonych pracownikw 20-30% swojego czasu pracy przeznacza na

19

udzia w realizacji zada innego zespou. Wzmacnia to wi midzy pracownikami z rnych zespow i tworzony warunki dla systemu przepywu i zarzdzania wiedz. Przewaga sieciowej organizacji:

Monitoring realizacji projektu - zagroenia w realizacji i odstpstwa od planowanych kosztw, czasu realizacji zada, zaoonych parametrw systemu s w systemie sieciowym wczeniej dostrzegane, ni w systemie hierarchicznym, wczeniej wic mona podj interwencj, Wsppraca i przekazywaniu wiedzy w realizacji zada - midzy czonkami istnieje dua wsppraca zarwno w realizacji zada, jak i w przekazywaniu dysponowanej wiedzy. Nie s tworzone sztuczne bariery midzy liderami i pracownikami. W zasadzie kady jest, zalenie od sytuacji, liderem i wykonawc,

Rozwizywanie sytuacji problemowych - konflikty w realizacji zada s o wiele mniejsze w systemie sieciowym ni w hierarchicznych, a jeeli ju powstay s szybko rozwizywane wewntrz grupy zadaniowej. System komunikacji stosowany w zespole zorganizowanym sieciowo wymaga spenienia szeregu warunkw. Najbardziej istotny jest poziom kwalifikacji poszczeglnych pracownikw i ich ch do wsplnej pracy. System ten jest trudny dla tak zwanych indywidualistw i osb pragncych zrobi karier administracyjn. Lider caoci projektu ma du odpowiedzialno. Odpowiada za dobr zespou, organizacj pracy oraz za stworzenie odpowiedniego klimatu. W stosunku do systemu hierarchicznego lider projektu powinien zrezygnowa z wielu swoich uprawnie kierowniczych i przekaza je do zespow realizujcych. Jego odpowiedzialno za realizacj projektu nie ulega zmianie. Dlatego wielu liderw projektw uwaa system hierarchiczny za atwiejszy do sprawowania kontroli nad terminow realizacj zada. Bardzo istotny jest te dobr pracownikw do zespou i stosowany system motywacji. 32. Ewolucja oprogramowania modyfikacja, restrukturyzacja, zarzdzania konfiguracjami Opracowanie wysokiej jakoci oprogramowania w ograniczonym czasie i przy ograniczonym budecie jest wielkim wyzwaniem. Modyfikacja istniejcego systemu w celu zaimplementowania nowych moliwoci jest zadaniem jeszcze trudniejszym. Proces modyfikacji powinien by przeprowadzany bez naruszania jakoci caego systemu. Cel ten nie zawsze jednak zostaje osignity. Modyfikacja oprogramowania moe prowadzi do niepodanych efektw ubocznych, a nastpnie do spadku jakoci. Mona wyrni nastpujce modele pielgnacji oprogramowania: styl budowy katedry - szczegowo zaplanowany, nie ulegajcy atwo zmianom i ewolucji, styl bazaru - ywioowo rozwijajcego si w wielu kierunkach, charakteryzujcy si wieloma wydaniami i koniecznoci okresowej restrukturyzacji Szczeglnie interesujcy jest ten drugi model, reprezentowany m.in. przez Linuxa, w ktrym system nieustannie znajduje si w fazie pielgnacji. Na pielgnacj oprogramowania skadaj si cztery rne rodzaje aktywnoci pielgnacyjnej: doskonalca (ok. 50%) - ma na celu implementacj nowych lub zmienionych wymaga funkcjonalnych, adaptacyjna (ok. 25%) - dostosowuje program do zmian zachodzcych w rodowisku, naprawcza (ok. 20%) - suy usuwaniu bdw z programu, prewencyjna (ok. 5%) - polega na wewntrznej restrukturyzacji programu, co pozwala zmniejszy koszty pielgnacji w przyszoci. Przyjmuje si, e koszt pielgnacji w kadym systemie moe by porwnywalny lub wyszy od kosztu jego stworzenia, w zalenoci od czasu jego pielgnacji i innych, wymienionych wczeniej, czynnikw. Na koszt pielgnacji ma wpyw wiele czynnikw technicznych i pozatechnicznych, m.in.:

dziedzina systemu - w przypadku obszarw dobrze zdefiniowanych, o intuicyjnych wymaganiach, koszt bdzie niszy ni w przypadku dziedzin o wysokiej zmiennoci wymaga, stao personelu - szybka rotacja pracownikw powoduje, e twrca oprogramowania nie zajmuje si pniej jego pielgnacj. Wie si to z dodatkowym kosztem zrozumienia oprogramowania przez nowego pracownika, wiek oprogramowania - wynika to z kosztw pielgnacji sprztu, na ktrym system jest uruchamiany, a take dotychczasowych zabiegw pielgnacyjnych, ktre utrudniaj wprowadzanie kolejnych zmian. W momencie, gdy koszt pielgnacji przekracza koszt stworzenia nowego systemu, dalsza ewolucja jest ekonomicznie nieuzasadniona,

20

wewntrzna jako oprogramowania oraz dokumentacji - program podzielony na moduy, o niewielkiej liczbie powiza, moe by modyfikowany czciami, bez potrzeby zmiany pozostaych moduw. Inynieria ponowna (czyli re-inynieria) jest pojciem stosowanym w odniesieniu do pielgnacji istniejcych systemw o sabej pielgnowalnoci. Celem jest zwikszenie tej zdolnoci przez zmian jego wewntrznej struktury, aktualizacj dokumentacji etc. Stosowanie jej pozwala ograniczy koszty zwizane z pielgnacj, a take ryzyko zwizane ze stworzeniem cakowicie nowego oprogramowania. Oczywicie, wie si z tym dodatkowy koszt, jaki naley ponie w fazie tworzenia programu, jednak jest on rodzajem inwestycji zwracajcej si podczas pielgnacji. Z uwagi na koszty, warto stosowa re-inynieri, szczeglnie w tych fragmentach systemu, ktre czsto ewoluuj. Ewolucja jest procesem naturalnym i w praktycznych zastosowaniach nie da si jej unikn. Programy, ktre nie ewoluuj, staj si coraz mniej uyteczne. Czynnikiem wspomagajcym pielgnacj jest sterowanie ewolucji poprzez informacj zwrotn pync ze rodowiska. Dlatego cyklem ycia szczeglnie dobrze wspomagajcym t faz rozwoju oprogramowania jest model spiralny. Koszt zwizany z pielgnacj zwykle przekracza koszt stworzenia oprogramowania. Dlatego stosowanie cyklicznej restrukturyzacji pozwala ograniczy ten koszt, za cen dodatkowych nakadw w fazie rozwoju

21