Телефонная связь

     Начнем  объектно-ориентированный анализ и  проектирование информационной системы данной коммерческой службы с рассмотрения модели бизнес-процесса. 

     2.3.1. Диаграмма бизнес-процесса

     Модель  бизнес процесса (Business Process Model) представляет собой совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Иное название этой модели – модель Эрикссона-Пенкера. Метод Эриксона-Пенкера представляет интерес, прежде всего, в связи с попыткой применения языка объектного моделирования UML (изначально предназначенного для моделирования архитектуры систем программного обеспечения) для моделирования бизнес-процессов. Это стало возможным благодаря наличию в UML механизмов расширения. Для наглядного просмотра работы коммерческой службы телефонной компании воспользуемся диаграммой бизнес-процессов.

     

     Рис. 9. Диаграмма бизнес-процесса деятельности коммерческой службы телефонной компании

     На  диаграмме можно наблюдать процесс  «Отслеживание стоимости междугородних телефонных переговоров», входными данными которого будет являться информация о тарифах, а выходными – отчеты о предоставлении скидок и со статистикой о звонке. При выполнении данного процесса будет происходить обращение к базе данных, которая содержит информацию о клиентах, статистике совершенных ими звонков. Целью отслеживания стоимости междугородних телефонных переговоров является повышение качества обслуживания (рис 9). 
 
 

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

     На  основе функциональных требований была разработана диаграмма вариантов использования (Use Case Model).  Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто диаграмму вариантов использования называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.

     Диаграммы вариантов использования описывают  функциональное назначение системы  или то, что система должна делать. Разработка диаграммы преследует следующие цели:

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

 

     Рис. 10. Диаграмма вариантов использования деятельности отдела учета стоимости телефонных переговоров

     На  диаграмме изображен актер «Менеджер компании», который просматривает предоставленную информацию о клиенте и о совершенном им вызове. Так же на диаграмме представлены отношения между вариантами использования. Например, вариант использования «Расчет стоимости переговоров» является базовым и может быть расширен вариантом использования «Предоставление скидки» при разговоре более определенного количества времени, в зависимости от времени суток и т.д. (рис. 10). Отношение расширение показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. 

     2.3.3. Диаграмма классов  анализа

     Класс анализа – еще более абстрактная  сущность, чем просто класс, представляет собой набор из одного или более  классов. Таким образом, класс анализа  – это укрупненная абстракции, которая на концептуальном уровне (без точного определения атрибутов и операций) описывает некоторый фрагмент системы.

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

     В качестве примера рассмотрим диаграмму  классов анализа процесса просмотра информации о длительности звонка (рис. 11).

     

     Рис. 11. Диаграмма классов анализа процесса просмотра информации о длительности переговоров

     На  диаграмме изображен менеджер компании, который с помощью формы детализации  переговоров вносит данные о клиентах в базу данных. В данном случае «Форма детализации переговоров» представляет собой граничный класс, «Диспетчер БД» – управляющий класс, а «Клиенты» – класс-сущность.

     Аналогичным образом были смоделированы процессы просмотра информации о клиенте, времени суток, местонахождении абонента (см. приложения 1-3). 

     2.3.4. Диаграмма последовательности

     Диаграмма последовательностей (Sequence Diagram) используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями.

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

  

     Рис. 12. Диаграмма последовательности процесса просмотра информации о длительности переговоров

     На  данной диаграмме последовательности менеджер компании заполняет форму через граничный класс «Форма детализации переговоров». После этого менеджер запрашивает информацию о длительности переговоров из сущности «Клиенты». Данный запрос формируется диспетчером базы данных. Далее диспетчер предоставляет полученную информацию менеджеру компании (рис. 12).

     Аналогичным образом были смоделированы процессы просмотра информации о клиенте, времени суток, местонахождении абонента (см. прил. 1-3). 

     2.3.5. Диаграмма деятельности

     Диаграммы деятельностей (Activity Diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей. Это частный случай диаграммы состояний. На ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы. Они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами.

     

Рис. 13. Диаграмма деятельности процесса работы программы учета и отслеживания телефонных переговоров

     На  диаграмме деятельности показан  процесс работы программы отслеживания стоимости звонка (рис. 13). В начале процесса программа отслеживает звонок. После этого происходит поиск абонента по базе данных. Если раньше он совершал звонки через эту телефонную компанию, то происходит обновление данных. В противном случае идет регистрация абонента в базе данных. Потом идет анализ полученных данных о звонке, по которым определяется предоставлять абоненту скидку или нет. Далее программа рассчитывает стоимость совершенного вызова. 

     2.3.6. Диаграмма классов

     Центральное место в объектно-ориентированном  программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (Class Diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.

     Диаграмма классов для коммерческой службы телефонной компании может выглядеть  следующим образом (рис. 14):

 

     Рис. 14. Диаграмма классов коммерческой службы телефонной компании

     На  диаграмме представлено 4 класса: «Абонент», «Переговоры», «Город», «Скидка». Каждый из них имеет свой набор атрибутов и операций. Все классы являются классами-сущностями. Класс «Переговоры» связан с классами «Абонент» и «Город» связями типа ассоциация и связан по средствам агрегации с классом «Скидка».

     Таким образом, можно сделать вывод, что  детальный анализ сферы деятельности предприятия позволяет достичь  максимальной производительности и создает возможность автоматизировать производство в данной сфере. В данном случае внедрение программного обеспечения в производство увеличивает эффективность работы коммерческой службы телефонной компании, что позволяет клиентам данной фирмы чаще прибегать к услугам этой телефонной компании в связи с удобством обслуживания. А также это избавит специалистов от ручной обработки информации и как следствие повысит производительность труда. 
 
 
 
 
 
 
 
 
 
 
 
 
 

     Заключение

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

     Широкое распространение в этой области  получил подход САSЕ. С помощью CASE-средств создаются информационные системы и информационные технологии, позволяющие отделить и автоматизировать процесс проектирования информационной системы от последующих этапов разработки. Использование САSЕ-технологий существенно изменяет технологию работ на этапах анализа, проектирования и модернизации информационной системы. Применяемые в САSЕ-технологиях методы успешно используются при создании моделей систем для решения задач стратегического управления, планирования, прогнозирования и т.п.

     В данной курсовой работе была спроектирована информационная система для коммерческой службы телефонной компании, позволяющая отследить основные процессы работы телефонной компании. Эти процессы были реализованы при создании функциональной, структурной и объектно-ориентированной моделей системы.

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

     В результате анализа построения структурной модели базы данных телефонной компании была выявлена логическая структура информационной системы.

     После анализа объектно-ориентированной модели и проектирования информационной системы были выполнены следующие задачи:

• построили модель (определили правила, необходимые для функционирования системы);
• определили требования к системе (описали функциональные и нефункциональные требования проектируемой информационной системы);
• провели анализ информационной системы телефонной компании.

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

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

Список  использованной литературы

1. Грекул, В. И. Проектирование информационных систем: курс лекций [Текст]/ В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина. – М.: Интернет-университет информационных технологий, 2005. – 304 с.
2. Группа компаний FUJITSU [Электронный ресурс]: http://www.icl.ru
3. Иванов, Д. Ю. Унифицированный язык моделирования UML [Текст]/ Д. Ю. Иванов, Ф. А. Новиков. – СПб.: Изд-во Политехнического университета, 2010. – 249 с.
4. Каммел, П. UML. Основы визуального анализа и проектирования. Универсальный язык программирования [Текст]/ П. Каммел; пер. с англ. Е. А.  Кедрова – М.: НТ ПРЕСС, 2008. – 272 с.
5. Леоненков, А. В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose [Текст]/ А. В. Леоненков. – М.: БИНОМ, 2006 – 320 с.
6. Максимчук, Р. Проектирование БД с помощью UML [Текст]/ Р. Масимчук, Э. Нейбург. – М.: Вильямс, 2002. – 288 с.
7. Скотт, К. Основные концепции UML [Текст]/ К. Скотт. – М.: Вильямс, 2002. – 144 с.
8. Трофимов, С. А. CASE-технологии. Практическая работа в Rational Rose [Текст]/ С. А. Трофимов. – М.: БИНОМ, 2001. – 272 c.
9. Якобсон, А. Унифицированный процесс разработки программного обеспечения [Текст]/ А. Якобсон, Г. Буч, Дж. Рамбо. – СПб.: Питер, 2002 – 496 с.