Nazwisko Indeks Lab2 Lab3 Lab4 Lab5 Lab6 Lab7 lab8 lab9 lab10 lab11 Lab12 13 14 229704
229615
p.2. ocena 5 p3 ocena 5 p4 ocena 5 Ocena: 5
Na diagramie Opis świata brakuje opisu danych technicznych.
Diagram wymagań:
1) brakuje wymagań niefunkcjonalnych 2) wymagania nie mają zdefinniowanych parameterów typu: kind, risk, status itp
W wymaganiach funkcjonalnych nie podano, jakie dane reprezentują pokój do rezerwacji.
Ocena po uzupełniu opisu i wymagań niefunkcjonalnych
Ocena po poprawie: 4.5 (oprócz kompozycji brakuje innych relacji między wymaganiami funkcjonalnymi)
W scenariuszach przypadków użycia:
PUPrzeglądaj pokoje, PUZarezerwuj pokój, PUAnuluj rezerwacje brakuje odwołań do powiązanych przypadków użycia przez relację include, czyli PUWyszukaj pokój, PUDodaj rezerwacje, PUWyszukaj rezerwacje, PUUsuń rezerwacje
Np scenariusz PUAnuluj rezerwacje powinien odwołać się do PUWyszukaj rezerwacje, PUUsuń rezerwacje.
Obecne scenariusze nie podają w p.1 danych wejściowych. Scenaiusz powinien zawierać algorytm wykonania operacji w szczegółach.
Błędy należy usunąć.
Poprawa 25.03.18 Ze scenariusza PU Zarezerwuj pokój brakuje wywołania
PUWyszukaj_goscia W celu powiązania danych pokoju z danymi goscia Ocena: 3.5 (ocenę można poprawić)
Poprawa 8.04.18 Ocena 4.0
Brak działającego kodu, diagramów sekwencji oraz powiązań na diagrami klas wg instrukcji:
Instrukcja - część 2
dla 1-go przypadku użycia (1-a iteracja) Z diagramu klas wynika, że rezerwacje będą powiązane z obiektem typu Gosc. Natomiast na diagramie przypadków użycia brakuje przypadku użycia, który umozliwia takie powiazanie z klientem tzn brak np
PUWyszukaj_gosc ia
Ocena???
16.04.18 Poprawa diagramu przypadków użycia Ocena 4.5
Diagram klas – klasa Facade powinna być klasą opatą na wzorcu Fasada. Oznacza to, że w nagłówkach metod tej klasy powinny być tzw obiekty transferowe (np tablice łańcuchów, a nie obiekty z modelu danych, np typu Client, Room itp).
Brakuje powiązania klas Client i Room z klasą Facade.
Diagramy sekwencji:
1) addClient: w liście parametrów operacji typu FoundMessage jest typ Client, a na diagramie tworzona jest linia życia Factory i tworzony jest obiekt typu Client na podstawie danych params.
Bardzo dużo błędów zawiera diagram createResrvation.
Kod: nie jest powiązany z diagramami sekwencji!
Błędy kodu:
Użycie metody contains kolekcji dla elementów, które nie mają poprawnej metody equals (dziedziczona od Object porównuje referencje!!!) itd
16.04.18 Diagram klas Nadal brakuje powiązań między klasą Facade i klasami: User i Room.
Diagramy sekwencji Utworzono trzy diagramy sekwencji jako diagramy dla trzech iteracji (realizacja trzech przypadków użycia).
Z instrukcji do lab 5- 7: Instrukcja - część 2
wynika, że do każdej iteracji należąło wykonać kilka diagramów, wynikających z potrzeb realizacji funkcji programu.
Obecnie wykoannie rezerwacji wyjątkowo wymaga pokazanie na kolejnym digramie sekwencji, jak jest zdefiniowany proces isFreeBetween(date From : LocalDate, dateTo : LocalDate) : boolean, w którym obiekt typu Room przewglada swoje rezerwacje i sprawdza, czy jest wolny w wyznaczonym terminie.
23.04.18 Diagram aktywności Aktywność Is free between jest nieprawidłowo połączona z obiektami typu Date.
10.06.18 Kod: 3.5 Np metooda equals w klasie Room if (this.category
!=
other.category) { return false; } porównuje referencje dwóch obiektów typu RoomCategory, a nie ich wartości
7.05.18
Brak spójności między diagramami oraz diagramami i kodem!!!
Diagram aktywności Brak poprawy. Nie podano, w którym torze rezerwacja jest dodana (Factory???).
Ten diagram tylko częściowo nawiązuje do diagramu sekwencji addReservation Ocena 3.0
Diagramy sekwencji- ocena: 2.0 (brak poprawy. Diagram sekwencji addReservation, określa, że to klasa Facade przechowuje rezerwacje (dodanie rezerwacji do kolekcji należącej do tej klasy), a z diagramu klas wynika, że to klasy Room i Client są jedynie powiązane z obiektami klasy Reservation. Niestety, na tym diagramie sekwencji brakuje pokazania dodawania rezerwacji do tych dwóch typów obiektów, natomiast pokazano dodawanie do klasy Facade!!!
15.05.18 Brak projektu 2.06.18
Testy jednostkowe 1) Adnotacja Rule zdefiniowana, ale nie zastosowana do testowania przypadku wystapienia wyjątku w klasach: FacadeTest, FactoryTest, 2) Nie zastosowamo adnotacji
@Parameterized.Paramete rs
Ocena 3- 10.0618
Testy jednostkowe 1)klasa FacasadTest addClient addreservation addRoom cancelreservation testy są realizowane w złej kolejności. Powinno być:
addClient addRoom addreservation cancelreservation 2) ReservationTest – w tej klasie 3 razy powtarza się te same testy na takich samych danych – parametr number jest używany tylko w metidzie equals Ocena 3
21.05.18 Brak projektu
27.05.2018 Testy akceptacyj ne:
Test_addRe servation i Test_cancel Reservation są pomyłką – przecież w klaswi Facade nie ma metody do rezerwacji oraz do anulowania rezerwacji.
Dwa testy są jedynie do oceny Ocena 3-
10.06.18 Brakuje stron wiki tetów akceptacyj nych.
27.05.19 Brak wykonan ia dokumen tacji zgodnie z instrukcj ą!!Ocena
???
10.06.18 Opis identyfik acji klas;
Ocena 2.0
2.06.18 Brak refaktoryzacji 10.06.18
Wykonano refaktoryzację częściowo – pozostawiono metody toString, zwracane przez return.
Ocena 4.0
10.06.18 Wykonano refaktoryzację Ocena 4.0
Konieczne są konsultacje.
23.04.18 Diagram klas Powiązania między klasą Facade i klasami:
User i Room powinny być typu asocjacja, a nie dependency
Równiez należy pokazać, w jaki sposób powstaje rezerwacja powiązana w dwukierunkowej relacji Client – Reservation o liczności 1..* oraz Room-Reservation o liczności 1..*.
Kod wykonano jedynie dla dodawanie obiektów typu Client i Room, a brakuje dla oboiektów typu Reservation.
Oznacza to brak wykonania niezbędnych elementów projektu Obecna ocena za lab5-7: 3.0 ???
23.04.18
Diagramy sekwencji 1)addReservation (Facade): Lost Message powinny byc typu Reply.
2)isFreeBetween Wiadomosci nie sa typu call Message.
Metoda isOcupied nie jest typu Call
Kod należy wysłać, jeśli został zmodyfikowany
Diagram klas: ocena : 3.5 (brak poprawy, brak korzystania z niektórych klas na diagramach sekwencji oraz powiązań)
Diagram stanu:
Nie podano, jaka klasę reprezentuje ten diagram. Dopiero wtedy ocenię ten diagram.
Kod jest niekompletny i nie jest powiązany z diagramami sekwencji. Brak wieloużywalności kodu: np obiektu Client są wyszukiwane za pomocą equals na kilka sposobów:
1)contains – metodą klasy ArrayList (opartá na indexOf)
2)for (Client fClient : clients) {
if
(fClient.equals(tempCl ient)) {
return fClient;
} },
co można zastąpić metodą indexOf i ułatwi testowanie Powinna byc jedna metoda użyta trzykrotnie: przy dodawaniu, wyszukiwaniu i rezerwacji.
Ocena kodu możliwa po „uspójnieniu” kodu i diagramów sekwencji
– obecnie kod nie jest zaliczony!!!
27.05.18
Diagramy sekwencji bez zmian
Ocena 2.0
Diagram stanów Zdarzenie
addRoom(params) dla klasy typu Room – jak pokój może siebie dodać
Ocena 2.0
Diagram aktywności Dodanie rezerwacji w torze Facade jest tylko na tym diagramie, natomiast nie ma takiego digramy sekwencji oraz nie istnieje metoda dodająca rezerwację w klasie Facade Ocena 3.0
10.06.18 Diagram stanów Nadal ocena 2.0
229636 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ę 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.getbook s();
Należy zawsze stosować zasadę wieloużywalności kodu oraz hermetyzacji danych!!!
Kod należy poprawić w celu zaliczenia lab2.
Poprawa 17.03.18 Ten fragment metody pokazuje dwukrotne wyszukiwanie tytulu
Opis „świata rzeczywistego” z pliku Laboratorium3_229636_
229630.docx należy przenieść do projektu VP laboratorium3_229636_
229630.vpp
(biuro_informacji_turust ycznej) do diagramu
„Opis świata rzeczywsitego”, ponieważ jest dokładnieszy!
Diagram
Wymagania_fumkcjonal ne jest niekompletny! – zawiera jedynie wymagania niefukcjonalne.
W celu zaliczenia lab3 należy poprawić i uzupełnić projekt.
Poprawa: 4.5
PUUsuń pozycję i PUEdytuj pozycje dziedziczą, czyli rozszerzają
PUOperacje_na_pozycjach . Na diagramie PUDodaj pozycje nie rozszerza PUOperacje_na_pozycjach , natomiast w scenariuszu PUDodaj pozycje jest b to zaznaczone.
Wtedy scenariusz PUOperacje_na_pozycjach powinien jedynie wywołać przypadki uzycia i jesli kończy scenariusz, to powoduje zakończenie scenariuszy dziedziczących po tym PU. Jednak teraz scenariusze tych przypadków użycia sa niespójne. Np
PUWyszukaj_po_nazwie w scenatriuszu odwołuje sie do PUWyszukaj_po_dacie, a na diagramie te przypadki użycia nie są powiązane. Wtedy scenariusz
PUOperacje_na_pozycjach jest sprzeczy z tym scenariuszem itd.
Relacja extend między PUWyszukaj_po_dacie i PUOperacje_na_pozycjach powoduje, że
PUWyszukaj_po_dacie opcjopnalnie wywołuje PUOperacje_na_pozycjach , a w scenariuszu PUWyszukaj_po_dacie nie ma odwołania do tego PU.
Należy to uporządkować w celu zaliczenia diagramu.
9.04.18
W scenariuszach należy podać algorytm działania
26.03.18 Brak lab5 9.04.18 Diagram klas i sekwencji są niekompletne
Diagram klas i sekwencji są niekompletne
16.04.18 Brak projektu
23.04.14 Wykonano poprawnie jedną iterację w projekcie UML.
Brakuje kodu oraz pozostałych trzech iteracji
7.05.18 Diagram klas:
Poprawiony, ocena 3.5 (opóźnienie)
Diagramy sekwencji Brakuje diagramu sekwencji doddawanie wydarzenia i rezerwacji Ocena:???
Diagramy aktywności 1)
dodajWydarzenie(Stri ng []) – brak odpowiadających diagramów sekwencji.
Tor wydearzennie powinien mieć nazwę Miejscowosc 2)
dodajRezerwacjeWyci eczki(String arg[], LocalDate data) – błąd syntaktyki i sematyki w torze Wydarzenie dotyczący bloku decyzyjnego Diagram stanów brak
Diagram przypadków użycia: Ocena 3.5
Kod: metoda main w klasie Fasada jest pusta. Kod metod poszczególnych klas jest niekompletny.
Ocena:???
4.06.18
Diagram aktywności:
4.0
13.05.18 Brak testów jednostkowych
Kod Kod metody
dodajRezerwacje w klasie Miejscowosc jest całkowicie błędny i różni się od scenariusza pokazanego na diagramie sekwencji
dodajRezerwacje_Miejsco wosc!!!:
public String dodajRezerwacje (LocalDate data){
Miejscowosc
szukMiejscowosc = new Miejscowosc();
if(szukMiejscowosc.szukaj WolnegoWydarzenia(data )){ Wydarzenie wydarzenie = new Wydarzenie();
wydarzenie.dodajRezerwa cje(data);
return "wykonano rezerwacje"; } else
return "brak wolnego wydarzenia"; }
Obiekt szukMiejscowosc nie posiada żadnych wydarzeń, ponieważ jest utworzony przez new!!!
oraz obiekt wydarzenie nie ma żadnych rezerwacji, ponieważ jest tworzony przez new.
Powinno być:
21.05.18 Brak projektu Brak testów akceptacyj nych
11.06.18 Testy jednostko we Błędy np w klasie Miejscowo scTest- testowanie nieistniejąc erj metody testSzukaj Wydarzenia () Ocena ???
Testy akceptacyj ne – brskuje stron wiki!!
Ocena???
4.06.18 W przypadk u opisu klas Fasada i Fabryka należy podkreśli c związake ich z odpowie dnimi wzorcami obiektow ymi Ocena:
4.0
4.06.18 Brak refaktoryzacji kodu wg instrukcji do lab13.
11.06.18 Refaktoryzacja 1 Ocena 4.0
11.06.18 Refaktoryzacja 2 Ocena 4.0
TTitle_book searching=search_
title_book(title_bo ok); //1 raz if (searching
!= null) { return (search_title_book (title_book).getbo oks());//2-I raz Powinno byc:
TTitle_book searching=search_
title_book(title_bo ok); //1 raz if (searching
!= null) { return searching..getboo ks();
Ocena 4.0-
przypadku użycia, podobnie jak w przykładach w instrukcji:
http://zofia.kruczkiewicz.st aff.iiar.pwr.wroc.pl/wyklad y/INP002017/Lab_INP0020 17_4.pdf
public String dodajRezerwacje (LocalDate data){
if(szukajWolnegoWydarze nia(data)){
wydarzenie.dodajRezerwa cje(data);
return "wykonano rezerwacje"; } else
return "brak wolnego wydarzenia"; } W tej metodzie
wydarzenie jest wstawione do atrybutu wydarzenie w metodzie
szukajWolnegoWydarzeni a(data),
I może być wykorzystany, gdy wynik tej metody jest równy true.
Diagram aktywności:
dodajRezerwacjeWycieczk i(String arg[], LocalDate data)
jest niepoprawny – błędne są scenariussze w torach Miejscowosc i Wydarzenie (nie nawiązują do scenariuszy diagramów sekwencji.
Tor Miejscowosc powinine wynikać z diagramów sekwencji
dodajRezerwacje_Miejsco wosc i
Miejscowosc.szukajWolne goWydarzenia, a scenariusz toru
Wydarzenie ze scenariuszy diagramów sekwencji:
Wydarzenia.czyWolne oraz dodaRezerwacje_Wydarze ne)
Należy go poprawić
Diagram stanów Przejście
equals[true]/getKodPoczto wy().equals(((Miejscowosc )obj).getKodPocztowy()) jest źle zdefiniowane.
Powinno być w polach Open Specification...:
Name: equals Effect:
getKodPocztowy().equals((
(Miejscowosc)obj).getKod Pocztowy())
Guard: true
Podobnie należy poprawić przejście z Guard równym false dla zdareznie equals.
Częśc diagramu stanów po wyjściu ze stanu loop jest błędna – nie nawiązuje przynajmniej do scenariusza diagramu sekwencji
dodajRezerwacje_Miejsco wosc. Mozna również uwzglednić scenariusz diagramu sekwencji Miejscowosc.szukajWolne goWydarzenia
Należy poprawić diagram stanów
4.06.18 Diagram stanów Ocena 3.5 229604 p.2 ocena 5
p3.
Metoda searchBookTitle Ma nie poprawny kod– powinien przy wykonaniu wzorcowego
W opisie „świata rzeczywistego” nie powinno być opisu funkcji i GUI programu, tylko procesów istniejących bez programu. Należy dokonać korekty opisu.
PUoperacjeNaPodrozach w scenariuszu odwołuje się do PUWyszukaj Oferte, a na diagramie
PUoperacjeNaPodrozach jest powiązany z PUwyszukajPodroz i ten
Brak programu.
Diagram klas:
brakuje klasy zarządzającej np Facade.
Brakuje podania liczności powiązań pomiędzy klasami.
Brak lab6 Ocena w lab7
14.04.18 Brak diagramów sekwencji modelujących przynajmniej 4 przypadki użycia podczas 4 iteracji rozwoju programu.
24.04.18 Brak projektu
21.05.18 Diagramy aktywności ; 5.0
6.05.18
Diagram klas Mimo oceny należy dodać właściwość Multiplicity!!!
Diagramy sekwencji:
Stan kodu i części diagramów ustalono w dniu 18.05.2018.
Nalezy dostarczyć poprawiony projekt UML.
21.05.18
21.05.18 Brakuje testów akceptacyjn ych 15.06.16 Testy akcepracyj
7.06.18 Brakuje dokume ntacji 10.06.16 Ocena 4.5
7.06.18 Brakuje refaktoryzacji 10.06.16 Ocena 4.5
10.06.18 Ocena 4.5 229685
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.getbook s();
Należy zawsze stosować zasadę wieloużywalności kodu
hermetyzacji kodu !!!
Kod należy poprawić w celu zaliczenia lab2.
Kod należy poprawić w celu zaliczenia lab2.
p.4
Koniecznie usunąć odwołania typu Facade.this.search BookTitle(help1)!!
! w metodach klasy Facade.
Ocena:???
Poprawa 9.03.18 Ocena 4.5
Wymagania: ocena 5.0 Pełna ocena po zmodyfikowanniu opisu
„świata rzeczywstego”
Ocena 5.0
PU powinien być wywołany w scenariuszu.
PUdodajPodroz powinien rozszerzać scenariusz PUoperacjeNaPodrozach, natomiast ten scenariusz powiela, ponieważ wywołuje nieistniejący PUWyszukaj Oferte.
Itd.
Nalezy poprawić te niespójne scenariusze.
23.03.18
Brak poprawy diagramu przypadków użycia.
Poprawa 3.04.18 PU usunPodroz i PU modyfikujPodroz są powiązane dodatkowo przez include z PU wyszukajPodroz. Jednak w scenariuszach tych PU brakuje odwołan do PU wyszukajPodroz.
PUusunRezerwacje jest powiązane z PU:
operacjeNaPodrozach, wyszukajRezerwacje, wyszukajKlienta, natomiast w scenariuszu brak odwołania do PU operacjeNaPodrozach Ocena poprawy 4.0
Agregacja silna powoduje, że usunięcie obiektu Travel spowoduje usunięcie obiektu typu Hotel itd Brak diagramów sekwencji Nie wykonano projektu i implementacji 1- go PU wg instrukcji:
Instrukcja - część 2
(realizacja 1-ej iteracji) Ocena???
3.04.18 Diagram klas powinien zawierać atrybuty prezentujące powiązania między klasami.
Obecnie atrybuty te sa razej ilustracją powiązań.
14.04.18 Diagram klas Ocena 5.0
Wykonano następujące diaramy sekwencji:
1)Sequence Diagram1- modeluje dodawanie obiektów typu Client (bez pomocniczych diagramów) 2)Sequence Diagram2- modeluje dodawanie obiektów typu Travel (bez pomocniczych diagramów) 2)addTravel”
modeluje niepoprawny sposób dodawania obiektów typu Travel (z naruszeniem integralności danych) poprawiony na diagramie Sequence Diagram2
Kod
Brak uruchomienia wykonanego kodu, podobnie jak pokazano w instrukcji do lab5-7:
Instrukcja - część 2
Wg ustaleń w wyniku wykonania lab5-7 należało wykonać 4 przypadki uzycia (projekt i implementacja)...
Ocena???
Wszystkie messages typu Lost Message powiny być typu Reply.
1)
Facade.addReservatio n
Klasa Façade nie posiada kolekcji reservations – nie jest powiązana na diagramie klas z klasą Reservation.
Diagram do poprawy!
Można wzorować się na dodawaniu rezerwacji w instrukcji do lab5-7.
2)addInvoice – ten sam błąd. Klasa Facade nie jest powiązana z klasą Invoice.
Można wzorować się na dodawaniu rezerwacji w instrukcji do lab5-7, rozszerzając ten scenariusz!
3)Travel.isAvaiable- brakuje diagram wywołującego scenariusz z tego diagramu Poza tym, Travel i Hotel również nie są powiązane za pomocą scenariusza
podobnego do dodawania obiektów Book (tutaj Travel) przez TitleBook lub TitleBookRead (tutaj Hotel).
Diagram aktywności – brak przepływu
Należy wykonać testy jednostkowe.
28.05.18
Testy jednostkowe klasy Facade (FacadeTest) powinny testować jdenie metody klasy Facade.
Testy nie korzystają z wyników testów poprzedniego testu np w przypadki testowania Np W klasei ClientTest test testSearchReservation powinie opierać się na danych wprowadzonych podczas testu
testAddReservation. Testy są do poprawy!
10.06.18 Testy jednostkowe niepoprawnie korzystają z parametryzacji. Konieczne jest zastosowanie adnotacji w nagłówkach danych typu @RunWith,
@Category (do tworzenia zestawu testów).
W testach należy sprawdzać przypadki:
korzystania z istniejących danych, dodać
sprawdzanie integralności danych (odporność na powtórne wstawianie tych samych danych) oraz odporność na próbę korzystania z danych nieistniejących.
Ocena???
ne po wykryciu i usunięciu błędów w dniu 15.06.18 należy rozbudowa ć o przypadki korzystania z
istniejącyc h danych, dodać sprawdzani e integralnoś ci danych (odporność na powtórne wstawianie tych samych danych) oraz odporność na próbę korzystania z danych nieistniejąc ych.
Ocena???
21.05.18 Diagramy sekwencji;
4.5 Kod: 5.0
między torem Facade i torem Hotel. Jednak, nie jest to mozliwe, aby Hotel sam się dodawał – tor Hotel może jedynie wykonaywać aktywność equals podczas wstawiania.
Diagram stanów – brakuje diagramów sekwencji, które są żródłem zdarzeń i akcji dla klasy Hotel????.
Ten diagram pokazuje analogię między klasami Hotel i TitleBook
(TitleBookRead) z instrukcji, Travel i Book (z instrukcji), Reservation i Reservation (z instrukcji). Jedynie Invoice rozszerza diaram klas i daje
szansę na
zaproponowanie koncepcjji dodawania tych obiektów.
Na tym etapie diagramy sekwencji są niezaliczone.
Kod programu – ma niewiele wspólnego z diagramami sekwencji i klas np umieszczenie kolekcji reservations w klasie Facade!!!
Warto ponownie skorzystać z konsultacji – jednak należy w kodzie i diagramach skorzystać z pewnych analogii
wynikających z i nstrukcji do lab5-7 i rozszerzyć projekt o obsługę Invoice, którą można
przedyskutować podczas konsultacji.
21.05.18 Diagramy stanów ; 4.5
