Projektowanie systemów informatycznych Zarządzanie projektemprac.us.edu.pl/~siminski/ip_psi/zpi_w_03.pdf · Projektowanie systemów informatycznych. ... Inżynieria wymaga ... często

Zarządzanie projektemZarządzanie projektem

Inżyniera wymagań

Roman Simiński

[email protected]/~siminski

Autor

Kontakt

Projektowanie systemów informatycznychProjektowanie systemów informatycznych

Cel wykładuCel wykładuZarządzanie projektem informatycznymZarządzanie projektem informatycznym

Copyright © Roman Simiński 2Strona :

Inżyniera wymagańInżyniera wymagań

Przedstawienie inżynierii wymagań jako istotnego i trudnego elementu zarządzania projektem informatycznym.

Zleceniodawca jako źródło wymagań stawianych systemowi.

Zdefiniowanie i przedstawienie różnicy pomiędzy różnymi rodzajami wymagań.

Przedstawienie metod zarządzania wymaganiami.

Ale o co im właściwie chodzi?

Wymagania w projektowaniu systemów informatycznychWymagania w projektowaniu systemów informatycznychZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wymagania to opis funkcji (usług), które mają być realizowane przez system i opis ograniczeń dla systemu.

Wymagania nie opisują jak system ma działać a co ma wykonywać.

Wymagania są definiowane na wczesnych etapach rozwoju systemu jako specyfikacja tego, co ma być implementowane.

W zakresie zarządzania projektem można wyróżnić różne typy wymagań stawianych systemowi.

Wymagania = opis funkcji + opis ograniczeń

Istnieją różne definicje wymagań dla systemów informatycznych. Dla potrzeb niniejszych zajęć przyjmijmy:

Zarządzanie wymaganiami — inżynieria wymagańZarządzanie wymaganiami — inżynieria wymagańZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Celem inżynierii wymagań jest:

pozyskanie informacji pozwalających na określenie wymagań,

zidentyfikowane wymagań i ich kategorii,

analiza wymagań (jednoznaczność, spójność, zgodność z założeniami),

opisanie wymagań — opracowanie specyfikacji wymagań,

weryfikacja wymagań,

zarządzanie zmianami wymagań w trakcie realizacji projektu.

Inżynieria wymagań to proces pozyskiwania, analizowania, dokumentowania oraz weryfikowania wymagań dla projektowanego systemu.

Inżynieria wymagań — graficzna ilustracja koncepcjiInżynieria wymagań — graficzna ilustracja koncepcjiZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Inżynieria wymagań

Opracowywanie wymagań

Zarządzanie wymaganiami

Pozyskiwanie

Analiza

Specyfikacja

Weryfikacja

Po co inżynieria wymagań?Po co inżynieria wymagań?Zarządzanie projektem informatycznymZarządzanie projektem informatycznym



Tak klient opisał, czego wymaga od systemu

Tak wymagania klienta zrozumiał analityk

Tak projektanci zrozumieli analityka

i taki stworzyli projekt

Tak programiści zrozumieli projekt

i to zaprogramowali

Po poprawkach wdrożono coś takiego

Za to klient zapłacił Tego klient chciał Oto, do czego się projekt nadawał i jak użyto jego

efektów

Rysunki pochodzą ze strony: http://usprawnienia.pl/

Po poprawkach wdrożono coś takiego

Inżynieria wymagań jako metod likwidowania przepaściInżynieria wymagań jako metod likwidowania przepaściZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Czy to tylko zabawna rysunkowa historyjka?

KlientWykonawca

Wielki Kanion

Inżynieria wymagań jako metod likwidowania przepaściInżynieria wymagań jako metod likwidowania przepaściZarządzanie projektem informatycznymZarządzanie projektem informatycznym



KlientMyślę, że system zapewni nam

minimalizację stanów magazynowych, co spowoduje mniejsze zaangażowanie

bieżących środków na zakup surowców, przy jednoczesnym utrzymaniu płynności produkcji na dotychczasowym poziomie.

Informatyk

Napiszę to obiektowo w Javie, ale bazę

wykorzystam relacyjną, dla magazynu zrobię

aplet, reszta będzie w JSP.

Na marginesie — brak ciągłości specyfikacji to też problemNa marginesie — brak ciągłości specyfikacji to też problemZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Kolejny Wielki Kanion...

ProjektantProgramista

Inżynieria wymagań — spotkanie dwóch światówInżynieria wymagań — spotkanie dwóch światówZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wizja informatykaWizja klienta

