Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 94

24.2 приведен пример профиля Java. Этого профиля недостаточно для моделирования приложений Java, поскольку в нем не хватает стереотипов для файлов классов и каталогов. Мы расширяем этотпрофиль двумя новыми стереотипами, представленными в табл. 24.3.На рис. 24.8 расширенный Javaпрофиль из спецификации UML применен к нашей модели. Как видите, с использованием наглядных стереотипов диаграмма стала намного более выразительной.Таблица 24.2СтереотипПрименяется к Семантика«EJBEntityBean»компонентуКомпонентсущность EJB.«EJBSessionBean»компонентуСеансовый компонент EJB.«EJBMessageDrivenBean» компонентуУправляемый сообщениямикомпонент EJB.«EJBHome»интерфейсу«Домашний» интерфейс EJB.«EJBRemote»интерфейсуУдаленный интерфейс EJB.«EJBCreate»операцииОперация создания EJB.«EJBBusiness»операцииОперация, поддерживающая бизнеслогику удаленного интерфейса EJB.«EJBSecurityRoleRef»ассоциацииАссоциация между EJB и поставщиком, предоставляющим ссылку на рольв системе безопасности.«EJBRoleName»актеруИмя роли в системе безопасности.«EJBRoleNameRef»актеруСсылка на роль в системе безопасности.«JavaSourceFile»артефактуИсходный файл Java.«JAR»артефактуФайл Javaархива.«EJBQL»выражениюВыражение на языке запросов EJB.Таблица 24.3СтереотипПрименяется к Семантика«JavaClassFile»артефактуФайл класса Java (откомпилированный исходный файл Java).«directory»артефактуКаталог.522Глава 24.

Развертывание«JAR»librarySystem.jar«JavaClassFile»ISBN.class«JavaClassFile»BookImpl.class«JavaClassFile»LibraryImpl.class«JavaClassFile»TicketImpl.class«JavaClassFile»Book.class«JavaClassFile»Library.class«JavaClassFile»Ticket.class«JavaClassFile»TicketID.class«directory»MET A_INF«file»MANIFEST .MF«JAR»jdom.jarРис. 24.8. К модели на рис. 24.7 применен расширенный Java+профильиз спецификации UML24.6.

РазвертываниеПростая экземплярная форма диаграммы развертывания представлена на рис. 24.9.Данный пример взят из обучающего курса Java (www.java.sun.com). Этоприложение преобразователя валют. На рис. 24.9 показан файл архивакорпоративных приложений (Enterprise application Archive, EAR) ConverterApp.ear, развернутый в среде выполнения J2EE Server на узле server(сервер) типа WindowsPC. J2EE Server – это сервер приложений корпорацииSun, поставляемый как часть J2EE. EARфайлы – особый тип JARфайлов, в которых содержатся приложения J2EE. Развернутое серверное приложение используется клиентским приложением ConverterClient.jar, которое исполняется на узле client (клиент) типа WindowsPC.Спецификацию развертывания можно прикрепить к развернутому артефакту, как показано на рисунке.

В ней содержится основная информация о развертывании. В данном случае определены три вещи:•EnterpriseBeanClass (класс корпоративного компонента) – класс, содержащий логику компонента;•EnterpriseBeanName – имя корпоративного компонента, которое можетприменяться клиентом для организации доступа к компоненту;52324.7. Что мы узнали«device»server:WindowsPC«device»client:WindowsPC«JAR»:ConverterClient.jar«RMI»«execution environment»:J2EE Server«JAR»:ConverterApp.ear«deployment spec»:web.xmlEnterpriseBeanClass : ConverterBeanEnterpriseBeanName : ConverterBeanEnterpriseBeanT ype : StatelessSessionРис.

24.9. Экземплярная форма диаграммы развертывания для приложенияпреобразователя валют•EnterpriseBeanType (тип корпоративного компонента) – тип компонента. В данном случае это не имеющий состояния сеансовый компонент – компонент, используемый для простых транзакций; он неимеет состояний и не является сохраняемым.Развертывание EJB – намного более сложный процесс, чем мог быпредложить этот простой пример, и некоторые из его деталей даже зависят от среды выполнения.

Однако цель моделирования в развертывании – отражение основных моментов развертывания, поэтому представленного дескриптора может быть вполне достаточно.24.7. Что мы узналиДиаграммы развертывания позволяют моделировать распределениепрограммной системы на физическом оборудовании. Мы узнали следующее:•Деятельность UP Реализация архитектуры состоит в определении важных с архитектурной точки зрения компонентов и проецированииих на физическое оборудование.•Диаграмма развертывания проецирует программную архитектуруна аппаратную архитектуру.524Глава 24.

