ПР / ПР3 / РазрабСтанд2021_ЛР3

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

7.Определить операции для каждого класса. Это можно сделать, анализируя диаграмму последовательности данного прецедента (лаб. работа 2). Для создания операции нужно открыть окно спецификации класса (2с по классу), активизировать вкладку Operations и в поле операции из к.з. меню исполнить команду Insert или из к.з. меню на классе исполнить команду New Operation. Для каждой операции указать тип возвращаемого значения (Return Type), если необходимо, и область видимости. Для всех операций, кроме Проверить найденное и Вычесть найденное, указать область видимости Public, а для указанных выше – Private. Это можно сделать, открыв окно спецификации операции (2с на имени операции в окне спецификаций класса). Для каждой операции в коде программы будет создана процедура. Для операции Ввести сообщение в классе Экран банкомата определить аргумент ввод типа Integer. Для задания аргумента нужно активизировать вкладку Detail для операции. Для операций Найти и Вычесть найденное определить аргумент счет типа Long. Для того, чтобы вся информация об операциях класса отображалась на экране,

нужно выполнить команду Options/Show Operation Signature из к.з. меню,

открытого на классе.

Классы могут иначе отображаться на диаграмме классов, если акцентировать внимание на типе класса. Для того чтобы перейти к другому изображению классов, надо из к.з. меню на классе выполнить команду Options/Stereotype Display/Icon. Чтобы вернуться снова к изображению рисунке 3.1, надо из к.з. меню выполнить команду

Options/Stereotype Display/Label.

11

Диаграммы пакетов

Пакеты используют, чтобы сгруппировать классы, обладающие некоторой общностью. Существует несколько подходов к группировке:

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

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

Пакеты могут быть связаны друг с другом. Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует любая зависимость. Таким образом, может быть построена диаграмма пакетов, которая представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Иначе говоря, диаграмма пакетов – это форма диаграммы классов. На рисунке 3.7 дан пример диаграммы пакетов для стереотипа Снять деньги со счета банковской системы, в которой использован принцип группирования классов в пакет по стереотипу.

пакет сущ ностей граничный

пакет

Рисунок 3.7. Диаграмма пакетов для стереотипа Снять деньги со счета

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

Классов в системе может быть очень много. Диаграммы пакетов позволяют

уменьшить количество обозримых объектов системы за счет объединения классов в пакет. 12

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

13

Диаграммы компонентов

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

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

На рисунках 3.8 и 3.9 изображены диаграммы компонентов для банковской системы при условии, что система разрабатывается на языке C++.

<<EXE>>

Клиент_банкомата

<<Package Specification>>

Экран банкомата

Рисунок 3.8. Диаграмма компонентов для клиентской части банковской системы

14

<<EXE>>

Сервер_банкомата

<<ActiveX>>

Счет

<<Package Specification>>

Счет

Рисунок 3.9. Диаграмма компонентов для сервера банковской системы

На диаграммах для каждого класса изображены собственные заголовочные файлы и файлы с расширением .CPP (для C++). Например, для класса Счет компонента «EXE» Счет является заголовочным файлом класса языка C++ (файл с расширением .H), а компонента «Package Specification» Счет – соответствует файлу тела класса Счет на языке C++ (файл с расширением .CPP).

На диаграмме рис.3.8 компонент «EXE» Клиент_банкомата является спецификацией задачи и представляет поток обработки информации. В данном случае поток обработки является исполняемой программой.

Компоненты соединены штриховой линией, что соответствует зависимостям между ними. Например, класс Устройство для чтения карточек зависит от класса

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

банкомата.exe.

Пример банковской системы содержит два потока обработки, и таким образом получаются два исполняемых файла. Один из них – это клиентская часть системы, она содержит компоненты Кассовый аппарат, Устройство для чтения карточек и Экран банкомата. Второй файл – это сервер, включающий в себя компонент Счет (Менеджер банкомата опущен).

15

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

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

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

1.На папке Component View в браузере объектов открыть к.з. меню и исполнить команду New/ Component Diagram и дать диаграмме имя Компоненты банк_системы для клиента.

2.С помощью элемента Component на панели элементов диаграммы поместить на диаграмму компоненту и дать ей имя Клиент банкомата.

3.Открыв окно спецификации компоненты (2с по компоненте), выбрать из списка

Stereotype стереотип EXE.

4.Аналогично нанести на диаграмму компоненты Устройство для чтения карточек, Экран банкомата и Кассовый аппарат со стереотипами ActiveX.

5.С помощью элемента Package Specification добавить на диаграмму элементы

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

Им автоматически будет присвоен стереотип Package Specification. Можно было воспользоваться и элементом Component, но тогда нужно было бы принудительно устанавливать стереотип Package Specification, как это было указано в п.3.

6.Аналогично создать диаграмму компонентов, изображенную на рисунке 3.9.

16

Рассмотрим эти шаги на конкретном примере системы банкомата.

Пусть создана модель, диаграмма классов которой представлена на рисунке 3.10. Предположим, что эта диаграмма классов находится в пакете Моя модель логического представления (Logical View). Необходимо создать пакет Моя модель в папке логического представления, и перетащить в него все необходимые классы.

