Należy przeprojektować generator labiryntów, który wyświetla wygenerowany przez siebie labirynt w dwóch trybach: graficznym i tekstowym. O tym, w którym trybie wyświetlany ma być labirynt decyduje argument wywołania programu.
Ponadto aplikacja ma mieć możliwość podania statystyk odnośnie liczby ścian, drzwi i pokoi. O tym co będzie robione (renderowany labirynt lub podane statystyki) decyduje argument wywołania programu.
Przy projektowaniu nie uwzględniać faktu, że powstała już implementacja/projekt i trzeba minimalizować koszty modyfikacji tak by uwzględniała nowy projekt, czyli należy unikać tworzenia dziwnych konstrukcji i projektować od nowa.
Jeśli nawet dana funkcjonalność nie uległa zmianie to należy się zastanowić czy nie można jej zaprojektować lepiej. Przecież doszły nowe wzorce :-)
Program ma optymalizować wykorzystanie zasobów (np. nie generować niepotrzebnych obiektów, struktur itd.).
Labirynt zbudowany jest przy pomocy pokoi, które składają się ze ścian. Pokoje łączy się poprzez drzwi lub zostawia dziurę w ścianie. Drzwi muszą wiedzieć, które dwa pokoje łączą. Labirynt może zawierać wejścia do innych labiryntów, czyli może istnieć labirynt zawierający inne labirynty.
Planuje się dodanie w przyszłości także innych wariantów tych samych elementów labiryntu jak np. ceglane ściany. O typie ściany decydowałby motyw wybierany przy uruchomieniu aplikacji. Generator labiryntu nie ma wpływu na wybór motywu. Motyw wybierany jest w momencie uruchamiania aplikacji. Niektóre elementy labiryntu mogą mieć taki sam wygląd dla wielu motywów np. okna wyglądać będą tak samo dla betonowego jak i ceglanego. Elementy labiryntu używane są tylko do reprezentowania labiryntu. Należy uwzględnić w projekcie możliwość dodania ich w przyszłości.
Rozwiązanie problemu renderowania w trybie graficznym i tekstowym zostawione jest do dyspozycji projektantów. Nie ma gotowej biblioteki graficznej z której trzeba skorzystać. Należy tylko zaprojektować system tak by uwzględniał także możliwość dodania w przyszłości innych trybów niż tylko graficzny, tekstowy.
Do oceny należy oddać diagramy Class Diagram oraz Sequence Diagram przedstawiające szczegółowy projekt programu dla języka Java. Projekt, który nie wykorzystuje funkcjonalności języka Java np. w projekcie są zaprojektowane kolekcje a przecież Java udostępnia ten mechanizm może spowodować obniżenie oceny.
Projekty nie zawierające wszystkich wymaganych diagramów nie są brane pod uwagę przy ocenianiu.
Błędy w projekcie typu formalnego jak niezgodność z UML powoduje obniżenie między 0,5 - 1 stopień. Przykłady to brak związku pomiędzy klasami w projekcie mimo, że taki istnieje, nie określenie typu związku (dziedziczenie, agregacja itd.), klasa abstrakcyjna, która nie posiada żadnej metody abstrakcyjnej, brak arności związku, opisu ról klas w związku itd. Pętle oraz instrukcje warunkowe też mają być modelowane! Projekt ma być też opatrzony w komentarz zawierający: datę utworzenia, imię, nazwisko i numer indeksu autora, wzorce projektowe, które wykorzystano w danym zadaniu z informacją za co dany wzorzec odpowiada np. wykorzystano wzorzec AbstractFactory do tworzenia... W przypadku gdy kilka wzorców może być wykorzystanych do zamodelowania danego zachowania itd. należy podać jakie to są wzorce oraz uzasadnienie wybrania jednego z nich. Należy podać przyjęte założenia w przypadku gdy treść zadania jest niejednoznaczna.
Klasy występujące w projekcie należy nazywać tak by były łatwo kojarzone z użytym wzorcem np. DeviceSingleton i nadawać rolę klasom występującym w związku np. Adaptee, Proxy itd.
Błędy związane ze wzorcami projektowymi typu nieprawidłowe zamodelowanie wzorca czy też omyłkowa nazwa wzorca powodują obniżenie oceny o 1 stopień za każdy nieprawidłowo zamodelowany wzorzec.
W zadaniu należy stworzyć projekt systemu, który jest czytelny, elastyczny i łatwy w modyfikacji. By tego dokonać należy zaprojektować aplikację tak by była elastyczna w wymaganych przez specyfikację miejscach oraz by posiadała minimalną liczbę klas/interfejsów przy zachowaniu założenia, że modyfikacja ma dotykać jak najmniejszej liczby klas/interfejsów. Dodanie zakładanej funkcjonalności ma także pociągać dodanie jak najmniejszej liczby klas/interfejsów. W przypadku nie spełnienia tego założenia możliwe jest obniżenie oceny od 0,5 do 1 stopnia.
Wystąpienie przykrego zapachu w projekcie obniża ocenę o 1 stopień. Obowiązują wszystkie przykre zapachy poznane na wykładzie z wyjątkiem Lazy Class.