note

31 КП-02068195-341-07-14

Служащие организации (Employees) готовят сообщения для рассылки в процессе проведения ежедневных бизнес-транзакций.

Отправку этих сообщений выполняют служащие отдела работы с клиентами (Customer Department Employees). Обычно эти действия выполняются во время сбора и проверки данных о рекламных операциях и при подготовке сообщений об операциях для клиентов. Служащие отдела работы с клиентами могут:

-просматривать список сообщений, предназначенных для отсылки, но ещё не отосланных;

-просматривать текст указанного сообщения;

-отсылать указанное сообщение по электронной почте.

3 Основные технические решения

3.1Архитектура системы

Система EM имеет двухуровневую клиент-серверную архитектуру (Рис. 3.1).

На уровне данных размещается подсистема хранения данных. Она содержит СУБД и БД.

На прикладном уровне размещается подсистема приложений. Она содержит байт-код

приложения, виртуальную Java-машину и библиотеку JavaMail API.

Подсистема хранения данных предназначена для хранения оперативных данных системы и данных для формирования аналитических отчетов.

Подсистема приложений предназначена для автоматизации процедур управления электронной почтой.

32 КП-02068195-341-07-14

Прикладной уровень

<<Client>> ПК

<<ByteCode>> *.class

<<JVM>> Java 6.0

<<Library>> JavaMail API

	<<Server>>
Уровень	Сервер БД
данных	<<DBMS>>
	Oracle 11g
	<<DataBase>>
	EMDB

Рис. 3.1. Диаграмма развёртывания

Функциональное деление компонентов программного обеспечения по слоям выполняется в

соответствии со структурным паттерном PCMEF+ (Рис. 3.2).

33 КП-02068195-341-07-14

<<layer>> presentation

aquaintance

<<layer>> control

	<<layer>>
entity	domain	mediator

<<layer>> foundation

Рис. 3.2. Структурный шаблон PCMEF

Слой presentation (представление) содержит классы, которые определяют GUI-объекты.

Слой control (управление) управляет запросами слоя presentation. Он состоит из классов,

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

Пакет entity (сущность) слоя domain (предметная область) имеет дело с запросами слоя control. Он содержит классы, представляющие «бизнес-объекты». Они хранят (в памяти) объекты,

извлеченные из БД или созданные с тем, чтобы поместить их в БД. Многие классы-сущности — контейнерные классы.

Пакет mediator (посредник) слоя domain устанавливает канал связи между классами пакетов entity и foundation. Такое посредничество обеспечивает две главные цели: во-первых, изолировать два пакета так, чтобы изменения в любом из них могли быть представлены независимо, и, во-

вторых, устранить потребность в классах control, чтобы связаться непосредственно с классами foundation всякий раз, когда должны быть извлечены из БД новые объекты пакета entity (такие запросы от классов пакета control затем передаются через классы пакета mediator).

Слой foundation (основание) отвечает за все коммуникации с БД. Здесь формируются запросы к сохраняемым данным и инициируются транзакции БД.

34 КП-02068195-341-07-14

Пакет acquaintance - пакет знакомств — это автономный пакет, состоящий только из интерфейсов. Он не представляет ни слой, ни часть иерархии слоёв. Пакет acquaintance

группирует интерфейсы как для восходящих связей, так и для нисходящих связей с несоседними объектами.

Информационный обмен между компонентами системы

Входящие в состав EM подсистемы в процессе функционирования должны обмениваться информацией на основе открытых форматов обмена данными по протоколам на основе TCP/IP.

Форматы данных будут разработаны и утверждены на этапе технического проектирования.

3.2 Решения по взаимосвязям со смежными системами

Система взаимодействует с почтовым сервером организации. Первая версия системы предусматривает только отсылку по электронной почте сообщений, хранящихся в БД.

3.3Решения по режимам функционирования, диагностированию работы системы

В работе системы можно выделить следующие режимы работы:

1)Работа неавторизованного пользователя

2)Работа авторизованного пользователя

3)Аварийный режим

