Использование разработки, управляемой моделями (MDD), заставляет планировщика проекта заново продумывать жизненный цикл решения. В этой главе мы обсудим то повышение производительности, которое MDD может внести в различные функциональные стадии жизненного цикла, такие, как тестирование, внедрение и поддержка.

Мы уже обсуждали жизненный цикл решения в гл. 4, «Планирование проекта, выполняемого с использованием разработки, управляемой моделями», в контексте планирования MDD-проекта. В этой главе мы сконцентрируемся на тех возможностях совершенствования жизненного цикла, которые дает MDD. Мы также расскажем об аспектах жизненного цикла MDD-решения, которые не раскрывались в других главах.

MDD может изменить жизненный цикл решения следующими способами:

• Создать новые артефакты, например модели, на более ранних стадиях жизненного цикла. С MDD-артефактами нужно работать как с первичными артефактами, такими, как код, а не как с документацией проекта.
• Стимулировать изменения в способах решения задач командой разработки. MDD изменяет и то, что разрабатывается, и то, как это делается. Данный подход также влияет на поздние стадии жизненного цикла, потенциально изменяя конфигурацию тестовой и рабочей среды.
• Создать возможности для перехода от ручного выполнения таких задач, как написание скриптов для конфигурирования, размещения и мониторинга, к автоматическому выполнению. Можно написать трансформации, которые будут создавать соответствующие скрипты автоматически, используя информацию, содержащуюся в моделях.

5.1 Введение в жизненный цикл решения

Жизненным циклом программного обеспечения называются фазы, через которые оно проходит от первоначальной концепции до того момента, когда прекращается его поддержка. Жизненным циклом решения называются те стадии и среды, через которые проходит программное решение от проверки концепции до состояния активной рабочей системы и далее через поддержку до момента, пока система не будет выведена из эксплуатации. Все программное обеспечение, включая программные решения, имеет жизненный цикл программного обеспечения, куда входит разработка и обслуживание программных компонентов. Программные решения, помимо этого, проходят через стадии от разработки решения из компонентов до ввода в эксплуатацию.

Стадии жизненного цикла решения в различных проектах могут быть разными, но, как правило, включают следующие элементы (среды):

• Design (Проектирование). Среда разработки и модульного тестирования, которая используется для создания прототипов и испытания технологий. В эту стадию также входит сбор и уточнение требований, а также анализ.
• Capability (Возможности). Тестовая среда, используемая для многопоточного тестирования работы компонентов, реализующих функции приложения/решения.
• Operation (Функционирование). Многоплатформенная интеграционная среда, отражающая требования рабочей среды. Данная среда применяется для тестирования качества обслуживания и для доказательства того, что решение удовлетворяет требованиям, предъявляемым соглашениями об уровне обслуживания.
• Production (Рабочая среда). Это реальная среда. Перед вводом в эксплуатацию рабочая среда и решение должны пройти сертификацию на соответствие требованиям качества услуг, преодоления сбоев и высокой степени доступности.
• Life cycle (Жизненный цикл). Эта стадия подразумевает управление рабочей средой и артефактами решения применительно к миграции, управлению версиями, замене аппаратного обеспечения, промежуточного программного обеспечения и компонентов приложения.

Когда мы говорим в этой главе о жизненном цикле, мы имеем в виду полный жизненный цикл решения для MDD-проекта, включая разработку программных компонентов, их конфигурирование и развертывание в решение.

Каким же образом применение разработки, управляемой моделями, изменяет те действия, которые должны выполняться и контролироваться в ходе жизненного цикла? В гл. 4, «Планирование проекта, выполняемого с использованием разработки, управляемой моделями», рассмотрение операций жизненного цикла перекрывается с обсуждением планирования MDD-проекта. Различие состоит в том, что в гл. 4 мы обсуждали, как планировщик проекта должен продумывать изменение цикла разработки для учета изменений, вносимых MDD. В этой главе мы сконцентрируемся на следующем:

• на изменениях жизненного цикла решения, которые являются обязательными для извлечения пользы из эффективного применения MDD;
• имеющихся инструментах, поддерживающих разные стадии жизненного цикла MDD-проекта;
• решениях некоторых проблем, связанных с продумыванием и реализацией операций, входящих в жизненный цикл MDD-проекта.

В начало

5.2 Жизненный цикл разработки, управляемой моделями

