n1

Анализ и проектирование программного обеспечения

341

•Если для некоторых ассоциаций нет необходимости в дву­ направленной связи, то вводятся направления навигации.

•Агрегации, обладающие свойствами композиции (см. подразд. 2.4.2), преобразуются в связи композиции.

Пример преобразования связей в соответствии с данными ре­ комендациями для классов варианта использования «Зарегист­ рироваться на курсы», приведен на рис. 4.34. Ассоциация между управляющим и фаничным классами преобразована в зависи­ мость. Агрегация между классами Student и Schedule обладает свойствами композиции. Направления навигации на ассоциаци­ ях между классами Schedule и CourseOffering введены по следую­ щим соображениям: нет необходимости в получении списка гра­ фиков, в которых присутствует какой-либо курс, и количество графиков относительно мало по сравнению с количеством кон­ кретных курсов.

%> Rational Й05е:^*оогШ^й;|аШШ;ШШ>шШМ

_J В» Ш ^»>9 Р&Ф^ grw*«s M>»t Qmf loofe

«entity» Student

. name : string

• address: string

« c l a s s » - nextAvaillD : int

. studentID : int

. dateofBirth : Date

Рис. 4.35. Преобразование обобщения

342

Глава 4

Связи обобщения могут преобразовываться в ситуациях с так называемой метаморфозой подтипов. Например, в случае с систе­ мой регистрации студент может переходить с очной формы обуче­ ния на вечернюю, т.е. объект Student может менять свой подтип. При таком изменении придется модифицировать описание объ­ екта в системе. Чтобы избежать этой модификации и тем самым повысить устойчивость системы, иерархия наследования реализу­ ется с помощью классификации, как показано на рис. 4.35.

Проектирование баз данных

Проектирование БД зависит от типа используемой для хране­ ния данных СУБД — объектной или реляционной. Для объектных БД никакого проектирования не требуется, поскольку классысущности непосредственно отображаются в БД. Для реляцион­ ных БД классы-сущности объектной модели должны быть отоб­ ражены в таблицы реляционной БД. Совокупность таблиц и свя­ зей между ними может быть представлена в виде диаграммы классов, которая по существу является ER-диаграммой. Набор правил, применяемых при отображении классов в таблицы БД, фактически совпадает с правилами преобразования сущностей и связей, описанными в подразд. 4.1. В технологии RUP, в частнос­ ти, для такого отображения используется специальный инстру­ мент - Data Modeler. Он выполняет преобразование классовсущностей в классы-таблицы с последующей генерацией описа­ ния БД на SQL.

Для описания схемы БД применяется следующий набор эле­ ментов языка UML со своими стереотипами (профиль UML):

•таблица представляется в виде класса со стереотипом «Table»;

•представление изображается в виде класса со стереотипом «View»;

•столбец таблицы представляется в виде атрибута класса с соответствующим типом данных;

•обычная ассоциация и афегация представляются в виде ас­ социации со стереотипом «Non-Identifying» (в терминоло­ гии IDEF1X — неидентифицирующей связи);

•композиция представляется в виде ассоциации со стереоти­ пом «Identifying» (в терминологии IDEF1X - идентифици­ рующей связи);

Анализ и проектирование программного обеспечения

343

•схема БД представляется в виде пакета со стереотипом «Schema», содержащего классы-таблицы;

•контейнер хранимых процедур представляется в виде класса со стереотипом «SP Container»;

•ограничения целостности, индексы и триггеры представля­ ются в виде операций классов-таблиц со стереотипами «РК» (Primary key), «FK» (Foreign key), «Unique», «Check», «Index» и «Triggep>;

•i> Rational Rose - coursereo^esiurtiw^ '^Шд1а Mdddipd^a^;:^^

« T a b l e » T Schedule

semester: SMALLINT

\n T_ScheduleOffermglnfoJD : INTEGER IstudentID : SMALLINT

# T_PrlmaiyScheduleOfferlnglnfo_T_ScheduleOfferlnglnfoJD : INTEGER

