Главная > Методическое пособие


2.2. Общие принципы работы в среде Rational Rose

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

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

2.3. Представления Rational Rose

Модель Rose поддерживает четыре представления (views): представление Вариантов Использования, Логическое представление, представление Компонентов и представление Размещения. У каждого из них свои цели и своя аудитория.

2.3.1. Представление Вариантов использования

Это представление включает в себя всех действующих лиц, все варианты использования и их диаграм­мы для конкретной системы. Оно может также содержать некоторые диаграммы Последовательности и Кооперативные диаграммы. Представление Вариантов Использования — это взгляд на систему, не­зависимый от ее реализации. Основное внимание здесь уделяется представлению высокого уровня, отображающему, что система будет делать, а не как она будет делать это.

Представление Вариантов Использования содержит:

- Действующих лиц, представляющих собой внешние сущности, взаимодействую­щие с создаваемой системой.

- Варианты использования, являющиеся высокоуровневыми элементами функционально­сти, которую обеспечивает система.

- Документацию по вариантам использования, детализирующую происходящие в них про­цессы (потоки событий), включая обработку ошибок.

- Диаграммы Вариантов Использования, отображающие действующих лиц, варианты ис­пользования и взаимодействие между ними. Обычно у системы бывает несколько таких диаграмм, каждая из которых показывает подмножество действующих лиц и/или вари­антов использования (это характерно для сложных систем, когда система разбивается на подсистемы, для простых систем можно использовать одну главную диаграмму вариантов использования).

- Диаграммы Взаимодействия, отображающие объекты или классы, которые принимают участие в одном потоке событий варианта использования. Для каждого варианта исполь­зования можно создать множество диаграмм Взаимодействия. Это делается либо в пред­ставлении Вариантов Использования, либо в Логическом представлении системы. Как правило, не зависящие от языка программирования и реализации, диаграммы Взаимо­действия создают в представлении Вариантов Использования. Обычно такие диаграммы показывают взаимодействие объектов, а не классов. Диаграммы Взаимодействия, завися­щие от языка, обычно находятся в Логическом представлении системы. Они, как прави­ло, отображают классы, а не объекты.

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

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

В процессе работы над проектом все члены команды могут ознакомиться с этим представлением, чтобы достичь понимания системы на высоком уровне. Документация варианта использования опи­сывает соответствующий поток событий. С помощью этой информации специалисты по контролю качества смогут приступить к созданию тестовых программ для системы, а технические писатели — документации для пользователей. Аналитики и заказчики будут уверены, что учтены все требования. Разработчики поймут, какие высокоуровневые элементы системы предстоит создать, и как будет рабо­тать ее логика.

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

2.3.2. Логическое представление

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

Логическое представление содержит:

- Классы, являющиеся строительными блоками системы. Класс состоит из небольшого ко­личества данных (атрибутов) и некоторого поведения (операций), сгруппированных вместе.

- Диаграммы Классов, используемые для представления классов системы, их атрибутов, операций и связей друг с другом. Как правило, для описания системы применяется не­сколько диаграмм Классов, каждая из которых отображает некоторое подмножество всех классов системы.

- Диаграммы Взаимодействия, применяемые для отображения классов, участвующих в од­ном потоке событий варианта использования. Как упоминалось ранее, диаграммы Взаи­модействия создаются в представлении Вариантов Использования или в Логическом представлении. При этом, как правило, в первом случае на диаграммах изображают объ­екты, а во втором — классы системы.

- Диаграммы Состояний, описывающие динамику поведения объекта. Они включают в себя все состояния, в которых данный объект может существовать. Они также показыва­ют, как объект переходит из одного состояния в другое, в каком состоянии он находится сразу после создания и в каком — непосредственно перед уничтожением.

- Пакеты, являющиеся группами взаимосвязанных классов. Объединять классы в пакеты не обязательно, но настоятельно рекомендуется. Типичная система может содержать сотню или более классов, и объединение их в пакеты помогает уменьшить сложность мо­дели. Для понимания общей картины системы достаточно взглянуть на ее пакеты. Чтобы изучить систему на более детальном уровне, приходится углубляться в пакеты и исследо­вать классы, находящиеся внутри.

Часто разработка Логического представления осуществляется в два этапа. Сначала определяются классы анализа (analysis classes). Они не зависят от языка программирования.

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

Рис.1. Пиктограммы классов анализа

Классы анализа могут появляться также на диаграммах Взаимодействия в представлении Вариан­тов Использования. После определения всех классов анализа каждый из них может быть преобразо­ван в класс проекта (design class). Класс проекта уже содержит специфические для данного языка детали. Например, можно представить себе класс анализа, отвечающий за обмен информацией с дру­гой системой. Нас пока не интересует, на каком языке он будет написан, мы уделяем внимание только его данным и поведению. Но преобразуя его в класс проекта, нам придется коснуться специфических для языка деталей. Причем отсутствует строгое соответст­вие между классами того и другого типа. Классы проекта изображают на диаграммах Взаимодействия Логического представления системы.