Поскольку модели при разработке, управляемой моделями, являются первичными артефактами, становится очень важно, чтобы элементы жизненного цикла продумыва-лись в проекте как можно раньше и чтобы мы изучили, какие аспекты можно зафиксировать в моделях. Чтобы надежды, возложенные на MDD, оправдались, мы должны применять тот же подход к программированию и автоматизации опыта профессионалов-разработчиков так, чтобы он единообразно и последовательно использовался в различных аспектах жизненного цикла. Это означает необходимость фиксации опыта по тестированию, внедрению, формированию пакетов, безопасности и т. д.

MDD добавляет к жизненному циклу еще одно измерение. Как правило, мы разрабатываем решение, тестируем и размещаем его в рабочей среде. В MDD-проекте разработка делится на следующие две фазы

• создание каркаса для генерации служб решения;
• генерацию служб решения.

5.2.1 Создание каркаса для генерации служб решения

Каркас покрывает этапы создания, тестирования и размещения моделей, шаблонов и трансформаций для генерации служб решения. Обеспечьте должным образом тестирование каркаса, чтобы генерируемые службы были безошибочными и единообразными. Часто используется практика, когда специалисты по платформе вручную или при помощи обычных инструментов данной платформы создают пример решения. Таким образом, в каждой итерации разработки каркаса сгенерированное тестовое решение можно сравнить с тем, которое было создано специалистами по платформе.

Трансформации должны быть развернуты до начала генерации и размещения решения. Это обеспечивает целостность каркаса и значительно уменьшает число ситуаций, когда трансформации нужно изменить и скорректировать в ходе генерации решения.

5.2.2 Генерация, настройка и тестирование служб решения

Сгенерированные службы выполняются в среде возможностей. Артефакты тестирования и размещения предназначены для этой среды и в некоторых случаях не автоматизируются. Размещение происходит в интерактивном режиме, с использованием графического пользовательского интерфейса. Это позволяет зафиксировать шаги и информацию, необходимые для размещения приложения, что, в свою очередь, поможет создать скрипты размещения для более сложных сред.

Сгенерированные службы сравниваются с образцами служб до того, как внимание в проекте перейдет на следующую фазу, в которой сгенерированное реальное решение и связанные с ним артефакты (тестирования, размещения и т. п.) будут подготавливаться для среды размещения.

Иными словами, создание каркаса является синонимом создания фабрики (factory) MDD-решений, а вторая фаза - это использование фабрики для создания наших продуктов.

Как и в любом проекте по разработке программного обеспечения, в ходе жизненного цикла необходимо принимать решения по управлению и по поддержке решения, активов и инструментов. В жизненном цикле MDD-проектов есть определенные вопросы, которые нужно учитывать в проекте гораздо раньше и которые оказывают значительное влияние на успешность проекта. Например, как управлять версиями и выявлением проблем в MDD-проекте, где главными артефактами являются модели? Далее мы обсудим эти вопросы.

В начало

5.3 Разработка, управляемая моделями, и управление версиями

Управление версиями оказывает влияние на сгенерированные решения, а также на шаблоны, профили, трансформации и другие артефакты моделирования, на основе которых генерируются эти решения.

Так, предположим, что в нашем примере с интеграцией служб рабочая среда представляет собой группу серверов, разделенную на кластеры, где промежуточное программное обеспечение имеет разные версии с разными возможностями. Поддержка разных версий J2EE или продуктов промежуточного слоя может быть как раз таким случаем. В таких ситуациях мы управляем версиями трансформаций, привязанных к каждой среде, а также изменениями версий трансформаций, которые специфичны для генерируемых приложений и служб в каждой среде. В каркасе мы должны определить, какую версию трансформации мы должны выполнять.

Если взять тот же сценарий и проанализировать генерируемые службы, то какие правила контроля версий следует применять к интеграционным службам? Давайте предположим, что вносится небольшое изменение, при котором в интеграционную службу updateCutomer вносится ранее не поддерживавшееся дополнительное поле secondHomeAddress без изменений интерфейса ранее разработанных приложений. По-прежнему нужно, чтобы интеграционная служба поддерживала все существующие фасады клиентов и интеграционных служб и чтобы для всех связанных со службой схем xml-трансформация и проверки сообщений не приводили к ошибке или сбою. В этом случае в решение должна быть встроена поддержка определения и выбора нужных версий для служб.

5.3.1 Политики управления версиями и заменами

