Министерство образования и науки Российской Федерации

БЕЛОРУССКО-РОССИЙСКИЙ УНИВЕРСИТЕТ

Кафедра «Автоматизированные системы управления»

С.К. Крутолевич

Э.И. Ясюкович
«ПРОЕКТИРОВАНИЕ АСОИУ»

Лабораторный практикум

"Автоматизированные системы обработки информации"

Могилев 2009

Данный лабораторный практикум содержит описание 10 лабораторных работ, выполнение которых закрепляет материал, изложенный в курсе «Проектирование АСОИУ»

Для выполнения лабораторных работ необходимо согласовать с преподавателем тему АСОИ, для индивидуальной разработки.

Студенту необходимо, используя данный материал как основу, и разработать диаграммы своей АСОИ.

При запуске Enterprise Architect первое, что отображается это стартовая страница.

Рисунок 1.1 – Стартовая страница Enterprise Architect

Эта страница предоставляет следующие возможности:

Search— поиск объектов в Enterprise Architect. Введите имя объекта в текстовое поле и нажмите кнопку […].

Getting Started открывает Tasks Pain. Отображает полезные темы и руководства для различных областей деятельности в Enterprise Architect.

Online Resources & Tutorials открывает страницу веб-сайта компании Sparx Systems, который предоставляет доступ к широкому кругу уроков по языку UML, демонстраций, примеров, надстроек и обсуждений.

Configure Options отображает диалоговое окно Options, которое позволяет определить, каким образом Enterprise Architect отображает и обрабатывает информацию.

Open a Project File отображает диалоговое окно Open Project, которое используется для открытия существующего проекта.

Create a New Project позволяет сохранить новый проект.

Copy a Base Project позволяет копировать базовый проект.

Connect to Server — служит для выбора имени источника данных для подключения.

Браузер проекта (Project Browser) позволяет перемещаться по пространству проекта Enterprise Architect. В нем отображаются пакеты, диаграммы, элементы и их свойства. Можно перетаскивать элементы из папки в папку или из браузера прямо на диаграмму.

Рисунок 1.2 Браузер проекта

Браузер проекта служит для управления и представления всех элементов в модели.

Браузер проекта можно разделить на представления, каждое из которых содержит диаграммы, пакеты и другие элементы:

Представление вариантов использования включает модели вариантов использования и бизнес процессов.

Динамическое представление включает диаграммы состояний, деятельности и последовательности. Логическое представление включает модель классов.

Представление компонентов – это представление системных компонентов (исполняемые, DDL и другие компоненты).

Представление размещения – физическая модель, которая показывает, какие использованы технические средства ЭВМ и какое программное обеспечение установлено.

Панель инструментов Enterprise Architect представляется как панель с иконками, которые используются для создания элементов и связей между ними. К тому же родственные элементы и связи организованы в страницы. Каждая страница содержит элементы и связи, используемые в конкретном типе диаграммы.

Рисунок 1.3 – Панель инструментов для диаграммы классов

Главное меню Enterprise Architect обеспечивает управляемый мышью доступ ко многим функциям, связанным с жизненным циклом проекта наряду с функциями администрирования.

Рисунок 1.4 – Главное меню Enterprise Architect

Меню инструментов (Tools Menu) обеспечивает доступ к различным настройкам, общим для генерации кода, управления ЕАР. файлами, настройки правописания, внешних ресурсов, настройки таких функций как управление ярлыками.

Рисунок 1.5 – Меню инструментов (Tools Menu)

В меню инструментов наибольший интерес представляет пункт Options. Здесь находятся опции настройки Enterprise Architect для отображения и работы с моделями и элементами модели. Основные режимы представлены в таблице 1.1

Таблица 1.1 – Назначение вкладок пункта меню Options

Рисунок 1.6 – Вкладка С++ Specifications

Освоить приемы работы в среде Enterprise Architect.

Содержание отчета:

Краткое описание основных режимов работы Enterprise Architect.

Вопросы для защиты

Перечислить основные диаграммы для моделирования АСОИ.

Перечислить основные элементы экрана.

Дать характеристику Браузеру.

