Проектный практикум

Рис. 45. Установка параметров генерации DDL

5. Укажите расположение и имя (указав расширение .sql) текстового файла с результатами генерации (рис. 46) и щелкните по кнопке Next.

Рис. 46. Задание имени файла с результатами генерации DDL

101

Завершив генерацию, откройте созданный текстовый файл и просмот-

рите результаты.

Результаты генерации должны иметь следующий вид:

CREATE TABLE T_Order (

OrderNumber NUMBER ( 10 ) NOT NULL,

CustomerName VARCHAR2 ( 255 ) NOT NULL,

OrderDate DATE NOT NULL,

OrderFillDate DATE NOT NULL,

T_Order_ID NUMBER ( 10 ) NOT NULL,

CONSTRAINT PK_T_Order0 PRIMARY KEY (T_Order_ID)

)

/

CREATE TABLE T_OrderItem (

ItemID NUMBER ( 10 ) NOT NULL,

ItemDescription VARCHAR2 ( 255 ) NOT NULL,

T_Order_ID NUMBER ( 10 ),

CONSTRAINT PK_T_OrderItem1 PRIMARY KEY (ItemID)

)

/

CREATE INDEX TC_T_OrderItem1 ON T_OrderItem (T_Order_ID)

/

ALTER TABLE T_OrderItem ADD ( CONSTRAINT FK_T_OrderItem0 FOREIGN KEY (T_Order_ID) REFERENCES T_Order (T_Order_ID))

/

102

1.10.Публикация разработанного проекта

Упражнение 14. Публикация разработанного проекта

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

1.11.Количественная оценка UML диаграмм

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

цию. Для оценки информационной насыщенности диаграмм применяют ме-

тодику количественной оценки.

Методика количественной оценки и сравнения диаграмм UML строит-

ся на присвоении элементам диаграмм оценок, зависящих от их информаци-

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

Словарь языка UML включает два вида строительных блоков: сущно-

сти и отношения. Сущности - это абстракции, являющиеся основными эле-

ментами модели. Отношения связывают различные сущности.

Количественную оценку диаграммы можно выполнить по следующей формуле:

где S оценка диаграммы;

Sobj - оценки для элементов диаграммы;

SLnk - оценки для связей на диаграмме;

Obj - число объектов на диаграмме;

Тоbj ~ число типов объектов на диаграмме;

103

ТLnк - число типов связей на диаграмме.

Если диаграмма содержит большое число связей одного типа (напри-

мер, модель БД), то число и тип связей можно не учитывать и формула расчета приводится к виду:

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

вующего класса:

где Scls - оценка операций и атрибутов для класса;

Ор - число операций у класса;

Art - число атрибутов у класса.

При этом учитываются только атрибуты и операции, отображенные на диаграмме.

Далее в табл. 9 и 10 приводятся оценки для различных типов элементов и связей.

Таблица 2. Основные элементы языка UML

104

Таблица 3 Основные типы связей языка UML

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

Недостатком диаграммы является как слишком низкая оценка (при этом диаграмма недостаточно информативна), так и слишком высокая оценка

(при этом диаграмма обычно слишком сложна для понимания).

В табл. 4 приведены диапазоны оптимальных оценок для основных ти-

пов диаграмм.

Таблица 4. Диапазоны, оценок для диаграмм UML

Приведем пример оценки простой диаграммы классов (рис. 47) по при-

веденной выше методике.

Диаграмма содержит три класса без операций и атрибутов, следовательно Tobj = 1, Sobj = 15 и Obj=3. В качестве связей на диаграмме используются ассоциация, агрегирование и обобщение, следовательно

SLnk= 6 и ТLnk = 3.

105

Рис. 47. Диаграмма классов

Определим численную оценку диаграммы классов:

То есть численная оценка для данной диаграммы равна 3,5. Полученное значение лежит в рекомендуемом диапазоне (табл. 4).

106

2.СОЗДАНИЕ БАЗЫ ТРЕБОВАНИЙ К ПРОЕКТУ

2.1. Инструментальное средство IBM Rational Requisitepro

2.1.1. Общие сведения

Назначение RequisitePro - управление требованиями (организация тре-

бований и отслеживание их изменений в жизненном цикле ПО). Каждое тре-

бование имеет определенный тип (используемый для классификации требо-

ваний) и наименование. Требования содержат текст и обладают следующим стандартным набором атрибутов, который может быть расширен при необ-

ходимости:

•приоритет (высокий, средний, низкий);

•статус (предложено, одобрено, утверждено, реализовано, вери-

фицировано);

•стоимость (высокая, средняя, низкая или числовое значение);

•сложность реализации (высокая, средняя, низкая);

•стабильность (высокая, средняя, низкая);

•исполнитель.

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

(view). Вся информация о требованиях сохраняется в базе данных.

Проект RequisitePro включает базу данных требований и набор связан-

ных с ней документов (например, документы вариантов использования в RequisitePro содержат их обычные текстовые описания). Требования в этих до-

кументах связаны с базой данных, в которой хранится дополнительная ин-

формация о требованиях - атрибуты, связи трассировки, сведения о версии,

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

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

107

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

Проектная база данных - база данных требований, управляемая RequisitePro (одна из трех физических баз данных — Microsoft Access, Oracle или

Microsoft SQL Server). Каждый проект RequisitePro имеет собственную базу данных.

Основным элементом интерфейса RequisitePro является Проводник

(Explorer). В его окне отображаются в иерархической упорядоченности раз-

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

2.1.2. Создание проекта RequisitePro

Для создания проекта RequisitePro:

1.Запустите RequisitePro из меню программ, сразу после запуска может появиться интерфейс системной помощи Let's Go. Закройте его. Затем появится диалоговое окно "Open Project". Оно позволяет выбрать проект для работы с ним (вкладка "Existing") или создать новый проект (вкладка "New").

2.После выбора вкладки "New" появится диалоговое окно "Create Project" (рис. 48). Здесь необходимо указать шаблон, на основе которого бу-

дет создан новый проект. Шаблоны "Composite Template‖, "Traditional Template" и "Use Case Template" содержат готовые наборы типов требований и типов документов, которые можно использовать для того, чтобы приступить к новому проекту RequisitePro. При выборе одного из указанных шаблонов эти типы требований и документов будут добавлены в новый проект. Описа-

ние выделенного шаблона можно получить в нижнем поле окна "Create Project". Выбор пустого шаблона "Blank" позволит создать новый проект с чистого листа. Выбор "Make New Template" запускает специальный мастер,

позволяющий самостоятельно построить новый шаблон на основе имеюще-

108

гося проекта. При этом в шаблон войдут уже имеющиеся требования и доку-

менты этого проекта.

Рис. 48.Диалоговое окно Create Progect

3.Выберите шаблон "Blank" и щелкните по кнопке ОК.

Появится новое диалоговое окно "Rational RequisitePro Project Properties"

(рис. 49), в котором необходимо указать название создаваемого проекта, за-

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

нительную информацию) и описание проекта.

4. Щелкните по кнопке ОК для создания проекта. Проект появится в окне Проводника. Если появится сообщение "Project directory does not exist. Do you want to create it?", щелкните по кнопке Yes.

109

Рис. 49. Диалоговое окно Свойства проекта

2.1.3. Создание типов требований в проекте RequisitePro

Перед описанием требований необходимо определить их типы:

1. Выберите пункт меню File > Properties, появится диалоговое окно

"Project Properties". Для добавления новых типов требований активизируйте вкладку "Requirement Types" (рис. 50).

Рис. 50. Окно Свойства проекта (Типы требований)

110