Разработка корпоративной информационной системы на основе объектно-ориентированного подхода (стр. 6 из 11)
построить ДПД, показывающие функциональные зависимости;
описать функции;
описать ограничения;
сформулировать критерии оптимизации;
уточнить набор операций в объектной модели.
Выполним все эти шаги, чтобы построить функциональную модель банковской сети (БМ).
Начнем с определения входных и выходных значений. Эти значения являются параметрами событий между системой и окружающим ее миром. Входные и выходные значения банковской сети показаны на рисунке 1.22 (пунктирная линия показывает границу системы).
Рисунок 1.22 - Входные и выходные значения банковской сети
Поскольку все взаимодействия между внешним миром и системой проходят через БМ, все входные и выходные значения являются параметрами событий, связанных с объектом БМ.
ДПД обычно строится по уровням. На верхнем уровне, как правило, показывают один единственный процесс, или, как в нашем примере (рисунок 1.23), процесс ввода, основной процесс вычисления требуемых значений и процесс вывода. Входные и выходные данные на этой диаграмме поставляются и потребляются внешними объектами (клиент, карточка).
Рисунок 1.23 - Процессы верхнего уровня в системе обслуживания банковской сети
На ДПД каждого уровня указываются элементы данных более высоких уровней, чтобы показать данные, обрабатываемые каждым процессом (рисунок 1.24). Большая часть систем содержит внутренние хранилища данных, в которых хранятся данные в периодах между взаимодействиями. Для процесса выполнить проводку таким хранилищем является объект счет. Внутренние хранилища данных отличаются тем, что получаемые ими данные не выдаются немедленно, а хранятся в объекте для использования в будущем.
Рисунок 1.24 - ДПД процесса выполнить проводку в системе обслуживания банковской сети
ДПД показывают только зависимости между операциями; они не содержат информации о последовательности выполнения операций. Например, пароль должен быть подтвержден до внесения изменений в счет; если он указан неверно, изменения в счет не вносятся. Последовательность выполнения операций указывается в динамической, а не в функциональной модели.
Некоторые значения данных влияют на выбор последовательности вычислений в динамической модели; тем не менее, эти значения не влияют непосредственно на выходные значения ДПД, так как ДПД показывает все возможные пути вычислений. Однако может оказаться полезным поместить функции, осуществляющие выбор последовательности вычислений, и в функциональную модель, так как эти функции могут выражать сложные зависимости от входных данных. Такие функции показаны на ДПД, но их выходными значениями являются управляющие сигналы, показанные пунктирными линиями. Примером такой функции является функция проверить пароль.
После того как ДПД составлена, необходимо описание каждой функции из ДПД. Пример описания функции:
изменить_счет (счет, сумма, вид_проводки) -> деньги, квитанция
если сумма снимается и больше баланса счета,
то "отменить_проводку";
если сумма снимается и меньше баланса счета,
то "дебетовать_счет" и "выдать_деньги";
если сумма вносится на счет,
то "кредитовать_счет";
если запрос,
то "выдать_запрос";
во всех случаях: квитанция должна содержать номер ATM, дату, время,
номер счета, вид проводки, сумму проводки (если она есть), новый баланс счета
Ограничения - это функциональные зависимости между объектами, не сводящиеся к непосредственным зависимостям между выходами и входами. Ограничения могут накладываться одновременно на два объекта, на различные объекты одного класса в различные моменты времени (инвариант), или на объекты разных классов в различные моменты времени (хотя в последнем случае это, как правило, связи между входами и выходами). Ограничения, которым должны удовлетворять входные значения функции, называются ее предусловиями, а ограничения, которым удовлетворяют выходные значения функции, - ее постусловиями.
В банковской сети можно ввести следующие ограничения:
"счет не может иметь отрицательного баланса";
"отрицательный баланс кредитуемого счета не может быть больше лимита кредитования для этого счета".
Определяем, какие значения необходимо максимизировать или минимизировать в процессе работы системы; если критериев оптимизации несколько и они противоречат один другому, следует определить компромиссные решения. На этой стадии не следует принимать по этому поводу слишком точных решений, так как в процессе дальнейшего проектирования критерии будут уточняться и изменяться.
Оптимизационные критерии для банковской сети:
минимизировать количество физических пересылок между различными узлами сети;
минимизировать время, в течение которого счет закрыт для доступа.
Операции вводятся на различных стадиях разработки модели проектируемой системы (см. выше):
при разработке объектной модели;
при определении событий;
при определении действий и активностей;
при определении функций.
На этапе разработки модели проектируемой системы все введенные операции вводятся в ее объектную модель.
К перечисленным операциям добавляются операции, связанные с внешним поведением объектов рассматриваемых классов: эти операции определяются природой объектов, а не свойствами разрабатываемой системы. Такие операции расширяют определение объекта, выводя его за рамки непосредственных требований со стороны конкретной системы. Примерами таких операций для банковской сети являются: закрыть счет, создать сберегательный счет, создать банковскую карточку и т.п. С точки зрения системы эти операции не имеют смысла, но они отражают реальные свойства классов счет и карточка и могут оказаться полезными при использовании этих классов в других системах. Далее следует исследовать объектную модель на предмет упрощения операций ее классов.
После того как прикладная задача исследована, и результаты ее исследования зафиксированы в виде объектной, динамической и функциональной моделей, можно приступить к конструированию системы. На этапе конструирования системы принимаются решения о распределении подсистем по процессорам и другим аппаратным устройствам. Устанавливаются основные принципы и концепции, которые формируют основу детальной последующей разработки программного обеспечения системы.
Внешняя организация системы называется архитектурой системы. Выбор архитектуры системы является еще одной задачей, решаемой на этапе ее конструирования.
Конструирование системы завершается конструированием ее объектов. На этом этапе разрабатываются полные определения классов и зависимостей, используемые на этапе реализации системы. Кроме того, определяются и конструируются внутренние объекты и оптимизируются структуры данных и алгоритмы.
2.1. Разработка архитектуры системы
Во время анализа требований к системе основное внимание уделялось выяснению того, что должно быть сделано, вне зависимости от того, как это сделать. На этапе разработки системы решается вопрос, как реализовать решения, принятые на этапе анализа.
Сначала разрабатывается общая структура (архитектура) системы. Архитектура системы определяет ее разбиение на модули, задает контекст, в рамках которого принимаются проектные решения на следующих этапах разработки. Приняв решения о структуре системы в целом, разработчик системы производит ее разбиение на относительно независимые в реализации части (модули), разделяя разработку между разработчиками выделенных модулей, что дает возможность расширить фронт работ, подключить к разработке системы новых исполнителей.
На этапе конструирования системы ее разработчик должен принять следующие решения:
определить разбиение системы на модули;
выявить асинхронный параллелизм в системе;
определить состав вычислительного комплекса, на котором будет работать система;
распределить компоненты системы по процессорам вычислительного комплекса и независимым задачам;
организовать управление хранилищами данных;
организовать управление глобальными ресурсами;
выбрать принципы реализации управления программным обеспечением;
организовать управление пограничными ситуациями.
2.1.1. Разбиение системы на модули
Первое, что необходимо сделать, начиная этап разработки системы, определить ее разбиение на некоторое количество компонентов - модулей. Модуль не является ни объектом, ни функцией; модуль - это набор (пакет) классов и отдельных объектов, подсистем, зависимостей, операций, событий и ограничений, которые взаимосвязаны и имеют достаточно хорошо определенный и по возможности небольшой интерфейс с другими модулями. Часто модуль включает одну подсистему, являясь ее реализацией. Модуль (подсистема) обычно определяется через службы, которые он обеспечивает. Службой называется набор взаимосвязанных функций, которые совместно обеспечивают какую-либо функциональность, например, выполнение ввода-вывода, обрисовку картинок, выполнение арифметических действий. Подсистема определяет согласованный способ рассмотрения одной из сторон прикладной задачи, для решения которой разрабатывается рассматриваемая система. Например, система файлов - подсистема операционной системы; она обеспечивает набор взаимосвязанных абстрактных операций, которые в большой степени (но не полностью) независимы от абстрактных операций, обеспечиваемых другими подсистемами. Эта подсистема может быть реализована в виде отдельного модуля.
Как уже отмечалось, каждая подсистема имеет хорошо определенный (внешний) интерфейс с остальной частью системы (другими подсистемами). Этот интерфейс определяет форму всех взаимодействий с подсистемой и все потоки данных через ее границы, но не специфицирует внутреннюю структуру и внутреннее окружение подсистемы, а также особенности ее реализации. Поэтому каждая подсистема может разрабатываться независимо от остальных подсистем.