tema_6,doc

Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 1 из
12
Тема 6. Построение модели средствами UML и ее реализация в CASEинструментах
1. Основные диаграммы языка и модель проблемной области в нотации UML
2. Частичный пример построения модели
3. Инструментальные средства реализации модели: Rational Rose
1. Основные диаграммы языка и модель проблемной области в нотации UML
В языке определены следующие виды диаграмм:
 диаграмма вариантов использования, в ряде источников называемая диаграммой
прецедентов (use case diagram);
 диаграмма классов (class diagram);
 диаграммы поведения (behavior diagrams);
 диаграммы взаимодействия (interaction diagrams);
 диаграмма кооперации (collaboration diagram);
 диаграмма последовательности (sequence diagram);
 диаграмма состояний (statechart diagram);
 диаграмма деятельности (acivity diagram);
 диаграммы реализации (implementation diagrams);
 диаграмма компонентов (component diagram);
 диаграмма развертывания (deployment diagram).
Выделенные жирным курсивом диаграммы используются в языке UML в качестве самостоятельных, другие же служат для обозначения подвидов диаграмм.
Перечень этих диаграмм является каноническим и представляет собой неотъемлемую часть языка. Процесс ООАП реализуется через посредство построения таких диаграмм. При этом совокупность построенных канонических диаграмм содержит всю информацию, необходимую для реализации проекта сложной системы.
Диаграмма вариантов использования являет собой наиболее общую концептуальную модель
сложной системы, которая является исходной для построения всех остальных диаграмм.
Диаграмма классов является по своей сути логической моделью, отражающей статические аспекты сложной системы.
Диаграммы, описывающие поведение, также являются разновидностями логической модели и отражают динамические аспекты функционирования сложной системы.
Диаграммы, отображающие программную реализацию (последние три), служат для представления физических компонентов системы и относятся к физической модели.
Интегрированная модель сложной системы в нотации UML может быть представлена в виде совокупности перечисленных выше диаграмм (см. ниже рис. 6.1).
Хотя последовательность построения диаграмм в языке не определена, приведенный порядок
диаграмм соответствует порядку их построения согласно рекомендациям RUP1 и оправдывает себя на практике.
Количество типов диаграмм для конкретной модели приложения не является строго фиксированным. Перечень используемых диаграмм зависит от специфики конкретного проекта.
Как было сказано в теме 5, процесс ООАП, а, следовательно, и визуальное моделирование с использованием нотации UML, представляет собой процесс поуровневого спуска от наиболее общих
моделей и представлений концептуального уровня к более детальным представлениям логического и физического уровней.
1
Rational Unified Process, см. тему 5
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 2 из
12
Возможности нотации языка будут проиллюстрированы на примере построения отдельных диаграмм.
диаграмма классов
диаграмма
кооперации
Исходная концептуальная модель.
Описывает функциональное назначение системы
представление
структуры
взаимодействие
классов структурного характера
диаграмма
компонентов
архитектура
программной
реализации
Статическое
представление
диаграмма вариантов использования
диаграмма
состояний
диаграмма
деятельности
диаграмма последовательности
процесс изменения
состояний
частный случай диаграммы состояний
диаграмма
развертывания
представление
компонентов
программы,
существующих
на этапе выполнения
Динамическое
представление
Интегрированная модель
сложной системы
временной аспект поведения
Концептуальное и логическое представление
Физическое представление
Рис. 6.1. Интегрированная модель сложной системы в нотации UML
2. Частичный пример построения модели
Мы рассмотрим часть примера построения модели системы управления банкоматом, например,
банкоматом Сбербанка РФ, взятого из кн. Леоненкова. Цель примера – продемонстрировать суть
использования и основные выразительные возможности языка UML.
Рассматривается система организации взаимодействия клиента и банка при выполнении основных
транзакций.
Ограничимся диаграммой вариантов использования как наиболее общей, описывающей функционирование системы, и диаграммой классов как одной из важнейших и, кроме того, переводимой в
программный код CASE-средствами.
2.1. Диаграмма вариантов использования (use case diagram)
 Разработка диаграммы вариантов использования преследует цели:
- определить общие границы и контекст моделируемой предметной области;
- сформулировать общие требования к функциональному поведению проектируемой системы;
- разработать исходную концептуальную модель системы;
- подготовить документацию для взаимодействия разработчиков системы с ее заказчиками и
пользователями.
 Диаграмма вариантов использования для системы управления банкоматом приведена на рис.
