Selected Client. Brak 26.05.2018 Testy jednostkowe Wykonano jedynie testy klasy Factory!!!

(1)

Nazwisko Indeks Lab2 Lab3 Lab4 Lab5 Lab6 7 8 9 10 11 13 14 15 229715 P.9 – uwaga pomija fakt, że

tytuły są jedynie rozróżniane za pomocą atrybutów ISBN i aktor.

Dlatego przy wstawianiu ksiązek nie powinno się podawać pozostałych danych.

Brakuje wykonania p. 3 i 4.

W celu zaliczenia lab2 należy wykonać p.3 i 4.

Poprawa 9.03.18 Ocena 4.0

Brakuje pełnej informacji o danych wynikających z definicji wymagania Ocena 4 – można poprawić ocenę Poprawa 5.0

PUZlecenie przelewu w scenariuszu wywołuje 2 przypadki użycia:

PUWyszukiwanie nr konta (jest powiązany na diagramie) i PUZatwierdź przelew (nie jest powiązany na diagramie).

PUWyszukaj nazwę odbiorcy przez relację extend opcjonalnie może wywołać PUZlecenie przelewu- tylko dlaczego?

Również scenariiusz wykłucza taką potrzebę.

PUZablokowanie karty jest powiązane na diagramie za pomocą include z PUWyszukiwanie nr konta i PUWyszukaj nr karty, natomiast w scenariuszu tylko odwołuje się do PUWyszukaj nr karty itd Należy poprawić wg tych wskazówek błędy na diagramie przypadków użycia.

6.04.18

PUZlecenie przelewu nie został poprawiony

Ocena ???

15.04.18

Po poprawie scenariusz PU Zatwierdzanie przelewu jest nieprawidłowy, ponieważ to PU może być wywołane również tylko przez aktora System automatyczny, więc nie można w scenariuszu napisać:

1. System dostaje nr transakcji do zatwierdzenia (od PU Zlecenie przelewu) W opisach PU brakuje wypełnienia formularzy w zakładce Details w następujących PU:

Wyszukiwanie nr konta, Wyszukaj nazwę odbiorcy, Wyszukaj nr karty,

Diagram klas powinien zawierać atrybuty prezentujące powiązania między klasami. Obecnie atrybuty te sa razej ilustracją powiązań.

Podczas zajęc (lab6) wyjaśnie, jak zmodyfikować te powiązania.

Należy koniecznie dodać diagramy sekwencji wynikające z dwóch przypadków użcyia – opisanych w instrukcji do lab5-7. Kod zawiera szkielet kodu – jednak atrybut prezentujące powiązania mięcdzy klasami nalezy poprawić np. P

(http://zofia.kruczkiewicz.s taff.iiar.pwr.wroc.pl/wykla dy/INP002017/Lab_INP00 2017_5_2.pdf )owiązanie między klasą Facade i Client jest 1..*, a w klasie Facade nie zdefinioiwano kolekcji obiektów typu Client.

Ocena???

15.04 18

Nadal na diagramie klas asocjacje nie są powiązane z atrybutami klas (nazwa na ostrzu strzałki powinna reprezentować nazwę atrybutu w klasie, z której strzałka wychodzi, a ustawiona liczność określa, czy jest to kolekcja, czy pojedyncza referencja ) Ocena za diagram klas: ???

15.04.2018 Diagramy sekwencji:

1)Zlecenie_przelewu jest nieprawidłowy, ponieważ z diagramu klas wynika, że obiekty typu Account nie są powązane z klasą Facade, tylko z klasą Client, a na diagramie sekwencji operand [searchAccount(helpR ecipient) != null]

oznacza wywołanie metody

searchAccount należącej do klasy Facade! Diagram nie pokazuje, jak wyszukuje się Account odbiorcy itd 2)Definiowanie_odbio rcy – podobne uwagi.

Dodatkowo, brakuje wyszukania właściwego obiektu typu Client.

Kod: jedynie zdefiniowano szkielet kodu klas. Jest to opóźnienie prac!

Ocena ???

22.04.18

Uwagi o diagramach sekwencji podano przy lab7.

22.04.18

Diagramy sekwencji:

1)Zlecenie_przelew u

W metodzie makeTransfer(sende r : Account, recipient : String[], transferAmount : double) : String Jeden z parametrów jest typem nalezacym do biznesowego modelu danych (Account), co narusza zasadę hermetyzacji.

Klasa typu Facade nie może

wyszukiwać obiektu typu Accout.

Powinno być w metodzie

makeTransfer klasy Facade:

wyszukiwany jest obiekt typu Client jako obiekt dokonujący przelewu oraz drugi obiekt typu Client jako odbiorca.

Wtedy wywołuje się metodę dokonującą transferu od pierwszego znalezionego klienta przekazując znalezionego odbiorcę oraz kwotę do przelania. Ta metoda powinna wyszukać obiekt typu Account w

Brak projektu 6.05.18

19.05.18

Diagramy sekwencji:

makeTransfer Facade makeTransfer Client nie są zgodne z kodem np:

kod:

if ((senderExists = searchClient(helpSender))

!= null)

diagram makeTransfer Façade

Operand w pierwszym fragmencie alt:

searchClient(helpClientS)

!= null

makeTransfer Account odwolue sie do dwóch kolekcji: senderTransfers i recipentTransfers. Na diagramie klas jest tylko jedna kolekcja: -transfers : Transfer = new ArrayList() a w kodzie:

transfers.add(transfer);

(recipient.getTransfers()).a dd(transfer);

Nalezy poprawic podane diagramy sekwencji Diagram klas: ocena???

Diagram aktywności:

Procesy zatrzymują sie w torach Account i Transfer.

Brak zakończenia procesu makeTransfer!!!

Diagram stanów:

Jest niedokładny: brak zdarzeń equals przy przejściu do stanu Selected Client. Brak

26.05.2018 Testy jednostkowe Wykonano jedynie testy klasy Factory!!!

Testy klasy Facade są niedokończone, nie zastosowani żadnej z adnotacji określającej przebieg testów – testy należy dokończyć.

9.06.18 W testach jednostkowych nie powinno używać się wartości zwracanej przez metodę toString! np w testach:

test7AddDefinedRecip ient

