Навигация
Пакеты модели метамодели, фактов и безопасности
16886
знаков
0
таблиц
17
изображений
2.1. Пакеты модели метамодели, фактов и безопасности
Пакет model.meta на рис. 2.2 содержит классы, описывающие метамодель предметной области, с которой работает система. Мной было выделено всего три основных класса для этой цели. Безусловно, ее необходимо расширять для каждой специфической предметной области. Класс MetaModel предназначен для того, чтобы держать в одной системе несколько метамоделей. Класс FactDescription описывает факты. Класс Group выступает в роли тематического классификатора фактов, который всегда присутствует в информационных системах и может быть также расширен.
Рис 2.2 Модель метамодели
Пакет model.fact на рис. 2.3 имеет всего один класс Fact, объекты которого будут фактами. Этот класс следует, безусловно, расширить, так как встреченные мной факты из разных предметных областей имеют общее только то, что они являются фактами.
Рис. 2.3 Модель фактов
Пакет model.security на рис. 2.4 описывает права доступа к системе, к фактам и метамодели. За основу взято классическое решение безопасности. Есть пользователи (класс User), которые сопоставлены с ролями (класс Role), имеющими права доступа (класс Access) на метамодель, которая также описывает факты. Соответственно, отсутствие прав доступа на описание факта отсекает доступ на сам факт. В процессе аутентификации участвует класс User, а в процессе авторизации - классы Role и Access соответственно.
Рис. 2.4 Модель безопасности
2.2. Пакет источников данных
Пакет server.datasource на рис. 2.5 обеспечивает связку между источниками данных и фактами. Другими словами, здесь описывается, в каком источнике данных находится какой факт. Вводится понятие картриджа (класс FactCarttridge), представляющего источник данных, в котором хранятся факты. Для работы с конкретным типом источником данных картридж использует интерфейс FactDAOInterface. Данный подход позволяет серверу приложений, с одной стороны, хранить свои факты в разных источниках данных, а с другой, не заботиться клиентскому приложению о том, как они хранятся и как расположены физически, что облегчает клиентскую часть системы.
Рис. 2.5 Источник данных
2.3. Пакет доступа к фактам
Пакет server.factdao на рис. 2.6 отвечает за работу с фактами для разных типов источников данных. За основу берется интерфейс FactDAOInteface, задающий принципы работы с фактами. Его необходимо реализовать для всех типов источников данных, которые будут подключены к системе. При реализации данного интерфейса в случае, когда некоторые источники данных имеют общие черты, следует использовать Template Method для увеличения степени повторного использования кода.
Рис. 2.6 Доступ к фактам
2.4. Пакет ядра
Пакет server.kernel на рис. 2.7 представляет собой набор заводов FactDAOFactory, MetaFactory и SecurityFactory, управляющих моделями пакетов model.fact, model.meta и model.security, которые были описаны выше. Классы AbstractMetaSource и AbstractFactSource в своей работе используют безопасность, т.е. пользуются услугами SecurityFactory. Основная функциональная нагрузка ядра ложится на классы AbstractFactSource, AbstractMetaSource и AbstractSecuritySource, но процесс управления объектами моделей model.fact, model.meta и model.security делегируется классам FactDAOFactory, MetaFactory и SecurityFactory с использованием шаблона Adapter.
Рис. 2.7 Ядро системы
2.5. Пакеты источников метамодели, фактов и безопасности
Пакет source.meta на рис. 2.8 представляет собой интерфейс MetaSourceInterface с поддерживающим его заводом по шаблону Factory Method, который предоставляет клиентскому приложению Proxy-объект этого интерфейса по шаблону Proxy. Как уже говорилось выше, на стороне клиентского приложения реализуют этот интерфейс в виде стаба (stub), а на стороне сервера приложения - в виде скелетона (skeleton).
Рис. 2.8 Источник метамодели
Пакет source.fact на рис. 2.9 построен по таким же принципам, как пакет source.meta.
Рис. 2.9 Источник фактов
Пакет source.security на рис. 2.10 построен по таким же принципам, как пакет source.meta.
Рис. 2.10 Источник безопасности
Похожие работы
... Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем. 3 Глава. Разработка концептуальной модели информационной системы для поддержки принятия управленческих решений при формировании маркетинговой стратегии региона Процесс создания и внедрения любой ИС принято разделять на четыре последовательные фазы: анализ, глобальное проектирование ( ...
... их интеграция, расширение их возможностей в новых версиях, создание новых средств и перенос их на другие аппаратные платформы и в другие ОС IBM. 12.4 Операционная система z/VM ОС z/VM [21, 24, 42] (последняя версия - V4R2) является высокопроизводительной многопользовательской интерактивной ОС, предоставляющей уникальные возможности в части выполнения различных операционных сред на одном ...
... коммуникационного центра. 51 1. Реферат. В целях комплексной автоматизации документооборота, а также повышения качества диагностики и лечения онкологических больных в Мелитопольском межрайонном онкологическом диспансере, разработан проект информационно-диагностической системы, предназначенной для оперативного ввода, анализа и хранения графической, текстовой лечебно-диагностической информации и ...
... предприятия. Для дальнейшего развития Системы необходимо рассчитать экономическую эффективность проекта. Для этого необходимо выбрать направление распространения Системы. Заказчиком системы выступало закрытое акционерное общество "Белгородский бройлер". Произведем расчет экономической эффективности проекта с точки зрения заказного проекта. Структура экономической части при создании программного ...
0 комментариев