Навигация
Концептуальная модель клиента
16886
знаков
0
таблиц
17
изображений
3. Концептуальная модель клиента
Клиентское приложение на рис. 3.1 построено на основе популярного шаблона Модель-Вид-Контроллер (Model-View-Controller) [1]. Моделью служит абстрактный класс Model, который необходимо расширить для разных типов моделей, присутствующих в клиентском приложении. В роли Вида выступает абстрактный класс View, который соответственно необходимо переопределить для имеющихся видов в клиентском приложении. В роли контроллера выступает интерфейс Command, который необходимо реализовать в командах, производящих действия над Моделью на основе событий, приходящих в Вид от пользователя. Также применяется шаблон Mediator, выступающий в роли посредника между взаимосвязанными Видами. Клиентское приложение взаимодействует с сервером приложений через такие интерфейсы, как FactSourceInterface, MetaSourceInterface и SecuritySourceInterface.
Рис. 3.1 Концептуальная модель клиента
3.1. Пакет вид
Пакет client.view на рис. 3.2 представляет собой набор классов со ссылками на объекты из пакета client.model. Другими словами, Вид строится на основании Модели. Для того, чтобы ослабить их сцепленность (coupling), взаимосвязь между связанными Видами, используется ссылка на посредник класс Mediator, которому делегируются события, приходящие из внешнего мира от пользователя. В случае, когда есть уже готовый инструментарий для построения приложения, следует применять шаблон Adapter при адаптации имеющихся компонентов Видов. В случае, когда приходится самостоятельно реализовывать обвязку API, следует обратить внимание на шаблоны Composite, Decorator. Chain of Responsibility и Observer.
Рис. 3.2 Пакет вид
3.2. Пакет модель
Пакет client.model на рис. 3.3 содержит классы Модели, которые отображаются классами Вида из пакета client.view. В случае, когда есть уже готовый инструментарий для построения приложения, приходится адаптировать имеющиеся Модели из пакетов client.model.fact, client.model.meta и client.model.security с помощью шаблона Adapter к имеющимся моделям.
Рис. 3.3 Пакет модель
3.3. Пакет посредник
Пакет client.mediator на рис. 3.4 содержит класс Mediator, в роли которого может выступать главный класс приложения с методом main(). Обычно в сложных клиентских приложениях присутствует несколько расширяющих его классов.
Рис. 3.4 Пакет посредник
3.4. Пакет контроллер
Пакет client.controller на рис. 3.5 содержит интерфейс Command, который описывает стандартный способ инициирования команд, наследуемых от этого интерфейса. В этом пакете содержится классы, содержащие бизнес-логику, которая манипулирует моделью.
Рис. 3.5 пакет контроллер
4. Пример функционирования распределенной архитектуры
Описанная выше картина представляет собой функционально-ориентированный взгляд на систему и имеет статический характер. Для получения динамической картины работы всей системы следует обратить внимание на диаграмму кооперации на рис. 4.1.
Рис. 4.1 Функционирование системы
На данной диаграмме умышленно опущены детали и моменты ветвления потока управления системы для того, чтобы выделить главную идею работы, не погружаясь в детали. Распишу событийную модель по шагам:
Пользователь воздействует на Вид (View) клиентского приложения.
Вид делегирует событие Посреднику (Mediator).
Посредник обращается к Заводу (FactSourceFactory), чтобы тот создал Proxy-объект, поддерживающий интерфейс FactSourceInterface для работы с фактами.
Медиатор вызывает Контроллер (Controller) который отвечает за обработку данного типа события пришедшего от пользователя.
Контроллер посылает запрос к созданному Proxy-объекту на 3 шаге.
Proxy-объект, поддерживающий интерфейс FactSourceInteface, делегирует запрос к Источнику Фактов (AbstractFactSource) в ядре, находящемуся на стороне сервера приложения. На этом шаге происходит сетевой вызов, который проходит через стаб (stub) клиентского приложения и скелетон (skeleton) сервера приложения, где реализуется взаимодействие на одной из технологий RMI, CORBA, DCOM или др.
На стороне сервера происходит аутентификация с помощью завода, отвечающего за безопасность (SecurityFactory). Процесс аутентификации происходит только при первом обращении клиентского приложения к серверу приложений.
Происходит процесс авторизации, во время которого выясняются права доступа пользователя.
Ядро запрашивает Метамодель (MetaModel) у Завода Метаданных (MetaFactory) для описания факта, с которым взаимодействует пользователь.
Завод Метаданных извлекает запрашиваемую Метамодель.
Ядро запрашивает Метамодель на предмет Картриджа (FactCartridge), в котором находится факт.
Метамодель берет Картридж, в котором находится искомый факт.
Для доступа к фактам для разных типов источников данных ядро запрашивает у Картриджа объект, поддерживающий интерфейс FactDAO.
Картридж запрашивает этот объект у Завода Доступа к Фактам (FactDAOFactory), который создает эти объекты.
Завод Доступа к Фактам создает запрашиваемый объект.
Ядро делегирует объекту запрос от Контроллера клиентского приложения.
Объект, поддерживающий интерфейс FactDAO, производит изменения факта (Fact).
Управление возвращается в Контроллер клиентского приложения, производящий коррекцию Модели (Model).
Медиатор посылает сообщение об обновлении Модели Виду, и он производит свою перерисовку.
5. Сложность реализации
Предложенная мной спецификация имеет точки соприкосновения со спецификацией EJB в плане целей, но не содержит ограничения на архитектуру безопасности, бизнес-объектов и их описаний. Спецификация не имеет узкую направленность на конкретную распределенную технологию, такую как RMI, и определяет архитектуру клиентских приложений, чего нет в спецификации EJB. Использование уже готовых реализаций спецификации EJB очень привлекательно по сравнению с самостоятельной реализацией, предложенной мной спецификации, но в силу своих ограничений может быть отвергнута. Для получения первой версии реализации спецификации каркаса системы с распределенной архитектурой было затрачено шесть месяцев группой программистов из 6 человек с 8 часовым рабочим днем и 5 дневной рабочей неделей. Для тех организаций, которые решили воспользоваться данной спецификацией, следует предварительно просчитать все плюсы и минусы ввязывания в данную разработку.
6. Благодарности
Выражаю свою благодарность людям, которые имели прямое отношение к реализации спецификации и внесения в нее своих поправок: Алексей Неупокоев, Юрий Юдин, Роман Камерлох, Тарас Улахович, Геннадий Пестунов, Иван Пономаренко. Без участия этих людей данная спецификация никогда бы не была мной получена.
Список литературыГамма Э. Приемы объектно-ориентированного проектирования (паттерны проектирования). - Санкт-Петербург: Издательство «Питер», 2001. – 368с.
Цимбал А. Технология CORBA для профессионалов. – Санкт-Петербург: Издательство «Питер», 2001. – 62
Похожие работы
... Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем. 3 Глава. Разработка концептуальной модели информационной системы для поддержки принятия управленческих решений при формировании маркетинговой стратегии региона Процесс создания и внедрения любой ИС принято разделять на четыре последовательные фазы: анализ, глобальное проектирование ( ...
... их интеграция, расширение их возможностей в новых версиях, создание новых средств и перенос их на другие аппаратные платформы и в другие ОС IBM. 12.4 Операционная система z/VM ОС z/VM [21, 24, 42] (последняя версия - V4R2) является высокопроизводительной многопользовательской интерактивной ОС, предоставляющей уникальные возможности в части выполнения различных операционных сред на одном ...
... коммуникационного центра. 51 1. Реферат. В целях комплексной автоматизации документооборота, а также повышения качества диагностики и лечения онкологических больных в Мелитопольском межрайонном онкологическом диспансере, разработан проект информационно-диагностической системы, предназначенной для оперативного ввода, анализа и хранения графической, текстовой лечебно-диагностической информации и ...
... предприятия. Для дальнейшего развития Системы необходимо рассчитать экономическую эффективность проекта. Для этого необходимо выбрать направление распространения Системы. Заказчиком системы выступало закрытое акционерное общество "Белгородский бройлер". Произведем расчет экономической эффективности проекта с точки зрения заказного проекта. Структура экономической части при создании программного ...
0 комментариев