Współdziałanie, komunikacja, synergia

Inżynieria wymagań — spotkanie dwóch światówInżynieria wymagań — spotkanie dwóch światówZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Cele strategiczne, strategie biznesowe, oczekiwania, nadzieje, ograniczenia

Własne cele biznesowe, technologia, wiedza, zaplecze, doświadczenie, ograniczenia

Realizacja projektu

Pozyskiwanie, analiza i specyfikacja wymagań

Wymagania

Realizowalność + ryzyko

Inżynieria wymagań — kto jest naszym zleceniodawcą?Inżynieria wymagań — kto jest naszym zleceniodawcą?Zarządzanie projektem informatycznymZarządzanie projektem informatycznym



Kto powinien określać wymagania dla

projektowanego systemu?

System ma służyć organizacji i wspierać realizację jej celów strategicznych.

System wcale nie jest po to, by ludziom pracowało się łatwiej i wygodniej.

Użytkownik końcowy (operator systemu) często nie rozumie jego działania w sensie globalnym.

Inżynieria wymagań — kto jest naszym zleceniodawcą?Inżynieria wymagań — kto jest naszym zleceniodawcą?Zarządzanie projektem informatycznymZarządzanie projektem informatycznym



Zidentyfikuj przedstawicieli zamawiającego system

Rozdziel przedstawicieli na decydentów i operatorów

Przeanalizuj ichpunkty widzenia

Przejdź do wydobywania wymagań

Rozdzielaj ale nie dyskryminuj — każdy jest ważnym źródłem wymagańRozdzielaj ale nie dyskryminuj — każdy jest ważnym źródłem wymagańZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wyższe kierownictwo określa cele strategiczne i cele systemu — oni wiedzą czego chcą, choć niekoniecznie jak to osiągnąć.

Kadra kierownicza średniego szczebla — oni zwykle wiedzą jak osiągnąć poszczególne cele cząstkowe.

Kadra kierownicza niższego szczebla — oni znają procesy biznesowe w ich realnym wymiarze.

Szeregowi pracownicy — oni wiedzą dokładnie jak wykonać każdą elementarna operację.

Poziomy i typy wymagańPoziomy i typy wymagańZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wyższe kierownictwo określa cele strategiczne i cele systemu — oni wiedzą czego chcą, choć niekoniecznie jak to osiągnąć.

Wymagania biznesowe

Kadra kierownicza średniego szczebla — oni zwykle wiedzą jak osiągnąć poszczególne cele cząstkowe.

Opisują cel, który chce osiągnąć zleceniodawca dzięki realizacji danego projektu. Pozwalają zespołowi projektowemu poznać wizję i zakres projektowanego systemu oczami decydentów zleceniodawcy.

Można stworzyć dokument: „Wizja i zakres projektu”.

Poziomy i typy wymagańPoziomy i typy wymagańZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wymagania użytkowe

Kadra kierownicza niższego szczebla — oni znają procesy biznesowe w ich realnym wymiarze.

Szeregowi pracownicy — oni wiedzą dokładnie jak wykonać każdą elementarna operację.

Opisują to, co użytkownicy będą mogli wykonać w systemie. Określają ogólny scenariusz realizacji poszczególnych operacji istotnych dla użytkownika.

Scenariusze te mogą być spisane w dokumencie „Przypadki użycia”. Dokument ten stanowi podstawę do określenia szczegółowych funkcji systemu.

Wymagania biznesowe i użytkoweWymagania biznesowe i użytkoweZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wymagania biznesowe

Wymagania użytkowe

Wizja i zakresprojektu

Przypadkiużycia

Dokument — im konkretniejszy tym lepiej, jednak nie stosuje

się notacji formalnych

Dokument — rysunki + opis, zwykle Use Case Diagrams z UML

Wymagania biznesowe, użytkowe i wymaganie funkcjeWymagania biznesowe, użytkowe i wymaganie funkcjeZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wymagania biznesowe

Wymagania użytkowe


Przypadkiużycia

Wymagane funkcje

Wymagane funkcje specyfikują dokładnie to, co system powinien robić — czyli to, co zespół programistów powinien zrealizować w formie programu komputerowego.

Wymagania funkcjonalne

Wymagania funkcjonalneWymagania funkcjonalneZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wymagania biznesowe

Wymagania użytkowe


Przypadkiużycia

Wymagane funkcje

