Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Инновационные подходы к визуализации и разработке с применением унифицированного языка моделирования (UML). Учебное пособие
.pdf
11
программного кода, проверка согласованности моделей, подключение
дополнительных модулей).
Рисунок 1.2 – Внешний вид главного меню программы
1.3.2 Стандартная панель инструментов
Стандартная панель инструментов располагается ниже главного меню
программы и имеет вид, представленный на рисунке 1.3. Некоторые из
инструментов недоступны (новый проект не имеет никаких элементов).
Стандартная панель инструментов обеспечивает быстрый доступ к тем
командам меню, которые выполняются разработчиками наиболее часто.
Рисунок 1.3 – Внешний вид стандартной панели инструментов
Пользователь может настроить внешний вид этой панели по своему
усмотрению. Для этого необходимо выбрать пункт меню
Tools -> Options (Инструменты -> Параметры) и открыть вкладку Toolbars
(Панели инструментов). Этим способом можно показать или скрыть различные
кнопки инструментов, а также изменить их размер.
1.3.3 Окно браузера
Окно браузера по умолчанию располагается в левой части рабочего
интерфейса под стандартной панелью инструментов (рисунок 1.4).
Браузер организует представления модели в виде иерархической структуры,
которая упрощает навигацию и позволяет отыскать любой элемент модели в
проекте. При этом любой элемент, который разработчик добавляет в модель,
сразу отображается в окне браузера. Соответственно, выбрав элемент в окне
браузера, можно его визуализировать в окне диаграммы или изменить его
спецификацию. Браузер позволяет также организовывать элементы модели в
пакеты и перемещать элементы между различными представлениями модели.
При желании окно браузера можно расположить в другом месте рабочего
интерфейса либо скрыть вовсе, используя для этого пункт меню View (Вид).
12
Можно также изменить размеры браузера, переместив мышью границу его
внешней рамки.
Рисунок 1.4 – Внешний вид браузера
1.3.4 Специальная панель инструментов
Специальная панель инструментов располагается между окном браузера и
окном диаграммы в средней части рабочего интерфейса. По умолчанию
предлагается панель инструментов для построения диаграммы классов модели
(рисунок 1.5).
Рисунок 1.5 – Внешний вид специальной панели инструментов для диаграммы
классов
Расположение специальной панели инструментов можно изменять,
переместив рамку панели в нужное место. Можно настраивать и состав панели,
добавляя или удаляя отдельные кнопки, соответствующие тем или иным
инструментам. Назначения кнопок можно узнать из всплывающих подсказок,
появляющихся после задержки указателя мыши над соответствующей кнопкой.
1.3.5 Окно диаграммы
Окно диаграммы является основной рабочей областью ее интерфейса, в
которой визуализируются различные представления модели проекта. По
умолчанию окно диаграммы располагается в правой части рабочего
интерфейса, однако его расположение и размеры также можно изменить. При
разработке нового проекта, если не был использован мастер проектов, окно
диаграммы представляет собой чистую область, не содержащую никаких
элементов модели (рисунок 1.6).
13
Рисунок 1.6 – Внешний вид окна диаграмм с различными видами
представлений модели
Название диаграммы, которая располагается в данном окне, указывается в
строке заголовка программы (самая верхняя строка программы) или, если окно
не развернуто во весь экран, в строке заголовка окна диаграммы. Одновременно
в окне диаграммы могут присутствовать несколько диаграмм, однако активной
может быть только одна из них. Например, на рисунке 1.6 активной является
диаграмма развертывания, хотя имеются и другие диаграммы. Переключение
между диаграммами можно осуществить выбором нужного представления на
стандартной панели инструментов либо через пункт меню Window (Окно). При
активизации отдельного вида диаграммы изменяется внешний вид специальной
панели инструментов, которая настраивается под конкретный вид диаграммы.
1.3.6 Окно документации
Окно документации по умолчанию может не присутствовать на экране. В
этом случае оно может быть активизировано через пункт меню View ->
Documentation (Вид->Документация), после чего появится ниже браузера
(рисунок 1.7).
Рисунок 1.7 – Внешний вид окна документации
Окно документации, как следует из его названия, предназначено для
документирования элементов представления модели. В него можно записывать
14
самую различную информацию, и что важно на русском языке. Эта
информация в последующем преобразуется в комментарии и никак не влияет на
логику выполнения программного кода.
В окне документации активизируется та информация, которая относится к
отдельному выделенному элементу диаграммы. При этом выделить элемент
можно либо в окне браузера, либо в окне диаграммы. При добавлении нового
элемента на диаграмму (например, класса) автоматически генерируется
документация к нему, которая является пустой (No documentation). В
последующем разработчик самостоятельно вносит необходимую
пояснительную информацию, которая запоминается и может быть изменена в
ходе работы над проектом.
Так же, как и для других окон рабочего интерфейса, можно изменять
размеры и положение окна документации.
1.3.7 Окно журнала
Окно журнала (Log) предназначено для автоматической записи различной
служебной информации, образующейся в ходе работы с программой. В
журнале фиксируется время и характер выполняемых разработчиком действий,
таких как обновление модели, настройка меню и панелей инструментов, а
также сообщений об ошибках, возникающих при генерации программного
кода.
Рисунок 1.8 – Внешний вид окна журнала
Окно журнала всегда присутствует на рабочем интерфейсе в области окна
диаграммы (рисунок 1.8). Однако оно может быть закрыто другими окнами с
диаграммами или быть свернутым. Активизировать окно журнала можно через
меню Window->Log (Окно->Журнал).
15
В этом случае оно изображается поверх других окон в правой области
рабочего интерфейса. Полностью удалить это окно нельзя, его можно только
минимизировать.
1.4 Принцип работы в Rational Rose
Исходным шагом разработки нового проекта является создание отдельных
моделей или представлений в контексте построения канонических диаграмм.
Для нового проекта можно воспользоваться мастером типовых проектов
(если он установлен в данной конфигурации). Мастер типовых проектов
доступен из меню File -> New (Файл -> Создать). Если мастер недоступен, то
появляется рабочий интерфейс программы с чистым окном диаграммы.
Если имеется готовый проект (файл с расширением mdl модель), то его
можно открыть для последующей модификации через меню File -> Open (Файл
-> Открыть). В этом случае программа загрузит существующий проект со всеми
имеющимися в нем диаграммами, спецификациями и документацией.
По окончании сеанса работы над проектом выполненную работу
необходимо сохранить в файле проекта с расширением mdl. Это можно сделать
через меню File -> Save (Файл -> Сохранить) или File -> Save As (Файл ->
Сохранить как). При этом вся информация о проекте, включая диаграммы и
спецификации элементов, будет сохранена в одном файле.
Как и другие программы, Rational Rose позволяет настраивать глобальные
параметры среды, такие как выбор шрифтов и цвета для представления
различных элементов модели. Настройка шрифтов производится через меню
Tools -> Options (Инструменты -> Параметры). Характерной особенностью
среды является возможность работы с символами кириллицы. Однако следует
заметить, что при спецификации элементов модели с последующей генерацией
текста программного кода нужно сразу записывать имена и свойства элементов
символами того языка, который поддерживается соответствующим языком
программирования.
16
Для изменения цвета линий необходимо воспользоваться пунктом меню
Edit -> Diagram Object Properties -> Line Color (Правка -> Свойства объекта
диаграммы -> Цвет линии). В этом случае предлагается специальная цветовая
палитра, на которой можно выбрать подходящий цвет для линий на
диаграммах.
Общий процесс работы над проектом заключается в добавлении на
диаграммы соответствующих графических элементов, установлении
отношений между этими элементами, их спецификации и документировании.
После проверки правильности модели и согласованности спецификаций ее
элементов можно сгенерировать текст программного кода на одном из
выбранных языков программирования. Конечно, этот текст можно доработать в
соответствующей среде программирования и получить исполнимые модули
программ, ориентированные на работу в определенной операционной среде и
вычислительной платформе.
Процесс добавления графических элементов на диаграммы аналогичен
реализованному в популярных средах визуального программирования. При
этом следует предостеречь от неосторожного добавления элементов на
диаграммы, поскольку каждый добавляемый элемент заносится в браузер.
Последующее удаление элемента с диаграммы автоматически не удаляет его из
браузера, и необходимо предпринять дополнительные меры для удаления
ненужного элемента из модели проекта.
1.5 Рабочие процессы RUP и диаграммы UML
Ни для кого не секрет, что создание программного обеспечения – это
сложный процесс, который, с одной стороны, имеет много общего с
творчеством, а с другой, – хотя и высокодоходный, но и высокозатратный
бизнес. Жестокая конкуренция на рынке вынуждает разработчиков вести поиск
более эффективных методов работы, путей создания программных систем в
еще более короткие сроки, с меньшими затратами и лучшим качеством.
17
Сложность программ постоянно увеличивается. Еще недавно программные
продукты могли быть созданы в обозримые сроки одиночками или, например, в
IT-отделе автоматизируемого предприятия [1].
Корпорация Rational Software (http://www.rational.com) выпустила на рынок
структурированную базу знаний под названием Rational Unified Process (RUP),
которая представляет собой набор исчерпывающих рекомендаций для создания
практически любых программных продуктов. Вобрав в себя опыт лучших
разработок, RUP подробно рассказывает, когда, кто и что должен делать в
проекте, чтобы в результате получить программную систему в установленные
сроки, с определенной функциональностью и в рамках отведенного бюджета.
Для реализации требований заказчика в установленные сроки
унифицированный процесс разделяется на фазы, которые состоят из итераций,
поэтому процесс еще называют итеративным и инкрементным. Каждая
итерация проходит цикл основных работ и подводит разработчиков к конечной
цели: созданию программной системы. В ходе итераций создаются
промежуточные артефакты, которые требуются для успешного завершения
проекта, и вариант программной системы, который реализует некоторый набор
функций, увеличивающийся от итерации к итерации. Фазы и основные потоки
работ процесса показаны на рисунке 1.9, там же даны примерные трудозатраты
работ по фазам [2, 3]. Нужно отметить, что на рисунке 1.9 показаны только
основные работы унифицированного процесса. Например, работы по
управлению деятельностью здесь не показаны, чтобы не загромождать
диаграмму.
Вся разработка ПО рассматривается в RUP как процесс создания
артефактов. Любой результат работы проекта, будь то исходные тексты,
объектные модули, документы, передаваемые пользователю, модели – это
подклассы всех артефактов проекта. Каждый член проектной группы создает
свои артефакты и несет за них ответственность. Программист создает
программу, руководитель проектный план, а аналитик модели системы.
18
RUP позволяет определить: когда, кому и какой артефакт необходимо создать,
доработать или использовать.
Рисунок 1.9 – Фазы и потоки работ RUP
Одним из интереснейших классов артефактов проекта являются модели,
которые позволяют разработчикам определять, визуализировать,
конструировать и документировать артефакты программных систем. Модели
позволяют рассмотреть будущую систему, ее объекты и их взаимодействие еще
до вкладывания значительных средств в разработку, позволяют увидеть ее
глазами будущих пользователей снаружи и разработчиков изнутри еще до
создания первой строки исходного кода. Большинство моделей представляются
UML диаграммами.
Диаграммы позволяют легче общаться членам проекта между собой, и, что
особенно ценно, вовлекают в процесс конечных пользователей системы.
Моделирование позволяет уменьшить риски проекта, поскольку
программистам всегда легче делать то, что ясно и понятно, чем идти к
неопределенному результату. Создание диаграмм аналогично созданию проекта
в строительстве: можно обойтись и без него, например, при строительстве сарая
на дачном участке, однако чем больше здание (в нашем случае программный
продукт), тем труднее это делать и неопределеннее конечный результат.
1.5.1 Определение требований
Унифицированный процесс – это процесс, управляемый прецедентами,
которые отражают сценарии взаимодействия пользователей. Фактически, это
19
взгляд пользователей на программную систему снаружи. Таким образом, одним
из важнейших этапов разработки, согласно RUP, будет этап определения
требований, который заключается в сборе всех возможных пожеланий к работе
системы, которые только могут прийти в голову пользователям и аналитикам.
Позднее эти данные должны быть систематизированы и структурированы, но
на данном этапе в ходе интервью с пользователями и изучения документов
аналитики должны собрать как можно больше требований к будущей системе,
что не так просто, как кажется на первый взгляд. Пользователи часто сами не
представляют, что они должны получить в конечном итоге. Для облегчения
этого процесса аналитики используют диаграммы прецедентов (рисунок 1.10).
Рисунок 1.10 – Пример диаграммы прецедентов
Диаграмма представляет собой отражение действующих лиц (актантов),
которые взаимодействуют с системой, и реакцию программных объектов на их
действия. Актантами могут быть как пользователи, так и внешние агенты,
которым необходимо передать или получить информацию. Значок варианта
использования отражает реакцию системы на внешнее воздействие и
показывает, что должно быть сделано для актанта.
Для детализации конкретного прецедента используется диаграмма
активности (Activity Diagram), пример которой дан на рисунке 1.11.
Простота диаграммы прецедентов позволяет аналитикам легко общаться с
заказчиками в процессе определения требований, выявлять ограничения,
налагаемые на систему и на выполнение отдельных требований, которые в
дальнейшем попадают в раздел нефункциональных требований, такие,
например, как время реакции системы.
20
Рисунок 1.11 – Пример диаграммы активности
Также диаграмма прецедентов может использоваться для создания
сценариев тестирования, поскольку все взаимодействие пользователей и
системы уже определено.
1.5.2 Анализ
После определения требований и контекста, в котором будет работать
система, наступает черед анализа полученных данных. В процессе анализа
создается аналитическая модель, которая подводит разработчиков к
архитектуре будущей системы. Аналитическая модель – это взгляд на систему
изнутри, в отличие от модели прецедентов, которая показывает, как система
будет выглядеть снаружи.
Эта модель позволяет понять, как система должна быть спроектирована,
какие в ней должны быть классы и как они должны взаимодействовать между
собой. Основное ее назначение определить направление реализации
функциональности, выявленной на этапе сбора требований и сделать набросок
архитектуры системы.
Для отображения модели анализа при помощи UML используется
диаграмма классов со стереотипами (образцами поведения) «граничный класс»,
«сущность», «управление», а для детализации используются диаграммы
сотрудничества (Collaboration) (рисунок 1.12). Стереотип «граничный класс»
отображает класс, который взаимодействует с внешними актантами,
«сущность» отображает классы, которые являются хранилищами данных, а
«управление» – классы, управляющие запросами к сущностям.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]