6.2. Пояснения к отдельным элементам рисунка сделаны в затененных выносках. Определения
основных понятий и текстовые пояснения следуют за рисунком.
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 3 из
12
Примечание
Снятие наличных по
кредитной карточке
<<include>>
Актер
Актер
Базовые варианты использования
Клиент
Отношение
ассоциации
Проверка ПИН-кода
Банк
<<include>>
Отношение
включения
Получение справки о
состоянии счета
Рис. 6.2. Диаграмма вариантов использования для системы управления банкоматом
 Базовые элементы диаграммы – актер, вариант использования и отношение. Дополнительные
элементы – примечания (для любой диаграммы).
Актер (Actor), или действующее лицо – любой объект, субъект или система, взаимодействующая
с моделируемой системой извне так, как определит сам разработчик.
Рассматриваемая система включает двух актеров, взаимодействующих с банкоматом, – Клиента и
Банк. Здесь Клиент является главным актером, так как он инициирует деятельность банкомата;
банку же предоставляется информация о результатах функционирования банкомата, и в этом контексте он является второстепенным актером.
Вариант использования (Use Case) – описание некоторого аспекта поведения проектируемой
системы без указания особенностей реализации данной функциональности. В этом смысле каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая система по запросу актера, т.е. одному из способов применения системы.
Содержание варианта использования может быть представлено в форме дополнительного пояснительного текста – текста-сценария, или просто сценария. Для написания сценариев методологией RUP предлагаются определенные шаблоны. Далее рассматривается один из таких шаблонов.
На диаграмме рис. 6.2 отмечены базовые варианты использования: Снятие наличных по кредитной карточке и Получение справки о состоянии счета. Оба варианта обращаются к отдельному
дополнительному сервису (варианту использования) – Проверка ПИН-кода.
Отношения отображают взаимодействие экземпляров одних актеров и вариантов использования
с экземплярами других.
В языке имеется несколько видов стандартных отношений между актерами и вариантами использования:
 отношение ассоциации (association relationship); одно из фундаментальных понятий языка, используемое при построении всех моделей систем; служит для обозначения специфической роли актера при взаимодействии с отдельным вариантом использования;
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 4 из
12
 отношение включения ( include relationship); указывает, что некоторое заданное поведение для одного варианта использования (включаемого) входит в качестве составного
фрагмента в поведение другого варианта (базового);
 отношение расширения ( extend relationship); определяет взаимосвязь базового варианта
использования с некоторым другим, функциональное поведение которого задействуется
базовым вариантом не всегда;
 отношение обобщения (generalization relationship); указывает, что некоторый вариант использования является специальным случаем (потомком) другого варианта использования (предка).
На рис. 6.2 актеры и базовые варианты использования связаны отношениями ассоциации. Оба
базовых варианта использования связаны с дополнительным вариантом (Проверка ПИН-кода) отношением включения, которое помечено стереотипом <<include>>.
Примечание (note) может содержать любую текстовую информацию. Если примечание относится
к определенному элементу диаграммы, то оно соединяется с этим элементом пунктирной линией.
На рисунке в диаграмму вставлено пустое примечание к отношению ассоциации.
 Текстовые сценарии вариантов использования отображают особенности поведения сложной системы, уточняют или детализируют последовательность действий, связанных с определенным вариантом использования. Разработчики языка настоятельно рекомендуют использовать сценарии, так как многие из них считают, что изобразительных средств языка явно недостаточно для