Дать характеристику Окну диаграмм.

Дать характеристику четырем представлениям модели.

Лабораторная .работа № 2

Анализ предметной области

Цель работы. описание основных требований к АСОИ. Формирования глоссария проекта.
1. Теоретический материал

Анализ предметной области Система регистрации для ВУЗа

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

Из-за недостатка средств университет не в состоянии заменить сразу всю существующую систему. Остается функционировать в прежнем виде база данных, содержащая всю информацию о курсах (каталог курсов). Эта база данных поддерживается реляционной СУБД. Новая система будет работать с существующей БД в режиме доступа, без обновления.

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

Новая система должна позволять студентам выбирать 4 курса в предстоящем семестре. Дополнительно каждый студент может указать 2 альтернативных курса на тот случай, если какой-либо из выбранных им курсов окажется уже заполненным или отмененным. На каждый курс может записаться не более 10 и не менее 3 студентов (если менее 3, то курс будет отменен). В каждом семестре существует период времени, когда студенты могут изменить свои планы. В это время студенты должны иметь доступ к системе, чтобы добавить или удалить выбранные курсы. После того, как процесс регистрации некоторого студента завершен, система регистрации направляет информацию в расчетную систему, чтобы студент мог внести плату за семестр. Если курс окажется заполненным в процессе регистрации, студент должен быть извещен об этом до окончательного формирования его личного учебного плана.

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

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

Составление глоссария проекта

Глоссарий предназначен для описания терминологии предметной области. Он может быть использован как неформальный словарь данных системы.

Таблица 2.1 – Глоссарий проекта

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

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

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

Удобство использования: пользовательский интерфейс должен быть совместимым с Windows XP.

Надежность: система должна быть в работоспособном состоянии 24 часа в день 7 дней в неделю, время простоя – не более 10%.

Производительность: система должна поддерживать до 2000 одновременно работающих с центральной базой данных пользователей, и до 500 пользователей, одновременно работающих с локальными серверами.

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

Проектные ограничения: система должна быть интегрирована с существующей системой каталога курсов, функционирующей на основе реляционной СУБД.

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

Действующие лица:

Student (Студент) – записывается на курсы;

Professor (Профессор) – выбирает курсы для преподавания;

Registrar (Регистратор) – формирует учебный план и каталог курсов, ведет все данные о курсах, профессорах и студентах;

Billing System (Расчетная система) – получает от данной системы информацию по оплате за курсы;

Course Catalog (Каталог курсов) – передает в систему информацию из каталога курсов, предлагаемых университетом.

Цель работы. Изучение технологии формирования диаграммы вариантов использования.

Чтобы поместить действующее лицо в браузер:

Щелкните левой кнопкой мыши на панели инструментов Toolbox по кнопке Аctоr.

Щелкните по рабочей области диаграммы, в появившемся окне введите имя актера, выберите стереотип.

В браузере появится новое действующее лицо. Слева от его имени вы увидите пиктограмму действующего лица UML.

После создания действующих лиц сохраните модель под именем coursereg(analysis) с помощью пункта меню File > Save Project As.

Варианты использования.

Исходя из потребностей действующих лиц, выделяются следующие варианты использования:

Login (Войти в систему);

Register for Courses (Зарегистрироваться на курсы);

View Report Card (Просмотреть табель успеваемости);

Select Courses to Teach (Выбрать курсы для преподавания);

Submit Grades (Проставить оценки);

Maintain Professor Information (Вести информацию о профессорах);

Maintain Student Information (Вести информацию о студентах);

Close Registration (Закрыть регистрацию).

Чтобы поместить вариант использования в браузер:

Щелкните левой кнопкой мыши на панели инструментов Toolbox по кнопке Use Case.

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

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

Диаграмма вариантов использования. Создайте диаграмму вариантов использования для системы регистрации. Требуемые для этого действия подробно перечислены далее. Готовая диаграмма вариантов использования должна выглядеть как на рисунке 3.1.

Рисунок 3.1 – Диаграмма вариантов использования для системы регистрации

