note
.pdf
11 КП-02068195-341-07-14
Рис. 3.1 представляет диаграмму классов для концептуальных классов, необходимых в
итерации 1.
|
Сотрудник |
|
|
Деловой_партнёр |
|
|
+ |
Код_сотрудника |
: String |
+ |
Код_делового_партнёра |
: String |
|
+ |
Имя |
: String |
+ |
Организация |
|
: String |
+ |
Фамилия |
: String |
+ |
Имя |
|
: String |
+ |
Логин |
: String |
+ |
Фамилия |
|
: String |
+ |
Эл_почта |
: String |
+ |
Эл_почта |
|
: String |
|
0..1 |
1..1 |
|
|
1..1 |
|
|
|
Для |
|
|||
|
|
|
|
|
||
|
|
|
|
0..* |
|
|
|
|
0..* |
|
Исходящее_сообщение |
||
|
|
|
|
|
|
|
|
Разработчик |
+ |
Код_сообщения |
: No |
|
|
|
|
|
+ |
Тема |
: String |
|
|
|
|
+ |
Текст |
: String |
|
Отправитель |
0..* |
+ |
Дата_создания |
: Date |
|
|
|
|
|
|
|
||
|
|
|
+ |
Дата_отправки |
: Date |
|
|
Рис. 3.1. Концептуальная модель предметной области для итерации 1 |
|
|
|||||
Диаграмма классов содержит три класса: |
Сотрудник, Деловой_партнёр и |
|||||||
Исходящее_сообщение. В таблицах 3.1-3.3 перечислены свойства атрибутов. |
|
|
||||||
Таблица 3.1 - Атрибуты класса «Сотрудник» (Employee) |
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
Тип |
Видимость |
Нач. знач. |
Только для |
|
|
Название (Name) |
|
Код (Code) |
чтения |
|
||||
|
(Data Type) |
|
(Visibility) |
(Initial Value) |
|
|||
|
|
|
|
(Read-only) |
|
|||
|
|
|
|
|
|
|
||
Код_сотрудника |
|
employee_id |
String |
|
public |
|
FALSE |
|
Имя |
|
first_name |
String |
|
public |
|
FALSE |
|
Фамилия |
|
family_name |
String |
|
public |
|
FALSE |
|
Логин |
|
login_name |
String |
|
public |
|
FALSE |
|
Эл_почта |
|
employee_email |
String |
|
public |
|
FALSE |
|
Таблица 3.2 - Атрибуты класса «Деловой_партнёр» (Contact) |
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
Тип |
Видимость |
Нач. знач. |
Только для |
|
|
|
|
|
||||||
Название (Name) |
|
Код (Code) |
чтения |
|
||||
|
(Data Type) |
|
(Visibility) |
(Initial Value) |
|
|||
|
|
|
|
(Read-only) |
|
|||
|
|
|
|
|
|
|
||
Код_делового_партнёра |
|
contact_id |
String |
|
public |
|
FALSE |
|
Организация |
|
organization |
String |
|
public |
|
FALSE |
|
Имя |
|
first_name |
String |
|
public |
|
FALSE |
|
Фамилия |
|
family_name |
String |
|
public |
|
FALSE |
|
Эл_почта |
|
contact_email |
String |
|
public |
|
FALSE |
|
Таблица 3.3 - Атрибуты класса «Исходящее_сообщение» (OutMessage) |
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
Тип |
Видимость |
Нач. знач. |
Только для |
|
|
Название (Name) |
|
Код (Code) |
чтения |
|
||||
|
(Data Type) |
|
(Visibility) |
(Initial Value) |
|
|||
|
|
|
|
(Read-only) |
|
|||
|
|
|
|
|
|
|
||
Код_сообщения |
|
message_id |
No |
|
public |
|
FALSE |
|
Тема |
|
message_subject |
String |
|
public |
|
FALSE |
|
Текст |
|
message_text |
String |
|
public |
|
FALSE |
|
Дата_создания |
|
date_created |
Date |
|
public |
|
FALSE |
|
12 КП-02068195-341-07-14
|
|
Тип |
Видимость |
Нач. знач. |
Только для |
|
|
|
|||||
Название (Name) |
Код (Code) |
чтения |
||||
(Data Type) |
(Visibility) |
(Initial Value) |
||||
|
|
(Read-only) |
||||
|
|
|
|
|
||
Дата_отправки |
date_emailed |
Date |
public |
|
FALSE |
Ассоциации названы «отправитель» (sender), «разработчик» (creator) и «для» (for). Имеется точно один Contact для каждого OutMessage. Contact может быть связан с нулем или несколькими
OutMessage. Ассоциация по имени creator связывает OutMessage с Employee, кто создавал это
OutMessage в БД. Ассоциация по имени sender идентифицирует Employee, который будет отправлять по электронной почте OutMessage. Эта ассоциация связана с нулем Employee, если отправитель для OutMessage еще не намечен.
4 Требования к системе
4.1 Требования к системе в целом
4.1.1Требования к структуре и функционированию системы
Архитектура системы
Система EM должна иметь двухуровневую клиент-серверную архитектуру:
На уровне хранения данных размещается сервер БД, а на прикладном уровне насыщенное клиентское приложение.
Информационный обмен между компонентами системы
Входящие в состав EM подсистемы в процессе функционирования должны обмениваться информацией на основе открытых форматов обмена данными по протоколам на основе TCP/IP.
Взаимосвязи со смежными системами
Требуется обеспечить взаимодействие с почтовым сервером организации. Первая версия системы предусматривает только отсылку по электронной почте сообщений, хранящихся в БД.
Перспективы развития, модернизации системы
Система должна реализовывать возможность дальнейшей модернизации как программного обеспечения, так комплекса технических средств.
Также необходимо предусмотреть возможность увеличения производительности системы путем её масштабирования.
Управление электронной почтой может иметь более широкое применение как система для маркетинга с помощью электронной почты (Email Marketing). Маркетинг с помощью электронной почты — нечто вроде предоставления по электронной почте деловым партнерам (потенциальным клиентам) маркетинговой информации относительно изделий или услуг. Как и в системе ЕМ,
маркетинг электронной почты хранит информацию в БД относительно деловых партнеров и их
13 КП-02068195-341-07-14
электронных адресов, форматирует исходящие сообщения, основанные на информации, также
хранящейся в БД, автоматически посылает по электронной почте эти сообщения и соответственно
корректирует БД.
4.1.2Требования к численности и квалификации персонала системы и режиму его работы
Для эксплуатации АС Склад должны быть предусмотрены следующие роли пользователей:
1)Администратор;
2)Сотрудник;
3)Служащий отдела работы с клиентами.
Администратор должен обладать высоким уровнем квалификации и практическим опытом выполнения работ по установке, настройке и администрированию программных и технических средств, применяемых в системе.
Пользователи системы (Сотрудники и Служащие отдела работы с клиентами) должны иметь опыт работы с персональным компьютером на базе операционных систем Microsoft Windows на уровне квалифицированного пользователя и свободно осуществлять базовые операции в стандартных Windows-приложениях.
Рекомендуемая численность для эксплуатации системы EM:
-Администратор – 1 штатная единица;
-Пользователь – число штатных единиц определяется структурой предприятия.
4.1.3Показатели назначения
Нет никакого ограничения сверху на число одновременно работающих пользователей. Время отклика системы не должно меняться, если число одновременно работающих пользователей — 100
или менее.
Система должна предусматривать возможность масштабирования по производительности и объему обрабатываемой информации без модификации ее программного обеспечения путем модернизации используемого комплекса технических средств. Возможности масштабирования должны обеспечиваться средствами используемого базового программного обеспечения.
4.1.4Требования к надежности
Система должна быть доступна 24 часа каждый день недели. Не должно быть никакого связанного с БД времени простоя. О любых запланированных простоях почтового сервера из-за профилактик ЕМ-пользователи электронной почты должны быть уведомлены, по крайней мере, за
24 часа.
14 КП-02068195-341-07-14
Отказ компонентов программного обеспечения не должен ставить под угрозу корректность и целостность БД. Пользователь должен иметь возможность повторно начать программу после отказа и найти информацию БД непротиворечивой и не повреждённой в результате отказа.
Система должна сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих внештатных ситуаций:
– при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС,
восстановление программы должно происходить после перезагрузки ОС и запуска Системы;
– при ошибках в работе аппаратных средств (кроме носителей данных и программ)
восстановление функций системы возлагается на ОС;
– при ошибках, связанных с программным обеспечением (ОС и драйверы устройств),
восстановление работоспособности возлагается на ОС.
Система должна обеспечивать корректную обработку ситуаций, вызванных недопустимыми и несогласованными значениями входных данных. В указанных случаях пользователю должны выдаваться соответствующие уведомления, после чего система должна возвращаться в рабочее состояние.
Для обеспечения устойчивости к отказам электроснабжения все устройства хранения и обработки информации должны быть подключены к электросети через источники бесперебойного питания.
4.1.5Требования безопасности
Все технические решения, использованные при создании системы, а также при определении требований к аппаратному обеспечению, должны соответствовать действующим нормам и правилам техники безопасности, пожаробезопасности и взрывобезопасности, а также охраны окружающей среды при эксплуатации.
4.1.6Требования к эргономике и технической эстетике
Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав системы должно осуществляться посредством визуального графического интерфейса (GUI).
Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм.
Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы.
15 КП-02068195-341-07-14
4.1.7Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
Система должна быть рассчитана на эксплуатацию в составе программно-технического комплекса Заказчика и учитывать разделение ИТ инфраструктуры Заказчика на внутреннюю и внешнюю. Техническая и физическая защита аппаратных компонентов системы, носителей данных, бесперебойное энергоснабжение, резервирование ресурсов, текущее обслуживание реализуется техническими и организационными средствами, предусмотренными в ИТ инфраструктуре Заказчика.
Для нормальной эксплуатации разрабатываемой системы должно быть обеспечено бесперебойное питание персональных компьютеров (ПК). При эксплуатации системы должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации ПК температура и влажность воздуха.
4.1.8Требования к защите информации от несанкционированного доступа
ИС должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего РД Гостехкомиссии России [6].
Разрабатываемая система должна обеспечивать разграничение доступа на уровне отдельных программных модулей и структур данных. Компоненты подсистемы защиты от НСД должны обеспечивать:
–идентификацию пользователя;
–проверку полномочий пользователя при работе с системой;
–разграничение доступа пользователей на уровне задач и информационных массивов.
Разрабатываемая система должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов).
4.1.9Требования по сохранности информации при авариях
Программное обеспечение Системы должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации автоматического и (или) ручного резервного копирования данных системы средствами системного и базового программного обеспечения (ОС, СУБД), входящего в состав программно-технического комплекса Заказчика.
Приведенные выше требования не распространяются на компоненты системы,
разработанные третьими сторонами и действительны только при соблюдении правил эксплуатации этих компонентов, включая своевременную установку обновлений,
рекомендованных производителями покупного программного обеспечения.
16 КП-02068195-341-07-14
4.1.10 Требования к защите от влияния внешних воздействий
Требования к защите от влияния внешних воздействий не предъявляются.
4.1.11 Требования к патентной чистоте
Установка системы в целом, как и установка отдельных частей системы не должна предъявлять дополнительных требований к покупке лицензий на программное обеспечение сторонних производителей, кроме программного обеспечения, указанного в разделе 4.3.4.
4.1.12 Требования по стандартизации и унификации
Система должна обеспечивать работу с почтовыми серверами, работающими по протоколу
SMTP.
4.1.13 Дополнительные требования
Специальные требования не предъявляются.
4.2 Требования к функциям, выполняемым системой
Функции, подлежащие автоматизации перечислены в модели вариантов использования.
Итерация 1 основана на простом консольном приложении, которое обеспечивает доступ к БД. В
ответ на регистрационное имя, посланное к БД электронной почты, приложение может извлечь из БД и показать список исходящих сообщений, которые могут быть отправлены деловым партнерам. После этого пользователь (служащий) может запросить автоматическую отправку выбранного исходящего сообщения. Когда сообщение будет успешно отправлено, БД соответствующим образом обновляется.
Последующие итерации учебного примера адресованы к более сложным средствам управления сообщениями электронной почты, содержащими текст и добавленные к сообщению неструктурированные (мультимедиа) документы, которые должны быть посланы.
Итерация 2 позволяет вводить новые исходящие сообщения в БД через GUI или другой допустимый в веб-технологии интерфейс. Она поддерживает также рассмотрение исходящих сообщений, основанное на различных фильтрах и критериях поиска.
Итерация 3 перемещает основной акцент логики приложений на БД и задает дополнительные бизнес-правила в БД, которым должно подчиняться приложение.
4.2.1Модель вариантов использования итерации 1
Итерация 1 предполагает, что сообщения к деловым партнерам уже размещены в БД ЕМ.
Итерация 1 системы предназначена для создания и передачи по электронной почте сообщений и для обновления БД данных после успешной передачи.
17 КП-02068195-341-07-14
Рис. 4.1 представляет диаграмму вариантов использования, предназначенную для представления цели, намеченных функциональных возможностей, предположений и упрощений итерации 1. Вариант использования «Создать сообщение» (Store Messages to Contacts) — вне возможностей итерации 1.
uc Use Case Model
Создать сообщение
Сотрудник
Просмотреть непосланные сообщения
Отобразить текст
сообщения Служащий отдела
работы с клиентами
Послать сообщение
Рис. 4.1. Диаграмма вариантов использования для первой итерации
Цель варианта использования «Создать сообщение» (Store Messages to Contacts) —
разместить в БД тему и текст сообщений по электронной почте к деловым партнерам и поручить отправку этих сообщений соответствующим «Служащим отдела работы с клиентами» (Customer Department Employee). Обычно этот вариант использования активизируется во время сбора и проверки данных о рекламных операциях и при подготовке сообщений об операциях для клиентов. Итерация 1 предполагает, что такие сообщения уже существуют в БД.
«Просмотреть непосланные сообщения» (View Unsent Messages) отвечает за показ списка,
содержащего основную информацию о сообщениях, сохраняемых в БД и запланированных для отправки по электронной почте. «Служащий отдела работы с клиентами» может пожелать
«Отобразить текст сообщения» (Display Message Text) перед принятием решения «Послать сообщение» (Email Message).
Как только сообщение будет успешно послано, «Послать сообщение» устанавливает флаг, что это произошло.
18 КП-02068195-341-07-14
4.2.2Спецификация вариантов использования итерации 1
4.2.2.1 Краткое описание, предусловия и постусловия
Краткое описание
Итерация 1 сценария использования Manage Email позволяет служащему отображать и посылать сообщения деловым партнерам по электронной почте. Она имеет дело только с сообщениями, уже размещенными в БД. Одновременно может быть передано по электронной почте только одно сообщение.
Предусловия
Служащий находится в отделе работы с клиентами или как-то иначе уполномочен Администратором обеспечивать ЕМ-приложение.
БД ЕМ содержит сообщения, которые нужно послать деловым партнерам по электронной почте.
Служащий связан с сервером электронной почты и уполномочен быть пользователем
БД.
Постусловия
Программа обновила БД ЕМ, чтобы отразить любую успешную передачу сообщений электронной почты.
БД ЕМ осталась в неповрежденном состоянии, если произошли какое-либо исключение или ошибка.
Как только служащий покинет приложение, консольное окно закрывается.
4.2.2.2 Основной поток
Функционирование сценария использования начинается, когда служащий желает просмотреть и отправить по электронной почте сообщения деловым партнерам.
Система отображает информационное сообщение и запрашивает у служащего имя пользователя (username) и пароль (password) (Рис. 4.2).
Рис. 4.2. Эскиз 1 интерфейса пользователь—компьютер
Система пытается соединить служащего с БД ЕМ.
После успешной связи приложение отображает список меню, содержащий возможные опции, которые может запросить служащий. В меню на рис. 8.4 имеются четыре последовательно пронумерованные опции:
19 КП-02068195-341-07-14
1. Просмотреть непосланные сообщения (View Unsent Messages) деловым партнерам
(см. ниже «SI — View Unsent Messages»);
2. Отобразить текст сообщения (Display Text of a Message), далее задается идентификатор сообщения (message id) (см. ниже «S2 — Display Text of a Message»);
3.Переслать сообщение по электронной почте (Email a Message), заданное идентификатором message_id (см. ниже «S3 — Email a Message»);
4.Завершить программу (Quit this Program).
Рис. 4.3. Эскиз 2 интерфейса пользователь-компьютер
Если служащий выбирает выход из ЕМ-приложения, печатая цифру 4, сценарий
использования завершает работу.
4.2.2.3 Подпоток S1 — View Unsent Messages (просмотр непосланных сообщений)
Информация, показанная в консольном окне, аналогична примеру на Рис. 4.4. Список меню представляется после того, как будет показано последнее непосланное сообщение.
20 КП-02068195-341-07-14
Рис. 4.4. Эскиз 3 интерфейса пользователь-компьютер
4.2.2.4 Подпоток S2 — Display Text of a Message (отображение текста сообщения)
Служащий должен ввести message_id перед тем, как будет показан текст этого сообщения.
Текст сообщения отображается так, как приведено на Рис. 4.5. Список меню заново показывается
ниже текста сообщения.
4.2.2.5 Подпоток S3 — Email a Message (передача сообщения по электронной почте)
Служащий должен определить, с каким message_id должно быть передано сообщение по электронной почте. Он печатает message_id сообщения, которое посылается по электронной почте, после чего БД обновляется. Информационное сообщение отображается в консольном окне после его успешной передачи, как показано на Рис. 4.6. Список меню заново показывается после того, как сообщение было послано.