 | Уровень сложности: простой IBM developerWorks, IBM developerWorks, IBM
05.2007 В этой главе описываются идеи, лежащие в основе разработки, управляемой моделями (MDD).
В этой главе описываются идеи, лежащие в основе разработки, управляемой моделями (MDD). Раскрываются следующие темы
- ключевые концепции, лежащие в основе MDD;
- рольUMLвMDD;
- роль шаблонов в MDD;
- процесс MDD.
3.1 Абстракция
Абстракция - это процесс игнорирования несущественных деталей для того, чтобы сконцентрироваться на существенных. В MDD мы применяем абстракцию для того, чтобы работать с логическим представлением приложения, не обращая внимания на детали реализации.
Для моделирования приложений можно применять абстракцию различного уровня (включая анализ, проектирование и реализацию) и с разных точек зрения (включая безопасность, управление и пользовательский интерфейс). Абстракция позволяет нам концентрироваться на различных аспектах системы и не теряться в деталях, которые, хотя и важны для системы в целом, несущественны для данной точки зрения.
При написании кода мы описываем наши приложения, используя концепции реализации. Даже когда мы применяем промежуточные платформы (middleware) с развитой функциональностью, нам нужно писать большой объем кода (а также дескрипторы размещения, конфигурационные файлы и т. п.), чтобы выразить концепции приложения. Большая часть кода, который мы пишем, оказывается однотипной, особенно если мы следуем соглашениям, принятым в конкретном проекте или в организации. Во многих случаях большая часть кода жестко определяется небольшим числом решений по проектированию и архитектурных принципов проекта. MDD позволяет нам работать на таком уровне, на котором мы можем напрямую зафиксировать проектные решения в моделях и сгенерировать соответствующий код при помощи трансформаций.
Концепции моделирования гораздо богаче, чем артефакты реализации. Мы можем сказать больше с меньшими усилиями. Быстрее создать модель, чем писать код вручную. Кроме того, мы можем сконцентрироваться на логике дизайна приложения, не отвлекаясь на детали реализации.
3.2 Точное моделирование
Абстракция - это не отсутствие точности. Когда мы используем абстракцию, мы опускаем конкретные детали, но остаемся точными в тех деталях, на которых концентрируется наше внимание. Когда мы используем подход MDD, мы можем очень точно описывать архитектуру и высокоуровневый дизайн системы, ничего не говоря о деталях реализации.
Для создания моделей в MDD используется, как правило, унифицированный язык моделирования. UML - это язык моделирования программного обеспечения с графической системой обозначений и лежащей в их основе семантикой. Часто предполагается, что диаграммы должны быть неформальными. Хотя UML можно использовать неформально, в нем есть семантика и возможность создавать точные модели, если будем применять UML последовательно.
В MDD мы используем модели как часть определения системы, а не просто как наброски. Эти модели имеют четко определенную семантику и могут быть преобразованы в артефакты реализации (точно так же, как код Java компилируется в байт-код).
3.3 Автоматизация
Моделирование само по себе является полезным, но ручная синхронизация моделей и кода может занять много времени и способствовать ошибкам. Автоматизация - это главное свойство, отличающее MDD от других подходов, в которых используется моделирование.
MDD связан с автоматизацией процесса разработки, поэтому любой артефакт, который может быть создан на основе информации, содержащейся в модели, будет сгенерирован. Сюда относится код, а также дескрипторы размещения, тесты, компоновочные скрипты, другие модели, документация и все прочие виды артефактов, которые должны производиться в программном проекте.
Примечание. Термин разработка, управляемая моделями, иногда используется для описания неавтоматизированных, но модельно-ориентированных подходов. В этой книге мы употребляем термин «управляемый моделями», имея в виду только те подходы, в которых применяется автоматизация.
Реализовать автоматизацию можно с помощью двух основных методов:
-
Трансформации. Трансформации автоматизируют создание артефактов из моделей. Сюда входит генерация кода, а также генерация более детальных моделей. Например, генерация модели дизайна по модели анализа. Трансформации, как правило, применяются в пакетном режиме к целым моделям, как это показано на Рис. 1-4.
-
Шаблоны. Шаблоны автоматизируют создание и изменение элементов модели с целью определенного изменения программного обеспечения. Шаблоны могут применяться на всех уровнях абстракции, поэтому могут существовать, например, архитектурные шаблоны, шаблоны дизайна и шаблоны реализации. Шаблоны обычно применяются интерактивно, проектировщик выбирает шаблон и указывает параметры (см. рис. 1-3).
Трансформации определяют, как высокоуровневые концепции соответствуют концепциям низкого уровня в соответствии с общепризнанным практическим опытом. Шаблоны низкого уровня обычно применяются через трансформацию, а не вручную. Например, трансформация из модели дизайна в код осуществляется с помощью генерации кода по шаблонам реализации.
3.4 Архитектурный стиль
MDD увеличивает производительность и согласованность путем автоматической генерации типовых частей артефактов, и это позволяет разработчику приложения сконцентрироваться на особенностях реализуемой бизнес-функции. Программные платформы, в том числе языки программирования и промежуточное программное обеспечение, предназначены для широкого применения, и они должны подстраиваться под самые разные стили разработки. Чем в большей мере мы сможем специализировать и ограничить способы использования платформ в нашей области разработки, тем большего уровня автоматизации мы сможем достигнуть.
MDD - это не тот способ, который подходит для чего угодно. Не существует одного готового программного продукта, который смог бы автоматизировать создание любого программного обеспечения. Нет настолько высокой степени общности, чтобы полностью использовать преимущества MDD. Подход MDD наиболее эффективен при автоматизации такого процесса разработки, где требованием является создание множества компонентов служб, приложений или решений на основе общего набора соглашений.
Ричард Хуберт (Richard Hubert) в своей книге «Convergent Architecture: Building Model-driven J2EE Systems with UML» (см. литературу по теме) вводит термин архитектурный стиль, под которым подразумевает этот общий набор соглашений: «Архитектурный стиль - это семейство архитектур, связанных общими принципами и атрибутами». Также он говорит: «Архитектурный стиль выражает принципы и способы наиболее эффективного получения концепции дизайна».
На архитектурный стиль могут повлиять следующие элементы
- тип разрабатываемого программного обеспечения (например, интеграционная система предприятия, встроенная система реального времени, интерфейс конечного пользователя);
- тип используемой платформы (например, промежуточное программное обеспечение для обмена сообщениями; система, основанная на правилах);
- используемая парадигма разработки программного обеспечения (например, сервисно-ориентированная, аспектно-ориентированная);
- предметная область программного обеспечения (телекоммуникации, финансы, розничная торговля);
- архитектурные принципы разрабатываемой системы или систем;
- область применения архитектурного стиля (от общеиндустриального до проект -но-специфического);
- стиль работы организации, разрабатывающей программное обеспечение (например, моделирование соглашений);
- другие факторы, влияющие на концепции, относящиеся к моделированию программного обеспечения в конкретном контексте.
Мы используем термин «каркас MDD» (MDD framework) для обозначения метода и инструментов, которые автоматизируют разработку для конкретного архитектурного стиля. Каркас MDD, как он определяется в этой книге, включает в себя:
- профили UML, которые настраивают UML на конкретную предметную область;
- автоматизированные шаблоны, в которых используются лучшие практические методы для решения повторяющихся проблем;
- трансформации, которые генерируют артефакты реализации и другие необходимые для работы продукты;
- руководство, описывающее, как создавать приложения с использованием этого каркаса;
- примеры моделей, демонстрирующие работу каркаса.
Приведенный ниже перечень демонстрирует возможные границы использования каркасов MDD, автоматизирующих архитектурный стиль.
-
Коммерческий готовый каркас MDD. Коммерческие поставщики могут предлагать каркасы MDD для использования в часто встречающейся предметной области.
-
Каркас MDD масштаба предприятия или программы. Каркас MDD общего применения разрабатывается для использования на предприятии или в программе, связанной с разработкой нескольких проектов, объединенных общими характеристиками.
-
Проектно-специфический каркас MDD. Каркас MDD разрабатывается для использования в конкретном проекте.
Каркас MDD масштаба предприятия особенно важен для описания и внедрения общего архитектурного стиля для всех IT-систем предприятия. Архитектурный стиль предприятия может состоять из набора связанных друг с другом архитектурных стилей, которые относятся к различным формам разработки программного обеспечения, осуществляемым на предприятии.
3.5 Роль UML
Как мы уже узнали, UML традиционно применяется для моделирования при использовании MDD (см. также подразд. 6.3.1, «UML и DSL»). UML является открытым стандартом и де-факто стандартом моделирования программного обеспечения. UML - это язык общего назначения для моделирования программ, который можно применять различными способами. Методика моделирования встроенного приложения для телефонных систем, которое работает в реальном времени, очень сильно отличается от моделирования приложения для розничной продажи. Но UML можно использовать в обоих случаях.
UML-профили
UML-профиль - это набор расширений, с помощью которых UML настраивается для использования в конкретной предметной области или в конкретном контексте. Можно привести следующие примеры UML-профилей
UML-профили являются независимыми расширениями языка, поэтому можно применять одновременно несколько профилей. Например, если мы моделируем вопросы безопасности приложения, в котором используется сервисно-ориентированная архитектура, мы можем применить сразу UML-профиль для служб и UML-профиль для безопасности.
Примечание. Рекомендуемый профиль для моделирования безопасности приводится в статье "Modeling Security Concerns in Service-Oriented Architectures", которую можно найти по адресу
http://www.ibm.com/developerworks/rational/library/4994.html
В UML-профиле предлагается набор «стереотипов», расширяющих концепции UML. Например, в UML-профиле для программных служб вводится стереотип Message, который вы можете применить к UML-классу, чтобы показать, что службе должен быть передан класс, представляющий собой сообщение. Использование стереотипов привносит дополнительную семантическую информацию как для человека, осуществляющего моделирование, так и для средств автоматизации. Мы можем различить UML-классы, представляющие собой сообщения, и UML-классы, представляющие собой таблицы базы данных. В этом случае стереотип Message, описанный при помощи языка WSDL, позволяет трансформации определить UML-класс, который используется для моделирования сообщений и который, следовательно, должен применяться при генерации артефактов, относящихся к сообщению.
На рис. 3-1 показан простой пример MDD, в которой концепция сообщения (Message), имеющаяся в модели, трансформируется в определение сообщения на WSDL в контексте трансформации UML-WSDL.
Рис. 3-1. Простой пример MDD
Разработчику моделей не требуется знать синтаксис WSDL. Фактически ему даже не нужно знать, что в реализации модели будет использоваться WSDL. Такое решение во время моделирования может еще не быть принято. Позже может оказаться необходимой поддержка, наряду с WSDL, других стандартов. Модель является независимой от особенностей конкретной платформы, и возможно создание трансформаций, которые генерируют артефакты для разных платформ на основе требований, предъявляемых к реализации.
Ценность общего языка моделирования
Применение UML для моделирования в MDD имеет следующие преимущества:
- Использование UML-профилей для моделирования MDD позволяет нам воспользоваться значительным опытом, вложенным в разработку этого языка. Это означает, что мы можем предоставлять настраиваемую среду для моделирования (в той степени, в которой это поддерживается стандартом UML и инструментарием для работы с UML) без значительных затрат, которые понадобились бы при проектировании и реализации с нуля.
- UML - это открытый стандарт, а также де-факто промышленный стандарт моделирования программного обеспечения. UML доказал свою надежность. Его первая версия появилась в 1995 г. и поэтому вложения в UML стоят многого. Успех UML означает, что существует множество книг и учебных курсов по этому языку. Многие студенты, занимающиеся компьютерными науками и программной инженерией, знакомятся с UML в университете. Также существует множество инструментов для работы с UML, а это значит, что опыт работы с UML вполне переносим из области в область.
- Большинству организаций приходится разрабатывать множество видов программного обеспечения. Если мы можем использовать общий модельный подход, настроенный соответствующим образом, для описания разных предметных областей, становится гораздо проще вести разработку и интеграцию в масштабе предприятия.
 |