test6MakeTransfer w klasie FacadeTest.

Brak zestawu testów oraz zastowania adnotacji

@Parameterized Ocena 4.0

2.06.2018 Testy akceptacyjne – Ocena 5.0

9.06.18 Refaktoryzacja Ocena 5.0 229662

(2)

Zatwierdzanie przelewu typu Insert Use Case...., gdzie należy podać, z jakich PU są wywoływane Bez poprawy ocena 4=

22.04.18 Diagram klas jest poprawny, jednak zostanie oceniony po wykonaniu poprawnych diagramów sekwencji.

kolekcji obiektu typu Client oraz drugi obiekt typu Account od obiektu typu Client (odbiorcy) przekazanego do metody. Wtedy należy wywołać metodę makeTransfer od znalezionego obiektu typu Account należącego do obiektu typu Client, którego metoda jest realizowana, przekiazując mu znależiony obiekt typu Account od drugiego obiektu typu Client. Dopiero w tej metoddzie obiektu typu Account mozna wykonać obiekt typu Transfer.

Do tego celu należy wykonać trzy diagramy sekwencji makeTransfer – w klasach Facade, Client i Account.

Pierwsza z jich wywołuje drugą, a druga trzecią.

Należy wykonać kod tek metody.

wyjścia ze stanów: Defined Recipient added to list oraz add new Account Kod: Ocena 3.5

27.05.18 Diagram stanów:

Ocena 2.0

Diagram klas Ocena 3.0 Diagramy sekwencji Ocena 3.0

Diagramy aktywności Bez zmian

9.06.18

Diagram stanów – niedokładne odwzorowanie kodu metody

addDefinedRecipient klasy Client, ponieważ brakuje diagramów sekwencji modelujących proces addDefinedRecipient Uwaga:

W kodzie metody addDefinedRecipient klasy Client jest błędne porównanie dwóch obiektów typu String x.getName() == name, ponieważ porównuje się®ę ich referencje. Powinno być:

x.getName().equals(name) Ocena – 3.0

Diagram aktywnosci Ocena 5.0

(3)

231350 p.2 – ocena 5 p3.

Kod metody Search_title_book jest niepoprawny – powinien przy wykonaniu wzorcowego tytułu wykorzystać sposób z metody add_book z klasy TFacade. Nastepnie powinien wykorzystać istniejącą metodę search_title_book z klasy TFacade do wyszukania właściwego tytułu (jak w metodzie add book w klasie TFacade). Wtedy należy wywołać return

title_book.getbooks();

Należy zawsze stosować zasadę wieloużywalności kodu.

p.4

Podobnie niepoprawny kod zastosowano do wykonania p. 4!!!

Kod obu metod należy poprawić w celu zaliczenia lab2.

Należy wysyłać projekt z wykonanymi metodami z p.3 i p.4

Poprawa 17.03.18 Metoda remove_book nie usuwa

Ocena 5

Ocena 5 PUDodaj_konto oraz PUUsun_konto rozszerzają ywanescenariusz

PUOperacje_na_kontach, więc powinny go kontynuwać, a nie powtarzać

PIUPrzegladaj_historie_transakc ji jest powiazany przez include z trzema przypadkami użycia:

PUOperacje_na_kontach, PUWyszukaj_przelew, PUWyszukaj_klienta, a w scenariuszu odwołują się tylko do dwóch PUWyszukaj_przelew, PUWyszukaj_klienta

Diagram jest do poprawy.

7.04.18

PUPrzelew_bankowy – niedokładny scenariusz Ocena 5.

Należy koniecznie dodać diagramy sekwencji wynikające z dwóch przypadków użcyia – opisanych w instrukcji do lab5-7

(http://zofia.kruczkiewicz.s taff.iiar.pwr.wroc.pl/wykla dy/INP002017/Lab_INP00 2017_5_2.pdf )

Diagram metody toString() w instrukcji

http://zofia.kruczkiewicz.st aff.iiar.pwr.wroc.pl/wyklad y/INP002017/Lab_INP0020 17_5_1.pdf służył jedynie do nauki tworrzenie diagramu sekwencji. To nie jest projektowanie logiki biznesowej.

Ocena ???

15.04.18 Ocena 5.0

Diagramy sekwencji:

Ocena 5

Kod

Ocena 5, jednak koniecznie należy w metodzie main wywołać metody z przykładowymi danymi

21.04.18

Diagram sekwencji:

4.1 wykonajPrzelew Jest niepoprawny.

Po wykonaniu operacji podanych w bloku opt:

((kontoN = szukajKontaBank(ko ntoNadawca)) !=

null && kontoO = szukajKontaBank(ko ntoOdbiorca)) należy wyłować metodę klasy typu Factory o następującym nagłówku:

stworzPrzelew(kont oN : Konto, kontoO : Konto, kwota : double, data String) : Przelew

podobnie jak w kodzie programu:

public Przelew stworzPrzelew(Kont o kontoN, Konto kontoO, double kwotaPrzelewu, String data) Po poprawie ocena może byc poprawiona na 5.0

5.05.18 Na diagramie klas należy pokazać (ShowAssociations) powiązanie jednokierunkowo z klasą Konto:

kontaBank i ustawić Multiplicity.

Jednak kod dodawanie konta różni się od scenariusza prezentrowanego przez diagramy sekwencji!!!

To musi byc poprawione!

Kod narusza hemetyzację klasy Fasada, ponieważ do metody klasy Klient przekazuje się atrybut: kontaBank- to jest

niedopuszczalne.

Jednak wtedy ta kolekcja Fasady zawiera wszystkie konta – tylko bez podziału na konta:

kontaKlient i kontaBank.

Natomiast na diagramach sekwencji kolekcje kont w klasie Fasada nie są

aktualizowane!!!

Dlatego wykonanie przelewu jest niemożliwe po stronie UML.

19.05.18

Diagram klas Nie zawiera kolekcji przelewy, która znajduje się w kodzie

Kod pokrywa się z diagramami sekwencji – klasa Facade nie używa kolekcji przelewy, mimo ją posiada.

Ocena kodu: 4.0

Ocena diagramów sekwencji: 4.0

Diagramy aktywności 1) wykonajPrzelew- niepotrzebny tor Przelew, a brakuje torów kontoN i kontoO. Obecny tor Przelew wykonuje aktywności, których brakuje w kodzie i na diagramach sekwencji 2) dodajKonto – proces nie zostaje zakończony w torze Klient Ocena???