описания многих упомянутых особенностей.
Ниже приведен один из базы шаблонов RUP для написания сценариев (табл. 6.1).
Таблица 6.1. Шаблон для написания сценария отдельного варианта использования
Главный раздел
Раздел
«Типичный ход событий»
Имя варианта использования
Типичный ход событий,
приводящий к успешному
варианту использования
Актеры
Цель
Раздел
«Исключения»
Раздел
«Примечания»
Исключение № 1
Исключение № 2
Примечания
Краткое описание
Тип
Исключение № 3
Ссылки на другие варианты использования
Напишем сценарий для варианта использования Снятие наличных по кредитной карточке. Пусть
сценарий будет представлен в виде отдельных таблиц, каждая из которых соответствует определенному разделу шаблона. Раздел «Примечания» опустим.
Таблица 6.2. Снятие наличных по кредитной карточке. Главный раздел
Вариант использования
Снятие наличных по кредитной карточке
Актеры
Клиент, Банк
Цель
Получение требуемой суммы наличными
Краткое описание
Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту наличные
Тип
Базовый
Ссылки на другие варианты
использования
Включает в себя вариант использования Проверка ПИН-кода
кредитной карточки
В следующей таблице отметим каждое действие его порядковым номером в общей последовательности.
Таблица 6.3. Снятие наличных по кредитной карточке. Раздел «Типичный ход событий»
Типичный ход событий
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 5 из
12
Действия актера
Отклик системы
1. Клиент вставляет кредитную карточку в
устройство чтения банкомата
2. Банкомат проверяет кредитную карточку
3. Банкомат предлагает ввести ПИН-код
Исключение № 1: кредитная карточка недействительна или неверно вставлена
4. Клиент вводит персональный ПИН-код
5. Банкомат проверяет ПИН-код
Исключение № 2: Клиент вводит неверный
ПИН-код
6. Банкомат отображает опции меню
.........
............
Таблица 6.4. Снятие наличных по кредитной карточке. Раздел «Исключения»
Действия актера
Отклик системы
Исключение № 1. Кредитная карточка недействительна или неверно вставлена
3. Банкомат отображает информацию о неверно
вставленной кредитной карточке
14. Банкомат предлагает клиенту забрать его
кредитную карточку
15. Клиент получает свою кредитную карточку
Исключение № 2: Клиент вводит неверный ПИН-код
6. Банкомат отображает информацию о неверном ПИН-коде
4. Клиент вводит новый персональный ПИН-код
.........
.........
Этот сценарий является элементом документации проекта; далее будет показано, каким образом
такая документация включается в проект.
2.2. Диаграмма классов
Поскольку предполагается программная реализация разрабатываемой модели (прежде всего диаграммы классов), имена классов, атрибутов и операций должны быть записаны символами латиницы. На иллюстрации для наглядности запишем эти имена по-русски, а при создании диаграммы
в Rational Rose используем транслитерацию соответствующих имен.
Диаграмма классов системы управления банкоматом приведена на рис. 6.3.
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 6 из
12
<<boundary>>
УстройствоЧтения
Имя класса
– значениеПИНкода
– номерСчетаКлиента
Атрибуты
+ прочитатьПИНкод()
+ прочитатьНомерСчета()
+ извлечьКарту()
Операции
Стереотип
класса
<<interface >>
КонтроллерБанка
Квантор
видимости
+ проверитьПИНкод()
+ проверитьНомерСчета()
+ открытьСчет()
+ УменьшитьСчет()
1
1
Аутентифицирует клиента
и выполняет транзакции
Считывает
информацию
1
Кратность
отношения
*
<<control>>
КонтроллерБанкомата
1
Отображает
информацию
1
1
1
<<boundary>>
ЭкранБанкомата
+ показатьМенюОпций()
+ показатьМенюСуммы()
1
Выдает наличные
Печатает справку
<<boundary>>
ПринтерБанкомата
+ печатьСправки()
1
<<boundary>>
УстройствоПолучения
Наличных
+ выдатьНаличные()
Рис. 6.3. Диаграмма классов системы управления банкоматом
3. Инструментальные средства реализации модели: Rational Rose
3.1. Основные этапы работы над проектом с использованием CASE-средств, базирующихся
на методологии ООАП
 Построение модели
 Проверка ее правильности и согласованности свойств
 Выбор класса, компонента или пакета
 Генерация кода на одном из выбранных языков программирования
 Доработка кода в той или иной среде программирования и получение исполнимых модулей
программы, ориентированной на работу в определенной операционной среде и вычислительной платформе.
3.2. Общая характеристика CASE-средства Rational Rose
 Назначение
Rational Rose - CASE-средство фирмы IBM Rational Software Corporation (США). Предназначено:
 для автоматизации этапов анализа и проектирования ПО;
 для генерации кодов на различных языках;
 для выпуска проектной документации.
Rational Rose базируется на методологии объектно-ориентированного анализа и проектирования и
в качестве нотации использует язык UML. Позволяет разрабатывать проектную документацию в
виде диаграмм и спецификаций, а также генерировать программные коды на ряде языков объектно-ориентированного программирования, основным из которых является С++. Кроме того, Rational
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 7 из
12
Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование
программных компонентов в новых проектах.
 Структура и функции
В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций,
определяющих логическую и физическую структуры модели и ее статические и динамические аспекты так, как это описано в п. 1.
В составе Rational Rose можно выделить 6 основных структурных компонентов:
 репозиторий;
 графический интерфейс пользователя;
 средства просмотра проекта (browser);
 средства контроля проекта;
 средства автоматической генерации кодов программ;
 средства сбора статистики;
 генератор документов.
