Разработка системы рассылки СМС сообщений

Министерство образования и  науки Российской федерации

Федеральное агентство по образованию

Государственное образовательное  учреждение высшего профессионального  образования «Алтайский государственный  технический университет им. И. И.Ползунова»

Факультет инженерной педагогики и информатики

Кафедра систем автоматизированного проектирования

 

Отчет защищен с оценкой ________________

Преподаватель __________________________

(подпись)

«________» ____________________ 20___ г.

Разработка системы рассылки СМС  сообщений

Пояснительная записка к курсовому проекту

По дисциплине Объектно-ориентированное программирование

Студент группы 7САПР(с)-01 А.Н. Непомнящев

Руководитель  проекта Л. Ю. Качесова

Барнаул 2011

 

Содержание

Введение 2

1. Описание предметной области 3

1.1. Предметная область курсового проекта 3

1.2. Информационно-логическая модель предметной области 3

2. Создание приложения SmsMessenger 6

2.1.  Логическое проектирование 6

2.2. Модель данных 7

2.3. Описание представлений и представителей 8

3. Тестирование программы 17

Заключение 25

Список литературы 26

Приложение А. Задание на курсовой проект 27

Приложение Б. Структура исходных файлов 28

Приложение В. XAML код всех представлений и библиотек ресурсов 30

Приложение Г. Код классов программы. 62

 

 

Введение

В работе куратора группы 7САПР(С)-01 требуется организовать оповещение студентов о важных событиях. На то чтобы обзвонить каждого студента индивидуально уходит много времени, поэтому возникла необходимость в создании приложения для SMS рассылки, которое автоматизирует процесс рассылки SMS, и будет производить хранение контактной информации по студентам, а так же шаблоны SMS сообщений.

Целью курсовой работы является автоматизация рассылки SMS сообщений, для ускорения и облегчения работы по оповещению студентов.

Задачей, для достижения данной цели является создание приложения SmsMessenger, которое будет производить автоматизацию рассылки SMS.

 

1. Описание  предметной области

Предметной областю данного  курсового проекта является массовая SMS рассылка. Приложение разрабатывается для куратора группы 7САПР(с)-01.

1. Предметная  область курсового проекта

Приложение использует для  работы куратора группы 7САПР(с)-01. Периодически возникает необходимость оповещать студентов о предстоящих мероприятиях: например дату начала сессии. Для того чтобы сообщить каждому студенту нужную информацию куратор обзванивает каждого студента по списку.

1. Выходная информация в системе;
2. Виды запросов информационной системе;
3. Вывести список студентов;
4. Вывести список групп;
5. Вывести список студентов по группам;
6. Вывести студентов из выбранных групп;
7. Вывести список шаблонов SMS;
8. Вывести списки рассылки;
9. Вывести сообщения SMS для указанных номеров на SMS шлюз.

Входная информация в системе

1. Ввод данных по группе;
2. Ввод данных по студенту;
3. Ввод шаблонов смс;
4. Формирование списка рассылки.

2. Информационно-логическая модель предметной области

Для разработки информацинно-логической модели (ER-модели) используется нотация IDEF1. Полученная ER-модель изображена на рисунке1.

ID контакта

Имя

Фамилия

Номер

Номер телефона

Номер сотового

День рождения

Фото

Группа

Адрес

ID группы

Название

Год начала обучения

Год окончания обучения

ID шаблона

Название

Текст

ID группы шаблонов

Название

ID списка рассылки

Название списка

ID контакта

ID списка рассылки

 

 

 

ID сообщения

 

Список рассылки

Шаблон SMS 

 

 

  

 

Группы  шаблонов

Шаблоны SMS

Списки рассылки

Группы

Контакты

Записи рассылка

Сообщения для отправки

R-1

R-2

R-3

R-4

R-5

R-6

Рисунок 1