В этом представлении основное внимание уделяется логической структуре системы. Мы изучаем данные и поведение системы, определяем ее составные части и исследуем взаимодействие между ними. Одной из ключевых особенностей здесь является возможность повторного использования (re­use). Тщательно соотнося данные и поведение классов, группируя классы вместе и исследуя взаимо­действие между классами и пакетами, можно определить, какие из них допускают повторное использование. Завершая новые и новые проекты, вы будете постепенно увеличивать вашу библиоте­ку повторно используемых классов и пакетов. В результате выполнение будущих проектов будет все более и более становиться процессом сборки целого из имеющихся у вас составных частей, а не раз­работки "с чистого листа".

Почти все участники команды должны изучить Логическое представление системы, однако более всего оно полезно для разработчиков и архитекторов. Взглянув на классы и их диаграммы, аналитики смогут убедиться, что все бизнес-требования будут реализованы в коде. Изучая классы, пакеты и диа­граммы Классов, специалисты по контролю качества поймут, из каких элементов состоит система, и какие нуждаются в тестировании, а с помощью диаграмм Состояний увидят, как должны вести себя конкретные классы. Менеджер проекта из тех же элементов представления сможет уяснить, хорошо ли структурирована система, а также получить оценку степени ее сложности.

Однако больше всего этим представлением пользуются разработчики и архитекторы. Первые вы­ясняют, какие классы надо создавать, а также какие данные и поведение должен иметь каждый класс. Для вторых важнее всего структура системы в целом. Их задача — добиться того, чтобы архитектура системы была, стабильна, но в то же время гибка настолько, чтобы адаптироваться к изменениям в требованиях. Другая задача — рассмотреть возможность повторного использования.

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

2.3.3. Представление Компонентов

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

В среде Rose компоненты и диаграммы Компонентов показывают в представлении Компонентов. Представление Компонентов системы отображает связи между модулями кода.

Представление Компонентов содержит:

- Компоненты, являющиеся физическими модулями кода.

- Диаграммы Компонентов, отображающие компоненты и их связи. Связи между компо­нентами системы позволяют понять зависимости, возникающие при компиляции. Зная эти зависимости, можно установить порядок компиляции компонентов.

- Пакеты, являющиеся группами связанных компонентов. Как и в случае классов, повтор­ное использование является одним из мотивов объединения компонентов в пакеты. Группу связанных компонентов системы можно использовать в других приложениях при условии, что связи между этой и другими группами тщательно отслеживаются.

Представление Компонентов более всего используется теми участниками проекта, кто отвечает за управление кодированием, компиляцию и размещение приложения. Часть компонентов — это биб­лиотеки кода. Остальные — динамические компоненты, такие как, исполняемые файлы и файлы ди­намических библиотек (.DLL). С помощью этого представления разработчики могут понять, какие библиотеки кода были созданы и какие классы содержатся в каждой из них.

2.3.4. Представление Размещения

Представление Размещения соответствует физическому размещению системы, которое может отли­чаться от ее логической архитектуры.

Например, система может иметь трехуровневую логическую архитектуру: интерфейс логически отделен от бизнес-логики, а она, в свою очередь, отделена от базы данных. Однако размещение систе­мы может быть и двухуровневым: интерфейс находится на одном компьютере, а остальные две час­ти — на другом.

Представление Размещения отражает и такие проблемы, как отказоустойчивость системы, шири­на полосы пропускания сети, восстановление после сбоев и время отклика.

В представление Размещения входят:

- Процессы, которые являются потоками (threads), исполняемыми в отведенной для них области памяти.

- Процессоры, т.е. компьютеры, способные обрабатывать данные. Любой процесс выпол­няется на одном или нескольких процессорах.

- Устройства, т.е. аппаратура, не способная обрабатывать данные. К числу таких устройств относятся, например, терминалы ввода-вывода и принтеры.

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

Из представления Размещения может извлечь пользу вся работающая над проектом команда, так как оно позволяет понять физическое размещение системы. Основными ее пользователями, однако, являются те участники проекта, которые отвечают за распределение приложения.

2.4. Диаграммы представления вариантов использования

2.4.1. Диаграммы Вариантов Использования

Диаграмма Вариантов Использования содержит некоторые варианты использования системы, некото­рых действующих лиц и связи между ними. Вариант использования (use case) — это описание функцио­нальности системы на "высоком уровне". Действующее лицо (actor) — это все, что взаимодействует с системой.

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

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

2.4.1.1. Работа с вариантами использования