При переходе в рабочую среду очень важно иметь план выпуска, в котором указаны политики контроля версий и замен. В политиках указываются правила и инструкции о том, когда нужно создавать версию, развертывать новую версию или заменить всю службу. Так, в нашем примере с новым полем secondHomeAddress мы будем определять используемый подход согласно политике, в которую могут входить следующие варианты:

• Если в существующую структуру данных добавляются новые поля или структуры, то увеличивается на единицу младшая часть в номере версии структуры (вспомогательная версия) и всех новых служб, использующих эту структуру. Следовательно, номер версии из M1m0 превращается в M1m1. Существующие реализации измененной службой поддерживаются.
• Если новое поле или структура является обязательной, то увеличивается старшая часть номера версии (основная версия) и поддерживаются только новые реализации. Существующие приложения продолжают использовать предыдущую версию до тех пор, пока в них не будет введена поддержка новой.
• Версии с измененной младшей частью (дополнительные версии) заменяют собой предыдущие версии, поскольку поддержка старых реализаций сохраняется.
• Как правило, существует стратегия выпуска, которая требует внесения улучшений в течение определенного времени, чтобы от старых версий можно было спокойно отказаться и больше их не поддерживать. Измененные основные версии должны существовать одновременно со старыми (основными) версиями в течение согласованного периода времени, которое требуется для осуществления перехода на новую версию.

Политики управления версиями и заменами влияют на процесс размещения. Должен существовать механизм замены или размещения новых версий, которые должны существовать совместно со старыми, и также нужно обеспечить доступ к ним со стороны служб-клиентов.

Мы также должны определить уровень управления версиями (управление по файлам, по классам, по службам, по элементам размещения и т. п.), который будет использоваться. В нашем примере мы контролируем версии трансформаций, шаблонов, профилей и всех повторно используемых артефактов. Также важно понимать все комбинированные уровни контроля версий, например, комбинацию конкретной версии трансформации с конкретной версией профиля.

В начало

5.4 Разработка, управляемая моделями, и управление артефактами

Модели, трансформации и код - это часть артефактов, которые мы создаем и используем в MDD-проекте. Эти активы могут быть простыми, например текстовые файлы с параметрами конфигурации и документацией, или сложными, например архивы проектов, содержащие исполняемый код и дескрипторы размещения.

Согласно Rational Unified Process (RUP), артефакт - это «рабочий продукт процесса: роли используют артефакты для выполнения операций и создают артефакты в ходе выполнения операций». Все рассматриваемые нами артефакты - это примеры артефактов в том смысле, который вкладывает в это понятие RUP. В данной главе мы ограничимся программными активами, которые применяются в решении в качестве части модели или в качестве исполняемых служб.

5.4.1 Повторное использование модельных артефактов

Успешность MDD-проекта зависит от успешности повторного использования модельных артефактов. В связи с этим нужно проанализировать значение и вклад артефакта и определить, нужно ли его генерировать.

Например, шаблоны и трансформации весьма полезны при повторном использовании, тогда как конфигурационный скрипт можно применить только один раз, но влияние на проект он оказывает значительное. По существу, хотя повторное использование - это главный фактор при принятии решения о том, стоит ли идти на расходы, связанные с генерацией артефакта, имеются и другие соображения, зависящие от контекста и значимости артефакта. Повторное использование в MDD включает в себя повторное применение шаблонов, моделей, трансформаций и, в меньшей степени, кода. Управление этими артефактами, связанными с ними описаниями (которые могут быть зафиксированы в эталонах) и обслуживание репозиториев становится все более важно.

Управление артефактами включает в себя следующие вопросы (хотя не ограничивается ими):

• Успешный выбор и получение артефакта для повторного использования.
• Обеспечение соответствия полученного артефакта и версии рабочей системы.
• Проверка целостности артефакта и проверка того, что данная версия артефакта является последней и подходящей.
• Проверка сертификации артефакта, а также того, сертифицирован ли он для работы в данной среде. Может быть, он предназначен только для тестовой среды или имеет ограниченную лицензию только для работы в определенной среде.

При определении методов и инструментов для использования в управлении артефактами необходимо принять во внимание ряд факторов, включая службы управления целостностью и поддержку размещения.

5.4.2 Службы управления целостностью

Существует необходимость проверять надежность модели и артефактов решения, чтобы обеспечить целостность системы. Мы, по сути, рекомендуем внедрить механизм сертификации службы на соответствие стандартам (установленным руководством). Такая практика сертификации службы должна применяться ко всем артефактам с учетом определенных уровней. Например, артефакт может быть сертифицирован как готовый к размещению в тестовой среде, в рабочей среде или может быть отвергнут и не использоваться в новых приложениях.

