КНИГА
02.04.01

Предыдущая часть

Консалтинг при автоматизации предприятий: подходы, методы, средства

2.5. Пример банковской задачи

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

На рис. 2.3 приведена контекстная диаграмма системы с единственным процессом ОБСЛУЖИТЬ, идентифицирующая внешние сущности КЛИЕНТ и КОМПЬЮТЕР БАНКА, хранящий информацию о счетах всех клиентов. Опишем потоки данных, которыми обменивается проектируемая система с внешними объектами.

Рис. 2.3. Контекстная диаграмма банковской задачи

Для банковского обслуживания клиенту необходимо предоставить системе свою КРЕДИТНУЮ КАРТУ для автоматического считывания с нее информации (ПАРОЛЬ, ЛИМИТ ДЕНЕГ, ДЕТАЛИ КЛИЕНТА), а также сообщить свои КЛЮЧЕВЫЕ ДАННЫЕ, а именно ПАРОЛЬ и ЗАПРОС НА ОБСЛУЖИВАНИЕ, т.е. требуемую ему услугу (например, снятие со счета наличных денег). Банковское обслуживание с позиций клиента, в свою очередь, должно обеспечить следующее:

Контекстный процесс и КОМПЬЮТЕР БАНКА должны обмениваться следующей информацией: Контекстный процесс может быть детализирован DFD первого уровня как показано на рис. 2.4. Эта диаграмма содержит 4 процесса и хранилище ДАННЫЕ КРЕДИТНОЙ КАРТЫ, которое изображено дважды на диаграмме с целью избежания пересечений линий потоков данных.

Процесс 1.1 (ПОЛУЧИТЬ ПАРОЛЬ) осуществляет прием и проверку пароля клиента и имеет на входе/выходе следующие потоки:

Процесс 1.2 (ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) осуществляет прием и проверку запроса клиента на проведение необходимой ему банковской операции и имеет на входе/выходе следующие потоки:

Рис. 2.4. Детализация процесса ОБСЛУЖИТЬ

Процесс 1.3 (ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) имеет внешний входной поток ДАННЫЕ ПО СЧЕТУ (из внешней сущности КОМПЬЮТЕР БАНКА), входной поток ДЕТАЛИ КЛИЕНТА (из хранилища), а также внешние выходные потоки ВЫПИСКА, ДЕНЬГИ и ПРОТОКОЛ ОБСЛУЖИВАНИЯ.

Процесс 1.4 (ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ) осуществляет считывание информации с кредитной карты и имеет на входе внешний поток КРЕДИТНАЯ КАРТА, а на выходе поток ДАННЫЕ КРЕДИТНОЙ КАРТЫ. Отметим, что нет необходимости в идентификации последнего потока, т.к. идентифицировано соответствующее хранилище.

Процессы 1.1, 1.2 и 1.4 являются элементарными, поэтому нет необходимости в их детализации с помощью DFD уровня 2 (они будут раскрыты с помощью спецификаций процессов в главе 4). Процесс 1.3 может быть детализирован с помощью DFD второго уровня как показано на рис. 2.5. Эта диаграмма содержит 4 элементарных процесса, спецификации которых также будут приведены в главе 4.

Процесс 1.3.1 (ОБРАБОТАТЬ ДОКУМЕНТАЦИЮ БАНКА) осуществляет обработку внутренней банковской документации по клиенту и имеет входной поток ДЕТАЛИ КЛИЕНТА и выходной поток ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ (часть внешнего потока ПРОТОКОЛ СДЕЛКИ).