«Non-ldenti(y!ng»

«Non-Identifying»

0..1

« T a b l e » T_ScheduleOfferinglnfo

« T a b l e » T_PrimaryScheduleOfferinglnfo

* status: SMALLINT	^ grade : SMALLINT
-T_ScheduleOfferinglnfoJD : INTEGER	0..1 T^ScheduleOfferinglnfoJD ; INTEGER
	0..1
«Non-ldentifying»	«Non-Identifying»

« T a b l e » T_CourseOffering

• number: VARCHAR(255)
.startTime: SMALLINT
* endTime : SMALLINT
- days: SMALLINT
и T Course number: SMALLINT
n TiScheduleOfferlnglnfoJD : INTEGER
# T_PrlmaiyScheduleOfTeringlnfo_^T_ScheduleOfferlnglnfoJD	: INTEGER
»SM&lM^^.^«r,	JM

Рис. 4.36. Пример неидентифицирующих связей

344

Глава 4

•физическая база данных представляется в виде компонента со стереотипом «Database».

Примеры преобразования, выполненного для классов вари­ анта использования «Зарегистрироваться на курсы» средствами Data Modeler, приведены на рис. 4.36 — 4.38.

На рис. 4.36 ассоциации-классы, представляющие свойства связей между классами Schedule и CourseOffering (см. рис. 4.16), преобразованы в таблицы в соответствии с правилом преобразо­ вания бинарных связей типа «многие-ко-многим».

Идентифицирующая связь между таблицами T_Student и T_Schedule на рис. 4.37 соответствует связи композиции между классами Student и Schedule на рис. 4.34.

На рис. 4.38 показано преобразование связи обобщения, изображенной на рис. 4.35. Здесь используется отдельная табли­ ца для каждого подтипа (в соответствии с правилом из подразд. 4.1). Достоинства и недостатки различных способов преобразо­ вания обсуждались в подразд. 4.1). Преимуществом способа, применяемого в данном случае, является простота алгоритма ав­ томатического преобразования, выполняемого средствами Data Modeler.

^ Ratidrtat:R^^:gt:^$e*eai^ja^^

