Пример диаграммы потоков данных («КоммИнфо»)
Рассмотрим пример системы другого класса – информационной системы для обслуживания запросов, имеющей центральную базу данных, откуда абоненты могут получать уже имеющуюся информацию и куда могут помещать свою информацию. Сформулируем основные положения, определяющие правила функционирования системы, под условным названием «КоммИнфо».
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); вместе с тем соответствующие потоки следует называть различным образом: идентифицированный запрос, запрос от платежеспособного абонента. Это связано с тем, что, несмотря на неизменность содержания, запросы меняют свое качество, так как предполагается, что неверные запросы и запросы от неплатежеспособных абонентов будут отклонены в ходе соответствующего анализа.
Построение словаря данных
Понятия, вводимые на диаграммах потоков данных, описываются аналитиком в словаре. Можно выделить три уровня описания:
1) элемент данных – информационный объект, который в контексте рассматриваемой задачи не имеет смысла подвергать дальнейшей детализации;
2) структура данных – агрегат, состоящий из элементов и / или других структур данных;
|
|
|
3) потоки и накопители данных; потоки – это структуры данных, находящиеся в движении, накопители – статические структуры данных.
Описание элемента данных в общем случае включает:
· имя;
· синонимы;
· связанные элементы данных;
· диапазон и смысл значений;
· длину;
· способ кодирования;
· другую необходимую информацию.
Имя элемента данных выбирается таким образом, чтобы оно было максимально информативно для пользователей (заказчиков) системы.
Синонимы возникают в том случае, когда различные пользователи называют одно и то же понятие поразному или понятие выступает в различных ролях по отношению к различным пользователям.
Например, в системе «КоммИнфо» (см. предыдущий параграф) ответ на поисковый запрос может содержать адрес продавца / покупателя; вместе с тем по отношению к системе эта же информация могла бы рассматриваться как адрес абонента.
Связанные элементы данных возникают в ситуации, когда одна и та же информация представляется различным образом (записывается в различном формате). Например, время может записываться как 6:30 PM (формат, принятый в США) или как 18:30; тогда первый элемент мог бы иметь имя «НАЦИОНАЛЬНОЕ ВРЕМЯ», а второй, связанный с ним, – просто «ВРЕМЯ».
Диапазон и смысл значений может указываться двояким образом:
· путем указания минимальной и максимальной границы; например, номер абонента – от 0 до 9999999 (непрерывный элемент данных);
· путем перечисления множества возможных значений, например, день недели – ПН, ВТ, СР, ЧТ, ПТ, СБ, ВС, тип запроса – поиск, актуализация (дискретный элемент данных).
Элемент данных целесообразно определять как дискретный, когда важен смысл значений. Например, типы запросов используются для их классификации, в воскресенье (ВС) система обслуживает ограниченный круг абонентов и т. д.
Длина и способ кодирования элемента данных на начальных этапах разработки, как правило, не задается; эта информация вводится не аналитиком, а проектировщиком. Вместе с тем аналитик может указать необходимые значения, если они важны для проектирования или выступают как ограничения (должен быть предусмотрен интерфейс с другой, уже существующей системой, выдающей данные в определенном формате).
Описание структуры данных представляет собой перечень элементов и структур данных, ее образующих. Любая структура данных может быть построена одним из трех возможных способов (табл. 2.2):
· объединение (агрегация);
· альтернативы (выбор);
· повторение (итерация).
Агрегация позволяет построить новый информационный объект посредством объединения других объектов, составляющие объекты обязательно входят в состав объекта верхнего уровня, например «АДРЕС» – это «ИНДЕКС», «ГОРОД», «УЛИЦА», «ДОМ».
Альтернатива позволяет представлять данные с переменной структурой, так книга может быть сборником, тогда для нее указывается редактор или монографией – тогда автор.
Итерация позволяет описывать данные с регулярной структурой: массивы, файлы, картотеки и т. д.
Таблица 2.2
Дата добавления: 2018-10-26; просмотров: 209; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!