UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• « device» (устройство) – узел представляет тип физического устрой ства, например ПК или сервер Fire корпорации Sun. • « execution environment» (среда выполнения) – узел представляет тип среды выполнения программного обеспечения, например веб сер вер Apache или EJB контейнер (Enterprise JavaBeans) JBoss. Узлы могут быть вложены в узлы. Например, дескрипторная форма диаграммы развертывания на рис. 24.3 показывает, что нуль или более WindowsPC, на которых выполняется веб броузер Firefox, могут быть со 516 Глава 24. Развертывание единены с нулем или более веб серверами Apache, которые выполняют ся на LinuxPC. Обратите внимание, что назвав узлы WindowsPC и LinuxPC, мы указали и тип оборудования (PC), и операционную систему, т. е. среду выполнения для всего программного обеспечения, выполняюще гося на этих устройствах. Это общепринятая практика, поскольку вы деление специального узла среды выполнения для операционной сис темы загромождает диаграмму. Firefox представлен как среда выполне ния, потому что в нем могут выполняться подключаемые (plug in) ком поненты, такие как апплеты Java. Ассоциация между узлами представляет канал связи, по которому мо жет передаваться информация в обоих направлениях. На рис. 24.3 ас социация обозначена стереотипом «http». Это указывает на то, что она представляет соединение HTTP (HyperText Transport Protocol 1 – про токол передачи гипертекста) между двумя узлами. Экземпляр узла представляет конкретный вычислительный ресурс. Если необходимо показать конкретные экземпляры узлов, можно ис пользовать экземплярную форму диаграммы развертывания (рис. 24.4). На рисунке изображены два конкретных ПК: компьютеры Джима ( JimsPC) и Илы (IlasPC), подключенные к серверу WebServer1, работающе му под управлением Linux. В экземплярной форме диаграммы экземп ляры представляют реальные физические устройства или реальные эк земпляры сред выполнения, выполняющихся на этих устройствах. Имена элементов подчеркнуты, чтобы показать, что они отображают экземпляры узлов. Дескрипторная форма диаграмм развертывания хороша для модели рования типа физической архитектуры, а экземплярная форма – для моделирования фактического развертывания этой архитектуры на конкретном сайте. 1 или Hypertext Transfer Protocol. – Примеч. науч. ред. «device» WindowsPC «device» LinuxPC 0..* 0..* «http» узел ассоциация «execution environment» Apache «execution environment» Firefox Рис. 24.3. Дескрипторная форма диаграммы развертывания 24.4. Узлы 517 Согласно книге «The UML User Guide» [Booch 2], диаграммы развер тывания являются самой богатой стереотипами частью UML. Для сте реотипов можно придумать собственные пиктограммы, напоминаю щие реальное оборудование, и затем использовать эти символы на диа грамме развертывания. Такой подход упрощает восприятие диаграм мы. Здесь может помочь богатая библиотека изображений! Пример полностью визуализированной дескрипторной формы диаграммы раз вертывания приведен на рис. 24.5. экземпляр узла «http» «execution environment» :Firefox «device» JimsPC:WindowsPC «execution environment» :Firefox «device» IlasPC:WindowsPC «execution environment» :Apache «device» WebServer1:LinuxPC Рис. 24.4. Экземплярная форма диаграммы развертывания Принтер Ноутбук IBM AS/400 IBM RS/6000 Рис. 24.5. Визуализированная дескрипторная форма диаграммы развертывания 518 Глава 24. Развертывание 24.5. Артефакты Артефакт представляет описание реальной сущности, например, такой как файл. Артефакт представляет описание конкретной, реальной сущности, та кой как исходный файл BankAccount.java. Артефакты развертываются на узлах. Некоторые примеры артефактов: • исходные файлы; • исполняемые файлы; • сценарии; • таблицы баз данных; • документы; • результаты процесса разработки, например UML модель. Экземпляр артефакта представляет конкретный экземпляр конкретного артефакта. Экземпляр артефакта представляет определенный экземпляр кон кретного артефакта, например определенную копию файла BankAc count.java, развернутую на конкретном компьютере. Экземпляры арте фактов развертываются на экземплярах узлов. Артефакты могут представлять один или более компонентов. Артефакты могут обеспечивать физическое представление UML эле ментов любого типа. Обычно они представляют один или более компо нентов, как проиллюстрировано на рис. 24.6. Здесь показан артефакт librarySystem.jar, который представляет три компонента типа «white box» (учитывающих внутреннюю структуру) – Book, Library и Ticket. Ар тефакты помечены стереотипом « artifact». В верхнем правом углу арте факта может располагаться пиктограмма артефакта, как показано на рисунке. Здесь также проиллюстрирован тот факт, что артефакты мо гут зависеть от других артефактов. В данном случае артефакт librarySys tem.jar зависит от артефакта jdom.jar. Наряду с именем в спецификации каждого артефакта есть имя файла ( filename), указывающее физическое местоположение артефакта. На пример, filename могло бы определять URL, по которому находится оригинал артефакта. Имена файлов экземпляров артефактов указыва ют на физическое местоположение экземпляра. Рассмотрим JAR файл на рис. 24.6 более подробно. Создание этого файла осуществляется в два этапа: 24.5. Артефакты 519 1. Компилируются исходные Java файлы для классов Book, ISBN, Book Impl, Library, LibraryImpl, Ticket, TicketID и TicketImpl. 2. С помощью Java инструмента jar 1 из этих откомпилированных фай лов создается JAR файл. Так создается JAR файл, изображенный на рис. 24.7. Как видите, он содержит Java файлы классов для каждого класса и интерфейса систе мы. В нем также есть каталог META_INF, включающий файл MANIFEST.MF. Этот файл генерируется при помощи jar и описывает содержимое JAR. Рисунок 24.7 также иллюстрирует, как можно показать зависимости между артефактами и артефактами, вложенными в артефакты. Хотя с точки зрения UML моделирования рис. 24.7 абсолютно верен, он не отличается особой наглядностью, потому что все элементы здесь – артефакты. Расширение .class сообщает, что некоторые из артефактов представляют откомпилированные файлы классов Java, но понять, что META_INF – каталог, сложно. Это указывает на необходимость обо 1 Имеется в виду исполняемый файл jar (в Windows это jar.exe), поставляемый вместе с JDK. – Примеч. науч. ред. «component» Library «component» Book «artifact» librarySystem.jar BookImpl ISBN 1 1 LibraryImpl TicketImpl TicketID 1 1 Book Library Ticket «component» Ticket «artifact» jdom.jar пиктограмма артефакта «manifest» «manifest» «manifest» Рис. 24.6. Артефакт librarySystem.jar представляет три компонента: Book, Library и Ticket 520 Глава 24. Развертывание значать артефакты стереотипами, чтобы было четко видно, что каж дый из них представляет. UML предлагает небольшое число стандартных стереотипов артефактов, представляющих разные типы файлов. Они перечислены в табл. 24.1. Таблица 24.1 Стереотип_артефакта_Семантика'>Стереотип артефакта Семантика «file» Физический файл. «deployment spec» Описание деталей развертывания (например, web.xml в J2EE). «document» Универсальный файл, содержащий некоторую инфор мацию. «executable» Исполняемый программный файл. «library» Статическая или динамическая библиотека, такая как динамически подключаемая библиотека (DLL) или файл Java архива (JAR). «script» Сценарий, который может быть выполнен интерпрета тором. «source» Исходный файл, который может быть скомпилирован в исполняемый файл. «artifact» librarySystem.jar «artifact» BookImpl.class «artifact» LibraryImpl.class «artifact» TicketImpl.class «artifact» jdom.jar «artifact» Book.class «artifact» Library.class «artifact» Ticket.class «artifact» MANIFEST .MF «artifact» TicketID.class «artifact» ISBN.class «artifact» MET A_INF Рис. 24.7. JAR файл содержит Java файлы классов для каждого класса и интерфейса системы 24.5. Артефакты 521 Можно ожидать, что со временем будут разработаны различные UML профили для конкретных программных платформ, таких как J2EE (Java 2 Platform, Enterprise Edition) и Microsoft .NET. Это обеспечит более богатый набор стереотипов артефактов (и других элементов). Спецификация UML 2.0 [UML2S] предоставляет примеры профилей для J2EE и EJB, Microsoft COM, Microsoft .NET и CORBA (Common Object Request Broker Architecture – общая архитектура посредника запросов к объектам). В табл. 24.2 приведен пример профиля Java. Этого профиля недоста точно для моделирования приложений Java, поскольку в нем не хва тает стереотипов для файлов классов и каталогов. Мы расширяем этот профиль двумя новыми стереотипами, представленными в табл. 24.3. На рис. 24.8 расширенный Java профиль из спецификации UML при менен к нашей модели. Как видите, с использованием наглядных сте реотипов диаграмма стала намного более выразительной. Таблица 24.2 Таблица 24.3 Стереотип Применяется к Семантика «EJBEntityBean» компоненту Компонент сущность EJB. «EJBSessionBean» компоненту Сеансовый компонент EJB. «EJBMessageDrivenBean» компоненту Управляемый сообщениями компонент EJB. «EJBHome» интерфейсу «Домашний» интерфейс EJB. «EJBRemote» интерфейсу Удаленный интерфейс EJB. «EJBCreate» операции Операция создания EJB. «EJBBusiness» операции Операция, поддерживающая бизнес логику удаленного интерфейса EJB. «EJBSecurityRoleRef» ассоциации Ассоциация между EJB и поставщи ком, предоставляющим ссылку на роль в системе безопасности. «EJBRoleName» актеру Имя роли в системе безопасности. «EJBRoleNameRef» актеру Ссылка на роль в системе безопасности. «JavaSourceFile» артефакту Исходный файл Java. «JAR» артефакту Файл Java архива. «EJBQL» выражению Выражение на языке запросов EJB. Стереотип Применяется к Семантика «JavaClassFile» артефакту Файл класса Java (откомпилирован ный исходный файл Java). «directory» артефакту Каталог. 522 Глава 24. Развертывание 24.6. Развертывание Простая экземплярная форма диаграммы развертывания представле на на рис. 24.9. Данный пример взят из обучающего курса Java (www.java.sun.com). Это приложение преобразователя валют. На рис. 24.9 показан файл архива корпоративных приложений (Enterprise application Archive, EAR) Con verterApp.ear, развернутый в среде выполнения J2EE Server на узле server (сервер) типа WindowsPC. J2EE Server – это сервер приложений корпорации Sun, поставляемый как часть J2EE. EAR файлы – особый тип JAR файлов, в которых содержатся приложения J2EE. Развернутое сервер ное приложение используется клиентским приложением ConverterCli ent.jar, которое исполняется на узле client (клиент) типа WindowsPC. Спецификацию развертывания можно прикрепить к развернутому ар тефакту, как показано на рисунке. В ней содержится основная инфор мация о развертывании. В данном случае определены три вещи: • EnterpriseBeanClass (класс корпоративного компонента) – класс, со держащий логику компонента; • EnterpriseBeanName – имя корпоративного компонента, которое может применяться клиентом для организации доступа к компоненту; « JAR » librarySystem.jar « JavaClassFile » BookImpl.class «JavaClassFile» LibraryImpl.class «JavaClassFile» TicketImpl.class « JAR » jdom.jar «JavaClassFile» Book.class «JavaClassFile» Library.class «JavaClassFile» Ticket.class « file » MANIFEST .MF «JavaClassFile» TicketID.class «JavaClassFile» ISBN.class « directory » MET A_INF Рис. 24.8. К модели на рис. 24.7 применен расширенный Java профиль из спецификации UML 24.7. Что мы узнали 523 • EnterpriseBeanType (тип корпоративного компонента) – тип компонен та. В данном случае это не имеющий состояния сеансовый компо нент – компонент, используемый для простых транзакций; он не имеет состояний и не является сохраняемым. Развертывание EJB – намного более сложный процесс, чем мог бы предложить этот простой пример, и некоторые из его деталей даже за висят от среды выполнения. Однако цель моделирования в разверты вании – отражение основных моментов развертывания, поэтому пред ставленного дескриптора может быть вполне достаточно. 24.7. Что мы узнали Диаграммы развертывания позволяют моделировать распределение программной системы на физическом оборудовании. Мы узнали сле дующее: • Деятельность UP Реализация архитектуры состоит в определении важ ных с архитектурной точки зрения компонентов и проецировании их на физическое оборудование. • Диаграмма развертывания проецирует программную архитектуру на аппаратную архитектуру. «RMI» EnterpriseBeanClass : ConverterBean EnterpriseBeanName : ConverterBean EnterpriseBeanT ype : StatelessSession «device» client:WindowsPC «JAR» :ConverterClient.jar «execution environment» :J2EE Server «device» server:WindowsPC «deployment spec» :web.xml «JAR» :ConverterApp.ear Рис. 24.9. Экземплярная форма диаграммы развертывания для приложения преобразователя валют 524 Глава 24. Развертывание • В процессе проектирования можно создать «первое приближение» диаграммы развертывания, определяя узлы или экземпляры узлов и отношения. В процессе реализации это приближение дополняется компонентами или экземплярами компонентов. • Дескрипторная форма диаграммы развертывания может использо ваться для моделирования того, какие типы оборудования, про граммного обеспечения и соединений будут присутствовать в окон чательно развернутой системе. • Описывает полный набор возможных сценариев развертывания. • Показывает: • узлы – на каких типах оборудования выполняется система; • отношения – типы соединений между узлами; • компоненты – типы компонентов, развернутых на конкрет ных узлах. • Экземплярная форма диаграммы развертывания представляет кон кретное развертывание системы на определенных, идентифицируе мых частях оборудования. • Описывает один определенный вариант развертывания системы, возможно, на конкретном пользовательском сайте. • Показывает: • экземпляры узлов – конкретные части оборудования; • экземпляры отношений – конкретные отношения между эк земплярами узлов; • экземпляры компонентов – конкретные идентифицируемые части программного обеспечения, развернутые на экземпляре узла, например конкретная копия Microsoft Office с уникаль ным серийным номером. • Узел – представляет тип вычислительного ресурса. • «device» – тип физического устройства, такой как ПК или сервер Fire корпорации Sun. • «execution environment» – тип среды выполнения программного обеспечения, например веб сервер Apache. • Экземпляр узла – представляет конкретный вычислительный ре сурс. • Артефакт – представляет описание реальной сущности, такой как конкретный исполняемый файл. • Артефакты могут представлять один или более компонентов. • Экземпляр артефакта – представляет определенный экземпляр кон кретного артефакта, например определенную копию конкретного исполняемого файла, установленную на конкретном компьютере. VI Дополнительные материалы 25 Введение в OCL 25.1. План главы Сначала мы собирались дать очень краткое введение в OCL, в основном охватывающее информацию, необходимую для сертификации по UML. Однако чем больше мы знакомились с существующей литерату рой по OCL, тем более ощущалась необходимость в простом, но исчер пывающем описании языка, ориентированном именно на ОО аналити ка/проектировщика. Именно такое описание мы постарались предста вить в этой главе. Оно основывается на спецификации «Unified Model ing Language: OCL, version 2.0» [OCL1], но пока книга готовилась к изданию, в спецификацию могли быть внесены некоторые незначи тельные изменения. Как ОО аналитик или проектировщик вы, вероятно, не очень хорошо знакомы с OCL. Надеемся, что прочитав главу, вы получите достаточ но полное представление об OCL и сможете оценить те возможности, которые он предоставляет для подробного UML моделирования. Глава содержит довольно много материала, поэтому в ее план включе ны только основные темы (рис. 25.1). 25.2. Что такое объектный язык ограничений (OCL)? OCL может определять запросы, ограничения и операции запросов. OCL – язык, позволяющий вводить в UML модель дополнительную информацию. Это стандартное расширение UML, предоставляющее следующие возможности: 528 Глава 25. Введение в OCL Рис. 25.1. План главы изучаем OCL коллекции изучаем простые типы изучаем структурированные типы учимся добавлять инфиксные операторы учимся проходить по нескольким ассоциациям изучаем простую навигацию учимся проходить по ассоциациям определяем переменные определяем произ водные атрибуты определяем локаль ные переменные изучаем инварианты изучаем пред и постусловия определяем операции запроса инициализируем переменные учимся использовать OCL в конечных автоматах работаем с сообщениями работаем с классами ассоциациями работаем с квалифицированными ассоциациями работаем с унаследованными ассоциациями учимся использовать OCL в диаграммах взаимодействия учимся использовать OCL в диаграммах деятельности |