Wymagania funkcjonalne — to wszystko opisuje co ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach.


Specyfikacja wymagań systemu SRSSpecyfikacja wymagań systemu SRSZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Specyfikacjawymagań

Wymagania biznesowe

Wymagania użytkowe


Przypadkiużycia

Wymagane funkcje

Specyfikacja wymagań systemu SRS(ang. software requirements specification)

Dokument ten jest oficjalna listą wymagań projektowanego systemu dla klienta, użytkowników końcowych oraz zespołu projektowego.

Istnieją normy określające postać, cechyi formę takiego dokumentu.


Wymagania niefunkcjonalneWymagania niefunkcjonalneZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Wymagania niefunkcjonalne


Wymagania biznesowe

Wymagania użytkowe


Przypadkiużycia

Wymagane funkcje

?

Wymagania niefunkcjonalne — ogólnieWymagania niefunkcjonalne — ogólnieZarządzanie projektem informatycznymZarządzanie projektem informatycznym





?Wymagania niefunkcjonalne — nie mają bezpośredniego wpływu na funkcjonalność systemu.

Nakładają one ograniczenie na sposób, w jaki sposób wymagania funkcjonalne będą zrealizowane.


Wymagania niefunkcjonalne — różne rodzajeWymagania niefunkcjonalne — różne rodzajeZarządzanie projektem informatycznymZarządzanie projektem informatycznym





Cele strategiczne

Kultura organizacji

Polityka firmy

Cele operacyjne

Technologia

Specyfika dziedziny

Wymagania biznesowe

Wymagania użytkowe


Przypadkiużycia

Wymagane funkcje

Klasyfikacja wymagań — wymagania funkcjonalneKlasyfikacja wymagań — wymagania funkcjonalneZarządzanie projektem informatycznymZarządzanie projektem informatycznym



określają jaki pożądane z punktu widzenia zamawiającego funkcje powinien posiadać system,

powinny pozwolić na realizację określonych wymagań biznesowych i prowadzić do celu systemu określonego w jego wizji i zakresie,

specyfikują co system ma realizować a nie jak ma to być zrobione.

Wymagania funkcjonalne:

System obsługi biblioteki powinien umożliwiać klientowi tej biblioteki przeszukiwanie jej zasobów katalogowych w poszukiwaniu konkretnej książki. Wyszukiwanie może odbywać się wg danych autora, tytułu książki lub wydawnictwa. Wyszukaną książkę klient może zarezerwować do wypożyczenia lub wypożyczyć. Wyszukiwanie może realizować każdy klient, rezerwować i wypożyczać może jedynie klient, który przeszedł proces rejestracji w systemie. Rejestracja obejmuje podanie imienia, nazwiska i adresu zamieszkania.

Przykład Biblioteka : Uproszczone wymagania funkcjonalne w języku naturalnym

Klasyfikacja wymagań — wymagania niefunkcjonalneKlasyfikacja wymagań — wymagania niefunkcjonalneZarządzanie projektem informatycznymZarządzanie projektem informatycznym



określają pożądane cechy systemu, nie wpływając bezpośrednio na istnienie konkretnych funkcji;

wpływają jednak zwykle na to, jak te funkcje będą realizowane.

Wymagania niefunkcjonalne:

ustaw, norm, przepisów, kodeksów;

strategii biznesowego działania zleceniodawcy, kultury jego organizacji, specyfiki jego działania rynkowego;

ograniczeń dziedziny dla której system jest tworzony;

technologii i metod realizacji systemu;

wymagań jakościowych i technicznych.

Wymagania niefunkcjonalne mogą wypływać z:

Klasyfikacja wymagań — wymagania niefunkcjonalneKlasyfikacja wymagań — wymagania niefunkcjonalneZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Klienci biblioteki nie płacą za korzystanie z niej. Strategia biblioteki zakłada jednak, że aby skorzystać z jej zasobów, klient musi się zarejestrować ujawniając dane obejmujące imię, nazwisko oraz adres zamieszkania.

Podając te informacje w trakcie rejestracji klient musi zgodzić się na przetwarzanie jego danych osobowych a system biblioteczny musi przestrzegać ograniczeń narzucanych przez ustawę o ochronie danych osobowych.

Przykład Biblioteka : Wymagania niefunkcjonalne — kontekst biznesowy

System obsługi biblioteki ma być aplikacją WWW, zrealizowaną w architekturze klient-serwer, przy czym warstwa kliencka jest „cienka” — realizuje ją przeglądarka internetowa.