Процесс 1.3.2 (РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТА) выдает справку по истории счета клиента и по балансу клиента. Входные потоки - ДЕТАЛИ КЛИЕНТА и ДАННЫЕ ПО БАЛАНСУ (часть внешнего потока ДАННЫЕ ПО СЧЕТУ), выходные потоки - ВЫПИСКА ПО БАЛАНСУ (часть внешнего потока ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть внешнего потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

Процесс 1.3.3 (ПРИГОТОВИТЬ ДЕНЬГИ КЛИЕНТУ) обеспечивает выдачу наличных денег и информирование компьютера банка об изъятых из банка деньгах. Он имеет входные потоки ДЕНЕЖНАЯ СУММА и ДЕТАЛИ КЛИЕНТА, и выходные потоки ДЕНЬГИ и ДЕНЕЖНАЯ СУММА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

Рис. 2.5. Детализация процесса ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ

Процесс 1.3.4 (РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА) выдает справку по истории счета и уведомление по проведенной операции. Входные потоки ДАННЫЕ ПО СЧЕТУ и ДЕТАЛИ КЛИЕНТА, выходные потоки - ВЫПИСКА ПО ОПЕРАЦИИ (часть потока ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

2.6. Расширения реального времени

Расширения реального времени используются для дополнения модели функционирования данных (иерархии DFD) средствами описания управляющих аспектов в системах реального времени. Для этих целей применяются следующие символы (рис. 2.6):

  1. УПРАВЛЯЮЩИЙ ПРОЦЕСС. Представляет собой интерфейс между DFD и спецификациями управления, собственно моделирующими и документирующими аспекты реального времени (глава 6). Его имя указывает на тип управляющей деятельности, вырабатываемой спецификацией. Фактически управляющий процесс представляет собой преобразователь входных управляющих потоков в выходные управляющие потоки; при этом точное описание этого преобразования должно задаваться в спецификации управления.
  2. УПРАВЛЯЮЩЕЕ ХРАНИЛИЩЕ. Представляет "срез" управляющего потока во времени. Содержащаяся в нем управляющая информация может использоваться в любое время после ее занесения в хранилище, при этом соответствующие данные могут быть использованы в произвольном порядке. Имя управляющего хранилища должно идентифицировать его содержимое и быть существительным. Управляющее хранилище отличается от традиционного тем, что может содержать только управляющие потоки; все другие их характеристики идентичны.
  3. УПРАВЛЯЮЩИЙ ПОТОК. Представляет собой "трубопровод", через который проходит управляющая информация. Его имя не должно содержать глаголов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное, а не непрерывное значение. Это может быть, например, сигнал, представляющий состояние или вид операции.
Логически управляющий процесс есть некий командный пункт, реагирующий на изменения внешних условий, передаваемые ему с помощью управляющих потоков, и продуцирующий в соответствии со своей внутренней логикой выполняемые процессами команды.

Рис. 2.6. Расширения реального времени

При этом режим выполнения процесса зависит от типа управляющего потока. Имеются следующие типы управляющих потоков:

  1. Т-поток (trigger flow). Является потоком управления процессом, который может вызывать выполнение процесса. При этом процесс как бы включается одной короткой операцией. Это - аналог выключателя света, единственным нажатием которого "запускается" процесс горения лампы.
  2. A-поток (activator flow). Является потоком управления процессом, который может изменять выполнение отдельного процесса. Используется для обеспечения непрерывности выполнения процесса до тех пор, пока поток "включен" (т.е. течет непрерывно), с "выключением" потока выполнение процесса завершается. Это - аналог переключателя лампы, которая может быть как включена, так и выключена.
  3. E/D-поток (enable/disable flow). Является потоком управления процессом, который может переключать выполнение отдельного процесса. Течение по E-линии вызывает выполнение процесса, которое продолжается до тех пор, пока не возбуждается течение по D-линии. Это - аналог выключателя с двумя кнопками: одной - для включения света, другой - для его выключения. Отметим, что можно использовать 3 типа таких потоков: E-поток, D-поток, E/D-поток.
Иногда возникает необходимость в представлении одного и того же фрагмента данных потоками различных типов. Например, поток данных СКОРОСТЬ МАШИНЫ в отдельных случаях может использоваться как управляющий для контроля критического значения. Для обеспечения этого используется УЗЕЛ ИЗМЕНЕНИЯ ТИПА (рис. 2.7): поток данных является входным для этого узла, а управляющий поток - выходным.

Рис. 2.7. Узел изменения типа

Дополним модель предложенной в 2.5 банковской системы, введя в диаграммы управляющий процесс и управляющие потоки, позволяющие описать ее функционирование в реальном времени. После такого расширения DFD, приведенные на рис. 2.4 и 2.5 будут выглядеть, как показано на рис. 2.8 и 2.9, соответственно.

Управляющий процесс 1.5 (УПРАВЛЕНИЕ ОБСЛУЖИВАНИЕМ), получив информацию о том, что кредитная карта введена (поток ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА), вызывает выполнение процесса 1.1 (поток А: ПОЛУЧИТЬ ПАРОЛЬ). Получив информацию о введенном пароле (поток КОРРЕКТНЫЙ ПАРОЛЬ), процесс 1.5 информирует процесс 1.4 о необходимости удаления кредитной карты (поток: УДАЛЕННАЯ КРЕДИТНАЯ КАРТА) и с помощью потока Т: ОБЕСПЕЧИТЬ ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ вызывает выполнение процесса 1.2, затем процесса 1.3 (поток ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ).

Рис. 2.8. Расширение диаграммы, детализирующей контекстный процесс

Рис. 2.9. Расширение диаграммы, детализирующей процесс 1.3

Последний управляющий поток на детализирующей процесс 1.3 диаграмме расчленяется на 4 подпотока, каждый из которых вызывает выполнение процессов 1.3.1 - 1.3.4, соответственно.

Продолжение статьи

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail


Interface Ltd.

Ваши замечания и предложения отправляйте автору
По техническим вопросам обращайтесь к вебмастеру
Документ опубликован: 02.04.01