MDD

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

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

IBM developerWorks, IBM developerWorks, IBM

05.2007

В этой главе объясняется, как вести управляемую моделями разработку (MDD) приложений и каркаса, используя Rational Software Architect (RSA). Мы рассмотрим действия, выполняемые архитекторами и проектировщиками.

В этой главе объясняется, как вести управляемую моделями разработку (MDD) приложений и каркаса, используя Rational Software Architect (RSA). Мы рассмотрим действия, выполняемые архитекторами и проектировщиками. Действия по написанию кода, которые выполняют программисты, рассматриваются в гл. 9, "Расширение возможностей Rational Software Architect". Мы рассмотрим следующие темы

• применение MDD с использованием RSA;
• применение профилей унифицированного языка моделирования (UML), шаблонов и трансформаций;
• создание UML-профилей;
• разработка шаблонов и трансформаций.

В предыдущей главе был определен архитектурный стиль для сервисно-ориентированной архитектуры (SOI). Этот стиль описывает архитектурные принципы, шаблоны, UML-профили и техническую архитектуру.

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

8.1 Общий обзор разработки, управляемой моделями, с использованием RSA

В процессе MDD есть два различных типа задач:

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

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

Операции, относящиеся на рис. 8-1 к разделу «разработка каркаса» (Framework Development), связаны с созданием каркаса, а операции, относящиеся к разделу «Разработка приложения» (Application Development), связаны с использованием данного каркаса для разработки приложений.

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

Между двумя упомянутыми видами деятельности есть следующие зависимости:

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

8.1.1 Разработка каркаса

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

• Фиксация опыта в форме архитектурных принципов и шаблонов.
• Реализация образцов компонентов и определение технической архитектуры. В гл. 7, «Разработка шаблонов для сценария», мы создали архитектурный стиль SOI для нашего сценария. В этой главе мы также покажем, как использовать RSA в ходе применения MDD к данному сценарию.
• Проектирование и реализация UML-профилей.
• Проектирование и реализация шаблонов RSA и трансформаций.

В гл. 9, "Расширение возможностей Rational Software Architect", показано, как реализовывать новые шаблоны RSA и трансформации.

8.1.2 Разработка приложения

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

Она включает следующие действия:

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

В начало

8.2 MDD-каркас для S0I в вRSA

В этой книге мы создаем MDD-каркас для SOI в RSA. .^тот каркас автоматизирует некоторые аспекты, которые мы определили в гл. 7, «Разработка шаблонов для сценария».

MDD-каркас RSA для SOI включает следующие расширения RSA

• (образец) SOI Example Profile;
• (образец) Pattern Library for SOI;
• (образец) SOI Transformation.

Для MDD-каркаса требуется UML-профиль от IBM Rational для программных служб (IBM Rational UML profile for software services).

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

В начало

8.3 Разработка приложения

В этом разделе мы расскажем, как реализовать пример с обновлением информации о покупателе, который был описан в гл. 7, «Разработка шаблонов для сценария», при помощи MDD-каркаса для SOI в RSA.

Для удобства повторим описание примера.

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

Этот пример реализуется при помощи каркаса MDD и архитектурного стиля, определенного в гл. 7, «Разработка шаблонов для сценария», для чего применяется MDD-каркас RSAдляSAдляS для SOI.

8.3.1 Инсталляция каркаса

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

Инсталляция UML-профиля для программных служб

1. Посетите указанный ниже Web-сайт: http://www.ibm.com/developerworks/rational/library/05/510_svc/ и найдите профиль UML profile for software services, который доступен в виде обновления для RSA.
2. Скачайте данный плагин на свою машину и инсталлируйте его, используя пункт меню RSA Help (Справка RSA) -> Software Updates (Обновления программы) -> Find and Install (Найти и установить).

Теперь вы можете использовать профиль для программных служб.

Инсталляция каркаса MDD для SOI и примера

Выполните инструкции, приведенные в прил. А, «Дополнительные материалы», чтобы установить примеры MDD (трансформацию и библиотеку шаблонов), updateCustomer. zip и sampleSource.zip. Теперь вы можете использовать пример профиля SOI, библиотеку шаблонов SOI и трансформацию SOL

8.3.2 Создание модели и применение профилей

Теперь мы готовы начать разработку примера, позволяющего обновлять информацию о покупателе.

