Autor: Piotr

Lista na lab – pdf.

Teoria na lab – pdf.

Lista na lab – pdf.

Teoria o prog. generycznym – pdf.

• Nadal obowiązuje regulamin ćw – link.
• Termin – przedostatnie ćw.
• Łącznie do zdobycia max 60 punktów. Próg zaliczenia: 25 pkt (bez innych punktów).
• Kolokwium należy wykonać na komputerach zamontowanych na stałe w pracowniach.
• Student przesyłając rozwiązania oświadcza, że rozwiązał je samodzielnie.
• W trakcie kolokwium nie można korzystać z żadnych materiałów pomocniczych w żadnej formie. Wszelkie kody powinny być napisane manualnie bez wspomagania się dodatkami automatycznie generującymi kod (np. Copilot, chat GPT itp.).
• Publikowanie poleceń i rozwiązań w internecie jest zabronione do czasu napisania kolokwium przez wszystkie grupy ćw.
• Należy zwracać uwagę na właściwe umieszczenie kodu (luzem lub w pakiecie).
• Kod musi się kompilować, aby był sprawdzany.
• Należy oddzielać klasę z definicjami od klasy testującej (z main) zgodnie z poleceniami.
• Jeśli w poleceniu nie jest podany typ zmiennej, można go wybrać dowolnie.
• Jeśli w danej metodzie nie ma sprecyzowanej „walidacji”, to można ją pominąć.
• Metody nie powinny wykonywać nadmiarowych, nielogicznych czynności.
• Poza zmiennymi/polami w klasie wymienionym w polecaniach zabronione jest tworzenie innych pól w klasie. Stworzenie dodatkowych metod jest dopuszczalne, ale nie należy tego nadużywać.
• Jeśli w poleceniu nie są sprecyzowane modyfikatory dostępu, należy dostępować zgodnie z zasadami hermetyzacji.
• W rozwiązaniach należy uwzględniać dobre praktyki omawiane na wykładzie i ćwiczeniach, o ile polecenie nie mówi coś innego.
• Rozwiązania (projekt z IntelliJ) należy w całości spakować jako archiwum zip. Następnie ustawić nazwę. Rozwiązania należy umieścić na pendrive przekazanym przez prowadzącego kolokwium.
• Nazwa archiwum powinna być wg schematu NUMERZESTAWU_NUMERALBUMU.zip gdzie numer zestawu znajduje się na górze kartki z poleceniami. np. A23_123456.zip.
• Archiwum powinno być bez hasła.
• Kod zakomentowany nie będzie sprawdzany.
• Zawartość pendrive będzie pusta. Udostępniony będzie tylko w celu zgrania rozwiązań. Umieszczenie poleceń na pendrive powinno odbyć się w czasie kolokwium. Rozwiązania po czasie mogą nie być sprawdzane.
• Jeśli w poleceniu pojawia się informacja o konieczności zachowania formatowania napisów (np. wielkość znaków, znaki interpunkcyjne), to należy to bezwzględnie wykonać.
• Podpunkty będą oceniane kaskadowo — wykonanie ich bez wykonania wcześniejszych podpunktów może oznaczać zero punktów.
• O ile nie zaznaczono w poleceniu inaczej, każdą z metod należy wywołać co najmniej jeden raz (może być bardzo trywialnie). Warto zwrócić uwagę, że samo tworzenie obiektów w każdym zdefiniowanym samodzielnie typie nie jest wymagane (chyba że polecenie tego wymaga).
• Należy zachowywać kolejność argumentów w konstruktorach i metodach. Należy dążyć do tego, że nazwy argumentów metod powinny pokrywać się z nazwami pól w klasie, gdzie to ma sens.
• Warto zwracać uwagę na typ zwracany metod — jeśli metoda ma „coś” zwrócić, będzie to wskazane w poleceniu.
• Po kartkach z poleceniami można pisać i traktować jako brudnopis.

Przykładowe zestawy (ISI2, ISI5):

• Z11 – pdf
• Z12 – pdf
• Z13 – pdf
• Z14 – pdf
• Z15 – pdf

Przykładowe zestawy (ISI4, IO-powt., ISI-powt. – bez kolekcji):

• T11 – pdf
• T12 – pdf
• T13 – pdf
• T14 – pdf
• T15 – pdf

Lista na lab – pdf.

Na podstawie wymagań funkcjonalnych i niefunkcjonalnych dla aplikacji konsolowej symulującej działanie kasy fiskalnej, można zaprojektować następujący układ klas, rekordów i interfejsów:

1. Interfejs ITransaction

Reprezentuje pojedynczą transakcję. Może zawierać metody takie jak startTransaction(), addItem(Item item), finalizeTransaction().

2. Klasa Item

Reprezentuje pojedynczy produkt lub usługę. Zawiera pola takie jak:

• String name – nazwa produktu/usługi.
• double price – cena produktu/usługi.
• String category – kategoria produktu/usługi.

