Przypadki użycia. Analiza. Model biznesowy. Specyfikacja wymagań. Model dziedziny problemu. Przypadki użycia
|
|
- Marta Zakrzewska
- 7 lat temu
- Przeglądów:
Transkrypt
1
2 2 Analiza Model biznesowy Specyfikacja wymagań Przypadki użycia Model dziedziny problemu
3 3 Przypadek użycia Przypadek użycia to umowa między uczestnikami systemu, określająca sposób zachowania systemu
4 4 Przypadek użycia - przykład Przypadek użycia: Zakup napoju Aktor główny: Klient Scenariusz główny: 1. Klient wrzuca bilon do automatu 2. Klient wybiera rodzaj napoju 3. Automat stwierdza, że wartość bilonu odpowiada cenie wybranego napoju 4. Automat wydaje napój Scenariusze alternatywne: *a. Awaria automatu: *a1. Koniec przypadku użycia 3a. Cena wybranego napoju jest większa niż wartość wrzuconego bilonu: 3a1. Automat prosi o wrzucenie dodatkowego bilonu 3a2. Klient wrzuca dodatkowy bilon 3b. Cena wybranego napoju jest mniejsza niż wartości bilonu: 3b1. Automat zwraca resztę
5 5 Elementy składowe Nazwa Aktor Scenariusz główny Scenariusze alternatywne
6 6 Nazwa przypadku użycia Odzwierciedla zawartość przypadku użycia Zawiera wyrażenie czasownikowe Przykłady: źle: Przypadek użycia 1, Wprowadź dane dobrze: Aktualizuj dane produktu, Utwórz konto
7 7 Scenariusz główny i alternatywny Scenariusz główny - najbardziej prawdopodobna sekwencja kroków ma postać akcji wykonywanych przez aktora oraz odpowiedzi systemu Scenariusze alternatywne - alternatywne sekwencje kroków wykonywane w sytuacjach wyjątkowych
8 8 Jak czytać przypadek użycia? (1) Przypadek użycia rozpoczyna się od wykonania pierwszego kroku scenariusza głównego Kolejne kroki wykonywane są w kolejności określonej przez numerację Przejście do scenariusza alternatywnego następuję w momencie, gdy akcja opisana w scenariuszu głównym nie może być zrealizowana Po wykonywaniu scenariusza alternatywnego następuje powrót do scenariusza głównego do ostatnio wykonywanego kroku (chyba, że w rozszerzeniu podano explicite krok do którego należy przejść) Przypadek użycia kończy się po wykonaniu ostatniego kroku scenariusza głównego lub w momencie napotkania kroku typu Koniec przypadku użycia Scenariusze alternatywne mogą być zagnieżdżane
9 9 Jak czytać przypadek użycia? (2) Przypadek użycia: Zakup napoju Scenariusz główny - kolejność wykonywania kroków zgodna z numeracją Rozszerzenie o charakterze asynchronicznym może pojawić się w dowolnym momencie Rozszerzenie odnosi się do wybranych punktów scenariusza głównego Aktor główny: Klient Scenariusz główny: 1. Klient wrzuca bilon do automatu 2. Klient wybiera rodzaj napoju 3. Automat stwierdza, że wartość bilonu odpowiada cenie wybranego napoju 4. Automat wydaje napój Scenariusze alternatywne: *a. Awaria automatu: *a1. Koniec przypadku użycia 3a. Cena wybranego napoju jest większa niż wartość wrzuconego bilonu: 3a1. Automat prosi o wrzucenie dodatkowego bilonu 3a2. Klient wrzuca dodatkowy bilon 3b. Cena wybranego napoju jest mniejsza niż wartości bilonu: 3b1. Automat zwraca resztę
10 10 Typowe konstrukcje w scenariuszu Prosta sekwencja kroków Kroki warunkowe Konstrukcje typu pętla
11 11 Przykład: prosta sekwencja kroków Przypadek użycia: Pokaż dane produktu Scenariusz główny: 1. Klient prosi system o pokazanie listy dostępnych produktów 2. System wyświetla listę dostępnych produktów 3. Klient wybiera jeden produkt 4. System wyświetla dane produktu
12 12 Przykład: kroki warunkowe Przypadek użycia: Aktualizuj dane produktu Scenariusz główny: 1. Administrator zmienia dane produktu 2. Administrator akceptuje zmiany 3. System zapisuje zmiany Scenariusz alternatywny: 2a. Administrator odrzuca zmiany: 2a1. System anuluje wprowadzone zmiany 2a2. Koniec przypadku użycia
13 13 Przykład: konstrukcja typu pętla Przypadek użycia: Przeglądaj galerię zdjęć Scenariusz główny: 1. Użytkownik wybiera galerię zdjęć 2. System wyświetla wszystkie zdjęcia z wybranej galerii 3. Użytkownik przegląda zdjęcia z wybranej galerii 4. Kroki 1-3 powtarzane są do momentu, aż użytkownik znajdzie pożądaną galerie zdjęć lub określone zdjęcie
14 14 Uczestnik/Udziałowiec Uczestnik/Udziałowiec - ktoś lub coś, co uzyskuje korzyść w związku z realizacją przypadku użycia. Uczestnik nie musi wchodzić w interakcje z systemem, aby osiągnąć swój cel. Przykłady: Właściciel systemu Instytucje nadzorcza Urząd skarbowe
15 15 Aktor główny Aktor główny kontaktuje się i wchodzi w interakcje z systemem, aby zrealizować swój cel. Aktor główny zwykle inicjuje wykonanie przypadku użycia. Aktora nie należy utożsamiać z konkretnymi osobami, aktor to pewna klasa osób, które w systemie odgrywają określone role Przykłady: Sprzedający Kupujący Urzędnik Zegar (powoduje uruchomienie jakiegoś przypadku użycia w określonym czasie lub po upływie określonego czasu
16 16 Aktor pomocniczy Aktor pomocniczy realizuje pewne zadania na żądanie systemu Przykłady: usługa sieciowa dostarczające określone dane, inny system informatyczny, z którym współpracuje nasz system
17 17 Aktorzy i uczestnicy Uczestnik/Udziałowiec uzyskuje korzyść z realizacji przypadku użycia Aktor Aktor główny wchodzi w interakcje z systemem, aby zrealizować swój cel Aktor pomocniczy realizuje pewne zadania na żądanie systemu
18 18 Gdzie szukać aktorów? Kto będzie korzystał z projektowanego systemu? Jakie inne systemy będą współpracować z projektowanym systemem? Kto będzie instalował, uruchamiał, konserwował projektowany system? Kto pobiera/dostarcza informacje systemowi
19 19 Zadanie Problem: Projektujemy system informatyczny dla bankomatu. Ustalić, które elementy z poniższej listy są uczestnikami, aktorami głównymi, aktorami pomocniczymi lub też systemem projektowanym Bankomat Posiadacz karty Karta bankomatowa Bank Klawiatura Akcjonariusz banku Drukarka System informatyczny banku
20 20 Rozwiązanie Bankomat projektowany system Posiadacz karty uczestnik, aktor główny Karta bankomatowa nie jest aktorem ani uczestnikiem, bo karta nie czerpie korzyści z realizacji przypadku użycia Bank nie jest aktorem, jest to otoczenie projektowanego systemu Klawiatura nie jest aktorem, jest komponentem projektowanego systemu Akcjonariusz banku uczestnik systemu Drukarka nie jest aktorem, jest komponentem projektowanego systemu System informatyczny banku aktor pomocniczy
21 21 Cechy przypadku użycia Określa CO system (podsystem, klasa) ma robić, a nie JAK ma to robić Opisuje system z zewnętrznego punktu widzenia - punkt widzenia aktora, a nie systemu Jest kompletny - opisuje wszystkie możliwe scenariusze zachowania systemu w odpowiedzi na żądania jednego z uczestników systemu, zwanego aktorem głównym Scenariusz główny zawiera 3 do 9 kroków Jest łatwy do zrozumienia, również dla osób nie posiadających specjalistycznej wiedzy Zbiór przypadków użycia zawiera wszystkie możliwe sposoby na jakie system może być używany
22 22 Czego nie powinien zawierać p. u. Architektury systemu Elementów związanych z technologią Elementów interfejsu użytkownika Szczegółów realizacji
23 23 Etapy tworzenia przypadków użycia 1. Zidentyfikować aktorów i ich cele (zasada: Szerokość przed głębokością) 2. Utworzyć główne scenariusze 3. Zidentyfikować rozszerzenia 4. Utworzyć scenariusze rozszerzeń
24 24 Lista aktor-cel Aktor Klient Pracownik Administrator Cel Składanie zamówienia Sprawdzanie stanu zamówienia Anulowanie zamówienia Przeglądanie oferty Kompletowanie zamówienia Przygotowanie wysyłki Wystawianie faktury Przyjmowanie zwrotu towaru Zarządzanie użytkownikami Uruchamianie systemu
25 25 Wskazówki (1) Używaj prostych form gramatycznych Niepoprawnie: 1. W tym kroku klient wprowadza kod PIN 2. System stwierdza, że kod PIN jest poprawny Poprawnie: 1. Klient wprowadza kod PIN 2. Kod PIN jest poprawny
26 26 Wskazówki (2) Określ jasno, kto wykonuje dany krok Niepoprawnie: 1. Do systemu wprowadzono identyfikator i hasło Poprawnie: 1. Klient wprowadził identyfikator i hasło
27 27 Wskazówki (3) Stwierdzaj, że, a nie sprawdzaj, czy Niepoprawnie: 1. System sprawdza, czy hasło jest poprawne. 2. Jeśli tak, wówczas system prezentuje użytkownikowi dostępne opcje Poprawnie: 1. System stwierdza, że hasło jest poprawne 2. System prezentuje użytkownikowi dostępne opcje
28 28 Wskazówki (4) Nie używaj synonimów Niepoprawnie: 1. Użytkownik wprowadza dane osobowe. 2. System weryfikuje pozytywnie wprowadzone dane 3. Klient uruchamia usługę Poprawnie: 1. Użytkownik wprowadza dane osobowe. 2. System weryfikuje pozytywnie wprowadzone dane 3. Użytkownik uruchamia usługę
29 29 Wskazówki (6) Nie twórz niepotrzebnych kroków Niepoprawnie: 1. Użytkownik wprowadza imię 2. Użytkownik wprowadza nazwisko 3. Użytkownik wprowadza adres Poprawnie: 1. Użytkownik wprowadza dane osobowe
30 30 Wskazówki (7) Niezależność od technologii i GUI Niepoprawnie: 1. Użytkownik klika na link dane osobowe 2. System wyświetla stronę html z formularzem danych osobowych Poprawnie: 1. Użytkownik wybiera opcję dane osobowe 2. System prezentuje formularz danych osobowych
31 31 Szablon przypadku użycia Identyfikator Nazwa Źródło wymagań Aktor główny Uczestnicy i interesy Zakres (projektowy) Poziom celu Wyzwalacz Warunki początkowe Warunki końcowe Minimalna gwarancja Gwarancja powodzenia Scenariusz główny Scenariusze alternatywne
32 32 Identyfikator i źródło wymagań Identyfikator unikalny oznaczenie dla przypadku, np. UC 2.1, PU Źródło wymagań skąd pochodzi przypadek użycia (np. Specyfikacja wymagań pkt 4.2) lub osoba, która zdefiniowała wymaganie
33 33 Uczestnicy/Udziałowcy i ich interesy Uczestnicy/udziałowcy i ich interesy lista uczestników przypadku użycia oraz tego, co chcą osiągnąć poprzez realizacje przypadku użycia Przykład: Przypadek użycia: Wybierz gotówkę Uczestnicy i interesy: (i) Klient chce wybrać gotówkę (ii) Właściciel bankomatu chce mieć potwierdzenie o wykonanej transakcji
34 34 Zakres Zakres (projektowy) określa, czy przypadek użycia dotyczy całego przedsiębiorstwa, jednostki organizacyjnej, komórki, czy też systemu informatycznego, fragmentu tego systemu Przykład: Przypadek użycia: Złóż zamówienie Zakres: Podsystem zamówienia Przypadek użycia: Organizacja sprzedaży Zakres: Dział sprzedaży
35 35 Poziomy celu Poziom celu - wyróżnia się 3 poziomy celów: poziom streszczenia (biznesowy) poziom celu użytkownika poziom podfunkcji
36 36 Poziom streszczenia (biznesowy) Obejmuje przypadki użycia, których główny cel składa się z wielu celów cząstkowych Stanowią kontekst dla przypadków użycia niższych poziomów Charakteryzują się wieloposiedzeniowością, polegająca na tym, że cel nie jest realizowany w jednym etapie, tj. w trakcie jednego ciągu interakcji z systemem Czas trwania streszczających przypadków użycia jest o wiele dłuższy niż czas trwania przypadków użycia na poziomie celu użytkownika może wynosić od kilku godzin do nawet kilku lat na poziomie streszczenia opisują zazwyczaj pewien proces biznesowy, w którym występuje wielu aktorów
37 37 Poziom streszczenia przykłady (1) Sklep internetowy Przypadek użycia: Sprzedaż towarów Poziom celu: Streszczenie Komentarz: Na przypadek użycia składają się następujące przypadki niższego poziomu: (i) Składanie zamówienia, realizowane przez klienta, (ii) Przygotowanie towarów, realizowane przez dział zamówień i polegające na zebraniu wszystkich zamawianych produktów (iii) Wysyłka produktów, realizowane z kolei przez dział wysyłek we współpracy z firmą kurierską lub pocztą
38 38 Poziom streszczenia przykłady (2) System aukcyjny Przypadek użycia: Zakup przedmiotu na licytacji Poziom celu: Streszczenie Komentarz: Internauta licytuje zazwyczaj wiele razy zanim uda mu się wygrać licytację. Proces ten jest rozłożony w czasie. Każda z takich licytacji stanowi jedno posiedzenie
39 39 Poziom celu użytkownika na tym poziomie opisują sekwencje czynności, po wykonaniu której użytkownik systemu uzyska jakąś korzyść Tego typu przypadki użycia charakteryzują się jednoposiedzeniowością - użytkownik systemu po wykonaniu ciągu interakcji z system osiąga jakąś korzyść, przy czym żaden z pośrednich kroków nie stanowi dla użytkownika wartości samej w sobie Poziom celu użytkownika jest tym poziomem, na którym powinien się skupić analityk, bowiem tego typu przypadki dostarczają najwięcej wartościowych informacji dla projektanta systemu Grupa przypadków na poziomie celu użytkownika jest najliczniejsza w całym projekcie systemu
40 40 Poziom celu użytkownika - Przykład Bankomat Przypadek użycia: Wybierz gotówkę Poziom Celu: Użytkownika Komentarz: Wybierając gotówkę z bankomatu wykonywane są m.in. takie czynności jak: Weryfikacja karty, Weryfikacja PIN-u, itd. Żadna z tych czynności nie jest celem użytkownika - jest jedynie środkiem do realizacji celu głównego, jakim jest wypłata gotówki. Nietrudno zauważyć, że przypadek użycia Wypłać gotówkę spełnia warunek jednego posiedzenia: nie można bowiem włożyć karty, wprowadzić PIN i zgłosić się za kilka dni po odbiór gotówki
41 41 Poziom podfunkcji Obejmuje przypadki użycia, które same w sobie nie stanowią wartości dla użytkownika są jedynie środkiem do uzyskania celu Liczba kroków w tego typu przypadkach jest zazwyczaj nieduża Wyodrębnienie podfunkcji w postaci nowego przypadku użycia zwykle ma na celu uproszczenie przypadku głównego lub wykorzystanie wyodrębnionego zachowania w kilku innych przypadkach użycia
42 42 Poziom podfunkcji - przykłady Loguj się do systemu Wyślij powiadomienie Komentarz: Tego typu operacje nie stanowią wartości samej w sobie. Logujemy się do sytemu, aby np. sprawdzić saldo konta i to stanowi pewną wartość dla użytkownika.
43 43 Poziomy celu - diagram
44 44 Biznesowe a systemowe przypadki użycia Biznesowy przypadek użycia: Zakres - zakresem jest całe przedsiębiorstwo lub jego dział, komórka, etc. Poziom celu - cel przypadku użycia jest realizowany wieloposiedzeniowo Systemowy przypadek użycia: Zakres - zakresem jest system lub jego cześć (podsystem, moduł, etc.) Poziom celu - aktor realizuje swój cel w trakcie jednej sesji
45 45 Warunki początkowe Określają stan systemu w momencie rozpoczęcia przypadku użycia Spełnienie warunków początkowych leży w gestii systemu System nie pozwoli na rozpoczęcie przypadku użycia, jeśli warunek początkowy nie jest spełniony Najczęściej w tej sekcji umieszcza się informację o wykonaniu jakiegoś innego przypadku, od którego zależy możliwość wykonanie danego przypadku użycia Przykład: Warunek początkowy: Użytkownik jest zalogowany
46 46 Warunki końcowe Określają stan systemu po wykonaniu przypadku użycia Istnieją dwa rodzaje warunków końcowych: Minimalna gwarancja Gwarancja powodzenia
47 47 Minimalna gwarancja Stan systemu po ukończeniu przypadku użycia, niezależnie od realizowanego scenariusza Przykłady: Minimalna gwarancja: Dziennik systemowy zawiera wpis o dokonanej transakcji, pozwalający odtworzyć przebieg zdarzeń Minimalna gwarancja: Brak zmian w systemie
48 48 Gwarancja powodzenia Stan systemu po ukończeniu scenariusza głównego W tej sekcji należy opisać w jaki sposób zrealizowano cele wszystkich uczestników Pomocne w tej kwestii może być pytanie: Co sprawi, że uczestnik będzie niezadowolony po ukończeniu głównego scenariusza? Lista zaprzeczeń odpowiedzi na powyższe pytanie stanowi gwarancje powodzenia Przykład: Przypadek użycia: Wypłać gotówkę Gwarancją powodzenia: (i) Bankomat wydał gotówkę w kwocie wnioskowanej przez klienta (ii) Stan konta klienta został pomniejszony o kwotę równą wnioskowanej kwocie
49 49 Wyzwalacz Określa zdarzenie, które powoduje rozpoczęcie przypadku użycia Czasami wyzwalacz poprzedza pierwszy krok przypadku użycia, czasami jest pierwszym krokiem Przykłady: Wyzwalacz: Klient wkłada kartę do bankomatu Wyzwalacz: Recepcjonistka odbiera telefon od klienta w sprawie reklamacji
50 50 Przypadek użycia - przykład Nazwa: Wybierz gotówkę Aktor główny: Klient Uczestnicy i interesy: Klient chce wybrać gotówkę Właściciel bankomatu chce mieć potwierdzenie o wykonanej transakcji Zakres: Bankomat Poziom: Cel użytkownika Warunki początkowe: Bankomat jest sprawny i zawiera gotówkę Minimalna gwarancja: Dziennik systemowy zawiera informacje, pozwalające odtworzyć sekwencje wszystkich działań Gwarancja powodzenia: Bankomat wydał gotówkę w kwocie wnioskowanej przez klienta, Stan konta klienta został pomniejszony o kwotę równą wnioskowanej kwocie Wyzwalacz: Klient wkłada kartę do bankomatu Główny scenariusz: Rozszerzenia:
51 51 Notacja UML podstawowe symbole Symbol Znaczenie <<aktor>> Aktor Nazwa przypadku użycia <<include>> <<extend>> Przypadek użycia Asocjacja zachodzi pomiędzy aktorem a przypadkiem użycia Zawieranie zachodzi pomiędzy przypadkami użycia Rozszerzenie zachodzi pomiędzy przypadkami użycia Generalizacja zachodzi pomiędzy przypadkami użycia lub pomiędzy aktorami
52 52 Generalizacja aktorów Generalizacja - relacja miedzy aktorem ogólniejszym a specjalizowanym Aktor specjalizowany może wykonać wszystkie przypadki użycia aktora ogólniejszego, ale nie odwrotnie
53 53 Generalizacja aktorów - przykład
54 54 Zależności między przypadkami użycia Notacja UML dopuszcza 3 rodzaje zależności między przypadkami użycia: zawieranie rozszerzenie generalizacja/specjalizacja
55 55 Zawieranie Związek zawierania oznacza, że przypadek bazowy wywołuje inny przypadek użycia (zwany przypadkiem zawieranym ) w określonym miejscu Związku zawierania używa się w sytuacji, gdy pewna sekwencja kroków jest wspólna dla kilku przypadków użycia, bądź też wtedy, gdy przypadek użycia jest bardzo złożony W przypadku bazowym i przypadku zawieranym występują ci sami aktorzy Związek zawierania oznacza się stereotypem <<include>>
56 56 Zawieranie - przykład UC1: Złóż zamówienie Poziom: Cel Użytkownika Scenariusz główny: 1. Użytkownik przegląda produkty UC3. Przeglądaj produkty 2. Klient dodaje produkt do koszyka 3. System umieszcza produkt w koszyku i podlicza zawartość koszyka UC3: Przeglądaj produkty Poziom: Cel użytkownika Scenariusz główny: 1. Klient prosi system o pokazanie listy produktów 2. System wyświetla listę produktów 3. Klient wybiera jeden produkt 4. System wyświetla szczegółowe dane o produkcie
57 57 Rozszerzenie Związek rozszerzenia oznacza, że przypadek bazowy może w określonym kroku wywołać inny przypadek, zwany przypadkiem rozszerzającym Związku rozszerzenia używa się do modelowania sytuacji, gdzie istnieje pewien typowy scenariusz oraz dodatkowe czynności, które mają charakter opcjonalny Rozszerzenie zostało pomyślane jako sposób na dodanie nowej funkcjonalności, bez ingerencji w pierwotną treść przypadku użycia W przypadku bazowym i rozszerzeniu występują ci sami aktorzy Związek rozszerzenia oznacza się stereotypem <<extend>>
58 58 Rozszerzenie - przykład UC1: Edytuj dokument Scenariusz główny: 1. Użytkownik wybiera dokument do edycji 2. System otwiera wybrany dokument 3. Użytkownik edytuje wybrany dokument 4. Użytkownik prosi system o zapisanie dokumentu Scenariusze alternatywne: 2a. Dokument nie może być otwarty: 2a1. Punkty rozszerzenia: 3a Opcja sprawdzanie pisowni: UC3. Sprawdź pisownie 3b Opcja synonimy: UC4. Znajdź synonim UC3: Sprawdź pisownię Warunek początkowy: Dokument, dla którego ma być sprawdzana pisownia jest otwarty (UC1 Edytuj dokument) Wyzwalacz: Użytkownik wybrał opcję sprawdzania pisowni Scenariusz główny: 1. System sprawdza pisownie 2. System prezentuje użytkownikowi listę błędów i propozycję poprawy 3. Użytkownik akceptuje propozycje poprawy błędów
59 59 Generalizacja Oznacza sytuacje, kiedy jeden przypadek użycia jest specjalizowaną wersją innego przypadku użycia Przypadek specjalizowany dziedziczy całą sekwencje kroków po przypadku bazowym Kroki odziedziczone po przypadku bazowym mogą być zmieniane, usuwane; można również dodawać nowe kroki W przypadku specjalizowanym mogą występować inni aktorzy niż w przypadku bazowym
60 60 Generalizacja - przykład UC1: Rezerwacja pokoju Scenariusz główny: 1. Rezerwujący przegląda ofertę i wybiera pokój 2. Rezerwujący prosi system o rezerwacje wybranego pokoju 3. System rezerwuje wybrany pokój 4. System wystawia potwierdzenie rezerwacji UC1.1: Rezerwacja przez WWW Scenariusz główny: 1.1. Internauta prosi system o pokazanie listy pokoi 1.2. System wyświetla listę pokoi 1.3. Internauta wybiera pokój 1.4. System pokazuje szczegółowe dane pokoju 2-4 Tak jak w przypadku generalizującym UC1.2: Rezerwacja telefoniczna Scenariusz główny: 1.1. Recepcjonistka odbiera telefon od klienta 1.2. Recepcjonistka prosi system o wyszukanie pokoju spełniającego kryteria klienta 1.3. System wyszykuje pokój spełniający kryteria 2-4 Tak jak w przypadku generalizującym
61 61 Pakiet Forma organizacji przypadków użycia Obejmuje przypadki użycia logicznie powiązane ze sobą, tzn. posiadające tego samego aktora, dotyczące tego samego problemu (biznesowego przypadku użycia), itp.
62 62 Pakiet - przykład
63 63 Instancja przypadku użycia Instancja aktora Przypadek użycia: Zakup napoju Aktor: Klient Przypadek użycia: Zakup napoju Aktor główny: Klient Główny scenariusz: 1. Klient wrzuca bilon do automatu 2. Klient wybiera rodzaj napoju 3. Automat stwierdza, że wartość bilonu odpowiada cenie wybranego napoju 4. Automat wydaje napój Scenariusze alternatywne: *a. Awaria automatu: *a1. Koniec przypadku użycia 3a. Cena wybranego napoju jest większa niż wartość wrzuconego bilonu: 3a1. Automat prosi o wrzucenie dodatkowego bilonu 3a2. Klient wrzuca dodatkowy bilon 3b. Cena wybranego napoju jest mniejsza niż wartości bilonu: 3b1. Automat zwraca resztę Instancja przypadku użycia - konkretny scenariusz Instancja aktora konkretna osoba wykonującą instancję przypadku użycia Scenariusz Jana 1. Jan wrzuca bilon do automatu przy ul. Szewskiej 2. Jan wybiera rodzaj napoju *a. Awaria automatu przy ul. Szewskiej: *a1. Koniec przypadku użycia Scenariusz Anny 1. Anna wrzuca bilon do automatu przy ul. Szewskiej 2. Anna wybiera rodzaj napoju 3. Automat przy ul. Szewskiej stwierdza, że wartość bilonu odpowiada cenie wybranego napoju 4. Automat przy ul. Szewskiej wydaje napój
64 64 Literatura Alistair Cockburn: Jak pisać efektywne przypadki S. Adolph, P. Bramble, A Cockburn, A Pols: Patterns for effective use cases ria_oprogramowania
Diagram przypadków użycia
Diagram przypadków użycia Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje, co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu
Bardziej szczegółowoModelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.
Bardziej szczegółowoModelowanie i analiza systemów informatycznych Spis treści
Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów
Bardziej szczegółowoProjektowanie systemów informatycznych. Diagramy przypadków użycia
Informacje ogólne i przykłady Autor Roman Simiński Kontakt roman.siminski@us.edu.pl www.us.edu.pl/~siminski jako narzędzie modelowania wymagań Nazwa use case diagrams. Cel stosowania Określenie wymagań
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoInżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie
Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków
Bardziej szczegółowoDiagramy przypadków użycia - MS Visio
Diagramy przypadków użycia - MS Visio LABORKA Piotr Ciskowski zad. 1. Sklep internetowy - diagram przypadków użycia (Visio) o przykład z: Wrycza i in., UML 2.x. Ćwiczenia zaawansowane o narzędzie: MS Visio
Bardziej szczegółowoDiagramy przypadków użycia. WYKŁAD Piotr Ciskowski
Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Diagramy przypadków użycia Diagramy przypadków użycia jako narzędzie modelowania wymagań Nazwa diagramu
Bardziej szczegółowoĆwiczenia 3: Specyfikacja wymagań Pytania:
Ćwiczenia 3: Specyfikacja wymagań Pytania: 1. Przygotuj przypadek użycia opisujący obsługę zamówienia w sklepie internetowym (krok po kroku). Zaczynamy od identyfikatora przypadku użycia (powiedzmy UC1),
Bardziej szczegółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Bardziej szczegółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoSPECYFIKACJE WYMAGAŃ PRZYPADKI UŻYCIA (USE CASE)
SPECYFIKACJE WYMAGAŃ PRZYPADKI UŻYCIA (USE CASE) Na podstawie http://wazniak.mimuw.edu.pl/index.php?title=io-2-lab Prof. dr hab. Marek Wisła INTERNETOWA SPRZEDAŻ KSIĄŻEK Księgarnia internetowa Przygotuj
Bardziej szczegółowoAgenda. Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia
Analiza biznesowa Agenda Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia Cele projektu Cechy SMART S Specific Precyzyjne M Measurable Mierzalne A Agreed To Zaakceptowane
Bardziej szczegółowoUML cz. I. UML cz. I 1/1
UML cz. I UML cz. I 1/1 UML cz. I 2/1 UML - Unified Modeling Language ujednolicony można go współdzielić z wieloma pracownikami modelowania służy do opisu projektowanego modelu język posiada opisaną strukturę
Bardziej szczegółowoIO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl
IO - inżynieria oprogramowania dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Metody porządkowania wymagań funkcjonalnych Liczba wymagań funkcjonalnych może być bardzo duża; konieczne jest pewnego rodzaju
Bardziej szczegółowoDiagramy przypadków użycia
Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy
Bardziej szczegółowoInżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia
Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu
Bardziej szczegółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use
Bardziej szczegółowoJerzy Skalski s9473, grupa WIs I.6-11c. System wspierający obsługę klienta dla firm sprzedających na Allegro
Jerzy Skalski s9473, grupa WIs I.6-11c System wspierający obsługę klienta dla firm sprzedających na Allegro 1. WYMAGANIA UŻYTKOWNIKA Użytkownicy systemu: System powinien przechowywać informacje dotyczące:
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 2: Przypadki użycia
Analiza i projektowanie obiektowe 2017/2018 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.
Bardziej szczegółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 9 Strukturyzacja modelu przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements
Bardziej szczegółowoPrzypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady
Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady Po co są przypadki użycia? Gdy projektujemy jakikolwiek system, najważniejszym etapem jest!!!
Bardziej szczegółowoSpecyfikowanie wymagań przypadki użycia
Specyfikowanie wymagań przypadki użycia Prowadzący Dr inż. Zofia 1 La1 La2 Forma zajęć - laboratorium Wprowadzenie do laboratorium. Zasady obowiązujące na zajęciach. Wprowadzenie do narzędzi wykorzystywanych
Bardziej szczegółowoAnaliza procesów: notacja UML, modele przypadków użycia, Rich Picture
45 min Ergonomia pracy umysłowej prof. dr hab. inż. Marcin Sikorski Analiza procesów: notacja UML, modele przypadków użycia, Rich Picture 7 Data wykładu:............. Razem slajdów: 23 Sytuacja problemowa
Bardziej szczegółowoPodstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Bardziej szczegółowoSystem CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski
System CRM dla banku Analiza i projekt Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski Spis treści 1 Cel projektu 3 2 Słownik 4 3 Wymagania funkcjonalne 5 3.1 F.BK Baza klientów.................................
Bardziej szczegółowowww.projektor.org.pl Instrukcja obsługi internetowego systemu wsparcia programu Projektor
www.projektor.org.pl Instrukcja obsługi internetowego systemu wsparcia programu Projektor Spis treści 1. Ekran powitalny, logowanie 2. Rejestracja 3. Utworzenie nowego projektu 4. Zgłoszenie projektu 5.
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoTECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek
TECHNOLOGIE OBIEKTOWE WYKŁAD 2 Anna Mroczek 2 Diagram czynności Czym jest diagram czynności? 3 Diagram czynności (tak jak to definiuje język UML), stanowi graficzną reprezentację przepływu kontroli. 4
Bardziej szczegółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoDiagramy przypadków uŝycia. związków między nimi
Diagramy przypadków uŝycia Graficzne przedstawienie przypadków uŝycia, aktorów oraz związków między nimi Zadania diagramów platforma komunikacji pomiędzy inwestorem a twórcą systemu identyfikacja i dokumentacja
Bardziej szczegółowoŹródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI
DIAGRAMY INTERAKCJI DIAGRAMY STEROWANIA INTERAKCJĄ Diagramy sterowania interakcją dokumentują logiczne związki między fragmentami interakcji. Podstawowe kategorie pojęciowe diagramów sterowania interakcją
Bardziej szczegółowoInstrukcja obsługi: Moduł Reklamacje
Instrukcja obsługi: Moduł Reklamacje Moduł Reklamacje znajdujący się na platformie B2B Ateneum został utworzony w celu usprawnienia procesu wymiany informacji oraz obsługi reklamacji zrealizowanych dostaw
Bardziej szczegółowoLodówka w której przechowujemy produkty zalogowanego użytkownika. Inaczej zwykły użytkownik posiadający konto w systemie.
1. Skróty akronimy i definicje Skrót Spichlerz Klient Definicja Lodówka w której przechowujemy produkty zalogowanego użytkownika. Inaczej zwykły użytkownik posiadający konto w systemie. 2. Cel realizacji
Bardziej szczegółowoProfil pracy wariant konfiguracji programu obejmujący m.in język, walutę, konto allegro, szablon aukcji, zdefiniowane koszty wysyłki itp.
KQS ALLEGRO PRZYGOTOWYWANIE I WYSTAWIANIE AUKCJI Pojęcia użyte w instrukcji: Profil pracy wariant konfiguracji programu obejmujący m.in język, walutę, konto allegro, szablon aukcji, zdefiniowane koszty
Bardziej szczegółowoProjekt aplikacji internetowej specyfikacja wymagań (cz.1)
Cykl życia aplikacji internetowej modelowanej przy pomocy WebML Etapy: 1) Specyfikacja wymagań określenie wymagań funkcjonalnych i niefunkcjonalnych, jakie ma spełniać tworzona aplikacja. 2) Stworzenie
Bardziej szczegółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
Bardziej szczegółowoDIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL
Projektowanie Systemów Komputerowych Laboratoria/Projekty Krzysztof Regulski AGH, WIMiIP DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL 1) Zastosowanie Jedną ze stosowanych metodologii prowadzenia projektów
Bardziej szczegółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
Bardziej szczegółowoVENUS-BEAUTY.pl. Instrukcja obsługi procesu zamówienia
VENUS-BEAUTY.pl Instrukcja obsługi procesu zamówienia 1 Wymagania techniczne Komputer podłączony do sieci internetowej (ze stałym łączem internetowym) System Windows z zainstalowanym oprogramowaniem antywirusowym
Bardziej szczegółowoJęzyk UML definicja i architektura. Modelowanie biznesowe TRZEJ AMIGOS. Co było przed UMLem ROZWÓJ JĘZYKA UML ROZWÓJ JĘZYKA UML
Modelowanie biznesowe Modelowanie w języku UML Język UML definicja i architektura Powiedziałem mu, że najpierw musi przygotować model Czy to Pani Claudia Shiffer? Co było przed UMLem TRZEJ AMIGOS Inicjatywy
Bardziej szczegółowoKancelaria rozpoczęcie pracy z programem
Kancelaria rozpoczęcie pracy z programem Przyciski w programie Kancelaria 2.0 i Kancelaria LT Przyciski dostępne w poszczególnych modułach programu (na dole okien): Przejście do pierwszego Przejście do
Bardziej szczegółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
Bardziej szczegółowoSystem CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski
System CRM dla banku Analiza i projekt Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski Spis treści 1 Wprowadzenie 4 1.1 Cel projektu....................................... 4 1.2 Słownik.........................................
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoNarysować diagram sekwencji pokazujący rejestrację wypożyczenia przez Jana Kowalskiego książki Potop
Egzamin: 31/01/2009 Godzina: 14:15 16:00 Opracowano na podstawie przykładowych zadań MODELOWANIE I ANALIZA SYSTEMÓW OPRACOWANIE ZADAŃ Zadanie 1 Zamodeluj funkcjonalność systemu bibliotecznego Należy: Utworzyć
Bardziej szczegółowoInżynierski Projekt Zespołowy
Inżynierski Projekt Zespołowy Projekt Funkcji Systemu 1. Wymagania funkcjonalne i niefunkcjonalne Prace nad specyfikacją powinny się koncentrowad na funkcjonalnościach, interakcji systemu z użytkownikiem,
Bardziej szczegółowo9 Zakup [ Zakup ] 56. 9. Zakup
9 Zakup [ Zakup ] 56 9. Zakup Moduł zakupu działa na podobnych zasadach, które opisywaliśmy w poprzednim rozdziale: Sprzedaż. Dla uproszczenia zastosowano niemal ten sam interfejs, który tam widzieliśmy,
Bardziej szczegółowoProjekt z przedmiotu Projektowanie systemów teleinformatycznych
Państwowa Wyższa Szkoła Zawodowa w Tarnowie Projekt z przedmiotu Projektowanie systemów teleinformatycznych Temat : Centrum Raportowania Sprzedaży w sieciach telefonii komórkowej Wykonali: Pasula Marcin
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity
Bardziej szczegółowoCel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Bardziej szczegółowoModelowanie obiektowe - Ćw. 5.
1 Modelowanie obiektowe - Ćw. 5. Treść zajęć: Dokumentacja przypadków użycia tworzenie scenariuszy. Diagramy przypadków użycia przedstawiają bardzo ogólny obraz systemu, nie pozwalają jednak na przedstawienie
Bardziej szczegółowoJęzyk UML. dr inż. Piotr Szwed C3, pok
Język UML dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl Przypadki użycia Przypadki użycia: Definicja Przypadek użycia to specyfikacja ciągów akcji i ich wariantów,
Bardziej szczegółowoa. (20 pkt.) Aplikacja powinna zawierać następujące elementy: 2. Formularz edycji profilu użytkownika (2 pkt.).
1. Biblioteka aplikacja internetowa umożliwiająca użytkownikom rezerwowanie i wypożyczanie książek oraz administratorom edycję bazy książek i zarządzanie użytkownikami. a. (20 pkt.) Aplikacja powinna zawierać
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia
Analiza i projektowanie obiektowe 2015/2016 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.
Bardziej szczegółowoBankofon - klient. system obsługi banku Novum Bank Enterprise NOE. Instrukcja Użytkownika wersja dokumentu: 3.0
system obsługi banku Novum Bank Enterprise NOE Bankofon - klient Instrukcja Użytkownika wersja dokumentu: 3. Instrukcja przeznaczona jest dla klienta banku. I. Informacje ogólne Klient, by móc skorzystać
Bardziej szczegółowoINSTRUKCJA UŻYTKOWANIA USŁUGI mobile e-bank EBS
INSTRUKCJA UŻYTKOWANIA USŁUGI mobile e-bank EBS INFORMACJE OGÓLNE Usługa mobile e-bank EBS umożliwia dostęp do usług bankowych poprzez Internet z wykorzystaniem urządzeń mobilnych (tablety, smartfony).
Bardziej szczegółowoDiagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między
Bardziej szczegółowoInstrukcja dla użytkowników serwisu internetowego
Instrukcja dla użytkowników serwisu internetowego 1 2 Spis treści SPIS TREŚCI... 2 I WSTĘP... 3 II OPIS FUNKCJONALNOŚCI... 3 1. LOGOWANIE DO SERWISU INTERNETOWEGO... 3 1.1 Reguły bezpieczeństwa... 3 2.
Bardziej szczegółowoINSTRUKCJA UŻYTKOWNIKA. Zamówienie zestawu z certyfikatem kwalifikowanym i odnowienie certyfikatu. Wersja dokumentacji 1.1 UNIZETO TECHNOLOGIES SA
INSTRUKCJA UŻYTKOWNIKA Zamówienie zestawu z certyfikatem kwalifikowanym i odnowienie certyfikatu Spis treści 1. WSTĘP...3 2. OBSŁUGA ZAMÓWIENIA...4 2.1. WYBÓR SPOSOBU ZAKUPU...4 2.2. WYBÓR OFERTY...5 2.3.
Bardziej szczegółowoModelowanie obiektowe - Ćw. 6.
1 Modelowanie obiektowe - Ćw. 6. Treść zajęć: Dokumentacja przypadków użycia diagramy czynności. Poznane wcześniej diagramy przypadków użycia pokazują co system powinien robić. Natomiast diagramy czynności
Bardziej szczegółowoPodręcznik użytkownika serwisu internetowego www.promoterka.pl. Co to jest promoterka?... 2. Dodawanie wizytówek... 3 Dodawanie kuponów...
Podręcznik użytkownika serwisu internetowego www.promoterka.pl Spis treści Co to jest promoterka?... 2 Jestem właścicielem firmy Dodawanie wizytówek... 3 Dodawanie kuponów... 3 Jestem konsumentem Wyszukiwanie
Bardziej szczegółowoWPROWADZANIE ZLECEŃ POPRZEZ STRONĘ WWW.KACZMARSKI.PL INSTRUKCJA UŻYTKOWNIKA
WPROWADZANIE ZLECEŃ POPRZEZ STRONĘ WWW.KACZMARSKI.PL INSTRUKCJA UŻYTKOWNIKA WSTĘP... 2 1 UWARUNKOWANIA TECHNICZNE... 2 2 UWARUNKOWANIA FORMALNE... 2 3 LOGOWANIE DO SERWISU... 2 4 WIDOK STRONY GŁÓWNEJ...
Bardziej szczegółowoĆwiczenia z IO dotyczące przypadków użycia.
Radek Bartosiak kedar@mimuw.edu.pl Ćwiczenia z IO dotyczące przypadków użycia. Zagadnienia do omówienia na ćwiczeniach 1. Wprowadzenie do przypadków użycia jako sposobu przedstawienia interakcji użytkownika
Bardziej szczegółowoTechnologie Internetowe Raport z wykonanego projektu Temat: Internetowy sklep elektroniczny
Technologie Internetowe Raport z wykonanego projektu Temat: Internetowy sklep elektroniczny AiRIII gr. 2TI sekcja 1 Autorzy: Tomasz Bizon Józef Wawrzyczek 2 1. Wstęp Celem projektu było stworzenie sklepu
Bardziej szczegółowoAplikacja mobilna Nasz Bank
Aplikacja mobilna Nasz Bank Instrukcja Użytkownika BANK SPÓŁDZIELCZY w ZATORZE Aplikacja mobilna Nasz Bank Przewodnik Użytkownika system operacyjny Android 1 Spis treści WSTĘP... 3 Pobranie Aplikacji mobilnej...
Bardziej szczegółowoDiagramy czynności Na podstawie UML 2.0 Tutorial
Diagramy czynności Na podstawie UML 2.0 Tutorial http://sparxsystems.com.au/resources/uml2_tutorial/ Zofia Kruczkiewicz 1 Diagramy czynności 1. Diagramy czyności UML http://sparxsystems.com.au/resources/uml2_tutorial/
Bardziej szczegółowoPlan wykładu 2. Model Przypadków Użycia (PU) systemu Diagram PU Opisy PU Związki w modelu PU, strukturalizacja
Plan wykładu 2 Model Przypadków Użycia (PU) systemu Diagram PU Opisy PU Związki w modelu PU, strukturalizacja 1 Model Przypadków Użycia Reprezentuje użytkowanie systemu. Stosuje sie do systemu biznesowego
Bardziej szczegółowoPodręcznik użytkownika
Podręcznik użytkownika Sklep internetowy ROCKWOOL Spis treści Uruchomienie sklepu... 2 Okno główne... 2 Katalog produktów... 3 Wyszukiwanie produktów... 3 Opis szczegółowy produktu... 4 Dodanie produktu
Bardziej szczegółowoDokumentacja użytkownika aplikacji: KanWebOffer v1.14
Dokumentacja użytkownika aplikacji: KanWebOffer v1.14 Drogi Użytkowniku, Dziękujemy za zainteresowanie programem KANWebOffer! Nasz program służy do łatwego i bezpiecznego przygotowywania ofert handlowych
Bardziej szczegółowoInPost dla PrestaShop. kompatybliny z wersjami: 1.5, 1.6. Instrukcja obsługi
InPost dla PrestaShop kompatybliny z wersjami: 1.5, 1.6 Instrukcja obsługi 1 Spis treści 1. Konto InPost... 2 2. Instalacja wtyczki... 2 2.1 Aktualizacja modułu... 2 3. Konfiguracja... 3 3.1 Informacje
Bardziej szczegółowoINTEGRACJA z OLX. Aplikacja Shoper - Dokumentacja. Lęborska 8/10/ Warszawa.
INTEGRACJA z OLX Aplikacja Shoper - Dokumentacja Lęborska 8/10/45 03-443 Warszawa info@afida.pl www.afida.pl Spis treści Instalacja Aplikacji...1 Uruchomienie aplikacji...1 Opis techniczny...10 Działanie
Bardziej szczegółowoInstrukcja obsługi sklepu internetowego PKL. Opracowane w Dziale Sprzedaży i Marketingu PKL SA autor: Marcin Skuza
Instrukcja obsługi sklepu internetowego PKL Opracowane w Dziale Sprzedaży i Marketingu PKL SA autor: Marcin Skuza Spis treści REJESTRACJA... I) Formularz rejestracyjny... I)1) Uwagi do rejestracji... I)2)
Bardziej szczegółowoInstrukcja obsługi Zaplecza epk dla Pracowników Instytucji w zakresie zarządzania danymi szczegółowymi dotyczącymi sposobu realizacji procedury
Instrukcja obsługi Zaplecza epk dla Pracowników Instytucji w zakresie zarządzania danymi szczegółowymi dotyczącymi sposobu realizacji procedury 1 Spis treści: 1 WSTĘP... 3 2 DOSTĘP DO SYSTEMU... 3 3 INSTYTUCJA
Bardziej szczegółowoInżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia
Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 3 Identyfikacja przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Znajdowanie przypadków użycia
Bardziej szczegółowoSkrócona instrukcja. DriveConfigurator Konfigurator produktu firmy SEW-EURODRIVE
Technika napędowa \ Automatyzacja napędów \ Integracja systemowa \ Usługi Skrócona instrukcja DriveConfigurator Konfigurator produktu firmy SEW-EURODRIVE Wydanie 11/2014 20089333/PL SEW-EURODRIVE Driving
Bardziej szczegółowocstore 3.2 Integracja z serwisem Allegro.pl Instrukcja użytkownika
cstore 3.2 Integracja z serwisem Allegro.pl Instrukcja użytkownika Spis treści 1 Informacje ogólne...3 2 Konfiguracja...4 2.1 Wymagania...4 2.2 Konfiguracja...4 2.3 Szablony aukcji...5 2.4 Szablony kosztów
Bardziej szczegółowoINSTRUKCJA OBSŁUGI SKLEPU INTERNETOWEGO. Alu System Plus Sp.J. ul.leśna 2d 32-500 Chrzanów, tel.(+48-32) 625-71-38 sprzedaz@alusystem.
INSTRUKCJA OBSŁUGI SKLEPU INTERNETOWEGO 1. Jak rozpocząć zakupy? Aby złoŝyć zamówienie w sklepie naleŝy zalogować się, klikając na linka Zaloguj w prawym górnym rogu ekranu. Następnie naleŝy podać nazwę
Bardziej szczegółowoepuap Zakładanie konta organizacji
epuap Zakładanie konta organizacji Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka Jak założyć konto? Proces zakładania
Bardziej szczegółowoNowe funkcjonalności wersji 3.12.0
1. Folder poczekalnia Nowe funkcjonalności wersji 3.12.0 Dostępny jest z poziomu strony głównej w zakładce Foldery 2. Wkładka adresowa Zdefiniowane wkładu 3. Lokalizacja składów chronologicznych Możliwość
Bardziej szczegółowoNowa odsłona sklepu internetowego
Nowa odsłona sklepu internetowego Szybsze zakupy Ulepszony mechanizm wyszukiwania produktu Możliwość powtarzania złożonych wcześniej zamówień Kilka różnych opcji dodawania produktów do koszyka Lepsza prezentacja
Bardziej szczegółowoPrzykładowy Projekt i
Przykładowy Projekt i Autor Dokumentu: Józef Cyrankiewicz Jerzy Urban Właściciele Dokumentu: j.w. Wersja Dokumentu: 0.5 Status Dokumentu: Roboczy Data utworzenia: 27.10.2015 r. Data ostatniej modyfikacji:
Bardziej szczegółowoZalety projektowania obiektowego
Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy
Bardziej szczegółowoEXSO-CORE - specyfikacja
EXSO-CORE - specyfikacja System bazowy dla aplikacji EXSO. Elementy tego systemu występują we wszystkich programach EXSO. Może on ponadto stanowić podstawę do opracowania nowych, dedykowanych systemów.
Bardziej szczegółowoUżytkownik zewnętrzny (UZ) może wykonywać następujące czynności:
Instrukcja obsługi Aplikacji Zarządzania Uprawnieniami (AZU) dla użytkowników zewnętrznych (UZ) w Zintegrowanym Systemie Zarządzania Tożsamością (ZSZT) Użytkownik zewnętrzny (UZ) może wykonywać następujące
Bardziej szczegółowoMobilny handlowiec by CTI. Instrukcja
Mobilny handlowiec by CTI Instrukcja Spis treści 1. Opis programu... 3 2. Logowanie... 4 3. Główne menu... 5 4. Tworzenie zamówienia... 6 4.1. Zamówienie w Comarch ERP XL... 14 5. Lista zamówień... 16
Bardziej szczegółowoBank Spółdzielczy w Suszu Spółdzielcza Grupa Bankowa. Aplikacja mobilna. Nasz Bank. Przewodnik Użytkownika. system operacyjny Android
Bank Spółdzielczy w Suszu Spółdzielcza Grupa Bankowa Aplikacja mobilna Nasz Bank Przewodnik Użytkownika system operacyjny Android https://www.bssusz.pl Spis treści WSTĘP... 3 Pobranie Aplikacji mobilnej...
Bardziej szczegółowoPrzewodnik dla użytkownika. Instrukcja korzystania z aplikacji mobilnej mtoken Asseco MAA
1. Wstęp... 3 2. Wymagania techniczne... 3 3. Instalacja mtoken Asseco MAA na urządzeniu mobilnym... 4 5. Logowanie do aplikacji mtoken Asseco MAA...10 5. Autoryzacja dyspozycji złożonej w systemie bankowości
Bardziej szczegółowoSystem IVR. Opis elementów systemu
System IVR Opis elementów systemu 1. Wstęp Na system IVR (IVR Pack) składają się następujące usługi: IVR Player, IVR Menu, IVR List, IVR Switch. Cennik usług IVR dostępny jest na stronie www.ipfon.pl.
Bardziej szczegółowoTworzenie warstwy zasobów projektowanie metodą strukturalną
Tworzenie warstwy zasobów projektowanie metodą strukturalną Autor Zofia Kruczkiewicz Programowanie i wdrażanie systemów informatycznych 2011-03-27 1 1. Zasady modelowania wymagań funkcjonalnych systemu
Bardziej szczegółowoANEKS NR 1 DO REGULAMINU DROGERII INTERNETOWEJ ROSSMANN ( Aneks )
ANEKS NR 1 DO REGULAMINU DROGERII INTERNETOWEJ ROSSMANN ( Aneks ) 1 POSTANOWIENIA OGÓLNE 1. Jeśli nic innego nie wynika z treści niniejszego Aneksu, do Zamówień składanych w Drogerii Internetowej i dotyczących
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoINSTRUKCJA OBSŁUGI PANELU ADMINISTRACYJNEGO MÓJ DOTPAY v0.1
Dział Pomocy Technicznej Dotpay ul. Wielicka 72 30-552 Kraków Tel. +48 126882600 Faks +48 126882649 E-mail: tech@dotpay.pl INSTRUKCJA OBSŁUGI PANELU ADMINISTRACYJNEGO MÓJ DOTPAY v0.1 Przyjmowanie płatności
Bardziej szczegółowoInstrukcja obsługi Panelu Sklep
Instrukcja obsługi Panelu Sklep Spis treści: Logowanie Lista wniosków Filtr Stan Edycja wniosku Ustawienia sklepu Zmiana hasła Blokada hasła Generator Linków w Panelu Sklep Strona 1 z 22 Logowanie Panel
Bardziej szczegółowoInstrukcja pobrania i instalacji. certyfikatu niekwalifikowanego na komputerze lub karcie kryptograficznej. wersja 1.4 UNIZETO TECHNOLOGIES SA
Instrukcja pobrania i instalacji certyfikatu niekwalifikowanego na komputerze lub karcie kryptograficznej wersja 1.4 Spis treści 1 NIEZBĘDNE ELEMENTY DO WGRANIA CERTYFIKATU NIEKWALIFIKOWANEGO NA KARTĘ
Bardziej szczegółowoInstrukcja pobrania i instalacji certyfikatu niekwalifikowanego na komputerze lub karcie. Instrukcja dla użytkowników. wersja 1.4
Instrukcja pobrania i instalacji certyfikatu niekwalifikowanego na komputerze lub karcie Instrukcja dla użytkowników wersja 1.4 Spis treści 1 NIEZBĘDNE ELEMENTY DO WGRANIA CERTYFIKATU NIEKWALIFIKOWANEGO
Bardziej szczegółowo