К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++,
обеспечивающий реинжиниринг – восстановление модели проекта по исходным текстам программ.
Репозиторий представляет собой объектно-ориентированную базу данных. Средства просмотра
обеспечивают "навигацию" по проекту, в том числе, перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д.
Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания.
Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.
Средства автоматической генерации кодов программ (прежде всего на языке С++ как базовом),
используя информацию, содержащуюся в логической и физической моделях проекта, формируют
файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет
программы может быть уточнен путем прямого программирования на языке С++.
Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных
проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация
должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонентов.
 В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:
 диаграммы перечисленных в п. 1 видов;
 спецификации классов, объектов, атрибутов и операций
 заготовки текстов программ;
 модель разрабатываемой программной системы.
Последний из перечисленных документов является текстовым файлом, содержащим всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций).
Тексты программ являются заготовками для последующей работы программистов. Они формируются в рабочем каталоге в виде файлов типов .h (заголовки, содержащие описания классов) и .cpp
(заготовки программ для методов). Система включает в программные файлы собственные комментарии, которые начинаются с последовательности символов //##. Состав информации, вклю-
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 8 из
12
чаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы.
 Среда функционирования
Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC
stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).
Совместимость по версиям обеспечивается на уровне моделей.
3.3. Работа с Rational Rose. Пример построения модели
 Рабочий интерфейс инструмента Rational Rose (рис. 6.4)
Окно браузера проекта
Главное меню
Стандартная панель инструментов
Рабочая область изображения диаграммы
Окно документации
Специальная панель инструментов. Определяется
выбором вида разрабатываемой диаграммы
Окно журнала
Выбранный язык кодирования
Рис. 6.4 . Общий вид рабочего интерфейса инструмента Rational Rose 2003
 Разработка диаграммы вариантов использования
1. Создание нового проекта
File/New; отказаться от мастера типовых проектов.
Появляется рабочий интерфейс с чистым окном активной диаграммы классов.
Сохранить проект под нужным именем на диске. Пусть наш проект хранится в каталоге Rose под
именем ATM_Model.mtl.
2. Активизация диаграммы вариантов одним из способов:
- через окно браузера проектов, раскрыв представление вариантов использования (Use Case
View) и дважды кликнув на пиктограмме Main;
- через пункт меню Browse/ Use Case Diagram.
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 9 из
12
При этом специальная панель инструментов преобразуется в соответствии с видом диаграммы.
3. Добавление актера на диаграмму
Щелкнуть левой кнопкой мыши на пиктограмме актера на специальной панели, а затем в окне диаграммы.
Задать актеру нужное имя.
Для указания стереотипа отношения выделить отношение, нажать правую кнопку мыши, выбрать в
контекстном меню и открыть диалоговое окно свойств отношения (Open Specification). Выбрать
нужный стереотип из предлагаемого списка.
4. Изменение и задание дополнительных характеристик и информации для элементов диаграмм
Выделить элемент, нажать правую кнопку мыши, выбрать в контекстном меню и открыть диалоговое окно свойств элемента (Open Specification). Задать нужную информацию.
5. Добавление варианта использования
Щелкнуть левой кнопкой мыши на пиктограмме варианта использования на специальной панели, а
затем в окне диаграммы.
Задать нужное имя варианта использования.
6. Добавление ассоциации между актером и вариантом использования
Щелкнуть левой кнопкой мыши на пиктограмме направленной ассоциации на специальной панели,
а затем в окне диаграммы на изображении актера и, не отпуская, протащить до изображения варианта использования. Отпустить кнопку.
7. Добавление отношения зависимости
Щелкнуть левой кнопкой мыши на пиктограмме зависимости на специальной панели, а затем в
окне диаграммы на изображении нужного варианта использования и, не отпуская, протащить до
изображения второго варианта использования, связанного данной зависимостью с первым. Отпустить кнопку.
Для указания стереотипа отношения в диалоговом окне свойств отношения выбрать нужный стереотип из предлагаемого списка.
В результате выполнения описанных действий для примера из п. 2 получаем требуемую диаграмму, отображение которой в соответствующем окне приведено на рис. 6.5.
 Добавление текстового файла со сценарием варианта использования
