Жизненный цикл разработки с помощью MDA

Введение
Аббревиатура MDA расшифровывается как Model Driven Architecture архитектура, управляемая моделью. MDA это архитектура, описывающая новый способ разработки программного обеспечения. Название говорит само за себя очевидно, что в рамках этой архитектуры создание приложений базируется на разработке модели приложения.В основе новой архитектуры лежит идея о полном разделении этапов общего проектирования (моделирования) и последующей реализации приложения на конкретной программной платформе. Идея эта не нова: сначала при помощи специальных средств проектирования создается общая и независимая от способов реализации модель приложения, а затем осуществляется реализация программы в какой-либо среде разработки. При этом процесс разработки полностью основан на модели, которая должна содержать всю необходимую для программирования информацию. Очевидны преимущества, которые дает такой подход:Независимость модели от средств разработки обеспечивает возможность реализации на любой программной платформе.Приложение, реализованное в архитектуре MDA, может быть легко перенесено из одной операционной системы в другую.Существенна экономия ресурсов при реализации приложения для нескольких программных платформ одновременно.1. Основные понятияМодель - описание или спецификация системы и ее окружения, созданная для определенных целей. Часто является комбинацией текстовой и графической информации. Текст может быть описан специализированным или естественным языком.Управление на основе модели - процесс разработки системы,использующий модель для понимания, конструирования, распространения и других операций.Платформа - набор подсистем и технологий, которые представляют собой единый набор функциональности, используемой любым приложением без уточнения деталей реализации.Вычислительная независимость - качество модели, обозначающее отсутствие любых деталей структуры и процессов.Платформенная независимость - качество модели, обозначающее ее независимость от свойств любой платформы.Вычислительно-независимая модель - модель, скрывающая любые детали реализации и процессов системы; описывает только требования к системе и ее окружению.Платформенно-независимая модель - модель, скрывающая детали реализации системы, зависимые от платформы, и содержащая элементы, не изменяющиеся при взаимодействии системы с любой платформой.Платформенно-зависимая модель - модель системы с учетом деталей реализации и процессов, зависимых от конкретной платформы.Модель платформы - набор технических характеристик и описаний технологий и интерфейсов, составляющих платформу.Преобразование модели - процесс преобразования одной модели системы в другую модель той же системы [2].2. Цель MDAВ современных программных системах активно используются много различных стандартов и технологий промежуточного слоя — CORBA, DCOM, .Net, Web-службы, технологии, основанные на Java и т.д. Все чаще возникает потребность в интеграции и обеспечении взаимодействия систем,основанных на разных технологиях, а также в модернизации существующих программ и их переработке в соответствии с новой технологической основой.Новая архитектурная концепция, предложенная консорциумом OMG,основанная на модельно-ориентированном подходе к разработке программного обеспечения, позволяет существенно упростить и частично автоматизировать разработку, интеграцию и модернизацию систем.В связи с большим количеством используемых и разрабатываемых стандартов и технологий стало очевидно, что попытка создать единый универсальный стандарт построения и взаимодействия программных систем обречена на неудачу. Примером тому стандарт CORBA, который, хотя и приобрел определенную известность, так и не занял предполагаемого для него места «универсального стандарта». Поэтому консорциум OMG принял решение перейти от «стандарта интеграции» к интеграции стандартов.Концепция MDA (Model Driven Architecture) призвана обеспечить общую основу для описания и использования большинства существующих стандартов, не ограничивая разработчиков в выборе конкретных технологий.Интеграция стандартов достигается за счет:введения концепции платформно-независимой модели приложения;использования унифицированного инструмента (UML) для описания таких моделей;наличия разработанных OMG стандартных отображений моделей в среду большинства технологических платформ и программных инструментов промежуточного слоя.Использование MDA для разработки и интеграции программного обеспечения позволяет сохранить инвестиции, сделанные в разработку бизнес-логики даже при смене технологических платформ.Модельно-ориентированный подход облегчает интеграцию как разнородных, основанных на различных технологиях распределенных систем, так и организацию взаимодействия между системами, основанными на одной технологии, но использующими разные интерфейсы, сервисы и стандарты. Кроме того, MDA позволяет разрабатывать стандартные сервисы (репозитарии, сервисы событий и сообщений и т.д.), которые поддерживают сразу несколько технологий промежуточного слоя. Например, можно создать репозитарий объектов, который предоставляет соответствующий сервис системам как на базе CORBA, так и на базе Web-сервисов. Это не только упрощает разработку программного обеспечения, но и позволяет организовать взаимодействие различных систем [3].3. Ядро MDAЯдром MDA являются несколько стандартов — UML, MOF, CWM и XMI. Язык UML (Universal Modeling Language) используется для описания всех моделей. Совокупность метамоделей CWM (Common Warehouse Model)представляет наиболее часто используемые в базах данных и инструментах бизнес-анализа метаданные. CWM содержит большое количество различных метамоделей, описывающих функционирование бизнеса. MOF (Meta Object Facility) — общий абстрактный язык для описания метамоделей; на его основе построены формальные описания метамодели для CWM и UML.Последний стандарт, XMI (XML Metadata Interchange), играет служебную роль, описывая отображение моделей MOF и UML на стандарт XML. При этом метамодели преобразуются в DTD-структуру документа, а модели — в тело XML-документа. Это позволяет объединить модель и ее метамодель в одном документе и получить так называемый «самоописываемый» (selfdescribing) документ, содержащий не только данные, но и информацию, необходимую для их интерпретации.В основе MDA лежит понятие платформно-независимой модели(platform independent model, PIM). Речь идет о детальной исполняемой модели на языке действий UML (action semantics) с пред- и постусловиями,сформулированными на OCL.Вполне логично, что для описания PIM выбран язык UML. Этот язык принципиально позиционировался как независящий от платформ и технологий. Однако UML в своих ранних версиях не являлся «точным» языком: он только предоставлял дизайнеру возможность описать структуру и поведение системы, практически не определяя ее функционирование и используемые алгоритмы. В новый стандарт UML 2.0, который был одобрен OMG в июне 2003 года, включено большое количество средств, позволяющих описывать внутреннюю организацию и функционирование системы. Одна из основных задач, которые были решены при создании этого стандарта, — превратить UML в алгоритмически полный исполнимый язык,в то же время, по возможности, не повышая уровня детализации UML-моделей.Несмотря на то, что PIM — это детальная исполняемая модель, ее вряд ли можно использовать на практике как финальный программный продукт.UML-инструментарий нового поколения предоставляет унифицированную среду, в которой можно интерпретировать эту модель и получать исполняемый код прототипного качества. Такой код может быть крайне неэффективным, не удовлетворять некоторым функциональным требованиям, не полностью реализовывать функциональность системы и даже требовать участия человека в процессе исполнения. Инструментарий,используемый для интерпретации UML-модели, может быть полуавтоматическим и допускать вмешательство оператора. Только после привязывания к конкретной платформе можно получить код промышленного качества. Но, хотя исполнение PIM-модели и нельзя применять для решения практических задач, оно необычайно важно для целей тестирования иотладки. Фактически, у разработчиков появляется возможность получить первый прототип системы еще до начала стадии кодирования, когда сравнительно легко вносить даже существенные изменения в систему (в том числе, изменения требований и технического задания).Многие крупные производители объявили о поддержке MDA и начале разработки соответствующих инструментов, и в ближайшее время можно ожидать выхода первых инструментариев разработки с использованиемMDA. Но, вероятно, потребуется значительный период времени, чтобы инструменты развились и смогли максимально использовать возможности технологии. Пока это не сделано, значительную часть рутинной работы придется выполнять вручную [3].4. Технология Model Driven Architecture (MDA), суть,перспективы использованияModel Driven Architecture — модельно-ориентированный подход к разработке программного обеспечения.Суть этой технологии состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов ее трансформации в поддерживаемые технологии программирования (Java, CORBA, XML и др.).Архитектура MDA предлагает новый интегральный подход к созданию многоплатформенных приложений и базируется на трех основных элементах:UML(Unified Modelling Language) унифицированный язык моделирования;MOF (MetaObject Facility)абстрактный язык для описания информации о моделях (язык описания метамоделей);CWM (Common Warehouse Metamodel) общий стандарт описания информационных взаимодействий между хранилищами данных.На центральном уровне структуры находится собственно MDA, которая «разворачивается» наружу посредством второго уровня, содержащего вышеперечисленные базовые составляющие UML, MOF и CWM, и на третьем, внешнем уровне представлены некоторые из широко известных в настоящее время программных платформ разработки: CORBA, XML, .NET, JAVA. На этом внешнем уровне, по замыслу OMG, могут и должны быть размещены и все возможные будущие технологии разработки.Этим подчеркивается тот факт, что OMG считает архитектуру MDA не просто новой технологией, а скорее «метатехнологией» создания приложений. Последняя отныне будет и единственно актуальной — вне зависимости от развития и появления новых средств разработки, которые MDA уже «заранее интегрировала» в себя.Само понятие «разработчик программного обеспечения» может при внедрении MDA довольно сильно видоизмениться. Со смещением акцента на создание модели разработкой приложений будут заниматься не столько программисты, сколько специалисты, владеющие описываемой предметной областью. Возможно, что также в какой-то степени «пострадает» традиционное деление специалистов на разработчиков баз данных и разработчиков приложений баз данных. Уже сейчас возможно при разработке MDA-приложений практически полностью абстрагироваться от знания конкретной СУБД; более того, во многих случаях нет необходимости и использовать язык SQL, поскольку многие инструменты MDA предоставляют возможность работать на более «высоком» уровне (бизнес-уровне), где становится абсолютно не важным знание конкретной структурной схемы базы данных или состава полей ее таблиц.Однако программисты-разработчики вряд ли останутся без работы, так как, с одной стороны, создание MDA-инструментария само по себе является чрезвычайно интересной, сложной и объемной задачей для них. А с другой стороны, внедрение MDA уже сейчас избавляет и самих программистов от рутинной работы, передавая большую ее часть искусственному программному интеллекту — инструментам реализации MDA [5].5. Жизненный цикл разработки с помощью MDAЖизненный цикл разработки с помощью MDA не сильно отличается от традиционного. Он разделен на такие же этапы.Одно из существенных различий состоит в природе артефактов,которые создаются во время процесса разработки. Здесь артефакты являются формальными моделями, то есть (говоря примитивным языком), моделями,понятными компьютерам. Далее рассмотрим три вида моделей, из которых состоит ядро технологии MDA [6].6. Типы моделейАрхитектура MDA описывает и структурирует поэтапный процесс разработки любых программных систем на основе создания и использования моделей. При этом используется несколько типов моделей, создаваемых и преобразуемых на различных этапах разработки. Процесс разработки поMDA это последовательное (поэтапное) продвижение от одной модели системы к другой. При этом каждая последующая модель преобразуется из предыдущей и дополняется новыми деталями. Модели, общая схема разработки и процесс преобразования моделей - ключевые составные части архитектуры.Основная идеяMDAв том,что преобразованиеиз PIM в PSM,а также же генерациякодаиз PSM,может производитьсяавтоматически.Преобразования проводятся при помощи инструментов преобразования(transformation tools), которые в свою очередь используют правила преобразования. Эти правила будут написаны на языке, который будет описан стандартом QVT (Queries, Views, Transformations). Преобразования могут быть параметризованы, что позволит их подстраивать под нужды конкретных проектов.Рассмотрим типы моделей, используемых в архитектуре MDA [2].CIM Common Information Model (типовая информационная модель, CIM) — открытый стандарт, определяющий представление управляемых элементов IT среды в виде совокупности объектов и их отношений, предназначенный обеспечить унифицированный способ управления такими объектами, вне зависимости от их поставщика или производителя.В упрощенном виде CIM можно представить как способ, позволяющий нескольким участникам обмениваться информацией, необходимой для управления их элементами. Упрощение заключается в том, что CIM не только определяет представление управляемых элементов и управляющей информации, но и предоставляет возможность управлять ими и контролировать их работу. Управляющее программное обеспечение, созданное с использованием CIM, может работать с множеством реализаций этого стандарта без потери данных или сложных перекодировок.CIM разработан и опубликован Distributed Management Task Force.Связанный с ним стандарт Web-Based Enterprise Management (также разработанный DMTF), определяет реализацию CIM, включая протокол обнаружения и доступа.Стандарт CIM включает спецификацию инфраструктуры и схему. Cпецификация инфраструктуры определяет архитектуру и понятия CIM, включая язык определения CIM Schema (и любых её расширений), и способ отображения CIM на другие информационные модели, например SNMP. Архитектура CIM объектно-ориентированная, поскольку основывается на UML: управляемые элементы представляются классами CIM, любые отношения между ними представляются ассоциациями CIM, а наследование позволяет создавать специализированные элементы из более простых базовых.Cхема SIM - концептуальная схема, определяющая набор объектов и отношений между ними, представляющих общую основу управляемых элементов в IT среде. Схема охватывает большую часть современных элементов IT среды, например компьютеры, операционные системы, сети, подпрограммное обеспечение, сервисы и хранилища. Cхема определяет общий базис представления таких элементов. Поскольку большинство управляемых элементов для каждого типа элемента и его производителя имеют своё поведение, схема является расширяемой и даёт возможность производителям представлять специфический функционал сходным образом с базовым функционалом, определенном в схеме.На CIM основаны либо используют большинство остальных стандартов DMTF (так как WBEM или SMASH). Также он является основой стандарта SMI-S, предназначенного для управления хранилищами.Множество производителей предоставляют различные реализации CIM:большинство операционных систем предоставляют реализацию CIM. Например, CIM реализован в семействе Microsoft Windows (WMI) и некоторых дистрибутивах GNU/Linux CIM и WBEM активно применяется в области сетей хранения данных в виде основанного на CIM стандарта SMI-S, определенного ассоциацией SNIA большинство производителей серверов сотрудничают с DMFT в рамках стандарта SMASH, основанного на CIM DMTF разрабатывает стандарт DASH управления настольными компьютерами [7].CIM описывает общие требования к системе, словарь используемых понятий и условия функционирования (окружение). Модель не должна содержать никаких сведений технического характера, описаний структуры и функционала системы. CIM максимально общая и независимая от реализации системы модель. Спецификация MDA подчеркивает, что CIM должна быть построена так, чтобы ее можно было преобразовать в платформенно-независимую модель. Поэтому CIM рекомендуется выполнять с использованием унифицированного языка моделирования UML [2].PIMНа этапе анализа на основании требований вырабатывается платформно независимая модель системы (PIM). Она привязана к постановке задачи и предметной области и не зависит от таких деталей реализации, как,например, язык программирования или тип базы данных (реляционная,объектная, иерархическая и т.д.) [8].Платформенно-независимая модель (Platform Independent Model, PIM)описывает состав, структуру, функционал системы. Модель может содержать сколь угодно подробные сведения, но они не должны касаться вопросов реализации системы на конкретных платформах. Модель PIM создается на основе CIM. Для создания модели используется унифицированный язык моделирования UML [2].PSMДалее, на этапе дизайна будет осуществлен выбор деталей реализации:платформ, языков, распределенной или централизованной архитектуры.На основании эти решений PIM будет преобразована в соответствующие платформно зависимые модели (PSM). Для этого преобразования скорее всего будут использоваться готовые инструменты преобразования и библиотеки правил преобразования. Из одной PIM может быть сгенерировано несколько PSM. Например, одна из PSM может основываться на CWM метамодели для реляционых баз данных и описывать модель данных. В тоже время другая модель может, используя UML/EJB Mapping, представить PSI в терминах Enterprise Java Beans. Для стыковки разных PSM моделей в процессе PIM PSM трансформации могут также быть сгенерированы так называемые «bridges» — связки между разными PSM моделями, сгенерированными из общей PIM модели [8].Платформенно-зависимая модель (Platform Specific Model, PSM) описывает состав, структуру, функционал системы применительно к вопросам ее реализации на конкретной платформе. В зависимости от назначения модель может быть более или менее детализированной. Модель создается на основе двух моделей. Модель PIM служит основой модели PSM.Модель платформы используется для доработки PSM в соответствии с требованиями платформы [2].Модель платформыНу и наконец, из PSM при помощи других инструментов преобразований и других наборов правил будет сгенерирован код. Например,если Oracle был выбран как реляционная база данных, то будет использован набор правил, который из соотвествующей PSM построит схему базы данных. Другой набор правил может сгенеририровать Java код для EJB контейнера. Опять же, при использовании нескольких PSM моделей будут сгенерированы связки на уровне кода между ними, которые, например, позволят сгенерированным Java Beans работать с сгенерированной схемой базы данных Oracle. Хотя преобразования будут делаться автоматически, выбор их параметров останется за дизайнером. Например, он может указать использовать ли определенные возможности платформы или нет, подсказать системе примерные объемы ожидаемых данных, и т.п [2].Модель платформы описывает технические характеристики, интерфейсы, функции платформы. Зачастую модель платформы представлена в виде технических описаний и руководств. Модель платформы используется при преобразовании модели PIM в модель PSM. Для целей MDA описание модели платформы должно быть представлено на унифицированном языке моделирования UML [8].7. Уровни моделиУровень бизнес-логикиУровень бизнес-логики содержит описание основного функционала приложения, обеспечивающего исполнение его назначения. Как правило,уровень бизнес-логики хуже всего поддается автоматизации. Он составляет львиную долю кода приложения, который приходится писать вручную [2].Уровень данныхУровень данных описывает структуру данных приложения, используемые источники, форматы данных, технологии и механизмы доступа к данным.Для приложений .NET чаще всего используются возможности ADO.NET [2].Уровень пользовательского интерфейсаУровень пользовательского интерфейса описывает возможности приложения по взаимодействию с пользователями, а также состав форм приложения, функционал элементов управления (например, контроль ввода данных). Легкость автоматизации этого уровня зависит от того, насколько унифицированы пользовательские операции. Если удается создать типовые шаблоны элементов управления для основных операций, появляется возможность автоматической генерации форм и их содержимого при создании приложения из модели [2].
Заключение
Архитектура MDA возникла не на пустом месте. Само ее появление и возможность реализации обусловило наличие ряда стандартов и технологий,на практике доказавших свою полезность. Концептуальной основой появления MDA стали спецификации OMA, ORB, CORBA. Перевести замысел в практическую плоскость позволили технологии объектно-ориентированного программирования (ООП), стандарт CWM, языки UML, XML, MOF. Работами по созданию новой архитектуры программирования занялся консорциум OMG (Object Management Group).По мнению создателей, архитектура MDA является новым витком эволюции технологий программирования, так как описывает процесс разработки в целом. Новизна MDA заключается в том, что описание процесса разработки в ней выполнено с использованием современных средств представления и позволяет автоматизировать создание приложений. И весьма вероятно, что через некоторое время архитектура MDA станет общим промышленным стандартом в разработке программного обеспечения [2].На данном этапе эта методология находится больше в области академических исследований, чем практического применения. Хотя множество деталей еще требуют уточнений и разработки и потребуются еще годы работы перед тем, как мы увидим практические применения MDA,общее видение и направление развития уже достаточно хорошо определены.Тем не менее, многие считают идею генерации работающих систем автоматически из моделей утопической [5].
Список использованной литературы
1. Абрютина, М.С. Анализ финансово-экономической деятельности предприятия / М.С. Абрютина, А.В. Грачев. - М.: Дело и сервис; Издание 3-е, перераб. и доп., 2001. - 272 c.2. Александр, Затеса und Владимир Дик Выбор ИТ-сервисов на предприятии / Александр Затеса und Владимир Дик. - М.: LAP Lambert Academic Publishing, 2012. - 160 c.3. Багмут, С.И. Интерьер предприятий общественного питания / С.И. Багмут. - М.: Экономика, 1976. - 382 c.4. Балашов, В.Г. Антикризисное управление предприятиями и банками: моногр. / В.Г. Балашов. - М.: Дело, 2001. - 840 c.5. Баринов, Андрей Безопасность сетевой инфраструктуры предприятия / Андрей Баринов. - М.: LAP Lambert Academic Publishing, 2012. - 915 c.6. Бердникова, Т.Б. Анализ и диагностика финансово-хозяйственной деятельности предприятия / Т.Б. Бердникова. - М.: ИНФРА-М, 2007. - 224 c.7. Богачева, Т.Г. 1С: Предприятие 8.0. Управление торговлей в вопросах и ответах: Практическое пособие / Т.Г. Богачева. - М.: 1С Паблишинг, 2004. - 252 c.8. Бургонова, Г.Н. Бухгалтерский учет на предприятиях различных организационно-правовых форм / Г.Н. Бургонова. - М.: СПб:; Издание 2-е, перераб. и доп., 1993. - 102 c.9. Вилисов, В. Я. Инфраструктура инноваций и малые предприятия. Состояние, оценки, моделирование / В.Я. Вилисов, А.В. Вилисова. - М.: РИОР, Инфра-М, 2015. - 228 c.10. Вилисов, В.Я. Инфраструктура инноваций и малые предприятия: состояние, оценки, моделирование: Монография / В.Я. Вилисов. - М.: Инфра-М, РИОР, 2015. - 162 c.