Вы должны проанализировать практику сертификации заранее, поскольку она может повлиять на выбор используемого репозитория (например, репозиторий может обеспечивать возможности, поддерживающие часть требований).

Раннее продумывание управления артефактами помогает определить, какой объем информации нужно (если нужно) добавить в сгенерированные артефакты, чтобы они прошли сертификацию, и определить способ запроса/извлечения артефакта с учетом конкретного контекста. Например, в нашем сервисно-ориентированном интеграционном (SOI) сценарии хранимые артефакты снабжаются для повторного использования информацией, необходимой для поиска по следующим элементам:

• тип службы (IB, PF): (см. подразд. 2.2.1, «Структура ESB»);
• стадия (бета, готов к размещению, отвергнут);
• протокол (SOAP/HTTP, SOAP/JMS, JMS).

Часть этой информации фиксируется в шаблонах RAS, которые описывают артефакты, а другая часть извлекается из самого артефакта.

5.4.3 Поддержка размещения

Мы заинтересованы в простоте доступа к активам и их размещения. Структура репозитория должна учитывать политики управления версиями и политики сертификации и должна обеспечивать эффективное обслуживание репозитория служб и активов.

Определение типов активов также важно для обеспечения поддержки размещения (вероятно, проще размещать заранее упакованный EAR-файл, чем EJB), набора Java-классов и некоторых схем данных. В большинстве случаев типы хранимых активов определяются по типу решения и политике размещения. Сравните следующие два случая:

• Сценарий быстрого размещения, когда размещение автоматизируется и создаваемые и сертифицируемые новые службы размещаются в «горячем режиме».
  В этой ситуации создание пакетов артефактов является обычной частью процесса их генерации, что способствует максимальной эффективности быстрого размещения.
• Сценарий, при котором существуют упаковывающие скрипты и практические методы выпуска в рабочую систему.
  В этой ситуации репозиторий может содержать более простой тип активов. К артефактам применяется упаковывающее приложение, после чего результаты работы этого приложения размещаются.

Применение технологий и методов управления артефактами и конфигурациями в значительной степени зависит от типа и размера проекта, а также от типа и размера артефактов. Политика сертификации, политика размещения и т. п. не только влияют на технологию и продукт, используемый при управлении артефактами, но также определяют принятие решения по разделению возможностей, которые предлагает инструмент, и возможностей, встраиваемых в артефакт. Переход артефактов из стадии в стадию в значительной степени зависит от этих политик, и его нужно анализировать в ходе обсуждения жизненного цикла на ранних стадиях проекта.

В начало

5.5 Разработка, управляемая моделями, и определение проблем

Выявление проблем в MDD-проекте охватывает как каркас, так и сгенерированное решение. Наличие механизмов отладки на различных стадиях, от проектирования до рабочей системы, крайне важно для успешности проекта. Поскольку главными артефактами при MDD являются модели, обеспечьте разработку механизмов отладки моделей параллельно с самой разработкой моделей. В некоторых случаях может быть необходимо отлаживать сгенерированный код и другие артефакты решения.

Ниже приводятся две причины того, почему не следует отлаживать сгенерированный код.

• Чрезвычайно сложно вернуться назад, от сгенерированного кода к соответствующей проблеме в модели.
• Крайне важно, чтобы все изменения вносились в модели или в трансформации, но не в сгенерированные артефакты.

Все это обеспечивает согласованность моделей и решения и защищает целостность фабрики (factory) и сгенерированного решения. По существу, отладка сдвигается вверх и точкой определения проблемы становятся модели и трансформации.

Инструментарий против инструментирования

На практике выявление проблемы осуществляется с использованием комбинации инструментария и инструментирования. Инструментарием здесь называются возможности отладки, предоставляемые инструментами моделирования и разработки, которые позволяют выявлять проблемы в артефактах начиная от моделей и кончая сгенерированными артефактами. Под инструментированием имеются в виду механизмы, встраиваемые в модели и трансформации для выявления проблем. Средства инструментирования варьируют от встраиваемых трассировочных сообщений до встраивания системы событий и доступа к инфраструктуре событий при поиске проблем и управлении решением.

