8. Требования к защите от влияния внешних воздействий

Требования к защите от влияния внешних воздействий не предъявляются.

9. Требования к патентной чистоте

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

10. Требования по стандартизации и унификации

Система должна обеспечивать работу с почтовыми серверами, работающими по протоколу SMTP.

11. Дополнительные требования

Специальные требования не предъявляются.

2. Требования к функциям, выполняемым системой

Функции, подлежащие автоматизации перечислены в модели вариантов использования. Итерация 1 основана на простом консоль­ном приложении, которое обеспечивает доступ к БД. В ответ на регистрационное имя, посланное к БД электронной почты, приложение может извлечь из БД и показать список исходящих сооб­щений, которые могут быть отправлены деловым партнерам. После этого по­льзователь (служащий) может запросить автоматическую отправку выбран­ного исходящего сообщения. Когда сообщение будет успешно отправлено, БД соответствующим образом обновляется.

Последующие итерации учебного примера адресованы к более сложным средствам управления сообщениями электронной почты, содержащими текст и добавленные к сообщению неструктурированные (мультимедиа) докумен­ты, которые должны быть посланы.

Итерация 2 позволяет вводить новые исходящие сообщения в БД через GUI или другой допустимый в веб-технологии интерфейс. Она поддерживает также рассмот­рение исходящих сообщений, основанное на различных фильтрах и критери­ях поиска.

Итерация 3 перемещает основной ак­цент логики приложений на БД и задает дополнительные бизнес-правила в БД, которым должно подчиняться приложение.

1. Модель вариантов использования итерации 1

Итерация 1 предполагает, что сообщения к деловым партнерам уже размещены в БД ЕМ. Итерация 1 системы предназначена для создания и передачи по электронной почте сооб­щений и для обновления БД данных после успешной передачи.

Рис. 4 .2 представляет диаграмму вариантов использования, предназначенную для представления цели, намеченных функциональных возможностей, пред­положений и упрощений итерации 1. Сценарий использования StoreMessagestoContacts(размещение сообщений для деловых партне­ров) — вне возможностей итерации 1.

Рис. 4.2. Диаграмма вариантов использования для первой итерации

Цель StoreMessagestoContacts(размещение сообщений для де­ловых партнеров) — разместить вProductionDatabase(БД произво­дства) тему и текст сообщений по электронной почте к деловым партнерам и поручить отправку этих сообщений соответствующимCustomerDepartmentEmployee(служащим отдела работы с клиентами). Обычно этот сценарий использования активизируется во время сбора и проверки дан­ных о рекламных операциях и при подготовке сообщений об операциях для клиентов. Итерация 1 предполагает, что такие сообщения уже существуют вProductionDatabase.

ViewUnsentMessages(просмотр непосланных сообщений) отвечаетза показ списка, содержащего основную информацию о сообщениях, сохра­няемых вProductionDatabaseи запланированных для отправки поэлектронной почте из Customer Department Employee. Customer Department Employee может пожелать отобразить полный текст сообще­ния (Display Message Text — отображение текста сообщения) перед принятием решения послать его по электронной почте (Email Message — сообщение электронной почты).

Как только сообщение будет успешно послано, EmailMessageуста­навливает флаг, что это произошло. Данное действие не очевидно в диаграм­ме сценариев использования, потому что модель сама не фиксирует, как и гдебудет установлен «флаг отсылки». Возможно, например, что Production Database используется только сценарием использования View Unsent Messages, который читает сообщения и загружает их в БД, внутреннюю по отношению к ЕМ. Внутренняя БД не может быть актёром в ЕМ-модели.