Практические задания по курсу «Язык программирования Java» 1

1 Практические задания по курсу «Язык программирования Java»
Названия задач вида base-* означает, что они относятся к тем, кто посетил по соответствующей теме лекцию-семинар базового уровня, а названия вида intensive-* – лекциюсеминар углубленного уровня.
1.1 Короткая задача base-1
1. Вывести в цикле for буквы русского алфавита (в любом регистре) и их число (1 балл)
2. Вывести для каждой буквы код юникода в десятичном (приведение к int) и шестнадцатеричном представлении (16-ичное число можно вывести в обратном порядке) (1 балл)
3. Написать 2 функции преобразования букв к верхнему и нижнему регистру
(toUpperCase, toLowerCase); написать функцию, использующую две предыдущие, которая
на входе принимает букву и возвращает ее в противоположном регистре (т.е. строчную
букву делает прописной и наоборот). Весь код пишется для русского алфавита и не использует готовые библиотеки. Функции оформляются с модификаторами public static, которые необходимо протестировать в main() (1 балл)
Итого за задачу: 3 балла
1.2 Короткая задача intensive-1
Не меняя ничего в функции main(), модифицировать класс Hello таким образом, чтобы на консоль выводилась другая строка (не “Hello, World!” или не только “Hello,
World!”) (3 балла)
class Hello {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
РЕШЕНИЕ ЗАДАЧИ: либо полное переопределение класса System (вместе с out и т.д.),
либо делается static блок инициализации, где на консоли печатается другое и выполняется
System.exit().
1.3 Короткая задача base-2
1. Создать 3-мерный неравномерный массив (т.е. не параллелепипед с пустующими
ячейками) следующего вида: основание - прямоугольный равнобедренный треугольник с
катетом = 10 ячеек, одна из вершин при остром угле - ячейка [0][0], высота в ячейках произведение (x+1)*(y+1), где x,y - индексы точки на треугольнике.
2. Заполнить элементы массива объектами ссылочного типа(класса) StringBuffer, содержащими индексы массива в виде "x,y,z", и вывести их на экран.
Итого за задачу: 2 балла
1.4 Короткая задача intensive-2
Доработать пример example1, рассматриваемый на семинарах 1-2 (работать в пакете
фамилия.example1):
1. В наследнике класса ConsoleShower сделать private-поле типа java.io.PrintStream c
getter/setter-методами (их рекомендуется сгенерировать средствами IDE) и использовать
его для вывода строк. В getter-методе "при необходимости" (т.е. если поле не инициализировано ранее) присваивать полю ссылку на поток вывода ошибок System.err. (1 балл)
2. Создать реализацию класса StringShower, показывающую строки в окне сообщения с
помощью javax.swing.JOptionPane.showMessageDialog() (можно наследовать эту реализацию от GUIShower, чтобы одновременно показывать строки и в TextArea). Проверить работоспособность (2 балла)
3. Переопределить метод GUIShower.updateComponentSize, используя для обработки текста регулярные выражения (java.util.regex.*) вместо java.util.StringTokenizer (3 балла)
4. В Rational Rose импортировать (reverse engineer) и показать на диаграмме классы пакетов ru.ipccenter.examples.example1 и фамилия.example1 (1 балл)
Итого за задачу: 7 баллов
1.5 Короткая задача base-3
Разработать несколько (3-4) классов для хранения структуры данных, которые описывали бы некую реальную систему или процесс («предметную область»). Например, такой предметной областью может быть институт, магазин, расписание и т.п.; конкретная
область выдается куратором или может быть предложена самим студентом. Классы должны быть связаны отношениями наследования, агрегации и др. 1 балл дается за выполнение
каждого из следующих требований:
1. Разработать классы как угодно (лишь бы они могли хранить данные)
2. Написать классы в соответствии с правилами ООП, с getter/setter-методам доступа к полям, с разумными модификаторами.
3. Написать любую логику в getterах или setterах, а также переопределить какой-либо метод с вызовом соответствующего метода суперкласса.
4. Классы импортировать (reverse engineer) в Rational Rose и показать на диаграмме
5. Указать на диаграмме те отношения между классами, которые не импортировались автоматически, показать множественность (multiplicity) ассоциаций
Итого за задачу: 5 баллов
1.6 Короткая задача intensive-3
Доработать часть примера example2, связанную с объектами хранения данных и рассматриваемую на семинаре 3 (работать в пакете фамилия.example2, скопировав туда 4
класса хранения данных). Пусть нужно добавить в гипотетическую информационную систему института возможность логина пользователей, причем она должна быть у преподавателей и начальников (причем пусть начальник не наследует Person), а у студентов этой
возможности не планируется. Следовательно, для хранения информации о логине и пароле (а также для проверки пароля в специальном методе) классу Teacher наряду с Person
требуется другой суперкласс User (другой, т.к. Student наследует Person). Задача – реализовать множественное наследование через одиночное наследование и агрегацию:
1. Реализовать любым образом (2 балла)
2. Выделить интерфейс Human, который реализуют 2 из 3-х видов людей – аналогично
тому, как класс Person расширяют другие 2 вида людей (1 балл)
3. При необходимости (т.е. если не установлен ранее) инициализировать агрегированный
в Teacher объект («делегат») в отдельном методе – см. аналог в примере 1 GUIShower.*TextArea() (1 балл)
4. Указать достоинства и недостатки сделанного выбора суперкласса для Teacher (2 балла)
5. В Rational Rose импортировать (reverse engineer) и показать на диаграмме классы пакета
фамилия.example2 (1 балл)
Итого за задачу: 7 баллов
1.7 Практическая задача base-4: «Архиватор»
Написать консольную утилиту для работы с zip файлами, которая использовала бы
стандартные java классы для работы с файлами zip формата (пакет java.util.zip):
1. Написать консольную программу, которая бы могла упаковывать, распаковывать и добавлять файлы в zip архивы. Как аргументы командной строки, программа должна принимать имена входных файлов и имя выходного архива, в который нужно упаковать их. Для
распаковывания должна принимать имя архива и, опционально, путь к (существующей
или не существующей) директории для распаковки. (5 баллов)
2. Если вместо входного файла указана директория – упаковывать ее содержимое рекурсивно (2 балла).
3. Поддерживать комментарии к архивам (чтение комментариев у существующего архива,
добавление комментария в существующий архив, создания архива с комментарием) (3
балла: по одному за каждое «подтребование»)
Итого за задачу: 10 баллов.
1.8 Короткая задача intensive-4
Реализовать классы для создания, записи и загрузки объектов ("людей" из примера
2) на основе диаграммы классов, рассмотренной на семинаре 7 (или на основе другой подобной диаграммы, удовлетворяющей принципам ОО проектирования). Рекомендуется
использовать для этого генерацию кода из Rational Rose (см. приложенный к семинару 7
файл). На выходе должно быть 2 программы, аналогичные по возможностям программам
PersonArrayWriteTest и PersonArrayReadTest:
1.
Написать
классы
(с
main)
для
создания
и
записи
людей
аналогично
PersonArrayWriteTest, но с хранением людей в java.util.List (3 балла), а также в
java.util.Map (+1 балл)
2. Написать классы (с main) для загрузки и сортировки людей аналогично
PersonArrayReadTest (2 балла; если с проектированием иерархии интерфейса PersonSorter 4 балла)
3. Написать класс ReadPersonCreator, использующий PersonReader для создания людей; а
также соответствующий main (2 балла)
Итого за задачу: 7-10 баллов
1.9 Практическая задача base-5, intensive-5: «Робот»
Написать робота для игровой платформы Robocode. Робот – это Java-класс, наследующийся от robocode.Robot и определяющий (в методе run()) некоторое поведение робота на игровом поле (передвижение, слежение за противниками, стрельба). Одна из целей
задачи заключается в получении навыка использования документации по незнакомой тематике.
1. Написать и протестировать работоспособного (двигающегося и стреляющего) робота,
логика которого не совпадает с логикой примера из пакета sample (который является частью платформы). (2 балла).
2. Находить робота-противника на поле боя размером в 5000 на 5000. При таком размере
поля радар не охватывает всю поверхность, и поэтому противника нужно будет искать. (3
балла)
3. Применить при реализации робота шаблон State/Strategy (т.е. реализовать переключение
между типами поведения класса не через многочисленные условные выражения, «разбросанные» по всему коду, а через делегирование некоторых функций экземпляру интерфейса/абстрактного класса State – так, чтобы при переключении в какое-либо состояние устанавливать в качестве делегата одну из реализаций State). Разные состояния шаблона State
следует использовать для описания действий робота при поиске противника и, собствен-
но, при ведении боя, можно также переключаться в разные состояния при битве с одним и
со многими противниками (метод getOthers() возвращает число противников). (5 баллов)
4. Побеждать написанным роботом большинство роботов пакета sample (4-10 баллов):
* при битве типа 1 на 1, то есть в основном режиме (7 баллов, если всех);
* при коллективной битве «каждый сам за себя» (+3 балла; робот должен занять первое место по очкам и остаться в живых, как минимум, в половине раундов; как правило,
победа всех в режиме «1 на 1» автоматически приведете к такой победе; ни один из роботов пакета sample не имеет специальной стратегии для этого режима).
5. Победить робота автора задачи – 5 баллов.
6. Занять место в турнире между студентами учебного центра (5–15 баллов):
Баллы за все нумерованные требования суммируются друг с другом.
Итого за задачу: 10 баллов за реализацию + 7-30 баллов за победы.
1.10 Практическая задача base-6: «Блокнот»
Написать текстовый редактор (аналог Notepad в Windows) на базе Swing со
следующими элементами: окно, меню (File, Edit, Help), текстовая область с содержимым
(неформатированного) текстового файла.
1. Действия меню File: загрузка/сохранение файла; действия меню Edit: select all, delete,
cut/copy/paste; единственный пункт меню Help (About...) должен показывать информацию
о программе. (7 баллов при условии качественного кода)
2. "Ручная" поддержка режима "Word wrap" ("перенос по словам") при загрузке файл и
при изменении размеров окна: то есть, разбиение текста на несколько строк, так чтобы их
длина не превосходила ширину окна, а слова не разрезались на части. Можно, но необязательно, сделать опцию (JCheckBox) в меню Format, включающую и отключающую режим
переноса по словам. (до 4 баллов)
3. Использование системного буфера обмена для операций cut/copy/paste (до 4 балов)
Итого за задачу: до 15 баллов.
1.11 Практическая задача intensive-6: «Очередь в столовую»
Есть 1000 студентов с разных факультетов. Они по звонку собираются в столовую,
где занимают очередь. Считается, что это происходит довольно быстро, и очередь не
успевает двигаться. Если очередь пустая, то студент становится в очередь первым, если в
очереди уже кто-то стоит, то студент ищет сначала первого студента со своего факультета
и пристраивается к нему как к знакомому. У любого студента есть случайный параметр
«совесть», которая определяет число студентов, которых он может пропустить вместе с
собой (поставив их впереди себя). Если пристроиться к текущему студенту с факультета
не позволяет совесть, то ищется следующий, и т.д. Если подходящих вариантов не
нашлось, то студент становится в самый конец.
1.
Моделирование вышеописанного процесса на Java
1.1.
генерация "случайного" студента (имя, фамилия, пол, факультет, совесть) и подача
студентов «на вход» столовой (2 балла)
1.2.
моделирование очереди, т.е. создание структуры данных отвечающую очереди и
заполнение ее по вышеописанным правилам; один из 2х альтернативных вариантов:
* используя массив (2 балла)
* используя List (2 балла)
1.3.
реализация варианта с несколькими дверями, т.е. когда студенты приходят двумя и
более независимыми потоками; все операции должны быть thread safe (3 балла)
1.4.
выделение класса, ответственного за «правила» приема студента в очередь и учи-
тывающего характеристики «принимающего» и «принимаемого» студентов (и, возможно,
«допускающего» студента, то есть того, кто стоит сзади принимающего и может сказать
«вы что, обнаглели совсем?»); а также реализация любого из таких правил. Например, такими правилами могут быть "альтернативный способ влияния совести", "учет пола студента", "учет вероятности того, что студенты с одного факультета могут быть не знакомы"
или " учет того, что студент, который стоит сзади принимающего, не пустит принимаемого студента в очередь (на вероятность этого может также влиять совесть принимаемого)".
(2 балла)
1.5.
(при условии реализации предыдущего требования) комбинирование различных
правил приема студента в очередь (например, с помощью перемножения «вероятности
приема», получаемого по разным правилам, и сравнения итоговой вероятности с пороговой); желательно реализовать с применением шаблона Chain of Responsibility и проверить
на комбинации из более чем двух правил (2 балла)
2.
Вывод результата – чисел студентов в каждой группе, образованной студентами
одного факультета.
2.1.
вывод в текстовом режиме (1 балл)
2.2.
вывод в графике: гистограмма (факультеты – разные цвета; подпись имен)
* статическое распределение – после того как все встали в очередь (3 балла)
* показ процесса в динамике – т.е. должно быть видно, как растет очередь в процессе
прихода студентов (3+5 баллов)
Итого за задачу: 20 баллов.
2 Дополнительные задачи к курсу «Язык программирования
Java»
Приведенные ниже вопросы и короткие задачи выдаются не всем студентам, а персонально: кураторы выдают их тем студентам, которые досрочно справляются с практическими задачами и лабораторными работами, а также глубоко интересуются вопросами
устройства JVM и оптимизации программного года.
1. Сможет ли эта программа корректно завершиться?
public class Main {
public static void main(String[] args){
A a = new A();
B b = new B();
a.b = b;
b.a = a;
}
}
class A{
B b;
public void doSomeTask(){}
public void finalize() {
b.doSomeTask();
}
}
class B {
A a;
public void doSomeTask(){}
public void finalize() {
a.doSomeTask();
}
}
Подсказка:
Возможные варианты: а) Garbage Collector должен уничтожить сначала либо объект
a, либо b. Пусть он выбрал a, тогда в объекте b обнулится поле a и в b.finalize() вылетит NullPointerException. б) GC обнаруживает два связанных (взаимно ссылающихся друг на друга) объекта, на которые нет ссылок извне. В некотором (недетерминированном) порядке он вызовет их методы finalize(), и только затем физически очистит память; в) GC вообще не сможет уничтожить эту пару объектов, но тогда здесь возникает
memory leak – утечка памяти.
Ответ: б
Замечание: Летучим голландцем в java называется набор объектов, где каждый ссылается на другие объекты этого набора, причем набор сильно связан, т.е. из каждого объекта набора можно по ссылкам добраться до любого другого объекта этого набора.
2. Может ли в одной JVM создаться несколько экземпляров такого класса?
public final class Singleton {
private static Singleton instance = null;
public static Singleton getInstance() {
synchronized(Singleton.getClass()){
if(instance != null)
return instance;
return instance = new Singleton();
}
}
private Singleton() {
}
public String usefulFunction(){
return "";
}
}
Ответ: Да, может. Нужно создать хитрую систему ClassLoader’ов. Например,
можно у системного ClassLoader'а создать два дочерних ClassLoader 'а, которые
могут загружать файлы из jar-файла или с диска. С помощью каждого из них можно загрузить класс Singleton, загрузятся две копии класса. Имена обоих загруженных классов
будут совпадать, тем не менее это будут два отдельных и различных класса в java-машине,
поэтому можно будет создать две копии синглтона. Хотя на практике такие проблемы
встречаются крайне редко, все же полезно иметь представление об организации
ClassLoader'ов в java.
3. Что выведет данная программа?
public class Main{
public static void main(String[] args){
new B().print();
}
}
class A{
void print(){
System.out.println(getClass());
}
}
class B extends A{
}
4 а) Что вернет метод?
boolean getResult(){
try {
return true;
}
finally {
return false;
}
}
4 б) Что выведется на экран?
try {
System.out.println(“Hello, “);
System.exit(0);
}
finally {
System.out.println(“world!”);
}
Ответ: а) false; б) “Hello, ”
5. Возникнет ли ошибка, и если да, то когда?
а) String obj = (String) (Object) ((String) ((Object) new String()).toString()).toString()
б) Class class = String.getClass();
Ответ: а) нет; б) да: class нельзя использовать в качестве имени переменной; надо
также писать String.class вместо String.getClass().
6. Что следует сделать, чтобы следующий код компилировался без ошибок?
public pause(int sec) {
int start = System.currentTime();
while (System.currentTime() - start < sec * 1000) {
this.wait();
}
}
Ответ: а) вставить void; б) заменить на currentTimeMillis(); в) привести к типу int
или заменить int на long; г) поймать InterruptedException или определить его в заголовке
метода.
7. Чего не хватает здесь?
public final class SomeClass implements Serializable {
public String someField;
}
8. Написать метод sort(List, boolean), который сортирует List, учитывая параметр
(вверх или вниз) и используя Comparator.
9. Сравнить время формирования длинной строки (size порядка 104–105) из отдельных символов с помощью String и StringBuffer. Объяснить результаты.
10. Есть сериализованный объект класса, о котором известно только имя. Нужно с
помощью reflection вывести полную информацию об объекте, т.е. все поля, в том числе и
private. Указать механизм, который запретит получать информацию о private полях.
Ответ (о том, как запретить): либо запуск с policy, либо или System.
setSecurityManager(new CheckPermitionSecurityManager());
10. Есть сериализованный объект класса, о котором известно только имя. Нужно с
помощью reflection вывести полную информацию об объекте, т.е. все поля, в том числе и
private. Указать механизм, который запретит получать информацию о private полях.
11. Нужен интерфейс TimedTask с единственным методом run() и класс Timer, который будет заниматься вызовом этого метода в заданный момент времени. У таймера
должны быть такие методы:
1. добавить новый TimedTask
2. изменить назначенное время для какого-то TimedTask'a
3. удалить (если этот TimedTask еще не успел выполниться)
4. проверить выполнялся ли этот TimedTask
Разумеется, все MultiThread и Thread-safe. Циклы вида while(!good){Thread.sleep(100);}
использовать запрещено – все должно быть реализоввано на synchronized блоках, мониторах (Object.wait(), Object.notify(), Object.notifyAll()) и Thread.sleep()/Thread.interrupt().
Архитектура: должен быть один поток, ждущий времени ближайшего TimedTask'а в
вызове Thread.sleep(); для выполнения TimedTask'а этот поток должен создать новый поток, в котором будет выполнен TimedTask. Ключевое отличие от стандартного
java.util.Timer состоит в пункте 2.
12. Хитрая синхронизация для HashMap. Стандартный HashMap синхронизации не
имеет, но есть Hashtable, который по сути от HashMap отличается только тем, что все его
методы synchronized. Таким образом, никакие два потока не могут одновременно даже читать из него. За основу своего класса надо взять HashMap. Всех, кто к нему обращается,
делим на 2 класса: readers и writers. Ридерам можно заходить в HashMap в любом количестве одновременно при условии отсутствия врайтеров. А writer может быть в HashMapе
тогда и только тогда, когда там больше никого нет.
Приложение: сравнить по производительности HashMap с приведенной идеей синхронизации и HashTable, который реализован с помощью обычных synchronized-секций.
13. Thread pool. Имеется N рабочих потоков (Thread) и класс ThreadPoolManager, который распределяет задачи между ними. Задача (Job) – это интерфейс с одним методом
public void doJob(). Необходимо реализовать следующую функциональность (можно не
всю):
1. При создании тредпула указывается количество потоков в нем.
2. При поступлении задачи, менеджер выбирает один из свободных потоков и передает
ему на выполнение эту задачу. Если свободных потоков нет, то задача ждет в очереди.
3. При работе тредпула можно изменить (увеличить или уменьшить) количество рабочих
потоков.
4. HealthMonitor: если время выполнения какой-либо задачи превысило таймаут, то поток
считается зависшим (hung). Менеджер пула должен иметь метод, возвращающий зависшие потоки. При этом если задача завершилась, поток более не считается зависшим.
5. Если какая-то задача ждет в очереди дольше заданного порога времени, то в пул может
добавиться новый поток, если количество потоков не превзошло максимума.
6. Величины таймаута (п.4), порога времени (п.5) и максимума рабочих потоков (п.5)
должны быть конфигурируемы.
14. Есть n клиентских и один серверный поток. У серверного потока есть одна операция (например, int sum(int x, int y)). Клиентские потоки хотят воспользоваться этой операцией. Операция обязательно должна производиться в серверном потоке. Серверный поток, ожидающий поступления операции, не должен попусту расходовать процессорное
время (т.е. не должно быть цикла вида while(!taskAvailable)Thread.sleep(100); ). Клиентский поток, ожидающий результата операции от серверного потока, также не должен расходовать процессорное время.
3 Лабораторные работы №1 по курсу «Язык программирования Java»
В данном разделе приведены не полные описания заданий (не включающие, в частности, ссылки и указания студентам по выполнению задачи).
3.1 Лабораторная работа 1.1. Сетевая модель
Краткое описание
Реализовать описанную ниже объектную модель сети или аналогичную ей. На базе этой
модели реализовать алгоритмы маршрутизации (routing) по различным критериям.
Детальное описание
Один из возможных вариантов модели представлен на UML диаграмме. Детализацию
классов предлагается разработать самостоятельно исходя из предметной области. Возможна другая реализация модели сети, если кому-то она покажется (аргументировано) более удачной.
Сама сеть состоит из набора PathElement'ов. Метод getConnections() возвращает ближайших соседей данного элемента, а методы getTimeDelay() и getCosts() затраты денег и времени на прохождение пакетом данного узла. Маршрутом называется упорядоченная по-
следовательность PathElement'ов начинающаяся с одного заданного элемента и заканчивающаяся на другом заданном элементе.
Задача состоит в том, чтобы в объекте класса Network находить маршруты между заданными узлами, т.е. должен быть реализован класс NetworkTest, который