Помните, что после того, как программный продукт или решение выпущены и функционируют в рабочем режиме, модели по-прежнему следует рассматривать как исходные и главные артефакты. Любые найденные дефекты нужно корректировать в моделях, а не в сгенерированном коде, поскольку такая правка создает несоответствия и модель становится бесполезной для будущих версий, что сводит на нет преимущества MDD.

В начало

5.6 Добыча информации

Успех проекта зависит от качества используемой и создаваемой информации. Модели и трансформации в MDD-проекте, применяющем UML, должны заполняться точной и достоверной информацией. На практике источники информации могут быть многочисленными и иметь разный формат. В RSA предлагаются настраиваемые возможности для ввода информации из разных источников и разных форматов, а также для генерации документов в различных форматах.

Так, в нашем примере с SOI при использовании RSA все модели, пакеты и элементы моделей описываются в документации. Мы применяем заранее определенную структуру, позволяющую создавать отчеты и пользовательскую документацию в форме HTML для Web и документов Microsoft® Word, для чего применяется SoDA.

Для тех ролей, которые не могут работать напрямую с моделями, мы предлагаем Web-приложение, которое собирает информацию и заполняет модели. В зависимости от уровня абстракции входные данные для модели могут поступать из приложения в форме данных, сохраненных с заданной структурой в файловой системе. На основе этой информации в моделях может генерироваться другая информация для других приложений в форме конфигурационных файлов или файлов свойств.

Хотя информация может храниться в разных местах, вы должны понимать свой способ хранения и иметь политику управления этими данными. Такое понимание позволяет уменьшить необходимость в управлении одинаковыми данными, находящимися в разных местах, и обеспечивает целостность данных. Старайтесь сделать модели своим основным источником информации и хранилищем, чтобы другие инструменты обеспечивали просто представление информации в настраиваемом формате.

В начало

5.7 Тестирование

Тестирование, основанное на моделях, и тестирование, управляемое моделями, применяются во множестве проектов:

• Тестирование, основанное на моделях, - это подход к тестированию, при котором используется модель системы, предсказывающая ее поведение, и эти предсказания применяются для автоматизации тестов.
• Тестирование, управляемое моделями, концентрируется на создании набора инструментов и среды выполнения тестов для автоматизации тестирования, а разработчик модели может обратить основное свое внимание на продумывание хорошего набора тестов, специфичных для приложения.

Здесь мы не будем рассматривать тестирование, основанное на моделях, и автоматическую генерацию тестов. Однако тестирование, управляемое моделями, мы обсудим.

В тестировании, управляемом моделями, можно выделить две фазы

• Тестирование модельного каркаса. Проверка модели, чтобы удостовериться, что она создает правильные артефакты в нужном формате.
• Тестирование сгенерированных артефактов решения. Проверка артефактов решения на соответствие требованиям, предъявляемым к решению, и бизнес логике служб.

5.7.1 Моделирование для тестирования

Для моделирования тестирования мы используем тот же подход, связанный с применением трансформаций к моделям и генерацией артефактов, но в данном случае акцент делается на генерации тестовых артефактов.

Полезный подход к моделированию для тестирования - это повторное использование моделей, описывающих решение, при котором модели снабжаются тестовыми элементами. Ввод в модели тестовых элементов позволяет нам понять границы, тестируемую систему и тестовые данные. Генерируемые артефакты тестирования могут быть просто объектами и методами-заглушками для тестовых служб, имитирующими работающую систему, а могут быть тестовыми скриптами, запускающими средства тестирования. Другой подход - это использование модели для создания образца кода, а затем этот код, с соответствующими заглушками, применяется для генерации тестов.

Наша цель здесь - проиллюстрировать методы моделирования для тестирования и обсудить практические способы тестирования, применяемые в MDD-проекте.

5.7.2 Применение тестовых шаблонов

Наш язык шаблонов может также содержать шаблоны тестов. В нашем примере с SOI мы зафиксировали шаблон приложения для службы updateCustomerDetails в формате, показанном на рис. 5-1.

В шаблонах тестирования фиксируется опыт, необходимый для тестирования решения в разных средах. Например, при сквозном тестировании службы updateCustomerDetails в среде возможностей нужно установить соединение между фасадом поставщика и внешним поставщиком. Поскольку внешний поставщик может представлять собой активную систему, на которой мы не можем запускать тесты, нужно создать тестового поставщика. Тестовый поставщик - это имитация, которая предоставляет все общедоступные интерфейсы внешнего поставщика и поддерживает все необходимые данные и типы сообщений.