3. Klasa Receipt

Reprezentuje paragon/fakturę. Zawiera:

• List<Item> items – lista produktów/usług na paragonie.
• double totalPrice – łączna wartość paragonu.
• DateTime date – data i czas transakcji.

4. Interfejs IPayment

Reprezentuje płatność. Może zawierać metody takie jak processPayment(double amount).

5. Klasa CashPayment implementująca IPayment

Reprezentuje płatność gotówką. Zawiera implementację metody processPayment.

6. Klasa CardPayment implementująca IPayment

Reprezentuje płatność kartą. Zawiera implementację metody processPayment.

7. Klasa Transaction implementująca ITransaction

Reprezentuje realizację transakcji. Zawiera:

• Receipt receipt – paragon/faktura.
• IPayment paymentMethod – metoda płatności.
• Metody z interfejsu ITransaction.

8. Klasa CashRegister

Główna klasa symulująca kasę fiskalną. Zawiera:

• List<Transaction> transactions – historia transakcji.
• Metody do zarządzania transakcjami i płatnościami.

9. Interfejs IUserInterface

Reprezentuje interfejs użytkownika. Może zawierać metody do wyświetlania menu, przyjmowania wejść od użytkownika itp.

10. Klasa ConsoleInterface implementująca IUserInterface

Reprezentuje konsolowy interfejs użytkownika. Zawiera implementację metod z IUserInterface.

Zależności i przepływ danych:

• CashRegister tworzy i zarządza Transaction.
• Transaction używa Item, Receipt i implementacji IPayment.
• CashRegister komunikuje się z użytkownikiem przez ConsoleInterface.

Wymagania Funkcjonalne

1. Interfejs Konsolowy: Aplikacja powinna posiadać prosty interfejs użytkownika w konsoli, który pozwala na wprowadzanie danych produktów i obsługę transakcji.
2. Wprowadzanie Produktów: Użytkownik powinien mieć możliwość wprowadzenia nazwy produktu, ceny jednostkowej oraz ilości.
3. Obliczanie Podsumowania: Aplikacja powinna automatycznie obliczać łączną kwotę do zapłaty po wprowadzeniu każdego produktu.
4. Generowanie Paragonu: Po zakończeniu wprowadzania produktów i potwierdzeniu transakcji, aplikacja powinna generować paragon z listą produktów, ich cenami, łączną kwotą oraz datą i godziną transakcji.
5. Obsługa Błędów: Aplikacja powinna obsługiwać błędy wprowadzania danych (np. nieprawidłowy format ceny) i wyświetlać odpowiednie komunikaty.
6. Historia Transakcji: Opcjonalnie, aplikacja może przechowywać historię transakcji do późniejszego wyświetlenia.

Wymagania Niefunkcjonalne

1. Język Programowania: Aplikacja powinna być napisana w Javie, z minimalnym wykorzystaniem niestandardowych klas z API Javy.
2. Prostota: Aplikacja powinna być prosta w obsłudze i przeznaczona dla użytkowników bez zaawansowanej wiedzy technicznej.
3. Wydajność: Aplikacja powinna szybko przetwarzać dane i generować paragony bez znaczących opóźnień.
4. Skalowalność: Kod powinien być napisany w taki sposób, aby umożliwić łatwe rozszerzenie funkcjonalności aplikacji w przyszłości.
5. Przenośność: Aplikacja powinna być łatwa do uruchomienia na różnych systemach operacyjnych obsługujących Javę.
6. Testowalność: Kod powinien być napisany w taki sposób, aby ułatwić testowanie jednostkowe i integracyjne.
7. Dokumentacja: Aplikacja powinna być dostarczona z dokumentacją, która opisuje jej działanie i sposób użycia.
8. Bezpieczeństwo: Chociaż aplikacja jest symulatorem, powinna być zaprojektowana z uwzględnieniem podstawowych zasad bezpieczeństwa oprogramowania.

Zadanie #1:

• zastanów się jakie wymagania i funkcjonalności powinna posiadać Twoja aplikacja. Warto do spisać w jakimś zaawansowanych edytorze tekstu np. LaTeX, Markdown. Przykład.

Zadanie #2:

• zaplanuj roboczy schemat klas/interefejsów/rekordów (?). Przykład2.

Zadanie #3:

• rozbuduj roboczy schemat klas/interfejsów/rekordów pod kątem zasad SOLID. Przemyśl na ile ich zastosowanie ulepszy czy utrudni późniejsze kodowanie (?).

Zadanie: #4

• zastanów się, czy zamiana niektórych metod/klas na generyczne nie sprawiłaby ulepszenia projektu? Jeśli tak, zmodyfikuj schemat z punktu 2.

Zadanie: #5

• zaimplementuj zaplanowany schemat. W razie potrzeby, możesz zmodyfikować schemat.

Zadanie: #6

• przetestuj działanie programu.

Lista na lab – pdf.