ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.11.2023
Просмотров: 157
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
16) переход – от деятельности ‘Получить карточку’ к конечному состоянию.
Диаграмма деятельности не является необходимой для генерации кода. Поэтому разработку диаграмм этого типа иногда опускают. В проектах реинжиниринга и документирования бизнес-процессов диаграмма деятельности является основным средством визуализации бизнес-процессов в контексте UML.
5.3. Порядок выполнения
1. Изучить назначение элементов интерфейса RR для построения диаграммы состояний. Рассмотреть типовой пример построения диаграммы.
2. Продолжить моделирование системы в соответствии с индивидуальным заданием в виде построения диаграммы состояний:
2.1. Активизировать окно диаграммы состояний, добавить требуемые состояния и переходы, в т.ч. переходы со сторожевым условием.
2.2. Выполнить спецификацию определённых состояний и переходов.
3. Изучить назначение элементов интерфейса RR для построения диаграммы деятельности. Рассмотреть типовой пример построения диаграммы.
4. Продолжить моделирование системы в соответствии с индивидуальным заданием в виде построения диаграммы деятельности:
4.1. Активизировать окно диаграммы деятельности, добавить деятельности и переходы, в т.ч. при необходимости добавить символы ветвления (решения), символы соединения, переходы со сторожевым условием.
4.2. Определить при необходимости стереотипы деятельностей, выполнить спецификацию определённых переходов.
5. Оформить отчёт по результатам выполнения лабораторной работы.
5.4. Содержание отчёта
Результаты выполнения лабораторной работы необходимо представить в виде отчёта, который должен содержать следующие разделы:
1. Постановка задачи.
2. Краткое описание составляющих каждой из диаграмм переходов состояний.
3. Окончательный вид каждой из диаграмм проектируемой системы.
5.5. Варианты заданий
Вариант индивидуального задания соответствует варианту, полученному при выполнении лабораторной работы №2.
5.6. Контрольные вопросы
1. Для чего предназначена диаграмма состояний?
2. В чём особенности построения диаграммы состояний в среде RR?
3. В чём отличие диаграммы состояний от диаграммы деятельности?
4. Используются ли диаграммы переходов состояний при генерации кода?
5. Как можно создать диаграмму переходов состояний?
6. Сколько начальных и конечных состояний может иметь диаграмма переходов состояний? Как они добавляются?
7. Как превратить обычное состояние в композитное?
8. Какие свойства состояний (переходов, деятельности) можно определить?
9. Что определяет сторожевое условие?
10. Что позволяет определить
Synchronization на диаграмме деятельности?
6. Диаграмма компонентов
6.1. Цель работы
Целью данной работы является использование диаграммы компонентов при разработке программной системы в среде RR.
6.2. Общие сведения
Диаграмма компонентов (component diagram) служит частью физического представления модели и относится к диаграммам реализации (implementation diagram). Она является необходимой для генерации кода. Она отображает компоненты системы и зависимости между ними: компоненты – исходный код, исполняемые компоненты, библиотеки кода; зависимости – порядок компиляции. В модели может быть создано несколько диаграмм для отражения пакетов, компонентов верхнего уровня и описания содержимого каждого пакета компонентов.
В RR есть возможность работы с программными библиотеками. Можно как разрабатывать библиотеки, так и пользоваться уже готовыми. Для этого необходимо указать, какие классы в каких компонентах будут находиться. При разработке проекта разделение классов по компонентам является серьёзной задачей. Чтобы обеспечить минимальные трудозатраты на разработку и сопровождение, тесно связанные между собой классы собираются в библиотеки DLL, OCX и т.п. Этим обычно занимаются системные аналитики, проектирующие структуру ПО.
Для разработки диаграмм компонентов в браузере предназначено представление компонентов (Component View), в котором уже есть диаграмма компонентов с пустым содержанием и именем Main (Главная). Активизация диаграммы компонентов может быть выполнена одним из следующих способов:
1. Раскрыть представление компонентов и дважды щёлкнуть на значке Main.
2. В браузере щёлкнуть правой кнопкой мыши на пакете и в открывшемся меню выбрать New → Component Diagram (Создать → Диаграмма компонентов).
3. Через меню Browse → Component Diagram (Браузер → Диаграмма компонентов), указав пакет и выбрав в окне диаграммы компонентов пункт New.
При этом появляется новое окно с чистым рабочим листом диаграммы и специальная панель инструментов, содержащая кнопки с изображением графических элементов для разработки диаграммы компонентов (табл.6.1).
Таблица 6.1
| Значок | Подсказка | Назначение кнопки |
 | Selection Tool | Переключает в режим выделения элементов на диаграмме |
 | Text Box | Добавляет на диаграмму текстовую область |
 | Note | Добавляет на диаграмму примечание |
 | Anchor Note to Item | Добавляет связь примечания с элементом диаграммы |
 | Component | Добавляет на диаграмму компонент |
 | Package | Добавляет на диаграмму пакет |
 | Dependency | Добавляет на диаграмму отношение зависимости |
 | Subprogram Specification | Добавляет на диаграмму спецификацию подпрограммы |
 | Subprogram Body | Добавляет на диаграмму тело подпрограммы |
 | Main Program | Добавляет на диаграмму главную программу |
 | Package Specification | Добавляет на диаграмму спецификацию пакета |
 | Package Body | Добавляет на диаграмму тело пакета |
 | Task Specification | Добавляет на диаграмму спецификацию задачи |
 | Task Body | Добавляет на диаграмму тело задачи |
 | Generic Subprogram | Добавляет на диаграмму типовую подпрограмму |
 | Generic Package | Добавляет на диаграмму типовой пакет |
 | Database | Добавляет на диаграмму базу данных |
