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