OCL: Definicja terminów biznesowych Fakty pokazujące relacje między terminami Ograniczenia Wnioskowania stereotypy wartosci znakowane

Transkrypt

1 OCL: Reguła biznesowa jest stwierdzeniem, które definiuje lub ogranicza pewne elementy/aspekty biznesu. Opisuje operacje definicje i ograniczenia, które stosuje się do organizacji zapewniając osiągnięcie jej celów; jest abstrakcją polityki i praktyk stosowanych w organizacji. Kategorie reguł: Definicja terminów biznesowych (np. obywatel polski, posiadający adres zam. w POLSCE ) Fakty pokazujące relacje między terminami (Czytelnik może wypozyczyć ksiązkę) Ograniczenia (określenie zachowania, wartość; mozna mieć wypozycz. max 5 ksiązek w jednym czasie.) Wnioskowania (wiedza z jednej postaci przekształcona w inną wiedzę- Czytelnik musi mieć PESEL) stereotypy : Element klasyfikacyjny, używany do specjalizacji (uzupełnienia) semantyki elementu modelu już zdefiniowanego w języku np.: (<<nazwa>>) wartosci znakowane : Bezpośredni opis właściwości elementu modelu w postaci pary nazwa wartość (Name = Value ;Name) Ograniczenia : Semantyczny warunek lub zawęzenie nałozone na element modelu/ restrykcja nałozona na jedną lub więcej wartości (części) modelu lub systemu obiektowego Składnia : Zdefiniowana przez OCL - Object Constraint Language zapisywane w nawiasach klamrowych {ograniczenie} Przykłady { subset } { x.a > 10 } { ordered } Dzięki ograniczeniom uzyskuje się: poprawienie jakości dokumentacji zwiększenie precyzji diagramów polepszenie zrozumienia miedzy klientem a projektantami Dowolne elementy modelu UML (klasy, atrybuty, operacje) mogą być opatrzone ograniczeniami, zapisywanymi w nawiasach {}. Ograniczenia na model system mogą przyjąć postać: 1. niezmienników dla atrybutów klasy 2. niezmienników dla asocjacji klasy 3. określenia warunków początkowych i końcowych realizacji operacji 4. ograniczeń dla relacji generalizacji 5. precyzowania sposobu postępowania z kolekcjami W UML są zdefiniowane 3 stereotypy odpowiadające pojęciom 1-3: «invariant», «precondition» oraz «postcondition>> Język OCL podstawy Charakterystyka języka OCL: - język deklaratywny - kontekstowy język wyrażeń - silnie typizowany z rozbudowaną hierarchią typów - bez tzw. efektów ubocznych (nie zmienia stanu modelu) - prosty (zgodnie z deklaracją autorów) Wyrazenia OCL są wykorzystywane m.in. do definicji: 1) inwariantów (niezmienników) klas, 2) warunków pre i post dla operacji 3) specyfikacji wyrażeń nawigacyjnych Ograniczenie OCl jest wyrażeniem OCL typu Boolean. Wyrazenie OCl to wyrazenie napisane zgodnie z regułami języka OCL. Typy predefiniowane: typy podstawowe typy kolekcyjne Predefiniowane typy podstawowe to: Integer, Real, String i Boolean Boolean true, false Integer - -1, 0, 1, Real - liczby rzeczywiste... String - ciąg znaków Uwaga: UML dopuszcza stosowanie typu wyliczeniowego. Aby odwołać sie do wartości takiego typu w języku OCL należy poprzedzić go symbolem #. Inwariant (niezmiennik) klasy wyrazenie logiczne, które powinno być spełnione w kazdym momencie przez wszystkie obiekty danej klasy. context [nazwa_obiektu:]nazwa_klasy inv [nazwa_inwariantu]: warunek_logiczny -- inwariant 1 inv [nazwa_inwariantu]: warunek_logiczny -- inwariant 2 Przykład: Osoba ma co najmniej 18 lat context Osoba inv: self.wiek > 18 context Osoba inv:

2 wiek > self opuszczony context os: Osoba inv: -- os jawna nazwa instancji klasy Osoba self.wiek > 18 context Osoba inv wiek_osoby: -- inwariant ma nazwę self.wiek > 18 Ograniczenia początkowe dla atrybutów wartości początkowe atrybutu. Przykład: context Czytelnik Instytucjonalny::rzetelny:Wylicz init: if self.nazwa== XXX then # wysoka else #niska Definicja ograniczeń dla operacji context NazwaKlasy::NazwaOperacji(par1 : Typ1,... ) : TypWyniku pre [nazwa_warunku]: par1 > warunki wstępne post [nazwa_warunku]: result = par result słowo zastrzeżone -- do definiowania wyniku operacji context Dziennik::srednia_osoby(o : Osoba):Real post: result = 5 -- to tylko przykład -- brak pre oznacza brak ograniczeń; pre : true W warunku post mozliwe jest takze odwoływanie się do poprzednich (początkowych) wartości parametrów wywołania operacji poprzez uzycie Przykład: ob.imie@pre oznacza wartość poprzednią (przed wykonaniem operacji) atrybutu imie obiektu ob. Ograniczenia: Nawigowanie po modelu Szczególnymi własnościami klas są związki (asocjacji, agregacji) z innymi klasami. Opisując ograniczenia powiązań klasy za pomocą OCL można się odwoływać do obiektów na drugim końcu powiązania poprzez nazwę roli. Odwołanie do obiektu powiązanego przez nawigację za pomocą notacji kropkowej. Drugi koniec jest identyfikowany przez nazwę roli lub, gdy jej brak, przez nazwę klasy (pisaną małą literą). context Rezerwacja inv: czytelnik.nazwa < > -- czytelnik musi mieć nazwę; Ograniczenia: Nawigowanie po modelu - kolekcje Jeśli występuje powiązanie obiektu z wieloma obiektami klasy, to odwołania dotyczą kolekcji obiektów. Do własności kolekcji odwołuje się poprzez notację ->, np. jeżeli X jest kolekcją, to X->size() jest wywołaniem funkcji zwracającej rozmiar kolekcji. Przykład: context Czytelnik inv: self.rezerwacja->size() < 3 -- czytelnik ma najwyżej 3 rezerwacje Typy języka OCL (cd) Predefiniowane typy kolekcyjne Collection(T) to zbiory Set(T) ciągi Sequence(T) wielozbiory Bag(T) Typy specjalne OclAny -- nadtyp wszystkich innych typów OCL, oclistypeof(t: OclType):Boolean, ocliskindof(t: OclType): Boolean OclType, -- dowolny typ OCL, Typy użytkownika modelowe: Wszystkie klasy, interfejsy i inne typy utworzone przez użytkownika w modelu UML Kolekcja Definicje kolekcji wyrażenia typu kolekcja Set{1, 2, 4, 5} -- elementy zbioru nie są uporządkowane Sequence{1, 2, 3, 2, 3} -- elementy ciągu są uporządkowane Sequence{1.. 3, 2.. 3} -- elementy ciągu są uporządkowane Bag{1, 2, 3, 2, 3} -- elementy wielozbioru nie są uporządkowane Elementami kolekcji mogą być również kolekcje. W przypadku zbioru zbiorów następuje automatyczne spłaszczenie do jednego zbioru. Na przykład, podane zbiory są identyczne: Set{Set{1,2},Set{3,4}} i Set{1..4}

