Новые изменения

1. Переработан полностью интерфейс команд сетевого взаимодействия сетевых клиентов. Теперь для обмена данными используются отдельные функции для каждой команды, что облегчает их использование в процессе разработки.

2. Введен новый класс - CaesarTable:

/**

* Класс представляет собой объект для хранения данных в виде таблицы строк. Объект оддерживает сетевое

* обновление, но не предназначен для хранения связанных данных с другими таблицами. Предназначен

* для хранения различных справочных данных в виде текстовой таблицы.

*/

Соответственно введены новые команды работы с таблицами по сети.

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

Промежуточные итоги

Давно не писал в блоге - был занят работой :).

Наконец то можно подвести итоги. В настоящий момент закончена и протестировано ядро логического хранения данных со всей обвязкой, структура взаимосвязи всех объектов, разрешения и привелегии, архивирование (1-й этап). Закончено, но не протестировано сетевое взаимодействие клиентов. Клиенты в автоматическом режиме самостоятельно , без дополнительных телодвижений пользователей находят друг-друга в сети, обмениваются наработанными данными. (2-й этап). После тестирования начнется 3-й этап - создание пользовательского интерфейса. Планируется реализация на JavaFX - интерфейс похожий на The Brain. 

Менеджер объектов CesarObject - Manager

Наконец то закончил и первично оттестировал менеджер объектов.

Краткое описание:

public class Manager
extends java.lang.Object

Менеджер объектов CesarObject. Управляет их размещением в памяти и на диске. В зависимости от статуса объект может быть размещен на диске или в памяти. Содержит множество самих объектов, их статусы, пользователей программы и текущего пользователя.
Инициализация - вызов Manager.Manager(). Он инициализирует множества, загружает ранее сохраненные или создает новые в каталоге пользователя в созданном подкаталоге .cesar 
Окончание работы - обязательный вызов save() - которая записывает все наработанные менеджером данные в файл. Это аналогично раздельному вызову saveStatuses() и saveUsers(). Данные по новому объекту сразу записываются в архивный файл при вызовеputCesarObject(CesarObject cesarObject)

http://tsvetkov.at.ua/publ/1-1-0-17 - полное описание

Средневековая техподдержка

Ревизия сделанного

Давно не публиковал сообщений, потому что столкнулся с проблемой размещения всех объектов CesarObject в памяти.

Поскольку изначально задача стояла в том, что объекты не удаляются, возникла проблема:

с течением времен количество объектов может вырасти настолько, что не поместится в памяти.

Принятое решение:

Разбил объекты CesarObject на четыре категории.

1. Вновь созданный (неутвержденный) CesarObject. Работа с таким объектом ведется только текущим пользователем. После утверждения данный объект рассылается всем заинтересованным пользователям и не может быть удален. Виден на рабочем столе.  Размещен в оперативке. 
2. Активный объект CesarObject. С активным объектом ведется какая-либо работа кем-то из пользователей. Виден на рабочем столе. Размещен в оперативке.
   
3. Архивный объект CesarObject. Имеет срок хранения. После истечения срока хранения удаляется. Размещен на жестком диске в архивном файле объектов. При необходимости подгружается в оперативку.
4. Удаленный объект CesarObject. Имеет срок хранения . После истечения срока хранения удаляется. Размещается в файле удаленных объектов. При необходимости подгружается в оперативку.

Активные и вновь созданные объекты сохраняются цельным объектом со всеми взаимосвязями в единый файл.

Архивные и удаленные объекты сохраняются в текстовый файл построково. При указании соответствующей опции защиты информация шифруется.

Архивный срок хранения редактируется собственником объекта. По умолчанию равен среднему сроку жизни документов в конкретной организации. Задается руководителем организации.

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

После проверки целостности схемы и подбора реализации, приступил к переделке CesarObject с учетом вышесказанного. Вместо ссылок на объекты новый CesarObject хранит внутри их хеш-коды в множестве HashMap. Класс CesarObject хранит единое множество всех объектов CesarObject. Дополнительно снабжу инструментами для подготовки информации для записи в текстовые файлы.

Проверка кода

Последнюю неделю занимался проверкой и отладкой всего написанного кода. Нашел замечательный плагин для NetBeans - https://sqe.dev.java.net/

Позволяет проверить код на наличие ошибок, а также укажет на потенциальные проблемы. Интегрируется в JDeveloper, Eclipse, JEdit, JBuilder, BlueJ, CodeGuide, NetBeans/Sun Java Studio Enterprise/Creator, IntelliJ IDEA, TextPad, Maven, Ant, Gel, JCreator и Emacs.

Возможности плагина:
Анализ код на наличие дефектов 
Поиск багов
Проверка стиля 
Поиск, проверка, анализ зависимостей

Вовремя заметил проблему

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

Принятое решение - из CesarObject удалил флаг состояния. Вместо этого буду реализовывать разные списки ссылок на CesarObject. Действующие объекты будут размещатся в памяти, а неактивные (удаленные) будут хранится на диске.

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

Описание локаций

Создан объект Location - описание локации с подробностями  и взаимосвязми. Построена структурная взамосвязь данных: 

Страна - Регион - Населенный пункт - Улица - Локация

Добавлена возможность локализации данного модуля.

Модуль протестирован при помощи JUnit 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CesarObject

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

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

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

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

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

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