MDD

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

Уровень сложности: простой

IBM developerWorks, IBM developerWorks, IBM

05.2007

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

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

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

4.1 Ценность и стоимость разработки, управляемой моделями

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

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

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

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

В следующих разделах мы изучим необходимые дополнительные этапы, связанные с планированием и управлением MDD-проектом.

В начало

4.2 Понятие о задачах, входящих в MDD-проект

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

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

4.2.1 Описание задач

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

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

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

1. Идентификация общих шаблонов и стандартов. Архитектор решения выявляет в бизнес-приложении повторяющиеся шаблоны (patterns). Эти шаблоны встречаются часто по причине согласованного использования архитектурного стиля или из-за требований, которые предъявляют платформы. Общие шаблоны можно описать, применяя стандартные способы, используемые в процессе разработки, принятом в организации.
2. Идентификация имеющихся MDD-активов, которые можно использовать. При выполнении этой задачи архитектор решения сравнивает выявленные общие шаблоны с существующими активами MDD, чтобы можно было после небольшой доводки использовать то, что уже есть. Такие активы могут остаться от предыдущих MDD-проектов или могут поставляться со стандартными инструментами и пакетами.
3. Определение модели дизайна. При выполнении этой задачи архитектор решения выбирает тип UML-модели, который могли бы использовать разработчики приложения при определении деталей создаваемых компонентов. Архитектор решения также создает исходный список стереотипов для UML-профиля проекта. Для выполнения этой задачи архитектор решения должен понимать разные типы UML-диаграмм (диаграммы классов, диаграммы кооперации, диаграммы деятельности) и то, когда используется каждая из них.
4. Идентификация модели компонентов, независимой от среды времени выполнения. При выполнении этой задачи создается UML-модель, в которой независимо от среды времени выполнения указываются компоненты бизнес-приложения. Эту задачу может выполнить архитектор решения или опытный разработчик приложения, который хорошо разбирается в средах времени выполнения.
5. Создание образцов артефактов. В ходе выполнения этой задачи разработчик приложения вручную пишет артефакты для бизнес-приложения для типичного сценария. Эти образцы артефактов играют роль чертежей для шаблонов MDD и трансформаций. Поэтому эту задачу должен выполнять ваш лучший программист.
6. Определение цепочки инструментов. В ходе этой задачи определяются инструменты MDD, которые нужно разработать для проекта. Выполняется эта задача тем, кто имеет опыт разработки MDD-инструментария. После завершения этой задачи вы сможете составить детальный план работ по созданию набора инструментов. В разд. 4.3 приводятся дополнительные пояснения причин важности цепочки инструментов.

В следующих задачах создается инструментарий для MDD:

1. Получение шаблонов из образцов артефактов. В ходе выполнения этой задачи разработчик инструментария MDD просматривает образцы артефактов и использует их как основу для создания шаблона для каждого артефакта, который нужно сгенерировать. Шаблон (template) содержит код, который является общим для каждого экземпляра сгенерированного артефакта. Поэтому разработчику инструментария MDD необходимы навыки работы с языком/форматом данного артефакта. В нем также содержатся маркеры, которые используются в трансформациях для вставки конкретных разделов артефакта в зависимости от содержимого модели.
2. Проектирование, программирование и тестирование трансформаций и шаблонов. Для выполнения этой задачи необходимы навыки программирования на Java. Для каждой трансформации или шаблона разработчик MDD-инструментария должен написать Java-код, который читает модель UML 2, и либо обновляет модель, либо заполняет пробелы в шаблоне, генерируя новый артефакт.
3. Формирование пакетов MDD-инструментов. Инструментарий MDD должен быть упакован в такую форму, чтобы его можно было установить в рабочей среде каждого из разработчиков приложения. Существует несколько вариантов: просто поместить все файлы в zip-архив и написать инструкции по распаковке; использовать стандартную систему управления плагинами Eclipse; использовать хранилище RAS или разместить их на Web-сайте, с которого их можно скачивать. Выбор варианта зависит от количества людей, которым нужно установить инструментарий MDD. Разумным подходом будет сосредоточиться на поддержке исходной группы разработчиков приложения. Если же активы начинает применять более широкая группа, можно изменить механизм формирования пакетов.
4. Создание документации и средств обучения разработчиков приложения. Эту задачу может выполнить архитектор решения или технический писатель. Результат - это описание того, как разработчик приложения должен создавать модель, а потом выбирать нужную трансформацию для генерации нужных артефактов.
5. Проверка цепочки инструментов на ключевых сценариях. Эта последняя задача в разработке инструментария MDD выполняет функцию тестирования. С помощью инструментария MDD создаются модели и генерируются все артефакты для каждой платформы для нескольких ключевых сценариев.