В среде Enterprise Architect диаграммы вариантов использования создаются в представлении вариантов использования. Главная диаграмма предлагается по умолчанию. Для моделирования системы можно затем разработать столько дополнительных диаграмм, сколько необходимо.

Чтобы получить доступ к главной диаграмме вариантов использования:

Рядом с представлением вариантов использования в браузере щелкните на значке « + », это приведет к открытию данного представления.

Дважды щелкните на главной диаграмме, чтобы открыть её.

Для создания новой диаграммы вариантов использования:

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

Из всплывающего меню выберите пункт Add > Add Diagram.

Выделив новую диаграмму, введите ее имя.

Дважды щелкните на названии этой диаграммы в браузере, чтобы открыть ее.

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

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

Чтобы поместить действующее лицо или вариант использования на диаграмму, перетащите его мышью из браузера на диаграмму вариантов использования.

Наличие общего варианта использования Login для трех действующих лиц позволяет обобщить их поведение и ввести новое действующее лицо Any User. Модифицированная диаграмма вариантов использования показана на рисунке 3.2.

Рисунок 3.2 – Модифицированная диаграмма вариантов использования

Щелкните правой кнопкой мыши по варианту использования «Register for Courses».

Выберите Add > Note, введите следующее описание к этому варианту использования: «This use case allows a student to register for courses in the current semester» (Этот вариант использования дает студенту возможность зарегистрироваться на курсы в текущем семестре).

Описание основных и альтернативных потоков событий.

Создайте с помощью MS Word три текстовых файла с описаниями вариантов использования Login (Войти в систему), Register for Courses (Зарегистрироваться на курсы) и Close Registration (Закрыть регистрацию).

Вариант использования Login.

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

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

Система запрашивает имя пользователя и пароль.

Пользователь вводит имя и пароль.

Система проверяет имя и пароль, после чего открывается доступ в систему.

Вариант использования Register for Courses.

Система запрашивает требуемое действие (создать график, обновить график, удалить график).

Когда студент указывает действие, выполняется один из подчиненных потоков (создать, обновить, удалить или принять график).

Создать график:

Система выполняет поиск в каталоге курсов доступных конкретных курсов и выводит их список.

Студент выбирает из списка 4 основных курса и 2 альтернативных курса.

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

Выполняется подчиненный поток «Принять график».

Обновить график:

Система выводит текущий график студента.

Система выполняет поиск в каталоге курсов доступных конкретных курсов и выводит их список.

Студент может обновить свой выбор курсов, удаляя или добавляя конкретные курсы.

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

Выполняется подчиненный поток «Принять график».

Удалить график:

Система выводит текущий график студента.

Система запрашивает у студента подтверждения удаления графика.

Студент подтверждает удаление.

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

Принять график.

Для каждого выбранного, но еще не «зафиксированного» конкретного курса в графике система проверяет выполнение студентом предварительных требований (прохождение определенных курсов), факт открытия конкретного курса и отсутствие конфликтов графика. Затем система добавляет студента в список выбранного конкретного курса. Курс фиксируется в графике и график сохраняется в системе.

Альтернативные потоки. Сохранить график.

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

«Незафиксированные» конкретные курсы помечаются в графике
как «выбранные».

График сохраняется в системе.

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

График не найден. Если во время выполнения подчиненных потоков «Обновить график» или «Удалить график» система не может найти график студента, то выдается сообщение об ошибке. После того, как студент подтвердит это сообщение, основной поток начнется с начала.

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

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

Удаление отменено. Если во время выполнения подчиненного потока «Удалить график» студент решит не удалять его, удаление отменяется, и основной поток начнется с начала.

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

Постусловия. Если вариант использования завершится успешно, график студента будет создан, обновлен или удален. В противном случае состояние системы не изменится.

Вариант использования Close Registration.

Система проверяет состояние процесса регистрации. Если регистрация еще выполняется, выдается сообщение и вариант использования завершается.

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

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

Система закрывает все конкретные курсы. Если в каком-либо конкретном курсе оказывается менее трех студентов (с учетом добавлений, сделанных в пункте 3), система отменяет его и исключает из каждого содержащего его графика.

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

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

Щелкните правой кнопкой мыши на варианте использования.