Создайте новый UML-проект с именем Update Customer Details, выбрав пункт меню File (Файл) -> Project (Проект) -> Modeling (Моделирование) -> UML Project (UML-проект). Опции, установленные по умолчанию, вполне подходят, хотя при желании вы можете ввести другое имя для модели.

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

Далее мы применим к модели UML-профиль для программных служб и пример профиля SOL

1. Найдите модель в проводнике Model Explorer и выберите ее. При этом в представлении Properties (Свойства) вы увидите свойства модели.
   
2. В представлении Properties (Свойства) выберите вкладку Profile (Профиль).
3. Нажмите кнопку Add Profile (Добавить профиль).
4. Появится диалоговое окно Select Profile (Выбор профиля) (рис. 8-2). Выберите профиль UML Profile for Software Services.

Теперь в списке профилей, примененных к данной модели, появится профиль UML Profile for Software Services.

В качестве альтернативы использованию размещенных общих профилей, таких, как UML Profile for Software Services, вы также можете обращаться к профилям как к файлам .epx.

Совет. Если в команде практикуется совместный доступ к профилям, мы рекомендуем настроить в RSA карту путей (pathmap). За дополнительной информацией обращайтесь к статье «Comparing and merging UML models in IBM Rational Software Architect, Part 6: Parallel model development with custom profiles»:

http://www.ibm.com/developerworks/rational/library/05/0823_Letkeman/

Чтобы добавить в модель пример профиля SOI (SOI Example Profile), найдите его в рабочем пространстве проекта UpdateCustomerDetails, который вы загрузили в качестве дополнительных материалов.

1. Вернитесь в окно Select Profile (Выбор профиля) (рис. 8-3) и выберите вариант File (Файл) вместо Deployed Profile (Размещенный профиль).

2. Найдите пример профиля SOI (SOI Example Profile) и выберите его, как показано на рис. 8-4, чтобы добавить его в список примененных профилей.

8.3.3 Применение шаблонов

Теперь мы можем моделировать приложение, используя стереотипы, определенные в профилях, которые мы применили, а также шаблоны из библиотеки шаблонов SOL

Воспроизведем еще раз из гл. 3, «Разработка, управляемая моделями», описание использования языка шаблонов, данное Кристофером Александером (Christopher AlexrAlexA ander).

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

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

MDD-каркас для SOI, который мы инсталлировали ранее, включает пример библиотеки шаблонов SOL

1. Чтобы увидеть библиотеку шаблонов (SOI Pattern Library), выберите пункт меню Window (Окно) -> Show View (Показать представление) -> Pattern Explorer (Проводник по шаблонам). Проводник по шаблонам позволяет увидеть SOI Pattern Library, а также любые другие установленные библиотеки шаблонов (включая те, которые поставляются с RSA).
2. Откройте библиотеку SOI Pattern Library - и вы увидите список доступных шаблонов, показанный на рис. 8-5.

В нашем примере библиотеки шаблонов содержится только один высокоуровневый шаблон: шаблон соединения служб (service connection pattern), который подходит для нашего примера с обновлением информации о покупателе. В более полной библиотеке шаблонов у нас были бы шаблоны, подходящие и для других сценариев.

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

1. Чтобы использовать шаблон, создайте UML-кооперацию.
2. Создайте UML-диаграмму в свободном формате, используя пункт меню Add Diagram (Добавить диаграмму) -> Freeform Diagram (Диаграмма в свободном формате).
3. Добавьте на диаграмму UML-кооперацию из панели Composite Structure Diagram (Диаграмма сложной структуры) на палитре RSA.
4. Дайте кооперации имя UpdateCustomerDetails (рис. 8-6).

5. Чтобы создать экземпляр шаблона Service Connection Pattern, перетащите его из проводника шаблонов (Pattern explorer) в диаграмму, содержащую кооперацию (рис. 8.7).

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

Перетащите кооперацию [из проводника моделей (Model explorer) или диаграммы классов] на параметр-кооперацию экземпляра шаблона. Шаблон будет применен, и в кооперацию будут добавлены детали, как показано на рис. 8-8. Чтобы добиться идеального расположения, размещать объекты на диаграмме необходимо вручную.