хранит объект/объекты Network (hard code/подгружаемые с диска)

хранит список классов RouteProvider (hard code/динамически подгружаемые по Reflection)

по команде с консоли route network, provider, id1, id2 или route –ip network, provider, ip1, ip2 выводит один или несколько найденных маршрутов, где network –
название модели сети, provider – название провайдера для поиска маршрута, id –
уникальный id элемента сети, а ip – ip адрес одного из активных элементов сети.
Описание модели
Описание алгоритмов
На базе данной модели реализовать поиск маршрута между двумя произвольно заданными
элементами сети по следующим алгоритмам:

с наименьшей задержкой по времени

с наименьшей стоимостью

с наименьшим числом промежуточных узлов

…
Требования
Звездочками * отмечены обязательные требования, в скобках – количество баллов (может
быть уменьшено, если требование реализовано не полностью, с ошибками, с замечаниями
и т.п.).
1. детальное UML представление модели вашей программы (6)
2. реализация модели, классы должны переопределять методы интерфейса PathElement,
учитывая особенности конкретного устройства, например, Firewall может пропускать
пакеты далеко не по всем физически доступным соединениям, это задается отдельно
в его конфигурации и т.д. (5) *
3. реализация любого алгоритма поиска пути (5) *
4. графическое представление используемых моделей сетей, любая картинка, чтобы проверяющему было легче понять вашу тестовую модель (2) *
5. сохранение загрузка через Serialization API (3)
6. сохранение загрузка через XML (4)
7. реализация дополнительных алгоритмов поиска пути (5)
8. реализация поиска пути в виде plug-in'ов, подгружаемых по reflection (3)
9. вывод всех элементов пути/только активных (3)
10. архитектура всего приложения, code style, java doc и прочие вещи на усмотрение куратора (6)
Модификации задания
На усмотрение куратора можно менять модель в данной задаче, желательно придерживаться следующей логики, что модель должна представляться графом, а работа с моделью
реализацией одного из возможных алгоритмов на графах. Возможно более детальная проработка предложенной модели. Например, Firewall метод getConnections() должен быть
переопределен и учитывать не только физические соединения, но и таблицу допустимых
маршрутов. И т.д.
Итого за задачу: 42 балла
3.2 Лабораторная работа 1.2. Система регистрации сообщений
Один из возможных вариантов данной модели (модели регистрации сообщений, но
не модели реализации) представлен на рисунке.
LogManager – объект управляющий системой логов, должен быть единственным в пределах вашего приложения.
Logger – объект представляющий конкретный регистратор, который обрабатывает поступившее сообщение и решает регистрировать его или нет. Может иметь древовидную
структуру. По умолчанию сообщение должно регистрироваться во всех нижележащих
Logger’ах.
Filter – объект задающий политику фильтрации сообщений для Logger’а.
Handler – объект производящий физическую регистрацию сообщения в файле, базе данных, на удаленном сервере.
Требования
Звездочками * отмечены обязательные требования, в скобках – количество баллов (может
быть уменьшено, если требование реализовано не полностью, с ошибками, с замечаниями
и т.п.).
1. создание классов (ООП модели) Logging системы (2) *
2. UML представление модели Logging системы (5)
3. поддержка различных типов сообщений: пользовательские сообщения, exceptions и
т.д. (3) *
4. поддержка уровня серьезности сообщений от Info до Severe (3)
5. некоторые Handler’ы могут поддерживать форматирование сообщений (3)
6. поддержка конфигурирования системы логов через настоечный файл (+4 балла за
XML)

