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

Wielkość: px
Rozpocząć pokaz od strony:

Download "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: 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ę.

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2 Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów

Bardziej szczegółowo

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

Diagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com

Diagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com Diagramy klas dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com O czym będzie? Notacja Ujęcie w różnych perspektywach Prezentacja atrybutów Operacje i metody Zależności Klasy aktywne,

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................

Bardziej szczegółowo

Przedsięwzięcia Informatyczne w Zarządzaniu

Przedsięwzięcia Informatyczne w Zarządzaniu Przedsięwzięcia Informatyczne w Zarządzaniu 2005/06 dr inż. Grażyna Hołodnik-Janczura GHJ 1 LITERATURA 1. Praca zbiorowa p.r. Górski J., Inżynieria oprogramowania, MIKOM, W-wa, 2000 2. Jaszkiewicz A.,

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

Modelowanie i Programowanie Obiektowe Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Modelowanie danych, projektowanie systemu informatycznego

Modelowanie danych, projektowanie systemu informatycznego Modelowanie danych, projektowanie systemu informatycznego Modelowanie odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym Modele - konceptualne reprezentacja obiektów w uniwersalnym

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Web frameworks do budowy aplikacji zgodnych z J2EE

Web frameworks do budowy aplikacji zgodnych z J2EE Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida promotor: dr Dariusz Król Przypomnienie Celem pracy jest porównanie wybranych szkieletów programistycznych o otwartym kodzie źródłowym

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

Maciej Oleksy Zenon Matuszyk Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)

Bardziej szczegółowo

Wykład 7. Projektowanie kodu oprogramowania

Wykład 7. Projektowanie kodu oprogramowania Wykład 7 Projektowanie kodu oprogramowania Treść wykładu cykl życiowy oprogramowania zagadnienia inżynierii oprogramowania tworzenie oprogramowania z gotowych elementów tworzenie niezawodnego oprogramowania

Bardziej szczegółowo

Michał Adamczyk. Język UML

Michał Adamczyk. Język UML Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy

Bardziej szczegółowo

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy

Bardziej szczegółowo

Zapewnij sukces swym projektom

Zapewnij sukces swym projektom Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie

Bardziej szczegółowo

Diagramy przypadków użycia

Diagramy przypadków użycia Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy

Bardziej szczegółowo

Analiza i projektowanie aplikacji Java

Analiza i projektowanie aplikacji Java Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie

Bardziej szczegółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Zakres wykładu. Podstawy InŜynierii Oprogramowania Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,

Bardziej szczegółowo

Rysunek 1: Przykłady graficznej prezentacji klas.

Rysunek 1: Przykłady graficznej prezentacji klas. 4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez

Bardziej szczegółowo

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan testów M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 SPIS TREŚCI 2 Spis treści 1 Historia zmian 3 2 Zakres testów 3 2.1 Integration testing - Testy spójnosci.............. 3 2.2

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Dr Katarzyna Grzesiak-Koped

Dr Katarzyna Grzesiak-Koped Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd

Bardziej szczegółowo

poziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS

poziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS poziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS Niniejszy dokument jest syllabusem obowiązującym dla certyfikatu EUCIP ver. 2.6. Prezentuje obszary wiedzy, których znajomość jest niezbędna do

Bardziej szczegółowo

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Notka biograficzna Dr inż. Mariusz Trzaska jest adiunktem w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zajmuje się

Bardziej szczegółowo

Wprowadzenie do zarządzania projektami

Wprowadzenie do zarządzania projektami Wprowadzenie do zarządzania projektami Project Management dr Marek Wąsowicz Katedra Projektowania Systemów Zarządzania, UE Wrocław Wrocław, 23 października 2012 r. Zawartość modułu (4h): wskazanie możliwości

Bardziej szczegółowo

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Modelowanie diagramów klas w języku UML Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Czym jest UML - Unified Modeling Language - Rodzina języków modelowania graficznego - Powstanie na przełomie lat 80

Bardziej szczegółowo

Paweł Kurzawa, Delfina Kongo

Paweł Kurzawa, Delfina Kongo Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management

Bardziej szczegółowo

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny mgr inż. Kajetan Kurus 15 kwietnia 2014 1 Dostępne techniki programowania Tworząc program należy

