Проектирование ИС учета деятельности городской телефонной сети

     

     2.1 Выбор методологии  проектирования

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

     Технология  создания ИС предъявляет особые требования к методикам реализации и программным инструментальным средствам, а именно:

• Реализацию проектов по созданию ИС принято разбивать на стадии анализа (необходимо понять и описать бизнес-логику предметной области), проектирования (необходимо определить модули и архитектуру будущей системы), непосредственного кодирования, тестирования и сопровождения. Известно, что исправление ошибок, допущенных на предыдущей стадии, обходится примерно в 10 раз дороже, чем на текущей; откуда следует, что наиболее критическими являются первые стадий проекта. Поэтому крайне важно иметь эффективные средства автоматизации ранних этапов реализации проекта.
• Проект по созданию сложной ИС невозможно реализовать в одиночку. Коллективная работа существенно отличается от индивидуальной, поэтому при реализации крупных проектов необходимо иметь средства координации и управления коллективом разработчиков.
• Жизненный цикл создания сложной ИС сопоставим с ожидаемым временем ее эксплуатации. Другими словами, в современных условиях компании перестраивают свои бизнес-процессы примерно раз в два года, столько же требуется (если работать по традиционной технологии) для создания ИС. Может оказаться, что к моменту сдачи ИС она уже никому не нужна, поскольку компания, ее заказавшая, вынуждена перейти на новую технологию работы. Следовательно, для создания ИС жизненно необходим инструмент, значительно (в несколько раз) уменьшающий время разработки ИС.
• Вследствие значительного жизненного цикла может оказаться, что в процессе создания системы внешние условия изменились. Обычно внесение изменений в проект на поздних этапах создании ИС весьма трудоемкий и дорогостоящий процесс. Поэтому для успешной реализации крупного проекта необходимо, чтобы инструментальные средства, на которых он реализуется, были достаточно гибкими к изменяющимся требованиям.

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

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

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

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

     2.2 Моделирование бизнес-процессов

     Бизнес-моделирование  − деятельность по выявлению и описанию существующих бизнес-процессов (анализ бизнес-процессов), а также проектированию новых (проектирование бизнес-процессов).

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

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

• SADT: IDEF0, IDEF3, DFD
• Методология ARIS: VAD, eEPC
• BPMN
• RUP: Прецеденты (use-cases), Диаграммы деятельности, BPEL

     При разработке небольших программных  систем обычно применяются облегчённые  текстовые «нотации»:

• Agile: User Story
• UCD: Scenarios

     IDEF0 − Function Modeling − методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (WorkFlow).

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

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

     Первым  из них является понятие функционального  блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

     Каждая  из четырех сторон функционального  блока имеет своё определенное значение (роль), при этом:

1. Верхняя сторона имеет значение “Управление” (Control);
2. Левая сторона имеет значение “Вход” (Input);
3. Правая сторона имеет значение “Выход” (Output);
4. Нижняя сторона имеет значение “Механизм” (Mechanism).

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

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

     Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного. При построении IDEF0-диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто.

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

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

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

     Построим  контекстную диаграмму модели деятельности городской телефонной сети. Произведем ее декомпозицию на 4 уровня (Учёт абонентов, Учёт телефонных номеров, Учёт звонков, Регистрация системы оплаты). Затем каждую полученную декомпозицию разобьем на свои подсистемы.

Рисунок 1 − Контекстная диаграмма модели деятельности городской телефонной сети 

Рисунок 2 − Декомпозиция первого уровня

Рисунок 3 − Декомпозиция Учёта абонентов 

Рисунок 4 − Декомпозиция Учёта телефонных номеров

Рисунок 5 − Декомпозиция Учёта звонков

     Рисунок 6 − Декомпозиция системы регистрации  оплаты

      2.3 Моделирование функциональных требований к БД

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

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

• внешние сущности;
• системы/подсистемы;
• процессы;
• накопители данных;
• потоки данных.

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

      Далее представлена диаграмма потоков данных (DFD) информационной системы городской телефонной сети и произведены все необходимые декомпозиции этой системы и ее подсистем. 

Рисунок 7 − Диаграмма потоков данных

Рисунок 8 − Декомпозиция первого уровня (DFD) 

Рисунок 9 − Декомпозиция Учёта абонентов (DFD)

Рисунок 10 − Декомпозиция Учёта телефонных номеров (DFD) 

Рисунок 11 − Декомпозиция Учёта звонков (DFD)

     Рисунок 12 – Декомпозиция системы регистрации оплаты

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

     Логическая  модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, так как мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.