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

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

Давно не публиковал сообщений, потому что столкнулся с проблемой размещения всех объектов 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 готова.