В открывшемся меню выберите пункт Properties.

Перейдите на вкладку Files.

Укажите путь к ранее созданному файлу(File Path) и нажмите на кнопку Save, чтобы прикрепить файл к варианту использования.

Нажмите кнопку Launch, чтобы открыть прикрепленный файл.

Выделите элемент на диаграмме.

Нажмите на клавишу Delete или нажмите сочетание клавиш CTRL+ D.

Обратите внимания, что, хотя элемент и удален с диаграммы, он остался в браузере и на других диаграммах системы.

Чтобы удалить элемент из модели:

Выделите элемент на диаграмме.

Выберите пункт меню Delete.
2. Практическое задание

Разработать диаграммы вариантов использования по индивидуальному заданию.

Содержание отчета.

1. Краткое описание основных элементов диаграммы.

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

3. Описание потока событий

Цель диаграммы

Дать определение терминам: «Вариант использования», «Действующее лицо».

Виды связей между вариантами использования и действующими лицами

Разработка диаграммы классов

Принятие соглашений по моделированию включает: используемые диаграммы и элементы модели; правила их применения; соглашения по именованию элементов; организация модели (пакеты).

Пример соглашений моделирования:

Имена вариантов использования должны быть короткими глагольными фразами. Для каждого варианта использования должен быть создан пакет Use-Case Realization, включающий:

a) по крайней мере одну реализацию варианта использования;

б) диаграмму «View Of Participating Classes» (VOPC).

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

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

Имена атрибутов и операций должны начинаться со строчной буквы.

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

Реализация варианта использования (Use-Case Realization) описывает реализацию конкретного варианта использования в терминах взаимодействующих объектов и представляется с помощью набора диаграмм (диаграмм классов, реализующих вариант использования, и диаграмм взаимодействия (диаграмм последовательности), отражающих взаимодействие объектов в процессе реализации варианта использования).

Рисунок 4.1 – Реализация варианта использования

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

Рисунок 4.2 – Классы анализа системы регистрации

Структура логического представления браузера должна иметь следующий вид:

Рисунок 4.3 – Структура логического представления

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

В открывшемся меню выберите пункт Add > Add Package.

Назовите новый пакет Design Model.

Создайте аналогичным образом пакеты Use-Case Realizations, Use-Case Realization – Close Registration, Use-Case Realization – Login и Use-Case Realization – Register for Courses.

В каждом из пакетов типа Use-Case Realization создайте соответствующие кооперации Close Registration, Login и Register for Courses (каждая кооперация представляет собой вариант использования со стереотипом «use-case realization», который задается в спецификации варианта использования).

Создайте в пакете Use-Case Realizations новую диаграмму вариантов использования с названием Traceabilities и постройте ее в соответствии с рисунком 4.4.

Рисунок 4.4 – Диаграмма Traceabilities

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

Граничные классы (Boundary) – служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо – вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса – кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).

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

Управляющие классы (Control) – обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, обработчик ошибок.

Пример набора классов, участвующих в реализации варианта использования Register for Courses, приведен на рисунке 4.5.

Рисунок 4.5 – Классы, участвующие в реализации варианта использования Register for Courses

Щелкните правой кнопкой мыши на пакете Design Model.

Выберите в открывшемся меню пункт Add > Add Element, выберите тип Class.

Введите имя RegisterForCoursesForm.

В открывшемся окне в поле стереотипа выберите Boundary и нажмите на кнопку ОК.

Создайте аналогичным образом классы CourseCatalogSystem со стереотипом Boundary и RegistrationController со стереотипом Control.

Назначьте классам Schedule, CourseOffering и Student стереотип Entity.

Щелкните правой кнопкой мыши на кооперации Register for Courses в пакете Use-Case Realization – Register for Courses.

В открывшемся меню выберите пункт Add > Add Diagram > Class.

Назовите новую диаграмму классов VOPC (classes only).

Откройте ее и перетащите классы на открытую диаграмму в соответствии с рисунком 4.5.

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

Примеры: обработка ошибок; контроль времени выполнения; обработка неправильных вводимых данных.

Нецелесообразно описывать тривиальные потоки событий (например, в потоке участвует только один объект).

