5. Пример диаграммы потоков данных («КоммИнфо»)

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

1. Система обеспечивает получение справок о предложениях по купле / продаже.

2. Примерная архитектура системы приведена на рис. 2.13. Система включает сервер, поддерживающий базу данных и обслуживающий запросы, поступают с ПЭВМ абонентов через телефонные каналы.

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

4. Абонент «КоммИнфо» может послать поисковый запрос для получения справки о предложениях по купле/продаже.

5. Абонент вносит плату за пользование системы. Система оценивает стоимость каждого поискового запроса и с определенной периодичностью формирует счет на услуги.

6. Абонент «КоммИнфо» может поместить на сервер информацию о собственных предложениях, указав срок ее хранения.

7. Абонент может удалить с сервера информацию о своих предложениях, если она потеряла актуальность.

8. Хранение информации абонента на сервере оплачивается в зависимости от продолжительности ее хранения и объема.

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

10. Информация, хранимая на сервере, автоматически уничтожается по истечении срока ее хранения.

Контекстная диаграмма системы «КоммИнфо» приведена на рис. 2.14. В рассматриваемой системе могут быть выделены три группы функций:

• процедура регистрации абонента;

• процедура обслуживания запросов;

• процедура оплаты услуг.

Регистрация абонента (рис. 2.15, процесс P2) состоит в контроле оплаты, занесении реквизитов абонента в накопитель «СПИСОК АБОНЕНТОВ», а также сообщении абоненту его идентификатора и пароля доступа.

Обслуживание запросов (процесс P3) предусматривает:

• получение запроса содержащего, в том числе, идентификатор и пароль абонента;

• контроль идентификатора, пароля и платежеспособности абонента (информация поступает из накопителя «СПИСОК АБОНЕНТОВ»);

• формирование и передачу ответа на запрос;

• модификацию счета абонента в накопителе «СЧЕТА АБОНЕНТОВ» с учетом стоимости оказанных услуг.

Оплата услуг производится периодически (процесс P4), при этом используется информация из накопителя «СЧЕТА АБОНЕНТОВ», на основе которой составляется направляемый абоненту счет. При данных об оплате в накопителе «СЧЕТА АБОНЕНТОВ» регистрируется погашение задолженности. Если абонент пропустил установленный срок оплаты, то информация о его неплатежеспособности помещается в накопитель «СПИСОК АБОНЕНТОВ»; обслуживание запросов такого абонента прекращается.

Рассмотрим более детально процесс обслуживания запросов. Диаграмма, детализирующая этот процесс, приведена на рис. 2.16. Как следует из диаграммы, после приема запросы разделяются на два потока и помещаются либо в накопитель «ОЧЕРЕДЬ ПОИСК. ЗАПРОСОВ», либо в накопитель «ОЧЕРЕДЬ ЗАПР. НА АКТУАЛИЗ.» (запросы, содержащие информацию, подлежащую записи в банк данных). Процесс поиска информации (P6) выбирает очередной поисковый запрос и проводит его обслуживание; стоимость обслуживания регистрируется в накопителе «СЧЕТА АБОНЕНТОВ», а сформированный ответ заносится в накопитель «ОЧЕРЕДЬ ОТВЕТОВ». Процесс актуализации информации (P7) функционирует аналогично процессу поиска. Процесс передачи ответа (P8) выбирает очередной ответ из очереди и выдает его в канал связи. Накопитель «БАНК КОММЕРЧЕСКОЙ ИНФОРМАЦИИ» периодически модифицируется процессом удаления устаревшей информации (P9).

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

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