Развертывание•••••••В процессе проектирования можно создать «первое приближение»диаграммы развертывания, определяя узлы или экземпляры узлови отношения. В процессе реализации это приближение дополняетсякомпонентами или экземплярами компонентов.Дескрипторная форма диаграммы развертывания может использоваться для моделирования того, какие типы оборудования, программного обеспечения и соединений будут присутствовать в окончательно развернутой системе.• Описывает полный набор возможных сценариев развертывания.• Показывает:• узлы – на каких типах оборудования выполняется система;• отношения – типы соединений между узлами;• компоненты – типы компонентов, развернутых на конкретных узлах.Экземплярная форма диаграммы развертывания представляет конкретное развертывание системы на определенных, идентифицируемых частях оборудования.• Описывает один определенный вариант развертывания системы,возможно, на конкретном пользовательском сайте.• Показывает:• экземпляры узлов – конкретные части оборудования;• экземпляры отношений – конкретные отношения между экземплярами узлов;• экземпляры компонентов – конкретные идентифицируемыечасти программного обеспечения, развернутые на экземпляреузла, например конкретная копия Microsoft Office с уникальным серийным номером.Узел – представляет тип вычислительного ресурса.• «device» – тип физического устройства, такой как ПК или серверFire корпорации Sun.• «execution environment» – тип среды выполнения программногообеспечения, например вебсервер Apache.Экземпляр узла – представляет конкретный вычислительный ресурс.Артефакт – представляет описание реальной сущности, такой какконкретный исполняемый файл.• Артефакты могут представлять один или более компонентов.Экземпляр артефакта – представляет определенный экземпляр конкретного артефакта, например определенную копию конкретногоисполняемого файла, установленную на конкретном компьютере.VIДополнительные материалы25Введение в OCL25.1.

План главыСначала мы собирались дать очень краткое введение в OCL, в основномохватывающее информацию, необходимую для сертификации поUML. Однако чем больше мы знакомились с существующей литературой по OCL, тем более ощущалась необходимость в простом, но исчерпывающем описании языка, ориентированном именно на ОО аналитика/проектировщика. Именно такое описание мы постарались представить в этой главе. Оно основывается на спецификации «Unified Modeling Language: OCL, version 2.0» [OCL1], но пока книга готовиласьк изданию, в спецификацию могли быть внесены некоторые незначительные изменения.Как ОО аналитик или проектировщик вы, вероятно, не очень хорошознакомы с OCL.

Надеемся, что прочитав главу, вы получите достаточно полное представление об OCL и сможете оценить те возможности,которые он предоставляет для подробного UMLмоделирования.Глава содержит довольно много материала, поэтому в ее план включены только основные темы (рис. 25.1).25.2. Что такое объектный языкограничений (OCL)?OCL может определять запросы, ограничения и операции запросов.OCL – язык, позволяющий вводить в UMLмодель дополнительнуюинформацию.

Это стандартное расширение UML, предоставляющееследующие возможности:528Глава 25. Введение в OCL25.2. Что такое объектный язык ограничений (OCL)?25.3. Почему OCL?25.4. Синтаксис выражений OCL25.8.2. Система типов OCLизучаем простые типыизучаем структурированные типыучимся добавлять инфиксные операторыизучаем OCL!коллекции25.8.4. Тип Tuple25.8.5. Инфиксные операторы25.8.6. OCLQколлекции25.8.3.

Простые типы25.9. Навигация в OCLизучаем простую навигациюучимся проходить по ассоциациямучимся проходить по нескольким ассоциациям25.9.1. Навигация в рамкахэкземпляра контекста25.9.2. Навигацияпо ассоциациям25.9.3. Навигацияпо нескольким ассоциациям25.10. Типы OCLQвыражений подробноизучаеминвариантыизучаем пред!и постусловияопределяемоперации запросаинициализируемпеременныеопределяемпеременныеопределяем локаль!ные переменныеопределяем произ!водные атрибуты25.10.1. inv:25.10.2. pre:,post: и @pre25.10.3.

body:25.10.4. init:25.10.5. def:25.10.6. ВыраQжения let25.10.7. derive:25.11. OCL на диаграммах других типовучимся использовать OCLв диаграммах взаимодействияучимся использовать OCLв диаграммах деятельностиучимся использовать OCLв конечных автоматах25.11.1. OCL на диаграммахвзаимодействий25.11.2. OCL на диаграммахдеятельности25.11.3. OCL на диаграммахсостояний25.12. Дополнительные вопросыработаем с классами!ассоциациямиработаем с квалифицированнымиассоциациямиработаем с унаследованнымиассоциациямиработаемс сообщениями25.12.1. Навигация ки из классовQассоциаций25.12.2. Навигация по квалифициQрованным ассоциациям25.12.3.

Унаследованныеассоциации25.12.4. OclMessage25.13. Что мы узналиРис. 25.1. План главы25.3. Почему OCL?•••529писать запросы для организации доступа к элементам модели и ихзначениям; это язык запросов, немного похожий на SQL;накладывать ограничения на элементы модели – можно определятьбизнесправила как ограничения, накладываемые на элементы модели;определять операции запросов.OCL не язык действий для UML, потому что выражения OCL не оказываютпобочных эффектов.Очень важно понять, что OCL не является языком действий для UML.С его помощью невозможно определить поведение, потому что OCLвыражения не имеют побочных эффектов.

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