Специальных процедур диагностирования состояния компонентов системы не предусмотрено.

3.4Решения по численности, квалификации и функциям персонала, режимам его работы, порядку взаимодействия

ЕМ — многопользовательское приложение.

Авторизация пользователя и его права доступа к различным средствам приложения управляются централизованно из БД, которая соединена с прикладной программой.

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

3.5Сведения об обеспечении заданных в ТЗ потребительских характеристик системы, определяющих ее качество

3.5.1Временные характеристики

Время отклика для подпотоков S1 (Просмотреть непосланные сообщения) и S2 (Отобразить

текст сообщения) с 90-процентной вероятностью будет меньше 5 секунд за счет использования

35 КП-02068195-341-07-14

высокопроизводительной СУБД - Oracle 11g Standard Edition, которая обеспечивает работу 4-х

сокетов.

Время отклика для подпотока S3 (Послать сообщение) с 90-процентной вероятностью будет меньше 10 секунд для сообщений электронной почты, не превышающих 1 мегабайт в размере

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

MS Exchange Server 2007 Standard Edition, средств библиотеки JavaMail API и скоростью сети 100

Мбит/с.

3.5.2Надёжность

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

3.5.3Эргономика и техническая эстетика

Требования эргономичности и технической эстетики начиная со 2-ой итерации будут обеспечены использованием набора компонентов Swing библиотеки классов Java Foundation Classes (JFC).

3.5.4Защищенность информации

Защита от несанкционированного доступа обеспечивается в системе EM за счёт парольной аутентификации Пользователя при входе в систему и разделением прав доступа для двух классов пользователей:

1)Сотрудник;

2)Служащий отдела работы с клиентами.

Для восстановления работоспособности системы после сбоев предусмотрено резервное копирование БД средствами СУБД Oracle 11g.

3.6Состав функций, реализуемых системой

На диаграмме вариантов использования (Рис. 3.3) приведены функции системы.

36 КП-02068195-341-07-14

uc Use Case Model

Создать сообщение

Сотрудник

Просмотреть непосланные сообщения

Отобразить текст

сообщения Служащий отдела

работы с клиентами

Послать сообщение

Рис. 3.3. Диаграмма вариантов использования

Итерация 1 системы рассматривает только варианты использования для Служащего отдела работы с клиентами:

1.Просмотреть непосланные сообщения.

2.Отобразить текст сообщения.

3.Послать сообщение.

3.7Решения по комплексу технических средств

В соответствии с ТЗ:

1)в качестве сервера БД будет использован компьютер, имеющийся у AEM-организации, и

установленный в специальном серверном помещении;

2)в качестве ПК пользователей будут использованы компьютеры установленные в настоящее время на рабочих местах Сотрудников;

3)все компьютеры объединены локальной вычислительной сетью с пропускной способностью 100 Мбит/с.

Характеристики сервера

–процессор – 2 х Intel Xeon 3 ГГц;

–объем оперативной памяти – 16 Гб;

–дисковая подсистема – 4 х 146 Гб;

–устройство чтения компакт-дисков (DVD-ROM);

37 КП-02068195-341-07-14

– сетевой адаптер – 100 Мбит/с.

Минимальные характеристики для ПК пользователя

–процессор – Intel Pentium 1.5 ГГц;

–объем оперативной памяти – 256 Мб;

–дисковая память – 40 Гб;

–сетевой адаптер – 100 Мбит/с.

3.8Решения по информационному обеспечению

Компонентом информационного обеспечения является системная БД «EM».

Итерация 1 ЕМ предполагает, что БД существует заранее и загружена данными

относительно служащих, деловых партнеров и исходящих сообщений. Прикладная программа ЕМ извлекает эту информацию из БД, готовит и посылает электронные сообщения (исходящие сообщения) и корректирует БД, чтобы отметить, какие исходящие сообщения уже были по-

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

3.8.1Логическая модель БД

На основе Концептуальной модели предметной области, приведённой в ТЗ (п. 3.2) была получена логическая модель реляционной БД (Рис. 3.4).

	Employee
