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

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 (диаграммы последовательностей действий);