{j£|e £;<*< ^Jw ^m(^ firov»» 8зрроЛ iSiwr loofe ^^Ы jfeHtfew ЬФ jtJMJ

«Table»

TStudent

*name : SMALLINT

*address: SMALLINT

*nextAvaillD : SMALLINT

.studentID: SMALLINT + dateofBirth : DATE

«Identifying»

«Table» T Schedule

semester: SMALLINT

{# T ScheduleOfTeringlnfoJD : INTEGER StudentID : SMALLINT

Ш T_PrimaryScheduleOfferlnglnfo_T_ScheduleOfferinglnfoJD : INTEGER

Рис. 4.37. Пример идентифицирующей связи

Анализ и проектирование программного обеспечения		345
Ф Rat1опаГЙо5ё::^»|:Ш«ёЩШШ)ШШ1ШШ^М
Ete Ш й,»^ Fum^ ©Wide ^«pot^C йч^гу в>о1$; AM-lf^	Wf^^
ЙФ	:з
« T a b l e»

Т Student

• name : SMALLINT

• address: SMALLINT

• nextAvalllD : SMALLINT -studentID: SMALLINT

• dateofBirth : DATE

« P K » • PK_T_Student250 «Identifying» TT

«Table»

T Classification studentIO : SMALLINT

« P K » • PK_T_Classlfication230

«Unique» + TC_T_Classlficatlon440

« F K » • FK_T_Classification230

«Index» • TC_T_Classification430

«Identifying»

«Table»

T FulltimeClassification

gradDate : SMALLINT StudentID : SMALLINT

«Identifying»

« P K » + PK_T_^FulltimeClassification280

« F K » • FK_TJFulltimeClasslfication280

«Table»

TParttimeClassification

^maxNumCourses: SMALLINT StudentID : SMALLINT

« P K »	• PK_T_ParttimeClasslfication290
« F K »	+ FK_T_ParttimeClassification290

Jtib

Рис. 4.38. Пример преобразования обобщения

! Следует запомнить

Целью объектно-ориентированного анализа является транс­ формация функциональных требований к ПО в предваритель­ ный системный проект и создание стабильной основы архитекту­ ры системы. В процессе проектирования системный проект «пог-

346

Глава 4

ружается» в среду реализации с учетом всех нефункциональных требований.

^ Основные понятия

Архитектурные механизмы, архитектурные уровни, классы анализа, проектные классы, процесс, поток.

?Вопросы для самоконтроля

1.Перечислите правила формирования схемы базы данных из ERM.

2.К каким последствиям для системы может привести отсут­ ствие архитектурного анализа?

3.Что дает использование образцов распределения обязан­ ностей?

4.Какие классы нуждаются в моделировании состояний?

5.Охарактеризуйте достоинства и область применения мето­ дики анализа и проектирования Rational Unified Process.

^=:--»^ \ < У г•^^^^^•^XД^^•=•\ « Ь ^ ^ ' Й ' ' V " Ач5 X* П-r'f¥^ ^^%'^Л-••^*-iU.,-4-^X-1V \ Ч '

ТЕХНОЛОГИИ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Прочитав эту главу, вы узнаете:

•Что представляет собой технология создания ПО,

•Какие требования предъявляются к технологии создания ПО.

•В нем заключается процесс внедрения технологии в организации.

5 . 1 . ОПРЕДЕЛЕНИЕ ТЕХНОЛОГИИ

Начиная с введения, в разных контекстах упоминались раз­ личные элементы технологии создания ПО (ТС ПО) - процессы, методы, языки и др. В предыдущем издании учебника ТС ПО не­ формально определялась как совокупность технологических опе­ раций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта ПО. Здесь мы дадим более раз­ вернутое и строгое определение ТС ПО.

Основные определения (система понятий, описывающих ТС ПО)

Технология создания ПО — упорядоченная совокупность взаи­ мосвязанных технологических процессов в рамках ЖЦ ПО.

Технологический процесс — совокупность взаимосвязанных технологических операций.

Технологическая операция — основная единица работы, выпол­ няемая определенной ролью, которая:

•подразумевает четко определенную ответственность роли;

•дает четко определенный результат (набор рабочих продук­ тов), базирующийся на определенных исходных данных (другом наборе рабочих продуктов);

•представляет собой единицу работы с жестко определенны­ ми границами, которые устанавливаются при планировании проекта.

348

Глава 5

Рабочий продукт — информационная или материальная сущ­ ность, которая создается, модифицируется или используется в некоторой технологической операции (модель, документ, код, тест и т.п.). Рабочий продукт определяет область ответственности роли и является объектом управления конфигурацией.

Роль — определение поведения и обязанностей отдельного ли­ ца или группы лиц в среде организации-разработчика ПО, осуще­ ствляющих деятельность в рамках некоторого технологического процесса и ответственных за определенные рабочие продукты.

Руководство — практическое руководство по выполнению од­ ной или совокупности технологических операций. Руководства включают методические материалы, инструкции, нормативы, стандарты и критерии оценки качества рабочих продуктов.

Инструментальное средство (CASE-cpedcmeo) — программн средство, обеспечивающее автоматизированную поддержку дея­ тельности, выполняемой в рамках технологических операций.

4* Rationar йо $ е - :Нойе1 . ШШШШШ1111вИ

Технология

Руководство

Средство

1..* / 1-.*

• в х о д н ой \

/ +ВЫХОДНОЙ

Рабочий продукт

Рис. 5.1. Объектная модель ТС ПО

Технологии создания программного обеспечения

349

Данную систему понятий можно представить в виде объект­ ной модели на языке UML в виде совокупности абстракций (классов), соответствующих приведенным выше понятиям (рис. 5.1). Каждому классу модели соответствует множество объектов (экземпляров), определяющих конкретные элементы ТС ПО: технологические процессы, технологические операции, рабочие продукты, роли, CASE-средства и руководства.

Рабочий вариант (экземпляр) конкретной ТС ПО представля­ ет собой ТС ПО, адаптированную к условиям объекта внедрения и проектам создания ПО.

Динамическая модель, описывающая поведение ТС ПО в жизненном цикле ПО, представляется в виде последовательнос­ ти переходов между состояниями ТС ПО (рис. 5.2). Событием, инициирующим переход между различными состояниями ТС ПО, является изменение требований к ТС ПО, а ограничиваю­ щим условием перехода является соответствие комплексу крите­ риев оценки и выбора ТС ПО, который будет рассмотрен далее. Каждое состояние ТС ПО определяется набором ее элементов и

фRational Rose -:Моде1*т<11:*^:Г§Шес^^:0|аш^шшШЯВ gjb ЩЙ ;^w f^n^ grcH^se' ^mft ^my^ x<«>^''''''^l

:-^^M>t':^ir.}*^»*^h^*

Выбор ТС П0[ Соответствие критериям выбора ]	ifrtMil

Изменение требований

Состояние ТС ПО

Состояние элемента ТС ПО

Рис. 5.2. Диаграмма состояний ТС ПО

350

Глава 5

является композитным состоянием по отношению к состояниям отдельных элементов. Поведение каждого отдельного элемента ТС ПО (технологического процесса, технологической операции, рабочего продукта и др.) в ЖЦ ПО также представляется в виде последовательности переходов между его состояниями.

5.2. ОБЩИЕ ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ КТСПО

Основным требованием, предъявляемым к современным ТС

ПО, является их соответствие стандартам и нормативным до ментам, связанным с процессами ЖЦ ПО и оценкой технологи­ ческой зрелости организаций-разработчиков (ISO 12207, ISO 9000, СММ и др.). Согласно этим нормативам ТС ПО должна поддерживать следующие процессы:

•управление требованиями;

•анализ и проектирование ПО;

•разработка ПО;

•эксплуатация;

•сопровождение;

•документирование;

•управление конфигурацией и изменениями;

•тестирование;

•управление проектом.

Полнота поддержки процессов ЖЦ ПО должна поддерживать ся комплексом инструментальных средств (CASE-средств).

Соответствие стандартам означает также, в частности, ис­ пользование общепринятых, стандартных нотаций и соглашений. Для того чтобы проект мог выполняться разными коллективами разработчиков, необходимо использование стандартных методов моделирования и стандартных нотаций, которые должны быть оформлены в виде нормативов до начала процесса проектирова­ ния. Несоблюдение проектных стандартов ставит разработчиков в зависимость от фирмы — производителя данного средства, делает затруднительным формальный контроль корректности проект­ ных решений и снижает возможности привлечения дополнитель­ ных коллективов разработчиков, смены исполнителей и отчужде­ ния проекта, поскольку число специалистов, знакомых с данным методом (нотацией), может быть ограниченным.