В
ариант использования иллюстрирует, как можно использовать систему. Например, система Контроля исполнения поручений (КИП) предоставляет пользователю некоторый базовый на­бор функциональных возможностей. Она позволяет принимать новое поручение на контроль, рассылать напоминания, снимать поручение с контроля, каждая из них — это самостоятельный вариант использования. На языке UML вариант использования “Принять новое поручение” изображают, как показано на рис.2:

Принять новое поручение

Рис.2. Пример Варианта Использования

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

Конкретная цель диаграмм Вариантов Использования — документирование вариантов использова­ния (все входящее в сферу применения системы), действующих лиц (все вне этой сферы) и связей между ними. Разрабатывая диаграммы Вариантов Использования, старайтесь придерживаться следу­ющих правил:

- Не моделируйте связи между действующими лицами. По определению действующие лица нахо­дятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции. Для изучения коммуникации между действующими лицами применяется диа­грамма потоков работ (workflow diagram).

- Не соединяйте стрелкой непосредственно два варианта использования (кроме случаев связей использования и расширения, рассматриваемых ниже). Диаграммы данного типа описывают только, какие варианты использования доступны системе, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяются диаграммы Деятельностей.

- Каждый вариант использования должен быть инициирован действующим лицом. Это означа­ет, что всегда должна быть стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования. Исключением являются рассматриваемые далее связи использова­ния и расширения.

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

Для того чтобы обнаружить варианты испо­льзования. Необходимо внимательно прочитать документацию заказчика. Часто помогает также рас­смотрение области использования системы на высоком уровне и документов концептуального характера. Учтите мнение каждого из заинтересованных лиц проекта. Подумайте, чего они ожидают от готового продукта. Каждому заинтересованному лицу можно задать следующие вопросы:

- Что он хочет делать с системой?

- Будет ли он с ее помощью работать с информацией (вводить, получать, обновлять, удалять)?

- Нужно ли будет информировать систему о каких-либо внешних событиях?

- Должна ли система в свою очередь информировать пользователя о каких-либо изменениях или событиях?

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

Для того чтобы убедиться, что вы обнаружили все варианты использования необходимо ответить на вопросы:

- Присутствует ли каждое функциональное требование хотя бы в одном варианте использования? Если требование не нашло отражение в варианте использования, оно не будет реализовано.

- Учтено ли, как с системой будет работать каждое заинтересованное лицо?

- Какую информацию будет передавать системе каждое заинтересованное лицо?

- Какую информацию будет получать от системы каждое заинтересованное лицо?

- Учтены ли проблемы, связанные с эксплуатацией? Кто-то должен будет запускать готовую сис­тему и выключать ее.

- Учтены ли все внешние системы, с которыми будет взаимодействовать данная?

- Какой информацией каждая внешняя система будет обмениваться с данной?

2.4.1.2. Документирование потока событий

