Функциональная модель банковской сети

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

­ определить входные и выходные значения;

­ построить ДПД, показывающие функциональные зависимости;

­ описать функции;

­ описать ограничения;

­ сформулировать критерии оптимизации;

­ уточнить набор операций в объектной модели.

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

Определение входных и выходных значений

Начнём с определения входных и выходных значений. Эти значения являются параметрами событий между системой и окружающим её миром. Входные и выходные значения банковской сети показаны на рисунке 2.66 (пунктирная линия показывает границу системы).

 

 

Рис. 2.66. Входные и выходные значения банковской сети

 

Поскольку все взаимодействия между внешним миром и системой проходят через ATM (или кассовый терминал, который здесь не рассматривается), все входные и выходные значения являются параметрами событий, связанных с объектом ATM (банкомат).

Построение ДПД

ДПД обычно строится по уровням. На верхнем уровне, как правило, показывают один-единственный процесс или, как в нашем примере (рис. 2.67), процесс ввода, основной процесс вычисления требуемых значений и процесс вывода. Входные и выходные данные на этой диаграмме поставляются и потребляются внешними объектами (клиент, карточка).

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

 

Рис. 2.67. Процессы верхнего уровня

в системе обслуживания банковской сети

 

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

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

Большая часть систем содержит внутренние хранилища данных, в которых хранятся данные в периодах между взаимодействиями. Для процесса выполнить проводку таким хранилищем является объект счёт. Внутренние хранилища данных отличаются тем, что получаемые ими данные не выдаются немедленно, а хранятся в объекте для использования в будущем.

Рис. 2.68. ДПД процесса выполнить проводку

в системе обслуживания банковской сети

 

Описание функций

После того как ДПД составлена, необходимо составить описание каждой функции из ДПД. Пример описания функции приведён на рисун- ке 2.65. Мы не приводим других примеров описания функций банковской сети ввиду их тривиальности.

Описание ограничений

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

В банковской сети можно ввести следующие ограничения:

­ «счёт не может иметь отрицательного баланса»;

­ «отрицательный баланс кредитуемого счёта не может быть больше лимита кредитования для этого счёта».

Определение критериев оптимизации

Определяем, какие значения необходимо максимизировать или минимизировать в процессе работы системы; если критериев оптимизации несколько и они противоречат один другому, следует определить компромиссные решения. На этой стадии не следует принимать по этому поводу слишком точных решений, так как в процессе дальнейшего проектирования критерии будут уточняться и изменяться.

Оптимизационные критерии для банковской сети:

­ минимизировать количество физических пересылок между различными узлами сети;

­ минимизировать время, в течение которого счёт закрыт для доступа.

Операции вводятся на различных стадиях разработки модели проектируемой системы (см. выше):

­ при разработке объектной модели;

­ при определении событий;

­ при определении действий и активностей;

­ при определении функций.

На заключительном этапе разработки модели проектируемой системы все введённые операции вводятся в её объектную модель.

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