Защита данных

Исследовал различные механизмы реализации защиты данных при многопоточности. Итог - решил не реализовывать специальных механизмов гарантирующих целостных даннных при обращении к ним из разных потоков непосредственно в структуре данных, хотя это и возможно. Подобный метод как мне кажется приведет к утяжелению исходных объектов CesarObject. Защиту проще будет реализовать непосредственно в тех местах, где идет изменение данных при помощи блокировки/разблокировки критически важным мест.

Кроме этого в потоку уведомляющих событий нужно будет включить сохранение истории выполненных изменений.

Тестирование CesarObject

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

Тестирование

Для тестирования выбрана платформа JUnit. Скачал, установил и опробовал встроенный модуль в NetBeans 6.5 (интегрированная среда разработки под Java). Позволяет проводить быстрое тестирование написанных модулей на предмет простых ошибок. В целом уменьшает время на отладку.

Для отслеживания хода разработки применяю новый плагин в NetBeans - Cube°n v.1.0.3.1. 

Многопоточность

При работе УЗЕЛ не только загружает все измененные данные с других УЗЛОВ по сети, но и должен будет оперативно отправлять свои события + принимать события от других УЗЛОВ. Поэтому необходимо рассмотреть, а затем разработать механизм многопоточности системы.

Рабочий поток - основная работа пользователя.

Поток своих событий - рассылка событий (изменение данных, статусов объектов) для других УЗЛОВ.

Потоки обновлений - прием обновлений от других УЗЛОВ.

Взаимодействие и организация УЗЛОВ

Взаимодействие и организация работы между компьютерами происходит по принципу организации работы людей.

Рабочее место существует виртуально - УЗЕЛ.

Экземпляры выполненной работы распределены на других УЗЛАХ и на УЗЛЕ исполнителя.

Выполненная работа дублируется на УЗЛЕ руководителя.

Каждый УЗЕЛ является клиентом и сервером одновременно.

При начале работы УЗЕЛ инициализируется регистрацией личности.

Регистрация личности производится на основе обычных данных – Ф.И.О, дата и место рождения. Уникальность достигается за счет хеш кода этих данных.

После регистрации УЗЕЛ запрашивает другие УЗЛЫ по поводу работы.

Каждое УЗЕЛ «принимает на работу» другое УЗЕЛ – регистрирует у себя, дает ему право на доступ к своим ресурсам в какой-либо из РАБОЧИХ ОБЛАСТЕЙ. Выделяет часть полномочий и выдает задания. Каждое УЗЕЛ выделяет свой пароль для доступа другого УЗЛА.

УЗЕЛ может быть создан на любой машине путем запроса к УЗЛУ собственнику РАБОЧЕЙ ОБЛАСТИ верхнего уровня. УЗЕЛ выдает список УЗЛОВ с которыми контактировало данное УЗЕЛ или должен будет контактировать. На всех этих УЗЛАХ проводится авторизация по известным паролям. УЗЛЫ пересылают всю ранее проделанную работу на новый экземпляр существующего узла. Вновь созданный узел имеет все необходимое в своем Рабочем пространстве для работы.

УЗЕЛ создает РАБОЧИЕ ОБЛАСТИ, в которые может приглашать другие УЗЛЫ. Кроме того в рамках РАБОЧЕЙ ОБЛАСТИ могут быть созданы другие РАБОЧИЕ ОБЛАСТИ, в которые приглашены другие УЗЛЫ.

УЗЕЛ создатель РАБОЧЕЙ ОБЛАСТИ имеет полные права в этой области. Другие УЗЛЫ могут создавать свои РАБОЧИЕ ОБЛАСТИ в рамках основной РАБОЧЕЙ ОБЛАСТИ. В этих областях они тоже имеют полные права.

Верхний уровень РАБОЧЕЙ ОБЛАСТИ – Организация. Дальше идут отделы, затем проекты, затем задачи.

РАБОЧАЯ ОБЛАСТЬ включает меньшие рабочие области, приглашенные узлы, списки задач, выполненную работу (файлы), отметки о выполненной работе

CesarObject

Основа системы - глобальный суперкласс CesarObject, свойства которого наследуют все остальные объекты создаваемые пользователями в системе Cesar. Он определяет структуру всех остальных данных и систему взаимоотношений между ними. Все остальные объекты происходят от него. 

Любой объект в системе идентифицируется на основе даты создания и имени. 

Объект может быть модифицирован любым пользователем имеющим на это разрешения. Не может меняться название объекта, его дата и автор.

CesarObject хранит основные данные объекта:

• Автор, текущий собственник - ссылка на объекты типа User
  
• Дата создания объекта
  
• Название объекта
  
• Текущее состояние объекта (создан/неутвержден, свободный, редактируется, удален/в работе не учавствует*)
  
• Объект родитель - ссылка
  
• Массив ссылок на дочерних объектов
  
•  Список разрешенные действия над объектом для каждого из пользователей (примечание: в списке храняться пары ссылок пользователь - битовый массив разрешений по мере добавления новых пользователей, которым разрешены действия над данным объектом. Ссылки на пользователей, которым полностью закрыт доступ не храняться в данном массиве).
  

*Предпологается, что объекты не удаляются, выставляется лишь статус объекта.