Bardziej szczegółowo

Diagramy klas. WYKŁAD Piotr Ciskowski

Diagramy klas. WYKŁAD Piotr Ciskowski Diagramy klas WYKŁAD Piotr Ciskowski przedstawienie statyki systemu graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi obiekty byt, egzemplarz

Bardziej szczegółowo

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

Plan zarządzania projektem

Plan zarządzania projektem Plan zarządzania projektem Opracował: Zatwierdził: Podpis: Podpis: Spis treści: 1. Wst p... 2 1.1 Cel... 2 1.2 Zakres... 2 1.3 Przeznaczenie dokumentu... 2 1.4 Organizacja dokumentu... 2 1.5 Dokumenty

Bardziej szczegółowo

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

Bardziej szczegółowo

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Zarządzanie testowaniem wspierane narzędziem HP Quality Center Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

UML cz. III. UML cz. III 1/36

UML cz. III. UML cz. III 1/36 UML cz. III UML cz. III 1/36 UML cz. III 2/36 Diagram współpracy Diagramy współpracy: prezentują obiekty współdziałające ze sobą opisują rolę obiektów w scenariuszu mogą prezentować wzorce projektowe UML

Bardziej szczegółowo

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki. Inżynieria Programowania Zarządzanie projektem Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 3 października 2013 Plan wykładu 1. Wstęp 2. Czynności zarządzania 3.

Bardziej szczegółowo

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2 Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu Projekt ZEFIR 2 1 Metryka dokumentu Nazwa projektu Właściciel projektu Izba Celna Wykonawca* Produkt Autorzy Plik_wersja

Bardziej szczegółowo

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot Inżynieria Programowania Inżynieria Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 20 października 2015 Plan wykładu 1. Wstęp 2. Studium wykonywalności 3. Określanie

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20 Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę

Bardziej szczegółowo

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji Modelowanie danych. Model związków-encji Plan wykładu Wprowadzenie do modelowania i projektowania kartograficznych systemów informatycznych Model związków-encji encje atrybuty encji związki pomiędzy encjami

Bardziej szczegółowo

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo

Inżynieria Programowania Zarządzanie projektem

Inżynieria Programowania Zarządzanie projektem Inżynieria Programowania Zarządzanie projektem Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 12 października 2015 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i

Bardziej szczegółowo

Projekt systemu informatycznego

Projekt systemu informatycznego Projekt systemu informatycznego Kod przedmiotu: PSIo Rodzaj przedmiotu: specjalnościowy ; obieralny Wydział: Informatyki Kierunek: Informatyka Specjalność (specjalizacja): Inżynieria Systemów Informatycznych

Bardziej szczegółowo

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja I

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja I Zespół TI Instytut Informatyki Uniwersytet Wrocławski ti@ii.uni.wroc.pl http://www.wsip.com.pl/serwisy/ti/ Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja I Rozkład zgodny

Bardziej szczegółowo

Cykle życia systemu informatycznego

Cykle życia systemu informatycznego Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów

Bardziej szczegółowo

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania...

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania... Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników Spis treúci Wstęp... 11 Podziękowania... 13 O autorach... 15 Robert A. Maksimchuk... 15 Eric J. Naiburg... 15 Przedmowa...

Bardziej szczegółowo

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0

ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0 ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0 Przeznaczenie Sylabusa Dokument ten zawiera szczegółowy Sylabus dla modułu ECDL/ICDL Zarządzanie projektami. Sylabus opisuje zakres wiedzy

Bardziej szczegółowo

Projektowanie Modeli Usług dla rozwiązań typu SOA

Projektowanie Modeli Usług dla rozwiązań typu SOA Projektowanie Modeli Usług dla rozwiązań typu SOA Service Oriented Modeling and Architecture (SOMA ) IBM Global Business Services, zdefiniował zestaw usług konsultingowych oraz narzędzi pomagających organizacjom

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW 01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO

Bardziej szczegółowo

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II Zespół TI Instytut Informatyki Uniwersytet Wrocławski ti@ii.uni.wroc.pl http://www.wsip.com.pl/serwisy/ti/ Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II Rozkład wymagający

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie

Bardziej szczegółowo

Testy poziom po poziomie

Testy poziom po poziomie poziom po poziomie Prowadzący: Tomasz Mielnik Eliza Słonińska Agenda 1. Modele prowadzenia projektów 2. V-Model 3. Poziomy testów 4. Typy testów 5. Zadanie 1 Modele prowadzenia projektów Wodospadowy (ang.

Bardziej szczegółowo

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo

Systemy ERP. dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/

Systemy ERP. dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/ Systemy ERP dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/ Źródło: Materiały promocyjne firmy BaaN Inventory Control Jako pierwsze pojawiły się systemy IC (Inventory Control) - systemy zarządzania

Bardziej szczegółowo

Projektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc.

Projektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc. Projektowanie oprogramowania Termin zajęć: poniedziałek, 18.00-19.45 a podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/ Przebieg realizacji projektu (tabela 1) Nr tygo dnia Spotkanie

Bardziej szczegółowo

Testowanie oprogramowania

Testowanie oprogramowania Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

KARTA MODUŁU KSZTAŁCENIA KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator

Bardziej szczegółowo

Projektowanie oprogramowania

Projektowanie oprogramowania Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management

Bardziej szczegółowo

Szablon Planu Testów Akceptacyjnych

Szablon Planu Testów Akceptacyjnych Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia

Bardziej szczegółowo

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.6 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

Bardziej szczegółowo

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosław Żeliński analityk biznesowy, projektant systemów Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia

Bardziej szczegółowo

Systemy baz danych w zarządzaniu przedsiębiorstwem. W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi

Systemy baz danych w zarządzaniu przedsiębiorstwem. W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi Systemy baz danych w zarządzaniu przedsiębiorstwem W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi Proces zarządzania danymi Zarządzanie danymi obejmuje czynności: gromadzenie

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia CASE dla.net. Łukasz Popiel Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania

Bardziej szczegółowo

Spis treści 1. Wstęp 2. Projektowanie systemów informatycznych

Spis treści 1. Wstęp 2. Projektowanie systemów informatycznych Spis treści 1. Wstęp... 9 1.1. Inżynieria oprogramowania jako proces... 10 1.1.1. Algorytm... 11 1.2. Programowanie w językach wysokiego poziomu... 11 1.3. Obiektowe podejście do programowania... 12 1.3.1.

Bardziej szczegółowo

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA Projekt to metoda na osiągnięcie celów organizacyjnych. Jest to zbiór powiązanych ze sobą, zmierzających

Bardziej szczegółowo

2.11. Monitorowanie i przegląd ryzyka 2.12. Kluczowe role w procesie zarządzania ryzykiem

2.11. Monitorowanie i przegląd ryzyka 2.12. Kluczowe role w procesie zarządzania ryzykiem Spis treści Wstęp 1. Wprowadzenie 1.1. Co to jest bezpieczeństwo informacji? 1.2. Dlaczego zapewnianie bezpieczeństwa informacji jest potrzebne? 1.3. Cele, strategie i polityki w zakresie bezpieczeństwa

Bardziej szczegółowo

Transformacja wiedzy w budowie i eksploatacji maszyn

Transformacja wiedzy w budowie i eksploatacji maszyn Uniwersytet Technologiczno Przyrodniczy im. Jana i Jędrzeja Śniadeckich w Bydgoszczy Wydział Mechaniczny Transformacja wiedzy w budowie i eksploatacji maszyn Bogdan ŻÓŁTOWSKI W pracy przedstawiono proces

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.

Bardziej szczegółowo

Spis treści Wstęp 1. Wprowadzenie 2. Zarządzanie ryzykiem systemów informacyjnych

Spis treści Wstęp 1. Wprowadzenie 2. Zarządzanie ryzykiem systemów informacyjnych Wstęp... 13 1. Wprowadzenie... 15 1.1. Co to jest bezpieczeństwo informacji?... 17 1.2. Dlaczego zapewnianie bezpieczeństwa informacji jest potrzebne?... 18 1.3. Cele, strategie i polityki w zakresie bezpieczeństwa

Bardziej szczegółowo