Diagram stanów 1)Klient

Przejście ma zdarzenie, dozór i akcje zapisane jako zdarzenie.

equals[true] /

getNumerDowodu().equal s(((Klient)

obj).getNumerDowodu()) Należy dozór [true]

zdefiniować w polu Guard, a akcje

getNumerDowodu().equal

3.06.18

Testy jednostkowe 5.0

3.06.18 Testy akceptacyjne Brak testowania przelewu Obecna ocena 3.5 Po wykonaniu tego testu ocena 5.0.

8.06.18 Ocena 5.0

8.06.18 Refaktoryzacja Ocena 5.0 229654

(4)

Niestety, dopiero teraz to widać!!!

Powinno być:

2.2. dodajKonto 2.

Etap – przez return powinnno być zwracane utworzone konto i na diagramie 2.1.

dodajKonto 1. Etap dodane do kolekcji kontaBank.

W kodzie:

Klasa Fasada:

public ArrayList<String>

dodajKonto(String[] data1, String[] data2) { Klient klient, klientHelp;

Fabryka fabryka = new Fabryka();

klientHelp =

fabryka.stworzKlienta(data 1);

if ((klient =

szukajKlienta(klientHelp))

!= null) { Konto konto = klient.dodajKonto(data2);

if (konto!=null) kontaBank.add(konto);

return

klient.pobierzKonta(); } return null;

}

Klasa Klient:

public Konto dodajKonto(String[] data){

Fabryka fabryka = new Fabryka();

Konto noweKonto = fabryka.stworzKonto(data);

if(szukajKonto(noweKonto)

==null){

kontaKlient.add(noweKont o);

noweKonto.setKlient(this);

return noweKonto; } return null;

}

Ten kod należy przedstawić również za pomocą

s(((Klient)

obj).getNumerDowodu()) w polu Effect

Na przejściu ze stanu Selected klient do stanu Create new konto brakuje zdarzenia dodajKonto

2)Przelew Brak podstaw do wykonania takiego diagramu stanów. Z diagramu sekwencji 4.1 wykonajPrzelew można uwazać, że jest to diagram stamów klasy Konto lub Facade???

Diagramy stanów do poprawy!!!

3.06.18

Jedynie diagram stanów klasy Konto jest poprawny Ocena 4.0

Diagram aktywności Diagram aktywności wykonajPrzelew jest niepoprawny. Pozostałe są poprawne,

Ocena 4.0

8.06.18 Diagramy stanów Ocena 5.0

(5)

diagramów sekwencji Diagramy aktywności 1) dodajKlienta- poprawny 2)dodajKonto - tor Konto powinien mieć nazwę Klient.

Ma te same wady, co diagramy sekwencji dodające konto.

3) wykonajPrzelew – tor Przelew wykonuje to, co wykonuje klasa Fabryka na diagramach sekwencji

229639 Ocena 5 ocena 5 Redundancja w wywoływaniu

przypdków użycia np PUDodajLot

rozszerza PUOperacjeNaLotach, który przez include wywołuje PUWyszukajLot, a mimo to PUDodajLot ponownie przez include wywołuje

PUWyszukajLot- czyli 2 razy!

Tylko przy modyfikacji danych lotu ma to uzasadnienie.

PUUsuńLot, – identyczna uwaga.

Należy usunąć redundancję w scenariuszach przypadków użycia i ograniczyć ich ilość np pozostawiając jedynie przypadki dodające dane.

7.04.18

PUKupBilet na diagramire nie jest powiązany z PUUsuwanie rezerwacji, o któtej mowa w scenariuszu

Na diagramie klas klasa Fasada nie jest powiązana z klasą Polaczenie, a na diagramie sekwencji klasa Fasada wstawia obiekt typu Polaczenie do kolekcji polaczenia. Klasa Fasada może jedynie pośredniczyć w takkiej operacji (podobnie jak w przykładach w innstrrukcji http://zofia.kruczkiewicz.st aff.iiar.pwr.wroc.pl/wyklad y/INP002017/Lab_INP0020

Diagramy sekwencji:

1)3.1. Dodawanie nowego lotu dla danego połączenia; 1.

Klasa Polaczenie nie zarządza obiektami typu Maszyna, jednak je wyszukuje w lotach i łączy z nowym obiektem typu Lot nie sprawdzając, czy ta sama maszyna będzie przydzielona do lotu, który ma unikatowy numer, ale może mieć taką samą godzinę.

Również klasa Fasada nie powinna zlecać wykonanie obiektów, z którymi nie jest powiązana.

2)4.1. Rezerwowanie Lotu; 1. Etap.

Podobnie, klasa

21.04.18

Diagramy sekwencji:

Ocena: 5.0 Kod:

1)Należy dodać metodę equals do klasy Rezerwacja (kontrola

integralności danych rezerwacji za pomocą idRezerwacja) 2)Nalezy poprawic kod metody:

jestWolny w klasie Lot w linii:

if

(rezerwacja.getKlas a() == klasaP) Naruszono zasadę hermetyzacji danych. Powinno być: if

5.05.18 Diagram aktywności:

5.0

Kod: 5.5

11.05.18 Diagram stanów Ocena 5.0

26.05.18 Testy jednostkowe Klasy PolaczenieTest, MaszynaTest, FabrykaTest:

Brakuje sprawdzenia integralności danych, Brak przygotowania do przezprowadzenia zestawu testów (brak adnotacji Category), adnotacja Rule nie jest wykorzystana w metodach testowych klasy MaszynaTest, Brak zasosowania w obu klasach adnotacji Parameters i Parameter.

Jedynie testy klasy Facade są sprawdzianerm dzialania programu.

1.06.18 Testy akceptacyjne 1. 1. Brakuje

sprwadzenia więzów integralności danych w testach:

dodajLotnisko, dodajKlienta, dodajMaszyne, dodajPolaczenie 2. Ocena 4.0

7.06.18 Ocena 5.5

1.

7.06.18 Refaktoryzacja Ocena 5.0 229661

