Skip to content
This repository has been archived by the owner on Aug 16, 2018. It is now read-only.
Alexey Kovrizhkin edited this page Nov 5, 2014 · 1 revision

Функциональные требования

Введение

Тема использования в разработке веб-проекта таких технологий, как ExtJS и Java, позволяет по-новому посмотреть и на функциональные требования к системе и на других программных платформах, в частности, perl + postgresql.

Следствия из ExtJS

Схема “обработчик запроса готовит все данные и передает их в шаблон для построения страницы” не подходит, т.к. динамической странице уже выгруженной клиенту могут понадобиться данные, которые заранее неизвестны.

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

Следствия из Java

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

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

Выводы

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

  1. ядро предоставляет клиентам унифицированный интерфейс для вызова методов (API), результаты методов – данные (в формате JSON)
  2. клиентами ядра выступают: построитель html-интерфейса (шаблонизатор), программы js-интерфейса и программы на серверах клиентов
  3. основная часть кода обработки данных расположена рядом с данными, в хранимых функциях БД
  4. описание API (документация по методам, аргументам, результатам и т.п.) хранится в БД и доступно посредством вызова методов API
  5. данные для описания API хранимого кода автоматически формируются по системному каталогу БД
  6. для разгрузки БД используется кэширование вызовов методов (в т.ч. для каждого метода может быть задан свой тип кэша и условия его инвалидации)

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

Требования к функционалу

Для проверки гипотезы необходимо реализовать программное решение со следующим функционалом:

  1. Предоставление доступа к программному интерфейсу посредством стандартного протокола:
  1. для внешних приложений
  2. для собственных RIA (модулей на javascript)
  3. для построения html-страниц интерфейса системы
  4. Автоматическое документирование программного интерфейса для внутренних и внешних разработчиков
  5. Единая система разграничения доступа к объектам системы
  6. Оптимизация доступа к данным посредством кэширования запросов
  7. Поддержка мультиязычности интерфейса
Clone this wiki locally