INŻYNIERIA OPROGRAMOWANIA [ 1968 ]

INŻYNIERIA

OPROGRAMOWANIA[ 1968 ]

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

OBIEKTOWE METODY PROJEKTOWANIA

Faza Analizy

Specyfikacja Systemu

Faza Projektowania

Architektura Systemu

Ogólny Opis Systemu

Faza Implementacji

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

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

aktor

inicjuje wykonanie funkcji systemu

wymaga dostępu do systemu

reprezentuje punkt widzenia na system

jest osobą fizyczną lub innym systemem

bibliotekarz kasjerka zegar

systemaktor aktor

p-u

p-u

p-u

diagram przypadków użycia

Klient

Klient ZdalnyKlient Bezpośredni

Komentarz

uogólnianie aktorów

specyficzny przypadek użycia

ogólny przypadek użycia

« extend »

relacja rozszerzania

aktor_A

aktor_B

wspólny przypadek użycia

przypadek użycia 1 przypadek użycia 2

« include »« include»

relacja zawierania

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:

1. Odwiedzający posiada konto użytkownika (UC5).

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

1. Fraza czasownikowa w nazwie

Wystawianie faktury

Generowanie raportu miesięcznego

Główny przypadek użycia

Przypadek użycia 23

Zarządzanie

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

3. 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ą elementuDataGrid 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