Обратите внимание, что структура в кооперации соответствует шаблону, предложенному в подразд. 2.2.1, «Структура ESB». Шаблон создал компоненты служб, пригодные для повторного использования, которые можно применять в других кооперациях (рис. 8-9). Имена компонентов создаются на основе имени, которое мы дали кооперации. В данном примере шаблон всегда создает новые компоненты служб. Более сложный шаблон мог бы использовать существующие компоненты служб, где это возможно.

Этот шаблон также применяет соответствующие стереотипы из UML-профиля для программных служб. В частности, для компонентов служб имеется стереотип <<servi-ceProvider>>.

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

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

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

Для завершения модели были выполнены следующие шаги:

1. Внешние интегрируемые компоненты были смоделированы в пакете CustomerRecords. К этому пакету был применен стереотип <<external>>. Этот стереотип используется для того, чтобы указать, что смоделированные компоненты уже существуют и в трансформации не нужно генерировать новые артефакты. Таким же образом мы смоделировали компонент-внешний клиент.
2. Спецификации служб были смоделированы в пакете Service Specifications, а сообщения, применяемые в ходе взаимодействий, были смоделированы в пакете Data.
3. Спецификации служб выполнения запросов и служб-поставщиков для компонентов были определены в пакете Service Components. Эту дополнительную информацию также можно увидеть в объединенной структуре кооперации UpdateCustomerDetails в пакете End-to-End Service Collaborations.
4. Поведение каждого компонента было смоделировано при помощи диаграммы операций, которая соответствует определенному шаблону поведения. Соответственным образом были сконфигурированы стереотипные свойства операций в диаграммах операций.

8.3.4 Применение трансформаций

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

Чтобы понять дизайн трансформаций, обращайтесь к разд. 7.8, «Трансформации RSA».

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

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

Чтобы применить SOI-трансформацию, щелкните правой кнопкой мыши по модели и выберите пункт меню Transform (Трансформация) -> Service Transformation (Трансформация службы) -> Run (Выполнить). При трансформации генерируется набор EJB-проектов, реализующих компоненты служб приложения.

Если в исходной модели недостает какой-то информации, необходимой для генерации кода, трансформация генерирует часть своих выходных данных, но завершается ошибкой. Если применить трансформацию к нашей модели UpdateCustomerDetails, то рабочее пространство будет выглядеть так, как показано на рис. 8-10.

Сгенерированный код соответствует технической архитектуре, предложенной в гл. 2, «Общий обзор сценария».

8.3.5 Тестирование сгенерированного кода

Выполните следующие шаги, чтобы разместить и протестировать сгенерированные EJB-компоненты фасада службы-поставщика, используя IBM WebSphere Application Server V6.0 Integrated Test Environment (в Microsoft Windows®).

1. Переключитесь на перспективу J2ЕЕ.
2. Создайте проект клиентского приложения для EJB-компонента, который вы хотите протестировать.
3. В проводнике проектов (Project Explorer) выберите UpdateCustomerDetailsA_MPFSEJBEAR.
4. Щелкните правой кнопкой мыши и во всплывающем меню выберите New (Новый) -> Application Client Project (Проект клиентского приложения).
5. Введите в мастере имя нового проекта, а затем нажмите Next (Далее).
6. На странице Module Dependencies (Зависимости модуля) выберите модули, как показано на рис. 8-11.

7. Отредактируйте сгенерированное клиентское приложение (Main.java).
8. Откройте файл Main.java в новом проекте клиентского приложения и создайте новый метод test.
9. Вызовите его из метода Main, как показано в примере 8-1.

public class Main {
  public static void main(String[] args){
    new Main().test(); 
  }
  public  Main(){ 
    super();
  }
	public void test(){
	}
}
			

С помощью представления Snippets (Фрагменты) вставьте фрагмент Call a Session Bean service method (Вызов метода сессионного компонента) (рис. 8-12).

Настройка строки, передаваемой в метод EJB-компонента

После того как фрагмент кода вставлен, следующий шаг - настроить строку, передаваемую в метод EJB.

Примечание. Архитектура позволяет EJB-компоненту фасада поставщика выполнять XSLT-трансформацию для создания сообщения, передаваемого службе-поставщику. Однако в примере модели такая трансформация не указана. Кроме того, поставляемый базовый класс EJB (в проекте ESBUtilities) не поддерживает трансформации сообщений.

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

