Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

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

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

«class» - 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^;:^^

«Table»

T Schedule

semester: SMALLINT

T_ScheduleOffermglnfoJD : INTEGER

IstudentID : SMALLINT

# T_PrlmaiyScheduleOfferlnglnfo_T_ScheduleOfferlnglnfoJD : INTEGER

«Non-ldenti(y!ng»

«Table»

T_ScheduleOfferinglnfo

«Non-Identifying»

0..1

* status: SMALLINT

-T_ScheduleOfferinglnfoJD : INTEGER

«Non-ldentifying»

0..1

«Table»

T_PrimaryScheduleOfferinglnfo

^ grade : SMALLINT

T^ScheduleOfferinglnfoJD ; INTEGER

0..1

«Non-Identifying»

«Table»

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,

Рис. 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 ЬФ jtJM

«Table»

T Student

* 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

Ф Rat 1опаГЙо5ё::^»|:Ш«ёЩШШ)ШШ1ШШ^М

ЙФ

Ete

Ш й,»^ Fum^

©Wide ^«pot^C йч^гу в>о1$;

AM-lf^

Wf^^

:з

«Table»

Т Student

• name : SMALLINT

• address: SMALLINT

• nextAvalllD : SMALLINT

-studentID: SMALLINT

• dateofBirth : DATE

«PK» • PK_T_Student250

«Identifying»

«Table»

T Classification

studentIO : SMALLINT

«PK» • PK_T_Classlfication230

«Unique» + TC_T_Classlficatlon440

«FK» • FK_T_Classification230

«Index» • TC_T_Classification430

«Identifying»

«Table»

T FulltimeClassification

gradDate : SMALLINT

StudentID : SMALLINT

«PK» + PK_T_^FulltimeClassification280

«FK» • FK_TJFulltimeClasslfication280

«Identifying»

«Table»

T ParttimeClassification

^ maxNumCourses: SMALLINT

StudentID : SMALLINT

«PK» • PK_T_ParttimeClasslfication290

«FK» + FK_T_ParttimeClassification290

Jtib

Рис.

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

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

Целью объектно-ориентированного анализа является транс-

формация функциональных требований к ПО в предваритель-

ный системный проект

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

ры

системы.

процессе проектирования системный проект «пог-

346 Глава 4

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

требований.

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

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

анализа, проектные классы, процесс, поток.

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

Перечислите правила формирования схемы

базы

данных из

ERM.

К каким последствиям для системы может привести отсут-

ствие архитектурного анализа?

Что дает использование образцов распределения обязан-

ностей?

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

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

дики анализа и проектирования Rational Unified Process.

^=:--»^ \ <У г•^^^^^•^XД^^•=•\ «Ь^^'Й''V" Ач5 X*

П-r'f¥^

^^%'^Л-••^*-iU.,-4-^X-1V

\Ч'

ТЕХНОЛОГИИ СОЗДАНИЯ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

•

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

ПО,

•

Какие требования предъявляются

технологии создания

ПО.

• В

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

организации.

5.1.

ОПРЕДЕЛЕНИЕ ТЕХНОЛОГИИ

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

личные элементы технологии создания ПО (ТС ПО) - процессы,

методы, языки и др. В предыдущем издании учебника ТС ПО не-

формально определялась как совокупность технологических опе-

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

приводящая к разработке проекта ПО. Здесь мы дадим более раз-

вернутое и строгое определение ТС ПО.

Основные определения (система

понятий,

описывающих ТС ПО)

Технология

создания ПО

—

упорядоченная совокупность взаи-

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

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

технологических операций.

Технологическая операция —

основная единица работы, выпол-

няемая определенной ролью, которая:

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

• дает четко определенный результат (набор рабочих продук-

тов),

базирующийся на определенных исходных данных

(другом наборе рабочих продуктов);

• представляет собой единицу работы с жестко определенны-

ми границами, которые устанавливаются при планировании

проекта.

348

Глава

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

информационная или материальная сущ-

ность, которая создается, модифицируется

или

используется

некоторой технологической операции (модель, документ,

код,

тест

т.п.).

Рабочий продукт определяет область ответственности

роли и является объектом управления конфигурацией.

Роль —

определение поведения и обязанностей отдельного ли-

ца или группы лиц

среде организации-разработчика

ПО,

осуще-

ствляющих деятельность

рамках некоторого технологического

процесса и ответственных за определенные рабочие продукты.

Руководство —

практическое руководство по выполнению од-

ной

или

совокупности технологических операций. Руководства

включают методические материалы, инструкции, нормативы,

стандарты и критерии оценки качества рабочих продуктов.

Инструментальное средство (CASE-cpedcmeo) —

программное

средство, обеспечивающее автоматизированную поддержку дея-

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

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-средств).

Соответствие стандартам

означает также, в частности, ис-

пользование общепринятых, стандартных нотаций и соглашений.

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

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

моделирования и стандартных нотаций, которые должны быть

оформлены в виде нормативов до начала процесса проектирова-

ния. Несоблюдение проектных стандартов ставит разработчиков в

зависимость от фирмы

—

производителя данного средства, делает

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

ных решений и снижает возможности привлечения дополнитель-

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

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

методом (нотацией), может быть ограниченным.