Спецификация требований к ПО “Система коллекционирования”

спецификации рамки информационной системы с распределенной архитектурой

спецификации рамки информационной системы с распределенной архитектурой

Евгений Игумнов

Введение

Полученная мной спецификации рамки системы с распределенной архитектурой (distributed framework - dfw) можно использовать как отправную точку при создании корпоративных распределенных систем. Предлагаемая спецификация не зависит от распределенной технологии, в основе которого будет построена система. Другими словами, предлагаемая спецификация может быть использован совместно с технологиями RMI, CORBA, DCOM и других Вопросов осуществления интеграции этих технологий, не рассматриваются. Они находятся на разработчики решили использовать эту спецификацию. Спецификации были получены при анализе трех типов систем: OLTP, OLAP и ГИС. Структура системы имеет целью объектно-ориентированный язык и на основе набора шаблонов дизайна, высокое повторного использования.

1. Итого компонент модели

Система состоит из трех частей: клиентское приложение (GUI или Веб-сайта), сервер приложений и источник данных (базы данных, XML и др.). Идеология системы основана на три вещи: факты, политика безопасности. Факты являются так называемые бизнес-объекты из области, с которой будет работать система. Метамодель представляет собой описание этих бизнес-объектов. Безопасность - это описание прав доступа на факты и метамодели. Диаграмма пакетов системы представлена на рис. 1.1. Следует обратить внимание на функциональную значимость метамодель в этой системе. Как правило, при реализации большого количества типов бизнес-объектов (фактов) для каждого самом деле ставится в соответствие класс. Для того, чтобы увеличить степень повторного использования и упростить механизм поддержки большого числа типов факты из вашей системы, следует все факты, выбрать только один или два класса, а структура фактов описывает метамодель. Поэтому, когда меняется структура деяния, не будет необходимости менять исходный код, и будет достаточно, чтобы исправить данные в источнике данных, например, базы данных, откуда берет данные метамодели.

Рис. 1.1 Диаграмма зависимости между пакетами,

на стороне Клиента состоит из 10 пакетов. Пакет view отвечает за ее внешний вид. Пакет посредника сопрягает типы приложений. Пакет модели отвечает за внутреннее представление данных приложения. Пакет контроллер содержит классы, которые работают с моделью данных приложения. Пакет модели.fact структура фактов, которые меняются клиентского приложения с сервером приложений. Пакет модели.мета представляют собой структуры, которые описывают факты, то есть метамодель, которые меняются клиентского приложения с сервером приложений. Пакет модели.security представляет собой структуру, которая описывает безопасность доступа на факты и метамодели, которые также обмена клиентского приложения с сервером приложений. Пакеты кодом.fact, кодом.мета и кодом.security отвечают за взаимодействие между клиентским приложением и сервером приложений и поддерживать между ними обмен фактами (модель.fact), метаданные (модель.мета) и безопасности (модели.security), независимо от того, используется разработчиком технологий распределенной. Иными словами, в основе они должны делать стабы (заглушки) [2].