(6)

PUZatwierdźRejestracjęKlienta nie może być wywołany z PUZałóżKonto.

Ocena ??? (4.0 – warto poprawić)

15.04.18

PUAutomatyczneUsuwanieReze rwacji nie moży być wywołane!

Należy ten przypadek połączyć z aktorem reprzezentującym program wywołujący.

Po tym uzupełniuniu ocena 5.0 21.04.18

Ocena 5.0

17_5_2.pdf pośredniczy przy dodawanie książek.

Należy koniecznie dodać diagramy sekwencji wynikające z dwóch przypadków użcyia – opisanych w instrukcji do lab5-7

(http://zofia.kruczkiewicz.s taff.iiar.pwr.wroc.pl/wykla dy/INP002017/Lab_INP00 2017_5_2.pdf ) Ocena ???

15.04.18

Diagram klas: ocena 5

Fasada nie powinna zlecać wykonanie obiektów, z którymi nie jest powiązana.

Aby wykonać rezerwację, należy również wyszukać Lot, ponieważ na diagramie klas klasa Rezerwacja jest powiązana z obiektem typu Lot!

3)3.3. Wyszukiwanie obiektu klasy Lot- pomyłkowo jest wyszukiwanny w kolekcji klienci 4)4.3. Wyszukiwanie obiektu klasy Rezerwacja-

pomyłkowo w kolekcji rezerwacje

wyszukiwany jest lot

Kod: Brakuje wywołania

utworzonych metod w metodzie main klasy Fasada.

Ocena???

21.04.18

Diagramy sekwencji:

Ocena 5.0

(rezerwacja.porown ajklasy(klasaP))

Po dodaniu poprawek ocena 5.0

Brak wykonania zestawu testów Ocena 3.0

7.06.18 Ocena 5.0

229678 p2 i p4 – ocena 5 p3.

searchTitleBook Kod metody Search_title_book jest niepoprawny – powinien przy wykonaniu wzorcowego tytułu wykorzystać sposób z metody add_book z klasy TFacade. Nastepnie powinien wykorzystać istniejącą metodę

Ocena 5 Relacja asocjacji między przypadkami użycia jest zbyt ogólna i nie powinna być używanana np PUZgłaszanie awarii i PUOperacje na kontach oraz PUZgłaszanie awarii i PUOperacje na kontach.

PU Miesięczna opłata przez include używa PU Operacje na kontach, natomiast nigdy nie zostanie użyty, ponieważ nie jest powiązny w żadnej relacji z innym PU lub aktorem.

Klasa Film nie może odwołać się do obiektów typu

15.04.18 Ocena ??? (projekt jednego prostego przypadku użycia) Kod tylko jednego przypadku użycia Ocena zostanie wystawiona po wykonaniu projektu i implementacji kolejnych przypadków użycia

22.04.18 Kod:

Naruszana jest zasada hermetyzcji!!!

1)Metoda addFilmFile narusza zasade

hermetyzacji!

public List<Film>

addFilmFile (String[]

data) {

5.05.18

Diagramy sekwencji:

1)subbusinesstier.Fa cade.watchFilm(Stri ng) – jest niepoprawny (w 2- im fragmencie alt wykonane elementy typu Create Message itd) Algorytm powinien być zbliżony do algorytmu

18.05.18

Diagramy sekwencji Niepoprawne diagramy – błędnie użyte

createMessage:

subbusinesstier.Facade.wa tchFilm(String)

subbusinesstier.Facade.sto pWatching(String)

Diagramy aktywności 1) PU_Oglądanie filmu - rozpoczęcie oglądania

4.06.2018 Podano, co należy poprawić w kodzie (modyfikacja n) oraz testach

jednostkowych

4.06.2018 Podano, co należy poprawić w kodzie (modyfikacja n) oraz testach akceptacyjnych

9.06.18 Refaktoryzacja Ocena 5.0 231361

(7)

search_title_book z klasy TFacade do wyszukania właściwego tytułu (jak w metodzie add book w klasie TFacade). Wtedy należy wywołać return

Należy zawsze stosować zasadę wieloużywalności kodu!!!

Kod należy poprawić w celu zaliczenia lab2.

Brak poprawy:

Ocena 4.0

