INŻYNIERIA OPROGRAMOWANIA [ 1968 ]

Zasady skutecznego działania [ Stephen Covey ] Bądź proaktywny – odpowiedzialnośc  świadomy wybór Zaczynaj mając koniec na względzie Aby rzeczy pierwsze były pierwsze Myśl o obopólnej korzyści Najpierw staraj się zrozumieć Dbaj o synergię – 1 + 1 > 2 Ostrz piłę – odnowa fizyczna, umysłowa, społeczna i duchowa

OBIEKTOWE METODY PROJEKTOWANIA Faza Projektowania Ogólny Opis Systemu Architektura Systemu Faza Analizy Faza Implementacji Specyfikacja Systemu Gotowy System

Unified Modeling Language język modelowania – język do tworzenia modeli systemów modele : dokładne spójne łatwe do zmiany komunikatywne zrozumiałe

UML - unifikacja poprzednich metod : języki modelowania : zazwyczaj języki wizualne – widoki, diagramy, opisy w języku naturalnym UML - unifikacja poprzednich metod : Booch, OMT, OOSE/Objectory, Fusion, Coad/Yourdon zdefiniowany głównie przez [1997] : G. Booch, J. Rumbaugh, I. Jacobson wspierany przez DEC, HP, IBM, Microsoft, Oracle, Rational i innych UML : język modelowania zorientowany obiektowo

Czym jest UML język wizualny do opisu struktury statycznej dynamicznego zachowania się systemu główne części : widoki – obrazują główne aspekty systemu diagramy – opisują zawartość widoku elementy – pojęcia użyte w diagramach (klasy, obiekty, generalizacja ...)

Modelowanie przypadków użycia (use-case) do modelowania najbardziej ogólnego poziomu działania systemu porozumienie pomiędzy Projektantem a Klientem (formalny kontrakt) podstawa dalszego projektowania podstawa testowania

tworzenie modelu przypadków użycia definiowanie systemu znajdowanie aktorów znajdowanie przypadków użycia opisywanie przypadków użycia definiowanie relacji pomiędzy przypadkami użycia ocena modelu

diagramy przypadków użycia system przypadek użycia aktor relacje

inicjuje wykonanie funkcji systemu wymaga dostępu do systemu aktor inicjuje wykonanie funkcji systemu wymaga dostępu do systemu reprezentuje punkt widzenia na system jest osobą fizyczną lub innym systemem bibliotekarz kasjerka zegar

diagram przypadków użycia p-u p-u p-u aktor aktor system diagram przypadków użycia

Komentarz Klient Klient Bezpośredni Klient Zdalny uogólnianie aktorów

relacja rozszerzania specyficzny przypadek użycia aktor_B « extend » ogólny przypadek użycia aktor_A relacja rozszerzania

relacja zawierania wspólny przypadek użycia « include» « include »

temat przypadku użycia (cel) jak jest inicjowany opisywanie przypadków użycia : język naturalny temat przypadku użycia (cel) jak jest inicjowany przepływ komunikatów pomiędzy aktorami a przypadkami użycia (główny i alternatywne) jak przypadek użycia kończy się i dostarcza wyniku aktorowi

testowanie przypadków użycia weryfikacja i ocena (ręczna) odegranie przypadku użycia (testujący odgrywają rolę aktorów i systemu)

Specyfikacja wymagań opis systemu informatycznego będący podstawą kontraktu klient – wykonawca wymaganie  opis pojedynczej właściwości systemu specyfikacja wymagań  zbiór wymagań wymagania funkcjonalne i pozafunkcjonalne opisy wszystkich funkcji inne cechy realizowanych przez system systemu

Wymagania Pozafunkcjonalne  URPS { Usability, Reliability, Performance, Security } { Użyteczność, Niezawodność, Wydajność, Bezpieczeństwo } U - użyteczność, oznacza łatwość użytkowania systemu. Takie wymagania można precyzować np. poprzez maksymalny czas szkolenia pracownika, liczba kontaktów ze wsparciem klienta, liczbą sytuacji, w których konieczne jest skorzystanie z systemu pomocy.

R - niezawodność, może być mierzona poprzez: średnią liczbę godzin pracy bez awarii (MTBF - Mean Time Between Failure), maksymalną liczbą godzin w miesiącu w ciągu których system może być wyłączony w celach pielęgnacyjnych (maintainance) - ma to znaczenie szczególnie w przypadku systemów, które muszą pracować na okrągło - np. systemy bankowości elektronicznej P - wydajność - mierzona np. liczbą transakcji, którą system jest w stanie obsłużyć w ciągu godziny, liczbą użytkowników, którzy mogą być zalogowani jednocześnie do portalu S - bezpieczeństwo, to wymagania związane z szyfrowaniem, polityką praw, itp.