Из предметной области  выделяются следующие сущности: Контакты, группы, шаблоны СМС сообщений, группы шаблонов, списки рассылки, рассылка, сообщения  для отправки. Тип сущности определяется исходя из типа связи. Рассмотрим связь R-1: сущность Группы является родительской по отношению к сущности контакты. Кроме того она не является дочерней ни для одной другой сущности, выделенной в предметной области. Такая сущность является независимой, а дочерняя сущность контакты – зависимой. Связь между группами шаблонов и шаблонами СМС является аналогичной.

Связи R-1, R-3, R-4 – это связи 1:М (один ко многим), а связи R-2, R-5 и R-6 – 1:1.

Каждый контакт может  состоять только в 1-й группе, в то время как группа может содержать  множество контактов. Аналогично обстоят  дела с отношением группы шаблонов к шаблонам СМС. Списки рассылки так  же могут содержать множество  записей которые в свою очередь  могут содержать ссылку на контакт. Исходящее СМС сообщение в  конечном итоге формируется из шаблона  сообщения и записи из списка рассылки.

Для определения конкретных экземпляров сущностей вводятся идентифицирующие атрибуты. На рисунке 1 они расположены над горизонтальной линией, разделяющей атрибуты сущности. В данном случае идентифицирующим атрибутом  всех сущностей является ID и только у сущности запись списка рассылки, идентифицирующий атрибут – составной.

 

2. Создание приложения SmsMessenger

2.1.  Логическое проектирование

Приложение SmsMessenger разработано с использованием технологии Windows Presentation Foundation (WPF) на языке C# в среде Visual Studio 2010.

При проектировании инфраструктуры приложения использовался паттерн  MVP (Model-View-Presenter). Суть данного подхода заключается в разделении приложения на 3 логические части:

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

Сердцем программы является класс ApplicationPressenter, который отвечает за все основные операции и создание представлений и других представителей.

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

Отправка SMS сообщений осуществляется через SMS шлюз: smsc.ru.

Шлюз принимает на себя GET-запрос, который формирует приложение SmsMessenger, затем после удачной, или неудачной отправке SMS сообщения smsc.ru высылает ответ с кодами результатов выполнения операции. После этого SmsMessenger выводит отчет о результатах отправки.

2. Модель  данных

При создании модели данных каждая сущность, описанная на рисунке 1, превращается в класс, полями которого являются атрибуты сущности. В приложении SmsMessenger были определены следующие классы модели:

Рисунок 2

Кроме упомянутых выше, классов  написанных «из сущностей», были созданы  вспомогательные классы SendSmsReport – класс который хранит данные для отчета об отправке сообщений, а так же класс LogEvent который, используется при отображении лога приложения.

Для обработки операций с  данными были разработаны классы-репозитарии, которые обеспечивают загрузку, сохранение, поиск и другие операции с данными. Диаграмма классов репозитариев изображена на рисунке 3

Рисунок 3

Сохранение  информации производится по средствам  стандартной сериализации в .NET. Данные сохраняются в файлы с расширением .source, при всех операциях связанных с созданием и редактированием данных. Загрузка данных производится при запуске приложения.

3. Описание  представлений и представителей

При запуске  приложения происходит загрузка представления  Sehll.xaml. На Shell.xaml размещены 3 ExpandPanel в которые помещаются контролы(User Controls) отвечающие за отображение списка контактов, списка рассылок и списка шаблонов SMS. Главное меню так же выполнено в виде User Control (Рисунок 4).

Рисунок 4

• SideBar.xaml – контакты;
• DistributionTreeBar.xaml – список рассылки;
• SmsTemplateBar.xaml – список шаблонов;
• Menu.xaml – главное меню;

Кроме указаных выше контролов  в Shell.xaml расположен TabControl, который служит для отображения «дочерних» представлений, каждое из которых создается на отдельной вкладке.

Диаграмма класса Shell представлена на Рисунок 5

Рисунок 5

Рассмотрим основные методы класса Shell

• AddTab<T>: принимает на себя параметром экземпляр представителя и создает вкладку на TabControl присваивая для DataContext у вкладки - экземпляр полученного представителя, а в качестве свойства вкладки Content – представление связанное с полученным представителем. При создании вкладки проверяется существует ли уже такая вкладка, и если вкладка существует, то создание новой (дублирующей вкладки) отменяется.
• RemoveTab<T>: удаляет вкладку, если такая вкладка существует.

