INŻYNIERIA OPROGRAMOWANIA [ 1968 ]

1. INŻYNIERIA OPROGRAMOWANIA [ 1968 ]

2. Zasady skutecznego działania • [ Stephen Covey] • Bądź proaktywny – odpowiedzialność  ś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

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

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

5. 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

6. 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 ...)

7. 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

8. 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

9. diagramy przypadków użycia • system • przypadek użycia • aktor • relacje

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

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

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

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

14. wspólny przypadek użycia « include» « include » przypadek użycia 1 przypadek użycia 2 relacja zawierania

15. 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

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

19. 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

20. 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.

21. 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.

22. 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

23. 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:

24. 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).

25. 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.

26. 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.

27. 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

28. 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ć

29. 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

30. 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 ............................................

31. 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

32. 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