Poprawa 10.03.`18 Ocena 5.0

PUOperacje na filmach jest powiązany jedynie z PU Wyszukiwanie filmu za pomocą relacji include – i tylko taka informacja powinna byc podana w scenariuszu tego PU.

Natomiast przypadki użycia rozszerzajace ten scenariusz powinny zawierać scenariusz rozszerzający ten dziedziczony scenariusz.

Diagram jest do poprawy.

7.04.18 Ocena 5

Ilosc_uzytkownikow_onlin e. Oznacza brak możliwości odwołanie się do obiektów tej klasy.

Diagram sekwencji: dwie strzałki typu LostMessage powinny dodadkowo być typu Reply.

15.04.18

Brak poprawy asocjacji na diagramie klas.

int idTitleFilm = Integer.parseInt(dat a[0]);

TitleFilm titleFilm = allFilms.get(idTitleFil m);

Factory factory=

new Factory();

Film filmFile = factory.createFilmFil e(titleFilm, data);

if

(titleFilm.getFiles()

== null ||

!titleFilm.getFiles().

contains(filmFile)){

allFilms.get(idTitleFi lm).addFile(filmFile)

; return

allFilms.get(idTitleFil m).getFiles();

}

else return null;

}

Druga uwaga:

dlaczego idFilm ma oznaczac pozycje obiektu typu TitleBook w kolekcji allFilms. Uzależnia to niedopuszczalnie GUI od sposobu przechowywania danych!!!

Przy dodawaniu obiektów typu Film należało naśladować dodawanie obiektów typu Book

2) metoda searchTitleFilmByTit le narusza zasadę hermetyzacji w linii

rezerwacji!!!

podany w

materiałach do zajęć lab 5-7.

2)subbusinesstier.Fa cade.watchFilm(Stri ng) – podobne uwagi

Na obecnym etapie nie jest zgodny z kodem modelowanych operacji.

Diagramy aktywności:

1)PU_Oglądanie filmu – w torze Facade nie mozna wyszukiwać FileFile- to może ywkonać tor typu TitleFilm itd 2)Wyświetlenia danego filmu - które diagramy sekwencji modelują ten proces???

Kod:

Podobnie- klasa Facade nie powinna przetwarzać obiektów typu Film (metody: watchFilm, stopWatching).

Kod nie jest zgodny z diagramem klas-na diagranie klas brakuje asocjacji 1...* miedzy klasą Film i klasa View!!! – zdefiniowany w klasie Film za pomocą:

musii być zgodne z diagramami sekwncji, które muszą być poprawione

2)Wyświetlenia danego filmu - - które diagramy sekwencji modelują ten proces??? Takie samo pytanie jest zadane w dniu 5.05.18

Diagram stanów TitleFilm

Przejście ma zdarzenie, dozór i akcje zapisane jako zdarzenie.

equals [true]

/Objects.equals(this.title, other.title) &&

Objects.equals(this.directo r, other.director).

Należy dozór [true]

zdefiniować w polu Guard, a akcje

Objects.equals(this.title, other.title) &&

Objects.equals(this.directo r, other.director) w polu Effect

Brak zdarzeń na wyjściach ze stanu Selected title 1) do stanu addFilm – powinno być zdarzenie addFilm

2)do stanu watchFilm–

powinno być zdarzenie addWatch

3) do stanu

showNumberOfViews-???

4.06.18 (na podstawie 2.06.18)

Diagram stanów – brakuje zdarzenia na przejściu ze

(8)

if(film.getTitle().equ alsIgnoreCase(title))

3) metoda public String

watchFilm(TitleFilm titleFilm, int indexOfFile) narusza zasade hermetyzacji, poniewaz w liscie paramwetrów metody przekazuje typy TitleFilm – GUI nie moze uzywac typów danych z biznesowego modelu danych.

Druga uwaga:

dlaczego indexOfFile ma oznaczac pozycje obiektu typu TitleBook w kolekcji allFilms.

Uzależnia to niedopuszczalnie GUI od sposobu przechowywania danych!!!

4)Czym różni się metoda searchTitleFilm i searchFilmFile.

Konieczna poprawa kodu i diagramów sekwencji w celu zaliczenia lab5-7!

2.06.18

Diagramy sekwencji Po poprawie kodu ocena końcowa 4.0

private List<View>

views;

Kod, mimo naruszenia zasady hermetyzacji w przetwarzaniu powiązanych obiektów – wykonuje pewne czynności, natomiast diagram klas i sekwencji. Z pewnością należy poprawić kod i wyrazić go za pomocą diagramu klas i sekwencji.

2.06.18 Diagramy aktywności Oglądanie filmu - rozpoczęcie oglądania – brak wejścia do aktywności viewsConnected.siz e() <

maxNumberOfClient s – powinna wychodzić z wierzchołka Fork z toru GUI.

Podobnie jest na diagramie Wyświetlenia danego filmu Jedynie diagram Wyświetlenia danego filmu nawiązuje do digramów sekwencjj procrsu watchFilm.

Ocena 3.5

stanu Selected title do stanu stopWatching Ocena 4.0

(9)

Diagram klas Po zmianie nagłówków niektórych metod- ocena końcowa 4.0

229679 p.3 – ocena 5 p.2 – ocena 4 p.4 ???

Ocena 4

Ocena 5 Należy uzupełnić scenariusze (Info) oraz zdefiniować dane w zakładce Details

19.03.18 Do poprawy:

1) PUKup bilet wykonuje nastepujący algorytm: wywoła PUWyszukaj lot, a to PU wywoła pomocniczy przypadek użycia PUWyszukaj Lot oraz pomocniczy przypadek PUWyszukaj Miasto. Następnie PUKup bilet wywołuje drugi raz pomocniczy przypadek PUWyszukaj Lot. Należy to poprawić, bo po wyszukaniu lotu można sprawdzić bilet na ten lot. Takie redundancje pojawiając się, gdy przypadki użycia są powiązane jako sekwencja przypadków użycia.

Pomocnicze przypadki użycia powinny być wywołane z głównych przypadków użycia, które integrują te pomocnicze.

Obecnie należy usunąć relację include między PUSprawdź czy bilet jest dostępny i

PUWyszukaj lot.

Należy uzupełnić scenariusze wszystkich PU powiązanych z PU Kup bilet. i skorygować scenariusze tych PU.

Poprawa 21.03.18 Ocena 5.0

Brakuje diagramów sekwencji wg instrukcji:

http://zofia.kruczkiewicz.st aff.iiar.pwr.wroc.pl/wyklad y/INP002017/Lab_INP0020 17_5_2.pdf

Diagram klas 5.0

15.04.18

Diagramy sekwencji Metody typu Lost Message powinny być typu replay.

1)addFlight: dwa racy przeszukiwany jest plane:w metodzie selfMessage: plane = findPlane(planeID : String) : Plane oraz w operand fragmentu typu alt:

searchPlane(plane)==

null. W kodzie findPlane oznacza jedynie utworzenie obiektu obiektu typu Plane....

W drugim fragmencie operand narusza hermetyzację przetwarzania atrybutów klasy Plane:

departureCity ==

plane.getCity() Możliwe jest dodanie kolejnego lotu, który o tej samej godzinie ma ten sam samolot do różnych miejsc – tak wynika z metody equals klasy Flight.

Ocena???

Kod: podobnie należy zweryfikować tworzenie lotu.

Brakuje wywołania utworzonych metod w

21.04.18

Diagramy sekwencji:

1)addFlight narusza integralnosc referencji do danych!

Bledy:

Jest (plane =

searchCity(departur eCity))==null ||

searchCity(arrivalCit y)==null ||

searchPlane(plane)

== null Powinno byc:

((plane=searchPlan e(plane))==null||((

dcity=searchCity(de partureCity))==null)

||(acity=searchCity(

arrivalCity))==null) Na tym digramie należy wywołać od znalezionego plane metodę

isFree(data:String[]) w celu sprawdzenia, czy plane nie jest przypisany do jakiegoś lotu w tych samych godzinach, podanych w tablicy data2. Należy dodać diagram sekwencji tej metody.

Jeśli jest wolny, mozna

5.05.18 Diagram aktywności: 4.0 Diagramy sekwencji 4.0

Kod: 4.0

7.05.18

Diagram stanów wymaga dopracowania- brak wstawianych akcji przy zdarzeniach equals Ocena ???

26.05.18 Diagram stanów Ocena: 3.0

26.05.18 Testy metod klasy Fasada

- brak testowania integralności danych -brak wykorzystania integracji wyników testów dzięki utworzeniu obiektu typu Facade jako statycznemu atrybutowi klasy testującej np wywołanie kolejno testów:

add_client create_cities create_planes create_flights, gdzie w teście creates_planes nie trzeba wywołać wstawiania miast, a w teście creates_flights również mozna skorzystać z danych wsstawionych w poprzednich testach.

Taka koljenosc może być wyznaczona za pomocą adnotacji

@FixMethodOrder(M ethodSorters.NAME_A SCENDING), a nazwy matod można sztucznie pozmieniać.

Np test

testCanBeAdded w klasie FlightTest jest wykonywany 5 razy,

2.06.18 W kodzie brak generowania wyjątków, dlatego brakuje

testowania ich występowania w testach akceptacyjnnych Ocena 4.0

Refaktoryzacja Ocena 5.0 ???

229686

(10)

metodzie main klasy Fasada.

Ocena??

kontynuować dodawanie lotu.

Metoda createFlight powinna byc wywolana ze znalezionym i wolnym obiektem typu plane oraz obiektami dcity i acity czyli

createFlight(plane:P lane, dcity:City, acity:City, data : String[]) : Flight Oczywiscie, nalezy zmodyfikowac naglowki metod na diagramie klas I dodac nowa metode.

Kod

Nalezy poprawic kod dodawanie lotu wg uwag podanych do diagramu

czyli 5 razy wykonywana jest ta sama pętla. Nalezało w kolejnym teście wynikającym z zastosowanego parametru (od 0 do 4) w metodzie setUp należało pobierać kolejny lot:

@Before public void setUp() { flight=

data.flights[number1];

}

I w metodzie testowej użyć go w jako kolejnym teście.

Należy dodać wtedy adnotację:

@RunWith(Parameter ized.class) do nazwy klasy testującej i testy są wykonywane:

equals testCanBeAdded equals testCanBeAdded equals testCanBeAdded equals testCanBeAdded equals testCanBeAdded Ocena 3=

229646 Należy usunąć wszystkie metody typu

System.out.println z metod klasy TFacade i pozostałych klas realizujących logikę biznesową!

Tylko w metodzie main można wyświetlać wynik działania tych metod.

Wyjątkiem mogą być metody specjalne w klasie

Brakuje powiązań pomiędzy wymaganiami np typu

Dependency lub Derive Ocena 4.5 Poprawa 5.0

PUOperacje_na_rachunku_bank owym jest rozszerzany przez PU Tworzenie_rachunku_bankowe go,

PUUsuwanie_rachunku_banko wego,

PUWnioskuj_o_założenie_rachu nku, natomiast nie podano wspólnej części scenariusza w tym przypadku użycia, który

Diagram sekwencji: dwie strzałki typu LostMessage powinny dodadkowo być typu Reply.

Fragment alt nie powinien mieć podfragmenntów alternatywnych. Wrunek searchClient(Cient) == null, oznacza, zę wszystkie czynności związane ze wstawianiem będą

15.04.18

Diagramy sekwencji 1)subbusinesstier.Faca de.addBankAccount Brakuje połączenia obiektu typu Client z obiektem typu BankAccount.

Brak kodu!

16.04.18

22.04.18

Diagramy sekwencji:

1)

subbusinesstier.Fac ade.addInvestment

W tej metodzie nie moze dodawać bezpośrednio obiekty typu Investment klasa

6.05.18

Diagramy sekwencji i klas – 5.0

Diagram aktywności do poprawy – nie modeluje

prawidłowo procesu prezentowanego przez następujące diagramy sekwencji:

20.05.18

Diagram aktywności Brak w wysłanym projekcie???

Diagram stanów Nazwa \

Nie wiadomo, jakiej klasy jest to diagram!!!

brak zdarzeń equals itd

3.06.18

Testy jednostkowe zostały sprawdzone i wysłano uwagi dotyczące ich poprawy

4.06.2018 Brak testów akceptacyjnych

8.06.18 Ocena : 5.0

9.06.18 Refaktoryzacja Ocena : 5.0 229623

(11)

TFacade, które są metodami tymczasowymi.

p.3 Kod metody Search_title_book jest niepoprawny – powinien przy wykonaniu wzorcowego tytułu wykorzystać sposób z metody add_book z klasy TFacade. Nastepnie powinien wykorzystać istniejącą metodę search_title_book z klasy TFacade do wyszukania właściwego tytułu (jak w metodzie add book w klasie TFacade). Wtedy należy wywołać return

Kod należy poprawić w celu zaliczenia lab2.

p.4 Metoda delete_book jest niepoprawna- wystarczy wywolac metode:

mBooks.remove(newbook);

Kod należy poprawić.

Ocena po dokonaniu zmian.

Poprawa z 5.03.18 Ocena 5

byłby rozszerzany przez pozostałe podane PU.

Brak scenariuszy w zakładce Info oraz informacji w zakładce Details utrudnia ocenę diagramu. Konieczne jest uzupełnienie scenariuszy.

8.04.18

PUUtwórz_przelew – powiązanie trzykrotne z PU Operacje_na_rachunku_banko wym- przez generalizację i include bezśrednio i za pośrednictwem PU Zatwierdzanie transakcji.

15.04.18 Ocena 5

wykonane w bloku alternatywnym czyli searchClient(Cient) != null

Diagram klas:

Obecnie z diagramu wynika, że to klasy BankAccount oraz Client zawierają wiele fasad (Dwukierunkowe relacje 1 do 0..*)

15.04.15 Ocena 5.0

Kod zawiera definicje klas, natomiast brakuje implementacji metod, które są projektowane za pomocą diagramów sekwencji. Realizacja zadań do lab5-7 oznacza wykonanie projektu i

implementacji (kod) 4- ch przypadków użycia- z wykorzystaniem wielu diagramów sekwencji. Przykłady iteracji (od koncepcji, projektu i do napisania kodu, któy jest uruchomiony ) podano w instrukcji do lab5-7:

http://zofia.kruczkiewi cz.staff.iiar.pwr.wroc.

pl/wyklady/INP00201 7/Lab_INP002017_5_2 .pdf

W instrukcji pokazano definicje

najważniejszych metod logiki biznesowej w poszczególnych klasach, wykonanych w trakcje realizacji kolejnych (4-ch) iteracji. Konieczne jest napisanie takiego kodu i uruchomienie go w metodzie main klasy Facade dla przykładowych danych.

Ocena ???

Facade. Z tym typem obiektu jest powiązana klasa typu AccountBank.

Jedyna mozliwością jest dodanie powiązania pomiedzy klasa Facade - Investment jako asocjacja 1...1..*

Druga uwaga:

dlaczego wyszukiwany jest obiekt typu Client na tym diagramie?

2)

subbusinesstier.Fac ade.addTransfer jest niedokończomy???

Te same uwagi dotycza przesłanego kodu.

Należy poprawić diagram klas, podany diagram sekwencji oraz kod (metodę

addInvestment w klasie Facade)

Wysłano Uwagi.pdf w dniu 25.04.18

1)subbusinesstier.Fa cade.addTransactio n,

2)subbusinesstier.e ntities.Client.addTra nsaction(Client, BankAccount, Client, BankAccount, double),

3)subbusinesstier.e ntities.BankAccount.

addTransaction Diagram powinien mieć nastepujące tory: GUI, Facade, Client, BankAccount

Diagram do poprawy

3.06.2018 Diagram stanów Przejścia oznaczone za pomoca

investment.toString() i gettransactions(), które są zdarzeniami na

porzejściach, a powinny być zmienione na akcje za pomocą Open

Specification.../Effect/Crea te Activity. Zdarzeniami dla klasy Client są metody wywołane od niego przez inne obiekty!!!

Po poprawie ocena 5.0

3.06.2018

Diagram aktywności Ocena 5.0

229293 p.2 – ocena 5 p.3

Ocena 5 Scenariusze przypadków użycia PUDodaj_ofertę,

PUModyfikuj_ofertę,

Należy koniecznie dodać diagramy sekwencji wynikające z dwóch

14.04.18

Diagramy sekwencji

18.04.18 Konieczne są konsultacje w celu

6.05.18 Diagram klas – ocena 4.0

12.05.18 Diagram stanów

27.05.18

Testy jednostkowe

3.06.18 Testy akceptacyjne

9.06.18 Refaktoryzacja Ocena 5.0 229711

(12)

Kod metody

Search_title_book2 jest niepoprawny – powinien przy wykonaniu wzorcowego tytułu wykorzystać sposób z metody add_book z klasy TFacade. Nastepnie powinien wykorzystać istniejącą metodę search_title_book z klasy TFacade do wyszukania właściwego tytułu (jak w metodzie add book w klasie TFacade). Wtedy należy wywołać return

Poprawa 8.03.18 1)W klasie TTitle_Book metoda remove_book dwa razy przeszukuje kolekcję books:search_book oraz remove(newbook):

public boolean remove(Object o) { if (o == null) {

for (int index = 0; index <

size; index++) if (elementData[index] ==

null) { fastRemove(index);

return true; } } else {

for (int index = 0; index <

size; index++) if

(o.equals(elementData[ind

PUUsuń_ofertę rozszerzają scneariusz

PUOperacje_na_ofertach, więć nie powinny powtarzać tego scenariusza tylko, go rozszerzyć np PUModyfikuj_ofertę w swoim scenariuszu powinien po modyfikacji ponownie wywołać PUWyszukaj_ofertę, a pierwsze szukanie jest wykonane w rozszerzanym scenariuszu. Taki przkład jest w instrukcji do lab3!

W przypadkach użycia rozszerzających PUOperacje_na_ofertach powinna być wzmianka o tym rozszeniu w kroku badająym wynik tego rozszerzanego scenariusza.

Diagram należy poprawić.

6.04.18

Ocena poprawy 4.0

przypadków użcyia – opisanych w instrukcji do lab5-7

(http://zofia.kruczkiewicz.s taff.iiar.pwr.wroc.pl/wykla dy/INP002017/Lab_INP00 2017_5_2.pdf )

Diagram metody toString() w instrukcji

http://zofia.kruczkiewicz.st aff.iiar.pwr.wroc.pl/wyklad y/INP002017/Lab_INP0020 17_5_1.pdf służył jedynie do nauki tworrzenie diagramu sekwencji. To nie jest projektowanie logiki biznesowej.

Między klasą Fasada i klasami Rezerwacja oraz Klient powinny być powiązania jednokierunkowe.

14.04.18 Klasa Klient nie ma dostępu do rezerwacji Atrybuty klas bez zmian

18.04.18

Konieczne są konsultacje w celu wyjaśnienia wielu sprzeczności w projekcie!

1)strzałki typu LostMessge powinny być typu reply.

Kod Metody:

public List<Oferta>

searrchOferta(String[]

dane,int rodzajDanej) oraz

public List<Oferta>

searrchOferta(String[]

dane,Date data,int rodzajDanej) naruszają rażąco hermetyzację danych, ponieważ klasa Fasada przetwarza atrybuty klasy Oferta.

Podobnie jest z metodami public Klient searchKlient(String email)

oraz

public List<Klient>

searchKlient2(String nazwisko) Ocena???

18.04.18 Konieczne są konsultacje w celu wyjaśnienia wielu sprzeczności w projekcie!

wyjaśnienia wielu sprzeczności w projekcie!

Diagramy sekwencji – ocena 4.0 Diagram aktywności-ocena 5.0

Kod: 4.0 (Nie sprawdza się, czy oferta jest wolna)

Niepoprawny fragment diagramu:

Po wyjściu ze stanu type of comparing wierzchołek decyzyjny ma dwa wyjścia alternatywne, czy osiąga stan kierunek i data lub stan kierunek, lotnisko i data. Oznacza to stany typu Join nie mogą być poprawne, ponieważ można z nich wyjść, gdy oba wejscia są gotowe – a one są alternatywne!!!

Diagram należy poprawić

27.05.18 Diagram stanów Zdarzeniie

compare(String[] dane, Date data) nie istnieje jako metoda wywołana od oferty przez inny obiekt.

Ocena 3.5

9.06.18 Diagram stanów Ocena 5.0

1)Nie wykorzystano wykonanej adnotacji Rule do testowania wystąpień wyjątków we wszystkich klasach testujących???

2)Brak zestawu testów i brak przygotowania klas testujących – brak adnotacji Category) 3)W testowaniu metod klasy Fasada brak integrowania wyników testów (jak to jest wykonywane podczas testów akceptacyjnych za pomocą instrukcji include) np test testSearchKlient_Klien t powinien bazować na wynikach testu testAddKlient() Np

addKlient addOferta searchKlient searchKlient searchKlient searchOferta searchOferta searchOferta searchOferta rezerwuj searchRezerwacja anulowanieRezerwacji deleteOferta 4) Brak zastosowania

@Parameterized.Para meters

Ocena obecna 3.0

9.06.18 Ocena 5.0

Ocena 5.5

(13)

ex])) { fastRemove(index) return true; } } return false;

}

Oznacza to, że wystarczyło wywołać tylko metodę mBooks.remove(newbook);

2)Search_title_book Błędna koncepcja wyszukiwania obiektw porównując wyniki ich metody toString Ocena poprawy 4.0 229675 Należye usunąć wszystkie

metody typu

System.out.println z metod klasy TFacade i pozostałych klas realizujących logikę biznesową!

Tylko w metodzie main można wyświetlać wynik działania tych metod.

Wyjątkiem mogą być metody specjalne w klasie TFacade, które są metodami tymczasowymi.

p.3 Kod metody Search_title_book jest niepoprawny – powinien przy wykonaniu wzorcowego tytułu wykorzystać sposób z metody add_book z klasy TFacade. Nastepnie powinien wykorzystać istniejącą metodę search_title_book z klasy TFacade do wyszukania właściwego tytułu (jak w metodzie add book w klasie TFacade). Wtedy należy wywołać return

Należy uzupełnić opis danych, do których odwołują sie wymagania zdefiniowane na diagramach Wymagania funkcjonalne – pracownik oraz Wymagania funkcjonalne – klient.

Poprawa 5.0

PUoperacje na egzemplarzach na diagramie zawiera odwołanie rekurencyjne tzn powinno wywołać PUdodanie nowej pozycji, a PUdodanie nowej pozycji wywołuje

PUwyszukiwanie pozycji, które z kolei wywołuje PUoperacje na egzemplarzach. Należy to koniecznie poprawić, unikając takich łańcuchów powiązanych przypadków użycia.

Purezerwacja dwukrotnie wywołuje PUprzeszukiwane bazy klientów oraz PUwyszukaj rezerwację – pierwszy raz bezpośrednio i drugi raz po wywołaniu Puwypożyczenie, który wywoła PUanulowanie rezerwacji, a to PU wywoła ponownie podane wcześniej przypadku użycia. Nalezy zastosować relacje use np między PUanulowanie rezerwacji i PUprzeszukiwane bazy klientów oraz PUwyszukaj rezerwację.

Diagram należy poprawić.

6.04.18

PUwypożyczenie dwukrotnie wywołuje PUprzeszukiwane bazy klientów i PUwyszukaj

Brakuje diagramów sekwencji wg instrukcji:

http://zofia.kruczkiewicz.st aff.iiar.pwr.wroc.pl/wyklad y/INP002017/Lab_INP0020 17_5_2.pdf

14.04.18 Ocena 4.5

14.04.18

Diagramy sekwencji:

obiektów typu Egzemplarz, bo nie st z niemi powiązana.

6 diagramów sekwencji jest pustych na 10!

Kod

Wykonano projekt i implementację 1-go przypadku użycia Ocena???

22.04.18

Diagramy sekwencji:

1)addEgzemplarz in Pozycja Sequence Diagram2 – w tym diagramie brakuje fragment alt lub opt.

2)addRezerwacja Sequence Diagram Warunek we fragmencie alt Narusza zasadé hermetyzacji danych klient != null &&

!klient.getRezerwac je.containsKey(num er)

Podobnie, wywolania metod na tym diagramie:

addRezerwacja(num er: int, egzemplarz:

pozycja.getEgzempl arze().get(indx), date:LocalDate = date) : void oraz

getEgzemplarze().g et(indx).addRezerw acja(numer : int,

6.05.18

Diagramy sekwencji:

3.5 Kod: 4.0 Diagramy aktywności: kopia z przykładów 3.5 Warto dodać diagram usuwania rezerwacji

2.06.18 Diagramy aktywnoci 4.0

20.05.18

Diagramy aktywności removeRezerwacja – w torze Fasada nie mozna wyszukiwać rezerwacji, gdyć Fasada nie jest ppowiązana z rezerwacją.

Rezerwację może usuwać Klient lub Egzemplarz!.

Diagram do poprawy.

Diagram sekwencji removeRezerwacja in Facade pokazuje algorytm usuwania naruszający zasadę hermetyzacji – to wyszukany obiekt typu Klient może usuwać rezerwację. Obecnie klasa Fasada pobiera metodą get kolekcję do usunięcia jednej z rezerwacji Diagram nalezy poprawić.

2.06.18 Diagram stanów Ocena 4.0

2.06.18

Testy jednostkowe 3.0

1)Brakuje

wykorzyustanie użytej adnotacj @Rule 2)Brak zastosowania adnotacji

@Parameterized.Para meters

Ocena 3.5

2.06.2018 Testy akceptacyjne Ocena 5.0

10.06.18 Refaktoryzacja 5.0 184928

(14)

p.4 Metoda delete_book jest niepoprawna- wystarczy wywolac metode:

mBooks.remove(newbook);

Kod należy poprawić.

Ocena po dokonaniu zmian.

Poprawa 16.03.18 Ocena 4.5

rezerwację- bezpośrednio i za pomocą PUanulowanie rezerwacji.

Purezerwacja-scenariusz nie odwołuje się do PU przeszukiwane bazy klientów Ocena 3.5

klient : Klient, date : LocalDate) : void

Konieczna poprawa tego diagramu oraz kodu program!!!