3 Zgodność typów Typ t1 jest zgodny z typem t2 (jest podtypem typu t2), gdy w dowolnym miejscu, w którym oczekiwana jest instancja (wartość) typu t2, może ona zastąpiona przez instancję typu t1. Każdy typ jest zgodny ze swoim nadtypem. Relacja zgodności typów jest przechodnia. Typ jest zgodny z Integer Real Set(T) Collection(T) Sequence(T) Collection(T) Bag(T) Collection(T) Collection(T1) Collection(T2), gdy T1 jest podtypem T2 Operacje kolekcji Podstawowe operacje dla kolekcji collection->isempty() : Boolean sprawdza czy kolekcja jest pusta, collection->size() : Integer zwraca rozmiar kolekcji (ilość jej elementów), collection->includes(object : OclAny) : Boolean sprawdza czy obiekt object jest w danej kolekcji collection->sum() : T zwraca sumę wszystkich elementów kolekcji, collection->exists(expr : OclExpression) : Boolean collection->forall (expr : OclExpression) : Boolean operacje reprezentujące kwantyfikatory ogólne dla kolekcji jeżeli dla każdego elementu kolekcji wyrażenie expr jest prawdziwe to operacja forall zwraca True, jeżeli istnieje choć jeden element dla którego prawdziwe jest wyrażenie expr, to operacja exists zwraca True Operacja collect tworzy nową kolekcję na podstawie informacji z kolekcji pierwotnej, wstawiając do wynikowej kolekcji obliczone wyrażenia collection->collect( expression ) collection->collect( v : Type expression-with-v ) collection->collect( v : Type expression-with-v ) Operacja select tworzy nową kolekcję będącą podkolekcją kolekcji, dla której wywołana została operacja. collection->select( boolean-expression ) collection->select( v boolean-expression-with-v ) collection->select( v : Type boolean-expression-with-v) Wynikiem tej operacji jest nowa kolekcja z tymi elementami z kolekcji źródłowej, dla których wyrażenie logiczne w operacji select było prawdziwe. Przykład Rezerwacja.pozycja->select(k: pozycja.książka k.autor = Pressman ) Iteracja po elementach kolekcji Operacja iterate uniwersalna operacja dla kolekcji; za jej pomocą mozna zdefiniować inne operacje, np. collect, sum, average, itp. Ogólna postać operacji iterate: collection->iterate( elem : Type; acc : Type = <expression> expression-withelem-and-acc ) Operacja ta przebiega całą kolekcję z iteratorem elem. Acc jest akumulatorem, który może być na początku zainicjowany wartością początkową (expression). Dla każdej wartości iteratora, czyli dla wszystkich elementów kolekcji obliczane jest wyrażenie expression-with-elemand-acc, a jego wynik jest podstawiany do akumulatora. Przykład: operacja sumowania wartości kolekcji (elementy typu Integer) zdefiniowana jako iteracja mogłaby wyglądać następująca: collection->iterate(x : Integer; acc : Integer = 0; acc + x) OCL - podsumowanie Modele UML mogą być doprecyzowane przez formalnie wyrażone ograniczenia w OCL. OCL jest językiem tekstowy, kontekstowym, silnie typizowanym. Istnieje wiele narzędzi, w tym generatory kodu (sprawdzające w locie ograniczenia) przeznaczone dla OCL. Faza analizy: Analiza Architektoniczna: Cele: - Definicja architektury kandydującej systemu w oparciu o doświadczenia w wytwarzaniu podobnych systemów - Dostarczenie wejść dla procesów planowania Kroki: 1. Definicja organizacji podsystemów (wysokiego poziomu) zwykle wykorzystuje się model warstwowy 2. Wytworzenie modelu rozmieszczenia wysokiego poziomu (RUP) 3. Identyfikacja kluczowych abstrakcji 4. Identyfikacja mechanizmów analizy Mechanizmy: Mechanizm analizy reprezentuje wzorzec, który stanowi rozwiązanie powszechnego problemu.