При создании экземпляра класса Shell так же создается экземпляр класса-представителя ApplicationPresenter (Рисунок 6)

Рисунок 6

ApplicationPresenter является главным представителем и выполняет является посредником между другими представителями и классами-модели, обеспечивая операции по созданию, редактированию и удалению данных.

Когда пользователь инициирует какое-либо событие требующее обработки  данных, то представление вызывает метод своего представителя, который в свою очередь «знает» как обратится к главному представителю, и передать ему данные для обработки. После этого ApplicationPresenter передает данные нужному репозитарию, который производит требуемую обработку. Мы имеем некую цепочку, по которой данные должны дойти до репозитария прежде чем будут сохранены или обновлены, что на первый взгляд кажется не совсем удобным. Но при этом достигается независимость работы отдельных частей программы, каждая из которых предназначена только для своих задач. Например, представление используется только для визуализации данных и не коем образом не «знает» как эти данные должны обрабатываться. Все, что должно уметь делать представление – это вызывать нужные методы представителя. Представитель, в свою очередь, обладает властью лишь над своим типов данных. Так представитель EditContactPresenter имеет при себе только экземпляр редактируемого контакта. Все что нужно знать представителю EditContactPresenter - это то, как передать контакт для отображения и куда передавать контакт для сохранения. Подобная инфраструктура приложения позволяет добиться независимости работы отдельных «частей», разделяя логику работы. Этот подход позволяет приложению быть более гибким и легко расширяемым.

Рассмотрим представителей более подробно (Рисунок 7):

• PresenterBase: предок для всех шаблонов, содержит в себе такие важные свойства как ссылка на представление и заголовок для закладки на которой будет отображено представление;
• EditConfigPresenter: предназначен для работы с настройками приложения
• EditContactPresenter: предназначен для создания и редактирования контактов;
• EditDistributionListPresenter: предназначен для редактирования списков рассылки;
• EditSmsTemplateGroupPresenter: предназначен дляредактирования групп сиписков рассылки;
• EditSmsTemplatePresenter: предназначен для редактирования шаблонов SMS сообщений;
• EditGroupPresenter: предназначен для редактирования групп;
• LogPresenter: предназначен для отображения лога программы;
• SendSmsByListPresenter: данный представитель осуществляет подготавливает сообщение для отправки по списку рассылки;
• SmsSendReportPresenter: представитель для отображения отчета после отправки сообщения.

 

Рисунок 7

Рассмотрим механизм создания новой вкладки на примере представителя  редактирования группы:

Процесс создание или редактирование группы начинается с вызова метода OpenGroup, представителя ApplicationPresenter. В данный метод параметром передается экземпляр класса Group, новый, или уже существующий. В методе OpenGroup проверяется, является ли группа пустой, и если нет, то со свойства View вызывается метод AddTab (у ApplicationPresenter свойством View является Shell).  В метод AddTab параметром передается новый экземпляр представителя EditGroupPresenter конструктор, которого в свою очередь принимает параметрами ссылку на главный представитель ApplicationPresenter, новый экземпляр представления EditGroupView и сам экземпляр редактируемой группы.

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

Как отмечалось выше, сформированный экземпляр EditGroupPresenter отправляется в метод AddTab класса Shell. В методе AddTab проверяется, есть ли уже вкладка, на которой редактируется группа с таким же ID, как и в только что сформированном EditGroupPresenter. Если такой вкладки еще нет, то она создается. Далее происходит биндинг названия вкладки с нужным свойством представителя, в данном случае это название группы. В качестве DataContext созданной вкладки используется переданный экземпляр EditGroupPresenter, а в содержание вкладки идет свойство View у нашего экземпляра EditGroupPresenter, в качестве которого выступает экземпляр EditGroupView. После этого новая вкладка вставляется в TabControl и пользователь может увидеть новую вкладку, в которой будет отображен интерфейс для редактирования группы.