Использование стереотипов увеличивает наглядность и позволяет архитектору уточнить характер реализации модели на выбранном ЯП (табл.6.2).
Таблица 6.2
| Изображение | Название | Характеристика стереотипа компонента |
 | Subprogram Specification Спецификация подпрограммы | Содержит описание переменных и подпрограмм и не содержит определений классов. |
 | Subprogram Body Тело подпрограммы | Содержит реализацию подпрограмм, не относящихся к каким-либо классам, при этом не содержит определений классов или реализаций операций других классов. |
 | Main Program Главная программа | Реализует базовую логику работы приложения и содержит ссылки на другие компоненты модели. |
 | Package Specification Спецификация пакета | Содержит определение класса, его атрибутов и операций. В C++ спецификации пакета соответствует файл-заголовок. |
 | Package Body Тело пакета | Содержит код реализации операций класса. В C++ спецификации пакета соответствует файл-реализация. |
 | Task Specification Спецификация задачи | Может содержать определение класса, его атрибутов и операций, которые предполагается использовать в независимом потоке управления. |
 | Task Body Тело задачи | Может содержать реализацию операций класса, которые имеют независимый поток управления. |
 | Generic Subprogram Типовая подпрограмма | Содержит описание переменных и подпрограмм, которые могут быть использованы в нескольких приложениях. При этом типовая подпрограмма не содержит определений классов. |
 | Generic Package Типовой пакет | Содержит определение класса, его атрибутов и операций, которое может быть использовано в нескольких приложениях. |
 | Database База данных | Содержит определение классов, их атрибутов и, возможно, операций. При этом классы могут быть реализованы в форме одной или нескольких таблиц базы данных. |
Для добавления компонента можно использовать специальную панель инструментов, главное меню Tools → Create → Component или контекстного меню представления компонентов New → Component. Для удаления компонента из диаграммы выделите его и нажмите клавишу Delete. Для удаления компонента из модели выделите его и в меню модели выберите Edit → Delete from Model.
Для каждого компонента можно определить свойства: стереотип, ЯП, декларации, реализуемые классы. Редактирование этих свойств для произвольного компонента осуществляется с помощью окна спецификации свойств. По умолчанию для всех добавляемых компонентов в качестве ЯП используется язык анализа.
Можно назначать ЯП для кодирования отдельных компонентов. Есть также возможность создавать дополнительные декларации для каждого компонента при генерации кода (вкладка Declarations спецификации компонента). Декларациями называют специфичные для ЯП операторы объявления переменных, классов и т.д.
Для генерации кода класса необходимо соотнести класс с компонентом. Это позволяет определить, в каком физическом файле следует сохранить код класса. С каждым компонентом можно соотнести несколько классов. В результате в логическом представлении после имени класса появится имя соответствующего компонента, заключённое в скобки.
Для соотнесения класса с компонентом нужно открыть окно спецификации компонента, перейти на вкладку Realizes (Реализации), щёлкнуть правой кнопкой мыши на классе и в открывшемся меню выбрать Assign (Назначить). На вкладке Realizes содержатся все классы, которые присутствуют в модели. Классы будут показаны только при выбранном свойстве Show all classes (Показать все классы).
Для добавления зависимости между двумя компонентами нужно с помощью левой кнопки мыши нажать кнопку с изображением зависимости на специальной панели инструментов. Для наглядности можно указать в форме примечаний те классы модели, которые предполагается реализовать в данных компонентах Отношение зависимости в среде RR не имеет окна спецификации свойств. Специфицировать свойства этого отношения (имя и стереотип) можно только с помощью текстовой области.
Для удаления диаграммы компонентов щёлкните правой кнопкой мыши на диаграмме в браузере и в открывшемся меню выберите Delete.
Типовой пример
Пример диаграммы компонентов для модели банкомата приведён на рис.6.1. При её построении добавлены следующие компоненты и зависимости.