4 Mechanizmy analizy są używane do reprezentacji umiejscowienia złożonej technologii w warstwach pośrednich (middleware) oraz oprogramowania systemowego. Zwykle są niezwiązane z dziedziną problemu. Przykładowe mechanizmy dotyczą trwałości danych, komunikacji pomiędzy procesami, obsługi błędów, powiadomień, zarządzania transakcjami, bezpieczeństwa itp. Np. charakterystyk dotyczących opisu trwałości danych: o Wielkość (Granularity) o Liczbę (Volume) o Okres przechowywania (Duration) o Mechanizm odtwarzania (Retrieval mechanism) o Częstość modyfikacji (Update frequency) o Pewność (Reliability) ANALIZA przypadków uzycia Cele: - Identyfikacja klas analizy, które będą odpowiedzialne za realizację przypadku uzycia - Odkrycie wymagań dodatkowych związanych z przypadkiem uzycia Kroki: 1. Identyfikacja klas analizy 2. Opisanie interakcji obiektów analizy 3. Odkrywanie wymagań dodatkowych ANALIZA klas Cele: - Identyfikacja zakresu odpowiedzialności klas analizy w oparciu o role, które pełnią one w przypadku użycia - Identyfikacja atrybutów klas analizy - Odkrycie wymagań dodatkowych związanych z klasą Kroki: 1. Identyfikacja zakresów odpowiedzialności klas 2. Identyfikacja atrybutów 3. Identyfikacja asocjacji i agregacji 4. Identyfikacja generalizacji 5. Odkrywanie wymagań dodatkowych PROJEKTOWANIE PROJEKT - Projektowanie architektury Celem projektowania architektury jest podanie modeli: projektowego i rozmieszczenia, oraz ich architektury. Można to uzyskać dzięki identyfikacji: Architektury fizycznej Węzłów i ich sieciowej konfiguracji, Architektury logicznej Podsystemów i ich interfejsów, Architektonicznie znaczących klas projektowych np. klas aktywnych, Generycznego mechanizmu projektowego, który obsłuzy wspólne wymagania np. specjalne wymagania na trwałość, rozproszenie, wydajność i inne, określone w fazie analizy klas i przypadków użycia z modelu analizy(-> wymagania niefunkcjonalne!!) Projekty architektury projekt logiczny Wykorzystuje się diagram rozmieszczenia. Przedstawia konfigurację węzłów (przetwarzających) oraz umieszczonych w nich komponentów; odzwierciedla statyczny aspekt perspektywy instalacyjnej Elementy: węzły; komponenty; połączenia pomiędzy węzłami PROJEKT - Projektowanie podsystemu Celem projektowania podsystemu jest zapewnienie: tak dużej jak jest to możliwe niezależności podsystemu od innych podsystemów i/lub interfejsów, dostarczania przez podsystem poprawnego interfejsu własnego, zapewnienie wypełniania przez podsystem jego celów w tym sensie, ze oferuje on poprawną realizację operacji, tak jak jest ona zdefiniowana w interfejsie, który on dostarcza. dla kazdego interfejsu oferowanego przez podsystem muszą istnieć klasy projektowe lub inne podsystemy, które dostarczą ten interfejs, w celu wyjaśnienia jak wewnętrzny projekt realizuje dowolny swój interfejs lub przypadek użycia, należy podać kolaborację zawierającą elementy podsystemu; PROJEKT - Projektowanie przypadku użycia Celem projektowania PU jest: identyfikacja klas/podsystemów, które uczestniczą w PU rozdzielenie zachowania między klasy/podsystemy zdefiniowanie wymagań dotyczących operacji klas/podsystemów rozpoznanie wymagań implementacyjnych dla PU Etapy: - identyfikacja klas projektowych (z analizy uzupełnione o klasy dla wymagań niefunkcjonalnych); - opis interakcji obiektów (diagram sekwencji poszerzony o nowe klasy; nazwa wiadomości staje się nazwą operacji); - rozważenie ścieżek alternatywnych: timeouty, błędy we, błedy systemów spadkowych.

5 PROJEKT - Projektowanie klasy Celem projektowania klasy jest określenie: Operacji, atrybutów, relacji, metod, stanów i zależności od mechanizmów generycznych, a także interfejsów, które klasa realizuje. Dla klasy projektowej stosować śladowanie <<trace>> do klasy analizy. Nalezy zidentyfikować: - klasy boundary - zalezą od zastosowanej technologii interfejsu (nowe stereotypy <<form>>, <<dialog>>, <<view>>) - klasy entity - dla modelu relacyjnego: model danych, projekt bazuy danych - klasy sterujące - trudne, decyzje powinny uwzględniać rozproszenie aplikacji, wymagania wydajnościowe (enkapsulacja do klas interfejsu), obsługę transakcji. PROJEKT - wzorce projektowe Cel: tworzenie projektu wielokrotnego uzytku Wzorzec projektowy - opisanie istoty rozwiązania problemu (spotykanego często w otoczeniu) w sposób, który umożliwia wielokrotne wykorzystywanie tego rozwiązania - niekoniecznie w ten sam sposób. Na Wzorzec projektowy składają się cztery elementy: nazwa wzorca, problem, sposób rozwiązania, konsekwencje stosowania wzorca. Wzorce projektowe dotyczą pewnego poziomu abstrakcji problemu tzn. nie są wzorcami budowy list, drzew itp.; nie są też wzorcami budowy całych aplikacji podsystemów(np. bankowego, sterowania procesem itp.) Wzorce projektowe - definicje Wzorzec projektowy identyfikuje i specyfikuje abstrakcję wyższą niż klasa, instancja czy nawet komponent (Gamma, 1993) Wzorce projektowe są opisem komunikujących się obiektów i klas dostosowanych do rozwiązania problemu projektowego w konkretnym kontekście (Gamma 1995) Wzorce projektowe stanowią zbiór reguł określających jak osiągnąć konkretne cele w dziedzinie wytwarzania oprogramowania (Pree, 1994) Wzorzec stanowi rozwiązanie powtarzających się problemów projektowych (Bushmann, 1996) Wzorzec ~ przepis na upieczenie ciasta Wzorce projektowe - klasyfikacja Kreujące przejmują na siebie tworzenie nowych instancji obiektów, ukrywając rodzaj obiektów (singleton, proxy, fabryka abstrakcyjna) Strukturalne wspomagają organizowanie obiektów w duże struktury, np. UI czy operacje na danych (fasada, adapter, most, dekorator, kompozycja) Behawioralne wspomagają definiowanie komunikacji i przepływu zdarzeń pomiędzy obiektami (łańcuch odpowiedzialności, mediator, iterator) Wzorce kreujące (Creational Patterns) związane z tworzeniem nowych obiektów; ukrywają szczegóły dotyczące tworzenia obiektów; kod klienta ma pozostać niezmieniony w przypadku dodania nowego typu; Przykłady: singleton, proxy, metoda fabrykująca (factory method), abstrakcyjna fabryka (abstract factory). Wzorzec Singleton wzorzec projektowy, który daje pewność że istnieje tylko jedna instancja danej klasy. Wzorzec Proxy umożliwia dostęp do obiektu klasy rzeczywistej, poprzez obiekt klasy pośredniczącej (obiekt proxy). Wzorce strukturalne (Structural Patterns) wzorce, które pomagają grupować obiekty w większe struktury; obiekty pozostają w pewnych połączeniach; wzorce te mają ukrywać sposób powiązania obiektów i uniezależniać klienta od tych zmian; przykłady: fasada, adapter, dekorator, most (bridge), kompozycja (composition) Wzorzec Decorator opakowanie zbioru klas posiadających wspólny interfejs. Wzorce behawioralne (Behavioral Patterns) wzorce, które są związane z projektowaniem obiektów, które mają wykonywać specyficzne akcje w programie; wzorce dotyczące sposobów komunikowania się obiektów; ich działanie jest oparte o dziedziczenie, dzięki któremu klasy zachowują się podobnie przykłady: obserwator, łańcuch odpowiedzialności (chain of responsibility), polecenie (command), interpreter, iterator, mediator, stan (state), strategia (strategy) Wzorzec obserwator (observer) definiuje zależność pomiędzy obiektami w ten sposób, że gdy jeden z nich zmienia stan, reszta jest o tym powiada-miana i uaktualniana automatycznie Wzorzec Łańcuch odpowiedzialności (Chain of Responsibility) umożliwia różnym obiektom, połączonym w listę, na podjęcie próby obsłużenia pewnego żądania, podczas gdy żaden z nich nic nie wie o możliwościach innych. Wzorce projektowe - podsumowanie Wzorce projektowe ułatwiają proces modelowania aplikacji obiektowych Pozwalają na wykorzystanie gotowych przepisów na rozwiązanie trudnych problemów Kluczem do ich stosowania jest znajomość przynajmniej specyfiki problemów, z jakimi poszczególne wzorce sobie radzą Proces przechodzenia z modelu analizy do modelu projektowego powinien następować z uwzględnieniem użytecznych wzorców projektowych