employee_id	<pi> Characters (4)	<M>
first_name	Variable characters (20)
family_name	Variable characters (40)	<M>
login_name	Variable characters (40)	<M>
employee_email	Variable characters (60)	<M>
Key_1 <pi>

		Contact
contact_id		<pi> Characters (5)	<M>
organization		Variable characters (80)
first_name		Variable characters (20)
family_name		Variable characters (40)	<M>
contact_email		Variable characters (60)
Key_1	<pi>

			for
		OutMessage
	message_id	<pi>	Integer	<M>
creator	conact_id	<fi1>	Characters (5)	<M>
	creator_emp_id	<fi2>	Characters (4)	<M>
	sender_emp_id	<fi3>	Characters (4)
	message_subject		Variable characters (40)	<M>
sender	message_text		Variable characters (255)	<M>
	date_created		Date & Time	<M>
	date_emailed		Date & Time
	Key_1 <pi>

Рис. 3.4. Логическая модель БД EM

Каждому концептуальному классу поставлена в соответствие таблица:

1)таблица Employee – предназаначена для хранения данных о служащих

AEM-организации;

38 КП-02068195-341-07-14

2)таблица Contact – предназаначена для хранения данных о деловых партнёрах

AEM-организации;

3)таблица OutMessage – предназаначена для хранения сведений об исходящих сообщениях.

3.8.2Физическая модель БД

Рис. 3.5 представляет физическую модель БД, полученную из логической модели,

изображенной на Рис. 3.4.

	Employee
employee_id	CHAR(4)	<pk>	not null
first_name	VARCHAR2(20)		null
family_name	VARCHAR2(40)		not null
login_name	VARCHAR2(40)	<i>	not null
employee_email	VARCHAR2(60)		not null
login_UN <i>

employee_id = creator_emp_id
employee_id = sender_emp_id	0..*
	0..*

	Contact
contact_id	CHAR(5)	<pk> not null
organization	VARCHAR2(80)	null
first_name	VARCHAR2(20)	null
family_name	VARCHAR2(40)	not null
contact_email	VARCHAR2(60)	null

	contact_id = conact_id
	0..*
	OutMessage
message_id	INTEGER	<pk>	not null
conact_id	CHAR(5)	<fk1>	not null
creator_emp_id	CHAR(4)	<fk2>	not null
sender_emp_id	CHAR(4)	<fk3>	null
message_subject	VARCHAR2(40)		not null
message_text	VARCHAR2(255)		not null
date_created	DATE		not null
date_emailed	DATE		null

Рис. 3.5. Физическая модель БД EM

Модель определяет физические характеристики (индексы) и использует типы данных конкретной СУБД - Oracle 11g.

Кроме неявных индексов на первичных ключах определен дополнительный уникальный индекс (login_UN) на login_name в таблице Employee. Этот индекс используется, чтобы засвидетельствовать, что пользователь программы работает под login_name БД, который внесен в список таблицы Employee. Такой пользователь рассматривается как законный служащий,

уполномоченный использовать систему EМ.

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

Таблица 3.1 – Структура таблицы Employee (Сотрудник)

			Тип	Обязат.	Нач. знач.	Только для
	Имя поля (Code)	Название (Name)		(null/		чтения
			(Data Type)		(Initial Value)
				not null)		(Read-only)

39 КП-02068195-341-07-14

employee_id		Код сотрудника	Char(4)		not null		FALSE
first_name		Имя	Varchar2(20)		null		FALSE
family_name		Фамилия	Varchar2(40)		not null		FALSE
login_name		Логин	Varchar2(40)		not null		FALSE
employee_email		Эл. почта	Varchar2(60)		not null		FALSE
Таблица 3.2 – Структура таблицы Contact (Деловой партнёр)
			Тип		Обязат.	Нач. знач.	Только для
Код (Code)		Название (Name)			(null/		чтения
			(Data Type)			(Initial Value)
					not null)		(Read-only)