W trakcie rejestracji klienta jego dane mają być przekazywane w połączeniu zapewniającym bezpieczeństwo chronionych informacji osobistych.

Przykład Biblioteka : Wymagania niefunkcjonalne — kontekst technologiczny

Specyfikacja wymagań — SRSSpecyfikacja wymagań — SRSZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Specyfikacją wymagań dla oprogramowaniu lub systemu — ang. Software Requirements Specification (SRS) jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu przez zleceniodawcę.

Dokument SRS nie jest dokumentem projektowym, stanowi materiał wejściowy dla analityków i projektantów systemu.

Istnieję standardy wykonywania SRS — IEEE Recommended Practice for Software Requirements Specyfication, IEEE std 830-1998.

DokumentSRS

Specyfikacja wymagań a uczestnicy projektuSpecyfikacja wymagań a uczestnicy projektuZarządzanie projektem informatycznymZarządzanie projektem informatycznym



DokumentSRSTesterzy

Wymagania pozwalają opracować plan testów systemu

AnalitycyWymagania pozwalają opracować koncepcję i architekturę systemu

ProjektanciWymagania pozwalają zaprojektować strukturę systemu

ProgramiściWymagania weryfikują szczegóły implementacji gdy jest taka potrzeba

Zarządzający ITWymagania pozwalają na zaplanowanie projektu, i zarządzanie jego realizacją

ZleceniodawcyOkreślają wymagania, weryfikują ich zgodność z potrzebami, określają potrzebę zmian.

Specyfikacja wymagań — kryteria jakości dokumentu SRSSpecyfikacja wymagań — kryteria jakości dokumentu SRSZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Poprawność.

Jednoznaczność.

Kompletność.

Spójność.

Informacja o wydajności i stabilności.

Weryfikowalność.

Modyfikowalność.

Możliwość śledzenia powiązań.

Dokument SRS — struktura ogólnaDokument SRS — struktura ogólnaZarządzanie projektem informatycznymZarządzanie projektem informatycznym



1 Wprowadzenie

2 Ogólny opis produktu

3 Wymagania funkcjonalne

4 Wymagania niefunkcjonalne

Dodatki

Indeks

IEEE Recommended Practice for Software Requirements Specification

IEEE std 830-1998

Dokument SRS — wprowadzenieDokument SRS — wprowadzenieZarządzanie projektem informatycznymZarządzanie projektem informatycznym



1 Wprowadzenie

1.1 Cel dokumentu

1.2 Zakres produktu

1.3 Definicje, akronimy i skróty

1.4 Odwołania do literatury

1.5 Omówienie dokumentu




Dodatki

Indeks


IEEE std 830-1998

Dokument SRS — ogólny opis produktuDokument SRS — ogólny opis produktuZarządzanie projektem informatycznymZarządzanie projektem informatycznym



1 Wprowadzenie


2.1 Kontekst funkcjonowania

2.2 Charakterystyka użytkowników

2.3 Główne funkcje produktu

2.4 Ograniczenia

2.5 Założenia i zależności



Dodatki

Indeks


IEEE std 830-1998

Dokument SRS — wymagania funkcjonalneDokument SRS — wymagania funkcjonalneZarządzanie projektem informatycznymZarządzanie projektem informatycznym



1 Wprowadzenie



3.1 . . .

3.2 . . .

. . .

3.n . .


Dodatki

Indeks


IEEE std 830-1998

Dokument SRS — wymagania niefunkcjonalneDokument SRS — wymagania niefunkcjonalneZarządzanie projektem informatycznymZarządzanie projektem informatycznym



1 Wprowadzenie




4.1 . . .

4.2 . . .

. . .

4.m . .

Dodatki

Indeks


IEEE std 830-1998

Diagramy przypadków użycia jako narzędzie modelowania wymagańDiagramy przypadków użycia jako narzędzie modelowania wymagańZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Diagramy przypadków użycia — use case diagrams.

Nazwa diagramu UML:

Określenie wymagań stawianych systemowi — czyli co system ma robić z punktu widzenia jego otoczenia.

Określenie granic systemu — jego otoczenia oraz elementów, które wchodzą z nim w interakcję.

Cel stosowania:

Diagramy przypadków użycia opisują, co robi system z punktu widzenia zewnętrznego obserwatora.

Eksponują to, co robi system, a nie jak to robi.

Diagramy przypadków użycia jako narzędzie modelowania wymagańDiagramy przypadków użycia jako narzędzie modelowania wymagańZarządzanie projektem informatycznymZarządzanie projektem informatycznym



Główne zastosowania:

Określanie i doprecyzowanie funkcji systemu — opisywane przypadki użycia zwykle generują nowe wymagania, a projekt przybiera coraz wyraźniejszy kształt.

Komunikacja z klientami — prostota notacji i intuicyjność sprawiają, że diagramy przypadków użycia są dobrym sposobem porozumiewania się projektantów z przyszłymi użytkownikami systemu.

Generowanie przypadków testowych — opis danego przypadku użycia może zasugerować sposoby testowania i konkretne dane testowe.

Zrozumienie różnych scenariuszy wykorzystania projektowanego systemu.

Porozumiewanie się projektantów systemu i jego przyszłych użytkowników.

Zarządzanie projektem informatycznymZarządzanie projektem informatycznym



Komponenty diagramów przypadków użyciaKomponenty diagramów przypadków użycia

Aktor

Przypadek użycia

Związek

Przypadekużycia

Aktor




Komponenty diagramów przypadków użycia — aktorzyKomponenty diagramów przypadków użycia — aktorzy

Aktorami mogą być ludzie, urządzenia, inne systemy informatyczne.

Pojęcia aktora odpowiada roli jaką on odgrywa w stosunku do systemu.

Pojęcia aktora nie odpowiada zawsze np. konkretnej osobie fizycznej, bo ta może wcielać się w różne role (ta sama osoba fizyczna może się logować do systemu raz jako administrator, a innym razem jako zwykły użytkownik).

Jeden aktor może reprezentować całą grupę fizycznych użytkowników systemu (aktor Klient reprezentuje wszystkich potencjalnych klientów systemu).

Aktorzy są zwykle aktywni — inicjują przypadku użycia, choć mogą być również pasywni (np. aktor tyko zatwierdzający przelew bankowy).

Klient Admin Kierownik

<<Actor>>System obsługi kart

płatniczych

<<Actor>>System weryfikacji

podpisu elektronicznego




Komponenty diagramów przypadków użycia — przypadki użyciaKomponenty diagramów przypadków użycia — przypadki użycia

Przypadek użycia reprezentuje sekwencję operacji wykonywanych przez system, inicjowanych przez aktora.

Przypadek użycia modeluje oczekiwanie zachowanie systemu wobec danego aktora, nie precyzując sposobu realizacji tego zachowania.

Uruchomienie danego przypadku użycia ma dostarczyć aktorowi wymiernych wyników.

Przypadek użycia zwykle opisuje pewien większy, dłuższy, bardziej złożony proces a nie elementarną akcję.

Porada lekarska Sprzedaż towaru Wystawienie faktury




Komponenty diagramów przypadków użycia — związkiKomponenty diagramów przypadków użycia — związki

Związek pomiędzy aktorem a przypadkiem użycia opisuje udział aktora w danym przypadku użycia.

Pomiędzy przypadkami użycia mogą występować związki — zostaną przedstawione za chwilę.

Porada lekarska

Pacjent

Aktor Pacjent inicjuje przypadek użycia Porada lekarska. Jest to pewien nieelementarny proces, wynikiem którego jest umówienie wizyty lekarskiej oraz przygotowanie kartoteki pacjenta. Ten przypadek użycia dostarcza aktorowi konkretnych efektów działania systemu.




Związki pomiędzy przypadkami użycia — zawieranie Związki pomiędzy przypadkami użycia — zawieranie

Czasem wiele przypadków użycia posiada pewną wspólną sekwencję operacji (wspólne zachowanie) — można ją wyróżnić w postaci odrębnego przypadku użycia.

Wspólny, odrębny przypadek użycia włącza się do przypadku bazowego wykorzystując związek zawierania, opisany stereotypem <<include>>.

Przypadek bazowy występuje jako pierwszy i zawsze używa przypadku składowego.

Składowy przypadek użycia reprezentuje podzadanie, zadania jakim jest przypadek bazowy.

Przypadek składowyPrzypadek bazowy<<include>>




Związki pomiędzy przypadkami użycia — zawieranie, przykład Związki pomiędzy przypadkami użycia — zawieranie, przykład Biblioteka Biblioteka

Klient

Rezerwacja książki <<include>>

<<include>>Wypożyczenie książki

Wyszukanieksiążki