6 Podstawy Inżynierii Oprogramowania Asocjacja (n do m) jest odwzorowywana na tabelę Asocjacja (1 do n) jest odwzorowywana: na tabelę lub jest reprezentowana przez klucz obcy w tabeli reprezentującej klasę z licznością n Asocjacja (1 do 1) oraz (1 do n) może być odwzorowana na jedną klasę (jeżeli asocjacje nie tworzą cyklu) reprezentującą zarówno oba końce (klasy) asocjacji, jak i asocjację Asocjacja n-arna jest odwzorowywana na tabelę Asocjacja kwalifikowana jest odwzorowywana na tabelę z przynajmniej trzema atrybutami: 2 klucze główne dla każdego końca asocjacji oraz kwalifikator Agregacja jest odwzorowywana tak, jak asocjacja Zasady odwzorowania dla generalizacji prostej: każda klasa (nadklasa oraz podklasy) są odwzorowywane na tabele lub nie ma tabeli dla nadklasy; atrybuty nadklasy są replikowane w każdej tabeli podklasy lub nie ma tabeli dla podklasy; wszystkie atrybuty podklas są przeniesione do tabeli nadklasy Zasady odwzorowania dla generalizacji wielokrotnej: dla klas rozłącznych - każda klasa (nadklasy oraz podklasy) są odwzorowywane na tabele lub dla klas nierozłącznych - każda klasa (nadklasy oraz podklasy) są odwzorowywane na tabele oraz generalizacja jest odwzorowywana na tabelę Model projektowy obejmuje: architekturę logiczną tzn. podsystemy projektowe, podsystemy usługowe (service) wraz z ich interfejsami, zawartością oraz związkami zachodzącymi pomiędzy nimi; widok architektoniczny uwzględnia mechanizmy architektoniczne, w tym wzorce projektowe architekturę fizyczną opisującą węzły i i ich sieciową konfigurację (wyrażoną modelem rozmieszczenia) realizację projektowych przypadków użycia, wykorzystującą klasy projektowe z uwzględnieniem klas aktywnych; realizacja obejmuje wątki alternatywne wynikające z ograniczonych zasobów oraz błędów interfejsu Implementacja Przyrost (ang. build) - wykonywalna wersja systemu lub jego części; efekt iteracji PLAN INTEGRACJI Przyrostu opisuje sekwencję przyrostów kodu, które mają być zbudowane w kolejnych iteracjach PLAN INTEGRACJI Przyrostu zawiera dla każdego przyrostu: - funkcjonalność, która ma zostać zaimplementowana w przyroście (lista przypadków użycia lub ich części, lub/i scenariuszy; lista może dotyczyć wymagań dodatkowych) - wskazanie części modeli implementacyjnych (podsystemów, artefaktów, komponentów) składających się na przyrost STRATEGIA DEKOMPOZYCJI NA Przyrosty: - kolejny przyrost powinien dodawać funkcjonalność w stosunku do poprzednich buildów - nie należy wprowadzać zbyt wielu nowych elementów do przyrostu (trudności w integracji i testowaniu) - początkowe przyrosty implementują niższe warstwy aplikacji, późniejsze - warstw bliższych warstwie aplikacji Ogół właściwości produktu wiążących się z jego zdolnością do zaspokojenia potrzeb stwierdzonych i oczekiwanych jakość zewnętrzna (punkt widzenia klienta: własności dotyczące oprogramowania lub jego oferty), jakość wewnętrzna (punkt widzenia dostawcy oprogramowania: metody narzędzia, reguły, procedury, standardy, normy). TESTOWANIE to wykonywanie programu w celu i z intencją znalezienia błędu (na podstawie błędnego wykonywania się programu - ang. fault) WERYFIKACJA - wykazanie w warunkach sztucznych zgodności wytworzonego programu/systemu ze specyfikacją. WALIDACJA (zatwierdzanie) - wykazanie w warunkach naturalnych (np. w środowisku klienta) zgodności wytworzonego programu/systemu ze specyfikacją. CERTYFIKACJA - autorytatywne potwierdzenie zgodności wytworzonego programu/systemu ze specyfikacją, która jest znormalizowana (np. w postaci normy ISO, ANSI, IEC). Błąd oprogramowania ( ang. fault) - nie są spełnione sensowne oczekiwania użytkownika/klienta; stan rzeczy odbiega od przyjętych założeń/zasad. Awaria (ang. failure) efekt wykonania błędu Przypadek testowy para <dane wejściowe, oczekiwane wyniki> specyfikacja sposobu testowania systemu, łącznie z określeniem, co testować, pod jakim warunkiem można testować. Przypadek testowy musi weryfikować, co najmniej jeden scenariusz przypadku użycia. Procedura testowa kroki opisujące kolejność wykonywania przypadku testowego Skrypt testowy zautomatyzowana procedura testowa

