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

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

Содержание

Введение

Глава 1. Имитационное моделирование деятельности "Центра обслуживания абонентов"

1.1 Диаграммы потоков данных

Глава 2. Проектирование системы "обслуживание абонентов"

2.1 Выявление вариантов использования

2.1.1 Выделение субъектов (актеров) и прецедентов (видов деятельности)

2.1.2 Документирование прецедентов

2.1.3 Диаграмма прецедентов

2.2 Выявление классов - сущностей

2.3 Моделирование видов деятельности

2.4 Моделирование взаимодействий

2.5 Моделирование состояний

2.6 Проектирование статической структуры

2.7 Проектирование пользовательского интерфейса

2.8 Диаграмма компонентов

2.9 Проектирование архитектуры приложения

Заключение

Глоссарий

Библиография

Введение

Сегодня нет такого вида электросвязи, который развивался бы столь быстро, как беспроводная радиотелефония, и особенно сотовая связь, обслуживающая подвижных пользователей. Число таких пользователей ежегодно увеличивается где-то на 40% и недавно уверенно перешагнуло 350-миллионный рубеж. Следует заметить, что отдельные разновидности сотовых сетей подвижной связи показывают еще более впечатляющие темпы роста.

С момента, когда сотовые сети вышли из стадии научно-технических разработок на коммерческий рынок (рубеж 70-80-х годов), прошло не так уж много времени, сотовый телефон ныне перестал быть символом престижа и стал инструментом, позволяющим более эффективно использовать рабочее время, оперативно управлять технологическими, экономическими и другими процессами. Сотовые сети при этом не только растут вширь, но и неуклонно наращивают количество предоставляемых дополнительных услуг.

Если взять плотность сотовых сетей, которой достигли многие развитые страны, то бесспорным лидером среди них является Финляндия, где около 70% населения имеют сотовые телефоны. Немного отстают от нее соседи по Скандинавии (от 50 до 60%), между которыми вклинился кусочек КНР (бывший Гонконг). Ещё шесть стран, включая Австралию и Японию, перешагнули 30% -ный рубеж, а целая группа стран, в том числе Великобритания и США, вплотную к нему приблизилась. Примерно 20% -ные показатели имеют Германия, Франция, Испания, Канада и ряд других стран. Впрочем, можно еще долго перечислять успехи подвижной связи, но и уже приведенной информации достаточно, чтобы сделать некоторые выводы.

Все сказанное выше свидетельствует о том, что в большинстве этих стран плотность радиотелефонных линий уже достигла уровня плотности линий традиционной телефонии (примерно 50-60%) или составила весьма обширные территории, либо очень многочисленные население, либо и то, и другое одновременно. Поэтому даже 5% в Бразилии и 3% в КНР без учета Гонконга (какая маленькая цифра и одновременно чудовищно большое число пользователей) оказывается весомее, чем, например, 27% где-нибудь в Голландии. В общем, сотовая связь уже стала продуктом массового потребления и продолжает наращивать темпы роста.

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

Бурно развивающийся мировой рынок услуг сотовой связи привлекает внимание многих компаний. Например, только в России в этот бизнес вовлечено около двухсот компаний - операторов. Все убыстряющиеся темпы развития общества настоятельно требуют получения более персональных услуг, а именно: возможности телефонного разговора (и не только) с любым абонентом, в любом месте и в любое время.

Глава 1. Имитационное моделирование деятельности "Центра обслуживания абонентов"

Сотовая связь - это разновидность высокоподвижной радиосвязи, отличающаяся прежде всего массовостью обслуживания абонентов на ограниченной территории. При этом исторически сложилось так, что сотовая связь постепенно расширяла сферу обслуживания телефонной сети общего пользования (ТфОП). Вообще-то, сам термин "сотовая связь - это общепринятое сокращенное наименование услуги, получаемой с помощью развернутых сотовых сетей подвижной связи, выполненных на базе соответствующих систем. Таким образом, этот термин характеризует именно подвижную связь.

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

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

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

В данной дипломной работе требуется разработать имитационную модель программного обеспечения информационной системы "Центр обслуживания абонентов" (далее просто Системы).

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

Имитационное моделирование - это метод, позволяющий строить модели, учитывающие время выполнения функций. Полученную модель можно “проиграть” во времени и получить статистику происходящих процессов так, как это было бы в реальности. В имитационной модели изменения процессов и данных ассоциируются с событиями. “Проигрывание" модели заключается в последовательном переходе от одного события к другому. Обычно имитационные модели строятся для поиска оптимального решения в условиях ограничения по ресурсам, когда другие математические модели оказываются слишком сложными.

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

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

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

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

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

Типичный сценарий работы оператора с Системой выглядит следующим образом. Оператор открывает программу и выбирает одного из имеющихся операторов сотовой связи, так как у каждого оператора свой Центральный офис и сервер. Электронные документы абонентов бывают следующих видов: договор об оказании услуг связи, заявления для замены sim-карты, замены абонентского номера, на детализацию счета, пополнения счета. При создании договора или заявления открывается окно формы соответствующего документа, оператор заполняет все необходимые поля формы, сохраняет документ. При заполнении реквизитов документов и сохранением документа выполняется проверка правильности заполнения реквизитов документов.

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