contact_id	Код делового партнёра		Char(5)		not null		FALSE
organization	Организация		Varchar2(80)		null		FALSE
first_name	Имя		Varchar2(20)		null		FALSE
family_name	Фамилия		Varchar2(40)		not null		FALSE
contact_email	Эл. почта		Varchar2(60)		null		FALSE
Таблица 3.3 – Структура таблицы OutMessage (Исходящее сообщение)
			Тип		Обязат.	Нач. знач.	Только для
Код (Code)		Название (Name)			(null/		чтения
			(Data Type)			(Initial Value)
					not null)		(Read-only)
message_id	Код сообщения		Integer		not null		FALSE
contact_id	Код делового партнёра		Char(5)		not null		FALSE
creator_emp_id	Код создателя сообщения		Char(4)		not null		FALSE
sender_emp_id	Код отправителя сообщения		Char(4)		null		FALSE
message_subject	Тема сообщения		Varchar2(40)		not null		FALSE
message_text	Текст сообщения		Varchar2(255)		not null		FALSE
date_created	Дата создания		Date		not null		FALSE
date_emailed	Дата отправки		Date		null		FALSE

3.9 Решения по программному обеспечению

Проектные решения по программному обеспечению представлены проектом классов

(диаграмма классов и описание полей и методов классов), моделью инициализации объектов

(диаграмма инициализации) и моделью взаимодействия (диаграммы последовательности).

3.9.1Классы

Врезультате детального проектирования, получены следующие классы:

3.9.1.1 acquaintance.IAConstants

Интерфейс IAConstants (константы) используется для хранения констант системы.

Поля интерфейса:

String DB_DRIVER - Драйвер в формате, указанном поставщиком БД. Используется

Oracle.

String DB_URL - JDBC URL для БД.

int MAX_MESSAGE - Предельное число сообщений, которые могут быть отображены.

String SMTP_ADDRESS - SMTP-адрес для передачи по электронной почте.

40 КП-02068195-341-07-14

3.9.1.2 acquaintance.IAEmployee

Интерфейс acquaintance.IAEmployee (служащий) реализуется классом entity.EEmployee.

Объект EEmployee представляет текущего пользователя ЕМ-приложения.

Методы интерфейса:

String getEmail() - Получение электронного адреса служащего.

String getEmployeeID() - Получение идентификатора служащего.

String getFamilyName() - Получение фамилии служащего.

String getFirstName() - Получение имени служащего.

String getLoginName() - Получение регистрационного имени служащего.

Collection getUnsentOutMessages(int numMsgRetrieve) - Получение всех сообщений

(вплоть до numMsgRetrieve — число извлеченных сообщений), предназначенных этому

служащему.

void removeSentOutMessage() - Удаление сообщения из списка этого служащего,

вероятно, потому, что оно уже послано.

void setEmail(java.lang.String email) - Задание электронного адреса служащего.

void setEmployeelD(java.lang.String id) - Задание идентификатора служащего.

void setFamilyName(java.lang.String familyName) - Задание фамилии данного служащего.

void setFirstName(java.lang.String fname) - Задание имени данного служащего.

void setLoginName(java.lang.String login) - Задание регистрационного имени служащего.

3.9.1.3 acquaintance.IAContact

Интерфейс acquaintance.IAContact (деловой партнер) реализуется классом entity.Econtact.

Объект EContact представляет бизнес-сущность, которой может быть послано исходящее сообщение.

Методы интерфейса:

String getContactID() - Получение идентификатора делового партнера.

String getEmail() - Получение электронного адреса делового партнера.

String getFamilyName() - Получение фамилии делового партнера.

String getFirstName() - Получение имени делового партнера.

String getOrganization() - Получение организации, которой принадлежит данный деловой партнер.

Collection getUnsentOutMessages(int numMsgToBeRetrieved) - Получение всех исходящих сообщений, предназначенных данному деловому партнеру.

void removeSentOutMessage(IAOutMessage msg) - Удаление исходящего сообщения,

предназначенного данному деловому партнеру, вероятно, потому, что оно уже послано.

void setContactID(java.lang.String contactID) - Задание идентификатора делового партнера.