Zonemng Software Requirement Specification

Введение

Определения

Система – совокупность Агента, установленного на некотором конкретном Сервере, и данных, которыми оперирует Агент.
Сервер – компьютер, работающий под управлением ОС Solaris 10, на котором установлена и запущена Система.
Агент – приложение, исполняемое на Сервере, которое получает RPC-запросы от Клиента, совершает в соответствии с запросом действия над Системой и/или Сервером, и возвращает некоторый результат выполнения запроса Клиенту.
VT: Необходимо подумать над тем как будет реализована аутентификация и авторизация пользователя при взаимодействии клиента с агентом. Но это уже углубление в архитектуру, поэтому здесь я не буду расписывать возможные варианты
Клиент – приложение, исполняемое на компьютере Пользователя Системы, предоставляющее интерфейс между Пользователем Системы и Агентом, т.е. в соответствии с действиями Пользователя Системы отправляющее RPC-запросы к Агенту, получающее результат от Агента, и отображающее результат в удобном для Пользователя Системы виде.
Пользователь Системы – человек, работающий с Клиентом.
Профиль Пользователя Системы – некоторая информация в Системе, которая может быть связанна с каким-либо Пользователем Системы.
Авторизованный Пользователь Системы – Пользователь Системы, с которым ассоциирован некоторый Профиль Пользователя Системы.
Неавторизованный Пользователь Системы – Пользователь Системы, с которым не ассоциирован ни какой Профиль Пользователя Системы.
Роль – часть Профиля Пользователя Системы, отвечающая за то, какие действия может совершать Авторизованный Пользователь Системы, ассоциированный с этим Профилем Пользователя Системы.
Ресурс – некоторый физический или программный объект, который разделяется между приложениями, работающими на Сервере.
VT: Не совсем так, к примеру, количество зон или количество ZR'ов не будет являться ресурсом по этому определению.
По поводу введения понятия пермиссии, то есть разрешения на выполнение определенной операции. Мы обсуждали это с Alexey Romanenko?, но насколько я помню так и не пришли к однозначному выводу. Есть 2 варианта – считать пермисии лимитом на ресурс, который может принимать булевы значения, либо ввести понятие пермиссии и рассматривать их отдельно от ресурсов. Но после некоторых размышлений я всё же больше склоняюсь ко второму варианту, так мне он кажется более прозрачным и он вписывается в мое представление архитектуры. Если мы решим разделить ресурсы и пермиссии, то тогда ресурсом можно будет считать количественную характеристику набора бизнес объектов, ввести несколько разных типов ресурсов и применять для каждого из этих ресурсов свою стратегию управления, но здесь речь заходит об архитектуре, но о ней мы говорить в SAD'е (Software Architecture Document) :)
Для того чтобы не путать понятия ресурса OS Solaris и ресурса нашей системы можно ввести разделение: первый называть системным ресурсом, второй – бизнес-ресурсом. Для того чтобы не было путанницы можно ввести такое правило: все с чем мы работаем на уровне бизнес-логики называть бизнес-(ресурс, объект, сервис) или просто (ресурс, объект, сервис), аналогичные понятия системного уровня называть системными-(ресурсами, объектами, сервисами))
Лимит – ограничение Профиля Пользователя Системы по некоторым его элементам или ограничение по действиям Авторизованного Пользователя Системы, ассоциировнного с данным Профилем Пользователя Системы.
VT: Думаю, проще и понятнее такое определение: лимит – ограничение сверху на количество используемого Пользователем Системы ресурса
Сервис – некоторая услуга, предоставляемая пользователю.
VT: Нужно решить будут ли сервисы добавлять собственные ресурсы, например количество виртуальных хостов в Apache – это необходимо обсудить, поскольку сильно влияет на архитектуру подсистемы сервисов

Сокращения

ПС – Пользователь Системы
UC – Use Case

Общее описание

Цель

Основными целями проекта является создание системы, которая позволит:

