Указания методические к лабораторным работам по дисциплине “Системы автоматизации проектирования программного обеспечения” МЕТОДИЧЕСКИЕ УКАЗАНИЯ к лабораторным работам по дисциплине “Системы автоматизации проектирования программного обеспечения” Содержание Введение. 3 1 Использование CASE-технологии в разработоке программного обеспечения. 4 1.1 Унифицированный Язык Моделирования. 4 1.2 CASE-средство Rational Rose 2003. 6 Лабораторная работа № 1. 8 Тема: «Исследование структуры и характеристик типовой автоматизированной системы». 8 Лабораторная работа № 2. 24 Тема: «Построение концептуальной модели предметной области. Разработка диаграммы вариантов использования в среде Rational Rose». 24 Лабораторная работа № 3. 41 Тема: «Построение моделей поведения проектируемого ПО. Построение диаграммы состояний в среде Rational Rose». 41 Лабораторная работа № 4. 51 Тема: «Построение диаграммы классов этапа проектирования в среде Rational Rose» 51 Лабораторная работа № 5. 67 Тема: «Генерация кода проектируемого программного обеспечения». 67 Лабораторная работа № 6. 82 Тема: «Отладка и тестирование проектируемого программного обеспечения». 82 Лабораторная работа № 7. 90 Тема: «Исследование характеристик разработанной автоматизированной системы» 90 Список использованных источников. 91 Приложение А . Техническое задание. 92 Приложение Б . Варианты заданий. 93 Введение В современных информационных технологиях важное место отводится инструментальным средствам и средам разработки автоматизированных информационных систем и, в частности, системам разработки и сопровождения их программного обеспечения. Эти технологии и среды образуют системы, называемые CASE-системами. Изначально разрабатываемые как инструмент для создания программного обеспечения, в настоящее время CASE-технологии являются целым направлением по системному анализу и проектированию. CASE-технологии представляют собой инструментарий для аналитиков и разработчиков, позволяющими минимизировать затраты на создание моделей будущей (или существующей) системы и на основе этой модели заранее найти возможные ошибки. Объемы информации, высокие требования к точности и достоверности, необходимость эффективного анализа - вот основные причины, предопределяющие использование новых информационных технологий, что становится принципиальным условием для достижения успешного результата. В предлагаемом материале рассмотрен пример разработки типовой автоматизированной информационной системы на основе CASE-средства Rational Rose 2003. 1 Использование CASE-технологии в разработоке программного обеспечения В индустрии разработок программного обеспечения существует понятие CASE-технологии (Computer-Aided Software/System Engineering). CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС. Главными преимуществами CASE-технологии по сравнению с другими способами моделирования являются: - создание модели системы в приемлемые сроки; - сокращение затрат связанных с процессом проектирования; - возможность анализа полученных данных до начала процесса непосредственного создания системы (тем самым появляется возможность «предотвращения» глобальных ошибок); - возможность применения «готовых» разработок в соответствии со своими требованиями (стандартные программные продукты и инструменты, относящиеся к группе CASE-средств). 1.1 Унифицированный Язык Моделирования UML – это язык визуализации, специфицирования, проектирования (конструирования) и документирования. UML – это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997г., и на сегодняшний день она поддерживается многими объектно-ориентированным CASE продуктами, включая Rational Rose. Для понимания UML необходимо усвоить основные принципы, положенные в структуру этого языка. Этих принципов всего три, а сам язык как бы состоит из трех частей: основные конструкции языка, правила их взаимодействия и некоторые общие для всего языка механизмы. Освоив эти идеи, вы сумеете читать модели на UML и самостоятельно их разрабатывать, естественно, вначале не очень сложные. По мере приобретения навыков работы с языком вы научитесь использовать и более развитыми его возможностями. Язык UML предназначен, прежде всего, для разработки программных систем. Его использование особенно эффективно в следующих областях: - информационные системы масштаба предприятия; - банковские и финансовые услуги; - телекоммуникации; - транспорт; - оборонная промышленность, авиация, космонавтика; - торговые системы; - медицинская электроника; - наука; - распределенные Web-системы. Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, например, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств. Существует несколько CASE-средств, поддерживающих язык UML. Наиболее известным являются PLATINUM Paradigm Plus фирмы PLATINUM technology и выпущенный фирмой Rational Software программный пакет Rational Rose. Эти инструменты позволяют генерировать код приложения, в полной мере отвечающий бизнес-правилам, и с наименьшим риском. Снижение риска в объектной технологии достигается за счет реализации технологии итерационной разработки (так называемая спиральная модель жизненного цикла разработки). Разработка состоит из ряда итераций, которые в дальнейшем приводят к созданию ИС. Каждая итерация может приводить к созданию фрагмента или новой версии и включает этапы выработки требований, анализа, проектирования, реализации и тестирования. Поскольку тестирование проводится на каждой итерации, риск снижается уже на начальных этапах жизненного цикла разработки. Модель представляет собой совокупность диаграмм, описывающих различные аспекты структуры и поведения ИС. В дальнейшем в качестве примера будет описана объектная модель, построенная в Rational Rose 2003. 1.2 CASE-средство Rational Rose 2003 Весь лабораторный практикум по данной дисциплине построен на изучении Case-средства Rational Rose 2003. Rational Rose — Case-средство предназначенное для анализа и проектирования объектно-ориентированных програм­мных систем. Выбор Case-средства визуального объектно-ориентированного проектирования информационных систем Rational Rose 200x Enterprise Edition , определялся рядом возможностей данного Case-средства: ­ имеет удобный для пользователя графический интерфейс; ­ многоплатформенность; ­ проектирование систем любой сложности; ­ предоставления развернутого представления о проекте в сочетании со средствами документирования (SoDA); ­ проводить обратное проектирование имеющихся систем; ­ интеграция с MS Visual Studio 6, что включает в себя поддержку на уровне прямой и обратной генерации кодов и диаграмм VB 6, Visual C++ 6, Visual J++ 6 (ATL-Microsoft Active Template Library, Web-Classes, DHTML, Data Connections); ­ непосредственная работа (инжиниринг и реинжиниринг) с исполняемыми модулями и библиотеками форматов EXE, DLL, TLB, OCX; ­ поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов стратегической технологии Microsoft — СОМ+ (DCOM); ­ полная поддержка CORBA 2.2, включая реализацию технологии компонентной разработки приложений CBD (Component-Based Development), языка определения интерфейса IDL (Interface Definition Language) и языка определения данных DDL (Data Definition Language); ­ полная поддержка среды разработки Java-приложений JDK 1.2, включая прямую и обратную генерацию классов Java формата JAR, а также работу с файлами форматов CAB и ZIP; ­ поддержка языка UML. В распоряжение проектировщика системы Rational Rose предоставляет сле­дующие типы диаграмм, последовательное создание которых позволяет полу­чить полное представление обо всей проектируемой системе и об отдельных ее компонентах: - диаграммы вариантов использования; - диаграммы классов; - диаграммы поведения системы; - диаграммы взаимодействия; - диаграммы последовательности; - кооперативные диаграммы; - диаграммы состояний; - диаграммы деятельностей; - диаграммы реализацией; - диаграммы компонентов; - диаграммы размещения. Rational Rose допускает как высокоуровневое (абстрактное) представление (например, схема автоматизации предприятия), так и низкоуровневое проектирование (интерфейс программы, схема базы данных, частичное описание классов). Весь этап проектирования и создания программного продукта основан на построении соответствующих диаграмм, которые в зависимости от ситуации способны описывать различные действия. Лабораторная работа № 1 Тема: «Исследование структуры и характеристик типовой автоматизированной системы» Цель работы: 1) ознакомиться с программным средством, предназначенным для решения комбинаторно-оптимизационных задач на графах; 2) исследовать структуру и характеристики программного средства. 1 Задание на самоподготовку - вспомнить изученный материал по дисциплине «Технология разработки программного обеспечения»; - знать методику построения функциональной схемы, укрупненной схемы алгоритма работы программного средства. Техническое задание 1 Введение При проектировании сложных систем, таких как микропроцессорная автоматизированная системы или её узлы, возникает ряд комбинаторно-оптимизационных задач структурного синтеза, на всех этапах, начиная с эскизного проектирования и заканчивая разработкой конструкторской документации. К таким задачам относятся, например, схемная компоновка, размещение компонентов в монтажном пространстве, коммутации соединений и т. д. Автоматизация указанных процессов является актуальной проблемой. Поэтому целью настоящего курсового проекта является автоматизация решения комбинаторно-оптимизационных задач. Для достижения указанных задач необходимо решить ряд инженерных задач, а именно: - анализ области применения комбинаторно-оптимизационных задач; - математические методы выбранных задач; - разработка архитектуры ПС; - выбор метода проектирования, программных средств реализации ПС; - разработка структуры данных для хранения информации; - разработка алгоритмов решения задач; - тестирование ПС; - разработка руководства программиста; - зработка руководства пользователя; - енка экономической эффективности внедрения ПС; - зопасность труда пользователя. Решение данных задач возможно на основании методов дискретной математики, программирования на языках высокого уровня, теории баз данных, статистических методов и моделей. 2 Основание для разработки Система разрабатывается на основании учебного плана подготовки специалистов 230105.65 - ПОВТАС и рабочей программе по дисциплине специализации «Системы автоматизации проектирования программного обеспечения» 3 Назначение Целью данной разработки является создание программного средства, позволяющего автоматизировать работу по решению комбинаторно-оптимизационных задач коммутации. Первая версия системы предназначена для решения небольшого круга комбинаторно-оптимизационных задач на графах (поиск кратчайшего пути, минимального покрывающего дерева и покрывающего цикла минимальной длины). В следующих версиях предполагается увеличение количества решаемых задач. Пользователями могут выступать научные работники и инженеры, занимающиеся проектированием компьютерной техники, и студенты соответствующих специальностей. Пользователями могут также быть и специалисты других предметных областей, которым приходится решать подобные задачи. 4 Требования к программе или программному изделию 4.1Требования к функциональным характеристикам Система должна представлять совокупность методических и программных средств решения следующих задач: - задачи построения минимального покрывающего дерева; - поиск покрывающего цикла минимальной длины (задача коммивояжера); - задачи поиска кратчайшего пути. Для этих задач должны быть реализованы: - алгоритмы, обеспечивающие получение точного решения; - в том случае, если точное решение получается алгоритмом, имеющим неполиномиальную вычислительную сложность, то необходимо дополнительно разработать алгоритм, обеспечивающий получение приближенных решений с полиномиальной вычислительной сложностью. Методическое обеспечение должно быть реализовано в пользовательском интерфейсе системы, который должен предполагать выбор задачи, метода и алгоритме ее решения; ввод данных; решение проектной задачи и сохранение исходных данных, промежуточных и окончательных результатов во встроенной базе данных для последующего анализа. 4.2 Требования к надежности Предусмотреть контроль вводимой информации и блокировку некорректных действий пользователя при работе с системой. Обеспечить корректное завершение вычислений с соответствующей диагностикой при превышении имеющихся вычислительных ресурсов. Обеспечить целостность информации, хранящейся в базе данных. 4.3 Требования к составу и параметрам технических средств Система должна работать на IBM совместимых персональных компьютерах. Минимальная конфигурация: Тип процессора…………………………………………Pentium-100; Объем оперативного запоминающего устройства ………16 Мб; Тип монитора…………………………………..…………SVGA (15'). 4.4 Требования к информационной и программной совместимости Система должна работать под управлением операционной системы Windows'95 и выше. 5 Требования к программной документации Разрабатываемая система должна включать справочную информацию о работе системы и подсказки пользователю. В состав сопровождающей документации должны входить: - пояснительная записка; - руководство пользователя. 6 Этапы разработки № Название этапа Сроки Точность 1 Разработка ядра системы 01.12.2006-31.12.2006 Описание внутренних форматов, интерфейса и форматов данных базы. Реализация системы на уровне интерфейса 2 Разработка методов и алгоритмов и их реализация для задачи коммивояжера 01.01.2007-11.01.2007 Описание методов и алгоритмов. Программные модули, реализующие методы 3 Разработка методов и алгоритмов и их реализация для задачи построения минималь­ного связывающего дерева и задачи поиска кратчайшего пути в графе 12.01.2007-31.01.2007 Описание методов и алгоритмов. Программные модули, реализующие методы. 4 Тестирование программного продукта и составление программной документации 01.02.2007-23.02.2007 Тесты. Документация. Программный продукт 2 Выбор метода проектирования, программных средств реализации ПС Программное средство разработано для локальной работы на одном компьютере. Для создания базы данных была использована СУБД PARADOX, достаточную для ведения простой БД, состоящей из шести таблиц. Для разработки приложения была выбрана система разработки приложений Delphi 6, предназначенная для быстрой разработки приложений самого разного характера и назначения. В данной версии системы, как и в более ранних ее версиях используется язык программирования высокого уровня Object Pascal. Одним из ключевых функций системы Delphi 6 является возможность разработки приложений для работы с базами данных как локальными, так и удаленными. Поэтому данная среда широко используется для программирования пользовательских приложений. Связующим звеном между приложением и базой данных является компонент TDataSet, причем данный ком­понент может работать с базой данных практически любого типа. Приложения баз данных строятся на основе компонентов доступа к базам данных и так называемых компонентов управления базами данных. При этом поддерживаются форматы dBase, Paradox, ASCII, FoxPro, Access. Посредством окружения Delphi, предназначенного для работы с базами данных можно создавать, индексировать, читать базы данных (DataBase Desktop). Кроме того, Delphi представляет широкие возможности по графическому представлению данных, что существенно облегчает работу пользователей по анализу полученных результатов. 3 Архитектура программного средства Программное средство решения комбинаторно-оптимизационных задач предусматривает выполнение следующих функций рассматриваемой предметной области: Просмотр и загрузка данных из БД. Ввод новых данных и сохранение записей в таблицах БД. Построение минимального покрывающего дерева. Поиск цикла минимальной длины (задача коммивояжера). Поиск кратчайшего пути. Формирование отчета. Функциональную схему разработать самостоятельно и представить на рисунке преподавателю. Программное средство “ПС_РКОЗ” включает в себя следующие программные модули, организующие работу по автоматизации решения комбинаторно-опитимизационных задач: 1. Glav.pas – выводит главное меню программы. В случае работы пользователя со справкой передает управление модулю sprav.pas; если пользователь выбрал пункт открытие БД, то управление передается модулю open_bd.pas, представляющим собой модуль загрузки и редактирования данных. После загрузки данных графа (или его изображение с помощью примитивов) становятся доступны пункты меню: если активизирован пункт минимальный путь, то управление передается модулю minimum_way.pas, являющимся модулем задания начальной и конечной вершин и вычисления кратчайшего пути; если активизирован пункт цикл минимальной длины, то управление передается модулю minimum_cycle.pas, являющимся модулем вычисления цикла минимальной длины; если активизирован пункт кратчайшее остовное дерево, то управление передается модулю minimum_frame.pas, являющимся модулем нахождения кратчайшего остовного дерева. В случае выбора пункта сохранить, управление передается модулю save_in_bd.pas, реализующим соответственно функции сохранения данных о графе в базе данных. Если необходимо получить сведения о программе или помощь, управление передается модулям sprav.pas и spravka.pas. 2. sprav.pas – справочная информация по программе. 3. spravka.pas – о программе (версия, разработчик). 4. open_bd.pas – модуль открытия и/или загрузки и редактирования имеющихся записей в БД. 5. save_in_bd.pas – модуль сохранения и редактирования имеющихся записей в БД. 6. Ves_way.pas – модуль ввода веса ребра во время рисования графа. 7. minimum_way.pas – модуль задания начальной и конечной вершин графа и выбора алгоритма для вычисления кратчайшего пути. 8. minimum_frame.pas – модуль выбора алгоритма и вычисления кратчайшего остовного дерева. 9. minimum_cycle.pas – модуль выбора алгоритма и вычисления цикла минимальной длины. 10. print.pas – модуль формирования отчета и вывода его на печать. Диаграмма модулей ПС представлена на рисунке Приложения А. На основании функциональной схему и диаграммы модулей разработать укрупненную схему алгоритма ПС. 4 Разработка структуры данных для хранения информации Для проектирования базы данных необходимо построить модель «объект-отношение», то есть для данных в создаваемой базе данных необходимо построить связи, характеризующие их отношения. Данная модель не зависит от использования СУБД. В создаваемой базе данных имеются таблицы: «glav_tabl», «x_wer», «y_wer», «line_begin», «line_end», «line_ves». В виду простых требований к данной БД таблицы «x_wer», «y_wer», «line_begin», «line_end», «line_ves» связаны с таблицей «glav_tabl» отношением 1:1. 4 Даталогическая модель базы данных Для дальнейшего проектирования базы данных необходимо построить даталогическую модель базы. Основной задачей даталогического моделирования является получение структуры данных, описанной на языке математической модели, ориентированной на выбранную СУБД. Дататалогическая модель представляет собой схему проектируемой базы данных, в которой представлены все связи между объектами базы данных, описанные в модели «объект-отношение». Объекты представлены в виде таблиц, имеющих названия, значимые поля свойств, характеризующие хранимые в таблицах данные и уникальные первичные и внешние ключи, на основе взаимосвязи между которыми осуществляется реализация связей между таблицами базы данных и целостность базы данных. Даталогическая модель формируется на основе ER-диаграммы и представляет собой заключительный этап создания структуры базы данных перед переходом от процесса проектирования к созданию физической модели с детальным описанием всех таблиц, непосредственно составляющих базу данных. Схема логической модели представлена на рисунке 1. Рисунок 1 – Логическая схема базы данных Приложение А Рисунок 2 – Иерархия модулей ПС Приложение Б Руководство пользователя После запуска программы на выполнение на экране монитора отображается главное окно программы, на которой пользователь имеет возможность выбора одного из четырех пунктов: «Открыть», «Рисовать», «Помощь» и «Выход» (рисунок 5). Рисунок 5 – Главное окно ПС При выборе пункта «Открыть» появляется возможность выбора или удаления данных, хранящихся в базе данных (рисунок 6). Рисунок 6 – Выбор/удаление задачи При активации кнопки «Рисовать» появляется возможность нарисовать с помощью графических примитивов: окружности (вершина) и линии (дуга с весом) граф (рисунок 7). Рисунок 7 – Рисование графа с помощью примитивов После выбора задачи из БД или рисования графа открывается доступ к остальному меню: «Min_way»(поиск кратчайшего пути рисунок 8) , «Min_cycle» (цикл минимальной длины рисунок 9), «Min_frame» (кратчайшее остовное дерево рисунок 10), «Save» (сохранение графа в БД рисунок 3.7). Рисунок 8 – Поиск кратчайшего пути Рисунок 9 – Поиск цикла минимальной длины Рисунок 10 – Поиск кратчайшего остовного дерева Рисунок 11 – Сохранение/удаление графа в БД На вкладе «матричное представление» можно просмотреть табличное представление связей в графе (рисунок 12). Рисунок 12 – Матричное представление графа На рисунке 13 представлены результаты применение выбранных алгоритмов, просмотр которых возможен после выбора закладки «Результаты». Рисунок 13 – Результаты оптимизации В пункте меню «Справка» имеется возможность обращения к справочной информации, на рисунке 14 показана форма вывода справочной информации. Рисунок 14 – Справочная информация ПС При выборе пункта «Выход» главного окна, ПС завершает свою работу. Лабораторная работа № 2 Тема: «Построение концептуальной модели предметной области. Разработка диаграммы вариантов использования в среде Rational Rose» Цель работы: 1) Освоить методику построения диаграмм вариантов использования; 2) Познакомиться с Case-средством Rational Rose и получить навыки работы в данной среде; 3) Разработать диаграмму вариантов использования согласно заданию. 1 Задание на самоподготовку - изучить лекционный материал по данной теме; - знать методику построения диаграмм вариантов использования. 2 Краткие теоретические сведения Концептуальную модель предметной области можно представить в виде ER-диаграммы, т.е. отношения “сущность-связь”.Для этого необходимо разработать модель данных. Моделирование данных является важнейшим процессом при проектировании программного обеспечения (ПО). По этой причине, разработчики CASE-средств в своих продуктах вынуждены уделять моделированию данных повышенное внимание. Являясь признанным лидером в области объектных методологий, фирма Rational Software Corporation, тем не менее, до недавнего времени такого средства не имела. Основной причиной этого, по-видимому, является ориентация на язык Unified Modeling Language (UML), как универсальный инструмент моделирования. UML полностью покрывает потребности моделирования данных. Сложившаяся на протяжении десятилетий технология моделирования данных, традиции, система понятий и колоссальный опыт разработчиков не могли далее игнорироваться. Немаловажную роль здесь сыграла и необходимость формального контроля моделей данных, что является абсолютно необходимым при проектировании мало-мальски больших схем баз данных и что UML не обеспечивает в достаточной степени. И, наконец, последней причиной, побудившей специалистов Rational Software Corporation к созданию собственного средства моделирования данных, является требование построения эффективных физических моделей, прежде всего для конкретных СУБД - лидеров рынка. В начале 2000 года фирма Rational Software Corpоration анонсировала появление собственного средства моделирования данных – Data Modeler, и в настоящее время оно доступно специалистам, например, использующим в своей работе Rational Rose 2000. Целью данной лабораторной работы является знакомство с основными возможностями этого нового средства. Авторы Data Modeler, прежде всего, ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и, наоборот, в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элементов моделей (табл. 1). Таблица 1. Соответствие элементов логической и физической модели Логическая модель Физическая модель Class (Класс) Table (Таблица) Operation (Операция) Constraint (Ограничение) Attribute (Атрибут) Column (Колонка) Package (Пакет) Scheme (Схема) Component (Компонент) Database (База данных) Association (Ассоциация) Relationship (Связь) Нет Trigger (Тригер) Нет Index (Индекс) 2.1 Rose Data Modeler После установки Rational Rose в специальной редакции (Rational Rose Professional Data Modeler Edition) в разделе главного меню Tools появляется новый раздел Data Modeler (рис. 1). В разделе Data Modeler имеются два пункта: “Add Schema” и “Reverse Engeneer…”. Пункт “Add Schema” используется для создания новых схем БД, а пункт “Reverse Engeneer” - для построения модели на основе существующей схемы БД. Рисунок 2.1- Отображение компоненты Data Modeler в меню Rational Rose 2.1.1 Создание диаграммы модели данных После создания схемы (рис.2.1) в ней можно сформировать диаграмму модели данных. Эта диаграмма позволит добавить, изменить или просмотреть таблицы и другие элементы модели данных, поскольку играет ту же роль, что и диаграмма классов в объектной модели. Хотя можно добавлять элементы моделирования данных непосредственно в браузере, диаграмма модели данных позволяет показать в графическом виде, как сами элементы, так и отношения между ними. Для любой схемы можно создать любое необходимое число Создание диаграммы модели данных осуществляется следующим образом: 1. В браузере щелкните правой кнопкой мыши на схеме. 2. Выберите Data Modeler > New > Data Model Diagram. 3. Введите имя новой диаграммы. 4. Дважды щелкните на диаграмме для ее открытия. Как и другие диаграммы в среде Rose, диаграмма модели данных имеет специализированную панель инструментов для добавления таблиц, отношений и других элементов моделирования. Кнопки этой панели перечислены в таблице 2.2. Таблица 2.2 – Значки панели инструментов для диаграммы модели данных Значки Назначение Курсор принимает форму стрелки для выделения элемента Добавляет в диаграмму текстовое поле Добавляет к элементу диаграммы примечание Соединяет примечание с элементом диаграммы Добавляет в диаграмму таблицу Рисует неидентифицируемое отношение между двумя таблицами Рисует идентифицируемое отношение между двумя таблицами Добавляет в диаграмму представление Рисует зависимость между двумя таблицами Диаграмма Data Model предоставляет следующие возможности: - создание и редактирование таблиц и их элементов (колонок, ограничений, индексов, триггеров и т. п.); - создание и редактирование идентифицирующих связей между таблицами; - создание и редактирование неидентифицирующих связей. Основные возможности по работе с таблицей доступны, если войти в контекстном меню в пункт “Open Specification”. Появляющееся на экране окно включает следующую информацию (рис. 2.2). Рисунок 2.2 - Окно спецификации таблицы При редактировании спецификации таблицы обеспечиваются следующие возможности (табл. 2.3). Таблица 2.3 - Спецификация таблицы БД Закладка Описание General Вводится общая информация о таблице. Columns Задается описание колонок. Здесь можно добавить или отредактировать свойства колонок, задать тип, длину, обязательность (NULL, NOT NULL), а также пометить, что колонка входит в состав первичного ключа. Типы колонок соответствуют типам конкретной выбранной СУБД. Key Constraints Задаются ограничения на колонки таблицы. Здесь можно задать ограничение на уникальность первичного ключа, ограничение на уникальность альтернативных ключей, а также просто определить индекс. Check Constraints Задаются выражения – инварианты, которые должны выполнятся для всех строк таблицы. Triggers Содержит список триггеров, который можно отредактировать, в том числе добавив новый триггер. Relationships При наличии связей между таблицами, закладка содержит полный список связей. 2.1.1.1 Добавление отношений Отношения в модели данных подобны отношениям в объектной модели. В объектной модели отношение связывает два класса, а в модели данных — две таблицы. В Rose поддерживаются два основных типа отношений: иденти­фицируемые отношения (identifying relationship) и неидентифицируемые от­ношения (non-identifying relationship). В обоих случаях для поддержки отношений в дочернюю таблицу добавля­ется внешний ключ. При идентифицируемом отношении внешний ключ ста­новится частью первичного ключа в дочерней таблице. В этом случае дочерняя таблица не может содержать запись, не связанную с записью в ро­дительской таблице. Идентифицируемые отношения моделируются состав­ными агрегациями. Неидентифицируемые отношения тоже создают внешний ключ в дочер­ней таблице, но он не становится частью первичного ключа в дочерней таб­лице. При неидентифицируемом отношении мощность (множественность) определяет то, будет ли запись в дочерней таблице существовать без связи с записью в родительской таблице. Если мощность равна 1, должна присутст­вовать родительская запись. Если мощность равна 0..1, присутствие роди­тельской записи необязательно. Неидентифицируемые отношения моделиру­ются ассоциациями. Для редактирования свойств связи требуется войти в пункт контекстного меню “Open specification”. Рисунок 2.3 - Окно спецификации связи При редактировании спецификации связи обеспечиваются следующие возможности (табл. 2.4). Таблица 2.4 - Спецификация связи Закладка Описание General Основные свойства связи. Здесь задаются: имя связи; тип связи; наименования ролей (Parent, Child); кардинальность для каждой роли; Migrated Key Содержит список внешних ключей, образующихся в результате создания связи. RI Задание условий ссылочной целостности. Ссылочная целостность обеспечивается двумя способами: на основе триггеров; на основе декларативной ссылочной целостности (с использованием ограничений внешних ключей). Оба способа реализуют наиболее популярные алгоритмы, задаваемые для каждой роли (только для операций update и delete, для insert мы не нашли): Restrict; Cascade; Set Null; Set Default. 2.2 Пример концептуальной модели предметной области На рисунке 2.4 приведен фрагмент модели данных заданной предметной области. Данная модель разработана в среде Rational Rose 2003 с использованием утилиты Rose Data Modeler. Описание предметной области. Организация предоставляет услуги по трудоустройству. Организацией ведется банк данных о существующих вакансиях. По каждой вакансии поддерживается следующая информация: - предприятие, предоставляющее соответствующую вакансию; - название вакансии (должность); - требования к соискателю: пол, возраст, образование, знание определенных видов деятельности (выбор из перечня - знание электронного документооборота, определенных прикладных программ и т.п.), коммуникабельность; - обязанности (выбор из перечня – заключение договоров, распространение агитационного материала, работа с клиентами и т.п.); - предполагаемая оплата, единицы измерения оплаты - рубли; - оформление трудовой книжки (да, нет); - наличие социального пакета (да, нет); - срок начала открытия вакансии; - срок закрытия вакансии (вакансия занята). Рисунок 2.4 – Модель данных предметной области 2.3 Разработка диаграммы вариантов использования Диаграмма вариантов использования отображает взаимодействие между вариантами использования, представляющими функции системы, и действующими лицами, представляющими людей или системы, получающие или передающие информацию в данную систему. Данный тип диаграмм предназначен для создания списка операций, которые выполняет система, поэтому его иногда называют диаграммой функций. Любая система обладает своим множеством вариантов использования и множеством действующих лиц. Каждый вариант использования описывает элемент представляемой системой функциональности. Множество вариантов использования описывает всю функциональность системы на некотором уровне абстракции. Абстракция ( abstraction) – сосредоточение на важнейших аспектах приложения и игнорирование всех остальных. Использование абстракции позволяет сохранить свободу принятия решений как можно дольше благодаря тому, что детали не фиксируются раньше времени. Каждое действующее лицо представляет собой один вид объектов, для которых система может выполнять некоторое поведение. Язык UML предусматривает систему графических обозначений для вариантов использования (рис. 2.5). Рисунок 2.5 – Графические обозначения диаграммы вариантов использования Действующее лицо (actor) – это непосредственный внешний пользователь системы. Это объект или множество объектов, непосредственно взаимодействующих с системой. Каждое действующее лицо является обобщением группы объектов, ведущих себя определенным образом по отношению к системе. Действующими лицами могут быть люди, устройства и другие системы – все, что взаимодействует с интересующей нас системой непосредственно. Действующее лицо должно иметь одну четко определенную цель. Моделирование действующих лиц помогает определить границы системы, то есть идентифицировать объекты, находящиеся внутри системы, и объекты, лежащие на ее границе. Различные взаимодействия действующих лиц с системой группируются в варианты использования. Вариант использования (use case) – это связный элемент функциональности, представляемый системой при взаимодействии с действующими лицами (рис. 2.6) . Рисунок 2.6 – Вариант использования В каждом варианте использования участвуют одно или несколько действующих лиц и система. Вариант использования объединяет все поведение, имеющее отношение к элементу функциональности системы: нормальное поведение, вариации нормального поведения, исключительные ситуации, сбойные ситуации и отмены запросов. Любой вариант использования должен иметь краткое описание, объясняющее действия в этом варианте. Описание должно быть кратким, но в него необходимо включить сведения о разных типах пользователей, выполняющих данный вариант использования, и ожидаемый результат. Во время работы (особенно если проект сложный) эти описания будут напоминать членам команды, почему тот или иной вариант использования был включен в проект и что он должен делать. Четко документируя, таким образом, цели каждого варианта использования, можно уменьшить неразбериху, возникающую среди разработчиков. На рисунке 2.7 приведен пример документирования варианта использования. Рисунок 2.7 – Окно документирования варианта использования Между компонентами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов. Один актер может взаимодействовать с несколькими вариантами использования. В этом случае этот актер обращается к нескольким сервисам данной системы. В свою очередь один вариант использования может взаимодействовать с несколькими актерами, предоставляя для всех них свой сервис. Следует заметить, что два варианта использования, определенные для одной и той же сущности, не могут взаимодействовать друг с другом, поскольку каждый из них самостоятельно описывает законченный вариант использования этой сущности. Более того, варианты использования всегда предусматривают некоторые сигналы или сообщения, когда взаимодействуют с актерами за пределами системы. В то же время могут быть определены другие способы для взаимодействия с элементами внутри системы. В языке UML имеется несколько стандартных видов отношений между действующими лицами и вариантами использования: - отношение ассоциации; - отношение зависимости; - отношение обобщения. Ассоциация – структурное отношение, описывающее совокупность связей, представленных соединениями между объектами модели. Выделяют разновидность ассоциации, агрегирование, предусмотренное для выражения отношений между целым и его частями. Рисунок 2.8 – Пример реализации отношения ассоциации Применительно к диаграммам вариантов использования оно служит для обозначения специфической роли актера в отдельном варианте использования. Другими словами, ассоциация специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы. Таким образом, это отношение устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. На диаграмме вариантов использования, так же как и на других диаграммах, отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь дополнительные условные обозначения, такие, например, как имя и кратность Кратность (multiplicity) ассоциации указывается рядом с обозначением компонента диаграммы, который является участником данной ассоциации. Кратность характеризует общее количество конкретных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации. Применительно к диаграммам вариантов использования кратность имеет специальное обозначение в форме одной или нескольких цифр и, возможно, специального символа "*" (звездочка). Зависимость – семантическое отношение между двумя сущностями, при которой изменение одной из сущностей, независимой, может повлиять на семантику второй сущности, зависимой. Отношение зависимости определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров. В метамодели отношение зависимости является направленным и указывает, что применительно к отдельным примерам некоторого варианта использования должны быть выполнены конкретные условия, определенные для расширения данного варианта использования. Отношение зависимости между вариантами использования обозначается пунктирной линией со стрелкой, направленной от того варианта использования, который является расширением для исходного варианта использования. Рисунок 2.8 - Пример графического изображения отношения зависимости (расширения) между вариантами использования Обобщение – отношение, при котором объект специализированного элемента может быть подставлен и использован вместо объекта обобщенного элемента. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования (рис. 2.9). Рисунок 2.9 - Пример графического изображения отношения обобщения между действующими лицами 2.4 Особенности разработки диаграмм вариантов использования в среде IBM Rational Rose 2003 Запустите Rational Rose , и создайте новую пустую модель. Для этого в окне Create New Model мастера создания моделей, открывающегося после первого запуска системы, включите флажок Don’t show this dialog in the future и нажмите кнопку Cancel . Эта команда закроет окно мастера, и не будет выводить его при следующих открытиях Rational Rose . В рабочем поле Rational Rose будет выведена пустое окно диаграммы классов. Это будет наша рабочая модель, в которой и должны быть отражены все нюансы будущей системы. Затем для того чтобы открыть окно диаграммы Use Case необходимо сделать двойной щелчок по значку Main в папке User Case View в окне Browser. Если открыто окно хотя бы одной диаграммы, то в главном меню активизируется пункт Browse и диаграмму Use C ase можно открыть командой Browse,Use Case Diagram. Отметим, что в панели инструментов Standard нет кнопки просмотра Browse Use Case Diagram. Создание новых элементов в диаграмме Use Case Rational Rose предоставляет несколько способов создания новых элементов в окне диаграмм Use Case : 1. Командой New,Use Case контекстного меню папки Use Case View в окне Browser . 2. Командой Tools,Create,Use Case главного меню. 3. Командами строки инструментов окна Use Case Diagram. В первом случае элемент создается непосредственно в дереве модели (в папке Use Case View окна Browser), но его значок не включается ни в одну диаграмму. После создания элемента, таким способом, можно поместить его на выбранную диаграмму, например путём перетаскивания мышкой значка элемента из дерева модели окна Browser в окно диаграммы. Во втором и третьем случае вместе с созданием элемента его значок помещается на текущую диаграмму автоматически. При создании элементов посредством меню Tools программа предоставляет возможность создавать все элементы, которые можно включить в текущую диаграмму, тогда как при создании средствами строки инструментов пользователь ограничен созданием элементов согласно включенным в данную строку значкам. По причине большей простоты и наглядности рекомендуем пользоваться третьим вариантом. Для этого необходимо ознакомиться с содержанием строки инструментов, установленной по умолчанию для данной диаграммы. Для моделирования бизнес-процессов Rational Rose предоставляет дополнительные элементы Use Case , которые можно активизировать при помощи режима настройки инструментов (командой Use Case Diagram… на вкладке Toolbars окна Optins, открываемого командой Tools,Options главного меню). Но для создания системы учета товародвижения на складе достаточно значков, установленных в панелях инструментов по умолчанию. Рассмотрим панель инструментов рабочего окна диаграммы Use Case. Таблица 2.5 - Пиктограммы панели инструментов диаграммы Use Case Пиктограмма Кнопка Описание Selects or deselects an item (Выделение или отмена выделения объекта) Превращает курсор в стрелку указателя, так что вы можете выделить объект Text Box (Текст) Добавляет к диаграмме текст Note (Примечание) Добавляет к диаграмме примечание Anchor Note to Item (Прикрепление примечания к объекту) Связывает примечание с вариантом использования или объектом на диаграмме Package (Пакет) Помещает на диаграмму новый пакет Use Case (Вариант использования) Помещает на диаграмму новый вариант использования Actor (Действующее лицо Помещает на диаграмму новое действующее лицо Unidirectional Association (Однонаправленная ассоциация) Рисует связь между действующим лицом и вариантом использования Dependency or Instantiates (Зависимость или наполнение) Рисует зависимость между элементами диаграммы Generalization (Обобщение) Рисует связь использования или расширения между ва­риантами использования либо рисует связь наследова­ния между действующими лицами По умолчанию строка инструментов Use Case- диаграммы состоит из десяти значков. При необходимости можно настроить панель инструментов. Как настроить панель инструментов для диаграмм в среде IBM Rational Rose 2003 Необходимо открыть диалоговое окно настройки специальных панелей инструментов для диаграмм в среде IBM Rational Rose 2003 можно с помощью операции главного меню: Tools Options (Инструменты Параметры), раскрыв вкладку Toolbars (Панели инструментов) и нажав соответствующую кнопку (например, Use Case diagram) в группе опций Customize Toolbars (Настройка панелей инструментов). Это окно настройки также можно открыть с помощью операции контекстного меню Customize (Настройка) при позиционировании курсора на специальной панели инструментов (рис. 2.6). Рисунок 2.10 - Диалоговое окно настройки специальной панели инструментов для диаграммы вариантов использования Для добавления необходимых кнопок на панель следует выделить их в левом окне со списком пиктограмм графических элементов, после чего нажать кнопку «Добавить» в центре диалогового окна. Для удаления ненужных кнопок с панели инструментов следует выделить их в правом окне со списком пиктограмм графических элементов, после чего нажать кнопку «Удалить» в центре диалогового окна. Для восстановления набора пиктограмм по умолчанию можно нажать кнопку «Сброс». После настройки специальной панели инструментов соответствующее окно следует закрыть нажатием на кнопку «Закрыть». Способы именования элементов и связей Структурным элементам Actor, Use Case и Package, вводимым в диаграмму, система Rational Rose автоматически присваивает умалчиваемые имена (NewClassN , NewUseCaseN и NewPackageN ). Изменит эти имена можно двумя способами: – редактирования подписи под значком после двойного щелчка на ней левой клавишей мыши (эта команда переводит окно с надписью в режим редактирования текста); – контекстной командой Rename на соответствующем значке в дереве модели окна Browser; – активизируя панель спецификаций элемента (двойным левым щелчком мыши на самом значке элемента в окне диаграммы) и редактируя умалчиваемое имя в поле Name : этой панели. Связям умалчиваемые имена не присваиваются. При необходимости их именования можно использовать только третий способ – вводом нужного имени в поле Name : окна спецификаций связей. Для открытия этого окна переведите указатель мыши точно на стрелку связи в окне диаграммы и выполните двойной левый щелчок. Должно открыться диалоговое окно Assotiasin Specification for… с полем Name : , в которое и вводится имя связи. 2.4.1 Пример разработанной диаграммы вариантов использования На рисунке 2.7 приведена диаграмма вариантов использования для приложения АИС «Трудоустройство». Описание предметной области. Организация предоставляет услуги по трудоустройству. Организацией ведется банк данных о существующих вакансиях. По каждой вакансии поддерживается определенная информация. Помимо проектирования реляционной базы данных АИС, необходимо еще и разработать приложение к ней. Цель приложения: автоматизация информационного процесса определения подходящей вакансии по данным резюме (анкеты) соискателя. Метод: дискриминантный анализ. Пользователь: менеджер по работе с кадрами. Рисунок 2.11 – Пример диаграммы вариантов использования 3 Задание на лабораторное занятие Согласно своему варианту (Приложение А, Таблица 1 – Варианты заданий на лабораторные работы) разработать диаграмму вариантов использования, используя выше описанную методику ее построения. 4 Содержание отчета - титульный лист; - постановка задачи; - диаграмма вариантов использования. 5 Контрольные вопросы для защиты лабораторной работы 1. Что представляет собой программа Rational Rose? 2. Что такое язык UML? 3. Какие преимущества дает применение Rational Rose при разработке программных систем? 4. Какие UML диаграммы доступны в Rational Rose? 5. Для чего используется диаграмма Use Case? 6. Как создать новую диаграмму? 7. Какие значки находятся в строке инструментов диаграммы Use Case и каково их назначение? Как настроить панель инструментов для диаграмм в RR? 8. Какие типы связи существуют между элементами диаграммы вариантов использования? 9. Какие значки специфичны только для диаграммы Use Case? 10. Как при помощи диаграммы создать сценарий поведения? Лабораторная работа № 3 Тема: «Построение моделей поведения проектируемого ПО. Построение диаграммы состояний в среде Rational Rose» Цель работы: 1) Освоить методику построения диаграмм состояний; 2) Согласно заданию на лабораторное занятие построить диаграмму состояний. 1 Задание на самоподготовку - изучить лекционный материал по данной теме; - знать методику построения диаграмм состояний. 2 Краткие теоретические сведения Чтобы представить поведение системы более детально на логическом уровне используют диаграммы: состояний, деятельности, последовательности и кооперации. В отличие от диаграмм деятельности, последовательности и кооперации, диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. Модель состояний состоит из нескольких диаграмм состояний, по одной на каждый класс, поведение которого во времени важно для приложения. Диаграмма Statechart (диаграмма состояний) предназначена для описания состояний объекта и условий перехода между ними. Описание состояний по­зволяет точно описать модель поведения объекта при получении различных сообщений и взаимодействии с другими объектами. Перед тем как рассмотреть особенности построения диаграмм состояний выделим ряд определений: Автомат (State machine) -это описание последовательности состояний, через которые проходит объект на протяжении своего жизненного цикла, реагируя на события, - в том числе описание реакций на эти события. Состояние (State) - это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события. Событие (Event) - это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие - это стимул, способный вызвать срабатывание перехода. Переход (Transition) - это отношение между Двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние, как только произойдет определенное событие и будут выполнены заданные условия. Деятельность (Activity) -это продолжающееся неатомарное вычисление внутри автомата. Действие (Action) - это атомарное вычисление, которое приводит к смене состояния или возврату значения. Графически состояние отображается в виде прямоугольника с закругленными вершинами. а) б) Рисунок 3.1 – Графическое изображение состояний на диаграмме состояний а) состояние без указания в нем действий или переходов б) состояние с указанием действий или переходов Список внутренних действий состояния содержит перечень внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии. Каждое из действий записывается в виде отдельной строки и имеет следующий формат: <метка действия / выражение действия> Метка действия указывает на обстоятельства или условия, при которых будет выполняться деятельность, определенная выражением действия. Существует ряд значений, которые может принимать метка действия: - entry - эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие); - do – действия, производимые в течение состояния до выхода. Если таких действий набирается несколько, то почти наверняка их можно выделить в отдельную диаграмму состояния; - exit – метка показывающая, что действие должно быть выполнено перед самым выходом из указанного состояния; - include - эта метка используется для обращения к подавтомату, при этом следующее за ней выражение действия содержит имя этого подавтомата. Выражение действия – действие, которое должно быть выполнено в зависимости от метки действия. Составное состояние (composite state) - такое сложное состояние, которое состоит из других вложенных в него состояний. Вложенные состояния можно отобразить или скрыть по необходимости. Рисунок 3.2 – Пример составного состояния История состояния позволяет показать, что в следующий раз, когда система попадает в указанное состояние, она должна не начинать с начала со­стояний, а сразу перейти на последнее состояние, из которого вышла, то есть при первом входе в некоторое состояние производятся единичные действия, которые при следующем входе проделывать уже не нужно. Например, при первом входе в режим протоколирования сообщений нужно создать файл про­токола, который при последующих обращениях к этому режиму пересоздавать не нужно. Рисунок 3.3 – Графическое представление истории состояния в среде Rational Rose Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние действия или деятельности. Для описания этого потока используются переходы показывающие путь из одного состояния действия или деятельности в другое. Простой переход (simple transition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Срабатывание перехода зависит от наступления некоторого события, и от выполнения определенного условия, называемого сторожевым условием. Объект перейдет из одного состояния в другое в том случае, если произошло указанное событие и сторожевое условие приняло значение "истина". Переход может быть направлен не только в другое состояние, но и в то же состояние, из которого он выходит. В этом случае его называют переходом в себя. При переходе в себя объект покидает исходное состояние, а затем снова входит в него. При этом всякий раз выполняются внутренние действия, специфицированные метками entry и exit. 2.1 Особенности разработки диаграммы состояний в среде IBM Rational Rose 2003 Для того чтобы построить диаграмму состояний, ее вначале необходимо создать и активизировать. Начать построение диаграммы состояний для выбранного элемента модели или моделируемой системы в целом можно одним из следующих способов: - щелкнуть на кнопке с изображением диаграммы состояний на стандартной панели инструментов, после чего следует выбрать представление и тип разрабатываемой диаграммы - новая диаграмма состояний. - выделить логическое представление (Logical View) или представление вариантов использования (Use Case View) в браузере проекта и выполнить операцию контекстного меню: New Statechart Diagram (Новая Диаграмма состояний). - раскрыть логическое представление (Logical View) в браузере проекта и выделить рассматриваемый класс, операцию класса, пакет, или раскрыть представление вариантов использования (Use Case View) и выбрать вариант использования, после чего выполнить операцию контекстного меню: New Statechart Diagram (Новая Диаграмма состояний). - выполнить операцию главного меню: Browse State Machine Diagram (Обзор Диаграмма состояний), после чего следует выбрать представление и тип разрабатываемой диаграммы. В результате выполнения этих действий появляется новое окно с чистым рабочим листом диаграммы состояний и специальная панель инструментов, содержащая кнопки с изображением графических элементов модели, необходимых для разработки диаграммы состояний (табл. 1). Назначение отдельных кнопок панели можно узнать из всплывающих подсказок. Таблица 3.1 - Назначение кнопок специальной панели инструментов диаграммы состояний Графическое изображение Всплывающая подсказка Назначение кнопки Selection Tool Превращает изображение курсора в форму стрелки для последующего выделения элементов на диаграмме Text Box Добавляет на диаграмму текстовую область Note Добавляет на диаграмму примечание Anchor Note to Item Добавляет на диаграмму связь примечания с соответствующим графическим элементом диаграммы State Добавляет на диаграмму состояние Start State Добавляет на диаграмму начальное состояние End State Добавляет на диаграмму конечное состояние State Transition Добавляет на диаграмму переход Transition to Self Добавляет на диаграмму рефлексивный переход Horizontal Synchronization Добавляет на диаграмму горизонтально расположенный символ синхронизации (по умолчанию отсутствует) Vertical Synchronization Добавляет на диаграмму вертикально расположенный символ синхронизации (по умолчанию отсутствует) Decision Добавляет на диаграмму символ принятия решения для альтернативных переходов (по умолчанию отсутствует) По умолчанию на специальной панели инструментов могут отсутствовать кнопки с тремя последними графическими элементами из таблицы 1. При необходимости их можно добавить на специальную панель диаграммы состояний аналогично способу, рассмотренному ранее в лабораторной работе №2. 2.1.1 Добавление состояния на диаграмму состояний и редактирование его свойств Для добавления состояния на диаграмму состояний необходимо с помощью левой кнопки мыши нажать кнопку с изображением пиктограммы состояния на специальной панели инструментов, отпустить левую кнопку мыши и щелкнуть левой кнопкой мыши на свободном месте рабочего листа диаграммы. На диаграмме появится изображение состояния с маркерами изменения его геометрических размеров и предложенным средой именем по умолчанию, которое разработчику следует изменить (рис. 3.4). Для добавленного состояния можно открыть диалоговое окно его свойств - двойным щелчком левой кнопкой мыши на изображении этого элемента на диаграмме. В этом случае активизируется диалоговое окно со специальными вкладками, в поля которых можно занести всю информацию по данному состоянию. Рисунок 3.4 – Разработка диаграммы состояния. Добавление состояния Рисунок 3.5 - Диалоговое окно спецификации свойств состояния При необходимости в диалоговом окне спецификации свойств выбранного состояния можно задать вложенное историческое состояние. Для этого следует выставить отметку у свойства State/activity history (Историческое состояние/деятельность) и нажать кнопку Apply. В результате внутри исходного состояния появится вложенное историческое состояние (рис. 3.6 а). а) б) Рисунок 3.6 - Добавление вложенного исторического состояния (а) и состояния глубокой истории (б) для состояния «Ожидание системы» Чтобы обычное историческое состояние превратить в состояние глубокой истории, следует дополнительно выставить отметку у свойства Sub state/activity history (Историческое подсостояние/деятельность), которое становится доступным для редактирования после выбора первого свойства, и нажать кнопку Apply. В результате внутри исходного состояния появится вложенное состояние глубокой истории (рис. 3.6 б). Чтобы обычное состояние превратить в композит, следует при добавлении нового состояния поместить его внутри границы того состояния, которое необходимо сделать композитным. В результате внутри исходного состояния появится новое вложенное состояние с именем NewState, которое при перемещении композита в области диаграммы состояний всегда будет находиться внутри своего композита (рис. 3.7). Рисунок 3.7 – Композитное (составное) состояние Рассмотренные выше действия приведены только с целью иллюстрации особенностей спецификации исторических и вложенных подсостояний. Дополнительно можно определить следующие свойства состояний: задать текстовый стереотип состояния, определить внутренние действия на входе и выходе, а также внутреннюю деятельность. Эти свойства доступны для редактирования на вкладке General (Общие) и Actions (Действия). На вкладке Transitions (Переходы) можно определять и редактировать переходы, которые входят и выходят из рассматриваемого состояния. Последняя вкладка Swimlanes (Дорожки) служит для спецификации дорожек, которые, в контексте языка UML, определяются для диаграммы деятельности. 2.1.2 Добавление перехода и редактирование его свойств Для добавления перехода между двумя состояниями нужно с помощью левой кнопки мыши нажать кнопку с изображением перехода на специальной панели инструментов, отпустить левую кнопку мыши, щелкнуть левой кнопкой мыши на изображении исходного состояния на диаграмме и отпустить ее на изображении целевого состояния. В результате этих действий на диаграмме появится изображение перехода , соединяющего два выбранных состояния (см. рис. 3.8). Рисунок 3.8 - Диаграмма состояний после добавления на нее перехода из начального состояния в состояние «Ожидание системы» После добавления перехода на диаграмму состояний можно открыть диалоговое окно его свойств и специфицировать дополнительные свойства, доступные на соответствующих вкладках (рис. 3.9). Следует обратить внимание на две первые строки вкладки Detail (Подробно), которые представляются наиболее важными из свойств перехода. Первое поле ввода Guard Condition служит для задания сторожевого условия, которое определяет правило срабатывания соответствующего перехода. Во втором поле ввода Action можно специфицировать действие, которое происходит при срабатывании перехода до того, как моделируемая система попадет в целевое состояние. Рисунок 3.9 - Диалоговое окно спецификации свойств перехода, открытое на вкладке Detail (Подробно) При необходимости можно определить сообщение о событии, происходящем при срабатывании перехода, а также визуализировать вложенность состояний и подключить историю отдельных состояний. 3 Пример построения диаграммы состояний На рисунке 3.10 представлен пример диаграммы состояний для объекта класса “Diskr_analiz” (дискриминантного анализа). Рисунок 3.10 - Диаграмма состояний объекта класса “Diskr_analiz” 4 Задание на лабораторное занятие Согласно своему варианту разработать диаграмму состояний для алгоритма вашего метода многомерного статистического анализа. 5 Содержание отчета - титульный лист; - постановка задачи; - диаграмма состояний 6 Контрольные вопросы для защиты лабораторной работы 1. Для чего предназначена диаграмма состояний (Statechart)? 2. Как создать новую диаграмму состояний в среде IBM R Rose 2003? 3. Какие бывают переходы между состояниями? 4. Какие спецификации можно задать для переходов между состояниями? 5. Что такое история состояний? 6. Что такое композитное состояние и как его создать? 7. Какие значки специфичны только для диаграммы состояний, расскажите о назначении каждого из них? 8. Что такое сценарий поведения системы? Для чего его создают? 9. Что такое сторожевое условие? 10. Как настроить панель инструментов, если на ней нет нужных значков? Лабораторная работа № 4 Тема: «Построение диаграммы классов этапа проектирования в среде Rational Rose» Цель работы: 1) Освоить методику построения диаграмм классов; 2) Согласно заданию на лабораторное занятие разработать диаграмму классов. 1 Задание на самоподготовку - изучить лекционный материал по данной теме; - знать методику построения диаграмм классов. 2 Краткие теоретические сведения Class diagram (диаграмма классов) — основная диаграмма для создания кода приложения. При помощи диаграммы классов создается внутренняя структура системы, описывается наследование и взаимное положение классов друг относительно друга. Здесь описывается логическое представление систе­мы. Именно логическое, так как классы — это лишь заготовки, на основе ко­торых затем будут определены физические объекты. Таким образом, диаграмма классов описывает общее представление систе­мы и является противоположной Collaboration diagram, в которой представле­ны объекты системы. Однако такое разделение не является строгим правилом, и возможно смешанное представление классов и объектов. Диаграмма классов используется не только для создания логического пред­ставления системы, Rational Rose позволяет на основе диаграммы классов соз­давать исходный код приложения. А так как описание классов создается на языке UML, то по диаграммам, созданным в едином стиле, возможна генера­ция исходного кода на любом языке программирования, который поддержива­ется генератором кода Rational Rose. Обычно диаграмма классов создается для всех классов системы, в отличие от диаграммы объектов, которую проектировщики создают для отдельных объектов со сложным поведением и взаимодействием. Диаграмма классов содержит значки, представляющие классы, интерфей­сы и их связи. Классы могут представлять любые C++ классы: простые, параметризированные или метаклассы. Интерфейсы — это некоторый набор дейст­вий или операций, который обслуживает взаимодействие реализаций классов. Возможно создание одной или нескольких диаграмм классов, которые опи­сывают классы верхнего уровня в текущей модели. Также возможно создание одной или более диаграмм классов, которые описывают классы, содержащие­ся в пакетах. Так, диаграмма классов сама по себе является пакетом для клас­сов модели, но можно выделить дополнительные пакеты для логической груп­пировки классов. Посредством диаграммы классов возможно изменение в любой момент свойств любого класса или его связей, и при этом диаграммы или специфика­ции, связанные с изменяемым классом, будут автоматически обновлены. 2.1 Особенности разработки диаграмм классов в среде IBM Rational Rose 2003 Диаграмма классов является основным логическим представлением модели и содержит детальную информацию о внутреннем устройстве объектно-ориентированной программной системы или, используя современную терминологию, об архитектуре программной системы. Активизировать рабочее окно диаграммы классов можно несколькими способами: - окно диаграммы классов появляется по умолчанию в рабочем окне диаграммы после создания нового проекта; - щелкнуть на кнопке с изображением диаграммы классов на стандартной панели инструментов; - раскрыть логическое представление (Logical View) в браузере проекта и дважды щелкнуть на пиктограмме Main (Главная); - выполнить операцию главного меню: Browse Class Diagram (Обзор Диаграмма классов ). При этом появляется новое окно с чистым рабочим листом диаграммы классов и специальная панель инструментов, содержащая кнопки с изображением графических примитивов, необходимых для разработки диаграммы классов (табл. 1). Назначение отдельных кнопок панели можно узнать также из всплывающих подсказок. Таблица 4.1 - Назначение кнопок специальной панели инструментов для диаграммы классов Графическое изображение Всплывающая подсказка Назначение кнопки Selection Tool Превращает изображение курсора в форму стрелки для последующего выделения элементов на диаграмме Text Box Добавляет на диаграмму текстовую область Note Добавляет на диаграмму примечание Anchor Note to Item Добавляет на диаграмму связь примечания с соответствующим графическим элементом диаграммы Class Добавляет на диаграмму класс Interfase Добавляет на диаграмму интерфейс Unidirectional Association Добавляет на диаграмму направленную ассоциацию Association Class Добавляет на диаграмму ассоциацию класс Package Добавляет на диаграмму пакет Dependency or Instantiates Добавляет на диаграмму отношение зависимости Generalization Добавляет на диаграмму отношение обобщения Realize Добавляет на диаграмму отношение реализации 2.1.1 Добавление класса на диаграмму классов и редактирование его свойств Для добавления класса на диаграмму классов нужно с помощью левой кнопки мыши нажать кнопку с изображением пиктограммы класса на специальной панели инструментов, отпустить левую кнопку мыши и щелкнуть левой кнопкой мыши на свободном месте рабочего листа диаграммы. На диаграмме появится изображение класса с маркерами изменения его геометрических размеров и предложенным средой именем по умолчанию NewClass. Продолжая разработку модели приложения для АИС «Трудоустройство», в качестве сквозного примера проекта, построим для этой модели следующую диаграмму классов. С этой целью следует изменить предложенное по умолчанию имя диаграммы Main на - Диаграмма классов «Трудоустройство», а имя добавленного на диаграмму класса - на «Matrix» (см. рис. 4.1). Рисунок 4.1 - Диаграмма классов после добавления на нее класса «Matrix» Для класса «Matrix» можно уточнить его назначение в модели с помощью указания стереотипа и пояснительного текста в форме документации. С этой целью двойным щелчком левой кнопкой мыши на изображении этого класса на диаграмме или в браузере проекта следует открыть диалоговое окно спецификации свойств этого класса (рис. 4.2) и на вкладке General (Общие) выбрать из вложенного списка Stereotype стереотип. Рисунок 4.2 - Диалоговое окно спецификации свойств класса Для отдельного класса можно уточнить также и другие его свойства, доступные для редактирования на вкладке Detail (Подробно) окна спецификации свойств этого класса. Например, на этой вкладке с помощью вложенного списка Multiplicity (Кратность) можно задать количество объектов или экземпляров данного класса, для чего следует выбрать строку с буквой n. Данное значение означает, что у класса может быть любое конечное число экземпляров (рис. 4.3). Поле ввода с именем Space (Пространство) служит для указания объема абсолютной или относительной памяти, которая требуется, по оценке разработчика, для реализации каждого объекта данного класса. Применительно к рассматриваемой модели это поле можно оставить пустым. Рисунок 4.3 - Диалоговое окно спецификации свойств класса Далее можно задать устойчивость классов в группе выбора Persistence. При этом выбор свойства Persistent (Устойчивый) означает, что информация об объектах данного класса должна быть сохранена в системе. Выбор свойства Transient (Временный) означает, что нет необходимости сохранять информацию об объектах данного класса в системе после завершения работы программного приложения. Применительно к рассматриваемой модели следует выбрать свойство Persistent. В группе выбора Concurrency (Параллельность) можно специфицировать условия на возможность реализации объектов данного класса в параллельных потоках управления. Для выбора могут быть использованы следующие свойства: Sequential (Последовательный) - свойство по умолчанию, которое означает, что объекты класса будут вести себя нормально только при наличии одного потока управления, т. е. соответствующие операции объектов должны выполняться последовательно. В то же время при наличии нескольких потоков управления стабильное поведение объектов класса не гарантируется. Guarded (Безопасный) - означает, что при наличии нескольких потоков управления объекты класса будут вести себя ожидаемым от них образом. Для этого объекты в различных потоках должны взаимодействовать друг с другом для того, чтобы гарантировать отсутствие конфликта между ними. Active (Активный) - означает, что класс должен иметь свой собственный поток управления. Synchronous (Синхронный) - означает, что объекты класса будут вести себя ожидаемым от них образом при наличии нескольких потоков управления. При этом нет необходимости во взаимодействии объектов в различных потоках управления, поскольку объекты данного класса могут самостоятельно разрешать возможные конфликты. Для того, чтобы специфицировать класс как абстрактный, т.е. не имеющий экземпляров, следует на этой же вкладке выставить отметку в свойстве Abstract (Абстрактный). 2.1.2 Добавление и редактирование атрибутов классов Из всех графических элементов среды IBM Rational Rose 2003 класс обладает максимальным набором свойств, главными из которых являются его атрибуты и операции . Добавить атрибут к созданному ранее классу можно одним из следующих способов: - с помощью операции контекстного меню New Attribute (Новый атрибут ) для класса, выделенного на диаграмме классов. В этом случае активизируется курсор ввода текста в области графического изображения класса на диаграмме. - с помощью операции контекстного меню: New Attribute (Новый Атрибут ) для класса, выделенного в браузере проекта. В этом случае активизируется курсор ввода текста в области иерархического представления класса в браузере проекта под именем соответствующего класса. - с помощью операции контекстного меню Insert (Вставить), вызванного при позиционировании курсора в области открытой вкладки атрибутов в диалоговом окне свойств Class Specification соответствующего класса. После добавления атрибута к классу по умолчанию ему присваивается имя name и некоторый квантор видимости (рис. 4.4). Рисунок 4.4 - Диалоговое окно спецификации свойств класса после добавления нового атрибута Напомним, что имена атрибутов и операций классов должны начинаться со строчной буквы. Видимость атрибутов на диаграмме классов изображается в форме специальных пиктограмм. Используемые пиктограммы видимости изображаются перед именем соответствующего атрибута и имеют следующий смысл (табл. 4.2). Таблица 4.2 - Пиктограммы видимости атрибутов классов Графическое изображение Текстовый аналог Назначение пиктограммы Public Общедоступный или открытый. В нотации языка UML такому атрибуту соответствует знак «+» Protected Защищенный. В нотации языка UML такому атрибуту соответствует знак «#» Private Закрытый. В нотации языка UML такому атрибуту соответствует знак «-» Implementation Реализация. В нотации языка UML такому атрибуту соответствует знак «∼» Для редактирования свойств атрибутов предназначено специальное диалоговое окно спецификации атрибута Class Attribute Specification, которое открывается двойным щелчком мыши на строке выбранного атрибута в окне спецификации свойств класса. В окне свойств отдельного атрибута класса можно задать тип данных атрибута и его начальное значение , а также назначить атрибуту стереотип из раскрывающегося списка или изменить его квантор видимости . Рисунок 4.5 - Диалоговое окно спецификации свойств атрибута 2.1.4 Добавление и редактирование операций классов Функционирование любой системы основано на выполнении отдельными его элементами тех или иных действий. В нашей модели все действия представляются с помощью операций классов. Таким образом, следующий этап разработки диаграммы классов связан со спецификацией операций классов. Добавить операцию к созданному ранее классу можно одним из следующих способов: - с помощью операции контекстного меню New Operation (Новая операция ) для класса, выделенного на диаграмме классов. В этом случае активизируется курсор ввода в области графического изображения класса на диаграмме. - с помощью операции контекстного меню: New Operation (Новая Операция ) для класса, выделенного в браузере проекта. В этом случае активизируется курсор ввода в области иерархического представления класса в браузере под именем соответствующего класса. - с помощью операции контекстного меню Insert (Вставить), вызванного при позиционировании курсора в области открытой вкладки операций в диалоговом окне свойств Class Specification соответствующего класса. После добавления операции к классу по умолчанию ей присваивается имя opname и некоторый квантор видимости . Видимость операций на диаграмме классов также изображается в форме специальных пиктограмм. Используемые пиктограммы видимости изображаются перед именем соответствующей операции и имеют следующий смысл (табл. 4.3). Таблица 4.3 - Пиктограммы видимости операций классов Графическое изображение Текстовый аналог Назначение пиктограммы Public Общедоступный или открытый. В нотации языка UML такому атрибуту соответствует знак «+» Protected Защищенный. В нотации языка UML такому атрибуту соответствует знак «#» Private Закрытый. В нотации языка UML такому атрибуту соответствует знак «-» Implementation Реализация. В нотации языка UML такому атрибуту соответствует знак «∼» Каждая из операций классов имеет собственное диалоговое окно спецификации свойств Operation Specification, которое может быть открыто по двойному щелчку на имени операции на соответствующей вкладке спецификации класса или на имени этой операции в браузере проекта (рис. 4.9). Рисунок 4.6 - Диалоговое окно спецификации свойств операции Для операций классов кроме квантора видимости можно также задать: аргументы и их тип, тип возвращаемого результата , стереотип операции , а также определить протокол и размер, задать исключительные ситуации, специфицировать предусловия и постусловия и целый ряд других свойств. Для отдельной операции эти дополнительные свойства доступны для редактирования на вкладке Detail (Подробно) диалогового окна спецификации свойств выбранной операции (рис. 4.7). Рисунок 4.7 - Диалоговое окно спецификации свойств операции, открытое на вкладке Detail (Подробно) На вкладке Detail в многостраничном поле Arguments (Аргументы) можно определить аргументы редактируемой операции . Для этого следует выполнить операцию контекстного меню Insert (Вставить). После этого в этом поле появится аргумент данной операции с именем по умолчанию argname. Для редактирования свойств аргумента предназначено специальное окно свойств аргумента. На вкладке Detail в поле Protocol (Протокол) можно специфицировать порядок выполнения операций класса, например, указать, что одна операция не может быть вызвана раньше другой. Соответствующий текст в данное поле вводится с клавиатуры и попадает в генерируемый код в форме комментария. В поле Qualification (Квалификация) можно уточнить детали реализации операции , связанные с конкретным языком программирования. Соответствующий текст также вводится в данное поле с клавиатуры и попадает в генерируемый код в форме комментария. Далее на этой же вкладке в полях Size (Размер) и Time (Время) можно специфицировать предполагаемый объем памяти и время, необходимое для выполнения операции . Соответствующая информация попадает в генерируемый код в форме комментария. В группе выбора Concurrency (Параллельность) можно специфицировать условия на возможность параллельного выполнения данной операции . Для выбора могут быть использованы следующие свойства: Sequential (Последовательная) - свойство по умолчанию, которое означает, что данная операция класса может быть выполнена только при наличии одного потока управления, т. е. соответствующая операция класса должна выполняться последовательно. При наличии нескольких потоков управления выполнение данной операции класса не гарантируется. Guarded (Безопасная) - означает, что при наличии нескольких потоков управления выполнение данной операции класса гарантируется только в том случае, когда обеспечено взаимодействие объектов друг с другом в различных потоках. Synchronous (Синхронная) - означает, что выполнение данной операции класса гарантируется при наличии нескольких потоков управления. При этом нет необходимости во взаимодействии объектов в различных потоках управления, поскольку данная операция класса будет выполняться в отдельном потоке управления вплоть до своего завершения. 2.1.5 Добавление ассоциации на диаграмму классов и редактирование ее свойств Добавление на диаграмму ассоциации между двумя классами выполняется следующим образом. На специальной панели инструментов необходимо нажать кнопку с изображением пиктограммы направленной ассоциации и отпустить левую кнопку мыши. Если ассоциация - направленная, то на диаграмме классов надо выделить первый элемент ассоциации или источник, от которого исходит стрелка, и, не отпуская нажатую левую кнопку мыши, переместить ее указатель ко второму элементу отношения или приемнику, к которому направлена стрелка. После перемещения ко второму элементу кнопку мыши следует отпустить, в результате чего на диаграмму классов будет добавлена направленная ассоциация с именем Untitled между двумя выбранными классами (рис. 4.11). Рисунок 4.11 - Фрагмент диаграммы классов после добавления на неё направленной ассоциации Изменим имя для данной ассоциации , предложенное средой по умолчанию. Это можно выполнить с помощью окна спецификации свойств ассоциации . Доступ к диалоговому окну спецификации свойств ассоциации Association Specification можно получить после выделения линии ассоциации на диаграмме классов или в браузере проекта и двойного щелчка на ней левой кнопки мыши (рис. 4.12). Рисунок 4.12 - Диалоговое окно спецификации свойств ассоциации Для задания имени ассоциации следует на вкладке General (Общие) в поле ввода Name (Имя) ввести текст ее имени: Соответствует и нажать кнопку Apply или OK, чтобы сохранить результаты редактирования имени ассоциации . Для ассоциации можно задать также кратность каждого из концов ассоциации , стереотип, использовать ограничения и роли, а также некоторые другие свойства. Если ассоциация является ненаправленной, то порядок выбора классов может быть произвольный, а после добавления ассоциации на диаграмму классов следует изменить значение соответствующего свойства данной ассоциации . С этой целью необходимо перейти на вкладку Role A Detail в окне спецификации свойств ассоциации и убрать отметку у свойства Navigable (Навигация). 2.1.6 Добавление отношений агрегации и композиции на диаграмму классов и редактирование их свойств Агрегация – это частный случай ассоциации, описывающий объекты, состоящие из частей. Например, газонокосилка состоит из ножа, двигателя, нескольких колес и корпуса. Здесь газонокосилка является агрегатом (незакрашенный ромбик), а остальные детали – составляющими частями (стрелка). Композиция – это частный случай агрегации. Композиция подразумевает, что части принадлежат целому. Например, компания, состоящая из отделений, которые в свою очередь, состоят из отделов. - добавить на диаграмму отношение агрегации между двумя классами можно следующими способами: - щелкнуть на кнопке с изображением отношение агрегации на специальной панели инструментов и провести линию агрегации от одного класса к другому. Провести линию ассоциации между выбранными классами и изменить ее свойства таким образом, чтобы превратить данную ассоциацию в агрегацию . В первом случае может оказаться, что по умолчанию на специальной панели инструментов диаграммы классов отсутствует кнопка с пиктограммой агрегации . В этом случае необходимо предварительно добавить ее на панель инструментов одним из описанных ранее способов. Во втором случае следует открыть окно спецификации свойств ассоциации Association Specification и на вкладке деталей соответствующего конца ассоциации выставить отметку в строке выбора Aggregate (Агрегация ). В качестве примера изменим тип созданной ранее ассоциации и сделаем ее агрегацией. С этой целью на вкладке Role В Detail деталей конца ассоциации одного класса следует выставить отметку в строке выбора Aggregate(рис. 4.13). Рисунок 4.13 - Диалоговое окно спецификации свойств ассоциации Соответствующий фрагмент диаграммы классов после изменения ассоциации между классами на отношение агрегации будет иметь следующий вид (рис. 4.14). Рисунок 4.14 - Фрагмент диаграммы классов модели после добавления на нее отношения агрегации Для изображения отношения композиции можно также вначале изобразить обычную ассоциацию , после чего, открыв окно ее свойств на вкладке деталей соответствующего конца ассоциации , выставить отметку в строке выбора Aggregate (Агрегация ) и в секции Containment (Локализация) выбрать опцию By Value (По значению). По умолчанию эта опция не специфицирована, т.е. выставлена отметка опции Unspecified (рис. 4.15). Рисунок 4.15 - Фрагмент диаграммы классов модели после добавления на нее отношения композиции 2.1.7 Добавление отношения обобщения на диаграмму классов и редактирование ее свойств Добавление на диаграмму отношения обобщения между двумя классами выполняется следующим образом. На специальной панели инструментов необходимо нажать кнопку с изображением пиктограммы обобщения и отпустить левую кнопку мыши. Далее на диаграмме классов надо выделить первый элемент обобщения или потомок, от которого исходит стрелка, и, не отпуская нажатую левую кнопку мыши, переместить ее указатель ко второму элементу отношения или предок, к которому направлена стрелка. После перемещения ко второму элементу кнопку мыши следует отпустить, в результате чего на диаграмму классов будет добавлена линия обобщения с именем Untitled между двумя выбранными классами. Пример приведен на рисунке 4.16. Рисунок 4.16 – Пример диаграммы классов после добавления на неё отношения обобщения Изменим имя отношения обобщения , предложенное средой по умолчанию. Это можно выполнить с помощью окна спецификации свойств обобщения . Доступ к диалоговому окну спецификации свойств отношения обобщения Generalize Specification можно получить после выделения линии обобщения на диаграмме классов или в браузере проекта и двойного щелчка на ней левой кнопки мыши (рис. 4.17). Рисунок 4.17 - Диалоговое окно спецификации свойств отношения обобщения Для задания имени обобщения следует на единственной вкладке General (Общие) в поле ввода Name (Имя) ввести текст ее имени: следует и нажать кнопку Apply или OK, чтобы сохранить результаты редактирования имени ассоциации . 3 Пример построения диаграммы классов Рисунок 4.18 – Диаграмма классов для алгоритма дискриминантного анализа 4 Задание на лабораторное занятие Разработайте диаграмму классов для реализации метода многомерного статистического анализа, применяемого в приложении. 5 Контрольные вопросы для защиты лабораторной работы 1. Каково назначение диаграммы классов? 2. Какими способами можно создать диаграмму? 3. Какие инструменты доступны для диаграммы? 4. Какие команды предоставляет контекстное меню класса? 5. Как настроить свойства атрибутов класса? 6. Как настроить свойства методов класса? 7. Какие типы отношений классов вы знаете? Лабораторная работа № 5 Тема: «Генерация кода проектируемого программного обеспечения» Цель работы: 1) Подготовка модели к генерации программного кода; 2) Генерация программного кода на язык С++. 1 Задание на самоподготовку - разработать диаграмму классов (предыдущая лабораторная работа); - знать основы объектно-ориентированного программирования. 2 Краткие теоретические сведения Одно из самых мощных свойств Rational Rose – возможность генерации программного кода, представляющего модель. Варианты генерации программ меняются в зависимости от установленной версии Rose. В настоящее время применяются следующие три различные версии: - Rose Modeler – позволяет создавать модель системы, но не поддерживает генерацию программного кода и обратное проектирование. - Rose Professional – позволяет генерировать программный код на одном языке. - Rose Enterprise – позволяет генерировать программный код на Ada 83, Ada 95, ANSI C++, CORBA, Java, COM, Visual Basic, Visual C++, C++ и XML. Кроме того, поддерживается генерация кода и обратное проектирование баз данных. Весь лабораторный практикум по данной дисциплине построен на изучении Case-средства Rational Rose версии - Enterprise Edition. 2.1 Подготовка к генерации программного кода Процесс генерации программного кода состоит из пяти основных этапов: 1. Проверка модели. 2. Создание компонентов. 3. Отображение классов на компоненты. 4. Установка свойств генерации программного кода. 5. Генерация программного кода. В разных языках не все этапы обязательны. Так, программы, разработанные на языке С++, генерируются и без предварительного создания компонентов. Генерировать код программ на любом языке можно, не выполняя проверки модели, хотя во время генерации это порой приводит к различным ошибкам. Хотя не все этапы обязательны, первые пять из них рекомендуется выполнять до начала процесса генерации. Проверка модели поможет выявить ее неточности и недостатки, нежелательные с точки зрения последующей генерации программ. Этапы, на которых рассматриваются компоненты, - это способ отобразить логическую схему системы на ее физическую реализацию, причем на этих этапах собирается большой объем полезной информации. Если пропустить эти этапы, то для создания компонентов Rose воспользуется пакетной структурой логического представления. 2.1.1 Проверка модели В Rose существует не зависящее от языка средство проверки моделей, применяемое для обеспечения корректности модели перед генерацией программного кода. Такая проверка помогает выявить в модели неточности и ошибки, не позволяющие генерировать программы надлежащим образом. В общем случае проверка модели может выполняться на любом этапе работы над проектом. Однако после завершения разработки графических диаграмм она является обязательной, поскольку позволяет выявить целый ряд ошибок разработчика. К числу таких ошибок и предупреждений относятся, например, не используемые ассоциации и классы, оставшиеся после удаления отдельных графических элементов с диаграмм, а также операции, не являющиеся именами сообщений на диаграммах взаимодействия. Для проверки модели следует выполнить операцию главного меню: Tools Check Model (Инструменты Проверить модель). Результаты проверки разработанной модели на наличие ошибок отображаются в окне журнала. Прежде чем приступить к генерации текста программного кода разработчику следует добиться устранения всех ошибок и предупреждений, о чем должно свидетельствовать чистое окно журнала (рис. 5.1). Рисунок 5.1- Вид журнала при отсутствии ошибок по результатам проверки модели К наиболее распространенным ошибкам относятся, например, сообще­ния на диаграмме Последовательности или Кооперативной диаграмме, не отображенные на операцию, либо объекты этих диаграмм, не отображенные на класс. 2.1.2 Создание компонентов Второй этап процесса генерации программного кода - создание компонентов для классов. Существуют компоненты самых разных типов: файлы исходного программного кода, исполняемые файлы, библиотеки исполнения в реальном времени, компоненты ActiveX, апплеты и т.д. Перед генерацией программ можно отобразить каждый из классов на соответствующий компонент исходного программного кода. После создания компонентов можно добавить зависимости между ними на диаграмме Компонентов. Зависимости между компонентами - это зависимости во время компиляции системы. При генерации программ на C++, Java или Visual Basic выполнять подобный шаг не обязательно. В Java и Visual Basic Rose создаст автоматически соответствующий компонент для каждого из классов. Для создания компонента: 1. Откройте диаграмму Компонентов (Component). 2. С помощью значка Component панели инструментов Diagram введите новый компонент в диаграмму. 2.1.3 Отображение классов на компоненты Каждый компонент исходного кода - это файл с исходным программным кодом для одного или нескольких классов. В C++ каждый класс отображается на два компонента с исходным кодом: файл заголовка и основной файл (тело). В PowerBuilder на один компонент отображается несколько классов. Компонентом с исходным программным кодом в PowerBuilder является файл библиотеки PowerBuilder (.pbl). В Java каждый компонент - это один файл .java. Компоненты также создаются для элементов управления ActiveX, апплетов, файлов DDL, исполняемых файлов, а также других исходных и скомпилированных файлов. Третий этап процесса генерации программного кода - отображение каждого из классов на соответствующие компоненты. В PowerBuilder необходимо отобразить каждый класс на компонент перед генерацией программы, в то время как в C++, Java и Visual Basic этот шаг не является обязательным. Rose может генерировать программный код самостоятельно. При генерации в Rose программ Java и Visual Basic производится еще и генерация нужных компонентов и отображение классов. Однако для C++ компоненты не создаются автоматически, а кроме того, ни для одного из языков не генерируются зависимости. Поэтому рекомендуется выполнять этот шаг независимо от применяемого языка программирования. Для отображения класса на компонент: 1. Щелкните правой кнопкой мыши на компоненте, на диаграмме Компонентов или в браузере. 2. Выберите Open Specification в контекстном меню. 3. Выберите вкладку Realizes (Реализует). 4. Во вкладке Realizes щелкните правой кнопкой мыши на нужном классе (классах) и выберите Assign (Присвоить) в контекстном меню. В браузере имя компонента будет показано в круглых скобках вслед за именем класса в Логическом представлении (Logical view). ИЛИ 1. Найдите класс в окне Logical view браузера. 2. Перетащите класс на нужный компонент в окне Component view. 3. В окне Logical view имя компонента будет показано в круглых скобках за именем класса. 2.1.4 Установка свойств генерации программного кода Для каждого языка в Rose предусмотрен ряд определенных свойств гене­рации программного кода. Можно установить несколько параметров генерации программного кода для классов, атрибутов, компонентов и других элементов модели. Этими свойствами определяется способ генерации программ. В Rose предлагаются общепринятые параметры по умолчанию. 2.1.4.1 Настройка свойств C++ Для того чтобы пользоваться возможностями C++, необходимо описать назначение этих свойств, список которых доступен во вкладке C++ спецификаций класса. (см. рис. 5.2) Рисунок 5.2 – Окно свойств генерации кода на С++ Перед генерацией программного кода рекомендуется анализировать эти свойства и вносить необходимые изменения. Назначение свойств: 1) CodeName - устанавливает имя класса в создаваемом коде. Данное свойство необходимо устанавливать только в том случае, если имя класса должно быть отлично от имени заданного в модели Rational Rose. Данное свойство необходимо использовать для создания работоспособного кода C++, если для классов в модели используются русские имена. 2) ImplementationType - позволяет использовать простые типы вместо определения класса, устанавливаемого Rational Rose по умолчанию. При задании этого параметра создается директива typedef. 3) ClassKey - используется для задания типа класса, такого как class, struct, или union. Если тип не указан, то создается класс. 4) GenerateEmptyRegion - свойство указывает, как будет создаваться пустой раздел protected: None - пустой раздел не будут создан; Preserved - пустой раздел будет создан, если будет установлено свойство «preserve=yes»; Unpreserved — пустой раздел будет создан, если будет установлено свойство «preserve=no»; All — всегда будет создаваться. 5) PutBodiesInSpec - если установлено как true, то в заголовочный файл попадет и описание тела класса. Используется для компиляторов, которым необходимо определение шаблона класса в каждом компилируемом файле. 6) GenerateDefaultConstructor - позволяет установить, необходимо ли создавать конструктор для класса по умолчанию. Может принимать следующие значения: DeclareAndDefine - создается определение для конструктора и скелет конструктора в теле класса; Declare Only - создается только определение; DoNotDeclare - не создается ни определения, ни скелета конструктора. 7) DefaultConstructorVisibility - устанавливает раздел, в котором будет определен конструктор по умолчанию: public, protected, private, implementation. 8) InlineDefaultConstructor - устанавливает, будет ли конструктор по умолчанию создаваться как inline подстановка. Если конструктора по умолчанию нет, то данное свойство не оказывает на код никакого эффекта. 9) ExplicitDefaultConstructor - устанавливает конструктор по умолчанию как explicit (явно заданный). 10) InlineRelationalOperations - определяет, будут ли функции операторов сравнения создаваться как inline подстановка. 11) GenerateStorageMgmtOperations - определяет, будут ли переопределяться операторы new и delete в классе. 12) StorageMgmtVisibility - определяет раздел, в который будут помещены операторы new и delete. 13) InlineStorageMgmtOperations - определяет, будут ли операторы new и delete определены как inline подстановка. 14) GenerateSubscriptOperation - определяет, будет ли переопределен оператор []. 15) Subscript Visibility определяет - раздел, в который будет помещен оператор []. 16) SubscriptKind - определяет вид функций оператора []: Common - обычная, Virtual - виртуальная, Abstract - абстрактная. 17) SubscriptResultType - определяет тип возвращаемого выражения для оператора []. 18) InlineSubscriptOperation - определяет, будет ли оператор [] определен как inline подстановка. 19) GenerateDereferenceOperation - определяет, будет ли переопределен оператор *. 20) Dereference Visibility - определяет раздел, в который будет помещен оператор *. 21) DereferenceKind - определяет вид функций оператора *: Common - обычная, Virtual - виртуальная, Abstract - абстрактная. 22) DereferenceResultType - определяет тип возвращаемого выражения для оператора *. 23) InlineDereferenceOperation - определяет, будет ли оператор * определен, как inline подстановка. 24) GeneratelndirectionOperation - определяет, будет ли переопределен оператор ->. 25) IndirectionVisibility - определяет раздел, в который будет помещен оператор ->. 26) IndirectionKind - определяет вид функций оператора ->: Common - обычная, Virtual - виртуальная, Abstract - абстрактная. 27) IndirectionResultType - определяет тип возвращаемого выражения для оператора ->. 28) InlinelndirectionOperation - определяет, будет ли оператор -> определен как inline подстановка. 29) GenerateStreamOperations - определяет, будут ли переопределены операторы потоков (« и »). 2.1.5 Выбор класса, компонента или пакета При генерации программного кода за один раз можно создать класс, компонент или целый пакет. Программный код генерируется с помощью диаграммы или браузера. При генерации кода из пакета можно выбрать либо пакет Логического представления на диаграмме Классов, либо пакет представления Компонентов на диаграмме Компонентов. При выборе пакета Логического представления генерируются все его классы. При выборе пакета представления Компонентов генерируются все его компоненты. Программный код можно генерировать одновременно для нескольких классов, компонентов или пакетов. На диаграмме с помощью клавиши Ctrl выберите классы, компоненты или пакеты, для которых нужно сгенерировать программный код, а затем - соответствующую команду генерации в меню. 2.1.6 Генерация программного кода Если у вас установлены Rose Professional или Rose Enterprise, то в меню Tools предлагается несколько вариантов, специфичных для конкретного языка программирования (см. рис. 5.3). Рисунок 5.3 - Пункты меню генерации кода Чтобы показать или скрыть эти пункты меню, выберите пункт Add-Ins → Add-Ins (Надстройки → Менеджер надстроек). В диалоговом окне Add-In Manager (см. рис. 5.4) с помощью флажков покажите или скройте нужные варианты для различных языков. Рисунок 5.4 - Менеджер надстроек Add-Ins Генерация программного кода в среде IBM Rational Rose 2003 возможна для отдельного класса или компонента. Для этого нужный элемент модели предварительно следует выделить в браузере проекта и выполнить операцию контекстного меню: Tools→C++→Code Generation - (Язык C++→Генерировать код). В результате этого будет открыто диалоговое окно с предложением выбора классов для генерации программного кода на выбранном языке программирования (рис. 5.5). После выбора соответствующих классов и нажатия кнопки OK программа IBM Rational Rose 2003 выполняет кодогенерацию. Рисунок 5.5 - Окно выбора классов для генерации программного кода Затем происходит компиляция и выдается окно статуса (Code Generation Status). Здесь можно увидеть информацию о том, какой класс был закодирован и количество ошибок и предупреждений (рис. 5.6). Если у вас произошла, какая-либо ошибка или же предупреждение, то их можно увидеть на рабочем поле в Rational Rose, для этого и существует самое нижнее окно, в нем передаются все ваши действия и ошибки, произошедшие в ходе кодогенерации. Рисунок 5.6 – Окно статуса компиляции 2.1.7 Результаты генерации В результате кодогенерации Rational Rose создает два файла с расширением “.h” и “.cpp”, названия у них те же, что и название класса. Итак, выполнив эти действия, нажимаем правой клавишей на класс, появляется окошко, в нем ищем “С++”, и видим два пункта Browse Header и Browse Body, и в зависимости от того какой из файлов нам нужен “.h” (заголовочный) или “.cpp” (непосредственно реализация), выбираем их. Эти файлы открываются с помощью блокнота и теперь легко можно увидеть скелет класса, с различными комментариями, которые писали вы на диаграммах, и комментарии которые вставляет сама Rose. Теперь можно открыть один из файлов в С++ и доработать класс, описать работу функций, добавить различные нововведения. Следует заметить, что при установленной на компьютер разработчика интегрированной среды сгенерированные файлы с текстом программного кода автоматически открываются в этой среде после двойного щелчка на пиктограмме этих файлов. Тем не менее, лучше копировать содержимое этих файлов в предварительно созданные программные проекты для полного контроля в этих средах процесса программирования и отладки приложений. Сгенерированные программой IBM Rational Rose 2003 файлы с текстом программного кода содержат минимум информации. Для включения дополнительных элементов в программный код следует изменить свойства генерации программного кода, установленные по умолчанию. В заключение следует отметить, что эффект от использования средства IBM Rational Rose 2003 проявляется при разработке масштабных проектов в составе команды или проектной группы. Однако ситуация покажется не столь тривиальной, когда станет необходимо выполнить проект с несколькими десятками вариантов использования и сотней классов . Именно для подобных проектов явно выявляется преимущество использования средства IBM Rational Rose 2003 и нотации языка UML для документирования и реализации соответствующих моделей. 3 Пример сгенерированного кода на язык программирования С++ {Class Diskr_analiz} //## begin module%1.5%.codegen_version preserve=yes // Read the documentation to learn more about C++ code generator // versioning. //## end module%1.5%.codegen_version //## begin module%470F79570399.cm preserve=no // %X% %Q% %Z% %W% //## end module%470F79570399.cm //## begin module%470F79570399.cp preserve=no //## end module%470F79570399.cp //## Module: Diskr_analiz%470F79570399; Pseudo Package body //## Source file: C:\Program Files\Rational\Rose\C++\source\Diskr_analiz.cpp //## begin module%470F79570399.additionalIncludes preserve=no //## end module%470F79570399.additionalIncludes //## begin module%470F79570399.includes preserve=yes //## end module%470F79570399.includes // Diskr_analiz #include "Diskr_analiz.h" //## begin module%470F79570399.additionalDeclarations preserve=yes //## end module%470F79570399.additionalDeclarations // Class Diskr_analiz Diskr_analiz::Diskr_analiz() //## begin Diskr_analiz::Diskr_analiz%470F79570399_const.hasinit preserve=no //## end Diskr_analiz::Diskr_analiz%470F79570399_const.hasinit //## begin Diskr_analiz::Diskr_analiz%470F79570399_const.initialization preserve=yes //## end Diskr_analiz::Diskr_analiz%470F79570399_const.initialization { //## begin Diskr_analiz::Diskr_analiz%470F79570399_const.body preserve=yes //## end Diskr_analiz::Diskr_analiz%470F79570399_const.body } Diskr_analiz::Diskr_analiz(const Diskr_analiz &right) //## begin Diskr_analiz::Diskr_analiz%470F79570399_copy.hasinit preserve=no //## end Diskr_analiz::Diskr_analiz%470F79570399_copy.hasinit //## begin Diskr_analiz::Diskr_analiz%470F79570399_copy.initialization preserve=yes //## end Diskr_analiz::Diskr_analiz%470F79570399_copy.initialization { //## begin Diskr_analiz::Diskr_analiz%470F79570399_copy.body preserve=yes //## end Diskr_analiz::Diskr_analiz%470F79570399_copy.body } Diskr_analiz::~Diskr_analiz() { //## begin Diskr_analiz::~Diskr_analiz%470F79570399_dest.body preserve=yes //## end Diskr_analiz::~Diskr_analiz%470F79570399_dest.body } Diskr_analiz & Diskr_analiz::operator=(const Diskr_analiz &right) { //## begin Diskr_analiz::operator=%470F79570399_assign.body preserve=yes //## end Diskr_analiz::operator=%470F79570399_assign.body } int Diskr_analiz::operator==(const Diskr_analiz &right) const { //## begin Diskr_analiz::operator==%470F79570399_eq.body preserve=yes //## end Diskr_analiz::operator==%470F79570399_eq.body } int Diskr_analiz::operator!=(const Diskr_analiz &right) const { //## begin Diskr_analiz::operator!=%470F79570399_neq.body preserve=yes //## end Diskr_analiz::operator!=%470F79570399_neq.body } //## Other Operations (implementation) void Diskr_analiz::Vector_DF () { //## begin Diskr_analiz::Vector_DF%470F7D1003D8.body preserve=yes //## end Diskr_analiz::Vector_DF%470F7D1003D8.body } void Diskr_analiz::Vector_zn_DF () { //## begin Diskr_analiz::Vector_zn_DF%470F7FB703A9.body preserve=yes //## end Diskr_analiz::Vector_zn_DF%470F7FB703A9.body } void Diskr_analiz::Const_diskr () { //## begin Diskr_analiz::Const_diskr%470F800F037A.body preserve=yes //## end Diskr_analiz::Const_diskr%470F800F037A.body } void Diskr_analiz::Rasch_zn_DF () { //## begin Diskr_analiz::Rasch_zn_DF%470F802C005D.body preserve=yes //## end Diskr_analiz::Rasch_zn_DF%470F802C005D.body } // Additional Declarations //## begin Diskr_analiz%470F79570399.declarations preserve=yes //## end Diskr_analiz%470F79570399.declarations //## begin module%470F79570399.epilog preserve=yes //## end module%470F79570399.epilog {Class Kovar_matrix} //## begin module%1.5%.codegen_version preserve=yes // Read the documentation to learn more about C++ code generator // versioning. //## end module%1.5%.codegen_version //## begin module%470F792B01A5.cm preserve=no // %X% %Q% %Z% %W% //## end module%470F792B01A5.cm //## begin module%470F792B01A5.cp preserve=no //## end module%470F792B01A5.cp //## Module: Kovar_matrix%470F792B01A5; Pseudo Package body //## Source file: C:\Program Files\Rational\Rose\C++\source\Kovar_matrix.cpp //## begin module%470F792B01A5.additionalIncludes preserve=no //## end module%470F792B01A5.additionalIncludes //## begin module%470F792B01A5.includes preserve=yes //## end module%470F792B01A5.includes // Kovar_matrix #include "Kovar_matrix.h" //## begin module%470F792B01A5.additionalDeclarations preserve=yes //## end module%470F792B01A5.additionalDeclarations // Class Kovar_matrix Kovar_matrix::Kovar_matrix() //## begin Kovar_matrix::Kovar_matrix%470F792B01A5_const.hasinit preserve=no //## end Kovar_matrix::Kovar_matrix%470F792B01A5_const.hasinit //## begin Kovar_matrix::Kovar_matrix%470F792B01A5_const.initialization preserve=yes //## end Kovar_matrix::Kovar_matrix%470F792B01A5_const.initialization { //## begin Kovar_matrix::Kovar_matrix%470F792B01A5_const.body preserve=yes //## end Kovar_matrix::Kovar_matrix%470F792B01A5_const.body } Kovar_matrix::Kovar_matrix(const Kovar_matrix &right) //## begin Kovar_matrix::Kovar_matrix%470F792B01A5_copy.hasinit preserve=no //## end Kovar_matrix::Kovar_matrix%470F792B01A5_copy.hasinit //## begin Kovar_matrix::Kovar_matrix%470F792B01A5_copy.initialization preserve=yes //## end Kovar_matrix::Kovar_matrix%470F792B01A5_copy.initialization { //## begin Kovar_matrix::Kovar_matrix%470F792B01A5_copy.body preserve=yes //## end Kovar_matrix::Kovar_matrix%470F792B01A5_copy.body } Kovar_matrix::Kovar_matrix () //## begin Kovar_matrix::Kovar_matrix%470F7A3501C5.hasinit preserve=no //## end Kovar_matrix::Kovar_matrix%470F7A3501C5.hasinit //## begin Kovar_matrix::Kovar_matrix%470F7A3501C5.initialization preserve=yes //## end Kovar_matrix::Kovar_matrix%470F7A3501C5.initialization { //## begin Kovar_matrix::Kovar_matrix%470F7A3501C5.body preserve=yes //## end Kovar_matrix::Kovar_matrix%470F7A3501C5.body } Kovar_matrix::~Kovar_matrix() { //## begin Kovar_matrix::~Kovar_matrix%470F792B01A5_dest.body preserve=yes //## end Kovar_matrix::~Kovar_matrix%470F792B01A5_dest.body } Kovar_matrix & Kovar_matrix::operator=(const Kovar_matrix &right) { //## begin Kovar_matrix::operator=%470F792B01A5_assign.body preserve=yes //## end Kovar_matrix::operator=%470F792B01A5_assign.body } int Kovar_matrix::operator==(const Kovar_matrix &right) const { //## begin Kovar_matrix::operator==%470F792B01A5_eq.body preserve=yes //## end Kovar_matrix::operator==%470F792B01A5_eq.body } int Kovar_matrix::operator!=(const Kovar_matrix &right) const { //## begin Kovar_matrix::operator!=%470F792B01A5_neq.body preserve=yes //## end Kovar_matrix::operator!=%470F792B01A5_neq.body } //## Other Operations (implementation) void Kovar_matrix::Sovm_kov_matrix () { //## begin Kovar_matrix::Sovm_kov_matrix%470F7A5E02EE.body preserve=yes //## end Kovar_matrix::Sovm_kov_matrix%470F7A5E02EE.body } // Additional Declarations //## begin Kovar_matrix%470F792B01A5.declarations preserve=yes //## end Kovar_matrix%470F792B01A5.declarations //## begin module%470F792B01A5.epilog preserve=yes //## end module%470F792B01A5.epilog {Class_Matrix} //## begin module%1.5%.codegen_version preserve=yes // Read the documentation to learn more about C++ code generator // versioning. //## end module%1.5%.codegen_version //## begin module%470F762F032C.cm preserve=no // %X% %Q% %Z% %W% //## end module%470F762F032C.cm //## begin module%470F762F032C.cp preserve=no //## end module%470F762F032C.cp //## Module: Matrix%470F762F032C; Pseudo Package body //## Source file: C:\Program Files\Rational\Rose\C++\source\Matrix.cpp //## begin module%470F762F032C.additionalIncludes preserve=no //## end module%470F762F032C.additionalIncludes //## begin module%470F762F032C.includes preserve=yes //## end module%470F762F032C.includes // Matrix #include "Matrix.h" //## begin module%470F762F032C.additionalDeclarations preserve=yes //## end module%470F762F032C.additionalDeclarations // Class Matrix Matrix::Matrix() //## begin Matrix::Matrix%470F762F032C_const.hasinit preserve=no //## end Matrix::Matrix%470F762F032C_const.hasinit //## begin Matrix::Matrix%470F762F032C_const.initialization preserve=yes //## end Matrix::Matrix%470F762F032C_const.initialization { //## begin Matrix::Matrix%470F762F032C_const.body preserve=yes //## end Matrix::Matrix%470F762F032C_const.body } Matrix::Matrix(const Matrix &right) //## begin Matrix::Matrix%470F762F032C_copy.hasinit preserve=no //## end Matrix::Matrix%470F762F032C_copy.hasinit //## begin Matrix::Matrix%470F762F032C_copy.initialization preserve=yes //## end Matrix::Matrix%470F762F032C_copy.initialization { //## begin Matrix::Matrix%470F762F032C_copy.body preserve=yes //## end Matrix::Matrix%470F762F032C_copy.body } Matrix::~Matrix() { //## begin Matrix::~Matrix%470F762F032C_dest.body preserve=yes //## end Matrix::~Matrix%470F762F032C_dest.body } Matrix & Matrix::operator=(const Matrix &right) { //## begin Matrix::operator=%470F762F032C_assign.body preserve=yes //## end Matrix::operator=%470F762F032C_assign.body } int Matrix::operator==(const Matrix &right) const { //## begin Matrix::operator==%470F762F032C_eq.body preserve=yes //## end Matrix::operator==%470F762F032C_eq.body } int Matrix::operator!=(const Matrix &right) const { //## begin Matrix::operator!=%470F762F032C_neq.body preserve=yes //## end Matrix::operator!=%470F762F032C_neq.body } //## Other Operations (implementation) void Matrix::Proizv () { //## begin Matrix::Proizv%470F7891009C.body preserve=yes //## end Matrix::Proizv%470F7891009C.body } void Matrix::Standart () { //## begin Matrix::Standart%470F78AC0242.body preserve=yes //## end Matrix::Standart%470F78AC0242.body } void Matrix::Obratn () { //## begin Matrix::Obratn%470F78C3006D.body preserve=yes //## end Matrix::Obratn%470F78C3006D.body } void Matrix::Transp () { //## begin Matrix::Transp%470F78D00177.body preserve=yes //## end Matrix::Transp%470F78D00177.body } // Additional Declarations //## begin Matrix%470F762F032C.declarations preserve=yes //## end Matrix%470F762F032C.declarations //## begin module%470F762F032C.epilog preserve=yes //## end module%470F762F032C.epilog 4 Задание на лабораторное занятие 1. Сгенерировать программный код на С++ для диаграммы классов, разработанной вами в предыдущей лабораторной работе. 5 Содержание отчета - титульный лист; - постановка задачи; - листинг сгенерированного кода; - вывод. 6 Контрольные вопросы 1. Какие диаграммы необходимо предварительно разработать, чтобы выполнить кодогенерацию? 2. Как посмотреть исходный код? 3. Какие установки свойств доступны на вкладке C++? 4. Какова структура создаваемого кода? 5. Что необходимо добавить в шаблоны классов для получения работоспособного приложения? 6. Какие шаги нужно предпринять для обновления модели по исходному коду? 7. Какие основные этапы кодогенерации вы знаете? Расскажите кратко о каждом из них?