Варианты использования начинают описывать, что должна будет делать ваша система. Но чтобы фак­тически разработать систему, потребуются более конкретные детали. Они определяются в документе, называемом "потоком событий" (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подроб­но описывает, что будут делать пользователи системы и что — сама система.

Поток событий также не должен зависеть от реализации. Составляя этот документ, представьте себе, что создается автоматизированная система. Ваша цель — описать, что будет де­лать система, а не как она будет это делать.

Конкретные детали вариантов использования отражаются в основном и в альтернативных потоках со­бытий. Поток событий поэтапно описывает, что должно происходить во время выполнения заложен­ной в варианты использования функциональности. Поток событий уделяет внимание тому, что (а не как) будет делать система, причем описывает это с точки зрения пользователя. Первичный и альтер­нативный потоки событий содержат:

- Описание того, каким образом запускается вариант использования

- Различные пути выполнения варианта использования

- Нормальный, или основной, поток событий варианта использования

- Отклонения от основного потока событий (так называемые альтернативные потоки)

- Потоки ошибок

- Описание того, каким образом завершается вариант использования

2.4.1.3. Работа с действующими лицами

Действующее лицо (actor) — это то, что взаимодействует с создаваемой системой. Если варианты исполь­зования описывают все, что происходит внутри области действия системы, действующие лица опре­деляют все, что находится вне ее. На языке UML действующие лица представляют в виде фигур (рис. 3).


Рис. 3. Пример актёра

Действующие лица делятся на три основных типа: пользователи системы, другие системы, взаимо­действующие с данной, и время.

Первый тип действующих лиц — это физические личности. Они наиболее типичны и имеются практически в каждой системе. В системе Стол заказов к этому типу относятся оператор и клиент.

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

2.4.1.4. Работа со связями

Связи коммуникации

Связь коммуникации (communicates relationship) — это связь между вариантом использования и действующим лицом. На языке UML связь коммуникации изображают в виде стрелки. Направление стрелки показывает, кто инициирует коммуникацию. Каждый вариант использования должен быть инициирован действующим лицом; исключения составляют лишь варианты использования в связях использования и расширения.

Связь использования

Связь использования (uses relationship) позволяет одному варианту использования задействовать функциональность другого. С помощью таких связей обычно моделируют многократно применяемую функциональность, встречающуюся в двух или более вариантах использования. Например, в системе КИП варианты использования “Распечатать поручение или группу поручений”, “Редактировать поручение ” должны выделять цветом поручения, у которых подходит срок исполнения.

Для этого заведём один вариант использования “Выделить поручения”

Когда какому-нибудь варианту использования потребуется выполнить эти действия, он сможет воспользоваться функциональностью созданного варианта использования " Выделить поручения ".

Связь использования изображается в UML с помощью стрелок и слова «использование» (uses), как показано на рис. 4.

Р
ис.4. Связь использования

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

Связь использования предполагает, что один вариант использования всегда применяет функцио­нальные возможности другого. Напротив, связи расширения (extends relationships) позволяют варианту использования толь­ко при необходимости применять функциональные возможности другого.

Связь расширения

Связь расширения (extends relationship) позволяет варианту использования только при необходимости применять функциональные возможности, предоставляемые другим вариантом использования. Она напоминает связь использования. В обоих типах отношений некоторая общая функциональность выделяется в отдельный Вариант Использования.

На языке UML связи расширения изображают в виде стрелки со словом «расширение» (extends), как показано на рис.5.

Р
ис.5. Связь расширения

В нашем примере вариант использования "Снять поручение с контроля" иногда применяет функциональные воз­можности, предоставляемые вариантом использования "Снять невыполненное поручение с контроля".

Предоставляющий дополнительные возможности вариант использования "Снять не выполненное поручение с контроля" является абстрактным. Вариант использования "Снять поручение с контроля" — конкретный.

2.4.1.5. Работа с пакетами

На языке UML такие элементы, как действующие лица, варианты использования, классы и компонен­ты, можно сгруппировать в пакеты (packages). В частности, в представлении Вариантов Использова­ния можно сгруппировать в пакеты варианты использования и действующих лиц.

Т
ак изучив предметную область можно выявить, что в КИП необходимо реализовать три типа функций. Можно представить группы функций в виде пакетов: ”Поддержка справочников”, ”Оперативная работа с поручениями” и “Формирование аналитической информации” (см. рис. 6).

Рис.6. Главная диаграмма вариантов использования

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

2.4.1.6. Работа с примечаниями

При работе над диаграммой имеет смысл связывать примечания (notes) с действующими лицами и ва­риантами использования. Например, иногда нужно пояснить, почему конкретное действующее лицо взаимодействует с конкретным вариантом использования, почему вариант использования участвует в связях использования или расширения или почему одно действующее лицо наследуется от другого. До­бавление примечаний в Rose выполняется с помощью кнопки Note (Примечание) панели инструмен­тов.

На диаграмму можно поместить примечания двух типов: собственно примечания (notes) и текстовую область (text box). В общем случае, примечания позволяют добавить комментарий к какому-то одному элементу диаграммы, а текстовая область содержит сведения, общие для всей диаграммы, например ее имя.



Скачать документ

Похожие документы:

  1. Рабочая программа дисциплины теоретические основы автоматизированного управления

    Программа
    ... ПРОГРАММА дисциплины ТЕОРЕТИЧЕСКИЕ ОСНОВЫ АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ индекс по учебному плану – СД.01 Рекомендовано Методическим Советом ... ERP 2005 и QPR7. Наименования лабораторных работ с указанием разделов дисциплины, к которым они относятся, ...
  2. Методическое пособие по дисциплине «операционные системы» и указания по выполнению лабораторных работ

    Методическое пособие
    ... технологии» Методическое пособие по дисциплине «Операционные системы» и указания по выполнению лабораторных работ Направление 230100 «Информатика и вычислительная техника» Специальность 230102 «Автоматизированные ...
  3. Методические указания по выполнению лабораторных работ по дисциплине «метрология стандартизация и сертификация»

    Методические указания
    ... технологии» Методические указания по выполнению лабораторных работ по дисциплине «Метрология, стандартизация и сертификация» Специальность 230102 «Автоматизированные системы обработки информации и управления» Составитель ...
  4. Методические указания к выполнению контрольной работы по всс и тк

    Методические указания
    ... , Учебники, Лабораторные работы =>файл Методические указания для выполнения лабораторных работ). 2. Выбрать вариант по последней цифре номера ... пособия Е.В. Молнина. Основы построения и функционирования вычислительных машин» для изучения дисциплины ...
  5. Методические указания по выполнению лабораторных работ по дисциплине «компьютерная графика»

    Методические указания
    ... технологии» Методические указания по выполнению лабораторных работ по дисциплине «Компьютерная графика» Направление 230100 «Информатика и вычислительная техника» Специальность 230102 «Автоматизированные ...

Другие похожие документы..