Теперь инструментарий MDD готов к тому, чтобы его использовали разработчики приложения. Здесь можно выделить два этапа:

1. Обучение разработчиков использованию MDD-инструментов. Прежде чем начинать использовать инструменты MDD, обучите разработчиков приложения работе с новым процессом разработки. Они должны понимать, как и когда используются инструменты MDD, а также как они взаимодействуют с традиционными инструментами, такими, как средства управления конфигурациями.
2. Разработка бизнес-приложения. На этом этапе разработчики приложения применяют MDD-инструменты для создания бизнес-приложения.

4.2.2 Цепочка инструментов для разработки, управляемой моделями

Процесс, показанный на рис. 4-3, демонстрирует, как разработчик может применять MDD-инструменты для создания части бизнес-приложения. В данном примере разработчик изучает бизнес-проблему и выбирает шаблон дизайна. Это приводит к частичному заполнению модели дизайна, а разработчик вводит детали, касающиеся разрабатываемой бизнес-функции. Далее процесс выполняется автоматически. Разработчик выбирает настройки для генерации артефактов. Формируется пакет артефактов, который помещается в область сборки. Затем разработчик может выбрать другие варианты настройки для генерации дополнительных артефактов для конкретной рабочей платформы.

В начало

4.3 Планирование MDD-проекта

Когда вы понимаете порядок выполнения задач в MDD-проекте, процесс планирования становится сходным с планированием любого проекта по разработке программного обеспечения. Определите задачи, выясните их объем и выделите на них ресурсы. В следующих подразделах приводятся некоторые дополнительные советы, касающиеся планирования.

4.3.1 Использование итеративного подхода к разработке, управляемой моделями

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

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

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

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

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

Навыки архитектора решения

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

• базовые типы диаграмм:
  • диаграммы классов,
  • диаграммы активности,
  • диаграммы прецедентов,
  • диаграммы кооперации,
  • диаграммы компонентов -
  • и то, когда их следует применять;
• как расширять элементы UML 2, используя стереотипы, определенные в UML-про-филе.

По UML 2 существует множество руководств, в которых описываются диаграммы и расширение UML 2. Кроме того, существуют специальные курсы по UML 2. Также об UML 2 могут рассказать на курсах по объектно-ориентированному дизайну.

Навыки разработчика MDD-инструментов

Написание MDD-инструментов - это, по сути, Java-программирование. Разработчик MDD-инструментов создает:

• Реализации шаблонов RSA. Это плагины (plug-in) RSA, которые обеспечивают соответствие моделей, имеющихся у разработчиков приложения, архитектурному стилю, установленному архитектором решения. Это может быть заранее заполненная UML-модель или запуск дополнительных проверок после завершения разработчиком своей модели.
• Трансформации RSA. Это плагины RSA, которые обычно читают модель UML 2 и генерируют по ней новые артефакты.
• Профили и ограничения RSA. Здесь определяются новые стереотипы и правила, контролирующие их использование.
• Правила (ограничения) проверки моделей. Эти ограничения определяют допустимые связи между элементами UML-модели.
• Расширения RSA. Это каркас для добавления новой функциональности в RSA.

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

Таким образом, разработчик инструментария MDD должен обладать следующими знаниями и навыками:

• навыками проектирования и программирования на Java;
• знанием интерфейса программирования UML 2 для Eclipse;
• знанием того, как собираются и размещаются в RSA плагины;
• дополнительно знанием интерфейса программирования UML-диаграмм в RSA.

Навыки разработчика бизнес-приложения

Разработчик бизнес-приложения должен понимать, как использовать MDD-инстру-менты в RSA в ходе процесса разработки. Конкретные детали работы зависят от созданных MDD-инструментов. Именно поэтому одним из пунктов плана MDD-проекта является обучение разработчиков использованию MDD-инструментов.

4.3.3 Размышления о повторном использовании

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

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

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

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

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

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

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

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

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

В начало

4.4 Контроль качества инструментария MDD

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

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

Архитектор решений должен уметь объяснить вам, какие из этих задач решает инструментарий MDD.

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

Менеджеры проектов должны проверять цепочку инструментов на соответствие следующим характеристикам:

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

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

В начало

4.5 Наблюдение за MDD-проектом

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

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

В начало

4.6 В конце проекта

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

Весьма полезно измерять следующие параметры

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

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

В начало

4.7 Заключение

В этой главе мы описали дополнительные шаги, необходимые для применения MDD в проекте.

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

Мы также предложили инструкции по планированию и работе в вашем первом MDD-проекте.

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

Гл. 5, «Жизненный цикл решения, создаваемого с использованием разработки, управляемой моделями», более подробно рассказывает об изменениях, которые вносит в жизненный цикл решения применение в проекте MDD.

Об авторе

		команда developerWorks работает над созданием полезных материалов для разработчиков

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало