Как описать требования к резервному копированию

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

Техники выявления требования: интервью, изучение документации.

Требования к резервному копированию системы могут быть разными, поэтому полноту надо оценивать исходя из вашего контекста. Однако, в большинстве проектов, где я работал, требования были достаточно стандартны.

Как же описать требования?

Непосредственно процесс сбора требований:

1. Выявляем типы данных для резервного копирования

Это могут быть различные данные, не только реляционные базы данных. 
Пример:

  a.      Файлы (XSD, JSON схемы, снапшоты виртуальных машин, ...)

  b.     Key-value storage (MongoDB), в т.ч. и держащие данные в памяти (Redis).

  c.      Реляционные базы данных.

  d.     Данные из очередей (Kafka).

Для примера, возьмем резервное копирование данных из очередей – пункт d.

2. Определяем целевые показатели для резервного копирования 

  a. Recovery Point Objective (RPO) - как много данных мы можем потерять(за какой период)? Очевидно, что для каждого типа данных может быть свое значение. 

Из очередей данных можно потерять за последний час, т.е. PRO - 1 час. 

  b. Recovery Time Objective (RTO) - как быстро система должна восстановиться после сбоя до нужного уровня работоспособности. 

RTO в нашем случае – 15 минут.

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

3. Определяем процесс, по которому будет происходить процесс резервного копирования и восстановления

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

Я опишу процесс копирования с точки зрения обывателя, в для статьи правильный процесс – не самоцель.

 Основные шаги:

1. Подготовка данных.
2. Резервное копирование (Инициализация копирования, копирование, завершение и проверка резервной копии).
3. Восстановление из резервной копии (опционально).
4. Удаление данных.

4. Выявляем Use Cases и строим диаграмму

Я выявляю UC по шагам процесса:

• 1-й шаг – UC с целью подготовить данные.
• 2-й шаг – UC с целью получить резервную копию в определенном месте.
• 3-й шаг – UC с целью получить работающую систему с данными, актуальными на момент копирования.
• 4-й шаг – UC с целью получить файловое хранилище с местом, достаточным для последующего резервного копирования.

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

Note: Если вы жестко придерживаетесь концепции описания и применения use cases, то, вероятно, диаграмму вариантов использования вам строить не стоит. Сценарии backup и save queues state, где эктором является scheduler – это не совсем сценарии использования в их классическом значении, поскольку и пользу эктор не получает, и логически находится в рамках системы резервного копирования, да и пресловутого взаимодействия как такового нет, особенно, если в качестве триггера для UC обозначить «наступление времени копирования». Сами UC можно описать в качестве activity diagram. Но все ж у вас есть оправдание, можно ссылаться на UML 2.5:

"Also, all UML 2.x specifications until UML 2.5 stated that use cases "are defined according to the needs of actors." This sentence was removed from UML 2.5 as some actors might have neither needs nor requirements by themselves"

5. Далее, описываем сценарии использования

Для примера возьмем UC «резервное копирование».

UC-ID-Name|Служебная информация: triggers, actors, post and pre-conditions|Main flow:
1. Scheduler инициализирует задачу резервного копирования.
2. System проверяет наличие данных для копирования.
3. System проверяет доступность хранилища и наличие свободного места.
4. System копирует подготовленные данные в хранилище.
5. System проверяет сохраненные данные.
6. End with success.

Alternative flow:
3a. Данные не были подготовлены.
1. System запускает процедуру подготовки данных
2. Kafka готовит данные для копирования [ссылка на UC подготовки данных].
3. Переходим к шагу 3 основного потока.
3a2a Данные не готовы.
1. System оповещает администратора об ошибке.
2. Failed end.
И т.д.

При расписывании сценария у вас возникнет куча требований по тому КАК должна система выполнять те или иные действия, а это и есть цель извлечения требований

6. Формализуем требования и начинаем анализ на непротиворечивость, выполнимость, проверяемость, понятность, нужность и т.д.

Отдельно хочу отменить нужность, т.к. есть шанс придумать что-то очень крутое инженерное, но ненужное.

7. Согласовываем и можно разрабатывать дизайн систем

Источники:
http://wikibon.org/wiki/v/Recovery_point_objective_-_recovery_time_objective_strategy
https://en.wikipedia.org/wiki/Backup

Как показать "найденное сообщение" на диаграмме последовательностей

Eng: How to Show "found message" in EA on Sequence Diagram

Проблема: На диаграмме последовательностей вам надо изобразить найденного сообщение (found message), вы используете Enterprise Architect.

Делается это довольно просто.

1. Добавляем на диаграмму endpoint

2. А уже от неё ведем связь взаимодействия 

Готово.

Подробнее можно почитать тут:

1. http://www.sparxsystems.com/enterprise_architect_user_guide/10/standard_uml_models/endpoint.html
2. http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html