Разработать на диаграмме классов соответствующие классы по индивидуальному заданию.

Содержание отчета:

1. Краткое описание основных элементов диаграммы.

Вопросы для защиты

Цель диаграммы

Стереотипы классов.

Связи между классами.

Лабораторная работа № 5. Разработка диаграммы последовательности и редактирование свойств ее элементов.

1. Теоретический материал

Создадим диаграммы последовательности и кооперативные диаграммы для основного потока событий варианта использования Register for Courses.

Готовые диаграммы последовательности должны иметь вид, как на рисунках 5.1 – 5.5.

Рисунок 5.1 – Диаграмма последовательности Register for Courses – Basic Flow

Рисунок 5.2 – Диаграмма последовательности Register for Courses – Basic Flow (Create Schedule)

В меню модели выберите пункт Tools > Options или нажмите сочетание клавиш CTRL + F9.

Перейдите на вкладку Diagram > Sequence.

Контрольный переключатель Show Sequence Numbering должен быть помечен.

Нажмите Close, чтобы выйти из окна параметров.

Создание диаграммы последовательности:

Щелкните правой кнопкой мыши на кооперации Register for Courses в пакете Use-Case Realization – Register for Courses.

В открывшемся меню выберите пункт Add > Add Diagram > Sequence.

Назовите новую диаграмму Register for Courses – Basic Flow.

Дважды щелкните на ней, чтобы открыть ее.

Добавление на диаграмму действующего лица, объектов и сообщений:

Перетащите действующее лицо Student из браузера на диаграмму.

Перетащите классы RegisterForCoursesForm и RegistrationController из браузера на диаграмму.

На панели инструментов нажмите кнопку Message (Сообщение).

Проведите мышью от линии жизни действующего лица Student к линии жизни объекта RegisterForCoursesForm.

Выделив сообщение, введите его имя: register for courses.

Повторите, описанные выше действия, чтобы поместить на диаграмму остальные сообщения, как показано на рисунке 5.1 (для рефлексивного сообщения 1.2 используется кнопка Self -Message).

Рисунок 5.3 – Диаграмма последовательности Register for Courses – Basic Flow (Update Schedule)

Рисунок 5.4 – Диаграмма последовательности Register for Courses – Basic Flow (Delete Schedule)

Выполните аналогичные действия для создания диаграмм последовательности, показанных на рисунках 5.2…5.5. Обратите внимание, что на диаграмме (рисунок 5.5) появился объект нового класса PrimarySheduleOffering-Info (класса ассоциаций, описывающего связь между классами Shedule и OfferingInfo), который нужно предварительно создать.

Рисунок 5.5 – Диаграмма последовательности Register for Courses – Basic Flow (Submit Schedule)

Чтобы поместить на диаграмму примечание:

Нажмите на панели инструментов кнопку Note.

Щелкните мышью в том месте диаграммы, куда собираетесь поместить примечание.

Выделив новое примечание, введите туда текст.

Чтобы прикрепить примечание к элементу диаграммы, щелкните по примечанию правой кнопкой мыши, в появившемся окне выберите Advanced > Set Attached Links.

Установите флажок напротив того (тех) элемента (элементов) диаграммы, с которым связываете примечание. Между примечанием и элементом возникнет штриховая линия.

Кроме примечаний, на диаграмму можно поместить также и текстовую область. С ее помощью можно, например, добавить к диаграмме заголовок.

Чтобы поместить на диаграмму текстовую область:

На панели управления нажмите кнопку New Text Element.

Щелкните мышью внутри диаграммы, чтобы поместить туда текстовую область.

Введите в неё текст.

Практическое задание

Разработать диаграммы последовательности по индивидуальному заданию.

Содержание отчета:

1. Краткое описание основных элементов диаграммы.

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

Вопросы для защиты

1. Цель диаграммы последовательности.

2. Объекты, линии жизни объектов.

3. Сообщения и их виды.
Лабораторная работа № 6. Разработка кооперативной диаграммы и редактирование свойств ее элементов.
1. Теоретический материал

Создание кооперативной диаграммы.

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