1.1 Диаграммы потоков данных

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

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

Структурные методы имеют три основные особенности:

расчленение сложной системы на части, представляемые как "черные ящики", а каждый черный ящик реализует определенную функцию системы управления;

иерархическое упорядочение выделенных элементов системы с определением взаимосвязей между ними;

использование графического представления взаимосвязей элементов системы;

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

За последнее десятилетие сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering). В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Очень грубо, CASE - технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимоувязанных средств автоматизации. CASE - это инструментарий для системных аналитиков, разработчиков и прогpаммистов, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки ПО.

В составе методологий структурного анализа к наиболее распространенным можно отнести следующие:

SADT (Structured Analysis and Design Technique) - технология структурного анализа и проектирования и ее подмножество стандарт IDEF0;

DFD (Data Flow Diagrams) - диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь";

STD (State Transition Diagrams) - диаграммы переходов состояний.

В моей работе была использована методология DFD (Data Flow Diagrams). В DFD методологии исследуемый процесс разбивается на подпроцессы и представляется в виде сети, связанной потоками данных. В число элементов данной методолошии входят процессы, потоки данных и хранилища. Хранилище позволяет в необходимых случаях определить данные, которые будут сохраняться в памяти между процессами.

Диаграммы потоков данных (DFD - Data Flow Diagram) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

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

Построю контекстную DFD диаграмму системы. Для этого необходимо изобразить основную функцию рассматриваемой системы "Центр обслуживания абонентов" и внешние по отношению к ней сущности, а также взаимосвязи между внешними сущностями и функцией системы. Контекстная диаграмма будет выглядеть следующим образом.

Рис.1. Контекстная диаграмма системы "Обслуживание абонентов"

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

Далее клиент в случае необходимости посещает центр для заполнения заявления. Заявление может быть по разному поводу (просьба детализации счета, замена абонентского номера, замена sim-карты, заявка на пополнение счета…). Оператором рассматриваются заявления, и выносится решение об удовлетворении либо об отказе, что показано на диаграмме.

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

Рис.2. Диаграмма детализации первого уровня системы "Обслуживание абонентов"

Обслуживание абонентов может быть представлено в виде семи основных функций:

Рассмотрение анкеты

Заключение договора

Отказ от заключения договора

Подключение к сети

Рассмотрение заявления

Отказ от исполнения заявления

Исполнение заявления

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

Рассмотрение анкеты.

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

Заключение договора.

Результатом данной операции является внесение в систему информации о клиенте.

Отказ от заключения договора.

Оператор решает в силу тех или иных причин отказать в заключении договора о предоставлении услуг связи.

Подключение к сети.

При заключении договора необходимо выбрать оператора сети, приобрести sim-карту и соответственно абонентский номер.

Рассмотрение заявления.

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

Отказ от исполнения заявления.

При наличии новых заявлений оператор осуществляет их проверку. Если принято решение о нецелесообразности исполнения данного требования, то сообщается абоненту об отказе.

Исполнение заявления

В случае принятия положительного решения, требования заявления исполняется.

Глава 2. Проектирование системы "обслуживание абонентов"

Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах:

Use case diagram (диаграммы прецедентов);

Deployment diagram (диаграммы топологии);

Statechart diagram (диаграммы состояний);

Activity diagram (диаграммы активности);

Interaction diagram (диаграммы взаимодействия);

Sequence diagram (диаграммы последовательностей действий);

Collaboration diagram (диаграммы сотрудничества);

Class diagram (диаграммы классов);

Component diagram (диаграммы компонент).

Для целей анализа деятельности предприятия все большее распространение получает средство моделирования Rational Rose компании Rational Software.

Rational Rose - мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого начала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат. Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы.

2.1 Выявление вариантов использования

 

UML и Rational Rose являются универсальными средствами, которые вполне подходят и для моделирования бизнес-процессов.

Use case diagram (диаграммы прецедентов) - позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors). Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.

  2.1.1 Выделение субъектов (актеров) и прецедентов (видов деятельности)

Исходя из поиска ответов на следующие вопросы:

Кто взаимодействует с системой или использует систему?

Кто передает или принимает информацию в/из системы?

Кто является внешним по отношению к системе?

Я выявил следующих субъектов.

Рис.3 Субъекты системы "Обслуживание абонентов"

Прецедент представляет собой целостный набор функций, имеющих определенную ценность для субъекта. Прецеденты можно вывести в результате определения задач для субъекта. Для этого следует задаться вопросом: "Каковы обязанности субъекта по отношению к системе и чего он ожидает от системы?" Каждый вариант использования (прецедент) определяет набор действий, совершаемых системой при диалоге с актером. При этом ничего не говорится о том, как конкретно будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования. Прецедент изображается в виде эллипса, внутри или ниже которого помещается имя прецедента.

Рис.4. Прецеденты системы "Обслуживание абонентов"

2.1.2 Документирование прецедентов

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

1. Краткое описание.

2. Участвующие субъекты.

3. Предусловия, необходимые для инициирования прецедента.

4. Детализированное описание потока событий, которое включает:

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

альтернативные потоки для определения исключительных ситуаций.