Поделиться через

Логическая модель: определение приложения и планирование

  • Статья

Второй шаг в процессе проектирования приложений COM+ — разбить концептуальную модель на логические уровни трехуровневой архитектуры: уровень презентации или пользовательские службы, средний уровень или бизнес-службы, а также уровень данных или службы данных. Если вы не знакомы с трехуровневой архитектурой, см. статью "Использование модели архитектуры с тремя уровнями".

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

Большинство бизнес-объектов в конечном итоге будут находиться на уровне бизнес-служб, а остальные объекты разделены между объектами пользовательского интерфейса на уровне служб пользователей и объектами данных на уровне служб данных. При создании логической модели с помощью трехуровневой архитектуры следует учитывать следующее:

  • Некоторые существительные в концептуальном дизайне не представляют фактические физические части данных, но могут представлять действие по системе или роли бизнес-объекта в системе. Бизнес-объект также может быть службой, которая выполняет какой-то системный контроль, например идентификатор входа для безопасности.
  • Избегайте создания расплывчатых бизнес-объектов путем чтения между строками в концептуальной модели. Такие бизнес-объекты могут не быть правильными, и следует тщательно рассмотреть их перед их включением в логическую модель. Если они отображаются правильно, добавьте их в концептуальную модель явно.
  • Избегайте создания бизнес-объектов, которые выражают ту же информацию или функцию; дублирование может быть дорогостоящим с точки зрения скорости и производительности приложения.
  • Определите зависимости объектов. Некоторые существительные в концептуальной модели могут просто быть атрибутами других бизнес-объектов. Определите, может ли атрибут существовать независимо. В этом случае он должен стать собственным бизнес-объектом; Если нет, его следует объединить с соответствующим бизнес-объектом.
  • Избегайте создания бизнес-объектов, которые пытаются сделать слишком много. Перегрузка бизнес-объектов может означать больше времени, затрачиваемого на разделение кода позже, и может быть головной болью обслуживания. Отдельные объекты в концептуальной модели не должны объединяться; Они должны оставаться отдельными бизнес-объектами. Вы можете обрабатывать любые сходства с помощью кода для делегирования общих функций бизнес-объекту.
  • Удалите все бизнес-объекты, которые не используются в каких-либо сценариях использования. Если объекты предназначены для дальнейшего роста, рассмотрите возможность их реализации после завершения первоначального приложения.

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

Определение службы или объекта не должно включать какой-либо аспект физической реализации. Цель заключается в том, чтобы предоставить четкое руководство для построителей логических компонентов для работы и включения других программистов кодировать части приложения, которые могут использовать компонент до его завершения. В конструкторе логической модели необходимо документировать каждый экран, функцию и объект. Не переходите к физической модели или реализации, пока не будете соответствовать этим критериям. Если вы продолжаете работу, пока концептуальная модель и логическая модель не находятся в соглашении, у вас будут серьезные проблемы позже в цикле разработки.

Добавочная разработка приложения COM+ распространена. Это включает создание подмножества конечных, известных компонентов и их тестирование с помощью каждого слоя приложения: клиентских, бизнес-уровней и уровней данных через хранилище данных. Эта рабочая модель предоставляет представление о дополнительных требованиях клиентов и реализации. Часто эта рабочая модель тестируется на одном компьютере.

Концептуальная модель: требования к приложениям

Физическая модель: архитектура приложения

Использование модели трехуровневой архитектуры