7 Klasyfikacja błędów w systemach informatycznych: - wg przyczyny: uszkodzenie sprzętu, błąd danych, nieadekwatność oprogramowania - wg czasu trwania: trwały, chwilowy - wg skutków dla użytkownika: krytyczny, niekrytyczny - wg miejsca powstania : wewnętrzny, zewnętrzny - wg kryterium: faza cyklu zycia oprogramowania: testowanie jednostki (procedury,modułu, programu) testowanie integracyjne testowanie systemowe testowanie akceptacyjne - wg kryterium wymagania niefunkcjonalne : testowanie instalacyjne testowanie wydajnościowe testowanie niezawodności - wg kryterium : technika testowania: testowanie statyczne (dotyczy artefaktów niewykonywalnych ; inspekcja kodu/projektu) testowanie dynamiczne (wykonywanie programu dla danych testowych) Testy integracyjne dotyczą łączenia modułow/podsystemów (powstawanie kolejnych build ów). Testy systemowe - testowanie powstałej edycji ( release ) oprogramowania; wykorzystuje się scenariusze z przypadków użycia (realizacja projektowa) - weryfikacja wymagań co do systemu. Testy akceptacyjne dotyczą zainstalowanego produktu i są generowane na podstawie przypadków użycia. Poprawne wykonanie każdego z tych testów rozumiane jako spełnienie warunku (-ów) post przypadku użycia oznacza osiągnięcie celu tego przypadku i jest walidacją wymagania użytkownika. Podstawy Inzynierii Oprogramowania TESTOWANIE - zakres Model Rodzaj testowania Technika testowania Model specyfikacji Testowanie akceptacyjne, Testowanie funkcjonalne wymagań i systemowe, Pomiar osiągów Model projektowy Testowanie integracyjne, Testowanie strukturalne, Testowanie funkcjonalne Model implementacyjny Testowanie jednostkowe, Testowanie strukturalne, Testowanie funkcjonalne, weryfikacja Testowanie jednostkowe black-box white-box Testowanie integracyjne - zasady łączenia jednostek przyrostowa zstępująca - wymaga namiastek (stubs) wstępująca - wymaga sterowników skokowa Testowanie systemowe - zalecane typy testów systemowych Test Czynność Najczęściej stosuje się do systemów użyteczności sprawdzenie funkcji systemu systemy o rozbudowanej funkcjonaln. Wydajności pomiar parametrów, wyznaczenie systemy o narzuconych wymaganiach charakterystyk wydajnościowych obciążenia praca systemu w ekstremalnych systemy sieciowe, wielodostępne warunkach (dużo danych, wielu użytkowników) pamięci pomiary zapotrzebowania na pamięć konfiguracji próba pracy w różnych konfiguracjach instalacji testowanie procedur systemy o skomplikowanej instalacji instalacyjnych poufności próba włamania systemy z poufnymi danymi Testowanie akceptacyjne akceptacja fazowa - prototypy, kolejne wersje produktu akceptacja ostateczna Wymagania pojawiające się podczas implementacji testów jednostkowych: Niepowodzenie jednego testu nie powinno przerywać procesu testowania (assert() z języka C kończy program) Raporty z wykonania testów powinny być generowane automatycznie Asercje powinny dawać możliwość porównywania obiektów różnych typów Konieczna możliwość organizacji testów w zbiory Ogólna zasada działania JUnit a Dla klasy testowanej tworzymy TestCase Dodajemy metody testowe rozpoczynające się frazą test W miarę potrzeby nadpisujemy metody setup() i teardown() trudno jest stwierdzić, kiedy skończyć testowanie nie można testować własnego programu, testowanie powinno być powtarzalne, dane testowe obejmują zarówno dane poprawne jak i niepoprawne, należy badać dokładnie wyniki testowania, wzrost liczby wykrytych jest symptomem istnienia pozostałych, testowalność jest kluczowym założeniem projektu Przegląd jest procesem lub spotkaniem, podczas którego produkt roboczy/artefakt (lub zbiór produktów roboczych) jest