использование заранее известных классов, статическая инициализация
LogManager’а (6) *

динамическая загрузка определенных классов, реализующий общий интерфейс (reflection) (+3 балла)
7. поддержка различных Handler’ов (2 балла за каждый пункт – итого максимум 8
баллов):

файл *

электронная почта (сообщение об ошибке уходит по почте)

html страница *

любые другие
8. архитектура всего приложения, code style, java doc и прочие вещи на усмотрение
куратора (6)
Итого за задачу: 43 балла
3.3 Лабораторная работа 1.3. Информационная (справочная) система
Краткое описание
В данной задаче рассматривается структура данных, описывающая некую реальную
систему, объект или процесс. На основе заданной структуры данных реализовать справочную систему, отвечающую за манипулирование данными.
Детальное описание
Данные разделены на два (или более) типа, связанные между собой. Обработка каждого типа данных осуществляется в отдельном классе (Model class). После обработки информация сохраняется на диск в определенном формате. Каждый класс должен уметь создавать, удалять и модифицировать свой тип данных, при этом корректно взаимодействуя
с классом, занимающимся обработкой зависимых типов. Управление справочной системой осуществляется из консоли с помощью набора команд, которые обрабатываются специальным классом-контроллером (Controller class), а он в свою очередь обращается к
классам, работающими с данными, для осуществления конкретной операции с данными.
Вывод запрашиваемой информации на экран осуществляется отдельным классом (View
class), который получает данные от Model классов. Реализация конкретной справочной
системы производится по шаблону MVC(Model-View-Controller).
Требования
(* помечены обязательные требования)
11. Реализация Справочной системы должны соответствовать шаблону MVC.*(5)
12. Интуитивно понятный интерфейс работы с пользователем.*(4)
13. Наличие функций 1) добавления, 2) удаления, 3) изменения и 4) просмотра данных.* (за
каждую функцию по 2 балла)
14. Реализация поиска данных в соответствии с некоторым шаблоном, введенным пользователем. Шаблон включает в себя все разрешенные символы с точки зрения хранимых
данных и символы заменяющие один и несколько любых символов (* и ?).(4)
15. сохранение загрузка данных через Serialization/XML.*(3 за Serialization, 4 за XML, +2
за использование сжатия данных)
16. Возможность добавления всех данных из другого файла в текущий с проверкой на
наличие дубликатов, т.е. не должно быть абсолютно одинаковых данных.(4)
17. программный код должен удовлетворять Code Conventions(4) * и снабжен JavaDoc (2).
Модификации задания
1. Группы и студенты: Студент (ФИО, группа, дата зачисления), Группа (Номер, Факультет).
2. Библиотека: Экземпляр книги (инвентарный номер, книга, выдана или нет), Книга (авторы, название, год издания, число страниц).
3. Отдел кадров: Сотрудник (ФИО, отдел, телефон, зарплата), Отдел (название, начальник).
4. Отдел поставок: Сырье (название, поставщик, цена), Поставщик (название, расчетный
счет, ФИО контактного лица).
5. Отдел продаж: Заказ (номер, заказчик, дата, сумма заказа), Заказчик (название, телефон, адрес).
6. Ресторан: Блюдо (название, категория, цена), Категория блюд (название).
7. Анализ публикаций: Публикация (название, тип, источник, дата), Источник (название,
город, телефон).
8. Авиарейсы: Рейс (Номер рейса, аэробус, маршрут, время вылета, путевое время),
Маршрут (Пункт вылета, пункт прибытия).
9. Расписание электричек: Электропоезд (Номер состава, маршрут, время отправления,
путевое время), Маршрут (Начальная станция, конечная станция).
10. Собственный вариант, согласованный с куратором.
Итого за задачу: 40 баллов
3.4 Лабораторная работа 1.4. Планировщик задач
Краткое описание
Написать программу, которая выполняет основные функции планировщика задач. Взаимодействие с пользователем осуществляется через консоль, либо через простенький графический интерфейс (если студент знает, как такой интерфейс реализуется).
Детальное описание
Планировщик задач состоит из журнала задач, пользовательского интерфейса для добавления и удаления задачи, а также системы оповещения пользователя о каком-то событии,
т.е. в назаначенное в планировщике время должно происходить нечто, говорящее пользователю о том, что у него запланирована некоторая задача (см. ниже).
Журнал задач должен храниться на диске и загружаться при запуске программы, а также
сохраняться при выходе. Формат файла может быть произвольный, по желанию можно
использовать XML.
В качестве пользовательского интерфейса может выступать консоль или графический интерфейс. Определенными командами пользователь может удалять запланированные задачи, добавлять новые с указанием необходимых параметров (см. пункт ниже).
Система оповещения может иметь различную функциональность. В качестве базовой
предлагается следующая система. В назначенное в планировщике время на экране должно
появляться окошко, в котором сообщается название задачи и ее описание (можно также
добавить пару кнопочек: «отложить задачу» и «завершить задачу»). По согласованию с
куратором можно использовать и другую систему оповещения.
Параметры планируемой задачи:
- название
- описание
- время (дата) оповещения
- контакты
Реализация планировщика должна быть выполнена по следующим принципам. Функционал, реализующий работу с журналом задач, пользовательским интерфейсом и системой
оповещения а также сам журнал задач, должен находиться в различных классах. Т.е. пользовательский интерфейс в отдельном классе, работа с журналом задач в отдельном, сам
журнал тоже в отдельном и система оповещения в отдельном. Эти классы могут общаться
между собой через интерфейсы, но при этом ни один из них не должен реализовывать логику другого.
Требования
(* помечены обязательные требования)
1. Реализация Планировщика задач должна соответствовать указанным выше принципам.*(6)
2. Интуитивно понятный интерфейс работы с пользователем.*(4)
3. Наличие функций добавления и удаления задач с сохранением их в общий журнал задач на диск.*(4, +4 за использование формата XML)
4. Система оповещения пользователя.* (3, +3 за использование Swing, +2 за доп. функциональность с «завершить» или «отложить» задачу)
5. Возможность программы сворачиваться в системный трей (с использованием
systray4j). (4)
6. Программный код должен удовлетворять Code Conventions(4) и снабжен JavaDoc (2).
Модификации задания
1. Использование различных систем оповещения (базовая, звуковой сигнал + вывод в
консоль, запуск другой программы, написанной на Java).
2. Графический/текстовый интерфейс.
3. Формат хранения журнала задач на диске: текстовый файл, сериализованные объекты,
XML, сжатый текстовый файл (zip).
Итого за задачу: 36 баллов
4 Лабораторные работы №2 по курсу «Язык программирования
Java»
4.1 Лабораторная работа 2.1. Instant Messenger
Краткое описание
Создать клиент-серверное приложение для обмена сообщениями в реальном времени.
Детальное описание
Клиентская часть должна быть реализована в графическом варианте. После запуска
клиент пытается установить соединение с сервером, получает список всех доступных для
общения пользователей, которым может отправлять/получать сообщения. Необходимо
оповещать клиента об изменение в доступном списке контактов.
Серверная часть может быть выполнена в как графическом варианте, так и в консольном.
Протокол общения между клиентом и сервером и, возможно, сервером и сервером
предлагается разработать самостоятельно. Рекомендуется для этих целей использовать
XML.
Требования
Звездочками * отмечены обязательные требования, в скобках – количество баллов
(может быть уменьшено, если требование реализовано не полностью, с ошибками, с замечаниями и т.п.).
Клиент
1. графическая реализация пользовательского интерфейса (внешний вид на ваше
усмотрение), требования по дизайну минимальные (6) *
2. дополнительные возможности UI (на усмотрение куратора, за основу можно
брать любые популярные im) (3)
3. поддержка режимов диалога с конкретным пользователем (2) *, группой (2) и
чата (2)
4. сохранение настроек клиента в реестре (с использованием JNI) (7)
5. поддержка динамически подгружаемых по Reflection plug-in'ов (4)
6. реализация клиента на J2ME (20)
Сервер
7. передача сообщений между клиентами (3) *
8. поддержка авторизации (3) *
9. поддержка безопасного соединения с помощью JCA/JCE (8)
10. ведение логов/истории сообщений и т.д. (2)
11. модерирование, фильтры (5)
12. поддержка настоек с использованием графического интерфейса и/или конфигурационного файла (список запрещенных пользователей, номер ожидающего
подключения порта, ведение логов (да/нет) и т.д.), рекомендуется для хранения использовать XML (5)
13. организация пула, потоков, для обслуживания клиентов, т.е. когда новый клиент подсоединяется к серверу, для его обслуживания поток создается не с нуля, а берется из пула, где находятся уже заранее проинициализированные потоки, готовые к обслуживанию (4)
Поддержка нескольких серверов (для клиентов это должно быть абсолютно прозрачно, т.е. клиентское приложение ничего не должно знать о структуре сервера):
14. поддержка кластерной конфигурации, т.е. каждый сервер при запуске пытается установить соединения с соседними серверами, которые указываются в
конфигурационном файле (8)
15. баланс нагрузки, на каждом сервере должно быть приблизительно равное
число клиентов (12)
16. в случае выхода из строя одного сервера, клиенты должны распределиться
между оставшимися серверами, возможны два варианта работы серверов или
как равноправные ноды (12) или с менеджером кластера (10)
Общие требования:
17. внутренний протокол клиент/сервер: архитектура, документация (7) *
18. внутренний протокол сервер/сервер: архитектура, документация (4)
19. архитектура, code style, java doc и прочие вещи на усмотрение куратора (6)
4.2 Лабораторная работа 2.5. Task Tracker
Краткое описание
Создать приложение типа «органайзер» для отслеживания занятости человека различными задачами (сколько времени он занимается каждой из них). Реализовать оповещение некоего сервера об изменениях занятости, а также возможность сохранения (и загрузки) информации о занятости в постоянной памяти (на клиенте и/или на сервере).
Детальное описание
Каждая из задач, время занятости которыми необходимо отслеживать, – это, прежде
всего, название (строка текста). Однако задача должна также иметь невидимый пользователю идентификатор, чтобы при переименовании задачи прежняя информация о занятости
оставалась актуальной. Задачи образуют иерархию (дерево), точнее, несколько иерархий
со своим «корнем» каждая. При этом заниматься человеку можно не только задачами«листьями» дерева, но и любыми другими («родительскими») узлами. Время занятости
родительской задачей определяется как сумма ее собственного времени и времен всех ее
подзадач. Подразумевается, что в каждый момент времени человек занимается ровно одной задачей.
В качестве запоминаемой информации о занятости можно фиксировать либо все
факты переключений между задачами, либо время занятости человека задачей в течение
одного дня. Как бы то ни было, выбранная модель хранения занятости должна позволять
показывать статистику занятости по задачам (верхнего уровня), а также статистику по
подзадачам для любой выбранной задачи. Статистика представляет собой таблицу со
столбцами «Название задачи», «Дата», «Время занятости», «Процент занятости» (процент
берется от суммы времен задач, имеющихся в таблице на соответствующую дату). Среди
строк таблицы должны встречаться не только подзадачи, которые на один уровень ниже
выбранной задачи, но и она сама (в случае, если ей тоже сопоставлено «собственное» время: см. выше).
Одной из задач верхнего уровня является «Не работа»; при первом запуске программы это – единственная задача. «Не работу» нельзя удалить, но в остальном это задача такая же, как остальные (в частности, для нее можно сделать подзадачи «Отдых», «Обед»,
«Перекур» и т.п.). Все время, когда программа не запущена, следует считать временем «не
работы». Программа должна «помечать» это время таким образом при следующем запуске. В случае, если в выбранной модификации программы запоминаются непосредственно времена занятости задачами в течение дня (см. выше), то не следует создавать записи для всех дней, в которых программа
не запускалась (или запускалась, но пользователь не переключался с «Не работы»).
Клиентская часть программы должна быть снабжена графическим интерфейсом. После запуска клиент загружает иерархию задач (из файла либо с сервера); после чего одна
из задач выделяется как активная (на основе загруженных данных). Серверная часть программы не является графической и имеет набор функций, сильно зависящий от модификации задачи (см. ниже). Клиент подключается к серверу либо по запросу пользователя, либо при запуске. Клиент может сохранять информацию о занятости либо при выходе, либо при каждом переключении
между задачами. Когда реализуется возможность редактирования иерархии задач пользователем, измененная иерархия должна сохраняться (как единое целое) при выходе из программы и/или по запросу пользователя; либо вместо этого можно оповещать сервер непосредственно при выполнении операций создания, удаления и переименования задач.
Сохранение клиентом чего-либо (информации о занятости или иерархии задач) может означать либо сохранение в файле (текстовый файл, XML, сериализация и т.д.), либо
передача соответствующих данных на сервер (для дальнейшего сохранения там). Протокол общения между клиентом и сервером предлагается разработать самостоятельно; рекомендуется при этом использовать XML. Сервер может сохранять информацию в том же виде, что
и клиент; делать это он может как при обработки запроса от клиента, так и при завершении работы (например, при финализации).
Идентификатор пользователя при его общении с сервером задается в
настройках программы (там же, где параметры сетевого соединения с сервером); если он
не задан, то в качестве идентификатора можно использовать ip-адрес клиентского компьютера.
Требования
Звездочками * отмечены обязательные требования, в скобках – количество баллов
(может быть уменьшено, если требование реализовано не полностью, с ошибками, с замечаниями и т.п.).
1. Реализация на Swing основного внешнего вида клиента с обработкой событий (главная часть окна – дерево задач; действия можно реализовать пунктами меню или
кнопками); загрузка иерархии задач, сохранение/загрузка занятости (5; в случае
обобщения занятости – см. модификацию 1.2 – 6) *
2. Редактирование иерархии задач, ее сохранение. (5)
3. Выдача стандартного отчета статистики занятости (описанной выше таблицы, для
заданного интервала дат) + сортировка по заданному пользователем столбцу (6+1; в
случае хранения обобщенной занятости – см. модификацию 1.2 – 4+1)
4. Дополнительные аналитические функции типа «показывать статистику по месяцам,
осредняя времена занятости задачами в день», «показывать статистику для всех задач, выполнявшихся в заданный день, независимо от их места в иерархии», «показы-
вать постоянно такую статистику на сегодня, автоматически изменяя с течением
времени данные в строке активной задачи» (на усмотрение куратора – до 5)
5. Реализация сервера, поддерживающего несколько соединений с клиентами (5) *
6. Взаимодействия клиента с сервером (не менее одного взаимодействия); возможны не
только указанные в описании взаимодействия типа «загрузка задач с сервера», «оповещение о переключении задачи», но и такие: «уведомление сервера при изменении
имени пользователя», «синхронизация времени с сервером» (4) *
7. Синхронизация иерархии задач в разных клиентах: оповещение сервером всех клиентов при изменении задач одним из клиентов (3)
8. Поддержка более чем одного принципиально отличающегося формата хранения данных или протокола передачи данных (текст с разделителями(3), XML(4), сериализация(3), …) (всего не более 6)
9. Протокол клиент/сервер: архитектура, документация (если XML, то DTD) (4) *
10. Архитектура, code style, java doc и прочее «представление» программы (на усмотрение куратора – до 6)
Примечание: Функции сервера отдельно не оцениваются, так как они являются аналогами функций клиента, перенесенными на сервер (только для многих пользователей);
соответствующее взаимодействие между клиентом и сервером – это пп. 6 и 7.
Итого: баллов за обязательные требования – около 25, баллов за дополнительные
требования – порядка 55.
4.3 Модификации задания
Модификации задания отличаются друг от друга по нескольким критериям; так что
каждая из модификаций представляет собой некоторую комбинацию из нижеследующих
пунктов. Здесь звездочками * обозначено то, что является модификациями обязательных
требований (остальное относится к дополнительным требованиям).
1 Различие по содержанию хранимой информации о занятости *:
1.1 отдельные временные интервалы занятости задачей (между переключениями задач)
1.2 время занятости задачей в течение дня
2 Различие по формату хранения/передачи информации. Здесь сразу 3 критерия – для
хранения иерархии, для хранения занятости, для передачи информации (иерархии + занятости + другое) *:
2.1 текст (с разделителями) типа «список» или «таблица» (в случае структурно сложной
информации, структура элементов текста линейная – «таблица»)
2.2 текст (с разделителями) типа «дерево» (только для иерархической информации,
строка текста содержит явное указание на ее уровень в иерархии)
2.3 XML-совместимый формат
2.4 сериализованные объекты
2.5 собственный бинарный формат (при побайтовом чтении могут использоваться байты-разделители, хотя для хранения чисел, дат и т.п. разделители не нужны)
3 Различие по размещению (клиент или сервер) следующих функций:
3.1 загрузка иерархии задач (из файла) *
3.2 сохранение/загрузка занятости (в файле) *
3.3 обобщение информации о занятости (в случае, если эта информация хранится в
обобщенном по дням виде; в противном случае информация обобщается лишь при генерации отчета)
3.4 сохранение иерархии задач (в случае, если она редактируемая); выбор = выбор по
п. 3.1
3.5 генерация отчета (статистики)
4 Различие по времени выполнения операций (при запуске, по запросу пользователя,
при выполнении другой операции, при выходе). К операциям относятся:
4.1 соединение клиента с сервером, – возможно, сопровождающееся загрузкой задачи
и/или занятости с него (при запуске или по запросу) *
4.2 сохранение занятости (при переключениях между задачами или по запросу или при
выходе) *
4.3 сохранение иерархии задач (при операциях редактирования задач или по запросу
или при выходе)
Примечание к критерию 4. Загрузка чего-либо на клиенте происходит либо сразу после соединения с сервером (если загружать надо с сервера), либо при запуске (если из
файла). Загрузка чего-либо на сервере происходит при его запуске.
4.4 Лабораторная работа 2.6. Port Mapper
Краткое описание
Создать программу для перенаправления входящих (по какому-либо порту) соединений на другой компьютер.
Мотивация
Необходимо обеспечить доступ извне к HTTP-серверу, работающему на компьютере
с виртуальным IP-адресом. С помощью Port Mapper-а можно организовать такой доступ с
любого компьютера, на котором установлена Java-машина.
Детальное описание
Требуется написать серверное приложение (консольное приложение, не реагирующее на нажатие клавиш). Также можно написать «консоль администратора»: при подключении telnet-ом на определенный порт, можно осуществлять управление приложением.
Для совсем продвинутых студентов – написать клиента.
Должен быть главный класс SocketTransmitter, который слушает какой-то порт, который указывается при создании экземпляра этого класса (см. диаграмму на следующей
странице). При поступлении входящего соединения (3) он открывает новое исходящее соединение (4) на порт другого компьютера (назовем его сервером; порт и IP-адрес сервера
указываются в конструкторе класса SocketTransmitter) и запускает два потока, передающие данные в обе стороны (6-11). Запросы клиента (12) принимает один из потоков и перенаправляет их на сервер (13). Второй поток передает данные в другую сторону: от сервера к клиенту (14, 15).
Запуск SocketTransmitte-’а не должен захватывать управление программой (он должен выполняться в отдельном потоке). Обязательно наличие функции, которая корректно
завершает работу SocketTransmitte-’а. Все функции должны быть в обязательном порядке
синхронизованы. Никаких race condition или deadlock-ов не должно быть.
Требования
Звездочками * отмечены обязательные требования, в скобках – количество баллов
(может быть уменьшено, если требование реализовано не полностью, с ошибками, с замечаниями и т.п.).
1. Поддержка неограниченного числа одновременных подключений. (3) *
2. Грамотная синхронизация. Никаких race condition или deadlock-ов. (3) *
3. Если никакие данные не передаются, приложение не должно загружать процессор. (2) *
4. Ведение логов. Все ошибки должны грамотно складываться в лог. (2) *
5. Сохранение/загрузка настроек в файле (xml-формат/properties-файл/сериализация). (4)
6. Фильтры IP-адресов, квоты на трафик, статистика трафика. (2+3+3)
7. Пул потоков. При каждом новом соединении не создается новый поток, а используется один из пула, при наличии там свободных потоков. (6)
8. Администраторская консоль (через telnet); возможности:

Создание новых SocketTransmitter-ов

Удаление существующих

Список работающих

Помощь

Остановка сервера

Грамотная синхронизация. Никаких race condition или deadlock-’ов.

Аутентификация
(7+)
Следующие пункты имеют смысл только при наличии администраторской консоли.
9. Графический клиент к администраторской консоли (5).
10. Health-монитор. Следит за состоянием потоков, при запросе из администраторской
консоли выдает состояния всех потоков (OK/Probably hung) (5).
11. Documentation (Javadoc), Code style и прочее. (6)
4.5 Лабораторная работа 2.7. Игровой сервер
Краткое описание
Реализовать клиентское и серверное приложения: «игровой сервер». Предлагается
создать программу, которая предоставит возможность двум (или более) пользователям
играть друг с другом по сети.
Детальное описание
Сервер содержит список игроков - тех, кто сейчас подключен к серверу. Игроки делятся на две группы: «играющие» и «свободные». Группа «Играющие» состоит из игроков, которые участвуют в какой-либо партии. Соответственно в группе «свободные» - игроки, которые сейчас не участвуют ни в одной партии. При подключении к серверу игрок
попадает в группу «свободные». Игрок переходит в группу «играющие» когда он присо-
единяется к уже существующей партии или начинает новую. Соответственно, когда «партия» заканчивается, игрок возвращается в группу «свободные».
Под термином «партия» подразумевается один сеанс связи между игроками (через
сервер), в процессе которого они обмениваются информацией о сделанном ходе и текущем
состоянии. Есть несколько вариантов контролирования этого процесса (обмена данными):

сервер самостоятельно контролирует соблюдение правил, вычисляет новые состояния
для всех игроков и рассылает эту информацию всем участникам; контроль завершения
партии осуществляется сервером;

клиенты самостоятельно контролируют правильность хода; при возникновении конца
партии (например, мата в шахматах) один или несколько клиентов уведомляют об
этом сервер;

клиенты только реализуют отображение и пересылку информации; при возникновении
конца партии один из игроков сообщает об этом серверу, после чего сервер спрашивает согласия остальных игроков на завершение партии (при этом запрашиваются информация о том, кто проиграл, а кто выиграл). Предполагается, что игроки честные, и
реализовывать проверки в программе не надо.
Сервер хранит некоторые данные об игроках: имя, пароль, ранг и др. Для вычисле-
ния ранга можно использовать, например, следующий алгоритм: каждому новому игроку
дается определенное количество очков. Пусть k – коэффициент «значимости» партии (k
<< 1). При окончании партии сервер выполняет следующие изменения количества очков:
если ничья, то каждому игроку прибавляется количество очков оппонента, умноженное на
k/2. Иначе выигравшему начисляется количество очков проигравшего, умноженное на k.
Требования
Звездочками * отмечены обязательные требования, в скобках – количество баллов
(может быть уменьшено, если требование реализовано не полностью, с ошибками, с замечаниями и т.п.).
1. При подключению к серверу клиент получает список игроков из группы «свободные», после чего он может выбрать, с кем он бы хотел сыграть. Выбранному сопернику посылается запрос, согласен ли он сыграть с таким-то игроком и в случае
получения утвердительного ответа начинается партия. (5) *
2. Завершение партии должен контролироваться программой (либо клиентом, либо
сервером). (4) *
3. При долгом бездействии игрока в партии, ему выводится предупреждение «idling».
Если он не проявит активности, то соединение с ним закрывается. (3)
4. Использование XML для обмена данными между сервером и клиентом. (4)
5. Для каждого игрока сервер должен вести статистику: количество выигранных и
проигранных партий, сколько всего времени провел на сервере, ранг (очки). (2)
6. При подключении к серверу клиент получает список всех игроков. При выборе в
качестве соперника игрока из группы «играющие» сервер должен выполнить действия, описанные в пункте 1 после того, как выбранный игрок закончит текущую
партию. То есть сервер поддерживает «ожидание игрока»: клиент выбирает игрока,
который уже с кем-то играет, чтобы сыграть с ним, когда он освободится (сервер
автоматически сообщает, что выбранный игрок закончил свою партию). (4)
7. Возможность банить игроков/ip адреса. (3)
8. Возможность восстановления игровой позиции в случае разрыва связи с одним
клиентом. То есть при обрыве соединения клиенту дается возможность подключиться к серверу в течении некоторого времени (например, 2 минут) и если он подключится – партия должна продолжиться. (5)
9. Сохранение пользовательских настроек на сервере. (3) *
10. Ограничение времени, данного игроку на раздумывание (на партию 30 минут каждому игроку) – то есть в сумме игрок не может размышлять над своим ходом более
какого либо времени. (4)
11. Поддержка «чемпионатов». (6)
12. Возможность сохранения партии в файл. (3)
13. Изменение Look-and-Feel на клиенте. (2)
14. Организовать ведение логов на сервере. (2) *
Модификации задания
В качестве модификаций задания предлагается реализовать различные игры (баллы
также зависят от реализованной игры). В зависимости от сложности реализации контроля
соблюдения правил за различные игры начисляется различное количество баллов. Cложные игры (шахматы, нарды, домино), где для написания клиента может потребоваться
много времени, рекомендуются задавать только студентам из групп углубленного изучения Java.
Игры:
1. Шашки.

Поле: 8x8.

Правила игры, контролируемые программой: окончание партии; если есть
возможность, игрок должен «брать» максимальное количество фишек
противника.

Реализация: Java2D; JTable+JLables; Console

Ресурсы: http://www.shashki.com/
2. Шахматы.

Поле: 8x8.

Правила игры, контролируемые программой: окончание партии; ситуация
«шах»; ситуация «пат».

Реализация: Java2D; JTable+JLables; Console

Ресурсы: http://www.sportzone.ru/sport/rules.html?sport=chess&chapter=02
3. «Точки» («ГО»).

Поле: размер поля на усмотрение студента.

Правила игры, контролируемые программой: окончание партии; «окружение» точек противника

Реализация: Java2D

Ресурсы: http://www.tochki-club.narod.ru/; http://forum.kido.com.ru/
4. Морской Бой.

Поле: 10x10

Правила игры, контролируемые программой: окончание партии;

Реализация: Java2D или JTable+JLables
5. Нарды.

Правила игры, контролируемые программой: окончание партии; корректность хода;

Реализация: Java2D

Ресурсы: http://amis.h11.ru/nardprav.htm
6. Домино.

Правила игры, контролируемые программой: окончание партии; правильность хода

Реализация: Java2D

Ресурсы: http://www.orgdosug.ru/pubcatalog.php?cid=83
7. «Быки И Коровы»

Правила игры, контролируемые программой: окончание партии;

Реализация: Swing; Console

Ресурсы: http://www.wowwi.orc.ru/games/bulls/help-ru.htm