Подходящее SOAP-сообщение показано в примере 8-2.

<SOAP-ENV:Envelope
  SOAP-ENV:encodingStyle=»http://schemas.xmlsoap.org/soap/encoding/»
  xmlns:SOAP-ENV=»http://schemas.xmlsoap.org/soap/envelope/»
  xmlns :tns=»http://customer.soi.example.itso»
  xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»>
  <SOAP-ENV:Body>
  <tns:updateCustomerRecords>
  <tns:customerInformation> 
    <tns : FName>John</tns:FName> 
    <tns:SName>Smlth</tns:SName>
  </tns:customerInformation> 
</tns:updateCustomerRecords> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope>
			

1. Поместите файл test.xml в корневую директорию проекта клиентского приложения. Нужно добавить еще одну строку, чтобы распечатать сообщение, возвращаемое EJB-компонентом, и получить возможность оценить его успешность. Метод test теперь должен выглядеть так, как показано в примере 8-3.

// чтение тестового сообщения 
StringBuffer buffer = new StringBuffer(); 
BufferedReader file = null; 
try {
  file = new BufferedReader(new FileReader(«test.xml»)); 
  String  line = file. readLine(); 
  while(   line  != null   ){ 
    buffer.append(line); 
    line = file. readLine();
  }
} catch   (FileNotFoundException e)   { 
// TODO Auto-generated  catch  block
  e.printStackTrace(); 
} catch  (IOException e)   { 
  // TODO Auto-generated  catch  block 
  e.printStackTrace();
} finally { 
  try  {
    file.close();
  } catch  (IOException  e1)   {
    // TODO Auto-generated  catch  
    block e1.printStackTrace();
    String in = buffer. toString();
    UpdateCustomerDetailsA_MPFSEJBRemote anUpdateCustomerDetailsA_MPFSEJBRemote
    = createUpdateCustomerDetailsA_MPFSEJBRemote();
    try {
      String aString = anUpdateCustomerDetailsA_MPFSEJBRemote 
        .updateCustomerDetails(in);
      System.out.println(aString); 
    } catch (RemoteException ex) {
      // TODO Auto-generated catch block
      ex. printStackTrace();
    }
			

Совет. Если в клиентском приложении возникли ошибки компиляции, которые нельзя исправить, выполните чистую сборку EJB.

2. Разместите Web-службу и EJB-проекты.
3. В представлении Servers (Серверы) щелкните правой кнопкой мыши по серверу, который вы хотите использовать, и выберите в меню пункт Add and remove projects... (Добавление и удаление проектов...). Добавьте проекты CustomerRecordsA_ MEAR и UpdateCustomerDetailsA_MPFSEJBEAR. Вы также можете протестировать проекты N_Z, но они нисколько не отличаются.

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

4. Проверьте номер порта Web-службы-поставщика.
5. В проекте CustomerRecordsA_M откройте файл WebContent\WEB-INF\wsdl\Custo-merRecords.wsdl. В конце этого файла определяется служба с URL, указывающим ее положение, как показано в примере 8-4.

<wsdl: service name="CustomerRecordsServiceA-M">
<wsdl:port binding="intf:CustomerRecordsSoapBinding"  name="CustomerRecords">
<wsdlsoap:address
location = "http ://localhost: 9080/CustomerRecordsA_M/services/CustomerRecords"/>
</wsdl:port>
</wsdl:service>
			

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

6. Если вы не знаете, какой должен быть номер порта, выполните следующие инструкции, чтобы запустить на сервере административную консоль:
   1. Перейдите на страницу Servers (Серверы) -> Application servers (Серверы приложений).
   2. Щелкните мышью по имени сервера.
   3. Нажмите Ports (Порты) [в разделе Communications (Связь)]. В конце таблицы портов нужно найти порт WC_defaulthost, если вы используете узел, заданный по умолчанию.
7. При необходимости измените URL, указывающий положение службы, в wsdl-файле, чтобы узел и порт были указаны верно.

Далее нужно протестировать службу-поставщика.

Тестирование Web-службы-поставщика

Прежде чем тестировать EJB-компонент, играющий роль фасада поставщика, неплохо было бы протестировать службу-поставщик (CustomerRecordsA_M), чтобы проверить правильность ее настройки.

1. Щелкните правой кнопкой мыши по файлу CustomerRecords.wsdl и выберите в появившемся меню пункт Web Services (Web-службы) -> Test with Web Services explorer (Протестировать с помощью проводника Web-служб).
2. В проводнике Web-служб выберите операцию updateCustomerRecords.
3. Нажмите Go (Запустить), чтобы вызвать службу. Вы должны увидеть ответ OK (рис. 8-13).

4. Запустите скрипт для соединения.
   EJB-компонент-фасад поставщика находит в JNDI URL службы-поставщика, которую он должен вызвать. Трансформация генерирует скрипт, который можно запустить, чтобы настроить необходимые для сгенерированных EJB связи в пространстве имен JNDI. Скрипт находится в проекте, который называется ChangeCustomerDetailsService Connect.
5. Откройте скрипт (UpdateCustomerDetails.jacl) и убедитесь, что URL, который указан как местоположение службы-поставщика, совпадает с заданным вами URL местоположения службы.
6. В представлении Servers (Серверы) щелкните правой кнопкой мыши ваш сервер и выберите из меню пункт Run external admin script... (Запустить внешний административный скрипт...).
7. Выберите файл скрипта UpdateCustomerDetails.jacl и запустите его.
   Выполнение скрипта занимает несколько секунд. Дождитесь его завершения, а затем с помощью административной консоли убедитесь, что связи пространства имен были созданы.
8. Запустите клиентское приложение:
   1. щелкните правой кнопкой мыши по файлу Main.java в проекте клиентского приложения и выберите в появившемся меню пункт Run (Выполнить) -> Run...(Выполнение...);
   2. в диалоговом окне Launch Configuration (Конфигурация запуска) создайте новую конфигурацию клиента WebSphere 6.0 Application Client;
   3. убедитесь, что выбрана опция Enable application client to connect to server (Разрешить клиентскому приложению связываться с сервером), как показано на рис. 8-14.

Настройка рабочей директории

Вы также должны настроить рабочую директорию, чтобы клиентское приложение могло найти файл test.x.xx^l.

1. Перейдите на вкладку Arguments (Аргументы) и в поле Working directory (Рабочая директория) укажите проект клиентского приложения, как показано на рис. 8-15.

2. Нажмите Apply (Применить), чтобы сохранить изменения.
3. Нажмите Run (Выполнить), чтобы запустить приложение. Если приложение выполнено успешно, вы увидите на консоли ответное сообщение от EJB, сходное с тем, которое показано на рис. 8-16.

8.3.6 Заключение по разработке приложения

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

В начало

8.4 Разработка каркаса

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

8.4.1 Разработка архитектурного стиля

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

Создание архитектурного стиля включает в себя следующие задачи:

• разработку высокоуровневых архитектурных принципов и шаблонов;
• проектирование UML-профиля или профилей;
• разработка технической архитектуры и образцов компонентов.

Архитектурный стиль SOI описан в гл. 2, «Общий обзор сценария». Также были разработаны образцы компонентов, демонстрирующие техническую архитектуру.

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

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

8.4.2 Создание UML-профиля

К проектированию UML-профиля необходимо подходить внимательно, чтобы создать правильный набор концепций для моделирования в данном контексте. Проектирование примера профиля для SOI показано в разд. 7.7, «Детализация первоначальной модели шаблонами служб». Проектирование приводит к необходимости поддержки стереотипов, которые идентифицируют следующие элементы

• Все возможные операции на диаграммах операций для ESB-служб. Каждый тип операции имеет свой собственный стереотип.
• Атрибуты, определяющие поведение службы. Например, операция по трансформации имеет атрибут «transformationID», который определяет трансформацию, которая применяется службой трансформации.
• Параметры, управляющие генерацией службы. Например, стереотип <<optional>> имеет атрибут булева типа <<generate>>, который определяет, является ли данная служба генерируемой, или же это ссылка на существующую службу.
• Идентификация параметров, определяющих и направляющих поведение службы в целом. Например, стереотип фасада интеграционной службы определяет версию службы и используемый уровень журналирования.

Шаги, приведенные в следующих подразделах, показывают, как создать набор стереотипов, включаемых в пример профиля SOI (SOI Example Profile).

Создание проекта профиля

Создайте новый проект UML-профиля с именем SOI Example Profile, для чего выполните следующие действия:

1. Выберите пункт меню File (Файл) -> New (Новый) -> Project (Проект) -> Modeling (Моделирование) -> UML Extensibility (Расширения UML) -> UML Profile Project (Проект UML-профиля).
2. Вызовите профиль Test. Опции, заданные в мастере по умолчанию, вполне подходят.

Добавление стереотипов

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

Для добавления стереотипа <<external>> выполните следующие шаги

1. Щелкните правой кнопкой мыши и выберите пункт меню Profile model (Модель профиля) -> Add UML (Добавить UML) -> stereotype (стереотип).
2. Дайте стереотипу имя external.
3. Теперь нужно указать, к каким UML-элементам можно будет применять стереотип. Выберите стереотип <<external>> в Model Explorer (Проводник по моделям) -> Properties view (представление свойства) -> Extensions (Расширения) -> Add Extension (Добавить расширение) -> Class (Класс).

4. Повторите эти шаги для элементов Component (Компонент), Package (Пакет) и Interface (Интерфейс).

Теперь у нас есть стереотип <<external>>, который можно применить к UML-классам, компонентам, пакетам и интерфейсам.

Совет. Обычное соглашение об именах предусматривает, что первая буква в именах стереотипов является строчной.

Проверка и тестирование профиля

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

1. Сохраните проект профиля.
2. Щелкните правой кнопкой мыши и выберите пункт Run Validation (Запустить проверку). Все ошибки проверки или предупреждения будут выводиться в представлении Problems (Проблемы).
3. Прежде чем продолжать, исправьте все проблемы.
4. Создайте новый проект для UML-моделирования и выберите модель.
5. Перейдите в окно Properties (Свойства) -> Profiles (Профили) -> Add Profile (Добавить профиль). Мы еще не разместили профиль, поэтому выберите пункт File (Файл) в раскрывающемся меню профилей и найдите профиль в файловой системе (он должен иметь расширение .ерх). На рис. 8-18 показан результат.

6. Создайте один UML-элемент, к которому вы можете применить стереотип <<external>> (класс, компонент, пакет или интерфейс). Мы решили применить стереотип к классу Test.
7. Выберите элемент и просмотрите вкладку Stereotypes (Стереотипы) в представлении Properties (Свойства). Нажмите Add (Добавить).

В раскрывающемся списке появится стереотип <<external>> (рис. 8-19).

Если вы вносите изменение в профиль, вам нужно синхронизировать все модели, к которым этот профиль был применен.

1. Вернитесь в проект профиля Test.
2. Добавьте новый стереотип с именем externalService. Он обозначает компоненты внешней службы, которые вызываются из фасадов служб-поставщиков.
3. Сохраните профиль.

4. Добавьте расширение-компонент к новому стереотипу и сохраните профиль Test.epx.
5. Вернитесь к примеру модели и посмотрите на вкладку Profiles (Профили). Профиль SOI Example Profile помечен как несинхронизированный (OUT OF SYNC), как показано на рис. 8-20.
6. Выберите пункт Test profile (Протестировать профиль) -> Migrate profile (Перенести профиль), чтобы загрузить новую версию профиля. Теперь вы можете использовать добавленный стереотип.

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

Использование проводника по наследованию

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

Операции, которые предоставляет профиль SOI Example Profile для применения к операциям в диаграммах операций, соответствуют этому шаблону.

1. Создайте стереотип <<ServiceAction>> и добавьте расширение к метаклассу Action.
2. В окне Properties (Свойства) -> General (Общие) пометьте стереотип как Abstract (Абстрактный). Это означает, что пользователи не смогут применять этот стереотип к модели напрямую. В профиле SOI Example Profile используется соглашение, что абстрактные стереотипы начинаются с прописной буквы, а конкретные стереотипы начинаются со строчной буквы.
3. Перетащите стереотип ServiceAction в Inheritance Explorer (Проводник по наследованию) (рис. 8-21).

4. Щелкните по стереотипу правой кнопкой мыши и выберите пункт меню Create New Subtype (Создать новый подтип), чтобы ввести новые подстереотипы.
5. Добавьте новые подстереотипы с именами pushCallbackAddress, popCallbackAddress и createAcknowledgement.
6. Сохраните профиль и протестируйте его, используя пример модели.
7. Создайте диаграмму операций, а затем добавьте к ней операции. Примените к операциям три конкретных подстереотипа (рис. 8-22).

Совет. Не забывайте переводить все открытые модели на новые версии профиля, если вы вносите изменения в профиль. Если вы откроете модель после изменения профиля, RSA спросит вас, нужно ли переходить к самой последней версии профиля.

Добавление атрибутов к стереотипам

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

• Создайте в иерархии стереотипы TechnicalServiceAction и recordPerformance (рис. 8-23).

• В проводнике по моделям (Model Explorer) (но не в Inheritance explorer) щелкните правой кнопкой по стереотипу recordPerformance и выберите пункт меню Add UML (Добавить UML) -> Attribute (Атрибут).
• Присвойте атрибуту имя subidentifier.
• В окне Properties (Свойства) -> General (Общие) атрибута subidentifier укажите тип атрибута - String. В качестве типов атрибутов можно использовать элементарные типы UML. Вы можете задать атрибуту значение по умолчанию в том случае, если это имеет смысл.

Задание перечислимых типов

Часто бывают полезны атрибуты перечислимого типа (Enumeration). Стереотип recordPerformance имеет два атрибута: class и level.

1. Щелкните правой кнопкой мыши по модели Test и выберите пункт меню Add UML (Добавить UML) -> Enumeration (Перечислимые значения) и введите перечислимые значения PerformanceEventClass и PerformanceEventLevel (рис. 8-24).

2. Щелкните правой кнопкой мыши по каждому из литералов и выберите пункт меню Add UML (Добавить UML) -> Enumeration Literal (Перечислимый литерал) с литералами, показанными на рис. 8-24.
3. Примените эти перечислимые типы в качестве типов для атрибутов class и level стереотипа recordPerformance, как показано на рис. 8-25.

4. Сохраните профиль и протестируйте его снова.
5. Примените стереотип recordPerformance к операции и откройте окно Properties (Свойства) -> Stereotypes (Стереотипы), чтобы увидеть атрибуты и задать для них значения (рис. 8-26).

Добавление значков

Для стереотипов также можно указать значки, которые будут отображаться в RSA. Значки добавляются на закладке Properties General (Общие свойства) стереотипа (рис. 8-27).

Значки используются в проводнике моделей (Model Explorer), а также как декоративные элементы на диаграммах. Значки могут представлять собой GIF- или ВМР-файлы, и для них рекомендуется размер 16 х 16.

Контуры (Shape Images) используются на диаграммах, когда для отображения стереотипа элемента гистограммы задана опция Shape Images. Контуры представляют собой SVG-файлы, для которых рекомендуется размер 50 х 50.

В профиле SOI Example Profile не предлагается никаких новых значков, а используются те значки, которые предлагаются в UML-профиле для программных служб (UML profile for software services). Например, значок, связанный со стереотипом «service рrovider» выглядит так

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

Выпуск профиля

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

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

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

Совет. Правильно выбирайте время выпуска профиля. После выпуска вы не сможете вносить несовместимых изменений, например, переименовывать стереотип.

Упаковка профиля для размещения

Когда вы готовы к тому чтобы ввести UML-профиль в совместное использование, удобным способом его размещения будет применение плагина (plug-in). После размещения профиля он появляется в списке размещенных плагинов и может быть применен к модели. Размещение профиля как плагина описано в разд. 9.3, «Размещение UML-профилей».

8.4.3 Реализация образцов компонентов

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

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

8.4.4 Разработка шаблонов и трансформаций

Шаблоны и трансформации, необходимые для каркаса MDD, идентифицируются в ходе разработки архитектурного стиля. Шаблоны и трансформации, необходимые для MDD-каркаса для SOI, были перечислены в гл. 2, «Общий обзор сценария».

Шаблоны и трансформации RSA реализуются в форме плагинов RSA, написанных на Java. В гл. 9, «Расширение возможностей Rational Software ArchitectSoftwareArchitecteArchitectArchitect^^, описано, как реализовать шаблоны и трансформации RSA

В начало

8.5 Заключение

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

В следующей главе мы рассмотрим реализацию шаблонов и трансформаций в RSA

Об авторе

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

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

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

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

В начало