Функциональная модель банковской сети
Функциональная модель показывает как вычисляются значения в системе и как они зависят одно от другого. Для конструирования функциональной модели необходимо выполнить следующее:
- определить входные и выходные значения;
- построить ДПД, показывающие функциональные зависимости;
- описать функции;
- описать ограничения;
- сформулировать критерии оптимизации;
- уточнить набор операций в объектной модели.
Выполним все эти шаги, чтобы построить функциональную модель банковской сети (ATM).
Определение входных и выходных значений
Начнем с определения входных и выходных значений. Эти значения являются параметрами событий между системой и окружающим ее миром. Входные и выходные значения банковской сети показаны на рисунке 2.66 (пунктирная линия показывает границу системы).
Рис. 2.66. Входные и выходные значения банковской сети
Поскольку все взаимодействия между внешним миром и системой проходят через ATM (или кассовый терминал, который здесь не рассматривается), все входные и выходные значения являются параметрами событий, связанных с объектом ATM (банкомат).
Построение ДПД
ДПД обычно строится по уровням. На верхнем уровне, как правило, показывают один единственный процесс, или, как в нашем примере (рисунок 2.67), процесс ввода, основной процесс вычисления требуемых значений и процесс вывода. Входные и выходные данные на этой диаграмме поставляются и потребляются внешними объектами (клиент, карточка).
Рис. 2.67. Процессы верхнего уровня в системе обслуживания банковской сети
На ДПД каждого уровня указываются элементы данных более высоких уровней, чтобы показать данные, обрабатываемые каждым процессом (см. рисунок 2.68). Большая часть систем содержит внутренние хранилища данных, в которых хранятся данные в периодах между взаимодействиями. Для процесса выполнить проводку таким хранилищем является объект счет. Внутренние хранилища данных отличаются тем, что получаемые ими данные не выдаются немедленно, а хранятся в объекте для использования в будущем.
Рис. 2.68. ДПД процесса выполнить проводку в системе обслуживания банковской сети
ДПД показывают только зависимости между операциями; они не содержат информации о последовательности выполнения операций (операции, показанные на ДПД могут быть не всегда выполняемыми или исключающими одна другую). Например, пароль должен быть подтвержден до внесения изменений в счет; если он указан неверно, изменения в счет не вносятся. Последовательность выполнения операций указывается в динамической, а не в функциональной модели. Некоторые значения данных влияют на выбор последовательности вычислений в динамической модели; тем не менее эти значения не влияют непосредственно на выходные значения ДПД, так как ДПД показывает все возможные пути вычислений. Однако может оказаться полезным поместить функции, осуществляющие выбор последовательности вычислений, и в функциональную модель, так как эти функции могут выражать сложные зависимости от входных данных. Такие функции показаны на ДПД, но их выходными значениями являются управляющие сигналы, показанные пунктирными линиями. Примером такой функции является функция проверить пароль. Описание функций После того как ДПД составлена, необходимо составить описание каждой функции из ДПД. Пример описания функции приведен на . Мы не приводим других примеров описания функций банковской сети в виду их тривиальности. Описание ограничений Ограничения - это функциональные зависимости между объектами, не сводящиеся к непосредственным зависимостям между выходами и входами. Ограничения могут накладываться одновременно на два объекта, на различные объекты одного класса в различные моменты времени (инвариант), или на объекты разных классов в различные моменты времени (хотя в последнем случае это, как правило, связи между входами и выходами). Ограничения, которым должны удовлетворять входные значения функции, называются ее предусловиями, а ограничения, которым удовлетворяют выходные значения функции, - ее постусловиями. В банковской сети можно ввести следующие ограничения:
- "счет не может иметь отрицательного баланса";
- "отрицательный баланс кредитуемого счета не может быть больше лимита кредитования для этого счета".
Определение критериев оптимизации Определяем какие значения необходимо максимизировать или минимизировать в процессе работы системы; если критериев оптимизации несколько и они противоречат один другому, следует определить компромиссные решения. На этой стадии не следует принимать по этому поводу слишком точных решений, так как в процессе дальнейшего проектирования критерии будут уточняться и изменяться. Оптимизационные критерии для банковской сети:
- минимизировать количество физических пересылок между различными узлами сети;
- минимизировать время, в течение которого счет закрыт для доступа.
Операции вводятся на различных стадиях разработки модели проектируемой системы (см. выше):
- при разработке объектной модели;
- при определении событий;
- при определении действий и активностей;
- при определении функций.
На заключительном этапе разработки модели проектируемой системы все введенные операции вводятся в ее объектную модель. К перечисленным операциям добавляются операции, связанные с внешним поведением объектов рассматриваемых классов: эти операции определяются природой объектов, а не свойствами разрабатываемой системы. Такие операции расширяют определение объекта, выводя его за рамки непосредственных требований со стороны конкретной системы. Примерами таких операций для банковской сети являются: закрыть счет, создать сберегательный счет, создать банковскую карточку и т.п. С точки зрения системы эти операции не имеют смысла, но они отражают реальные свойства классов счет и карточка и могут оказаться полезными при использовании этих классов в других системах. В заключение следует исследовать объектную модель на предмет упрощения операций ее классов. Пример банковской сети недостаточно сложен, чтобы продемонстрировать это.
| |
Comments:
Copyright ©