• управлять зонами ОС Solaris 10;
• автоматизировать управление хостингом на базе ОС Solaris 10;
• в некоторой степени упростить управление компьютером, работающим под ОС Solaris 10.

ОС Solaris 10

Причины, по которым была выбрана ОС Solaris 10:

• наличие встроенной системы виртуализации – зон, и системы управлениями ресурсами компьютера;
• официальная поддержка Sun.

Схожие програмные продукты

Parallels Plesk – система автоматизации хостинга.
Parallels Virtuozzo – система виртуализации для Linux – аналог зон в Solaris 10.
Solaris Container Manager – система для облегчения управления зонами в ОС Solaris.

---

Роли (система управления правами)

Краткое описание Ролей и их места в Системе в целом:
1) Administrator (root Сервера)

• управляет Сервером в целом.
• управляет Профилями ПС с ролью Zone-reseller.
• может существовать только один Профиль ПС с такой ролью. В дальнейшем может быть рассмотрена возможность создания алиасов – Профилей ПС, дублирующих всю информацию Профиля ПС за исключением пары Логин-Пароль. Так же может быть рассмотрена возможность создания нескольких Профилей ПС с ролью Administrator, но только после получения работоспособного прототипа системы, т.к. в данный момент непонятны преимущества использования нескольких Профилей ПС этой роли, зато видны значительные усложнения в реализации и логике работы самой программы.

2) Zone-reseller (root Сервера с ограниченными правами)

• обладает некоторым количеством Ресурсов: см. Ресурсы.
• производит некоторые действия над зонами: создает, редактирует, удалят, привязывает к зонам Ресурсы.
• управляет Профилями ПС с ролью Zone-owner: создает, редактирует, удаляет, привязывает зоны.

3) Zone-owner (root внутри зоны)

• обладает root-овым доступом к привязанным к нему зонам
• управляет сервисами внутри своих зон.
• управляет профилями End-user'ов внутри своих зон.

4) End-user (user внутри зоны)

• пользуется сервисами, которые предоставил Zone-owner

Профиль Пользователя Системы

Профиль ПС в первую очередь включает в себя:
1. Логин и Пароль, знание Пользователем Системы которых является достаточным условиям для ассоциации Профиля ПС с этим Пользователем Системы (процесс Авторизации).
2. Флаг приостановки Профиля ПС – означает временную невозможность авторизоваться в Системе, а также возможную приостановку всех подчиненных Профилей ПС, использованных ресурсов и зон.
VT: Можно просто назвать это статусом ПС. Что понимается под «приостановкой использованных ресурсов»? Может имелось ввиду «остановкой действующих сервисов»?
3. Персональная информация ПС – имя, фамилия, e-mail, дата создания.
VT: Сюда можно добавить и другие поля (адрес, телефон, факс, язык (в зависимости от него меняется локализация приложения-клиента))
4. Роль, определяющая дальнейшее содержание профиля, а также действия, которые может совершать Авторизованный ПС.

Далее, содержание профиля зависит от Роли:
1) Zone-reseller

• Родительский Профиль ПС с ролью Administrator
• Подчиненные Профили ПС с ролью Zone-owner
• Подчиненные Зоны
• Лимиты (некоторые ресурсы)

2) Zone-owner

• Зоны
• Подчиненные Профили ПС с ролью End-user
• Родительский Профиль ПС с ролью Zone-reseller

3) End-user

• Родительский Профиль ПС с ролью Zone-owner
• Доступные сервисы, и для каждого сервиса – свои настройки
• Лимиты (ресурсы и сервисы)

Лимиты

Пользовательские лимиты подразделяются по Ролям – Авторизованый ПС соответствующей роли имеет соответствующие лимиты.
1) Zone-reseller