Мы создаем в RSA тестовый шаблон внешних сущностей, который сгенерирует тестового поставщика или инициатора запроса на основе определений внешнего поставщика или клиента. Такой тестовый поставщик или инициатор запроса связывается со службой-фасадом (как показано на рис. 5-2) и обеспечивает необходимые вызовы операций.

Использование шаблонов в данном примере позволило нам зафиксировать и применить знание предметной области, в частности сред и методов тестирования, используемых в проекте. При применении шаблонов модели могут дополняться тестовыми инициаторами запросов, тестовыми службами и классами-заглушками, чтобы модели соответствовали необходимым определениям. В любом случае сгенерированные артефакты в форме методов, классов, проектов и т. д. можно поместить в отдельный пакет или встроить в реальный артефакт решения, в зависимости от сложности, а также от политик упаковки и размещения.

5.7.3 Моделирование с использованием UML-профиля для тестирования

UML-профиль для тестирования является формальным расширением UML, в котором определены тесты системы, зафиксированные в UML-моделях. В спецификации Object Modeling Group (OMG) UML Testing Profile UML-профиль для тестирования описывается как язык для проектирования, визуализации, спецификации, анализа, конструирования и документирования артефактов тестирования. Этот язык вы можете применять при тестировании систем в широком диапазоне предметных областей, какие бы объектные или компонентные технологии не использовались при создании приложений. UML-профиль для тестирования позволяет просто описать тестовые системы, или же его можно использовать вместе с UML для одновременной работы с системными и тестовыми артефактами.

UML-профиль для тестирования имеет следующие характеристики:

• основан на метамодели UML и дополняет UML концепциями, специфичными для тестирования;
• позволяет определять тесты для статических и динамических аспектов UML-моде-лей;
• интегрируется с UML и имеющимися технологиями и стандартами тестирования (например, UNIT и TTCN3).

UML-профиль для тестирования организован в виде четырех логических групп концепций тестирования (описание взято из спецификации OMG-профиля для тестирования UML):

• концепции определения архитектуры, связанные со структурой и конфигурацией тестов;
• концепции определения данных для тестовых данных, которые используются в процедурах тестирования;
• концепции определения поведения, связанные с динамическими аспектами процедур тестирования;
• концепции определения времени, для количественного определения времени для процедур тестирования.

UML-профиль для тестирования предназначен для тестирования «черного ящика» на соответствие стандартам, и тестируемая система не указывается в качестве составной части модели тестирования. Она доступна только через общедоступные интерфейсы и операции. Информация о структуре тестируемой системы остается недоступной, поскольку такая система является «черным ящиком». Модель тестируемой системы импортируется в пакет архитектуры теста для того, чтобы получить необходимые права доступа.

В нашем примере мы рассматриваем шину ESB и содержащиеся в ней элементы как тестируемую систему и, используя UML-профиль для тестирования, определяем тесты, тестовые элементы, тестовое поведение, тестовые данные, вердикты и т. п., которые позволяют сгенерировать тестовые артефакты и тестовые примеры в JUNIT. Создание трансформации, которая работает с тестовым профилем и моделями, к которым был применен этот профиль, здесь не рассматривается. Мы даем это вам в качестве самостоятельного упражнения.

За дополнительной информацией о тестировании, управляемом моделями, обращайтесь к следующим страницам:

• http://www.agedis.de/
• http://www.haifa.il.ibm.com/projects/verification/mdt/tools.html
• http://heim.ifi.uio.no/~janoa/wmdd2004/presentations/alan.pdf

В начало

5.8 Заключение

В этой главе мы познакомили вас с основными идеями, лежащими в основе управления жизненным циклом. Мы также дали общий обзор некоторых операций жизненного цикла, которые разработка, управляемая моделями, может улучшить, например тестирование и размещение.

В гл. 6, «Разработка, управляемая моделями, и ее место в ИТ», рассматривается несколько подходов, которые дополняют методологию MDD, которую мы описали. Также обсуждается, как MDD соотносится с концепцией архитектуры, управляемой моделями, как она определяется OMG.

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• 5.1 Введение в жизненный цикл решения
• 5.2 Жизненный цикл разработки, управляемой моделями
• 5.3 Разработка, управляемая моделями, и управление версиями
• 5.4 Разработка, управляемая моделями, и управление артефактами
• 5.5 Разработка, управляемая моделями, и определение проблем
• 5.6 Добыча информации
• 5.7 Тестирование
• 5.8 Заключение
• Об авторе
• Комментарии