1. Pojęcia wstępne-projektowanie, proces projektowania, inżynieria oprogramowania, wymagania, co do jakości oprogramowania, dokumentowania wyników prac.Projektowanie - to sekwencja spójnych, interdyscyplinarnych i wielokryterialnie ocenianych czynności, zmierzających do zbudowania i wykorzystywania SI w organizacji. Projektowanie systemu informatycznego - jest procesem. Jest to skończony ciąg kroków (etapów, czynności) powiązanych ze sobą relacjami, które mają doprowadzić do osiągnięcia zamierzonego celu w postaci systemu spełniającego przyjęte wymagania. Sam proces projektowania jest jednym z elementów większego procesu – cyklu życia systemu informatycznego. Cykl życia SI: Planowanie (strategia) → co, i dlaczego ma być informatyzowane Analiza (następuje badanie potrzeb użytkownika i modelowanie systemu) → co, po co ma być wspomagane za pomocą SI Projektowanie: • Dialog • Baza danych • Projektowanie procesów • Baza modeli • Baza wiedzy Inżynieria oprogramowania - jest wiedzą techniczną dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu – oprogramowania. Inżynieria oprogramowania wymaga przede wszystkim myślenia w kategoriach zastosowania, a nie w kategoriach kodu. Dobre oprogramowanie powinno być: • zgodne z wymaganiami użytkownika • niezawodne • efektywne • łatwe w konserwacji • ergonomiczne Dokumentacja Dokumentacja powinna zawierać: • Opis funkcjonalny – dla początkujących użytkowników lub dla zainteresowanych kupnem systemu (opis przeznaczenia systemu, niezbędne informacje), • Podręcznik użytkownika – dla początkujących użytkowników. Powinien zawierać informacje o sposobie realizacji funkcji, przykłady korzystania z systemu, • • • • • Kompletny opis systemu – dla doświadczonych użytkowników. Zawiera: szczegółowy opis wszystkich funkcji systemu, opisy formatów danych, opisy błędów i sposoby ich naprawy, Opis instalacji systemu – dla administratora. Zawiera: procedury instalacji systemu dostosowujące system do środowiska, w którym będzie pracował, Podręcznik administratora – zawiera: możliwości zmiany systemu, sposoby udostępniania systemu użytkownikom. Słownik używanych terminów – pojęcia, których używamy w dokumentacji a w rzeczywistości mało z nich korzystamy, Indeks – zwroty, których użytkownicy najczęściej używają. Czynniki wpływające na jakość dokumentacji • struktura (rozdziały, podrozdziały). • zastosowanie standardów • sposób pisania. 2. Pojęcie oraz modele cyklu życia oprogramowania. Cykl życia oprogramowania (ang. software lifecycle) - ciąg działań projektowo-programowych, obejmujący zakres od powstania zapotrzebowania na oprogramowanie aż do jego wycofania z eksploatacji. Obejmuje wiele etapów składających się na projektowanie, programowanie (kodowanie), testowanie i wdrażanie oprogramowania oraz czas jego użytkowania. Nowa wersja oprogramowania na ogół wymaga zmiany lub rozszerzenia wyposażenia sprzętowego. Modele cyklu życia oprogramowania: • Model kaskadowy (wodospadowy) - polega na wykonywaniu podstawowych czynności jako odrębnych faz projektowych, w porządku jeden po drugim. Każda czynność to kolejny schodek (kaskada): o Planowanie systemu (w tym specyfikacja wymagań), 1 o o o o o Zalety: Analiza systemu (w tym analiza wymagań i studium wykonalności), Projekt systemu (poszczególnych struktur itp.), Implementacja (wytworzenie kodu), Testowanie (poszczególnych elementów systemu oraz elementów połączonych w całość), Wdrożenie i pielęgnacja powstałego systemu. o o o o Wady: łatwość harmonogramowania i budżetowania, formalny odbiór poszczególnych etapów (kamienie milowe): monitorowanie postępu prac, rozliczenia finansowe z klientem, tradycyjny, przejrzysty, uniwersalny, z podziałem zasobów. narzucona ścisła kolejność faz, wysoki koszt błędów ze wczesnych faz, problemy ze wprowadzaniem zmian, długa przerwa w kontaktach z klientem. o o o o • Model spiralny - w pierwszej fazie rozważa się ogólne opcje budowy systemu, następnie możliwości te są analizowane przy wzięciu pod uwagę ryzyka związanego z ich realizacją. W kolejnej fazie konstruowana jest wersja systemu w sposób zgodny z modelem kaskadowym. W fazie testowania system jest oceniany przez klienta. Jeśli ocena nie jest w pełni pozytywna - rozpoczynany jest kolejny cykl. W fazie planowania ustalane są cele produkcji kolejnej wersji systemu. Zalety: o harmonogramowanie i budżetowanie – dość łatwe, choć utrudnione ze względu na liczbę iteracji, o możliwość wyznaczenia kamieni milowych, choć nie tak oczywistych jak w modelu kaskadowym, o elastyczność, łatwość wprowadzania zmian, Wady: o o o o wczesne wykrywanie błędów, zarządzanie ryzykiem. nie tak łatwe, jak w modelu kaskadowym, zarządzanie, narzucone przez klienta wymogi dotyczące harmonogramu mogą utrudniać skorzystanie z tego modelu • Model oparty o prototypowanie – zakłada zebranie wymagań dotyczących systemu – a następnie realizację wersji testowej oraz zaprezentowanie użytkownikowi. Po prezentacji następuje powrót do określenia wymagań i ewentualna zmiana (specyfikacja bądź uogólnienie wybranych funkcji). Jest to o tyle różne od modelu przyrostowego, że uwaga osób realizujących projekt skupiona jest bardziej na realizacji prototypu niż na formalnym prowadzeniu projektu. Zalety: o wykrycie nieporozumień pomiędzy klientem a twórcami systemu, o wykrycie brakujących funkcji, o możliwość demonstracji pracującej wersji systemu, o możliwość szkoleń, zanim zostanie zbudowany pełny system. Wady: o może powodować zbytnie wydłużenie realizacji projektu, gdyż klient wciąż będzie wprowadzał jakieś modyfikacje do systemu, Model realizacji przyrostowej – po etapie określenia wymagań zostaje stworzony ogólny projekt systemu. Następnie wymagane funkcje zostają podzielone na zestawy i realizowane przyrostowo, tzn. po zrealizowaniu jednego zestawu funkcji realizowane są następne, i tak, aż do realizacji całego projektu. Zalety: o skracanie przerw w kontaktach z klientem, o możliwość wczesnego wykorzystania dostarczonych fragmentów systemu, • 2 • Model oparty na montażu z gotowych komponentów . z których najczęściej stosowane są dwie: YourdonaDeMarco i Gane'a-Sarsona. osoby. Wady: o dodatkowy koszt związany z niezależną realizacją fragmentów systemu. o narzucenie standardów. Na podstawie tego fundamentalnego dowodu Dijkstra w latach 1968-1972 stworzył teoretyczne podstawy programowania strukturalnego.źródło lub przeznaczenie danych – zewnętrzne obiekty. Gotowe elementy mogą być wykorzystane na różnych etapach realizacji przedsięwzięcia. z którymi system komunikuje się. Natomiast trudności pojawiają się przy powiązaniu i zestrojeniu ze sobą opracowanych oddzielnie modułów . Podstawy teoretyczne programowania strukturalnego dali Bohm i Jacopini w 1966r. Wady: o dodatkowy koszt przygotowania elementów ponownego użycia. Wyróżniki podejścia strukturalnego. czyli określenie algorytmów miedzy nimi. • • • • proces (funkcja) . jednostki organizacyjne itp.podstawowe narzędzie reprezentacji modelu funkcjonalnego projektowanego systemu. Podejście strukturalne polega na rozłożeniu problemu na składowe i ustaleniu powiązań między nimi. a następnie zintegrowaniu tych składników dla opracowania użytecznego rozwiązania problemu Cechy podejścia strukturalnego: hierarchiczna struktura projektu (top-down design) podział projektu na moduły Podejście strukturalne składa się z dwóch etapów: • analizy – definiowanie modelu logicznego systemu. które muszą być przechowywane w systemie przez określony czas terminator (obiekt zewnętrzny) .działalność realizowana w systemie przekształcająca dane wejściowe w wynikowe. Tworzenie DFD opiera się na czterech kategoriach pojęciowych. na określenie. o ryzyko uzależnienia się od dostawcy. działy. Specyfikacje procesów – definiowanie mechanizmów transformacji danych wejściowych w wyjściowe.o możliwość elastycznego reagowania na opóźnienia. tj. w jaki sposób wystąpienie jednych zdarzeń wpływa na zmianę innych a w rezultacie na zmianę całego systemu. Metodyki. oznaczenia i zalecenia przy tworzeniu diagramu DFD DFD . są to: o o Diagramy ERD (Entity-Relationship Diagram). 3 . Zalety: o wysoka niezawodność. szczegółowa specyfikacja zadań i funkcji realizowanych przez system wyrażana przeważnie przez graficzne języki opisu takie jak: o Diagramy FHD (Function Hierarchy Diagram) o Diagramy DFD (Data Flow Diagram). o Diagramy przejść stanowych – pozwalają na modelowanie dynamiki systemu tzn. o mała elastyczność.powiązanie między procesami i innymi kategoriami DFD. 4. o zmniejszenie ryzyka. formalizacja wymagań użytkownika. magazyn) .kładzie nacisk na możliwość redukcji nakładów poprzez wykorzystanie podobieństwa tworzonego oprogramowania do wcześniej tworzonych systemów oraz wykorzystanie gotowych komponentów dostępnych na rynku. 3. • projektowanie – powstanie fizycznego modelu procesu Zaletą projektowania strukturalnego jest podział przedsięwzięcia projektowego na mniejsze części. przepływ danych .kolekcja danych. składnica (zbiór. Istnieje kilka konwencji graficznych. nie interesują nas przepływy miedzy obiektami zewnętrznymi. zgodnie z regułami: • każdy poziom powinien zawierać nie więcej niż połowę ogólnej liczby procesów i składów danych w systemie. przypisanie jednoznacznych nazw do wszystkich elementów na diagramie. unikanie nadmiernie złożonych diagramów by zapewnić spójność miedzy diagramami i diagramami a hierarchią danych Realizację DFD rozpoczynamy od utworzenia diagramu kontekstowego reprezentującego cały system w postaci jednego procesu wraz z zewnętrznymi terminatorami powiązanymi z nim przepływami. już na etapie projektowania można przeprowadzić oprócz identyfikacji poszczególnych struktur danych ich wstępną normalizację (sprowadzenie do kolejnych postaci normalnych). • prosty system powinien zawierać nie więcej niż 2-3 poziomy. niższym poziomie. oznaczenia i zalecenia przy tworzeniu diagramu ERD Podstawową funkcją diagramu ERD jest przejrzyste przedstawienie modelu danych. Metodyki. • przepływy wchodzące i wychodzące z procesu na jednym poziomie muszą odpowiadać przepływom wchodzącym i wychodzącym z całego diagramu na następnym. żadne dane nie wykorzystywane przez proces nie mogą do niego wpływać . Notacja graficzna: Pracownik o słaba – jest to encja. każdy proces musi mieć przynajmniej jedno wejście i wyjście . nie ma przepływów miedzy składnicami danych a obiektami zawietrznymi. duży do 8 poziomów. konsekwentnie używać symboli i nazw. Notacja graficzna: 4 . średni 3-5. 5. który jest rozwinięciem tego procesu (bilansowanie względem DFD). o którym informacja powinna być znana albo utrzymywana (częściowe uczestnictwo w związku). • nie wszystkie procesy muszą być rozwijane do tej samej liczby poziomów.oznacza dowolny znaczący element. Dzięki temu. Następnie rozwijamy poszczególne procesy na podpoziomy. gdy jest związana z innymi encjami lub też nie posiada własnych atrybutów kluczowych (całkowite uczestnictwo w związku) Notacja graficzna: Sprzęt o obiekt asocjacyjny – przechowuje informacje o związku pomiędzy dwiema encjami. gdyż zmiany na etapie projektu nie wymagają zmian w kodzie aplikacji. która może istnieć tylko wtedy.Zasady • • • • • • • • tworzenia (modelowania) systemu za pomocą diagramów przepływów danych: uporządkowanie diagramów w hierarchię. Umożliwia to zmniejszenie kosztów wdrożenia. Podstawowe komponenty diagramu ERD to: • typy obiektów (encji): o regularna . ). Warto dodać. a ponadto każda kolumna. o typy relacji: a) 1:1 (jeden-do-jeden) b) 1:M (jeden-do-wiele) c) M:N (wiele-do-wiele) o opcjonalność: związek wymagany (obowiązkowy) – wszystkie wystąpienia encji muszą uczestniczyć w związku. Oznacza to. Nazwa relacji wraz z nazwami połączonych z nią obiektów stanowi zdanie o określonym znaczeniu. modelowanie tablic. dekompozycja relacji nie prowadzi do utraty informacji. A zatem tabela musi spełniać warunki drugiej postaci normalnej. Druga postać normalna . sięgająca poza trzecią postać normalną. aby w kolumnach były tylko wartości elementarne oraz aby w trakcie przekształceń nie utracić żadnej informacji. Etapy projektowania ERD: ustalenie kluczy głównych i obcych. Dlatego schemat relacji musimy tak przekształcić. dlatego trzecia postać normalna jest zupełnie wystarczająca dla tabel bazy danych. Pierwsza postać normalna wymaga. które nie uczestniczy w związku. niebędąca kluczem.Wypożyczenie • relacje . aby wszystkie wartości jej kolumn były elementarne(niepodzielne. są to pojedyncze wartości określonego typu. wszystkie zależności funkcyjne są reprezentowane w pojedynczych schematach relacji. W praktyce stosuje się relacje w trzeciej postaci normalnej jako optymalne do zaprogramowania systemu baz danych. Dekompozycja relacji.to nazwane powiązania pomiędzy dwoma obiektami. Trzecia postać normalna . związek opcjonalny – jeśli istnieje przynajmniej jedno wystąpienie encji. 6. że współczesne systemy baz danych dobrze obsługują klucze złożone. Celem normalizacji jest uzyskanie optymalnej struktury bazy danych. normalizacja danych. Problematyka normalizacji schematu relacyjnego Normalizacja relacji jest to proces. prowadzi na ogół do utworzenia bardzo skomplikowanego modelu. musi być niezależna od pozostałych kolumn niekluczowych.aby tabela była w tej postaci każda z jej kolumn musi być całkowicie zależna od klucza głównego i niezależna od pozostałych kolumn. którego implementacja może być nieopłacalna. Rozróżniamy pięć kolejnych postaci normalnych relacji. relacje między tabelami mogą być tylko typu jeden do jeden lub jeden do wielu. niebędącej kluczem muszą być jednoznacznie identyfikowane przez klucz główny tabeli. podczas którego schematy relacji posiadające niepożądane cechy są przekształcane na mniejsze schematy relacji o pożądanych własnościach. Proces normalizacji musi spełniać następujące warunki: • • żaden atrybut nie zostanie zagubiony w trakcie normalizacji. • • 5 . że elementy każdej kolumny tabeli. a nie zbiory wartości. jeśli klucz ten składa się z wielu kolumn.aby tabela przyjęła taką postać musi być w pierwszej postaci normalnej i każda z jej kolumn musi być w pełni zależna od klucza głównego i od każdego atrybutu klucza głównego. jaki typ obiektu jest wskazywany przez wskaźnik lub referencję.0). Jeżeli działający program ma być pewnym tworem przetwarzającym informację . Projektowanie obiektowe to metodyka projektowania programów komputerowych.elementów łączących stan (czyli dane) i zachowanie (czyli procedury. interakcji: 6 . Największym atutem projektowania oraz analizy obiektowej jest zgodność takiego podejścia z rzeczywistością. Początkowo język był wspierany głównie przez firmę Rational. • • • aktywności (czynności). Pojęcia podstawowe: • Obiekt – jest to struktura zawierająca: o argumenty (dane). Z reguły obiekty (a właściwie klasy. czyli jakby zamknięcie ich w kapsule. • struktur połączonych • wdrożeniowe: o komponentów. a jednocześnie niezależnych od implementacji. Każdy obiekt ma 3 cechy: o tożsamość – czyli cechę umożliwiającą jego identyfikację i odróżnienie od innych obiektów. obecnie opiekuje się nim OMG (Object Management Group). o stan – czyli aktualny stan danych składowych. dynamiki. o metody (funkcje). o zachowanie – czyli zestaw metod wykonujących operacje na danych. polegające na ograniczeniu zakresu cech manipulowanych obiektów wyłącznie do cech kluczowych dla algorytmu. tu: metody). • pakietów. o rozlokowania. komunikujących się pomiędzy sobą w celu wykonywania zadań. Enkapsulacja – polega na ukrywaniu pewnych danych składowych lub metod obiektów danej klasy tak. wyróżnia się 13 diagramów głównych oraz 4 abstrakcyjne (struktur. która definiuje programy za pomocą obiektów . do których te obiekty należą) są konstruowane tak. wdrożeniowe i interakcji). • • Abstrakcja – to pewnego rodzaju uproszczenie rozpatrywanego problemu. • • 8. • Metoda – funkcja składowa klasy. Co to jest UML? Na przykładach objaśnić najważniejsze diagramy UML UML (Unified Modeling Language) – ujednolicony język modelowania. Dziedziczenie porządkuje i wspomaga polimorfizm i enkapsulację dzięki umożliwieniu definiowania i tworzenia specjalizowanych obiektów na podstawie bardziej ogólnych. Twórcami języka UML są: Grady Booch. Takie zamknięcie danych nazywa się enkapsulacją. Dziedziczenie – to operacja. gdzie dane i procedury nie są ze sobą bezpośrednio związane. Jamek Rumbaugh i Ivar Jacobson (nazywani często „trzej amigos”). Diagramy struktury: • klas. która powoduje przeniesienie danych i metod z klasy bazowej do potomnej. W najnowszej wersji języka UML (2. Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów. co zabezpiecza je przed niechcianymi modyfikacjami. Podejście to różni się od tradycyjnego programowania strukturalnego. której zadaniem jest działanie na rzecz określonych elementów danej klasy lub klas z nią spokrewnionych. maszyny stanowej.tym lepiej będzie z nią współpracował (tym bardziej będzie zrozumiały). w której żyjemy .pewnym modelem rzeczywistości . jest to język formalny służący do opisu świata obiektów w analizie obiektowej oraz programowaniu obiektowym. Diagramy dynamiki: • przypadków użycia. Podejście obiektowe – pojęcia wstępne.to im bardziej ten twór będzie naśladował rzeczywistość.7. • obiektów. Polimorfizm – to wykazywanie przez metodę różnych form działania w zależności od tego. aby były one (i ich modyfikacja) dostępne tylko metodom wewnętrznym danej klasy lub funkcjom z nią zaprzyjaźnionym. aby dane przez nie przenoszone były dostępne wyłącznie przez odpowiednie metody. rozdzielanie wariantów zachowania – stosujemy. Atrybuty. gdy przypadek użycia uwzględnia dwa lub więcej diametralnie różnych scenariuszy.jest stopniowo wzbogacany o elementy opisu niezbędne dla prawidłowej specyfikacji modelu. iż obiekty jednego elementu są powiązane z obiektami innego. rozpoczyna się przeważnie od tworzenia diagramów w następującej kolejności: • przypadków użycia. Są to najczęściej wykorzystywane diagramy. Asocjacje: • są głównym rodzajem związków między klasami • stanowią one związek strukturalny. do którego dana klasa należy. • pakietowy (~) – wartość domyślna – tylko składowe pakietu. Strzałkę prowadzimy od przypadku wyjątkowego do przypadku bazowego. w których może zachodzić potrzeba udokumentowania relacji między przypadkami użycia: • wielokrotne użycie przypadków – stosujemy aby pokazać w jaki sposób system może korzystać z istniejących już wcześniej komponentów lub pokazać wspólne funkcje dla różnych przypadków użycia. • aktywności. Diagram przypadków użycia. zobowiązania. że w zależności od okoliczności mogą wydarzyć się różne rzeczy. mają dostęp do atrybutu lub operacji. jak również operacje mogą posiadać różny poziom widoczności. • chroniony (#) – wyłącznie obiekty klas dziedziczących mają dostęp do atrybutu lub operacji. 10. Są względnie łatwe w czytaniu nawet bez znajomości notacji.o sekwencji. Aktorem nie zawsze musi być człowiek (może to być np. Relację tą oznaczamy przerywaną strzałką z otwartym grotem wraz z etykietą <<include>>. • publiczny (+) – obiekty wszystkich klas mają dostęp do atrybutu lub operacji. jakie powinien dostarczać swoim użytkownikom). Diagram klas Diagramy klas służą do obrazowania statycznych aspektów perspektywy projektowej. zwłaszcza przy budowaniu niedużych systemów informatycznych. o scharakteryzowane poprzez role klas pełnione w asocjacji. • prywatny (-) – tylko obiekty danej klasy mają dostęp do atrybutu lub operacji. Relację tą oznaczamy przerywaną strzałką z otwartym grotem wraz z etykietą <<extend>>. • sekwencji. W diagramach przypadków użycia występują: • aktorzy – są kimś w rodzaju użytkowników systemu. aby pokazać. o nienazwane. Pozostałe bywają pomijane. jeśli aktor może współdziałać z systemem w celu odegrania jakiejś roli w zadaniu. zestawu atrybutów oraz zestawu operacji.zawiera wyłącznie podstawowe elementy. Każda klasa składa się z nazwy. Aktora i przypadek użycia łączy linia. takie jak np. Istnieją dwa główne rodzaje sytuacji. 9. o sterowania interakcją. o harmonogramowania. o komunikacji. inny system informatyczny). • klas. Projektując system informatyczny. • mogą być: o nazwane. oznaczają coś zewnętrznego wobec systemu. widoczność i zależności. • implementacyjny . 7 . Diagramy przypadków użycia dokumentują zachowanie systemu z punktu widzenia użytkownika. • • liczebność asocjacji określa liczbę obiektów jednej klasy pozostających w związku z pojedynczym obiektem klasy powiązanej. • przypadki użycia – określają zadania jakie muszą być wykonywane przez projektowany system. Strzałka prowadzi od bazowego przypadku użycia do szczegółowego. w której bierze się pod uwagę wymagania funkcjonalne systemu (usługi. iż źródłowy przypadek użycia zawiera docelowy przypadek. atrybutów i operacji. Poziomy tworzenia diagramów klas: • konceptualny . który wskazuje. cechując się przystępnością nazewnictwa klas. typy danych. co oznacza. Diagram pakietów Diagram pakietów służy do tego. przedstawia się nie same klasy. byłyby poprawne. konfiguracjami czy modyfikowaniem elementów systemu. zwłaszcza. obiekty. Zwykle zawiera wewnątrz drzewo pakietów. Nazwy elementów na diagramach są podkreślone. Na tej linii od strony całości umieszczamy romb. Całość z komponentami łączona jest za pomocą linii. Posiada dobrze wyspecyfikowany zbiór interfejsów. zarówno nazwa Jan. co oznacza. a instancje (wystąpienia) klas. uwzględniający zbiór obiektów.Diagram obiektów Diagram obiektów należy do diagramów statyki. Diagram struktur połączonych Przedstawia hierarchicznie wewnętrzną strukturę złożonego obiektu z uwzględnieniem punktów interakcji (wzajemnego oddziaływania) z innymi częściami systemu.obiekty-segmenty będące częściami agregatów nie mogą samodzielnie i niezależnie funkcjonować. podsystem (<<subsystem>>) . a także inne pakiety).usunięcie obiektu będącego agregatem nie powoduje likwidacji obiektów będących jego częściami. widzianą z pewnej perspektywy. że są one instancjami. Nazwa pakietu znajduje się na zakładce albo wewnątrz prostokąta. gdy możliwe powiązania miedzy obiektami są skomplikowane. czyli obiektów-segmentów. to wystąpienie diagramu klas. Elementy składowe diagramu: • klasyfikatory – obejmują i uogólniają klasy. ich stan oraz związki.• agregacja asocjacji . przypadki użycia.jest rodzajem pakietu. by uporządkować strukturę zależności w systemie. Specjalne rodzaje pakietów: • • • fasada (<<fasade>>) . dzięki temu łatwiej jest ocenić jakość i stopień powiązań między nimi. Na diagramie obiektów przedstawia się egzemplarze elementów z diagramu klas. JanKowalski:Osoba). 13. • można umieścić w nich dowolne elementy (klasy. dobrze wyizolowany fragment systemu. komponenty. który reprezentuje pewien spójny. ułatwiają zarządzanie przechowywaniem.zawiera wyłącznie odwołania do elementów zdefiniowanych w innych pakietach. model . do interakcji z otoczeniem. Diagramy obiektów mogą być użyte do pokazania przykładowej konfiguracji obiektów. • każdy pakiet musi mieć przypisaną swoją (niepowtarzalną) nazwę. węzły i inne współdziałania. niezależnie od agregatu. ułatwiają zarządzanie procesem konstrukcji produktu programistycznego. • interfejsy: 8 . Obiekty współdzielone mogą zatem funkcjonować samodzielnie. jak i nazwa :Osoba (obiekt anonimowy). tzn. Wyróżniamy agregację: o całkowitą . Jeden pakiet jest zależny od drugiego. jednak obie części tej nazwy są opcjonalne. jeśli zmiany w drugim pakiecie mogą wymusić zmiany w pierwszym. • składniki (części) – pełnią we współdziałaniu określone role. odwzorowujące strukturę systemu w wybranym momencie jego działania. Przydatne są. Są środkiem ogólnego zastosowania przeznaczonym do budowania struktur hierarchicznych.jest powiązaniem między klasą a jej komponentami nazywanym związkiem całość-część.stanowi mniej lub więcej kompletną abstrakcję systemu (na pewnym poziomie szczegółowości). Inaczej mówiąc. Każda nazwa ma postać nazwaInstancji:nazwaKlasy (np. Właściwości pakietów: • stanowią zgrupowanie elementów modelu. Pakiety to prostokąty z małymi zakładkami na górze. 12. • • • doskonale potrafią pokazać zależności pomiędzy częściami systemu. o częściową . 11. logiczny. operacje. Strzałki z przerywanymi liniami to zależności. Jest to rzut systemu w danej chwili. które mogą być umieszczane na węzłach. Komponenty (programy.. itp. Diagram komponentów jest przedstawiany jako graf. Mogą także pokazywać wszelkie obecne lub planowane zależności pomiędzy jednym systemem a innymi. Zależności między komponentami pokazują jak zmiany jednego komponentu wpływają na inne. biblioteki. aplikacja internetowa).zależności) prowadzą od klienta pewnej informacji do jej dostawcy. które łączy różne maszyny. oraz oprogramowanie pośredniczące. Diagram pakietów koncentrował się na podziale systemu z logicznego punktu widzenia. • • file – określa komponent reprezentujący dokument zawierający kod źródłowy lub dane. pliki) to fizyczne opakowanie bytów logicznych (klas. Diagram rozlokowania umożliwia modelowanie rozmieszczenia infrastruktury sprzętowej oraz platform ubytkowania systemu. Rodzaj zależności jest zależny od typu języka programowania. Strzałki oznaczające zależności mogą prowadzić od komponentu do interfejsu Dobrze skonstruowany komponent korzysta z innych komponentów wyłącznie za pośrednictwem ich interfejsów. tzn. Diagram komponentów Diagram komponentów robimy z podobnych powodów. reprezentujące zarówno oprogramowanie jak i komponenty maszyny.• konektory składane – połączenie interfejsu udostępniającego i interfejsu pozyskującego • porty – zapewniają komunikację obiektu ze światem zewnętrznym. gdzie węzłami są komponenty. Innymi słowy pokazuje nam cały hardware. do pokazania jak współpracuje ze sobą oprogramowanie z komponentami maszyny. Fizyczne węzły powinny być oznakowane stereotypem <<device>>. • Wyspecyfikowanie połączeń. Stereotypy komponentów: • executable – określa komponent. służą do modelowania elementów fizycznych. • table – określa komponent reprezentujący tabelę bazy danych. 9 . diagram komponentów z kolei dzieli system na fizyczne elementy oprogramowania: pliki. Diagram rozlokowania przedstawia węzły systemu (stacje robocze. biblioteki. jak również ich ról. który można wykonać na węźle. serwery). który przedstawia fizyczną lub logiczna strukturę systemu (w konkretnych modułach sprzętowych) wraz ze ścieżkami interakcji zachodzącymi pomiędzy nimi. Tworzenie diagramu: • Określenie zakresu i nazwy współdziałania. Poszczególne komponenty mogą istnieć w różnym czasie: niektóre z nich w czasie kompilacji. zaś strzałki (z przerywaną linią .wymienna cześć systemu. • library – określa dynamiczną lub statyczną bibliotekę obiektów. na których przedstawiono wdrożone elementy systemu informatycznego (baza danych. • Przypisanie klasyfikatorów do opracowanego współdziałania oraz wskazanie konkretnych jego wystąpień 14. realizująca pewien zbiór interfejsów. 15. oprogramowanie. niektóre w czasie konsolidacji (linking) zaś niektóre w czasie wykonania. kooperacji). co diagram pakietów – chcemy podzielić system na prostsze elementy i pokazać zależności między nimi. Diagram może także pokazywać interfejsy poszczególnych komponentów. Obrazują główne rozmieszczenie/powiązanie aplikacji biznesowych. Diagramy te mogą być tworzone do odkrywania architektury wbudowanych systemów. obiektów itp. document – określa komponent reprezentujący dokument. Komponent . które jest zainstalowane na nim. co z założenia ułatwia przyszłe modyfikacje. Diagram rozlokowania Diagram rozlokowania to rodzaj diagramu wdrożeniowego. • Identyfikacja poszczególnych części: klas. Węzły reprezentowane są przez trójwymiarowe kwadraty. Są one oznaczane przy użyciu symbolu koła z wpisanym znakiem ‘x’. w jaki sposób system będzie osiągał swoje zamierzone cele. podstanów oraz obszarów współbieżnych. koncentrując się na procesach. Zachowanie dyskretne maszyny stanowej należy interpretować jako stany i przejścia między nimi organizowane w sekwencję stan-przejście-stan. Sygnały są komunikatami. a nie całą czynność. np. Diagram sekwencji 10 . Pomiędzy węzłem początkowym a końcowym czynności występują akcje obrazowane za pomocą prostokątów o zaokrąglonych narożnikach. 17.odpowiada blokowi instrukcji typu if-else w kodzie programu. • zidentyfikowanie poszczególnych stanów maszyny stanowej. sterowanie interakcjami GUI itp. • • • • połączenia . • lokalne. • zewnętrzne. Wykonanie czynności rozpoczyna się w jej węźle początkowym przedstawionym pod postacią wypełnionego koła. • podlegają prostym regułom i są łatwe do weryfikacji. przedstawiają dozwolone przejścia pomiędzy stanami tego obiektu. • określanie hierarchii stanów. oznaczając w ten sposób koniec zachowania warunkowego. Klasyfikacja stanów: • proste. Diagramy czynności umożliwiają określenie tego. podsystemu. • automatyczne. • złożone. protokoły komunikacji. Algorytm tworzenia diagramu: • określenie rodzaju tworzonej maszyny stanowej i identyfikacja obiektów. • umożliwiają generację kodu. Klasyfikacja przejść: • proste. • szeroki zakres zastosowań. rozwidlenia oraz scalenia – w celu zobrazowania kroków. • zastosowanie adekwatności pseudostanów. które zachodzą w tym samym czasie. Diagram maszyny stanowej Diagram maszyny stanowej jest odzwierciedleniem dyskretnego. • zwrotne. Zalety diagramu maszyny stanowej: • są bardzo potężnym sposobem opisu i implementacji logiki sterującej aplikacji. Diagramy czynności modelują dynamiczne zachowanie systemu. • powiązanie stanów oraz ich podstanów przejściami. • podstany. Podział maszyn stanowych: • • protokołowe – koncentrują się na konkretnym obiekcie. • wewnętrzne. skokowego zachowania się skończonych systemów stan – przejście (obiekty użytkowane w systemie przechodzą w trakcie swojego cyklu życia przez szereg kolejnych stanów).łączy ze sobą krawędzie wychodzące z węzła decyzyjnego. Węzeł początkowy oznacza najzwyczajniej początek czynności. z których środkowe jest wypełnione.. • złożone. 18..16. przypadku użycia i innych obiektów. W diagramach czynności występują również: • węzły decyzyjne . węzły końcowe przepływu – kończą jedynie własną ścieżkę. zachowania – przedstawiają przejścia między stanami obiektów w szerszym niż w protokołowych maszynach stanowych kontekście zachowania systemu. • opracowanie specyfikacji sekcji stanów i przejść zgodnie z przyjętymi składniami. które mogą być nadawane lub odbierane. Diagram czynności Diagramy czynności obrazują przepływy sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności. akcji i obiektów. Przepływ czynności przedstawiony jest przy użyciu strzałek nazywanych krawędziami lub ścieżkami. Na drugim końcu diagramu występuje węzeł końcowy czynności oznaczający jej koniec i przedstawiony pod postacią dwóch koncentrycznych kół. węzły sygnału odbieranego lub wysyłanego – reprezentują interakcję z zewnętrznymi uczestnikami.. • przeniesienie lub dobór obiektów/aktorów. • zdecentralizowany . im późniejsza chwila wysłania. Na osi poziomej znajduje się skala czasu. • 11 .jeden z obiektów kontroluje cały przebieg przypadku. nazwa stanu. • identyfikacja stanów każdego obiektu z wykorzystaniem diagramów maszyny stanowej. Do sporządzenia harmonogramów interakcji dostępne są dwie notacje: • czasowa (klasyczna). poprzednik. Komunikaty są uporządkowane w czasie wzdłuż osi Y.pionowe przerywane kreski reprezentujące czas istnienia obiektów. specyfikującym strukturalne związki pomiędzy instancjami klasyfikatorów biorącymi udział w interakcji oraz wymianę komunikatów pomiędzy tymi instancjami. Na osi pionowej obiekty lub aktorzy. tym komunikat umieszczony niżej. współbieżnik. 20. Sposoby współpracy obiektów: • scentralizowany . • wprowadzenie zdarzeń na podstawie diagramów maszyny stanowej. tak jak to ma miejsce w diagramach sekwencji. umieszczone są obiekty uczestniczce w interakcji. a coraz bardziej podrzędne kolejno po prawej.wyrażoną za pomocą asocjacji. Zaawansowane składniki diagramu: • • • • • • izomorfizm diagramów sekwencji i komunikacji. • zadaniowa (alternatywna) Elementy diagramu harmonogramowania to: • klasyfikator. steruje operacjami i pośredniczy w wymianie danych.nie ma obiektu kontrolującego i obiekty komunikują się ze sobą bezpośrednio.Diagram sekwencji jest połączeniem między światem funkcjonalnym i obiektowym. Celem tego diagramu jest badanie zachowania jednego lub więcej obiektów w pewnym przedziale czasowym. Są stosowane do określenia przepływów zdarzeń wyszczególnionych w scenariuszach adekwatnego przypadku użycia oraz zależnych wewnętrznych interakcjach systemu. Konieczne jest wprowadzenie numeracji porządkowej. Obiekt inicjujący interakcję znajduje się zazwyczaj po lewej stronie diagramu. • wprowadzenie ograniczeń czasowych dla poszczególnych stanów. które odróżniają je od diagramów komunikacji: • linie życia obiektów . obiekty wielokrotne. zagnieżdżenie. Proces tworzenia diagramu przebiegów czasowych: • identyfikacja interakcji i jej diagramu sekwencji lub diagramu komunikacji. klasy aktywne. Diagram harmonogramowania Diagram harmonogramowania jest używany do pokazywania interakcji między obiektami. • uwzględnienie ośrodka sterowania . • ewentualne wprowadzenie komunikatów. Odpowiada konkretnemu scenariuszowi danego przypadku użycia. wzdłuż osi X.podłużny. Diagram komunikacji zawiera dwa ściśle powiązane ze sobą składniki: • strukturalną organizację klasyfikatorów . 19. • linia zmiany stanów klasyfikatora. • numeracja kwalifikowana – system klasyfikacji dziesiętnej Deweya. Diagram komunikacji Diagram komunikacji jest rodzajem diagramu interakcji. ponieważ kolejność wysyłania komunikatów nie wynika z ich naturalnego uporządkowania na osi czas. • określenie linii zmiany stanów obiektów. Główny nacisk położony jest na uwypuklenie kolejności komunikatów w czasie. • interakcję między instancjami . • harmonizacja linii zmiany stanów wszystkich obiektów.realizowaną za pośrednictwem komunikatów – w ujęciu graficznym przyporządkowanych do asocjacji łączących klasyfikatory. Diagramy sekwencji mają dwie cechy. • ustalenie przedziału czasowego diagramu. Wyróżnić można następujące rodzaje numeracji: • numeracja prosta – w postaci kolejnych liczb naturalnych. W górnej części diagramu sekwencji. cienki prostokąt reprezentujący okres wykonywania przez obiekt jakiejś akcji. jakie elementy powinno zawierać? Feasibility study – studium możliwości – pierwszy etap w każdym cyklu projektowym. istotnych dla analityka • Zakresy odpowiedzialności • Limit czasu • Określenie nieprzekraczalnych kosztów Cele studium: • Ocena. Diagram sterowania interakcją Diagram sterowania interakcją dokumentuje przepływ sterowania między powiązanymi logicznie diagramami i fragmentami interakcji Na diagramie sterowania interakcją znajdują się: • podstawowe oraz wybrane zaawansowane elementy diagramów czynności. arkusze kalkulacyjne. 12 . • wybrane kategorie pojęciowe poszczególnych diagramów interakcji. socjologicznie oraz ekonomicznie przyczyny wprowadzenia zmian • Upewnienie się. • przeanalizowanie wzajemnych zależności między tymi diagramami. • Ocenę rozwiązań. że pod hasłem tym kryją się wszelkie narzędzia komputerowe wykorzystywane w trakcie prac nad oprogramowaniem. debuggery edytory tekstu. komunikacji itp. że system będzie do zaakceptowania przez użytkownika • Sporządzenie dostatecznie dokładnej specyfikacji proponowanego systemu. tj. Powinno odpowiadać na takie pytania jak: • czy system będzie odporny na czas? • czy cele nie są we wzajemnym konflikcie? • czy cele mogą ulec zmianie? • kto i jak zostanie poddany wpływowi systemu? Studium możliwości powinno zawierać 3 fazy: • Zdefiniowanie zadania. Co to jest feasibility study. przykłady. o fragmentów interakcji (cd. które: • wspomagają ogólnie rozumiane wytwarzanie oprogramowania. tak aby mogła stanowić bazę do negocjacji z twórcami przyszłego systemu i dostawcami Przyczyny wprowadzenia studium: • Identyfikacja ludzi odpowiedzialnych za określenie celu systemu • Identyfikacja wad i niedostatków aktualnego systemu informatycznego • Ustalenie celów i ograniczeń nowego systemu • Określenie wykonalności systemu z podaniem kilku scenariuszy • Określenie lidera projektu 23. diagramów sekwencji. struktura. Termin CASE (Computer Assisted/Aided Software/System Engineering) oznacza komputerowo wspomaganą inżynierię oprogramowania/systemów. narzędzia harmonogramowania przedsięwzięć. • opcjonalne wymienienie w nagłówku diagramu sterownia interakcją nazw instancji klasyfikatorów biorących udział w interakcji. • Przekształcenie strategii w założenia projektowe systemu informatycznego. • opracowanie kompletnego diagramu sterowania interakcją z wykorzystaniem podstawowych jak i zaawansowanych kategorii pojęciowych. td) dla miej obszernych diagramów. Proces tworzenia diagramu sterowania interakcją: • zgromadzenie wszystkich dotychczasowych diagramów interakcji dla danego przypadku użycia. 22. a więc także kompilatory. W pierwszej fazie powinny znaleźć się: • Opis zadania • Sformułowanie celów • Podanie kryteriów oceny • Podanie ograniczeń i uwarunkowań zewnętrznych. Tradycyjnie jednak pod pojęciem CASE rozumie się narzędzia. sd. itp. • kwalifikacja tych diagramów do: o przywołanych wystąpień interakcji (ref) w przypadku diagramów złożonych.21. Nazwa ta sugeruje. Narzędzia CASE – klasyfikacja. czy występują dostatecznie uzasadnione technicznie. • ustalenie logicznej kolejności wykonywania poszczególnych fragmentów interakcji. Przykładami są pakiety: Paradigm Plus . Narzędzia te nie są związane z konkretnym środowiskiem implementacji.koncentrujące się na fazach projektowania i implementacji. Wymagania. • Select OMT Professional. Wymagania klienta mogą być opisywane na różnych poziomach abstrakcji (ogólności): • definicja wymagań . Są to pakiety łączące w sobie możliwości narzędzi Upper-CASE i Lower-CASE. Narzędzia CASE mogą wspomagać jedną metodykę analizy i projektowania. w szczególności fazy analizy. • zapisywanie poszczególnych modeli systemu w repozytoriach. operacje) wykonywane przez system. Z drugiej strony cele klienta często można osiągnąć na wiele sposobów. Technologia CASE powinna umożliwiać • przedstawienie istniejących i realizowanych systemów w ich poszczególnych fazach cyklu życia. jakie wymagania zapewniają osiągnięcie tych celów.opisują ograniczenia. Można je podzielić na: 13 .0. • wymagania niefunkcjonalne . Do metod ułatwiających zapanowanie nad dużą liczbą wymagań możemy zaliczyć: o hierarchiczny zapis wymagań. Inne narzędzia pozwalają na stosowanie całego szeregu różnych notacji. Narzędzia CASE dzielą się na dwie główne grupy: • Upper-CASE . Opis taki jest wstępnym rezultatem rozmów z przedstawicielami klienta. jak i proste. Narzędzia te są z reguły ściśle związane z konkretnym środowiskiem implementacji. • • • System Architect .to w pełni formalny opis wymagań.koncentrują się na fazach analizy i projektowania oraz bezpośrednim wykorzystaniu wyników tych faz w implementacji. • współpracę wielu osób w ramach tego samego projektu lub nawet modelu. lecz jako proces. ich klasyfikacja.który wspomaga szeroki zakres różnorodnych notacji obiektowych. Proces określania wymagań należy więc rozumieć nie jako proste zbieranie wymagań klienta. Przykłady takich narzędzi to: • Oracle CASE. • specyfikacja wymagań . • duże systemy są wykorzystywane przez wielu użytkowników. częściowo przynajmniej sformalizowane notacje.opisują funkcje (czynności. • CASE 4. • opracowanie dokładnego i wysokiej jakości modelu systemu. że klient rzadko dokładnie wie. Ich cele są często sprzeczne. W fazie tej dokonywana jest więc zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie tych celów. • transformację. 24. czyli zamianę lub odtwarzanie modelu opracowanego na etapie jednej fazy cyklu życia na model fazy następnej. • specyfikacja oprogramowania . Narzędzia typu I-CASE uzupełnione o narzędzia wspomagające zarządzanie przedsięwzięciem programistycznym nazywane są środowiskami inżynierii oprogramowania. Wymagania wobec oprogramowania można podzielić na dwa zasadnicze rodzaje: • wymagania funkcjonalne .to ogólny opis w języku naturalnym. który pozwala na stosowanie tej metodyki. W efektywny sposób wspomagają one wykonywanie praktycznie wszystkich faz produkcji oprogramowania. w którym klient wspólnie z przedstawicielami producenta (analitykami) konstruuje zbiór wymagań wobec systemu zgodny z postawionymi celami. • Lower-CASE . Trudności określania wymagań wynika z następujących czynników: • klient z reguły nie wie dokładnie w jaki sposób osiągnąć założone cele.koncentrujące się na wspomaganiu wczesnych faz pracy nad oprogramowaniem. przy których system musi realizować swoje funkcje. • objectiF. Obecnie większość producentów pakietów CASE określa swoje produkty jako narzędzia I-CASE (Integrated-CASE). Oferują one spójny zestaw notacji.to częściowo ustruktualizowany zapis wykorzystujący zarówno język naturalny. o diagramy przypadków użycia. Należy pamiętać. • EasyCASE. metody (techniki) użyteczne przy formułowaniu wymagań Wymagania klienta wobec tworzonego systemu są opisywane w fazie określania wymagań. • zleceniodawcy i użytkownicy to często inne osoby.który wspomaga szereg notacji strukturalnych i obiektowych. Liczba wymagań funkcjonalnych może być bardzo duża. której język maszynowy służy do implementacji następnego poziomu maszyny abstrakcyjnej. Projektując interfejs można uwzględnić następujące sposoby interakcji: 14 .układa system w ciągi warstw. • Zdatność do pielęgnacji. • Dostępność. wymagania dotyczące procesu (np. systemy zarządzania informacjami. identyfikuje się podsystemy.pozwala na kontaktowanie się użytkownika z komputerem poprzez sekwencje znaków alfanumerycznych. Projektowanie interfejsu użytkownika Interfejs użytkownika: • Dobry projekt interfejsu użytkownika jest niezbędnym warunkiem prowadzenia systemu.najważniejszym elementem graficznego interfejsu jest okno programu. • Jeśli informacja jest przedstawiona w sposób zagmatwany i mylący. Obecnie istnieją następujące rodzaje interfejsów znakowych: o dialog pytanie-odpowiedź o język poleceń o język naturalny • graficzny (GUI – Graphical User Interface) . wewnątrz takiego okna są rozmieszczone elementy interakcyjne. o Sieć. • Zabezpieczenie. Architektura systemu ma wpływ na efektywność. Różne graficzne modele systemu przedstawiają rozmaite perspektywy architektury.jest przystosowany do zastosowań. Pierwsza faza projektowania architektonicznego – podział systemu na zbiór oddziałujących ze sobą podsystemów. Użytkownik komunikuje się z aplikacją pośrednio przez te widgety najczęściej za pomocą myszy i klawiatury. np systemy sterowania i kontroli. Produktem tej fazy procesu jest opis architektury oprogramowania. 26. solidność oraz zdatność do rozpraszania i pielęgnacji. ustala zrąb sterowania i komunikacji podsystemów. z których każda oferuje pewne usługi. • • maszyny abstrakcyjnej . systemy CAD i zestawy narzędzi CASE. Każda warstwa jest maszyną abstrakcyjną. a używane przez inny.. 25. • Bezpieczeństwo. Rodzaje interfejsów użytkownika: • znakowy . wymagania zewnętrzne (np. Wynikiem procesu projektowania architektonicznego jest dokumentacja projektu architektonicznego. w których dane są generowane przez jeden podsystem. w którym dane i przetwarzanie są rozdzielone między zbiór procesorów. zwane widgetami. która składa się z kilku graficznych przedstawień modeli systemu oraz tekstu opisowego. o Zbiór klientów. • Interfejs trudny w użyciu w najlepszym wypadku doprowadzi do wielu pomyłek użytkowników. użytkownicy mogą źle zrozumieć znaczenie systemu. Projekt architektoniczny można przedstawić w postaci diagramu blokowego. • klient – serwer . • W najgorszym wypadku użytkownicy po prostu odmówią używania systemu niezależnie od jego funkcjonalności. proces realizacji systemu musi być zgodny ze standardem opisanym w dokumencie XXX).jest modelem rozproszonego systemu. Projektowanie architektury (architektoniczne) Projektowanie architektury to początkowa faza procesu projektowania. musi istnieć możliwość przeglądania systemu wyłącznie za pomocą klawiatury). Wyróżniamy trzy standardowe modele: • repozytorium . system musi współpracować z bazą danych jakiegoś działu). Wybrany dla danego zastosowania styl i struktura mogą więc zależeć od wymagań niefunkcjonalnych systemu: Efektywność. Ta dokumentacja powinna zawierać opis systemu jako struktury złożonej z podsystemów i każdego podsystemu jako struktury złożonej z modułów. na którym każdy prostokąt odpowiada podsystemowi.o o o wymagania dotyczące produktu (np. Głównymi komponentami tego modelu są: o Zbiór samodzielnych serwerów. wypełnienie formularza polega na wypełnieniu odpowiednich pól w celu realizacji zadania. tym mniejsza szansa na ich przeczytanie i większa dezorientacja użytkownika 10. język poleceń np. za pomocą metafory trzeba użytkownikowi przybliżyć model programu 4.oparte na analizie kodu. których musi dokonać użytkownik 5. Pojęcie testowania. szybkości działania. umiejętności użytkownika) 7. Projektowanie interfejsu powinno odbywać się z uwzględnieniem warunków ekstremalnych musi on być użyteczny nie tylko w idealnych warunkach (oświetlenie. solidności. których celem jest wykrycie przyczyn najczęstszych błędnych wykonań oraz ocena niezawodności systemu Z punktu widzenia podstawowej techniki wykonywania testów można je podzielić na: • testy dynamiczne . Osoba pracująca z komputerem lubi mieć poczucie sprawowania kontroli nad maszyną powinno się je zapewnić za wszelką cenę Zasady projektowania interfejsu: porady dla użytkownika.czyli testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań. • • 27. Z punktu widzenia głównego celu testy można podzielić na: • wykrywanie błędów. czasami wystarczy mała grupa ludzi 3. język DOS. Jeśli nie jest znany model użytkownika.im więcej słów w oknach dialogowych. zdolności adaptacji. łatwości nauczenia.czyli testowanie zgodności systemu z rzeczywistymi potrzebami użytkownika. zdolności wycofania.które polegają na wykonywaniu programu i porównywaniu uzyskanych wyników z wynikami poprawnymi. że użytkownicy często mają kłopoty z poprawną obsługą myszy 8.nie są do tego potrzebne specjalne laboratoria.• • • • • bezpośrednie działanie np. Użytkownicy nie czytają . możliwość wycofania. • rozróżnienie użytkowników Interfejs można ocenić według: • • • • • • • • zbliżenie do użytkownika. Interfejs jest dobrze zaprojektowany wtedy. etapy i techniki testowania Mówiąc o testowaniu należy rozróżnić następujące pojęcia: • atestowanie . • weryfikacja . Należy dążyć do ograniczenia liczby opcji. jak oczekuje tego użytkownik 2. „usuń plik” 10 zasad projektowania interfejsu graficznego: 1. Nie obciążajmy pamięci użytkowników . • testy statystyczne. a co za tym idzie: liczby wyborów. Dobry interfejs w maksymalnym stopniu uwzględnia fakt. W trakcie projektowania interfejsu powinien on być testowany na użytkownikach .interfejs nie powinien wymagać zapamiętywania zbyt wielu informacji 9. • testy statyczne . Dobrze zaprojektowany interfejs zachowuje zgodność z już stosowanymi schematami (np. spójność. aby usunąć plik należy wpisać odpowiednie polecenie. skrótów klawiaturowych czy ikon) 6. wybór z menu np. gdy program zachowuje się dokładnie tak. w Windows polega na przeniesieniu obiektu do usunięcia do kosza. język naturalny użytkownik w język naturalnym wpisuje polecenia np. minimum niespodzianek. polega na wyborze z menu polecenia usuń. Testy można klasyfikować z różnych punktów widzenia. rodzaje. Testowanie systemu przebiega z reguły przez następujące fazy: 15 . polegają na integracji poszczególnych modułów i testowany jest system jako całość. • o • próbne – obejmujące wszystkie funkcje systemu ale ograniczone ze względu na objętość zbiorów. W praktyce przyjmuje się zazwyczaj. 29. 16 . Instalacja oraz wdrożenie obejmują: • instalację oprogramowania i przekazanie dokumentacji użytkowej. • nadzorowanie pilotowej eksploatacji systemu. testy systemu . • szkolenie użytkowników systemu.dotychczasowy system jest eksploatowany tak długo. strategie. system przekazywany jest do przetestowania przyszłemu użytkownikowi. wydajnościowe. efektywniejszym i mniej zawodnym. Projektanci systemu zostają zastępowani przez jego użytkowników. Tu również ujawniają się wszystkie niedoskonałości i braki wynikające z niedostatecznego dopracowania we wcześniejszych fazach cyklu życia systemu. równoległe . wdrażanie cząstkowe – mniejszy stopień ryzyka. Wzorce projektowe mogą przyspieszyć proces rozwoju oprogramowania przez dostarczenie wypróbowanych rozwiązań dla problemów. Zamiast skupiać się na funkcjonowaniu poszczególnych elementów. Podejście wygodne i mało kosztowne jednak obarczone jest dużym ryzykiem. Helma. 28. wymaga podziału na części.realizowane w przypadku oprogramowania realizowanego na zamówienie. historia. które mogą nie być oczywiste na początku procesu projektowego. wykorzystanie Termin wzorca projektowego został wprowadzony do inżynierii oprogramowania w 1995 roku w książce ‘Design Patterns’ autorstwa Gammy. system informatyczny jest w całości przekazany użytkownikowi. Poza dokładniej przedstawionymi rodzajami testów wyróżnić możemy jeszcze następujące testy: operacyjne. Wdrażanie cząstkowe możemy podzielić na: o pilotowe – ograniczone ze względu na zakres funkcjonowania systemu. Wzorce projektowe – pojęcie. ergonomiczne. przykłady. Johnsona i Vlissidesa.• • • • • • • testy modułów . działania. zaprojektowanego i oprogramowanego modelu rzeczywistości oraz dopasowanie systemu do wymagań rzeczywistości. etapem działań cyklu życia systemu. po projektowaniu. W trakcie wdrożenia następuje wprowadzenie do praktyki wcześniej opracowanego. Strategie Przyjmując jako kryterium zakres wdrożenia i metodę postępowania. W fazie wdrożenia. testy akceptacji . • usuwanie błędów w systemie. wzorce projektowe stanowią abstrakcyjny opis zależności pomiędzy klasami. możemy wydzielić następujące strategie działań: • wdrażanie całościowe (totalne) – to implementacja nowego systemu przy równoczesnej rezygnacji z eksploatacji dotychczasowego systemu. że pełna zgodność wyników przetwarzania tradycyjnego i nowego systemu w trzech kolejnych cyklach badawczych jest podstawą do zaniechania przetwarzania równoległego. • przekazanie systemu do eksploatacji. bezpośrednio po zakończeniu realizacji poszczególnych modułów. W przypadku błędów w systemie powstają znaczne dodatkowe koszy. przykłady Wdrażanie systemu jest następnym. Jest to jedno z najtrudniejszych zadań w unowocześnianiu systemu informacji.wykonywane już w fazie implementacji. Faza wdrażania – pojęcie. Proces ten jest w całości przeprowadzany w siedzibie przyszłego użytkownika systemu. Gdy system opracowywany jest dla nowej organizacji jest to jedyna możliwa strategia działania. co w efekcie doprowadza do pewnej standaryzacji kodu i czyni go bardziej zrozumiałym. dokumentacji użytkownika końcowego. aż nowy nie zostanie w pełni wdrożony. • inicjację i parametryzację systemu. a jej interfejs nie odpowiada temu. jakiego klient oczekuje. Chcemy utworzyć klasę wielokrotnego użytku. • Klasowe wzorce czynnościowe wykorzystują dziedziczenie do rozdzielania działań pomiędzy klasy. Wzorce czynnościowe . • Budowniczy.Wartość wzorców projektowych stanowi nie tylko samo rozwiązanie problemu. Ten typ wzorców jest szczególnie przydatny wtedy. co pomaga w łatwiejszym stosowaniu i adaptacji wzorców w danym zastosowaniu. Uzasadnienie stosowania: • 17 . o Fasada. Ponadto charakteryzują złożone przepływy sterowania. o Dekorator. • Do wzorców strukturalnych możemy zaliczyć taki wzorzec jak: o Adapter . Przykłady wzorców obiektowych: o Obserwator . które są trudne do prześledzenia w czasie wykonywania programu. Niektóre z nich opisują sposób współdziałania równorzędnych obiektów w grupie w celu wykonania zadania. Wzorzec Adapter stosujemy. o Pośrednik. Wzorce konstrukcyjne . Uzasadnienie stosowania: Gdy pewien rodzaj problemu pojawia się dość często. w jaki obiekty są ze sobą połączone. a nie na sposobie. a także interpreter. Dodatkowa elastyczność związana ze składaniem obiektów wynika z możliwości zmieniania obiektu złożonego w czasie wykonywania programu. o Kompozyt. ale także dokumentacja. ponieważ mają niezgodne interfejsy. którego potrzebujemy. a opisują sposoby składania obiektów w celu uzyskania nowej funkcjonalności. którego żaden z nich nie mógłby wykonać w pojedynkę. Obiektowe wzorce czynnościowe wykorzystują składnie obiektów zamiast dziedziczenia.wzorzec ten określa relacje jeden-do-wiele między obiektami. wszystkie obiekty odeń zależne są o tym automatycznie powiadamiane i uaktualniane. która wyjaśnia cel. że jeśli jeden obiekt zmienia stan. warto wyrazić egzemplarze tego problemu jako zadania w prostym języku. Oznacza to. adapter obiektów może adoptować interfejs swojej nadklasy.definiuje reprezentację dla gramatyki zadanego języka .wykorzystywane do pozyskiwania obiektów zamiast bezpośredniego tworzenia instancji klas: • Fabryka abstrakcyjna. Możemy wyróżnić 2 takie wzorce: o Interpreter . Potrzebujemy użyć kilku istniejących podklas.nie wykorzystują składania interfejsów lub implementacji. Wzorce czynnościowe dotyczą algorytmów i przydzielania zobowiązań obiektom.służą do zdefiniowania komunikacji pomiędzy obiektami oraz kontrolowania przepływu danych w złożonej aplikacji. który wykorzystuje tę prezentację do interpretowania zdań w zadanym języku. co bez niego nie było możliwe. o Łańcuch odpowiedzialności. ale zaadoptowanie ich interfejsów przez tworzenie ich podklas jest niepraktyczne.wykorzystują dziedziczenie do składania interfejsów lub implementacji. to znaczy takimi. Dzięki Adapterowi klasy mogą współpracować. • Metoda fabrykująca.pomagają łączyć obiekty w większe struktury: • Klasowe wzorce strukturalne . • Inne wzorce strukturalne: o Most. • Obiektowe wzorce strukturalne . jak i wzorce komunikacji pomiędzy nimi. gdy: Chcemy wykorzystać istniejącą klasę. która współpracuje z niepowiązanymi ze sobą lub nieprzewidzianymi klasami. Wzorce strukturalne . przez interpretowanie tych zdań. kiedy w jednym programie używamy niezależnie utworzonych bibliotek klas.wzorzec ten przekształca interfejs klasy w taki. które niekoniecznie mają zgodne interfejsy. • Prototyp. Umożliwiają skoncentrowanie się na przepływie sterowania. działanie oraz zalety danego rozwiązania. • Singleton. Uwzględniają one zarówno wzorce obiektów i klas. Ów problem rozwiązuje zbudowany interpreter. Przy czym nie chodzi tu o wprowadzenie silnych powiązań pomiędzy klasami (zmniejsza to szanse na ponowne wykorzystanie tych klas). o różnej skali. co wyklucza zastosowanie obiektywnych metod pomiarowych. Może być także złożony. posiada cechy obiektywne – mierzalne. • Śledzenie i zarządzanie przedsięwzięciem. zasobów lub kosztu. Zwykle można wyróżnić trzy główne fazy: • Budowa planu.łatwość użycia aplikacji przez zdefiniowaną grupę odbiorców. że mogą działać w różnych zastosowaniach. Możliwości konserwacji . planowanie zadań. składać się na przykład z listy zadań z ich datami rozpoczęcia i zakończenia zapisanymi w notatniku. Atrybuty oceny jakości oprogramowania Funkcjonalność . zwykle w ramach ograniczeń czasu. Większość przedsięwzięć ma takie same elementy. Szerokie pole zastosowań produktów programistycznych sprawia. 30. składać się na przykład z tysięcy zadań i zasobów oraz budżetu liczonego w milionach złotych. Plan projektu może być prosty. • Zamykanie przedsięwzięcia Problem oceny oraz jakości oprogramowania Na jakość oprogramowania składają się cechy mierzalne i niemierzalne (subiektywne). ich czasochłonność lub niewykonalność z powodu niemożliwości stworzenia środowiska pomiarowego. Wydajność – stosunek ilości zadań wykonanych przez program do ilości zasobów zużytych przy wykonywaniu tych zadań. łączność w zespole i śledzenie zadań w trakcie postępu pracy. Złożoność powoduje trudności w wyodrębnieniu cech mierzalnych. Łańcuch zobowiązań. Niezawodność . posiada cechy subiektywne. Stan. Przenośność . Pomiary cech produktów programistycznych są utrudnione lub niemożliwe. Zarządzanie projektem informatycznym. Wiele czynników składających się na jakość produktu jest niemierzalna. ani też o ograniczanie liczbę zależnych obiektów do dwóch. organizacji oraz zarządzania zadaniami i zasobami w celu osiągnięcia zdefiniowanego celu.zdolność aplikacji do niezakłóconej pracy przez dany dłuższy okres czasu. Trudności z oceną jakości oprogramowania • • • • • • • • • • • • • • • • • trudne do zdefiniowania. Wieloaspektowość. Liczba interfejsów użytkownika przedstawiających te same dane może być dowolna. Pojęcie jakości: stopień uwolnienia wyrobu od wad i błędów.określa stopień realizacji potrzeb użytkownika przez funkcje programu.zdolność oprogramowania do adaptacji do różnych środowisk. Iterator. Mediator. Strategia. działający produkt. Kosztowność pomiarów. Polecenie. takie jak podział na łatwe do zarządzania zadania. jakość to pewien stopień doskonałości. Oceny jakości najczęściej muszą być znane zanim powstanie gotowy. Użyteczność .o o o o o o Typowym efektem ubocznym dzielenia systemu na współpracujące klasy jest potrzeba utrzymania spójności między powiązanymi obiektami. problem oceny oraz jakości oprogramowania Zarządzanie przedsięwzięciem (projektem) jest to proces planowania. niska przewidywalność wszystkich aspektów zastosowań w długim czasie. Wówczas pomiary jakości mogą okazać się nieadekwatne przy zmianie skali. które odzwierciedlałyby istotne aspekty jakości.ilość wysiłku potrzebnego do wprowadzenia modyfikacji w toku użytkowania systemu 18 . które umieszczane są w dwóch kategoriach: o kategoria wymagań klienta . Jednocześnie uważa się. modularność). ale nie dotyczy to przekazywania swojej wiedzy na ten temat. ponieważ tu pracownik otrzymuje tylko polecenia. praca w zespole projektującym system informatyczny Liderzy grup projektowych wymagają od pracowników zarówno gotowości do kompromisu i podporządkowania. wyrażone w języku zrozumiałym dla klienta. które „rozbijają” podstawowy problem na mniejsze podproblemy. • o o o • Charakterystyki (charakterystyki elastyczności: przenośność.powiązania między uczestnikami zespołu projektującego są bezpośrednie i różnorodne. SOJO (System Oceny Jakości Oprogramowania) – hierarchiczna reprezantacja cech produktu.: elastyczność). o o Rozwojowość systemu. Pracownik podległy raczej niechętnie przekazuje wiedzę liderowi. Qestion. Jedyną osobą koordynującą całość prac jest lider projektu. Liderzy wolą więc tworzyć zespoły z młodych pracowników zdając sobie sprawę z braku ich doświadczenia zawodowego. Miary (np. jakie oceniany obiekt powinien spełniać. • Motywacja do pracy. Metoda wyznaczników jakości McCalla – ocenia jakość systemów informatycznych według 3 grup wyznaczników: o Funkcjonowanie systemu. czego klient oczekuje. czyli określonego już wcześniej sukcesu. kreatywności. bazuje na zestawieniu cech badanego systemu. • Tradycyjny . Hierarchia wygląda następująco: o Atrybuty (np. Wybrana grupa bardziej doświadczonych pracowników 20-30% swojego czasu pracy przeznacza na 19 . Można powiedzieć. modyfikowalność). liczba linii kodu podana w tys. że powód tego leży bardziej w sferze psychiki. że pracownik uznaje za swój obowiązek przekazywanie informacji o realizacji projektu. że większość ludzi w trakcie pracy zawodowej traci kreatywność i indywidualizm na rzecz konformizmu i standardowości.. Kryteria doboru: • Kompetencje.są to informacje o tym. określenie metryk i ich przyporządkowanie do pytań. • Atrybuty osobiste Przez skuteczność systemu komunikacji rozumie się stopień realizacji założonych celów projektu.). niezbędne do zapewnienia implementacji wymagań klienta. przygotowanych w punkcie drugim. W praktyce stosowane są dwa systemy organizacyjne w zespołach projektowych: Sieciowy system komunikacji . jak i wysokiego poziomu indywidualizmu. której sens zawiera się w 3 krokach: o ustalenie celów podstawowych. o kategoria czynników technicznych . Nie można rekomendować systemu hierarchicznego. Metryki (dla modyfikowalności np. w jaki klienci odbierają jakość badanego programu. o o przyporządkowanie serii prostych pytań do każdego celu. Uniwersalność systemu 31. konfiguralność. Metric) – prosta i intuicyjna metoda.Metody oceny jakości oprogramowania • Metoda GQM (Goal. Organizacyjne aspekty procesu projektowania. W zarządzaniu stosowany jest system bezpośredniego podporządkowania.hierarchiczny system komunikacji Dla zwiększenia efektywności funkcjonowania systemu zarządzania należy maksymalnie eliminować ogniwa pośrednie. Strukturę organizacyjną i komunikacyjną w zespole projektującym zorganizowanym sieciowo można scharakteryzować: • • • • Podział na zespoły zadaniowe zmienia się dynamicznie w trakcie realizacji projektu. Udział grupy wykonawców z jednego zespołu w realizacji zadań innego zespołu. Wydaje się. które decydują o jego jakości. • Metoda QFD (Quality Function Deployment) – mierzy sposób.zawiera wszystkie techniki i metryki techniczne. restrukturyzacja. • naprawcza (ok. na którym system jest uruchamiany. wymienionych wcześniej. Nie są tworzone sztuczne bariery między liderami i pracownikami. wiek oprogramowania . Dlatego wielu liderów projektów uważa system hierarchiczny za łatwiejszy do sprawowania kontroli nad terminową realizacją zadań. zarządzania konfiguracjami Opracowanie wysokiej jakości oprogramowania w ograniczonym czasie i przy ograniczonym budżecie jest wielkim wyzwaniem. Przyjmuje się. czasu realizacji zadań. reprezentowany m. a następnie do spadku jakości. Można wyróżnić następujące modele pielęgnacji oprogramowania: • styl budowy katedry . 50%) . liderem i wykonawcą.ma na celu implementację nowych lub zmienionych wymagań funkcjonalnych. Jego odpowiedzialność za realizację projektu nie ulega zmianie. Bardzo istotny jest też dobór pracowników do zespołu i stosowany system motywacji.in. w którym system nieustannie znajduje się w fazie pielęgnacji. nie ulegający łatwo zmianom i ewolucji. 20 . wcześniej więc można podjąć interwencję. Lider całości projektu ma dużą odpowiedzialność. W zasadzie każdy jest. koszt będzie niższy niż w przypadku dziedzin o wysokiej zmienności wymagań. a także dotychczasowych zabiegów pielęgnacyjnych. co pozwala zmniejszyć koszty pielęgnacji w przyszłości.w przypadku obszarów dobrze zdefiniowanych.szybka rotacja pracowników powoduje. Cel ten nie zawsze jednak zostaje osiągnięty.in.zagrożenia w realizacji i odstępstwa od planowanych kosztów. Modyfikacja oprogramowania może prowadzić do niepożądanych efektów ubocznych. 25%) . 20%) . Najbardziej istotny jest poziom kwalifikacji poszczególnych pracowników i ich chęć do wspólnej pracy. charakteryzujący się wieloma wydaniami i koniecznością okresowej restrukturyzacji Szczególnie interesujący jest ten drugi model. 32.udział w realizacji zadań innego zespołu. • styl bazaru .szczegółowo zaplanowany. o intuicyjnych wymaganiach. Na koszt pielęgnacji ma wpływ wiele czynników technicznych i pozatechnicznych. 5%) . że twórca oprogramowania nie zajmuje się później jego pielęgnacją. • adaptacyjna (ok. Rozwiązywanie sytuacji problemowych . organizację pracy oraz za stworzenie odpowiedniego klimatu.między członkami istnieje duża współpraca zarówno w realizacji zadań. System komunikacji stosowany w zespole zorganizowanym sieciowo wymaga spełnienia szeregu warunków. m.żywiołowo rozwijającego się w wielu kierunkach.konflikty w realizacji zadań są o wiele mniejsze w systemie sieciowym niż w hierarchicznych. Współpraca i przekazywaniu wiedzy w realizacji zadań . Ewolucja oprogramowania – modyfikacja. Odpowiada za dobór zespołu. Wiąże się to z dodatkowym kosztem zrozumienia oprogramowania przez nowego pracownika. Na pielęgnację oprogramowania składają się cztery różne rodzaje aktywności pielęgnacyjnej: • doskonaląca (ok. jak i w przekazywaniu dysponowanej wiedzy. Modyfikacja istniejącego systemu w celu zaimplementowania nowych możliwości jest zadaniem jeszcze trudniejszym. Wzmacnia to więź między pracownikami z różnych zespołów i tworzony warunki dla systemu przepływu i zarządzania wiedzą. zależnie od sytuacji. Proces modyfikacji powinien być przeprowadzany bez naruszania jakości całego systemu.polega na wewnętrznej restrukturyzacji programu. • prewencyjna (ok. przez Linuxa. Przewaga sieciowej organizacji: • • Monitoring realizacji projektu . które utrudniają wprowadzanie kolejnych zmian. gdy koszt pielęgnacji przekracza koszt stworzenia nowego systemu. stałość personelu . W momencie. W stosunku do systemu hierarchicznego lider projektu powinien zrezygnować z wielu swoich uprawnień kierowniczych i przekazać je do zespołów realizujących. założonych parametrów systemu są w systemie sieciowym wcześniej dostrzegane.służy usuwaniu błędów z programu.dostosowuje program do zmian zachodzących w środowisku. System ten jest trudny dla tak zwanych indywidualistów i osób pragnących zrobić karierę administracyjną. niż w systemie hierarchicznym.wynika to z kosztów pielęgnacji sprzętu. czynników.: • • • • dziedzina systemu . że koszt pielęgnacji w każdym systemie może być porównywalny lub wyższy od kosztu jego stworzenia. a jeżeli już powstały są szybko rozwiązywane wewnątrz grupy zadaniowej. dalsza ewolucja jest ekonomicznie nieuzasadniona. w zależności od czasu jego pielęgnacji i innych. program podzielony na moduły. jednak jest on rodzajem inwestycji zwracającej się podczas pielęgnacji. Programy. Dlatego cyklem życia szczególnie dobrze wspomagającym tę fazę rozwoju oprogramowania jest model spiralny. może być modyfikowany częściami. stają się coraz mniej użyteczne. aktualizację dokumentacji etc. a także ryzyko związane ze stworzeniem całkowicie nowego oprogramowania. Ewolucja jest procesem naturalnym i w praktycznych zastosowaniach nie da się jej uniknąć. bez potrzeby zmiany pozostałych modułów. za cenę dodatkowych nakładów w fazie rozwoju • 21 . szczególnie w tych fragmentach systemu. wiąże się z tym dodatkowy koszt. warto stosować re-inżynierię. o niewielkiej liczbie powiązań. Dlatego stosowanie cyklicznej restrukturyzacji pozwala ograniczyć ten koszt. Z uwagi na koszty. Celem jest zwiększenie tej zdolności przez zmianę jego wewnętrznej struktury. Stosowanie jej pozwala ograniczyć koszty związane z pielęgnacją. Czynnikiem wspomagającym pielęgnację jest sterowanie ewolucji poprzez informację zwrotną płynącą ze środowiska. Koszt związany z pielęgnacją zwykle przekracza koszt stworzenia oprogramowania. Inżynieria ponowna (czyli re-inżynieria) jest pojęciem stosowanym w odniesieniu do pielęgnacji istniejących systemów o słabej pielęgnowalności. które często ewoluują. które nie ewoluują. Oczywiście. jaki należy ponieść w fazie tworzenia programu.wewnętrzna jakość oprogramowania oraz dokumentacji .