Разработка диаграммы развертывания в среде Rational Rose

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

Щелкнуть на кнопке с изображением диаграммы развертывания на стандартной панели инструментов.

Дважды щелкнуть на пиктограмме представления развертывания в браузере (Deployment View).

Через пункт меню Browse‑»Deployment Diagram (Браузер‑»Диаграмма развертывания).

После активизации диаграммы развертывания специальная панель инструментов приобретет следующий вид (рис. 12.20).

Рис. 12.20. Внешний вид специальной панели инструментов для диаграммы развертывания

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

Ниже приводится пример графического изображения диаграммы развертывания (рис. 12.21).

Рис. 12.21. Пример графического изображения диаграммы развертывания в среде Rational Rose

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

Общая последовательность действий, которые необходимо выполнить для этого, состоит из шести этапов:

Проверка модели независимо от выбора языка генерации кода.

Создание компонентов для реализации классов.

Отображение классов на компоненты.

Установка свойств генерации программного кода.

Выбор класса, компонента или пакета.

Генерация программного кода.

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

Заключение

В настоящее время полностью специфицирована и документирована версия 1.3 языка UML и продолжается дальнейшая работа по его развитию. Хотя уже анонсирована следующая версия языка UML – 1.4, на момент написания книги окончательная документация по этой версии еще не специфицирована. Возможно, по этой причине следующей версией станет UML 2.0, работу над которой планируется развернуть в 2001 году. Ход этой работы и ее состояние отражаются на официальном сайте OMG: http://www.omg.org/. Там же содержатся полные спецификации стандарта OMG‑UML, предоставленные для свободного доступа.

Другим источником информации по языку UML в Интернете является сайт компании Rational Software Corp.: http://www.rational.com/, в которой сосредоточены основные разработчики и со стороны которой осуществляется общая координация работы над очередными версиями языка. Эта компания также является разработчиком CASE‑средства Rational Rose 98/2000, в котором реализуются текущие дополнения языка UML.

Из отечественных ресурсов нельзя не упомянуть сайт компании «Интерфейс» – http://www.interface.ru/, где содержится информация по многим современным CASE‑средствам, рассматриваются их характеристики и возможности, а также особенности отдельных технологий ООАП.

Перспективы дальнейшего развития UML связаны со становлением и интенсивным развитием новой парадигмы объектно‑ориентированного анализа – компонентной разработки приложений (Component‑Based Development – CBD). В этой связи развернута работа над дополнительной спецификацией языка UML применительно к технологиям CORBA и СОМ+. Речь идет о разработке так называемых профилей, содержащих нотацию всех необходимых элементов для представления в языке UML компонентов соответствующих технологий. При этом интенсивно используется механизм расширения языка UML за счет добавления новых стереотипов, помеченных значений и ограничений.

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

В частности, для моделирования бизнес‑процессов могут быть использованы: применительно к подсистемам – стереотипы «organization unit» и «work unit», для классов – стереотипы «worker», «case worker», «internal worker». При этом, например, стереотип «worker» служит для обозначения класса, который представляет абстракцию человека, выполняющего определенную деятельность или работу в бизнес‑системе. Работник или сотрудник взаимодействует с другими сотрудниками подсистемы в процессе выполнения отдельных операций, образующих бизнес‑логику процесса.

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

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

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

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

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

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

Date: 2015-09-17; view: 709; Нарушение авторских прав