Классы Устройство для чтения карточек и Счет имеют стереотип Сущность

(entity). Поэтому будем считать, что имеется реляционная БД, состоящая из двух взаимосвязанных таблиц, соответствующих этим сущностям. Из диаграммы классов видно, что они имеют общий атрибут номер карточки.

Шаг 1. Создание нового компонента – базы данных.

1.Из к.з. меню на пакете Component View выполнить команду Data Modeler/New/Database. В результате появится новая компонента DB_0 или с другим номером, если эту команду выполняли неоднократно, а также папки

Global Data Types и Schemas.

2.Открыть окно спецификации для вновь созданного компонента DB_0 и в списке Target выбрать стандарт языка SQL, который будет использоваться для описания БД. Если БД будет реализована в среде Access, то следует выбрать

ANSI SQL 92.

Шаг 2. Определение устойчивых (persistent) классов.

Такими классами являются те, которые будут отображаться таблицами в БД.

Это классы Устройство для чтения карточек и Счет.

1.Открыть окно спецификации класса Устройство для чтения карточек в пакете

Моя модель.

2.Перейти на вкладку Detail и установить значение переключателя Persistence из положения Transparent в положение Persistent.

3.То же самое проделать для класса Счет.

4.Для класса Устройство для чтения карточек открыть перечень атрибутов и операций (нажав «+» в браузере слева от названия класса).

5.Из к.з. меню на имени атрибута номер карточки выбрать команду Data Modeler/Part of Object Identity, тем самым назначив этот атрибут первичным ключом.

18

6. То же самое проделайте для атрибута номер_счета для класса Счет.

Шаг 3. Создание схемы БД.

1.Из к.з. меню на пакете Моя модель выполнить команду Data

Modeler/Transform to Data Model.

2.В открывшемся окне в списке Target Database указать DB_0 и закрыть окно кнопкой ОК. В результате в логическом представлении в пакете Schemas появится пакет «Schema S_0», в который войдут две таблицы Устройство для чтения карточек и Счет.

3.Из к.з. меню на пакете «Schema S_0» выполнить команду Data Modeler/New/Data Model Diagram. В пакете «Schema S_0» появится новая диаграмма NewDiagram (диаграмма «сущность – связь»).

4.Откройте эту диаграмму и нанесите на нее все классы – таблицы, находящиеся в пакете «Schema S_0».

Получим диаграмму, изображенную на рисунке 3.11.

T_Счет

номер_счета_ : INTEGER PIN : INTEGER

баланс : INTEGER

номер_карточки : INTEGER COL_1 : INTEGER

<<PK>> PK_T_Счет2() <<FK>> FK_T_Счет1() <<Index>> TC_T_Счет4() <<Unique>> TC_T_Счет5()

1

<<Non-Identifying>>

0..1

T_Устройство_для_чтения_карточек

номер_карточки : INTEGER

<<PK>> PK_T_Устройство_для_чтения_3()

Рисунок 3.11. Диаграмма «сущность – связь»

19

Шаг 4. Генерация описания БД на SQL.

1.Из к.з. меню на пакете «Schema S_0» выполнить команду Data Modeler/Forward Engineer. Произойдет запуск генератора описания БД на SQL и нажмите кн. Next.

2.На следующем шаге мастера установить все флажки генерации и кн. Next.

3.Указать имя и расположение текстового файла с результатами генерации. Например, пусть это будет файл БД_моя модель. Довести до конца работу с мастером.

4.После завершения генерации открыть созданный текстовый файл (например, в блокноте) и просмотрите результаты. Этот файл для данного примера будет таким:

ALTER TABLE "S_0"."T_Счет" DROP CONSTRAINT "FK_T_Счет1"; DROP TABLE "S_0"."T_Счет";

DROP TABLE "S_0"."T_Устройство_для_чтения_карточек"; CREATE TABLE "S_0"."T_Счет" (

"номер_счета_" INTEGER NOT NULL, "PIN" INTEGER NOT NULL,

"баланс" INTEGER NOT NULL, "номер_карточки" INTEGER NOT NULL, "COL_1" INTEGER,

CONSTRAINT "TC_T_Счет5" UNIQUE ("COL_1"),

CONSTRAINT "PK_T_Счет2" PRIMARY KEY ("номер_счета_") ); CREATE TABLE "S_0"."T_Устройство_для_чтения_карточек" (

"номер_карточки" INTEGER NOT NULL,

CONSTRAINT "PK_T_Устройство_для_чтения_3" PRIMARY KEY ("номер_карточки") );

CREATE INDEX "S_0"."TC_T_Счет4" ON "S_0"."T_Счет" ("COL_1");

ALTER TABLE "S_0"."T_Счет" ADD CONSTRAINT "FK_T_Счет1" FOREIGN KEY ("COL_1") REFERENCES "S_0"."T_Устройство_для_чтения_карточек" ("номер_карточки") ON DELETE NO ACTION ON UPDATE NO ACTION;

20