8 prezentowany personelowi projektu, kierownictwu, użytkownikom, klientom lub innych zainteresowanych stron celem uzyskania komentarzy, opinii i akceptacji. Przeglądy mogą być formalne i nieformalne. Przejście (walkthrough). Wczesna, nieformalna ocena dokumentów, modeli, projektów i kodu. Celem jest zidentyfikowanie defektów i rozważenie możliwych rozwiązań. Wtórnym celem jest szkolenie i rozwiązanie problemów stylistycznych (np. z formą kodu, dokumentacji, interfejsów użytkownika). Formalne przeglądy mogą być inspekcją bądź audytem Inspekcja - formalna technika oceny, w której wymagania na oprogramowanie, projekt lub kod są szczegółowo badane przez osobę lub grupę osób niebędących autorami, w celu identyfikacji błędów, naruszenia standardów i innych problemów Korzyści z inspekcji: 1. Wzrost produktywności od 30% do 100% 2. Skrócenie czasu projektu od 10% do 30% 3. Skrócenie kosztu i czasu wykonywania testów od 5 do 10 razy (mniej błędów, mniej testów regresyjnych) razy mniejsze koszty pielęgnacji (naprawczej) 5. Poprawa procesu programowego Wymaganie powinno : - być jasno i jednoznacznie sformułowane - być wyrazone w sposób mierzalny (wazne zwłaszcza dla wymagań niefunkcjonalnych) - mieć nadany priorytet - mieć oszacowany koszt realizacji - być dostarczone do etapu projektu - być rozpoznawalne w kodzie - być weryfikowalne: stowarzyszone z testem, - testowalne w izolacji oraz łącznie z innymi wymaganiami - być walidowalne po zbudowaniu systemu Audyt niezależny przegląd i ocena jakości oprogramowania, która zapewnia, ze osiągnięto zgodność z wymaganiami na oprogramowanie, a także ze specyfikacją, generalnymi założeniami, standardami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi wymaganiami. Celem audytu projektu informatycznego jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych informacji o stanie całego projektu lub produktu końcowego. Przedmioty audytu: stan projektu, proces wytwórczy lub jego dowolny podproces, system jakości, produkt końcowy Ogół właściwości produktu wiążących się z jego zdolnością do zaspokojenia potrzeb stwierdzonych i oczekiwanych Wyróżnia się: jakość zewnętrzną (punkt widzenia klienta: własności dotyczące oprogramowania lub jego oferty), jakość wewnętrzną (punkt widzenia dostawcy oprogramowania: metody narzędzia, reguły, procedury, Pomiary w projekcie Mierzonymi elementami przedsięwzięcia informatycznego mogą być: proces - sekwencja aktywności wywołanych w celu wyprodukowania produktu software owego ( i innych artefaktów) produkt - artefakty procesu włączając w to oprogramowanie, dokumenty i modele przedsięwzięcie - całkowite zasoby, aktywności i artefakty zasoby - ludzie, metody i narzędzia, czas, nakład, budżet dostępne dla projektu Podstawowy zbiór miar (zalecany przez SEI) reprezentuje minimalny zbiór miar niezbędny z punktu widzenia zarządzania projektem: - rozmiar - koszt - czas trwania - defekty. Pomiar artefaktu - Jednostki przydzielane atrybutom artefaktu podczas procesu pomiarowego są nazywane miarą danego atrybutu. Miara charakteryzuje w terminach numerycznych pewien prosty atrybut elementu (e.g. liczba linii kodu programu) Miara: mierzalny atrybut bytu (encji) np. nakład czasowy projektu jest miarą jego rozmiaru; by to zmierzyć należy zsumować wszystkie sprawozdania czasowe projektu. Miara może być zbudowana w oparciu o jedną lub więcej innych miar -> powinno się definiować podstawowe miary i procedury ich zbierania. Kategorie miar przedsięwzięcia ze względu na różne aspekty przedsięwzięcia miary dotyczą: postępu (w terminach rozmiaru i złożoności), stabilności (w terminach szybkości zmian wymagań

9 lub implementacji, rozmiaru lub złożoności), modularności (w terminach zakresu zmian), jakości (w terminach liczby i typów błędów), dojrzałości (w terminach częstości błędów), zasobów (w terminach stosunku wydatków projektu do planowanych wydatków). Ważne są trendy zmiany wartości miar, i ważne ich monitorowanie, a nie absolutna wartość miary w danym momencie Miary złożoności projektu Dla podejścia strukturalnego dwie miary: moc modułu miara złożoności wewnątrz modułowej: przypadkowa, klasyczna, logiczna, komunikacyjna, funkcjonalna, informacyjna, więź modułu - miara złożoności komunikacji międzymodułowej: treściowa, sterowania, wspólna, zewnętrzna Dla podejścia obiektowego miary dla klasy zestaw miar Chidamber/Kemerer (1994) dla projektu - MOOD (Abreu,Goualo,Esteves 1995 (Chidamber/Kemerer 1994) Złożoność klasy (WMC)- to, jeśli złożoność każdej metody klasy jest traktowana jako jeden, to WMC=n, gdzie n jest liczbą metod w klasie Złożoność metody jest obliczana w postaci wariantu złożoności cyklomatycznej liczby McCabe a; ponieważ ta miara jest addytywna, to można policzyć złożoność klasy. Głębokość drzewa dziedziczenia (DIT) zlicza poziomy, od korzenia drzewa Liczba potomków (NOC) zlicza klasy pochodne na sąsiednim poziomie Więź międzyobiektowa (CBO) zlicza komunikacje nie-dziedziczone Żądanie wygenerowane przez klasę (RFC) zlicza wszystkie metody stosowane przez klasę. Brak spójności w metodach (LCOM) identyfikuje metody, które stosują różne atrybuty. Postępowanie służące zarządzaniu i kontroli rozwoju oraz ewolucji projektu Dyscyplina określania elementów nieustannie rozwijającego się systemu programowego w celu kontrolowania zmian w tych elementach i pielęgnowania spójności oraz udogodnienia śledzenia zmian w ciągu całego cyklu zycia systemu Zbiór czynności słuzących zarządzaniu zmianą poprzez: identyfikację artefaktów ulegających zmianie, ustalenie relacji między nimi, określenie mechanizmów zarządzania wersjami, kontrolę zmian, audyt, raportowanie. Zarządzanie konfiguracją - podstawowe pojęcia Konfiguracja zmienny w czasie zestaw ustalonych artefaktów projektu i innych informacji, które są istotne do sprawnej jego realizacji. Jej elementy to: - Dokumentacja produktu programowego - Dokumentacja projektowa - Standardy, procedury, instrukcje - Kod programu Linia bazowa konfiguracji Zestaw artefaktów, który został poddany przeglądowi i zatwierdzony. Jest podstawą do dalszego rozwoju. Może być zmieniony tylko poprzez formalne procedury. Konfiguracja podstawowe pojęcia Jednostka (element) konfiguracji (ang. SCI) - artefakt powstały w trakcie procesu wytwarzania oprogramowania Identyfikowanie jednostki Nazwa Opis (typ SCI, identyf. projektu, wersja, informacja o zmianach) Zasoby wymagane przez SCI (np. zmienne globalne wymagane do kompilacji) Realizacja (np. odwołanie do pliku tekstowego z kodem) Typy elementów konfiguracji: oprogramowanie (kod źródłowy lub binarny) dokumenty (w tym podręczniki) dane (np. przypadki testowe) Zarządzanie konfiguracją błędy nie ma pewności, która wersja elementu jest wersją bieżącą (strata czasu, dodatkowy nakład pracy) niezgodności między poszczególnymi elementami konfiguracji (np. specyfikacja programu, kod i specyfikacja testów są

10 niezgodne) wydawanie produktów nie jest kontrolowane niekontrolowane zmiany w środowisku oprogramowania lub sprzętu bez analizy ich skutków w przypadku katastrofy - nie do odtworzenia bieżący stan przedsięwzięcia Zarządzanie zmianami (ZZ) obejmuje proces modyfikacji elementów linii bazowej w jednolity, spójny sposób. Żądanie zmian może dotyczyć różnorodnych elementów np. zmian wymagań, dokumentowania defektów, zmiany czasu przejścia między iteracjami. ZZ dotyczy struktury procesu Zarządzanie wersjami Dotyczy: elementu linii bazowej konfiguracji Cele: Kontrolowanie zmian Zarządzanie bazą wersji Kontrolowanie i przechowywanie historii zmian Wersja instancja artefaktu, która różni się od innych instancji oferowanymi funkcjami Wydanie wersja dostarczona użytkownikowi Zarządzanie wersjami - narzędzia Perforce Repozytorium Śledzenie działań programistów IBM Rational ClearCase CVS (Concurrent Versions System) SubVersion następca CVS; najbardziej popularny Dokumencik Funkcje narzędzi wersjonowania Zarządzanie repozytorium komponentów Zarządzanie wersjami Historia Przechowywanie delt Zarządzanie wielodostępem Zarządzanie relacjami między obiektami Zawieranie Zależność Wsparcie inżynieryjne - Kompilowanie i budowa projektu - Wsparcie środowiska pracy - Wsparcie pracy kooperacyjnej Wsparcie procesu projektowania Cofanie dowolnej liczby zmian Dokonywanie przeglądów sprawdzanie kompletności i spójności komponentów Ustalenie odpowiedzialności pracowników kto dopisał tę linię kodu, która powoduje błąd? Raportowanie: historii zmian różnic między wersjami aktywności pracowników statusu całego projektu i jego komponentów Oszczędność zasobów (czasu, pracy ), bezpieczeństwo Repository ( repozytorium) - miejsce, gdzie przechowywane są pliki Check-Out - pobranie pliku z repozytorium Update ( aktualizacja) - kopiuje zmiany dokonane w repozytorium do katalogu, w którym pracujemy Change ( zmiana) reprezentuje modyfikację do dokumentu znajdującego się pod kontrolą wersji. Commit (również: install, submit, check-in) - wgranie zmian do repozytorium Change List (lista zmian) zespół zmian dokonanych podczas jednej operacji commit Merge ( łączenie) łączy konkurencyjne zmiany do jednej zunifikowanej wersji Conflict ( konflikt) pojawia się, kiedy algorytm łączenia nie jest w stanie wygenerować poprawnej wersji zawierającej zmiany wprowadzone do łączonych plików Resolve ( rozwiązanie konfliktu) akt interwencji użytkownika w celu wsparcia algorytmu do nanoszenia różnych zmian tego samego do kumentu Blokada Łączenie plików (merging) Porównaj linię po linii dokument początkowy z wersjami zmienionymi Jeśli linia wystąpiła tylko w nowej wersji musi być dodana Jeśli linia wystąpiła tylko w pierwotnej wersji musi być usunięta Pielęgnacja oprogramowania

11 Typy konserwacji/pielęgnacji: - korekcyjna usuwanie błędów niewykrytych podczas testowania - adaptacyjna modyfikacja systemu dopasowująca go do zmian w środowisku - perfekcyjna rozszerzenie systemu do rozwiązywania nowych problemów lub uzyskania korzyści z nowych okoliczności - prewencyjna zabezpieczenie systemu przed przyszłymi problemami Konserwacja oprogramowania obejmuje 4 aktywności: otrzymanie wymagań konserwacyjnych transformacje wymagań w zmiany zaprojektowanie zmian zaimplementowanie zmian Pielęgnacja oprogramowania Powód prowadzenia modyfikacji (przykłady) 1. adaptacyjnej (dostosowującej): - zmiany wymagań użytkowników - zmiany przepisów prawnych, - zmiany organizacyjne w firmie klienta - zmiany sprzętu/oprogramowania systemowego 2. perfekcyjnej (ulepszającej): - poprawa wydajności pewnych funkcji - poprawa ergonomii interfejsu - poprawa przejrzystości raportów Przyczynami prowadzenia modyfikacji są na ogół żądania uzytkownikow Pielęgnacja oprogramowania Obiektywne czynniki kosztów konserwacji/pielęgnacji: stabilność środowiska pracy systemu stabilność platformy sprzętowej i oprogramowania systemowego czas użytkowania systemu Redukcja kosztów dzięki: znajomości dziedziny problemu wysokiej jakości modelu i projektu wysokiej jakości dokumentacji technicznej (możliwość stosowania inżynierii odwrotnej) stabilność personelu środowisko implementacji niezawodność oprogramowania zarządzanie wersjami Zarzadzanie przedsięwzięciem: Zarządzanie przedsięwzięciem (syn. projekt) - planowanie - szacowanie kosztów - komunikacja i nadzorowanie - zespół wytwórczy Przedsięwzięcie (projekt): każda działalność podjęta w celu osiągnięcia wyspecyfikowanych zamierzeń Własności projektu: złożony i nierutynowy zestaw działań, wymaga powierzenia ludzi, zasobów, kapitału i czasu, obejmuje różnych ludzi, funkcje i organizacje, wymaga ścisłej koordynacji i nadzorowania prowadzonych działań. ZARZĄDZANIE obejmuje działania: planowanie (decydowanie, co będzie wykonywane) organizację (aranżowanie prac) kierowanie (dawanie instrukcji) monitorowanie (kontrola postępu) nadzorowanie/sterowanie (podejmowanie akcji naprawczych) dobór personelu (wybór odpowiednich ludzi) innowacje (proponowanie nowych rozwiązań) prezentowanie (sesje z użytkownikami..)... I WSZYSTKO INNE Przedsięwzięcie kończy się sukcesem, gdy jest wykonane w terminie zgodnie ze specyfikacją, mieści się w przyznanym budżecie, a efekt jego zamierzeń posiada wymaganą jakość. Aktywności podczas inicjowania projektu 1. Aktywności i działania podejmowane w fazie inicjowania/opracowywania projektu

12 2. Ustalenie daty początku / końca projektu (sterowany czasem czy nakładem). 3. Wybór metodyki projektowej i/lub cyklu życia oprogramowania. 4. Ustalenie zakresu projektu ze względu na fazy wybranej metodyki; wybór struktury organizacyjnej. 5. Identyfikacja lub wybór metod oceny projektu. 6. Identyfikacja terminów krytycznych dla projektu (tymczasowe kamienie milowe). 7. Identyfikacja i podanie listy zadań w poszczególnych fazach w kolejności terminów ich zakończenia 8. Oszacowanie personelu potrzebnego do realizacji każdego z zadań. 9. Prezentacja personelu potrzebnego do realizacji każdego zadania. i określenie wymaganych umiejętności do realizacji podanych zadań. 10. Określenie zależności między zadaniami (zadania równoległe, warunki rozpoczęcia poszczególnych zadań itp.). 11. Wskazanie punktów kontrolnych projektu. 12. Dokonanie oszacowania kosztów projektu oraz analiza zysku. Plan Wytwarzania Oprogramowania (PWO) obejmuje: wykaz produktów, wybór środowiska wytwarzania szacunek rozmiaru i nakładu wymaganego do uzyskania produktów wybór modelu cyklu życia oprogramowania diagram WBS harmonogram specyfikację wymaganego personelu i jego organizację budżet czasowy zbierane miary projektu oraz opis strategii zbierania informacji Szacowanie kosztów - służy ilościowej ocenie przybliżonych kosztów zasobów wymaganych do zakończenia zaplanowanych aktywności projektu. ZASÓB każdy element lub człowiek potrzebny do zrealizowania projektu Kategorie zasobów: praca wyposażenie materiały środowisko pracy usługi czas pieniądze Szacunek kosztu jest prowadzony podczas: - studium wykonalności (-> wykonalność ekonomiczna : analiza koszt-korzyści) Cel: podjęcie decyzji o kontynuowaniu (lub nie) projektu - na poziomie planowania zadań (->harmonogram kosztów) Cel: ocena finansowej realizowalności projektu Szacunek kosztów zleceniobiorcy może być oparty o następujące rodzaje metod: osąd eksperta analogia z dołu do góry z góry do dołu cena do wygrania algorytmiczne wykorzystujace modele parametryczne W celu oszacowania kosztów szacuje się: 1. rozmiar oprogramowania (linie kodu, punkty funkcyjne, liczbe modułów, liczba klas) 2. nakład (pracochłonność) ( liczba osób/czas w miesiącach - MM) 3. czas trwania: liczba miesięcy wymagana do dostarczenia produktu 4. produktywność: rozmiar/nakład 5. koszt wytworzenia: koszt pracy zawarty w nakładzie METODY SZACOWANIA NA ETAPIE ANALIZY: analogia ( na poziomie systemu) analogia ( na poziomie pakietów) --> szacowanie metodą PERT modele parametryczne Model COCOMO (Constructive Cost Model B.Boehm 1981) Formuła szacowania nakładu pracy niezbędnej do wytworzenia produktu: Nakład = A (rozmiar) ^p rozmiar - rozmiar projektu w KLOC, A - określa wpływ parametrów systemu na wkład pracy, p - współczynnik dobierany w zależności od skali projektu.

13 Metoda punktów funkcyjnych (Albrecht 1987) Analiza punktów funkcyjnych rozpatruje możliwości systemu z punktu widzenia użytkownika. Złożoność funkcjonalna F (niska, średnia, duża) podawana w postaci punktów funkcyjnych FP; złożoność jest określana w oparciu o kombinację grupowania danych i elementów danych konkretnych typów. FPznor= UFP*( *suma(TCFi)) UFP nieskorygowana liczba punktów funkcyjnych TCF współczynnik złożoności technicznej Monitorowanie (długookresowa obserwacja zjawisk lub przedmiotów w celu poznania ich reakcji na działanie określonych czynników) zachowania się projektu: obserwacja rzeczywistych terminów rozpoczęcia i zakończenia zadań oraz porównywanie ich z zaplanowanymi (baseline), obserwacja zużycia zasobów Monitorowanie zabiera czas i zużywa zasoby; W zależności od ryzyka projektu (i zadań) można ograniczać monitorowanie do: - Zadań ścieżki krytycznej jakiekolwiek opóźnienie w tych zadaniach oznacza opóźnienie całego projektu; - Zadań bez możliwości manewru czasowego opóźnienie w nich spowoduje jednocześnie opóźnienie w części innych zadań, co z kolei może spowodować problemy w harmonogramie zasobów; - Zadań z niewielkim manewrem czasowym problemy jak poprzednio; - Zadań o wysokim ryzyku duże prawdopodobieństwo, że przekroczą one wyznaczony termin lub budżet; - Zadań wykorzystujące krytyczne zasoby ważne ze względu na dostępność ich w określonym czasie lub ilości. RAPORTOWANIE STANU PROJEKTU Cel: dostarczenie inwestorom informacji, jak są wykorzystane zasoby projektu w celu osiągnięcia zamierzeń projektowych; Informacje zawarte w raporcie dotyczą: zakresu, harmonogramu, kosztów, jakości, ryzyka (opcja) zakupów (opcja). Raportowanie obejmuje: Raportowanie statusu projektu Raportowanie postępu projektu Przewidywanego przebiegu projektu. Kategorie raportów: - Werbalny formalny regularny np. cotygodniowe spotkania - Werbalny formalny ad-hoc np. podsumowanie jakiegoś okresu - Pisemny formalny regularny np. raporty postępu - Pisemny formalny ad-hoc np. raporty na żądanie, informowanie o zmianach - Werbalny informacyjny ad-hoc okazyjne dyskusje, Zespół - grupa ludzi wspólnie pracujących w pewnej dziedzinie w celu osiągnięcia ustalonego celu. Optymalna liczność zespołu to 7 11 osób Powyżej osób komunikacja staje się niemożliwa Zalecenie, by zespół programistyczny był nie większy niż 8 osób ALE Profesjonalne oprogramowanie tworzone przez grupy 200 do kilkuset osób, więc konieczny Podział wielkiego zespołu na podzespoły (analogicznie do systemu na podsystemy) Sieciowa członkowie zespołu komunikują się i wspłpracują każdy z każdym Gwieździsta jedyną osobą wspłpracująca i komunikująca się z grupą jest szef zespołu Osobowości w zespole:cechy - Urojony przywódca Wydaje mu się, że dziś kieruje projektem, a jutro zacznie rządzić całą firmą. - Mysz Boi się jakichkolwiek samodzielnych działań, nic nie zrobi bez bezpośredniego polecenia. Ze strachu przed katastrofalną pomyłką wymaga od ciągłego nadzoru. - Ulubiony wujek (ciocia). Biurowy dowcipniś. Wygłupia się, opowiada kawały i zabawne historyjki, robi innym psikusy. Jest zabawny, ale marnuje strasznie dużo czasu. - Eksperymentator Uwielbia emocje. Jest szczęśliwy mogąc sprawdzić co się stanie, jeśli zrobi coś nietypowego. Może mieć duże doświadczenie, ale jest zbyt pewny siebie, a jego wyczyny nie zawsze są przemyślane. - Maruda Ponurak. Nie obchodzi go projekt, uważa, że technologia jest do niczego. Robi sobie 20 min. przerwy na kawę.