Wymagania Funkcjonalne znaczenie słów i zwrotów nie zawsze jest identyczne dla obu stron wiedza świadoma i nieświadoma nieprecyzyjne przymiotniki szybka reakcja, duża czcionka, odpowiednio dobrane kolory

formułowanie wymagań funkcjonalnych za pomocą definicji przypadków użycia ( use cases ) ID: Nazwa: Aktorzy główni: Aktorzy pomocniczy: Priorytet: Opis: Wyzwalacze: Warunki początkowe: Warunki końcowe: Scenariusz główny: Scenariusze alternatywne i rozszerzenia:

ID : LO_UC1 Nazwa : Logowanie na konto użytkownika Aktorzy główni: Odwiedzający Aktorzy pomocniczy: Brak Priorytet: Wysoki Opis: Odwiedzający posiada aktywne konto użytkownika i chce się na nie zalogować. Przechodzi na stronę logowania, wypełnia formularz wymaganymi danymi i je zatwierdza. Odwiedzający zostaje zalogowany w serwisie. Wyzwalacze: 1. Odwiedzający chce zalogować się do systemu. Warunki początkowe: Odwiedzający posiada konto użytkownika (UC5). Konto Odwiedzającego nie zostało zablokowane (UC7, US8).

Warunki końcowe: 1. Odwiedzający zalogował się na swoje konto użytkownika. Scenariusz Główny: 1. Odwiedzający przechodzi do strony logowania. 2. Serwis wyświetla formularz logowania. 3. Odwiedzający wypełnia formularz wymaganymi danymi i je zatwierdza. 4. Odwiedzający zostaje zalogowany. Scenariusze alternatywne i rozszerzenia: 3.A. Wprowadzone dane są nieprawidłowe lub niekompletne: 3.A.1. Serwis prezentuje informację o błędzie logowania. 3.A.2. Powrót do kroku 3.

3.B. Konto Użytkownika nie zostało aktywowane: 3.B.1. Serwis prezentuje informację o błędzie logowania z powodu nieaktywnego konta. 3.B.2. Powrót do kroku 2. 3.C. Konto zostało zablokowane: 3.C.1 Serwis prezentuje informację o błędzie logowania z powodu zablokowania konta. 3.C.2. Powrót do kroku 2. 3.D. Serwis wysyła do Odwiedzającego wiadomość SMS z kodem jednorazowym 3.D.1. Odwiedzający wprowadza kod jednorazowy i zatwierdza. 3.D.2. Kod jednorazowy jest poprawny – powrót do kroku 4. 3.D.3. Kod jednorazowy nie jest poprawny, serwis prezentuje informację o błędzie logowania – powrót do kroku 2.

Zasady definiowania przypadków użycia Fraza czasownikowa w nazwie Wystawianie faktury Generowanie raportu miesięcznego Główny przypadek użycia Przypadek użycia 23 Zarządzanie

Scenariusz i rozszerzenia maksymalna czytelność 3 – 9 punktów alternatywy i rozszerzenia ( nr punktu + litera ): głównego scenariusza nie da się zrealizować dodatkowe warianty można zagnieżdżać

Niezależność od technologii ( obojętność technologiczna ) technologie szybko się zmieniają szczegóły interfejsu graficznego (GUI) zaciemniają treść klient nie rozumie terminów informatycznych Pracownik klika na przycisk kalendarza System zapisuje dane w relacyjnej bazie danych Za pomocą protokołu SOAP system odczytuje temperaturę Dane wyświetlane są za pomocą elementu DataGrid w trybie JointTable

4. Scenariusze hierarchiczne UC1. Przeprowadzenie badania ankietowego UC1.1. Przygotowanie ankiety ........................................... UC1.2. Rozsyłanie ankiet UC1.2.1 Pozyskanie zbioru adresów UC1.2.2 Weryfikacja adresów UC1.2.3 Personalizowanie ankiet UC1.2.4. Wysyłanie ankiet UC1.3. Zbieranie odpowiedzi ............................................ UC1.4. Analizowanie odpowiedzi

5. Zespół przygotowujący wymagania pracownicy o różnych specjalnościach zespół niezbyt liczny ( 3 – 5 osób ) analitycy i klienci synergia: kompensowanie słabych stron jednej osoby silnymi stronami innej osoby większa liczba recenzentów

6. Często popełniane błędy UC1: Faktura Główny scenariusz: 1. Sprzedawca wpisuje kod dostępu 2. System weryfikuje użytkownika 3. Kliknięcie przycisku wystawiania faktury 4. System prezentuje formularz 5. Wpisanie pozycji w dolnym okienku 6. Wpisanie wartości pozycji, stawki VAT, liczby pozycji i nr porządkowego 7. System podlicza faskturę i prezentuje sumę 8. System nadaje nowy numer i zapisuje w rejestrze faktur 9. Wydruk faktury 10. Jeżeli wystawianie faktury się zakończyło to użytkownik się wylogowuje