Документ проектирования nest-ldap

Документ проектирования


3.1. Проект архитектуры и интерфейса пользователя
(Разработчик архитектуры - Нуйкин, автор документа - Димитров)
Особенности диаграммы:
  • Классы и интерфейсы, выделенные синим цветом, не реализуются подсистемой nest-ldap. Они предоставляются ей системой Nest.
  • Классы и интерфейсы, выделенные желтым цветом, реализуются подсистемой nest-ldap.
  • Классы и интерфейсы, выделенные серым цветом, не реализуются. Возможно они будут реализованы когда-либо в будущем. Они показаны на схеме для общего понимания архитектуры, ее преимуществ и обоснованности.

Архитектура системы nest-ldap

Manager's hierarchy        Cache's hierarchy        Storage's hierarchy
На высоком уровне абстракции архитектура базируется на трех понятиях:
  • Хранилище (Storage) - место, где будут храниться данные.
  • Элемент (Element) - минимальная структура данных, которыми оперирует система.
  • Кэш (Cache) - специфично организованная часть оперативной память для хранения элементов.
Таким образом систему можно разделить на три подмодуля, реализация которых происходит независимо друг от друга. Разработчик одного из подмодулей может ничего не знать об устройстве каких-либо других подмодулей.
  • Модуль работы с хранилищем - отвечает за реализацию доступа к конкретному хранилищу данных. Включает в себя все специфичные особенности этого хранилища. Будь то LDAP,mysql или что-то другое.
  • Модуль работы с элементами - устанавливает связи, если такие имеются, между элементами. Реализует все специфические особенности работы с элементами.
  • Модуль работы с кэшем - конкретная организация памяти.
Все эти подмодули "повязаны" между собой при помощи интерфейсов:
  • Интерфейс Storage - предоставляет доступ к хранилищу.
  • Интерфейс Cache - предоставляет доступ к кэшу.
  • Интерфейс работы с элементами специфичен для вида элемента. Зависит от набора необходимых операций над элементами и конкретных нужд системы. В нашем случае интерфейс SanStorage работает с SanElement

Преимущества такое организации системы:
  • Минимальность затрат на переписывание системы при смене вида хранилища, типов элементов или организации кэша. При таких изменениях разработчикам необходимо будет только переписать реализацию интерфейса, отвечающего за соответствующий раздел системы и естественно сам подмодуль
  • Простота тестирования. Тестировщику какого-либо подмодуля нет необходимости знать устройства каких-либо других подмодулей. Он лишь должен использовать по назначению реализованный для него интерфейс.
  • Написанный единожды тест для тестирования реализации одного из интерфейсов не потребует переписывания при изменении этой самой реализации