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

СОДЕРЖАНИЕ 

ВВЕДЕНИЕ

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

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

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

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

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

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

      Для достижения поставим ряд задач:

  1. Выбор метода проектирования и его описание.
  2. Построение необходимых моделей баз данных.
  3. Выбор средств реализации системы.
  4. Составление технического задания на разработку ИС

 

     1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

      1.1 Постановка задачи

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

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

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

     Абонентов любой АТС можно подразделить на простых и льготных. К категории льготников относятся пенсионеры, инвалиды и т.д. Льготники платят только 50% абонентской платы. В соответствии со всем этим (тип телефона, льготник или нет, есть ли выход на межгород) рассчитывается размер абонентской платы.

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

     В городе также существуют общественные телефоны и таксофоны, расположенные по определенным адресам. 

     1.2 Виды запросов

  1. Получить перечень и общее число абонентов указанной АТС полностью, только льготников, по возрастному признаку, по группе фамилий.
  2. Получить перечень и общее число свободных телефонных номеров на указанной АТС, по всей ГТС, по признаку возможности установки телефона в данном районе.
  3. Получить перечень и общее число должников на указанной АТС, по всей ГТС, по данному району, абонентов, которые имеют задолженность уже больше недели (месяца), по признаку задолженности за межгород и (или) по абонентской плате, по размеру долга.
  4. Определить АТС (любого или конкретного типа), на которой самое большое (маленькое) число должников, самая большая сумма задолженности.
  5. Получить перечень и общее число общественных телефонов и таксофонов во всем городе, принадлежащих указанной АТС, по признаку нахождения в данном районе.
  6. Найти процентное соотношение обычных и льготных абонентов на указанной АТС, по всей ГТС, по данному району, по типам АТС.
  7. Получить перечень и общее число абонентов указанной АТС, по всей ГТС, по данному району, по типам АТС имеющих параллельные телефоны, только льготников имеющих параллельные телефоны.
  8. Определить, есть ли по данному адресу телефон, общее количество телефонов и (или) количество телефонов с выходом на межгород, с открытым выходом на межгород в данном доме, на конкретной улице.
  9. Определить город, с которым происходит большее количество междугородных переговоров.
  10. Получить полную информацию об абонентах с заданным телефонным номером.
  11. Получить перечень спаренных телефонов, для которых есть техническая возможность заменить их на обычные (выделить дополнительный номер).
  12. Получить перечень и общее число внутренних на определенной ведомственной или учрежденческой АТС, с которых за некоторый период времени было произведено менее определенного числа внешних звонков.
  13. Получить перечень и общее число должников на указанной АТС, по всей ГТС, по данному району, которым следует послать письменное уведомление, отключить телефон и(или) выход на межгород.
 

     1.3 Описание входной/выходной  информации

     В ходе анализа информационной системы  городской телефонной сети, в её подсистемах можно выделить следующую  входную и выходную информацию: 

1. Учёт абонентов.

Вход: документация: паспорт (фамилия, имя, отчество абонента, адрес, наименование органа выдачи паспорта, дата выдачи), льготное удостоверение, если таковое имеется (фамилия, имя, отчество, тип льготы, номер удостоверения, подтверждающего наличие льготы), принадлежность определённой АТС, дата регистрации. 

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

2. Учёт телефонных номеров.

Вход: телефонный номер, адрес абонента, название АТС, (ГТС, района), наименование типа телефонного номера (спаренный, параллельный, частный, служебный, общественный, таксофон), заложенные в базе телефонных номеров ГТС. 

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

3. Учёт телефонных звонков.

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

Выход: отчёты с расшифровкой звонков – счета к оплате, имеющие следующие атрибуты:

вызываемый  номер,

название  места назначения звонка,

дата  и время совершения звонка,

продолжительность звонка,

тариф (цена одной  минуты разговора),

сумма к оплате,

общая сумма к оплате.

4. Система регистрации оплаты.

Вход: квитанция об оплате (ФИО абонента, адрес, телефонный номер, название АТС (ГТС, района)). 

Выход: квитанция об оплате (тариф абонента, размер абонентской платы, наличие задолженности, сумма задолженности, вид задолженности, период задолженности), перечень количества должников на искомой АТС (ГТС, искомом районе), имеющий атрибуты: ФИО абонента, адрес, телефонный номер, тариф, сумма задолженности, вид задолженности, период задолженности).

 

     2 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ    СИСТЕМЫ

     

     На  этапе проектирования формируется  модель данных. Проектировщики в качестве исходной информации получают результаты анализа. Конечным продуктом этапа проектирования являются:

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

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

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

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

     

     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-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, так как мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.

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