Klient pewnej biblioteki może przeszukiwać jej zasoby katalogowe w poszukiwaniu konkretnej książki.

Klient pewnej biblioteki może rezerwować konkretną książkę przed jej fizycznym wypożyczeniem, co wymaga zwykle jej wyszukania.

Klient pewnej biblioteki może wypożyczyć konkretną książkę, co wymaga zwykle jej wyszukania.




Związki pomiędzy przypadkami użycia — zawieranie, przykład Związki pomiędzy przypadkami użycia — zawieranie, przykład KontoKonto

Klient

<<include>>

<<include>>Wykonanie przelewu

Dodatkoweuwierzytelnienie

Zalogowany klient pewnego systemu bankowości elektronicznej, może wykonywać przelewy i składać zlecenia stałe. Wymaga to jednak zawsze dodatkowego uwierzytelnienia klienta. Przegląd transakcji i sprawdzenie stanu konta wymaga zawsze standardowej autoryzacji klienta.

<<include>>

<<include>>

Standardowa autoryzacja

Sprawdzenie stanu konta

Przeglądnietransakcji

<<include>>

<<include>>Złożenie

zlecenia stałego




Związki pomiędzy przypadkami użycia — rozszerzanie Związki pomiędzy przypadkami użycia — rozszerzanie

Czasem pewien przypadek bazowy opcjonalnie realizuje jakaś czynność opcjonalną. Przypadek bazowy może działać samodzielnie i nie wykonywać funkcji opcjonalnej.

Jednak po dojściu do pewnego punktu rozszerzającego, może zostać uruchomiony przypadek rozszerzający. Po zakończeniu przypadku rozszerzającego, wznawiane jest wykonanie przypadku bazowego.

Rozszerzający przypadek użycia opisany jest stereotypem <<extend>>

Notacja wykorzystująca komentarz z warunkiem rozszerzenia:

Przypadek rozszerzający

Przypadek bazowyExtension points

Opis punktu

<<extend>>

Condition: opis warunkuExtension point: opis punktu




Związki pomiędzy przypadkami użycia — rozszerzanie, przykład Związki pomiędzy przypadkami użycia — rozszerzanie, przykład BibliotekaBiblioteka

Klient

Rezerwacja książki<<include>>

<<include>>

Wyszukanieksiążki

Klient pewnej biblioteki może wypożyczyć konkretną książkę. Jednak na tym etapie sprawdza się, czy nie zalega z opłatą karną za nieterminowe oddawanie książek, jeżeli tak, użytkownik musi opłacić wszystkie zaległości.

<<extend>>

Wypożyczenie książkiExtension points

Opłata karna

Zapłataopłaty karnej




Związki pomiędzy przypadkami użycia — uogólnienie Związki pomiędzy przypadkami użycia — uogólnienie

Czasem pewien można zidentyfikować przypadki określające ten sam rodzaj przetwarzania realizowanego przez system. Przypadki są podobne, lecz nie jednakowe.

W stosunku do przypadków można zastosować związek generalizacja-specjalizacja, i zastosować podejście analogiczne do klas.

Przypadek będący specjalizacją pewnego przypadku uogólnionego, dziedziczy po nim całe zachowanie.

Potomek może dodać nowe elementy do odziedziczonego zachowania lub wręcz całkowicie zmienić odziedziczone zachowanie.

Przypadek ogólnyPrzypadek

specjalizowany




Związki pomiędzy przypadkami użycia — uogólnienie, przykład Związki pomiędzy przypadkami użycia — uogólnienie, przykład BibliotekaBiblioteka

Klient

Rezerwacja książki<<include>>

<<include>>

Wyszukanieksiążki

<<extend>>

Wypożyczenie książkiExtension points

Opłata karna

Zapłataopłaty karnej

Wypożyczenie książkiz odbiorem osobistym

Wypożyczenie książkiz dostawą do domu




Zadanie na ćwiczenia: opracuje SRS i dopracuj diagram dla Zadanie na ćwiczenia: opracuje SRS i dopracuj diagram dla BibliotekaBiblioteka

Bibliotekarz

Rejestracja klientaInni aktorzy . . . Inne przypadki użycia . . .

Do tworzenia diagramów Use Case można wykorzystać darmowy system ArgoUML — dostępne via Internet

Documents

Projektowanie systemów informatycznych Zarządzanie projektemprac.us.edu.pl/~siminski/ip_psi/zpi_w_03.pdf · Projektowanie systemów informatycznych. ... Inżynieria wymaga ... często