INŻYNIERIA OPROGRAMOWANIA [ 1968 ]
description
Transcript of 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