• Ресурсы Сервера:
  • Процессоры:
    • какие именно (для многопроцессорной системы)
    • долевая нагрузка
  • Оперативная память
  • Файловая квота
  • Сетевые интерфейсы
    • физические сетевые интерфейсы
    • для каждого физического сетевого интерфейса – диапазон IP-адресов
    • для каждого физического сетевого интерфейса – максимальный трафик (входящий/исходящий) за определенный период
    • опционально: для каждого физического сетевого интерфейса – максимальная пропускная способность
• Максимальное количество подчиненных зон 
• Максимальное количество подчиненных Профилей ПС роли Zone-owner

VT: Ресурсы типа «количество ZO» и «количество зон» – это разные ресурсы. Реселлер может поступить как описано выше, но тогда такие "Zone Owner'ы?" теряют все премущества использования нашего web-клиента

2) Zone-owner
Все лимиты для Профилей ПС этой роли задаются лимитами зон, находящихся в подчинении.
3) End-user

• Дисковая квота для домашней директории
• Максимальный сетевой траффик за месяц
• Все остальные лимиты задаются настройками Сервисов

Также существуют лимиты (в общем случае ресурсы) на зону: Определится с лимитами более точно

• Процессоры:
  • какие именно (для многопроцессорной системы)
  • долевая нагрузка
• Оперативная память
• Файловая квота
• Виртуальные сетевые интерфейсы – для каждого: диапазон IP-адресов, максимальная пропускная способность, максимальный трафик (входящий/исходящий) за месяц
• Максимальное количество Профилей ПС роли End-user, привязанных к зоне.

непонятно абсолютно аналогично лимитам для ZR
VT: Здесь и правда не совсем понятно как технически ограничить число пользователей зоны. Видимо придеться убрать этот ресурс и соответственно ограничение на число EU.
B: еще вариант – не давать рутового доступа для пользователей типа Zone-owner, тогда ограничение будет иметь смысл; можно еще сделать два варианта по выбору для каждого профиля владельца зоны – предоставить/ограничить рутовый доступ, тогда все нормально будет

Шаблоны

В системе планируется много мест, в которых будет происходить создание какого-то объекта (пользователя, зоны, аккаунта веб-сервера, и т.д.). Пунктов, которые нужно заполнять при создании объекта достаточно много при тонкой настройке. Также возможны некоторые пре- и пост- действия (после создания end-user аккаунта создать аккаунт для него в зоне с веб-сервером + настроить виртуальные хосты в случае апача). Для облегчения типовых задач – создание некоторого сценария создания + автозаполнение полей форм.
Обязательно необходимо реализовать шаблоны:

• Зоны
• Пользователя для каждой роли
• Набора лимитов

наверно надо специфицировать более точно, что будет включаться в каждый шаблон не в UC, а отдельным документом
и наверно стоит реализовывать шаблоны в самую последнюю очередь, т.к. в данный момент не все понятно
VT: Согласен, в принципе, это дополнительная, хотя и важная функциональность, ее отсутствие не будет блокировать основные UC.

Общие требования

Протокол взаимодействия Клиента и Агента

В качестве основного протокола взаимодействия Клиента и Агента должен быть XML-RPC.

Клиенты

Два типа Клиентов:
1. Web-приложение (вероятно PHP5)

• основная цель – мобильность – возможность запустить клиент там где есть браузер и интернет, и условия не позволяют установить настольное приложение (например: отсутствие прав для запуска сторонних приложений, блокировка фаерволами).
• должен работать как при наличии Java Script?, так и при его отсутствии (требование мобильности)
• интерфейс должен быть унифицирован с Plesk
• при наличии Java Script?, желательно использовать AJAX-технологии, как в Plesk'e
• должно работать во всех версиях популярных браузеров (IE 5/6/7, Firefox, Opera 9) максимально одинаково

1. Настольное приложение (вероятно Java) вопрос о востребованности данного приложения – либо не реализовывать, либо очень низкий приоритет

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

Общие требования:

• клиенты должны быть максимально простыми для повседневного типового использования, интуитивно понятны, не перегружены лишними и редкоиспользуемуми возможностями, какие есть в SCM.
• но в тоже время должна быть возможность тонкой настройки по требованию.
• мультиязычность – должны быть простые средства для локализации клиента (для web-клиента – см. Plesk); в базовом варианте должно быть как минимум два языка – английский и русский.

язык возможно будет пока один, но обязательна возможность добавления других языков

Установка, конфигурирование, отладка:
Должны существовать утилиты для обслуживания системы:

1. Инсталятор Агента на Solaris. Должен включать в себя утилиту для создания пользователя-администратора и смены его пароля.
2. Инсталятор web-клиента на web-сервер.

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

Неавторизованный ПС

Для следующих UC необходимым требованием является, что ПС является Неавторизованным ПС.
1) Login (Авторизация) ??слишком детализовано? ??
VT: Да, я думаю не стоит так подробно расписывать, достаточно тяжело воспринимать UC целиком. Может стоит задействовать UML (хотя на это уйдет дополнительное время)?
B: его надо было использовать с самого начала, а не писать SRS. если сделать не сильную детализацию и только диаграмму для UC то уйдет не так уж много времени; а каждый UC можно будет документировать по мере его создания
Предусловие: То, что ПС является Неавторизованным ПС по сути означает, что либо ПС только что запустил Клиент, либо что ПС применил Logout
Сценарий:
1. Запрашиваются логин и пароль. Пароль не должен отображаться на экране в явном виде.
2. Пользователь нажимает кнопку входа в систему
3. Клиент производит начальную проверку введенных данных – является ли логин и пароль введенные пользователем корректными логином и паролем в Системе. Если не являются – происходит возврат на шаг 1, причем поле логин должно быть автоматически заполнено изначально введенными ПС на 1-м шаге данными. Если являются – отсылается запрос Серверу, проверяется существование Профиля ПС с такими логином-паролем. Если проверка завершилась успешно – устанавливается привязка ПС (точнее Клиента) к этому Профилю ПС. В противном случае – переход на шаг 1 с сообщением об некорректном логине и пароле и автозаполнением логина старым значением.
Дополнительные пожелания:
Все сообщения об ошибках должны выглядеть одинаково.
Должна быть в некотором виде система защиты от подбора пароля – например максимальное число попыток входа с одного IP-адреса. При большом количестве неудачных попыток входа каким-либо образом должны быть отправлено сообщение администраторам системы.

Авторизованный ПС

Для следующих UC необходимым требованием является, что ПС является Авторизованным ПС.
1) Logout (Выход из Системы)
Описание: текущий ПС становится Неавторизованным ПС и переводится на страницу авторизации.

2) Смена пароля
Описание:
1.Запрашиваются текущий пароль, новый пароль и подтверждение нового пароля.
2. Если введеный текущий пароль не является паролем текущего Профиля ПС – переход на шаг 1 с сообщением о том что старый пароль неверный.
3. Проверяются новый пароль и подтверждение на корректность и совпадение. В случает неудачи – соответствующие сообщения об ошибке.
4. Происходит изменение пароля текущего Профиля ПС на новый.

По ролям

Для следующих UC необходимым требованием является, что ПС является Авторизованным ПС и Профиль ПС имеет роль, указанную в заголовке.

Administrator

UC роли Администратор

Zone-reseller

UC роли Zone Reseller

Zone-owner

UC роли Zone Owner

End-user

Сервисы

1) Просмотр доступных сервисов
Идея:
Просмотр доступных сервисов (т.е. включенных для данного пользователя) в виде списка, с возможностью быстрого перехода к «Настройки/использование сервиса» каждого конкретного сервиса.

2) Настройки/использование сервиса
Примечание:
Что именно должно быть реализовано в данном пункте определяется для каждого сервиса по своему. Для дополнительной информации см. Service SRS.

Лимиты

1) Просмотр своих лимитов.
Идея:
Просмотр потребления основных своих ресурсов и соответствующих им лимитов
Описание:
Должны отображаться следующие поля: