Здравствуйте, уважаемые.

Не стал раздувать предыдущий созданный топик, там о том как начать проект, а тут по конкретному проекту.

Всем наверно уже известно, что я делаю робкие попытки сделать тестовую систему.
Встали пара вопросов.
1. Использовать в своей системе JUnit, который есть не только на Java, но и на других языках. 1 вопрос, хочется проконсультироваться может ли JUnit манипулировать временем и объемом выделяемой памяти процессу. Или нет смысла? Лучше делать по программе на тест.

2. Конвертируемость тестовых данных. Т.е. думается сделать удобную ГАИшку, в которой тыкая можно выбирать число входных параметров, их тип, а затем набор данных по ним и эталонный результат, нуу, может + еще погрешность. В результате получается xml на основе которого получаем 4 тестирующих программы (на Java, C++, C#, VB) Проблема встала с массивами, как в xml описать массив, чтоб по записи можно было понять что это массив такого-то типа такой-то размерности и с такими-то данными.

Также атрибутом можно указать и то, что тэг содержит массив. В примере powerOn я бы сделал так (если надо именно указать, что "это - массив"):

А размерность массива как делать? что-то типа


?

 Что имеется ввиду?
JUnit тесты - это те-же java классы просто подчиняющиеся определеным правилам. Т.е. если есть возможность в принципе манипулировать временем и объемом выделяемой памяти процессу, то это не составит труда реализовать в тесте. 

Так, вернемся к нашим баранам ^_^
Запустил я эту тему, так и не начав...

В общем, у меня разработана кое какая модель по генерации шаблонных тестеров. Возник вопрос по velocity... я видимо слабоват в этом направлении.
У меня получилось следующее:
Описание классов и тестовых решений в xml

единственное, что тут может быть непонятно - это num, определяет очередность аргументов в методе

case-num - номер тестового семпла
num - номер аргумента
answer - ответ

Теперь по коду (обращайте внимание в основном на velocity и на обслуживающие классы (ClassData, MethodArgument, ArrayMethodArgument)):
Код шаблона:

Обслуживающие классы:


Информер пишет:

проверил на вывод $classData - работает, $classData.args - не работает
Подумал нужны getter/setter методы, сделал, но пишет исключение:

Черт ногу сломит, у меня в [1,22] только объявления макрокоманд, в чем может быть подвох?

И еще доп вопрос, может я глупо сделал и решения не нашел правильного, сделал свой вариант синхронного вывода. Как не странно это звучит ^_^ люди мучаются с асинхронным, а я с синхронным, в общем я решил, что нече клиенту в разнобой слать запросы пусть шлет их последовательно в основном потоке (специфика такая)
Фича очень похожая на RMI

Примерчик:

Клиентская реализация

Сервернная реализация:

Якобы, таким образом я хочу создать ощущение при программировании, что программируется все на одной локальной машине.

А, да, самое главное, вот класс, который ожидает приема объекта, и сразу будет поток


Оцените, и покритикуйте.

Platon, 
нужны геттер/сеттеры, потому что Velocity их использует. Верни их обратно 


Это ж обычный ArrayIndexOutOfBoundsException. Вот в этом куске кода:

У тебя $d от 1 до размера вектора, а нужно от 0 до РАЗМЕР_ВЕКТОРА-1

Поясню некоторые моменты:
мы выполняем простую процедуру авторицации/аутентификации (точно не уверен,  что тут правильно)
Клиент пишет в сокет сервера запрос, и ставит себя в ожидание
Сервер принимает этот запрос и направляет его в своем реализованном интерфейсе AuthBridge, и сразу же отсылает ответ.
Клиентская реализация получает ответ, пробуждает поток и продолжает победное шествие.

Kangaroo, ууух, не успел запостить следующее сообщение, уже ответил! А я сижу жду ответа.


А как насчет того что не в ту строку указывает?

Это фишка Velocity - ошибки не там показывать ))..  у меня пока не доходили руки, чтобы разобраться. Сам сталкиваюсь с этим.

Да ^_^ мне реально помогло , но мне не понравилось, что выход такой некозистый получился.
Пришлось написать всё в 1 строчку... чтоб было так как я хочу.

читать такое тяжеловато.

Еще бы хотел спросить по поводу внутреннего устройства системы.
Я вижу внутренности системы так, распределенная на несколько компов.
1. Сервер, с ним идет основное общение клиентов.
2. Тестер, их несколько, коннектятся к серверу и ждут, когда он скажет им проверить ту или иную задачу.
3. Файловый сервер условий задач, тут хранятся все файлы задач.
4. Файловый сервер решенных пользователями задач.
5. База данных

насчет 3-4 я думаю, может объеденить?
А также возникают вопросы как лкчше всего эти пункты наладить между собой.
Я прикинул так, что сервер, при запросе условия задачи,  может перенаправить пользователя на файловый сервер и скачать задачу прямо с него, тогда возникает проблема тоог, что файловый сервер должен быть не просто ФС, но также минимально фильтровать тех, кто к нему коннектиться, нельзя выдавать задания раньше, чем назначено соревнование.
Сервер при взаимодействии с клиентом, формирует на Файл сервере решенных задач отправленные пользователем задачи.
При запросе от сервера к тестеру проверить определенную задачу, тестер скачивает с этого файл сервера необходимую задачу.

В итоге, получается хоть локальное взаимодействие, но внутренний трафик мыслится гигантским.
Тут очередной каскад вопросов связанных с кешированием данных. Целесообразно ли на тестере кешировать к примеру 10 последних решенных задач, если очень высока вероятность их повторного (2-кратного, 3х, 4х, 50х) запроса. Или это не так существенно и только нагрузит систему?

Что тут может не понравиться? Жду критики.

Добавлено через 1 минуту
Насчет этого поста кто, что может сказать?

Пришел к тому, что это лишняя морока разделять основной сервер от набора задач и набора решенных заданий, получается все эти 3 компонента будут в 1-й серверной программе.

Причина по которой я не смог разделить эти компоненты: 
Рассмотрим предполагаемый алгоритм, если клиент выбирает задачу, конектясь к серверу списка задач а не к главному серверу:
-- коннект к серверу списка задач(ССЗ), запрос конкретной задачи
  -- ССЗ коннектится к главному серверу (ГС), чтобы спросить можно ли выдавать задачу клиенту. (вот тут то и загвоздка)

Если сервер интегрирован, т.е. все 3 компонента в 1-й серверной программе, то проверку доступности организовать не составит труда, иначе получается, что каждый раз придется дергать БД, чтоб установить подключаемую личность, это видится мне как накладный расход.

Думал о всяких фишках типа временной подписи. Последовательного запроса клиент-ГС (запрос на получение задачи), ГС-ССЗ (приказ выдать пользователю задачу), ССЗ-клиент(коннект(!)* к клиенту и впрыскивание данных) *по безопасности такой вариант не проходит.
Думал о К->ГС, ГС->ССЗ, К->ССЗ, но тут велика вероятность конфликта синхронизации, да и тоже много темных пятен...

Слишком много вопросов и мало ответов :(

Может мне посмотреть в сторону кластеров (группы серверов)?
По вики, выглядит очень заманчиво  необходимо только реализовать или использовать готовый кластерный менеджер.
Что можете посоветовать по этому поводу? Есть готовые менеджеры? Может это уже удел J2EE? хотя хотелось бы без него обойтись 

На самом деле кластеризация это то, что надо.
Получается, теперь можно строить такую схему


                    
К-клиент
КМ - кластерный менеджер, к конотому первоначально коннектятся клиенты
КС-Кластерный сервер
ССЗ - сервер списка задач
ТС - получается новый компонент, тестовый диспетчер.
Т -тестовый работник, коннектится к ТС, с целью получения работы (запуска задачи пользователя)

Это сообщение отредактировал(а) Platon - 15.12.2007, 09:34

Не просёк, это система предназначенная для тестирования людей или ПО. Если ПО, к чему относится аля topcoder, если людей то при чём тут JUnit.
Видимо всё таки речь идёт о ПО? Просто уточнить.
Поскольку тема топика, в основном касается архитектуры будущей системы, давайте начнем с описания use cases, а то из-за деревьев леса не видно   

JUnit я просто подумал в качестве тестера, но вскоре понял что он тут не при чем...

ivg, на самом деле было бы клёво, если бы вы помогли мне научиться писать Use Case, Sequence и Classes Diagrams.

Кстати, я совсем туплю, система кодеров вот она: topcoder.com если кому интересно зайдите и посмотрите, что я имею ввиду под системой тестирования. На самом деле это соревнования по спортивному программированию.

Знаете, безвылазно 2-й день парюсь над писанием кода. попробовал сначала закодить сходу, не получилось, потом 2-й раз попробовал, подумал о кластеризации, переделываю 3-й раз.

Да, в этом деле без проектировки ну никак не обойтись ^_^

В каком формате эти диаграммы писать будем? Картинками или с помощью единой программы?

Да при подходе к кластерной задаче выяснилось, что кластерным серверам так или иначе придется общаться между собой(?) если к примеру это чат. Опять усложнение системы :(

Я тут накидал фигульку, не знаю правильно-неправильно, но по сути, она просто с круглешками и с подписью ролей.

Кажется я понял, что вы хотите сделать. Попробую сформулировать, для тех кто может, как и я не понял с начала:
Система для оценки (тестирование, по моему тут неоднозначный термин) кода (программ, модулей, единиц компиляции и т. п.), написанного её пользователями, с целью определения оптимального решения из множества решений конкретного задания.
Поправьте если не так.

Я могу помочь, только в качестве "второй головы" (ну это там где две головы лучше). Я не архитектор, и подобного опыта у меня нет. Вот если бы, кто нибудь из здешних архитекторов преподал на этом примере мастер-класс, это 
Хотя у меня есть смутное подозрение, что вопросы проектирования в разделе по Java - это оффтоп. С другой стороны, если реализация планируется на Java, то многие вопросы или решения (например по выбору тех или иных библиотек, фреймворков и т. п.) так или иначе будут относится к этому разделу.
Уважаемые модераторы, как вы на это смотрите?

Я не понимаю, зачем нужен кластер? На систему планируется мега-нагрузка, с которой не справиться один сервер?

AlexeyVorotnikov, на самом деле планируется. Дело в том, что это онлайн тестирование в определенный временной промежуток, т.е. к примеру около 2500 челов одновременно тыкаются по клиенту, отсылая туеву кучу запросов серверам. Я не знаю как это называется научно, ну что то типа часов пик. 
В общем, это не сайт, где нагрузка распределяется равномерно.
+ На самом деле хотелось бы получить опыт программирования подобной системы.