3.6 Фиксация опыта
Многие IT-проекты страдают от недостатка квалифицированных экспертов. Это часто приводит к слишком большой зависимости проекта от ключевых сотрудников, без которых проект претерпевает очень серьезные трудности.
Ключевой аспект MDD - это фиксация опыта. Вместо необходимости постоянно иметь под рукой эксперта каждый раз, когда нужно принять практическое решение, мы фиксируем его опыт в автоматизированных шаблонах и трансформациях, которые мы можем применять многократно. Такой подход позволяет разработчикам, не имеющим специализированных знаний, создавать сложные системы.
Существует два вида опыта, которые нужно зафиксировать при построении каркаса MDD: опыт логической архитектуры и опыт технической архитектуры. Оба вида опыта являются частью общего архитектурного стиля.
3.6.1 Опыт логической архитектуры
Логическая архитектура решения относится к функциональности, которой программа должна обладать, а не к способу ее реализации с применением конкретных технологий. При использовании MDD целью является моделирование на логическом уровне и генерация артефактов реализации.
В MDD мы определяем стиль логической архитектуры и разрабатываем UML-профи-ли, шаблоны и соглашения по моделированию, которые относятся к этому стилю. Это означает, что большая часть опыта, используемого при определении логической архитектуры, фиксируется в каркасе MDD и применяется каждый раз, когда мы разрабатываем новое приложение. Разработчик нового приложения может больше сконцентрироваться на самой проблеме и меньше на аспектах программной архитектуры, которые являются общими для всех приложений.
3.6.2 Опыт технической архитектуры
Современные платформы предлагают широкий диапазон возможностей для поддержки самых разных приложений, которые будут создаваться на их основе. Однако в конкретных проектах используется только часть этой функциональности, и эта часть применяется специфическим образом.
Способ использования платформ в конкретном проекте (программе) определяет техническую архитектуру. Техническая архитектура может фиксироваться в документации, описывающей рекомендуемые решения, или передаваться от разработчика к разработчику. На практике получается, что очень сложно обеспечить согласованное применение архитектуры, если это делается вручную.
MDD предлагает нам возможность напрямую реализовывать техническую архитектуру. Вместо того чтобы записывать в документе, например, что «входные и выходные данные всех public-методов должны записываться в журнал с помощью log4j», мы можем создать трансформацию, которая генерирует код записи в журнал в соответствии с этим правилом.
Одним из побочных эффектов MDD является то, что этот подход заставляет нас обдумывать техническую архитектуру на более ранних стадиях проекта, и более тщательно. Если это понятно с самого начала и если выделено достаточно времени на определение технической архитектуры, то на более поздних стадиях проекта это сэкономит нам массу сил и времени.
3.7 Шаблоны
Мы уже вводили понятие моделирования с использованием концепций, специфических для предметной области, таких, как сообщение, прокси и адаптер. Часто в словарь предметной области приложения входит и понятие шаблона. Например, в области интеграции предприятия могут быть шаблоны гарантированной доставки и публикация-подписка. Они не являются отдельными элементами, но вводят связи между элементами и ограничения на их поведение.
Архитектор (строительный) Кристофер Александер (Christopher Alexander) предлагает в своей классической книге «The Timeless Way of Building» (см. полное описание в литературе по теме) концепцию языка шаблонов. Его представление о шаблонах как о наилучших способах решения распространенных проблем проектирования широко принято и в сообществе разработчиков программного обеспечения. Он предлагает концепцию языка шаблонов, который определяется как набор связанных друг с другом шаблонов, которые все вместе формируют «словарь» для проектирования в конкретном контексте или в предметной области.
В своей следующей книге, «A Pattern Language» (см. полное описание в литературе по теме), Александер вводит понятие специфического языка шаблонов, в который входят подъязыки для проектирования городов (это делают планировщики) и зданий (это делают архитекторы), и подъязык для конструирования (это делают разработчики-строители).
Ниже приводятся примеры шаблонов Александера.
- шаблоны городов: кольцевые дороги, ночные клубы и улицы таунхаусов.
- шаблоны зданий: сады на крыше, солнечное освещение в домах и ниши.
- шаблоны конструирования: подходящие материалы, соединения колонн и подгонка.
Идея языка шаблонов применима как к строительству, так и к разработке программного обеспечения, и мы будем применять этот термин в нашей книге. Природа разработки программного обеспечения подразумевает, что при использовании языка шаблонов становится возможной дополнительная автоматизация процесса проектирования.
Как и в строительстве, при проектировании программного обеспечения требуется человеческий опыт для выбора крупномасштабных (уровня предприятия и приложения) шаблонов. Однако применение шаблона можно автоматизировать таким образом, чтобы при выборе шаблона в проект записывались все детали, связанные с данным шаблоном. Простым примером программного шаблона являются шаблон функций доступа (get/set), в котором доступ к атрибутам всегда реализуется через операции, имеющие соответствующие имена. Мы можем автоматизировать этот шаблон так, чтобы применение его к атрибуту name класса Customer приводило к созданию операций с именами getName и setName (c соответствующими параметрами) в классе Customer.
Автоматизировать физическое строительство зданий невозможно. Однако программные системы создаются на основе информационных артефактов, которые можно генерировать автоматически на основе шаблонов реализации. Там, где строителю нужно вручную применять шаблон, мы можем описать реализацию достаточно подробно, чтобы артефакты можно было сгенерировать в данном специфическом контексте. Например, если у нас есть модель, в которой используется шаблон get/set, мы можем сгенерировать код этих методов для конкретной платформы (например, для Java) в соответствии с шаблонами реализации для данной платформы. В некоторых случаях может быть шаблон реализации, напрямую осуществляющий шаблон приложения. В других случаях для реализации шаблона приложения мы должны применить несколько низкоуровневых шаблонов реализации.
В разработке, управляемой моделями, применяются четко определенные модели, которые можно использовать как входные данные для автоматической трансформации. Язык шаблонов предоставляет структурированный метод разработки таких моделей.
3.8 Качество и согласованность
Разработка, управляемая моделями, - это не только более быстрое создание программного обеспечения (хотя она гарантирует и это). MDD - это в первую очередь более качественное программное обеспечение.
Автоматизация делает возможной согласованную реализацию программных компонентов, а это дает следующие преимущества:
-
Уменьшение стоимости обслуживания и поддержки. Сходство компонентов, генерируемых при использовании каркаса MDD, означает, что при обслуживании и поддержке вам меньше придется иметь дело с различиями. Например, вы не попадете в ситуацию, когда разные разработчики в ущерб общей согласованности используют разные пакеты для ведения журналов из соображений локальной оптимизации (например, наличие квалификации, производительность).
-
Ускоренное приобретение пользователями опыта работы. Согласованность оказывает положительное влияние на приобретение опыта применения разработанного программного обеспечения пользователем. Разработчикам не нужно тратить силы на следование фирменному стилю при разработке компонентов, взаимодействующих с пользователями, поскольку этот стиль применяется автоматически. Это не просто единообразное впечатление от работы с программой, это единая трактовка концептуальной модели, представленной пользователю. Мы получаем такой уровень согласованности, которого очень сложно добиться вручную.
-
Повышение качества. Поскольку опыт фиксируется и кодируется только один раз, а используется многократно, становится возможным больше внимания уделять качеству. Любые усовершенствования, вносимые в шаблоны и трансформации, повлияют на все программные компоненты, создаваемые с их помощью.
|
3.9 Интеграция
Распространенным заблуждением является представление о том, что MDD лучше всего подходит к разработке новых приложений. В действительности некоторые из преимуществ MDD наиболее выражены при построении интеграционных решений.
MDD позволяет игнорировать отличия в реализации существующих компонентов и приложений и сконцентрироваться на логической функциональности, которую дают эти приложения и компоненты. Мы можем моделировать логику интеграции или новую комбинированную функциональность приложений независимо от технологий, которые используются в компонентах. На рис. 3-2 показано UML-моделирование интеграционного решения, создаваемого на основе разнородных компонентов. В этом примере используются новые методы моделирования комбинированных структур, имеющиеся в UML 2.0 (компоненты-порты-коннекторы), которые хорошо подходят для моделирования слабосвязанных интеграционных решений.
Рис. 3-2. Согласованное моделирование разнородных компонентов
Мы моделируем существующие компоненты и новые компоненты согласованно. Если у нас есть какое-то количество компонентов, созданных с использованием одной технологии (например, CICS®), тогда, возможно, стоит разработать обратную трансформацию, которая создает логическую модель по существующему компоненту. Очевидно, что это возможно только в том случае, если существующий компонент имеет подходящий интерфейс. В других случаях придется писать компонент-адаптер с соответствующим интерфейсом. Если нам нужно создать несколько сходных адаптеров, можно автоматизировать этот процесс с помощью MDD.
Мы можем применять трансформации для генерации платформенно-специфического интеграционного кода, например создавать для приложений оболочки, чтобы они могли взаимодействовать с использованием Web-служб.
MDD предоставляет основу для согласованного и четко структурированного подхода к интеграции в масштабе предприятия. Использование UML для моделирования компонентов в интеграционном решении дает нам согласованное представление всего решения. Мы выигрываем от использования единого языка моделирования, поскольку работаем с логическими представлениями всех компонентов в одном инструменте.
3.10 Независимость от платформ
Возможность разработки независимых от платформы моделей часто называется основным преимуществом MDD, особенно в формальном представлении MDD от Object Modeling Group (OMG), которое называется Model-Driven Architecture (архитектура, управляемая моделями). Идея состоит в том, что в независимых от платформы моделях фиксируется функциональность системы, не связанная с платформой, на которой выполняется реализация, поэтому становится проще переходить на другие платформы, относящиеся к той же категории (например, между платформами для приложений масштаба предприятия J2EE и .NET). Хотя в некоторых ситуациях это может оказаться полезным, возможность переходить с платформы на платформу после реализации приложения не является самой распространенной причиной выбора такого подхода, как MDD.
На практике независимость MDD от платформы имеет несколько видов:
-
MDD, зависимая от платформы. В тех случаях, когда платформа известна и задана заранее, стоимость истинной независимости от платформы может оказаться слишком высокой. Повышение уровня абстракции не обязательно означает независимость от платформы. Можно создавать абстракции по рабочей платформе и пользоваться всеми преимуществами, которые дает применение платформы в конкретном архитектурном стиле. Часто гораздо эффективнее воспользоваться тем, что платформа известна.
-
Отсрочка выбора платформы. Существует возможность настроить каркас MDD так, чтобы большая часть моделирования выполнялась до выбора платформы. Это может быть полезным, если для принятия решения требуется больше времени. В некоторых случаях можно разработать трансформации для нескольких платформ и сравнить нефункциональные характеристики перед принятием решения. Очевидно, что при таком подходе нужно учитывать затраты на разработку трансформаций.
-
Несколько целевых платформ. Для многих приложений должна существовать возможность размещения в нескольких целевых средах, например в разных операционных системах для тех клиентов, которые применяют несколько языков программирования. В таких случаях моделируется общая функциональность и для реализации на разных платформах используются трансформации. Это уменьшает стоимость поддержки нескольких платформ и обеспечение соответствия между ними.
-
Переход между версиями. Для большинства платформ промежуточного программного обеспечения регулярно выпускаются новые версии с дополнительными возможностями. Чтобы использовать эти возможности, часто бывает необходимо заново реализовать какие-то части приложения. MDD позволяет вносить изменения в трансформации, включая в них новые возможности, и генерировать приложение заново.
Примечание. Независимость от платформ не означает, что мы можем полностью игнорировать платформу при моделировании. Мы должны иметь возможность моделировать так, чтобы можно было трансформировать модели в эффективную реализацию на целевой платформе.
При моделировании мы должны понимать возможности, которые предлагает платформа или класс платформ, которые мы хотим использовать. Например, платформа, работающая в реальном времени, будет иметь службу-таймер, а платформа, предназначенная для выполнения правил, будет содержать службу запуска правил. Эти возможности можно предполагать на этапе моделирования, и трансформации будут генерировать соответствующий код, применяющий эти службы платформ.
Нельзя сказать, что MDD совершенно не зависит от платформы. Правильнее будет сказать, что MDD зависит от класса платформ или от типа платформы.
3.11 Многоуровневое моделирование
Мы уже проводили различие между логическими моделями и реализациями этих моделей. Это разные уровни представления нашего решения, имеющие различную детализацию. В некоторых случаях целесообразно разделить разработку на большее число уровней, добавляя детализацию на каждом уровне по мере принятия решений по архитектурному стилю.
На рис. 3-3 показаны три модели.
Рис. 3-3. Уровни моделей
- В аналитической модели акцент делается на фиксации прецедентов использования (use case) приложения и не рассматриваются никакие решения относительно архитектуры.
- В модели IT-дизайна предприятия мы принимаем решения по IT-архитектуре, например о внедрении сервисно-ориентированной архитектуры. Однако сохраняется независимость от конкретной технологической платформы.
- В модели реализации мы внедряем конкретную платформу времени выполнения, например WebSphere.
Три уровня, показанные на рис. 3-3 (анализ, дизайн, реализация), применяются часто, но это никоим образом не единственный способ разбиения моделей на уровни. Могут также использоваться бизнес-модели, модели требований, модели высокоуровневого и детального дизайна и т. д. Идея в том, что каждый последующий уровень добавляет в решение детализацию, отвечая на вопросы, оставшиеся открытыми на предыдущем уровне, и ограничивает реализацию приложения.
При многоуровневом моделировании мы можем применять шаблоны на любом уровне (например, шаблоны дизайна и шаблоны реализации) и можем применять трансформации между любой смежной парой моделей (например, от дизайна к реализации).
3.12 Моделирование нефункциональных характеристик
При проектировании решения мы должны принимать во внимание нефункциональные характеристики, такие, как безопасность и производительность. Например, мы можем ввести стереотипы, указывающие, какой трафик, как ожидается, будет проходить по соединению (частый/нечастый, большой объем/малый объем). Затем в трансформациях эта информация применяется для генерации артефактов реализации с учетом данных характеристик.
Моделирование концепций, связанных с безопасностью, - это пример проектирования, специфичного для конкретного решения. Вы можете прочитать об этом в статье Саймона Джонстона (Simon Johnston) под названием «Modeling Security Concerns in Service-Oriented Architectures», которую можно найти на сайте IBM developerWorks<reg/> по адресу
http://www.ibm.com/developerworks/rational/library/4994.html
3.13 Заключение
В этой главе мы познакомили вас с основными идеями, лежащими в основе разработки, управляемой моделями, и дали краткий обзор операций, выполняемых в MDD-проекте. гл. 4, «Планирование проекта, выполняемого с использованием разработки, управляемой моделями», даст вам понимание процесса разработки с использованием MDD. Также в ней обсуждается, о чем должен подумать человек, занимающийся планированием MDD-проекта, прежде чем приступить к своей работе.
Об авторе | | | команда developerWorks работает над созданием полезных материалов для разработчиков |
Выскажите мнение об этой странице
| |
