Александр Леоненков - Самоучитель UML
Ниже представлен пример диаграммы кооперации (рис. 12.17), которая была автоматически сгенерирована средой после построения диаграммы последовательности (см. рис. 12.15).
Рис. 12.17. Пример графического изображения диаграммы кооперации, соответствующей построенной ранее диаграмме последовательности
Как и для диаграммы последовательности, для диаграммы кооперации можно изменять порядок следования сообщений, добавлять потоки данных, определять устойчивость объектов на основе активизации соответствующих спецификаций.
12.9. Разработка диаграммы компонентов в среде Rational Rose
Диаграмма компонентов является частью физического представления модели и играет важную роль в процессе ООАП. Активизация диаграммы компонентов может быть выполнена одним из следующих способов:
• Щелкнуть на кнопке с изображением диаграммы компонентов на стандартной панели инструментов.
• Раскрыть компонентное представление в браузере (Component View) и дважды щелкнуть на пиктограмме Main (Главная).
• Через пункт меню Browse-»Component Diagram (Браузер-»Диаграмма компонентов).
После активизации диаграммы компонентов специальная панель инструментов приобретет следующий вид (рис. 12.18).
Рис. 12.18. Внешний вид специальной панели инструментов для диаграммы компонентов
Добавление и удаление элементов происходит аналогично, однако для каждого компонента можно определить различные детали, такие как стереотип, язык программирования, декларации, классы. Работа с этими деталями компонентов осуществляется через спецификацию компонента, доступную после вызова контекстного меню.
Ниже приводится пример графического изображения элементов диаграммы компонентов (рис. 12.19).
При работе с диаграммой компонентов можно создавать пакеты и компоненты, изменять их спецификацию и зависимости между различными элементами диаграммы. При установлении реализации классов на компоненте можно выделить класс в браузере и перетащить его на нужный компонент диаграммы.
Рис. 12.19. Пример графического изображения диаграммы компонентов в среде Rational Rose
12.10. Разработка диаграммы развертывания в среде 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 может быть использован не только для унификации представлений этих знаний, но что не менее важно – для их интеграции, направленной на повышение адекватности много-модельных представлений сложных систем.
