Архитектура, управляемая моделью (курсовая), страница 3
Описание файла
PDF-файл из архива "Архитектура, управляемая моделью (курсовая)", который расположен в категории "". Всё это находится в предмете "распределённые ис и базы данных" из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве НИУ «МЭИ» . Не смотря на прямую связь этого архива с НИУ «МЭИ» , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "распределённые ис и базы данных" в общих файлах.
Просмотр PDF-файла онлайн
Текст 3 страницы из PDF
Пока это не сделано, значительную часть рутинной работыпридется выполнять вручную [3].13Архитектура CWMCWMСпецификация Common Warehouse Metamodel (Общая метамодельХранилища данных, далее CWM) определяет метамодель (модель моделиданных), представляющую как бизнес, так и технические метаданные,которые в большинстве случаев присутствуют в области технологииХранилищ данных и бизнес аналитики. Она используется как основа дляобмена экземплярами метаданных между гетерогенным программнымобеспечением, поставляемым различными производителями. Системы,которые "понимают" метамодель CWM, обмениваются данными в форматах,которые согласуются с этой моделью.CWM выражен на языке UML (Unified Modeling Language,Унифицированный язык моделирования).
Но, хотя UML являетсянотационным основанием для определения CWM, CWM расширяет базовуюметамодель UML с помощью концепций технологий Хранилищ данных ибизнес-анализа.Можно сказать, что CWM расширяет язык UML в том смысле, чтокаждый метакласс (metaclass) CWM наследуется напрямую, либоненапрямую из метаклассов UML. Таким образом, CWM можнохарактеризовать как язык определенной области применения,предназначенный для определения моделей Хранилищ данных.CWM определяющая метамодель для обмена экземплярамиметаданных между различными средствами моделирования иинформационными системами [4].MOFДругой стандарт OMG - Meta Object Facility (Средство метаобъекта,MOF) - определяет общие интерфейсы и семантику для взаимодействующихметамоделей. MOF - это пример мета-метамодели, или модели метамодели14(подмножество UML). Он также определяет набор IDL-преобразований(Interface Definition Language, язык описания интерфейса, которыйустанавливает спецификацию интерфейса для обнаружения и управлениямоделей с помощью программных APIs).Помимо определения общей семантики для метамоделей MOF такжеслужит в качестве модели для UML (то есть в конечном итоге MOFопределяет язык, на котором выражается метамодель UML).
ПосколькуCWM наследуется из UML, MOF также является моделью и для CWM. Всемодели CWM выражаются на UML и реализуют семантику MOF.MOF состоит из четырех уровней, верхний из которых соответствуетмета-метамодели. Третий уровень соответствует метамодели (например,UML). Второй уровень соответствует экземпляру UML модели, описывающеекакую-либо систему. Самый нижний уровень отражает экземплярымоделируемых объектов [4].XMIНаконец, третий стандарт, который непосредственно задействован вобмене метамоделями - это XMI. XMI (XML Metadata Interchange, Обменметаданными XML) - это стандарт OMG, который устанавливает правилапреобразования метамоделей MOF в XML. XMI определяет, какиспользовать XML-теги для представления сериализованных моделей,совместимых с MOF.
Метамодели MOF транслируются в XML DTD, амодели - в XML-документы, которые согласуются со своими DTD.XMI описывает отображение метамоделей, построенных согласно MOFв XML, который в свою очередь может являться основой для обменаметаданными [4].Представление метамоделиКаждая метамодель CWM представляется как XML DTD (всоответствие с правилами XMI), так и определение IDL. В первом случае15модели CWM преобразуются в поток (serialize), после чего имиобмениваются, как документами XMI. При экспорте метаданныепосредством XMI-документа, необходимо выполнить XMI-преобразование(MXI-rendering) в форме, которая легальна по отношению к DTD. Приимпорте данных с помощью XMI-документа, следует проверять модель надопустимость по этим DTD.Во втором случае моделей объектов CWM создаются в памяти илихранятся в репозитории - в этой ситуации IDL предпочтительней, посколькуон определяет необходимые интерфейсы, подписи методов и структурусовокупности , которые эта модель должна поддерживать.Итак, CWM фактически состоит из ряда составных метамоделей (илисуб-метамоделей), которые организованы в виде следующих 4 слоев:базовый слой (Foundation), источники данных (Resources), анализ (Analysis) иуправление Хранилищем (Management) .Базовый слой состоит из метамоделей, которые поддерживаютмоделирование таких различных элементов и сервисов, как типы данных,16системное преобразование типов, абстрактные ключи и индексы, выражения,бизнес-информация и включения программного обеспечения, основанного наиспользовании компонентных объектов.Слой источников данных предоставляет возможность моделироватьсуществующие и новые источники данных, в том числе реляционные базыданных, ориентированные на запись базы данных (record oriented databases), атакже XML- и основанные на объектах (object-based) источники данных.Слой анализа предоставляет средства для моделирования сервисовинформационного анализа, которые обычно используются в Хранилищеданных.
Он определяет метамодель для преобразования данных, OLAP,визуализации информации/репортинга (business nomenclature) и data mining.Слой управления состоит из метамоделей, представляющихстандартные процессы и операции Хранилища данных, журнализации(activity tracking) и планирования работ [scheduling] (например, ежедневнойзагрузки и выгрузки).Этот набор метамоделей, предоставляемых CWM, достаточен длямоделирования всего Хранилища данных. Используя инструмент,поддерживающий CWM, можно было бы сгенерировать экземплярХранилища данных прямо из модели Хранилища данных. Каждый из этихразличных инструментов использует те части модели, которыми можновоспользоваться. Например, сервер реляционной базы данных задействуетреляционный блок этой модели и будет использовать его для построения егокаталога.
Аналогично OLAP-сервер будет отыскивать в модели метаданныеOLAP и использовать их для определения многомерной схемы. А инструментизвлечения, преобразования и загрузки данных (ETL) скорее всего обработалбы срез модели Хранилища данных, которая охватывает несколькометамоделей CWM, в том числе метамодели OLAP, преобразования, типаданных, преобразования типов, выражений и реляционную метамодель [4].17ТехнологияModelDrivenArchitecture(MDA),суть,перспективы использования.Model Driven Architecture — модельно-ориентированный подход кразработке программного обеспечения.Суть этой технологии состоит в построении абстрактной метамоделиуправления и обмена метаданными (моделями) и задании способов еетрансформации в поддерживаемые технологии программирования (Java,CORBA, XML и др.).Архитектура MDA предлагает новый интегральный подход к созданиюмногоплатформенных приложений и базируется на трех основных элементах:UML(Unified ModellingLanguage) унифицированный языкмоделирования;MOF (MetaObject Facility)абстрактный язык для описанияинформации о моделях (языкописания метамоделей);CWM (CommonWarehouse Metamodel) общийстандарт описания информационныхвзаимодействий между хранилищамиданных.На центральном уровне структуры находится собственно MDA,которая«разворачивается»наружупосредствомвторогосодержащего вышеперечисленные базовые составляющиеуровня,UML, MOF иCWM, и на третьем, внешнем уровне представлены некоторые из широкоизвестных в настоящее время программных платформ разработки: CORBA,18XML, .NET, JAVA.
На этом внешнем уровне, по замыслу OMG, могут идолжны быть размещены и все возможные будущие технологии разработки.Этим подчеркивается тот факт, что OMG считает архитектуру MDA непростоновойтехнологией,аскорее«метатехнологией»созданияприложений. Последняя отныне будет и единственно актуальной — внезависимости от развития и появления новых средств разработки, которыеMDA уже «заранее интегрировала» в себя.Само понятие «разработчик программного обеспечения» может привнедрении MDA довольно сильно видоизмениться.
Со смещением акцента насоздание модели разработкой приложений будут заниматься не столькопрограммисты, сколько специалисты, владеющие описываемой предметнойобластью.Возможно,чтотакжевкакой-тостепени«пострадает»традиционное деление специалистов на разработчиков баз данных иразработчиков приложений баз данных. Уже сейчас возможно приразработке MDA-приложений практически полностью абстрагироваться отзнания конкретной СУБД; более того, во многих случаях нет необходимостии использовать язык SQL, поскольку многиеинструменты MDAпредоставляют возможность работать на более «высоком» уровне (бизнесуровне), где становится абсолютно не важным знаниеконкретнойструктурной схемы базы данных или состава полей ее таблиц.Однако программисты-разработчики вряд ли останутся без работы, таккак, с одной стороны, создание MDA-инструментария само по себе являетсячрезвычайно интересной, сложной и объемной задачей для них.
А с другойстороны, внедрение MDA уже сейчас избавляет и самих программистов отрутиннойработы,передаваябольшуюеечастьискусственномупрограммному интеллекту — инструментам реализации MDA [5].19Жизненный цикл разработки с помощью MDAЖизненный цикл разработки с помощью MDA не сильно отличается оттрадиционного. Он разделен на такие же этапы.Одно из существенных различий состоит в природе артефактов,которые создаются во время процесса разработки. Здесь артефакты являютсяформальными моделями, то есть (говоря примитивным языком), моделями,понятными компьютерам.
Далее рассмотрим три вида моделей, из которыхсостоит ядро технологии MDA [6].20Типы моделейАрхитектура MDA описывает и структурирует поэтапный процессразработки любых программных систем на основе создания и использованиямоделей. При этом используется несколько типов моделей, создаваемых ипреобразуемых на различных этапах разработки. Процесс разработки поMDA это последовательное (поэтапное) продвижение от одной моделисистемы к другой. При этом каждая последующая модель преобразуется изпредыдущей и дополняется новыми деталями. Модели, общая схемаразработки и процесс преобразования моделей - ключевые составные частиархитектуры.Основная идея MDA в том, что преобразование из PIM в PSM,а также же генерация кода из PSM, может производиться автоматически.Преобразования проводятся при помощи инструментов преобразования(transformationtools),которыев своюочередьиспользуютправилапреобразования.