Ви є тут

Метод побудови програмного забезпечення систем дистанційного навчання

Автор: 
Хальдун Дакак Набіль
Тип роботи: 
Дис. канд. наук
Рік: 
2006
Артикул:
0406U003259
129 грн
Додати в кошик

Вміст

РАЗДЕЛ 2
метод построения пРОГРАММНОГО
ОБЕСПЕЧЕНИЯ сИСТЕМЫ дистанционного
обучения. многоуровневое представление
и шаблонирование
В данной главе исследуются принципы многоуровневого представления и
шаблонирования.
2.1. Принцип многоуровневого представления
Многоуровневая архитектура в общем случае имеет следующие уровни [122]:
представления (клиент), бизнес-логики, хранение (см.рис.2.1).

Рис. 2.1 Архитектура ПО СДО
Уровень представления отображает взаимодействия СДО с клиентом. Данные
вводятся клиентом в СДО и выводятся клиенту. Для Web-приложения уровень клиента
может быть представлен командной строкой, текстовым или графическим окном ввода
данных, просмотра и отображения клиентам в Web-окне. На этом уровне известно
как обрабатывать запрос клиента, как взаимодействовать с уровнем бизнес-логики,
и как выбрать текущее отображение.
Уровень бизнес-логики отражает обработку запросов уровня представления
преобразования (в объекты и сервисы уровня бизнес-логики). Инициируются и
выполняются функции бизнес-логики и осуществляется промежуточный доступ к
ресурсам уровня хранения. Компоненты уровня бизнес-логики лучше всего
сочетаются с услугами системного уровня, например, такими, как управление
безопасностью, трансакциями и ресурсами.
Уровень хранения отражает обработку запросов уровня бизнес-логики в уровнь
хранения, отделяя таким образом уровень бизнес-логики от уровня хранения
данных.
Указанное общее деление на уровни является основой для ряда конкретных моделей
многоуровневых архитектур, например, Брауна [6], Core J2EE [2], Microsoft DNA
[16], Маринеску [17], Нильссона [19] (табл.2.1).
Модель Брауна различает в архитектуре пять уровней: представление,
контроллер/медиатор, домен, отображение данных и источник данных. Два новых
уровня (контроллер/медиатор и отображение данных) выполняют посреднические
функции между базовыми уровнями. Уровень контроллер/медиатор соединяет уровни
представления и домена, а уровень отображения данных связывает предметную
область и источник данных.
Модель типовых решений Core J2EE различает в архитектуре следующие уровни:
клиент, представление, бизнес, интеграция и ресурсы. Для уровней бизнеса и
интеграции существуют прямые аналоги в рассмотренной общей схеме (рис.2.1).
Уровень ресурсов представляет внешние службы, с которыми соединен уровень
интеграции. Основное отличие связано с расщеплением уровня представления между
клиентом и сервером, на две части (уровень клиента и уровень представления).
Модель Microsoft DNA различает в архитектуре три уровня – представление,
бизнес и доступ к данным, которые довольно точно отвечают рассматриваемым в
общей схеме трем уровням. Наибольшее отличие состоит в способе передачи
информации от уровня доступа к уровню данных. В Microsoft DNA все уровни
оперируют данными, возвращаемыми SQL-запросами. Поэтому уровни бизнеса и
представления учитывают, что при реализации соответствующие функции выполняются
конкретной СУБД.
Модель Маринеску различает в архитектуре пять уровней. Уровень представления
расщеплен на два уровня, отображающих структуру контроллера приложения. Уровень
домена также расщепляется. На основе модели предметной области сконструирован
уровень служб. Это соответствует обычной практике деления уровня бизнес-логики
на две части собственно приложения и сервисы, обслуживающие приложение.
Таблица 2.1
Модели построения многоуровневой архитектуры программного обеспечения
Названия модели
Уровни
Брауна
Представление, контроллер, домен, отображение, база данных
Core J2EE
Клиент, представление, бизнес, интеграция, ресурсы
Microsoft DNA
Представление, бизнес, доступ к данным
Маринеску
Представление, приложение, службы, домен, хранение данных
Нильссона
Потребитель, вспомогательный слой потребителя, приложения, доступ, доступ к
данным, хранимые процедуры
Фаулер
Представление, домен, источник данных
Выделение уровня служб в модели предметной области основано на предположении о
возможности отделения логики процесса (управления) от «чистой» бизнес-логики
(функции). Уровень служб обычно охватывает логику, которая относится к
конкретному варианту использования системы или обеспечивает взаимодействие с
другими инфраструктурами (например, с помощью механизма сообщений).
Модель Нильссона различает в архитектуре следующие уровни: потребитель;
вспомогательный слой потребителя; приложение; домен; доступ к хранимым данным;
общедоступные хранимые процедуры; приватные хранимые процедуры. Реализация
модели предусматривает использование хранимых процедур и размещение в них
фрагментов бизнес-логики для повышения производительности приложения. Вынесение
бизнес-логики в хранимые модули ведет к усложнению процедур сопровождения кода,
а уровни хранимых процедур Нильссона содержат как источники данных, так и
бизнес-логику. Как и модель Маринеску, для описания бизнес-логики модель
Нильссона использует отдельные уровни приложения и домена. Однако предлагает
отказаться от уровня домена в небольших системах.
Для реализации уровня представления, как показывает опыт, лучше выбирать
существующие, доказавшие свою работоспособность структуры Web-приложений, а не
строить заказную структуру.
Для уровня бизнес-логики могут быть использованы Enterprise JavaBeans (EJB)
или простые старые объекты Java (POJO). При этом, EJB с удаленными интерфейсами
лучше использовать, если приложение распределено.
Для уровня хранения могут быть использованы следующие технологии:
- Pure Java Database Connectivity (JDBC);
- Entity beans - beans объекта с постоянным управляю