1. Сохранить сценарий в отдельном файле.
Для сценария примера (табл. 6.2 – 6.4) создадим файл Rose/scenario.doc.
2. Выделить вариант использования в браузере проекта. По щелчку правой кнопки мыши вызвать
контекстное меню.
3. Выполнить операцию New/File.
4. В появившемся окне задать имя добавляемого файла со сценарием. Пиктограмма файла появится в браузере проекта ниже соответствующего варианта использования (рис. 6.6).
При выделении этой пиктограммы, вызове контекстного меню и нажатии кнопки Открыть (или
двойном щелчке на пиктограмме) файл сценария открывается соответствующим приложением.
Таким образом, вся документация диаграммы варианта использования локализована в проекте,
отображается в браузере проекта и может быть дополнена и отредактирована.
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 10 из
12
Рис. 6.5. Диаграмма вариантов использования модели, созданная в Rational Rose
Добавленный
файл сценария
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 11 из
12
Рис. 6.6. Результат добавления файла сценария к диаграмме
 Разработка диаграммы классов
1. Активизация диаграммы классов
Окно этой диаграммы появляется по умолчанию в рабочем окне диаграмм после создания нового
проекта.
Другие способы открытия:
- через окно браузера проектов, раскрыв логическое представление (Logical View) и дважды
кликнув на пиктограмме Main;
- через пункт меню Browse/ Class Diagram.
При этом специальная панель инструментов соответствует виду диаграммы.
2. Добавление классов на диаграмму
Щелкнуть левой кнопкой мыши на пиктограмме класса на специальной панели, а затем в окне диаграммы. Задать классу нужное имя.
Для указания стереотипа класса выделить отношение, нажать правую кнопку мыши, выбрать в меню и открыть диалоговое окно свойств класса (Open Specification). Выбрать нужный стереотип из
предлагаемого списка.
Способ изображения стереотипного класса определяется опцией Options/Stereotype Display. Значение Label соответствует стандартному изображению..
3. Добавление атрибутов классов
Один из способов: выделить класс на диаграмме и через контекстное меню задать атрибут с помощью операции New Attribute. В области атрибутов задать имя атрибута.
Для изменения квантора видимости атрибута можно выделить класс и кликнуть левой кнопкой
мыши по пиктограмме видимости, приписанной атрибуту по умолчанию. В появившемся списке
пиктограмм выбрать нужную.
Тип атрибута можно описать, выделив класс и кликнув левой кнопкой мыши по имени атрибута;
курсор устанавливается в позицию, с которой можно набрать описание типа.
4. Добавление операций можно выполнить аналогично добавлению атрибутов.
5. Добавление отношений выполняется аналогично тому, как это делается для диаграммы вариантов использования.
Кратность отношения можно установить, выделив отношение и для каждого конца линии в контекстном меню выбрать пункт Multiplicity и нужное значение кратности.
Поскольку пример модели управления банкоматом является модельным, построим для него только часть диаграммы классов, изображенной на рис. 6.3. Эта частичная диаграмма приведена на
рис. 6.7.
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 12 из
12
Рис. 6.7. Часть диаграммы классов системы управления банкоматом,
построенной в Rational Rose
 Генерация программного кода
 Генерация программного кода в Rational Rose возможна для отдельного класса, пакета 1 или
компонента.
 Необходимой для генерации кода является лишь диаграмма компонентов.
С точки зрения общей модели системы эта диаграмма служит частью физического представления
модели (см. рис. 6.1).
С точки зрения смысла разделения системы на компоненты, согласно кн. Фаулера 2 (с. 159), такое
разделение является в большей мере маркетинговым решением, чем техническим. Компоненты
представляют собой элементы, которые можно независимо друг от друга купить и обновить.
Учитывая сказанное, будем полагать, что вся наша система представляет единственный компонент, изображенный на диаграмме рис. 6.8, созданной аналогично предыдущим.
SistemaUpravleniaBankomatom
Рис. 6.8. Диаграмма компонентов системы управления банкоматом
 Сгенерируем программный код для всех классов диаграммы классов. Один из способов таков.
Выделить нужные классы на диаграмме классов (например, «захватив» их курсором мыши). В
главном меню выбрать пункты Tools/ ANSI C++ / Generate Code. Задать каталог для размещения
файлов с кодом.
1
2
Пакеты в теме не рассматривались
Мартин Фаулер. UML. Основы. 3-е издание. – СПб: Символ, 2005. – 184 с.
Тема 6. Постр-е модели ср-вами UML и ее реализ. в CASE-инстр. Файл 147335079. С. 13 из
13
В данном случае все файлы размещены в каталоге Rose. Для каждого класса создан заголовочный файл с расширением h, содержащий объявление класса, и файл реализации с расширением
cpp и заготовкой для реализации операций класса.